diff options
| author | Paolo Carlini <paolo@gcc.gnu.org> | 2009-07-23 15:50:16 +0000 |
|---|---|---|
| committer | Paolo Carlini <paolo@gcc.gnu.org> | 2009-07-23 15:50:16 +0000 |
| commit | f50e1d8436260c7fceff35cf62fe5fe0d03fc216 (patch) | |
| tree | 4f566aad684366f547aa61adbd447725a92dd523 | |
| parent | 6d53a79fde65d6d9bcfd445a250e9c3d2c92c703 (diff) | |
| download | gcc-f50e1d8436260c7fceff35cf62fe5fe0d03fc216.zip gcc-f50e1d8436260c7fceff35cf62fe5fe0d03fc216.tar.gz gcc-f50e1d8436260c7fceff35cf62fe5fe0d03fc216.tar.bz2 | |
lwg-closed.html: Update to R65.
2009-07-23 Paolo Carlini <paolo.carlini@oracle.com>
* doc/html/ext/lwg-closed.html: Update to R65.
* doc/html/ext/lwg-defects.html: Likewise.
* doc/html/ext/lwg-active.html: Likewise.
* doc/xml/manual/intro.xml: Update DRs entries.
From-SVN: r150016
| -rw-r--r-- | libstdc++-v3/doc/html/ext/lwg-active.html | 34680 | ||||
| -rw-r--r-- | libstdc++-v3/doc/html/ext/lwg-closed.html | 6813 | ||||
| -rw-r--r-- | libstdc++-v3/doc/html/ext/lwg-defects.html | 10028 | ||||
| -rw-r--r-- | libstdc++-v3/doc/xml/manual/intro.xml | 16 |
4 files changed, 39902 insertions, 11635 deletions
diff --git a/libstdc++-v3/doc/html/ext/lwg-active.html b/libstdc++-v3/doc/html/ext/lwg-active.html index 94b57c0..2413048 100644 --- a/libstdc++-v3/doc/html/ext/lwg-active.html +++ b/libstdc++-v3/doc/html/ext/lwg-active.html @@ -14,11 +14,11 @@ del {background-color:#FFA0A0} <table> <tbody><tr> <td align="left">Doc. no.</td> -<td align="left">N2727=08-0237</td> +<td align="left">N2894=09-0084</td> </tr> <tr> <td align="left">Date:</td> -<td align="left">2008-08-24</td> +<td align="left">2009-06-21</td> </tr> <tr> <td align="left">Project:</td> @@ -29,9 +29,9 @@ del {background-color:#FFA0A0} <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> +<h1>C++ Standard Library Active Issues List (Revision R65)</h1> - <p>Reference ISO/IEC IS 14882:1998(E)</p> + <p>Reference ISO/IEC IS 14882:2003(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> @@ -43,8 +43,8 @@ del {background-color:#FFA0A0} <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> + potential defects in the ISO/IEC IS 14882:2003(E) document. + </p> <p>This document contains only library issues which are actively being considered by the Library Working Group. That is, issues which have a @@ -58,11 +58,6 @@ del {background-color:#FFA0A0} 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 @@ -78,24 +73,160 @@ del {background-color:#FFA0A0} <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 + the document number above, reference ISO/IEC 14882:2003(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>R65: +2009-06-19 pre-Frankfurt mailing. +<ul> +<li><b>Summary:</b><ul> +<li>378 open issues, up by 32.</li> +<li>765 closed issues, up by 0.</li> +<li>1143 issues total, up by 32.</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#1115">1115</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1116">1116</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1117">1117</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1118">1118</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1119">1119</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1120">1120</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1121">1121</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1122">1122</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1123">1123</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1124">1124</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1125">1125</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1126">1126</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1127">1127</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1128">1128</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1129">1129</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1130">1130</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1131">1131</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1132">1132</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1133">1133</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1134">1134</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1135">1135</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1136">1136</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1137">1137</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1138">1138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1139">1139</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1140">1140</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1141">1141</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1142">1142</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1143">1143</a>.</li> +<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1112">1112</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1113">1113</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1114">1114</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#937">937</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#696">696</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-active.html#727">727</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#900">900</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#911">911</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#916">916</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#917">917</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#920">920</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#933">933</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#935">935</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#941">941</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#947">947</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#951">951</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#953">953</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#954">954</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#955">955</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#956">956</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#977">977</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#978">978</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#985">985</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#989">989</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#996">996</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1033">1033</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1054">1054</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1056">1056</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1057">1057</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1059">1059</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1062">1062</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1068">1068</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1069">1069</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1071">1071</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1072">1072</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1076">1076</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1090">1090</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1092">1092</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1096">1096</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1098">1098</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1099">1099</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1105">1105</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1106">1106</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1108">1108</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1110">1110</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#817">817</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#971">971</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#992">992</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1004">1004</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1010">1010</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1012">1012</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1015">1015</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1019">1019</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#780">780</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#897">897</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#919">919</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#939">939</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#957">957</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#983">983</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1001">1001</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1080">1080</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1091">1091</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1093">1093</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1094">1094</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1095">1095</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1097">1097</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1102">1102</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1104">1104</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1111">1111</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#921">921</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#987">987</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1087">1087</a>.</li> +<li>Changed the following issues from New to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#568">568</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-active.html#785">785</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#903">903</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#912">912</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#918">918</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#946">946</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#995">995</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1074">1074</a>.</li> +<li>Changed the following issues from Open to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#458">458</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#644">644</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#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>.</li> +<li>Changed the following issues from Review to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#901">901</a>.</li> +<li>Changed the following issues from Tentatively Ready to Tentatively NAD: <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#988">988</a>.</li> +<li>Changed the following issues from New to Tentatively NAD Editorial: <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#862">862</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#927">927</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#945">945</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#952">952</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#969">969</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#972">972</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#973">973</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#979">979</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1058">1058</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1060">1060</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1061">1061</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1077">1077</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1101">1101</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1109">1109</a>.</li> +<li>Changed the following issues from Open to Tentatively NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#424">424</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#884">884</a>.</li> +<li>Changed the following issues from Review to Tentatively NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1023">1023</a>.</li> +<li>Changed the following issues from Open to Tentatively NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#96">96</a>.</li> +<li>Changed the following issues from New to Tentatively Ready: <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#898">898</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#906">906</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#910">910</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#913">913</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#914">914</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#915">915</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#925">925</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#974">974</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#976">976</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#981">981</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#982">982</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#984">984</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#990">990</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#998">998</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#999">999</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1063">1063</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1067">1067</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1070">1070</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1073">1073</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1100">1100</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1103">1103</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1107">1107</a>.</li> +<li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#814">814</a>.</li> +<li>Changed the following issues from Review to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#899">899</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#907">907</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#909">909</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#934">934</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#938">938</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#940">940</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#943">943</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#950">950</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#965">965</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#970">970</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#975">975</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#986">986</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#991">991</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#993">993</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#994">994</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#997">997</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1002">1002</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1006">1006</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1011">1011</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1013">1013</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1014">1014</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1021">1021</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1024">1024</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1037">1037</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1038">1038</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1039">1039</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1040">1040</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1044">1044</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1045">1045</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1065">1065</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1066">1066</a>.</li> +</ul></li> +</ul> +</li> +<li>R64: +2009-05-01 mid-term mailing. +<ul> +<li><b>Summary:</b><ul> +<li>346 open issues, up by 19.</li> +<li>765 closed issues, up by 0.</li> +<li>1111 issues total, up by 19.</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#1093">1093</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1094">1094</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1095">1095</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1096">1096</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1097">1097</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1098">1098</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1099">1099</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1100">1100</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1101">1101</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1102">1102</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1103">1103</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1104">1104</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1105">1105</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1106">1106</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1107">1107</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1108">1108</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1109">1109</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1110">1110</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1111">1111</a>.</li> +<li>Changed the following issues from DR to CD1: <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-defects.html#386">386</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#406">406</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#409">409</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#413">413</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#434">434</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#438">438</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#444">444</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#445">445</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#455">455</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#457">457</a>, <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-defects.html#469">469</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#533">533</a>.</li> +<li>Changed the following issues from Review to New: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1070">1070</a>.</li> +</ul></li> +</ul> +</li> +<li>R63: +2009-03-20 post-Summit mailing. +<ul> +<li><b>Summary:</b><ul> +<li>327 open issues, up by 96.</li> +<li>765 closed issues, up by 14.</li> +<li>1092 issues total, up by 110.</li> +</ul></li> +<li><b>Details:</b><ul> +<li>Added the following NAD Editorial issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1022">1022</a>.</li> +<li>Added the following NAD Future issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1025">1025</a>.</li> +<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#983">983</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#984">984</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#985">985</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#989">989</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#990">990</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#995">995</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#996">996</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#998">998</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#999">999</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1001">1001</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1033">1033</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1054">1054</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1056">1056</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1057">1057</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1058">1058</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1059">1059</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1060">1060</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1061">1061</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1062">1062</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1063">1063</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1067">1067</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1068">1068</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1069">1069</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1071">1071</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1072">1072</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1073">1073</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1074">1074</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1076">1076</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1077">1077</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1080">1080</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1090">1090</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1091">1091</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1092">1092</a>.</li> +<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#987">987</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1000">1000</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1007">1007</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1008">1008</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1016">1016</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1017">1017</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1018">1018</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1020">1020</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1026">1026</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1027">1027</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1028">1028</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1029">1029</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1030">1030</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1031">1031</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1032">1032</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1034">1034</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1035">1035</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1036">1036</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1041">1041</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1042">1042</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1046">1046</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1048">1048</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1051">1051</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1052">1052</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1053">1053</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1055">1055</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1064">1064</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1075">1075</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1078">1078</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1079">1079</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1081">1081</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1082">1082</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1083">1083</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1084">1084</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1085">1085</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1086">1086</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1087">1087</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1088">1088</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1089">1089</a>.</li> +<li>Added the following Review issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#986">986</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#991">991</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#992">992</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#993">993</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#994">994</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#997">997</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1002">1002</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1003">1003</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1004">1004</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1005">1005</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1006">1006</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1009">1009</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1010">1010</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1011">1011</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1012">1012</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1013">1013</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1014">1014</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1015">1015</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1019">1019</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1021">1021</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1023">1023</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1024">1024</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1037">1037</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1038">1038</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1039">1039</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1040">1040</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1043">1043</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1044">1044</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1045">1045</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1047">1047</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1049">1049</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1050">1050</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1065">1065</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1066">1066</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1070">1070</a>.</li> +<li>Added the following Tentatively Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#988">988</a>.</li> +<li>Changed the following issues from New to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#905">905</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#942">942</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#980">980</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#874">874</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#875">875</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#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#793">793</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#794">794</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#800">800</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#683">683</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#892">892</a>.</li> +<li>Changed the following issues from Ready to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#803">803</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#466">466</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#111">111</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#149">149</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#219">219</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#880">880</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#891">891</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#893">893</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#902">902</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#908">908</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#921">921</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#923">923</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#924">924</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#926">926</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#930">930</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#936">936</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#944">944</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#958">958</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#959">959</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#960">960</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#961">961</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#962">962</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#963">963</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#964">964</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#966">966</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#967">967</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#968">968</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#788">788</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#937">937</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#879">879</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#899">899</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#901">901</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#907">907</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#909">909</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#929">929</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#934">934</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#938">938</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#940">940</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#943">943</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#950">950</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#965">965</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#970">970</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#971">971</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#975">975</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#817">817</a>.</li> +<li>Changed the following issues from New to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#904">904</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#922">922</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#928">928</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#931">931</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#932">932</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#948">948</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#949">949</a>.</li> +<li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#890">890</a>.</li> +<li>Changed the following issues from Review to Tentatively Ready: <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-active.html#822">822</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#869">869</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#878">878</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#888">888</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#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#821">821</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#866">866</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#894">894</a>.</li> +</ul></li> +</ul> +</li> +<li>R62: +2009-02-06 pre-Summit mailing. +<ul> +<li><b>Summary:</b><ul> +<li>231 open issues, up by 44.</li> +<li>751 closed issues, up by 0.</li> +<li>982 issues total, up by 44.</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#939">939</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#940">940</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#941">941</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#942">942</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#943">943</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#944">944</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#945">945</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#946">946</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#947">947</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#948">948</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#949">949</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#950">950</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#951">951</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#952">952</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#953">953</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#954">954</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#955">955</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#956">956</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#957">957</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#958">958</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#959">959</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#960">960</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#961">961</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#962">962</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#963">963</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#964">964</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#965">965</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#966">966</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#967">967</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#968">968</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#969">969</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#970">970</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#971">971</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#972">972</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#973">973</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#974">974</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#975">975</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#976">976</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#977">977</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#978">978</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#979">979</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#980">980</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#981">981</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#982">982</a>.</li> +</ul></li> +</ul> +</li> +<li>R61: +2008-12-05 mid-term mailing. +<ul> +<li><b>Summary:</b><ul> +<li>187 open issues, up by 20.</li> +<li>751 closed issues, up by 0.</li> +<li>938 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-active.html#919">919</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#920">920</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#921">921</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#922">922</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#923">923</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#924">924</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#925">925</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#926">926</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#927">927</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#928">928</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#929">929</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#930">930</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#931">931</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#932">932</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#933">933</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#934">934</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#935">935</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#936">936</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#937">937</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#938">938</a>.</li> +</ul></li> +</ul> +</li> +<li>R60: +2008-10-03 post-San Francisco mailing. +<ul> +<li><b>Summary:</b><ul> +<li>167 open issues, down by 25.</li> +<li>751 closed issues, up by 65.</li> +<li>918 issues total, up by 40.</li> +</ul></li> +<li><b>Details:</b><ul> +<li>Added the following CD1 issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#882">882</a>.</li> +<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#879">879</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#880">880</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#891">891</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#893">893</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#897">897</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#898">898</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#899">899</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#900">900</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#901">901</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#902">902</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#903">903</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#904">904</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#905">905</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#906">906</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#907">907</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#908">908</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#909">909</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#910">910</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#911">911</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#912">912</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#913">913</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#914">914</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#915">915</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#916">916</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#917">917</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#918">918</a>.</li> +<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#881">881</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#883">883</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#884">884</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#885">885</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#886">886</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#887">887</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#889">889</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#890">890</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#895">895</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#896">896</a>.</li> +<li>Added the following Pending NAD Editorial issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#892">892</a>.</li> +<li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#894">894</a>.</li> +<li>Added the following Review issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#888">888</a>.</li> +<li>Changed the following issues from New to CD1: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#818">818</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#820">820</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#843">843</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#845">845</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#846">846</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#856">856</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#858">858</a>.</li> +<li>Changed the following issues from Ready to CD1: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#396">396</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#714">714</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#762">762</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#769">769</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#772">772</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#776">776</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#779">779</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#787">787</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#805">805</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#806">806</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#807">807</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#808">808</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#809">809</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#813">813</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#824">824</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#829">829</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#842">842</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#844">844</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#848">848</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#850">850</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#852">852</a>.</li> +<li>Changed the following issues from Review to CD1: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#23">23</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#698">698</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#709">709</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#804">804</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#823">823</a>.</li> +<li>Changed the following issues from WP to CD1: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#44">44</a>, <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#92">92</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#98">98</a>, <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#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#118">118</a>, <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#123">123</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#167">167</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#179">179</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#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#187">187</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#198">198</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#200">200</a>, <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#202">202</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#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#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#228">228</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#230">230</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#231">231</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#233">233</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#235">235</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#238">238</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#239">239</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#240">240</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#243">243</a>, <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#248">248</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#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#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-defects.html#256">256</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-defects.html#259">259</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#264">264</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#266">266</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#268">268</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#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#274">274</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#276">276</a>, <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#280">280</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#282">282</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#283">283</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#291">291</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#294">294</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#300">300</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#305">305</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#310">310</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#311">311</a>, <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#315">315</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#316">316</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#317">317</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#318">318</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#319">319</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#320">320</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#321">321</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#322">322</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#324">324</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#325">325</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#327">327</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#328">328</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#329">329</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#331">331</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#333">333</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#334">334</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#335">335</a>, <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-defects.html#337">337</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#338">338</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#339">339</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#340">340</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#341">341</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#345">345</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#346">346</a>, <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-defects.html#349">349</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#352">352</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#354">354</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#355">355</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#358">358</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#359">359</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#360">360</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#363">363</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#364">364</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#365">365</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#370">370</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#373">373</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#375">375</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#379">379</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#380">380</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#381">381</a>, <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#384">384</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#391">391</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#395">395</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#400">400</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#402">402</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#403">403</a>, <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-defects.html#405">405</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#407">407</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#410">410</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#411">411</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#412">412</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#414">414</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#415">415</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#420">420</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#425">425</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#426">426</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#428">428</a>, <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-defects.html#435">435</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#436">436</a>, <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#442">442</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#443">443</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#448">448</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#449">449</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#453">453</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#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#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#488">488</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#496">496</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#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#519">519</a>, <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#524">524</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</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#534">534</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>, <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#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-defects.html#550">550</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#552">552</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#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#566">566</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#574">574</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#577">577</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#581">581</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#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#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#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#612">612</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#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#619">619</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#628">628</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#638">638</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>, <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#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#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-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#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-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-defects.html#685">685</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#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-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>, <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#712">712</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> +<li>Changed the following issues from Open to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#670">670</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#849">849</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#855">855</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#871">871</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#454">454</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#832">832</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#811">811</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#812">812</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#841">841</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#864">864</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#870">870</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#872">872</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#299">299</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#484">484</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#556">556</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#676">676</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#724">724</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#742">742</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#532">532</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-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>.</li> +<li>Changed the following issues from New to Open: <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-active.html#751">751</a>, <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#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#819">819</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#836">836</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#838">838</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#857">857</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>, <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#873">873</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>.</li> +<li>Changed the following issues from Pending NAD Editorial to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#424">424</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#625">625</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#851">851</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#788">788</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#821">821</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#866">866</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#753">753</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#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#803">803</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#765">765</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#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#869">869</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#878">878</a>.</li> +<li>Changed the following issues from TC to TC1: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1">1</a>, <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#5">5</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#7">7</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#11">11</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#13">13</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#14">14</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#15">15</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#16">16</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#17">17</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#18">18</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#20">20</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#21">21</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#22">22</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#24">24</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#25">25</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#27">27</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#28">28</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#29">29</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#30">30</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#32">32</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#33">33</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#34">34</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#35">35</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#36">36</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#37">37</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#38">38</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#39">39</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#40">40</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#41">41</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#42">42</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#46">46</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#47">47</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#48">48</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#50">50</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#51">51</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#52">52</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#53">53</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#54">54</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#55">55</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#56">56</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#57">57</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#59">59</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</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#62">62</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#64">64</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#66">66</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#68">68</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#69">69</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#70">70</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#71">71</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#74">74</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#75">75</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#78">78</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#79">79</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#80">80</a>, <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#90">90</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#106">106</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#110">110</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#119">119</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#124">124</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#125">125</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#126">126</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#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-defects.html#137">137</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#139">139</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#141">141</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#148">148</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#150">150</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#151">151</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#152">152</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#154">154</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#155">155</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#156">156</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#158">158</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#160">160</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#161">161</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#168">168</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#169">169</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#172">172</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#173">173</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#174">174</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#175">175</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#176">176</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#189">189</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#193">193</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</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>.</li> +</ul></li> +</ul> +</li> <li>R59: 2008-08-22 pre-San Francisco mailing. <ul> @@ -105,7 +236,7 @@ del {background-color:#FFA0A0} <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> +<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#870">870</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#871">871</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.html#874">874</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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> @@ -118,11 +249,11 @@ del {background-color:#FFA0A0} <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>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-closed.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-defects.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> +<li>Changed the following issues from WP to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.html#709">709</a>.</li> </ul></li> </ul> </li> @@ -136,24 +267,24 @@ del {background-color:#FFA0A0} </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 New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#841">841</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#843">843</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#845">845</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-closed.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-closed.html#855">855</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.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 Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#842">842</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#844">844</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#848">848</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#850">850</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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 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-closed.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> +<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#714">714</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#769">769</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#772">772</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#779">779</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#787">787</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#805">805</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#806">806</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#807">807</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#808">808</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#809">809</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#813">813</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#824">824</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#396">396</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#698">698</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#804">804</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-closed.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-defects.html#23">23</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-defects.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-defects.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-defects.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> @@ -166,7 +297,7 @@ del {background-color:#FFA0A0} <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>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-defects.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-defects.html#820">820</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.html#823">823</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.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-closed.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> @@ -182,8 +313,8 @@ del {background-color:#FFA0A0} <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 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-closed.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-defects.html#804">804</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#805">805</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#806">806</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#807">807</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#808">808</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-closed.html#811">811</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#812">812</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#813">813</a>.</li> +<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#793">793</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.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> @@ -192,15 +323,15 @@ del {background-color:#FFA0A0} <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 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-defects.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-defects.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#724">724</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-defects.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-defects.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-defects.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-defects.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-active.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-active.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-defects.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-defects.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-defects.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 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-defects.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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> @@ -216,7 +347,7 @@ del {background-color:#FFA0A0} <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>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-defects.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-defects.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.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-defects.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-defects.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> @@ -234,7 +365,7 @@ del {background-color:#FFA0A0} <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>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-defects.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-defects.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> @@ -249,16 +380,16 @@ del {background-color:#FFA0A0} <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>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-defects.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-closed.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-defects.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-closed.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-defects.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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 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-defects.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-closed.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-closed.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 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-defects.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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 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-defects.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> @@ -274,7 +405,7 @@ del {background-color:#FFA0A0} <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> +<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.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> @@ -287,13 +418,13 @@ del {background-color:#FFA0A0} <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>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-defects.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-closed.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 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-closed.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> @@ -314,7 +445,7 @@ del {background-color:#FFA0A0} <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 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-defects.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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> @@ -331,12 +462,12 @@ del {background-color:#FFA0A0} <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>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-closed.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-defects.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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 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-active.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 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-active.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-active.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-active.html#149">149</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-active.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> @@ -358,11 +489,11 @@ del {background-color:#FFA0A0} <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>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-defects.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-closed.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-active.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 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-active.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> @@ -376,7 +507,7 @@ del {background-color:#FFA0A0} <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> +<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#611">611</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#613">613</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#614">614</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-active.html#617">617</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#619">619</a>.</li> </ul></li> </ul> </li> @@ -392,10 +523,10 @@ del {background-color:#FFA0A0} <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#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-closed.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> +<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-closed.html#594">594</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-active.html#597">597</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#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#604">604</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#605">605</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#606">606</a>, <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#609">609</a>.</li> </ul></li> </ul> </li> @@ -408,7 +539,7 @@ del {background-color:#FFA0A0} <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> +<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#584">584</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-defects.html#586">586</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#587">587</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-defects.html#589">589</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-closed.html#591">591</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#592">592</a>.</li> </ul></li> </ul> </li> @@ -421,7 +552,7 @@ del {background-color:#FFA0A0} <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>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-defects.html#576">576</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#578">578</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-active.html#580">580</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-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> @@ -436,9 +567,9 @@ del {background-color:#FFA0A0} <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>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-active.html#568">568</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#569">569</a>, <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-closed.html#571">571</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#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#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-defects.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#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#528">528</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> @@ -454,7 +585,7 @@ del {background-color:#FFA0A0} <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>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#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-active.html#539">539</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>, <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#543">543</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-defects.html#545">545</a>, <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-closed.html#547">547</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#548">548</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#550">550</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#552">552</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#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#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-closed.html#558">558</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-closed.html#560">560</a>, <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-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-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> @@ -469,7 +600,7 @@ del {background-color:#FFA0A0} <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> +<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#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-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#533">533</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#535">535</a>.</li> </ul></li> </ul> </li> @@ -485,7 +616,7 @@ Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.htm </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>. +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-defects.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: @@ -494,7 +625,7 @@ Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active </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 +for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#454">454</a> were moved to "DR" status, and all issues previously in "DR" status were moved to "WP". </li> <li>R35: @@ -542,7 +673,7 @@ Pre-Oxford mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22 <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 +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-defects.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> @@ -601,7 +732,7 @@ Changed status of issues 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-active.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. @@ -627,7 +758,7 @@ issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#265 <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 +<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-defects.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 @@ -680,7 +811,7 @@ in Dublin. (99-0016/N1193, 21 Apr 99) 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) +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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>, @@ -693,7 +824,7 @@ 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 +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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: @@ -756,12 +887,6 @@ format, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64 <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 @@ -775,11 +900,15 @@ format, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64 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 + <p><b><a name="TC1">TC1</a></b> - (Technical Corrigenda 1) - 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="CD1">CD1</a></b> - (Committee Draft 2008) - The full + WG21 committee has voted to accept the Defect Report's Proposed + Resolution into the Fall 2008 Committee Draft.</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 @@ -790,6 +919,13 @@ format, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64 the full WG21 committee has voted to apply the Defect Report's Proposed Resolution to the working paper.</p> + <p><b>Tentatively</b> - This is a <i>status qualifier</i>. The issue has + been reviewed online, or at an unofficial meeting, but not in an official meeting, and some support has been formed + for the qualified status. Tentatively qualified issues may be moved to the unqualified status + and forwarded to full committee (if Ready) within the same meeting. Unlike Ready issues, Tentatively Ready issues + will be reviewed in subcommittee prior to forwarding to full committee. When a status is + qualified with Tentatively, the issue is still considered active.</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 @@ -815,210 +951,10 @@ format, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64 <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>Section:</b> 23.3.6 [vector] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">Tentatively NAD Future</a> + <b>Submitter:</b> AFNOR <b>Opened:</b> 1998-10-07 <b>Last modified:</b> 2009-05-25</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> @@ -1086,7 +1022,61 @@ over-my-dead-body positions.]</i></p> <p>We need a paper for the new bit_vector class.</p> +<p><i>[ +Batavia: +]</i></p> + +<blockquote> +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. +</blockquote> + +<p><i>[ +Post Summit Alisdair adds: +]</i></p> + + +<blockquote> +<p> +<tt>vector<bool></tt> is now a conforming container under the revised terms of C++0x, +which supports containers of proxies. +</p> +<p> +Recommend NAD. +</p> +<p> +Two issues remain: +</p> +<p> +i/ premature optimization in the specification. +There is still some sentiment that deprecation is the correct way to go, +although it is still not clear what it would mean to deprecate a single +specialization of a template. +</p> +<p> +Recommend: Create a new issue for the discussion, leave as Open. +</p> +<p> +ii/ Request for a new bitvector class to guarantee the optimization, perhaps +with a better tuned interface. +</p> +<p> +This is a clear extension request that may be handled via a future TR. +</p> +</blockquote> + +<p><i>[ +Batavia (2009-05): +]</i></p> +<blockquote> +We note that most of this issue has become moot over time, +and agree with Alisdair's recommendations. +Move to NAD Future for reconsideration of part (ii). +</blockquote> <p><b>Proposed resolution:</b></p> @@ -1097,23 +1087,99 @@ and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2160.html">N2160</a>. </p> + + + + + +<hr> +<h3><a name="111"></a>111. istreambuf_iterator::equal overspecified, inefficient</h3> +<p><b>Section:</b> 24.6.3.5 [istreambuf.iterator::equal] <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>Opened:</b> 1998-10-15 <b>Last modified:</b> 2009-03-13</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#istreambuf.iterator::equal">active issues</a> in [istreambuf.iterator::equal].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istreambuf.iterator::equal">issues</a> in [istreambuf.iterator::equal].</p> +<p><b>View all 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 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><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. +Summit: ]</i></p> +<blockquote> +Reopened by Alisdair. +</blockquote> + +<p><i>[ +Post Summit Daniel adds: +]</i></p> + + +<blockquote> +<p> +Recommend NAD. The proposed wording would violate the axioms of +concept requirement <tt>EqualityComparable</tt> axioms as part of concept <tt>InputIterator</tt> +and more specifically it would violate the explicit wording of +24.2.2 [input.iterators]/7: +</p> + +<blockquote> +If two iterators <tt>a</tt> and <tt>b</tt> of the same type are equal, then either <tt>a</tt> +and <tt>b</tt> are both +dereferenceable or else neither is dereferenceable. +</blockquote> + +</blockquote> + + + +<p><b>Proposed resolution:</b></p> +<p>Replace 24.6.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="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>Section:</b> 27.8 [string.streams], 27.9 [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>Opened:</b> 1999-02-22 <b>Last modified:</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#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> @@ -1145,7 +1211,7 @@ post Bellevue: Alisdair requested to re-Open. <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> +qualified as const to 27.6.2 [streambuf]:</p> <p> <tt>openmode mode() const</tt>;</p> @@ -1169,145 +1235,528 @@ 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> +<h3><a name="138"></a>138. Class ctype_byname<char> redundant and misleading</h3> +<p><b>Section:</b> 22.4.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> Angelika Langer <b>Opened:</b> 1999-03-18 <b>Last modified:</b> 2009-03-09</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.codecvt">active issues</a> in [locale.codecvt].</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>Section 22.4.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><i>[ +Summit: +]</i></p> + + +<blockquote> +Reopened by Alisdair. +</blockquote> + + + +<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="149"></a>149. Insert should return iterator to first element inserted</h3> +<p><b>Section:</b> 23.2.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> + <b>Submitter:</b> Andrew Koenig <b>Opened:</b> 1999-06-28 <b>Last modified:</b> 2009-05-01</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#sequence.reqmts">active issues</a> in [sequence.reqmts].</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#Open">Open</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>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> -<p>Here's a simple and typical example problem which is currently very -difficult or impossible to solve without the change proposed -below.</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> -<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> +</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><i>[ -post Bellevue, Alisdair adds: +Summit: +]</i></p> + + +<blockquote> +Reopened by Alisdair. +</blockquote> + +<p><i>[ +Post Summit 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>. +In addition to the original rationale for C++03, this change also gives a +consistent interface for all container insert operations i.e. they all +return an iterator to the (first) inserted item. </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? +Proposed wording provided. </p> </blockquote> -<p><i>[ -Sophia Antipolis: -]</i></p> +<p><b>Proposed resolution:</b></p> +<p> +<sef ref="[sequence.reqmts]"> Table 83 +change return type from <tt>void</tt> to <tt>iterator</tt> for the following rows: +</sef></p> + +<blockquote> +<table border="1"> +<caption>Table 83 -- Sequence container requirements (in addition to container)</caption> +<tbody><tr> +<th>Expression</th> +<th>Return type</th> +<th>Assertion/note pre-/post-condition</th> +</tr> +<tr> +<td> +<tt>a.insert(p,n,t)</tt> +</td> +<td> +<tt><del>void</del> <ins>iterator</ins></tt> +</td> +<td> +Inserts <tt>n</tt> copies of <tt>t</tt> before <tt>p</tt>. +</td> +</tr> + +<tr> +<td> +<tt>a.insert(p,i,j)</tt> +</td> +<td> +<tt><del>void</del> <ins>iterator</ins></tt> +</td> +<td> +Each iterator in the range <tt>[i,j)</tt> shall be +dereferenced exactly once. +pre: <tt>i</tt> and <tt>j</tt> are not iterators into <tt>a</tt>. +Inserts copies of elements in <tt>[i, j)</tt> before <tt>p</tt> +</td> +</tr> + +<tr> +<td> +<tt>a.insert(p,il)</tt> +</td> +<td> +<tt><del>void</del> <ins>iterator</ins></tt> +</td> +<td> +<tt>a.insert(p, il.begin(), il.end())</tt>. +</td> +</tr> +</tbody></table> +</blockquote> + +<p> +Add after p6 23.2.3 [sequence.reqmts]: +</p> + <blockquote> +<p>-6- ...</p> + +<p><ins> +The iterator returned from <tt>a.insert(p,n,t)</tt> points to the copy of the +first element inserted into <tt>a</tt>, or <tt>p</tt> if <tt>n == 0</tt>. +</ins></p> + +<p><ins> +The iterator returned from <tt>a.insert(p,i,j)</tt> points to the copy of the +first element inserted into <tt>a</tt>, or <tt>p</tt> if <tt>i == j</tt>. +</ins></p> + +<p><ins> +The iterator returned from <tt>a.insert(p,il)</tt> points to the copy of the +first element inserted into <tt>a</tt>, or <tt>p</tt> if <tt>il</tt> is empty. +</ins></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. +p9 23.2.6.1 [container.concepts.free] change return type from +<tt>void</tt> to <tt>iterator</tt>: </p> + +<blockquote><pre>concept RangeInsertionContainer<typename C, typename Iter> : InsertionContainer<C> { + requires InputIterator<Iter>; + <del>void</del> <ins>iterator</ins> insert(C&, const_iterator position, Iter first, Iter last); +} +</pre></blockquote> + <p> -The wording updated. +p9 23.2.6.2 [container.concepts.member] change return type from +<tt>void</tt> to <tt>iterator</tt>: </p> + +<blockquote><pre>auto concept MemberRangeInsertionContainer<typename C, typename Iter> : MemberInsertionContainer<C> { + requires InputIterator<Iter>; + <del>void</del> <ins>iterator</ins> C::insert(const_iterator position, Iter first, Iter last); +} +</pre></blockquote> + <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. +p8 23.2.6.3 [container.concepts.maps] change return type from +<tt>void</tt> to <tt>iterator</tt>, add return statement: </p> + +<blockquote><pre>template <MemberRangeInsertionContainer C, InputIterator Iter> +concept_map RangeInsertionContainer<C, Iter> { + <del>void</del> <ins>iterator</ins> insert(C& c, Container<C>::const_iterator i, Iter first, Iter last) + { <ins>return</ins> c.insert(i, first, last); } +} +</pre></blockquote> + +<p> +p2 23.3.2 [deque] Update class definition, change return type +from <tt>void</tt> to <tt>iterator</tt>: +</p> + +<blockquote><pre>requires AllocatableElement<Alloc, T, const T&> && MoveAssignable<T> + <del>void</del> <ins>iterator</ins> insert(const_iterator position, size_type n, const T& x); +template <InputIterator Iter> + requires AllocatableElement<Alloc, T, Iter::reference> && MoveAssignable<T> + <del>void</del> <ins>iterator</ins> insert(const_iterator position, Iter first, Iter last); +requires AllocatableElement<Alloc, T, const T&> && MoveAssignable<T> + <del>void</del> <ins>iterator</ins> insert(const_iterator position, initializer_list<T>); +</pre></blockquote> + <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>. +23.3.2.3 [deque.modifiers] change return type from <tt>void</tt> to <tt>iterator</tt> on following declarations: </p> + +<blockquote><pre>requires AllocatableElement<Alloc, T, const T&> && MoveAssignable<T> + <del>void</del> <ins>iterator</ins> insert(const_iterator position, size_type n, const T& x); +template <InputIterator Iter> + requires AllocatableElement<Alloc, T, Iter::reference> && MoveAssignable<T> + <del>void</del> <ins>iterator</ins> insert(const_iterator position, Iter first, Iter last); +</pre></blockquote> + +<p> +Add the following (missing) declaration +</p> + +<blockquote><pre><ins>requires AllocatableElement<Alloc, T, const T&> && MoveAssignable<T> + iterator insert(const_iterator position, initializer_list<T>);</ins> +</pre></blockquote> + +<p> +23.3.3 [forwardlist] Update class definition, change return type +from <tt>void</tt> to <tt>iterator</tt>: +</p> + +<blockquote><pre>requires AllocatableElement<Alloc, T, const T&> + <del>void</del> <ins>iterator</ins> insert_after(const_iterator position, initializer_list<T> il); +requires AllocatableElement<Alloc, T, const T&> + <del>void</del> <ins>iterator</ins> insert_after(const_iterator position, size_type n, const T& x); +template <InputIterator Iter> + requires AllocatableElement<Alloc, T, Iter::reference> + <del>void</del> <ins>iterator</ins> insert_after(const_iterator position, Iter first, Iter last); +</pre></blockquote> + +<p> +p8 23.3.3.4 [forwardlist.modifiers] change return type from <tt>void</tt> to <tt>iterator</tt>: +</p> + +<blockquote><pre>requires AllocatableElement<Alloc, T, const T&> + <del>void</del> <ins>iterator</ins> insert_after(const_iterator position, size_type n, const T& x); +</pre></blockquote> + +<p> +Add paragraph: +</p> + +<blockquote> +Returns: position. </blockquote> +<p> +p10 23.3.3.4 [forwardlist.modifiers] change return type from <tt>void</tt> to <tt>iterator</tt>: +</p> +<blockquote><pre>template <InputIterator Iter> + requires AllocatableElement<Alloc, T, Iter::reference> + <del>void</del> <ins>iterator</ins> insert_after(const_iterator position, Iter first, Iter last); +</pre></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: +Add paragraph: </p> -<blockquote><pre>namespace std { - template<class charT, class traits = char_traits<charT>, - class Allocator = allocator<charT> > - class basic_string { - ... +<blockquote> +Returns: position. +</blockquote> - 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>); +<p> +p12 23.3.3.4 [forwardlist.modifiers] change return type from <tt>void</tt> to <tt>iterator</tt> on following declarations: +</p> - ... +<blockquote><pre>requires AllocatableElement<Alloc, T, const T&> + <del>void</del> <ins>iterator</ins> insert_after(const_iterator position, initializer_list<T> il); +</pre></blockquote> + +<p> +change return type from <tt>void</tt> to <tt>iterator</tt> on following declarations: +</p> - iterator erase(<ins>const_</ins>iterator <ins>const_</ins>position); - iterator erase(<ins>const_</ins>iterator first, <ins>const_</ins>iterator last); +<p> +p2 23.3.4 [list] Update class definition, change return type from <tt>void</tt> to <tt>iterator</tt>: +</p> - ... +<blockquote><pre>requires AllocatableElement<Alloc, T, const T&> && MoveAssignable<T> + <del>void</del> <ins>iterator</ins> insert(const_iterator position, size_type n, const T& x); - }; -} +template <InputIterator Iter> + requires AllocatableElement<Alloc, T, Iter::reference> && MoveAssignable<T> + <del>void</del> <ins>iterator</ins> insert(const_iterator position, Iter first, Iter last); + +requires AllocatableElement<Alloc, T, const T&> && MoveAssignable<T> + <del>void</del> <ins>iterator</ins> insert(const_iterator position, initializer_list<T>); +</pre></blockquote> + + +<p> +23.3.4.3 [list.modifiers] change return type from <tt>void</tt> to <tt>iterator</tt> on following declarations: +</p> + +<blockquote><pre>requires AllocatableElement<Alloc, T, const T&> && MoveAssignable<T> + <del>void</del> <ins>iterator</ins> insert(const_iterator position, size_type n, const T& x); + +template <InputIterator Iter> + requires AllocatableElement<Alloc, T, Iter::reference> && MoveAssignable<T> + <del>void</del> <ins>iterator</ins> insert(const_iterator position, Iter first, Iter last); +</pre></blockquote> + +<p> +Add the following (missing) declaration +</p> + +<blockquote><pre>requires AllocatableElement<Alloc, T, const T&> && MoveAssignable<T> + iterator insert(const_iterator position, initializer_list<T>); </pre></blockquote> <p> -Update the following signatures in 21.3.6.4 [string::insert]: +p2 23.3.6 [vector] +</p> + +<p> +Update class definition, change return type from <tt>void</tt> to <tt>iterator</tt>: </p> -<blockquote><pre>iterator insert(<ins>const_</ins>iterator p, charT c); -void insert(<ins>const_</ins>iterator p, size_type n, charT c); +<blockquote><pre>requires AllocatableElement<Alloc, T, T&&> && MoveAssignable<T> + <del>void</del> <ins>iterator</ins> insert(const_iterator position, T&& x); + +requires AllocatableElement<Alloc, T, const T&> && MoveAssignable<T> + <del>void</del> <ins>iterator</ins> insert(const_iterator position, size_type n, const T& x); + +template <InputIterator Iter> + requires AllocatableElement<Alloc, T, Iter::reference> && MoveAssignable<T> + <del>void</del> <ins>iterator</ins> insert(const_iterator position, Iter first, Iter last); + +requires AllocatableElement<Alloc, T, const T&> && MoveAssignable<T> + <del>void</del> <ins>iterator</ins> insert(const_iterator position, initializer_list<T>); +</pre></blockquote> + +<p> +23.3.6.4 [vector.modifiers] change return type from <tt>void</tt> to <tt>iterator</tt> on following declarations: +</p> + +<blockquote><pre>requires AllocatableElement<Alloc, T, const T&> && MoveAssignable<T> + <del>void</del> <ins>iterator</ins> insert(const_iterator position, size_type n, const T& x); + +template <InputIterator Iter> + requires AllocatableElement<Alloc, T, Iter::reference> && MoveAssignable<T> + <del>void</del> <ins>iterator</ins> insert(const_iterator position, Iter first, Iter last); +</pre></blockquote> + +<p> +Add the following (missing) declaration +</p> + +<blockquote><pre>requires AllocatableElement<Alloc, T, const T&> && MoveAssignable<T> + iterator insert(const_iterator position, initializer_list<T>); +</pre></blockquote> + + +<p> +p1 23.3.7 [vector.bool] Update class definition, change return type from <tt>void</tt> to <tt>iterator</tt>: +</p> + +<blockquote><pre><del>void</del> <ins>iterator</ins> insert (const_iterator position, size_type n, const bool& x); + +template <InputIterator Iter> + requires Convertible<Iter::reference, bool> + <del>void</del> <ins>iterator</ins> insert(const_iterator position, Iter first, Iter last); + + <del>void</del> <ins>iterator</ins> insert(const_iterator position, initializer_list<bool> il); +</pre></blockquote> + +<p> +p5 21.4 [basic.string] Update class definition, change return type from <tt>void</tt> to <tt>iterator</tt>: +</p> + +<blockquote><pre><del>void</del> <ins>iterator</ins> insert(const_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>); + <del>void</del> <ins>iterator</ins> insert(const_iterator p, InputIterator first, InputIterator last); + +<del>void</del> <ins>iterator</ins> insert(const_iterator p, initializer_list<charT>); +</pre></blockquote> + +<p> +p13 21.4.6.4 [string::insert] change return type from <tt>void</tt> to <tt>iterator</tt>: +</p> + +<blockquote><pre><del>void</del> <ins>iterator</ins> insert(const_iterator p, size_type n, charT c); +</pre></blockquote> + +<p> +Add paragraph: +</p> + +<blockquote> +<i>Returns:</i> an iterator which refers to the copy of the first inserted +character, or <tt>p</tt> if <tt>n == 0</tt>. +</blockquote> + +<p> +p15 21.4.6.4 [string::insert] change return type from <tt>void</tt> to <tt>iterator</tt>: +</p> + +<blockquote><pre>template<class InputIterator> + <del>void</del> <ins>iterator</ins> insert(const_iterator p, InputIterator first, InputIterator last); </pre></blockquote> <p> -Update the following signatures in 21.3.6.5 [string::erase]: +Add paragraph: +</p> + +<blockquote> +<i>Returns:</i> an iterator which refers to the copy of the first inserted +character, or <tt>p</tt> if <tt>first == last</tt>. +</blockquote> + +<p> +p17 21.4.6.4 [string::insert] change return type from <tt>void</tt> to <tt>iterator</tt>: </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); +<blockquote><pre><del>void</del> <ins>iterator</ins> insert(const_iterator p, initializer_list<charT> il); </pre></blockquote> +<p> +Add paragraph: +</p> + +<blockquote> +<i>Returns:</i> an iterator which refers to the copy of the first inserted +character, or <tt>p</tt> if <tt>il</tt> is empty. +</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> +<p><i>[ +The following was the C++98/03 rationale and does not necessarily apply to the +proposed resolution in the C++0X time frame: +]</i></p> + + +<blockquote> +<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> +</blockquote> <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>Section:</b> 25.5.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>Opened:</b> 1999-08-26 <b>Last modified:</b> 2008-03-14</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#alg.min.max">active issues</a> in [alg.min.max].</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> @@ -1335,9 +1784,66 @@ function objects.</p> <hr> +<h3><a name="219"></a>219. find algorithm missing version that takes a binary predicate argument</h3> +<p><b>Section:</b> 25.3.5 [alg.find] <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>Opened:</b> 2000-03-06 <b>Last modified:</b> 2009-03-09</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#Open">Open</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><i>[ +Summit: +]</i></p> + + +<blockquote> +Reopened by Alisdair. +</blockquote> + + + +<p><b>Proposed resolution:</b></p> +<blockquote> +<p>In section 25.3.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="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>Section:</b> 27.6.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>Opened:</b> 2000-08-12 <b>Last modified:</b> 2007-01-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#Open">Open</a> status.</p> <p><b>Discussion:</b></p> @@ -1415,8 +1921,9 @@ signature.</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>Section:</b> 25.3.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>Opened:</b> 2001-01-03 <b>Last modified:</b> 2006-12-27</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#alg.foreach">active issues</a> in [alg.foreach].</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> @@ -1460,133 +1967,16 @@ algorithm does not say so. <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>Section:</b> 27.7 [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>Opened:</b> 2001-03-19 <b>Last modified:</b> 2006-12-27</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 +(27.7.1.1.3 [istream::sentry]) and basic_ostream<>::sentry +(27.7.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 @@ -1599,14 +1989,14 @@ The text also mentions that the functions may call setstate(failbit) 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 +issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a> amends 27.7.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 +The same sentence that appears in 27.7.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 @@ -1886,15 +2276,15 @@ committee. <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>Section:</b> 27.7.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>Opened:</b> 2001-10-09 <b>Last modified:</b> 2007-01-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#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 +description of seekg in 27.7.1.3 [istream.unformatted] paragraph 38 now looks like:</p> <blockquote><p> @@ -1972,7 +2362,7 @@ you can never seek away from the end of stream.</li> <p><b>Proposed resolution:</b></p> -<p>Change 27.6.1.3 [istream.unformatted] to:</p> +<p>Change 27.7.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 @@ -2004,9 +2394,10 @@ In case of failure, the function calls <tt>setstate(failbit)</tt> <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>Section:</b> 17 [library] <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>Opened:</b> 2001-10-09 <b>Last modified:</b> 2009-03-11</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</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#Open">Open</a> status.</p> <p><b>Discussion:</b></p> <p> @@ -2242,8 +2633,9 @@ Hinnant: It's time we dealt with this issue for C++0X. Reopened. <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>Section:</b> 22.4.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>Opened:</b> 2002-08-30 <b>Last modified:</b> 2007-01-15</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.codecvt">active issues</a> in [locale.codecvt].</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> @@ -2271,7 +2663,7 @@ the following seems less than adequately specified: <ol> <li> - 22.2.1.4.2 [locale.codecvt.virtuals], p2 says this about the effects of the + 22.4.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 @@ -2304,7 +2696,7 @@ the following seems less than adequately specified: </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: +Finally, the conditions described at the end of 22.4.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), @@ -2318,7 +2710,7 @@ 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 +converted (according to 22.4.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> @@ -2363,166 +2755,9 @@ partial can only occur if (from_next != from_end)? <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>Section:</b> 27.7.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>Opened:</b> 2002-12-27 <b>Last modified:</b> 2007-01-15</p> <p><b>View all 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> @@ -2625,143 +2860,9 @@ functions should be changed as proposed below. <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>Section:</b> 27.7.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>Opened:</b> 2003-01-05 <b>Last modified:</b> 2007-07-25</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> @@ -2812,8 +2913,8 @@ See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#418">41 <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>Section:</b> 27.7.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>Opened:</b> 2003-01-05 <b>Last modified:</b> 2007-01-15</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> @@ -2915,10 +3016,10 @@ end-of-file): <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>Section:</b> 24.2 [iterator.concepts] <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>Opened:</b> 2003-06-03 <b>Last modified:</b> 2009-05-10</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iterator.concepts">active issues</a> in [iterator.concepts].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.concepts">issues</a> in [iterator.concepts].</p> <p><b>View all 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> @@ -2927,7 +3028,7 @@ 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" +24.2 [iterator.concepts] 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 @@ -3025,7 +3126,7 @@ 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>Related issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#407">407</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1012">1012</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 @@ -3037,9 +3138,31 @@ wrong to impose so strict a requirement for iterators. ]</i></p> +<p><i>[ +2009-05-10 Alisdair provided wording. +]</i></p> + + +<blockquote> +The comments regarding destroying singular iterators have already been +resolved. That just leaves copying (with moving implied). +</blockquote> + <p><b>Proposed resolution:</b></p> +<p> +Add to the end of Iterator concepts 24.2 [iterator.concepts] para 6 (the one +describing singular iterators) +</p> +<blockquote> +Any Iterator that satisfies the <tt>DefaultConstructible</tt> concept shall +be safely copyable after value-initialization, even if it would otherwise be +singular. [<i>Note:</i> This guarantee is not offered for default-initialization +(8.5 [dcl.init]), although the distinction only matters for types with +trivial default constructors such as pointers. — <i>end note</i>] +</blockquote> + @@ -3047,8 +3170,8 @@ wrong to impose so strict a requirement for iterators. <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>Section:</b> 22.4.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>Opened:</b> 2003-09-18 <b>Last modified:</b> 2006-12-27</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> @@ -3081,8 +3204,10 @@ and iostream to reliably detect this failure. <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>Section:</b> 27.5.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>Opened:</b> 2003-09-18 <b>Last modified:</b> 2007-07-25</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#ios::Init">active issues</a> in [ios::Init].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios::Init">issues</a> in [ios::Init].</p> <p><b>View all 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> @@ -3124,16 +3249,16 @@ See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#397">39 <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>Section:</b> 27.7.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>Opened:</b> 2003-09-18 <b>Last modified:</b> 2007-01-30</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() +27.7.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 +true if the stream state is good after any preparation. 27.7.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. @@ -3213,7 +3338,7 @@ you can never seek away from the end of stream. <p><b>Proposed resolution:</b></p> <p> -Change 27.6.1.1.3 [istream::sentry], p2 to: +Change 27.7.1.1.3 [istream::sentry], p2 to: </p> <blockquote> @@ -3232,8 +3357,8 @@ Otherwise</ins> prepares for formatted or unformatted input. ... <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>Section:</b> 27.6.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>Opened:</b> 2003-09-18 <b>Last modified:</b> 2007-01-15</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> @@ -3434,7 +3559,8 @@ basic_filebuf. <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> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18 <b>Last modified:</b> 2006-12-27</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#input.output">active issues</a> in [input.output].</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> @@ -3474,9 +3600,120 @@ ostream::write(). <hr> +<h3><a name="424"></a>424. normative notes</h3> +<p><b>Section:</b> 17.5.1.2 [structure.summary] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Tentatively NAD Editorial</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18 <b>Last modified:</b> 2009-05-23</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD%20Editorial">Tentatively 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.8.6.1 [allocator.members], p3,<br> +20.8.6.1 [allocator.members], p10,<br> +21.4.2 [string.cons], p11,<br> +22.3.1.2 [locale.cons], p11,<br> +23.3.2.3 [deque.modifiers], p2,<br> +25.5.7 [alg.min.max], p3,<br> +26.4.6 [complex.ops], p15,<br> +27.6.2.4.3 [streambuf.virt.get], p7.<br> +<br> + +List 2 -- Examples of (presumably) informative Notes: +<br> + +18.6.1.3 [new.delete.placement], p3,<br> +21.4.6.6 [string::replace], p14,<br> +22.4.1.4.2 [locale.codecvt.virtuals], p3,<br> +25.3.4 [alg.foreach], p4,<br> +26.4.5 [complex.member.ops], p1,<br> +27.5.2.5 [ios.base.storage], p6.<br> +<br> + +List 3 -- Examples of Notes that are not clearly either normative +or informative: +<br> + +22.3.1.2 [locale.cons], p8,<br> +22.3.1.5 [locale.statics], p6,<br> +27.6.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><i>[ +post San Francisco: Howard: reopened, needs attention. +]</i></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> + + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +<p> +A spot-check of List 2 suggests the issue is still relevant, +and a review of List 3 still seems called-for. +</p> +<p> +Move to NAD Editorial. +</p> +</blockquote> + + + +<p><b>Proposed resolution:</b></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>Section:</b> 22.4.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>Opened:</b> 2003-09-18 <b>Last modified:</b> 2007-01-15</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> @@ -3535,8 +3772,8 @@ use <tt>char_traits<charT></tt>.</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>Section:</b> 26.6.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>Opened:</b> 2003-09-18 <b>Last modified:</b> 2009-05-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> @@ -3571,7 +3808,7 @@ post-Bellevue: Bill provided wording. <p><b>Proposed resolution:</b></p> <p> -Insert after 26.5.2.4 [valarray.sub], paragraph 1: +Insert after 26.6.2.4 [valarray.sub], paragraph 1: </p> <blockquote> @@ -3674,7 +3911,7 @@ 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) +// valarray<char>("dfhkmo", 6) </pre></blockquote> <p> @@ -3685,7 +3922,7 @@ designated by <tt>boolarr</tt>. For example: <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) +// valarray<char>("cdf", 3) </pre></blockquote> <p> @@ -3707,13 +3944,13 @@ const size_t vi[] = {7, 5, 2, 3, 8}; <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>Section:</b> X [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>Opened:</b> 2003-09-20 <b>Last modified:</b> 2009-05-01</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 +<p>Clause X [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 @@ -3774,6 +4011,29 @@ swap allocators, else it will perform a "slow swap" using copy construction and ]</i></p> +<p><i>[ +2009-04-28 Pablo adds: +]</i></p> + +<blockquote> +Fixed in +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2525.pdf">N2525</a>. +I argued for marking this Tentatively-Ready right after Bellevue, +but there was a concern that +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2525.pdf">N2525</a> +would break in the presence of the RVO. (That breakage had nothing to do with +swap, but never-the-less). I addressed that breakage in in +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2840.pdf">N2840</a> +(Summit) my means of a non-normative reference: + +<blockquote> +[<i>Note:</i> in situations where the copy constructor for a container is elided, +this function is not called. The behavior in these cases is as if +<tt>select_on_container_copy_construction</tt> returned <tt>x</tt> — <i>end note</i>] +</blockquote> + +</blockquote> + <p><b>Proposed resolution:</b></p> @@ -3784,10 +4044,10 @@ swap allocators, else it will perform a "slow swap" using copy construction and <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>Section:</b> 24.2 [iterator.concepts], 23.2 [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>Opened:</b> 2003-12-16 <b>Last modified:</b> 2008-09-30</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iterator.concepts">active issues</a> in [iterator.concepts].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.concepts">issues</a> in [iterator.concepts].</p> <p><b>View all 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> @@ -3821,219 +4081,66 @@ reachability. <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> +<h3><a name="458"></a>458. 24.1.5 contains unintented limitation for operator-</h3> +<p><b>Section:</b> 24.2.6 [random.access.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">Tentatively NAD</a> + <b>Submitter:</b> Daniel Frey <b>Opened:</b> 2004-02-27 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#random.access.iterators">active issues</a> in [random.access.iterators].</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#Tentatively%20NAD">Tentatively NAD</a> status.</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. +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>[ -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: +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> -<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. +Post Summit Alisdair adds: ]</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. +This issue refers to a requirements table we have removed. </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.) +The issue might now relate to 24.2.6 [random.access.iterators] p5. +However, the rationale in the issue already recognises that the +<tt>difference_type</tt> must be signed, so this really looks NAD. </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: +Batavia (2009-05): ]</i></p> - <blockquote> <p> -Move again to Ready. +We agree with Alisdair's observations. </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. +Move to NAD. </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 +<blockquote><pre> { Distance m = n; + if (m >= 0) + while (m--) --r; + else while (m++) ++r; return r; } </pre></blockquote> @@ -4045,8 +4152,8 @@ operational semantics for this column to: <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>Section:</b> 22.4.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>Opened:</b> 2004-03-16 <b>Last modified:</b> 2006-12-27</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> @@ -4099,7 +4206,7 @@ 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 +part of numbers during parsing. In fact, the requirement in 22.4.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 @@ -4139,7 +4246,8 @@ technique to perform the comparison:</p> <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> + <b>Submitter:</b> Rani Sharoni <b>Opened:</b> 2003-12-07 <b>Last modified:</b> 2007-11-15</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#auto.ptr">active issues</a> in [auto.ptr].</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> @@ -4540,9 +4648,76 @@ The expression <tt>delete get()</tt> is well formed. <hr> +<h3><a name="466"></a>466. basic_string ctor should prevent null pointer error</h3> +<p><b>Section:</b> 21.4.1 [string.require] <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>Opened:</b> 2004-06-10 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#string.require">active issues</a> in [string.require].</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#Open">Open</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. + Recommend NAD. Relegate this functionality to debugging implementations.]</i></p> + + +<p><i>[ +Post Summit: Alisdair requests this be re-opened as several new language facilities are +designed to solve exactly this kind of problem. +]</i></p> + + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +We are unable to achieve consensus on an approach to a resolution. +There is some sentiment for treating this as a QOI matter. +It is also possible +that when <tt>string</tt> is brought into the concepts world, +this issue might be addressed in that context. +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +Add to the synopsis in 21.4 [basic.string] +</p> + +<blockquote><pre><ins>basic_string( nullptr_t ) = delete;</ins> +</pre></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>Section:</b> 18.7.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>Opened:</b> 2004-06-28 <b>Last modified:</b> 2009-05-23</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> @@ -4625,16 +4800,34 @@ Sophia Antipolis: <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. +is intended to be supported, not coping from a derived to a base. </blockquote> +<p><i>[ +Batavia (2009-05): +]</i></p> +<blockquote> +<p> +Howard supplied the following replacement wording +for paragraph 7 of the proposed resolution: +</p> +<blockquote> +<ins>-7- <i>Postcondition:</i> <tt>what()</tt> shall return the same NTBS + as would be obtained by using <tt>static_cast</tt> + to cast the rhs to the same types as the lhs + and then calling <tt>what()</tt> on that possibly sliced object.</ins> +</blockquote> +<p> +Pete asks what "the same NTBS" means. +</p> +</blockquote> <p><b>Proposed resolution:</b></p> <p> -Change 18.7.1 [exception] to: +Change 18.8.1 [exception] to: </p> <blockquote> @@ -4664,8 +4857,8 @@ to all standard library-defined classes that derive from <tt>exception</tt>.</in <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>Section:</b> 22.4.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>Opened:</b> 2004-07-01 <b>Last modified:</b> 2006-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> @@ -4747,66 +4940,9 @@ provide wording.</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>Section:</b> 24.2.3 [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>Opened:</b> 2004-10-13 <b>Last modified:</b> 2006-12-27</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> @@ -4850,10 +4986,10 @@ wording (I believe) x,a,b,c could be written to in any order. <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>Section:</b> 17.5.1.4 [structure.specifications] <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>Opened:</b> 2004-12-12 <b>Last modified:</b> 2009-05-10</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#structure.specifications">active issues</a> in [structure.specifications].</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#Open">Open</a> status.</p> <p><b>Discussion:</b></p> <p>Various clauses other than clause 25 make use of iterator arithmetic not @@ -5024,6 +5160,16 @@ Bellevue: Keep open and ask Bill to provide wording. </blockquote> +<p><i>[ +2009-05-09 Alisdair adds: +]</i></p> + + +<blockquote> +This issue is related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#997">997</a>. +</blockquote> + + <p><b>Proposed resolution:</b></p> @@ -5040,8 +5186,8 @@ 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>Section:</b> 25.4.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>Opened:</b> 2005-05-04 <b>Last modified:</b> 2009-05-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> @@ -5055,6 +5201,62 @@ and <a href="http://www.sgi.com/tech/stl/stable_partition.html">http://www.sgi.com/tech/stl/stable_partition.html</a>). </p> +<p><i>[ +2009-04-30 Alisdair adds: +]</i></p> + + +<blockquote> +<p> +Now we have concepts this is easier to express! +</p> +<p> +Proposed resolution: +</p> +<p> +Add the following signature to: +</p> +<p> +Header <tt><algorithm></tt> synopsis 25.2 [algorithms.syn]<br> +p3 Partitions 25.4.13 [alg.partitions] +</p> +<blockquote><pre> template<ForwardIterator Iter, Predicate<auto, Iter::value_type> Pred> + requires ShuffleIterator<Iter> + && CopyConstructible<Pred> + Iter partition(Iter first, Iter last, Pred pred); +</pre></blockquote> + +<p> +Update p3 Partitions 25.4.13 [alg.partitions]: +</p> + +<blockquote> +<p> +<i>Complexity:</i> <del>At most <tt>(last - first)/2</tt> swaps. Exactly <tt>last - first</tt> +applications of the predicate +are done.</del> +<ins> +If <tt>Iter</tt> satisfies <tt>BidirectionalIterator</tt>, at most <tt>(last - +first)/2</tt> swaps. Exactly <tt>last - first</tt> applications of the predicate +are done. +</ins> +</p> +<p><ins> +If <tt>Iter</tt> merely satisfied <tt>ForwardIterator</tt> at most <tt>(last - first)</tt> swaps +are done. Exactly <tt>(last - first)</tt> applications of the predicate are done. +</ins></p> +</blockquote> + +<p> +[Editorial note: I looked for existing precedent in how we might call out +distinct overloads overloads from a set of constrained templates, but there +is not much existing practice to lean on. advance/distance were the only +algorithms I could find, and that wording is no clearer.] +</p> + +</blockquote> + + <p><b>Proposed resolution:</b></p> <p> @@ -5091,7 +5293,7 @@ swaps are done; otherwise at most (last - first) swaps are done. Exactly <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 +iterators is foward_list - without this extension you can't partition an foward_list (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 @@ -5112,8 +5314,8 @@ 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>Section:</b> 22.3.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>Opened:</b> 2005-06-07 <b>Last modified:</b> 2008-03-13</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> @@ -5158,8 +5360,8 @@ Bill. <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>Section:</b> 22.4 [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>Opened:</b> 2005-06-20 <b>Last modified:</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#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> @@ -5270,111 +5472,10 @@ Berlin: Bill to provide wording. <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> + <b>Submitter:</b> Eric Niebler <b>Opened:</b> 2005-07-01 <b>Last modified:</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#re">active issues</a> in [re].</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> @@ -5506,8 +5607,8 @@ Pete: Possible general problem with case insensitive ranges. <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>Section:</b> 26.7.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>Opened:</b> 2006-02-06 <b>Last modified:</b> 2009-05-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> @@ -5678,11 +5779,38 @@ the accumulator must be the <tt>input_iterator</tt>'s <tt>value_type</tt>, the w should specify it. </blockquote> +<p><i>[ +2009-05-09 Alisdair adds: +]</i></p> + + +<blockquote> +<p> +Now that we have the facility, the 'best' accumulator type could probably be +deduced as: +</p> +<blockquote><pre>std::common_type<InIter::value_type, OutIter::reference>::type +</pre></blockquote> +<p> +This type would then have additional requirements of constructability and +incrementability/assignability. +</p> +<p> +If this extracting an accumulator type from a pair/set of iterators (with +additional requirements on that type) is a problem for multiple functions, +it might be worth extracting into a SharedAccumulator concept or similar. +</p> +<p> +I'll go no further in writing up wording now, until the group gives a +clearer indication of preferred direction. +</p> +</blockquote> + <p><b>Proposed resolution:</b></p> <p> -Add to section 26.6.3 [partial.sum] paragraph 4 the following two sentences: +Add to section 26.7.3 [partial.sum] paragraph 4 the following two sentences: </p> <blockquote> @@ -5692,7 +5820,7 @@ The type of <tt>*first</tt> shall meet the requirements of <tt>CopyConstructible </blockquote> <p> -Add to section 26.6.4 [adjacent.difference] paragraph 2 the following sentence: +Add to section 26.7.4 [adjacent.difference] paragraph 2 the following sentence: </p> <blockquote> @@ -5708,7 +5836,7 @@ The type of <tt>*first</tt> shall meet the requirements of <tt>CopyConstructible <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> + <b>Submitter:</b> Matt Austern <b>Opened:</b> 2006-01-10 <b>Last modified:</b> 2007-10-09</p> <p><b>View all 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> @@ -5733,70 +5861,9 @@ list, so that people may use long long as a hash key. <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>Section:</b> 27.8.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>Opened:</b> 2006-02-23 <b>Last modified:</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#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> @@ -5857,8 +5924,8 @@ plugs the hole by specifying <tt>seekpos()</tt> in terms of <tt>seekoff()</tt>. <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>Section:</b> 27.6.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>Opened:</b> 2006-02-23 <b>Last modified:</b> 2007-10-09</p> <p><b>View all 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> @@ -5929,9 +5996,9 @@ proposed wording doesn't accomplish that. Proposed Disposition: Open <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>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#NAD">Tentatively NAD</a> + <b>Submitter:</b> Paolo Carlini <b>Opened:</b> 2006-03-07 <b>Last modified:</b> 2009-05-23</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD">Tentatively NAD</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. @@ -5941,6 +6008,15 @@ proposed wording doesn't accomplish that. Proposed Disposition: Open Hinnant: This is a TR1 issue only. It is fixed in the current (N2135) WD. </p> +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +We agree this has been fixed in the Working Draft. +Move to NAD. +</blockquote> + <p><b>Proposed resolution:</b></p> <p> @@ -5953,8 +6029,8 @@ Add <tt>log2</tt> to the list of functions in TR1 8.16.4 [tr.c99.cmath.over] p1. <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>Section:</b> 27.5.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>Opened:</b> 2006-04-12 <b>Last modified:</b> 2007-10-09</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> @@ -6007,10 +6083,10 @@ these definitions are horrible. Proposed Disposition: Open <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>Section:</b> 23.2.1 [container.requirements.general] <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>Opened:</b> 2006-06-14 <b>Last modified:</b> 2009-05-01</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements.general">active issues</a> in [container.requirements.general].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements.general">issues</a> in [container.requirements.general].</p> <p><b>View all 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> @@ -6051,12 +6127,29 @@ Batavia: We support this resolution. Martin to provide wording. pre-Oxford: Martin provided wording. ]</i></p> + +<p><i>[ +2009-04-28 Pablo adds: +]</i></p> + + +<blockquote> +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2554.pdf">N2554</a> +(scoped allocators), +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2768.pdf">N2768</a> +(allocator concepts), and +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2810.pdf">N2810</a> +(allocator defects), address all of these points EXCEPT <tt>max_size()</tt>. +So, I would add a note to that affect and re-class the defect as belonging +to section 23.2.1 [container.requirements.general]. +</blockquote> + <p><b>Proposed resolution:</b></p> <p> -Specifically, I propose to change 23.1 [container.requirements], +Specifically, I propose to change 23.2 [container.requirements], p9 as follows: </p> @@ -6146,11 +6239,13 @@ post Oxford: This would be rendered NAD Editorial by acceptance of <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>Section:</b> 20.8.11.2 [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>Opened:</b> 2006-06-14 <b>Last modified:</b> 2009-03-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>Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1029">1029</a></p> <p> The specialized algorithms [lib.specialized.algorithms] are specified @@ -6271,8 +6366,8 @@ effect by means of function template overloading. <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>Section:</b> 22.4 [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>Opened:</b> 2006-06-22 <b>Last modified:</b> 2007-10-09</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> @@ -6393,8 +6488,8 @@ Proposed Disposition: Open <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>Section:</b> 23.3.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>Opened:</b> 2006-07-18 <b>Last modified:</b> 2009-05-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> @@ -6527,6 +6622,37 @@ it relies on table 80: "size() of the largest possible container" which, again, doesn't seem to consider fixed size containers </p> +<p><i>[ +2009-05-29 Daniel adds: +]</i></p> + + +<blockquote> +<ol type="a"> +<li> +<p> +star bullet 1 ("what's the effect of calling <tt>assign(T&)</tt> on a +zero-sized array?[..]"); +</p> +<blockquote> +<tt>assign</tt> has been renamed to <tt>fill</tt> and the semantic of <tt>fill</tt> is now +defined in terms of +the free algorithm <tt>fill_n</tt>, which is well-defined for this situation. +</blockquote> +</li> +<li> +<p> +star bullet 3 ("it would be desiderable to have a static const data +member..."): +</p> +<blockquote> +It seems that <tt>tuple_size<array<T, N> >::value</tt> as of 23.3.1.7 [array.tuple] does +provide this functionality now. +</blockquote> +</li> +</ol> +</blockquote> + <p><b>Proposed resolution:</b></p> <p> @@ -6546,7 +6672,7 @@ requirements? Alisdair will prepare a paper. Proposed Disposition: Open <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> + <b>Submitter:</b> Daveed Vandevoorde <b>Opened:</b> 2006-04-05 <b>Last modified:</b> 2009-05-01</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> @@ -6566,16 +6692,16 @@ Here is an example: </p> </blockquote> <pre> - struct S { - S(_Decimal32 const&); // Converting constructor - }; - void f(S); + struct S { + S(_Decimal32 const&); // Converting constructor + }; + void f(S); - void f(_Decimal64); + void f(_Decimal64); - void g(_Decimal32 d) { - f(d); - } + void g(_Decimal32 d) { + f(d); + } </pre> <blockquote> @@ -6635,7 +6761,7 @@ C-to-C++ compatibility, since neither example can be expressed in C. <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> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-06-15 <b>Last modified:</b> 2007-01-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> @@ -6694,8 +6820,8 @@ Redmond: We prefer explicit conversions for narrowing and implicit for widening. <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>Section:</b> 21.4 [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>Opened:</b> 2006-12-05 <b>Last modified:</b> 2008-03-12</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> @@ -6737,7 +6863,7 @@ rules (substr, operator+, etc.). Howard to supply wording. <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: +consistent with 23.2 [container.requirements], p9 which says in part: <blockquote> All other constructors for these container types take an @@ -6766,24 +6892,24 @@ post Bellevue: We re-confirm that the issue is real. Pablo will provide wording. <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>Section:</b> 23.3.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>Opened:</b> 2006-12-30 <b>Last modified:</b> 2008-03-14</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: +The <tt><array></tt> header is given under 23.3 [sequences]. +23.3.1 [array]/paragraph 3 says: </p> <blockquote><p> "Unless otherwise specified, all array operations are as described in -23.1 [container.requirements]". +23.2 [container.requirements]". </p></blockquote> <p> -However, array isn't mentioned at all in section 23.1 [container.requirements]. +However, array isn't mentioned at all in section 23.2 [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]. +that std::array does not have in 23.3.1 [array]. </p> <p> Also, Table 83 "Optional sequence operations" lists several operations that @@ -6800,110 +6926,154 @@ std::array does have, but array isn't mentioned. <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> +<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#Open">Open</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-01-20 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</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#Open">Open</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> + +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> -Further notes/ideas from the lib-reflector, messages 17982-17984: +The difference between the two forms of specification is that per +17.5.1.4 [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> -<blockquote> <p> -Add additional entries in num_punct to cover the complex separator (French would be ';'). +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> -Insert a space before the comma, which should eliminate the ambiguity. +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> -Solve the problem for ordered sequences in general, perhaps with a -dedicated facet. Then complex should use that solution. +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-active.html#424">424</a>): </p> -</blockquote> -<p><i>[ -Bellevue: -]</i></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> -<blockquote> <p> -After much discussion, we agreed on the following: Add a footnote: +Here's another similar example, one that existed even prior to the +introduction of <i>Remark</i>s: </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.] +<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> -And move this to READY status. +<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><p> + </p> -</blockquote> +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><i>[ -Pre-Sophia Antipolis, Howard adds: +Batavia: Alan and Pete to work. ]</i></p> -<blockquote> -Changed "showbase" to "showpoint" and changed from Ready to Review. -</blockquote> +<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><i>[ +Batavia (2009-05): +]</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> +Tom proposes we say that, unless specified otherwise, +it is always the caller's responsibility to verify that supplied arguments +meet the called function's requirements. +If further semantics are specified +(e.g., that the function throws under certain conditions), +then it is up to the implementer to check those conditions. +Alan feels strongly that our current use of Requires in this context +is confusing, especially now that <tt>requires</tt> is a new keyword. </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>Section:</b> 26.6.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>Opened:</b> 2007-01-28 <b>Last modified:</b> 2008-06-02</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 +Section 26.2 [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 @@ -6930,7 +7100,7 @@ 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]. +26.2 [numeric.requirements]. </p> <p> @@ -6982,7 +7152,7 @@ If no proposed wording by June meeting, this issue should be closed NAD. <p><b>Proposed resolution:</b></p> <p> -Change 26.5.2.2 [valarray.assign], p1 as follows: +Change 26.6.2.2 [valarray.assign], p1 as follows: </p> <blockquote> @@ -7020,7 +7190,7 @@ text: </blockquote> <p> -Also add the following paragraph to 26.5.2.2 [valarray.assign], immediately after p4: +Also add the following paragraph to 26.6.2.2 [valarray.assign], immediately after p4: </p> <blockquote> @@ -7042,7 +7212,7 @@ prefers the original proposed resolution: <p> -Change 26.5.2.2 [valarray.assign], p1 as follows: +Change 26.6.2.2 [valarray.assign], p1 as follows: </p> <blockquote> @@ -7060,7 +7230,7 @@ Change 26.5.2.2 [valarray.assign], p1 as follows: </blockquote> <p> -Add the following paragraph to 26.5.2.2 [valarray.assign], immediately after +Add the following paragraph to 26.6.2.2 [valarray.assign], immediately after p4: </p> @@ -7087,95 +7257,9 @@ which you can assign to a <tt>valarray</tt> of size 0, but not to any other <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>Section:</b> 23.2 [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>Opened:</b> 2007-02-01 <b>Last modified:</b> 2009-05-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#Open">Open</a> status.</p> @@ -7221,13 +7305,6 @@ 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 @@ -7247,19 +7324,36 @@ invalidated. Alan to provide wording that toughens wording, but that does not absolutely mandate O(1). </blockquote> +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +We observed that the wording "should" (in note a) has no effect. +Howard prefers that O(1) size be mandated. +It is not clear that this issue can be resolved to everyone's satisfaction, +but Alan will provide wording nonetheless. +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +</p> + + <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>Section:</b> X [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>Opened:</b> 2007-02-08 <b>Last modified:</b> 2009-05-01</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 +The table of allocator requirements in X [allocator.requirements] describes <tt>allocator::address</tt> as: </p> <blockquote><pre>a.address(r) @@ -7299,11 +7393,31 @@ Mandating that <tt>allocator::address</tt> can only be called for values which t allocator allocated seems overly restrictive. </p> +<p><i>[ +post San Francisco: +]</i></p> + + +<blockquote> +Pablo recommends NAD Editorial, solved by +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2768.pdf">N2768</a>. +</blockquote> + +<p><i>[ +2009-04-28 Pablo adds: +]</i></p> + + +<blockquote> +Tentatively-ready NAD Editorial as fixed by +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2768.pdf">N2768</a>. +</blockquote> + <p><b>Proposed resolution:</b></p> <p> -Change 20.1.2 [allocator.requirements]: +Change X [allocator.requirements]: </p> <blockquote> @@ -7335,15 +7449,17 @@ no resolution to this issue was recorded. Moved to Open. <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>Section:</b> 20.7.16.2 [func.wrap.func] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">Tentatively NAD</a> + <b>Submitter:</b> Bo Persson <b>Opened:</b> 2007-02-25 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#func.wrap.func">active issues</a> in [func.wrap.func].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.wrap.func">issues</a> in [func.wrap.func].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD">Tentatively NAD</a> status.</p> <p><b>Discussion:</b></p> <p> -X [func.wrap.func.undef] +20.7.16.2 [func.wrap.func] </p> <p> -The note in paragraph 2 refers to 'undefined void operators', while the +The note in paragraph 2 refers to 'undefined void operators', while the section declares a pair of operators returning bool. </p> @@ -7358,23 +7474,65 @@ changed from private to deleted. The two issues stepped on each other. What do type of these deleted functions to be? </blockquote> +<p><i>[ +2009-05-02 Daniel adds: +]</i></p> + + +<blockquote> +<p> +I suggest harmonizing this issue with similar classes. E.g. in +20.8.13.3 [util.smartptr.weak] <tt>bool</tt> return values for +</p> +<blockquote><pre>template <class Y> bool operator<(weak_ptr<Y> const&) const = delete; +template <class Y> bool operator<=(weak_ptr<Y> const&) const = delete; +template <class Y> bool operator>(weak_ptr<Y> const&) const = delete; +template <class Y> bool operator>=(weak_ptr<Y> const&) const = delete; +</pre></blockquote> + +<p> +are used and basically all <em>newer</em> provided deleted copy assignment operators +of type <tt>X</tt> use the canonical return type <tt>X&</tt> instead of <tt>void</tt>. Since the note +mentioned in the issue description has now already been changed to +</p> +<blockquote> +deleted overloads close possible hole in the type system +</blockquote> +<p> +it seems to be of even lesser need to perform the change. Therefore +I recommend declaring the issue as NAD. +</p> +</blockquote> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +<p> +We agree with Daniel's recommendation. +</p> +<p> +Move to NAD. +</p> +</blockquote> <p><b>Proposed resolution:</b></p> <p> -Change 20.6.15.2 [func.wrap.func] +Change 20.7.16.2 [func.wrap.func] </p> <blockquote><pre>... private: - // X [func.wrap.func.undef], undefined operators: + // 20.7.16.2 [func.wrap.func], 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] +Change 20.7.16.2 [func.wrap.func] </p> <blockquote><pre>template<class Function2> <del>bool</del> <ins>void</ins> operator==(const function<Function2>&); @@ -7387,8 +7545,8 @@ template<class Function2> <del>bool</del> <ins>void</ins> operator!=(const <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>Section:</b> 24.6.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>Opened:</b> 2007-03-25 <b>Last modified:</b> 2009-05-30</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> @@ -7433,37 +7591,6 @@ 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>, @@ -7498,25 +7625,112 @@ is just: <tt>istreambuf_iterator</tt> should have an <tt>operator->()</tt>! </p> </blockquote> +<p><i>[ +2009-04-30 Alisdair adds: +]</i></p> + + +<blockquote> +Note that operator-> is now a requirement in the <tt>InputIterator</tt> concept, so +this issue cannot be ignored or existing valid programs will break when +compiled with an 0x library. +</blockquote> + +<p><i>[ +2009-05-29 Alisdair adds: +]</i></p> + + +<blockquote> +<p> +I agree with the observation that in principle the type 'pointer' may be a +proxy, and the words highlighting this are redundant. +</p> +<p> +However, in the current draught <tt>pointer</tt> is required to be exactly '<tt>charT *</tt>' +by the derivation from <tt>std::iterator</tt>. At a minimum, the 4th parameter of +this base class template should become unspecified. That permits the +introduction of a proxy as a nested class in some further undocumented (not +even exposition-only) base. +</p> +<p> +It also permits the <tt>istream_iterator</tt> approach where the cached value is +stored in the iterator itself, and the iterator serves as its own proxy for +post-increment <tt>operator++</tt> - removing the need for the existing +exposition-only nested class <tt>proxy</tt>. +</p> +<p> +Note that the current <tt>proxy</tt> class also has exactly the right properties to +serve as the pointer <tt>proxy</tt> too. This is likely to be a common case where an +<tt>InputIterator</tt> does not hold internal state but delegates to another class. +</p> +<p> +Proposed Resolution: +</p> +<p> +In addition to the current proposal: +</p> +<p> +24.6.3 [istreambuf.iterator] +</p> +<blockquote><pre>template<class charT, class traits = char_traits<charT> > +class istreambuf_iterator + : public iterator<input_iterator_tag, charT, + typename traits::off_type, <del>charT*</del> <ins><i>unspecified</i></ins>, charT> { +</pre></blockquote> +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +Add to the synopsis in 24.6.3 [istreambuf.iterator]: +</p> + +<blockquote><pre>charT operator*() const; +<ins>pointer operator->() const;</ins> +istreambuf_iterator<charT,traits>& operator++(); +</pre></blockquote> + +<p> +Change 24.6.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> + + + + <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>Section:</b> 22.4.6.1.2 [locale.money.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">Tentatively NAD</a> + <b>Submitter:</b> Thomas Plum <b>Opened:</b> 2007-04-16 <b>Last modified:</b> 2009-05-23</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD">Tentatively NAD</a> status.</p> <p><b>Discussion:</b></p> <p> -22.2.6.1.2 [locale.money.get.virtuals], para 1 says: +22.4.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 +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> @@ -7561,6 +7775,16 @@ which are translated by <tt>ct.widen(c)</tt> calls before being stored in <tt>di the widened characters are not relevant to the parsing of the subject string. </blockquote> +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +We agree with Bill's comment above, +in line with the first of the interpretations offered in the issue. +Move to NAD. +</blockquote> + <p><b>Proposed resolution:</b></p> <p> @@ -7572,30 +7796,29 @@ the widened characters are not relevant to the parsing of the subject string. <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>Section:</b> 22.4.6.1.2 [locale.money.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">Tentatively NAD</a> + <b>Submitter:</b> Thomas Plum <b>Opened:</b> 2007-04-16 <b>Last modified:</b> 2009-05-23</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD">Tentatively NAD</a> status.</p> <p><b>Discussion:</b></p> <p> -22.2.6.1.2 [locale.money.get.virtuals], para 3 says: +22.4.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 +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: +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 +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> @@ -7608,52 +7831,108 @@ Kona (2007): Bill to provide proposed wording and interpretation of existing wor ]</i></p> +<p> +Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#669">669</a>. +</p> +<p><i>[ +2009-05-17 Howard adds: +]</i></p> -<p><b>Proposed resolution:</b></p> + +<blockquote> <p> +I disagree that a <tt>negative_sign</tt> of "" means "there is no +way to +write a negative sign". The meaning requires the sentences of +22.4.6.1.2 [locale.money.get.virtuals] p3 following that quoted above +to be +taken into account: </p> +<blockquote> +-3- ... 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. Otherwise, the character +in the indicated position must match the first character of <tt>pos</tt> +or <tt>neg</tt>, and the result is given the corresponding sign. 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. +</blockquote> +<p> +So a <tt>negative_sign</tt> of "" means "there is no way to write a +negative sign" only when <tt>positive_sign</tt> is also "". However +when <tt>negative_sign</tt> is "" and <tt>postive_sign.size() > +0</tt>, then one writes a negative value by not writing the +<tt>postive_sign</tt> in the position indicated by +<tt>money_base::sign</tt>. +For example: +</p> +<blockquote><pre>pattern = {symbol, sign, value, none} +positive_sign = "+" +negative_sign = "" +$123 // a negative value, using optional sign +$+123 // a positive value +$-123 // a parse error +</pre></blockquote> - -<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: +And: </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> +<blockquote><pre>pattern = {symbol, sign, value, none} +positive_sign = "" +negative_sign = "" +$123 // a positive value, no sign possible +$+123 // a parse error +$-123 // a parse error +</pre></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: +And (regarding <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#669">669</a>): </p> -<blockquote><p> -The input can successfully match only a positive sign, so the negative -pattern is an unsuccessful match. -</p></blockquote> +<blockquote><pre>pattern = {symbol, sign, value, none} +positive_sign = "-" +negative_sign = "-" +$123 // a parse error, sign is mandatory +$+123 // a parse error +$-123 // a positive value +</pre></blockquote> + <p> -[Plum ref _222612Y34, 222612Y51b] +The text seems both unambiguous and clear to me. I recommend NAD for +both this issue and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#669">669</a>. However I would have no +objection to adding examples such as those above. </p> +</blockquote> <p><i>[ -Bill to provide proposed wording and interpretation of existing wording. +Batavia (2009-05): ]</i></p> +<blockquote> +<p> +This discussion applies equally to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#669">669</a> (q.v.). +Howard has added examples above, +and recommends either NAD or a resolution that adds his (or similar) examples +to the Working Paper. +</p> +<p> +Alan would like to rewrite paragraph 3. +</p> +<p> +We recommend moving to NAD. +Anyone who feels strongly about adding the examples +is invited to submit corresponding wording. +We further recommend issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#669">669</a> be handled identically. +</p> +</blockquote> @@ -7666,42 +7945,65 @@ Bill to provide proposed wording and interpretation of existing wording. <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> +<h3><a name="669"></a>669. Equivalent postive and negative signs in <tt>money_get</tt></h3> +<p><b>Section:</b> 22.4.6.1.2 [locale.money.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">Tentatively NAD</a> + <b>Submitter:</b> Thomas Plum <b>Opened:</b> 2007-04-16 <b>Last modified:</b> 2009-05-23</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#Tentatively%20NAD">Tentatively NAD</a> status.</p> <p><b>Discussion:</b></p> - - <p> -22.2.6.3 [locale.moneypunct], para 2 says: +22.4.6.1.2 [locale.money.get.virtuals], para 3 sentence 4 says: </p> <blockquote><p> -The value <tt>space</tt> indicates that at least one space is required at -that position. +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> -The following objection has been raised: +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> -Whitespace is optional when matching space. (See 22.2.6.1.2 [locale.money.get.virtuals], para 2.) +The input can successfully match only a positive sign, so the negative +pattern is an unsuccessful match. </p></blockquote> <p> -[Plum ref _22263Y22] +[Plum ref _222612Y34, 222612Y51b] </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. +Bill to provide proposed wording and interpretation of existing wording. ]</i></p> +<p><i>[ +2009-05-17 See Howard's comments in related issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#668">668</a>. +]</i></p> + + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +<p> +This discussion applies equally to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#668">668</a> (q.v.). +Howard has added examples there, +and recommends either NAD or a resolution that adds his (or similar) examples +to the Working Paper. +</p> +<p> +We recommend moving to NAD. +Anyone who feels strongly about adding the examples +is invited to submit corresponding wording. +We further recommend issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#668">668</a> be handled identically. +</p> +</blockquote> <p><b>Proposed resolution:</b></p> @@ -7714,8 +8016,8 @@ whitespace characters on input. <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>Section:</b> 22.4.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>Opened:</b> 2007-04-20 <b>Last modified:</b> 2009-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#Open">Open</a> status.</p> <p><b>Discussion:</b></p> @@ -7729,7 +8031,7 @@ As far as I can tell, it does so via the following: 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 +In subclause 22.4.2.2.2 [facet.num.put.virtuals], Table 58 Floating-point conversions, after the line: floatfield == ios_base::scientific %E </p> @@ -7744,10 +8046,10 @@ floatfield == ios_base::fixed | ios_base::scientific %A 2 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] +conversion specifier. end note] </p> <p> -Following the thread, in 22.2.2.2.2 [facet.num.put.virtuals], we find: +Following the thread, in 22.4.2.2.2 [facet.num.put.virtuals], we find: </p> <p> For conversion from a floating-point type, if (flags & fixed) != 0 or @@ -7757,16 +8059,16 @@ conversion specification. <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 +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 +%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> @@ -7788,777 +8090,111 @@ Kona (2007): Robert volunteers to propose wording. <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> +<h3><a name="688"></a>688. reference_wrapper, cref unsafe, allow binding to rvalues</h3> +<p><b>Section:</b> 20.7.5.1 [refwrap.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2007-05-10 <b>Last modified:</b> 2009-05-23</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#Tentatively%20Ready">Tentatively Ready</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]: +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> -<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. +Also please see the thread starting at c++std-lib-17398 for some good discussion on this subject. </p> -</blockquote> <p><i>[ -post Sophia Antipolis Howard updated proposed wording: +2009-05-09 Alisdair adds: ]</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]: +Now that <tt>ref/cref</tt> are constained that <tt>T</tt> must be an <tt>ObjectType</tt>, I do not +believe there is any risk of binding <tt>ref</tt> to a temporary (which would rely on +deducing <tt>T</tt> to be an rvalue reference type) </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]: +However, the problem for <tt>cref</tt> remains, so I recommend retaining that deleted +overload. </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><i>[ +2009-05-10 Howard adds: +]</i></p> -<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]: +Without: </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> +<blockquote><pre>template <class T> void ref(const T&& t) = delete; </pre></blockquote> - <p> -Add to 23.4.2.1 [unord.multimap.cnstr]: +I believe this program will compile: </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> +<blockquote><pre>#include <functional> -<p> -Add new section [unord.multimap.modifiers]: -</p> +struct A {}; -<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> +const A source() {return A();} -<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 +int main() { - ... - 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> + std::reference_wrapper<const A> r = std::ref(source()); +} </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]: +I.e. in: </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> +<blockquote><pre>template <ObjectType T> reference_wrapper<T> ref(T& t); +</pre></blockquote> <p> -Change 23.4.4 [unord.multiset]: +this: </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> +<blockquote><pre>ref(source()) </pre></blockquote> - <p> -Add to 23.4.4.1 [unord.multiset.cnstr]: +deduces <tt>T</tt> as <tt>const A</tt>, and so: </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> +<blockquote><pre>ref(const A& t) +</pre></blockquote> <p> -Add new section [unord.multiset.modifiers]: +will bind to a temporary (tested with a pre-concepts rvalue-ref enabled compiler). </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]: +Therefore I think we still need the ref-protection. I respectfully disagree with Alisdair's +comment and am in favor of the proposed wording as it stands. Also, CWG 606 +(noted below) has now been "favorably" resolved. </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: +Batavia (2009-05): ]</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> +We agree with the proposed resolution. +Move to Tentatively Ready. </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: +In 20.7 [function.objects], add the following two signatures to the synopsis: </p> <blockquote><pre>template <class T> void ref(const T&& t) = delete; @@ -8593,291 +8229,211 @@ the "special deduction rule" is disabled with the const T&& pattern. <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> +<h3><a name="696"></a>696. <code>istream::operator>>(int&)</code> broken</h3> +<p><b>Section:</b> 27.7.1.2.2 [istream.formatted.arithmetic] <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>Opened:</b> 2007-06-23 <b>Last modified:</b> 2009-05-28</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#Open">Open</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]: +From message c++std-lib-17897: </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]: +The code shown in 27.7.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> - -<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. +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> -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. +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> -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><i>[ +Batavia (2009-05): +]</i></p> -<p><b>Proposed resolution:</b></p> +<blockquote> <p> -Add a new paragraph immediately above p4 of 27.6.4 [ext.manip] with the -following text: +We believe this part of the Standard has been recently adjusted +and that this issue was addressed during that rewrite. </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: +Move to NAD. </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> - +</blockquote> <p><i>[ -post Bellevue: +2009-05-28 Howard adds: ]</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. +I've moved this issue from Tentatively NAD to Open. </p> - -<p><b>Proposed resolution:</b></p> <p> +The current wording of +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2857.pdf">N2857</a> +in 22.4.2.1.2 [facet.num.get.virtuals] p3, stage 3 appears to indicate that +in parsing arithmetic types, the value is always set, but sometimes in addition +to setting <tt>failbit</tt>. </p> +<ul> +<li> +If there is a range error, the value is set to min or max, else +</li> +<li> +if there is a conversion error, the value is set to 0, else +</li> +<li> +if there is a grouping error, the value is set to whatever it would be if grouping were ignored, else +</li> +<li> +the value is set to its error-free result. +</li> +</ul> - - - -<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. +However there is a contradictory sentence in 22.4.2.1.2 [facet.num.get.virtuals] p1. </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>. +27.7.1.2.2 [istream.formatted.arithmetic] should mimic the behavior of 22.4.2.1.2 [facet.num.get.virtuals] +(whatever we decide that behavior is) for +<tt>int</tt> and <tt>short</tt>, and currently does not. I believe that the +correct code fragment should look like: </p> +<blockquote><pre>typedef num_get<charT,istreambuf_iterator<charT,traits> > numget; +iostate err = ios_base::goodbit; +long lval; +use_facet<numget>(loc).get(*this, 0, *this, err, lval); +if (lval < numeric_limits<int>::min()) +{ + err |= ios_base::failbit; + val = numeric_limits<int>::min(); +} +else if (lval > numeric_limits<int>::max()) +{ + err |= ios_base::failbit; + val = numeric_limits<int>::max(); +} +else + val = static_cast<int>(lval); +setstate(err); +</pre></blockquote> +</blockquote> + <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. +Change 22.4.2.1.2 [facet.num.get.virtuals], p1: </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> +<blockquote> +-1- <i>Effects:</i> Reads characters from <tt>in</tt>, interpreting them +according to <tt>str.flags()</tt>, <tt>use_facet<ctype<charT> +>(loc)</tt>, and <tt>use_facet< numpunct<charT> +>(loc)</tt>, where <tt>loc</tt> is <tt>str.getloc()</tt>. <del>If an error +occurs, <tt>val</tt> is unchanged; otherwise it is set to the resulting value.</del> +</blockquote> <p> -To 19.4.5.2 [syserr.syserr.members] Class system_error members add: +Change 27.7.1.2.2 [istream.formatted.arithmetic], p2 and p3: </p> <blockquote> -<pre>system_error(error_code ec, const char* what_arg); +<pre>operator>>(short& val); </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>. +-2- The conversion occurs as if performed by the following code fragment (using the same notation as for +the preceding code fragment): </p> + +<blockquote><pre>typedef num_get<charT,istreambuf_iterator<charT,traits> > numget; +iostate err = ios<del>tate</del><ins>_base</ins>::goodbit; +long lval; +use_facet<numget>(loc).get(*this, 0, *this, err, lval); +<del>if (err != 0) + ; +else if (lval < numeric_limits<short>::min() + || numeric_limits<short>::max() < lval) + err = ios_base::failbit;</del> +<ins>if (lval < numeric_limits<short>::min()) +{ + err |= ios_base::failbit; + val = numeric_limits<short>::min(); +} +else if (lval > numeric_limits<short>::max()) +{ + err |= ios_base::failbit; + val = numeric_limits<short>::max(); +}</ins> +else + val = static_cast<short>(lval); +setstate(err); +</pre></blockquote> + </blockquote> -<pre>system_error(int ev, const error_category* ecat, const char* what_arg); +<pre>operator>>(int& val); </pre> - <blockquote> <p> -<i>Effects:</i> Constructs an object of class <tt>system_error</tt>. +-3- The conversion occurs as if performed by the following code fragment (using the same notation as for +the preceding code fragment): </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><pre>typedef num_get<charT,istreambuf_iterator<charT,traits> > numget; +iostate err = ios<del>tate</del><ins>_base</ins>::goodbit; +long lval; +use_facet<numget>(loc).get(*this, 0, *this, err, lval); +<del>if (err != 0) + ; +else if (lval < numeric_limits<int>::min() + || numeric_limits<int>::max() < lval) + err = ios_base::failbit;</del> +<ins>if (lval < numeric_limits<int>::min()) +{ + err |= ios_base::failbit; + val = numeric_limits<int>::min(); +} +else if (lval > numeric_limits<int>::max()) +{ + err |= ios_base::failbit; + val = numeric_limits<int>::max(); +}</ins> +else + val = static_cast<int>(lval); +setstate(err); +</pre></blockquote> + </blockquote> +</blockquote> @@ -8885,9 +8441,9 @@ To 19.4.5.2 [syserr.syserr.members] Class system_error members add: <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>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#NAD">Tentatively NAD</a> + <b>Submitter:</b> Christopher Crawford <b>Opened:</b> 2007-06-30 <b>Last modified:</b> 2009-05-23</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD">Tentatively NAD</a> status.</p> <p><b>Discussion:</b></p> <p> I see that the definition the associated Laguerre @@ -8912,24 +8468,18 @@ standard, either adding extra functions for real <tt>m</tt> or switching the current ones to <tt>double</tt>. </p> +<p><i>[ +Batavia (2009-05): +]</i></p> -<p><b>Proposed resolution:</b></p> +<blockquote> <p> +We understand the issue, and have opted not to extend as recommended. </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> +Move to NAD. +</p> +</blockquote> <p><b>Proposed resolution:</b></p> @@ -8941,151 +8491,33 @@ One other small thing, in TR1 5.2.1.2 [tr.num.sf.Plm], the restriction should b <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> +<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#NAD">Tentatively NAD</a> + <b>Submitter:</b> Christopher Crawford <b>Opened:</b> 2007-06-30 <b>Last modified:</b> 2009-05-23</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD">Tentatively NAD</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> +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> -<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><i>[ +Batavia (2009-05): +]</i></p> +<blockquote> <p> +The error has been corrected in the pending IS. </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> +Move to NAD. </p> +</blockquote> -<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><b>Proposed resolution:</b></p> <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> - - @@ -9093,7 +8525,8 @@ Bellevue: This should be handled as part of the concepts work. <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> + <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2007-07-28 <b>Last modified:</b> 2008-09-17</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#localization">active issues</a> in [localization].</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> @@ -9130,86 +8563,27 @@ Kona (2007): Bill and Nick to provide wording. ]</i></p> +<p><i>[ +San Francisco: Bill and Nick still intend to provide wording, but this +is a part of the task to be addressed by the group that will look into +issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#860">860</a>. +]</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>Section:</b> 20.8.13.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>Opened:</b> 2007-08-24 <b>Last modified:</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#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> @@ -9240,7 +8614,7 @@ 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]: +This is contradicted by the second sentence in the Returns clause of 20.8.13.2.5 [util.smartptr.shared.obs]: </p> <blockquote> @@ -9316,7 +8690,7 @@ that Peter's description above is supporting an undesirable behavior. <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]: +In keeping the N2351 spirit and obviously my preference, change 20.8.13.2.5 [util.smartptr.shared.obs]: </p> <blockquote> @@ -9332,7 +8706,7 @@ Alternative proposed resolution: (I won't be happy if we do this, but it's possi </p> <p> -Change 20.7.12.2.1 [util.smartptr.shared.const]: +Change 20.8.13.2.1 [util.smartptr.shared.const]: </p> <blockquote> @@ -9356,103 +8730,13 @@ instance with a non-NULL stored pointer. <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>Section:</b> 28.14 [re.grammar] <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>Opened:</b> 2007-08-31 <b>Last modified:</b> 2009-05-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> -TR1 7.13 [tr.re.grammar]/3 and C++0x WP 28.13 [re.grammar]/3 say: +TR1 7.13 [tr.re.grammar]/3 and C++0x WP 28.14 [re.grammar]/3 say: </p> <blockquote> @@ -9475,6 +8759,22 @@ This definition for <tt>CharacterClass</tt> appears to be exactly identical to t Was an actual modification intended here and accidentally omitted, or was this production accidentally included? </p> +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +<p> +We agree that what is specified is identical to what ECMA-262 specifies. +Pete would like to take a bit of time to assess whether we had intended, +but failed, to make a change. +It would also be useful to hear from John Maddock on the issue. +</p> +<p> +Move to Open. +</p> +</blockquote> + <p><b>Proposed resolution:</b></p> <p> @@ -9493,14 +8793,14 @@ Remove this mention of the CharacterClass production. <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>Section:</b> 21.4 [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>Opened:</b> 2007-08-18 <b>Last modified:</b> 2008-03-12</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: +Paragraph 21.4 [basic.string]/3 states: </p> <blockquote> @@ -9511,7 +8811,7 @@ Sequence (23.1.1) and for a Reversible Container (23.1). </blockquote> <p> -First of all, 23.1.3 [sequence.reqmts] is no longer "Sequence" but "Sequence container". +First of all, 23.2.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. @@ -9558,8 +8858,9 @@ different, a string abstraction in its own right. <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>Section:</b> 20.6 [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>Opened:</b> 2007-08-25 <b>Last modified:</b> 2009-03-14</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta">active issues</a> in [meta].</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> @@ -9589,7 +8890,7 @@ a new type category "literal", which is defined in 3.9 [basic.types]/p.11: <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: +literal types in 20.6.4.3 [meta.unary.prop] for several reasons: </p> <ol type="a"> @@ -9612,32 +8913,7 @@ way to portably test the condition for literal class types: </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 @@ -9651,7 +8927,7 @@ These two issues should move to OPEN pending AM paper on type traits. <p><b>Proposed resolution:</b></p> <p> -In 20.5.2 [meta.type.synop] in the group "type properties", +In 20.6.2 [meta.type.synop] in the group "type properties", just below the line </p> @@ -9666,7 +8942,7 @@ add a new one: </pre></blockquote> <p> -In 20.5.4.3 [meta.unary.prop], table Type Property Predicates, just +In 20.6.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> @@ -9689,93 +8965,12 @@ array of unknown bound, or <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>Section:</b> 22.3.3.2.2 [conversions.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>Opened:</b> 2007-08-27 <b>Last modified:</b> 2008-09-18</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#conversions.string">active issues</a> in [conversions.string].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#conversions.string">issues</a> in [conversions.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 3 says that the <tt>Codecvt</tt> template parameter shall meet the @@ -9802,6 +8997,14 @@ void main() } </pre></blockquote> +<p><i>[ +San Francisco: +]</i></p> + + +<blockquote> +Bill will propose a resolution. +</blockquote> <p><b>Proposed resolution:</b></p> @@ -9814,14 +9017,17 @@ void main() <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>Section:</b> 28.9 [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>Opened:</b> 2007-08-29 <b>Last modified:</b> 2009-03-13</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><b>Addresses UK 316</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 +template <tt>basic_regex</tt>, as described in 28.9 [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 @@ -9838,187 +9044,101 @@ Sophia Antipolis: Needs wording for the semantics, the idea is agreed upon. </blockquote> +<p><i>[ +Post Summit Daniel updated wording to reflect new "swap rules". +]</i></p> + + <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, +In the class definition of <tt>basic_regex</tt>, just below 28.9 [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> +<ol type="a"> <li> -<p>Change the current <tt>swap</tt> function to read:</p> -<blockquote><pre>void swap(basic_regex&&); -</pre></blockquote> -</li> +<p> +Just after <tt>basic_regex(const basic_regex&);</tt> insert: +</p> -<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> +<p> +Just after <tt>basic_regex& operator=(const basic_regex&);</tt> insert: +</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> +<p> +Just after <tt>basic_regex& assign(const basic_regex& that);</tt> insert: +</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. +In 28.9.2 [re.regex.construct], just after p.11 add the following +new member definition: </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><pre>basic_regex(basic_regex&& e); +</pre> <blockquote> <p> -Walking into the default/value-initialization mess... +<i>Effects:</i> Move-constructs a <tt>basic_regex</tt> instance from <tt>e</tt>. </p> <p> -Why two lines? Because we need both expressions to be valid. +<i>Postconditions:</i> <tt>flags()</tt> and <tt>mark_count()</tt> return <tt>e.flags()</tt> and +<tt>e.mark_count()</tt>, respectively, +that <tt>e</tt> had before construction, leaving +<tt>e</tt> in a valid state with an unspecified value. </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. +<i>Throws:</i> nothing. </p> +</blockquote> +</blockquote> +</li> +<li> <p> -This is an issue that must be solved by concepts, but we might need to solve it independantly first. +Also in 28.9.2 [re.regex.construct], just after p.18 add the +following new member definition: </p> + +<blockquote><pre>basic_regex& operator=(basic_regex&& e); +</pre> +<blockquote> +<i>Effects:</i> Returns the result of <tt>assign(std::move(e))</tt>. +</blockquote> +</blockquote> +</li> +<li> <p> -It seems that the requirements are the syntax in the proposed first -column is valid, but not clear what semantics we need. +In 28.9.3 [re.regex.assign], just after p. 2 add the following new +member definition: </p> +<blockquote><pre>basic_regex& assign(basic_regex&& rhs); +</pre> +<blockquote> <p> -A table where there is no post-condition seems odd, but appears to sum up our position best. +<i>Effects:</i> Move-assigns a <tt>basic_regex</tt> instance from <tt>rhs</tt> and returns <tt>*this</tt>. </p> <p> -At a minimum an object is declared and is destuctible. +<i>Postconditions:</i> <tt>flags()</tt> and <tt>mark_count()</tt> return <tt>rhs.flags()</tt> +and <tt>rhs.mark_count()</tt>, respectively, that +<tt>rhs</tt> had before assignment, leaving <tt>rhs</tt> +in a valid state with an unspecified value. </p> <p> -Move to open, as no-one happy to produce wording on the fly. +<i>Throws:</i> nothing. </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> - +</blockquote> +</li> +</ol> @@ -10026,8 +9146,8 @@ following table: <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>Section:</b> 28.12.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>Opened:</b> 2007-09-22 <b>Last modified:</b> 2008-06-18</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> @@ -10109,7 +9229,7 @@ Sophia Antipolis: <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 +wording is provided only for 28.12.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> @@ -10122,7 +9242,7 @@ 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]: +charT* str</tt> and <tt>const charT* fmt</tt>). 28.12.4 [re.alg.replace]: </p> <blockquote> @@ -10188,11 +9308,11 @@ charT* str</tt> and <tt>const charT* fmt</tt>). 28.11.4 [re.alg.replace]: <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>Section:</b> 28.12.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>Opened:</b> 2007-09-22 <b>Last modified:</b> 2009-05-23</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>View all 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>regex_match()</tt> and <tt>regex_search()</tt> take <tt>const basic_string<charT, ST, @@ -10201,6 +9321,23 @@ SA>&</tt>. <tt>regex_replace()</tt> takes <tt>const basic_string<char allocators. </p> +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +<p> +Bill comments, "We need to look at the depth of this change." +</p> +<p> +Pete remarks that we are here dealing with a convenience function +that saves a user from calling the iterato-based overload. +</p> +<p> +Move to Open. +</p> +</blockquote> + <p><b>Proposed resolution:</b></p> <p> @@ -10218,37 +9355,58 @@ arguments. <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> +<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.6.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>Opened:</b> 2007-10-10 <b>Last modified:</b> 2008-03-11</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta.unary.prop">active issues</a> in [meta.unary.prop].</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> -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>]. +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> -I see two possible resolutions: +What level of magic do we expect to deduce if this is known? +</p> +<p> +E.g. </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> - +<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> -See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a> -for further discussion. +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>[ @@ -10257,124 +9415,420 @@ Bellevue: <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> -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> + + + + + +<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.6.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>Opened:</b> 2007-10-10 <b>Last modified:</b> 2008-03-11</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta.rel">active issues</a> in [meta.rel].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.rel">issues</a> in [meta.rel].</p> +<p><b>View all 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> -Take the proposed recommendation in N2424 and move to REVIEW. +With the pending arrival of explicit conversion functions though, I'm +wondering if we want an additional trait, <tt>is_explictly_convertible</tt>? </p> -</blockquote> +<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.3.7 [vector.bool] <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>Opened:</b> 2007-10-10 <b>Last modified:</b> 2008-09-22</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#Open">Open</a> status.</p> +<p><b>Discussion:</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. +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>[ -Stephan Tolksdorf adds pre-Bellevue: +post 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. +<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><i>[ -Sophia Antipolis: +San Francisco: ]</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>. +<p> +This is really a clause 17 issue, rather than something specific to vector<bool>. +</p> +<p> +Move to Open. Alisdair to provide a resolution. Alternately, Howard can +close this as NAD and then open a new issue to handle the general issue +(rather than the vector<bool> one). +</p> +<p> +Howard: Haven't yet opened new issue. Lacking wording for it. +</p> </blockquote> +<p><b>Proposed resolution:</b></p> +<p> +</p> + <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> +<h3><a name="760"></a>760. The emplace issue</h3> +<p><b>Section:</b> 23.2 [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>Opened:</b> 2007-11-11 <b>Last modified:</b> 2008-06-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#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. +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.2 [container.requirements]/11, the implementation must check all of them for +that possibility. A possible solution can involve extending the +exception in 23.2 [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.2 [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="765"></a>765. more on iterator validity</h3> +<p><b>Section:</b> 24.2 [iterator.concepts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-12-14 <b>Last modified:</b> 2009-03-09</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iterator.concepts">active issues</a> in [iterator.concepts].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.concepts">issues</a> in [iterator.concepts].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively 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#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><i>[ +San Francisco: +]</i></p> + + +<blockquote> +<p>Pablo: add a note to the last bullet of paragraph 11 of 23.1.1 +clarifying that the end() iterator doesn't refer to an element and that +it can therefore be invalidated. +</p> +<p> +Proposed wording: +</p> +<blockquote> +[<i>Note:</i> The <tt>end()</tt> iterator does not refer to any element and can +therefore be invalidated. <i>-- end note</i>] +</blockquote> <p> -<b>Possible resolution:</b> For these reasons, I propose to delete section 26.4.8.5.3 [rand.dist.samp.genpdf]. +Howard will add this proposed wording to the issue and then move it to Review. </p> +</blockquote> <p><i>[ -Bellevue: +Post Summit: ]</i></p> <blockquote> <p> -Disagreement persists. +Lawrence: suggestion: "Note: The <tt>end()</tt> iterator does not refer to any element" +</p> +<p> +Walter: "Note: The <tt>end()</tt> iterator can nevertheless be invalidated, +because it does not refer to any element." +</p> +<p> +Nick: "The <tt>end()</tt> iterator does not refer to any element. It is therefore +subject to being invalidated." </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. +Consensus: go with Nick </p> <p> -Correction: The formula above should instead read 1+sin(n*x). +With that update, Recommend Tentatively Ready. </p> +</blockquote> + + + +<p><b>Proposed resolution:</b></p> <p> -Objector proposes the following possible compromise positions: +Add to 23.2.1 [container.requirements.general], p11: +</p> + +<blockquote> +<p> +Unless otherwise specified (see 23.1.4.1, 23.1.5.1, 23.2.2.3, and +23.2.6.4) all container types defined in this Clause meet the following +additional requirements: </p> <ul> +<li>...</li> <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. +no <tt>swap()</tt> function invalidates any references, pointers, or +iterators referring to the elements of the containers being swapped. +<ins>[<i>Note:</i> The <tt>end()</tt> iterator does not refer to any element. It is therefore +subject to being invalidated. <i>-- end note</i>]</ins> </li> </ul> </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>Opened:</b> 2008-01-14 <b>Last modified:</b> 2008-05-11</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> -See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a> -for the proposed resolution. +Wording provided in +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2590.pdf">N2590</a>. </p> @@ -10382,147 +9836,603 @@ for the proposed resolution. <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> +<h3><a name="780"></a>780. <tt>std::merge()</tt> specification incorrect/insufficient</h3> +<p><b>Section:</b> 25.5.4 [alg.merge] <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>Opened:</b> 2008-01-25 <b>Last modified:</b> 2009-05-23</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). +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.5.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><i>[ +Post Summit Alisdair adds: +]</i></p> + + +<blockquote> <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). +Suggest: </p> +<blockquote> +(where <tt>last</tt> is equal to <tt>next(result, distance(first1, last1) + +distance(first2, last2))</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 < *prev(i)</tt> or, respectively, <tt>comp(*i, +*prev(i))</tt> will be <tt>false</tt>. +</blockquote> <p> -<b>Possible resolution:</b> For these reasons, I propose to change the type of the respective parameters -to double. +Note that this might still not be technically accurate in the case of +<tt>InputIterators</tt>, depending on other resolutions working their way through the +system (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1011">1011</a>). </p> +</blockquote> <p><i>[ -Bellevue: +Post Summit Daniel adds: ]</i></p> <blockquote> -In N2424. Not wildly enthusiastic, not really felt necessary. Less -frequently used in practice. Not terribly bad either. Move to OPEN. +If we want to use <tt>prev</tt> and <tt>next</tt> here (Note: <tt>merge</tt> +is sufficiently satisfied with <tt>InputIterator</tt>) we should instead *add* more to +25 [algorithms]/6, but I can currently not propose any good wording for this. </blockquote> <p><i>[ -Sophia Antipolis: +Batavia (2009-05): ]</i></p> - <blockquote> <p> -Marc Paterno: The generalizations were explicitly left out when designing the facility. It's harder to test. +Pete points out the existing wording in [algorithms]/4 +that permits the use of + in algorithm specifications. +</p> +<p> +Alisdair points out that that wording may not apply to input iterators. </p> <p> -Marc Paterno: Ask implementers whether floating-point is a significant burden. +Move to Review. +</p> +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +In 25.5.4 [alg.merge] replace p.1+ 2: </p> + +<blockquote> <p> -Alisdair: It's neater to do it now, do ask Bill Plauger. +<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> -Disposition: move to review with the option for "NAD" if it's not straightforward to implement; unanimous consent. +<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> </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> -<p><b>Proposed resolution:</b></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#NAD">Tentatively NAD</a> + <b>Submitter:</b> John Maddock <b>Opened:</b> 2008-01-15 <b>Last modified:</b> 2009-05-23</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD">Tentatively NAD</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> -See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a> -for the proposed resolution. +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>[ -Stephan Tolksdorf adds pre-Bellevue: +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><i>[ +Post Summit Daniel adds: ]</i></p> <blockquote> +Recommend NAD: <tt>xor_combine</tt> does no longer exist and <tt>discard_block[_engine]</tt> +has now the required seed overload accepting a <tt>result_type</tt>, which shall be an +unsigned integral type. +</blockquote> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +Move to NAD as recommended. +</blockquote> + + +<p><b>Proposed resolution:</b></p> <p> -In 26.4.8.4.3 [rand.dist.norm.chisq]: +NAD Recommended. </p> + + + + +<hr> +<h3><a name="788"></a>788. ambiguity in [istream.iterator]</h3> +<p><b>Section:</b> 24.6.1 [istream.iterator] <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>Opened:</b> 2008-02-06 <b>Last modified:</b> 2009-03-14</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#Open">Open</a> status.</p> +<p><b>Discussion:</b></p> + +<p><b>Addresses UK 287</b></p> + <blockquote> <p> -Delete ", where <tt>n</tt> is a positive integer" in the first paragraph. +It is not clear what the initial state of an <tt>istream_iterator</tt> should be. Is +_value_ initialized by reading the stream, or default/value initialized? If +it is initialized by reading the stream, what happens if the initialization +is deferred until first dereference, when ideally the iterator value should +have been that of an end-of-stream iterator which is not safely +dereferencable? </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>". +Recommendation: Specify _value_ is initialized by reading the stream, or +the iterator takes on the end-of-stream value if the stream is empty. </p> +</blockquote> <p> -Replace both occurrences of "<tt>int n() const;</tt>" with "<tt>RealType n() const;</tt>". +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> -In 26.4.8.4.5 [rand.dist.norm.f]: +<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><i>[ +Summit: +]</i></p> + + <blockquote> +Moved from Ready to Open for the purposes of using this issue to address NB UK 287. +Martin to handle. +</blockquote> + + +<p><b>Proposed resolution:</b></p> <p> -Delete ", where <tt>m</tt> and <tt>n</tt> are positive integers" in the first paragraph. +Change 24.6.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="801"></a>801. <tt>tuple</tt> and <tt>pair</tt> trivial members</h3> +<p><b>Section:</b> 20.5 [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>Opened:</b> 2008-02-18 <b>Last modified:</b> 2009-05-30</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> -Replace both occurrences of +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> -<blockquote><pre>explicit fisher_f_distribution(int m = 1, int n = 1); +<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> -with +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> -<blockquote><pre>explicit fisher_f_distribution(RealType m = 1, RealType n = 1); +<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> -Replace both occurrences of "<tt>int m() const;" with "RealType m() const;</tt>". +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> -Replace both occurrences of "<tt>int n() const;" with "RealType n() const;</tt>". +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><i>[ +2009-05-27 Daniel adds: +]</i></p> + + +<blockquote> +This is partly solved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1117">1117</a>. +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +</p> + + + + + +<hr> +<h3><a name="810"></a>810. Missing traits dependencies in operational semantics of extended manipulators</h3> +<p><b>Section:</b> 27.7.4 [ext.manip] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-03-01 <b>Last modified:</b> 2009-05-23</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#Tentatively%20Ready">Tentatively Ready</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]/4) and <tt>put_money</tt> ([ext.manip]/6), 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> -In 26.4.8.4.6 [rand.dist.norm.t]: +The same problem occurs within the <tt>get_time</tt> and <tt>put_time</tt> semantic +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><i>[ +Batavia (2009-05): +]</i></p> + <blockquote> <p> -Delete ", where <tt>n</tt> is a positive integer" in the first paragraph. +This appears to be an issue of presentation. </p> +<p> +We agree with the proposed resolution. +Move to Tentatively Ready. +</p> +</blockquote> + +<p><b>Proposed resolution:</b></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>". +In 27.7.4 [ext.manip]/4 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.7.4 [ext.manip]/5 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.7.4 [ext.manip]/6 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.7.4 [ext.manip]/8 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.7.4 [ext.manip]/10 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> +In 27.7 [iostream.format], Header <tt><iomanip></tt> synopsis change: +</p> + +<blockquote><pre>template <<del>class charT, </del>class moneyT> T8 put_money(const moneyT& mon, bool intl = false); +</pre></blockquote> + + + + + +<hr> +<h3><a name="814"></a>814. <tt>vector<bool>::swap(reference, reference)</tt> not defined</h3> +<p><b>Section:</b> 23.3.7 [vector.bool] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-03-17 <b>Last modified:</b> 2009-05-23</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#Tentatively%20Ready">Tentatively Ready</a> status.</p> +<p><b>Discussion:</b></p> <p> -Replace both occurrences of "<tt>int n() const;</tt>" with "<tt>RealType n() const;</tt>". +<tt>vector<bool>::swap(reference, reference)</tt> has no definition. </p> + +<p><i>[ +San Francisco: +]</i></p> + + +<blockquote> +Move to Open. Alisdair to provide a resolution. </blockquote> +<p><i>[ +Post Summit Daniel provided wording. +]</i></p> + + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +We agree with the proposed resolution. +Move to Tentatively Ready. +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +Just after 23.3.7 [vector.bool]/5 add the following prototype and description: +</p> + +<blockquote> +<p> +<ins>static void swap(reference x, reference y);</ins> +</p> +<blockquote> +<p> +<ins>-6- <i>Effects:</i> Exchanges the contents of <tt>x</tt> and <tt>y</tt> as-if</ins> by: +</p> +<blockquote><pre><ins> +bool b = x; +x = y; +y = b; +</ins></pre></blockquote> +</blockquote> </blockquote> @@ -10530,157 +10440,496 @@ Replace both occurrences of "<tt>int n() const;</tt>" with "<tt>RealType n() con <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> +<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.7.16.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>Opened:</b> 2008-03-16 <b>Last modified:</b> 2009-06-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> -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>. +<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><i>[ +2009-05-01 Howard adds: +]</i></p> + + +<blockquote> <p> -This issue seeks to widen the <tt>Swappable</tt> requirement to support proxy iterators. Here -is example code: +Sebastian Gesemann brought to my attention that the <tt>CopyConstructible</tt> +requirement on <tt>function</tt>'s <tt>ArgTypes...</tt> is an unnecessary +restriction. </p> -<blockquote><pre>namespace Mine { +<blockquote><pre>template<Returnable R, <b>CopyConstructible</b>... ArgTypes> +class function<R(ArgTypes...)> +... +</pre></blockquote> -template <class T> -struct proxy {...}; +<p> +On further investigation, this complaint seemed to be the same +issue as this one. I believe the reason <tt>CopyConstructible</tt> was put +on <tt>ArgTypes</tt> in the first place was because of the nature of the +<i>invoke</i> member: +</p> -template <class T> -struct proxied_iterator +<blockquote><pre>template<class R, class ...ArgTypes> +R +function<R(ArgTypes...)>::operator()(ArgTypes... arg) const { - typedef T value_type; - typedef proxy<T> reference; - reference operator*() const; - ... -}; + if (f_ == 0) + throw bad_function_call(); + return (*f_)(arg...); +} +</pre></blockquote> + +<p> +However now with rvalue-refs, "by value" no longer implies <tt>CopyConstructible</tt> +(as Sebastian correctly points out). If rvalue arguments are supplied, <tt>MoveConstructible</tt> +is sufficient. Furthermore, the constraint need not be applied in <tt>function</tt> +if I understand correctly. Rather the client must apply the proper constraints +at the call site. Therefore, at the very least, I recommend that <tt>CopyConstructible</tt> +be removed from the template class <tt>function</tt>. +</p> + +<p> +Furthermore we need to mandate that the <i>invoker</i> is coded as: +</p> -struct A +<blockquote><pre>template<class R, class ...ArgTypes> +R +function<R(ArgTypes...)>::operator()(ArgTypes... arg) const { - // heavy type, has an optimized swap, maybe isn't even copyable or movable, just swappable - void swap(A&); - ... -}; + if (f_ == 0) + throw bad_function_call(); + return (*f_)(<b>std::forward<ArgTypes>(</b>arg<b>)</b>...); +} +</pre></blockquote> + +<p> +Note that <tt>ArgTypes&&</tt> (the "perfect forwarding signature") is not +appropriate here as this is not a deduced context for <tt>ArgTypes</tt>. Instead +the client's arguments must implicitly convert to the non-deduced <tt>ArgType</tt> +type. Catching these arguments by value makes sense to enable decay. +</p> -void swap(A&, A&); -void swap(proxy<A>, A&); -void swap(A&, proxy<A>); -void swap(proxy<A>, proxy<A>); +<p> +Next <tt>forward</tt> is used to move the <tt>ArgTypes</tt> as efficiently as +possible, and also with minimum requirements (not <tt>CopyConstructible</tt>) +to the type-erased functor. For object types, this will be a <tt>move</tt>. For +reference type <tt>ArgTypes</tt>, this will be a copy. The end result <em>must</em> be +that the following is a valid program: +</p> -} // Mine +<blockquote><pre>#include <functional> +#include <memory> +#include <cassert> -... +std::unique_ptr<int> +f(std::unique_ptr<int> p, int& i) +{ + ++i; + return std::move(p); +} -Mine::proxied_iterator<Mine::A> i(...) -Mine::A a; -<b>swap(*i1, a);</b> +int main() +{ + int i = 2; + std::function<std::unique_ptr<int>(std::unique_ptr<int>, + int&> g(f); + std::unique_ptr<int> p = g(std::unique_ptr<int>(new int(1)), i); + assert(*p == 1); + assert(i == 3); +} </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><i>[ +Tested in pre-concepts rvalue-ref-enabled compiler. +]</i></p> + <p> -That is, no standard library code needs to change. We simply need to have a more flexible -definition of <tt>Swappable</tt>. +In the example above, the first <tt>ArgType</tt> is <tt>unique_ptr<int></tt> +and the second <tt>ArgType</tt> is <tt>int&</tt>. Both <em>must</em> work! </p> +</blockquote> + <p><i>[ -Bellevue: +2009-05-27 Daniel adds: ]</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. +in the 2009-05-01 comment of above mentioned issue Howard </p> + +<ol type="a"> +<li> +Recommends to replace the <tt>CopyConstructible</tt> requirement by a +<tt>MoveConstructible</tt> requirement +</li> +<li> +Says: "Furthermore, the constraint need not be applied in <tt>function</tt> if I +understand correctly. Rather the client must apply the proper constraints +at the call site" +</li> +</ol> <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. +I'm fine with (a), but I think comment (b) is incorrect, at least in the +sense I read these sentences. Let's look at Howard's example code: </p> + +<blockquote><pre>function<R(ArgTypes...)>::operator()(ArgTypes... arg) const +{ + if (f_ == 0) + throw bad_function_call(); + return (*f_)(std::forward<ArgTypes>(arg)...); +} +</pre></blockquote> + <p> -Motivation is proxy-iterators, but facility is considerably more -general. Are we happy going so far? +In the constrained scope of this <tt>operator()</tt> overload the expression +"<tt>(*f_)(std::forward<ArgTypes>(arg)...)</tt>" must be valid. How can it +do so, if <tt>ArgTypes</tt> aren't at least <tt>MoveConstructible</tt>? </p> +</blockquote> + + + +<p><b>Proposed resolution:</b></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> + + + + + +<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.7.12.1.3 [func.bind.bind] <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>Opened:</b> 2008-02-08 <b>Last modified:</b> 2009-05-23</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#Open">Open</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><i>[ +San Francisco: +]</i></p> + + +<blockquote> +Howard to provide wording. </blockquote> +<p><i>[ +Post Summit, Anthony provided wording. +]</i></p> + + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +Part of all of this issue appears to be rendered moot +by the proposed resolution to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#817">817</a> (q.v.). +We recommend the issues be considered simultaneously +(or possibly even merged) +to ensure there is no overlap. +Move to Open, and likewise for issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#817">817</a>. +</blockquote> <p><b>Proposed resolution:</b></p> <p> -Change 20.1.1 [utility.arg.requirements]: +Add a new sentence to the end of paragraphs 2 and 4 of 20.7.12.1.3 [func.bind.bind]: </p> <blockquote> +<p> +-2- <i>Returns:</i> A forwarding call wrapper <tt>g</tt> with a weak result type (20.6.2). The effect of <tt>g(u1, u2, +..., uM)</tt> shall be <tt><i>INVOKE</i>(f, v1, v2, ..., vN, Callable<F cv,V1, V2, ..., VN>::result_type)</tt>, where <i>cv</i> +represents the <i>cv</i>-qualifiers of <tt>g</tt> and the values and types of the bound arguments +<tt>v1, v2, ..., vN</tt> are determined as specified below. +<ins>The copy constructor and move constructor of the forwarding call wrapper shall throw an +exception if and only if the corresponding constructor of <tt>F</tt> or any of the types +in <tt>BoundArgs...</tt> throw an exception.</ins> +</p> +<p>...</p> +<p> +-4- <i>Returns:</i> A forwarding call wrapper <tt>g</tt> with a nested type <tt>result_type</tt> defined as a synonym +for <tt>R</tt>. The effect of <tt>g(u1, u2, ..., uM)</tt> shall be <tt><i>INVOKE</i>(f, v1, v2, ..., vN, R)</tt>, where the +values and types of the bound arguments <tt>v1, v2, ..., vN</tt> are determined as specified below. +<ins>The copy constructor and move constructor of the forwarding call wrapper shall throw an +exception if and only if the corresponding constructor of <tt>F</tt> or any of the types +in <tt>BoundArgs...</tt> throw an exception.</ins> +</p> + +</blockquote> + + + + +<hr> +<h3><a name="817"></a>817. <tt>bind</tt> needs to be moved</h3> +<p><b>Section:</b> 20.7.12.1.3 [func.bind.bind] <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>Opened:</b> 2008-03-17 <b>Last modified:</b> 2009-05-23</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#Open">Open</a> status.</p> +<p><b>Discussion:</b></p> +<p><b>Addresses US 72, JP 38 and DE 21</b></p> + +<p> +The functor returned 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> --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>. +This issue is related to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#816">816</a>. </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: +US 72: </p> -<ul> + +<blockquote> +<tt>bind</tt> should support move-only functors and bound arguments. +</blockquote> + +<p> +JP 38: +</p> + +<blockquote> +<p> +add the move requirement for bind's return type. +</p> +<p> +For example, assume following <tt>th1</tt> and <tt>th2</tt>, +</p> + +<blockquote><pre>void f(vector<int> v) { } + +vector<int> v{ ... }; +thread th1([v]{ f(v); }); +thread th2(bind(f, v)); +</pre></blockquote> + +<p> +When function object are set to thread, <tt>v</tt> is moved to <tt>th1</tt>'s lambda +expression in a Move Constructor of lambda expression because <tt>th1</tt>'s lambda +expression has a Move Constructor. But <tt>bind</tt> of <tt>th2</tt>'s +return type doesn't have the requirement of Move, so it may not +moved but copied. +</p> +<p> +Add the requirement of move to get rid of this useless copy. +</p> +<p> +And also, add the <tt>MoveConstructible</tt> as well as <tt>CopyConstructible</tt>. +</p> +</blockquote> + +<p> +DE 21 +</p> + +<blockquote> +The specification for bind claims twice that "the values and types for +the bound arguments v1, v2, ..., vN are determined as specified below". +No such specification appears to exist. +</blockquote> + +<p><i>[ +San Francisco: +]</i></p> + + +<blockquote> +Howard to provide wording. +</blockquote> + +<p><i>[ +Post Summit Alisdair and Howard provided wording. +]</i></p> + + +<blockquote> +<p> +Several issues are being combined in this resolution. They are all touching the +same words so this is an attempt to keep one issue from stepping on another, and +a place to see the complete solution in one place. +</p> + +<ol> <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>); +<tt>bind</tt> needs to be "moved". </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. +20.7.12.1.3 [func.bind.bind]/p3, p6 and p7 were accidently removed from N2798. </li> +<li> +Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#929">929</a> argues for a way to pass by && for +efficiency but retain the decaying behavior of pass by value for the +<tt>thread</tt> constructor. That same solution is applicable here. +</li> +</ol> +</blockquote> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +<p> +We were going to recommend moving this issue to Tentatively Ready +until we noticed potential overlap with issue 816 (q.v.). +</p> +<p> +Move to Open, +and recommend both issues be considered together +(and possibly merged). +</p> +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +Change 20.7 [function.objects] p2: +</p> + +<blockquote><pre>template<<del>CopyConstructible</del> <ins>MoveConstructible</ins> Fn, <del>CopyConstructible</del> <ins>MoveConstructible</ins>... Types> + <i>unspecified</i> bind(Fn<ins>&&</ins>, Types<ins>&&</ins>...); +template<Returnable R, <del>CopyConstructible</del> <ins>MoveConstructible</ins> Fn, <del>CopyConstructible</del> <ins>MoveConstructible</ins>... Types> + <i>unspecified</i> bind(Fn<ins>&&</ins>, Types<ins>&&</ins>...); +</pre></blockquote> + +<p> +Change 20.7.12.1.3 [func.bind.bind]: +</p> + +<blockquote><pre>template<<del>CopyConstructible</del> <ins>MoveConstructible</ins> F, <del>CopyConstructible</del> <ins>MoveConstructible</ins>... BoundArgs> + <i>unspecified</i> bind(F<ins>&&</ins> f, BoundArgs<ins>&&</ins>... bound_args); +</pre> + +<blockquote> +<p> +<ins><i>Requires:</i> <i>unspecified</i> return type shall be <tt>MoveConstructible</tt>.</ins> +</p> +<p> +-1- <i>Requires:</i> <tt><i>INVOKE</i>(f, w1, w2, ..., wN)</tt> (20.6.2) shall be a valid expression for some values +<i>w1, w2, ..., wN</i>, where <tt>N == sizeof...(bound_args)</tt>. +</p> +<p> +-2- <i>Returns:</i> A forwarding call wrapper <tt>g</tt> with a weak result type (20.6.2). The effect of <tt>g(u1, u2, +..., uM)</tt> shall be <tt><i>INVOKE</i>(f, v1, v2, ..., vN, Callable<F cv,V1, V2, ..., VN>::result_type)</tt>, where <i>cv</i> +represents the <i>cv</i>-qualifiers of <tt>g</tt> and the values and types of the bound arguments +<tt>v1, v2, ..., vN</tt> are determined as specified below. +</p> +<p><ins> +<i>Throws:</i> Nothing unless the constructor of <tt>F</tt> or of one of the types in the <tt>BoundArgs...</tt> pack expansion +throws an exception. +</ins></p> +</blockquote> + +<pre>template<Returnable R, <del>CopyConstructible</del> <ins>MoveConstructible</ins> F, <del>CopyConstructible</del> <ins>MoveConstructible</ins>... BoundArgs> + <i>unspecified</i> bind(F<ins>&&</ins> f, BoundArgs<ins>&&</ins>... bound_args); +</pre> + +<blockquote> +<p> +<ins><i>Requires:</i> <i>unspecified</i> return type shall be <tt>MoveConstructible</tt>.</ins> +</p> +<p> +-3- <i>Requires:</i> <tt><i>INVOKE</i>(f, w1, w2, ..., wN)</tt> shall be a valid expression for some values <i>w1, w2, ..., +wN</i>, where <tt>N == sizeof...(bound_args)</tt>. +</p> +<p> +-4- <i>Returns:</i> A forwarding call wrapper <tt>g</tt> with a nested type <tt>result_type</tt> defined as a synonym +for <tt>R</tt>. The effect of <tt>g(u1, u2, ..., uM)</tt> shall be <tt><i>INVOKE</i>(f, v1, v2, ..., vN, R)</tt>, where the +values and types of the bound arguments <tt>v1, v2, ..., vN</tt> are determined as specified below. +</p> +<p> +</p><p><ins> +<i>Throws:</i> Nothing unless the constructor of <tt>F</tt> or of one of the types in the <tt>BoundArgs...</tt> pack expansion +throws an exception. +</ins></p> + +</blockquote> + +<p><ins> +Let the values of <i>bound arguments</i> <tt>v1, v2, ..., vN</tt> and +their corresponding types <tt>V1, V2, ..., VN</tt> depend on the type of +the corresponding argument <tt>ti</tt> in <tt>bound_args</tt> in the +call to <tt>bind</tt> and the <i>cv</i>-qualifiers <i>cv</i> of the call +wrapper <tt>g</tt> as follows. Let <tt>Ti</tt> be an alias for the ith +element of the pack expansion <tt>decay<BoundArgs>::type...</tt>, +and let <tt>ti</tt> be an alias for the ith element in the function +parameter pack expansion <tt>bound_args...</tt>: +</ins></p> + +<ul> +<li><ins> +if <tt>ti</tt> is of type <tt>reference_wrapper<T></tt> the argument is +<tt>ti.get()</tt> and its type <tt>Vi</tt> is <tt>T&</tt>; +</ins></li> +<li><ins> +if the value of <tt>std::is_bind_expression<Ti>::value</tt> is <tt>true</tt> the argument is <tt>ti(u1, u2, ..., uM)</tt> and +its type <tt>Vi</tt> is <tt>result_of<Ti cv (U1&, U2&, ..., UM&)>::type</tt>; +</ins></li> +<li><ins> +if the value <tt>j</tt> of <tt>std::is_placeholder<Ti>::value</tt> is not zero the argument is <tt>std::forward<Uj>(uj)</tt> and +its type <tt>Vi</tt> is <tt>Uj&&</tt>; +</ins></li> +<li><ins> +otherwise the value is <tt>ti</tt> and its type <tt>Vi</tt> is <tt>Ti cv &</tt>. +</ins></li> </ul> -</td></tr> -</tbody></table> + </blockquote> @@ -10689,68 +10938,235 @@ semantics described in this table. <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> +<h3><a name="819"></a>819. rethrow_if_nested</h3> +<p><b>Section:</b> 18.8.6 [except.nested] <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>Opened:</b> 2008-03-25 <b>Last modified:</b> 2008-09-17</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#except.nested">active issues</a> in [except.nested].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#except.nested">issues</a> in [except.nested].</p> <p><b>View all 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>: +Looking at the wording I submitted for <tt>rethrow_if_nested</tt>, I don't think I +got it quite right. </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? +The current wording says: </p> + +<blockquote> +<pre>template <class E> void rethrow_if_nested(const E& e); +</pre> +<blockquote> <p> -E.g. +<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> -<blockquote><pre>struct test{ - int x; - test() : x() {} -}; +<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><i>[ +San Francisco: +]</i></p> + + +<blockquote> +Alisdair was volunteered to provide wording. +</blockquote> + + +<p><b>Proposed resolution:</b></p> + + + + + +<hr> +<h3><a name="822"></a>822. Object with explicit copy constructor no longer <tt>CopyConstructible</tt></h3> +<p><b>Section:</b> X [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">Tentatively NAD</a> + <b>Submitter:</b> James Kanze <b>Opened:</b> 2008-04-01 <b>Last modified:</b> 2009-05-23</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#Tentatively%20NAD">Tentatively NAD</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> -Should I expect a conforming compiler to - <tt>assert( has_nothrow_constructor<test>::value )</tt> +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><i>[ +San Francisco: +]</i></p> + + +<blockquote> +The subgroup that looked at this felt this was a good change, but it may +already be handled by incoming concepts (we're not sure). +</blockquote> + +<b> +Original Proposed resolution: +</b> + <p> -Is this a QoI issue? +In X [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> -Should I expect to 'know' only if-and-only-if there is an inline definition -available? +In X [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> + +<p><i>[ +Post Summit: +]</i></p> + + +<blockquote> <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? +Alisdair: Proposed resolution kinda funky as these tables no longer +exist. Move from direct init to copy init. Clarify with Doug, recommends +NAD. </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. +Walter: Suggest NAD via introduction of concepts. </p> <p> -(agreement since is that trivial ops and explicit no-throws are required. -Open if QoI should be allowed to detect further) +Recommend close as NAD. +</p> +</blockquote> + + + +<p><b>Proposed resolution:</b></p> +<p> +Recommend close as NAD. +</p> + + + + + +<hr> +<h3><a name="825"></a>825. Missing rvalues reference stream insert/extract operators?</h3> +<p><b>Section:</b> 19.5.2.2 [syserr.errcode.overview], 20.8.13.2.8 +[util.smartptr.shared.io], 22.4.8 [facets.examples], 20.3.6.3 +[bitset.operators], 26.4.6 [complex.ops], 27.6 [stream.buffers], 28.10 +[re.submatch] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Tentatively NAD Editorial</a> + <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-04-10 <b>Last modified:</b> 2009-05-23</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD%20Editorial">Tentatively NAD Editorial</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.5.2.2 [syserr.errcode.overview]</li> +<li>20.8.13.2.8 [util.smartptr.shared.io]</li> +<li>22.4.8 [facets.examples]</li> +<li>20.3.6.3 [bitset.operators]</li> +<li>26.4.6 [complex.ops]</li> +<li>Doubled signatures in 27.6 [stream.buffers] for character inserters +(ref 27.7.2.6.4 [ostream.inserters.character]) ++ definition 27.7.2.6.4 [ostream.inserters.character]</li> +<li>28.10 [re.submatch]</li> +</ul> + <p><i>[ -Bellevue: +Sophia Antipolis ]</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. +Agree with the idea in the issue, Alisdair to provide wording. +</blockquote> + +<p><i>[ +Daniel adds 2009-02-14: +]</i></p> + + +<blockquote> +The proposal given in the paper +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2831.html">N2831</a> +apparently resolves this issue. +</blockquote> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +<p> +The cited paper is an earlier version of +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2844.html">N2844</a>, +which changed the rvalue reference binding rules. +That paper includes generic templates +<tt>operator<<</tt> and <tt>operator>></tt> +that adapt rvalue streams. +</p> +<p> +We therefore agree with Daniel's observation. +Move to NAD Editorial. +</p> </blockquote> @@ -10763,27 +11179,67 @@ Move to OPEN. Need to talk to Core about this. <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> +<h3><a name="827"></a>827. <tt>constexpr shared_ptr::shared_ptr()?</tt></h3> +<p><b>Section:</b> 20.8.13.2.1 [util.smartptr.shared.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>Opened:</b> 2008-04-11 <b>Last modified:</b> 2009-05-30</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#util.smartptr.shared.const">active issues</a> in [util.smartptr.shared.const].</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#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>? +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><i>[ -Bellevue: +San Francisco: ]</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. +<p> +It's not clear to us that you can initialize a pointer with the literal +0 in a constant expression. We need to ask CWG to make sure this works. +Bjarne has been appointed to do this. +</p> +<p> +Core got back to us and assured as that <tt>nullptr</tt> would do the job +nicely here. +</p> +</blockquote> + +<p><i>[ +2009-05-01 Alisdair adds: +]</i></p> + + +<blockquote> +<p> +I don't believe that constexpr will buy anything in this case. +<tt>shared_ptr/weak_ptr/enable_shared_from_this</tt> cannot be literal types as they +have a non-trivial copy constructor. As they do not produce literal types, +then the constexpr default constructor will <em>not</em> guarantee constant +initialization, and so not buy the hoped for optimization. +</p> +<p> +I recommend referring this back to Core to see if we can get static +initialization for types with constexpr constructors, even if they are not +literal types. Otherwise this should be closed as NAD. +</p> +</blockquote> + +<p><i>[ +2009-05-26 Daniel adds: +]</i></p> + + +<blockquote> +If Alisdair's 2009-05-01 comment is correct, wouldn't that also make +<tt>constexpr mutex()</tt> useless, because this class has a non-trivial +destructor? (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#828">828</a>) + </blockquote> @@ -10796,103 +11252,216 @@ These two issues should move to OPEN pending AM paper on type traits. <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> +<h3><a name="828"></a>828. Static initialization for <tt>std::mutex</tt>?</h3> +<p><b>Section:</b> 30.4.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>Opened:</b> 2008-04-18 <b>Last modified:</b> 2009-05-30</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.mutex.class">active issues</a> in [thread.mutex.class].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.mutex.class">issues</a> in [thread.mutex.class].</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> -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? +[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>[ -post Bellevue: +Sophia Antipolis: ]</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. +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> -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. +If ubiquitous implementability cannot be assured, plan B is to introduce +another constructor, make this constexpr, which is +conditionally-supported. To avoid ambiguities, this new constructor needs +to have an additional parameter. </p> +</blockquote> + +<p><i>[ +Post Summit: +]</i></p> + + +<blockquote> <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. +Jens: constant initialization seems to be ok core-language wise </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. +Consensus: Defer to threading experts, in particular a Microsoft platform expert. </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. +Lawrence to send e-mail to Herb Sutter, Jonathan Caves, Anthony Wiliams, +Paul McKenney, Martin Tasker, Hans Boehm, Bill Plauger, Pete Becker, +Peter Dimov to alert them of this issue. +</p> +<p> +Lawrence: What about header file shared with C? The initialization +syntax is different in C and C++. </p> +<p> +Recommend Keep in Review +</p> +</blockquote> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +Keep in Review status pending feedback from members of the Concurrency subgroup. </blockquote> +<p><i>[ +See related comments from Alisdiar and Daniel in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#827">827</a>. +]</i></p> + + <p><b>Proposed resolution:</b></p> <p> +Change 30.4.1.1 [thread.mutex.class]: </p> +<blockquote><pre>class mutex { +public: + <ins>constexpr</ins> mutex(); + ... +</pre></blockquote> + <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> +<h3><a name="830"></a>830. Incomplete list of char_traits specializations</h3> +<p><b>Section:</b> 21.2 [char.traits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Tentatively NAD Editorial</a> + <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 2008-04-23 <b>Last modified:</b> 2009-05-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#Tentatively%20NAD%20Editorial">Tentatively NAD Editorial</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."? + Paragraph 4 of 21.2 [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.3 [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> -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? +Idea of the issue is ok. </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. +Alisdair to provide wording, once that wording arrives, move to review. +</p> + +</blockquote> + +<p><i>[ +2009-05-04 Alisdair adds: +]</i></p> + + +<blockquote> +<p> +The main point of the issue was resolved editorially in +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>, +so we are +close to NAD Editorial. +However, exploring the issue we found a second tweak was necessary for +<tt><iosfwd></tt> and that is still outstanding, so here are the words I am long +overdue delivering: +</p> + +<p><i>[ +Howard: I've put Alisdair's words into the proposed wording section and +moved the issue to Review. +]</i></p> + + +</blockquote> + +<p><i>[ +Original proposed wording. +]</i></p> + + +<blockquote> + +<p> + Replace paragraph 4 of 21.2 [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> +</blockquote> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +We agree. Move to NAD Editorial. +</blockquote> <p><b>Proposed resolution:</b></p> <p> -Change 20.1.2 [allocator.requirements]/2: +Change Forward declarations 27.3 [iostream.forward]: </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. +<b>Header <tt><iosfwd></tt> synopsis</b> </p> +<pre>namespace std { + template<class charT> class char_traits; + template<> class char_traits<char>; + <ins>template<> class char_traits<char16_t>;</ins> + <ins>template<> class char_traits<char32_t>;</ins> + template<> class char_traits<wchar_t>; +... +} +</pre> </blockquote> @@ -10900,378 +11469,1798 @@ requirements on allocator types. <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> +<h3><a name="833"></a>833. Freestanding implementations header list needs review for C++0x</h3> +<p><b>Section:</b> 17.6.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>Opened:</b> 2008-05-14 <b>Last modified:</b> 2009-03-11</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#compliance">active issues</a> in [compliance].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#compliance">issues</a> in [compliance].</p> <p><b>View all 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. +Once the C++0x standard library is feature complete, the LWG needs to +review 17.6.1.3 [compliance] Freestanding implementations header list to +ensure it reflects LWG consensus. </p> +<p><i>[ +San Francisco: +]</i></p> + + +<blockquote> +<p> +This is a placeholder defect to remind us to review the table once we've +stopped adding headers to the library. +</p> +<p> +Three new headers that need to be added to the list: +</p> +<blockquote><pre><initializer_list> <concept> <iterator_concepts> +</pre></blockquote> <p> -<tt>MoveConstructible</tt> requirements are defined in Table 33 in 20.1.1 [utility.arg.requirements] as -follows: +<tt><iterator_concepts></tt>, in particular, has lots of stuff +that isn't needed, so maybe the stuff that is needed should be broken +out into a separate header. </p> +<p> +Robert: What about <tt>reference_closure</tt>? It's currently in +<tt><functional></tt>. +</p> +</blockquote> + +<p><i>[ +Post Summit Daniel adds: +]</i></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> +<ol> +<li> +The comment regarding <tt>reference_closure</tt> seems moot since it was just +recently decided to remove that. +</li> +<li> +A reference to proposal +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2814.pdf">N2814</a> +("Fixing freestanding") should be added. This +paper e.g. proposes to add only <tt><initializer_list></tt> to the include list +of freestanding. +</li> +</ol> </blockquote> + + +<p><b>Proposed resolution:</b></p> + + + + + +<hr> +<h3><a name="834"></a>834. Unique_ptr::pointer requirements underspecified</h3> +<p><b>Section:</b> 20.8.12.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>Opened:</b> 2008-05-14 <b>Last modified:</b> 2008-06-19</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unique.ptr.single">active issues</a> in [unique.ptr.single].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr.single">issues</a> in [unique.ptr.single].</p> +<p><b>View all 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-defects.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> -(where <tt>rv</tt> is a non-const rvalue of type <tt>T</tt>). +<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-defects.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> -So I assume the move constructor is the constructor that would be used -in filling the above requirement. +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> -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 +Add the following sentence just at the end of the newly proposed +20.8.12.2 [unique.ptr.single]/p. 3: </p> <blockquote> -<i>Requires:</i> If <tt>value_type</tt> has a move constructor, that constructor shall -not throw any exceptions. +<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.5.4.2 [basic.ios.members] <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>Opened:</b> 2008-05-17 <b>Last modified:</b> 2009-05-30</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#Review">Review</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><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +We agree with the proposed resolution. +Move to Review. </blockquote> +<p><i>[ +2009-05-26 Daniel adds: +]</i></p> + + +<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! +I think that the most recently suggested change in +27.7.2.4 [ostream::sentry] need some further word-smithing. As +written, it would make the behavior undefined, if under +conditions when <tt>pubsync()</tt> should be called, but when +in this scenario <tt>os.rdbuf()</tt> returns 0. +</p> +<p> +This case is explicitly handled in <tt>flush()</tt> and needs to be +taken care of. My suggested fix is: </p> +<blockquote> +If <tt>((os.flags() & ios_base::unitbuf) && !uncaught_exception()</tt> +<ins><tt>&& os.rdbuf() != 0</tt></ins>) is true, calls <del><tt>os.flush()</tt></del> +<ins><tt>os.rdbuf()->pubsync()</tt></ins>. +</blockquote> + <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,". +Two secondary questions are: </p> +<ol> +<li> +Should <tt>pubsync()</tt> be invoked in any case or shouldn't a +base requirement for this trial be that <tt>os.good() == true</tt> +as required in the original <tt>flush()</tt> case? +</li> +<li> +Since <tt>uncaught_exception()</tt> is explicitly tested, shouldn't +a return value of -1 of <tt>pubsync()</tt> produce <tt>setstate(badbit)</tt> +(which may throw <tt>ios_base::failure</tt>)? +</li> +</ol> +</blockquote> + + + +<p><b>Proposed resolution:</b></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. + +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.5.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.7.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.4.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> Martin Sebor <b>Opened:</b> 2008-05-17 <b>Last modified:</b> 2008-09-22</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>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#670">670</a></p> +<p><b>Discussion:</b></p> + + <p> + +In paragraph 2, 22.4.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><i>[ +San Francisco: +]</i></p> + + +<blockquote> +Martin will revise the proposed resolution. +</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.4.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.5.4.2 [basic.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Tentatively NAD Editorial</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2008-05-17 <b>Last modified:</b> 2009-05-23</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#Tentatively%20NAD%20Editorial">Tentatively NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> + <p> + +The <code>basic_ios::copyfmt()</code> member function is specified in 27.5.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><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +We agree with the proposed resolution. +Move to NAD Editorial. +</blockquote> + <p><b>Proposed resolution:</b></p> <p> -Add new defintions to 17.1 [definitions]: + +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.6.1 [istream.iterator] <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>Opened:</b> 2008-05-17 <b>Last modified:</b> 2008-10-27</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#Open">Open</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.6.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#788">788</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><i>[ +San Francisco: +]</i></p> + + +<blockquote> +<p> +We like the direction of the proposed resolution. We're not sure about +the wording, and we need more time to reflect on it, +</p> +<p> +Move to Open. Detlef to rewrite the proposed resolution in such a way +that no reference is made to exposition only members of +<tt>istream_iterator</tt>. +</p> +</blockquote> + + + <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.6.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.4 [associative], 23.5 [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>Opened:</b> 2008-05-18 <b>Last modified:</b> 2008-09-22</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative">active issues</a> in [associative].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative">issues</a> in [associative].</p> +<p><b>View all 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> -<b>move constructor</b> +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> -a constructor which accepts only rvalue arguments of that type, and modifies the rvalue as a -side effect during the construction. +Jens: <tt>absorb</tt>? </p> <p> -<b>move assignment operator</b> +Alan: <tt>subsume</tt>? </p> <p> -an assignment operator which accepts only rvalue arguments of that type, and modifies the rvalue as a -side effect during the assignment. +Robert: <tt>recycle</tt>? </p> <p> -<b>move assignment</b> +Howard: <tt>transfer</tt>? (but no direction) </p> <p> -use of the move assignment operator. +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><i>[ -Howard adds post-Bellevue: +San Francisco: ]</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. :-) +Martin: this would possibly outlaw an implementation technique that is +currently in use; caching nodes in containers. +</p> +<p> +Alan: if you cache in the allocator, rather than the individual +container, this proposal doesn't interfere with that. +</p> +<p> +Martin: I'm not opposed to this, but I'd like to see an implementation +that demonstrates that it works. </p> </blockquote> +<p><b>Proposed resolution:</b></p> + + <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> +<h3><a name="847"></a>847. string exception safety guarantees</h3> +<p><b>Section:</b> 21.4.1 [string.require] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> + <b>Submitter:</b> Hervé Brönnimann <b>Opened:</b> 2008-06-05 <b>Last modified:</b> 2009-02-14</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#string.require">active issues</a> in [string.require].</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#Open">Open</a> status.</p> <p><b>Discussion:</b></p> <p> -Consider the following program: +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.4 [basic.string], para 3: </p> -<blockquote><pre>int main() { - shared_ptr<int> p(nullptr); - return 0; -} -</pre></blockquote> +<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> -This program will fail to compile because <tt>shared_ptr</tt> uses the following -template constructor to construct itself from pointers: +However, the chapter 23 only says, on the topic of exceptions: 23.2 [container.requirements], +para 10: </p> -<blockquote><pre>template <class Y> shared_ptr(Y *); -</pre></blockquote> +<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.2 [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> -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>. +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> -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. +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.2 [container.requirements], para 1 +applies here). </p> <p><i>[ -Bellevue: +San Francisco: ]</i></p> <blockquote> +Implementors will study this to confirm that it is actually possible. +</blockquote> + +<p><i>[ +Daniel adds 2009-02-14: +]</i></p> + + +<blockquote> +The proposed resolution of paper +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2815.html">N2815</a> +interacts with this issue (the paper does not refer to this issue). +</blockquote> + + + +<p><b>Proposed resolution:</b></p> <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.) +Add a blanket statement in 21.4.1 [string.require]: </p> + +<blockquote> <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. +- if any member function or operator of <tt>basic_string<charT, traits, Allocator></tt> +throws, that function or operator has no effect. </p> <p> -Peter suggests definition of empty should be "does not own anything" +- no <tt>erase()</tt> or <tt>pop_back()</tt> function throws. </p> +</blockquote> + <p> -Is there an editorial issue that post-conditions should refer to get() = -nullptr, rather than get() = 0? +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="851"></a>851. simplified array construction</h3> +<p><b>Section:</b> 23.3.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> Benjamin Kosnik <b>Opened:</b> 2008-06-05 <b>Last modified:</b> 2009-06-10</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> -No strong feeling towards accept or NAD, but prefer to make a decision than leave it open. +This is an issue that came up on the libstdc++ list, where a +discrepancy between "C" arrays and C++0x's <tt>std::array</tt> was pointed +out. </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 +In "C," this array usage is possible: </p> + +<blockquote><pre>int ar[] = {1, 4, 6}; +</pre></blockquote> + <p> -Move to Ready, modulo editorial comments +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><i>[ +San Francisco: +]</i></p> + + +<blockquote> +<p> +Benjamin: Move to Ready? +</p> +<p> +Bjarne: I'm not convinced this is useful enough to add, so I'd like us +to have time to reflect on it. +</p> +<p> +Alisdair: the constraints are wrong, they should be +</p> +<blockquote><pre>template<ValueType T, ValueType... Args> +requires Convertible<Args, T>... +array<T, sizeof...(Args)> make_array(Args&&... args); +</pre></blockquote> +<p> +Alidair: this would be useful if we had a constexpr version. +</p> +<p> +Bjarne: this is probably useful for arrays with a small number of +elements, but it's not clearly useful otherwise. +</p> +<p> +Consensus is to move to Open. </p> </blockquote> <p><i>[ -post Bellevue Peter adds: +2009-06-07 Daniel adds: ]</i></p> <blockquote> <p> -The following wording changes are less intrusive: +I suggest a fix and a simplification of the current proposal: Recent +prototyping by +Howard showed, that a fix is required because narrowing conversion +8.5.4 [dcl.init.list]/6 b.3 +would severely limit the possible distribution of argument types, e.g. +the expression +<tt>make_array<double>(1, 2.0)</tt> is ill-formed, because the narrowing +happens <em>inside</em> the +function body where no constant expressions exist anymore. Furthermore +given e.g. </p> +<blockquote><pre>int f(); +double g(); +</pre></blockquote> +<p> +we probably want to support +</p> +<blockquote><pre>make_array<double>(f(), g()); +</pre></blockquote> <p> -In 20.7.12.2.1 [util.smartptr.shared.const], add: +as well. To make this feasible, the currently suggested expansion </p> -<blockquote><pre>shared_ptr(nullptr_t); +<blockquote><pre>{ std::forward<Args>(args)... } </pre></blockquote> <p> -after: +needs to be replaced by </p> -<blockquote><pre>shared_ptr(); +<blockquote><pre>{ static_cast<T>(std::forward<Args>(args))... } </pre></blockquote> <p> -(Absence of explicit intentional.) +which is safe, because we already ensure convertibility via the +element-wise <tt>Convertible<Args, T></tt> requirement. Some other fixes are +necessary: The <tt>ValueType</tt> requirement for the function <em>parameters</em> +is invalid, because all lvalue arguments will deduce to an lvalue-reference, +thereby no longer satisfying this requirement. </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. +The suggested simplification is to provide a default-computed effective +type for the result array based on common_type and decay, in +unconstrained form: </p> + +<blockquote><pre>template<typename... Args> +array<typename decay<typename common_type<Args...>::type>::type, +sizeof...(Args)> +make_array(Args&&... args); +</pre></blockquote> + +<p> +The approach used below is similar to that of <tt>make_pair</tt> and <tt>make_tuple</tt> +using a symbol <tt>C</tt> to represent the decayed common type [Note: Special +handling of <tt>reference_wrapper</tt> types is intentionally <em>not</em> provided, because +our target has so satisfy <tt>ValueType</tt>, thus under the revised proposal only +an all-<tt>reference_wrapper</tt>-arguments would be well-formed and an array of +<tt>reference_wrapper</tt> will be constructed]. I do currently not suggest to +add new concepts reflecting <tt>decay</tt> and <tt>common_type</tt>, but an implementor will +need something like this to succeed. Note that we use a similar fuzziness for +<tt>make_pair</tt> and <tt>make_tuple</tt> currently. This fuzziness is not related to +the currently +missing <tt>Constructible<Vi, Ti&&></tt> requirement for those functions. The following +proposal fixes that miss for <tt>make_array</tt>. If the corresponding <tt>C</tt> type +deduction is +explicitly wanted for standardization, here the implementation +</p> + +<blockquote><pre>auto concept DC<typename... T> { + typename type = typename decay<typename common_type<T...>::type>::type; +} +</pre></blockquote> + <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: +where <tt>C</tt> is identical to <tt>DC<Args...>::type</tt> in the proposed resolution below. </p> <p> -Add +I intentionally added no further type relation between type and the concept +template parameters, but instead added this requirement below to make +the specification as transparent as possible. As written this concept is +satisfied, if the corresponding associated type exists. </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); +<p><b>Suggested Resolution:</b></p> + +<ol> +<li> +<p> +Add to the array synopsis in 23.3 [sequences]: +</p> +<blockquote><pre><ins> +template<ReferentType... Args> +requires ValueType<C> && Constructible<C, Args&&>... +array<C, sizeof...(Args)> +make_array(Args&&... args); +</ins> </pre></blockquote> +</li> +<li> <p> -after +Append after 23.3.1.7 [array.tuple] Tuple interface to class template array +the following new section: +</p> +<blockquote> +<p> +23.4.1.7 Array creation functions [array.creation] </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><ins> +template<ReferentType... Args> +requires ValueType<C> && Constructible<C, Args&&>... +array<C, sizeof...(Args)> +make_array(Args&&... args);</ins> +</pre> + +<blockquote> +<p><ins> +Let <tt>C</tt> be <tt>decay<common_type<Args...>::type>::type</tt>. +</ins></p> +<p> +<ins><i>Returns:</i> an <tt>array<C, sizeof...(Args)></tt> initialized with +<tt>{ static_cast<C>(std::forward<Args>(args))... }</tt>. +</ins></p> +</blockquote> +</blockquote> + +</li> + +</ol> + +</blockquote> + + + +<p><b>Proposed resolution:</b></p> +<p> +Add to the <tt>array</tt> synopsis in 23.3 [sequences]: +</p> + +<blockquote><pre>template<ValueType T, ValueType... Args> + requires Convertible<Args, T>... + array<T, sizeof...(Args)> + make_array(Args&&... args); </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>. +Append after 23.3.1.7 [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<ValueType T, ValueType... Args> + requires Convertible<Args, T>... + array<T, sizeof...(Args)> + make_array(Args&&... args); +</pre> + +<blockquote> <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. +<i>Returns:</i> an <tt>array<T, sizeof...(Args)></tt> initialized with <tt>{std::forward<T>(args)...}</tt>. </p> +</blockquote> +</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> 20.3.6 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2008-06-18 <b>Last modified:</b> 2009-05-10</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#template.bitset">active issues</a> in [template.bitset].</p> +<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#Tentatively%20Ready">Tentatively Ready</a> status.</p> +<p><b>Discussion:</b></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. +Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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><i>[ +post San Francisco: +]</i></p> + + +<blockquote> +Daniel found problems with the wording and provided fixes. Moved from Ready +to Review. </blockquote> <p><i>[ -Sophia Antipolis: +Post Summit: +]</i></p> + + +<blockquote> +<p> +Alisdair: suggest to not repeat the default arguments in B, C, D +(definition of to_string members) +</p> +<p> +Walter: This is not really a definition. +</p> +<p> +Consensus: Add note to the editor: Please apply editor's judgement +whether default arguments should be repeated for B, C, D changes. +</p> +<p> +Recommend Tentatively Ready. +</p> +</blockquote> + +<p><i>[ +2009-05-09: See alternative solution in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1113">1113</a>. +]</i></p> + + + + +<p><b>Proposed resolution:</b></p> +<ol type="A"> +<li> +<p>replace in 20.3.6 [template.bitset]/1 (class <tt>bitset</tt>) +</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> +</li> +<li> +<p> +replace in 20.3.6.2 [bitset.members]/37 +</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; +</pre> +<blockquote> +37 <i>Returns:</i> <tt>to_string<charT, traits, allocator<charT> >(<ins>zero, one</ins>)</tt>. +</blockquote> +</blockquote> +</li> +<li> +<p> +replace in 20.3.6.2 [bitset.members]/38 +</p> + +<blockquote><pre>template <class charT> + basic_string<charT, char_traits<charT>, allocator<charT> > + to_string(<ins>charT zero = charT('0'), charT one = charT('1')</ins>) const; +</pre> +<blockquote> +38 <i>Returns:</i> <tt>to_string<charT, char_traits<charT>, allocator<charT> >(<ins>zero, one</ins>)</tt>. +</blockquote> +</blockquote> +</li> + +<li> +<p> +replace in 20.3.6.2 [bitset.members]/39 +</p> + +<blockquote><pre>basic_string<char, char_traits<char>, allocator<char> > + to_string(<ins>char zero = '0', char one = '1'</ins>) const; +</pre> +<blockquote> +39 <i>Returns:</i> <tt>to_string<char, char_traits<char>, allocator<char> >(<ins>zero, one</ins>)</tt>. +</blockquote> +</blockquote> +</li> + +</ol> + + + + + + +<hr> +<h3><a name="854"></a>854. <tt>default_delete</tt> converting constructor underspecified</h3> +<p><b>Section:</b> 20.8.12.1.1 [unique.ptr.dltr.dflt] <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>Opened:</b> 2008-06-18 <b>Last modified:</b> 2009-05-23</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> +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><i>[ +Howard adds 2008-11-26: +]</i></p> + + +<blockquote> +<p> +I believe we need to be careful to not outlaw the following use case, and +I believe the current proposed wording +(<tt>requires Convertible<U*, T*> && HasVirtualDestructor<T></tt>) does so: +</p> + +<blockquote><pre>#include <memory> + +int main() +{ + std::unique_ptr<int> p1(new int(1)); + std::unique_ptr<const int> p2(move(p1)); + int i = *p2; +<font color="#c80000">// *p2 = i; // should not compile</font> +} +</pre></blockquote> + +<p> +I've removed "<tt>&& HasVirtualDestructor<T></tt>" from the +<tt>requires</tt> clause in the proposed wording. +</p> + +</blockquote> + +<p><i>[ +Post Summit: ]</i></p> <blockquote> <p> -We want to remove the reset functions from the proposed resolution. +Alisdair: This issue has to stay in review pending a paper constraining +<tt>unique_ptr</tt>. </p> <p> -The remaining proposed resolution text (addressing the constructors) are wanted. +Consensus: We agree with the resolution, but <tt>unique_ptr</tt> needs +to be constrained, too. </p> <p> -Disposition: move to review. The review should check the wording in the then-current working draft. +Recommend Keep in Review. </p> </blockquote> +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +Keep in Review status for the reasons cited. +</blockquote> <p><b>Proposed resolution:</b></p> <p> -Add the following constructors to 20.7.12.2 [util.smartptr.shared]: +Change 20.8.12.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*></ins> + default_delete(const default_delete<U>&); + void operator()(T*) const; + }; +} +</pre></blockquote> + +<p> +... </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); +<blockquote><pre>template <class U> + <ins>requires Convertible<U*, T*></ins> + default_delete(const default_delete<U>& other); </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.5.1 [thread.condition.condvar] <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>Opened:</b> 2008-06-13 <b>Last modified:</b> 2009-06-14</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.condition.condvar">active issues</a> in [thread.condition.condvar].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.condition.condvar">issues</a> in [thread.condition.condvar].</p> +<p><b>View all 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 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> -Add the following constructor definitions to 20.7.12.2.1 [util.smartptr.shared.const]: +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><i>[ +San Francisco: +]</i></p> + <blockquote> -<pre> explicit shared_ptr(nullptr_t); +<p> +There is concern that the enumeration names are just as confusing, if +not more so, as the bool. You might have awoken because of a signal or a +spurious wakeup, for example. +</p> +<p> +Group feels that this is a defect that needs fixing. +</p> +<p> +Group prefers returning an enum over a void return. +</p> +<p> +Howard to provide wording. +</p> +</blockquote> + +<p><i>[ +2009-06-14 Beman provided wording. +]</i></p> + + + +<p><b>Proposed resolution:</b></p> +<p> +Change Condition variables 30.5 [thread.condition], Header +condition_variable synopsis, as indicated: +</p> + +<blockquote><pre>namespace std { + class condition_variable; + class condition_variable_any; + + <ins>enum class cv_status { no_timeout, timeout };</ins> +} +</pre></blockquote> + +<p> +Change Class condition_variable 30.5.1 [thread.condition.condvar] as indicated: +</p> + +<blockquote><pre>class condition_variable { +public: + ... + template <class Clock, class Duration> + <del>bool</del> <ins>cv_status</ins> wait_until(unique_lock<mutex>& lock, + const chrono::time_point<Clock, Duration>& abs_time); + template <class Clock, class Duration, class Predicate> + bool wait_until(unique_lock<mutex>& lock, + const chrono::time_point<Clock, Duration>& abs_time, + Predicate pred); + + template <class Rep, class Period> + <del>bool</del> <ins>cv_status</ins> wait_for(unique_lock<mutex>& lock, + const chrono::duration<Rep, Period>& rel_time); + template <class Rep, class Period, class Predicate> + bool wait_for(unique_lock<mutex>& lock, + const chrono::duration<Rep, Period>& rel_time, + Predicate pred); + ... +}; + +... + +template <class Clock, class Duration> + <del>bool</del> <ins>cv_status</ins> wait_until(unique_lock<mutex>& lock, + const chrono::time_point<Clock, Duration>& abs_time); </pre> <blockquote> <p> -<i>Effects:</i> Constructs an empty shared_ptr object. +-15- <i>Precondition:</i> <tt>lock</tt> is locked by the calling thread, and either </p> +<ul> +<li> +no other thread is waiting on this <tt>condition_variable</tt> object or +</li> +<li> +<tt>lock.mutex()</tt> returns the same value for each of the <tt>lock</tt> +arguments supplied by all concurrently waiting threads (via <tt>wait</tt>, +<tt>wait_for</tt> or <tt>wait_until</tt>.). +</li> +</ul> + <p> -<i>Postconditions:</i> <tt>use_count() == 0 && get() == 0</tt>. +-16- <i>Effects:</i> </p> + +<ul> +<li> +Atomically calls <tt>lock.unlock()</tt> and blocks on <tt>*this</tt>. +</li> +<li> +When unblocked, calls <tt>lock.lock()</tt> (possibly blocking on the lock) and returns. +</li> +<li> +The function will unblock when signaled by a call to <tt>notify_one()</tt>, +a call to <tt>notify_all()</tt>, <del>by +the current time exceeding <tt>abs_time</tt></del> <ins>if <tt>Clock::now() >= abs_time</tt></ins>, +or spuriously. +</li> +<li> +If the function exits via an exception, <tt>lock.unlock()</tt> shall be called prior +to exiting the function scope. +</li> +</ul> + <p> -<i>Throws:</i> nothing. +-17- <i>Postcondition:</i> <tt>lock</tt> is locked by the calling thread. </p> + +<p> +-18- <i>Returns:</i> <del><tt>Clock::now() < abs_time</tt></del> +<ins><tt>cv_status::timeout</tt> if the function unblocked because <tt>abs_time</tt> +was reached, otherwise <tt>cv_status::no_timeout</tt></ins>. +</p> + +<p> +-19- <i>Throws:</i> <tt>std::system_error</tt> when the effects or postcondition +cannot be achieved. +</p> + +<p> +-20- <i>Error conditions:</i> +</p> + +<ul> +<li> +<tt>operation_not_permitted</tt> — if the thread does not own the lock. +</li> +<li> +equivalent error condition from <tt>lock.lock()</tt> or <tt>lock.unlock()</tt>. +</li> +</ul> </blockquote> + +<pre>template <class Rep, class Period> + <del>bool</del> <ins>cv_status</ins> wait_for(unique_lock<mutex>& lock, + const chrono::duration<Rep, Period>& rel_time); + +</pre> +<blockquote> +<p> +-21- <i><del>Effects</del> <ins>Returns</ins>:</i> +</p> +<blockquote><pre>wait_until(lock, chrono::monotonic_clock::now() + rel_time) +</pre></blockquote> +<p> +<del>-22- <i>Returns:</i> <tt>false</tt> if the call is returning because the time +duration specified by <tt>rel_time</tt> has elapsed, +otherwise <tt>true</tt>.</del> +</p> + +<p><i>[ +This part of the wording may conflict with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#859">859</a> in detail, but does +not do so in spirit. If both issues are accepted, there is a logical merge. +]</i></p> + </blockquote> +<pre>template <class Clock, class Duration, class Predicate> + bool wait_until(unique_lock<mutex>& lock, + const chrono::time_point<Clock, Duration>& abs_time, + Predicate pred); +</pre> + <blockquote> -<pre>template <class D> shared_ptr(nullptr_t, D d); -template <class D, class A> shared_ptr<nullptr_t, D d, A a); +<p> +-23- <i>Effects:</i> +</p> +<blockquote><pre>while (!pred()) + if (<del>!</del>wait_until(lock, abs_time) <ins>== cv_status::timeout</ins>) + return pred(); +return true; +</pre></blockquote> + +<p> +-24- <i>Returns:</i> <tt>pred()</tt>. +</p> + +<p> +-25- [<i>Note:</i> +The returned value indicates whether the predicate evaluates to +<tt>true</tt> regardless of whether the timeout was triggered. +— <i>end note</i>]. +</p> +</blockquote> +</blockquote> + +<p> +Change Class condition_variable_any 30.5.2 [thread.condition.condvarany] as indicated: +</p> + +<blockquote><pre>class condition_variable_any { +public: + ... + template <class Lock, class Clock, class Duration> + <del>bool</del> <ins>cv_status</ins> wait_until(Lock& lock, + const chrono::time_point<Clock, Duration>& abs_time); + template <class Lock, class Clock, class Duration, class Predicate> + bool wait_until(Lock& lock, + const chrono::time_point<Clock, Duration>& abs_time, + Predicate pred); + + template <class Lock, class Rep, class Period> + <del>bool</del> <ins>cv_status</ins> wait_for(Lock& lock, + const chrono::duration<Rep, Period>& rel_time); + template <class Lock, class Rep, class Period, class Predicate> + bool wait_for(Lock& lock, + const chrono::duration<Rep, Period>& rel_time, + Predicate pred); + ... +}; + +... + +template <class Lock, class Clock, class Duration> + <del>bool</del> <ins>cv_status</ins> wait_until(Lock& lock, + const chrono::time_point<Clock, Duration>& abs_time); </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. +-13- <i>Effects:</i> </p> + +<ul> +<li> +Atomically calls <tt>lock.unlock()</tt> and blocks on <tt>*this</tt>. +</li> +<li> +When unblocked, calls <tt>lock.lock()</tt> (possibly blocking on the lock) and returns. +</li> +<li> +The function will unblock when signaled by a call to <tt>notify_one()</tt>, +a call to <tt>notify_all()</tt>, <del>by +the current time exceeding <tt>abs_time</tt></del> <ins>if <tt>Clock::now() >= abs_time</tt></ins>, +or spuriously. +</li> +<li> +If the function exits via an exception, <tt>lock.unlock()</tt> shall be called prior +to exiting the function scope. +</li> +</ul> + <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. +-14- <i>Postcondition:</i> <tt>lock</tt> is locked by the calling thread. </p> + <p> -<i>Postconditions:</i> <tt>use_count() == 1</tt> and <tt>get() == 0</tt>. +-15- <i>Returns:</i> <del><tt>Clock::now() < abs_time</tt></del> +<ins><tt>cv_status::timeout</tt> if the function unblocked because <tt>abs_time</tt> +was reached, otherwise <tt>cv_status::no_timeout</tt></ins>. </p> + <p> -<i>Throws:</i> <tt>bad_alloc</tt>, or an implementation-defined exception when a -resource other than memory could not be obtained. +-16- <i>Throws:</i> <tt>std::system_error</tt> when the effects or postcondition +cannot be achieved. </p> + <p> -<i>Exception safety:</i> If an exception is thrown, <tt>d(static_cast<Y *>(nullptr))</tt> is called. +-17- <i>Error conditions:</i> </p> + +<ul> +<li> +equivalent error condition from <tt>lock.lock()</tt> or <tt>lock.unlock()</tt>. +</li> +</ul> </blockquote> + +<pre>template <class Lock, class Rep, class Period> + <del>bool</del> <ins>cv_status</ins> wait_for(Lock& lock, + const chrono::duration<Rep, Period>& rel_time); + +</pre> + +<blockquote> +<p> +-18- <i><del>Effects</del> <ins>Returns</ins>:</i> +</p> +<blockquote><pre>wait_until(lock, chrono::monotonic_clock::now() + rel_time) +</pre></blockquote> + +<p> +<del>-19- <i>Returns:</i> <tt>false</tt> if the call is returning because the time +duration specified by <tt>rel_time</tt> has elapsed, +otherwise <tt>true</tt>.</del> +</p> + +<p><i>[ +This part of the wording may conflict with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#859">859</a> in detail, but does +not do so in spirit. If both issues are accepted, there is a logical merge. +]</i></p> + + </blockquote> +<pre>template <class Lock, class Clock, class Duration, class Predicate> + bool wait_until(Lock& lock, + const chrono::time_point<Clock, Duration>& <del>rel_time</del> <ins>abs_time</ins>, + Predicate pred); +</pre> + +<blockquote> +<p> +-20- <i>Effects:</i> +</p> +<blockquote><pre>while (!pred()) + if (<del>!</del>wait_until(lock, abs_time) <ins>== cv_status::timeout</ins>) + return pred(); +return true; +</pre></blockquote> + +<p> +-21- <i>Returns:</i> <tt>pred()</tt>. +</p> +<p> +-22- [<i>Note:</i> +The returned value indicates whether the predicate evaluates to +<tt>true</tt> regardless of whether the timeout was triggered. +— <i>end note</i>]. +</p> +</blockquote> + +</blockquote> @@ -11279,64 +13268,429 @@ resource other than memory could not be obtained. <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> +<h3><a name="859"></a>859. Monotonic Clock is Conditionally Supported?</h3> +<p><b>Section:</b> 30.5 [thread.condition] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> + <b>Submitter:</b> Pete Becker <b>Opened:</b> 2008-06-23 <b>Last modified:</b> 2009-06-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>Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#958">958</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#959">959</a>.</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 +<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><i>[ -Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a> +San Francisco: ]</i></p> +<blockquote> +<p> +Nick: maybe instead of saying that chrono::monotonic_clock is +conditionally supported, we could say that it's always there, but not +necessarily supported.. +</p> +<p> +Beman: I'd prefer a typedef that identifies the best clock to use for +wait_for locks. +</p> +<p> +Tom: combine the two concepts; create a duration clock type, but keep +the is_monotonic test. +</p> +<p> +Howard: if we create a duration_clock type, is it a typedef or an +entirely true type? +</p> +<p> +There was broad preference for a typedef. +</p> +<p> +Move to Open. Howard to provide wording to add a typedef for +duration_clock and to replace all uses of monotonic_clock in function +calls and signatures with duration_clock. +</p> +</blockquote> + <p><i>[ -Bellevue: +Howard notes post-San Francisco: ]</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? +After further thought I do not believe that creating a <tt>duration_clock typedef</tt> +is the best way to proceed. An implementation may not need to use a +<tt>time_point</tt> to implement the <tt>wait_for</tt> functions. </p> + <p> -Resolution: Alan Talbot to rework language, then set state to Review. +For example, on POSIX systems <tt>sleep_for</tt> can be implemented in terms of +<tt>nanosleep</tt> which takes only a duration in terms of nanoseconds. The current +working paper does not describe <tt>sleep_for</tt> in terms of <tt>sleep_until</tt>. +And paragraph 2 of 30.2.4 [thread.req.timing] has the words strongly encouraging +implementations to use monotonic clocks for <tt>sleep_for</tt>: +</p> + +<blockquote> +2 The member functions whose names end in <tt>_for</tt> take an argument that +specifies a relative time. Implementations should use a monotonic clock to +measure time for these functions. +</blockquote> + +<p> +I believe the approach taken in describing the effects of <tt>sleep_for</tt> +and <tt>try_lock_for</tt> is also appropriate for <tt>wait_for</tt>. I.e. these +are not described in terms of their <tt>_until</tt> variants. </p> + </blockquote> <p><b>Proposed resolution:</b></p> <p> -Add after 23.1 [container.requirements]/12: +Change 30.5.1 [thread.condition.condvar], p21-22: </p> <blockquote> +<pre>template <class Rep, class Period> + bool wait_for(unique_lock<mutex>& lock, + const chrono::duration<Rep, Period>& rel_time); +</pre> +<blockquote> +<p><ins> +<i>Precondition:</i> <tt>lock</tt> is locked by the calling thread, and either +</ins></p> +<ul> +<li><ins>no other thread is waiting on this <tt>condition_variable</tt> object or</ins></li> +<li><ins><tt>lock.mutex()</tt> returns the same value for each of the <tt>lock</tt> +arguments supplied by all concurrently waiting threads (via <tt>wait</tt>, +<tt>wait_for</tt> or <tt>wait_until</tt>).</ins></li> +</ul> <p> --12- Objects passed to member functions of a container as rvalue references shall not be elements of that container. No -diagnostic required. +21 <i>Effects:</i> </p> +<blockquote><pre><del>wait_until(lock, chrono::monotonic_clock::now() + rel_time)</del> +</pre></blockquote> +<ul> +<li><ins> +Atomically calls <tt>lock.unlock()</tt> and blocks on <tt>*this</tt>. +</ins></li> + +<li><ins> +When unblocked, calls <tt>lock.lock()</tt> (possibly blocking on the lock) and returns. +</ins></li> + +<li><ins> +The function will unblock when signaled by a call to <tt>notify_one()</tt>, a call +to <tt>notify_all()</tt>, by +the elapsed time <tt>rel_time</tt> passing (30.2.4 [thread.req.timing]), +or spuriously. +</ins></li> + +<li><ins> +If the function exits via an exception, <tt>lock.unlock()</tt> shall be called +prior to exiting the function scope. +</ins></li> +</ul> + +<p><ins> +<i>Postcondition:</i> <tt>lock</tt> is locked by the calling thread. +</ins></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> +22 <i>Returns:</i> <tt>false</tt> if the call is returning because the time +duration specified by <tt>rel_time</tt> has elapsed, otherwise <tt>true</tt>. +</p> + +<p><i>[ +This part of the wording may conflict with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#857">857</a> in detail, but does +not do so in spirit. If both issues are accepted, there is a logical merge. +]</i></p> + + +<p><ins> +<i>Throws:</i> <tt>std::system_error</tt> when the effects or postcondition cannot be achieved. +</ins></p> + +<p><ins> +<i>Error conditions:</i> +</ins></p> + +<ul> +<li><ins> +<tt>operation_not_permitted</tt> -- if the thread does not own the lock. +</ins></li> +<li><ins> +equivalent error condition from <tt>lock.lock()</tt> or <tt>lock.unlock()</tt>. +</ins></li> +</ul> + +</blockquote> +</blockquote> + +<p> +Change 30.5.1 [thread.condition.condvar], p26-p29: +</p> + +<blockquote> +<pre>template <class Rep, class Period, class Predicate> + bool wait_for(unique_lock<mutex>& lock, + const chrono::duration<Rep, Period>& rel_time, + Predicate pred); +</pre> +<blockquote> +<p><ins> +<i>Precondition:</i> <tt>lock</tt> is locked by the calling thread, and either +</ins></p> +<ul> +<li><ins>no other thread is waiting on this <tt>condition_variable</tt> object or</ins></li> +<li><ins><tt>lock.mutex()</tt> returns the same value for each of the <tt>lock</tt> +arguments supplied by all concurrently waiting threads (via <tt>wait</tt>, +<tt>wait_for</tt> or <tt>wait_until</tt>).</ins></li> +</ul> +<p> +<i>26 Effects:</i> +</p> +<blockquote><pre><del>wait_until(lock, chrono::monotonic_clock::now() + rel_time, std::move(pred))</del> +</pre> +<ul> +<li><ins> +Executes a loop: Within the loop the function first evaluates <tt>pred()</tt> +and exits the loop if the result of <tt>pred()</tt> is <tt>true</tt>. +</ins></li> +<li><ins> +Atomically calls <tt>lock.unlock()</tt> +and blocks on <tt>*this</tt>. +</ins></li> +<li><ins> +When unblocked, calls <tt>lock.lock()</tt> (possibly blocking on the lock). +</ins></li> +<li><ins> +The function will unblock when signaled by a call to <tt>notify_one()</tt>, a +call to <tt>notify_all()</tt>, by the elapsed time <tt>rel_time</tt> passing (30.1.4 +[thread.req.timing]), or spuriously. +</ins></li> +<li><ins> +If the function exits via an exception, <tt>lock.unlock()</tt> shall be called +prior to exiting the function scope. +</ins></li> +<li><ins> +The loop terminates when <tt>pred()</tt> returns <tt>true</tt> or when the time +duration specified by <tt>rel_time</tt> has elapsed. +</ins></li> +</ul> +</blockquote> + +<p> +27 [<i>Note:</i> There is no blocking if <tt>pred()</tt> is initially <tt>true</tt>, +even if the timeout has already expired. <i>-- end note</i>] +</p> + +<p><ins> +<i>Postcondition:</i> <tt>lock</tt> is locked by the calling thread. +</ins></p> + +<p> +28 <i>Returns:</i> <tt>pred()</tt> +</p> + +<p> +29 [<i>Note:</i> The returned value indicates whether the predicate evaluates to +<tt>true</tt> regardless of whether the timeout was triggered. <i>-- end note</i>] +</p> + +<p><ins> +<i>Throws:</i> <tt>std::system_error</tt> when the effects or postcondition cannot be achieved. +</ins></p> + +<p><ins> +<i>Error conditions:</i> +</ins></p> + +<ul> +<li><ins> +<tt>operation_not_permitted</tt> -- if the thread does not own the lock. +</ins></li> +<li><ins> +equivalent error condition from <tt>lock.lock()</tt> or <tt>lock.unlock()</tt>. +</ins></li> +</ul> + +</blockquote> +</blockquote> + +<p> +Change 30.5.2 [thread.condition.condvarany], p18-19: +</p> + +<blockquote> +<pre>template <class Lock, class Rep, class Period> + bool wait_for(Lock& lock, const chrono::duration<Rep, Period>& rel_time); +</pre> +<blockquote> +<p> +18 <i>Effects:</i> </p> +<blockquote><pre><del>wait_until(lock, chrono::monotonic_clock::now() + rel_time)</del> +</pre></blockquote> + +<ul> +<li><ins> +Atomically calls <tt>lock.unlock()</tt> and blocks on <tt>*this</tt>. +</ins></li> + +<li><ins> +When unblocked, calls <tt>lock.lock()</tt> (possibly blocking on the lock) and returns. +</ins></li> + +<li><ins> +The function will unblock when signaled by a call to <tt>notify_one()</tt>, a call to +<tt>notify_all()</tt>, by +the elapsed time <tt>rel_time</tt> passing (30.2.4 [thread.req.timing]), +or spuriously. +</ins></li> + +<li><ins> +If the function exits via an exception, <tt>lock.unlock()</tt> shall be called +prior to exiting the function scope. +</ins></li> +</ul> + +<p><ins> +<i>Postcondition:</i> <tt>lock</tt> is locked by the calling thread. +</ins></p> + +<p> +19 <i>Returns:</i> <tt>false</tt> if the call is returning because the time duration +specified by <tt>rel_time</tt> has elapsed, otherwise <tt>true</tt>. +</p> + +<p><ins> +<i>Throws:</i> <tt>std::system_error</tt> when the returned value, effects, +or postcondition cannot be achieved. +</ins></p> + +<p><ins> +<i>Error conditions:</i> +</ins></p> + +<ul> +<li><ins> +equivalent error condition from <tt>lock.lock()</tt> or <tt>lock.unlock()</tt>. +</ins></li> +</ul> +</blockquote> +</blockquote> + +<p> +Change 30.5.2 [thread.condition.condvarany], p23-p26: +</p> + +<blockquote> +<pre>template <class Lock, class Rep, class Period, class Predicate> + bool wait_for(Lock& lock, const chrono::duration<Rep, Period>& rel_time, Predicate pred); +</pre> +<blockquote> +<p><ins> +<i>Precondition:</i> <tt>lock</tt> is locked by the calling thread, and either +</ins></p> +<ul> +<li><ins>no other thread is waiting on this <tt>condition_variable</tt> object or</ins></li> +<li><ins><tt>lock.mutex()</tt> returns the same value for each of the <tt>lock</tt> +arguments supplied by all concurrently waiting threads (via <tt>wait</tt>, +<tt>wait_for</tt> or <tt>wait_until</tt>).</ins></li> +</ul> +<p> +<i>23 Effects:</i> +</p> +<blockquote><pre><del>wait_until(lock, chrono::monotonic_clock::now() + rel_time, std::move(pred))</del> +</pre> +<ul> +<li><ins> +Executes a loop: Within the loop the function first evaluates <tt>pred()</tt> +and exits the loop if the result of <tt>pred()</tt> is <tt>true</tt>. +</ins></li> +<li><ins> +Atomically calls <tt>lock.unlock()</tt> +and blocks on <tt>*this</tt>. +</ins></li> +<li><ins> +When unblocked, calls <tt>lock.lock()</tt> (possibly blocking on the lock). +</ins></li> +<li><ins> +The function will unblock when signaled by a call to <tt>notify_one()</tt>, a +call to <tt>notify_all()</tt>, by the elapsed time <tt>rel_time</tt> passing (30.1.4 +[thread.req.timing]), or spuriously. +</ins></li> +<li><ins> +If the function exits via an exception, <tt>lock.unlock()</tt> shall be called +prior to exiting the function scope. +</ins></li> +<li><ins> +The loop terminates when <tt>pred()</tt> returns <tt>true</tt> or when the time +duration specified by <tt>rel_time</tt> has elapsed. +</ins></li> +</ul> +</blockquote> + +<p> +24 [<i>Note:</i> There is no blocking if <tt>pred()</tt> is initially <tt>true</tt>, +even if the timeout has already expired. <i>-- end note</i>] +</p> + +<p><ins> +<i>Postcondition:</i> <tt>lock</tt> is locked by the calling thread. +</ins></p> + +<p> +25 <i>Returns:</i> <tt>pred()</tt> +</p> + +<p> +26 [<i>Note:</i> The returned value indicates whether the predicate evaluates to +<tt>true</tt> regardless of whether the timeout was triggered. <i>-- end note</i>] +</p> + +<p><ins> +<i>Throws:</i> <tt>std::system_error</tt> when the effects or postcondition cannot be achieved. +</ins></p> +<p><ins> +<i>Error conditions:</i> +</ins></p> + +<ul> +<li><ins> +<tt>operation_not_permitted</tt> -- if the thread does not own the lock. +</ins></li> +<li><ins> +equivalent error condition from <tt>lock.lock()</tt> or <tt>lock.unlock()</tt>. +</ins></li> +</ul> + +</blockquote> </blockquote> @@ -11344,305 +13698,1405 @@ sub-objects of elements of the container. No diagnostic required. + <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> +<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#Open">Open</a> + <b>Submitter:</b> Lawrence Crowl <b>Opened:</b> 2008-06-23 <b>Last modified:</b> 2009-03-09</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#numerics">active issues</a> in [numerics].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#numerics">issues</a> in [numerics].</p> +<p><b>View all 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 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>. +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><i>[ -Bellevue: +San Francisco: ]</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. +<p> +Nick: I think we already say that these functions do not introduce data +races; see 17.6.5.6/20 +</p> +<p> +Pete: there's more to it than not introducing data races; are these +states maintained per thread? +</p> +<p> +Howard: 21.5/14 says that strtok and strerror are not required to avoid +data races, and 20.9/2 says the same about asctime, gmtime, ctime, and +gmtime. +</p> +<p> +Nick: POSIX has a list of not-safe functions. All other functions are +implicitly thread safe. +</p> +<p> +Lawrence is to form a group between meetings to attack this issue. Nick +and Tom volunteered to work with Lawrence. +</p> +<p> +Move to Open. +</p> </blockquote> +<p><i>[ +Post Summit: +]</i></p> + -<p><b>Proposed resolution:</b></p> +<blockquote> <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>. +Hans: Sane oses seem ok. Sensible thing is implementable and makes sense. </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> +Nick: Default wording seems to cover this? Hole in POSIX, these +functions need to be added to list of thread-unsafe functions. </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>. +Lawrence: Not sufficient, not "thread-safe" per our definition, but +think of state as a thread-local variable. Need something like "these +functions only affect state in the current thread." </p> +<p> +Hans: Suggest the following wording: "The floating point environment is +maintained per-thread." +</p> +<p> +Walter: Any other examples of state being thread safe that are not +already covered elsewhere? +</p> +<p> +Have thread unsafe functions paper which needs to be updated. Should +just fold in 26.3 [cfenv] functions. +</p> +<p> +Recommend Open. Lawrence instead suggests leaving it open until we have +suitable wording that may or may not include the thread local +commentary. +</p> +</blockquote> -<ol> -<li> + +<p><b>Proposed resolution:</b></p> <p> -In 20.7.11 [unique.ptr]/2 add as the last sentence to the existing para: +</p> + + + + + +<hr> +<h3><a name="861"></a>861. Incomplete specification of EqualityComparable for std::forward_list</h3> +<p><b>Section:</b> 23.2 [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> Daniel Krügler <b>Opened:</b> 2008-06-24 <b>Last modified:</b> 2008-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> +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> -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> ] +<tt>==</tt> is an equivalence relation. <tt>a.size() == b.size() && +equal(a.begin(), a.end(), b.begin()</tt> </blockquote> -</li> +<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> -20.7.11.2.1 [unique.ptr.single.ctor]/1: No changes necessary. +Both proposal choices are discussed, the preferred choice of the author is +to apply (A). </p> +<p><i>[ +San Francisco: +]</i></p> + + <blockquote> +<p> +There's an Option C: change the requirements table to use distance(). +</p> +<p> +LWG found Option C acceptable. +</p> +<p> +Martin will draft the wording for Option C. +</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. +post San Francisco: ]</i></p> + +<blockquote> +Martin provided wording for Option C. </blockquote> -</li> + + +<p><b>Proposed resolution:</b></p> +<p> +Common part: +</p> +<ul> <li> <p> -In 20.7.11.2.1 [unique.ptr.single.ctor]/5 change the requires clause to say: +Just betwen 23.3.3.5 [forwardlist.ops] and 23.3.3.6 [forwardlist.spec] +add a new +section "forwardlist comparison operators" [forwardlist.compare] (and +also add the +new section number to 23.3.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> -<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> +Add to the new section [forwardlist.compare] the following paragraphs: </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> +<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> -Merge 20.7.11.2.1 [unique.ptr.single.ctor]/12+13 thereby removing the sentence -of 12, but transferring the "requires" to 13: +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> + +<p> +Option (C): +</p> <blockquote> +<ul> +<li> <p> -<i>Requires:</i> If <tt>D</tt> is not an lvalue-reference type then[..] +Change Table 91 - Container Requirements in 23.2.1 [container.requirements.general] +(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdf">N2798</a>) like so: </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> +<ol> +<li> +<p> +Change the text in the <b>Operational Semantics</b> column in + the row for <tt>a == b</tt> as follows: +</p> +<blockquote> +<tt>==</tt> is an equivalence relation. + <tt><ins>distance(a.begin(), a.end())</ins> + <del>a.size()</del> == + <ins>distance(b.begin(), b.end())</ins> <del>b.size()</del> && + equal(a.begin(), a.end(), b.begin())</tt> +</blockquote> +</li> + +<li> +<p> +Change the text in the <b>Operational Semantics</b> column in + the row for <tt>a.max_size()</tt> as follows: +</p> +<blockquote> +<tt><ins>distance(a.begin(), a.end())</ins> + <del>a.size()</del></tt> of the largest possible container </blockquote> </li> <li> -20.7.11.2.1 [unique.ptr.single.ctor]/17: No changes necessary. +<p> +Change the text in the <b>Operational Semantics</b> column in + the row for <tt>a.empty()</tt> as follows: +</p> +<blockquote> +<tt><ins>a.begin() == a.end()</ins> + <del>a.size() == 0</del></tt> +</blockquote> </li> + <li> -<p>20.7.11.2.1 [unique.ptr.single.ctor]/21:</p> +<p> +In addition, for consistency, change the text in the + <b>Operational Semantics</b> column in the row for <tt>a.size()</tt> + as follows: +</p> +<blockquote> +<tt><ins>distance(a.begin(), a.end())</ins> + <del>a.end() - a.begin()</del></tt> +</blockquote> +</li> +</ol> +</li> +</ul> +</blockquote> + + + + + +<hr> +<h3><a name="862"></a>862. Impossible complexity for 'includes'</h3> +<p><b>Section:</b> 25.5.5.1 [includes] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Tentatively NAD Editorial</a> + <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-07-02 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#includes">active issues</a> in [includes].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#includes">issues</a> in [includes].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD%20Editorial">Tentatively NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<p> +In 25.5.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><i>[ +2009-03-30 Beman adds: +]</i></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> +Suggest NAD. The complexity of empty ranges is -1 in other places in the +standard. See 25.5.4 [alg.merge] <tt>merge</tt> and +<tt>inplace_merge</tt>, and <tt>forward_list</tt> merge, for example. +The time and effort to find and fix all places in the standard where +empty range[s] result in negative complexity isn't worth the very +limited benefit. </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." +2009-05-09 Alisdair adds: ]</i></p> -</li> -<li> +<blockquote> <p> -20.7.11.2.2 [unique.ptr.single.dtor]: Just before p1 add a new paragraph: +I'm not happy with NAD if we can find a simple solution. </p> +<p> +How about adding a rider somewhere in clause 17 suggesting that complexities +that specify a negative number of operations are treated as specifying zero +operations? That should generically solve the issue without looking for +further cases. +</p> +</blockquote> + +<p><i>[ +Batavia (2009-05): +]</i></p> + <blockquote> +Pete to provide "straightforward" wording. +Move to NAD Editorial. +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +Recommend NAD. +</p> + + + + + +<hr> +<h3><a name="863"></a>863. What is the state of a stream after close() succeeds</h3> +<p><b>Section:</b> 27.9.1 [fstreams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">Tentatively NAD</a> + <b>Submitter:</b> Steve Clamage <b>Opened:</b> 2008-07-08 <b>Last modified:</b> 2009-05-23</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#Tentatively%20NAD">Tentatively NAD</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> -<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> +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><i>[ -N.B.: This requirement ensures that the whole responsibility on -type-completeness of <tt>T</tt> is delegated to this expression. +Batavia (2009-05): ]</i></p> +<blockquote> +<p> +Tom's impression is that the issue is about the <tt>failbit</tt>, etc. +</p> +<p> +Bill responds that the stream is now closed, +and any status bits remain unchanged. +</p> +<p> +See the description of <tt>close()</tt> in 27.9.1.17 [fstream.members]. +</p> +<p> +We prefer not to add wording to say that nothing changes. +Move to NAD. +</p> </blockquote> -</li> + +<p><b>Proposed resolution:</b></p> +<p> +</p> + + + + + +<hr> +<h3><a name="865"></a>865. More algorithms that throw away information</h3> +<p><b>Section:</b> 25.4.6 [alg.fill], 25.4.7 [alg.generate] <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>Opened:</b> 2008-07-13 <b>Last modified:</b> 2009-05-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> +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> -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. +In both cases the minimum requirements on the iterator are +<tt>OutputIterator</tt>, which means according to the requirements of +24.2.3 [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><i>[ -N.B. The current wording is sufficient, because we can delegate all -further requirements on the requirements of the effects clause +Post Summit Daniel "conceptualized" the wording. ]</i></p> -</li> +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +<p> +Alisdair likes the idea, but has concerns about the specific wording +about the returns clauses. +</p> +<p> +Alan notes this is a feature request. +</p> +<p> +Bill notes we have made similar changes to other algorithms. +</p> +<p> +Move to Open. +</p> +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<ol> <li> <p> -20.7.11.2.3 [unique.ptr.single.asgn]/6: +Replace the current declaration of <tt>fill_n</tt> in 25 [algorithms]/2, header +<tt><algorithm></tt> synopsis and in 25.4.6 [alg.fill] by </p> +<blockquote><pre>template<class Iter, IntegralLike Size, class T> + requires OutputIterator<Iter, const T&> + <del>void</del><ins>Iter</ins> fill_n(Iter first, Size n, const T& value); +</pre></blockquote> + +<p> +Just after the effects clause p.1 add a new returns clause saying: +</p> +<blockquote> +<i>Returns:</i> For <tt>fill_n</tt> and <tt>n > Size(0)</tt>, returns <tt>first + n</tt>. Otherwise +returns <tt>first</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.4.7 [alg.generate] by +</p> +<blockquote><pre>template<class Iter, IntegralLike Size, Callable Generator> + requires OutputIterator<Iter, Generator::result_type> + && CopyConstructible<Generator> + <del>void</del><ins>Iter</ins> generate_n(Iter first, Size n, Generator gen); +</pre></blockquote> +<p> +Just after the effects clause p.1 add a new returns clause saying: +</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> +<i>Returns:</i> For <tt>generate_n</tt> and <tt>n > Size(0)</tt>, returns <tt>first + n</tt>. +Otherwise returns <tt>first</tt> for <tt>generate_n</tt>. </blockquote> +</li> +</ol> + + + + + +<hr> +<h3><a name="867"></a>867. Valarray and value-initialization</h3> +<p><b>Section:</b> 26.6.2.1 [valarray.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Tentatively NAD Editorial</a> + <b>Submitter:</b> Alberto Ganesh Barbati <b>Opened:</b> 2008-07-20 <b>Last modified:</b> 2009-05-23</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#Tentatively%20NAD%20Editorial">Tentatively NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<p> +From 26.6.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><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). +Batavia (2009-05): ]</i></p> -</li> +<blockquote> +We agree with the proposed resolution. +Move to NAD Editorial. +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +Change 26.6.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> -<li> <p> -20.7.11.2.3 [unique.ptr.single.asgn]/11: No changes necessary. +Change 26.6.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#Open">Open</a> + <b>Submitter:</b> Alberto Ganesh Barbati <b>Opened:</b> 2008-07-22 <b>Last modified:</b> 2008-09-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#Open">Open</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-closed.html#724">724</a>. +</p> + <p><i>[ -N.B.: Delegation to requirements of effects clause is sufficient. +San Francisco: ]</i></p> -</li> -<li> -20.7.11.2.4 [unique.ptr.single.observers]/1+4+7+9+11: -</li> +<blockquote> +<p> +The list provided in the proposed resolution is not complete. James +Dennett will review the library and provide a complete list and will +double-check the vocabulary. +</p> +<p> +This issue relates to Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#886">886</a> tuple construction +</p> +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +Change X [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.3.2.1 [deque.cons] para 2</li> +<li>23.3.2.2 [deque.capacity] para 1</li> +<li>23.3.3.1 [forwardlist.cons] para 3</li> +<li>23.3.3.4 [forwardlist.modifiers] para 21</li> +<li>23.3.4.1 [list.cons] para 3</li> +<li>23.3.4.2 [list.capacity] para 1</li> +<li>23.3.6.1 [vector.cons] para 3</li> +<li>23.3.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.2.5 [unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> Sohail Somani <b>Opened:</b> 2008-07-22 <b>Last modified:</b> 2009-03-09</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#Tentatively%20Ready">Tentatively Ready</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><i>[ +San Francisco: +]</i></p> + + +<blockquote> +We believe that this is not a substantive change, but the proposed +change to the wording is clearer than what we have now. +</blockquote> + +<p><i>[ +Post Summit: +]</i></p> + <blockquote> -<pre>T* operator->() const;</pre> +Recommend Tentatively Ready. +</blockquote> + + + +<p><b>Proposed resolution:</b></p> +<p> +Change Table 97 "Unordered associative container requirements" in 23.2.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="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#Open">Open</a> + <b>Submitter:</b> Travis Vitek <b>Opened:</b> 2008-06-30 <b>Last modified:</b> 2009-03-21</p> +<p><b>View all 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> + 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><i>[ +San Francisco: +]</i></p> + + <blockquote> -<ins><i>Note:</i> Use typically requires <tt>T</tt> shall be complete. <i>-- end note</i>]</ins> +Plum, Sebor to review. </blockquote> + +<p><i>[ +Post Summit Daniel adds: +]</i></p> + + +<blockquote> +The proposed resolution needs to be "conceptualized". Currently we have +in 14.10.4 [concept.support] only concept <tt>IntegralType</tt> +for all "integral types", thus indeed the current <tt>Container</tt> +concept and Iterator concepts are sufficiently satisfied with "integral +types". If the changes are applied, we might ask core for concept +<tt>BilateralIntegerType</tt> and add proper restrictions to the library +concepts. </blockquote> + + + <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. + X [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.6.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.4.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.4.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.4.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.2 [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.2 [iterator.concepts] 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.5.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. + X [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.5.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.6 [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="876"></a>876. <tt>basic_string</tt> access operations should give stronger guarantees</h3> +<p><b>Section:</b> 21.4 [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> Daniel Krügler <b>Opened:</b> 2008-08-22 <b>Last modified:</b> 2008-09-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> +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> -20.7.11.2.5 [unique.ptr.single.modifiers]/1: No changes necessary. +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> -20.7.11.2.5 [unique.ptr.single.modifiers]/4: Just before p. 4 add a new paragraph: +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><i>[ +San Francisco: +]</i></p> + + +<blockquote> +<p> +We oppose part 1 of the issue but hope to address <tt>size()</tt> in +issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#877">877</a>. +</p> +<p> +We do not support part B. 4 of the issue because of the breaking API change. +</p> +<p> +We support part A. 2 of the issue. +</p> +<p> +On support part A. 3 of the issue: </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. +Pete's broader comment: now that we know that basic_string will be a +block of contiguous memory, we should just rewrite its specification +with that in mind. The expression of the specification will be simpler +and probably more correct as a result. </blockquote> -</li> +</blockquote> + +<p><b>Proposed resolution:</b></p> +<ol type="A"> <li> -20.7.11.2.5 [unique.ptr.single.modifiers]/7: No changes necessary. -</li> +<ol> +<li> +<p>In 21.4.4 [string.capacity], just after p. 1 add a new paragraph: +</p> +<blockquote> +<i>Throws:</i> Nothing. +</blockquote> +</li> <li> <p> -20.7.11.3 [unique.ptr.runtime]: Add one additional bullet on paragraph 1: +In 21.4.5 [string.access] <em>replace</em> p. 1 by the following <em>4</em> paragraghs: </p> <blockquote> <p> -A specialization for array types is provided with a slightly altered interface. +<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> -<ul> -<li> -... </li> <li> -<ins><tt>T</tt> shall be a complete type.</ins> +<p> +In 21.4.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> -</ul> +</ol> +</li> +<li> +<ol start="4"> +<li> +<p> +In 21.4.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> - -<p><i>[ -post Bellevue: Daniel provided revised wording. -]</i></p> - +</li> +</ol> @@ -11650,237 +15104,891 @@ post Bellevue: Daniel provided revised wording. <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> +<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#Open">Open</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2008-08-23 <b>Last modified:</b> 2008-09-18</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</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#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#278">278</a> -defines the meaning of the term "invalid iterator" as one that may be -singular. +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> -Consider the following code: +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> - <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>? +There are also 203 occurrences of "<i>Throws:</i> Nothing." scattered +throughout the spec. </p> <p> -I.e., is the expression below required to evaluate -to <code>true</code>? +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> - <pre> i == y.end() && j == x.end() - </pre> <p> -(There are at least two implementations where the expression -returns <code>false</code>.) +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> -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? +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> -Here's a motivating example intended to demonstrate the importance of -the question: +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> - <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> + <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> -<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>. +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><b>Proposed resolution:</b></p> + </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.3.3 [forwardlist] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2008-08-23 <b>Last modified:</b> 2009-05-10</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</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><i>[ +San Francisco: +]</i></p> + + +<blockquote> +Robert suggested alternate proposed wording which had large support. +</blockquote> + +<p><i>[ +Post Summit: +]</i></p> + + +<blockquote> +<p> +Walter: "position is before_begin() or a dereferenceable": add "is" after the "or" +</p> <p> +With that minor update, Recommend Tentatively Ready. </p> +</blockquote> + +<p><b>Proposed resolution:</b></p> + <p> + +Change the <i>Requires</i> clauses + [forwardlist] , p21, p24, p26, p29, and, +23.3.3.5 [forwardlist.ops], p39, p43, p47 +as follows: + + </p> + <blockquote> + +<i>Requires:</i> <tt>position</tt> is <ins><tt>before_begin()</tt> or is a</ins> +dereferenceable +<ins>iterator in the range <tt>[begin(), end())</tt></ins> +<del>or equal to <tt>before_begin()</tt></del>. ... + + </blockquote> + <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> +<h3><a name="879"></a>879. Atomic load const qualification</h3> +<p><b>Section:</b> 29 [atomics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> + <b>Submitter:</b> Alexander Chemeris <b>Opened:</b> 2008-08-24 <b>Last modified:</b> 2009-03-22</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#atomics">active issues</a> in [atomics].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics">issues</a> in [atomics].</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> -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". +The <tt>atomic_address</tt> type and <tt>atomic<T*></tt> specialization provide atomic +updates to pointers. However, the current specification requires +that the types pointer be to non-const objects. This restriction +is unnecessary and unintended. </p> +<p><i>[ +Summit: +]</i></p> + +<blockquote> +Move to review. Lawrence will first check with Peter whether the +current examples are sufficient, or whether they need to be expanded to +include all cases. +</blockquote> + <p><b>Proposed resolution:</b></p> +<p> +Add const qualification to the pointer values of the <tt>atomic_address</tt> +and <tt>atomic<T*></tt> specializations. E.g. +</p> + +<blockquote><pre>typedef struct atomic_address { + void store(<ins>const</ins> void*, memory_order = memory_order_seq_cst) volatile; + void* exchange( <ins>const</ins> void*, memory_order = memory_order_seq_cst) volatile; + bool compare_exchange( <ins>const</ins> void*&, <ins>const</ins> void*, + memory_order, memory_order) volatile; + bool compare_exchange( <ins>const</ins> void*&, <ins>const</ins> void*, + memory_order = memory_order_seq_cst ) volatile; + void* operator=(<ins>const</ins> void*) volatile; +} atomic_address; + +void atomic_store(volatile atomic_address*, <ins>const</ins> void*); +void atomic_store_explicit(volatile atomic_address*, <ins>const</ins> void*, + memory_order); +void* atomic_exchange(volatile atomic_address*<ins>, const void*</ins>); +void* atomic_exchange_explicit(volatile atomic_address*, <ins>const</ins> void*, + memory_order); +bool atomic_compare_exchange(volatile atomic_address*, + <ins>const</ins> void**, <ins>const</ins> void*); +bool atomic_compare_exchange_explicit(volatile atomic_address*, + <ins>const</ins> void**, <ins>const</ins> void*, + memory_order, memory_order); +</pre></blockquote> + + + + +<hr> +<h3><a name="880"></a>880. Missing atomic exchange parameter</h3> +<p><b>Section:</b> 29 [atomics] <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>Opened:</b> 2008-08-24 <b>Last modified:</b> 2009-03-22</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#atomics">active issues</a> in [atomics].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics">issues</a> in [atomics].</p> +<p><b>View all 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#942">942</a></p> +<p><b>Discussion:</b></p> <p> -In 20.6 [function.objects], header <tt><functional></tt> synopsis replace: +The <tt>atomic_exchange</tt> and <tt>atomic_exchange_explicit</tt> functions seem to +be inconsistently missing parameters. </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><i>[ +Post Summit: +]</i></p> + +<blockquote> <p> -In the class function synopsis of 20.6.15.2 [func.wrap.func] replace +Lawrence: Need to write up a list for Pete with details. </p> +<p> +Detlef: Should not be New, we already talked about in Concurrency group. +</p> +<p> +Recommend Open. +</p> +</blockquote> -<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><b>Proposed resolution:</b></p> <p> -In 20.6.15.2 [func.wrap.func], "Null pointer comparisons" replace: +Add the appropriate parameters. For example, </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...)>&); +<blockquote><pre>bool atomic_exchange(volatile atomic_bool*<ins>, bool</ins>); +bool atomic_exchange_explicit(volatile atomic_bool*, bool<ins>, memory_order</ins>); </pre></blockquote> + + + + +<hr> +<h3><a name="881"></a>881. shared_ptr conversion issue</h3> +<p><b>Section:</b> 20.8.13.2.1 [util.smartptr.shared.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>Opened:</b> 2008-08-30 <b>Last modified:</b> 2008-09-18</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#util.smartptr.shared.const">active issues</a> in [util.smartptr.shared.const].</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#Open">Open</a> status.</p> +<p><b>Discussion:</b></p> <p> -In 20.6.15.2.1 [func.wrap.func.con], replace +We've changed <tt>shared_ptr<Y></tt> to not convert to <tt>shared_ptr<T></tt> when <tt>Y*</tt> +doesn't convert to <tt>T*</tt> by resolving issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>. This only fixed the +converting copy constructor though. +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2351.htm">N2351</a> +later added move support, and +the converting move constructor is not constrained. </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>); +<p><i>[ +San Francisco: +]</i></p> + + +<blockquote> +We might be able to move this to NAD, Editorial once shared_ptr is +conceptualized, but we want to revisit this issue to make sure. +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +We need to change the Requires clause of the move constructor: +</p> + +<blockquote><pre>shared_ptr(shared_ptr&& r); +template<class Y> shared_ptr(shared_ptr<Y>&& r); +</pre> +<blockquote> +<i>Requires:</i> <del>For the second constructor <tt>Y*</tt> shall be +convertible to <tt>T*</tt>.</del> +<ins> +The second constructor shall not participate in overload resolution +unless <tt>Y*</tt> is convertible to <tt>T*</tt>. +</ins> +</blockquote> +</blockquote> + +<p> +in order to actually make the example in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a> compile +(it now resolves to the move constructor). +</p> + + + + + + +<hr> +<h3><a name="883"></a>883. swap circular 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#Open">Open</a> + <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-09-10 <b>Last modified:</b> 2009-03-11</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> +Note in particular that Table 90 "Container Requirements" 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><i>[ +San Francisco: +]</i></p> + + +<blockquote> +Robert to propose a resolution along the lines of "Postcondition: "a = +b, b = a" This will be a little tricky for the hash containers, since +they don't have <tt>operator==</tt>. +</blockquote> + +<p><i>[ +Post Summit Anthony Williams provided proposed wording. +]</i></p> + + + + +<p><b>Proposed resolution:</b></p> +<p> +In table 80 in section 23.2.1 [container.requirements.general], +replace the postcondition of <tt>a.swap(b)</tt> with the following: +</p> + +<blockquote> +<table border="1"> +<caption>Table 80 -- Container requirements</caption> +<tbody><tr> +<th>Expression</th> +<th>Return type</th> +<th>Operational semantics</th> +<th>Assertion/note pre-/post-conidtion</th> +<th>Complexity</th> +</tr> +<tr> +<td>...</td> +<td>...</td> +<td>...</td> +<td>...</td> +<td>...</td> +</tr> +<tr> +<td><tt>a.swap(b);</tt></td> +<td><tt>void</tt></td> +<td> </td> +<td><del><tt>swap(a,b)</tt></del> +<ins>Exchange the contents of <tt>a</tt> and <tt>b</tt> as-if<br> +<tt>X u=std::move(a);<br> +a=std::move(b);<br> +b=std::move(u);</tt></ins></td> +<td>(Note A)</td> +</tr> +</tbody></table> +</blockquote> + +<p> +Remove the reference to swap from the paragraph following the table. +</p> + +<blockquote> +Notes: the algorithms <del><tt>swap()</tt>, </del><tt>equal()</tt> and +<tt>lexicographical_compare()</tt> are defined in Clause 25. ... +</blockquote> + + + + + +<hr> +<h3><a name="884"></a>884. shared_ptr swap</h3> +<p><b>Section:</b> 20.8.13.2.4 [util.smartptr.shared.mod] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Tentatively NAD Editorial</a> + <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2008-09-15 <b>Last modified:</b> 2009-05-23</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD%20Editorial">Tentatively NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<blockquote><pre>#include <memory> +#include <cassert> + +struct A { }; +struct B : A { }; + +int main() +{ + std::shared_ptr<A> pa(new A); + std::shared_ptr<B> pb(new B); + std::swap<A>(pa, pb); // N.B. no argument deduction + assert( pa.get() == pb.get() ); + return 0; +} </pre></blockquote> <p> -In 20.6.15.2.6 [func.wrap.func.nullptr], replace +Is this behaviour correct (I believe it is) and if so, is it +unavoidable, or not worth worrying about? +</p> + +<p> +This calls the lvalue/rvalue swap overload for <tt>shared_ptr</tt>: </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); +<blockquote><pre>template<class T> void swap( shared_ptr<T> & a, shared_ptr<T> && b ); </pre></blockquote> <p> -and replace +silently converting the second argument from <tt>shared_ptr<B></tt> to +<tt>shared_ptr<A></tt> and binding the rvalue ref to the produced temporary. </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); +<p> +This is not, in my opinion, a <tt>shared_ptr</tt> problem; it is a general issue +with the rvalue swap overloads. Do we want to prevent this code from +compiling? If so, how? +</p> + +<p> +Perhaps we should limit rvalue args to swap to those types that would +benefit from the "swap trick". Or, since we now have <tt>shrink_to_fit()</tt>, just +eliminate the rvalue swap overloads altogether. The original motivation +was: +</p> + +<blockquote><pre>vector<A> v = ...; +... +swap(v, vector<A>(v)); </pre></blockquote> +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1690.html#Improved%20swap%20Interface">N1690</a>. + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +We agree with the proposed resolution. +Move to NAD Editorial. +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +Recommend NAD Editorial, fixed by +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2844.html">N2844</a>. +</p> <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> +<h3><a name="885"></a>885. pair assignment</h3> +<p><b>Section:</b> 20.3.3 [pairs] <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>Opened:</b> 2008-09-15 <b>Last modified:</b> 2009-05-25</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#pairs">active issues</a> in [pairs].</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#Open">Open</a> status.</p> <p><b>Discussion:</b></p> +<blockquote><pre>20.2.3 pairs +Missing assignemnt operator: +template<class U , class V> + requires CopyAssignable<T1, U> && CopyAssignable<T2, V> + pair& operator=(pair<U , V> const & p ); +</pre></blockquote> + <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: +Well, that's interesting. This assignment operator isn't in the +current working paper, either. Perhaps we deemed it acceptable to +build a temporary of type <tt>pair</tt> from <tt>pair<U, V></tt>, then move-assign +from that temporary? </p> +<p> +It sounds more like an issue waiting to be opened, unless you want to plug +it now. As written we risk moving from lvalues. +</p> + +<p><i>[ +San Francisco: +]</i></p> + <blockquote> -<i>Throws:</i> nothing +<p> +Would be NAD if better ctors fixed it. +</p> +<p> +Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#811">811</a>. +</p> +</blockquote> + +<p><i>[ +post San Francisco: +]</i></p> + + +<blockquote> +Possibly NAD Editorial, solved by +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2770.pdf">N2770</a>. +</blockquote> + +<p><i>[ +2009-05-25 Alisdair adds: +]</i></p> + + +<blockquote> +Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#885">885</a> was something I reported while reviewing the library concepts +documents ahead of San Francisco. The missing operator was added as part of +the paper adopted at that meeting +(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2770.pdf">N2770</a>) +and I can confirm this operator is +present in the current working paper. I recommend NAD. </blockquote> + + +<p><b>Proposed resolution:</b></p> <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> + + + + +<hr> +<h3><a name="886"></a>886. tuple construction</h3> +<p><b>Section:</b> 20.5.2.1 [tuple.cnstr] <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>Opened:</b> 2008-09-15 <b>Last modified:</b> 2009-05-05</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#tuple.cnstr">active issues</a> in [tuple.cnstr].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple.cnstr">issues</a> in [tuple.cnstr].</p> +<p><b>View all 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> +20.5.2.1 [tuple.cnstr]: +</p> <blockquote> -<i>Throws:</i> Nothing if the string construction throws nothing +<i>Effects:</i> Default initializes each element. </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). +Could be clarified to state each "non-trivial" element. Otherwise +we have a conflict with Core deinfition of default initialization - +trivial types do not get initialized (rather than initialization +having no effect) +</p> + +<p> +I'm going to punt on this one, because it's not an issue that's +related to concepts. I suggest bringing it to Howard's attention on +the reflector. </p> +<p><i>[ +San Francisco: +]</i></p> -<p><b>Proposed resolution:</b></p> +<blockquote> <p> -In 21.4 [string.conversions], remove the paragraphs 8 and 16. +Text in draft doesn't mean anything, changing to "non-trivial" makes it +meaningful. +</p> +<p> +We prefer "value initializes". Present implementations use +value-initialization. Users who don't want value initialization have +alternatives. +</p> +<p> +Request resolution text from Alisdair. </p> +<p> +This issue relates to Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#868">868</a> default construction and value-initialization. +</p> +</blockquote> + +<p><i>[ +2009-05-04 Alisdair provided wording and adds: +]</i></p> + + <blockquote> -<pre>string to_string(long long val); -string to_string(unsigned long long val); -string to_string(long double val); +<p> +Note: This <em>IS</em> a change of semantic from TR1, although one the room agreed +with during the discussion. To preserve TR1 semantics, this would have been +worded: +</p> +<blockquote><pre>requires DefaultConstructible<Types>... tuple(); </pre> <blockquote> -<del><i>Throws:</i> nothing</del> +-2- <i>Effects:</i> Default-initializes each non-trivial element. </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); + +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +Change p2 in Construction 20.5.2.1 [tuple.cnstr]: +</p> + +<blockquote><pre>requires DefaultConstructible<Types>... tuple(); </pre> <blockquote> -<del><i>Throws:</i> nothing</del> +<p> +-2- <i>Effects:</i> <del>Default</del> <ins>Value-</ins>initializes each element. +</p> </blockquote> </blockquote> @@ -11890,160 +15998,291 @@ string to_string(long double val); <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> +<h3><a name="887"></a>887. issue with condition::wait_...</h3> +<p><b>Section:</b> 30.5.1 [thread.condition.condvar] <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>Opened:</b> 2008-09-15 <b>Last modified:</b> 2009-03-09</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.condition.condvar">active issues</a> in [thread.condition.condvar].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.condition.condvar">issues</a> in [thread.condition.condvar].</p> +<p><b>View all 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 return clause 21.4 [string.conversions]/paragraph 15 of the new <tt>to_wstring</tt> -overloads says: +The Posix/C++ working group has identified an inconsistency between +Posix and the C++ working draft in that Posix requires the clock to be +identified at creation, whereas C++ permits identifying the clock at the +call to wait. The latter cannot be implemented with the former. </p> +<p><i>[ +San Francisco: +]</i></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> +Howard recommends NAD with the following explanation: +</p> <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: +The intent of the current wording is for the <tt>condtion_variable::wait_until</tt> +be able to handle user-defined clocks as well as clocks the system knows about. +This can be done by providing overloads for the known clocks, and another +overload for unknown clocks which synchs to a known clock before waiting. +For example: </p> -<blockquote><pre>int swprintf(wchar_t * restrict s, size_t n, -const wchar_t * restrict format, ...); +<blockquote><pre>template <class Duration> +bool +condition_variable::wait_until(unique_lock<mutex>& lock, + const chrono::time_point<chrono::system_clock, Duration>& abs_time) +{ + using namespace chrono; + nanoseconds d = __round_up<nanoseconds>(abs_time.time_since_epoch()); + __do_timed_wait(lock.mutex()->native_handle(), time_point<system_clock, nanoseconds>(d)); + return system_clock::now() < abs_time; +} + +template <class Clock, class Duration> +bool +condition_variable::wait_until(unique_lock<mutex>& lock, + const chrono::time_point<Clock, Duration>& abs_time) +{ + using namespace chrono; + typename Clock::time_point c_entry = Clock::now(); + system_clock::time_point s_entry = system_clock::now(); + nanoseconds dn = __round_up<nanoseconds>(abs_time.time_since_epoch() - + c_entry.time_since_epoch()); + __do_timed_wait(lock.mutex()->native_handle(), s_entry + dn); + return Clock::now() < abs_time; +} </pre></blockquote> <p> -therefore the paragraph needs to mention the <tt>size_t</tt> parameter <tt>n</tt>. +In the above example, <tt>system_clock</tt> is the only clock which the underlying +condition variable knows how to deal with. One overload just passes that clock +through. The second overload (approximately) converts the unknown clock into +a <tt>system_clock time_point</tt> prior to passing it down to the native +condition variable. </p> +<p> +On Posix systems vendors are free to add implementation defined constructors which +take a clock. That clock can be stored in the condition_variable, and converted +to (or not as necessary) as shown above. +</p> - -<p><b>Proposed resolution:</b></p> <p> -Change the current wording of 21.4 [string.conversions]/p. 15 to: +If an implementation defined constructor takes a clock (for example), then part +of the semantics for that implementation defined ctor might include that a +<tt>wait_until</tt> using a clock other than the one constructed with results +in an error (exceptional condition) instead of a conversion to the stored clock. +Such a design is up to the vendor as once an implementation defined ctor is used, +the vendor is free to specifiy the behavior of waits and/or notifies however +he pleases (when the cv is constructed in an implementation defined manner). </p> +</blockquote> + +<p><i>[ +Post Summit: +]</i></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> +"POSIX people will review the proposed NAD resolution at their upcoming NY +meeting. +</p> <p> -[Hint to the editor: The resolution also adds to mention the name of -the format specifier "fmt"] +See the minutes at: <a href="http://wiki.dinkumware.com/twiki/bin/view/Posix/POSIX-CppBindingWorkingGroupNewYork2009">http://wiki.dinkumware.com/twiki/bin/view/Posix/POSIX-CppBindingWorkingGroupNewYork2009</a>. </p> +</blockquote> + +<p><b>Proposed resolution:</b></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> + + + + +<hr> +<h3><a name="888"></a>888. this_thread::yield too strong</h3> +<p><b>Section:</b> 30.3.2 [thread.thread.this] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> Lawrence Crowl <b>Opened:</b> 2008-09-15 <b>Last modified:</b> 2009-03-09</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p> +<p><b>Discussion:</b></p> <p> -Change the current wording of 21.4 [string.conversions]/p. 7 to: +I never thought I'd say this, but <tt>this_thread::yield</tt> seems to be too +strong in specification. The issue is that some systems distinguish +between yielding to another thread in the same process and yielding +to another process. Given that the C++ standard only talks about +a single program, one can infer that the specification allows yielding +only to another thread within the same program. Posix has no +facility for that behavior. Can you please file an issue to weaken +the wording. Perhaps "Offers the operating system the opportunity +to reschedule." </p> +<p><i>[ +Post Summit: +]</i></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>. +Recommend move to Tentatively Ready. </blockquote> +<p><b>Proposed resolution:</b></p> +<p> +Change 30.3.2 [thread.thread.this]/3: +</p> + +<blockquote> +<pre>void this_thread::yield(); +</pre> +<blockquote> +<i>Effects:</i> Offers the <del>operating system</del> <ins>implementation</ins> +the opportunity to <ins>re</ins>schedule. +<del>another thread.</del> +</blockquote> +</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> +<h3><a name="889"></a>889. thread::id comparisons</h3> +<p><b>Section:</b> 30.3.1.1 [thread.thread.id] <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>Opened:</b> 2008-09-15 <b>Last modified:</b> 2009-05-24</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.thread.id">issues</a> in [thread.thread.id].</p> <p><b>View all 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><b>Addresses UK 324</b></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]) +The <tt>thread::id</tt> type supports the full set of comparison operators. This +is substantially more than is required for the associative containers that +justified them. Please place an issue against the threads library. </p> +<p><i>[ +San Francisco: +]</i></p> + + +<blockquote> <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. +Would depend on proposed extension to POSIX, or non-standard extension. +What about hash? POSIX discussing op. POSIX not known to be considering +support needed for hash, op. </p> - <p> -A quick survey of clause 23 shows that the following containers provide a -definition for member-swap: +Group expresses support for putting ids in both unordered and ordered containers. </p> +</blockquote> + +<p><i>[ +post San Francisco: +]</i></p> -<blockquote><pre>array -queue -stack -vector -</pre></blockquote> +<blockquote> <p> -Whereas the following declare it, but do not define the semantics: +Howard: It turns out the current working paper +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a> +<i>already has</i> <tt>hash<thread::id></tt> +(20.7 [function.objects], 20.7.17 [unord.hash]). We simply +overlooked it in the meeting. It is a good thing we voted in favor of it +(again). :-) +</p> +<p> +Recommend NAD. </p> -<blockquote><pre>deque -list -map -multimap -multiset -priority_queue -set -unordered_map -unordered_multi_map -unordered_multi_set -unordered_set -</pre></blockquote> +</blockquote> + +<p><i>[ +Post Summit: +]</i></p> + +<blockquote> +Recommend to close as NAD. For POSIX, see if we need to add a function to +convert <tt>pthread_t</tt> to integer. +</blockquote> + +<p><i>[ +Post Summit, Alisdair adds: +]</i></p> + + +<blockquote> <p> -Suggested resolution: +The recommendation for LWG-889/UK-324 is NAD, already specified. +</p> +<p> +It is not clear to me that the specification is complete. +</p> +<p> +In particular, the synopsis of <tt><functional></tt> in 20.7 [function.objects] does not mention <tt>hash< thread::id +></tt> nor <tt>hash< error_code ></tt>, although their +existence is implied by 20.7.17 [unord.hash], p1. +</p> +<p> +I am fairly uncomfortable putting the declaration for the +<tt>thread_id</tt> specialization into <tt><functional></tt> as +<tt>id</tt> is a nested class inside <tt>std::thread</tt>, so it implies +that <tt><functional></tt> would require the definition of the +<tt>thread</tt> class template in order to forward declared +<tt>thread::id</tt> and form this specialization. +</p> +<p> +It seems better to me that the dependency goes the other way around +(<tt><thread></tt> will more typically make use of +<tt><functional></tt> than vice-versa) and the +<tt>hash<thread::id></tt> specialization be declared in the +<tt><thread></tt> header. +</p> +<p> +I think <tt>hash<error_code></tt> could go into either +<tt><system_error></tt> or <tt><functional></tt> and have no +immediate preference either way. However, it should clearly appear in +the synopsis of one of these two. +</p> +<p> +Recommend moving 889 back to open, and tying in a reference to UK-324. </p> -<blockquote> -Provide a definition for each of the affected containers... </blockquote> <p><i>[ -Bellevue: +Batavia (2009-05): ]</i></p> +<blockquote> +Howard observes that <tt>thread::id</tt> need not be a nested class; +it could be a <tt>typedef</tt> for a more visible type. +</blockquote> + +<p><i>[ +2009-05-24 Alisdair adds: +]</i></p> <blockquote> -Move to Open and ask Alisdair to provide wording. +I do not believe this is correct. <tt>thread::id</tt> is explicitly documents as a +nested class, rather than as an unspecified typedef analogous to an +iterator. If the intent is that this is not implemented as a nested class +(under the as-if freedoms) then this is a novel form of standardese. </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>. +Move to NAD. </p> @@ -12051,321 +16290,1066 @@ Wording provided in <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> +<h3><a name="890"></a>890. Improving <tt><system_error></tt> initialization</h3> +<p><b>Section:</b> 19.5.1 [syserr.errcat] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2008-09-14 <b>Last modified:</b> 2009-03-09</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively 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 +The <tt>static const error_category</tt> objects <tt>generic_category</tt> and +<tt>system_category</tt> in header <tt><system_error></tt> are currently declared: </p> -<blockquote><pre>void assign(const T& u); +<blockquote><pre>const error_category& get_generic_category(); +const error_category& get_system_category(); + +static const error_category& generic_category = get_generic_category(); +static const error_category& system_category = get_system_category(); </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. +This formulation has several problems: </p> +<ul> +<li> +Implementation details are exposed, since initialization is specified in +the interface. This over-constrains implementations without offsetting +user benefits. The form of initialization specified may be less than +maximally efficient on some platforms. +</li> +<li> +Use of the objects is more expensive in terms of number of machine level +instructions. See <i>Implementation experience</i> below. +</li> +<li> +Depending on the compiler, some cost may be incurred by each translation unit +that includes the header, even if the objects are not used. This is a +common scenario in user code, since the header is included by other +standard library headers. It should be mentioned that at least one +compilers is able to optimize this cost away, however. +</li> +</ul> + <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: +IO streams uses a somewhat different formulation for iostream_category, but +still suffer much the same problems. </p> -<blockquote> -what's the effect of calling <tt>assign(T&)</tt> on a zero-sized array? -</blockquote> +<p> +The original plan was to eliminate these problems by applying the C++0x +<tt>constexpr</tt> feature. See LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#832">832</a>. However, that approach turned out +to be unimplementable, since it would require a <tt>constexpr</tt> object of a +class with virtual functions, and that is not allowed by the core +language. +</p> <p> -which does not answer the basic question of this issue. +The proposed resolution was developed as an alternative. It mitigates the above +problems by removing initialization from the visible interface, allowing +implementations flexibility. </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. +<b>Implementation experience:</b> </p> +<p> +Prototype implementations of the current WP interface and proposed +resolution interface were tested with recent Codegear, GCC, Intel, and Microsoft +compilers on Windows. The code generated by the Microsoft compiler was studied +at length; the WP and proposal versions generated very similar code. For both versions +the compiler did make use of static +initialization; apparently the compiler applied an implicit <tt>constexpr</tt> +where useful, even in cases where <tt>constexpr</tt> would not be permitted by +the language! +</p> + +<p> +<b>Acknowledgements:</b> +</p> -<p><b>Proposed resolution:</b></p> <p> -Just after the section 23.2.1.4 [array.data] add the following new section: +Martin Sebor, Chris Kohlhoff, and John Lakos provided useful ideas and comments on initialization issues. </p> +<p><i>[ +San Francisco: +]</i></p> + + +<blockquote> <p> -23.2.1.5 array::fill [array.fill] +Martin: prefers not to create more file-scope static objects, and would +like to see <tt>get_*</tt> functions instead. </p> +</blockquote> + + +<p><i>[Pre-Summit:]</i></p> <blockquote> -<pre>void fill(const T& u); -</pre> + <p> -1: <i>Effects:</i> <tt>fill_n(begin(), N, u)</tt> +Beman: The proposed resolution has been reworked to remove the file-scope +static objects, per Martin's suggestions. The <tt>get_</tt> prefix has been +eliminated from the function names as no longer necessary and to conform with +standard library naming practice. </p> + +</blockquote> + +<p><i>[ +Post Summit: +]</i></p> + + +<blockquote> +Agreement that this is wise and essential, text provided works and has +been implemented. Seems to be widespread consensus. Move to Tentative Ready. +</blockquote> + + + +<p><b>Proposed resolution:</b></p> + +<p>Change 17.6.4.12 [value.error.codes] Value of error codes as indicated:</p> +<blockquote> + <p>Certain functions in the C++ standard library report errors via a + <tt>std::error_code</tt> (19.4.2.2) object. That object's <tt>category()</tt> member shall + return <del>a reference to</del> <code>std::system_category</code><tt><ins><code>()</code></ins></tt> for errors originating from the + operating system, or a reference to an implementation-defined error_category + object for errors originating elsewhere. The implementation shall define the + possible values of value() for each of these error categories. [<i>Example:</i> For + operating systems that are based on POSIX, implementations are encouraged to + define the <code>std::system_category</code><tt><ins><code>()</code></ins></tt> values as identical to the POSIX <tt>errno</tt> values, + with additional values as defined by the operating system's documentation. + Implementations for operating systems that are not based on POSIX are + encouraged to define values identical to the operating system's values. For + errors that do not originate from the operating system, the implementation may + provide enums for the associated values --<i>end example</i>]</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] +Change 19.5.1.1 [syserr.errcat.overview] Class <tt>error_category</tt> overview +<tt>error_category</tt> synopsis as indicated: </p> +<blockquote> +<pre>const error_category& <del>get_</del>generic_category(); +const error_category& <del>get_</del>system_category(); + +<del>static storage-class-specifier const error_category& generic_category = get_generic_category(); +static storage-class-specifier const error_category& system_category = get_system_category();</del> +</pre> +</blockquote> + <p> -Change the synopsis in 23.2.1 [array]/3: +Change 19.5.1.5 [syserr.errcat.objects] Error category objects as indicated: </p> -<blockquote><pre>template <class T, size_t N> -struct array { - ... - void <del>assign</del> <ins>fill</ins>(const T& u); - ... -</pre></blockquote> +<blockquote> +<pre>const error_category& <del>get_</del>generic_category(); +</pre> +<blockquote> -<p><i>[ -Bellevue: -]</i></p> +<p> +<i>Returns:</i> A reference to an object of a type derived from class <tt>error_category</tt>. +</p> +<p> +<i>Remarks:</i> 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> +</blockquote> + +<pre>const error_category& <del>get_</del>system_category(); +</pre> <blockquote> <p> -Suggest substituting "fill" instead of "assign". +<i>Returns:</i> A reference to an object of a type derived from class <tt>error_category</tt>. +</p> + +<p> +<i>Remarks:</i> 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> +<blockquote> +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<ins>()</ins>)</tt>. Otherwise, the +function shall return <tt>error_condition(ev, system_category<ins>()</ins>)</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>] +</blockquote> +</blockquote> + +</blockquote> + +<p>Change 19.5.2.3 [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 error_code.</p> + <p><i>Postconditions:</i> <code>val_ == 0 </code>and <code>cat_ == &system_category</code><tt><ins>()</ins></tt>.</p> + </blockquote> +</blockquote> +<p>Change 19.5.2.4 [syserr.errcode.modifiers] Class error_code modifiers as +indicated:</p> +<blockquote> + <pre>void clear();</pre> + <blockquote> + <p>Postconditions: <code>value() == 0</code> and <code>category() == + system_category</code><tt><ins>()</ins></tt>.</p> + </blockquote> +</blockquote> +<p>Change 19.5.2.6 [syserr.errcode.nonmembers] Class error_code non-member +functions as indicated:</p> +<blockquote> + <pre>error_code make_error_code(errc e);</pre> + <blockquote> + <p><i>Returns:</i> <code>error_code(static_cast<int>(e), generic_category</code><tt><ins>()</ins></tt><code>)</code>.</p> + </blockquote> +</blockquote> +<p>Change 19.5.3.3 [syserr.errcondition.constructors] Class error_condition +constructors as indicated:</p> +<blockquote> + <pre>error_condition();</pre> + <blockquote> + <p><i>Effects:</i> Constructs an object of type <code>error_condition</code>.</p> + <p><i>Postconditions:</i> <code>val_ == 0</code> and <code>cat_ == &generic_category</code><tt><ins>()</ins></tt>.</p> + </blockquote> +</blockquote> +<p>Change 19.5.3.4 [syserr.errcondition.modifiers] Class error_condition +modifiers as indicated:</p> +<blockquote> + <pre>void clear();</pre> + <blockquote> + <p><i>Postconditions:</i> <code>value() == 0</code> and <code>category() == + generic_category</code><tt><ins>()</ins></tt>.</p> + </blockquote> +</blockquote> +<p>Change 19.5.3.6 [syserr.errcondition.nonmembers] Class error_condition +non-member functions as indicated:</p> +<blockquote> + <pre>error_condition make_error_condition(errc e);</pre> + <blockquote> + <p><i>Returns:</i> <tt>error_condition(static_cast<int>(e), generic_category<ins>()</ins>)</tt>.</p> + </blockquote> +</blockquote> + <p>Change 27.5 [iostreams.base] Iostreams base classes, Header <ios> + synopsis as indicated:</p> +<blockquote> + <pre>concept_map ErrorCodeEnum<io_errc> { }; +error_code make_error_code(io_errc e); +error_condition make_error_condition(io_errc e); +<del>storage-class-specifier</del> const error_category& iostream_category<ins>()</ins>;</pre> +</blockquote> +<p>Change 27.5.2.1.1 [ios::failure] Class ios_base::failure, paragraph 2 as +indicated:</p> +<blockquote> +<p>When throwing ios_base::failure exceptions, implementations should provide +values of ec that identify the specific reason for the failure. [ Note: Errors +arising from the operating system would typically be reported as <tt> +system_category</tt><tt><ins>()</ins></tt> errors with an error value of the +error number reported by the operating system. Errors arising from within the +stream library would typically be reported as <tt>error_code(io_errc::stream, +iostream_category<ins>()</ins>)</tt>. --end note ]</p> +</blockquote> +<p>Change 27.5.5.5 [error.reporting] Error reporting as indicated:</p> +<blockquote> + <pre>error_code make_error_code(io_errc e);</pre> + <blockquote> + <p><i>Returns:</i> <code>error_code(static_cast<int>(e), iostream_category</code><ins>()</ins><code>)</code>.</p> + </blockquote> + <pre>error_condition make_error_condition(io_errc e);</pre> + <blockquote> + <p><i>Returns:</i> <code>error_condition(static_cast<int>(e), + iostream_category</code><ins>()</ins><code>)</code>.</p> + </blockquote> + <pre><del>storage-class-specifier</del> const error_category& iostream_category<ins>()</ins>;</pre> + <blockquote> + <del><p>The implementation shall initialize iostream_category. Its storage-class-specifier + may be static or extern. It is unspecified whether initialization is static + or dynamic (3.6.2). If initialization is dynamic, it shall occur before + completion of the dynamic initialization of the first translation unit + dynamically initialized that includes header <system_error>.</p></del> <p> -Set state to Review given substitution of "fill" for "assign". +<ins><i>Returns:</i> A reference to an object of a type derived from class <tt>error_category</tt>.</ins> </p> +<p><i>Remarks:</i> The object's default_error_condition and equivalent virtual functions shall +behave as specified for the class error_category. The object's name virtual +function shall return a pointer to the string "iostream".</p> + </blockquote> </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> +<h3><a name="891"></a>891. std::thread, std::call_once issue</h3> +<p><b>Section:</b> 30.3.1.2 [thread.thread.constr], 30.4.5.2 [thread.once.callonce] <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>Opened:</b> 2008-09-15 <b>Last modified:</b> 2009-03-22</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.thread.constr">active issues</a> in [thread.thread.constr].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.thread.constr">issues</a> in [thread.thread.constr].</p> +<p><b>View all 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 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. +I notice that the vararg overloads of <tt>std::thread</tt> and <tt>std::call_once</tt> +(N2723 30.3.1.2 [thread.thread.constr] and 30.4.5.2 [thread.once.callonce]) are no longer specified in terms of +<tt>std::bind</tt>; instead, some of the <tt>std::bind</tt> wording has been inlined into +the specification. +</p> +<p> +There are two problems with this. +</p> +<p> +First, the specification (and implementation) in terms of <tt>std::bind</tt> allows, for example: +</p> + +<blockquote><pre>std::thread th( f, 1, std::bind( g ) ); +</pre></blockquote> + +<p> +which executes <tt>f( 1, g() )</tt> in a thread. This can be useful. The +"inlined" formulation changes it to execute <tt>f( 1, bind(g) )</tt> in a thread. +</p> +<p> +Second, assuming that we don't want the above, the specification has copied the wording </p> +<blockquote> +<tt>INVOKE(func, w1, w2, ..., wN)</tt> (20.6.2) shall be a valid +expression for some values <tt>w1, w2, ..., wN</tt> +</blockquote> + +<p> +but this is not needed since we know that our argument list is args; it should simply be +</p> + +<blockquote> +<tt>INVOKE(func, args...)</tt> (20.6.2) shall be a valid expression +</blockquote> + +<p><i>[ +Summit: +]</i></p> + + +<blockquote> +Move to open. +</blockquote> + +<p><i>[ +Post Summit Anthony provided proposed wording. +]</i></p> + + <p><b>Proposed resolution:</b></p> <p> -In 25.2.8 [alg.remove]/p.6, replace the N2461 requires clause with: +Change paragraph 4 of 30.3.1.2 [thread.thread.constr] to: </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> +<pre>template <class F> explicit thread(F f); +template <class F, class ...Args> thread(F&& f, Args&&... args); +</pre> +<blockquote> +-4- <i>Requires:</i> <tt>F</tt> and each <tt>Ti</tt> in <tt>Args</tt> +shall be <tt>CopyConstructible</tt> if an lvalue and otherwise +<tt>MoveConstructible</tt>. <tt><i>INVOKE</i>(f, <del>w1, w2, ..., wN</del> <ins>args...</ins>)</tt> +(20.6.2) shall be a valid expression<del> for some values <i>w1, w2, ..., +wN</i>, where <tt>N == sizeof...(Args)</tt></del>. +</blockquote> </blockquote> +<p> +Change paragraph 1 of 30.4.5.2 [thread.once.callonce] to: +</p> + +<blockquote><pre>template<class Callable, class ...Args> + void call_once(once_flag& flag, Callable func, Args&&... args); +</pre> +<blockquote> +-1- <i>Requires:</i> The template parameters <tt>Callable></tt> and each +<tt>Ti</tt> in <tt>Args</tt> shall be <tt>CopyConstructible</tt> if an +lvalue and otherwise <tt>MoveConstructible</tt>. <tt><i>INVOKE</i>(func, +<del>w1, w2, ..., wN</del> <ins>args...</ins>)</tt> (20.6.2) shall be a +valid expression<del> for some values <i>w1, w2, ..., wN</i>, where +<tt>N == sizeof...(Args)</tt></del>. +</blockquote> +</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> +<h3><a name="893"></a>893. std::mutex issue</h3> +<p><b>Section:</b> 30.4.1.1 [thread.mutex.class] <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>Opened:</b> 2008-09-15 <b>Last modified:</b> 2009-03-22</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.mutex.class">active issues</a> in [thread.mutex.class].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.mutex.class">issues</a> in [thread.mutex.class].</p> +<p><b>View all 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#905">905</a></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: +30.4.1.1 [thread.mutex.class]/27 (in +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>) +says that the behavior is undefined if: </p> - +<ul> +<li>a thread that owns a <tt>mutex</tt> object calls <tt>lock()</tt> or +<tt>try_lock()</tt> on that object</li> +</ul> <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: +I don't believe that this is right. Calling <tt>lock()</tt> or <tt>try_lock()</tt> on a +locked <tt>mutex</tt> is well defined in the general case. <tt>try_lock()</tt> is required +to fail and return <tt>false</tt>. <tt>lock()</tt> is required to either throw an +exception (and is allowed to do so if it detects deadlock) or to block +until the <tt>mutex</tt> is free. These general requirements apply regardless of +the current owner of the <tt>mutex</tt>; they should apply even if it's owned by +the current thread. +</p> +<p> +Making double <tt>lock()</tt> undefined behavior probably can be justified (even +though I'd still disagree with the justification), but <tt>try_lock()</tt> on a +locked <tt>mutex</tt> must fail. </p> +<p><i>[ +Summit: +]</i></p> + +<blockquote> +<p> +Move to open. Proposed resolution: +</p> <ul> <li> -no assignment requirements are specified (neither implicit nor explicit). +In 30.4.1 [thread.mutex.requirements] paragraph 12, change the error +condition for <tt>resource_deadlock_would_occur</tt> to: "if the implementation +detects that a deadlock would occur" </li> - <li> -the effects clause just speaks of "merges", which is badly worded -near to a circular definition. +Strike 30.4.1.1 [thread.mutex.class] paragraph 3 bullet 2 "a thread that owns a mutex object +calls <tt>lock()</tt> or <tt>try_lock()</tt> on that object, or" </li> +</ul> +</blockquote> + +<p><b>Proposed resolution:</b></p> +<p> +In 30.4.1 [thread.mutex.requirements] paragraph 12 change: +</p> + +<blockquote> +<ul> +<li>...</li> <li> -p. 2 mentions a range <tt>[first, last)</tt>, which is not defined by the -function arguments or otherwise. +<tt>resource_deadlock_would_occur</tt> -- if the <del>current thread already owns the mutex and is able +to detect it</del> <ins>implementation detects that a deadlock would occur</ins>. </li> +<li>...</li> +</ul> +</blockquote> +<p> +Strike 30.4.1.1 [thread.mutex.class] paragraph 3 bullet 2: +</p> +<blockquote> +<p> +-3- The behavior of a program is undefined if: +</p> +<ul> +<li>...</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) +<del>a thread that owns a <tt>mutex</tt> object calls <tt>lock()</tt> or <tt>try_lock()</tt> on that object, or</del> </li> +<li>...</li> </ul> +</blockquote> + + + + +<hr> +<h3><a name="895"></a>895. "Requires:" on std::string::at et al</h3> +<p><b>Section:</b> 17.5.1.4 [structure.specifications] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> + <b>Submitter:</b> James Dennett <b>Opened:</b> 2008-09-16 <b>Last modified:</b> 2009-03-11</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#structure.specifications">active issues</a> in [structure.specifications].</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#Open">Open</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Per discussion, we need an issue open to cover looking at "Requires" +clauses which are not constraints on user code, such as that on +<tt>std::basic_string::at</tt>. +</p> + + <p><b>Proposed resolution:</b></p> <p> -In 25.3.4 [alg.merge] replace p.1+ 2: </p> + + + + +<hr> +<h3><a name="896"></a>896. Library thread safety issue</h3> +<p><b>Section:</b> 20.8.13.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> + <b>Submitter:</b> Hans Boehm <b>Opened:</b> 2008-09-16 <b>Last modified:</b> 2008-09-25</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#Open">Open</a> status.</p> +<p><b>Discussion:</b></p> +<p> +It is unclear whether <tt>shared_ptr</tt> is thread-safe in the sense that +multiple threads may simultaneously copy a <tt>shared_ptr</tt>. However this +is a critical piece of information for the client, and it has significant +impact on usability for many applications. (Detlef Vollman thinks it +is currently clear that it is not thread-safe. Hans Boehm thinks +it currently requires thread safety, since the <tt>use_count</tt> is not an +explicit field, and constructors and assignment take a const reference +to an existing <tt>shared_ptr</tt>.) +</p> + +<p> +Pro thread-safety: +</p> +<p> +Many multi-threaded usages are impossible. A thread-safe version can +be used to destroy an object when the last thread drops it, something +that is often required, and for which we have no other easy mechanism. +</p> +<p> +Against thread-safety: +</p> +<p> +The thread-safe version is well-known to be far more expensive, even +if used by a single thread. Many applications, including all single-threaded +ones, do not care. +</p> + +<p><i>[ +San Francisco: +]</i></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>. +Beman: this is a complicated issue, and would like to move this to Open +and await comment from Peter Dimov; we need very careful and complete +rationale for any decision we make; let's go slow +</p> +<p> +Detlef: I think that <tt>shared_ptr</tt> should not be thread-safe. +</p> +<p> +Hans: When you create a thread with a lambda, it in some cases makes it +very difficult for the lambda to reference anything in the heap. It's +currently ambiguous as to whether you can use a <tt>shared_ptr</tt> to get at an +object. +</p> +<p> +Leave in Open. Detlef will submit an alternative proposed resolution +that makes <tt>shared_ptr</tt> explicitly unsafe. +</p> +<p> +A third option is to support both threadsafe and non-safe share_ptrs, +and to let the programmer decide which behavior they want. </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> +Beman: Peter, do you support the PR? </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] +Peter: +</p> +<blockquote> +<p> +Yes, I support the proposed resolution, and I certainly oppose any +attempts to <tt>make shared_ptr</tt> thread-unsafe. +</p> +<p> +I'd mildly prefer if </p> +<blockquote> +[<i>Note:</i> This is true in spite of that fact that such functions often +modify <tt>use_count()</tt> <i>--end note</i>] +</blockquote> +<p> +is changed to +</p> +<blockquote> +[<i>Note:</i> This is true in spite of that fact that such functions often +cause a change in <tt>use_count()</tt> <i>--end note</i>] +</blockquote> +<p> +(or something along these lines) to emphasise that <tt>use_count()</tt> is not, +conceptually, a variable, but a return value. +</p> +</blockquote> + +</blockquote> +<p><b>Proposed resolution:</b></p> +<p> +Make it explicitly thread-safe, in this weak sense, as I believe was intended: +</p> +<p> +Insert in 20.8.13.2 [util.smartptr.shared], before p5: +</p> +<blockquote> +<p> +For purposes of determining the presence of a data race, +member functions do not modify <tt>const shared_ptr</tt> and +const <tt>weak_ptr</tt> arguments, nor any objects they +refer to. [<i>Note:</i> This is true in spite of that fact that such functions often +cause a change in <tt>use_count()</tt> <i>--end note</i>] +</p> +</blockquote> +<p> +On looking at the text, I'm not sure we need a similar disclaimer +anywhere else, since nothing else has the problem with the modified +<tt>use_count()</tt>. I think Howard arrived at a similar conclusion. +</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> +<h3><a name="897"></a>897. Forward_list issues... Part 2</h3> +<p><b>Section:</b> 23.3.3.4 [forwardlist.modifiers] <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>Opened:</b> 2008-09-22 <b>Last modified:</b> 2009-05-23</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> -Table 16 of TR1 requires that all Pseudo Random Number generators have a +This issue was split off from <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#892">892</a> at the request of the LWG. </p> -<blockquote><pre>seed(integer-type s) -</pre></blockquote> +<p><i>[ +San Francisco: +]</i></p> + +<blockquote> <p> -member function that is equivalent to: +This issue is more complicated than it looks. +</p> +<p> +paragraph 47: replace each <tt>(first, last) with (first, last]</tt> +</p> +<p> +add a statement after paragraph 48 that complexity is O(1) +</p> +<p> +remove the complexity statement from the first overload of splice_after </p> +<p> +We may have the same problems with other modifiers, like erase_after. +Should it require that all iterators in the range (position, last] be +dereferenceable? +</p> +</blockquote> -<blockquote><pre>mygen = Generator(s) -</pre></blockquote> +<p> +There are actually 3 issues here: +</p> +<ol> +<li> <p> -But the generators <tt>xor_combine</tt> and <tt>discard_block</tt> have no such seed member, only the +What value should <tt>erase_after</tt> return? With <tt>list</tt>, code often +looks like: </p> +<blockquote><pre>for (auto i = l.begin(); i != l.end();) +{ + // inspect *i and decide if you want to erase it + // ... + if (I want to erase *i) + i = l.erase(i); + else + ++i; +} +</pre></blockquote> +<p> +I.e. the iterator returned from <tt>erase</tt> is useful for setting up the +logic for operating on the next element. For <tt>forward_list</tt> this might +look something like: +</p> +<blockquote><pre>auto i = fl.before_begin(); +auto ip1 = i; +for (++ip1; ip1 != fl.end(); ++ip1) +{ + // inspect *(i+1) and decide if you want to erase it + // ... + if (I want to erase *(i+1)) + i = fl.erase_after(i); + else + ++i; + ip1 = i; +} +</pre></blockquote> +<p> +In the above example code, it is convenient if <tt>erase_after</tt> returns +the element <i>prior</i> to the erased element (range) instead of the element +<i>after</i> the erase element (range). +</p> +<p> +Existing practice: +</p> +<ul> +<li>SGI slist returns an iterator referencing the element <i>after</i> the erased range.</li> +<li>CodeWarrior slist returns an iterator referencing the element <i>before</i> the erased range.</li> +</ul> +<p> +There is not a strong technical argument for either solution over the other. +</p> +</li> -<blockquote><pre>template <class Gen> -seed(Gen&); +<li> +<p> +With all other containers, operations always work on the range +<tt>[first, last)</tt> and/or <i>prior to</i> the given <tt>position</tt>. +</p> +<p> +With <tt>forward_list</tt>, operations sometimes work on the range +<tt>(first, last]</tt> and/or <i>after</i> the given <tt>position</tt>. +</p> +<p> +This is simply due to the fact that in order to operate on +<tt>*first</tt> (with <tt>forward_list</tt>) one needs access to +<tt>*(first-1)</tt>. And that's not practical with +<tt>forward_list</tt>. So the operating range needs to start with <tt>(first</tt>, +not <tt>[first</tt> (as the current working paper says). +</p> +<p> +Additionally, if one is interested in splicing the range <tt>(first, last)</tt>, +then (with <tt>forward_list</tt>), one needs practical (constant time) access to +<tt>*(last-1)</tt> so that one can set the <i>next</i> field in this node to +the proper value. As this is not possible with <tt>forward_list</tt>, one must +specify the last element of interest instead of one past the last element of +interest. The syntax for doing this is to pass <tt>(first, last]</tt> instead +of <tt>(first, last)</tt>. +</p> +<p> +With <tt>erase_after</tt> we have a choice of either erasing the range +<tt>(first, last]</tt> <em>or</em> <tt>(first, last)</tt>. Choosing the latter +enables: +</p> +<blockquote><pre>x.erase_after(pos, x.end()); </pre></blockquote> <p> -member, which will not accept an integer literal as an argument: something that appears to violate the intent of Table 16. +With the former, the above statement is inconvenient or expensive due to the lack +of constant time access to <tt>x.end()-1</tt>. However we could introduce: </p> +<blockquote><pre>iterator erase_to_end(const_iterator position); +</pre></blockquote> + <p> -So... is this a bug in TR1? +to compensate. </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> +The advantage of the former (<tt>(first, last]</tt>) for <tt>erase_after</tt> +is a consistency with <tt>splice_after</tt> which uses <tt>(first, last]</tt> +as the specified range. But this either requires the addition of <tt>erase_to_end</tt> +or giving up such functionality. </p> +</li> + +<li> +As stated in the discussion of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#892">892</a>, and reienforced by point 2 above, +a <tt>splice_after</tt> should work on the source range <tt>(first, last]</tt> +if the operation is to be <i>Ο</i>(1). When splicing an entire list <tt>x</tt> the +algorithm needs <tt>(x.before_begin(), x.end()-1]</tt>. Unfortunately <tt>x.end()-1</tt> +is not available in constant time unless we specify that it must be. In order to +make <tt>x.end()-1</tt> available in constant time, the implementation would have +to dedicate a pointer to it. I believe the design of +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2543.htm">N2543</a> +intended a nominal overhead of <tt>foward_list</tt> of 1 pointer. Thus splicing +one <i>entire</i> <tt>forward_list</tt> into another can not be <i>Ο</i>(1). +</li> +</ol> + <p><i>[ -Jens adds: +Batavia (2009-05): ]</i></p> +<blockquote> +<p> +We agree with the proposed resolution. +</p> +<p> +Move to Review. +</p> +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +Wording below assumes issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#878">878</a> is accepted, but this issue is +independent of that issue. +</p> + +<p> +Change 23.3.3.4 [forwardlist.modifiers]: +</p> <blockquote> -Both engines do have the necessary -constructor, therefore the omission of the <tt>seed()</tt> member -functions appears to be an oversight. +<pre>iterator erase_after(const_iterator position); +</pre> +<blockquote> +<p> +<i>Requires:</i> The iterator following <tt>position</tt> is dereferenceable. +</p> +<p> +<i>Effects:</i> Erases the element pointed to by the iterator following <tt>position</tt>. +</p> +<p> +<i>Returns:</i> <del>An iterator pointing to the element following the one that was erased, or <tt>end()</tt> if no such +element exists</del> +<ins>An iterator equal to <tt>position</tt></ins>. +</p> </blockquote> +<pre>iterator erase_after(const_iterator position, <ins>const_</ins>iterator last); +</pre> +<blockquote> +<p> +<i>Requires:</i> All iterators in the range +<tt><del>[</del><ins>(</ins>position,last)</tt> +are dereferenceable. +</p> +<p> +<i>Effects:</i> Erases the elements in the range +<tt><del>[</del><ins>(</ins>position,last)</tt>. +</p> +<p> +<i>Returns:</i> <ins>An iterator equal to <tt>position</tt></ins> <del><tt>last</tt></del> +</p> +</blockquote> +</blockquote> -<p><b>Proposed resolution:</b></p> <p> +Change 23.3.3.5 [forwardlist.ops]: </p> +<blockquote> +<pre>void splice_after(const_iterator position, forward_list<T,Allocator>&& x); +</pre> +<blockquote> +<p> +<i>Requires:</i> <tt>position</tt> is <tt>before_begin()</tt> or a +dereferenceable iterator in the range <tt>[begin(), end))</tt>. <tt>&x != this</tt>. +</p> +<p> +<i>Effects:</i> Inserts the contents of <tt>x</tt> after <tt>position</tt>, and +<tt>x</tt> becomes empty. Pointers and references to +the moved elements of <tt>x</tt> now refer to those same elements but as members of <tt>*this</tt>. +Iterators referring to the moved elements will continue to refer to their elements, +but they now behave as iterators into <tt>*this</tt>, not into <tt>x</tt>. +</p> +<p> +<i>Throws:</i> Nothing. +</p> +<p> +<i>Complexity:</i> <del><i>Ο</i>(1)</del> <ins><i>Ο</i>(<tt>distance(x.begin(), x.end())</tt>)</ins> +</p> +</blockquote> + +<p>...</p> + +<pre>void splice_after(const_iterator position, forward_list<T,Allocator>&& x, + const_iterator first, const_iterator last); +</pre> +<blockquote> +<p> +<i>Requires:</i> <tt>position</tt> is <tt>before_begin()</tt> or a +dereferenceable iterator in the range <tt>[begin(), end))</tt>. +<tt>(first,last<ins>]</ins><del>)</del></tt> is a valid range in +<tt>x</tt>, and all iterators in the range +<tt>(first,last<ins>]</ins><del>)</del></tt> are dereferenceable. +<tt>position</tt> is not an iterator in the range <tt>(first,last<ins>]</ins><del>)</del></tt>. +</p> +<p> +<i>Effects:</i> Inserts elements in the range <tt>(first,last<ins>]</ins><del>)</del></tt> +after <tt>position</tt> and removes the elements from <tt>x</tt>. +Pointers and references to the moved elements of <tt>x</tt> now refer to +those same elements but as members of <tt>*this</tt>. Iterators +referring to the moved elements will continue to refer to their +elements, but they now behave as iterators into <tt>*this</tt>, not into +<tt>x</tt>. +</p> +<p> +<ins><i>Complexity:</i> <i>Ο</i>(1).</ins> +</p> +</blockquote> + +</blockquote> + + <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> +<h3><a name="898"></a>898. Small contradiction in n2723 to forward to committee</h3> +<p><b>Section:</b> 23.3.3.5 [forwardlist.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> Arch Robison <b>Opened:</b> 2008-09-08 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#forwardlist.ops">active issues</a> in [forwardlist.ops].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forwardlist.ops">issues</a> in [forwardlist.ops].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively 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 +I ran across a small contradiction in working draft n2723. </p> - <blockquote> -At most <tt>log(last - first) + 2</tt> comparisons. +<p> +23.3.3 [forwardlist]p2: A <tt>forward_list</tt> satisfies all of the +requirements of a container (table 90), except that the <tt>size()</tt> member +function is not provided. +</p> +<p> +23.3.3.5 [forwardlist.ops]p57: <i>Complexity:</i> At most <tt>size() + x.size() - 1</tt> +comparisons. +</p> </blockquote> +<p> +Presumably 23.3.3.5 [forwardlist.ops]p57 needs to be rephrased to not use +<tt>size()</tt>, or note that it is used there only for sake of notational convenience. +</p> + +<p><i>[ +2009-03-29 Beman provided proposed wording. +]</i></p> + + +<p><i>[ +Batavia (2009-05): +]</i></p> +<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>. +We agree with the proposed resolution. </p> +<p> +Move to Tentatively Ready. +</p> +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p><i>Change 23.3.3.5 [forwardlist.ops], +forward_list operations, paragraph 19, merge complexity as indicated: +</i></p> +<blockquote><i>Complexity:</i> At most <tt><del>size() + x.size()</del> +<ins>distance(begin(), end()) + distance(x.begin(), x.end())</ins> - 1</tt> +comparisons. +</blockquote> + + + + +<hr> +<h3><a name="899"></a>899. Adjusting <tt>shared_ptr</tt> for <tt>nullptr_t</tt></h3> +<p><b>Section:</b> 20.8.13.2.2 [util.smartptr.shared.dest] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2008-09-18 <b>Last modified:</b> 2009-05-23</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared.dest">issues</a> in [util.smartptr.shared.dest].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p> +<p><b>Discussion:</b></p> +<p> +James Dennett, message c++std-lib-22442: +</p> +<blockquote> +The wording below addresses one case of this, but opening an +issue to address the need to sanity check uses of the term "pointer" +in 20.8.13.2 [util.smartptr.shared] would be a good thing. +</blockquote> +<p> +There's one more reference, in <tt>~shared_ptr;</tt> we can apply your suggested change to it, too. That is: +</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>. +Change 20.8.13.2.2 [util.smartptr.shared.dest]/1 second bullet from: </p> +<blockquote> +Otherwise, if *this owns a pointer p and a deleter d, d(p) is called. +</blockquote> +<p> +to: +</p> +<blockquote> +Otherwise, if *this owns an object p and a deleter d, d(p) is called. +</blockquote> <p><i>[ -Sophia Antipolis: +Post Summit: ]</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. +Recommend Review. </blockquote> +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +<p> +Peter Dimov notes the analogous change has already been made +to "the new nullptr_t taking constructors +in 20.8.13.2.1 [util.smartptr.shared.const] p9-13." +</p> +<p> +We agree with the proposed resolution. +Move to Tentatively Ready. +</p> +</blockquote> <p><b>Proposed resolution:</b></p> <p> -Change 25.3.3.4 [binary.search]/3 +Change 20.8.13.2.2 [util.smartptr.shared.dest]/1 second bullet: </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. +<ul> +<li>...</li> +<li> +Otherwise, if <tt>*this</tt> <i>owns</i> <del>a pointer</del> +<ins>an object</ins> <tt>p</tt> and a +deleter <tt>d</tt>, <tt>d(p)</tt> is called. +</li> +</ul> </blockquote> @@ -12373,238 +17357,636 @@ Change 25.3.3.4 [binary.search]/3 <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> +<h3><a name="900"></a>900. stream move-assignment</h3> +<p><b>Section:</b> 27.9.1.8 [ifstream.assign] <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>Opened:</b> 2008-09-20 <b>Last modified:</b> 2009-05-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> -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>: +It +appears that we have an issue similar to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#675">675</a> regarding the move-assignment of +stream types. For example, when assigning to an <tt>std::ifstream</tt>, +<tt>ifstream1</tt>, it seems preferable to close the file originally held by +<tt>ifstream1</tt>: +</p> + +<blockquote><pre>ifstream1 = std::move(ifstream2); +</pre></blockquote> + +<p> +The current Draft +(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>) +specifies that the move-assignment of +stream types like <tt>ifstream</tt> has the same effect as a swap: </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. +<p> +Assign and swap 27.9.1.8 [ifstream.assign] +</p> +<pre>basic_ifstream& operator=(basic_ifstream&& rhs); +</pre> +<blockquote> +<i>Effects:</i> <tt>swap(rhs)</tt>. +</blockquote> </blockquote> +<p><i>[ +Batavia (2009-05): +]</i></p> + +<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). +Howard agrees with the analysis and the direction proposed. </p> - <p> -Also I would prefer to be explicit about calling <tt>fail()</tt> here -(there is no <tt>operator void*()</tt> anymore.) +Move to Open pending specific wording to be supplied by Howard. </p> +</blockquote> <p><b>Proposed resolution:</b></p> <p> -Change 24.5.1 [istream.iterator]/1: </p> + + + + +<hr> +<h3><a name="901"></a>901. insert iterators can move from lvalues</h3> +<p><b>Section:</b> 24.7.5 [insert.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">Tentatively NAD</a> + <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-09-24 <b>Last modified:</b> 2009-05-23</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD">Tentatively NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p><b>Addresses UK 282</b></p> + +<p> +The requires clause on the <tt>const T &</tt> overloads in +<tt>back_insert_iterator/front_insert_iterator/insert_iterator</tt> mean that the +assignment operator will implicitly move from lvalues of a move-only type. +</p> +<p> +Suggested resolutions are: +</p> +<ol type="a"> +<li> +Add another overload with a negative constraint on copy-constructible +and flag it "= delete". +</li> +<li> +Drop the copy-constructible overload entirely and rely on perfect +forwarding to catch move issues one level deeper. +</li> +<li> +This is a fundamental problem in move-syntax that relies on the +presence of two overloads, and we need to look more deeply into this +area as a whole - do not solve this issue in isolation. +</li> +</ol> + +<p><i>[ +Post Summit, Alisdair adds: +]</i></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. +<p> +Both comment and issue have been resolved by the adoption of +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2844.html">N2844</a> +(rvalue references safety fix) at the last meeting. +</p> + +<p> +Suggest resolve as NAD Editorial with a reference to the paper. +</p> </blockquote> +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +We agree that this has been resolved in the latest Working Draft. +Move to NAD. +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +Recommend NAD, addressed by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2844.html">N2844</a>. +</p> + <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> +<h3><a name="902"></a>902. Regular is the wrong concept to constrain numeric_limits</h3> +<p><b>Section:</b> 18.3.1 [limits] <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>Opened:</b> 2008-09-24 <b>Last modified:</b> 2009-03-11</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#Open">Open</a> status.</p> <p><b>Discussion:</b></p> + +<p><b>Addresses FR 32 and DE 16</b></p> + <p> -<tt>discrete_distribution</tt> should have a constructor like: +<tt>numeric_limits</tt> has functions specifically designed to return NaNs, which +break the model of <tt>Regular</tt> (via its axioms.) While floating point types +will be acceptible in many algorithms taking <tt>Regular</tt> values, it is not +appopriate for this specific API and we need a less refined constraint. </p> -<blockquote><pre>template<class _Fn> - discrete_distribution(result_type _Count, double _Low, double _High, - _Fn& _Func); -</pre></blockquote> +<p>FR 32:</p> + +<blockquote> +The definition of <tt>numeric_limits<></tt> as requiring a regular +type is both conceptually wrong and operationally illogical. As we +pointed before, this mistake needs to be corrected. For example, the +template can be left unconstrained. In fact this reflects a much more +general problem with concept_maps/axioms and their interpretations. It +appears that the current text heavily leans toward experimental academic +type theory. +</blockquote> + +<p>DE 16:</p> + +<blockquote> +The class template <tt>numeric_limits</tt> should not specify the Regular concept +requirement for its template parameter, because it contains functions +returning NaN values for floating-point types; these values violate the +semantics of EqualityComparable. +</blockquote> + +<p><i>[ +Summit: +]</i></p> + +<blockquote> +Move to Open. Alisdair and Gaby will work on a solution, along with the new +treatment of axioms in clause 14. +</blockquote> + + + +<p><b>Proposed resolution:</b></p> <p> -(Makes it easier to fill a histogram with function values over a range.) +</p> + + + + + +<hr> +<h3><a name="903"></a>903. <tt>back_insert_iterator</tt> issue</h3> +<p><b>Section:</b> 24.7.1 [back.insert.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">Tentatively NAD</a> + <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2008-09-19 <b>Last modified:</b> 2009-05-30</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD">Tentatively NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +I just noticed this; don't know how far the problem(?) extends or +whether it's new or existing: <tt>back_insert_iterator</tt>'s <tt>operator*</tt> is not +<tt>const</tt>, so you can't dereference a <tt>const</tt> one. </p> <p><i>[ -Bellevue: +Post Summit Daniel adds: ]</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. +<p> +If done, this change should be applied for <tt>front_insert_iterator</tt>, +<tt>insert_iterator</tt>, <tt>ostream_iterator</tt>, and <tt>ostreambuf_iterator</tt> as well. +</p> </blockquote> <p><i>[ -Sophia Antipolis: +Batavia (2009-05): ]</i></p> - <blockquote> <p> -Bill is not requesting this. +Alisdair notes that these all are output iterators. +Howard points out that <tt>++*i</tt> +would no longer work if we made this change. </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. +Move to NAD. </p> +</blockquote> + +<p><i>[ +2009-05-25 Daniel adds: +]</i></p> + + +<ol> +<li> +If <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1009">1009</a> is accepted, <tt>OutputIterator</tt> does no longer support post increment. +</li> +<li> +To support backward compatibility a second overload of <tt>operator*</tt> +can be added. +Note that the <tt>HasDereference</tt> concept (and the <tt>HasDereference</tt> part of concept +<tt>Iterator</tt>) was specifically refactored to cope with optional const +qualification and +to properly reflect the dual nature of built-in <tt>operator*</tt> as of +13.5.8 [over.literal]/6. +</li> +</ol> + + +<p><b>Proposed resolution:</b></p> + + + + + +<hr> +<h3><a name="904"></a>904. result_of argument types</h3> +<p><b>Section:</b> 20.7.4 [func.ret] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2008-09-10 <b>Last modified:</b> 2009-03-09</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p> +<p><b>Discussion:</b></p> <p> -Jens: lambda expressions are rvalues +The WP and TR1 have the same text regarding the argument types of a +<tt>result_of</tt> expression: </p> +<blockquote> +The values <tt>ti</tt> are lvalues when the corresponding type <tt>Ti</tt> is a +reference type, and rvalues otherwise. +</blockquote> <p> -Add a library issue to provide an -<tt>initializer_list<double></tt> constructor for -<tt>discrete_distribution</tt>. +I read this to mean that this compiles: </p> +<blockquote><pre>typedef int (*func)(int&); +result_of<func(int&&)>::type i = 0; +</pre></blockquote> <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. +even though this doesn't: </p> +<blockquote><pre>int f(int&); +f( std::move(0) ); +</pre></blockquote> <p> -Daniel: See <tt>random_shuffle</tt>, pass-by-rvalue-reference. +Should the text be updated to say "when <tt>Ti</tt> is an lvalue-reference +type" or am I missing something? </p> <p> -Daniel to draft wording. +I later came up with this self-contained example which won't compile, +but I think it should: </p> -</blockquote> +<blockquote><pre>struct X { + void operator()(int&); + int operator()(int&&); +} x; + +std::result_of< X(int&&) >::type i = x(std::move(0)); +</pre></blockquote> <p><i>[ -Pre San Francisco, Daniel provided wording: +Post Summit: ]</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. +Recommend Tentatively Ready. </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 +Change 20.7.4 [func.ret], p1: </p> -<blockquote><pre>explicit discrete_distribution(const param_type& parm); -</pre></blockquote> +<blockquote> +... The values <tt>ti</tt> are lvalues +when the corresponding type <tt>Ti</tt> is a<ins>n</ins> <ins>lvalue-</ins>reference type, +and rvalues otherwise. +</blockquote> + + + + + +<hr> +<h3><a name="906"></a>906. <tt>ObjectType</tt> is the wrong concept to constrain <tt>initializer_list</tt></h3> +<p><b>Section:</b> 18.9 [support.initlist] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-09-26 <b>Last modified:</b> 2009-05-23</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The currently proposed constraint on <tt>initializer_list</tt>'s element type +<tt>E</tt> is that is has to meet <tt>ObjectType</tt>. This is an underspecification, +because both core language and library part of <tt>initializer_list</tt> +make clear, that it references an implicitly allocated array: +</p> +<p> +8.5.4 [dcl.init.list]/4: +</p> +<blockquote> +When an initializer list is implicitly converted to a +<tt>std::initializer_list<E></tt>, the object passed is constructed as if the +implementation allocated an array of N elements of type <tt>E</tt>, where +N is the number of elements in the initializer list.[..] +</blockquote> + +<p> +18.9 [support.initlist]/2. +</p> + +<blockquote> +An object of type <tt>initializer_list<E></tt> provides access to an array of +objects of type <tt>const E</tt>.[..] +</blockquote> <p> -insert: +Therefore, <tt>E</tt> needs to fulfill concept <tt>ValueType</tt> (thus excluding +abstract class types). This stricter requirement should be added +to prevent deep instantiation errors known from the bad old times, +as shown in the following example: </p> +<blockquote><pre>// Header A: (Should concept-check even in stand-alone modus) + +template <DefaultConstructible T> +requires MoveConstructible<T> +void generate_and_do_3(T a) { + std::initializer_list<T> list{T(), std::move(a), T()}; + ... +} -<blockquote><pre>template<typename Func> -discrete_distribution(result_type nf, double xmin, double xmax, Func fw); +void do_more(); +void do_more_or_less(); + +template <DefaultConstructible T> +requires MoveConstructible<T> +void more_generate_3() { + do_more(); + generate_and_do_3(T()); +} + +template <DefaultConstructible T> +requires MoveConstructible<T> +void something_and_generate_3() { + do_more_or_less(); + more_generate_3(); +} + +// Test.cpp + +#include "A.h" + +class Abstract { +public: + virtual ~Abstract(); + virtual void foo() = 0; // abstract type + Abstract(Abstract&&){} // MoveConstructible + Abstract(){} // DefaultConstructible +}; + +int main() { + // The restricted template *accepts* the argument, but + // causes a deep instantiation error in the internal function + // generate_and_do_3: + something_and_generate_3<Abstract>(); +} </pre></blockquote> -</li> +<p> +The proposed stricter constraint does not minimize the aim to +support more general containers for which <tt>ObjectType</tt> would be +sufficient. If such an extended container (lets assume it's still a +class template) provides a constructor that accepts an <tt>initializer_list</tt> +only <em>this</em> constructor would need to be restricted on <tt>ValueType</tt>: +</p> + +<blockquote><pre>template<ObjectType T> +class ExtContainer { +public: + requires ValueType<T> + ExtContainer(std::initializer_list<T>); + ... +}; +</pre></blockquote> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +Move to Tentatively Ready. +</blockquote> + + + +<p><b>Proposed resolution:</b></p> +<ol> <li> +In 18.9 [support.initlist]/p.1 replace in "header <tt><initializer_list></tt> synopsis" +the constraint "<tt>ObjectType</tt>" in the template parameter list by the +constraint "<tt>ValueType</tt>". +</li> +</ol> + + + + + + +<hr> +<h3><a name="907"></a>907. Bitset's immutable element retrieval is inconsistently defined</h3> +<p><b>Section:</b> 20.3.6.2 [bitset.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-09-26 <b>Last modified:</b> 2009-05-23</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#Tentatively%20Ready">Tentatively Ready</a> status.</p> +<p><b>Discussion:</b></p> <p> -Between p.4 and p.5 insert a series of new paragraphs as part of the -new member description:: +The current standard 14882::2003(E) as well as the current draft +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a> +have in common a contradiction of the operational semantics +of member function test 20.3.6.2 [bitset.members]/56-58 and the immutable +member <tt>operator[]</tt> overload 20.3.6.2 [bitset.members]/64-66 (all references +are defined in terms of +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>): </p> -<blockquote><pre>template<typename Func> -discrete_distribution(result_type nf, double xmin, double xmax, Func fw); -</pre> +<ol> +<li><pre>bool test(size_t pos) const; +</pre> +<blockquote> <p> -<i>Complexity:</i> Exactly nf invocations of fw. +<i>Requires:</i> <tt>pos</tt> is valid </p> <p> -<i>Requires:</i> +<i>Throws:</i> <tt>out_of_range</tt> if <tt>pos</tt> does not correspond +to a valid bit position. </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> +<p> +<i>Returns:</i> <tt>true</tt> if the bit at position <tt>pos</tt> in <tt>*this</tt> +has the value one. +</p> +</blockquote> +</li> +<li><pre>constexpr bool operator[](size_t pos) const; +</pre> +<blockquote> +<p> +<i>Requires:</i> <tt>pos</tt> shall be valid. +</p> +<p> +<i>Throws:</i> nothing. +</p> +<p> +<i>Returns:</i> <tt>test(pos)</tt>. +</p> +</blockquote> +</li> +</ol> -<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> +<p> +Three interpretations: +</p> +<ol type="A"> +<li> +The <tt>operator[]</tt> overload is indeed allowed to throw an exception +(via <tt>test()</tt>, if <tt>pos</tt> corresponds to an invalid bit position) which does +not leave the call frame. In this case this function cannot be a +<tt>constexpr</tt> function, because <tt>test()</tt> is not, due to +5.19 [expr.const]/2, last bullet. +</li> +<li> +The intend was not to throw an exception in <tt>test</tt> in case of an +invalid bit position. There is only little evidence for this interpretation. +</li> +<li> +The intend was that <tt>operator[]</tt> should not throw any exception, +but that <tt>test</tt> has the contract to do so, if the provided bit position +is invalid. +</li> </ol> <p> -<i>Effects:</i> +The problem became worse, because issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#720">720</a> +recently voted into WP argued that member <tt>test</tt> logically must be +a <tt>constexpr</tt> function, because it was used to define the semantics +of another <tt>constexpr</tt> function (the <tt>operator[]</tt> overload). </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> +<p> +Three alternatives are proposed, corresponding to the three bullets +(A), (B), and (C), the author suggests to follow proposal (C). +</p> + +<b> +Proposed alternatives: +</b> + +<ol type="A"> <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>) +<p> +Remove the <tt>constexpr</tt> specifier in front of <tt>operator[]</tt> overload and +undo that of member <tt>test</tt> (assuming <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#720">720</a> is accepted) in both the +class declaration 20.3.6 [template.bitset]/1 and in the member description +before 20.3.6.2 [bitset.members]/56 and before /64 to read: +</p> +<blockquote><pre><del>constexpr</del> bool test(size_t pos) const; +.. +<del>constexpr</del> bool operator[](size_t pos) const; </pre></blockquote> + +<p> +Change the throws clause of p. 65 to read: +</p> + +<blockquote> +<i>Throws:</i> <del>nothing</del> +<ins><tt>out_of_range</tt> if <tt>pos</tt> does not correspond to a valid bit +position</ins>. +</blockquote> +</li> +<li> +<p> +Replace the throws clause p. 57 to read: +</p> + +<blockquote> +<i>Throws:</i> <del><tt>out_of_range</tt> if <tt>pos</tt> does not correspond to a valid bit +position</del> <ins>nothing</ins>. +</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. +<p> +Undo the addition of the <tt>constexpr</tt> specifier to the <tt>test</tt> member +function in both class declaration 20.3.6 [template.bitset]/1 and in the +member description before 20.3.6.2 [bitset.members]/56, assuming that <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#720">720</a> +was applied. +</p> + +<blockquote><pre><del>constexpr</del> bool test(size_t pos) const; </pre></blockquote> + +<p> +Change the returns clause p. 66 to read: +</p> + +<blockquote> +<i>Returns:</i> <del><tt>test(pos)</tt></del> <ins><tt>true</tt> if the bit at position <tt>pos</tt> in <tt>*this</tt> +has the value one, otherwise <tt>false</tt></ins>. +</blockquote> </li> </ol> + +<p><i>[ +Post Summit: +]</i></p> + + +<blockquote> +<p> +Lawrence: proposed resolutions A, B, C are mutually exclusive. +</p> +<p> +Recommend Review with option C. +</p> +</blockquote> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +We agree with the proposed resolution. +Move to Tentatively Ready. +</blockquote> + + +<p><b>Proposed resolution:</b></p> + +<ol ,="" start="3" type="A"> +<li> +<p> +Undo the addition of the <tt>constexpr</tt> specifier to the <tt>test</tt> member +function in both class declaration 20.3.6 [template.bitset]/1 and in the +member description before 20.3.6.2 [bitset.members]/56, assuming that <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#720">720</a> +was applied. +</p> + +<blockquote><pre><del>constexpr</del> bool test(size_t pos) const; +</pre></blockquote> + +<p> +Change the returns clause p. 66 to read: +</p> + +<blockquote> +<i>Returns:</i> <del><tt>test(pos)</tt></del> <ins><tt>true</tt> if the bit at position <tt>pos</tt> in <tt>*this</tt> +has the value one, otherwise <tt>false</tt></ins>. </blockquote> </li> </ol> @@ -12613,167 +17995,217 @@ and non-infinity;</li> + <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> +<h3><a name="908"></a>908. Deleted assignment operators for atomic types must be volatile</h3> +<p><b>Section:</b> 29.5 [atomics.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> + <b>Submitter:</b> Anthony Williams <b>Opened:</b> 2008-09-26 <b>Last modified:</b> 2009-03-22</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#Open">Open</a> status.</p> <p><b>Discussion:</b></p> + +<p><b>Addresses US 90</b></p> + <p> -<tt>piecewise_constant_distribution</tt> should have a constructor like: +The deleted copy-assignment operators for the atomic types are not +marked as volatile in N2723, whereas the assignment operators from the +associated non-atomic types are. e.g. </p> +<blockquote><pre>atomic_bool& operator=(atomic_bool const&) = delete; +atomic_bool& operator=(bool) volatile; +</pre></blockquote> -<blockquote><pre>template<class _Fn> - piecewise_constant_distribution(size_t _Count, - _Ty _Low, _Ty _High, _Fn& _Func); +<p> +This leads to ambiguity when assigning a non-atomic value to a +non-volatile instance of an atomic type: +</p> +<blockquote><pre>atomic_bool b; +b=false; </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>.) +Both assignment operators require a standard conversions: the +copy-assignment operator can use the implicit <tt>atomic_bool(bool)</tt> +conversion constructor to convert <tt>false</tt> to an instance of +<tt>atomic_bool</tt>, or <tt>b</tt> can undergo a qualification conversion in order to +use the assignment from a plain <tt>bool</tt>. +</p> + +<p> +This is only a problem once issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#845">845</a> is applied. </p> <p><i>[ -Sophia Antipolis: +Summit: ]</i></p> - <blockquote> +Move to open. Assign to Lawrence. Related to US 90 comment. +</blockquote> + + +<p><b>Proposed resolution:</b></p> <p> -Marc: uses variable width of bins and weight for each bin. This is not -giving enough flexibility to control both variables. +Add volatile qualification to the deleted copy-assignment operator of +all the atomic types: </p> + +<blockquote><pre>atomic_bool& operator=(atomic_bool const&) <ins>volatile</ins> = delete; +atomic_itype& operator=(atomic_itype const&) <ins>volatile</ins> = delete; +</pre></blockquote> + <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>. +etc. </p> <p> -Daniel to draft wording. +This will mean that the deleted copy-assignment operator will require +<i>two</i> conversions in the above example, and thus be a worse match than +the assignment from plain <tt>bool</tt>. +</p> + + + + + +<hr> +<h3><a name="909"></a>909. <tt>regex_token_iterator</tt> should use <tt>initializer_list</tt></h3> +<p><b>Section:</b> 28.13.2 [re.tokiter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-09-26 <b>Last modified:</b> 2009-05-23</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#Tentatively%20Ready">Tentatively Ready</a> status.</p> +<p><b>Discussion:</b></p> + +<p><b>Addresses UK 319</b></p> +<p> +Construction of a <tt>regex_token_iterator</tt> (28.13.2 [re.tokiter]/6+) usually +requires the provision of a sequence of integer values, which +can currently be done via a <tt>std::vector<int></tt> or +a C array of <tt>int</tt>. Since the introduction of <tt>initializer_list</tt> in the +standard it seems much more reasonable to provide a +corresponding constructor that accepts an <tt>initializer_list<int></tt> +instead. This could be done as a pure addition or one could +even consider replacement. The author suggests the +replacement strategy (A), but provides an alternative additive +proposal (B) as a fall-back, because of the handiness of this +range type: </p> -</blockquote> <p><i>[ -Pre San Francisco, Daniel provided wording. +Batavia (2009-05): ]</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. +We strongly recommend alternative B of the proposed resolution +in order that existing code not be broken. +With that understanding, move to Tentatively Ready. </blockquote> +<p><b>Original proposed wording:</b></p> - -<p><b>Proposed resolution:</b></p> - +<ol type="A"> +<li><br> <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 +In 28.13.2 [re.tokiter]/6 and the list 28.13.2.1 [re.tokiter.cnstr]/10-11 change the +constructor 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); +<blockquote><pre><del>template <std::size_t N></del> +regex_token_iterator(BidirectionalIterator a, BidirectionalIterator b, + const regex_type& re, + <del>const int (&submatches)[N]</del> <ins>initializer_list<int> submatches</ins>, + regex_constants::match_flag_type m = + regex_constants::match_default); </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: +In 28.13.2.1 [re.tokiter.cnstr]/12 change the last sentence </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; +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>[<del>&</del>submatches<ins>.begin()</ins>, +<del>&</del>submatches<ins>.end()</ins> <del>+ N</del>)</tt>. +</blockquote> </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; +</ol> </li> + +<li><br> +<ol> <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> +In 28.13.2 [re.tokiter]/6 and the list 28.13.2.1 [re.tokiter.cnstr]/10-11 <em>insert</em> the +following constructor declaration between the already existing ones +accepting a <tt>std::vector</tt> and a C array of <tt>int</tt>, resp.: </p> -<ol type="a"> + +<blockquote><pre>regex_token_iterator(BidirectionalIterator a, BidirectionalIterator b, + const regex_type& re, + initializer_list<int> submatches, + regex_constants::match_flag_type m = + regex_constants::match_default); +</pre></blockquote> +</li> <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> +<p> +In 28.13.2.1 [re.tokiter.cnstr]/12 change the last sentence +</p> + +<blockquote> +The third <ins>and fourth</ins> constructor initialize<del>s</del> the member <tt>subs</tt> +to hold a copy of the sequence of integer values pointed to +by the iterator range <tt>[&submatches,&submatches + N)</tt> +<ins>and <tt>[submatches.begin(),submatches.end())</tt>, respectively</ins>. +</blockquote> </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> + + + +<p><b>Proposed resolution:</b></p> + +<ol start="2" type="A"> + +<li><br> +<ol> <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: +In 28.13.2 [re.tokiter]/6 and the list 28.13.2.1 [re.tokiter.cnstr]/10-11 <em>insert</em> the +following constructor declaration between the already existing ones +accepting a <tt>std::vector</tt> and a C array of <tt>int</tt>, resp.: </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> + +<blockquote><pre>regex_token_iterator(BidirectionalIterator a, BidirectionalIterator b, + const regex_type& re, + initializer_list<int> submatches, + regex_constants::match_flag_type m = + regex_constants::match_default); +</pre></blockquote> </li> -</ol> +<li> <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> +In 28.13.2.1 [re.tokiter.cnstr]/12 change the last sentence +</p> + +<blockquote> +The third <ins>and fourth</ins> constructor initialize<del>s</del> the member <tt>subs</tt> +to hold a copy of the sequence of integer values pointed to +by the iterator range <tt>[&submatches,&submatches + N)</tt> +<ins>and <tt>[submatches.begin(),submatches.end())</tt>, respectively</ins>. </blockquote> </li> </ol> +</li> + +</ol> @@ -12781,80 +18213,142 @@ and with the probability densities: <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> +<h3><a name="910"></a>910. Effects of MoveAssignable</h3> +<p><b>Section:</b> 20.2.9 [concept.copymove] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> Alberto Ganesh Barbati <b>Opened:</b> 2008-09-29 <b>Last modified:</b> 2009-05-23</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p> <p><b>Discussion:</b></p> +<p><b>Addresses UK 150</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. +The description of the effect of <tt>operator=</tt> in the <tt>MoveAssignable</tt> +concept, given in paragraph 7 is: </p> +<blockquote><pre>result_type T::operator=(T&& rv); // inherited from HasAssign<T, T&&> +</pre> + +<blockquote> +<i>Postconditions:</i> the constructed <tt>T</tt> object is equivalent to the value of +<tt>rv</tt> before the assignment. [<i>Note:</i> there is no +requirement on the value of <tt>rv</tt> after the assignment. <i>--end note</i>] +</blockquote> +</blockquote> + <p> -There are two more minor issues: +The sentence contains a typo (what is the "constructed <tt>T</tt> object"?) +probably due to a cut&paste from <tt>MoveConstructible</tt>. Moreover, the +discussion of LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#675">675</a> shows that the postcondition is too generic +and might not reflect the user expectations. An implementation of the +move assignment that just calls <tt>swap()</tt> would always fulfill the +postcondition as stated, but might have surprising side-effects in case +the source rvalue refers to an object that is not going to be +immediately destroyed. See LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#900">900</a> for another example. Due to +the sometimes intangible nature of the "user expectation", it seems +difficult to have precise normative wording that could cover all cases +without introducing unnecessary restrictions. However a non-normative +clarification could be a very helpful warning sign that swapping is not +always the correct thing to do. </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: +2009-05-09 Alisdair adds: ]</i></p> <blockquote> -Move to OPEN Bill will try to propose a resolution by the next meeting. +<p> +Issue 910 is exactly the reason BSI advanced the Editorial comment UK-150. +</p> +<p> +The post-conditions after assignment are at a minimum that the object +referenced by rv must be safely destructible, and the transaction should not +leak resources. Ideally it should be possible to simply assign rv a new +valid state after the call without invoking undefined behaviour, but any +other use of the referenced object would depend upon additional guarantees +made by that type. +</p> </blockquote> <p><i>[ -post Bellevue: Bill provided wording. +2009-05-09 Howard adds: ]</i></p> +<blockquote> <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. +The intent of the rvalue reference work is that the moved from <tt>rv</tt> is +a valid object. Not one in a singular state. If, for example, the moved from +object is a <tt>vector</tt>, one should be able to do anything on that moved-from +<tt>vector</tt> that you can do with any other <tt>vector</tt>. However you would +first have to query it to find out what its current state is. E.g. it might have <tt>capacity</tt>, +it might not. It might have a non-zero <tt>size</tt>, it might not. But regardless, +you can <tt>push_back</tt> on to it if you want. </p> +<p> +That being said, most standard code is now conceptized. That is, the concepts +list the only operations that can be done with templated types - whether or not +the values have been moved from. +</p> +<p> +Here is user-written code which must be allowed to be legal: +</p> +<blockquote><pre>#include <vector> +#include <cstdio> + +template <class Allocator> +void +inspect(std::vector<double, Allocator>&& v) +{ + std::vector<double, Allocator> result(move(v)); + std::printf("moved from vector has %u size and %u capacity\n", v.size(), v.capacity()); + std::printf("The contents of the vector are:\n"); + typedef typename std::vector<double, Allocator>::iterator I; + for (I i = v.begin(), e = v.end(); i != e; ++i) + printf("%f\n", *i); +} + +int main() +{ + std::vector<double> v1(100, 5.5); + inspect(move(v1)); +} +</pre></blockquote> -<p><b>Proposed resolution:</b></p> <p> -Replace 26.4.7.1 [rand.util.seedseq] paragraph 6 with: +The above program does not treat the moved-from <tt>vector</tt> as singular. It +only treats it as a <tt>vector</tt> with an unknown value. </p> +<p> +I believe the current proposed wording is consistent with my view on this. +</p> +</blockquote> + +<p><i>[ +Batavia (2009-05): +]</i></p> <blockquote> +We agree that the proposed resolution +is an improvement over the current wording. +</blockquote> + + + +<p><b>Proposed resolution:</b></p> <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: +In 20.2.9 [concept.copymove], replace the postcondition in paragraph 7 with: </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> +<i>Postconditions:</i> <tt>*this</tt> is equivalent to the value of <tt>rv</tt> before the +assignment. [<i>Note:</i> there is no requirement on the value of <tt>rv</tt> after the +assignment, but the +effect should be unsurprising to the user even in case <tt>rv</tt> is not +immediately destroyed. This may require that resources previously owned +by <tt>*this</tt> are released instead of transferred to <tt>rv</tt>. <i>-- end note</i>] </blockquote> @@ -12862,663 +18356,2669 @@ algorithm: <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> +<h3><a name="911"></a>911. I/O streams and <tt>move/swap</tt> semantic</h3> +<p><b>Section:</b> 27.7.1 [input.streams], 27.7.2 [output.streams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> + <b>Submitter:</b> Alberto Ganesh Barbati <b>Opened:</b> 2008-09-29 <b>Last modified:</b> 2009-05-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> -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. +Class template <tt>basic_istream</tt>, <tt>basic_ostream</tt> and <tt>basic_iostream</tt> +implements public move constructors, move assignment operators and <tt>swap</tt> +method and free functions. This might induce both the user and the +compiler to think that those types are <tt>MoveConstructible</tt>, <tt>MoveAssignable</tt> +and <tt>Swappable</tt>. However, those class templates fail to fulfill the user +expectations. For example: </p> + +<blockquote><pre>std::ostream os(std::ofstream("file.txt")); +assert(os.rdbuf() == 0); // buffer object is not moved to os, file.txt has been closed + +std::vector<std::ostream> v; +v.push_back(std::ofstream("file.txt")); +v.reserve(100); // causes reallocation +assert(v[0].rdbuf() == 0); // file.txt has been closed! + +std::ostream&& os1 = std::ofstream("file1.txt"); +os1 = std::ofstream("file2.txt"); +os1 << "hello, world"; // still writes to file1.txt, not to file2.txt! + +std::ostream&& os1 = std::ofstream("file1.txt"); +std::ostream&& os2 = std::ofstream("file2.txt"); +std::swap(os1, os2); +os1 << "hello, world"; // writes to file1.txt, not to file2.txt! +</pre></blockquote> + <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. +This is because the move constructor, the move assignment operator and +<tt>swap</tt> are all implemented through calls to <tt>std::basic_ios</tt> member +functions <tt>move()</tt> and <tt>swap()</tt> that do not move nor swap the controlled +stream buffers. That can't happen because the stream buffers may have +different types. </p> + <p> -There are at least two cases where specification of an explicitly -defaulted function may be desirable. +Notice that for <tt>basic_streambuf</tt>, the member function <tt>swap()</tt> is +protected. I believe that is correct and all of <tt>basic_istream</tt>, +<tt>basic_ostream</tt>, <tt>basic_iostream</tt> should do the same as the move ctor, move +assignment operator and swap member function are needed by the derived +<tt>fstream</tt>s and <tt>stringstream</tt>s template. The free swap functions for +<tt>basic_(i|o|io)stream</tt> templates should be removed for the same reason. </p> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> <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 +We note that the rvalue swap functions have already been removed. </p> +<p> +Bill is unsure about making the affected functions protected; +he believes they may need to be public. +</p> +<p> +We are also unsure about removing the lvalue swap functions as proposed. +</p> +<p> +Move to Open. +</p> +</blockquote> -<blockquote><pre>pair() = default; + +<p><b>Proposed resolution:</b></p> +<p> +27.7.1.1 [istream]: make the following member functions protected: +</p> + +<blockquote><pre>basic_istream(basic_istream&& rhs); +basic_istream& operator=(basic_istream&& rhs); +void swap(basic_istream&& rhs); </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. +Ditto: remove the three swap free functions signatures </p> +<blockquote><pre><del>// swap: +template <class charT, class traits> + void swap(basic_istream<charT, traits>& x, basic_istream<charT, traits>& y); +template <class charT, class traits> + void swap(basic_istream<charT, traits>&& x, basic_istream<charT, traits>& y); +template <class charT, class traits> + void swap(basic_istream<charT, traits>& x, basic_istream<charT, traits>&& y);</del> +</pre></blockquote> + <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? +27.7.1.1.2 [istream.assign]: remove paragraph 4 +</p> + +<blockquote><pre><del>template <class charT, class traits> + void swap(basic_istream<charT, traits>& x, basic_istream<charT, traits>& y); +template <class charT, class traits> + void swap(basic_istream<charT, traits>&& x, basic_istream<charT, traits>& y); +template <class charT, class traits> + void swap(basic_istream<charT, traits>& x, basic_istream<charT, traits>&& y);</del> +</pre> +<blockquote> +<del><i>Effects:</i> <tt>x.swap(y)</tt>.</del> +</blockquote> +</blockquote> + +<p> +27.7.1.5 [iostreamclass]: make the following member function protected: </p> + +<blockquote><pre>basic_iostream(basic_iostream&& rhs); +basic_iostream& operator=(basic_iostream&& rhs); +void swap(basic_iostream&& rhs); +</pre></blockquote> + <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: +Ditto: remove the three swap free functions signatures </p> -<blockquote><pre>tuple() = default; -tuple(const tuple&) = default; +<blockquote><pre><del>template <class charT, class traits> + void swap(basic_iostream<charT, traits>& x, basic_iostream<charT, traits>& y); +template <class charT, class traits> + void swap(basic_iostream<charT, traits>&& x, basic_iostream<charT, traits>& y); +template <class charT, class traits> + void swap(basic_iostream<charT, traits>& x, basic_iostream<charT, traits>&& y);</del> </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. +27.7.1.5.3 [iostream.assign]: remove paragraph 3 </p> + +<blockquote><pre><del>template <class charT, class traits> + void swap(basic_iostream<charT, traits>& x, basic_iostream<charT, traits>& y); +template <class charT, class traits> + void swap(basic_iostream<charT, traits>&& x, basic_iostream<charT, traits>& y); +template <class charT, class traits> + void swap(basic_iostream<charT, traits>& x, basic_iostream<charT, traits>&& y);</del> +</pre> +<blockquote> +<del><i>Effects:</i> <tt>x.swap(y)</tt>.</del> +</blockquote> +</blockquote> + <p> -** How does the committee wish to trade implementation -efficiency versus implementation flexibility? +27.7.2.1 [ostream]: make the following member function protected: +</p> + +<blockquote><pre>basic_ostream(basic_ostream&& rhs); +basic_ostream& operator=(basic_ostream&& rhs); +void swap(basic_ostream&& rhs); +</pre></blockquote> + +<p> +Ditto: remove the three swap free functions signatures +</p> + +<blockquote><pre><del>// swap: +template <class charT, class traits> + void swap(basic_ostream<charT, traits>& x, basic_ostream<charT, traits>& y); +template <class charT, class traits> + void swap(basic_ostream<charT, traits>&& x, basic_ostream<charT, traits>& y); +template <class charT, class traits> + void swap(basic_ostream<charT, traits>& x, basic_ostream<charT, traits>&& y);</del> +</pre></blockquote> + +<p> +27.7.2.3 [ostream.assign]: remove paragraph 13 (The paragraphs seems to +be misnumbered in the whole section 27.7.2 [output.streams] in +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>. +The paragraph to +remove is the one that describes the three <tt>swap</tt> free functions). +</p> + +<blockquote><pre><del>template <class charT, class traits> + void swap(basic_ostream<charT, traits>& x, basic_ostream<charT, traits>& y); +template <class charT, class traits> + void swap(basic_ostream<charT, traits>&& x, basic_ostream<charT, traits>& y); +template <class charT, class traits> + void swap(basic_ostream<charT, traits>& x, basic_ostream<charT, traits>&& y);</del> +</pre> +<blockquote> +<del><i>Effects:</i> <tt>x.swap(y)</tt>.</del> +</blockquote> +</blockquote> + + + + + + +<hr> +<h3><a name="912"></a>912. Array swap needs to be conceptualized</h3> +<p><b>Section:</b> 25.4.3 [alg.swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">Tentatively NAD</a> + <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-10-01 <b>Last modified:</b> 2009-05-23</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#Tentatively%20NAD">Tentatively NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +With the adaption of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#809">809</a> +we have a new algorithm <tt>swap</tt> for C-arrays, which needs to be conceptualized. </p> <p><i>[ -Bellevue: +Post Summit Daniel adds: ]</i></p> <blockquote> +Recommend as NAD Editorial: The changes have already been applied to the WP +<a href="" ref="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2800.pdf">N2800</a>. +</blockquote> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +Move to NAD; the changes have already been made. +</blockquote> + + +<p><b>Proposed resolution:</b></p> <p> -General agreement; the first half of the issue is NAD. +Replace in 25.4.3 [alg.swap] before p. 3 until p. 4 by </p> + +<blockquote><pre>template <<del>class</del> <ins>ValueType</ins> T, size_t N> +<ins>requires Swappable<T></ins> +void swap(T (&a)[N], T (&b)[N]); +</pre> +<blockquote> <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. +<del><i>Requires:</i> <tt>T</tt> shall be <tt>Swappable</tt>.</del> </p> <p> -Concensus: Go forward, but not at expense of other desired qualities. +<i>Effects:</i> <tt>swap_ranges(a, a + N, b);</tt> </p> +</blockquote> +</blockquote> + + + + + + +<hr> +<h3><a name="913"></a>913. Superfluous requirements for replace algorithms</h3> +<p><b>Section:</b> 25.4.5 [alg.replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-10-03 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#alg.replace">active issues</a> in [alg.replace].</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#Tentatively%20Ready">Tentatively Ready</a> status.</p> +<p><b>Discussion:</b></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. +(A) 25.4.5 [alg.replace]/1: </p> + +<blockquote> +<i>Requires:</i> The expression <tt>*first = new_value</tt> shall be valid. </blockquote> +<p> +(B) 25.4.5 [alg.replace]/4: +</p> + +<blockquote> +<i>Requires:</i> The results of the expressions <tt>*first</tt> and <tt>new_value</tt> shall +be writable to the result output iterator.[..] +</blockquote> -<p><b>Proposed resolution:</b></p> <p> +Since conceptualization, the quoted content of these clauses is covered +by the existing requirements </p> +<p> +(A) <tt>OutputIterator<Iter, const T&></tt> +</p> +<p> +and +</p> +<p> +(B) <tt>OutputIterator<OutIter, InIter::reference> && OutputIterator<OutIter, const T&></tt> +</p> +<p> +resp, and thus should be removed. +</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><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> <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. +We agree with the proposed resolution. </p> <p> -This repacking triggers several problems: +Move to Tentatively Ready. </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> +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<ol type="A"> <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.) +<p> +Remove 25.4.5 [alg.replace]/1. +</p> +<blockquote><pre>template<ForwardIterator Iter, class T> + requires OutputIterator<Iter, Iter::reference> + && OutputIterator<Iter, const T&> + && HasEqualTo<Iter::value_type, T> + void replace(Iter first, Iter last, + const T& old_value, const T& new_value); + +template<ForwardIterator Iter, Predicate<auto, Iter::value_type> Pred, class T> + requires OutputIterator<Iter, Iter::reference> + && OutputIterator<Iter, const T&> + && CopyConstructible<Pred> + void replace_if(Iter first, Iter last, + Pred pred, const T& new_value); +</pre> +<blockquote> +<del>1 <i>Requires:</i> The expression <tt>*first = new_value</tt> shall be valid.</del> +</blockquote> +</blockquote> </li> <li> -The description and algorithm have become unduly complicated. +<p> +25.4.5 [alg.replace]/4: Remove the sentence "The results of the +expressions <tt>*first</tt> and +<tt>new_value</tt> shall be writable to the result output iterator.". +</p> +<blockquote><pre>template<InputIterator InIter, typename OutIter, class T> + requires OutputIterator<OutIter, InIter::reference> + && OutputIterator<OutIter, const T&> + && HasEqualTo<InIter::value_type, T> + OutIter replace_copy(InIter first, InIter last, + OutIter result, + const T& old_value, const T& new_value); + +template<InputIterator InIter, typename OutIter, + Predicate<auto, InIter::value_type> Pred, class T> + requires OutputIterator<OutIter, InIter::reference> + && OutputIterator<OutIter, const T&> + && CopyConstructible<Pred> + OutIter replace_copy_if(InIter first, InIter last, + OutIter result, + Pred pred, const T& new_value); +</pre> +<blockquote> +4 <i>Requires:</i> <del>The results of the expressions <tt>*first</tt> and +<tt>new_value</tt> shall be writable to the <tt>result</tt> output +iterator.</del> The ranges <tt>[first,last)</tt> and <tt>[result,result + +(last - first))</tt> shall not overlap. +</blockquote> +</blockquote> </li> </ol> + + + + + +<hr> +<h3><a name="914"></a>914. Superfluous requirement for unique</h3> +<p><b>Section:</b> 25.4.9 [alg.unique] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-10-03 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#alg.unique">active issues</a> in [alg.unique].</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#Tentatively%20Ready">Tentatively Ready</a> status.</p> +<p><b>Discussion:</b></p> <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). +25.4.9 [alg.unique]/2: "Requires: The comparison function shall be an +equivalence relation." </p> + <p> -Here's how the description would read +The essence of this is already covered by the given requirement </p> -<blockquote> + +<blockquote><pre>EquivalenceRelation<auto, Iter::value_type> Pred +</pre></blockquote> + <p> -26.4.7.1 [rand.util.seedseq] Class <tt>seed_seq</tt> +and should thus be removed. </p> +<p><i>[ +Batavia (2009-05): +]</i></p> + <blockquote> -<pre>template<class InputIterator> - seed_seq(InputIterator begin, InputIterator end); +We agree with the proposed resolution. +Move to Tentatively Ready. +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +Remove 25.4.9 [alg.unique]/2 +</p> + +<blockquote><pre>template<ForwardIterator Iter> + requires OutputIterator<Iter, Iter::reference> + && EqualityComparable<Iter::value_type> + Iter unique(Iter first, Iter last); + +template<ForwardIterator Iter, EquivalenceRelation<auto, Iter::value_type> Pred> + requires OutputIterator<Iter, RvalueOf<Iter::reference>::type> + && CopyConstructible<Pred> + Iter unique(Iter first, Iter last, + Pred pred); </pre> <blockquote> <p> -5 <i>Requires:</i> NO CHANGE +1 <i>Effects:</i> ... </p> <p> -6 <i>Effects:</i> Constructs a <tt>seed_seq</tt> object by +<del>2 <i>Requires:</i> The comparison function shall be an equivalence relation.</del> </p> -<blockquote> -<pre>for (InputIterator s = begin; s != end; ++s) - v.push_back((*s) mod 2^32); -</pre> </blockquote> </blockquote> + + + + + +<hr> +<h3><a name="915"></a>915. <tt>minmax</tt> with <tt>initializer_list</tt> should return +<tt>pair</tt> of <tt>T</tt>, not <tt>pair</tt> of <tt>const T&</tt></h3> +<p><b>Section:</b> 25.5.7 [alg.min.max] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-10-04 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#alg.min.max">active issues</a> in [alg.min.max].</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#Tentatively%20Ready">Tentatively Ready</a> status.</p> +<p><b>Discussion:</b></p> +<p> +It seems that the proposed changes for +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2772.pdf">N2772</a> +were not clear enough in +this point: +</p> + +<blockquote> +25.5.7 [alg.min.max], before p.23 + p.24 + before p. 27 + p. 28 say that the return +type of the <tt>minmax</tt> overloads with an <tt>initializer_list</tt> is +<tt>pair<const T&, const T&></tt>, +which is inconsistent with the decision for the other <tt>min/max</tt> overloads which take +a <tt>initializer_list</tt> as argument and return a <tt>T</tt>, not a <tt>const T&</tt>. +Doing otherwise for <tt>minmax</tt> would easily lead to unexpected life-time +problems by using <tt>minmax</tt> instead of <tt>min</tt> and <tt>max</tt> separately. </blockquote> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +We agree with the proposed resolution. +Move to Tentatively Ready. </blockquote> + +<p><b>Proposed resolution:</b></p> +<ol> +<li> <p> -Discussion: +In 25 [algorithms]/2, header <tt><algorithm></tt> synopsis change as indicated: </p> + +<blockquote><pre>template<<del>class</del><ins>LessThanComparable</ins> T> +<ins>requires CopyConstructible<T></ins> +pair<<del>const </del>T<del>&</del>, <del>const </del>T<del>&</del>> +minmax(initializer_list<T> t); + +template<class T, <del>class</del><ins>StrictWeakOrder<auto, T></ins> Compare> +<ins>requires CopyConstructible<T></ins> +pair<<del>const </del>T<del>&</del>, <del>const </del>T<del>&</del>> +minmax(initializer_list<T> t, Compare comp); +</pre></blockquote> +</li> +<li> <p> -The chief virtues here are simplicity, portability, and generality. +In 25.5.7 [alg.min.max] change as indicated (Begin: Just before p.20): </p> -<ul> +<blockquote><pre>template<<del>class</del><ins>LessThanComparable</ins> T> + <ins>requires CopyConstructible<T></ins> + pair<<del>const </del>T<del>&</del>, <del>const </del>T<del>&</del>> + minmax(initializer_list<T> t); +</pre> +<blockquote> +<p> +<del>-20- <i>Requires:</i> <tt>T</tt> is <tt>LessThanComparable</tt> and +<tt>CopyConstructible</tt>.</del> +</p> +<p> +-21- <i>Returns:</i> <tt>pair<<del>const </del>T<del>&</del>, <del>const +</del>T<del>&</del>>(x, y)</tt> where <tt>x</tt> is the +smallest value and <tt>y</tt> the largest value in the <tt>initializer_list</tt>. +</p> +</blockquote> + +<p>[..]</p> +<pre>template<class T, <del>class</del><ins>StrictWeakOrder<auto, T></ins> Compare> + <ins>requires CopyConstructible<T></ins> + pair<<del>const </del>T<del>&</del>, <del>const </del>T<del>&</del>> + minmax(initializer_list<T> t, Compare comp); +</pre> + +<blockquote> +<p> +<del>-24- <i>Requires:</i> type <tt>T</tt> is <tt>LessThanComparable</tt> and <tt>CopyConstructible</tt>.</del> +</p> +<p> +-25- <i>Returns:</i> <tt>pair<<del>const </del>T<del>&</del>, <del>const +</del>T<del>&</del>>(x, y)</tt> where <tt>x</tt> is the +smallest value and <tt>y</tt> largest value in the <tt>initializer_list</tt>. +</p> +</blockquote> +</blockquote> +</li> +</ol> + + + + + + +<hr> +<h3><a name="916"></a>916. Redundant move-assignment operator of <tt>pair</tt> should be removed</h3> +<p><b>Section:</b> 20.3.3 [pairs] <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>Opened:</b> 2008-10-04 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#pairs">active issues</a> in [pairs].</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#Open">Open</a> status.</p> +<p><b>Discussion:</b></p> +<p><b>see also <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#917">917</a>.</b></p> + +<p> +The current WP provides the following assignment operators for <tt>pair</tt> +in 20.3.3 [pairs]/1: +</p> + +<ol> <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. +<pre>template<class U , class V> +requires HasAssign<T1, const U&> && HasAssign<T2, const V&> +pair& operator=(const pair<U , V>& p); +</pre> </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. +<pre>requires MoveAssignable<T1> && MoveAssignable<T2> pair& operator=(pair&& p ); +</pre> </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). +<pre>template<class U , class V> +requires HasAssign<T1, RvalueOf<U>::type> && HasAssign<T2, RvalueOf<V>::type> +pair& operator=(pair<U , V>&& p); +</pre> </li> -</ul> +</ol> + <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: +It seems that the functionality of (2) is completely covered by (3), therefore +(2) should be removed. </p> -<ul> -<li> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> <p> -The user can pass an array of <tt>unsigned char</tt> and <tt>seed_seq</tt> will nicely - repack it. +Bill believes the extra assignment operators are necessary for resolving +ambiguities, but that does not mean it needs to be part of the specification. </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 +Move to Open. +We recommend this be looked at in the context of the ongoing work +related to the pair templates. +</p> +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<ol type="A"> +<li> +<p> +In 20.3.3 [pairs] p. 1, class <tt>pair</tt> and just before p. 13 remove the declaration: </p> -<blockquote><pre>v = { 0x3, 0x434241 }; + +<blockquote><pre>requires MoveAssignable<T1> && MoveAssignable<T2> pair& operator=(pair&& p ); </pre></blockquote> +</li> + +<li> +Remove p.13+p.14 +</li> + +</ol> + + + + + +<hr> +<h3><a name="917"></a>917. Redundant move-assignment operator of <tt>tuple</tt> should be removed</h3> +<p><b>Section:</b> 20.5.2.1 [tuple.cnstr] <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>Opened:</b> 2008-10-04 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#tuple.cnstr">active issues</a> in [tuple.cnstr].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple.cnstr">issues</a> in [tuple.cnstr].</p> +<p><b>View all 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><b>see also <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#916">916</a>.</b></p> +<p> +N2770 (and thus now the WP) removed the +non-template move-assignment operator from tuple's class definition, +but the latter individual member description does still provide this +operator. Is this (a) an oversight and can it (b) be solved as part of an +editorial process? +</p> + +<p><i>[ +Post Summit Daniel provided wording. +]</i></p> + + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +<p> +We believe that the proposed resolution's part 1 is editorial. +</p> +<p> +Regarding part 2, we either remove the specification as proposed, +or else add back the declaration to which the specification refers. +Alisdair and Bill prefer the latter. +It is not immediately obvious whether the function is intended to be present. +</p> +<p> +We recommend that the Project Editor restore the missing declaration +and that we keep part 2 of the issue alive. +</p> <p> -while the simplified proposal yields +Move to Open. </p> -<blockquote><pre>v = { 0x41, 0x42, 0x43 }; +</blockquote> + + + +<p><b>Proposed resolution:</b></p> +<ol> +<li> +<p> +In 20.5.2 [tuple.tuple], class <tt>tuple</tt> just before member <tt>swap</tt> please +change as indicated: +</p> +<p><i>[ +This fixes an editorial loss between N2798 to N2800 +]</i></p> + +<blockquote><pre>template <class... UTypes> +requires HasAssign<Types, const UTypes&>... +<ins>tuple& operator=(const pair<UTypes...>&);</ins> + +template <class... UTypes> +requires HasAssign<Types, RvalueOf<UTypes>::type>... +<ins>tuple& operator=(pair<UTypes...>&&);</ins> </pre></blockquote> +</li> +<li> +<p> +In 20.5.2.1 [tuple.cnstr], starting just before p. 11 please remove +as indicated: +</p> + +<blockquote><pre><del>requires MoveAssignable<Types>... tuple& operator=(tuple&& u);</del> +</pre> +<blockquote> +<p> +<del>-11- <i>Effects:</i> Move-assigns each element of <tt>u</tt> to the corresponding +element of <tt>*this</tt>.</del> +</p> <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. +<del>-12- <i>Returns:</i> <tt>*this</tt>.</del> </p> +</blockquote> +</blockquote> </li> +</ol> + + + + + +<hr> +<h3><a name="918"></a>918. Swap for tuple needs to be conceptualized</h3> +<p><b>Section:</b> 20.5.2.6 [tuple.swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">Tentatively NAD</a> + <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-10-04 <b>Last modified:</b> 2009-05-23</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD">Tentatively NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#522">522</a> was accepted after <tt>tuple</tt> had been conceptualized, +therefore this step needs to be completed. +</p> + +<p><i>[ +Post Summit Daniel adds +]</i></p> + + +<blockquote> +This is now NAD Editorial (addressed by +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2844.html">N2844</a>) +except for item 3 in the proposed wording. +</blockquote> + +<p><i>[ +2009-05-01 Daniel adds: +]</i></p> + + +<blockquote> +As of the recent WP +(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2857.pdf">N2857</a>), +this issue is now completely covered by editorial +changes (including the third bullet), therefore I unconditionally recommend +NAD. +</blockquote> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +<p> +We observed that all the proposed changes have already been applied to the +Working Draft, rendering this issue moot. +</p> +<p> +Move to NAD. +</p> +</blockquote> + + + +<p><b>Proposed resolution:</b></p> +<ol> <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. +In both 20.5.1 [tuple.general]/2 and 20.5.2.7 [tuple.special] change </p> + +<blockquote><pre>template <<del>class</del> <ins>Swappable</ins>... Types> +void swap(tuple<Types...>& x, tuple<Types...>& y); +</pre></blockquote> + +</li> + +<li> <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>. +In 20.5.2 [tuple.tuple], class <tt>tuple</tt> definition and in +20.5.2.6 [tuple.swap], change </p> + +<blockquote><pre><ins>requires Swappable<Types>...</ins>void swap(tuple&); +</pre></blockquote> + </li> + <li> <p> -A user can pass an array of 64-bit integers and all the bits will be - used. +In 20.5.2.6 [tuple.swap] remove the current requires-clause, which says: </p> + +<blockquote> +<del><i>Requires:</i> Each type in <tt>Types</tt> shall be <tt>Swappable</tt></del> +</blockquote> +</li> + +</ol> + + + + + + +<hr> +<h3><a name="919"></a>919. (forward_)list specialized remove algorithms are over constrained</h3> +<p><b>Section:</b> 23.3.3.5 [forwardlist.ops], 23.3.4.4 [list.ops] <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>Opened:</b> 2008-10-06 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#forwardlist.ops">active issues</a> in [forwardlist.ops].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forwardlist.ops">issues</a> in [forwardlist.ops].</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> - 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 +The signatures of <tt>forwardlist::remove</tt> and <tt>list::remove</tt> +defined in 23.3.3.5 [forwardlist.ops] before 11 + 23.3.4.4 [list.ops] before 15: </p> -<blockquote><pre>unsigned long s[] = {1, 2, 3, 4}; -seed_seq q(s, s+4); + +<blockquote><pre>requires EqualityComparable<T> void remove(const T& value); </pre></blockquote> + +<p> +are asymmetric to their predicate variants (which only require +<tt>Predicate</tt>, <em>not</em> <tt>EquivalenceRelation</tt>) and with the free algorithm +remove (which only require <tt>HasEqualTo</tt>). Also, nothing in the +pre-concept WP +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a> +implies that <tt>EqualityComparable</tt> should +be the intended requirement. +</p> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +<p> +We agree with the proposed resolution, +but would like additional input from concepts experts. +</p> +<p> +Move to Review. +</p> +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<ol type="A"> +<li> <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. +Replace in 23.3.3.5 [forwardlist.ops] before 11 and in 23.3.4.4 [list.ops] before 15 </p> + +<blockquote><pre>requires <del>EqualityComparable<T></del> <ins>HasEqualTo<T, T></ins> void remove(const T& value); +</pre></blockquote> </li> -</ul> +</ol> + + + + + +<hr> +<h3><a name="920"></a>920. Ref-qualification support in the library</h3> +<p><b>Section:</b> 20.7.15 [func.memfn] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> + <b>Submitter:</b> Bronek Kozicki <b>Opened:</b> 2008-10-06 <b>Last modified:</b> 2009-05-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> -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>. +Daniel Krügler wrote: +</p> + +<blockquote> +<p> +Shouldn't above list be completed for &- and &&-qualified +member functions This would cause to add: +</p> +<blockquote><pre>template<Returnable R, class T, CopyConstructible... Args> +unspecified mem_fn(R (T::* pm)(Args...) &); +template<Returnable R, class T, CopyConstructible... Args> +unspecified mem_fn(R (T::* pm)(Args...) const &); +template<Returnable R, class T, CopyConstructible... Args> +unspecified mem_fn(R (T::* pm)(Args...) volatile &); +template<Returnable R, class T, CopyConstructible... Args> +unspecified mem_fn(R (T::* pm)(Args...) const volatile &); +template<Returnable R, class T, CopyConstructible... Args> +unspecified mem_fn(R (T::* pm)(Args...) &&); +template<Returnable R, class T, CopyConstructible... Args> +unspecified mem_fn(R (T::* pm)(Args...) const &&); +template<Returnable R, class T, CopyConstructible... Args> +unspecified mem_fn(R (T::* pm)(Args...) volatile &&); +template<Returnable R, class T, CopyConstructible... Args> +unspecified mem_fn(R (T::* pm)(Args...) const volatile &&); +</pre></blockquote> + +</blockquote> + +<p> +yes, absolutely. Thanks for spotting this. Without this change <tt>mem_fn</tt> +cannot be initialized from pointer to ref-qualified member function. I +believe semantics of such function pointer is well defined. </p> <p><i>[ -Bellevue: +Post Summit Daniel provided wording. ]</i></p> +<p><i>[ +Batavia (2009-05): +]</i></p> + <blockquote> -Walter needs to ask Fermilab for guidance. Defer till tomorrow. Bill likes the proposed resolution. +<p> +We need to think about whether we really want to go down the proposed path +of combinatorial explosion. +Perhaps a Note would suffice. +</p> +<p> +We would really like to have an implementation before proceeding. +</p> +<p> +Move to Open, and recommend this be deferred until after the next +Committee Draft has been issued. +</p> </blockquote> + +<p><b>Proposed resolution:</b></p> +<ol> +<li> +<p> +In 20.7 [function.objects]/2, header <tt><functional></tt> synopsis, just after +the section "// 20.6.15, member function adaptors::" add the following +declarations to the existing list: +</p> +<blockquote><pre>template<Returnable R, class T, CopyConstructible... Args> + <i>unspecified</i> mem_fn(R (T::* pm)(Args...) &); +template<Returnable R, class T, CopyConstructible... Args> + <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const &); +template<Returnable R, class T, CopyConstructible... Args> + <i>unspecified</i> mem_fn(R (T::* pm)(Args...) volatile &); +template<Returnable R, class T, CopyConstructible... Args> + <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const volatile &); +template<Returnable R, class T, CopyConstructible... Args> + <i>unspecified</i> mem_fn(R (T::* pm)(Args...) &&); +template<Returnable R, class T, CopyConstructible... Args> + <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const &&); +template<Returnable R, class T, CopyConstructible... Args> + <i>unspecified</i> mem_fn(R (T::* pm)(Args...) volatile &&); +template<Returnable R, class T, CopyConstructible... Args> + <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const volatile &&); +</pre></blockquote> +</li> +<li> +<p> +In 20.7.15 [func.memfn] add the following declarations to the existing +list: +</p> +<blockquote><pre>template<Returnable R, class T, CopyConstructible... Args> + <i>unspecified</i> mem_fn(R (T::* pm)(Args...) &); +template<Returnable R, class T, CopyConstructible... Args> + <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const &); +template<Returnable R, class T, CopyConstructible... Args> + <i>unspecified</i> mem_fn(R (T::* pm)(Args...) volatile &); +template<Returnable R, class T, CopyConstructible... Args> + <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const volatile &); +template<Returnable R, class T, CopyConstructible... Args> + <i>unspecified</i> mem_fn(R (T::* pm)(Args...) &&); +template<Returnable R, class T, CopyConstructible... Args> + <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const &&); +template<Returnable R, class T, CopyConstructible... Args> + <i>unspecified</i> mem_fn(R (T::* pm)(Args...) volatile &&); +template<Returnable R, class T, CopyConstructible... Args> + <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const volatile &&); +</pre></blockquote> +</li> +</ol> +<p> +The following text, most notably p.2 and p.3 which discuss influence +of the cv-qualification on the definition of the base class's first template +parameter remains unchanged. +</p> + + + + + +<hr> +<h3><a name="921"></a>921. Rational Arithmetic should use template aliases</h3> +<p><b>Section:</b> 20.4.1 [ratio.ratio] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> + <b>Submitter:</b> Pablo Halpern <b>Opened:</b> 2008-10-07 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#ratio.ratio">active issues</a> in [ratio.ratio].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ratio.ratio">issues</a> in [ratio.ratio].</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 compile-time functions that operate on <tt>ratio<N,D></tt> require the +cumbersome and error-prone "evaluation" of a <tt>type</tt> member using a +meta-programming style that predates the invention of template aliases. +Thus, multiplying three ratios <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> requires the expression: +</p> + +<blockquote><pre>ratio_multiply<a, ratio_multiply<b, c>::type>::type +</pre></blockquote> + +<p> +The simpler expression: +</p> + +<blockquote><pre>ratio_multiply<a, ratio_multiply<b, c>> +</pre></blockquote> + +<p> +Could be used by if template aliases were employed in the definitions. +</p> + <p><i>[ -Sophia Antipolis: +Post Summit: ]</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. +Jens: not a complete proposed resolution: "would need to make similar change" </p> <p> -Jens: the new algorithm looks perfectly portable +Consensus: We agree with the direction of the issue. </p> <p> -Marc Paterno to review off-line. +Recommend Open. </p> +</blockquote> + +<p><i>[ +2009-05-11 Daniel adds: +]</i></p> + + +<blockquote> <p> -Modify the proposed resolution to read "Constructs a seed_seq object by the following algorithm ..." +Personally I'm <em>not</em> in favor for the addition of: </p> +<blockquote><pre>typedef ratio type; +</pre></blockquote> <p> -Disposition: move to review; unanimous consent. +For a reader of the +standard it's usage or purpose is unclear. I haven't seen similar examples +of attempts to satisfy non-feature complete compilers. </p> +</blockquote> + +<p><i>[ +2009-05-11 Pablo adds: +]</i></p> + + +<blockquote> <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>) +The addition of type to the <tt>ratio</tt> template allows the previous style +(i.e., in the prototype implementations) to remain valid and permits the +use of transitional library implementations for C++03 compilers. I do +not feel strongly about its inclusion, however, and leave it up to the +reviewers to decide. </p> </blockquote> +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +Bill asks for additional discussion in the issue +that spells out more details of the implementation. +Howard points us to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#948">948</a> +which has at least most of the requested details. +Tom is strongly in favor of overflow-checking at compile time. +Pete points out that there is no change of functionality implied. +We agree with the proposed resolution, +but recommend moving the issue to Review +to allow time to improve the discussion if needed. +</blockquote> <p><b>Proposed resolution:</b></p> + + + <ol start="0"> +<li> <p> -Change 26.4.7.1 [rand.util.seedseq]: +In 20.4 [ratio]/3 change as indicated: </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); +<blockquote><pre>// ratio arithmetic +template <class R1, class R2> <del>struct</del><ins>using</ins> ratio_add<ins> = <em>see below</em></ins>; +template <class R1, class R2> <del>struct</del><ins>using</ins> ratio_subtract<ins> = <em>see below</em></ins>; +template <class R1, class R2> <del>struct</del><ins>using</ins> ratio_multiply<ins> = <em>see below</em></ins>; +template <class R1, class R2> <del>struct</del><ins>using</ins> ratio_divide<ins> = <em>see below</em></ins>; +</pre></blockquote> +</li> +<li> +<p> +In 20.4.1 [ratio.ratio], change as indicated: +</p> +<blockquote><pre>namespace std { + template <intmax_t N, intmax_t D = 1> + class ratio { + public: + <ins>typedef ratio type;</ins> + static const intmax_t num; + static const intmax_t den; + }; +} +</pre></blockquote> +</li> +<li> +<p> +In 20.4.2 [ratio.arithmetic] change as indicated: +</p> + +<blockquote><pre>template <class R1, class R2> <del>struct</del><ins>using</ins> ratio_add<ins> = <em>see below</em></ins><del>{ + typedef <em>see below</em> type; +}</del>; </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. +1 The <del>nested typedef</del> type <tt><ins>ratio_add<R1, R2></ins></tt> +shall be a synonym for <tt>ratio<T1, T2></tt> +where <tt>T1</tt> has the value <tt>R1::num * R2::den + R2::num * R1::den</tt> and <tt>T2</tt> +has the value <tt>R1::den * R2::den</tt>. </p> +</blockquote> +</blockquote> +<blockquote><pre>template <class R1, class R2> <del>struct</del><ins>using</ins> ratio_subtract<ins> = <em>see below</em></ins><del>{ + typedef <em>see below</em> type; +}</del>; +</pre> +<blockquote> <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> +2 The <del>nested typedef</del> type <tt><ins>ratio_subtract<R1, R2></ins></tt> +shall be a synonym for <tt>ratio<T1, T2></tt> +where <tt>T1</tt> has the value <tt>R1::num * R2::den - R2::num * R1::den</tt> and <tt>T2</tt> +has the value <tt>R1::den * R2::den</tt>. </p> +</blockquote> +</blockquote> +<blockquote><pre>template <class R1, class R2> <del>struct</del><ins>using</ins> ratio_multiply<ins> = <em>see below</em></ins><del>{ + typedef <em>see below</em> type; +}</del>; +</pre> +<blockquote> <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> +3 The <del>nested typedef</del> type <tt><ins>ratio_multiply<R1, R2></ins></tt> +shall be a synonym for <tt>ratio<T1, T2></tt> +where <tt>T1</tt> has the value <tt>R1::num * R2::num</tt> and <tt>T2</tt> has the value <tt>R1::den * R2::den</tt>. </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> +</blockquote> +<blockquote><pre>template <class R1, class R2> <del>struct</del><ins>using</ins> ratio_divide<ins> = <em>see below</em></ins><del>{ + typedef <em>see below</em> type; +}</del>; +</pre> <blockquote> -<pre><ins> -for (InputIterator s = begin; s != end; ++s) - v.push_back((*s) mod 2<sup>32</sup>); -</ins></pre> +<p> +4 The <del>nested typedef</del> type <tt><ins>ratio_divide<R1, R2></ins></tt> +shall be a synonym for <tt>ratio<T1, T2></tt> +where <tt>T1</tt> has the value <tt>R1::num * R2::den</tt> and <tt>T2</tt> has the value <tt>R1::den * R2::num</tt>. +</p> +</blockquote> </blockquote> +</li> +<li> +<p> +In 20.9.3.1 [time.duration.cons]/4 change as indicated: +</p> +<blockquote> +<p> +<i>Requires:</i> <tt>treat_as_floating_point<rep>::value</tt> shall be true or +<tt>ratio_divide<Period2, period>::<del>type::</del>den</tt> shall be 1.[..] +</p> </blockquote> +</li> +<li> +<p> +In 20.9.3.7 [time.duration.cast]/2 change as indicated: +</p> +<blockquote> +<p> +<i>Returns:</i> Let CF be <tt>ratio_divide<Period, typename +ToDuration::period><del>::type</del></tt>, and [..] +</p> </blockquote> +</li> +</ol> <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> +<h3><a name="922"></a>922. [func.bind.place] Number of placeholders</h3> +<p><b>Section:</b> B [implimits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> Sohail Somani <b>Opened:</b> 2008-10-11 <b>Last modified:</b> 2009-03-13</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p> <p><b>Discussion:</b></p> -<ol type="A"> +<p><b>Addresses DE 24</b></p> + +<p> +With respect to the section 20.7.12.1.4 [func.bind.place]: +</p> +<p> +TR1 dropped some suggested implementation quantities for the number of +placeholders. The purpose of this defect is to put these back for C++0x. +</p> + +<p><i>[ +Post Summit: +]</i></p> + + +<blockquote> +<p> +see DE 24 +</p> +<p> +Recommend applying the proposed resolution from DE 24, with that +Tentatively Ready. +</p> +</blockquote> + +<b>Original proposed resolution:</b> + +<p> +Add 20.7.12.1.4 [func.bind.place]/2: +</p> + +<blockquote> +While the exact number of placeholders (<tt>_M</tt>) is implementation defined, +this number shall be at least 10. +</blockquote> + + + +<p><b>Proposed resolution:</b></p> + +<p> +Add to B [implimits]: +</p> + +<ul> <li> +Number of placeholders (20.7.12.1.4 [func.bind.place]) [10]. +</li> +</ul> + + + + + + +<hr> +<h3><a name="923"></a>923. atomics with floating-point </h3> +<p><b>Section:</b> 29 [atomics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> + <b>Submitter:</b> Herb Sutter <b>Opened:</b> 2008-10-17 <b>Last modified:</b> 2009-05-01</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#atomics">active issues</a> in [atomics].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics">issues</a> in [atomics].</p> +<p><b>View all 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> -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>: +Right now, C++0x doesn't have <tt>atomic<float></tt>. We're thinking of adding +the words to support it for TR2 (note: that would be slightly +post-C++0x). If we need it, we could probably add the words. </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: +<b>Proposed resolutions:</b> Using <tt>atomic<FP>::compare_exchange</tt> (weak or +strong) should be either: </p> + <ol> <li> -The classes are not <tt>(Copy)Assignable</tt>, which is probably not the intent. +ill-formed, or </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. +well-defined. </li> </ol> + <p> -The simple fix would be to replace the reference by a pointer member. +I propose Option 1 for C++0x for expediency. If someone wants to argue +for Option 2, they need to say what exactly they want <tt>compare_exchange</tt> +to mean in this case (IIRC, C++0x doesn't even assume IEEE 754). </p> -</li> +<p><i>[ +Summit: +]</i></p> + + +<blockquote> +Move to open. Blocked until concepts for atomics are addressed. +</blockquote> + +<p><i>[ +Post Summit Anthony adds: +]</i></p> + + +<blockquote> +<p> +Recommend NAD. C++0x does have <tt>std::atomic<float></tt>, and both +<tt>compare_exchange_weak</tt> and <tt>compare_exchange_strong</tt> are well-defined in +this case. Maybe change the note in 29.6 [atomics.types.operations] paragraph 20 to: +</p> + +<blockquote> +<p> +[<i>Note:</i> The effect of the compare-and-exchange operations is +</p> +<blockquote><pre>if (!memcmp(object,expected,sizeof(*object))) + *object = desired; +else + *expected = *object; +</pre></blockquote> + +<p> +This may result in failed comparisons for values that compare equal if +the underlying type has padding bits or alternate representations of +the same value. <i>-- end note</i>] +</p> +</blockquote> + +</blockquote> + + + +<p><b>Proposed resolution:</b></p> +<p> +Change the note in 29.6 [atomics.types.operations] paragraph 20 to: +</p> + +<blockquote> +<p> +[<i>Note:</i> The effect of the compare-and-exchange operations is +</p> +<blockquote><pre>if (<del>*object == *expected</del> <ins>!memcmp(object,expected,sizeof(*object))</ins>) + *object = desired; +else + *expected = *object; +</pre></blockquote> + +<p><ins> +This may result in failed comparisons for values that compare equal if +the underlying type has padding bits or alternate representations of +the same value.</ins> <i>-- end note</i>] +</p> +</blockquote> + + + + + + +<hr> +<h3><a name="924"></a>924. structs with internal padding</h3> +<p><b>Section:</b> 29 [atomics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> + <b>Submitter:</b> Herb Sutter <b>Opened:</b> 2008-10-17 <b>Last modified:</b> 2009-03-22</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#atomics">active issues</a> in [atomics].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics">issues</a> in [atomics].</p> +<p><b>View all 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> +Right now, the <tt>compare_exchange_weak</tt> loop should rapidly converge on the +padding contents. But <tt>compare_exchange_strong</tt> will require a bit more +compiler work to ignore padding for comparison purposes. +</p> +<p> +Note that this isn't a problem for structs with no padding, and we do +already have one portable way to ensure that there is no padding that +covers the key use cases: Have elements be the same type. I suspect that +the greatest need is for a structure of two pointers, which has no +padding problem. I suspect the second need is a structure of a pointer +and some form of an integer. If that integer is <tt>intptr_t</tt>, there will be +no padding. +</p> +<p> +Related but separable issue: For unused bitfields, or other unused +fields for that matter, we should probably say it's the programmer's +responsibility to set them to zero or otherwise ensure they'll be +ignored by <tt>memcmp</tt>. +</p> + +<p> +<b>Proposed resolutions:</b> Using +<tt>atomic<struct-with-padding>::compare_exchange_strong</tt> should be either: +</p> + +<ol> <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). +ill-formed, or </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>). +well-defined. </li> </ol> +<p> +I propose Option 1 for C++0x for expediency, though I'm not sure how to +say it. I would be happy with Option 2, which I believe would mean that +<tt>compare_exchange_strong</tt> would be implemented to avoid comparing padding +bytes, or something equivalent such as always zeroing out padding when +loading/storing/comparing. (Either implementation might require compiler +support.) +</p> + <p><i>[ -Sophia Antipolis: +Summit: ]</i></p> <blockquote> +Move to open. Blocked until concepts for atomics are addressed. +</blockquote> + +<p><i>[ +Post Summit Anthony adds: +]</i></p> + + +<blockquote> +The resoultion of LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#923">923</a> should resolve this issue as well. +</blockquote> + + + +<p><b>Proposed resolution:</b></p> +<p> +</p> + + + + + +<hr> +<h3><a name="925"></a>925. <tt>shared_ptr</tt>'s explicit conversion from <tt>unique_ptr</tt></h3> +<p><b>Section:</b> 20.8.13.2.1 [util.smartptr.shared.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> Rodolfo Lima <b>Opened:</b> 2008-10-12 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#util.smartptr.shared.const">active issues</a> in [util.smartptr.shared.const].</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#Tentatively%20Ready">Tentatively Ready</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The current working draft +(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdf">N2798</a>), +section 20.8.13.2.1 [util.smartptr.shared.const] declares +<tt>shared_ptr</tt>'s constructor that takes a rvalue reference to <tt>unique_ptr</tt> and +<tt>auto_ptr</tt> as being explicit, affecting several valid smart pointer use +cases that would take advantage of this conversion being implicit, for +example: +</p> + +<blockquote><pre>class A; +std::unique_ptr<A> create(); +void process(std::shared_ptr<A> obj); + +int main() +{ + process(create()); // use case #1 + std::unique_ptr<A> uobj = create(); + process(std::move(uobj)); // use case #2 + return 0; +} +</pre></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>. +If <tt>unique_ptr</tt> to <tt>shared_ptr</tt> conversions are explicit, the above lines +should be written: </p> + +<blockquote><pre>process(std::shared_ptr<A>(create())); // use case #1 +process(std::shared_ptr<A>(std::move(uobj))); // use case #2 +</pre></blockquote> + <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). +The extra cast required doesn't seems to give any benefits to the user, +nor protects him of any unintended conversions, this being the raison +d'etre of explicit constructors. </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>. +It seems that this constructor was made explicit to mimic the conversion +from <tt>auto_ptr</tt> in pre-rvalue reference days, which accepts both lvalue and +rvalue references. Although this decision was valid back then, C++0x +allows the user to express in a clear and non verbose manner when he wants +move semantics to be employed, be it implicitly (use case 1) or explicitly +(use case 2). </p> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> <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. +Howard and Alisdair like the motivating use cases +and the proposed resolution. </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. +Move to Tentatively Ready. </p> </blockquote> - <p><b>Proposed resolution:</b></p> - <p> -Resolution of part A: +In both 20.8.13.2 [util.smartptr.shared] paragraph 1 and +20.8.13.2.1 [util.smartptr.shared.const] change: </p> -<blockquote> + +<blockquote><pre>template <class Y> <del>explicit</del> shared_ptr(auto_ptr<Y> &&r); +template <class Y, class D> <del>explicit</del> shared_ptr(unique_ptr<Y, D> &&r); +</pre></blockquote> + + + + + + +<hr> +<h3><a name="926"></a>926. Sequentially consistent fences, relaxed operations and modification order</h3> +<p><b>Section:</b> 29.3 [atomics.order] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> + <b>Submitter:</b> Anthony Williams <b>Opened:</b> 2008-10-19 <b>Last modified:</b> 2009-03-22</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.order">issues</a> in [atomics.order].</p> +<p><b>View all 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><b>Addresses UK 313</b></p> + <p> -Change 19.4.2.1 [syserr.errcode.overview] Class error_code overview synopsis as indicated: +There was an interesting issue raised over on comp.programming.threads +today regarding the following example </p> -<blockquote><pre>private: - int val_; // exposition only - const error_category<del>&</del><ins>*</ins> cat_; // exposition only +<blockquote><pre>// Thread 1: +x.store(1, memory_order_relaxed); // SX +atomic_thread_fence(memory_order_seq_cst); // F1 +y.store(1, memory_order_relaxed); // SY1 +atomic_thread_fence(memory_order_seq_cst); // F2 +r1 = y.load(memory_order_relaxed); // RY + +// Thread 2: +y.store(0, memory_order_relaxed); // SY2 +atomic_thread_fence(memory_order_seq_cst); // F3 +r2 = x.load(memory_order_relaxed); // RX </pre></blockquote> <p> -Change 19.4.2.2 [syserr.errcode.constructors] Class error_code constructors as indicated: +is the outcome <tt>r1 == 0</tt> and <tt>r2 == 0</tt> possible? +</p> +<p> +I think the intent is that this is not possible, but I am not sure the +wording guarantees that. Here is my analysis: +</p> +<p> +Since all the fences are SC, there must be a total order between them. +<tt>F1</tt> must be before <tt>F2</tt> in that order since they are in +the same thread. Therefore <tt>F3</tt> is either before <tt>F1</tt>, +between <tt>F1</tt> and <tt>F2</tt> or after <tt>F2</tt>. +</p> +<p> +If <tt>F3</tt> is <em>after</em> <tt>F2</tt>, then we can apply 29.3 [atomics.order]p5 from +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdf">N2798</a>: </p> <blockquote> -<pre>error_code(); -</pre> -<blockquote> +For atomic operations <tt>A</tt> and <tt>B</tt> on an atomic object +<tt>M</tt>, where <tt>A</tt> modifies <tt>M</tt> and <tt>B</tt> takes +its value, if there are <tt>memory_order_seq_cst</tt> fences <tt>X</tt> +and <tt>Y</tt> such that <tt>A</tt> is sequenced before <tt>X</tt>, +<tt>Y</tt> is sequenced before <tt>B</tt>, and <tt>X</tt> precedes +<tt>Y</tt> in <tt>S</tt>, then <tt>B</tt> observes either the effects of +<tt>A</tt> or a later modification of <tt>M</tt> in its modification +order. +</blockquote> + <p> -<i>Effects:</i> Constructs an object of type <tt>error_code</tt>. +In this case, <tt>A</tt> is <tt>SX</tt>, <tt>B</tt> is <tt>RX</tt>, the +fence <tt>X</tt> is <tt>F2</tt> and the fence <tt>Y</tt> is <tt>F3</tt>, +so <tt>RX</tt> must see 1. </p> <p> -<i>Postconditions:</i> <tt>val_ == 0</tt> and <tt>cat_ == <ins>&</ins>system_category</tt>. +If <tt>F3</tt> is <em>before</em> <tt>F2</tt>, this doesn't apply, but +<tt>F3</tt> can therefore be before or after <tt>F1</tt>. </p> <p> -<i>Throws:</i> Nothing. +If <tt>F3</tt> is <em>after</em> <tt>F1</tt>, the same logic applies, but this +time the fence <tt>X</tt> is <tt>F1</tt>. Therefore again, <tt>RX</tt> +must see 1. </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>. +Finally we have the case that <tt>F3</tt> is <em>before</em> <tt>F1</tt> +in the SC ordering. There are now no guarantees about <tt>RX</tt>, and +<tt>RX</tt> can see <tt>r2==0</tt>. </p> <p> -<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&</ins>cat</tt>. +We can apply 29.3 [atomics.order]p5 again. This time, +<tt>A</tt> is <tt>SY2</tt>, <tt>B</tt> is <tt>RY</tt>, <tt>X</tt> is +<tt>F3</tt> and <tt>Y</tt> is <tt>F1</tt>. Thus <tt>RY</tt> must observe +the effects of <tt>SY2</tt> or a later modification of <tt>y</tt> in its +modification order. </p> <p> -<i>Throws:</i> Nothing. +Since <tt>SY1</tt> is sequenced before <tt>RY</tt>, <tt>RY</tt> must +observe the effects of <tt>SY1</tt> or a later modification of +<tt>y</tt> in its modification order. </p> -</blockquote> +<p> +In order to ensure that <tt>RY</tt> sees <tt>(r1==1)</tt>, we must see +that <tt>SY1</tt> is later in the modification order of <tt>y</tt> than +<tt>SY2</tt>. +</p> +<p> +We're now skating on thin ice. Conceptually, <tt>SY2</tt> happens-before +<tt>F3</tt>, <tt>F3</tt> is SC-ordered before <tt>F1</tt>, <tt>F1</tt> +happens-before <tt>SY1</tt>, so <tt>SY1</tt> is later in the +modification order <tt>M</tt> of <tt>y</tt>, and <tt>RY</tt> must see +the result of <tt>SY1</tt> (<tt>r1==1</tt>). However, I don't think the +words are clear on that. +</p> + +<p><i>[ +Post Summit Hans adds: +]</i></p> + + +<blockquote> +<p> +In my (Hans') view, our definition of fences will always be weaker than +what particular hardware will guarantee. <tt>Memory_order_seq_cst</tt> fences +inherently don't guarantee sequential consistency anyway, for good +reasons (e.g. because they can't enforce a total order on stores). + Hence I don't think the issue demonstrates a gross failure to achieve +what we intended to achieve. The example in question is a bit esoteric. + Hence, in my view, living with the status quo certainly wouldn't be a +disaster either. +</p> +<p> +In any case, we should probably add text along the lines of the +following between p5 and p6 in 29.3 [atomics.order]: +</p> +<blockquote> +[Note: <tt>Memory_order_seq_cst</tt> only ensures sequential consistency for a +data-race-free program that uses exclusively <tt>memory_order_seq_cst</tt> +operations. Any use of weaker ordering will invalidate this guarantee +unless extreme care is used. In particular, <tt>memory_order_seq_cst</tt> fences +only ensure a total order for the fences themselves. They cannot, in +general, be used to restore sequential consistency for atomic operations +with weaker ordering specifications.] </blockquote> <p> -Change 19.4.2.3 [syserr.errcode.modifiers] Class error_code modifiers as indicated: +Also see thread beginning at c++std-lib-23271. </p> -<blockquote> -<pre>void assign(int val, const error_category& cat); -</pre> +</blockquote> + +<p><i>[ +Herve's correction: +]</i></p> + <blockquote> <p> -<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&</ins>cat</tt>. +Minor point, and sorry for the knee jerk reaction: I admit to having +no knowledge of Memory_order_seq_cst, but my former boss (John Lakos) +has ingrained an automatic introspection on the use of "only". I +think you meant: </p> + +<blockquote> +[Note: <tt>Memory_order_seq_cst</tt> ensures sequential consistency only +for . . . . In particular, <tt>memory_order_seq_cst</tt> fences ensure a +total order only for . . . +</blockquote> <p> -<i>Throws:</i> Nothing. +Unless, of course, <tt>Memory_order_seq_cst</tt> really do nothing but ensure +sequential consistency for a data-race-free program that uses +exclusively <tt>memory_order_seq_cst</tt> operations. </p> </blockquote> + + + +<p><b>Proposed resolution:</b></p> +<p> +Add a new paragraph after 29.3 [atomics.order]p5 that says +</p> + +<blockquote> +For atomic operations <tt>A</tt> and <tt>B</tt> on an atomic object +<tt>M</tt>, where <tt>A</tt> and <tt>B</tt> modify <tt>M</tt>, if there +are <tt>memory_order_seq_cst</tt> fences <tt>X</tt> and <tt>Y</tt> such +that <tt>A</tt> is sequenced before <tt>X</tt>, <tt>Y</tt> is sequenced +before <tt>B</tt>, and <tt>X</tt> precedes <tt>Y</tt> in <tt>S</tt>, +then <tt>B</tt> occurs later than <tt>A</tt> in the modifiction order of +<tt>M</tt>. </blockquote> + + + + +<hr> +<h3><a name="927"></a>927. <tt>Dereferenceable</tt> should be <tt>HasDereference</tt></h3> +<p><b>Section:</b> 20.8.2.2 [allocator.concepts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Tentatively NAD Editorial</a> + <b>Submitter:</b> Pablo Halpern <b>Opened:</b> 2008-10-23 <b>Last modified:</b> 2009-05-23</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD%20Editorial">Tentatively NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> <p> -Change 19.4.2.4 [syserr.errcode.observers] Class error_code observers as indicated: +20.8.2.2 [allocator.concepts] contains a reference to a concept named +<tt>Dereferenceable</tt>. No such concept exists. </p> +<p><i>[ +Daniel adds 2009-02-14: +]</i></p> + + <blockquote> -const error_category& category() const; +The proposal given in the paper +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2829.pdf">N2829</a> +would automatically resolve this issue. +</blockquote> + + +<p><i>[ +Batavia (2009-05): +]</i></p> + <blockquote> <p> -<i>Returns:</i> <tt><ins>*</ins>cat_</tt>. +This particular set of changes has already been made. +There are two related changes later on (and possibly also an earlier Example); +these can be handled editorially. </p> <p> -<i>Throws:</i> Nothing. +Move to NAD Editorial. </p> </blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +Change all uses of the concept <tt>Dereferenceable</tt> to +<tt>HasDereference</tt> in 20.8.2.2 [allocator.concepts]. +</p> + + + + + +<hr> +<h3><a name="928"></a>928. Wrong concepts used for <tt>tuple</tt>'s comparison operators</h3> +<p><b>Section:</b> 20.5.2.5 [tuple.rel] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> Joe Gottman <b>Opened:</b> 2008-10-28 <b>Last modified:</b> 2009-03-09</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple.rel">issues</a> in [tuple.rel].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p> +<p><b>Discussion:</b></p> +<p> +In the latest working draft for C++0x, <tt>tuple</tt>'s <tt>operator==</tt> and <tt>operator<</tt> +are declared as +</p> + +<blockquote><pre>template<class... TTypes, class... UTypes> + requires EqualityComparable<TTypes, UTypes>... + bool operator==(const tuple<TTypes...>& t, const tuple<UTypes...>& u); +</pre></blockquote> + +<p> +and +</p> + +<blockquote><pre>template<class... TTypes, class... UTypes> + requires LessThanComparable<TTypes, UTypes>... + bool operator<(const tuple<TTypes...>& t, const tuple<UTypes...>& u); +</pre></blockquote> + +<p> +But the concepts <tt>EqualityComparable</tt> and <tt>LessThanComparable</tt> only take one +parameter, not two. Also, even if <tt>LessThanComparable</tt> could take two +parameters, the definition of <tt>tuple::operator<()</tt> should also require +</p> + +<blockquote><pre>LessThanComparable<UTypes, TTypes>... // (note the order) +</pre></blockquote> + +<p> +since the algorithm for <tt>tuple::operator<</tt> is the following (pseudo-code) +</p> + +<blockquote><pre>for (size_t N = 0; N < sizeof...(TTypes); ++N) { + if (get<N>(t) < get<N>(u) return true; + else if ((get<N>(u) < get<N>(t)) return false; +} + +return false; +</pre></blockquote> + +<p> +Similar problems hold for <tt>tuples</tt>'s other comparison operators. +</p> + +<p><i>[ +Post Summit: +]</i></p> + + +<blockquote> +Recommend Tentatively Ready. </blockquote> + + +<p><b>Proposed resolution:</b></p> <p> -Change 19.4.3.1 [syserr.errcondition.overview] Class error_condition overview synopsis as indicated: +In 20.5.1 [tuple.general] and 20.5.2.5 [tuple.rel] change: </p> -<blockquote><pre>private: - int val_; // exposition only - const error_category<del>&</del><ins>*</ins> cat_; // exposition only +<blockquote><pre>template<class... TTypes, class... UTypes> + requires <del>EqualityComparable</del><ins>HasEqualTo</ins><TTypes, UTypes>... + bool operator==(const tuple<TTypes...>&, const tuple<UTypes...>&); + +template<class... TTypes, class... UTypes> + requires <del>LessThanComparable</del><ins>HasLess</ins><TTypes, UTypes>... <ins>&& HasLess<UTypes, TTypes>...</ins> + bool operator<(const tuple<TTypes...>&, const tuple<UTypes...>&); + +template<class... TTypes, class... UTypes> + requires <del>EqualityComparable</del><ins>HasEqualTo</ins><TTypes, UTypes>... + bool operator!=(const tuple<TTypes...>&, const tuple<UTypes...>&); + +template<class... TTypes, class... UTypes> + requires <del>LessThanComparable</del><ins>HasLess</ins><<del>U</del><ins>T</ins>Types, <del>T</del><ins>U</ins>Types>... <ins>&& HasLess<UTypes, TTypes>...</ins> + bool operator>(const tuple<TTypes...>&, const tuple<UTypes...>&); + +template<class... TTypes, class... UTypes> + requires <del>LessThanComparable</del><ins>HasLess</ins><<del>U</del><ins>T</ins>Types, <del>T</del><ins>U</ins>Types>... <ins>&& HasLess<UTypes, TTypes>...</ins> + bool operator<=(const tuple<TTypes...>&, const tuple<UTypes...>&); + +template<class... TTypes, class... UTypes> + requires <del>LessThanComparable</del><ins>HasLess</ins><TTypes, UTypes>... <ins>&& HasLess<UTypes, TTypes>...</ins> + bool operator>=(const tuple<TTypes...>&, const tuple<UTypes...>&); </pre></blockquote> + + + + +<hr> +<h3><a name="929"></a>929. Thread constructor</h3> +<p><b>Section:</b> 30.3.1.2 [thread.thread.constr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> + <b>Submitter:</b> Anthony Williams <b>Opened:</b> 2008-10-23 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.thread.constr">active issues</a> in [thread.thread.constr].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.thread.constr">issues</a> in [thread.thread.constr].</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><b>Addresses UK 323</b></p> + <p> -Change 19.4.3.2 [syserr.errcondition.constructors] Class error_condition constructors as indicated: +The <tt>thread</tt> constructor for starting a new thread with a function and +arguments is overly constrained by the signature requiring rvalue +references for <tt>func</tt> and <tt>args</tt> and the <tt>CopyConstructible</tt> requirements +for the elements of <tt>args</tt>. The use of an rvalue reference for the +function restricts the potential use of a plain function name, since +the type of the bound parameter will be deduced to be a function +reference and decay to pointer-to-function will not happen. This +therefore complicates the implementation in order to handle a simple +case. Furthermore, the use of rvalue references for args prevents the +array to pointer decay. Since arrays are not <tt>CopyConstructible</tt> or even +<tt>MoveConstructible</tt>, this essentially prevents the passing of arrays as +parameters. In particular it prevents the passing of string literals. +Consequently a simple case such as </p> + +<blockquote><pre>void f(const char*); +std::thread t(f,"hello"); +</pre></blockquote> + +<p> +is ill-formed since the type of the string literal is <tt>const char[6]</tt>. +</p> + +<p> +By changing the signature to take all parameters by value we can +eliminate the <tt>CopyConstructible</tt> requirement and permit the use of +arrays, as the parameter passing semantics will cause the necessary +array-to-pointer decay. They will also cause the function name to +decay to a pointer to function and allow the implementation to handle +functions and function objects identically. +</p> + +<p> +The new signature of the <tt>thread</tt> constructor for a function and +arguments is thus: +</p> + +<blockquote><pre>template<typename F,typename... Args> +thread(F,Args... args); +</pre></blockquote> + +<p> +Since the parameter pack <tt>Args</tt> can be empty, the single-parameter +constructor that takes just a function by value is now redundant. +</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.) +Howard adds: ]</i></p> <blockquote> -<pre>error_condition(); +<p> +I agree with everything Anthony says in this issue. However I believe we +can optimize in such a way as to get the pass-by-value behavior with the +pass-by-rvalue-ref performance. The performance difference is that the latter +removes a <tt>move</tt> when passing in an lvalue. +</p> + +<p> +This circumstance is very analogous to <tt>make_pair</tt> (20.3.3 [pairs]) +where we started with passing by const reference, changed to pass by value to +get pointer decay, and then changed to pass by rvalue reference, but modified with +<tt>decay<T></tt> to retain the pass-by-value behavior. If we were to +apply the same solution here it would look like: +</p> + +<blockquote><pre><del>template <class F> explicit thread(F f);</del> +template <class F, class ...Args> thread(F&& f, Args&&... args); </pre> <blockquote> <p> -<i>Effects:</i> Constructs an object of type <tt>error_condition</tt>. +-4- <i>Requires:</i> <tt>F</tt> and each <tt>Ti</tt> in <tt>Args</tt> shall be <del><tt>CopyConstructible</tt> +if an lvalue and otherwise</del> <tt>MoveConstructible</tt>. +<tt><i>INVOKE</i>(f, w1, w2, ..., wN)</tt> (20.7.2 [func.require]) shall be a valid expression for +some values <tt>w1, w2, ... , wN,</tt> where <tt>N == sizeof...(Args)</tt>. </p> <p> -<i>Postconditions:</i> <tt>val_ == 0</tt> and <tt>cat_ == <ins>&</ins>posix_category</tt>. +-5- <i>Effects:</i> Constructs an object of type <tt>thread</tt> +<del>and executes <tt><i>INVOKE</i>(f, t1, t2, ..., tN)</tt> in a new +thread of execution, where <tt>t1, t2, ..., tN</tt> are the values in <tt>args...</tt></del>. +<ins>Constructs +the following objects in memory which is accessible to a new thread of execution +as if:</ins> </p> +<blockquote><pre><ins>typename decay<F>::type g(std::forward<F>(f));</ins> +<ins>tuple<typename decay<Args>::type...> w(std::forward<Args>(args)...);</ins> +</pre></blockquote> <p> -<i>Throws:</i> Nothing. +<ins>The new thread of +execution executes <tt><i>INVOKE</i>(g, wi...)</tt> where the <tt>wi...</tt> refers +to the elements stored in the <tt>tuple w</tt>.</ins> +Any return value from <tt>g</tt> is ignored. +<del>If <tt>f</tt> terminates with an uncaught exception, <tt>std::terminate()</tt> shall be called.</del> +<ins>If the evaluation of <tt><i>INVOKE</i>(g, wi...)</tt> terminates +with an uncaught exception, <tt>std::terminate()</tt> shall be called [<i>Note:</i> +<tt>std::terminate()</tt> could be called before entering <tt>g</tt>. -- <i>end note</i>]. Any +exception thrown before the evaluation of <tt><i>INVOKE</i></tt> has started shall be +catchable in the calling thread.</ins> </p> </blockquote> -<pre>error_condition(int val, const error_category& cat); -</pre> +</blockquote> + +<p> +Text referring to when <tt>terminate()</tt> is called was contributed by Ganesh. +</p> + +</blockquote> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +We agree with the proposed resolution, +but would like the final sentence to be reworded +since "catchable" is not a term of art (and is used nowhere else). +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +Modify the class definition of <tt>std::thread</tt> in 30.3.1 [thread.thread.class] to remove the +following signature: +</p> + +<blockquote><pre><del>template<class F> explicit thread(F f);</del> +template<class F, class ... Args> <ins>explicit</ins> thread(F&& f, Args&& ... args); +</pre></blockquote> + +<p> +Modify 30.3.1.2 [thread.thread.constr] to replace the constructors prior to paragraph 4 with +the single constructor as above. Replace paragraph 4 - 6 with the +following: +</p> + <blockquote> <p> -<i>Effects:</i> Constructs an object of type <tt>error_condition</tt>. +-4- <i>Requires:</i> <tt>F</tt> and each <tt>Ti</tt> in <tt>Args</tt> shall be <del><tt>CopyConstructible</tt> +if an lvalue and otherwise</del> <tt>MoveConstructible</tt>. +<tt><i>INVOKE</i>(f, w1, w2, ..., wN)</tt> (20.7.2 [func.require]) shall be a valid expression for +some values <tt>w1, w2, ... , wN,</tt> where <tt>N == sizeof...(Args)</tt>. </p> <p> -<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&</ins>cat</tt>. +-5- <i>Effects:</i> Constructs an object of type <tt>thread</tt> +<del>and executes <tt><i>INVOKE</i>(f, t1, t2, ..., tN)</tt> in a new +thread of execution, where <tt>t1, t2, ..., tN</tt> are the values in <tt>args...</tt></del>. +<ins>Constructs +the following objects:</ins> </p> +<blockquote><pre><ins>typename decay<F>::type g(std::forward<F>(f));</ins> +<ins>tuple<typename decay<Args>::type...> w(std::forward<Args>(args)...);</ins> +</pre></blockquote> <p> -<i>Throws:</i> Nothing. +<ins>and executes <tt><i>INVOKE</i>(g, wi...)</tt> in a new thread of execution. +These objects shall be destroyed when the new thread of execution completes.</ins> +Any return value from <tt>g</tt> is ignored. +<del>If <tt>f</tt> terminates with an uncaught exception, <tt>std::terminate()</tt> shall be called.</del> +<ins>If the evaluation of <tt><i>INVOKE</i>(g, wi...)</tt> terminates +with an uncaught exception, <tt>std::terminate()</tt> shall be called [<i>Note:</i> +<tt>std::terminate()</tt> could be called before entering <tt>g</tt>. -- <i>end note</i>]. Any +exception thrown before the evaluation of <tt><i>INVOKE</i></tt> has started shall be +catchable in the calling thread.</ins> +</p> +<p> +-6- <i>Synchronization:</i> The invocation of the constructor <i>happens before</i> the +invocation of <del><tt>f</tt></del> <ins><tt>g</tt></ins>. </p> </blockquote> -</blockquote> + + + + + + +<hr> +<h3><a name="930"></a>930. Access to std::array data as built-in array type</h3> +<p><b>Section:</b> 23.3.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> Niels Dekker <b>Opened:</b> 2008-11-17 <b>Last modified:</b> 2009-06-01</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> -Change 19.4.3.3 [syserr.errcondition.modifiers] Class error_condition modifiers as indicated: +The Working Draft (N2798) allows access to the elements of +<tt>std::array</tt> by its <tt>data()</tt> member function: </p> <blockquote> -void assign(int val, const error_category& cat); + +<h5>23.2.1.4 array::data [array.data]</h5> +<pre> T *data(); + const T *data() const; +</pre> +<ol><li> + Returns: elems. +</li></ol> +</blockquote> + +<p> +Unfortunately, the result of <tt>std::array::data()</tt> cannot be bound +to a reference to a built-in array of the type of <tt>array::elems</tt>. +And <tt>std::array</tt> provides no other way to get a reference to +<tt>array::elems</tt>. +This hampers the use of <tt>std::array</tt>, for example when trying to +pass its data to a C style API function: +</p> + +<pre> // Some C style API function. + void set_path( char (*)[MAX_PATH] ); + + std::array<char,MAX_PATH> path; + set_path( path.data() ); // error + set_path( &(path.data()) ); // error +</pre> + + <p> +Another example, trying to pass the array data to an instance of another +C++ class: +</p> + +<pre> // Represents a 3-D point in space. + class three_d_point { + public: + explicit three_d_point(const double (&)[3]); + }; + + const std::array<double,3> coordinates = { 0, 1, 2 }; + three_d_point point1( coordinates.data() ); // error. + three_d_point point2( *(coordinates.data()) ); // error. +</pre> + +<p> +A user might be tempted to use <tt>std::array::elems</tt> instead, but +doing so isn't recommended, because <tt>std::array::elems</tt> is "for +exposition only". Note that Boost.Array users might already use +<tt>boost::array::elems</tt>, as its documentation doesn't explicitly +state that <tt>boost::array::elems</tt> is for exposition only: +http://www.boost.org/doc/libs/1_36_0/doc/html/boost/array.html +</p> +<p> +I can think of three options to solve this issue: +</p> +<ol><li> +Remove the words "exposition only" from the definition of +<tt>std::array::elems</tt>, as well as the note saying that "elems is +shown for exposition only." +</li><li> +Change the signature of <tt>std::array::data()</tt>, so that it would +return a reference to the built-in array, instead of a pointer to its +first element. +</li><li> +Add extra member functions, returning a reference to the built-in array. +</li></ol> +<p> +Lawrence Crowl wrote me that it might be better to leave +<tt>std::array::elems</tt> "for exposition only", to allow alternate +representations to allocate the array data dynamically. This might be +of interest to the embedded community, having to deal with very limited +stack sizes. +</p> +<p> +The second option, changing the return type of +<tt>std::array::data()</tt>, would break backward compatible to current +Boost and TR1 implementations, as well as to the other contiguous +container (<tt>vector</tt> and <tt>string</tt>) in a very subtle way. +For example, the following call to <tt>std::swap</tt> currently swap two +locally declared pointers <tt>(data1, data2)</tt>, for any container +type <tt>T</tt> that has a <tt>data()</tt> member function. When +<tt>std::array::data()</tt> is changed to return a reference, the +<tt>std::swap</tt> call may swap the container elements instead. +</p> + +<pre> template <typename T> + void func(T& container1, T& container2) + { + // Are data1 and data2 pointers or references? + auto data1 = container1.data(); + auto data2 = container2.data(); + + // Will this swap two local pointers, or all container elements? + std::swap(data1, data2); + } +</pre> + +<p> +The following concept is currently satisfied by all contiguous +containers, but it no longer is for <tt>std::array</tt>, when +<tt>array::data()</tt> +is changed to return a reference (tested on ConceptGCC Alpha 7): +</p> + +<pre> auto concept ContiguousContainerConcept<typename T> + { + typename value_type = typename T::value_type; + const value_type * T::data() const; + } +</pre> + +<p> +Still it's worth considering having <tt>std::array::data()</tt> return a +reference, because it might be the most intuitive option, from a user's +point of view. Nicolai Josuttis (who wrote <tt>boost::array</tt>) +mailed me that he very much prefers this option. +</p> +<p> +Note that for this option, the definition of <tt>data()</tt> would also +need to be revised for zero-sized arrays, as its return type cannot be a +reference to a zero-sized built-in array. Regarding zero-sized array, +<tt>data()</tt> could throw an exception. Or there could be a partial +specialization of <tt>std::array</tt> where <tt>data()</tt> returns +<tt>T*</tt> or gets removed. +</p> +<p> +Personally I prefer the third option, adding a new member function to +<tt>std::array</tt>, overloaded for const and non-const access, +returning a reference to the built-in array, to avoid those compatible +issues. I'd propose naming the function <tt>std::array::c_array()</tt>, +which sounds intuitive to me. Note that <tt>boost::array</tt> already +has a <tt>c_array()</tt> member, returning a pointer, but Nicolai told +me that this one is only there for historical reasons. (Otherwise a name +like <tt>std::array::native_array()</tt> or +<tt>std::array::builtin_array()</tt> would also be fine with me.) +According to my proposed resolution, a zero-sized <tt>std::array</tt> does not need +to have <tt>c_array()</tt>, while it is still required to have +<tt>data()</tt> functions. +</p> + +<p><i>[ +Post Summit: +]</i></p> + + <blockquote> + <p> -<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&</ins>cat</tt>. +Alisdair: Don't like p4 suggesting implementation-defined behaviour. </p> <p> -<i>Throws:</i> Nothing. +Walter: What about an explicit conversion operator, instead of adding +the new member function? +</p> +<p> +Alisdair: Noodling about: </p> +<blockquote><pre>template<size_t N, ValueType T> +struct array +{ + T elems[N]; + +// fantasy code starts here + +// crazy decltype version for grins only +//requires True<(N>0)> +//explict operator decltype(elems) & () { return elems; } + +// conversion to lvalue ref +requires True<(N>0)> +explict operator T(&)[N] () & { return elems; } + +// conversion to const lvalue ref +requires True<(N>0)> +explict operator const T(&)[N] () const & { return elems; } + +// conversion to rvalue ref using ref qualifiers +requires True<(N>0)> +explict operator T(&&)[N] () && { return elems; } + +// fantasy code ends here + +explicit operator bool() { return true; } +}; +</pre></blockquote> + +<p> +This seems legal but odd. Jason Merrill says currently a CWG issue 613 +on the non-static data member that fixes the error that current G++ +gives for the non-explicit, non-conceptualized version of this. Verdict +from human compiler: seems legal. +</p> +<p> +Some grumbling about zero-sized arrays being allowed and supported. +</p> +<p> +Walter: Would this address the issue? Are we inclined to go this route? +</p> +<p> +Alan: What would usage look like? +</p> +<blockquote><pre>// 3-d point in space +struct three_d_point +{ + explicit three_d_point(const double (&)[3]); +}; + +void sink(double*); + +const std::array<double, 3> coordinates = { 0, 1, 2 }; +three_d_point point1( coordinates.data() ); //error +three_d_point point2( *(coordinates.data()) ); // error +three_d_point point3( coordinates ); // yay! + +sink(cooridinates); // error, no conversion +</pre></blockquote> + +<p> +Recommended Open with new wording. Take the required clause and add the +explicit conversion operators, not have a <tt>typedef</tt>. At issue still is use +<tt>decltype</tt> or use <tt>T[N]</tt>. In favour of using <tt>T[N]</tt>, even though use of +<tt>decltype</tt> is specially clever. +</p> + </blockquote> + +<p><i>[ +Post Summit, further discussion in the thread starting with c++std-lib-23215. +]</i></p> + + + + +<p><b>Proposed resolution:</b></p> +<p> +Add to the template definition of array, 23.3.1 [array]/3: +</p> + +<blockquote> +<pre><ins> +typedef T c_array_type[N]; +c_array_type & c_array() &; +c_array_type && c_array() &&; +const c_array_type & c_array() const &; +</ins> +</pre> </blockquote> <p> -Change 19.4.3.4 [syserr.errcondition.observers] Class error_condition observers as indicated: +Add the following subsection to 23.3.1 [array], after 23.3.1.4 [array.data]: </p> <blockquote> -const error_category& category() const; +<h5><ins>23.2.1.5 array::c_array [array.c_array]</ins></h5> + <pre><ins> +c_array_type & c_array() &; +c_array_type && c_array() &&; +const c_array_type & c_array() const &; +</ins></pre> <blockquote> <p> -<i>Returns:</i> <tt><ins>*</ins>cat_</tt>. +<ins><i>Returns:</i> <tt>elems</tt>.</ins> </p> +</blockquote> + +</blockquote> + <p> -<i>Throws:</i> Nothing. +Add to Zero sized arrays 23.3.1.6 [array.zero]: </p> + +<blockquote> +4. The presence of <tt>c_array_type</tt> and <tt>c_array()</tt> and +their semantics are implementation defined, for a zero-sized array. </blockquote> + + + + + +<hr> +<h3><a name="931"></a>931. type trait <tt>extent<T, I></tt></h3> +<p><b>Section:</b> 20.6.4.3 [meta.unary.prop] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> Yechezkel Mett <b>Opened:</b> 2008-11-04 <b>Last modified:</b> 2009-03-09</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta.unary.prop">active issues</a> in [meta.unary.prop].</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#Tentatively%20Ready">Tentatively Ready</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The draft (N2798) says in 20.6.4.3 [meta.unary.prop] Table 44: +</p> +<blockquote> +<table border="1"> +<caption>Table 44 -- Type property queries</caption> +<tbody><tr><th>Template</th><th>Value</th></tr> +<tr> +<td> +<tt>template <class T, unsigned I = 0> struct extent;</tt> +</td> +<td> +If <tt>T</tt> is not an array type (8.3.4), or if it has rank less than +<tt>I</tt>, or if <tt>I</tt> is 0 +and <tt>T</tt> has type "array of unknown bound of <tt>U</tt>", then 0; otherwise, the +size of the <tt>I</tt>'th dimension of <tt>T</tt> +</td> +</tr> +</tbody></table> </blockquote> + +<p> +Firstly it isn't clear from the wording if <tt>I</tt> is 0-based or 1-based +("the <tt>I</tt>'th dimension" sort of implies 1-based). From the following +example it is clear that the intent is 0-based, in which case it +should say "or if it has rank less than or equal to <tt>I</tt>". +</p> +<p> +Sanity check: +</p> +<p> +The example says <tt>assert((extent<int[2], 1>::value) == 0);</tt> +</p> +<p> +Here the rank is 1 and <tt>I</tt> is 1, but the desired result is 0. +</p> + +<p><i>[ +Post Summit: +]</i></p> + + +<blockquote> +<p> +Do not use "size" or "value", use "bound". Also, move the +cross-reference to 8.3.4 to just after "bound". +</p> +<p> +Recommend Tentatively Ready. +</p> </blockquote> + + +<p><b>Proposed resolution:</b></p> <p> -Resolution of part C: +In Table 44 of 20.6.4.3 [meta.unary.prop], third row, column "Value", +change the cell content: </p> <blockquote> +<table border="1"> +<caption>Table 44 -- Type property queries</caption> +<tbody><tr><th>Template</th><th>Value</th></tr> +<tr> +<td> +<tt>template <class T, unsigned I = 0> struct extent;</tt> +</td> +<td> +If <tt>T</tt> is not an array type <del>(8.3.4)</del>, or if it has rank less than +<ins> or equal to</ins> <tt>I</tt>, or if <tt>I</tt> is 0 +and <tt>T</tt> has type "array of unknown bound of <tt>U</tt>", then 0; otherwise, the +<del>size</del> <ins>bound (8.3.4)</ins> of the <tt>I</tt>'th dimension of <tt>T</tt><ins>, +where indexing of <tt>I</tt> is zero-based.</ins> +</td> +</tr> +</tbody></table> +</blockquote> + +<p><i>[ +Wording supplied by Daniel. +]</i></p> + + + + + + + +<hr> +<h3><a name="932"></a>932. <tt>unique_ptr(pointer p)</tt> for pointer deleter types</h3> +<p><b>Section:</b> 20.8.12.2.1 [unique.ptr.single.ctor] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2008-11-26 <b>Last modified:</b> 2009-03-12</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unique.ptr.single.ctor">active issues</a> in [unique.ptr.single.ctor].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr.single.ctor">issues</a> in [unique.ptr.single.ctor].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p> +<p><b>Discussion:</b></p> + +<p><b>Addresses US 79</b></p> <p> -In 19.4.1.2 [syserr.errcat.virtuals], remove the throws clause p. 10. +20.8.12.2.1 [unique.ptr.single.ctor]/5 no longer requires for <tt>D</tt> +not to be a pointer type. I believe this restriction was accidently removed +when we relaxed the completeness reuqirements on <tt>T</tt>. The restriction +needs to be put back in. Otherwise we have a run time failure that could +have been caught at compile time: </p> +<blockquote><pre>{ +unique_ptr<int, void(*)(void*)> p1(malloc(sizeof(int))); <font color="#c80000">// should not compile</font> +} <font color="#c80000">// p1.~unique_ptr() dereferences a null function pointer</font> +unique_ptr<int, void(*)(void*)> p2(malloc(sizeof(int)), free); <font color="#c80000">// ok</font> +</pre></blockquote> + +<p><i>[ +Post Summit: +]</i></p> + + <blockquote> -<pre>virtual string message(int ev) const = 0; +Recommend Tentatively Ready. +</blockquote> + + + +<p><b>Proposed resolution:</b></p> +<p> +Change 20.8.12.2.1 [unique.ptr.single.ctor]/5: +</p> + +<blockquote><pre>unique_ptr(pointer p); </pre> +<blockquote> +<i>Requires:</i> <ins><tt>D</tt> shall not be a pointer type (diagnostic required).</ins> +<tt>D</tt> shall be default constructible, and that construction shall not throw an exception. +</blockquote> +</blockquote> + + + + + +<hr> +<h3><a name="933"></a>933. Unique_ptr defect</h3> +<p><b>Section:</b> 20.8.12.2.5 [unique.ptr.single.modifiers] <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>Opened:</b> 2008-11-27 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unique.ptr.single.modifiers">active issues</a> in [unique.ptr.single.modifiers].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr.single.modifiers">issues</a> in [unique.ptr.single.modifiers].</p> +<p><b>View all 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> +If we are supporting stateful deleters, we need an overload for +<tt>reset</tt> that +takes a deleter as well. +</p> + +<blockquote><pre>void reset( pointer p, deleter_type d); +</pre></blockquote> + +<p> +We probably need two overloads to support move-only deleters, and +this +sounds uncomfortably like the two constructors I have been ignoring +for +now... +</p> + +<p><i>[ +Batavia (2009-05): +]</i></p> <blockquote> <p> -<i>Returns:</i> A string that describes the error condition denoted by <tt>ev</tt>. +Howard comments that we have the functionality via move-assigment. </p> <p> -<del><i>Throws:</i> Nothing.</del> +Move to Open. </p> </blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +</p> + + + + + +<hr> +<h3><a name="934"></a>934. <tt>duration</tt> is missing <tt>operator%</tt></h3> +<p><b>Section:</b> 20.9.3 [time.duration] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> Terry Golubiewski <b>Opened:</b> 2008-11-30 <b>Last modified:</b> 2009-05-23</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p> +<p><b>Discussion:</b></p> + +<p><b>Addresses US 81</b></p> + +<p> +<tt>duration</tt> is missing <tt>operator%</tt>. This operator is convenient +for computing where in a time frame a given <tt>duration</tt> lies. A +motivating example is converting a <tt>duration</tt> into a "broken-down" +time duration such as hours::minutes::seconds: +</p> + +<blockquote><pre>class ClockTime +{ + typedef std::chrono::hours hours; + typedef std::chrono::minutes minutes; + typedef std::chrono::seconds seconds; +public: + hours hours_; + minutes minutes_; + seconds seconds_; + + template <class Rep, class Period> + explicit ClockTime(const std::chrono::duration<Rep, Period>& d) + : hours_ (std::chrono::duration_cast<hours> (d)), + minutes_(std::chrono::duration_cast<minutes>(d % hours(1))), + seconds_(std::chrono::duration_cast<seconds>(d % minutes(1))) + {} +}; +</pre></blockquote> + +<p><i>[ +Summit: +]</i></p> + + +<blockquote> +Agree except that there is a typo in the proposed resolution. The member +operators should be operator%=. </blockquote> +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +We agree with the proposed resolution. +Move to Tentatively Ready. +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +Add to the synopsis in 20.9 [time]: +</p> + +<blockquote><pre>template <class Rep1, class Period, class Rep2> + duration<typename common_type<Rep1, Rep2>::type, Period> + operator%(const duration<Rep1, Period>& d, const Rep2& s); +template <class Rep1, class Period1, class Rep2, class Period2> + typename common_type<duration<Rep1, Period1>, duration<Rep2, Period2>>::type + operator%(const duration<Rep1, Period1>& lhs, const duration<Rep2, Period2>& rhs); +</pre></blockquote> + <p> -In 19.4.2.4 [syserr.errcode.observers], remove the throws clause p. 8. +Add to the synopsis of <tt>duration</tt> in 20.9.3 [time.duration]: +</p> + +<blockquote><pre>template <class Rep, class Period = ratio<1>> +class duration { +public: + ... + <ins>duration& operator%=(const rep& rhs);</ins> + <ins>duration& operator%=(const duration& d);</ins> + ... +}; +</pre></blockquote> + +<p> +Add to 20.9.3.3 [time.duration.arithmetic]: </p> <blockquote> -<pre>string message() const; +<pre>duration& operator%=(const rep& rhs); </pre> <blockquote> <p> -<i>Returns:</i> <tt>category().message(value())</tt>. +<i>Effects:</i> <tt>rep_ %= rhs</tt>. </p> <p> -<del><i>Throws:</i> Nothing.</del> +<i>Returns:</i> <tt>*this</tt>. +</p> +</blockquote> + +<pre>duration& operator%=(const duration& d); +</pre> +<blockquote> +<p> +<i>Effects:</i> <tt>rep_ %= d.count()</tt>. +</p> +<p> +<i>Returns:</i> <tt>*this</tt>. </p> </blockquote> </blockquote> <p> -In 19.4.3.4 [syserr.errcondition.observers], remove the throws clause p. 6. +Add to 20.9.3.5 [time.duration.nonmember]: </p> <blockquote> -<pre>string message() const; + +<pre>template <class Rep1, class Period, class Rep2> + duration<typename common_type<Rep1, Rep2>::type, Period> + operator%(const duration<Rep1, Period>& d, const Rep2& s); </pre> <blockquote> <p> -<i>Returns:</i> <tt>category().message(value())</tt>. +<i>Requires:</i> <tt>Rep2</tt> shall be implicitly convertible to <tt>CR(Rep1, Rep2)</tt> and +<tt>Rep2</tt> shall not be an instantiation of <tt>duration</tt>. Diagnostic required. </p> <p> -<del><i>Throws:</i> Nothing.</del> +<i>Returns:</i> <tt>duration<CR, Period>(d) %= s</tt>. </p> </blockquote> + +<pre>template <class Rep1, class Period1, class Rep2, class Period2> + typename common_type<duration<Rep1, Period1>, duration<Rep2, Period2>>::type + operator%(const duration<Rep1, Period1>& lhs, const duration<Rep2, Period2>& rhs); +</pre> +<blockquote> +<p> +<i>Returns:</i> <tt>common_type<duration<Rep1, Period1>, duration<Rep2, Period2>>::type(lhs) %= rhs</tt>. +</p> </blockquote> </blockquote> @@ -13529,646 +21029,1927 @@ In 19.4.3.4 [syserr.errcondition.observers], remove the throws clause p. 6. <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> +<h3><a name="935"></a>935. clock error handling needs to be specified</h3> +<p><b>Section:</b> 20.9.5 [time.clock] <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>Opened:</b> 2008-11-24 <b>Last modified:</b> 2009-05-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> -19.4 [syserr] +Each of the three clocks specified in Clocks 20.9.5 [time.clock] +provides the member function: </p> -<blockquote><pre>namespace posix_error { - enum posix_errno { - address_family_not_supported, // EAFNOSUPPORT - ... +<blockquote><pre>static time_point now(); </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. +The semantics specified by Clock requirements 20.9.1 [time.clock.req] +make no mention of error handling. Thus the function may throw <tt>bad_alloc</tt> +or an implementation-defined exception (17.6.4.10 [res.on.exception.handling] +paragraph 4). +</p> + +<p> +Some implementations of these functions on POSIX, Windows, and +presumably on other operating systems, may fail in ways only detectable +at runtime. Some failures on Windows are due to supporting chipset +errata and can even occur after successful calls to a clock's <tt>now()</tt> +function. +</p> + +<p> +These functions are used in cases where exceptions are not appropriate +or where the specifics of the exception or cause of error need to be +available to the user. See +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2828.html">N2828</a>, +<i>Library Support for hybrid error +handling (Rev 1)</i>, for more specific discussion of use cases. Thus some change in +the interface of now is required. +</p> + +<p> +The proposed resolution has been implemented in the Boost version of the +chrono library. No problems were encountered. </p> <p><i>[ -Further discussion: +Batavia (2009-05): ]</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. +We recommend this issue be deferred until the next Committee Draft +has been issued and the prerequisite paper has been accepted. </p> <p> -Alberto Ganesh Barbati also raised this issue in private email, and also proposed the scoped-enum solution. +Move to Open. </p> +</blockquote> + + +<p><b>Proposed resolution:</b></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. +Accept the proposed wording of +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2828.html">N2828</a>, +<i>Library Support for hybrid error handling (Rev 1)</i>. </p> + <p> -The wording for the Proposed resolution was provided by Beman Dawes. +Change Clock requirements 20.9.1 [time.clock.req] as indicated: </p> -</blockquote> +<blockquote> +<p> +-2- In Table 55 <tt>C1</tt> and <tt>C2</tt> denote clock types. <tt>t1</tt> and +<tt>t2</tt> are values returned by <tt>C1::now()</tt> where the call +returning <tt>t1</tt> happens before (1.10) the call returning <tt>t2</tt> and +both of these calls happen before <tt>C1::time_point::max()</tt>. +<ins><tt>ec</tt> denotes an object of type <tt>error_code</tt> +(19.5.2.2 [syserr.errcode.overview]).</ins> +</p> + +<table border="1"> +<caption>Table 55 -- Clock requirements</caption> +<tbody><tr> +<th>Expression</th><th>Return type</th><th>Operational semantics</th> +</tr> + +<tr> +<td>...</td> +<td>...</td> +<td>...</td> +</tr> + +<tr> +<td><tt>C1::now()</tt></td> +<td><tt>C1::time_point</tt></td> +<td>Returns a <tt>time_point</tt> object representing the current point in time. +</td> +</tr> + +<tr> +<td><tt><ins>C1::now(ec)</ins></tt></td> +<td><tt><ins>C1::time_point</ins></tt></td> +<td><ins>Returns a <tt>time_point</tt> object representing the current point in time.</ins> +</td> +</tr> +</tbody></table> +</blockquote> -<p><b>Proposed resolution:</b></p> <p> -Change System error support 19.4 [syserr] as indicated: +Change Class system_clock 20.9.5.1 [time.clock.system] 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> +<blockquote><pre>static time_point now(<ins>error_code& ec=throws()</ins>); +</pre></blockquote> -template <> struct is_error_condition_enum<<del>posix_error::posix_errno</del> <ins>errc</ins>> - : public true_type {} +<p> +Change Class monotonic_clock 20.9.5.2 [time.clock.monotonic] as indicated: +</p> -<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> +<blockquote><pre>static time_point now(<ins>error_code& ec=throws()</ins>); </pre></blockquote> <p> -Change System error support 19.4 [syserr] : +Change Class high_resolution_clock 20.9.5.3 [time.clock.hires] as indicated: </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> +<blockquote><pre>static time_point now(<ins>error_code& ec=throws()</ins>); +</pre></blockquote> + + + + + +<hr> +<h3><a name="936"></a>936. Mutex type overspecified</h3> +<p><b>Section:</b> 30.4.1 [thread.mutex.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> + <b>Submitter:</b> Pete Becker <b>Opened:</b> 2008-12-05 <b>Last modified:</b> 2009-03-22</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.mutex.requirements">active issues</a> in [thread.mutex.requirements].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.mutex.requirements">issues</a> in [thread.mutex.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> -Change System error support 19.4 [syserr] and its subsections: +30.4.1 [thread.mutex.requirements] describes the requirements for a type to be +a "Mutex type". A Mutex type can be used as the template argument for +the <tt>Lock</tt> type that's passed to <tt>condition_variable_any::wait</tt> (although +<tt>Lock</tt> seems like the wrong name here, since <tt>Lock</tt> is given a different +formal meaning in 30.4.3 [thread.lock]) and, although the WD doesn't quite say +so, as the template argument for <tt>lock_guard</tt> and <tt>unique_lock</tt>. +</p> + +<p> +The requirements for a Mutex type include: </p> -<blockquote> <ul> <li> -remove all occurrences of <tt>posix_error::</tt> +<tt>m.lock()</tt> shall be well-formed and have [described] semantics, including a return type of <tt>void</tt>. </li> <li> -change all instances of <tt>posix_errno</tt> to <tt>errc</tt> +<tt>m.try_lock()</tt> shall be well-formed and have [described] semantics, including a return type of <tt>bool</tt>. </li> <li> -change all instances of <tt>posix_category</tt> to <tt>generic_category</tt> +<tt>m.unlock()</tt> shall be well-formed and have [described] semantics, including a return type of <tt>void</tt>. +</li> +</ul> + +<p> +Also, a Mutex type "shall not be copyable nor movable". +</p> + +<p> +The latter requirement seems completely irrelevant, and the three +requirements on return types are tighter than they need to be. For +example, there's no reason that <tt>lock_guard</tt> can't be instantiated with a +type that's copyable. The rule is, in fact, that <tt>lock_guard</tt>, etc. won't +try to copy objects of that type. That's a constraint on locks, not on +mutexes. Similarly, the requirements for <tt>void</tt> return types are +unnecessary; the rule is, in fact, that <tt>lock_guard</tt>, etc. won't use any +returned value. And with the return type of <tt>bool</tt>, the requirement should +be that the return type is convertible to <tt>bool</tt>. +</p> + +<p><i>[ +Summit: +]</i></p> + + +<blockquote> +<p> +Move to open. Related to conceptualization and should probably be tackled as part of that. +</p> +<ul> +<li> +The intention is not only to place a constraint on what types such as +<tt>lock_guard</tt> may do with mutex types, but on what any code, including user +code, may do with mutex types. Thus the constraints as they are apply to +the mutex types themselves, not the current users of mutex types in the +standard. </li> <li> -change all instances of <tt>get_posix_category</tt> to <tt>get_generic_category</tt> +This is a low priority issue; the wording as it is may be overly +restrictive but this may not be a real issue. </li> </ul> </blockquote> +<p><i>[ +Post Summit Anthony adds: +]</i></p> + + +<blockquote> +<p> +Section 30.4.1 [thread.mutex.requirements] conflates the +requirements on a generic Mutex type (including user-supplied mutexes) +with the requirements placed on the standard-supplied mutex types in an +attempt to group everything together and save space. +</p> +<p> +When applying concepts to chapter 30, I suggest that the concepts +<tt>Lockable</tt> and <tt>TimedLockable</tt> embody the requirements for +*use* of a mutex type as required by +<tt>unique_lock/lock_guard/condition_variable_any</tt>. These should be +relaxed as Pete describes in the issue. The existing words in 30.4.1 [thread.mutex.requirements] are requirements on all of +<tt>std::mutex</tt>, <tt>std::timed_mutex</tt>, +<tt>std::recursive_mutex</tt> and <tt>std::recursive_timed_mutex</tt>, +and should be rephrased as such. +</p> +</blockquote> + + + +<p><b>Proposed resolution:</b></p> +<p> +</p> + + + + + +<hr> +<h3><a name="938"></a>938. <tt>default_delete<T[]>::operator()</tt> should only accept <tt>T*</tt></h3> +<p><b>Section:</b> 20.8.12.1.2 [unique.ptr.dltr.dflt1] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2008-12-07 <b>Last modified:</b> 2009-05-23</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p> +<p><b>Discussion:</b></p> <p> -Change Error category objects 19.4.1.5 [syserr.errcat.objects], paragraph 2: +Consider: </p> +<blockquote><pre>derived* p = new derived[3]; +std::default_delete<base[]> d; +d(p); <font color="#c80000">// should fail</font> +</pre></blockquote> + +<p> +Currently the marked line is a run time failure. We can make it a compile +time failure by "poisoning" <tt>op(U*)</tt>. +</p> + +<p><i>[ +Post Summit: +]</i></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>. +Recommend Review. +</blockquote> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +We agree with the proposed resolution. +Move to Tentatively Ready. </blockquote> + +<p><b>Proposed resolution:</b></p> <p> -Change 19.4.2.5 [syserr.errcode.nonmembers] Class <tt>error_code</tt> non-member functions as indicated: +Add to 20.8.12.1.2 [unique.ptr.dltr.dflt1]: </p> +<blockquote><pre>namespace std { + template <class T> struct default_delete<T[]> { + void operator()(T*) const; + <ins>template <class U> void operator()(U*) const = delete;</ins> +}; +} +</pre></blockquote> + + + + + +<hr> +<h3><a name="939"></a>939. Problem with <tt>std::identity</tt> and reference-to-temporaries</h3> +<p><b>Section:</b> 20.7.6 [identity.operation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> + <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-12-11 <b>Last modified:</b> 2009-06-02</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>std::identity</tt> takes an argument of type <tt>T const &</tt> +and returns a result of <tt>T const &</tt>. +</p> +<p> +Unfortunately, this signature will accept a value of type other than <tt>T</tt> that +is convertible-to-<tt>T</tt>, and then return a reference to the dead temporary. The +constraint in the concepts version simply protects against returning +reference-to-<tt>void</tt>. +</p> +<p> +Solutions: +</p> <blockquote> -<pre>error_code make_error_code(<del>posix_errno</del> <ins>errc</ins> e); -</pre> +<p> +i/ Return-by-value, potentially slicing bases and rejecting non-copyable +types +</p> +<p> +ii/ Provide an additional overload: +</p> +<blockquote><pre>template< typename T > +template operator( U & ) = delete; +</pre></blockquote> +<p> +This seems closer on intent, but moves beyond the original motivation for +the operator, which is compatibility with existing (non-standard) +implementations. +</p> +<p> +iii/ Remove the <tt>operator()</tt> overload. This restores the original definition +of the <tt>identity</tt>, although now effectively a type_trait rather than part of +the perfect forwarding protocol. +</p> +<p> +iv/ Remove <tt>std::identity</tt> completely; its original reason to exist is +replaced with the <tt>IdentityOf</tt> concept. +</p> +</blockquote> +<p> +My own preference is somewhere between (ii) and (iii) - although I stumbled +over the issue with a specific application hoping for resolution (i)! +</p> + +<p><i>[ +Batavia (2009-05): +]</i></p> <blockquote> -<i>Returns:</i> <tt>error_code(<ins>static_cast<int>(</ins>e<ins>)</ins>, <del>posix</del><ins>generic</ins>_category)</tt>. +<p> +We dislike options i and iii, and option ii seems like overkill. +If we remove it (option iv), implementers can still provide it under a +different name. +</p> +<p> +Move to Open pending wording (from Alisdair) for option iv. +</p> </blockquote> + +<p><i>[ +2009-05-23 Alisdair provided wording for option iv. +]</i></p> + + + + +<p><b>Proposed resolution:</b></p> +<p> +Strike 20.2.1 [concept.transform] p3: +</p> + +<blockquote> +<del>-4- <i>Note:</i> concept form of the identity type metafunction (20.7.6).</del> </blockquote> <p> -Change 19.4.3.5 [syserr.errcondition.nonmembers] Class <tt>error_condition</tt> non-member functions as indicated: +Strike from 20.7 [function.objects] p2: +</p> + +<blockquote><pre><del>// 20.7.6, identity operation:</del> +<del>template <IdentityOf T> struct identity;</del> +</pre></blockquote> + +<p> +Remove 20.7.6 [identity.operation] (whole subclause): </p> <blockquote> -<pre>error_condition make_error_condition(<del>posix_errno</del> <ins>errc</ins> e); -</pre> +<pre><del>template <IdentityOf T> struct identity { + typedef T type; + requires ReferentType<T> + const T& operator()(const T& x) const; +};</del> + +<del>requires ReferentType<T> + const T& operator()(const T& x) const;</del> +</pre> <blockquote> -<i>Returns:</i> <tt>error_condition(<ins>static_cast<int>(</ins>e<ins>)</ins>, <del>posix</del><ins>generic</ins>_category)</tt>. +<del>-1- <i>Returns:</i> <tt>x</tt></del> </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> +<hr> +<h3><a name="940"></a>940. <tt>std::distance</tt></h3> +<p><b>Section:</b> 24.4 [iterator.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> Thomas <b>Opened:</b> 2008-12-14 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iterator.operations">active issues</a> in [iterator.operations].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.operations">issues</a> in [iterator.operations].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p> +<p><b>Discussion:</b></p> -<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> +<p><b>Addresses UK 270</b></p> -<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> +<p> +Regarding the <tt>std::distance</tt> - function, 24.4 [iterator.operations] +/ 4 says: +</p> +<blockquote> +Returns the +number of increments or decrements needed to get from first to last. +</blockquote> +<p> +This sentence is completely silent about the sign of the return value. +24.4 [iterator.operations] / 1 gives more information about the +underlying operations, but +again no inferences about the sign can be made. +Strictly speaking, that is taking that sentence literally, I think this +sentence even implies a positive return value in all cases, as the +number of increments or decrements is clearly a ratio scale variable, +with a natural zero bound. +</p> +<p> +Practically speaking, my implementations did what common sense and +knowledge based on pointer arithmetic forecasts, namely a positive sign +for increments (that is, going from <tt>first</tt> to <tt>last</tt> by <tt>operator++</tt>), and a +negative sign for decrements (going from <tt>first</tt> to <tt>last</tt> by <tt>operator--</tt>). +</p> +<p> +Here are my two questions: +</p> +<p> +First, is that paragraph supposed to be interpreted in the way what I +called 'common sense', that is negative sign for decrements ? I am +fairly sure that's the supposed behavior, but a double-check here in +this group can't hurt. +</p> +<p> +Second, is the present wording (2003 standard version - no idea about +the draft for the upcoming standard) worth an edit to make it a bit more +sensible, to mention the sign of the return value explicitly ? +</p> -<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> +<p><i>[ +Daniel adds: +]</i></p> -<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> +<blockquote> +<p> +My first thought was that resolution <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#204">204</a> would already cover the +issue report, but it seems that current normative wording is in +contradiction to that resolution: +</p> -<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> +<p> +Referring to +<a href="" ref="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdf">N2798</a>, +24.4 [iterator.operations]/ p.4 says: +</p> -<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> +<blockquote> +<i>Effects:</i> Returns the number of increments or decrements needed to get +from <tt>first</tt> to <tt>last</tt>. +</blockquote> -<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> +<p> +IMO the part " or decrements" is in contradiction to p. 5 which says +</p> +<blockquote> +<i>Requires:</i> <tt>last</tt> shall be reachable from <tt>first</tt>. +</blockquote> +<p> +because "reachable" is defined in 24.2 [iterator.concepts]/7 as +</p> +<blockquote> +An iterator <tt>j</tt> is called reachable from an iterator <tt>i</tt> if and only if +there is a finite +sequence of applications of the expression <tt>++i</tt> that makes <tt>i == j</tt>.[..] +</blockquote> +<p> +Here is wording that would be consistent with this definition of "reachable": +</p> -<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: +Change 24.4 [iterator.operations] p4 as follows: </p> <blockquote> -<i>Effects:</i> If <tt>p == get()</tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>. +<i>Effects:</i> Returns the number of increments <del>or decrements</del> +needed to get from <tt>first</tt> to <tt>last</tt>. +</blockquote> + +</blockquote> + +<p> +Thomas adds more discussion and an alternative view point +<a href="http://groups.google.com/group/comp.std.c++/browse_thread/thread/e8e46dcda0a5d797#">here</a>. +</p> + +<p><i>[ +Summit: +]</i></p> + + +<blockquote> +The proposed wording below was verbally agreed to. Howard provided. +</blockquote> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +<p> +Pete reports that a recent similar change has been made +for the <tt>advance()</tt> function. +</p> +<p> +We agree with the proposed resolution. +Move to Tentatively Ready. +</p> </blockquote> + +<p><b>Proposed resolution:</b></p> <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.) +Change 24.4 [iterator.operations]: </p> +<blockquote> +<pre>template <InputIterator Iter> + Iter::difference_type + distance(Iter first, Iter last); +<del>template <RandomAccessIterator Iter> + Iter::difference_type distance(Iter first, Iter last);</del> +</pre> + +<blockquote> <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. +-4- <i>Effects:</i> Returns the number of increments <del>or decrements</del> +needed to get from <tt>first</tt> to <tt>last</tt>. </p> +<p> +-5- <i>Requires:</i> <tt>last</tt> shall be reachable from <tt>first</tt>. +</p> +</blockquote> + +<pre><ins>template <RandomAccessIterator Iter> + Iter::difference_type distance(Iter first, Iter last);</ins> +</pre> +<blockquote> +<p> +<ins>-6- <i>Effects:</i> Returns the number of increments or decrements +needed to get from <tt>first</tt> to <tt>last</tt>.</ins> +</p> <p> -One might think that self-resets are necessary for operator= to work; it's specified to perform +<ins>-7- <i>Requires:</i> <tt>last</tt> shall be reachable from <tt>first</tt> +or <tt>first</tt> shall be reachable from <tt>last</tt>.</ins> </p> +</blockquote> + + +</blockquote> + + -<blockquote><pre>reset( u.release() ); + + + +<hr> +<h3><a name="941"></a>941. Ref-qualifiers for assignment operators</h3> +<p><b>Section:</b> 17 [library] <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>Opened:</b> 2008-12-18 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</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#Open">Open</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The assignment and equality operators <tt>=</tt> and <tt>==</tt> are easily confused, just +because of their visual similarity, and in this case a simple typo can cause +a serious bug. When the left side of an <tt>operator=</tt> is an rvalue, it's +highly unlikely that the assignment was intended by the programmer: +</p> +<blockquote><pre>if ( func() = value ) // Typical typo: == intended! </pre></blockquote> +<p> +Built-in types don't support assignment to an rvalue, but unfortunately, +a lot of types provided by the Standard Library do. +</p> +<p> +Fortunately the language now offers a syntax to prevent a certain member +function from having an rvalue as <tt>*this</tt>: by adding a ref-qualifier (<tt>&</tt>) +to the member function declaration. Assignment operators are explicitly +mentioned as a use case of ref-qualifiers, in "Extending Move Semantics +To <tt>*this</tt> (Revision 1)", +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1821.htm">N1821</a> by Daveed +Vandevoorde and Bronek Kozicki +</p> +<p> +Hereby I would like to propose adding ref-qualifiers to all appropriate +assignment operators in the library. +</p> + +<p><i>[ +Batavia (2009-05): +]</i></p> +<blockquote> +Move to Open. +We recommend this be deferred until after the next Committee Draft. +</blockquote> + + +<p><b>Proposed resolution:</b></p> <p> -and the self-assignment +A proposed resolution is provided by the paper on this subject, +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2819.html">N2819</a>, +<i>Ref-qualifiers for assignment operators of the Standard Library</i> </p> -<blockquote><pre>p = move(p); -</pre></blockquote> + + + +<hr> +<h3><a name="943"></a>943. <tt>ssize_t</tt> undefined</h3> +<p><b>Section:</b> 29.5.2 [atomics.types.address] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> Holger Grund <b>Opened:</b> 2008-12-19 <b>Last modified:</b> 2009-05-23</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p> +<p><b>Discussion:</b></p> <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. +There is a row in "Table 122 - Atomics for standard typedef types" +in 29.5.1 [atomics.types.integral] with <tt>atomic_ssize_t</tt> +and <tt>ssize_t</tt>. Unless, I'm missing something <tt>ssize_t</tt> +is not defined by the standard. </p> +<p><i>[ +Summit: +]</i></p> + + +<blockquote> +Move to review. Proposed resolution: Remove the typedef. Note: ssize_t +is a POSIX type. +</blockquote> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +We agree with the proposed resolution. +Move to Tentatively Ready. +</blockquote> <p><b>Proposed resolution:</b></p> +<p> +Remove the row containing <tt>ssize_t</tt> from Table 119 +"Atomics for standard typedef types" in 29.5.2 [atomics.types.address]. +</p> + + + + + +<hr> +<h3><a name="944"></a>944. <tt>atomic<bool></tt> derive from <tt>atomic_bool</tt>?</h3> +<p><b>Section:</b> 29.5.3 [atomics.types.generic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> + <b>Submitter:</b> Holger Grund <b>Opened:</b> 2008-12-19 <b>Last modified:</b> 2009-03-22</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types.generic">issues</a> in [atomics.types.generic].</p> +<p><b>View all 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 it's fairly obvious that <tt>atomic<bool></tt> is supposed to be derived +from <tt>atomic_bool</tt> (and otherwise follow the <tt>atomic<integral></tt> interface), +though I think the current wording doesn't support this. I raised this +point along with <tt>atomic<floating-point></tt> privately with Herb and I seem +to recall it came up in the resulting discussion on this list. However, +I don't see anything on the current libs issue list mentioning this +problem. +</p> <p> -Change 20.7.11.2.5 [unique.ptr.single.modifiers]: +29.5.3 [atomics.types.generic]/3 reads </p> <blockquote> -<pre>void reset(T* p = 0); -</pre> +There are full specializations over the integral types on the atomic +class template. For each integral type integral in the second column of +table 121 or table 122, the specialization <tt>atomic<integral></tt> shall be +publicly derived from the corresponding atomic integral type in the +first column of the table. These specializations shall have trivial +default constructors and trivial destructors. +</blockquote> + +<p> +Table 121 does not include (<tt>atomic_bool</tt>, <tt>bool</tt>), +so that this should probably be mentioned explicitly in the quoted paragraph. +</p> + +<p><i>[ +Summit: +]</i></p> + + <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>. +Move to open. Lawrence will draft a proposed resolution. Also, ask +Howard to fix the title. </blockquote> + +<p><i>[ +Post Summit Anthony provided proposed wording. +]</i></p> + + + +<p><b>Proposed resolution:</b></p> +<p> +Replace paragraph 3 in 29.5.3 [atomics.types.generic] with +</p> + +<blockquote> +-3- There are full specializations over the integral types on the <tt>atomic</tt> +class template. For each integral type <tt>integral</tt> in the second column of +table 121 or table 122, the specialization <tt>atomic<integral></tt> shall be +publicly derived from the corresponding atomic integral type in the first +column of the table. +<ins>In addition, the specialization <tt>atomic<bool></tt> +shall be publicly derived from <tt>atomic_bool</tt>.</ins> +These specializations shall have trivial default +constructors and trivial destructors. </blockquote> + + + + +<hr> +<h3><a name="945"></a>945. <tt>system_clock::rep</tt> not specified</h3> +<p><b>Section:</b> 20.9.5.1 [time.clock.system] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Tentatively NAD Editorial</a> + <b>Submitter:</b> Pete Becker <b>Opened:</b> 2008-12-19 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#time.clock.system">active issues</a> in [time.clock.system].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.clock.system">issues</a> in [time.clock.system].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD%20Editorial">Tentatively NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> <p> -Change 20.7.11.3.3 [unique.ptr.runtime.modifiers]: +In 20.9.5.1 [time.clock.system], the declaration of <tt>system_clock::rep</tt> says "see +below", but there is nothing below that describes it. </p> +<p><i>[ +Howard adds: +]</i></p> + + <blockquote> -<pre>void reset(T* p = 0); -</pre> +<p> +This note refers to: +</p> + <blockquote> -<p>...</p> +-2- <tt>system_clock::duration::min() < system_clock::duration::zero()</tt> shall be <tt>true</tt>. +</blockquote> + <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>. +I.e. this is standardeze for "<tt>system_clock::rep</tt> is signed". +Perhaps an editorial note along the lines of: </p> + +<blockquote> +-2- <tt>system_clock::duration::min() < system_clock::duration::zero()</tt> +shall be <tt>true</tt>. <ins>[<i>Note:</i> <tt>system_clock::rep</tt> shall be signed. <i>-- end note</i>].</ins> </blockquote> + +<p> +? +</p> + </blockquote> +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +We agree with the direction of the proposed resolution. +Move to NAD Editorial. +</blockquote> + + + +<p><b>Proposed resolution:</b></p> +<p> +Add a note to 20.9.5.1 [time.clock.system], p2: +</p> +<blockquote> +-2- <tt>system_clock::duration::min() < system_clock::duration::zero()</tt> +shall be <tt>true</tt>. <ins>[<i>Note:</i> <tt>system_clock::rep</tt> shall be signed. <i>-- end note</i>].</ins> +</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> +<h3><a name="946"></a>946. <tt>duration_cast</tt> improperly specified</h3> +<p><b>Section:</b> 20.9.3.7 [time.duration.cast] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">Tentatively NAD</a> + <b>Submitter:</b> Pete Becker <b>Opened:</b> 2008-12-20 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#time.duration.cast">active issues</a> in [time.duration.cast].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.duration.cast">issues</a> in [time.duration.cast].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD">Tentatively NAD</a> status.</p> <p><b>Discussion:</b></p> +20.9.3.7 [time.duration.cast]/3: + +<blockquote> +.... All intermediate computations shall be +carried out in the widest possible representation... . +</blockquote> + <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. +So ignoring +floating-point types for the moment, all this arithmetic has to be done +using the implementation's largest integral type, even if both arguments +use int for their representation. This seems excessive. And it's not at +all clear what this means if we don't ignore floating-point types. </p> +<p> +This issue is related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#952">952</a>. +</p> -<p><b>Proposed resolution:</b></p> +<p><i>[ +Howard adds: +]</i></p> + + +<blockquote> <p> -Add to 20.4.1.2 [tuple.cnstr]: +The intent of this remark is that intermediate computations are carried out +using: </p> +<blockquote><pre>common_type<typename ToDuration::rep, Rep, intmax_t>::type +</pre></blockquote> + +<p> +The Remark was intended to be clarifying prose supporting the rather algorithmic description +of the previous paragraph. I'm open to suggestions. Perhaps the entire paragraph +3 (Remarks) would be better dropped? +</p> +</blockquote> + +<p><i>[ +Batavia (2009-05): +]</i></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. +We view this as a specific case of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#952">952</a>, +and should be resolved when that issue is resolved. +</p> +<p> +Move to NAD. </p> </blockquote> +<p><b>Proposed resolution:</b></p> +<p> +</p> + + + <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> +<h3><a name="947"></a>947. duration arithmetic: contradictory requirements</h3> +<p><b>Section:</b> 20.9.3.5 [time.duration.nonmember] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> + <b>Submitter:</b> Pete Becker <b>Opened:</b> 2008-12-20 <b>Last modified:</b> 2009-05-23</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.duration.nonmember">issues</a> in [time.duration.nonmember].</p> +<p><b>View all 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> -p4 (forward) says: +In 20.9.3.5 [time.duration.nonmember], paragraph 8 says that calling +<tt>dur / rep</tt> +when <tt>rep</tt> is an instantiation of <tt>duration</tt> requires a diagnostic. +That's followed by an <tt>operator/</tt> that takes two durations. +So <tt>dur1 / dur2</tt> is legal under the second version, +but requires a diagnostic under the first. </p> + +<p><i>[ +Howard adds: +]</i></p> + + +<blockquote> +Please see the thread starting with c++std-lib-22980 for more information. +</blockquote> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +Move to Open, pending proposed wording (and preferably an implementation). +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +</p> + + + + + +<hr> +<h3><a name="948"></a>948. <tt>ratio</tt> arithmetic tweak</h3> +<p><b>Section:</b> 20.4.2 [ratio.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2008-12-26 <b>Last modified:</b> 2009-03-09</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#ratio.arithmetic">active issues</a> in [ratio.arithmetic].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ratio.arithmetic">issues</a> in [ratio.arithmetic].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p> +<p><b>Discussion:</b></p> +<p> +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2800.pdf">N2800</a>, +20.4.2 [ratio.arithmetic] lacks a paragraph from the proposal +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2661.htm">N2661</a>: +</p> + +<blockquote> +<p><b>ratio arithmetic [ratio.arithmetic]</b></p> + +<p> +... If the implementation is unable to form the indicated <tt>ratio</tt> due to +overflow, a diagnostic shall be issued. +</p> +</blockquote> + +<p> +The lack of a diagnostic on compile-time overflow is a significant lack of +functionality. This paragraph could be put back into the WP simply editorially. +However in forming this issue I realized that we can do better than that. This +paragraph should also allow alternative formulations which go to extra lengths +to avoid overflow when possible. I.e. we should not mandate overflow when the +implementation can avoid it. +</p> + +<p> +For example: +</p> + +<blockquote> +<pre>template <class R1, class R2> struct ratio_multiply { + typedef <i>see below</i>} type; +</pre> + <blockquote> -<i>Return type:</i> If <tt>T</tt> is an lvalue-reference type, an lvalue; otherwise, an rvalue. +The nested typedef type shall be a synonym for <tt>ratio<T1, T2></tt> where +<tt>T1</tt> has the value <tt>R1::num * R2::num</tt> and <tt>T2</tt> has the +value <tt>R1::den * R2::den</tt>. </blockquote> +</blockquote> + +<p> +Consider the case where <tt>intmax_t</tt> is a 64 bit 2's complement signed integer, +and we have: +</p> + +<blockquote><pre>typedef std::ratio<0x7FFFFFFFFFFFFFFF, 0x7FFFFFFFFFFFFFF0> R1; +typedef std::ratio<8, 7> R2; +typedef std::ratio_multiply<R1, R2>::type RT; +</pre></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.) +According to the present formulation the implementaiton will multiply +<tt>0x7FFFFFFFFFFFFFFF * 8</tt> which will result in an overflow and subsequently +require a diagnostic. </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.) +However if the implementation is first allowed to divde <tt>0x7FFFFFFFFFFFFFFF</tt> +by <tt>7</tt> obtaining <tt>0x1249249249249249 / 1</tt> and divide +<tt>8</tt> by <tt>0x7FFFFFFFFFFFFFF0</tt> obtaining <tt>1 / 0x0FFFFFFFFFFFFFFE</tt>, +then the exact result can then be computed without overflow: </p> + +<blockquote><pre>[0x7FFFFFFFFFFFFFFF/0x7FFFFFFFFFFFFFF0] * [8/7] = [0x1249249249249249/0x0FFFFFFFFFFFFFFE] +</pre></blockquote> + <p> -Similar with move: +Example implmentation which accomplishes this: </p> + +<blockquote><pre>template <class R1, class R2> +struct ratio_multiply +{ +private: + typedef ratio<R1::num, R2::den> _R3; + typedef ratio<R2::num, R1::den> _R4; +public: + typedef ratio<__ll_mul<_R3::num, _R4::num>::value, + __ll_mul<_R3::den, _R4::den>::value> type; +}; +</pre></blockquote> + +<p><i>[ +Post Summit: +]</i></p> + + <blockquote> -Return type: an rvalue. +Recommend Tentatively Ready. </blockquote> + + + + +<p><b>Proposed resolution:</b></p> <p> -is just wrong and also redundant. +Add a paragraph prior to p1 in 20.4.2 [ratio.arithmetic]: </p> +<blockquote> +Implementations may use other algorithms to compute the indicated ratios to avoid overflow. +If overflow occurs, a diagnostic shall be issued. +</blockquote> + + + + + +<hr> +<h3><a name="949"></a>949. <tt>owner_less</tt></h3> +<p><b>Section:</b> 20.8.13.4 [util.smartptr.ownerless] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> Thomas Plum <b>Opened:</b> 2008-12-30 <b>Last modified:</b> 2009-03-10</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p> +<p><b>Discussion:</b></p> +<p> +20.8.13.4 [util.smartptr.ownerless] (class template <tt>owner_less</tt>) says that +<tt>operator()(x,y)</tt> shall return <tt>x.before(y)</tt>. +</p> +<p> +However, <tt>shared_ptr</tt> and <tt>weak_ptr</tt> have an <tt>owner_before()</tt> but not a +<tt>before()</tt>, and there's no base class to provide a missing <tt>before()</tt>. +</p> +<p> +Being that the class is named <tt>owner_less</tt> , I'm guessing that +"<tt>before()</tt>" should be "<tt>owner_before()</tt>", right? +</p> + +<p><i>[ +Herve adds: +]</i></p> + + +<blockquote> +Agreed with the typo, it should be "shall return <tt>x.owner_before(y)</tt>". +</blockquote> + +<p><i>[ +Post Summit: +]</i></p> + + +<blockquote> +Recommend Tentatively Ready. +</blockquote> + + <p><b>Proposed resolution:</b></p> <p> -Change 20.2.2 [forward] as indicated: +Change 20.8.13.4 [util.smartptr.ownerless] p2: </p> <blockquote> -<pre>template <class T> T&& forward(typename identity<T>::type&& t); -</pre> +-2- <tt>operator()(x,y)</tt> shall return +<tt>x.<ins>owner_</ins>before(y)</tt>. [<i>Note:</i> ... +</blockquote> + + + + + +<hr> +<h3><a name="950"></a>950. unique_ptr converting ctor shouldn't accept array form</h3> +<p><b>Section:</b> 20.8.12.2.1 [unique.ptr.single.ctor] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unique.ptr.single.ctor">active issues</a> in [unique.ptr.single.ctor].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr.single.ctor">issues</a> in [unique.ptr.single.ctor].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p> +<p><b>Discussion:</b></p> +<p> +<tt>unique_ptr</tt>'s of array type should not convert to +<tt>unique_ptr</tt>'s which do not have an array type. +</p> + +<blockquote><pre>struct Deleter +{ + void operator()(void*) {} +}; + +int main() +{ + unique_ptr<int[], Deleter> s; + unique_ptr<int, Deleter> s2(std::move(s)); <font color="#c80000">// should not compile</font> +} +</pre></blockquote> + +<p><i>[ +Post Summit: +]</i></p> + <blockquote> -<p>...</p> <p> -<del><i>Return type:</i> If <tt>T</tt> is an lvalue-reference type, an lvalue; otherwise, an rvalue.</del> +Walter: Does the "diagnostic required" apply to both arms of the "and"? +</p> +<p> +Tom Plum: suggest to break into several sentences +</p> +<p> +Walter: suggest "comma" before the "and" in both places </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>. +Recommend Review. </p> </blockquote> -<pre>template <class T> typename remove_reference<T>::type&& move(T&& t); +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +The post-Summit comments have been applied to the proposed resolution. +We now agree with the proposed resolution. +Move to Tentatively Ready. +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +Change 20.8.12.2.1 [unique.ptr.single.ctor]: +</p> + +<blockquote> +<pre>template <class U, class E> unique_ptr(unique_ptr<U, E>&& u); </pre> +<blockquote> +<p> +-20- <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>unique_ptr<U, E>::pointer</tt> shall be +implicitly convertible to <tt>pointer</tt> <ins>(diagnostic required). <tt>U</tt> shall not be +an array type (diagnostic required)</ins>. [<i>Note:</i> These requirements +imply that <tt>T</tt> and <tt>U</tt> are complete types. -- <i>end note</i>] +</p> +</blockquote> +</blockquote> + +<p> +Change 20.8.12.2.3 [unique.ptr.single.asgn]: +</p> <blockquote> -<p>...</p> +<pre>template <class U, class E> unique_ptr& operator=(unique_ptr<U, E>&& u); +</pre> +<blockquote> <p> -<del><i>Return type:</i> an rvalue.</del> +-6- <i>Requires:</i> Assignment of the deleter <tt>D</tt> from an rvalue +<tt>D</tt> shall not throw an exception. <tt>unique_ptr<U, +E>::pointer</tt> shall be implicitly convertible to <tt>pointer</tt> +<ins>(diagnostic required). <tt>U</tt> shall not be an array type (diagnostic required)</ins>. +[<i>Note:</i> These requirements imply that <tt>T</tt> and <tt>U</tt> +are complete types. -- <i>end note</i>] </p> </blockquote> +</blockquote> + + + + + + +<hr> +<h3><a name="951"></a>951. Various threading bugs #1</h3> +<p><b>Section:</b> 20.9.2.1 [time.traits.is_fp] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> + <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2009-05-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> +Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#953">953</a>. +</p> +<p> +20.9.2.1 [time.traits.is_fp] says that the type <tt>Rep</tt> "is +assumed to be ... a class emulating an integral type." What are the +requirements for such a type? +</p> +<p><i>[ +2009-05-10 Howard adds: +]</i></p> + + +<blockquote> +<tt>IntegralLike</tt>. +</blockquote> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +<p> +As with issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#953">953</a>, +we recommend this issue be addressed in the context of providing concepts for the entire <tt>thread</tt> header. +</p> +<p> +We look forward to proposed wording. +</p> +<p> +Move to Open. +</p> </blockquote> +<p><b>Proposed resolution:</b></p> +<p> +</p> + <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> +<h3><a name="952"></a>952. Various threading bugs #2</h3> +<p><b>Section:</b> 20.9.3.7 [time.duration.cast] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Tentatively NAD Editorial</a> + <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#time.duration.cast">active issues</a> in [time.duration.cast].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.duration.cast">issues</a> in [time.duration.cast].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD%20Editorial">Tentatively NAD Editorial</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> +20.9.3.7 [time.duration.cast] specifies an implementation and imposes +requirements in text (and the implementation doesn't satisfy all of the +text requirements). Pick one. +</p> +<p> +This issue is related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#946">946</a>. +</p> + +<p><i>[ +2009-05-10 Howard adds: +]</i></p> + +<blockquote> <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> +The <i>Remarks</i> paragraph is an English re-statement of the preceeding +<i>Returns</i> clause. It was meant to be clarifying and motivating, not +confusing. I'm not aware with how the <i>Remarks</i> contradicts the <i>Returns</i> clause +but I'm ok with simply removing the <i>Remarks</i>. +</p> +</blockquote> + +<p><i>[ +Batavia (2009-05): +]</i></p> -<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. +<blockquote> +<p> +Pete suggests that this could be resolved +by rephrasing the Remarks to Notes. +</p> +<p> +Move to NAD Editorial. +</p> +</blockquote> +<p><b>Proposed resolution:</b></p> <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> + + + + + +<hr> +<h3><a name="953"></a>953. Various threading bugs #3</h3> +<p><b>Section:</b> 20.9.1 [time.clock.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> + <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#time.clock.req">active issues</a> in [time.clock.req].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.clock.req">issues</a> in [time.clock.req].</p> +<p><b>View all 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> +Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#951">951</a>. </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> +20.9.1 [time.clock.req] says that a clock's <tt>rep</tt> member is "an +arithmetic type or a class emulating an arithmetic type." What are the +requirements for such a type? </p> +<p><i>[ +2009-05-10 Howard adds: +]</i></p> + + +<blockquote> +This wording was aimed directly at the <tt>ArithmeticLike</tt> concept. +</blockquote> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +<p> +We recommend this issue be addressed in the context of providing concepts +for the entire <tt>thread</tt> header. +</p> +<p> +May resolve for now by specifying arithmetic types, +and in future change to <tt>ArithmeticLike</tt>. +However, Alisdair believes this is not feasible. +</p> +<p> +Bill disagrees. +</p> +<p> +We look forward to proposed wording. Move to Open. +</p> +</blockquote> + <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> + + + + + +<hr> +<h3><a name="954"></a>954. Various threading bugs #4</h3> +<p><b>Section:</b> 20.9.1 [time.clock.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> + <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2009-05-30</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#time.clock.req">active issues</a> in [time.clock.req].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.clock.req">issues</a> in [time.clock.req].</p> +<p><b>View all 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> +Table 55 -- Clock Requirements (in 20.9.1 [time.clock.req]) +</p> + +<ol type="a"> +<li> +the requirements for <tt>C1::time_point</tt> require <tt>C1</tt> and <tt>C2</tt> +to "refer to the same epoch", but "epoch" is not defined. +</li> +<li> +"Different clocks may share a <tt>time_point</tt> definition if it is +valid to compare their <tt>time_point</tt>s by comparing their +respective <tt>duration</tt>s." What does "valid" mean here? And, since +<tt>C1::rep</tt> is "**THE** representation type of the native +<tt>duration</tt> and <tt>time_point</tt>" (emphasis added), there +doesn't seem to be much room for some other representation. +</li> +<li> +<tt>C1::is_monotonic</tt> has type "<tt>const bool</tt>". The +"<tt>const</tt>" should be removed. +</li> +<li> +<tt>C1::period</tt> has type <tt>ratio</tt>. <tt>ratio</tt> isn't a type, +it's a template. What is the required type? +</li> +</ol> + +<p><i>[ +2009-05-10 Howard adds: +]</i></p> + + +<ol type="a"> +<li> +<p> +"epoch" is purposefully not defined beyond the common English +<a href="http://www.dictionary.net/epoch">definition</a>. The C standard +also chose not to define epoch, though POSIX did. I believe it is a strength +of the C standard that epoch is not defined. When it is known that two <tt>time_point</tt>s +refer to the same epoch, then a definition of the epoch is not needed to compare +the two <tt>time_point</tt>s, or subtract them. +</p> +<p> +A <tt>time_point</tt> and a <tt>Clock</tt> implicitly refer to an (unspecified) epoch. +The <tt>time_point</tt> represents an offset (<tt>duration</tt>) from an epoch. +</p> +</li> +<li> +<p> +The sentence: </p> <blockquote> -- <tt>T</tt> is <tt>Swappable</tt> if <tt>T</tt> is an array type whose element type is <tt>Swappable</tt>. +Different clocks +may share a <tt>time_point</tt> +definition if it is valid to +compare their <tt>time_point</tt>s by +comparing their respective +<tt>duration</tt>s. </blockquote> + <p> -Add the following to 25.2.3 [alg.swap]: +is redundant and could be removed. I believe the sentence which follows the above: </p> + <blockquote> -<pre>template<class T, size_t N> void swap(T (&a)[N], T (&b)[N]); -</pre> +<tt>C1</tt> and <tt>C2</tt> shall refer to the same epoch. +</blockquote> + +<p> +is sufficient. If two clocks share the same epoch, then by definition, comparing +their <tt>time_point</tt>s is valid. +</p> +</li> +<li> +<tt>is_monotonic</tt> is meant to never change (be <tt>const</tt>). It is also +desired that this value be usable in compile-time computation and branching. +</li> +<li> +<p> +This should probably instead be worded: +</p> <blockquote> -<i>Requires:</i> Type <code>T</code> shall be <tt>Swappable</tt>. +An instantiation of <tt>ratio</tt>. </blockquote> +</li> +</ol> + +<p><i>[ +Batavia (2009-05): +]</i></p> + <blockquote> -<i>Effects:</i> <code>swap_ranges(a, a + N, b);</code> +<p> +Re (a): It is not clear to us whether "epoch" is a term of art. +</p> +<p> +Re (b), (c), and (d): We agree with Howard's comments, +and would consider adding to (c) a <tt>static constexpr</tt> requirement. +</p> +<p> +Move to Open pending proposed wording. +</p> +</blockquote> + +<p><i>[ +2009-05-25 Daniel adds: +]</i></p> + + +<blockquote> +In regards to (d) I suggest to say "a specialization of ratio" instead of +"An instantiation of ratio". This seems to be the better matching standard +core language term for this kind of entity. +</blockquote> + +<p><i>[ +2009-05-25 Ganesh adds: +]</i></p> + + +<blockquote> +<p> +Regarding (a), I found this paper on the ISO website using the term "epoch" consistently with the current wording: +</p> + +<p> +<a href="http://standards.iso.org/ittf/PubliclyAvailableStandards/C030811e_FILES/MAIN_C030811e/text/ISOIEC_18026E_TEMPORAL_CS.HTM">http://standards.iso.org/ittf/PubliclyAvailableStandards/C030811e_FILES/MAIN_C030811e/text/ISOIEC_18026E_TEMPORAL_CS.HTM</a> +</p> +<p> +which is part of ISO/IEC 18026 "Information technology -- Spatial Reference Model (SRM)". +</p> </blockquote> + + + + +<p><b>Proposed resolution:</b></p> +<ol type="a"> +<li> +<p> +Change 20.9.1 [time.clock.req] p1: +</p> +<blockquote> +-1- A clock is a bundle consisting of a native <tt>duration</tt>, a native <tt>time_point</tt>, and a function <tt>now()</tt> to get the +current <tt>time_point</tt>. <ins>The origin of the clock's <tt>time_point</tt> is referred to as the clock's <i>epoch</i> as defined in +section 6.3 of ISO/IEC 18026.</ins> +A clock shall meet the requirements in Table 45. </blockquote> +</li> +<li> +<p> +Remove the sentence from the <tt>time_point</tt> row of the table "Clock Requirements": +</p> +<table border="1"> +<caption>Clock requirements</caption> +<tbody><tr> +<td> +<tt>C1::time_point</tt> +</td> +<td> +<tt>chrono::time_point<C1></tt> or <tt>chrono::time_point<C2, C1::duration></tt> +</td> +<td> +The native <tt>time_point</tt> type of the clock. +<del>Different clocks may share a <tt>time_point</tt> definition if it is valid to compare their <tt>time_point</tt>s by comparing their respective <tt>duration</tt>s.</del> +<tt>C1</tt> and <tt>C2</tt> shall refer to the same epoch. +</td> +</tr> +</tbody></table> +</li> +</ol> +<ol start="4" type="a"> +<li> +<p> +Change the row starting with <tt>C1::period</tt> of the table "Clock Requirements": +</p> +<table border="1"> +<caption>Clock requirements</caption> +<tbody><tr> +<td> +<tt>C1::period</tt> +</td> +<td> +<ins>a specialization of</ins> <tt>ratio</tt> +</td> +<td> +The tick period of the clock in seconds. +</td> +</tr> +</tbody></table> + +</li> +</ol> <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> +<h3><a name="955"></a>955. Various threading bugs #5</h3> +<p><b>Section:</b> 20.9.1 [time.clock.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> + <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2009-06-07</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#time.clock.req">active issues</a> in [time.clock.req].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.clock.req">issues</a> in [time.clock.req].</p> +<p><b>View all 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 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 +20.9.1 [time.clock.req] requires that a clock type have a member +typedef named <tt>time_point</tt> that names an instantiation of the +template <tt>time_point</tt>, and a member named <tt>duration</tt> that +names an instantiation of the template <tt>duration</tt>. This mixing of +levels is confusing. The typedef names should be different from the +template names. </p> -<blockquote><pre>istreambuf_iterator<charT> +<p><i>[ +Post Summit, Anthony provided proposed wording. +]</i></p> + + +<p><i>[ +2009-05-04 Howard adds: +]</i></p> + + +<blockquote> +<p> +The reason that the typedef names were given the same name as the class templates +was so that clients would not have to stop and think about whether they were +using the clock's native <tt>time_point</tt> / <tt>duration</tt> or the class +template directly. In this case, one person's confusion is another person's +encapsulation. The detail that sometimes one is referring to the clock's +native types, and sometimes one is referring to an independent type is +<em>purposefully</em> "hidden" because it is supposed to be an unimportant +detail. It can be confusing to have to remember when to type <tt>duration</tt> +and when to type <tt>duration_type</tt>, and there is no need to require the +client to remember something like that. +</p> + +<p> +For example, here is code that I once wrote in testing out the usability of +this facility: +</p> + +<blockquote><pre>template <class Clock, class Duration> +void do_until(const std::chrono::<b>time_point</b><Clock, Duration>& t) +{ + typename Clock::<b>time_point now</b> = Clock::now(); + if (t > now) + { + typedef typename std::common_type + < + Duration, + typename std::chrono::system_clock::<b>duration</b> + >::type CD; + typedef std::chrono::<b>duration</b><double, std::nano> ID; + + CD d = t - now; + ID us = duration_cast<ID>(d); + if (us < d) + ++us; + ... + } +} </pre></blockquote> <p> -and +I see no rationale to require the client to append <tt>_type</tt> to <em>some</em> +of those declarations. It seems overly burdensome on the author of <tt>do_until</tt>: </p> -<blockquote><pre>ostreambuf_iterator<charT> +<blockquote><pre>template <class Clock, class Duration> +void do_until(const std::chrono::<b>time_point</b><Clock, Duration>& t) +{ + typename Clock::<b>time_point<font color="#c80000">_type</font></b> now = Clock::now(); + if (t > now) + { + typedef typename std::common_type + < + Duration, + typename std::chrono::system_clock::<b>duration<font color="#c80000">_type</font></b> + >::type CD; + typedef std::chrono::<b>duration</b><double, std::nano> ID; + + CD d = t - now; + ID us = duration_cast<ID>(d); + if (us < d) + ++us; + ... + } +} </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. +Additionally I'm fairly certain that this suggestion hasn't been implemented. +If it had, it would have been discovered that it is incomplete. <tt>time_point</tt> +also has a nested type (purposefully) named <tt>duration</tt>. </p> +<blockquote> +That is, the current proposed wording would put the WP into an inconsistent state. +</blockquote> <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>). +In contrast, +the current WP has been implemented and I've received very favorable feedback +from people using this interface in real-world code. </p> +</blockquote> -<p><b>Proposed resolution:</b></p> +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +<p> +Bill agrees that distinct names should be used for distinct kinds of entities. +</p> +<p> +Walter would prefer not to suffix type names, +especially for such well-understood terms as "duration". +</p> +<p> +Howard reminds us that the proposed resolution is incomplete, per his comment +in the issue. +</p> <p> -In 27.6.4 [ext.manip]/3 within function <tt>f</tt> replace the first line +Move to Open. </p> +</blockquote> + +<p><i>[ +2009-06-07 Howard adds: +]</i></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> +<blockquote> <p> -In 27.6.4 [ext.manip]/4 remove the first template <tt>charT</tt> parameter: +Not meaning to be argumentative, but we have a decade of positive experience +with the precedent of using the same name for the nested type as an external +class representing an identical concept. </p> -<blockquote><pre>template <<del>class charT, </del>class moneyT> unspecified put_money(const moneyT& mon, bool intl = false<ins>)</ins>; +<blockquote><pre>template<class Category, class T, class Distance = ptrdiff_t, + class Pointer = T*, class Reference = T&> +struct <b>iterator</b> +{ + ... +}; + +template <BidirectionalIterator Iter> +class <b>reverse_iterator</b> +{ + ... +}; + +template <ValueType T, Allocator Alloc = allocator<T> > + requires NothrowDestructible<T> +class list +{ +public: + typedef <i>implementation-defined</i> <b>iterator</b>; + ... + typedef reverse_iterator<iterator> <b>reverse_iterator</b>; + ... +}; </pre></blockquote> <p> -In 27.6.4 [ext.manip]/5 within function <tt>f</tt> replace the first line +I am aware of <em>zero</em> complaints regarding the use of <tt>iterator</tt> +and <tt>reverse_iterator</tt> as nested types of the containers despite these +names also having related meaning at namespace std scope. </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; - ... +<p> +Would we really be doing programmers a favor by renaming these nested types? +</p> + +<blockquote><pre>template <ValueType T, Allocator Alloc = allocator<T> > + requires NothrowDestructible<T> +class list +{ +public: + typedef <i>implementation-defined</i> <b>iterator_type</b>; + ... + typedef reverse_iterator<iterator> <b>reverse_iterator_type</b>; + ... +}; </pre></blockquote> <p> -In 27.6.4 [ext.manip]/7 within function <tt>f</tt> replace the first line +I submit that such design contributes to needless verbosity which ends up +reducing readability. </p> +</blockquote> -<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; - ... + + +<p><b>Proposed resolution:</b></p> +<p> +Change 20.9 [time]: +</p> + +<blockquote><pre>... +template <class Clock, class Duration = typename Clock::duration<ins>_type</ins>> class time_point; +... </pre></blockquote> <p> -In 27.6.4 [ext.manip]/8 add const: +Change 20.9.1 [time.clock.req]: +</p> + +<blockquote> +<table border="1"> +<caption>Table 45 -- Clock requirements</caption> +<tbody><tr> +<th>Expression</th> +<th>Return type</th> +<th>Operational semantics</th> +</tr> +<tr> +<td>...</td> +<td>...</td> +<td>...</td> +</tr> +<tr> +<td><tt>C1::duration<ins>_type</ins></tt></td> +<td><tt>chrono::duration<C1::rep, C1::period></tt></td> +<td>The native <tt>duration</tt> type of the clock.</td> +</tr> +<tr> +<td><tt>C1::time_point<ins>_type</ins></tt></td> +<td><tt>chrono::time_point<C1></tt> or <tt>chrono::time_point<C2, C1::duration<ins>_type</ins><</tt></td> +<td>The native <tt>time_point</tt> type of the clock. Different clocks may share a <tt>time_point<ins>_type</ins></tt> +definition if it is valid to +compare their <tt>time_point<ins>_type</ins></tt>s by +comparing their respective +<tt>duration<ins>_type</ins></tt>s. <tt>C1</tt> and <tt>C2</tt> shall +refer to the same epoch.</td> +</tr> +<tr> +<td>...</td> +<td>...</td> +<td>...</td> +</tr> +<tr> +<td><tt>C1::now()</tt></td> +<td><tt>C1::time_point<ins>_type</ins></tt></td> +<td>Returns a <tt>time_point<ins>_type</ins></tt> object +representing the current point +in time. +</td> +</tr> +</tbody></table> +</blockquote> + +<p> +Change 20.9.5.1 [time.clock.system]: +</p> + +<blockquote> +<p> +-1- Objects of class <tt>system_clock</tt> represent wall clock time from the system-wide realtime clock. </p> -<blockquote><pre>template <class charT> unspecified put_time(<ins>const</ins> struct tm *tmb, const charT *fmt); +<blockquote><pre>class system_clock { +public: + typedef <i>see below</i> rep; + typedef ratio<<i>unspecified</i>, <i>unspecified</i>> period; + typedef chrono::duration<rep, period> duration<ins>_type</ins>; + typedef chrono::time_point<system_clock> time_point<ins>_type</ins>; + static const bool is_monotonic = <i>unspecified</i> ; + + static time_point<ins>_type</ins> now(); + + // Map to C API + static time_t to_time_t (const time_point<ins>_type</ins>& t); + static time_point<ins>_type</ins> from_time_t(time_t t); +}; </pre></blockquote> <p> -In 27.6.4 [ext.manip]/9 within function <tt>f</tt> replace the first line +-2- <tt>system_clock::duration<ins>_type</ins>::min() < system_clock::duration<ins>_type</ins>::zero()</tt> shall be <tt>true</tt>. </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>time_t to_time_t(const time_point<ins>_type</ins>& t); +</pre> + +<blockquote> +-3- <i>Returns:</i> A <tt>time_t</tt> object that represents the same +point in time as <tt>t</tt> when both values are truncated to the +coarser of the precisions of <tt>time_t</tt> and <tt>time_point<ins>_type</ins></tt>. +</blockquote> + +<pre><tt>time_point<ins>_type</ins></tt> from_time_t(time_t t); +</pre> + +<blockquote> +-4- <i>Returns:</i> A <tt>time_point<ins>_type</ins></tt> object that represents the same point +in time as <tt>t</tt> when both values are truncated to the coarser of the +precisions of <tt>time_t</tt> and <tt>time_point<ins>_type</ins></tt>. +</blockquote> +</blockquote> + +<p> +Change 20.9.5.2 [time.clock.monotonic]: +</p> + +<blockquote><pre>class monotonic_clock { +public: + typedef <i>unspecified</i> rep; + typedef ratio<<i>unspecified</i> , <i>unspecified</i>> period; + typedef chrono::duration<rep, period> duration<ins>_type</ins>; + typedef chrono::time_point<<i>unspecified</i> , duration<ins>_type</ins>> time_point<ins>_type</ins>; + static const bool is_monotonic = true; + + static time_point<ins>_type</ins> now(); +}; </pre></blockquote> <p> -Add to the <tt><iomanip></tt> synopsis in 27.6 [iostream.format] +Change 20.9.5.3 [time.clock.hires]: </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); +<blockquote><pre>class high_resolution_clock { +public: + typedef <i>unspecified</i> rep; + typedef ratio<<i>unspecified</i> , <i>unspecified</i>> period; + typedef chrono::duration<rep, period> duration<ins>_type</ins>; + typedef chrono::time_point<<i>unspecified</i> , duration<ins>_type</ins>> time_point<ins>_type</ins>; + static const bool is_monotonic = true; + + static time_point<ins>_type</ins> now(); +}; </pre></blockquote> @@ -14177,85 +22958,183 @@ template <class charT> unspecified put_time(const struct tm *tmb, const ch <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> +<h3><a name="956"></a>956. Various threading bugs #6</h3> +<p><b>Section:</b> 20.9.1 [time.clock.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> + <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#time.clock.req">active issues</a> in [time.clock.req].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.clock.req">issues</a> in [time.clock.req].</p> +<p><b>View all 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> -<blockquote><pre>#include <utility> +<p> +20.9.1 [time.clock.req] uses the word "native" in several places, +but doesn't define it. What is a "native <tt>duration</tt>"? +</p> + +<p><i>[ +2009-05-10 Howard adds: +]</i></p> + + +<blockquote> +The standard uses "native" in several places without defining it (e.g. +2.14.3 [lex.ccon]). It is meant to mean "that which is defined +by the facility", or something along those lines. In this case it refers +to the nested <tt>time_point</tt> and <tt>duration</tt> types of the clock. +Better wording is welcome. +</blockquote> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +Move to Open pending proposed wording from Pete. +</blockquote> -int main() -{ - std::pair<char *, char *> p (0,0); -} -</pre></blockquote> +<p><b>Proposed resolution:</b></p> <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> + + + +<hr> +<h3><a name="957"></a>957. Various threading bugs #7</h3> +<p><b>Section:</b> 20.9.5.1 [time.clock.system] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> + <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#time.clock.system">active issues</a> in [time.clock.system].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.clock.system">issues</a> in [time.clock.system].</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> -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>): +20.9.5.1 [time.clock.system]: <tt>to_time_t</tt> is overspecified. It +requires truncation, but should allow rounding. For example, suppose a +system has a clock that gives times in milliseconds, but <tt>time()</tt> rounds +those times to the nearest second. Then <tt>system_clock</tt> can't use any +resolution finer than one second, because if it did, truncating times +between half a second and a full second would produce the wrong <tt>time_t</tt> +value. </p> -<blockquote><pre>template<class U , class V > -requires Constructible<T1, U&&> && Constructible<T2, V&&> -pair(U&& x , V&& y ); -</pre></blockquote> +<p><i>[ +Post Summit Anthony Williams provided proposed wording. +]</i></p> + + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +Move to Review pending input from Howard. and other stakeholders. +</blockquote> +<p><i>[ +2009-05-23 Howard adds: +]</i></p> + + +<blockquote> +I am in favor of the wording provided by Anthony. +</blockquote> <p><b>Proposed resolution:</b></p> <p> +In 20.9.5.1 [time.clock.system] replace paragraphs 3 and 4 with: </p> +<blockquote> +<pre>time_t to_time_t(const time_point& t); +</pre> +<blockquote> +-3- <i>Returns:</i> A <tt>time_t</tt> object that represents the same +point in time as <tt>t</tt> when both values are <del>truncated</del> +<ins>restricted</ins> to the coarser of the precisions of +<tt>time_t</tt> and <tt>time_point</tt>. <ins> It is implementation +defined whether values are rounded or truncated to the required +precision.</ins> +</blockquote> + +<pre>time_point from_time_t(time_t t); +</pre> +<blockquote> +-4- <i>Returns:</i> A <tt>time_point</tt> object that represents the +same point in time as <tt>t</tt> when both values are <del>truncated</del> +<ins>restricted</ins> to the +coarser of the precisions of <tt>time_t</tt> and <tt>time_point</tt>. +<ins>It is implementation defined whether values are +rounded or truncated to the required precision.</ins> +</blockquote> +</blockquote> + <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> +<h3><a name="958"></a>958. Various threading bugs #8</h3> +<p><b>Section:</b> 30.5.1 [thread.condition.condvar] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> + <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2009-03-22</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.condition.condvar">active issues</a> in [thread.condition.condvar].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.condition.condvar">issues</a> in [thread.condition.condvar].</p> +<p><b>View all 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> -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. +30.5.1 [thread.condition.condvar]: the specification for <tt>wait_for</tt> +with no predicate has an effects clause that says it calls <tt>wait_until</tt>, +and a returns clause that sets out in words how to determine the return +value. Is this description of the return value subtly different from the +description of the value returned by <tt>wait_until</tt>? Or should the effects +clause and the returns clause be merged? </p> + +<p><i>[ +Summit: +]</i></p> + + +<blockquote> +Move to open. Associate with LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#859">859</a> and any other monotonic-clock +related issues. +</blockquote> + + +<p><b>Proposed resolution:</b></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> + + + + + +<hr> +<h3><a name="959"></a>959. Various threading bugs #9</h3> +<p><b>Section:</b> 30.5.1 [thread.condition.condvar] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> + <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2009-03-22</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.condition.condvar">active issues</a> in [thread.condition.condvar].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.condition.condvar">issues</a> in [thread.condition.condvar].</p> +<p><b>View all 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> +30.5.1 [thread.condition.condvar]: <tt>condition_variable::wait_for</tt> +is required to compute the absolute time by adding the duration value to +<tt>chrono::monotonic_clock::now()</tt>, but <tt>monotonic_clock</tt> is not required to +exist. </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). +Summit: ]</i></p> +<blockquote> +Move to open. Associate with LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#859">859</a> and any other monotonic-clock +related issues. +</blockquote> + <p><b>Proposed resolution:</b></p> <p> @@ -14266,166 +23145,515 @@ Thread-Safety in the Standard Library (Rev 1). <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> +<h3><a name="960"></a>960. Various threading bugs #10</h3> +<p><b>Section:</b> 30.4.1 [thread.mutex.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> + <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2009-03-27</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.mutex.requirements">active issues</a> in [thread.mutex.requirements].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.mutex.requirements">issues</a> in [thread.mutex.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> -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> +30.4.1 [thread.mutex.requirements]: paragraph 4 is entitled +"Error conditions", but according to 17.5.1.4 [structure.specifications], "Error +conditions:" specifies "the error conditions for error codes reported by +the function." It's not clear what this should mean when there is no +function in sight. </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: +Summit: ]</i></p> <blockquote> +Move to open. +</blockquote> + +<p><i>[ +Beman provided proposed wording. +]</i></p> + + + +<p><b>Proposed resolution:</b></p> <p> -Or, what is an "empty" <tt>shared_ptr</tt>? +Change 30.4.1 [thread.mutex.requirements] Mutex requirements, +paragraph 4 as indicated: </p> +<blockquote> +<p> +-4- <del><i>Error conditions:</i></del> +<ins>The error conditions for error codes, if any, reported by member +functions of type Mutex shall be:</ins> +</p> <ul> <li> +<tt>not_enough_memory</tt> -- if there is not enough memory to construct +the mutex object. +</li> +<li> +<tt>resource_unavailable_try_again</tt> -- if any native handle type +manipulated is not available. +</li> +<li> +<tt>operation_not_permitted</tt> -- if the thread does not have the +necessary permission to change the state of the mutex object. +</li> +<li> +<tt>device_or_resource_busy</tt> -- if any native handle type +manipulated is already locked. +</li> +<li> +<tt>invalid_argument</tt> -- if any native handle type manipulated as +part of mutex construction is incorrect. +</li> +</ul> +</blockquote> + + + + + +<hr> +<h3><a name="961"></a>961. Various threading bugs #11</h3> +<p><b>Section:</b> 30.4.1 [thread.mutex.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> + <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2009-03-22</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.mutex.requirements">active issues</a> in [thread.mutex.requirements].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.mutex.requirements">issues</a> in [thread.mutex.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> -Are any other <tt>shared_ptrs</tt> empty? +30.4.1 [thread.mutex.requirements] describes required member +functions of mutex types, and requires that they throw exceptions under +certain circumstances. This is overspecified. User-defined types can +abort on such errors without affecting the operation of templates +supplied by standard-library. </p> + +<p><i>[ +Summit: +]</i></p> + +<blockquote> +Move to open. Related to conceptualization and should probably be +tackled as part of that. +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +</p> + + + + + +<hr> +<h3><a name="962"></a>962. Various threading bugs #12</h3> +<p><b>Section:</b> 30.4.3.2.2 [thread.lock.unique.locking] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> + <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2009-03-22</p> +<p><b>View all 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> -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. +30.4.3.2.2 [thread.lock.unique.locking]: <tt>unique_lock::lock</tt> is +required to throw an object of type <tt>std::system_error</tt> "when the +postcondition cannot be achieved." The postcondition is <tt>owns == true</tt>, +and this is trivial to achieve. Presumably, the requirement is intended +to mean something more than that. </p> + +<p><i>[ +Summit: +]</i></p> + <blockquote> -(*) If it isn't, this is a legitimate defect. +Move to open. </blockquote> -</li> -<li> +<p><i>[ +Beman has volunteered to provide proposed wording. +]</i></p> + + + + +<p><b>Proposed resolution:</b></p> +<p> +</p> + + + + + +<hr> +<h3><a name="963"></a>963. Various threading bugs #13</h3> +<p><b>Section:</b> 30.3.1.5 [thread.thread.member] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> + <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2009-03-22</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.thread.member">active issues</a> in [thread.thread.member].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.thread.member">issues</a> in [thread.thread.member].</p> +<p><b>View all 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> -For example, is <tt>shared_ptr((T*) 0)</tt> empty? +30.3.1.5 [thread.thread.member]: <tt>thread::detach</tt> is required to +throw an exception if the thread is "not a detachable thread". +"Detachable" is never defined. </p> + +<p><i>[ +Howard adds: +]</i></p> + + +<blockquote> +Due to a mistake on my part, 3 proposed resolutions appeared at approximately +the same time. They are all three noted below in the discussion. +</blockquote> + +<p><i>[ +Summit, proposed resolution: +]</i></p> + + +<blockquote> <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. +In 30.3.1.5 [thread.thread.member] change: </p> -</li> -<li> +<blockquote><pre>void detach(); +</pre> +<blockquote> +<p>...</p> +<p>-14- <i>Error conditions:</i></p> +<ul> +<li><tt>no_such_process</tt> -- <ins>if the thread is</ins> not <del>a</del> valid<del> thread</del>.</li> +<li><tt>invalid_argument</tt> -- <ins>if the thread is</ins> not <del>a detachable</del> <ins>joinable</ins><del> thread</del>.</li> +</ul> +</blockquote> + +</blockquote> + +</blockquote> + +<p><i>[ +Post Summit, Jonathan Wakely adds: +]</i></p> + + +<blockquote> <p> -What are the properties of an empty <tt>shared_ptr</tt>? +A <tt>thread</tt> is detachable if it is joinable. As we've defined joinable, +we can just use that. </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. +This corresponds to the pthreads specification, where pthread_detach +fails if the thread is not joinable: </p> -</li> - -<li> +<blockquote> +EINVAL: The implementation has detected that the value specified by +thread does not refer to a joinable thread. +</blockquote> <p> -We should either clarify this term or stop using it. +Jonathan recommends this proposed wording: </p> +<blockquote> <p> -I don't agree with the imperative tone +In 30.3.1.5 [thread.thread.member] change: </p> + +<blockquote><pre>void detach(); +</pre> +<blockquote> +<p>...</p> +<p>-14- <i>Error conditions:</i></p> +<ul> +<li>...</li> +<li><tt>invalid_argument</tt> -- not a <del>detachable</del> <ins>joinable</ins> thread.</li> +</ul> +</blockquote> + +</blockquote> +</blockquote> +</blockquote> + +<p><i>[ +Post Summit, Anthony Williams adds: +]</i></p> + + +<blockquote> <p> -A clarification would be either a no-op - if it doesn't contradict the -existing wording - or a big mistake if it does. +This is covered by the precondition that <tt>joinable()</tt> be <tt>true</tt>. </p> <p> -I agree that a clarification that is formally a no-op may add value. +Anthony recommends this proposed wording: </p> -</li> -<li> +<blockquote> <p> -However, that term is nowhere defined. +In 30.3.1.5 [thread.thread.member] change: </p> + +<blockquote><pre>void detach(); +</pre> +<blockquote> +<p>...</p> +<p>-14- <i>Error conditions:</i></p> +<ul> +<li>...</li> +<li><del><tt>invalid_argument</tt> -- not a detachable thread.</del></li> +</ul> +</blockquote> + +</blockquote> + +</blockquote> + +</blockquote> + + + +<p><b>Proposed resolution:</b></p> + + + + + +<hr> +<h3><a name="964"></a>964. Various threading bugs #14</h3> +<p><b>Section:</b> 30.5.2 [thread.condition.condvarany] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> + <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2009-03-22</p> +<p><b>View all 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> -Terms can be useful without a definition. Consider the following -simplistic example. We have a type <tt>X</tt> with the following operations -defined: +The requirements for the constructor for <tt>condition_variable</tt> has several +error conditions, but the requirements for the constructor for +<tt>condition_variable_any</tt> has none. Is this difference intentional? </p> -<blockquote><pre>X x; -X x2(x); -X f(X x); -X g(X x1, X x2); -</pre></blockquote> + +<p><i>[ +Summit: +]</i></p> + + +<blockquote> +Move to open, pass to Howard. If this is intentional, a note may be +helpful. If the error conditions are to be copied from +<tt>condition_variable</tt>, this depends on LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#965">965</a>. +</blockquote> + +<p><i>[ +Post Summit Howard adds: +]</i></p> + + +<blockquote> +The original intention +(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2447.htm#ConditionVariablesWording">N2447</a>) +was to let the OS return whatever errors it was going to return, and for +those to be translated into exceptions, for both +<tt>condition_variable</tt> and <tt>condition_variable_any</tt>. I have not +received any complaints about specific error conditions from vendors on +non-POSIX platforms, but such complaints would not surprise me if they surfaced. +</blockquote> + + +<p><b>Proposed resolution:</b></p> + + + + + +<hr> +<h3><a name="965"></a>965. Various threading bugs #15</h3> +<p><b>Section:</b> 30.5.1 [thread.condition.condvar] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.condition.condvar">active issues</a> in [thread.condition.condvar].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.condition.condvar">issues</a> in [thread.condition.condvar].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p> +<p><b>Discussion:</b></p> <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. +30.5.1 [thread.condition.condvar]: the constructor for +<tt>condition_variable</tt> throws an exception with error code +<tt>device_or_resource_busy</tt> "if attempting to initialize a +previously-initialized but as of yet undestroyed <tt>condition_variable</tt>." +How can this occur? </p> +<p><i>[ +Summit: +]</i></p> + +<blockquote> <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. +Move to review. Proposed resolution: strike the <tt>device_or_resource_busy</tt> +error condition from the constructor of <tt>condition_variable</tt>. </p> +<ul> +<li> +This is a POSIX error that cannot occur in this interface because the +C++ interface does not separate declaration from initialization. +</li> +</ul> +</blockquote> +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +We agree with the proposed resolution. +Move to Tentatively Ready. +</blockquote> + + +<p><b>Proposed resolution:</b></p> <p> -Green and red are "nowhere defined" and completely defined at the same time. +Change 30.5.1 [thread.condition.condvar] p3: </p> + +<blockquote> +<ul> +<li>...</li> +<li> +<del><tt>device_or_resource_busy</tt> -- if attempting to initialize a +previously-initialized but as of yet undestroyed +<tt>condition_variable</tt>.</del> </li> </ul> +</blockquote> + + + + +<hr> +<h3><a name="966"></a>966. Various threading bugs #16</h3> +<p><b>Section:</b> 30.5.1 [thread.condition.condvar] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> + <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2009-03-22</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.condition.condvar">active issues</a> in [thread.condition.condvar].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.condition.condvar">issues</a> in [thread.condition.condvar].</p> +<p><b>View all 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> -Alisdair's wording is fine. +30.5.1 [thread.condition.condvar]: <tt>condition_variable::wait</tt> and +<tt>condition_variable::wait_until</tt> both have a postcondition that <tt>lock</tt> is +locked by the calling thread, and a throws clause that requires throwing +an exception if this postcondition cannot be achieved. How can the +implementation detect that this <tt>lock</tt> can never be obtained? </p> + +<p><i>[ +Summit: +]</i></p> + + +<blockquote> +Move to open. Requires wording. Agreed this is an issue, and the +specification should not require detecting deadlocks. </blockquote> <p><b>Proposed resolution:</b></p> + + + + + +<hr> +<h3><a name="967"></a>967. Various threading bugs #17</h3> +<p><b>Section:</b> 30.3.1.2 [thread.thread.constr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> + <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2009-03-22</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.thread.constr">active issues</a> in [thread.thread.constr].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.thread.constr">issues</a> in [thread.thread.constr].</p> +<p><b>View all 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 error handling for the constructor for <tt>condition_variable</tt> +distinguishes lack of memory from lack of other resources, but the error +handling for the thread constructor does not. Is this difference +intentional? +</p> + +<p><i>[ +Beman has volunteered to provide proposed wording. +]</i></p> + + + +<p><b>Proposed resolution:</b></p> +<p> +</p> + + + + + +<hr> +<h3><a name="968"></a>968. Various threading bugs #18</h3> +<p><b>Section:</b> 30.4.1 [thread.mutex.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> + <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2009-03-22</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.mutex.requirements">active issues</a> in [thread.mutex.requirements].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.mutex.requirements">issues</a> in [thread.mutex.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> -Append the following sentance to 20.7.12.2 [util.smartptr.shared] +30.4.1 [thread.mutex.requirements]: several functions are +required to throw exceptions "if the thread does not have the necessary +permission ...". "The necessary permission" is not defined. </p> + +<p><i>[ +Summit: +]</i></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> +Move to open. </blockquote> +<p><i>[ +Beman has volunteered to provide proposed wording. +]</i></p> + + + +<p><b>Proposed resolution:</b></p> +<p> +</p> + + <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> +<h3><a name="969"></a>969. What happened to Library Issue 475?</h3> +<p><b>Section:</b> 25.3.4 [alg.foreach] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Tentatively NAD Editorial</a> + <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2009-01-12 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#alg.foreach">active issues</a> in [alg.foreach].</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#Tentatively%20NAD%20Editorial">Tentatively NAD Editorial</a> status.</p> <p><b>Discussion:</b></p> <p> -<tt>vector<bool>::swap(reference, reference)</tt> has no definition. +Library Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#475">475</a> has CD1 status, but the non-normative note in +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a> +was removed in +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdf">N2798</a> +(25.3.4 [alg.foreach] in both drafts). </p> +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +Move to NAD Editorial. +</blockquote> + <p><b>Proposed resolution:</b></p> <p> +Restore the non-normative note. It might need to be expressed in terms of concepts. </p> @@ -14433,569 +23661,1880 @@ a pointer is said to be <i>empty</i>.</ins> <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> +<h3><a name="970"></a>970. addressof overload unneeded</h3> +<p><b>Section:</b> 20.8.11.1 [object.addressof] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-01-16 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#object.addressof">active issues</a> in [object.addressof].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#object.addressof">issues</a> in [object.addressof].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</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. +20.8.11.1 [object.addressof] specifies: +</p> + +<blockquote><pre>template <ObjectType T> T* addressof(T& r); +template <ObjectType T> T* addressof(T&& r); +</pre></blockquote> + +<p> +The two signatures are ambiguous when the argument is an lvalue. The +second signature seems not useful: what does it mean to take the +address of an rvalue? </p> <p><i>[ -Sophia Antipolis: +Post Summit: ]</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. +Recommend Review. </blockquote> +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +We agree with the proposed resolution. +Move to Tentatively Ready. +</blockquote> <p><b>Proposed resolution:</b></p> <p> +Change 20.8.11.1 [object.addressof]: </p> +<blockquote><pre>template <ObjectType T> T* addressof(T& r); +<del>template <ObjectType T> T* addressof(T&& r);</del> +</pre></blockquote> + + <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> +<h3><a name="971"></a>971. Spurious diagnostic conversion function</h3> +<p><b>Section:</b> 19.5.2.6 [syserr.errcode.nonmembers] <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>Opened:</b> 2009-01-19 <b>Last modified:</b> 2009-05-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> -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. +Anthony Williams raised the question in c++std-lib-22987 "why is there +<tt>std::make_error_code(std::errc)</tt>? What purpose does this serve?" </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.) +The function <tt>make_error_code(errc e)</tt> is not required, since +<tt>make_error_condition(errc e)</tt> is the function that is needed for <tt>errc</tt> +conversions. <tt>make_error_code(errc e)</tt> appears to be a holdover from my +initial confusion over the distinction between POSIX and operating +systems that conform to the POSIX spec. </p> + +<p><i>[ +Post Summit: +]</i></p> + + +<blockquote> +Recommend Review. +</blockquote> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +The designer of the facility (Christopher Kohlhoff) +strongly disagrees that there is an issue here, +and especially disagrees with the proposed resolution. +Bill would prefer to be conservative and not apply this proposed resolution. +Move to Open, and recommend strong consideration for NAD status. +</blockquote> + +<p><i>[ +2009-05-21 Beman adds: +]</i></p> + + +<blockquote> +My mistake. Christopher and Bill are correct and the issue should be +NAD. The function is needed by users. +</blockquote> + + +<p><b>Proposed resolution:</b></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? +Change System error support 19.5 [syserr], Header <tt><system_error></tt> +synopsis, as indicated: +</p> + +<blockquote><pre><del>error_code make_error_code(errc e);</del> +error_condition make_error_condition(errc e); +</pre></blockquote> + +<p> +Delete from Class error_code non-member functions +19.5.2.6 [syserr.errcode.nonmembers]: +</p> + +<blockquote><pre><del>error_code make_error_code(errc e);</del> +</pre> +<blockquote> +<del><i>Returns:</i> <tt>error_code(static_cast<int>(e), +generic_category)</tt>.</del> +</blockquote> +</blockquote> + + + + + + +<hr> +<h3><a name="972"></a>972. The term "Assignable" undefined but still in use</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">Tentatively NAD Editorial</a> + <b>Submitter:</b> Niels Dekker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</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#Tentatively%20NAD%20Editorial">Tentatively NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Previous versions of the Draft had a table, defining the Assignable +requirement. For example +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2134.pdf">N2134</a> +Table 79, "Assignable requirements". But I guess the term "Assignable" +is outdated by now, because the current Committee Draft provides +<tt>MoveAssignable</tt>, <tt>CopyAssignable</tt>, and <tt>TriviallyCopyAssignable</tt> concepts +instead. And as far as I can see, it no longer has a definition of +<tt>Assignable</tt>. (Please correct me if I'm wrong.) Still the word +"Assignable" is used in eight places in the Draft, +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2800.pdf">N2800</a>. +</p> + +<p> +Are all of those instances of "<tt>Assignable</tt>" to be replaced by "<tt>CopyAssignable</tt>"? </p> <p><i>[ -Howard adds: +Batavia (2009-05): ]</i></p> +<blockquote> +Move to NAD Editorial. +</blockquote> + +<p><b>Proposed resolution:</b></p> + +<p> +Change Exception Propagation 18.8.5 [propagation]: +</p> <blockquote> -<tt>tuple</tt> construction should probably have a similar guarantee. +<tt>exception_ptr</tt> shall be <tt>DefaultConstructible</tt>, <tt>CopyConstructible</tt>, +<tt><ins>Copy</ins>Assignable</tt> and <tt>EqualityComparable</tt>. +</blockquote> + +<p> +Change Class template reference_wrapper 20.7.5 [refwrap]: +</p> +<blockquote> +<tt>reference_wrapper<T></tt> is a <tt>CopyConstructible</tt> and <tt><ins>Copy</ins>Assignable</tt> wrapper around a reference to an object of type <tt>T</tt>. +</blockquote> +<p> +Change Placeholders 20.7.12.1.4 [func.bind.place]: +</p> +<blockquote> +It is implementation defined whether placeholder types are <tt><ins>Copy</ins>Assignable</tt>. <tt><ins>Copy</ins>Assignable</tt> placeholders' copy assignment operators shall not throw exceptions. +</blockquote> +<p> +Change Class template shared_ptr 20.8.13.2 [util.smartptr.shared]: +</p> +<blockquote> +Specializations of <tt>shared_ptr</tt> shall be <tt>CopyConstructible</tt>, <tt><ins>Copy</ins>Assignable</tt>, and <tt>LessThanComparable</tt>... +</blockquote> +<p> +Change Class template weak_ptr 20.8.13.3 [util.smartptr.weak]: +</p> +<blockquote> +Specializations of <tt>weak_ptr</tt> shall be <tt>CopyConstructible</tt>, <tt><ins>Copy</ins>Assignable</tt>, and <tt>LessThanComparable</tt>... +</blockquote> +<p> +Change traits typedefs 21.2.2 [char.traits.typedefs] (note: including deletion of reference to 23.1!): +</p> +<blockquote> +<i>Requires:</i> <tt>state_type</tt> shall meet the requirements of <tt><ins>Copy</ins>Assignable</tt><del> (23.1)</del>, <tt>CopyConstructible</tt> (20.1.8), and <tt>DefaultConstructible</tt> types. +</blockquote> +<p> +Change Class seed_seq 26.5.7.1 [rand.util.seedseq] (note again: including deletion of reference to 23.1!): +</p> +<blockquote> +In addition to the requirements set forth below, instances of +<tt>seed_seq</tt> shall meet the requirements of <tt>CopyConstructible</tt> (20.1.8) and of <tt><ins>Copy</ins>Assignable</tt><del> (23.1)</del>. </blockquote> +<p> +Note: The proposed resolution of this issue does not deal with the +instance of the term "Assignable" in D.9.1 [auto.ptr], as this is dealt +with more specifically by LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#973">973</a>, "<tt>auto_ptr</tt> characteristics", submitted +by Maarten Hilferink. +</p> + + + + + + +<hr> +<h3><a name="973"></a>973. auto_ptr characteristics</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%20Editorial">Tentatively NAD Editorial</a> + <b>Submitter:</b> Maarten Hilferink <b>Opened:</b> 2009-01-21 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#auto.ptr">active issues</a> in [auto.ptr].</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#Tentatively%20NAD%20Editorial">Tentatively NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<p> +I think that the Note of D.9.1 [auto.ptr], paragraph 3 needs a rewrite +since "Assignable" is no longer defined as a concept. +The relationship of <tt>auto_ptr</tt> with the new <tt>CopyAssignable</tt>, <tt>MoveAssignable</tt>, + and <tt>MoveConstructible</tt> concepts should be clarified. +Furthermore, since the use of <tt>auto_ptr</tt> is depreciated anyway, + we can also omit a description of its intended use. +</p> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +We agree with the intent of the proposed resolution. +Move to NAD Editorial. +</blockquote> <p><b>Proposed resolution:</b></p> <p> +Change D.9.1 [auto.ptr], paragraph 3: </p> +<blockquote> +The <tt>auto_ptr</tt> provides a semantics of strict ownership. An +<tt>auto_ptr</tt> owns the ob ject 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 ob ject at +the same time the behavior of the program is undefined. [<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. +<del><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.</del> + +<ins>Instances of <tt>auto_ptr</tt> shall +meet the <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt> +requirements, but do not meet the <tt>CopyConstructible</tt> and +<tt>CopyAssignable</tt> requirements.</ins> +-- <i>end note</i>] +</blockquote> + <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> +<h3><a name="974"></a>974. <tt>duration<double></tt> should not implicitly convert to <tt>duration<int></tt></h3> +<p><b>Section:</b> 20.9.3.1 [time.duration.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-01-21 <b>Last modified:</b> 2009-05-23</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</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>. +The following code should not compile because it involves implicit truncation +errors (against the design philosophy of the <tt>duration</tt> library). </p> + +<blockquote><pre>duration<double> d(3.5); +duration<int> i = d; <font color="#c80000">// implicit truncation, should not compile</font> +</pre></blockquote> + <p> -This issue is related to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#816">816</a>. +This intent was codified in the example implementation which drove this proposal +but I failed to accurately translate the code into the specification in this +regard. +</p> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +<p> +We agree with the proposed resolution. </p> +<p> +Move to Tentatively Ready. +</p> +</blockquote> <p><b>Proposed resolution:</b></p> <p> +Change 20.9.3.1 [time.duration.cons], p4: </p> +<blockquote> +<pre>template <class Rep2, class Period2> + duration(const duration<Rep2, Period2>& d); +</pre> +<blockquote> +-4- <i>Requires:</i> <tt>treat_as_floating_point<rep>::value</tt> +shall be <tt>true</tt> or <ins>both</ins> <tt>ratio_divide<Period2, +period>::type::den</tt> shall be 1 +<ins>and <tt>treat_as_floating_point<Rep2>::value</tt> +shall be <tt>false</tt></ins>. +Diagnostic required. +[<i>Note:</i> This requirement prevents implicit truncation error when +converting between integral-based <tt>duration</tt> types. Such a +construction could easily lead to confusion about the value of the +<tt>duration</tt>. -- <i>end note</i>] +</blockquote> +</blockquote> + <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> +<h3><a name="975"></a>975. <tt>is_convertible</tt> cannot be instantiated for non-convertible types</h3> +<p><b>Section:</b> 20.6.5 [meta.rel] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-01-25 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta.rel">active issues</a> in [meta.rel].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.rel">issues</a> in [meta.rel].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p> <p><b>Discussion:</b></p> + +<b>Addresses UK 206</b> + +<p> +Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1114">1114</a>. +</p> + +<p> +The current specification of <tt>std::is_convertible</tt> (reference is draft +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdf">N2798</a>) +is basically defined by 20.6.5 [meta.rel]/4: +</p> + +<blockquote> +<p> +In order to instantiate the template <tt>is_convertible<From, +To></tt>, the following code shall be well formed: +</p> + +<blockquote><pre>template <class T> + typename add_rvalue_reference<T>::type create(); + +To test() { + return create<From>(); +} +</pre></blockquote> + <p> -29.1 [atomics.order] p1 says in the table that +[<i>Note:</i> This requirement gives well defined results for reference +types, void types, array types, and function types. --<i>end note</i>] </p> +</blockquote> +<p> +The first sentence can be interpreted, that e.g. the expression +</p> + +<blockquote><pre>std::is_convertible<double, int*>::value +</pre></blockquote> + +<p> +is ill-formed because <tt>std::is_convertible<double, int*></tt> could not be +instantiated, or in more general terms: The wording requires that +<tt>std::is_convertible<X, Y></tt> cannot be instantiated for otherwise valid +argument types <tt>X</tt> and <tt>Y</tt> if <tt>X</tt> is not convertible to <tt>Y</tt>. +</p> + +<p> +This semantic is both unpractical and in contradiction to what the last type +traits paper +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2255.html">N2255</a> +proposed: +</p> + +<blockquote> +<p> +If the following <tt>test</tt> function is well formed code <tt>b</tt> +is <tt>true</tt>, else it is <tt>false</tt>. +</p> + +<blockquote><pre>template <class T> + typename add_rvalue_reference<T>::type create(); + +To test() { + return create<From>(); +} +</pre></blockquote> + +<p> +[<i>Note:</i> This definition gives well defined results for <tt>reference</tt> +types, <tt>void</tt> types, array types, and function types. --<i>end note</i>] +</p> +</blockquote> + +<p><i>[ +Post Summit: +]</i></p> + + +<blockquote> +<p> +Jens: Checking that code is well-formed and then returning true/false +sounds like speculative compilation. John Spicer would really dislike +this. Please find another wording suggesting speculative compilation. +</p> +<p> +Recommend Open. +</p> +</blockquote> + +<p><i>[ +Post Summit, Howard adds: +]</i></p> + + +<blockquote> +<p> +John finds the following wording clearer: +</p> <blockquote> + <table border="1"> <tbody><tr> -<th>Element</th><th>Meaning</th> +<th>Template</th><th>Condition</th><th>Comments</th> </tr> <tr> -<td><tt>memory_order_acq_rel</tt></td> -<td>the operation has both acquire and release semantics</td> +<td><tt>template <class From, class To><br>struct is_convertible;</tt></td> +<td><i>see below</i></td> +<td><tt>From</tt> and <tt>To</tt> shall be complete types, arrays of unknown bound, +or (possibly cv-qualified) <tt>void</tt> types.</td> </tr> </tbody></table> + +<p> +Given the following function prototype: +</p> + +<blockquote><pre>template <class T> + typename add_rvalue_reference<T>::type create(); +</pre></blockquote> + +<p> +<tt>is_convertible<From, To>::value</tt> shall be <tt>true</tt> if the +return expression in the following code would be well-formed, including +any implicit conversions to the return type of the function, else +<tt>is_convertible<From, To>::value</tt> shall be <tt>false</tt>. +</p> + +<blockquote><pre>To test() { + return create<From>(); +} +</pre></blockquote> + +</blockquote> + </blockquote> +<b>Original proposed wording:</b> + <p> -To my naked eye, that seems to imply that even an atomic read has both -acquire and release semantics. +In 20.6.5 [meta.rel]/4 change: </p> +<blockquote> +<del>In order to instantiate the template <tt>is_convertible<From, To></tt>, the +following code shall be well formed</del> <ins>If the following code +is well formed <tt>is_convertible<From, To>::value</tt> is <tt>true</tt>, otherwise +<tt>false</tt></ins>:[..] +</blockquote> + +<p><b>Revision 2</b></p> + +<blockquote> + <p> -Then, p1 says in the table: +In 20.6.5 [meta.rel] change: </p> <blockquote> + <table border="1"> <tbody><tr> -<th>Element</th><th>Meaning</th> +<th>Template</th><th>Condition</th><th>Comments</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><tr><td>...</td><td>...</td><td>...</td></tr> +<tr><td><tt>template <class From, class To><br>struct is_convertible;</tt></td> +<td> +<del>The code set out below shall be well formed.</del> +<ins><i>see below</i></ins></td> +<td><tt>From</tt> and <tt>To</tt> shall be complete types, arrays of unknown bound, +or (possibly cv-qualified) <tt>void</tt> types.</td> </tr> </tbody></table> -</blockquote> <p> -So that seems to be "the same thing" as <tt>memory_order_acq_rel</tt>, with additional -constraints. +-4- <del>In order to instantiate the template <tt>is_convertible<From, To></tt>, the +following code shall be well formed:</del> +<ins>Given the following function prototype:</ins> </p> +<blockquote><pre>template <class T> + typename add_rvalue_reference<T>::type create(); +</pre></blockquote> + <p> -I'm then reading p2, where it says: +<ins><tt>is_convertible<From, To>::value</tt> inherits either directly or +indirectly from <tt>true_type</tt> if the +return expression in the following code would be well-formed, including +any implicit conversions to the return type of the function, else +<tt>is_convertible<From, To>::value</tt> inherits either directly or +indirectly from <tt>false_type</tt>.</ins> </p> +<blockquote><pre>To test() { + return create<From>(); +} +</pre></blockquote> + +<p> +[<i>Note:</i> This requirement gives well defined results for reference types, +void types, array types, and function types. <i>-- end note</i>] +</p> + +</blockquote> +</blockquote> + +<p><i>[ +Batavia (2009-05): +]</i></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. +We agree with the proposed resolution. +Move to Tentatively Ready. </blockquote> + +<p><b>Proposed resolution:</b></p> + <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? +In 20.6.5 [meta.rel] change: </p> +<blockquote> + +<table border="1"> +<tbody><tr> +<th>Template</th><th>Condition</th><th>Comments</th> +</tr> +<tr> +</tr><tr><td>...</td><td>...</td><td>...</td></tr> +<tr><td><tt>template <class From, class To><br>struct is_convertible;</tt></td> +<td> +<del>The code set out below shall be well formed.</del> +<ins><i>see below</i></ins></td> +<td><tt>From</tt> and <tt>To</tt> shall be complete types, arrays of unknown bound, +or (possibly cv-qualified) <tt>void</tt> types.</td> +</tr> +</tbody></table> + <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. +-4- <del>In order to instantiate the template <tt>is_convertible<From, To></tt>, the +following code shall be well formed:</del> +<ins>Given the following function prototype:</ins> </p> +<blockquote><pre>template <class T> + typename add_rvalue_reference<T>::type create(); +</pre></blockquote> + <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.) +<ins>the predicate condition for a template specialization +<tt>is_convertible<From, To></tt> shall be satisfied, if and only +if the return expression in the following code would be well-formed, +including any implicit conversions to the return type of the +function.</ins> </p> +<blockquote><pre>To test() { + return create<From>(); +} +</pre></blockquote> + +<p> +[<i>Note:</i> This requirement gives well defined results for reference types, +void types, array types, and function types. <i>— end note</i>] +</p> + +</blockquote> + + + + + +<hr> +<h3><a name="976"></a>976. Class template std::stack should be movable</h3> +<p><b>Section:</b> 23.3.5.3.1 [stack.defn] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-02-01 <b>Last modified:</b> 2009-05-23</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p> +<p><b>Discussion:</b></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. +The synopsis given in 23.3.5.3.1 [stack.defn] does not show up </p> +<blockquote><pre>requires MoveConstructible<Cont> stack(stack&&); +requires MoveAssignable<Cont> stack& operator=(stack&&); +</pre></blockquote> + <p> -And why does 29.4 [atomics.types.operations] p9 for "load" say: +although the other container adaptors do provide corresponding +members. </p> +<p><i>[ +Batavia (2009-05): +]</i></p> <blockquote> -<i>Requires:</i> The order argument shall not be <tt>memory_order_acquire</tt> -nor <tt>memory_order_acq_rel</tt>. +<p> +We agree with the proposed resolution. +</p> +<p> +Move to Tentatively Ready. +</p> </blockquote> + +<p><b>Proposed resolution:</b></p> +<p> +In the class stack synopsis of 23.3.5.3.1 [stack.defn] insert: +</p> + +<blockquote><pre>template <ObjectType T, StackLikeContainer Cont = deque<T> > + requires SameType<Cont::value_type, T> + && NothrowDestructible<Cont> +class stack { +public: + ... + requires CopyConstructible<Cont> explicit stack(const Cont&); + requires MoveConstructible<Cont> explicit stack(Cont&& = Cont()); + <ins>requires MoveConstructible<Cont> stack(stack&&);</ins> + <ins>requires MoveAssignable<Cont> stack& operator=(stack&&);</ins> + template <class Alloc> + requires Constructible<Cont, const Alloc&> + explicit stack(const Alloc&); + ... +}; +</pre></blockquote> + <p> -(Since this is exactly the same restriction as for "store", it seems to be a typo.) +[Remark: This change should be done in sync with the resolution of +paper +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2819.html">N2819</a>] </p> + + + + + +<hr> +<h3><a name="977"></a>977. insert iterators inefficient for expensive to move types</h3> +<p><b>Section:</b> 24.7 [insert.iterators] <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>Opened:</b> 2009-02-02 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#insert.iterators">active issues</a> in [insert.iterators].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#insert.iterators">issues</a> in [insert.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> -And then: 29.4 [atomics.types.operations] p12: +The new concepts for the insert iterators mandate an extra copy when +inserting an lvalue: </p> +<blockquote><pre>requires CopyConstructible<Cont::value_type> + back_insert_iterator<Cont>& + operator=(const Cont::value_type& value); +</pre> <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. +-1- <i>Effects:</i> <tt>push_back(*container, <b>Cont::value_type(</b>value<b>)</b>);</tt> +</blockquote> </blockquote> <p> -This is redundant with 1.10 [intro.multithread], see above for the reasoning. +The reason is to convert <tt>value</tt> into an rvalue because the current +<tt>BackInsertionContainer</tt> concept only handles <tt>push_back</tt>-ing +rvalues: </p> +<blockquote><pre>concept BackInsertionContainer<typename C> : Container<C> { + void push_back(C&, value_type&&); +} +</pre></blockquote> -<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): +Without the conversion of <tt>value</tt> to an rvalue, the assignment operator +fails to concept check. </p> -<blockquote> <p> -For <tt>memory_order_relaxed</tt>, no operation orders memory. +A solution is to modify the <tt>BackInsertionContainer</tt> concept so that +the client can pass in the parameter type for <tt>push_back</tt> similar to +what is already done for the <tt>OutputIterator</tt> concept: </p> +<blockquote><pre>concept BackInsertionContainer<typename C, typename Value = C::value_type&&> + : Container<C> { + void push_back(C&, Value); +} +</pre></blockquote> + <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. +This allows the assignment operator to be adjusted appropriately: </p> +<blockquote><pre>requires BackInsertionContainer<Cont, Cont::value_type const&> && + CopyConstructible<Cont::value_type> + back_insert_iterator<Cont>& + operator=(const Cont::value_type& value); +</pre> +<blockquote> +-1- <i>Effects:</i> <tt>push_back(*container, value);</tt> +</blockquote> +</blockquote> + +<p><i>[ +We may want to propagate this fix to other concepts such as <tt>StackLikeContainer</tt>. +]</i></p> + + +<p><i>[ +Solution and wording collaborated on by Doug and Howard. +]</i></p> + + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +<p> +Howard notes that "these operations behaved efficiently until concepts were added." +</p> +<p> +Alisdair is uncertain that the proposed resolution is syntactically correct. +</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. +Move to Open, and recommend the issue be deferred until after the next +Committee Draft is issued. </p> </blockquote> + +<p><b>Proposed resolution:</b></p> <p> -Rephrase 29.1 [atomics.order] p2: +Change 23.2.6.1 [container.concepts.free]: </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>] +<pre>concept FrontInsertionContainer<typename C<ins>, typename Value = C::value_type&&</ins>> + : Container<C> { + void push_front(C&, <del>value_type&&</del> <ins>Value</ins>); + + axiom FrontInsertion(C c, <del>value_type</del> <ins>Value</ins> x) { + x == (push_front(c, x), front(c)); + } +} +</pre> + +<p>...</p> + +<pre>concept BackInsertionContainer<typename C<ins>, typename Value = C::value_type&&</ins>> + : Container<C> { + void push_back(C&, <del>value_type&&</del> <ins>Value</ins>); +} +</pre> + +<p>...</p> + +<pre>concept InsertionContainer<typename C<ins>, typename Value = C::value_type&&</ins>> + : Container<C> { + iterator insert(C&, const_iterator, <del>value_type&&</del> <ins>Value</ins>); + + axiom Insertion(C c, const_iterator position, <del>value_type</del> <ins>Value</ins> v) { + v == *insert(c, position, v); + } +} +</pre> + </blockquote> <p> -Rephrase 29.4 [atomics.types.operations] p12 as: +Change 23.2.6.2 [container.concepts.member]: </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>. +<pre>auto concept MemberFrontInsertionContainer<typename C<ins>, typename Value = C::value_type&&</ins>> + : MemberContainer<C> { + void C::push_front(<del>value_type&&</del> <ins>Value</ins>); + + axiom MemberFrontInsertion(C c, <del>value_type</del> <ins>Value</ins> x) { + x == (c.push_front(x), c.front()); + } +} +</pre> + +<p>...</p> + +<pre>auto concept MemberBackInsertionContainer<typename C<ins>, typename Value = C::value_type&&</ins>> + : MemberContainer<C> { + void C::push_back(<del>value_type&&</del> <ins>Value</ins>); +} +</pre> + +<p>...</p> + +<pre>auto concept MemberInsertionContainer<typename C<ins>, typename Value = C::value_type&&</ins>> + : MemberContainer<C> { + iterator C::insert(const_iterator, <del>value_type&&</del> <ins>Value</ins>); + + axiom MemberInsertion(C c, const_iterator position, <del>value_type</del> <ins>Value</ins> v) { + v == *c.insert(position, v); + } +} +</pre> </blockquote> <p> -Same in p15, p20, p22. +Change 23.2.6.3 [container.concepts.maps]: </p> +<blockquote> +<pre>template <MemberFrontInsertionContainer C<ins>, typename Value = C::value_type&&</ins>> +concept_map FrontInsertionContainer<C<ins>, Value</ins>> { + typedef Container<C>::value_type value_type; + void push_front(C& c, <del>value_type&&</del> <ins>Value</ins> v) { c.push_front(static_cast<<del>value_type&&</del> <ins>Value</ins>>(v)); } +} +</pre> +<p>...</p> +<pre>template <MemberBackInsertionContainer C<ins>, typename Value = C::value_type&&</ins>> +concept_map BackInsertionContainer<C<ins>, Value</ins>> { + typedef Container<C>::value_type value_type; + void push_back(C& c, <del>value_type&&</del> <ins>Value</ins> v) { c.push_back(static_cast<<del>value_type&&</del> <ins>Value</ins>>(v)); } +} +</pre> + +<p>...</p> + +<pre>template <MemberInsertionContainer C<ins>, typename Value = C::value_type&&</ins>> +concept_map InsertionContainer<C<ins>, Value</ins>> { + typedef Container<C>::value_type value_type; + Container<C>::iterator insert(C& c, Container<C>::const_iterator i, <del>value_type&&</del> <ins>Value</ins> v) + { return c.insert(i, static_cast<<del>value_type&&</del> <ins>Value</ins>>(v)); } +} +</pre> + +</blockquote> -<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. +Change 24.7.1 [back.insert.iterator]: </p> +<blockquote><pre>template <BackInsertionContainer Cont> +class back_insert_iterator { + ... + requires <ins>BackInsertionContainer<Cont, const Cont::value_type&></ins> + <del>CopyConstructible<Cont::value_type></del> + back_insert_iterator<Cont>& + operator=(const Cont::value_type& value); + ... +</pre></blockquote> + <p> -The current wording says: +Change 24.7.2.2 [back.insert.iter.op=]: </p> <blockquote> -<pre>template <class E> void rethrow_if_nested(const E& e); +<pre>requires <ins>BackInsertionContainer<Cont, const Cont::value_type&></ins> + <del>CopyConstructible<Cont::value_type></del> + back_insert_iterator<Cont>& + operator=(const Cont::value_type& value); </pre> <blockquote> +-1- <i>Effects:</i> <tt>push_back(*container, <del>Cont::value_type(</del>value<del>)</del>);</tt> +</blockquote> +</blockquote> + <p> -<i>Effects:</i> Calls <tt>e.rethrow_nested()</tt> only if <tt>e</tt> -is publicly derived from <tt>nested_exception</tt>. +Change 24.7.3 [front.insert.iterator]: </p> + +<blockquote><pre>template <FrontInsertionContainer Cont> +class front_insert_iterator { + ... + requires <ins>FrontInsertionContainer<Cont, const Cont::value_type&></ins> + <del>CopyConstructible<Cont::value_type></del> + front_insert_iterator<Cont>& + operator=(const Cont::value_type& value); + ... +</pre></blockquote> + +<p> +Change 24.7.4.2 [front.insert.iter.op=]: +</p> + +<blockquote> +<pre>requires <ins>FrontInsertionContainer<Cont, const Cont::value_type&></ins> + <del>CopyConstructible<Cont::value_type></del> + front_insert_iterator<Cont>& + operator=(const Cont::value_type& value); +</pre> +<blockquote> +-1- <i>Effects:</i> <tt>push_front(*container, <del>Cont::value_type(</del>value<del>)</del>);</tt> </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. +Change 24.7.5 [insert.iterator]: </p> +<blockquote><pre>template <InsertionContainer Cont> +class insert_iterator { + ... + requires <ins>InsertionContainer<Cont, const Cont::value_type&></ins> + <del>CopyConstructible<Cont::value_type></del> + insert_iterator<Cont>& + operator=(const Cont::value_type& value); + ... +</pre></blockquote> + +<p> +Change 24.7.6.2 [insert.iter.op=]: +</p> + +<blockquote> +<pre>requires <ins>InsertionContainer<Cont, const Cont::value_type&></ins> + <del>CopyConstructible<Cont::value_type></del> + insert_iterator<Cont>& + operator=(const Cont::value_type& value); +</pre> +<blockquote> +<p> +-1- <i>Effects:</i> +</p> +<blockquote><pre>iter = insert(*container, iter, <del>Cont::value_type(</del>value<del>)</del>); +++iter; +</pre></blockquote> +</blockquote> +</blockquote> + + + + + + +<hr> +<h3><a name="978"></a>978. Hashing smart pointers</h3> +<p><b>Section:</b> 20.7.17 [unord.hash] <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>Opened:</b> 2009-02-02 <b>Last modified:</b> 2009-05-31</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord.hash">active issues</a> in [unord.hash].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.hash">issues</a> in [unord.hash].</p> +<p><b>View all 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 don't see an open issue on supporting <tt>std::hash</tt> for smart pointers +(<tt>unique_ptr</tt> and <tt>shared_ptr</tt> at least). +</p> +<p> +It seems reasonable to at least expect support for the smart +pointers, especially as they support comparison for use in ordered +associative containers. +</p> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +<p> +Howard points out that the client can always supply a custom hash function. +</p> +<p> +Alisdair replies that the smart pointer classes are highly likely +to be frequently used as hash keys. +</p> +<p> +Bill would prefer to be conservative. +</p> +<p> +Alisdair mentions that this issue may also be viewed as a subissue or +duplicate of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1025">1025</a>. +</p> +<p> +Move to Open, and recommend the issue be deferred until after the next +Committee Draft is issued. +</p> +</blockquote> + +<p><i>[ +2009-05-31 Peter adds: +]</i></p> + + +<blockquote> +<blockquote> +Howard points out that the client can always supply a custom hash function. +</blockquote> +<p> +Not entirely true. The client cannot supply the function that hashes the +address of the control block (the equivalent of the old <tt>operator<</tt>, now +proudly carrying the awkward name of '<tt>owner_before</tt>'). Only the +implementation can do that, not necessarily via specializing <tt>hash<></tt>, of +course. +</p> +<p> +This hash function makes sense in certain situations for <tt>shared_ptr</tt> +(when one needs to switch from <tt>set/map</tt> using ownership ordering to +<tt>unordered_set/map</tt>) and is the only hash function that makes sense for +<tt>weak_ptr</tt>. +</p> +</blockquote> + + <p><b>Proposed resolution:</b></p> +<p> +</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> +<h3><a name="979"></a>979. Bad example</h3> +<p><b>Section:</b> 24.5.3 [move.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Tentatively NAD Editorial</a> + <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-02-03 <b>Last modified:</b> 2009-05-23</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD%20Editorial">Tentatively NAD Editorial</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. +24.5.3 [move.iterators] has an incorrect example: </p> +<blockquote> <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>. +-2- [<i>Example:</i> </p> +<blockquote><pre>set<string> s; +// populate the set s +vector<string> v1(s.begin(), s.end()); // copies strings into v1 +vector<string> v2(make_move_iterator(s.begin()), + make_move_iterator(s.end())); // moves strings into v2 +</pre></blockquote> + <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. +<i>-- end example</i>] +</p> +</blockquote> + +<p> +One can not move from a <tt>set</tt> because the iterators return <tt>const</tt> +references. </p> <p><i>[ -Peter's summary: +Batavia (2009-05): ]</i></p> +<blockquote> +We agree with the proposed resolution. Move to NAD Editorial. +</blockquote> + + + +<p><b>Proposed resolution:</b></p> +<p> +Change 24.5.3 [move.iterators]/2: +</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. +-2- [<i>Example:</i> </p> +<blockquote><pre><del>set</del><ins>list</ins><string> s; +// populate the <del>set</del><ins>list</ins> s +vector<string> v1(s.begin(), s.end()); // copies strings into v1 +vector<string> v2(make_move_iterator(s.begin()), + make_move_iterator(s.end())); // moves strings into v2 +</pre></blockquote> + +<p> +<i>-- end example</i>] +</p> +</blockquote> + + + + + +<hr> +<h3><a name="981"></a>981. Unordered container requirements should add <tt>initializer_list</tt> support</h3> +<p><b>Section:</b> 23.2.5 [unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-02-08 <b>Last modified:</b> 2009-05-23</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#Tentatively%20Ready">Tentatively Ready</a> status.</p> +<p><b>Discussion:</b></p> <p> -However, the resolution of core issue 475 may relax this requirement: +Refering to +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2800.pdf">N2800</a> +all container requirements tables (including those for +associative containers) provide useful member function overloads +accepting <tt>std::initializer_list</tt> as argument, the only exception is +Table 87. There seems to be no reason for not providing them, because 23.5 [unord] +is already <tt>initializer_list</tt>-aware. For the sake of +library interface consistency and user-expectations corresponding +overloads should be added to the table requirements of unordered +containers as well. </p> +<p><i>[ +Batavia (2009-05): +]</i></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. +<p> +We agree with the proposed resolution. +</p> +<p> +Move to Tentatively Ready. +</p> </blockquote> + +<p><b>Proposed resolution:</b></p> + <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. +In 23.2.5 [unord.req]/9 insert: </p> +<blockquote> +... <tt>[q1, q2)</tt> is a valid range in <tt>a</tt>, <ins><tt>il</tt> +designates an object of type <tt>initializer_list<value_type></tt>, </ins><tt>t</tt> is a value of type +<tt>X::value_type</tt>, ... +</blockquote> + <p> -Option (2) cannot be adopted by itself, because a potential infinite -recursion will need to be terminated by one of the other options. +In 23.2.5 [unord.req], Table 87 insert: </p> +<blockquote> +<table border="1"> +<caption>Table 87 - Unordered associative container requirements (in addition to container)</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>X(i, j)<br>X a(i, j)</tt></td> <td><tt>X</tt></td> <td>...</td> <td>...</td> +</tr> +<tr> +<td><ins><tt>X(il)</tt></ins></td> <td><ins><tt>X</tt></ins></td> +<td><ins>Same as <tt>X(il.begin(), il.end())</tt>.</ins></td> +<td><ins>Same as <tt>X(il.begin(), il.end())</tt>.</ins></td> +</tr> +<tr> +<td>...</td> <td>...</td> <td>...</td> <td>...</td> +</tr> +<tr> +<td><tt>a = b</tt></td> <td><tt>X</tt></td> <td>...</td> <td>...</td> +</tr> +<tr> +<td><ins><tt>a = il</tt></ins></td> <td><ins><tt>X&</tt></ins></td> +<td><ins><tt>a = X(il); return *this;</tt></ins></td> +<td><ins>Same as <tt>a = X(il)</tt>.</ins></td> +</tr> +<tr> +<td>...</td> <td>...</td> <td>...</td> <td>...</td> +</tr> +<tr> +<td><tt>a.insert(i, j)</tt></td> <td><tt>void</tt></td> <td>...</td> <td>...</td> +</tr> +<tr> +<td><ins><tt>a.insert(il)</tt></ins></td> <td><ins><tt>void</tt></ins></td> +<td><ins>Same as <tt>a.insert(il.begin(), il.end())</tt>.</ins></td> +<td><ins>Same as <tt>a.insert(il.begin(), il.end())</tt>.</ins></td> +</tr> +</tbody></table> </blockquote> -<p><b>Proposed resolution:</b></p> + + + + +<hr> +<h3><a name="982"></a>982. Wrong complexity for initializer_list assignment in Table 85</h3> +<p><b>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-02-08 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</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#Tentatively%20Ready">Tentatively Ready</a> status.</p> +<p><b>Discussion:</b></p> <p> -Add the following paragraph after 18.7.5 [propagation]/7: +According to +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2800.pdf">N2800</a>, +the associative container requirements table 85 says + that assigning an <tt>initializer_list</tt> to such a container is of + constant complexity, which is obviously wrong. </p> +<p><i>[ +Batavia (2009-05): +]</i></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>. +We agree with the proposed resolution. </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>] +Move to Tentatively Ready. </p> </blockquote> +<p><b>Proposed resolution:</b></p> + +<p> +In 23.2.4 [associative.reqmts], Table 85 change: +</p> + +<blockquote> +<table border="1"> +<caption>Table 85 - Associative container requirements (in addition to container)</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 = il</tt></td> <td><tt>X&</tt></td> <td><tt>a = X(il);<br>return *this;</tt></td> +<td><del>constant</del><ins>Same as <tt>a = X(il)</tt>.</ins></td> +</tr> +</tbody></table> +</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> +<h3><a name="983"></a>983. <tt>unique_ptr</tt> reference deleters should not be moved from</h3> +<p><b>Section:</b> 20.8.12.2 [unique.ptr.single] <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>Opened:</b> 2009-02-10 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unique.ptr.single">active issues</a> in [unique.ptr.single].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr.single">issues</a> in [unique.ptr.single].</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> -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: +Dave brought to my attention that when a <tt>unique_ptr</tt> has a non-const reference +type deleter, move constructing from it, even when the <tt>unique_ptr</tt> containing +the reference is an rvalue, could have surprising results: +</p> + +<blockquote><pre>D d(some-state); +unique_ptr<A, D&> p(new A, d); +unique_ptr<A, D> p2 = std::move(p); +<font color="#c80000">// has d's state changed here?</font> +</pre></blockquote> + +<p> +I agree with him. It is the <tt>unique_ptr</tt> that is the rvalue, not the +deleter. When the deleter is a reference type, the <tt>unique_ptr</tt> should +respect the "lvalueness" of the deleter. +</p> + +<p> +Thanks Dave. +</p> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +Seems correct, but complicated enough that we recommend moving to Review. +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +Change 20.8.12.2.1 [unique.ptr.single.ctor], p20-21 </p> <blockquote> -<pre>void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>); +<pre>template <class U, class E> unique_ptr(unique_ptr<U, E>&& u); </pre> +<blockquote> + <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>] +-20- <i>Requires:</i> If <tt><del>D</del> <ins>E</ins></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. +<ins> +Otherwise <tt>E</tt> is a reference type and construction of the deleter +<tt>D</tt> from an lvalue of type <tt>E</tt> shall be well formed and +shall not throw an exception. +</ins> +If <tt>D</tt> is +a reference type, then <tt>E</tt> shall be the same type as <tt>D</tt> +(diagnostic required). <tt>unique_ptr<U, E>::pointer</tt> shall be +implicitly convertible to <tt>pointer</tt>. [<tt>Note:</tt> These +requirements imply that <tt>T</tt> and <tt>U</tt> are complete types. +<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... +-21- <i>Effects:</i> Constructs a <tt>unique_ptr</tt> which owns the +pointer which <tt>u</tt> owns (if any). If the deleter +<ins><tt>E</tt></ins> is not a reference type, <del>it</del> <ins>this +deleter</ins> is move constructed from <tt>u</tt>'s deleter, otherwise +<del>the reference</del> <ins>this deleter</ins> is copy constructed +from <tt>u</tt>.'s deleter. After the construction, <tt>u</tt> no longer +owns a pointer. [<i>Note:</i> The deleter constructor can be implemented +with <tt>std::forward<<del>D</del><ins>E</ins>></tt>. <i>-- end +note</i>] </p> +</blockquote> +</blockquote> -<p><b>Proposed resolution:</b></p> <p> -Add to class template definition in 20.7.11.3 [unique.ptr.runtime] +Change 20.8.12.2.3 [unique.ptr.single.asgn], p1-3 </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>unique_ptr& operator=(unique_ptr&& u); </pre> +<blockquote> + +<p> +-1- <i>Requires:</i> <ins>If the deleter <tt>D</tt> is not a reference type,</ins> +<del>A</del><ins>a</ins>ssignment of the deleter <tt>D</tt> from an rvalue <tt>D</tt> shall not throw an exception. +<ins> +Otherwise the deleter <tt>D</tt> is a reference type, +and assignment of the deleter <tt>D</tt> from an lvalue <tt>D</tt> shall not throw an exception.</ins> +</p> + +<p> +-2- <i>Effects:</i> reset(u.release()) followed by +a<ins>n</ins> <del>move</del> assignment from <del><tt>u</tt>'s deleter to this deleter</del> +<ins><tt>std::forward<D>(u.get_deleter())</tt></ins>. +</p> + +<p> +-3- <i>Postconditions:</i> This <tt>unique_ptr</tt> now owns the pointer +which <tt>u</tt> owned, and <tt>u</tt> no longer owns it. <del>[<i>Note:</i> If +<tt>D</tt> is a reference type, then the referenced lvalue deleters are +move assigned. <i>-- end note</i>]</del> +</p> +</blockquote> </blockquote> <p> -Update 20.7.11.3.3 [unique.ptr.runtime.modifiers] +Change 20.8.12.2.3 [unique.ptr.single.asgn], p6-7 </p> <blockquote> -<pre>void reset(pointer p = pointer()); -<ins>void reset(nullptr_t);</ins> +<pre>template <class U, class E> unique_ptr& operator=(unique_ptr<U, E>&& u); </pre> +<blockquote> <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> +<i>Requires:</i> <ins>If the deleter <tt>E</tt> is not a reference type,</ins> +<del>A</del><ins>a</ins>ssignment of the deleter <tt>D</tt> from an rvalue +<tt><del>D</del><ins>E</ins></tt> shall not throw an exception. +<ins> +Otherwise the deleter <tt>E</tt> is a reference type, +and assignment of the deleter <tt>D</tt> from an lvalue <tt>E</tt> shall not throw an exception.</ins> +<tt>unique_ptr<U, E>::pointer</tt> shall be implicitly convertible to <tt>pointer</tt>. +[<i>Note:</i> These requirements imply that <tt>T</tt> and <tt>U></tt> +are complete types. <i>-- end note</i>] </p> + <p> -<i>Effects:</i> If <tt>get() == nullptr</tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>. +<i>Effects:</i> <tt>reset(u.release())</tt> followed by +a<ins>n</ins> <del>move</del> assignment from <del><tt>u</tt>'s deleter to this deleter</del> +<ins><tt>std::forward<E>(u.get_deleter())</tt></ins>. +<del>If either +<tt>D</tt> or <tt>E</tt> is a reference type, then the referenced lvalue +deleter participates in the move assignment.</del> </p> -<p>...</p> + +</blockquote> +</blockquote> + + + + + + +<hr> +<h3><a name="984"></a>984. Does <tt><cinttypes></tt> have macro guards?</h3> +<p><b>Section:</b> 27.9.2 [c.files] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-02-12 <b>Last modified:</b> 2009-05-23</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The C standard says about <tt><inttypes.h></tt>: +</p> + +<blockquote> +C++ implementations should define these macros only when <tt>__STDC_FORMAT_MACROS</tt>is defined +before <tt><inttypes.h></tt> is included. +</blockquote> + +<p> +The C standard has a similar note about <tt><stdint.h></tt>. For <tt><cstdint></tt> +we adopted a "thanks but no thanks" policy and documented that fact in +18.4.1 [cstdint.syn]: +</p> + +<blockquote> +... [<i>Note:</i> The macros defined by <tt><stdint></tt> are +provided unconditionally. In particular, the symbols +<tt>__STDC_LIMIT_MACROS</tt> and <tt>__STDC_CONSTANT_MACROS</tt> +(mentioned in C99 footnotes 219, 220, and 222) play no role in C++. +<i>-- end note</i>] </blockquote> +<p> +I recommend we put a similar note in 27.9.2 [c.files] regarding <tt><cinttypes></tt>. +</p> + <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). +Batavia (2009-05): ]</i></p> +<blockquote> +We agree with the proposed resolution. +Move to Tentatively Ready. +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +Add to 27.9.2 [c.files]: +</p> + +<blockquote> +Table 112 describes header <tt><cinttypes></tt>. +<ins> +[<i>Note:</i> The macros defined by <tt><cintypes></tt> are +provided unconditionally. In particular, the symbol +<tt>__STDC_FORMAT_MACROS</tt> +(mentioned in C99 footnote 182) plays no role in C++. +<i>-- end note</i>] +</ins> +</blockquote> <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> +<h3><a name="985"></a>985. Allowing throwing move</h3> +<p><b>Section:</b> 23.2.1 [container.requirements.general] <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>Opened:</b> 2009-02-12 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements.general">active issues</a> in [container.requirements.general].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements.general">issues</a> in [container.requirements.general].</p> +<p><b>View all 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 just noticed that the following program is legal in C++03, but -is forbidden in the current draft: +<b>Introduction</b> </p> -<blockquote><pre>#include <vector> -#include <iostream> +<p>This proposal is meant to resolve potential regression of the +<a href="" ref="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2800.pdf">N2800</a> +draft, see +next section, and to relax the requirements for containers of types with +throwing move constructors.</p> -class Toto -{ -public: - Toto() {} - explicit Toto( Toto const& ) {} -} ; +<p>The basic problem is that some containers operations, like <tt>push_back</tt>, +have a strong exception safety +guarantee (i.e. no side effects upon exception) that are not achievable when +throwing move constructors are used since there is no way to guarantee revert +after partial move. For such operations the implementation can at most provide +the basic guarantee (i.e. valid but unpredictable) as it does with multi +copying operations (e.g. range insert).</p> -int -main() -{ - std::vector< Toto > v( 10 ) ; - return 0 ; +<p>For example, <tt>vector<T>::push_back()</tt> (where <tt>T</tt> has a move +constructor) might resize the <tt>vector</tt> and move the objects to the new underlying +buffer. If move constructor throws it might +not be possible to recover the throwing object or to move the old objects back to +the original buffer.</p> + +<p>The current draft is explicit by disallowing throwing move +for some operations (e.g. <tt>vector<>::reserve</tt>) and not clear about other +operations mentioned in 23.2.1 [container.requirements.general]/10 +(e.g. single element <tt>insert</tt>): it guarantees strong exception +safety without explicitly disallowing a throwing move constructor. +</p> + +<p> +<b>Regression</b> +</p> + +<p>This section only refers to cases in which the contained object +is by itself a standard container.</p> + +<p>Move constructors of standard containers are allowed to throw and therefore +existing operations are broken, compared with C++03, due to move optimization. +(In fact existing implementations like Dinkumware are actually throwing).</p> + +<p>For example, <tt>vector< list<int> >::reserve</tt> yields +undefined behavior since <tt>list<int></tt>'s move constructor is allowed to throw. +On the other hand, the same operation has strong exception safety guarantee in +C++03.</p> + +<p>There are few options to solve this regression:</p> + +<ol> +<li> +Disallow throwing move and throwing default constructor +</li> + +<li> +Disallow throwing move but disallowing usage after move +</li> + +<li> +Special casing +</li> + +<li> +Disallow throwing move and making it optional +</li> + +</ol> + +<p>Option 1 is suggested by proposal +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2815.html">N2815</a> +but it might not be applicable for existing implementations for which +containers default constructors are throwing.</p> + +<p>Option 2 limits the usage significantly and it's error prone +by allowing zombie objects that are nothing but destructible (e.g. no <tt>clear()</tt> +is allowed after move). It also potentially complicates the implementation by +introducing special state.</p> + +<p>Option 3 is possible, for example, using default +construction and <tt>swap</tt> instead of move for standard containers case. The +implementation is also free to provide special hidden operation for non +throwing move without forcing the user the cope with the limitation of option-2 +when using the public move.</p> + +<p>Option 4 impact the efficiency in all use cases due to rare throwing move.</p> + +<p>The proposed wording will imply option 1 or 3 though option 2 is also +achievable using more wording. I personally oppose to option 2 that has impact +on usability.</p> + +<p> +<b>Relaxation for user types</b> +</p> + +<p>Disallowing throwing move constructors in general seems very restrictive +since, for example, common implementation of move will be default construction ++ <tt>swap</tt> so move will throw if the +default constructor will throw. This is currently the case with the Dinkumware +implementation of node based containers (e.g. <tt>std::list</tt>) +though this section doesn't refer to standard types.</p> + +<p>For throwing move constructors it seem that the implementation should have +no problems to provide the basic guarantee instead of the strong one. It's +better to allow throwing move constructors with basic guarantee than to +disallow it silently (compile and run), via undefined behavior.</p> + +<p>There might still be cases in which the relaxation will break existing generic +code that assumes the strong guarantee but it's broken either way given a +throwing move constructor since this is not a preserving optimization. </p> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +<p> +Bjarne comments (referring to his draft paper): +"I believe that my suggestion simply solves that. +Thus, we don't need a throwing move." +</p> +<p> +Move to Open and recommend it be deferred until after the next +Committee Draft is issued. +</p> +</blockquote> + + +<p><b>Proposed resolution:</b></p> + +<p> +23.2.1 [container.requirements.general] paragraph 10 add footnote: +</p> + +<blockquote> +<p> +-10- Unless otherwise specified (see 23.1.4.1, 23.1.5.1, 23.2.2.3, and +23.2.6.4) all container types defined in this Clause meet the following +additional requirements: +</p> +<ul> +<li>...</li> +</ul> + +<p> +<ins>[<i>Note</i>: for compatibility with C++ +2003, when "no effect" is required, standard containers should not use the +value_type's throwing move constructor when the contained object is by itself a +standard container. -- <i>end note</i>]</ins> +</p> + +</blockquote> + +<p>23.2.5.1 [unord.req.except] change paragraph 2 to say: </p> + +<blockquote> +<p> +-2- For unordered associative containers, if an exception is +thrown by any operation other than the container's hash function from within an +<tt>insert()</tt> function inserting a single element, the <tt>insert()</tt> +function has no effect<ins> unless the exception is thrown by the contained +object move constructor</ins>. +</p> + +<p> +-4- For unordered associative containers, if an exception is +thrown from within a <tt>rehash()</tt> function other than by the container's hash +function or comparison function, the <tt>rehash()</tt> function has no effect +<ins>unless the exception is thrown by the contained +object move constructor</ins>.</p> + +</blockquote> + +<p> +23.3.2.3 [deque.modifiers] change paragraph 2 to say: +</p> + +<blockquote> +-2- <i>Remarks:</i> If an exception is thrown other than by +the copy constructor<ins>, move constructor</ins> +or assignment operator of <tt>T</tt> +there are no effects. +<ins>If an exception is thrown by <tt>push_back()</tt> or <tt>emplace_back()</tt> +function, that function has no effects unless the exception is thrown by +the move constructor of <tt>T</tt>.</ins> +</blockquote> + +<p> +23.3.2.3 [deque.modifiers] change paragraph 6 to say: +</p> + +<blockquote> +-6- <i>Throws:</i> Nothing unless an exception is thrown by the copy +constructor<ins>, move constructor</ins> or assignment operator of <tt>T</tt>. +</blockquote> + +<p> +23.3.6.2 [vector.capacity] remove paragraph 2 +</p> + +<blockquote> +<del>-2- <i>Requires:</i> If <tt>value_type</tt> has a move constructor, +that constructor shall not throw any exceptions.</del> +</blockquote> + +<p> +23.3.6.2 [vector.capacity] paragraph 3 change to say: +</p> + +<blockquote> +-3- <i>Effects:</i> A directive that informs a <tt>vector</tt> +of a planned change in size, so +that it can manage the storage allocation accordingly. After <tt>reserve()</tt>, +<tt>capacity()</tt> is greater or equal to the argument of <tt>reserve</tt> +if reallocation happens; and equal +to the previous value of <tt>capacity()</tt> +otherwise. Reallocation happens at this point if and only if the current +capacity is less than the argument of <tt>reserve()</tt>. +If an exception is thrown, there are no effects<ins> +unless the exception is thrown by the contained object move constructor</ins>. +</blockquote> + +<p> +23.3.6.2 [vector.capacity] paragraph 12 change to say: +</p> + +<blockquote> +-12- <i>Requires:</i> <del>If <tt>value_type</tt> has a move constructor, +that constructor shall not throw any exceptions.</del> +<ins>If an exception is thrown, there are no effects unless the exception is thrown by +the contained object move constructor.</ins> +</blockquote> + +<p> +23.3.6.4 [vector.modifiers] change paragraph 1 to say: +</p> + +<blockquote> +-1- <del><i>Requires:</i> If <tt>value_type</tt> has a move constructor, +that constructor shall not throw any exceptions.</del> +<ins><i>Remarks:</i> If an exception is thrown by <tt>push_back()</tt> +or <tt>emplace_back()</tt> function, that function has no effect unless the +exception is thrown by the move constructor of <tt>T</tt>.</ins> +</blockquote> + +<p> +23.3.6.4 [vector.modifiers] change paragraph 2 to say: +</p> + +<blockquote> +-2- <i>Remarks:</i> 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<ins>, move constructor</ins> +or assignment operator of <tt>T</tt> or by any <tt>InputIterator</tt> +operation there are no effects. +</blockquote> + +<p> +23.3.6.4 [vector.modifiers] change paragraph 6 to say: +</p> + +<blockquote> +-6- <i>Throws:</i> Nothing unless an exception is thrown by the copy +constructor<ins>, move constructor</ins> or assignment operator of <tt>T</tt>. +</blockquote> + + + + + + +<hr> +<h3><a name="986"></a>986. Generic <tt>try_lock</tt> contradiction</h3> +<p><b>Section:</b> 30.4.4 [thread.lock.algorithm] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> Chris Fairles <b>Opened:</b> 2009-02-14 <b>Last modified:</b> 2009-05-23</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p> +<p><b>Discussion:</b></p> +<p> +In 30.4.4 [thread.lock.algorithm], the generic <tt>try_lock</tt> effects (p2) say that a failed +<tt>try_lock</tt> is when it either returns <tt>false</tt> or throws an exception. In +the event a call to <tt>try_lock</tt> does fail, by either returning <tt>false</tt> or +throwing an exception, it states that <tt>unlock</tt> shall be called for all +prior arguments. Then the returns clause (p3) goes on to state +in a note that after returning, either all locks are locked or none +will be. So what happens if multiple locks fail on <tt>try_lock</tt>? +</p> + +<p> +Example: +</p> + +<blockquote><pre>#include <mutex> + +int main() { + std::mutex m0, m1, m2; + std::unique_lock<std::mutex> l0(m0, std::defer_lock); + std::unique_lock<std::mutex> l1(m1); //throws on try_lock + std::unique_lock<std::mutex> l2(m2); //throws on try_lock + + int result = std::try_lock(l0, l1, l2); + + assert( !l0.owns_lock() ); + assert( l1.owns_lock() ); //?? + assert( l2.owns_lock() ); //?? } </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.) +The first lock's <tt>try_lock</tt> succeeded but, being a prior argument to a +lock whose <tt>try_lock</tt> failed, it gets unlocked as per the effects clause +of 30.4.4 [thread.lock.algorithm]. However, 2 locks remain locked in this case but the return +clause states that either all arguments shall be locked or none will +be. This seems to be a contradiction unless the intent is for +implementations to make an effort to unlock not only prior arguments, +but the one that failed and those that come after as well. Shouldn't +the note only apply to the arguments that were successfully locked? </p> +<p> +Further discussion and possible resolutions in c++std-lib-23049. +</p> + +<p><i>[ +Summit: +]</i></p> + +<blockquote> +Move to review. Agree with proposed resolution. +</blockquote> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +We agree with the proposed resolution. +Move to Tentatively Ready. +</blockquote> <p><b>Proposed resolution:</b></p> + <p> -In 20.1.1 [utility.arg.requirements] change Table 33: <tt>MoveConstructible</tt> requirements [moveconstructible]: +Change 30.4.4 [thread.lock.algorithm], p2: </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> +-2- <i>Effects:</i> Calls <tt>try_lock()</tt> for each argument in order +beginning with the first until all arguments have been processed or a +call to <tt>try_lock()</tt> fails, either by returning <tt>false</tt> or by throwing an +exception. If a call to <tt>try_lock()</tt> fails, <tt>unlock()</tt> shall be called for +all prior arguments<ins> and there shall be no further calls to <tt>try_lock()</tt></ins>. </blockquote> <p> -In 20.1.1 [utility.arg.requirements] change Table 34: <tt>CopyConstructible</tt> requirements [copyconstructible]: +Delete the note from 30.4.4 [thread.lock.algorithm], p3 </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> +-3- <i>Returns:</i> -1 if all calls to <tt>try_lock()</tt> returned <tt>true</tt>, +otherwise a 0-based index value that indicates +the argument for which <tt>try_lock()</tt> returned <tt>false</tt>. <del>[<i>Note:</i> +On return, either all arguments will be +locked or none will be locked. -- <i>end note</i>]</del> </blockquote> @@ -15003,69 +25542,227 @@ In 20.1.1 [utility.arg.requirements] change Table 34: <tt>CopyConstructible</tt> <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> +<h3><a name="987"></a>987. <tt>reference_wrapper</tt> and function types</h3> +<p><b>Section:</b> 20.7.5 [refwrap] <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>Opened:</b> 2009-02-18 <b>Last modified:</b> 2009-05-23</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#refwrap">issues</a> in [refwrap].</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. +The synopsis in 20.7.5 [refwrap] says: +</p> + +<blockquote><pre>template <<b>ObjectType</b> T> class reference_wrapper +... +</pre></blockquote> + +<p> +And then paragraph 3 says: +</p> + +<blockquote> +<p> +The template instantiation <tt>reference_wrapper<T></tt> shall be +derived from <tt>std::unary_function<T1, R></tt> only if the type +<tt>T</tt> is any of the following: +</p> + +<ul> +<li> +a <b>function type</b> or a pointer to function type taking one argument of +type <tt>T1</tt> and returning <tt>R</tt> +</li> +</ul> +</blockquote> + +<p> +But function types are not <tt>ObjectType</tt>s. </p> <p> -Suggested resolution: Specialize <tt>identity<void></tt> so as not to require -the member function's presence. +Paragraph 4 contains the same contradiction. </p> <p><i>[ -Sophia Antipolis: +Post Summit: +]</i></p> + + +<blockquote> +<p> +Jens: restricted reference to ObjectType +</p> +<p> +Recommend Review. +</p> +</blockquote> + +<p><i>[ +Post Summit, Peter adds: ]</i></p> <blockquote> <p> -Jens: suggests to add a requires clause to avoid specializing on <tt>void</tt>. +In <a href="https://svn.boost.org/trac/boost/ticket/1846">https://svn.boost.org/trac/boost/ticket/1846</a> +however Eric Niebler makes the very reasonable point that <tt>reference_wrapper<F></tt>, +where <tt>F</tt> is a function type, represents a reference to a function, +a legitimate entity. So <tt>boost::ref</tt> was changed to allow it. </p> <p> -Alisdair: also consider cv-qualified <tt>void</tt>. +<a href="https://svn.boost.org/trac/boost/browser/trunk/libs/bind/test/ref_fn_test.cpp">https://svn.boost.org/trac/boost/browser/trunk/libs/bind/test/ref_fn_test.cpp</a> </p> <p> -Alberto provided proposed wording. +Therefore, I believe an alternative proposed resolution for issue 987 could simply +allow <tt>reference_wrapper</tt> to be used with function types. </p> </blockquote> +<p><i>[ +Post Summit, Howard adds: +]</i></p> + + +<blockquote> +<p> +I agree with Peter (and Eric). I got this one wrong on my first try. Here +is code that demonstrates how easy (and useful) it is to instantiate +<tt>reference_wrapper</tt> with a function type: +</p> + +<blockquote><pre>#include <functional> + +template <class F> +void test(F f); + +void f() {} + +int main() +{ + test(std::ref(f)); +} +</pre></blockquote> + +<p> +Output (link time error shows type of <tt>reference_wrapper</tt> instantiated +with function type): +</p> + +<blockquote><pre>Undefined symbols: + "void test<std::reference_wrapper<void ()()> >(std::reference_wrapper<void ()()>)",... +</pre></blockquote> + +<p> +I've taken the liberty of changing the proposed wording to allow function types +and set to Open. I'll also freely admit that I'm not positive <tt>ReferentType</tt> +is the correct concept. +</p> + +</blockquote> + + + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +<p> +Howard observed that <tt>FunctionType</tt>, +a concept not (yet?) in the Working Paper, +is likely the correct constraint to be applied. +However, the proposed resolution provides an adequate approximation. +</p> +<p> +Move to Review. +</p> +</blockquote> + +<p><i>[ +2009-05-23 Alisdair adds: +]</i></p> + + +<blockquote> +<p> +By constraining to <tt>PointeeType</tt> we rule out the ability for <tt>T</tt> to be a +reference, and call in reference-collapsing. I'm not sure if this is +correct and intended, but would like to be sure the case was considered. +</p> +<p> +Is dis-allowing reference types and the +implied reference collapsing the intended result? +</p> +</blockquote> + + <p><b>Proposed resolution:</b></p> <p> -Change definition of <tt>identity</tt> in 20.2.2 [forward], paragraph 2, to: +Change the synopsis in 20.7 [function.objects]: </p> -<blockquote><pre>template <class T> struct identity { - typedef T type; +<blockquote><pre>// 20.6.5, reference_wrapper: +template <<del>ObjectType</del> <ins>ReferentType</ins> T> + <ins>requires PointeeType<T></ins> + class reference_wrapper; - <ins>requires ReferentType<T></ins> - const T& operator()(const T& x) const; - }; +template <<del>ObjectType</del> <ins>PointeeType</ins> T> + reference_wrapper<T> ref(T&); + +template <<del>ObjectType</del> <ins>PointeeType</ins> T> + reference_wrapper<const T> cref(const T&); + +template <<del>ObjectType</del> <ins>PointeeType</ins> T> + reference_wrapper<T> ref(reference_wrapper<T>); +template <<del>ObjectType</del> <ins>PointeeType</ins> T> + reference_wrapper<const T> cref(reference_wrapper<T>); </pre></blockquote> -<p>...</p> -<blockquote><pre> <ins>requires ReferentType<T></ins> - const T& operator()(const T& x) const; + +<p> +Change the synopsis in 20.7.5 [refwrap]: +</p> + +<blockquote><pre>template <<del>ObjectType</del> <ins>ReferentType</ins> T> + <ins>requires PointeeType<T></ins> + class reference_wrapper + ... </pre></blockquote> +<p> +Change the prototypes in 20.7.5.5 [refwrap.helpers]: +</p> + +<blockquote><pre>template <<del>ObjectType</del> <ins>PointeeType</ins> T> + reference_wrapper<T> ref(T&); +... +template <<del>ObjectType</del> <ins>PointeeType</ins> T> + reference_wrapper<const T> cref(const T&); +... +template <<del>ObjectType</del> <ins>PointeeType</ins> T> + reference_wrapper<T> ref(reference_wrapper<T>); +... +template <<del>ObjectType</del> <ins>PointeeType</ins> T> + reference_wrapper<const T> cref(reference_wrapper<T>); +</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?). +a) The occurrence of <tt>T&</tt> in the function signature auto-implies +<tt>std::ReferentType</tt>, +this is due to 14.11.1.2 [temp.req.impl]/4 bullet 4 +</p> +<p> +b) The occurrence of the constrained template <tt>reference_wrapper<T></tt> in +the remaining +signatures lets kick in 14.11.1.2 [temp.req.impl]/4 bullet 1 and adds *all* requirements of +this template. But we need to add at least *one* requirement (and it +was an arbitrary, +but natural decision to require <tt>std::PointeeType</tt> here) to *activate* +this. If we hadn't done +this, we were in unconstrained mode! </p> @@ -15073,127 +25770,379 @@ than <tt>cv void</tt> which aren't referent types (<tt>int[]</tt>, perhaps?). <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> +<h3><a name="988"></a>988. <tt>Reflexivity</tt> meaningless?</h3> +<p><b>Section:</b> 20.2.6 [concept.comparison] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">Tentatively NAD</a> + <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-02-24 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#concept.comparison">active issues</a> in [concept.comparison].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#concept.comparison">issues</a> in [concept.comparison].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD">Tentatively NAD</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>. +20.2.6 [concept.comparison] p2: +</p> +<p> +Due to the subtle meaning of <tt>==</tt> inside axioms, the <tt>Reflexivity</tt> axiom does +not do anything as written. It merely states that a value is substitutable +with itself, rather than asserting a property of the <tt>==</tt> operator. </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); +<b> +Original proposed resolution: +</b> + +<p> +Change the definition of <tt>Reflexivity</tt> in 20.2.6 [concept.comparison]: +</p> + +<blockquote><pre>axiom Reflexivity(T a) { <ins>(</ins>a == a<ins>) == true</ins>; } </pre></blockquote> +<p><i>[ +Post Summit: +]</i></p> + + +<blockquote> +<p> +Alisdair: I was wrong. +</p> <p> -The definition in 21.3.8.9 [string.io] lists two: +Recommend NAD. </p> +</blockquote> -<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><b>Proposed resolution:</b></p> +<p> +NAD. +</p> + + + + + +<hr> +<h3><a name="989"></a>989. late_check and library</h3> +<p><b>Section:</b> 17 [library] <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>Opened:</b> 2009-02-24 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</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#Open">Open</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The example in 6.9p2 shows how late_check blocks inhibit concept_map lookup +inside a constrained context, and so inhibit concept map adaption by users +to meet template requirements. +</p> +<p> +Do we need some text in clause 17 prohibitting use of late_check in library +template definitions unless otherwise documented? +</p> + +<p><i>[ +Doug adds: +]</i></p> + + +<blockquote> +We need something like this, but it should be a more general statement +about implementations respecting the concept maps provided by the +user. Use of late_check is one way in which implementations can +subvert the concept maps provided by the user, but there are other +ways as well ("pattern-based" overloading, tricks with "auto" concept +maps and defaulted associated type arguments). +</blockquote> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +Move to Open, pending proposed wording from Alisdair and/or Doug for further review. +</blockquote> + + +<p><b>Proposed resolution:</b></p> + + + + + +<hr> +<h3><a name="990"></a>990. <tt>monotonic_clock::is_monotonic</tt> must be <tt>true</tt></h3> +<p><b>Section:</b> 20.9.5.2 [time.clock.monotonic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-09 <b>Last modified:</b> 2009-05-23</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p> +<p><b>Discussion:</b></p> <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. +There is some confusion over what the value of <tt>monotonic_clock::is_monotonic</tt> +when <tt>monotonic_clock</tt> is a synonym for <tt>system_clock</tt>. The +intent is that if <tt>monotonic_clock</tt> exists, then <tt>monotonic_clock::is_monotonic</tt> +is <tt>true</tt>. </p> +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +<p> +We agree with the proposed resolution. +</p> +<p> +Move to Tentatively Ready. +</p> +</blockquote> + <p><b>Proposed resolution:</b></p> <p> -Delete the first of the two signatures in 21.3.8.9 [string.io]: +Change 20.9.5.2 [time.clock.monotonic], p1: </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> +<blockquote> +-1- Objects of class <tt>monotonic_clock</tt> represent clocks for which +values of <tt>time_point</tt> never decrease as physical time advances. +<tt>monotonic_clock</tt> may be a synonym for <tt>system_clock</tt> +<ins>if and only if <tt>system_clock::is_monotonic</tt> is +<tt>true</tt></ins>. +</blockquote> -template<class charT, class traits, class Allocator> - basic_ostream<charT, traits>& - operator<<(basic_ostream<charT, traits>&& os, - const basic_string<charT,traits,Allocator>& str); + + + + +<hr> +<h3><a name="991"></a>991. Response to JP 50</h3> +<p><b>Section:</b> 22.3.3.2.2 [conversions.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2009-03-03 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#conversions.string">active issues</a> in [conversions.string].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#conversions.string">issues</a> in [conversions.string].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Add custom allocator parameter to <tt>wstring_convert</tt>, since we cannot +allocate memory for strings from a custom allocator. +</p> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +We agree with the proposed resolution. +Move to Tentatively Ready. +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +Change 22.3.3.2.2 [conversions.string]: +</p> + +<blockquote><pre>template<class Codecvt, class Elem = wchar_t<ins>, + class Wide_alloc = std::allocator<Elem>, + class Byte_alloc = std::allocator<char> </ins>> class wstring_convert { + public: + typedef std::basic_string<char<ins>, char_traits<char>, Byte_alloc</ins>> byte_string; + typedef std::basic_string<Elem<ins>, char_traits<Elem>, Wide_alloc</ins>> wide_string; + ... </pre></blockquote> +<p> +Change 22.3.3.2.2 [conversions.string], p3: +</p> + +<blockquote> +-3- The class template describes an ob ject that controls conversions +between wide string ob jects of class +<tt>std::basic_string<Elem<ins>, char_traits<Elem>, Wide_alloc</ins>></tt> +and byte string objects of class +<tt>std::basic_string<char<ins>, char_traits<char>, Byte_alloc</ins>></tt> +<del>(also known as <tt>std::string</tt>)</del>. +</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> +<h3><a name="992"></a>992. Response to UK 169</h3> +<p><b>Section:</b> 17.6.1.1 [contents] <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>Opened:</b> 2009-03-03 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#contents">active issues</a> in [contents].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#contents">issues</a> in [contents].</p> <p><b>View all 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? +This phrasing contradicts later freedom to implement the C standard +library portions in the global namespace as well as std. (17.6.2.3p4) </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>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +The proposed wording seems to go too far. +Move back to Open. +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +Change 17.6.1.1 [contents], p2: +</p> + +<blockquote> +-2- All library entities except <ins>those from the Standard C +library,</ins> macros, <tt>operator new</tt> and <tt>operator +delete</tt> are defined within the namespace <tt>std</tt> or namespaces +nested within namespace <tt>std</tt>. +</blockquote> + + + + + + +<hr> +<h3><a name="993"></a>993. Response to UK 188</h3> +<p><b>Section:</b> 18.5 [support.start.term] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2009-03-03 <b>Last modified:</b> 2009-05-23</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#support.start.term">issues</a> in [support.start.term].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The function <tt>_Exit</tt> does not appear to be defined in this standard. +Should it be added to the table of functions included-by-reference to +the C standard? +</p> <p><i>[ -Sophia Antipolis +2009-05-09 Alisdair fixed some minor issues in the wording. ]</i></p> +<p><i>[ +Batavia (2009-05): +]</i></p> + <blockquote> -Agree with the idea in the issue, Alisdair to provide wording. +We agree with the proposed resolution. +Move to Tentatively Ready. </blockquote> +<p><b>Proposed resolution:</b></p> +<p> +Add to 18.5 [support.start.term] Table 20 (Header +<tt><cstdlib></tt> synopsis) Functions: +</p> + +<blockquote><pre>_Exit +</pre></blockquote> + +<p> +Add before the description of <tt>abort(void)</tt>: +</p> + +<blockquote><pre>void _Exit [[noreturn]] (int status) +</pre> + +<blockquote> +<p> +The function <tt>_Exit(int status)</tt> has additional behavior in this +International Standard: +</p> +<ul> +<li> +The program is terminated without executing destructors for objects of +automatic, thread, or static storage duration and without calling the +functions passed to <tt>atexit()</tt> (3.6.3 [basic.start.term]). +</li> +</ul> +</blockquote> +</blockquote> + + + + + + +<hr> +<h3><a name="994"></a>994. Response to UK 193</h3> +<p><b>Section:</b> 18.6.2.2 [new.handler] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2009-03-03 <b>Last modified:</b> 2009-05-23</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p> +<p><b>Discussion:</b></p> +<p> +<tt>quick_exit</tt> has been added as a new valid way to terminate a program in a +well defined way +</p> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +We agree with the proposed resolution. +Move to Tentatively Ready. +</blockquote> + <p><b>Proposed resolution:</b></p> <p> +Change 18.6.2.2 [new.handler], p2: </p> +<blockquote> +<p> +-2- <i>Required behavior:</i> ... +</p> +<ul> +<li>...</li> +<li> +<del>call either <tt>abort()</tt> or <tt>exit();</tt></del> +<ins>terminate execution of the program without returning to the caller</ins> +</li> +</ul> +</blockquote> + + + <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> +<h3><a name="995"></a>995. Operational Semantics Unclear</h3> +<p><b>Section:</b> 17.5.1.3 [structure.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">Tentatively NAD</a> + <b>Submitter:</b> David Abrahams <b>Opened:</b> 2009-03-06 <b>Last modified:</b> 2009-05-23</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD">Tentatively NAD</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. +As a practical matter there's disagreement on the meaning of <i>operational +semantics</i>. If the text in 17.5.1.3 [structure.requirements]p4 isn't +clear, it should be clarified. However, it's not clear whether the +disagreement is merely due to people not being aware of the text. </p> +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +Agree with the recommended NAD resolution. +</blockquote> + <p><b>Proposed resolution:</b></p> <p> +Recommend NAD. The text in 17.5.1.3 [structure.requirements] is +perfectly clear. </p> @@ -15201,150 +26150,623 @@ unfair advantage of raw pointers. <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> +<h3><a name="996"></a>996. Move operation not well specified</h3> +<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> + <b>Submitter:</b> David Abrahams <b>Opened:</b> 2009-03-06 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</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#Open">Open</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.] +There are lots of places in the standard where we talk about "the move +constructor" but where we mean "the move operation," i.e. <tt>T( move( x ) )</tt>. </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. +We also don't account for whether that operation modifies <tt>x</tt> or not, and +we need to. </p> <p><i>[ -Sophia Antipolis: +Batavia (2009-05): ]</i></p> +<blockquote> +Move to Open, pending proposed wording from Dave for further +review. +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +</p> + + + + + +<hr> +<h3><a name="997"></a>997. Response to UK 163</h3> +<p><b>Section:</b> 17.5.1.4 [structure.specifications] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> Thomas Plum <b>Opened:</b> 2009-03-03 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#structure.specifications">active issues</a> in [structure.specifications].</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#Tentatively%20Ready">Tentatively Ready</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Many functions are defined as "Effects: Equivalent to a...", which seems +to also define the preconditions, effects, etc. But this is not made +clear. +</p> + +<p> +After studying the occurrences of "Effects: Equivalent to", I agree with +the diagnosis but disagree with the solution. In 21.4.2 [string.cons] +we find +</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. +14 <i>Effects:</i> If <tt>InputIterator</tt> is an integral type, equivalent to +<tt>basic_string(static_cast<size_type>(begin), static_cast<value_type>(end), a)</tt> </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. +15 Otherwise constructs a string from the values in the range <tt>[begin, +end)</tt>, as indicated in the Sequence Requirements table (see 23.1.3). </p> </blockquote> +<p> +This would be devishly difficult to re-write with an explicit +"Equivalent to:" clause. Instead, I propose the following, which will +result in much less editorial re-work. +</p> + +<p><i>[ +2009-05-09 Alisdair adds: +]</i></p> + + +<blockquote> +This issue is related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#492">492</a>. +</blockquote> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +We agree with the proposed resolution. +Move to Tentatively Ready. +</blockquote> + <p><b>Proposed resolution:</b></p> <p> -Change 30.3.1.1 [thread.mutex.class]: +Add a new paragraph after 17.5.1.4 [structure.specifications], p3: </p> -<blockquote><pre>class mutex { -public: - <ins>constexpr</ins> mutex(); - ... -</pre></blockquote> +<blockquote> +<p> +-3- Descriptions of function semantics contain the following elements (as appropriate):<sup>154</sup> +</p> + +<ul> +<li> +<i>Requires:</i> the preconditions for calling the function +</li> +<li> +<i>Effects:</i> the actions performed by the function +</li> +<li> +<i>Postconditions:</i> the observable results established by the function +</li> +<li> +<i>Returns:</i> a description of the value(s) returned by the function +</li> +<li> +<i>Throws:</i> any exceptions thrown by the function, and the conditions that would cause the exception +</li> +<li> +<i>Complexity:</i> the time and/or space complexity of the function +</li> +<li> +<i>Remarks:</i> additional semantic constraints on the function +</li> +<li> +<i>Error conditions:</i> the error conditions for error codes reported by the function. +</li> +<li> +<i>Notes:</i> non-normative comments about the function +</li> +</ul> + +<p><ins> +Whenever the <i>Effects</i> element specifies that the semantics of some +function <tt>F</tt> are <i>Equivalent to</i> some <i>code-sequence</i>, then +the various elements are interpreted as follows. If <tt>F</tt>'s +semantics specifies a <i>Requires</i> element, then that requirement is +logically imposed prior to the <i>equivalent-to</i> semantics. Then, +the semantics of the <i>code-sequence</i> are determined by the +<i>Requires</i>, <i>Effects</i>, <i>Postconditions</i>, <i>Returns</i>, +<i>Throws</i>, <i>Complexity</i>, <i>Remarks</i>, <i>Error +Conditions</i> and <i>Notes</i> specified for the (one or more) function +invocations contained in the <i>code-sequence</i>. The value returned from +<tt>F</tt> is specified by <tt>F</tt>'s <i>Returns</i> element, or +if <tt>F</tt> has no <i>Returns</i> element, a non-<tt>void</tt> return from <tt>F</tt> is specified +by the <i>Returns</i> elements in <i>code-sequence</i>. If +<tt>F</tt>'s semantics contains a <i>Throws</i> (or +<i>Postconditions</i>, or <i>Complexity</i>) element, then that +supersedes any occurrences of that element in the <i>code-sequence</i>. +</ins></p> +</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> +<h3><a name="998"></a>998. Smart pointer referencing its owner</h3> +<p><b>Section:</b> 20.8.12.2.5 [unique.ptr.single.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> Pavel Minaev <b>Opened:</b> 2009-02-26 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unique.ptr.single.modifiers">active issues</a> in [unique.ptr.single.modifiers].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr.single.modifiers">issues</a> in [unique.ptr.single.modifiers].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p> <p><b>Discussion:</b></p> -<p>Consider this code:</p> +<p> +Consider the following (simplified) implementation of +<tt>std::auto_ptr<T>::reset()</tt>: +</p> + +<blockquote><pre>void reset(T* newptr = 0) { + if (this->ptr && this->ptr != newptr) { + delete this->ptr; + } + this->ptr = newptr; +} +</pre></blockquote> + +<p> +Now consider the following code which uses the above implementation: +</p> + +<blockquote><pre>struct foo { + std::auto_ptr<foo> ap; + foo() : ap(this) {} + void reset() { ap.reset(); } +}; +int main() { + (new foo)->reset(); +} +</pre></blockquote> + +<p> +With the above implementation of auto_ptr, this results in U.B. at the +point of auto_ptr::reset(). If this isn't obvious yet, let me explain +how this goes step by step: +</p> + +<ol> +<li> +<tt>foo::reset()</tt> entered +</li> +<li> +<tt>auto_ptr::reset()</tt> entered +</li> +<li> +<tt>auto_ptr::reset()</tt> tries to delete <tt>foo</tt> +</li> +<li> +<tt>foo::~foo()</tt> entered, tries to destruct its members +</li> +<li> +<tt>auto_ptr::~auto_ptr()</tt> executed - <tt>auto_ptr</tt> is no longer a valid object! +</li> +<li> +<tt>foo::~foo()</tt> left +</li> +<li> +<tt>auto_ptr::reset()</tt> sets its "ptr" field to 0 <- U.B.! <tt>auto_ptr</tt> +is not a valid object here already! +</li> +</ol> + +<p><i>[ +Thanks to Peter Dimov who recognized the connection to <tt>unique_ptr</tt> and +brought this to the attention of the LWG, and helped with the solution. +]</i></p> + + +<p><i>[ +Howard adds: +]</i></p> + <blockquote> -<pre>exception_ptr xp;</pre> -<pre>try {do_something(); } +To fix this behavior <tt>reset</tt> must be specified such that deleting the +pointer is the last action to be taken within <tt>reset</tt>. +</blockquote> -catch (const runtime_error& ) {xp = current_exception();} +<p><i>[ +Alisdair adds: +]</i></p> -... -rethrow_exception(xp);</pre> +<blockquote> +<p> +The example providing the rationale for LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#998">998</a> is poor, as it relies on +broken semantics of having two object believing they are unique owners of a +single resource. It should not be surprising that UB results from such +code, and I feel no need to go out of our way to support such behaviour. +</p> +<p> +If an example is presented that does not imply multiple ownership of a +unique resource, I would be much more ready to accept the proposed +resolution. +</p> +</blockquote> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +<p> +Howard summarizes: +</p> +<blockquote> +This issue has to do with circular ownership, +and affects <tt>auto_ptr</tt>, too (but we don't really care about that). +It is intended to spell out the order in which operations must be performed +so as to avoid the possibility +of undefined behavior in the self-referential case. </blockquote> +<p> +Howard points to message c++std-lib-23175 for another example, +requested by Alisdair. +</p> +<p> +We agree with the issue and with the proposed resolution. +Move to Tentatively Ready. +</p> +</blockquote> + + + +<p><b>Proposed resolution:</b></p> +<p> +Change 20.8.12.2.5 [unique.ptr.single.modifiers], p5 (<i>Effects</i> clause for <tt>reset</tt>), and p6: +</p> +<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. +-5- <i>Effects:</i> <del>If <tt>get() == nullptr</tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>.</del> +<ins>Assigns <tt>p</tt> to the stored <tt>pointer</tt>, and then if the old value of the <tt>pointer</tt> is not +equal to <tt>nullptr</tt>, calls <tt>get_deleter()(</tt>the old value of the <tt>pointer)</tt>. +[<i>Note:</i> The order of these operations is significant because the call to <tt>get_deleter()</tt> +may destroy <tt>*this</tt>. <i>-- end note</i>]</ins> </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. +-6- Postconditions: <tt>get() == p</tt>. +<ins>[<i>Note:</i> The postcondition does not hold if the call to +<tt>get_deleter()</tt> destroys <tt>*this</tt> since <tt>this->get()</tt> is no longer a valid +expression. <i>-- end note</i>]</ins> </p> +</blockquote> + + + + + +<hr> +<h3><a name="999"></a>999. Taking the address of a function</h3> +<p><b>Section:</b> 20.8.11.1 [object.addressof] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2009-03-09 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#object.addressof">active issues</a> in [object.addressof].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#object.addressof">issues</a> in [object.addressof].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The same fix (reference <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#987">987</a>) may be applied to <tt>addressof</tt>, which is also constrained to +<tt>ObjectType</tt>. (That was why <tt>boost::ref</tt> didn't work with functions - it +tried to apply <tt>boost::addressof</tt> and the <tt>reinterpret_cast<char&></tt> +implementation of <tt>addressof</tt> failed.) +</p> + + <p><i>[ -Peter adds: +Batavia (2009-05): ]</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. +We agree. </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. +Move to Tentatively Ready. </p> </blockquote> <p><b>Proposed resolution:</b></p> +<p> +Change the synopsis in 20.8 [memory]: +</p> +<blockquote><pre>template <<del>ObjectType</del> <ins>PointeeType</ins> T> + T* addressof(T& r); +</pre></blockquote> + +<p> +Change 20.8.11.1 [object.addressof]: +</p> + +<blockquote><pre>template <<del>ObjectType</del> <ins>PointeeType</ins> T> + T* addressof(T& r); +</pre></blockquote> + + +<p><b>Rationale:</b></p> <p> -After 18.7.5 [propagation] , paragraph 7, add the indicated text: +a) The occurrence of <tt>T&</tt> in the function signature auto-implies +<tt>std::ReferentType</tt>, +this is due to 14.11.1.2 [temp.req.impl]/4 bullet 4 </p> + + + + +<hr> +<h3><a name="1000"></a>1000. adjacent_find is over-constrained</h3> +<p><b>Section:</b> 25.3.8 [alg.adjacent.find] <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>Opened:</b> 2009-03-09 <b>Last modified:</b> 2009-03-13</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.adjacent.find">issues</a> in [alg.adjacent.find].</p> +<p><b>View all 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> +<b>Addresses UK 296</b> +</p> + +<p> +<tt>adjacent_find</tt> in C++03 allows an arbitrary predicate, but in C++0x +<tt>EqualityComparable/EquivalenceRelation</tt> is required. This forbids a +number of use cases, including: +</p> <blockquote> -<pre>exception_ptr current_exception();</pre> +<table> +<tbody><tr> +<td valign="top"> +<tt>adjacent_find(begin, end, less<double>)</tt> +</td> +<td> +Find the first +place where a range is not ordered in decreasing order - in use to check +for sorted ranges. +</td> +</tr> +<tr> +<td valign="top"> +<tt>adjacent_find(begin, end, DistanceBiggerThan(6) ) )</tt> +</td> +<td> +Find the first +place in a range where values differ by more than a given value - in use +to check an algorithm which produces points in space does not generate +points too far apart. +</td> +</tr> +</tbody></table> +</blockquote> + +<p> +A number of books use predicate which are not equivalence relations in +examples, including "Thinking in C++" and "C++ Primer". +</p> + +<p> +Adding the requirement that the predicate is an <tt>EquivalenceRelation</tt> +does not appear to open up any possibility for a more optimised algorithm. +</p> + + + +<p><b>Proposed resolution:</b></p> +<p> +Change the definition of adjacent_find in the synopsis of 25 [algorithms] +and 25.3.8 [alg.adjacent.find] to: +</p> + +<blockquote><pre>template<ForwardIterator Iter> + requires <del>EqualityComparable</del><ins>HasEqualTo</ins><Iter::value_type<ins>, Iter::value_type</ins>> + Iter adjacent_find(Iter first, Iter last); + +template<ForwardIterator Iter, <del>EquivalenceRelation</del><ins>Predicate</ins><auto, Iter::value_type<ins>, Iter::value_type</ins>> Pred> + requires CopyConstructible<Pred> + Iter adjacent_find(Iter first, Iter last, Pred pred); +</pre></blockquote> + + + + + +<hr> +<h3><a name="1001"></a>1001. Pointers, concepts and 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#Review">Review</a> + <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-10 <b>Last modified:</b> 2009-06-16</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</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#Review">Review</a> status.</p> +<p><b>Discussion:</b></p> + +<p><b>Addresses UK 78</b></p> + +<p> +Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1063">1063</a>. +</p> + +<p> +This is effectively an extension of LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#343">343</a>. +</p> +<p> +We know there is an increasing trend (encouraged by conformance testers and +some users) that each library header should supply no more than required to +satisfy the synopsis in the standard. This is typically achieved by +breaking larger headers into smaller subsets, and judicious use of forward +declarations. +</p> +<p> +If we apply this policy to C++0x (per +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2800.pdf">N2800</a>) +it will be very surprising for +people using library algorithms over ranges defined by pointers that they +must <tt>#include <iterator_concepts></tt> for their code to compile again. That is +because pointers do not satisfy any of the iterator concepts without the +<tt>concept_map</tt> supplied in this header. +</p> +<p> +Therefore, I suggest we should require all library headers that make use of +iterator concepts are specifically required to <tt>#include <iterator_concepts></tt>. +</p> +<p> +At a minimum, the list of headers would be: (assuming all are constrained by +concepts) +</p> +<blockquote><pre>algorithm +array +deque +forward_list +initializer_list +iterator +locale +list +map +memory // if <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1029">1029</a> is adopted +memory_concepts +numeric +random +regex +set +string +tuple +unordered_map +unordered_set +utility +vector +</pre></blockquote> + +<p><i>[ +Ganesh adds: +]</i></p> + <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>] +The same problems exists for <tt><memory_concepts></tt> and +<tt><container_concepts></tt>. +</p> +<p> +In order to compile <tt><vector></tt> you just need the +definitions of the concepts in <tt><memory_concepts></tt>, the +concept maps defined there are not necessary. Yet, from the user point +of view, if the concept map template for <tt>AllocatableElement</tt> are +not in scope, <tt><vector></tt> is pretty useless. Same for +<tt><tuple></tt> and <tt>ConstructibleWithAllocator</tt>. +</p> +<p> +Similarly, <tt><queue></tt> is not very useful if the concept map +template for <tt>QueueLikeContainer</tt> is not in scope, although the +definition of concept alone is theoretically sufficient. </p> +<p> +There's a pattern here: if a concept has concept maps "attached", they +should never be separated. +</p> +</blockquote> + +<p><i>[ +Beman provided the proposed resolution for the May 2009 mailing. He +comments: +]</i></p> + + +<blockquote> + +<p>Initially I tried to specify exactly what header should include what other +headers. This was verbose, error prone, hard to maintain, and appeared to add +little value compared to just stating the general rule.</p> +</blockquote> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> <p> -<i>Throws:</i> nothing. +Pete believes the proposed wording overconstrains implementers. +Instead of specifying the mechanism, +he prefers a solution that spells out what needs to be declared, +rather than how those declarations are to be provided, +e.g., </p> +<blockquote> +A C++ header shall provide the names +that are required to be defined in that header. +</blockquote> +<p> +Bill suggests approaching the wording from a programmer's perspective. +We may want to consider promising that certain widely-used headers +(e.g., the concept headers) are included when needed by other headers. +He feels, however, there is nothing broken now, +although we may want to consider "something nicer." +</p> +<p> +Move to Open status. +</p> + +</blockquote> + +<p><i>[ +2009-06-16 Beman updated the proposed resolution: +]</i></p> + +<blockquote> + <ul> + <li>The mechanism is no longer specified, as requested in Batavia.</li> + <li>The footnote has been removed since it specified mechanism and also did + not reflect existing practice.</li> + <li>A sentence was added that makes it clear that the existing practice is + permitted.</li> + </ul> </blockquote> + + + +<p><b>Proposed resolution:</b></p> +<p><i>Change 17.6.4.2 [res.on.headers], Headers, paragraph 1, as indicated:</i></p> +<blockquote> + <p> <ins>A C++ + header shall provide definitions for any names that appear in its synopsis (3.2 [basic.def.odr]).</ins> + A C++ header may include other C++ headers.<del><sup>[footnote]</sup></del> <ins>A C++ + header shown in its synopsis as including other C++ headers shall provide + definitions for the same names as if those other headers were included. A C++ header that uses a + concept (14.10 [concept]) shall provide the definition for that concept as if it included the C++ header + that defines that concept in its synopsis. The mechanism and ordering of such + definitions is unspecified.</ins></p> + + <p><ins>[<i>Example:</i> If C++ header <code><a></code> contains a concept + defined in C++ header <code><b></code>, and header <code><b></code> contains a + concept defined in C++ header <code><c></code>, then inclusion of <code><a></code> + is equivalent to inclusion of <code><a></code>, <code><b></code>, and <code> + <c></code>. <i>— end example</i>]</ins></p> + + <p><del><sup>[footnote]</sup> C++ headers must include a C++ header that contains + any needed definition (3.2).</del></p> </blockquote> @@ -15353,416 +26775,1281 @@ creates a new copy each time it is called. <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> +<h3><a name="1002"></a>1002. Response to UK 170</h3> +<p><b>Section:</b> 17.6.1.2 [headers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-05-23</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#Tentatively%20Ready">Tentatively Ready</a> status.</p> <p><b>Discussion:</b></p> + +<p><b>Addresses UK 170</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. +One of goals of C++0x is to make language easier to teach and for +'incidental' programmers. The fine-grained headers of the C++ library +are valuable in large scale systems for managing dependencies and +optimising build times, but overcomplicated for simple development and +tutorials. Add additional headers to support the whole library through a +single include statement. </p> <p><i>[ -Alisdair adds: +Batavia (2009-05): ]</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. +We do not all agree that this is an issue, +but we agree that if it needs solving this is the right way to do it. +Move to Tentatively Ready. </blockquote> + +<p><b>Proposed resolution:</b></p> +<p> +Insert a new paragraph in 17.6.1.2 [headers] between p4 and p5 +</p> +<blockquote> +An additional header <tt><std></tt> shall have the effect of +supplying the entire standard library. [<i>Note:</i> for example, it +might be implemented as a file with an <tt>#include</tt> statement for each of the +headers listed in tables 13 and 14. <i>-- end note</i>] +</blockquote> + + + + + +<hr> +<h3><a name="1003"></a>1003. Response to JP 23</h3> +<p><b>Section:</b> 17.6.1.3 [compliance] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> + <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#compliance">active issues</a> in [compliance].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#compliance">issues</a> in [compliance].</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><b>Addresses JP 23</b></p> + +<p> +There is a freestanding implementation including +<tt><type_traits></tt>, <tt><array></tt>, +<tt><ratio></tt>, lately added to Table 13, C++ library headers. +Programmers think them useful and hope that these headers are also added +to Table 15, C++ headers for freestanding implementations, that shows +the set of headers which a freestanding implementation shall include at +least. +</p> + +<p><b>Original proposed resolution</b></p> + +<p> +Add <tt><type_traits></tt>, <tt><array></tt>, +<tt><ratio></tt> to Table 15. +</p> + <p><i>[ -Sophia Antipolis: +Summit: ]</i></p> <blockquote> <p> -Idea of the issue is ok. + The <tt><array></tt> header has far too many dependencies to require for a +free-standing implementation. </p> <p> -Alisdair to provide wording, once that wording arrives, move to review. +The <tt><ratio></tt> header would be useful, has no dependencies, but is not +strictly necessary. +</p> +<p> +The <tt><type_traits></tt> header is fundamentally a core language facility with a +library interface, so should be supported. +</p> + +<p> +(it is anticipated the resolution will come via an update to paper +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2814.pdf">N2814</a>) +(see also LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#833">833</a>) </p> </blockquote> +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +Leave in Review status pending a paper on freestanding implementations +by Martin Tasker. +</blockquote> <p><b>Proposed resolution:</b></p> <p> - Replace paragraph 4 of 21.1 [char.traits] by: +Add <tt><type_traits></tt> to Table 15. +</p> + + + + + + +<hr> +<h3><a name="1004"></a>1004. Response to UK 179</h3> +<p><b>Section:</b> 17.6.3.8 [res.on.functions] <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>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-05-23</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#res.on.functions">issues</a> in [res.on.functions].</p> +<p><b>View all 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><b>Addresses UK 179</b></p> + +<p> +According to the 4th bullet there is a problem if "if any replacement +function or handler function or destructor operation throws an +exception". There should be no problem throwing exceptions so long as +they are caught within the function. </p> + +<p><i>[ +Batavia (2009-05): +]</i></p> + <blockquote> +The phrasing "throws an exception" is commonly used elsewhere +to mean "throws or propagates an exception." +Move to Open pending a possible more general resolution. +</blockquote> + + +<p><b>Proposed resolution:</b></p> <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. +Change the 4th bullet of 17.6.3.8 [res.on.functions], p2: </p> + +<blockquote> +<ul> +<li> +if any replacement function or handler function or destructor operation +<del>throws</del> <ins>propagates</ins> an exception, unless specifically +allowed in the applicable <i>Required behavior:</i> paragraph. +</li> +</ul> </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> +<h3><a name="1005"></a>1005. Response to JP 26</h3> +<p><b>Section:</b> 18.3.1.1 [numeric.limits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> + <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-05-25</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><b>Addresses JP 26</b></p> + +<p> +<tt>numeric_limits</tt> [partial specializations] does not use concept. +</p> + +<p><i>[ +Summit: +]</i></p> + + +<blockquote> +Alisdair will provide a soltion as part of treatment of axioms and LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#902">902</a>. +</blockquote> + +<p><i>[ +Post Summit: +]</i></p> + + +<blockquote> +Alisdair recommends NAD as the partial specializations are already +constrained by requirements on the primary template. +</blockquote> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +The Working Draft does not in general repeat a primary template's constraints +in any specializations. +Move to NAD. +</blockquote> + +<p><i>[ +2009-05-25 Howard adds: +]</i></p> + + +<blockquote> +A c++std-lib thread starting at c++std-lib-23880 has cast doubt that NAD is the +correct resolution of this issue. Indeed the discussion also casts doubt that +the current proposed wording is the correct resolution as well. Personally I'm +inclined to reset the status to Open. However I'm reverting the status to +that which it had prior to the Batavia recommendation. I'm setting back to Review. +</blockquote> + + +<p><b>Proposed resolution:</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. +Change 18.3.1.1 [numeric.limits]: </p> +<blockquote><pre>template<<del>class</del> <ins>Regular</ins> T> class numeric_limits<const T>; +template<<del>class</del> <ins>Regular</ins> T> class numeric_limits<volatile T>; +template<<del>class</del> <ins>Regular</ins> T> class numeric_limits<const volatile T>; +</pre></blockquote> + + + + + + +<hr> +<h3><a name="1006"></a>1006. Response to UK 190</h3> +<p><b>Section:</b> 18.6.1 [new.delete] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-05-23</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#new.delete">issues</a> in [new.delete].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p> +<p><b>Discussion:</b></p> + +<p><b>Addresses UK 190</b></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. +It is not entirely clear how the current specification acts in the +presence of a garbage collected implementation. </p> +<p><i>[ +Summit: +]</i></p> + + +<blockquote> +Agreed. +</blockquote> + +<p><i>[ +2009-05-09 Alisdair adds: +]</i></p> + + +<blockquote> +Proposed wording is too strict for implementations that do not support +garbage collection. Updated wording supplied. +</blockquote> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +We recommend advancing this to Tentatively Ready +with the understanding that it will not be moved for adoption +unless and until the proposed resolution to Core issue #853 is adopted. +</blockquote> + + +<p><b>Proposed resolution:</b></p> + <p> -Thanks to Jens Maurer, Gabriel Dos Reis, and Bjarne Stroustrup for clarification of <tt>constexpr</tt> requirements. +(Editorial note: This wording ties into the proposed +resolution for Core #853) </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. +Add paragraphs to 18.6.1.1 [new.delete.single]: </p> +<blockquote><pre>void operator delete(void* ptr) throw(); +<del>void operator delete(void* ptr, const std::nothrow_t&) throw();</del> +</pre> + <p><i>[ -Sophia Antipolis: +The second signature deletion above is editorial. ]</i></p> <blockquote> -On going question of extern pointer vs. inline functions for interface. +<p><ins> +<i>Requires:</i> If an implementation has strict pointer safety +(3.7.4.3 [basic.stc.dynamic.safety]) then <tt>ptr</tt> shall +be a safely-derived pointer. +</ins></p> + +<p>-10- ...</p> </blockquote> +<pre>void operator delete(void* ptr, const std::nothrow_t&) throw(); +</pre> + +<blockquote> +<p><ins> +<i>Requires:</i> If an implementation has strict pointer safety +(3.7.4.3 [basic.stc.dynamic.safety]) then <tt>ptr</tt> shall +be a safely-derived pointer. +</ins></p> + +<p>-15- ...</p> +</blockquote> + +</blockquote> + +<p> +Add paragraphs to 18.6.1.2 [new.delete.array]: +</p> + +<blockquote><pre>void operator delete[](void* ptr) throw(); +<del>void operator delete[](void* ptr, const std::nothrow_t&) throw();</del> +</pre> + <p><i>[ -Pre-San Francisco: +The second signature deletion above is editorial. ]</i></p> <blockquote> +<p><ins> +<i>Requires:</i> If an implementation has strict pointer safety +(3.7.4.3 [basic.stc.dynamic.safety]) then <tt>ptr</tt> shall +be a safely-derived pointer. +</ins></p> + +<p>-9- ...</p> +</blockquote> + +<pre>void operator delete[](void* ptr, const std::nothrow_t&) throw(); +</pre> + +<blockquote> +<p><ins> +<i>Requires:</i> If an implementation has strict pointer safety +(3.7.4.3 [basic.stc.dynamic.safety]) then <tt>ptr</tt> shall +be a safely-derived pointer. +</ins></p> + +<p>-13- ...</p> +</blockquote> + +</blockquote> + + <p> -Beman Dawes reports that this proposal is unimplementable, and thus NAD. +Add paragraphs to 18.6.1.3 [new.delete.placement]: </p> + +<blockquote><pre>void operator delete(void* ptr, void*) throw(); +</pre> + +<blockquote> +<p><ins> +<i>Requires:</i> If an implementation has strict pointer safety +(3.7.4.3 [basic.stc.dynamic.safety]) then <tt>ptr</tt> shall +be a safely-derived pointer. +</ins></p> + +<p>-7- ...</p> +</blockquote> + +<pre>void operator delete[](void* ptr, void*) throw(); +</pre> + +<blockquote> +<p><ins> +<i>Requires:</i> If an implementation has strict pointer safety +(3.7.4.3 [basic.stc.dynamic.safety]) then <tt>ptr</tt> shall +be a safely-derived pointer. +</ins></p> + +<p>-9- ...</p> +</blockquote> + +</blockquote> + + + + + + +<hr> +<h3><a name="1007"></a>1007. Response to JP 29</h3> +<p><b>Section:</b> 18.8.6 [except.nested] <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>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-03-13</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#except.nested">active issues</a> in [except.nested].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#except.nested">issues</a> in [except.nested].</p> +<p><b>View all 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><b>Addresses JP 29</b></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. +<tt>throw_with_nested</tt> does not use concept. </p> +<p><i>[ +Summit: +]</i></p> + + +<blockquote> +Agreed. </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. +Alisdair initially proposed wording in +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2619.pdf">N2619</a>. </p> - <p> -Change 19.4.1.1 [syserr.errcat.overview] Class -<tt>error_category</tt> overview <tt>error_category</tt> synopsis as -indicated: +We are awaiting an updated paper based on feedback from the San Francisco +review. </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> + + + +<hr> +<h3><a name="1008"></a>1008. Response to JP 31</h3> +<p><b>Section:</b> 18.8.6 [except.nested] <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>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-03-13</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#except.nested">active issues</a> in [except.nested].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#except.nested">issues</a> in [except.nested].</p> +<p><b>View all 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><b>Addresses JP 31</b></p> <p> -Change 19.4.1.5 [syserr.errcat.objects] Error category objects as indicated: +It is difficult to understand in which case <tt>nested_exception</tt> is applied. </p> +<p><i>[ +Summit: +]</i></p> + + <blockquote> -<pre><ins>extern</ins> const error_category<del>&</del><ins>* const</ins> <del>get_</del>generic_category<del>()</del>; +Alisdair will add an example in an update to +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2619.pdf">N2619</a>. +</blockquote> + + + +<p><b>Proposed resolution:</b></p> + + + + + +<hr> +<h3><a name="1009"></a>1009. Response to UK 251</h3> +<p><b>Section:</b> 24.2.1 [iterator.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> + <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-03-22</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><b>Addresses UK 251</b></p> + +<p> +The post-increment operator is dangerous for a general InputIterator. +The multi-pass guarantees that make it meaningful are defined as part of +the ForwardIterator refinement. Any change will affect only constrained +templates that have not yet been written, so should not break existing +user iterators which remain free to add these operations. This change +will also affect the generalised OutputIterator, although there is no +percieved need for the post-increment operator in this case either. +</p> + + + +<p><b>Proposed resolution:</b></p> +<p> +Change 24.2.1 [iterator.iterators]: +</p> + +<blockquote><pre>concept Iterator<typename X> : Semiregular<X> { + MoveConstructible reference = typename X::reference; + <del>MoveConstructible postincrement_result;</del> + + <del>requires HasDereference<postincrement_result>;</del> + + reference operator*(X&&); + X& operator++(X&); + <del>postincrement_result operator++(X&, int);</del> +} </pre> + +<p>...</p> +<pre><del>postincrement_result operator++(X& r, int);</del> +</pre> + +<blockquote> +<del>-3- <i>Effects:</i> equivalent to <tt>{ X tmp = r; ++r; return tmp; }</tt>.</del> +</blockquote> + +</blockquote> + <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>. +Change 24.2.2 [input.iterators]: </p> +<blockquote> +<pre>concept InputIterator<typename X> : Iterator<X>, EqualityComparable<X> { + ObjectType value_type = typename X::value_type; + MoveConstructible pointer = typename X::pointer; + + SignedIntegralLike difference_type = typename X::difference_type; + + requires IntegralType<difference_type> + && Convertible<reference, const value_type &>; + && Convertible<pointer, const value_type*>; + + <del>requires Convertible<HasDereference<postincrement_result>::result_type, const value_type&>;</del> + + pointer operator->(const X&); +} +</pre> +</blockquote> + <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>. +Change 24.2.3 [output.iterators]: </p> -<pre><ins>extern</ins> const error_category<del>&</del><ins>* const</ins> <del>get_</del>system_category<del>()</del>; +<blockquote> +<pre>auto concept OutputIterator<typename X, typename Value> { + requires Iterator<X>; + + typename reference = Iterator<X>::reference; + <del>typename postincrement_result = Iterator<X>::postincrement_result;</del> + requires SameType<reference, Iterator<X>::reference> + <del>&& SameType<postincrement_result, Iterator<X>::postincrement_result></del> + <del>&& Convertible<postincrement_result, const X&></del> + && HasAssign<reference, Value> + <del>&& HasAssign<HasDereference<postincrement_result>::result_type, Value></del>; +} </pre> +</blockquote> <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>. +Change 24.2.4 [forward.iterators]: </p> +<p><i>[ +See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1084">1084</a> which is attempting to change this same area in a compatible +way. +]</i></p> + + +<blockquote> +<pre>concept ForwardIterator<typename X> : InputIterator<X>, Regular<X> { + <del>requires Convertible<postincrement_result, const X&>;</del> + + <ins>MoveConstructible postincrement_result;</ins> + <ins>requires HasDereference<postincrement_result> + && Convertible<HasDereference<postincrement_result>::result_type, const value_type&>;</ins> + + <ins>postincrement_result operator++(X&, int);</ins> + + axiom MultiPass(X a, X b) { + if (a == b) *a == *b; + if (a == b) ++a == ++b; + } +} +</pre> + +<blockquote> +<p>-4- ...</p> +</blockquote> + +<pre><ins>postincrement_result operator++(X& r, int);</ins> +</pre> + +<blockquote> <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: +<ins>-5- <i>Effects:</i> equivalent to <tt>{ X tmp = r; ++r; return tmp; }</tt>.</ins> </p> +</blockquote> + +</blockquote> + + + + + + +<hr> +<h3><a name="1010"></a>1010. Response to UK 263</h3> +<p><b>Section:</b> 24.2.6 [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> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#random.access.iterators">active issues</a> in [random.access.iterators].</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><b>Addresses UK 263</b></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>] +This requirement on <tt>operator-=</tt> would be better expressed as a default +implementation in the concept, with a matching axiom. </p> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +The proposed resolution should also remove +paragraph 5 and the declaration that precedes it. +Further, we should provide an axiom +that captures the desired semantics. +This may be a broader policy to be applied. +Move to Open. </blockquote> + +<p><b>Proposed resolution:</b></p> <p> -Change 19.4.2.1 [syserr.errcode.overview] Class <tt>error_code</tt> overview as indicated: +Change 24.2.6 [random.access.iterators]: </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); +<blockquote><pre>concept RandomAccessIterator<typename X> : BidirectionalIterator<X>, LessThanComparable<X> { ... - const error_category<del>&</del><ins>*</ins> category() const; + X& operator-=(X& <ins>x</ins>, difference_type <ins>n</ins>)<ins> { return x += -n</ins>;<ins> }</ins> ... -private: - int val_; // exposition only - const error_category<del>&</del><ins>*</ins> cat_; // exposition only +} </pre></blockquote> + + + + + +<hr> +<h3><a name="1011"></a>1011. Response to UK 271</h3> +<p><b>Section:</b> 24.4 [iterator.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iterator.operations">active issues</a> in [iterator.operations].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.operations">issues</a> in [iterator.operations].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p> +<p><b>Discussion:</b></p> + +<p><b>Addresses UK 271</b></p> + <p> -Change 19.4.2.2 [syserr.errcode.constructors] Class <tt>error_code</tt> constructors as indicated: +<tt>next/prev</tt> return an incremented iterator without changing the value of +the original iterator. However, even this may invalidate an +<tt>InputIterator</tt>. A <tt>ForwardIterator</tt> is required to guarantee the +'multipass' property. </p> +<p><i>[ +Batavia (2009-05): +]</i></p> + <blockquote> -<pre><ins>constexpr</ins> error_code(int val, const error_category<del>&</del><ins>*</ins> cat); -</pre> +We agree with the proposed resolution. +Move to Tentatively Ready. +</blockquote> + + +<p><b>Proposed resolution:</b></p> <p> -<i>Effects:</i> Constructs an object of type <tt>error_code</tt>. +Change [iterator.synopsis]: </p> + +<blockquote><pre>template <<del>InputIterator</del> <ins>ForwardIterator</ins> Iter> + Iter next(Iter x, + Iter::difference_type n = 1); +</pre></blockquote> + <p> -<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == cat</tt>. +Change 24.4 [iterator.operations], p6: </p> + +<blockquote><pre>template <<del>InputIterator</del> <ins>ForwardIterator</ins> Iter> + Iter next(Iter x, + Iter::difference_type n = 1); +</pre></blockquote> + + + + + + +<hr> +<h3><a name="1012"></a>1012. Response to UK 277</h3> +<p><b>Section:</b> 24.5.1.2.1 [reverse.iter.cons] <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>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-05-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><b>Addresses UK 277</b></p> + <p> -<i>Throws:</i> Nothing. +The default constructor default-initializes current, rather than +value-initializes. This means that when Iterator corresponds to a +trivial type, the current member is left un-initialized, even when the +user explictly requests value intialization! At this point, it is not +safe to perform any operations on the reverse_iterator other than assign +it a new value or destroy it. Note that this does correspond to the +basic definition of a singular iterator. </p> + +<p><i>[ +Summit: +]</i></p> + + +<blockquote> +Agree with option i. </blockquote> <p> -Change 19.4.2.3 [syserr.errcode.modifiers] Class <tt>error_code</tt> modifiers as indicated: +Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#408">408</a> </p> +<p><i>[ +Batavia (2009-05): +]</i></p> + <blockquote> -<pre>void assign(int val, const error_category<del>&</del><ins>*</ins> cat); -</pre> +We believe this should be revisited +in conjunction with issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#408">408</a>, +which nearly duplicates this issue. +Move to Open. +</blockquote> + + +<p><b>Proposed resolution:</b></p> <p> -<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == cat</tt>. +Change [reverse.iter.con]: </p> + +<blockquote><pre>reverse_iterator(); +</pre> +<blockquote> +-1- <i>Effects:</i> <del>Default</del> <ins>Value</ins> 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>. +</blockquote> +</blockquote> + <p> -<i>Throws:</i> Nothing. +Change 24.5.3.2.1 [move.iter.op.const]: </p> + +<blockquote><pre>move_iterator(); +</pre> +<blockquote> +-1- <i>Effects:</i> Constructs a <tt>move_iterator</tt>, <del>default</del> <ins>value</ins> +initializing <tt>current</tt>. </blockquote> +</blockquote> + + + + + + +<hr> +<h3><a name="1013"></a>1013. Response to UK 305</h3> +<p><b>Section:</b> 25.5.7 [alg.min.max] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#alg.min.max">active issues</a> in [alg.min.max].</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#Tentatively%20Ready">Tentatively Ready</a> status.</p> +<p><b>Discussion:</b></p> + +<p><b>Addresses UK 305</b></p> <p> -Change 19.4.2.4 [syserr.errcode.observers] Class <tt>error_code</tt> observers as indicated: +The negative requirement on <tt>IsSameType</tt> is a hold-over from an earlier +draught with a variadic template form of <tt>min/max</tt> algorith. It is no +longer necessary. </p> +<p><i>[ +Batavia (2009-05): +]</i></p> + <blockquote> -<pre>const error_category<del>&</del><ins>*</ins> category() const; -</pre> +We agree with the proposed resolution. +Move to Tentatively Ready. +</blockquote> + +<p><b>Proposed resolution:</b></p> <p> -<i>Returns:</i> <tt>cat_</tt>. +Change 25 [algorithms]: </p> + +<blockquote><pre>template<class T, StrictWeakOrder<auto, T> Compare> + <del>requires !SameType<T, Compare> && CopyConstructible<Compare></del> + const T& min(const T& a, const T& b, Compare comp); +... +template<class T, StrictWeakOrder<auto, T> Compare> + <del>requires !SameType<T, Compare> && CopyConstructible<Compare></del> + const T& max(const T& a, const T& b, Compare comp); +... +template<class T, StrictWeakOrder<auto, T> Compare> + <del>requires !SameType<T, Compare> && CopyConstructible<Compare></del> + pair<const T&, const T&> minmax(const T& a, const T& b, Compare comp); +</pre></blockquote> + <p> -<i>Throws:</i> Nothing. +Change 25.5.7 [alg.min.max], p1, p9 and p17: </p> + +<blockquote><pre>template<class T, StrictWeakOrder<auto, T> Compare> + <del>requires !SameType<T, Compare> && CopyConstructible<Compare></del> + const T& min(const T& a, const T& b, Compare comp); +... +template<class T, StrictWeakOrder<auto, T> Compare> + <del>requires !SameType<T, Compare> && CopyConstructible<Compare></del> + const T& max(const T& a, const T& b, Compare comp); +... +template<class T, StrictWeakOrder<auto, T> Compare> + <del>requires !SameType<T, Compare> && CopyConstructible<Compare></del> + pair<const T&, const T&> minmax(const T& a, const T& b, Compare comp); +</pre></blockquote> + + + + + + +<hr> +<h3><a name="1014"></a>1014. Response to UK 317 and JP 74</h3> +<p><b>Section:</b> 28.9.2 [re.regex.construct] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-05-23</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.regex.construct">issues</a> in [re.regex.construct].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p> +<p><b>Discussion:</b></p> + +<p><b>Addresses UK 317 and JP 74</b></p> + +<p> +UK 317: +</p> + +<blockquote> +<tt>basic_string</tt> has both a constructor and an assignment operator that +accepts an initializer list, <tt>basic_regex</tt> should have the same. </blockquote> <p> -Change 19.4.3.1 [syserr.errcondition.overview] Class <tt>error_condition</tt> overview as indicated: +JP 74: </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); +<tt>basic_regx & operator= (initializer_list<T>);</tt> is not defined. +</blockquote> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +UK 317 asks for both assignment and constructor, +but the requested constructor is already present in the current Working Paper. +We agree with the proposed resolution. +Move to Tentatively Ready. +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +Change 28.9 [re.regex]: +</p> + +<blockquote><pre>template <class charT, + class traits = regex_traits<charT> > +class basic_regex { ... - const error_category<del>&</del><ins>*</ins> category() const; + basic_regex& operator=(const charT* ptr); + <ins>basic_regex& operator=(initializer_list<charT> il);</ins> + template <class ST, class SA> + basic_regex& operator=(const basic_string<charT, ST, SA>& p); ... -private: - int val_; // exposition only - const error_category<del>&</del><ins>*</ins> cat_; // exposition only -</pre> -</blockquote> +}; +</pre></blockquote> <p> -Change 19.4.3.2 [syserr.errcondition.constructors] Class <tt>error_condition</tt> constructors as indicated: +Add in 28.9.2 [re.regex.construct]: </p> <blockquote> -<pre><ins>constexpr</ins> error_condition(int val, const error_category<del>&</del><ins>*</ins> cat); +<blockquote> +-20- ... +</blockquote> +<pre>basic_regex& operator=(initializer_list<charT> il); </pre> +<blockquote> +-21- <i>Effects:</i> returns <tt>assign(il.begin(), il.end());</tt> +</blockquote> +</blockquote> + + + + + + +<hr> +<h3><a name="1015"></a>1015. Response to UK 199</h3> +<p><b>Section:</b> 20.2.1 [concept.transform] <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>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#concept.transform">active issues</a> in [concept.transform].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#concept.transform">issues</a> in [concept.transform].</p> +<p><b>View all 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><b>Addresses UK 199</b></p> + <p> -<i>Effects:</i> Constructs an object of type <tt>error_condition</tt>. +The requirement that programs do not supply <tt>concept_maps</tt> should +probably be users do not supply their own <tt>concept_map</tt> +specializations. The program will almost certainly supply +<tt>concept_maps</tt> - the standard itself supplies a specialization +for <tt>RvalueOf</tt> references. Note that the term <i>program</i> is +defined in 3.5 [basic.link]p1 and makes no account of the +standard library being treated differently to user written code. </p> + +<p><i>[ +2009-05-09 Alisdair adds: +]</i></p> + + +<blockquote> <p> -<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == cat</tt>. +The same problem is present in the words added for the +<tt>LvalueReference/RvalueReference</tt> concepts last meeting. </p> <p> -<i>Throws:</i> Nothing. +With three subsections requiring the same constraint, I'm wondering if there +is a better way to organise this section. +Possible 20.2.1 -> 20.2.3 belong in the fundamental concepts clause in +14.10.4 [concept.support]? While they can be implemented purely as a +library feature without additional compiler support, they are pretty +fundamental and we want the same restriction on user-concept maps as is +mandated there. </p> </blockquote> +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +We agree with the issue, +but believe the wording needs further improvement. +We want to investigate current definitions for nomenclature such as +"user" and "program." +Move to Open pending the recommended investigation. +</blockquote> + + +<p><b>Proposed resolution:</b></p> <p> -Change 19.4.3.3 [syserr.errcondition.modifiers] Class <tt>error_condition</tt> modifiers as indicated: +Change 20.2.1 [concept.transform] p2: </p> <blockquote> -<pre>void assign(int val, const error_category<del>&</del><ins>*</ins> cat); -</pre> +-2- A <del>program</del> <ins>user</ins> shall not provide concept maps for +any concept in 20.1.1. +</blockquote> + <p> -<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == cat</tt>. +Change 20.2.2 [concept.true] p2: </p> + +<blockquote> +-2- <i>Requires:</i> a <del>program</del> <ins>user</ins> shall not +provide a concept map for the <tt>True</tt> concept. +</blockquote> + <p> -<i>Throws:</i> Nothing. +Change 20.2.3 [concept.classify] p2: </p> + +<blockquote> +-2- <i>Requires:</i> a <del>program</del><ins>user</ins> shall not provide concept +maps for any concept in this section. </blockquote> + + + + + +<hr> +<h3><a name="1016"></a>1016. Response to JP 33</h3> +<p><b>Section:</b> 20.2.6 [concept.comparison] <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>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-03-12</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#concept.comparison">active issues</a> in [concept.comparison].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#concept.comparison">issues</a> in [concept.comparison].</p> +<p><b>View all 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><b>Addresses JP 33</b></p> + <p> -Change 19.4.3.4 [syserr.errcondition.observers] Class <tt>error_condition</tt> observers as indicated: +<tt>LessThanComparable</tt> and <tt>EqualityComparable</tt> don't correspond to NaN. </p> +<p><b>Original proposed resolution:</b></p> + +<p> +Apply <tt>concept_map</tt> to these concepts at <tt>FloatingPointType</tt>. +</p> + +<p><i>[ +Post Summit, Alisdair adds: +]</i></p> + + <blockquote> -<pre>const error_category<del>&</del><ins>*</ins> category() const; -</pre> <p> -<i>Returns:</i> <tt>cat_</tt>. +I don't understand the proposed resolution - there is no such thing as a +'negative' concept_map, and these concepts are auto concepts that match +float/double etc. Also not clear how we are supposed to match values to +concepts. </p> <p> -<i>Throws:</i> Nothing. +Recommend NAD and treat as a subset of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#902">902</a>. </p> </blockquote> + + +<p><b>Proposed resolution:</b></p> <p> -Throughout 19.4 [syserr] System error support, change "<tt>category().</tt>" to "<tt>category()-></tt>". -Appears approximately six times. +Recommend NAD. </p> + + + + +<hr> +<h3><a name="1017"></a>1017. Response to US 66</h3> +<p><b>Section:</b> 20.2.11 [concept.regular] <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>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-03-12</p> +<p><b>View all 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><b>Addresses US 66</b></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>". +Application of the <tt>Regular</tt> concept to floating-point types appears to be +controversial (see long discussion on std-lib reflector). </p> +<p><b>Original proposed resolution:</b></p> + <p> -Change 19.4.5.1 [syserr.syserr.overview] Class system_error overview as indicated: +State that the <tt>Regular</tt> concept does not apply to floating-point types. </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><i>[ +Summit: +]</i></p> + +<blockquote> <p> -Change 19.4.5.2 [syserr.syserr.members] Class system_error members as indicated: +Recommend that we handle the same as JP 33 / <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1016">1016</a>. </p> +</blockquote> + +<p><i>[ +Post Summit, Alisdair adds: +]</i></p> + <blockquote> -<pre>system_error(int ev, const error_category<del>&</del><ins>*</ins> ecat, const string& what_arg); -</pre> +<p> +Recommend Open, and review after resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#902">902</a> and revised axiom +feature. +</p> +</blockquote> + + + +<p><b>Proposed resolution:</b></p> + + + + + +<hr> +<h3><a name="1018"></a>1018. Response to US 70</h3> +<p><b>Section:</b> 20.6 [meta] <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>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-03-12</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta">active issues</a> in [meta].</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><b>Addresses US 70</b></p> + +<p> +Specifications now expressed via narrative text are more accurately and +clearly expressed via executable code. +</p> +<p> +Wherever concepts are available that directly match this section's type +traits, express the traits in terms of the concepts instead of via +narrative text. Where the type traits do not quite match the +corresponding concepts, bring the two into alignment so as to avoid two +nearly-identical notions. +</p> + +<p><i>[ +Summit: +]</i></p> + + <blockquote> <p> -<i>Effects:</i> Constructs an object of class <tt>system_error</tt>. +We think that this is a good idea, but it requires a lot of work. If someone +submits a paper proposing specific changes, we would be happy to review it +at the next meeting. </p> +</blockquote> + + + +<p><b>Proposed resolution:</b></p> + + + + + +<hr> +<h3><a name="1019"></a>1019. Response to UK 205</h3> +<p><b>Section:</b> 20.6.3 [meta.help] <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>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta.help">active issues</a> in [meta.help].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.help">issues</a> in [meta.help].</p> +<p><b>View all 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><b>Addresses UK 205</b></p> + <p> -<i>Postconditions:</i> <tt>code() == error_code(ev, ecat)</tt> and -<tt>strcmp(runtime_error::what(), what_arg.c_str()) == 0</tt>. +<tt>integral_constant</tt> objects should be usable in integral-constant-expressions. +The addition to the language of literal types and the enhanced rules for +constant expressions make this possible. </p> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +We agree that the <tt>static</tt> data member +ought be declared <tt>constexpr</tt>, +but do not see a need for the proposed <tt>operator value_type()</tt>. +(A use case would be helpful.) +Move to Open. </blockquote> -<pre>system_error(int ev, const error_category<del>&</del><ins>*</ins> ecat); -</pre> +<p><i>[ +2009-05-23 Alisdair adds: +]</i></p> + + <blockquote> <p> -<i>Effects:</i> Constructs an object of class <tt>system_error</tt>. +The motivating case in my mind is that we can then use +<tt>true_type</tt> and <tt>false_type</tt> as integral Boolean expressions, for example inside +a <tt>static_assert</tt> declaration. In that sense it is purely a matter of style. </p> <p> -<i>Postconditions:</i> <tt>code() == error_code(ev, ecat)</tt> and -<tt>strcmp(runtime_error::what(), "") == 0</tt>. +Note that Boost has applied the non-explicit conversion operator for many +years as it has valuable properties for extension into other metaprogramming +libraries, such as MPL. If additional rationale is desired I will poll the +Boost lists for why this extension was originally applied. I would argue +that explicit conversion is more appropriate for 0x though. </p> </blockquote> -</blockquote> +<p><b>Proposed resolution:</b></p> +<p> +Add to the <tt>integral_constant</tt> struct definition in 20.6.3 [meta.help]: +</p> + +<blockquote><pre>template <class T, T v> +struct integral_constant { + static const<ins>expr</ins> T value = v; + typedef T value_type; + typedef integral_constant<T,v> type; + <ins>constexpr operator value_type() { return value; }</ins> +}; +</pre></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> +<h3><a name="1020"></a>1020. Response to UK 204</h3> +<p><b>Section:</b> 20.6.7 [meta.trans.other] <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>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-03-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#Open">Open</a> status.</p> <p><b>Discussion:</b></p> + +<p><b>Addresses UK 204</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. +It is not possible to create a variant union based on a parameter pack +expansion, e.g. to implement a classic discriminated union template. +</p> + +<p><b>Original proposed resolutuion:</b></p> + +<p> +Restore <tt>aligned_union</tt> template that was removed by LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#856">856</a>. </p> +<p><i>[ +Summit: +]</i></p> + + +<blockquote> +Agree. The need for <tt>aligned_union</tt> is compelling enough to reinstate. +</blockquote> + +<p><i>[ +Post Summit, Alisdair adds: +]</i></p> + + +<blockquote> +paper +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2843.html">N2843</a> +proposes an extension to the <tt>[[align]]</tt> attribute +that further diminishes the need for this template. Recommend NAD. +</blockquote> + + <p><b>Proposed resolution:</b></p> @@ -15771,634 +28058,881 @@ ensure it reflects LWG consensus. <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> +<h3><a name="1021"></a>1021. Response to UK 211</h3> +<p><b>Section:</b> 20.8.12.2.3 [unique.ptr.single.asgn] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-05-23</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p> <p><b>Discussion:</b></p> + +<p><b>Addresses UK 211</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>). +The <tt>nullptr_t</tt> type was introduced to resolve the null pointer literal +problem. It should be used for the assignemnt operator, as with the +constructor and elsewhere through the library. </p> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +We agree with the proposed resolution. +Move to Tentatively Ready. +</blockquote> + + +<p><b>Proposed resolution:</b></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>: +Change the synopsis in 20.8.12.2 [unique.ptr.single]: </p> -<ol> -<li>Operational fail-safety.</li> -<li>(Well-)Definedness of expressions.</li> -</ol> +<blockquote><pre>unique_ptr& operator=(<del><i>unspecified-pointer-type</i></del> <ins>nullptr_t</ins>); +</pre></blockquote> <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>). +Change 20.8.12.2.3 [unique.ptr.single.asgn]: +</p> + +<blockquote><pre>unique_ptr& operator=(<del><i>unspecified-pointer-type</i></del> <ins>nullptr_t</ins>); +</pre> +<blockquote> +<del>Assigns from the literal 0 or <tt>NULL</tt>. [<i>Note:</i> The +<i>unspecified-pointer-type</i> is often implemented as a pointer to a +private data member, avoiding many of the implicit conversion pitfalls. +<i>-- end note</i>]</del> +</blockquote> +</blockquote> + + + + + +<hr> +<h3><a name="1023"></a>1023. Response to DE 22</h3> +<p><b>Section:</b> 20.7.16.2 [func.wrap.func] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Tentatively NAD Editorial</a> + <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#func.wrap.func">active issues</a> in [func.wrap.func].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.wrap.func">issues</a> in [func.wrap.func].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD%20Editorial">Tentatively NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> + +<p><b>Addresses DE 22</b></p> + +<p>Related to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1114">1114</a>.</p> + +<p> +The conditions for deriving from <tt>std::unary_function</tt> and +<tt>std::binary_function</tt> are unclear: The condition would also be satisfied if +<tt>ArgTypes</tt> were <tt>std::vector<T1></tt>, because it (arguably) +"contains" <tt>T1</tt>. </p> <p><i>[ -Sophia Antipolis: +Summit: ]</i></p> <blockquote> +Agree. <tt>std::reference_wrapper</tt> has the same structure, and we +suggest that <tt>std::function</tt> be presented in the same way as +<tt>std::reference_wrapper</tt>. +</blockquote> + +<p><i>[ +2009-05-09 Alisdair adds: +]</i></p> + + +<blockquote> +Phrasing should be "publicly and +unambiguously derived from" and probably back in reference_wrapper too. Updated +wording supplied. +</blockquote> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +We agree with the proposed wording. +Move to NAD Editorial. +</blockquote> + + +<p><b>Proposed resolution:</b></p> <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>. +(no changes to <tt><functional></tt> synopsis required) </p> + <p> -Howard will go through and enumerate the individual requirements wrt. <tt>pointer</tt> for each member function. +Change synopsis in Class template function 20.7.16.2 [func.wrap.func]: </p> -</blockquote> - +<blockquote><pre>template<Returnable R, CopyConstructible... ArgTypes> +class function<R(ArgTypes...)> + : public unary_function<T1, R> // <del><i>iff</i> sizeof...(ArgTypes) == 1 <i>and</i></del> <ins><i>see below</i></ins> + <del>// ArgTypes <i>contains</i> T1</del> + : public binary_function<T1, T2, R> // <del><i>iff</i> sizeof...(ArgTypes) == 2 <i>and</i></del> <ins><i>see below</i></ins> + <del>// ArgTypes <i>contains</i> T1 <i>and</i> T2</del> +{ + ... +</pre></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: +Add new p1/p2 before 20.7.16.2.1 [func.wrap.func.con]: </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. +<p><ins> +The template instantiation <tt>function<R(T1)></tt> shall be publicly and +unambiguously derived from +<tt>std::unary_function<T1,R></tt> if and only if the template type parameter +is a function type taking one argument of type <tt>T1</tt> and returning <tt>R</tt>. +</ins></p> + +<p><ins> +The template instantiation <tt>function<R(T1,T2)></tt> shall be publicly and +unambiguously derived from +<tt>std::binary_function<T1,T2,R></tt> if and only if the template type +parameter is a function type taking two arguments of type <tt>T1</tt> and <tt>T2</tt> and +returning <tt>R</tt>. +</ins></p> + +<pre>explicit function(); +</pre> </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> +<h3><a name="1024"></a>1024. Response to JP 39</h3> +<p><b>Section:</b> 20.7.16.2 [func.wrap.func] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#func.wrap.func">active issues</a> in [func.wrap.func].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.wrap.func">issues</a> in [func.wrap.func].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</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><b>Addresses JP 39</b></p> - </p> - <p> +<p> +There are no requires corresponding to <tt>F</tt> of <tt>std::function</tt>. +</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><i>[ +2009-05-01 Daniel adds: +]</i></p> - </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> +<blockquote> +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1070">1070</a> removes the second constructor. +</blockquote> - </p> - <blockquote> - <pre>#include <iostream> +<p><i>[ +Batavia (2009-05): +]</i></p> -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> +<blockquote> +We agree with the proposed resolution. +Move to Tentatively Ready. +If issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1070">1070</a> is accepted, +the changes to the second constructor +in this issue are moot. +</blockquote> -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> +<p><b>Proposed resolution:</b></p> +<p> +Correct as follows in 20.7.16.2 [func.wrap.func] (class definition) +</p> -Add a <i>Requires</i> clause to 27.4.4.2 [basic.ios.members] withethe following -text: +<blockquote><pre> template<class F, Allocator Alloc> + <ins>requires ConstructibleWithAllocator<F, Alloc> + && call=Callable<F, ArgTypes...> + && Convertible<call::result_type, R></ins> + function(allocator_arg_t, const Alloc&, F); + template<class F, Allocator Alloc> + <ins>requires ConstructibleWithAllocator<F,Alloc> + && call=Callable<F, ArgTypes...> + && Convertible<call::result_type, R></ins> + function(allocator_arg_t, const Alloc&, F&&); +</pre></blockquote> - </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>. +<hr> +<h3><a name="1026"></a>1026. Response to UK 209</h3> +<p><b>Section:</b> 20.8 [memory] <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>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-03-12</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#memory">active issues</a> in [memory].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#memory">issues</a> in [memory].</p> +<p><b>View all 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> - </blockquote> - +<p><b>Addresses UK 209</b></p> +<p> +Smart pointers cannot be used in constrained templates. +</p> +<p><i>[ +Summit: +]</i></p> -<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: +<blockquote> +We look forward to a paper on this topic. We recommend no action until a +paper is available. We understand that a paper is forthcoming. +</blockquote> - </p> - <blockquote> +<p><i>[ +Peter Dimov adds: +]</i></p> -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> +<blockquote> +<tt>shared_ptr<T></tt> and <tt>weak_ptr<T></tt> support all +types <tt>T</tt> for which <tt>T*</tt> is valid. In other words, a +possible (partial) resolution is to change class <tt>T</tt> to +<tt>PointeeType T</tt> for <tt>shared_ptr</tt>, <tt>weak_ptr</tt> and +possibly <tt>enable_shared_from_this</tt>. +</blockquote> -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 +<p><b>Proposed resolution:</b></p> - </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> +<hr> +<h3><a name="1027"></a>1027. Response to UK 213</h3> +<p><b>Section:</b> 20.8.6 [default.allocator] <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>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-03-13</p> +<p><b>View all 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> -where either <code>money_base::space</code> or <code>money_base::none</code> appears in the format, white space is optional. +<p><b>Addresses UK 213</b></p> - </blockquote> - +<p> +<tt>std::allocator</tt> should be constrained to simplify its use on constrained +contexts. This library component models allocation from free store via the +new operator so choose constraints to +match. The Allocator concept allows for a wider variety of allocators that +users may choose to supply if their allocation model does not require +operator new, without impacting the +requirements of this template. +</p> - <p><b>Proposed resolution:</b></p> - <p> +<p> +Suggested direction: +</p> +<p> +The primary allocator template should be constrained to require +<tt>ObjectType<T></tt> and <tt>FreeStoreAllocatable<T></tt>. +Further operations to be constrained as required. +</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><i>[ +Summit: +]</i></p> - </p> - <blockquote> +<blockquote> +Agree as stated. A future paper will address additional related issues. +</blockquote> + + + +<p><b>Proposed resolution:</b></p> -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> +<h3><a name="1028"></a>1028. Response to UK 214</h3> +<p><b>Section:</b> 20.8.8 [storage.iterator] <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>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-03-15</p> +<p><b>View all 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 <code>basic_ios::copyfmt()</code> member function is specified in 27.4.4.2 [basic.ios.members] to have the following effects: +<p><b>Addresses UK 214</b></p> - </p> - <blockquote> +<p> +<tt>raw_storage_iterator</tt> needs constraining as an iterator adaptor to be safely +used in constrained templates +</p> -<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 +<p><i>[ +Summit: +]</i></p> - <ul> - <li> -<code>rdstate()</code> and <code>rdbuf()</code> are left unchanged; +<blockquote> +We look forward to a paper on this topic. We recommend no action until a +paper is available. +</blockquote> - </li> - <li> +<p><i>[ +Post Summit Alisdair provided wording and rationale. +]</i></p> -<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> +<p><b>Proposed resolution:</b></p> +<p> +20.8 [memory] p2 +</p> +<p> +Update the synopsis for <tt><memory></tt> +</p> +<blockquote><pre>// 20.7.8, raw storage iterator: +template <<del>class</del> <ins>ForwardIterator</ins> Out<del>put</del>Iter<del>ator</del>, <del>class</del> <ins>ObjectType</ins> T> + <ins>requires OutputIterator< OutIter, T ></ins> + class raw_storage_iterator; -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. +<ins>template <ForwardIterator OutIter, ObjectType T> + requires OutputIterator< OutIter, T > + concept_map Iterator<raw_storage_iterator< OutIter, T > > { }</ins> +</pre></blockquote> - </p> - - <p><b>Proposed resolution:</b></p> - <p> +<p> +20.8.8 [storage.iterator] p1 +</p> +<p> +Replace class template definition with: +</p> +<blockquote><pre>namespace std { + template <<del>class</del> <ins>ForwardIterator</ins> Out<del>put</del>Iter<del>ator</del>, <del>class</del> <ins>ObjectType</ins> T> + <ins>requires OutputIterator< OutIter, T ></ins> + class raw_storage_iterator + : public iterator<output_iterator_tag,void,void,void,void> { + public: + explicit raw_storage_iterator(Out<del>put</del>Iter<del>ator</del> x); -I propose to tighten things up by adding a <i>Postcondition</i> clause -to the function like so: + raw_storage_iterator<del><OutputIterator,T></del>& operator*(); + raw_storage_iterator<del><OutputIterator,T></del>& operator=(const T& element); + raw_storage_iterator<del><OutputIterator,T></del>& operator++(); + raw_storage_iterator<del><OutputIterator,T></del> operator++(int); + }; - </p> - <blockquote> - <i>Postconditions:</i> + <ins>template <ForwardIterator OutIter, ObjectType T> + requires OutputIterator< OutIter, T > + concept_map Iterator<raw_storage_iterator< OutIter, T > > { }</ins> +} +</pre></blockquote> - <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><b>Rationale:</b></p> +<p> +<tt>raw_storage_iterator</tt> has to adapt a <tt>ForwardIterator</tt>, +rather than just an <tt>InputIterator</tt> for two reasons: +</p> + +<ol type="i"> +<li> +The initial iterator passed by value is expected to remain valid, +pointing to the initialized region of memory. +</li> +<li> +to avoid breaking the declaration of post-increment operator which would +require some kind of proxy formulation to support generalised InputIterators. +</li> +</ol> - </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> +<h3><a name="1029"></a>1029. Response to UK 210</h3> +<p><b>Section:</b> 20.8.11 [specialized.algorithms] <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>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-03-15</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#specialized.algorithms">issues</a> in [specialized.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> -From message c++std-lib-20003... +<p><b>Addresses UK 210</b></p> - </p> - <p> +<p>Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#582">582</a></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> +Specialized algorithms for memory managenment need requirements to be +easily usable in constrained templates. +</p> - </p> - <blockquote> +<p><i>[ +Summit: +]</i></p> -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> +<blockquote> +We look forward to a paper on this topic. We recommend no action until a +paper is available. +</blockquote> -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><i>[ +Post Summit Alisdair provided wording. +]</i></p> - </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><i>[ +Post Summit: +]</i></p> - </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. +<blockquote> +<p> +Daniel adds: +</p> - </p> - <p> +<blockquote> +<ol> +<li> +I suggest <tt>Size</tt> should require <tt>IntegralLike</tt> and not <tt>UnsignedIntegralLike</tt>, +because otherwise simple int-literals could not be provided as arguments +and it would conflict with other algorithms that only require <tt>IntegralLike</tt>. +</li> +<li> +<p> +The current for-loop-test relies on evaluation in boolean context which is +not provided by <tt>ArithmeticLike</tt> and it's refinements. I propose to change the +corresponding for-loop-headers to: +</p> +<ol type="a"> +<li> +for <tt>uninitialized_copy_n</tt>: <tt>for ( ; n > Size(0); ++result, ++first, --n) {</tt> +</li> +<li> +for <tt>uninitialized_fill_n</tt>: <tt>for (; n > Size(0); ++first, --n) {</tt> +</li> +</ol> +</li> +</ol> +</blockquote> -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> +Alisdair adds: +</p> +<blockquote> +For the record I agree with Daniel's suggestion. +</blockquote> - </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> +</blockquote> -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> +<p><b>Proposed resolution:</b></p> +<p> +20.8 [memory] p2 +</p> +<p> +Update the synopsis for <tt><memory></tt> +</p> +<blockquote><pre>template <<del>class</del> InputIterator <ins>InIter</ins>, + <del>class ForwardIterator</del> <ins>OutputIterator<auto, InIter::reference> OutIter</ins>> + <ins>requires ForwardIterator<OutIter></ins> + <del>ForwardIterator</del> <ins>OutIter</ins> + uninitialized_copy(<del>InputIterator</del> <ins>InIter</ins> first, <del>InputIterator</del> <ins>InIter</ins> last, + <del>ForwardIterator</del> <ins>OutIter</ins> result); -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. +template <<del>class</del> InputIterator <ins>InIter</ins>, + <del>class</del> <ins>IntegralLike</ins> Size, + <del>class ForwardIterator</del> <ins>OutputIterator<auto, InIter::reference> OutIter</ins>> + <ins>requires ForwardIterator<OutIter></ins> + <del>ForwardIterator</del> <ins>OutIter</ins> + uninitialized_copy_n(<del>InputIterator</del> <ins>InIter</ins> first, Size n, + <del>ForwardIterator</del> <ins>OutIter</ins> result); - </p> - <p> +template <<del>class</del> ForwardIterator <ins>Iter</ins>, <del>class</del> <ins>ObjectType</ins> T> + <ins>requires Constructible< Iter::value_type, const T& ></ins> + void uninitialized_fill(<del>ForwardIterator</del> <ins>Iter</ins> first, <del>ForwardIterator</del> <ins>Iter</ins> last, + const T& x); -To this end we propose to change 24.5.1 [istream.iterator], p1, -as follows: +template <<del>class</del> ForwardIterator <ins>Iter</ins>, <del>class</del> <ins>IntegralLike</ins> Size, <del>class</del> <ins>ObjectType</ins> T> + <ins>requires Constructible< Iter::value_type, const T& ></ins> + void + uninitialized_fill_n(<del>ForwardIterator</del> <ins>Iter</ins> first, Size n, const T& x); +</pre></blockquote> - </p> - <blockquote> +<p> +Update as follows: +</p> -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... +<p> +uninitialized_copy 20.8.11.2 [uninitialized.copy] +</p> - </blockquote> - <p> +<blockquote><pre>template <<del>class</del> InputIterator <ins>InIter</ins>, + <del>class ForwardIterator</del> <ins>OutputIterator<auto, InIter::reference> OutIter</ins>> + <ins>requires ForwardIterator<OutIter></ins> + <del>ForwardIterator</del> <ins>OutIter</ins> + uninitialized_copy(<del>InputIterator</del> <ins>InIter</ins> first, <del>InputIterator</del> <ins>InIter</ins> last, + <del>ForwardIterator</del> <ins>OutIter</ins> result); +</pre> -Add pre/postconditions to the member function descriptions of <code>istream_iterator</code> like so: +<blockquote> +<p> +-1- <i>Effects:</i> +</p> +<blockquote><pre>for (; first != last; ++result, ++first) { + new (static_cast<void*>(&*result)) + <del>typename iterator_traits<ForwardIterator></del> <ins>OutIter</ins>::value_type(*first); +} +</pre></blockquote> - </p> - <blockquote> +<p> +-2- <i>Returns:</i> <tt>result</tt> +</p> -<pre>istream_iterator();</pre> +</blockquote> -<i>Effects</i>: Constructs the <i>end-of-stream</i> iterator.<br> -<ins><i>Postcondition</i>: <code>in_stream == 0</code>.</ins> +<pre>template <<del>class</del> InputIterator <ins>InIter</ins>, + <del>class</del> <ins>IntegralLike</ins> Size, + <del>class ForwardIterator</del> <ins>OutputIterator<auto, InIter::reference> OutIter</ins>> + <ins>requires ForwardIterator<OutIter></ins> + <del>ForwardIterator</del> <ins>OutIter</ins> + uninitialized_copy_n(<del>InputIterator</del> <ins>InIter</ins> first, Size n, + <del>ForwardIterator</del> <ins>OutIter</ins> result); +</pre> -<pre>istream_iterator(istream_type &s);</pre> +<blockquote> +<p> +-3- Effects: +</p> +<blockquote><pre>for ( ; n > <ins>Size(</ins>0<ins>)</ins>; ++result, ++first, --n) { + new (static_cast<void*>(&*result)) + <del>typename iterator_traits<ForwardIterator></del> <ins>OutIter</ins>::value_type(*first); +} +</pre></blockquote> +<p> +-4- <i>Returns:</i> result +</p> +</blockquote> -<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> +</blockquote> -<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> +<p> +uninitialized_fill 20.8.11.3 [uninitialized.fill] +</p> -<pre>istream_iterator& operator++();</pre> +<blockquote><pre>template <<del>class</del> ForwardIterator <ins>Iter</ins>, <del>class</del> <ins>ObjectType</ins> T> + <ins>requires Constructible< Iter::value_type, const T& ></ins> + void uninitialized_fill(<del>ForwardIterator</del> <ins>Iter</ins> first, <del>ForwardIterator</del> <ins>Iter</ins> last, + const T& x); +</pre> + +<blockquote> +<p> +-1- <i>Effects:</i> +</p> +<blockquote><pre>for (; first != last; ++first) { + new ( static_cast<void*>( &*first) ) + <del>typename iterator_traits<ForwardIterator></del> <ins>Iter</ins>::value_type(x); +} +</pre></blockquote> +</blockquote> +</blockquote> + + +<p> +uninitialized_fill_n 20.8.11.4 [uninitialized.fill.n] +</p> + +<blockquote><pre>template <<del>class</del> ForwardIterator <ins>Iter</ins>, <del>class</del> <ins>IntegralLike</ins> Size, <del>class</del> <ins>ObjectType</ins> T> + <ins>requires Constructible< Iter::value_type, const T& ></ins> + void + uninitialized_fill_n(<del>ForwardIterator</del> <ins>Iter</ins> first, Size n, const T& x); +</pre> + +<blockquote> +<p> +-1- <i>Effects:</i> +</p> +<blockquote><pre>for (; n<del>--</del> <ins>> Size(0)</ins>; ++first<ins>, --n</ins>) { + new ( static_cast<void*>( &*first) ) + <del>typename iterator_traits<ForwardIterator></del> <ins>Iter</ins>::value_type(x); +} +</pre></blockquote> +</blockquote> +</blockquote> -<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> +<h3><a name="1030"></a>1030. Response to JP 44</h3> +<p><b>Section:</b> 20.8.13.6 [util.smartptr.shared.atomic] <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>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-03-12</p> <p><b>View all 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><b>Addresses JP 44</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. +The 1st parameter <tt>p</tt> and 2nd parameter <tt>v</tt> is now +<tt>shared_ptr<T>*</tt>. </p> - <p> -<b>Suggested resolution:</b> +It should be <tt>shared_ptr<T>&</tt>, or if these are +<tt>shared_ptr<T>*</tt> then add the "<tt>p</tt> shall not be a +null pointer" at the requires. </p> +<p><i>[ +Summit: +]</i></p> + + +<blockquote> +Agree. All of the functions need a requirement that <tt>p</tt> (or +<tt>v</tt>) is a pointer to a valid object. +</blockquote> + + + +<p><b>Proposed resolution:</b></p> + + + + + +<hr> +<h3><a name="1031"></a>1031. Response to US 78</h3> +<p><b>Section:</b> 20.8.13.2 [util.smartptr.shared] <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>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-03-12</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#Open">Open</a> status.</p> +<p><b>Discussion:</b></p> + +<p><b>Addresses US 78</b></p> + <p> -Add the following signatures to map, set, multimap, multiset, and the unordered associative containers: +There is presently no way to convert directly from a <tt>shared_ptr</tt> to a +<tt>unique_ptr</tt>. Add an interface that performs the conversion. </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><i>[ +Summit: +]</i></p> + + +<blockquote> +We look forward to a paper on this topic. We recommend no action until a +paper is available. We believe that the shared pointer must use the default +deleter for the conversion to succeed. +</blockquote> + +<p><i>[ +Peter Dimov adds: +]</i></p> + + +<blockquote> +This is basically a request for <tt>shared_ptr<>::release</tt> in +disguise, with all the associated problems. Not a good idea. +</blockquote> + + + +<p><b>Proposed resolution:</b></p> + + + + + +<hr> +<h3><a name="1032"></a>1032. Response to JP 45</h3> +<p><b>Section:</b> 20.9 [time] <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>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-03-12</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time">issues</a> in [time].</p> +<p><b>View all 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><b>Addresses JP 45</b></p> <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.) +<tt>Rep</tt>, <tt>Period</tt>, <tt>Clock</tt> and <tt>Duration</tt> +don't correspond to concept. </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); +<blockquote><pre>template <class Rep, class Period = ratio<1>> class duration; +template <class Clock, class Duration = typename Clock::duration> class time_point; </pre></blockquote> +<p> +Make concept for <tt>Rep</tt>, <tt>Period</tt>, <tt>Clock</tt> and <tt>Duration</tt>. +Fix 20.9 [time] and <tt>wait_until</tt> +and <tt>wait_for</tt>'s template parameter at 30 [thread]. +</p> <p><i>[ -Sophia Antipolis: +Summit: ]</i></p> <blockquote> +We agree that this section needs concepts. We look forward to a paper on +this topic. We recommend no action until a paper is available. +</blockquote> + + + +<p><b>Proposed resolution:</b></p> + + + + + +<hr> +<h3><a name="1033"></a>1033. <tt>thread::join()</tt> effects?</h3> +<p><b>Section:</b> 30.3.1.5 [thread.thread.member] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> + <b>Submitter:</b> Alberto Ganesh Barbati <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.thread.member">active issues</a> in [thread.thread.member].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.thread.member">issues</a> in [thread.thread.member].</p> +<p><b>View all 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> -Don't try to <tt>splice "list"</tt> into the other containers, it should be container-type. +While looking at <tt>thread::join()</tt> I think I spotted a couple of +possible defects in the specifications. I could not find a previous +issue or NB comment about that, but I might have missed it. </p> + <p> -<tt>forward_list</tt> already has <tt>splice_after</tt>. +The postconditions clause for <tt>thread::join()</tt> is: </p> + +<blockquote> +<i>Postconditions:</i> If <tt>join()</tt> throws an exception, the value +returned by <tt>get_id()</tt> is unchanged. Otherwise, <tt>get_id() == id()</tt>. +</blockquote> + <p> -Would "<tt>splice</tt>" make sense for an <tt>unordered_map</tt>? +and the throws clause is: </p> + +<blockquote> +<i>Throws:</i> <tt>std::system_error</tt> when the postconditions cannot be achieved. +</blockquote> + <p> -Jens, Robert: "<tt>splice</tt>" is not the right term, it implies maintaining ordering in <tt>list</tt>s. +Now... how could the postconditions <em>not</em> be achieved? +It's just a matter of resetting the value of <tt>get_id()</tt> or leave it +unchanged! I bet we can always do that. Moreover, it's a chicken-and-egg +problem: in order to decide whether to throw or not I depend on the +postconditions, but the postconditions are different in the two cases. </p> + <p> -Howard: <tt>adopt</tt>? +I believe the throws clause should be: </p> + +<blockquote> +<i>Throws:</i> <tt>std::system_error</tt> when the effects or postconditions +cannot be achieved. +</blockquote> + <p> -Jens: <tt>absorb</tt>? +as it is in <tt>detach()</tt>, or, even better, as the postcondition is +trivially satisfiable and to remove the circular dependency: </p> + + +<blockquote> +<i>Throws:</i> <tt>std::system_error</tt> if the effects cannot be achieved. +</blockquote> + <p> -Alan: <tt>subsume</tt>? +Problem is that... ehm... <tt>join()</tt> has no "Effects" clause. Is that intentional? </p> + +<p><i>[ +See the thread starting at c++std-lib-23204 for more discussion. +]</i></p> + + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> <p> -Robert: <tt>recycle</tt>? +Pete believes there may be some more general language (in frontmatter) +that can address this and related issues such as <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#962">962</a>. </p> <p> -Howard: <tt>transfer</tt>? (but no direction) +Move to Open. </p> +</blockquote> + + +<p><b>Proposed resolution:</b></p> + + + + + +<hr> +<h3><a name="1034"></a>1034. Response to UK 222</h3> +<p><b>Section:</b> 23.2.1 [container.requirements.general] <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>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-03-12</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements.general">active issues</a> in [container.requirements.general].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements.general">issues</a> in [container.requirements.general].</p> +<p><b>View all 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><b>Addresses UK 222</b></p> + <p> -Jens: <tt>transfer_from</tt>. No. +It is not clear what purpose the Requirement tables serve in the +Containers clause. Are they the definition of a library Container? Or +simply a conventient shorthand to factor common semantics into a single +place, simplifying the description of each subsequent container? This +becomes an issue for 'containers' like <tt>array</tt>, which does not meet the +default-construct-to-empty requirement, or <tt>forward_list</tt> which does not +support the size operation. Are these components no longer containers? +Does that mean the remaining requirements don't apply? Or are these +contradictions that need fixing, despite being a clear design decision? </p> + <p> -Alisdair: Can we give a nothrow guarantee? If your <tt>compare()</tt> and <tt>hash()</tt> doesn't throw, yes. +Recommend: </p> + <p> -Daniel: For <tt>unordered_map</tt>, we can't guarantee nothrow. +Clarify all the tables in 23.2 [container.requirements] are +there as a convenience for documentation, rather than a strict set of +requirements. Containers should be allowed to relax specific +requirements if they call attention to them in their documentation. The +introductory text for <tt>array</tt> should be expanded to mention a +default constructed <tt>array</tt> is not empty, and +<tt>forward_list</tt> introduction should mention it does not provide +the required <tt>size</tt> operation as it cannot be implemented +efficiently. </p> + +<p><i>[ +Summit: +]</i></p> + + +<blockquote> +Agree in principle. </blockquote> @@ -16410,388 +28944,650 @@ Daniel: For <tt>unordered_map</tt>, we can't guarantee nothrow. <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> +<h3><a name="1035"></a>1035. Response to UK 226</h3> +<p><b>Section:</b> 23.2.1 [container.requirements.general] <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>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-05-02</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements.general">active issues</a> in [container.requirements.general].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements.general">issues</a> in [container.requirements.general].</p> +<p><b>View all 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 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><b>Addresses UK 226</b></p> - </p> - <p> +<p> +<tt><array></tt> must be added to this list. In particular it +doesn't satisfy: - no <tt>swap()</tt> function invalidates any +references, pointers, or iterators referring to the elements of the +containers being swapped. and probably doesn't satisfy: - no +<tt>swap()</tt> function throws an exception. +</p> +<p> +If <tt><array></tt> remains a container, this will have to also +reference <tt>array</tt>, which will then have to say which of these +points it satisfies. +</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><i>[ +Summit: +]</i></p> - </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. +<blockquote> +Agree. The proposed resolution is incomplete. Further work required. +</blockquote> - <p> +<p><i>[ +2009-05-01 Daniel adds: +]</i></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> +<blockquote> +Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1099">1099</a> also suggests +adding move constructor to this. +</blockquote> -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><b>Proposed resolution:</b></p> - </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.] +<hr> +<h3><a name="1036"></a>1036. Response to UK 231</h3> +<p><b>Section:</b> 23.2.3 [sequence.reqmts] <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>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-03-12</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#sequence.reqmts">active issues</a> in [sequence.reqmts].</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#Open">Open</a> status.</p> +<p><b>Discussion:</b></p> + +<p><b>Addresses UK 231</b></p> + +<p> +p9-p11 are redundant now that Concepts define what it means to be an +Iterator and guide overload resolution accordingly. +</p> + +<p><i>[ +Summit: +]</i></p> + + +<blockquote> +Agree with issue and change to 23.2.3 [sequence.reqmts]. The +changes required to 21 [strings] will be part of the general +concept support for that clause. +</blockquote> + + + +<p><b>Proposed resolution:</b></p> +<p> +Strike 23.2.3 [sequence.reqmts]p9-11. Make sure <tt>std::basic_string</tt> +has constraints similar to +<tt>std::vector</tt> to meet this old guarantee. +</p> - </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> +<h3><a name="1037"></a>1037. Response to UK 232</h3> +<p><b>Section:</b> 23.2.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#sequence.reqmts">active issues</a> in [sequence.reqmts].</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#Tentatively%20Ready">Tentatively Ready</a> status.</p> <p><b>Discussion:</b></p> + +<p><b>Addresses UK 232</b></p> + <p> -23.1 [container.requirements]/p3 says: +<tt>match_results</tt> may follow the requirements but is not listed a general +purpose library container. </p> +<p> +Remove reference to <tt>match_results</tt> against <tt>a[n]</tt> operation. +</p> + +<p><i>[ +Summit: +]</i></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>] +Agree. <tt>operator[]</tt> is defined elsewhere. </blockquote> +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +We agree with the proposed resolution. +Move to Tentatively Ready. +</blockquote> + + +<p><b>Proposed resolution:</b></p> <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. +In 23.2.3 [sequence.reqmts] Table 84, remove reference to +<tt>match_results</tt> in the row describing the <tt>a[n]</tt> operation. </p> + + + +<hr> +<h3><a name="1038"></a>1038. Response to UK 233</h3> +<p><b>Section:</b> 23.2.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#sequence.reqmts">active issues</a> in [sequence.reqmts].</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#Tentatively%20Ready">Tentatively Ready</a> status.</p> +<p><b>Discussion:</b></p> + +<p><b>Addresses UK 233</b></p> + +<p> +Table 84 is missing references to several new container types. +</p> + +<p><i>[ +Summit: +]</i></p> + + +<blockquote> +Agree. +</blockquote> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +We agree with the proposed resolution. +Move to Tentatively Ready. +</blockquote> + + <p><b>Proposed resolution:</b></p> <p> -Change 23.1 [container.requirements]/p3: +In 23.2.3 [sequence.reqmts] Table 84, Add reference to listed +containers to the following rows: </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>] +<table border="1"> +<caption>Table 84 -- Optional sequence container operations</caption> +<tbody><tr> +<th>Expression</th> +<th>Return type</th> +<th>Operational semantics</th> +<th>Container</th> +</tr> +<tr> +<td><tt>a.front()</tt></td> +<td>...</td> +<td>...</td> +<td><tt>vector, list, deque, basic_string<ins>, array, forward_list</ins></tt></td> +</tr> +<tr> +<td><tt>a.back()</tt></td> +<td>...</td> +<td>...</td> +<td><tt>vector, list, deque, basic_string<ins>, array</ins></tt></td> +</tr> +<tr> +<td><tt>a.emplace_front(args)</tt></td> +<td>...</td> +<td>...</td> +<td><tt>list, deque<ins>, forward_list</ins></tt></td> +</tr> +<tr> +<td><tt>a.push_front(t)</tt></td> +<td>...</td> +<td>...</td> +<td><tt>list, deque<ins>, forward_list</ins></tt></td> +</tr> +<tr> +<td><tt>a.push_front(rv)</tt></td> +<td>...</td> +<td>...</td> +<td><tt>list, deque<ins>, forward_list</ins></tt></td> +</tr> +<tr> +<td><tt>a.pop_front()</tt></td> +<td>...</td> +<td>...</td> +<td><tt>list, deque<ins>, forward_list</ins></tt></td> +</tr> +<tr> +<td><tt>a[n]</tt></td> +<td>...</td> +<td>...</td> +<td><tt>vector, deque, basic_string<ins>, array</ins></tt></td> +</tr> +<tr> +<td><tt>a.at(n)</tt></td> +<td>...</td> +<td>...</td> +<td><tt>vector, deque<ins>, basic_string, array</ins></tt></td> +</tr> +</tbody></table> </blockquote> + + + + +<hr> +<h3><a name="1039"></a>1039. Response to UK 234</h3> +<p><b>Section:</b> 23.2.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#sequence.reqmts">active issues</a> in [sequence.reqmts].</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#Tentatively%20Ready">Tentatively Ready</a> status.</p> +<p><b>Discussion:</b></p> + +<p><b>Addresses UK 234</b></p> + <p> -Change 23.2.7 [vector.bool]/p2: +The reference to <tt>iterator</tt> in semantics for <tt>back</tt> should +also allow for <tt>const_iterator</tt> when called on a const-qualified +container. This would be ugly to specify in the 03 standard, but is +quite easy with the addition of <tt>auto</tt> in this new standard. </p> +<p><i>[ +Summit: +]</i></p> + + +<blockquote> +Agree. +</blockquote> + +<p><i>[ +Batavia (2009-05): +]</i></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>. +We agree with the proposed resolution. +Move to Tentatively Ready. </blockquote> + +<p><b>Proposed resolution:</b></p> <p> -Move 23.3.5 [template.bitset] to clause 20. +In 23.2.3 [sequence.reqmts] Table 84, replace iterator with auto in semantics for back: </p> +<blockquote> +<table border="1"> +<caption>Table 84 -- Optional sequence container operations</caption> +<tbody><tr> +<th>Expression</th> +<th>Return type</th> +<th>Operational semantics</th> +<th>Container</th> +</tr> +<tr> +<td><tt>a.back()</tt></td> +<td><tt>reference; const_reference</tt> for constant <tt>a</tt></td> +<td><tt>{ <del>iterator</del> <ins>auto</ins> tmp = a.end();<br>--tmp;<br>return *tmp; }</tt></td> +<td><tt>vector, list, deque, basic_string</tt></td> +</tr> +</tbody></table> +</blockquote> <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> +<h3><a name="1040"></a>1040. Response to UK 238</h3> +<p><b>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</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#Tentatively%20Ready">Tentatively Ready</a> status.</p> +<p><b>Discussion:</b></p> + +<p><b>Addresses UK 238</b></p> + +<p> +Leaving it unspecified whether or not <tt>iterator</tt> and <tt>const_iterator</tt> are the +same type is dangerous, as user code may or may not violate the One +Definition Rule by providing overloads for +both types. It is probably too late to specify a single behaviour, but +implementors should document what to expect. Observing that problems can be +avoided by users restricting themselves to using <tt>const_iterator</tt>, add a note to that effect. +</p> +<p> +Suggest Change 'unspecified' to 'implementation defined'. +</p> + +<p><i>[ +Summit: +]</i></p> + + +<blockquote> +Agree with issue. Agree with adding the note but not with changing the +normative text. We believe the note provides sufficient guidance. +</blockquote> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +We agree with the proposed resolution. +Move to Tentatively Ready. +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +In 23.2.4 [associative.reqmts] p6, add: +</p> + +<blockquote> +-6- <tt>iterator</tt> of an associative container meets the requirements +of the <tt>BidirectionalIterator</tt> concept. 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. +<ins>[<i>Note:</i> <tt>iterator</tt> and <tt>const_iterator</tt> have identical semantics in +this case, and <tt>iterator</tt> is convertible to <tt>const_iterator</tt>. Users can avoid +violating the One Definition Rule by always using <tt>const_iterator</tt> +in their function parameter lists <i>-- end note</i>]</ins> +</blockquote> + + + + + +<hr> +<h3><a name="1041"></a>1041. Response to UK 239</h3> +<p><b>Section:</b> 23.2.4 [associative.reqmts] <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>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-03-15</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</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#Open">Open</a> status.</p> <p><b>Discussion:</b></p> + +<p><b>Addresses UK 239</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. +It is not possible to take a move-only key out of an unordered +container, such as (<tt>multi</tt>)<tt>set</tt> or +(<tt>multi</tt>)<tt>map</tt>, or the new unordered containers. </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. +Add below <tt>a.erase(q)</tt>, <tt>a.extract(q)</tt>, with the following notation: </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. +<tt>a.extract(q)></tt>, Return type <tt>pair<key, iterator></tt> +Extracts the element pointed to by <tt>q</tt> and erases it from the +<tt>set</tt>. Returns a <tt>pair</tt> containing the value pointed to by +<tt>q</tt> and an <tt>iterator</tt> pointing to the element immediately +following <tt>q</tt> prior to the element being erased. If no such +element exists,returns <tt>a.end()</tt>. </p> + +<p><i>[ +Summit: +]</i></p> + + +<blockquote> +We look forward to a paper on this topic. We recommend no action until a +paper is available. The paper would need to address exception safety. +</blockquote> + +<p><i>[ +Post Summit Alisdair adds: +]</i></p> + + +<blockquote> +Would <tt>value_type</tt> be a better return type than <tt>key_type</tt>? +</blockquote> + + + +<p><b>Proposed resolution:</b></p> <p> -The semantics of assignment are effectively obtained by use of the -default destructor and default copy assignment operator via +In 23.2.4 [associative.reqmts] Table 85, add: </p> -<blockquote><pre>x.~reference_closure(); new (x) reference_closure(y); -</pre></blockquote> +<blockquote> +<table border="1"> +<caption>Table 85 -- Associative container requirements (in addition to container)</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.erase(q)</tt></td> +<td>...</td> +<td>...</td> +<td>...</td> +</tr><tr> +<td><ins><tt>a.extract(q)</tt></ins></td> +<td><ins><tt>pair<key_type, iterator></tt></ins></td> +<td><ins>Extracts the element pointed to by <tt>q</tt> and erases it from the <tt>set</tt>. +Returns a <tt>pair</tt> containing the value pointed to by <tt>q</tt> and an <tt>iterator</tt> +pointing to the element immediately following <tt>q</tt> prior to the element being +erased. If no such element +exists, returns <tt>a.end()</tt>.</ins></td> +<td><ins>amortized constant</ins></td> +</tr> +</tbody></table> +</blockquote> <p> -So the copy assignment operator generates no significant real burden -to the implementation. +In 23.2.5 [unord.req] Table 87, add: </p> +<blockquote> +<table border="1"> +<caption>Table 87 -- Unordered associative container requirements (in addition to container)</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.erase(q)</tt></td> +<td>...</td> +<td>...</td> +<td>...</td> +</tr><tr> +<td><ins><tt>a.extract(q)</tt></ins></td> +<td><ins><tt>pair<key_type, iterator></tt></ins></td> +<td><ins>Extracts the element pointed to by <tt>q</tt> and erases it from the <tt>set</tt>. +Returns a <tt>pair</tt> containing the value pointed to by <tt>q</tt> and an <tt>iterator</tt> +pointing to the element immediately following <tt>q</tt> prior to the element being +erased. If no such element +exists, returns <tt>a.end()</tt>.</ins></td> +<td><ins>amortized constant</ins></td> +</tr> +</tbody></table> +</blockquote> + + + + + +<hr> +<h3><a name="1042"></a>1042. Response to UK 244</h3> +<p><b>Section:</b> 23.3 [sequences] <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>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-03-14</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequences">issues</a> in [sequences].</p> +<p><b>View all 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><b>Addresses UK 244</b></p> + +<p> +The validity of the expression <tt>&a[n] == &a[0] + n</tt> is contingent on +<tt>operator&</tt> doing the "right thing" (as captured by the <tt>CopyConstructible</tt> +requirements in table 30 in C++2003). However this constraint has been +lost in the Concepts of C++0x. This applies to <tt>vector</tt> and <tt>array</tt> (it +actually applies to <tt>string</tt> also, but that's a different chapter, so I'll +file a separate comment there and cross-reference). +</p> + +<p> +Suggested solution: +</p> + +<p> +Define a <tt>ContiguousStrorage</tt> and apply it to +<tt>vector</tt>, <tt>array</tt> and <tt>string</tt>. +</p> + +<p><i>[ +Summit: +]</i></p> + + +<blockquote> +Agree with the issue but not the details of the proposed solution. Walter to +provide wording for the new concept. +</blockquote> + +<p><i>[ +Post Summit Alisdair adds: +]</i></p> + + +<blockquote> +Another LWG subgroup wondered if this concept +should extend to <tt>complex<T></tt>, and so not be built on the container concept at +all? +</blockquote> + + <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>. +Add to <tt><container_concepts></tt> synopsis in 23.2.6 [container.concepts] </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>; - ... +<blockquote><pre><ins>concept< typename C > ContiguousStorageContainer <i>see below</i>;</ins> </pre></blockquote> <p> -In 20.6.17.1 [func.referenceclosure.cons] Construct, copy, destroy, -add the member function description +Add a new section to the end of 23.2.6 [container.concepts] </p> <blockquote> -<pre>reference_closure& operator=(const reference_closure& f) +<p> +23.1.6.x ContiguousStorageContainer concept [container.concepts.contiguous] +</p> + +<pre>concept ContiguousStorageContainer< typename C > + : Container<C> +{ + value_type* data(C&); + + axiom Contiguity(C& c, size_type i) { + if( i < size(c) ) { + addressof( * (data(c) + i) ) + == addressof( * advance(data(c), i) ); + } + } +} </pre> -<blockquote> + <p> -<i>Postcondition:</i> <tt>*this</tt> is a copy of <tt>f</tt>. +The <tt>ContiguousStorageContainer</tt> concept describes a container whose elements +are allocated in a single region of memory, and are stored sequentially +without intervening padding other than to meet alignment requirements. +For example, the elements may be stored in a +single array of suitable length. </p> + +<pre>value_type * data( C& ); +</pre> + +<blockquote> +<i>Returns:</i> a pointer to the first element in the region of storage. +Result is unspecified for an empty container. +</blockquote> + +</blockquote> + <p> -<i>Returns:</i> <tt>*this</tt>. +Change 23.3.1 [array] p1: </p> + +<blockquote> +-1- The header <tt><array></tt> defines a class template for +storing fixed-size sequences of objects. An <tt>array</tt> supports +random access iterators. An instance of <tt>array<T, N></tt> +stores <tt>N</tt> elements of type <tt>T</tt>, so that <tt>size() == +N</tt> is an invariant. The elements of an <tt>array</tt> are stored +contiguously, meaning that <del>if <tt>a</tt> is</del> an +<tt>array<T, N></tt> <del>then it obeys the identity <tt>&a[n] +== &a[0] + n</tt> for all <tt>0 <= n < N</tt></del> +<ins>satisfies the concept <tt>ContiguousStorageContainer< array<T, +N>></tt></ins>. </blockquote> + +<p> +Add to the synopsis in 23.3.1 [array]: +</p> + +<blockquote><pre> ... + T * data(); + const T * data() const; + }; + + <ins>template< typename T, size_t N ></ins> + <ins>concept_map ContiguousStorageContainer< array<T, N>> {};</ins> +} +</pre></blockquote> + +<p> +Change 23.3.6 [vector] p1: +</p> + +<blockquote> +A <tt>vector</tt> is a sequence container that supports random access +iterators. In addition, it supports (amortized) constant time insert and +erase operations at the end; insert and erase in the middle take linear +time. Storage management is handled automatically, though hints can be +given to improve efficiency. The elements of a vector are stored +contiguously, meaning that <del>if <tt>v</tt> is</del> a +<tt>vector<T, Alloc></tt> <ins>(</ins>where <tt>T</tt> is some +type other than <tt>bool</tt><ins>)</ins><del>, then it obeys the +identity <tt>&v[n] == &v[0] + n</tt> for all <tt>0 <= n < +v.size()</tt></del> <ins>satisfies the concept <tt>ContiguousStorageContainer< +vector< T, Alloc>></tt></ins>. </blockquote> +<p> +Add at the end of the synopsis in 23.3.6 [vector] p2: +</p> + +<blockquote><pre><ins>template< typename T, typename A > + requires !SameType< T, bool > + concept_map ContiguousStorageContainer< vector<T, A>> {};</ins> +</pre></blockquote> @@ -16799,125 +29595,378 @@ add the member function description <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> +<h3><a name="1043"></a>1043. Response to US 91</h3> +<p><b>Section:</b> 29.6 [atomics.types.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> + <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-05-23</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#Review">Review</a> status.</p> <p><b>Discussion:</b></p> + +<p><b>Addresses US 91</b></p> + +<p> +It is unclear whether or not a failed <tt>compare_exchange</tt> is a RMW operation +(as used in 1.10 [intro.multithread]). +</p> + <p> -The current working draft is in an inconsistent state. +Suggested solution: </p> <p> -26.3.8 [complex.transcendentals] says that: +Make failing <tt>compare_exchange</tt> operations <b>not</b> be RMW. </p> +<p><i>[ +Anthony Williams adds: +]</i></p> + + <blockquote> -<tt>pow(complex<float>(), int())</tt> returns a <tt>complex<float></tt>. +In 29.6 [atomics.types.operations] p18 it says that "These +operations are atomic read-modify-write operations" (final sentence). +This is overly restrictive on the implementations of +<tt>compare_exchange_weak</tt> and <tt>compare_exchange_strong</tt> on platforms without a +native CAS instruction. </blockquote> + +<p><i>[ +Summit: +]</i></p> + + +<blockquote> +Group agrees with the resolution as proposed by Anthony Williams in the attached note. +</blockquote> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +We recommend the proposed resolution be reviewed +by members of the Concurrency Subgroup. +</blockquote> + + +<p><b>Proposed resolution:</b></p> <p> -26.3.9 [cmplx.over] says that: +Change 29.6 [atomics.types.operations] p18: </p> <blockquote> -<tt>pow(complex<float>(), int())</tt> returns a <tt>complex<double></tt>. +-18- <i>Effects:</i> Atomically, compares the value pointed to by +<tt>object</tt> or by <tt>this</tt> for equality with that in +<tt>expected</tt>, and if true, replaces the value pointed to by +<tt>object</tt> or by <tt>this</tt> with desired, and if false, updates +the value in <tt>expected</tt> with the value pointed to by +<tt>object</tt> or by <tt>this</tt>. Further, if the comparison is true, +memory is affected according to the value of <tt>success</tt>, and if the +comparison is false, memory is affected according to the value of +<tt>failure</tt>. When only one <tt>memory_order</tt> argument is +supplied, the value of <tt>success</tt> is <tt>order</tt>, and the value +of <tt>failure</tt> is <tt>order</tt> except that a value of +<tt>memory_order_acq_rel</tt> shall be replaced by the value +<tt>memory_order_acquire</tt> and a value of +<tt>memory_order_release</tt> shall be replaced by the value +<tt>memory_order_relaxed</tt>. <ins>If the comparison is <tt>true</tt>, </ins> +<del>T</del><ins>t</ins>hese operations are atomic +read-modify-write operations (1.10). +<ins>If the comparison is <tt>false</tt>, these +operations are atomic load operations.</ins> </blockquote> + + + + + +<hr> +<h3><a name="1044"></a>1044. Response to UK 325</h3> +<p><b>Section:</b> 30.4 [thread.mutex] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-05-23</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p> +<p><b>Discussion:</b></p> + +<p><b>Addresses UK 325</b></p> + +<p> +We believe constexpr literal values should be a more natural expression +of empty tag types than extern objects as it should improve the +compiler's ability to optimize the empty object away completely. +</p> + <p><i>[ -Sophia Antipolis: +Summit: ]</i></p> <blockquote> +Move to review. The current specification is a "hack", and the proposed +specification is a better "hack". +</blockquote> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +We agree with the proposed resolution. +Move to Tentatively Ready. +</blockquote> + + +<p><b>Proposed resolution:</b></p> <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>. +Change the synopsis in 30.4 [thread.mutex]: </p> + +<blockquote><pre>struct defer_lock_t <ins>{}</ins>; +struct try_to_lock_t <ins>{}</ins>; +struct adopt_lock_t <ins>{}</ins>; + +<del>extern</del> const<ins>expr</ins> defer_lock_t defer_lock <ins>{}</ins>; +<del>extern</del> const<ins>expr</ins> try_to_lock_t try_to_lock <ins>{}</ins>; +<del>extern</del> const<ins>expr</ins> adopt_lock_t adopt_lock <ins>{}</ins>; +</pre></blockquote> + + + + + + +<hr> +<h3><a name="1045"></a>1045. Response to UK 326</h3> +<p><b>Section:</b> 30.4.3.2.1 [thread.lock.unique.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-05-23</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p> +<p><b>Discussion:</b></p> + +<p><b>Addresses UK 326</b></p> + <p> -Special note: ask P.J. Plauger. +The precondition that the mutex is not owned by this thread offers +introduces the risk of un-necessary undefined behaviour into the +program. The only time it matters whether the current thread owns the +mutex is in the lock operation, and that will happen subsequent to +construction in this case. The lock operation has the identical +pre-condition, so there is nothing gained by asserting that precondition +earlier and denying the program the right to get into a valid state +before calling lock. </p> + +<p><i>[ +Summit: +]</i></p> + + <blockquote> -Looks fine. +Agree, move to review. </blockquote> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +We agree with the proposed resolution. +Move to Tentatively Ready. </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]: +Strike 30.4.3.2.1 [thread.lock.unique.cons] p7: </p> -<blockquote><pre><del>template<class T> complex<T> pow(const complex<T>& x, int y);</del> -</pre></blockquote> +<blockquote><pre>unique_lock(mutex_type& m, defer_lock_t); +</pre> +<blockquote> +<del>-7- <i>Precondition:</i> If <tt>mutex_type</tt> is not a recursive mutex +the calling thread does not own the mutex.</del> +</blockquote> +</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> +<h3><a name="1046"></a>1046. Response to UK 329</h3> +<p><b>Section:</b> 30.6 [futures] <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>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-03-13</p> +<p><b>View all 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><b>Addresses UK 329</b></p> + +<p> +<tt>future</tt>, <tt>promise</tt> and <tt>packaged_task</tt> provide a +framework for creating future values, but a simple function to tie all +three components together is missing. Note that we only need a *simple* +facility for C++0x. Advanced thread pools are to be left for TR2. +</p> + +<p> +Simple Proposal: +</p> + +<p> +Provide a simple function along the lines of: +</p> +<blockquote><pre>template< typename F, typename ... Args > + requires Callable< F, Args... > + future< Callable::result_type > async( F&& f, Args && ... ); +</pre></blockquote> + +<p> +Semantics are similar to creating a <tt>thread</tt> object with a <tt>packaged_task</tt> +invoking <tt>f</tt> with <tt>forward<Args>(args...)</tt> +but details are left unspecified to allow different scheduling and thread +spawning implementations. +</p> +<p> +It is unspecified whether a task submitted to async is run on its own thread +or a thread previously used for another async task. If a call to <tt>async</tt> +succeeds, it shall be safe to wait for it from any thread. +</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. +The state of <tt>thread_local</tt> variables shall be preserved during <tt>async</tt> calls. </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'. +No two incomplete async tasks shall see the same value of +<tt>this_thread::get_id()</tt>. +</p> +<p> +[<i>Note:</i> this effectively forces new tasks to be run on a new thread, or a +fixed-size pool with no queue. If the +library is unable to spawn a new thread or there are no free worker threads +then the <tt>async</tt> call should fail. <i>--end note</i>] </p> <p><i>[ -Jens adds: +Summit: ]</i></p> <blockquote> <p> -Note that +The concurrency subgroup has revisited this issue and decided that it +could be considered a defect according to the Kona compromise. A task +group was formed lead by Lawrence Crowl and Bjarne Stroustrup to write a +paper for Frankfort proposing a simple asynchronous launch facility +returning a <tt>future</tt>. It was agreed that the callable must be run on a +separate thread from the caller, but not necessarily a brand-new thread. +The proposal might or might not allow for an implementation that uses +fixed-size or unlimited thread pools. </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: +Bjarne in c++std-lib-23121: I think that what we agreed was that to +avoid deadlock <tt>async()</tt> would almost certainly be specified to launch in +a different thread from the thread that executed <tt>async()</tt>, but I don't +think it was a specific design constraint. </p> -<blockquote><pre>atomic_itype a2 { 6 }; -</pre></blockquote> - </blockquote> + <p><b>Proposed resolution:</b></p> + + + + + +<hr> +<h3><a name="1047"></a>1047. Response to UK 334</h3> +<p><b>Section:</b> 30.6.4 [futures.unique_future] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> + <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#futures.unique_future">active issues</a> in [futures.unique_future].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#futures.unique_future">issues</a> in [futures.unique_future].</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><b>Addresses UK 334</b></p> + <p> -In 29.3.1 [atomics.types.integral], strike the following sentence from paragraph 2: +Behaviour of <tt>get()</tt> is undefined if calling <tt>get()</tt> while +not <tt>is_ready()</tt>. The intent is that <tt>get()</tt> is a blocking +call, and will wait for the future to become ready. </p> +<p><i>[ +Summit: +]</i></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> +<p> +Agree, move to Review. +</p> </blockquote> <p><i>[ -2008-08-18, Lawrence adds: +2009-04-03 Thomas J. Gritzan adds: ]</i></p> + +<blockquote> +<p> +This issue also applies to <tt>shared_future::get()</tt>. +</p> + +<p> +Suggested wording: +</p> + +<p> +Add a paragraph to [futures.shared_future]: +</p> + +<blockquote><pre>void shared_future<void>::get() const; +</pre> <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. +<i>Effects:</i> If <tt>is_ready()</tt> would return <tt>false</tt>, block on the asynchronous +result associated with <tt>*this</tt>. +</blockquote> +</blockquote> +</blockquote> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +It is not clear to us that this is an issue, +because the proposed resolution's Effects clause seems to duplicate +information already present in the Synchronization clause. +Keep in Review status. +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +Add a paragraph to 30.6.4 [futures.unique_future]: +</p> + +<blockquote><pre>R&& unique_future::get(); +R& unique_future<R&>::get(); +void unique_future<void>::get(); +</pre> +<blockquote> +<p><i>Note:</i>...</p> +<p> +<ins><i>Effects:</i> If <tt>is_ready()</tt> would return <tt>false</tt>, +block on the asynchronous result associated with <tt>*this</tt>.</ins> +</p> +<p> +<i>Synchronization:</i> if <tt>*this</tt> is associated with a +<tt>promise</tt> object, the completion of <tt>set_value()</tt> or +<tt>set_exception()</tt> to that <tt>promise</tt> happens before (1.10) +<tt>get()</tt> returns. +</p> +</blockquote> </blockquote> @@ -16925,159 +29974,412 @@ we can also have implicit constructors. <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> +<h3><a name="1048"></a>1048. Response to UK 335</h3> +<p><b>Section:</b> 30.6.4 [futures.unique_future] <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>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-03-13</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#futures.unique_future">active issues</a> in [futures.unique_future].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#futures.unique_future">issues</a> in [futures.unique_future].</p> +<p><b>View all 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><b>Addresses UK 335</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. +<tt>std::unique_future</tt> is <tt>MoveConstructible</tt>, so you can transfer the +association with an asynchronous result from one instance to another. +However, there is no way to determine whether or not an instance has +been moved from, and therefore whether or not it is safe to wait for it. </p> +<blockquote><pre>std::promise<int> p; +std::unique_future<int> uf(p.get_future()); +std::unique_future<int> uf2(std::move(uf)); +uf.wait(); <font color="#c80000">// oops, uf has no result to wait for. </font> +</pre></blockquote> -<p><b>Proposed resolution:</b></p> <p> +Suggest we add a <tt>waitable()</tt> function to <tt>unique_future</tt> +(and <tt>shared_future</tt>) akin to <tt>std::thread::joinable()</tt>, +which returns <tt>true</tt> if there is an associated result to wait for +(whether or not it is ready). +</p> + +<p> +Then we can say: +</p> + +<blockquote><pre>if(uf.waitable()) uf.wait(); +</pre></blockquote> + +<p><i>[ +Summit: +]</i></p> + + +<blockquote> +<p> +Create an issue. Requires input from Howard. Probably NAD. </p> +</blockquote> + +<p><i>[ +Post Summit, Howard thows in his two cents: +]</i></p> + + +<blockquote> +<p> +Here is a copy/paste of my last prototype of <tt>unique_future</tt> which was +several years ago. At that time I was calling <tt>unique_future</tt> <tt>future</tt>: +</p> + +<blockquote><pre>template <class R> +class future +{ +public: + typedef R result_type; +private: + future(const future&);// = delete; + future& operator=(const future&);// = delete; + + template <class R1, class F1> friend class prommise; +public: + future(); + ~future(); + + future(future&& f); + future& operator=(future&& f); + + void swap(future&& f); + + <b>bool joinable() const;</b> + bool is_normal() const; + bool is_exceptional() const; + bool is_ready() const; + + R get(); + + void join(); + template <class ElapsedTime> + bool timed_join(const ElapsedTime&); +}; +</pre></blockquote> + +<p> +<tt>shared_future</tt> had a similar interface. I intentionally reused +the <tt>thread</tt> interface where possible to lessen the learning +curve std::lib clients will be faced with. +</p> +</blockquote> + + + +<p><b>Proposed resolution:</b></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> +<h3><a name="1049"></a>1049. Response to UK 339</h3> +<p><b>Section:</b> 30.6.6 [futures.promise] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> + <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#futures.promise">active issues</a> in [futures.promise].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#futures.promise">issues</a> in [futures.promise].</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><b>Addresses UK 339</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: +Move assignment is goiing in the wrong direction, assigning from +<tt>*this</tt> to the passed rvalue, and then returning a reference to +an unusable <tt>*this</tt>. </p> +<p><i>[ +Summit: +]</i></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). +<p> +Agree, move to Review. +</p> +</blockquote> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +We recommend deferring this issue until after Detlef's paper (on futures) +has been issued. </blockquote> + +<p><b>Proposed resolution:</b></p> <p> -However, the chapter 23 only says, on the topic of exceptions: 23.1 [container.requirements], -para 10: +Strike 30.6.6 [futures.promise] p6 and change p7: </p> +<blockquote><pre>promise& operator=(promise&& rhs); +</pre> <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: +<del>-6- <i>Effects:</i> move assigns its associated state to <tt>rhs</tt>.</del> </p> - -<ul> -<li>if an exception is thrown by...</li> -</ul> +<p> +-7- <i>Postcondition:</i> <del><tt>*this</tt> has no associated +state.</del> <ins>associated state of <tt>*this</tt> is the same as the +associated state of <tt>rhs</tt> before the call. <tt>rhs</tt> has no +associated state.</ins> +</p> +</blockquote> </blockquote> + + + + + +<hr> +<h3><a name="1050"></a>1050. Response to UK 340</h3> +<p><b>Section:</b> 30.6.6 [futures.promise] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> + <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#futures.promise">active issues</a> in [futures.promise].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#futures.promise">issues</a> in [futures.promise].</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><b>Addresses UK 340</b></p> + <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. +There is an implied postcondition for <tt>get_future()</tt> that the state of the +<tt>promise</tt> is transferred into the <tt>future</tt> leaving the <tt>promise</tt> with no +associated state. It should be spelled out. </p> +<p><i>[ +Summit: +]</i></p> + + +<blockquote> <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. +Agree, move to Review. </p> +</blockquote> + +<p><i>[ +2009-04-03 Thomas J. Gritzan adds: +]</i></p> + +<blockquote> <p> -The reaction in that group by Niels Dekker, Martin Sebor, and -Bo Persson, was all that this would be worth an LWG issue. +<tt>promise::get_future()</tt> must not invalidate the state of the promise object. +</p> +<p> +A promise is used like this: +</p> +<blockquote><pre>promise<int> p; +unique_future<int> f = p.get_future(); +<font color="#c80000">// post 'p' to a thread that calculates a value </font> +<font color="#c80000">// use 'f' to retrieve the value. </font> +</pre></blockquote> +<p> +So <tt>get_future()</tt> must return an object that shares the same associated +state with <tt>*this</tt>. +</p> +<p> +But still, this function should throw an <tt>future_already_retrieved</tt> error +when it is called twice. +</p> +<p> +<tt>packaged_task::get_future()</tt> throws <tt>std::bad_function_call</tt> if its <tt>future</tt> +was already retrieved. It should throw +<tt>future_error(future_already_retrieved)</tt>, too. +</p> +<p> +Suggested resolution: +</p> +<p> +Replace p12/p13 30.6.6 [futures.promise]: +</p> +<blockquote> +<p> +-12- <i>Throws:</i> <tt>future_error</tt> if <del><tt>*this</tt> has no associated state</del> +<ins>the <tt>future</tt> has already been retrieved</ins>. +</p> +<p> +-13- <i>Error conditions:</i> <tt>future_already_retrieved</tt> if <del><tt>*this</tt> +has no associated state</del> +<ins>the <tt>future</tt> associated with +the associated state has already been retrieved</ins>. +</p> +<p> +<ins><i>Postcondition:</i> The returned object and <tt>*this</tt> share the associated state.</ins> +</p> +</blockquote> +<p> +Replace p14 30.6.8 [futures.task]: +</p> +<blockquote> +<p> +-14- <i>Throws:</i> <tt><del>std::bad_function_call</del> <ins>future_error</ins></tt> if the future <del>associated with +the task</del> has already been retrieved. </p> +<p><ins> +<i>Error conditions:</i> <tt>future_already_retrieved</tt> if the <tt>future</tt> associated with +the task has already been retrieved. +</ins></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). +<ins><i>Postcondition:</i> The returned object and <tt>*this</tt> share the associated task.</ins> </p> +</blockquote> +</blockquote> + +<p><i>[ +Batavia (2009-05): +]</i></p> +<blockquote> +Keep in Review status +pending Detlef's forthcoming paper on futures. +</blockquote> <p><b>Proposed resolution:</b></p> <p> -Add a blanket statement in 21.3.1 [string.require]: +Add after p13 30.6.6 [futures.promise]: </p> +<blockquote><pre>unique_future<R> get_future(); +</pre> <blockquote> <p> -- if any member function or operator of <tt>basic_string<charT, traits, Allocator></tt> -throws, that function or operator has no effect. +-13- ... </p> <p> -- no <tt>erase()</tt> or <tt>pop_back()</tt> function throws. +<i>Postcondition:</i> <tt>*this</tt> has no associated state. </p> </blockquote> +</blockquote> + + + + + + +<hr> +<h3><a name="1051"></a>1051. Response to UK 279</h3> +<p><b>Section:</b> 24.5.1.2.12 [reverse.iter.opindex], 24.5.3.2.12 [move.iter.op.index] <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>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-03-21</p> +<p><b>View all 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><b>Addresses UK 279</b></p> <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. +The reason the return type became unspecified is LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#386">386</a>. This +reasoning no longer applies as there are at least two ways to get the right +return type with the new language facilities added since the previous +standard. </p> +<p> +Proposal: Specify the return type using either decltype or the Iter concept_map. +</p> + +<p><i>[ +Summit: +]</i></p> + + +<blockquote> +<p> +Under discussion. This is a general question about all iterator +adapters. +</p> +</blockquote> + +<p><i>[ +Howard adds post Summit: +]</i></p> + + +<blockquote> +I am requesting test cases to demonstrate a position. +</blockquote> + + + +<p><b>Proposed resolution:</b></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> +<h3><a name="1052"></a>1052. Response to UK 281</h3> +<p><b>Section:</b> 24.5.1.2.5 [reverse.iter.opref] <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>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-03-13</p> +<p><b>View all 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><b>Addresses UK 281</b></p> + +<p> +The current specification for return value for <tt>reverse_iterator::operator-></tt> +will always be a true pointer type, but <tt>reverse_iterator</tt> supports proxy +iterators where the pointer type may be some kind of 'smart pointer'. +</p> + +<p><i>[ +Summit: +]</i></p> + + +<blockquote> +<p> +<tt>move_iterator</tt> avoids this problem by returning a value of the wrapped +Iterator type. +study group formed to come up with a suggested resolution. +</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. +<tt>move_iterator</tt> solution shown in proposed wording. </p> +</blockquote> + <p><b>Proposed resolution:</b></p> <p> -Add the following to the synopsis in 20.6 [function.objects]/2: +Change synopsis in 24.5.1.1 [reverse.iterator]: </p> -<blockquote><pre>template<class Allocator> struct hash<std::vector<bool,Allocator>>; -template<size_t N> struct hash<std::bitset<N>>; +<blockquote><pre>template <BidirectionalIterator Iter> +class reverse_iterator { + ... + typedef Iter<del>::pointer</del> pointer; </pre></blockquote> <p> -Modify the last sentence of 20.6.16 [unord.hash]/1 to end with: +Change 24.5.1.2.5 [reverse.iter.opref]: </p> +<blockquote><pre>pointer operator->() const; +</pre> <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>. +<i>Returns:</i> +<blockquote><pre><del>&(operator*());</del> +<ins>this->tmp = current;</ins> +<ins>--this->tmp;</ins> +<ins>return this->tmp;</ins> +</pre></blockquote> +</blockquote> </blockquote> @@ -17086,78 +30388,182 @@ Modify the last sentence of 20.6.16 [unord.hash]/1 to end with: <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> +<h3><a name="1053"></a>1053. Response to UK 295</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> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-03-13</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><b>Addresses UK 295</b></p> + +<p> +There is a level of redundancy in the library specification for many +algorithms that can be eliminated with the combination of concepts and +default parameters for function templates. Eliminating redundancy simplified +specification and reduces the risk of introducing accidental +inconsistencies. +</p> +<p> +Proposed resolution: Adopt +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2743.pdf">N2743</a>. +</p> + +<p><i>[ +Summit: +]</i></p> + + +<blockquote> <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. +NAD, this change would break code that takes the address of an +algorithm. </p> +</blockquote> +<p><i>[ +Post Summit Alisdair adds: +]</i></p> + + +<blockquote> <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. +Request 'Open'. The issues in the paper go beyond just reducing +the number of signatures, but cover unifying the idea of the ordering +operation used by algorithms, containers and other library components. At +least, it takes a first pass at the problem. </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. +For me (personally) that was the more important part of the paper, and not +clearly addressed by the Summit resolution. </p> +</blockquote> + <p><b>Proposed resolution:</b></p> + + + + + +<hr> +<h3><a name="1054"></a>1054. <tt>forward</tt> broken</h3> +<p><b>Section:</b> 20.3.2 [forward] <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>Opened:</b> 2009-03-13 <b>Last modified:</b> 2009-05-23</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#Open">Open</a> status.</p> +<p><b>Discussion:</b></p> + <p> -Add the following to the synopsis in 20.5.2 [meta.type.synop] under "other transformations": +This is a placeholder issue to track the fact that we (well I) put the standard +into an inconsistent state by requesting that we accept +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2844.html">N2844</a> +except for the proposed changes to [forward]. </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> +There will exist in the post meeting mailing +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2835.html">N2835</a> +which in its current state reflects the state of affairs prior to the Summit +meeting. I hope to update it in time for the post Summit mailing, but as I write +this issue I have not done so yet. +</p> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +Move to Open, awaiting the promised paper. +</blockquote> + + + +<p><b>Proposed resolution:</b></p> + + + + + +<hr> +<h3><a name="1055"></a>1055. Response to UK 98</h3> +<p><b>Section:</b> 20.6.7 [meta.trans.other] <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>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-05-23</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#Open">Open</a> status.</p> +<p><b>Discussion:</b></p> + +<p><b>Addresses UK 98</b></p> <p> -Add three new entries to table 51 (20.5.7 [meta.trans.other]) with the following content +It would be useful to be able to determine the underlying +type of an arbitrary enumeration type. This would allow +safe casting to an integral type (especially needed for +scoped enums, which do not promote), and would allow +use of <tt>numeric_limits</tt>. In general it makes generic +programming with enumerations easier. +</p> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +Pete observes (and Tom concurs) +that the proposed resolution seems to require compiler support +for its implementation, +as it seems necessary to look at the range of values +of the enumerated type. +To a first approximation, +a library solution could give an answer based on the size of the type. +If the user has specialized <tt>numeric_limits</tt> for the enumerated type, +then the library might be able to do better, +but there is no such requirement. +Keep status as Open +and solicit input from CWG. +</blockquote> + +<p><i>[ +2009-05-23 Alisdair adds: +]</i></p> + + +<blockquote> +Just to confirm that the BSI originator of this comment assumed it did +indeed imply a compiler intrinsic. Rather than request a Core extension, it +seemed in keeping with that the type traits interface provides a library API +to unspecified compiler features - where we require several other traits +(e.g. <tt>has_trivial_*</tt>) to get the 'right' answer now, unlike in TR1. +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +Add a new row to the table in 20.6.7 [meta.trans.other]: </p> <blockquote> <table border="1"> +<caption>Table 41 -- Other transformations</caption> <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> +<th>Template</th> +<th>Condition</th> +<th>Comments</th> </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> +<td> +<tt>template< class T > struct enum_base;</tt> +</td> +<td> +<tt>T</tt> shall be an enumeration type (7.2 [dcl.enum]) +</td> +<td> +The member typedef <tt>type</tt> shall name the underlying type +of the enum <tt>T</tt>. +</td> </tr> </tbody></table> </blockquote> @@ -17166,71 +30572,475 @@ as an accessible unambiguous direct base class. If no such type exists, the memb +<hr> +<h3><a name="1056"></a>1056. Must all Engines and Distributions be Streamable?</h3> +<p><b>Section:</b> 26.5 [rand] <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>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-05-31</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand">active issues</a> in [rand].</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#Open">Open</a> status.</p> +<p><b>Discussion:</b></p> + +<p> +Both the concepts <tt>RandomNumberEngine</tt> and <tt>RandomNumberDistribution</tt> have +requirements to be <tt>InputStreamable</tt> and <tt>OutputStreamable</tt>. +</p> +<p> +I have no problems leaving the WP in an inconsistent state on the best-faith +assumption these concepts will be provided later, however disagree with the +proposers that these constraints are not separable, orthogonal to the basic +concepts of generating random number distributions. +</p> +<p> +These constraints should be dropped, and applied to specific algorithms as +needed. +</p> +<p> +If a more refined concept (certainly deemed useful by the proposers) is +proposed there is no objection, but the basic concept should not require +persistence via streaming. +</p> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +Move to Open. +</blockquote> + +<p><i>[ +2009-05-31 Alisdair adds: +]</i></p> + + +<blockquote> +<p> +Working on constraining the stream iterators, I have a few more observations +to make on the concepts proposed while constraining the random number +facility. +</p> +<p> +While I still believe the concerns are orthogonal, I don't believe the +existing constraints go far enough either! The goal we want to achieve is +not that a <tt>RandomNumberEngine</tt> / <tt>RandomNumberDistribution</tt> supports the stream +operators, but that it is <tt>Serializable</tt>. I.e. there is a relationship +between the insert and extract operations that guarantees to restore the +state of the original object. This implies a coupling of the concepts +together in a broader concept (<tt>Serializable</tt>) with at least one axiom to +assert the semantics. +</p> +<p> +One problem is that <tt>istream</tt> and <tt>ostream</tt> may be fundamentally different +types, although we can hook a relation if we are prepared to drop down to +the <tt>char</tt> type and <tt>char_traits</tt> template parameters. Doing so ties us to a +form of serialization that demands implementation via the std iostreams +framework, which seems overly prescriptive. I believe the goal is generally +to support serialization without regard to how it is expressed - although +this is getting even more inventive in terms of concepts we do not have +today. +</p> +</blockquote> + + +<p><b>Proposed resolution:</b></p> + + + + + +<hr> +<h3><a name="1057"></a>1057. <tt>RandomNumberEngineAdaptor</tt></h3> +<p><b>Section:</b> 26.5 [rand] <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>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand">active issues</a> in [rand].</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#Open">Open</a> status.</p> +<p><b>Discussion:</b></p> + +<p> +The <tt>RandomNumberEngineAdaptor</tt> concept breaks precedent in the +way the library has been specified by grouping requirements into a +concept that is never actually used in the library. +</p> +<p> +This is undoubtedly a very helpful device for documentation, but we are not +comfortable with the precedent - especially as we have rejected national +body comments on the same grounds. +</p> +<p> +Suggest either removing the concept, or providing an algorithm/type that +requires this concept in their definition (such as a factory function to +create new engines). +</p> +<p> +The preference is to create a single new algorithm and retain the value of +the existing documentation. +</p> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +<p> +Walter points out that it is unlikely that any algorithm would ever +require this concept, but that the concept nonetheless is useful as +documentation, and (via concept maps) as a means of checking specific adapters. +</p> +<p> +Alisdair disagrees as to the concept's value as documentation. +</p> +<p> +Marc points out that the <tt>RandomNumberDistribution</tt> +is also a concept not used elsewhere in the Standard. +</p> +<p> +Pete agrees that a policy of not inventing concepts +that aren't used in the Standard is a good starting point, +but should not be used as a criterion for rejecting a concept. +</p> +<p> +Move to Open. +</p> +</blockquote> + + +<p><b>Proposed resolution:</b></p> + + + + <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> +<h3><a name="1058"></a>1058. New container issue</h3> +<p><b>Section:</b> 23.2.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Tentatively NAD Editorial</a> + <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#sequence.reqmts">active issues</a> in [sequence.reqmts].</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#Tentatively%20NAD%20Editorial">Tentatively NAD Editorial</a> status.</p> <p><b>Discussion:</b></p> + +<p> +Sequence containers 23.2.3 [sequence.reqmts]: +</p> + +<p> +The return value of new calls added to table 83 are not specified. +</p> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +<p> +We agree with the proposed resolution. +</p> +<p> +Move to NAD Editorial. +</p> +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +Add after p6 23.2.3 [sequence.reqmts]: +</p> + +<blockquote> +<p> +-6- ... +</p> +<p><ins> +The iterator returned from <tt>a.insert(p,rv)</tt> points to the copy of <tt>rv</tt> +inserted into <tt>a</tt>. +</ins></p> +<p><ins> +The iterator returned from <tt>a.emplace(p, args)</tt> points to the new +element constructed from <tt>args</tt> inserted into <tt>a</tt>. +</ins></p> +</blockquote> + + + + + +<hr> +<h3><a name="1059"></a>1059. Usage of no longer existing FunctionType concept</h3> +<p><b>Section:</b> 20.7.16.2 [func.wrap.func] <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>Opened:</b> 2009-03-13 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#func.wrap.func">active issues</a> in [func.wrap.func].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.wrap.func">issues</a> in [func.wrap.func].</p> +<p><b>View all 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> +Due to a deliberate core language decision, the earlier called +"foundation" concept <tt>std::FunctionType</tt> had been removed in +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2773.pdf">N2773</a> +shortly +before the first "conceptualized" version of the WP +(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdf">N2798</a>) +had been +prepared. This caused a break of the library, which already used this +concept in the adapted definition of <tt>std::function</tt> +(20.7 [function.objects]/2, header <tt><functional></tt> synopsis and +20.7.16.2 [func.wrap.func]). +</p> +<p> +A simple fix would be to either (a) make <tt>std::function</tt>'s primary template +unconstrained or to (b) add constraints based on existing (support) concepts. +A more advanced fix would (c) introduce a new library concept. +</p> +<p> +The big disadvantage of (a) is, that users can define templates which +cause compiler errors during instantiation time because of under-constrainedness +and would thus violate the basic advantage of constrained +code. +</p> +<p> +For (b), the ideal constraints for <tt>std::function</tt>'s template parameter would +be one which excludes everything else but the single provided partial +specialization that matches every "free function" type (i.e. any function +type w/o cv-qualifier-seq and w/o ref-qualifier). +Expressing such a type as as single requirement would be written as +</p> +<blockquote><pre>template<typename T> +requires ReferentType<T> // Eliminate cv void and function types with cv-qual-seq + // or ref-qual (depending on core issue #749) + && PointeeType<T> // Eliminate reference types + && !ObjectType<T> // Eliminate object types +</pre></blockquote> +<p> +Just for completeness approach (c), which would make sense, if the +library has more reasons to constrain for free function types: +</p> +<blockquote><pre>auto concept FreeFunctionType<typename T> + : ReferentType<T>, PointeeType<T>, MemberPointeeType<T> +{ + requires !ObjectType<T>; +} +</pre></blockquote> +<p> +I mention that approach because I expect that free function types belong +to the most natural type categories for every days coders. Potential +candidates in the library are <tt>addressof</tt> and class template <tt>packaged_task</tt>. +</p> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> <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. +Alisdair would prefer to have a core-supported <tt>FunctionType</tt> concept +in order that any future changes be automatically correct +without need for a library solution to catch up; +he points to type traits as a precedent. +Further, he believes that a published concept can't in the future +be changed. </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. +Bill feels this category of entity would change sufficiently slowly +that he would be willing to take the risk. </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>. +Of the discussed solutions, we tend toward option (c). +We like the idea of having a complete taxonomy of native types, +and perhaps erred in trimming the set. </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. +We would like to have this issue reviewed by Core and would like +their feedback. Move to Open. </p> +</blockquote> <p><b>Proposed resolution:</b></p> +<ol> +<li> +<p> +Change in 20.7 [function.objects]/2, Header <tt><functional></tt> synopsis: +</p> +<blockquote><pre>// 20.6.16 polymorphic function wrappers: +class bad_function_call; +template<<del>FunctionType</del><ins>ReferentType F</ins>> +<ins>requires PointeeType<F> && !ObjectType<F></ins> +class function; // undefined +</pre></blockquote> +</li> +<li> <p> -To Class template deque 23.2.2 [deque] synopsis, add: +Change in 20.7.16.2 [func.wrap.func]: </p> -<blockquote><pre>void shrink_to_fit(); +<blockquote><pre>namespace std { +template<<del>FunctionType</del><ins>ReferentType F</ins>> +<ins>requires PointeeType<F> && !ObjectType<F></ins> +class function; // undefined </pre></blockquote> +</li> +</ol> + + + + +<hr> +<h3><a name="1060"></a>1060. Embedded nulls in NTBS</h3> +<p><b>Section:</b> 17.5.2.1.4.1 [byte.strings] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Tentatively NAD Editorial</a> + <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-13 <b>Last modified:</b> 2009-05-23</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD%20Editorial">Tentatively NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> + +<p> +Definition of null-terminated sequences allow for embedded nulls. This is +surprising, and probably not supportable with the intended use cases. +</p> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +We agree with the issue, but believe this can be handled editorially. +Move to NAD Editorial. +</blockquote> + + + +<p><b>Proposed resolution:</b></p> + + + + + +<hr> +<h3><a name="1061"></a>1061. Bad indexing for tuple access to pair (Editorial?)</h3> +<p><b>Section:</b> 20.3.4 [pair.astuple] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Tentatively NAD Editorial</a> + <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-13 <b>Last modified:</b> 2009-05-23</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD%20Editorial">Tentatively NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> + +<p> +The definition of <tt>get</tt> implies that <tt>get</tt> must return the second element if +given a negative integer. +</p> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +Move to NAD Editorial. +</blockquote> + + + +<p><b>Proposed resolution:</b></p> <p> -To deque capacity 23.2.2.2 [deque.capacity], add: +20.3.4 [pair.astuple] p5: </p> -<blockquote><pre>void shrink_to_fit(); + +<blockquote><pre>template<<del>int</del> <ins>size_t</ins> I, class T1, class T2> + requires True<(I < 2)> + const P& get(const pair<T1, T2>&); </pre> +</blockquote> + + + + + + +<hr> +<h3><a name="1062"></a>1062. Missing insert_iterator for stacks/queues</h3> +<p><b>Section:</b> 24.7 [insert.iterators] <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>Opened:</b> 2009-03-13 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#insert.iterators">active issues</a> in [insert.iterators].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#insert.iterators">issues</a> in [insert.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> +It is odd that we have an iterator to insert into a <tt>vector</tt>, but not an +iterator to insert into a <tt>vector</tt> that is adapted as a <tt>stack</tt>. The standard +container adapters all have a common interface to <tt>push</tt> and <tt>pop</tt> so it should +be simple to create an iterator adapter to complete the library support. +</p> + +<p> +We should provide an <tt>AdaptedContainer</tt> concept supporting <tt>push</tt> and <tt>pop</tt> +operations. Create a new insert iterator and factory function that inserts +values into the container by calling <tt>push</tt>. +</p> + +<p><i>[ +Batavia (2009-05): +]</i></p> <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>] +<p> +Walter recommends NAD Future. +</p> +<p> +Move to Open, and recommend deferring the issue until after the next +Committee Draft is issued. +</p> </blockquote> + + +<p><b>Proposed resolution:</b></p> + + + + + +<hr> +<h3><a name="1063"></a>1063. 03 iterator compatibilty</h3> +<p><b>Section:</b> D.10.4 [iterator.backward] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-15 <b>Last modified:</b> 2009-05-23</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p> +<p><b>Discussion:</b></p> + +<p> +Which header must a user <tt>#include</tt> to obtain the library-supplied +<tt>concept_maps</tt> declared in this paragraph? +</p> + +<p> +This is important information, as existing user code will break if this +header is not included, and we should make a point of mandating this header +is <tt>#include</tt>-d by library headers likely to make use of it, notably +<tt><algorithm></tt>. See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1001">1001</a> for more details. +</p> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +We agree with the direction of the proposed resolution. +Move to Tentatively Ready. +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p><i>Change D.10 [depr.lib.iterator.primitives], Iterator primitives, as +indicated:</i></p> + +<blockquote> + <p>To simplify the use of iterators and provide backward compatibility with + previous C++ Standard Libraries, + the library provides several classes and functions. <ins>Unless otherwise + specified, these classes and functions shall be defined in header <tt><iterator></tt>.</ins></p> +</blockquote> +<p><i>Change D.10.4 [iterator.backward], Iterator backward compatibility, as +indicated:</i></p> +<blockquote> + <p>The library provides concept maps that allow iterators specified with + <tt>iterator_traits</tt> to interoperate with + algorithms that require iterator concepts. <ins>These concept maps shall be + defined in the same header that defines the iterator.</ins> [<i>Example:</i></p> </blockquote> @@ -17238,200 +31048,792 @@ implementation-specific optimizations. -- <i>end note</i>] <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> +<h3><a name="1064"></a>1064. Response to UK 152</h3> +<p><b>Section:</b> 17.3.15 [defns.obj.state] <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>Opened:</b> 2009-03-15 <b>Last modified:</b> 2009-03-15</p> +<p><b>View all 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><b>Addresses UK 152</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. +Object state is using a definition of object (instance of a class) from +outside the standard, rather than the 'region of storage' definiton in +1.8 [intro.object]p1 </p> +<p><i>[ +Summit: +]</i></p> + +<blockquote> +We think we're removing this; See 20.7.18.1 [func.referenceclosure.cons]. +</blockquote> + + +<p><b>Proposed resolution:</b></p> <p> -In "C," this array usage is possible: </p> -<blockquote><pre>int ar[] = {1, 4, 6}; + + + + +<hr> +<h3><a name="1065"></a>1065. Response to UK 168</h3> +<p><b>Section:</b> 17.6.1.1 [contents] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-15 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#contents">active issues</a> in [contents].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#contents">issues</a> in [contents].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p> +<p><b>Discussion:</b></p> +<p><b>Addresses UK 168</b></p> +<p> +We should make it clear (either by note or normatively) that namespace +<tt>std</tt> may contain inline namespaces, and that entities specified to be +defined in std may in fact be defined in one of these inline namespaces. +(If we're going to use them for versioning, eg when TR2 comes along, +we're going to need that.) +</p> + +<p> +Replace "namespace std or namespaces nested within namespace std" with +"namespace std or namespaces nested within namespace std or inline +namespaces nested directly or indirectly within namespace std" +</p> + +<p><i>[ +Summit: +]</i></p> + +<blockquote> +adopt UK words (some have reservations whether it is correct) +</blockquote> + +<p><i>[ +2009-05-09 Alisdair improves the wording. +]</i></p> + + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +<p> +Bill believes there is strictly speaking no need to say that +because no portable test can detect the difference. +However he agrees that it doesn't hurt to say this. +</p> +<p> +Move to Tentatively Ready. +</p> +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +Change 17.6.1.1 [contents] p2: +</p> + +<blockquote> +All library entities except macros, <tt>operator new</tt> and +<tt>operator delete</tt> are defined within the namespace <tt>std</tt> or +namespaces nested within namespace <tt>std</tt>. +<ins>It is unspecified whether names declared in a specific namespace +are declared directly in that namespace, or in an inline namespace inside +that namespace. [<i>Footnote:</i> This gives implementers freedom to support +multiple configurations of the library.]</ins> +</blockquote> + + + + + +<hr> +<h3><a name="1066"></a>1066. Response to UK 189 and JP 27</h3> +<p><b>Section:</b> 18 [language.support] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-15 <b>Last modified:</b> 2009-05-23</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p> +<p><b>Discussion:</b></p> +<p><b>Addresses UK 189 and JP 27</b></p> +<p> +The addition of the <tt>[[noreturn]]</tt> attribute to the language will be an +important aid for static analysis tools. +</p> + +<p> +The following functions should be declared in C++ with the +<tt>[[noreturn]]</tt> attribute: <tt>abort</tt> <tt>exit</tt> +<tt>quick_exit</tt> <tt>terminate</tt> <tt>unexpected</tt> +<tt>rethrow_exception</tt> <tt>throw_with_nested</tt>. +</p> + +<p><i>[ +Summit: +]</i></p> + +<blockquote> +Agreed. +</blockquote> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +We agree with the proposed resolution. +Move to Tentatively Ready. +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +Change 18.5 [support.start.term] p3: +</p> + +<blockquote> +<p>-2- ...</p> +<pre><ins>void</ins> abort <ins>[[noreturn]]</ins> (void) +</pre> +<p>-3- ...</p> +<p>-6- ...</p> +<pre><ins>void</ins> exit<ins> [[noreturn]] </ins>(int status) +</pre> +<p>-7- ...</p> +<p>-11- ...</p> +<pre>void quick_exit<ins> [[noreturn]] </ins>(int status) +</pre> +<p>-12- ...</p> +</blockquote> + +<p> +Change the <tt><exception></tt> synopsis in 18.8 [support.exception]: +</p> + +<blockquote><pre>void unexpected<ins> [[noreturn]] </ins>(); +... +void terminate<ins> [[noreturn]] </ins>(); +... +void rethrow_exception<ins> [[noreturn]] </ins>(exception_ptr p); +... +template <class T> void throw_with_nested<ins> [[noreturn]] </ins>(T&& t); <del>// [[noreturn]]</del> </pre></blockquote> <p> -But for C++, +Change 18.8.2.4 [unexpected]: </p> -<blockquote><pre>std::array<int> a = { 1, 4, 6 }; // error +<blockquote><pre>void unexpected<ins> [[noreturn]] </ins>(); </pre></blockquote> <p> -Instead, the second parameter of the <tt>array</tt> template must be -explicit, like so: +Change 18.8.3.3 [terminate]: </p> -<blockquote><pre>std::array<int, 3> a = { 1, 4, 6 }; +<blockquote><pre>void terminate<ins> [[noreturn]] </ins>(); </pre></blockquote> <p> -Doug Gregor proposes the following solution, that assumes -generalized initializer lists. +Change 18.8.5 [propagation]: </p> -<blockquote><pre>template<typename T, typename... Args> -inline array<T, sizeof...(Args)> -make_array(Args&&... args) -{ return { std::forward<Args>(args)... }; } +<blockquote><pre>void rethrow_exception<ins> [[noreturn]] </ins>(exception_ptr p); </pre></blockquote> <p> -Then, the way to build an <tt>array</tt> from a list of unknown size is: +In the synopsis of 18.8.6 [except.nested] and the definition area change: </p> -<blockquote><pre>auto a = make_array<T>(1, 4, 6); +<blockquote><pre>template <class T> void throw_with_nested<ins> [[noreturn]] </ins>(T&& t); <del>// [[noreturn]]</del> </pre></blockquote> -<p><b>Proposed resolution:</b></p> + + +<hr> +<h3><a name="1067"></a>1067. simplified wording for inner_product</h3> +<p><b>Section:</b> 26.7 [numeric.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-17 <b>Last modified:</b> 2009-05-23</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p> +<p><b>Discussion:</b></p> + +<p> +One of the motivating examples for introducing requirements-aliases was to +simplify the wording of the <tt>inner_product</tt> requirements. As the paper +adopting the feature and constrained wording for the library went through in +the same meeting, it was not possible to make the change at the time. The +simpler form should be adopted now though. Similarly, most the other +numerical algorithms can benefit from a minor cleanup. +</p> <p> -Add to the <tt>array</tt> synopis in 23.2 [sequences]: +Note that in each case, the second more generalised form of the algorithm +does not benefit, as there are already named constraints supplied by the +template type parameters. </p> -<blockquote><pre>template<typename T, typename... Args> - requires Convertible<Args, T>... - array<T, sizeof...(Args)> - make_array(Args&&... args); -</pre></blockquote> +<p><i>[ +2009-05-02 Daniel adds: +]</i></p> + +<blockquote> <p> -Append after 23.2.1.6 [array.tuple] Tuple interface to class template <tt>array</tt> the -following new section. +one part of the suggested resolution suggests the removal of the +<tt>MoveConstructible<T></tt> requirement from +<tt>inner_product</tt>. According to 26.7.2 [inner.product] </p> <blockquote> +Computes its result by initializing the accumulator <tt>acc</tt> with the +initial value <tt>init</tt> +</blockquote> + <p> -23.2.1.7 Convenience interface to class template <tt>array</tt> [array.tuple] +this step requires at least <tt>MoveConstructible</tt>. </p> -<pre>template<typename T, typename... Args> - requires Convertible<Args, T>... - array<T, sizeof...(Args)> - make_array(Args&&... args); -</pre> +<p> +Therefore I strongly suggest to take this removal back (Note also +that the corresponding overload with a functor argument still has +the same <tt>MoveConstructible<T></tt> requirement). +</p> +</blockquote> + +<p><i>[ +Batavia (2009-05): +]</i></p> <blockquote> <p> -<i>Returns:</i> <tt>{std::forward<Args>(args)...}</tt> +We agree with the proposed resolution as amended by Daniel's suggestion +to restore <tt>MoveConstructible</tt>, +reflected in the updated proposed resolution below. +</p> +<p> +Move to Tentatively Ready. +</p> +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +Change in 26.7 [numeric.ops] and [accumulate]: +</p> + +<blockquote><pre>template <InputIterator Iter, MoveConstructible T> + requires <ins>add =</ins> HasPlus<T, Iter::reference> + && HasAssign<T, <del>HasPlus<T, Iter::reference></del> <ins>add</ins>::result_type> + T accumulate(Iter first, Iter last, T init); +</pre></blockquote> + +<p> +Change in 26.7 [numeric.ops] and 26.7.2 [inner.product]: +</p> + +<blockquote><pre>template <InputIterator Iter1, InputIterator Iter2, MoveConstructible T> + requires <ins>mult =</ins> HasMultiply<Iter1::reference, Iter2::reference> + && <ins>add =</ins> HasPlus<T, <del>HasMultiply<Iter1::reference, Iter2::reference></del> <ins>mult</ins>::result_type> + && HasAssign< + T, + <del>HasPlus<T, + HasMultiply<Iter1::reference, Iter2::reference>::result_type></del> <ins>add</ins>::result_type> + T inner_product(Iter1 first1, Iter1 last1, Iter2 first2, T init); +</pre></blockquote> + +<p> +Change in 26.7 [numeric.ops] and 26.7.3 [partial.sum]: +</p> + +<blockquote><pre>template <InputIterator InIter, OutputIterator<auto, const InIter::value_type&> OutIter> + requires <ins>add =</ins> HasPlus<InIter::value_type, InIter::reference> + && HasAssign<InIter::value_type, + <del>HasPlus<InIter::value_type, InIter::reference></del> <ins>add</ins>::result_type> + && Constructible<InIter::value_type, InIter::reference> + OutIter partial_sum(InIter first, InIter last, OutIter result); +</pre></blockquote> + +<p> +Change in 26.7 [numeric.ops] and 26.7.4 [adjacent.difference]: +</p> + +<blockquote><pre>template <InputIterator InIter, OutputIterator<auto, const InIter::value_type&> OutIter> + requires <ins>sub =</ins> HasMinus<InIter::value_type, InIter::value_type> + && Constructible<InIter::value_type, InIter::reference> + && OutputIterator<OutIter, <del>HasMinus<InIter::value_type, InIter::value_type></del> <ins>sub</ins>::result_type> + && MoveAssignable<InIter::value_type> + OutIter adjacent_difference(InIter first, InIter last, OutIter result); +</pre></blockquote> + + + + + + +<hr> +<h3><a name="1068"></a>1068. class random_device should be movable</h3> +<p><b>Section:</b> 26.5.6 [rand.device] <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>Opened:</b> 2009-03-18 <b>Last modified:</b> 2009-05-23</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.device">issues</a> in [rand.device].</p> +<p><b>View all 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> +class <tt>random_device</tt> should be movable. </p> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +Move to Open, and recommend this issue be deferred until after the next +Committee Draft is issued. </blockquote> + + +<p><b>Proposed resolution:</b></p> + + + + + +<hr> +<h3><a name="1069"></a>1069. class seed_seq should support efficient move operations</h3> +<p><b>Section:</b> 26.5.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> Alisdair Meredith <b>Opened:</b> 2009-03-18 <b>Last modified:</b> 2009-05-23</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> +class <tt>seed_seq</tt> should support efficient move operations. +</p> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +Move to Open, and recommend this issue be deferred until after the next +Committee Draft is issued. </blockquote> +<p><b>Proposed resolution:</b></p> + + <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> +<h3><a name="1070"></a>1070. Ambiguous move overloads in function</h3> +<p><b>Section:</b> 20.7.16.2 [func.wrap.func] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-19 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#func.wrap.func">active issues</a> in [func.wrap.func].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.wrap.func">issues</a> in [func.wrap.func].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively 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>: +The synopsis in 20.7.16.2 [func.wrap.func] says: </p> -<blockquote><pre>local_iterator begin(size_type n) const; +<blockquote><pre>template<Returnable R, CopyConstructible... ArgTypes> +class function<R(ArgTypes...)> +{ + ... + template<class F> + requires CopyConstructible<F> && Callable<F, ArgTypes...> + && Convertible<Callable<F, ArgTypes...>::result_type, R> + function(F); + template<class F> + requires CopyConstructible<F> && Callable<F, ArgTypes...> + && Convertible<Callable<F, ArgTypes...>::result_type, R> + function(F&&); + ... + template<class F, Allocator Alloc> function(allocator_arg_t, const Alloc&, F); + template<class F, Allocator Alloc> function(allocator_arg_t, const Alloc&, F&&); + ... + template<class F> + requires CopyConstructible<F> && Callable<F, ArgTypes..> + && Convertible<Callable<F, ArgTypes...>::result_type + function& operator=(F); + template<class F> + requires CopyConstructible<F> && Callable<F, ArgTypes...> + && Convertible<Callable<F, ArgTypes...>::result_type, R> + function& operator=(F&&); + ... +}; </pre></blockquote> +<p> +Each of the 3 pairs above are ambiguous. We need only one of each pair, and we +could do it with either one. If we choose the <tt>F&&</tt> version we +need to bring <tt>decay</tt> into the definition to get the pass-by-value behavior. +In the proposed wording I've gotten lazy and just used the pass-by-value signature. +</p> + +<p><i>[ +2009-05-01 Daniel adds: +]</i></p> + + +<blockquote> +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1024">1024</a> modifies the second removed constructor. +</blockquote> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +<p> +We briefly discussed whether we ought support moveable function objects, +but decided that should be a separate issue if someone cares to propose it. +</p> +<p> +Move to Tentatively Ready. +</p> +</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]: +Change the synopsis of 20.7.16.2 [func.wrap.func], and remove the associated definitions in +20.7.16.2.1 [func.wrap.func.con]: </p> -<blockquote><pre>local_iterator begin(size_type n)<del> const</del>; +<blockquote><pre>template<Returnable R, CopyConstructible... ArgTypes> +class function<R(ArgTypes...)> +{ + ... + template<class F> + requires CopyConstructible<F> && Callable<F, ArgTypes...> + && Convertible<Callable<F, ArgTypes...>::result_type, R> + function(F); + <del>template<class F> + requires CopyConstructible<F> && Callable<F, ArgTypes...> + && Convertible<Callable<F, ArgTypes...>::result_type, R> + function(F&&);</del> + ... + template<class F, Allocator Alloc> function(allocator_arg_t, const Alloc&, F); + <del>template<class F, Allocator Alloc> function(allocator_arg_t, const Alloc&, F&&);</del> + ... + template<class F> + requires CopyConstructible<F> && Callable<F, ArgTypes..> + && Convertible<Callable<F, ArgTypes...>::result_type + function& operator=(F); + <del>template<class F> + requires CopyConstructible<F> && Callable<F, ArgTypes...> + && Convertible<Callable<F, ArgTypes...>::result_type, R> + function& operator=(F&&);</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> +<h3><a name="1071"></a>1071. is_bind_expression should derive from integral_constant<bool></h3> +<p><b>Section:</b> 20.7.12.1.1 [func.bind.isbind] <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>Opened:</b> 2009-03-19 <b>Last modified:</b> 2009-05-31</p> +<p><b>View all 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-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. +Class template is_bind_expression 20.7.12.1.1 [func.bind.isbind]: +</p> + +<blockquote><pre>namespace std { + template<class T> struct is_bind_expression { + static const bool value = see below; + }; +} +</pre></blockquote> +<p> +<tt>is_bind_expression</tt> should derive from <tt>std::integral_constant<bool></tt> like +other similar trait types. </p> +<p><i>[ +Daniel adds: +]</i></p> -<p><b>Proposed resolution:</b></p> +<blockquote> +We need the same thing for the trait <tt>is_placeholder</tt> as well. +</blockquote> +<p><i>[ +2009-03-22 Daniel provided wording. +]</i></p> + + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +<p> +We recommend this be deferred until after the next Committee Draft is issued. +</p> <p> -Change the synopsis in 23.3.5 [template.bitset], and the signatures in 23.3.5.2 [bitset.members] to: +Move to Open. </p> +</blockquote> -<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; +<p><i>[ +2009-05-31 Peter adds: +]</i></p> + + +<blockquote> +<p> +I am opposed to the proposed resolution and to the premise of the issue +in general. The traits's default definitions should NOT derive from +<tt>integral_constant</tt>, because this is harmful, as it misleads people into +thinking that <tt>is_bind_expression<E></tt> always derives from +<tt>integral_constant</tt>, whereas it may not. +</p> +<p> +<tt>is_bind_expression</tt> and <tt>is_placeholder</tt> allow user +specializations, and in fact, this is their primary purpose. Such user +specializations may not derive from <tt>integral_constant</tt>, and the +places where <tt>is_bind_expression</tt> and <tt>is_placeholder</tt> are +used intentionally do not require such derivation. +</p> +<p> +The long-term approach here is to switch to +<tt>BindExpression<E></tt> and <tt>Placeholder<P></tt> +explicit concepts, of course, but until that happens, I say leave them +alone. +</p> +</blockquote> + + + +<p><b>Proposed resolution:</b></p> +<ol> +<li> +<p> +In 20.7.12.1.1 [func.bind.isbind] change as indicated: +</p> +<blockquote><pre>namespace std { + template<class T> struct is_bind_expression <ins>: integral_constant<bool, <i>see below</i>> { };</ins><del>{ + static const bool value = <i>see below</i>; + };</del> +} +</pre></blockquote> +</li> +<li> +<p> +In 20.7.12.1.1 [func.bind.isbind]/2 change as indicated: +</p> +<blockquote><pre><del>static const bool value;</del> +</pre> +<blockquote> +-2- <del><tt>true</tt> if <tt>T</tt> is a type returned from <tt>bind</tt>, <tt>false</tt> otherwise.</del> + <ins>If <tt>T</tt> is a type returned from <tt>bind</tt>, <tt>is_bind_expression<T></tt> shall +be publicly derived from + <tt>integral_constant<bool, true></tt>, otherwise it shall be +publicly derived from + <tt>integral_constant<bool, false></tt>.</ins> +</blockquote> +</blockquote> +</li> +<li> +<p> +In 20.7.12.1.2 [func.bind.isplace] change as indicated: +</p> +<blockquote><pre>namespace std { + template<class T> struct is_placeholder <ins>: integral_constant<int, <i>see below</i>> { };</ins><del>{ + static const int value = <i>see below</i>; + };</del> +} </pre></blockquote> +</li> +<li> +<p> +In 20.7.12.1.2 [func.bind.isplace]/2 change as indicated: +</p> +<blockquote><pre><del>static const int value;</del> +</pre> +<blockquote> +-2- <del>value is <tt>J</tt> if <tt>T</tt> is the type of <tt>std::placeholders::_J</tt>, 0 otherwise.</del> + <ins>If <tt>T</tt> is the type of <tt>std::placeholders::_J</tt>, <tt>is_placeholder<T></tt> +shall be publicly + derived from <tt>integral_constant<int, J></tt> otherwise it shall +be publicly derived + from <tt>integral_constant<int, 0></tt>.</ins> +</blockquote> +</blockquote> +</li> +</ol> <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> +<h3><a name="1072"></a>1072. Is std::hash a constrained template or not?</h3> +<p><b>Section:</b> 20.7.17 [unord.hash] <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>Opened:</b> 2009-03-19 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord.hash">active issues</a> in [unord.hash].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.hash">issues</a> in [unord.hash].</p> +<p><b>View all 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> -No relationship between <tt>U</tt> and <tt>T</tt> in the converting constructor for <tt>default_delete</tt> template. +Is <tt>std::hash</tt> a constrained template or not? </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. +According to Class template hash 20.7.17 [unord.hash], the definition is: </p> + +<blockquote><pre>template <class T> +struct hash : public std::unary_function<T, std::size_t> { + std::size_t operator()(T val) const; +}; +</pre></blockquote> + <p> -Rules out cross-casting. +And so unconstrained. </p> <p> -The requirements for <tt>unique_ptr</tt> conversions should be the same as those on the deleter. +According to the <tt><functional></tt> synopsis in p2 Function objects +20.7 [function.objects] the template is declared as: </p> +<blockquote><pre>template <ReferentType T> struct hash; +</pre></blockquote> + +<p> +which would make hash a constrained template. +</p> + +<p><i>[ +2009-03-22 Daniel provided wording. +]</i></p> + + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +<p> +Alisdair is not certain that Daniel's proposed resolution is sufficient, +and recommends we leave the hash template unconstrained for now. +</p> +<p> +Recommend that the Project Editor make the constrained declaration consistent +with the definition in order to make the Working Paper internally consistent, +and that the issue then be revisited. +</p> +<p> +Move to Open. +</p> +</blockquote> + <p><b>Proposed resolution:</b></p> + <p> -Change 20.7.11.1.1 [unique.ptr.dltr.dflt]: +[To the editor: This resolution is merge-compatible to the +resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1078">1078</a>] </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; - }; +<ol> +<li> +<p> +In 20.7 [function.objects]/2, header <tt><functional></tt> synopsis, change as indicated: +</p> + +<blockquote><pre>// 20.6.17, hash function base template: +template <ReferentType T> struct hash; <ins>// undefined</ins> +</pre></blockquote> +</li> +<li> +<p> +In 20.7.17 [unord.hash]/1 change as indicated: +</p> +<blockquote><pre>namespace std { + <del>template <class T> + struct hash : public std::unary_function<T, std::size_t> { + std::size_t operator()(T val) const; + };</del> + <ins>template <ReferentType T> struct hash; // undefined</ins> } </pre></blockquote> +</li> +<li> +<p> +In 20.7.17 [unord.hash]/2 change as indicated: +</p> + +<blockquote> +-2- <ins>For all library-provided specializations, the template +instantiation <tt>hash<T></tt> + shall provide a public <tt>operator()</tt> with return type <tt>std::size_t</tt> to +satisfy the concept + requirement <tt>Callable<const hash<T>, const T&></tt>. If <tt>T</tt> is an object +type or reference to + object, <tt>hash<T></tt> shall be publicly derived from +<tt>std::unary_function<T, std::size_t></tt>. + </ins> The return value of <tt>operator()</tt> is unspecified, except that +equal arguments + shall yield the same result. <tt>operator()</tt> shall not throw exceptions. +</blockquote> +</li> +<li> +<p> +In 18.7 [support.rtti]/1, header <tt><typeinfo></tt> synopsis change as indicated: +</p> +<blockquote><pre>namespace std { + class type_info; + class type_index; + template <<del>class</del><ins>ReferentType</ins> T> struct hash; +</pre></blockquote> +</li> +</ol> + + + + + +<hr> +<h3><a name="1073"></a>1073. Declaration of <tt>allocator_arg</tt> should be <tt>constexpr</tt></h3> +<p><b>Section:</b> 20.8 [memory] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-19 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#memory">active issues</a> in [memory].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#memory">issues</a> in [memory].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p> +<p><b>Discussion:</b></p> <p> -... +Declaration of <tt>allocator_arg</tt> should be <tt>constexpr</tt> to ensure constant +initialization. </p> -<blockquote><pre>template <class U> - <ins>requires Convertible<U*, T*> && HasVirtualDestructor<T></ins> - default_delete(const default_delete<U>& other); +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +We agree with the proposed resolution. Move to Tentatively Ready. +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +Change 20.8 [memory] p2: +</p> + +<blockquote><pre>// 20.8.1, allocator argument tag +struct allocator_arg_t { }; +const<ins>expr</ins> allocator_arg_t allocator_arg = allocator_arg_t(); </pre></blockquote> @@ -17440,222 +31842,954 @@ Change 20.7.11.1.1 [unique.ptr.dltr.dflt]: <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> +<h3><a name="1074"></a>1074. concept map broken by N2840</h3> +<p><b>Section:</b> 20.8.3 [allocator.element.concepts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">Tentatively NAD</a> + <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-19 <b>Last modified:</b> 2009-05-23</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD">Tentatively NAD</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. +p7 Allocator-related element concepts 20.8.3 [allocator.element.concepts] </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. +The changes to the <tt>AllocatableElement</tt> concept mean this <tt>concept_map</tt> +specialization no longer matches the original concept: </p> + +<blockquote><pre>template <Allocator Alloc, class T, class ... Args> + requires HasConstructor<T, Args...> + concept_map AllocatableElement<Alloc, T, Args&&...> { + void construct_element(Alloc& a, T* t, Args&&... args) { + Alloc::rebind<T>(a).construct(t, forward(args)...); + } + } +</pre></blockquote> + +<p><i>[ +2009-03-23 Pablo adds: +]</i></p> + + +<blockquote> +Actually, this is incorrect, +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2840.pdf">N2840</a> +says. "In section +20.8.3 [allocator.element.concepts] paragraph 8, modify the definition of the +<tt>AllocatableElement</tt> concept and eliminate the related concept map:" but +then neglects to include the red-lined text of the concept map that was +to be eliminated. Pete also missed this, but I caught it he asked me to +review his edits. Pete's updated WP removes the concept map entirely, +which was the original intent. The issue is, therefore, moot. Note, as +per my presentation of +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2840.pdf">N2840</a> +in summit, <tt>construct()</tt> no longer has a +default implementation. This regrettable fact was deemed (by David +Abrahams, Doug, and myself) to be preferable to the complexity of +providing a default implementation that would not under-constrain a more +restrictive allocator (like the scoped allocators). +</blockquote> + +<p><i>[ +2009-05-01 Daniel adds: +]</i></p> + +<blockquote> <p> -A simple picture of a deque: +it seems to me that #1074 should be resolved as a NAD, because the +current WP has already removed the previous AllocatableElement concept map. +It introduced auto concept AllocatableElement instead, but as of +20.8.3 [allocator.element.concepts]/7 this guy contains now </p> -<blockquote><pre>A-----|----|-----|---F+|++++|++B--|-----|-----Z +<blockquote><pre>requires FreeStoreAllocatable<T>; +void Alloc::construct(T*, Args&&...); </pre></blockquote> +</blockquote> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<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>. +The affected code is no longer part of the Working Draft. </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). +Move to NAD. </p> +</blockquote> + + +<p><b>Proposed resolution:</b></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: +Change 20.8.3 [allocator.element.concepts]: </p> +<blockquote><pre>template <Allocator Alloc, class T, class ... Args> + requires HasConstructor<T, Args...> + concept_map AllocatableElement<Alloc, T, Args&&...> { + void construct_element(<del>Alloc& a,</del> T* t, Args&&... args) { + Alloc::rebind<T>(a).construct(t, forward(args)...); + } + } +</pre></blockquote> -<p><b>Proposed resolution:</b></p> + + + + +<hr> +<h3><a name="1075"></a>1075. Response to US 65, US 74.1</h3> +<p><b>Section:</b> 20 [utilities], 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> Alan Talbot <b>Opened:</b> 2009-03-20 <b>Last modified:</b> 2009-06-10</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#utilities">issues</a> in [utilities].</p> +<p><b>View all 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><b>Addresses US 65 and US 74.1</b></p> + +<p>US 65:</p> + +<blockquote> +Scoped allocators and allocator propagation traits add a small amount of +utility at the cost of a great deal of machinery. The machinery is user +visible, and it extends to library components that don't have any +obvious connection to allocators, including basic concepts and simple +components like <tt>pair</tt> and <tt>tuple</tt>. + +<p>Suggested resolution:</p> <p> -Add new signatures to synopsis in 23.2.2 [deque]: +Sketch of proposed resolution: Eliminate scoped allocators, replace +allocator propagation traits with a simple uniform rule (e.g. always +propagate on copy and move), remove all mention of allocators from +components that don't explicitly allocate memory (e.g. pair), and adjust +container interfaces to reflect this simplification. </p> +<p> +Components that I propose eliminating include HasAllocatorType, +is_scoped_allocator, allocator_propagation_map, scoped_allocator_adaptor, +and ConstructibleAsElement. +</p> +</blockquote> -<blockquote><pre>size_type capacity() const; -bool reserve(size_type n); -</pre></blockquote> +<p>US 74.1:</p> + +<blockquote> +<p> +Scoped allocators represent a poor trade-off for standardization, since +(1) scoped-allocator--aware containers can be implemented outside the +C++ standard library but used with its algorithms, (2) scoped +allocators only benefit a tiny proportion of the C++ community +(since few C++ programmers even use today's allocators), and (3) all C++ +users, especially the vast majority of the C++ community that won't ever +use scoped allocators are forced to cope with the interface complexity +introduced by scoped allocators. +</p> +<p> +In essence, the larger community will suffer to support a very small +subset of the community who can already implement their own +data structures outside of the standard library. Therefore, scoped +allocators should be removed from the working paper. +</p> +<p> +Some evidence of the complexity introduced by scoped allocators: +</p> +<blockquote> +<p> +20.3.3 [pairs], 20.5 [tuple]: Large increase in the +number of pair and tuple constructors. +</p> +<p> +23 [containers]: Confusing "AllocatableElement" requirements throughout. +</p> +</blockquote> +<p>Suggested resolution:</p> <p> -Add new signatures to 23.2.2.2 [deque.capacity]: +Remove support for scoped allocators from the working paper. This +includes at least the following changes: </p> <blockquote> -<pre>size_type capacity() const; -</pre> +<p> +Remove 20.8.3 [allocator.element.concepts] +</p> +<p> +Remove 20.8.7 [allocator.adaptor] +</p> +<p> +Remove 20.8.10 [construct.element] +</p> +<p> +In Clause 23 [containers]: replace requirements naming the +<tt>AllocatableElement</tt> concept with requirements naming <tt>CopyConstructible</tt>, +<tt>MoveConstructible</tt>, <tt>DefaultConstructible</tt>, or <tt>Constructible</tt>, as +appropriate. +</p> +</blockquote> + +</blockquote> + +<p><i>[ +Post Summit Alan moved from NAD to Open. +]</i></p> + + +<p><i>[ +2009-05-15 Ganesh adds: +]</i></p> + + <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. +The requirement <tt>AllocatableElement</tt> should not be replaced with +<tt>Constructible</tt> on the <tt>emplace_xxx()</tt> functions as suggested. In the +one-parameter case the <tt>Constructible</tt> requirement is not satisfied when +the constructor is explicit (as per 14.10.2.1 [concept.map.fct], twelfth +bullet) but we do want to allow explicit constructors in emplace, as the +following example shows: +</p> + +<blockquote><pre>vector<shared_ptr<int>> v; +v.emplace_back(new int); <font color="#c80000">// should be allowed</font> +</pre></blockquote> + +<p> +If the issue is accepted and scoped allocators are removed, I suggest to +add a new pair of concepts to 20.2.7 [concept.construct], namely: </p> + +<blockquote><pre>auto concept HasExplicitConstructor<typename T, typename... Args> { + explicit T::T(Args...); +} + +auto concept ExplicitConstructible<typename T, typename... Args> + : HasExplicitConstructor<T, Args...>, NothrowDestructible<T> +{ } +</pre></blockquote> + <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. +We should then use <tt>ExplicitConstructible</tt> as the requirement for all +<tt>emplace_xxx()</tt> member functions. +</p> +<p> +For coherence and consistency with the similar concepts +<tt>Convertible/ExplicitlyConvertible</tt>, we might also consider changing +<tt>Constructible</tt> to: +</p> + +<blockquote><pre>auto concept Constructible<typename T, typename... Args> + : HasConstructor<T, Args...>, ExplicitConstructible<T, Args...> +{ } +</pre></blockquote> + +<p> +Moreover, all emplace-related concepts in 23.2.6 [container.concepts] +should also use <tt>ExplicitConstructible</tt> instead of <tt>Constructible</tt> in the +definitions of their axioms. In fact the concepts in 23.2.6 [container.concepts] should be +corrected even if the issue is not accepted. +</p> +<p> +On the other hand, if the issue is not accepted, the scoped allocator +adaptors should be fixed because the following code: +</p> + +<blockquote><pre>template <typename T> using scoped_allocator = scoped_allocator_adaptor<allocator<T>>; + +vector<shared_ptr<int>, scoped_allocator<shared_ptr<int>>> v; +v.emplace_back(new int); <font color="#c80000">// ops! doesn't compile</font> +</pre></blockquote> + +<p> +doesn't compile, as the member function <tt>construct()</tt> of the scoped +allocator requires non-explicit constructors through concept +<tt>ConstructibleWithAllocator</tt>. Fixing that is not difficult but probably +more work than it's worth and is therefore, IMHO, one more reason in +support of the complete removal of scoped allocators. </p> </blockquote> + +<p><i>[ +2009-06-09 Alan adds: +]</i></p> + + +<blockquote> +<p> +I reopened this issue because I did not think that these National Body +comments were adequately addressed by marking them NAD. My understanding +is that something can be marked NAD if it is clearly a misunderstanding +or trivial, but a substantive issue that has any technical merit +requires a disposition that addresses the concerns. +</p> +<p> +The notes in the NB comment list (US 65 & US 74.1) say that: +</p> +<ol type="a"> +<li> +this issue has not introduced any new arguments not previously discussed, +</li> +<li> +the vote (4-9-3) was not a consensus for removing scoped allocators, +</li> +<li> +the issue is resolved by +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2840.pdf">N2840</a>. +</li> +</ol> +<p> +My opinion is: +</p> +<ol type="a"> +<li> +there are new arguments in both comments regarding concepts (which were +not present in the library when the scoped allocator proposal was voted +in), +</li> +<li> +the vote was clearly not a consensus for removal, but just saying there +was a vote does not provide a rationale, +</li> +<li> +I do not believe that N2840 addresses these comments (although it does +many other things and was voted in with strong approval). +</li> +</ol> + +<p> +My motivation to open the issue was to ensure that the NB comments were +adequately addressed in a way that would not risk a "no" vote on our +FCD. If there are responses to the technical concerns raised, then +perhaps they should be recorded. If the members of the NB who authored +the comments are satisfied with N2840 and the other disposition remarks +in the comment list, then I am sure they will say so. In either case, +this issue can be closed very quickly in Frankfurt, and hopefully will +have helped make us more confident of approval with little effort. If in +fact there is controversy, my thought is that it is better to know now +rather than later so there is more time to deal with it. +</p> </blockquote> + + +<p><b>Proposed resolution:</b></p> + + + + + +<hr> +<h3><a name="1076"></a>1076. unary/binary_negate need constraining and move support</h3> +<p><b>Section:</b> 20.7.11 [negators] <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>Opened:</b> 2009-03-20 <b>Last modified:</b> 2009-05-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> +The class templates <tt>unary/binary_negate</tt> need constraining and move support. +</p> +<p> +Ideally these classes would be deprecated, allowing <tt>unary/binary_function</tt> to +also be deprecated. However, until a generic negate adaptor is introduced +that can negate any <tt>Callable</tt> type, they must be supported so should be +constrained. Likewise, they should be movable, and support adopting a +move-only predicate type. +</p> +<p> +In order to preserve ABI compatibility, new rvalue overloads are supplied in +preference to changing the existing pass-by-const-ref to pass-by-value. +</p> +<p> +Do not consider the issue of forwarding mutable lvalues at this point, +although remain open to another issue on the topic. +</p> + +<p><i>[ +2009-05-01 Daniel adds: +]</i></p> + <blockquote> -<pre>bool reserve(size_type n); +<p> +IMO the currently proposed resolution needs some updates +because it is ill-formed at several places: +</p> + +<ol> +<li> +<p> +In concept AdaptableUnaryFunction change +</p> +<blockquote><pre>typename X::result_type; +typename X::argument_type; +</pre></blockquote> +<p> +to +</p> +<blockquote><pre>Returnable result_type = typename X::result_type; +typename argument_type = typename X::argument_type; +</pre></blockquote> +<p> +[The replacement "Returnable result_type" instead of "typename +result_type" is non-editorial, but maybe you prefer that as well] +</p> +</li> +<li> +<p> +In concept AdaptableBinaryFunction change +</p> +<blockquote><pre>typename X::result_type; +typename X::first_argument_type; +typename X::second_argument_type; +</pre></blockquote> +<p> +to +</p> +<blockquote><pre>Returnable result_type = typename X::result_type; +typename first_argument_type = typename X::first_argument_type; +typename second_argument_type = typename X::second_argument_type; +</pre></blockquote> +<p> +[The replacement "Returnable result_type" instead of "typename +result_type" is non-editorial, but maybe you prefer that as well.] +</p> +</li> + +<li> +<p> +In class unary/binary_function +</p> +<ol type="a"> +<li> +I suggest to change "ReturnType" to "Returnable" in both cases. +</li> +<li> +I think you want to replace the remaining occurrences of "Predicate" by "P" +(in both classes in copy/move from a predicate) +</li> +</ol> +</li> +<li> +<p> +I think you need to change the proposed signatures of not1 and not2, because +they would still remain unconstrained: To make them constrained at least a +single requirement needs to be added to enable requirement implication. This +could be done via a dummy ("requires True<true>") or just explicit as follows: +</p> +<ol type="a"> +<li> +<blockquote><pre>template <AdaptableUnaryFunction P> +requires Predicate< P, P::argument_type> +unary_negate<P> not1(const P&& pred); +template <AdaptableUnaryFunction P> +requires Predicate< P, P::argument_type > +unary_negate<P> not1(P&& pred); </pre> <blockquote> +-3- Returns: unary_negate<P>(pred). +</blockquote> +</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. +[Don't we want a move call for the second overload as in </p> +<blockquote><pre>unary_negate<P>(std::move(pred)) +</pre></blockquote> <p> -3 <i>Returns:</i> <tt>true</tt> if iterators are invalidated as a result of this -operation, and false otherwise. +in the Returns clause ?] </p> +</li> +<li> +<pre>template <AdaptableBinaryFunction P> +requires Predicate< P, P::first_argument_type, P::second_argument_type > +binary_negate<P> not2(const P& pred); +template <AdaptableBinaryFunction P> +requires Predicate< P, P::first_argument_type, P::second_argument_type > +binary_negate<P> not2(P&& pred); +</pre> <p> -4 <i>Complexity:</i> It does not change the size of the sequence and takes -at most linear time in <tt>n</tt>. +-5- Returns: binary_negate<P>(pred). </p> <p> -5 <i>Throws:</i> <tt>length_error</tt> if <tt>n > max_size()</tt>. +[Don't we want a move call for the second overload as in </p> +<blockquote><pre>binary_negate<P>(std::move(pred)) +</pre></blockquote> <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>. +in the Returns clause ?] </p> +</li> +</ol> +</li> +</ol> +</blockquote> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> <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. +There is concern that complicating the solution +to preserve the ABI seems unnecessary, +since we're not in general preserving the ABI. +</p> +<p> +We would prefer a separate paper consolidating all Clause 20 +issues that are for the purpose of providing constrained versions +of the existing facilities. +</p> +<p> +Move to Open. </p> </blockquote> -</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +Add new concepts where appropriate:: +</p> + +<blockquote><pre>auto concept AdaptableUnaryFunction< typename X > { + typename X::result_type; + typename X::argument_type; +} + +auto concept AdaptableBinaryFunction< typename X > { + typename X::result_type; + typename X::first_argument_type; + typename X::second_argument_type; +} +</pre></blockquote> + +<p> +Revise as follows: +</p> + +<p> +Base 20.7.3 [base] (Only change is constrained Result) +</p> + +<blockquote> +<p> +-1- The following classes are provided to simplify the typedefs of the +argument and result types: +</p> +<pre>namespace std { + template <class Arg, <del>class</del> <ins>ReturnType</ins> Result> + struct unary_function { + typedef Arg argument_type; + typedef Result result_type; + }; + + template <class Arg1, class Arg2, <del>class</del> <ins>ReturnType</ins> Result> + struct binary_function { + typedef Arg1 first_argument_type; + typedef Arg2 second_argument_type; + typedef Result result_type; + }; +} +</pre></blockquote> <p> -And 23.2.2.3 [deque.modifiers] para 1, can be enhanced: +Negators 20.7.11 [negators]: </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. +<p> +-1- Negators <tt>not1</tt> and <tt>not2</tt> take a unary and a binary predicate, +respectively, and return their complements (5.3.1). +</p> + +<pre>template <<del>class</del> <ins>AdaptableUnaryFunction</ins> P<del>redicate</del>> + <ins>requires Predicate< P, P::argument_type ></ins> + class unary_negate + : public unary_function<<del>typename</del> P<del>redicate</del>::argument_type,bool> { + public: + <ins>unary_negate(const unary_negate & ) = default;</ins> + <ins>unary_negate(unary_negate && );</ins> + + <ins>requires CopyConstructible< P ></ins> + explicit unary_negate(const Predicate& pred); + <ins>requires MoveConstructible< P > + explicit unary_negate(Predicate && pred);</ins> + + bool operator()(const <del>typename</del> P<del>redicate</del>::argument_type& x) const; + }; +</pre> +<blockquote> +-2 <tt>operator()</tt> returns <tt>!pred(x)</tt>. +</blockquote> + +<pre>template <class Predicate> + unary_negate<Predicate> not1(const Predicate&amp; pred); +<ins>template <class Predicate> + unary_negate<Predicate> not1(Predicate&& pred);</ins> +</pre> +<blockquote> +-3- <i>Returns:</i> <tt>unary_negate<Predicate>(pred)</tt>. +</blockquote> + +<pre>template <<del>class</del> <ins>AdaptableBinaryFunction</ins> P<del>redicate</del> > + <ins>requires Predicate< P, P::first_argument_type, P::second_argument_type ></ins> + class binary_negate + : public binary_function<<del>typename</del> P<del>redicate</del>::first_argument_type, + <del>typename</del> P<del>redicate</del>::second_argument_type, bool> { + public: + <ins>biary_negate(const binary_negate & ) = default;</ins> + <ins>binary_negate(binary_negate && );</ins> + + <ins>requires CopyConstructible< P ></ins> + explicit binary_negate(const Predicate& pred); + <ins>requires MoveConstructible< P > + explicit binary_negate(const Predicate& pred);</ins> + + bool operator()(const <del>typename</del> P<del>redicate</del>::first_argument_type& x, + const <del>typename</del> P<del>redicate</del>::second_argument_type& y) const; + }; +</pre> +<blockquote> +-4- <tt>operator()</tt> returns <tt>!pred(x,y)</tt>. +</blockquote> + +<pre>template <class Predicate> + binary_negate<Predicate> not2(const Predicate& pred); +<ins>template <class Predicate> + binary_negate<Predicate> not2(Predicate&& pred);</ins> +</pre> + +<blockquote> +-5- <i>Returns:</i> <tt>binary_negate<Predicate>(pred)</tt>. +</blockquote> </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> +<h3><a name="1077"></a>1077. Nonesense <tt>tuple</tt> declarations</h3> +<p><b>Section:</b> 20.5.2 [tuple.tuple] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Tentatively NAD Editorial</a> + <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-03-20 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#tuple.tuple">active issues</a> in [tuple.tuple].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple.tuple">issues</a> in [tuple.tuple].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD%20Editorial">Tentatively NAD Editorial</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. +Class template tuple 20.5.2 [tuple.tuple]: </p> +<blockquote><pre>template <class... UTypes> + requires Constructible<Types, const UTypes&>... +template <class... UTypes> + requires Constructible<Types, RvalueOf<UTypes>::type>... +</pre></blockquote> + +<p> +Somebody needs to look at this and say what it should be. +</p> + +<p><i>[ +2009-03-21 Daniel provided wording. +]</i></p> + + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +The resolution looks correct; move to NAD Editorial. +</blockquote> + <p><b>Proposed resolution:</b></p> <p> -Remove the following signature from 20.5.2 [meta.type.synop]: +In 20.5.2 [tuple.tuple], class <tt>tuple</tt>, change as indicated: </p> -<blockquote><pre>template <std::size_t Len, class... Types> struct aligned_union; + +<blockquote><pre>template <class... UTypes> + requires Constructible<Types, const UTypes&>... + <ins>tuple(const pair<UTypes...>&);</ins> +template <class... UTypes> + requires Constructible<Types, RvalueOf<UTypes>::type>... + <ins>tuple(pair<UTypes...>&&);</ins> </pre></blockquote> <p> -Remove the second row from table 51 in 20.5.7 [meta.trans.other], -starting with: +[NB.: The corresponding prototypes do already exist in 20.5.2.1 [tuple.cnstr]/7+8] +</p> + + + + + +<hr> +<h3><a name="1078"></a>1078. DE-17: Remove class type_index</h3> +<p><b>Section:</b> 18.7.2 [type.index] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> + <b>Submitter:</b> Doug Gregor <b>Opened:</b> 2009-03-20 <b>Last modified:</b> 2009-03-31</p> +<p><b>View all 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><b>Addresses DE 17</b></p> + +<p> +DE-17: +</p> +<p> +The class <tt>type_index</tt> should be removed; it provides no additional +functionality beyond providing appropriate concept maps. +</p> + +<p><i>[ +2009-03-31 Peter adds: +]</i></p> + + +<blockquote> +<p> +It is not true, in principle, that <tt>std::type_index</tt> provides no utility +compared to bare <tt>std::type_info*</tt>. +</p> +<p> +<tt>std::type_index</tt> can avoid the lifetime issues with <tt>type_info</tt> when the +DLL that has produced the <tt>type_info</tt> object is unloaded. A raw +<tt>type_info*</tt> does not, and cannot, provide any protection in this case. +A <tt>type_index</tt> can (if the implementor so chooses) because it can wrap a +smart (counted or even cloning) pointer to the <tt>type_info</tt> data that is +needed for <tt>name()</tt> and <tt>before()</tt> to work. </p> +</blockquote> + + + +<p><b>Proposed resolution:</b></p> +<p>Modify the header <typeinfo> synopsis in + 18.7 [support.rtti]p1 as follows:</p> -<blockquote><pre>template <std::size_t Len, -class... Types> -struct aligned_union; +<blockquote><pre>namespace std { + class type_info; + <del>class type_index;</del> + template <class T> struct hash; + template<> struct hash<<del>type_index</del><ins>const type_info *</ins>> : public std::unary_function<<del>type_index</del><ins>const type_info *</ins>, size_t> { + size_t operator()(<del>type_index</del><ins>const type_info *</ins> <del>index</del><ins>t</ins>) const; + }<ins>;</ins> + <ins>concept_map LessThanComparable<const type_info *> <i>see below</i></ins> + class bad_cast; + class bad_typeid; +} </pre></blockquote> +<p>Add the following new subsection</p> +<blockquote> +<p> +<ins>18.7.1.1 Template specialization <code>hash<const type_info *></code> +[type.info.hash]</ins></p> + +<pre><ins>size_t operator()(const type_info *x) const;</ins> +</pre> +<ol> +<li><ins><i>Returns</i>: <code>x->hash_code()</code></ins></li> +</ol> +</blockquote> + + <p>Add the following new subsection</p> + <blockquote> +<p><ins>18.7.1.2 <code>type_info</code> concept map [type.info.concepts]</ins></p> + + +<pre><ins>concept_map LessThanComparable<const type_info *> {</ins> + <ins>bool operator<(const type_info *x, const type_info *y) { return x->before(*y); }</ins> + <ins>bool operator<=(const type_info *x, const type_info *y) { return !y->before(*x); }</ins> + <ins>bool operator>(const type_info *x, const type_info *y) { return y->before(*x); }</ins> + <ins>bool operator>=(const type_info *x, const type_info *y) { return !x->before(*y); }</ins> +<ins>}</ins> +</pre> +<ol> + <li><ins><i>Note</i>: provides a well-defined ordering among + <code>type_info const</code> pointers, which makes such pointers + usable in associative containers (23.4).</ins></li> +</ol> +</blockquote> + +<p>Remove section 18.7.2 [type.index]</p> + <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> +<h3><a name="1079"></a>1079. UK-265: <code>RandomAccessIterator</code>'s <code>operator-</code> has nonsensical effects clause</h3> +<p><b>Section:</b> 24.2.6 [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> Doug Gregor <b>Opened:</b> 2009-03-20 <b>Last modified:</b> 2009-03-22</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#random.access.iterators">active issues</a> in [random.access.iterators].</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><b>Addresses UK 265</b></p> + +<p>UK-265:</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. +This effects clause is nonesense. It looks more like an axiom stating +equivalence, and certainly an effects clause cannot change the state of +two arguments passed by const reference </p> + + + +<p><b>Proposed resolution:</b></p> + +<p>Modify 24.2.6 [random.access.iterators]p7-9 as follows:</p> + +<blockquote><pre>difference_type operator-(const X& a, const X& b); +</pre> +<ol start="7"> + <li><i>Precondition</i>: there exists a value <code>n</code> of + <code>difference_type</code> such that <code>a == b + n</code>.</li> + <li><del><i>Effects</i>: <code>b == a + (b - a)</code></del></li> + <li><i>Returns</i>: <del><code>(a < b) ? distance(a,b) : + -distance(b,a)</code></del><ins><code>n</code></ins></li> +</ol> +</blockquote> + + + + + +<hr> +<h3><a name="1080"></a>1080. Concept ArithmeticLike should provide explicit boolean conversion</h3> +<p><b>Section:</b> 20.2.13 [concept.arithmetic] <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>Opened:</b> 2009-03-21 <b>Last modified:</b> 2009-05-23</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> -It might be simpler to change the return type to a scoped enum: +Astonishingly, the current concept ArithmeticLike as specified in +20.2.13 [concept.arithmetic] does not provide explicit conversion +to <tt>bool</tt> although this is a common property of arithmetic types +(4.12 [conv.bool]). Recent proposals that introduced such types +(integers of arbitrary precision, +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2143.pdf">n2143</a>, +decimals +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2732.pdf">n2732</a> +indirectly +via conversion to <tt>long long</tt>) also took care of such a feature. +</p> +<p> +Adding such an explicit conversion associated function would also +partly solve a currently invalid effects clause in library, which bases +on this property, 24.2.6 [random.access.iterators]/2: +</p> +<blockquote><pre>{ difference_type m = n; + if (m >= 0) while (m--) ++r; + else while (m++) --r; + return r; } +</pre></blockquote> + +<p> +Both while-loops take advantage of a contextual conversion to <tt>bool</tt> +(Another problem is that the >= comparison uses the no +longer supported existing implicit conversion from <tt>int</tt> to <tt>IntegralLike</tt>). </p> -<blockquote><pre>enum class timeout { not_reached, reached }; + +<b>Original proposed resolution:</b> +<ol> +<li> +<p> +In 20.2.13 [concept.arithmetic], add to the list of less refined +concepts one further concept: +</p> + +<blockquote><pre>concept ArithmeticLike<typename T> + : Regular<T>, LessThanComparable<T>, HasUnaryPlus<T>, HasNegate<T>, + HasPlus<T, T>, HasMinus<T, T>, HasMultiply<T, T>, HasDivide<T, T>, + HasPreincrement<T>, HasPostincrement<T>, HasPredecrement<T>, + HasPostdecrement<T>, + HasPlusAssign<T, const T&>, HasMinusAssign<T, const T&>, + HasMultiplyAssign<T, const T&>, + HasDivideAssign<T, const T&><ins>, ExplicitlyConvertible<T, bool></ins> { </pre></blockquote> +</li> +<li> +<p> +In 24.2.6 [random.access.iterators]/2 change the current effects clause +as indicated [The proposed insertion fixes the problem that the previous +implicit construction from integrals has been changed to an explicit +constructor]: +</p> +<blockquote><pre>{ difference_type m = n; + if (m >= <ins>difference_type(</ins>0<ins>)</ins>) while (m--) ++r; + else while (m++) --r; + return r; } +</pre></blockquote> +</li> +</ol> + +<p><i>[ +Batavia (2009-05): +]</i></p> +<blockquote> <p> -That's the same cost as returning a <tt>bool</tt>, but not subject to mistakes. Your example below would be: +We agree that arithmetic types ought be convertible to <tt>bool</tt>, +and we therefore agree with the proposed resolution's paragraph 1. </p> +<p> +We do not agree that the cited effects clause is invalid, +as it expresses intent rather than specific code. +</p> +<p> +Move to Review, pending input from concepts experts. +</p> +</blockquote> -<blockquote><pre>if (cv.wait_until(lk, time_limit) == timeout::reached ) - throw time_out(); + + +<p><b>Proposed resolution:</b></p> +<p> +In 20.2.13 [concept.arithmetic], add to the list of less refined +concepts one further concept: +</p> + +<blockquote><pre>concept ArithmeticLike<typename T> + : Regular<T>, LessThanComparable<T>, HasUnaryPlus<T>, HasNegate<T>, + HasPlus<T, T>, HasMinus<T, T>, HasMultiply<T, T>, HasDivide<T, T>, + HasPreincrement<T>, HasPostincrement<T>, HasPredecrement<T>, + HasPostdecrement<T>, + HasPlusAssign<T, const T&>, HasMinusAssign<T, const T&>, + HasMultiplyAssign<T, const T&>, + HasDivideAssign<T, const T&><ins>, ExplicitlyConvertible<T, bool></ins> { </pre></blockquote> + + + + +<hr> +<h3><a name="1081"></a>1081. Response to UK 216</h3> +<p><b>Section:</b> 21 [strings] <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>Opened:</b> 2009-03-22 <b>Last modified:</b> 2009-03-22</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><b>Addresses UK 216, JP 46, JP 48</b></p> + +<p> +All the containers use concepts for their iterator usage, exect for +<tt>basic_string</tt>. This needs fixing. +</p> + +<p> +Use concepts for iterator template parameters throughout the chapter. +</p> + <p><i>[ -Beman to supply exact wording. +Summit: ]</i></p> +<blockquote> +NB comments to be handled by Dave Abrahams and Howard Hinnant with +advice from PJP: UK216 (which duplicates) JP46, JP48. JP46 supplies +extensive proposed wording; start there. +</blockquote> <p><b>Proposed resolution:</b></p> @@ -17665,264 +32799,904 @@ Beman to supply exact wording. <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> +<h3><a name="1082"></a>1082. Response to JP 49</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> Howard Hinnant <b>Opened:</b> 2009-03-22 <b>Last modified:</b> 2009-03-22</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#localization">active issues</a> in [localization].</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><b>Addresses JP 49</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 +<tt>codecvt</tt> does not use concept. For example, create <tt>CodeConvert</tt> +concept and change as follows. </p> + +<blockquote><pre>template<CodeConvert Codecvt, class Elem = wchar_t> + class wstring_convert { +</pre></blockquote> + +<p><i>[ +Summit: +]</i></p> + <blockquote> -... for all non-null <tt>p</tt> referencing the argument is no longer declared reachable... +To be handled by Howard Hinnant, Dave Abrahams, Martin Sebor, PJ Plauger. </blockquote> + + +<p><b>Proposed resolution:</b></p> + + + + + +<hr> +<h3><a name="1083"></a>1083. Response to JP 52, 53</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> Howard Hinnant <b>Opened:</b> 2009-03-22 <b>Last modified:</b> 2009-03-22</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#localization">active issues</a> in [localization].</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><b>Addresses JP 52, JP 53</b></p> + <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. +<tt>InputIterator</tt> does not use concept. </p> + <p> -I don't know what "shall be live" in the Requires clause means. +<tt>OutputIterator</tt> does not use concept. </p> + +<p> +Comments include proposed wording. +</p> + +<p><i>[ +Summit: +]</i></p> + +<blockquote> +To be handled by Howard Hinnant, Dave Abrahams, Martin Sebor, PJ Plauger. +</blockquote> + + +<p><b>Proposed resolution:</b></p> + + + + + +<hr> +<h3><a name="1084"></a>1084. Response to UK 250</h3> +<p><b>Section:</b> 24.2.4 [forward.iterators] <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>Opened:</b> 2009-03-22 <b>Last modified:</b> 2009-06-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#Open">Open</a> status.</p> +<p><b>Discussion:</b></p> +<p><b>Addresses UK 250</b></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"? +A default implementation should be supplied for the post-increment +operator to simplify implementation of iterators by users. </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. +Copy the Effects clause into the concept description as the default +implementation. Assumes a default value for postincrement_result </p> +<p><i>[ +Summit: +]</i></p> + +<blockquote> +Howard will open an issue. +</blockquote> + +<p><i>[ +2009-06-07 Daniel adds: +]</i></p> + + +<blockquote> +This issue cannot currently be resolved as suggested, because +that would render auto-detection of the return type +<tt>postincrement_result</tt> invalid, see 14.10.2.2 [concept.map.assoc]/4+5. The +best fix would be to add a default type to that associated type, but +unfortunately any default type will prevent auto-deduction of types of +associated functions as quoted above. A corresponding core issue +is in preparation. +</blockquote> + <p><b>Proposed resolution:</b></p> +<p><i>[ +This wording assumes the acceptance of UK 251 / <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1009">1009</a>. Both +wordings change the same paragraphs. +]</i></p> + + <p> +Change 24.2.4 [forward.iterators]: </p> +<blockquote> +<pre>concept ForwardIterator<typename X> : InputIterator<X>, Regular<X> { + + MoveConstructible postincrement_result; + requires HasDereference<postincrement_result> + && Convertible<HasDereference<postincrement_result>::result_type, const value_type&>; + + postincrement_result operator++(X& r, int)<del>;</del> <ins>{ + X tmp = r; + ++r; + return tmp; + }</ins> + + axiom MultiPass(X a, X b) { + if (a == b) *a == *b; + if (a == b) ++a == ++b; + } +} +</pre></blockquote> + + <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> +<h3><a name="1085"></a>1085. Response to UK 258</h3> +<p><b>Section:</b> 24.2.5 [bidirectional.iterators] <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>Opened:</b> 2009-03-22 <b>Last modified:</b> 2009-06-09</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><b>Addresses UK 258</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. +A default implementation should be supplied for the post-decrement +operator to simplify implementation of iterators by users. </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 +Copy the Effects clause into the concept description as the default +implementation. Assumes a default value for postincrement_result </p> -<blockquote><pre>wait_until(lock, chrono::monotonic_clock::now() + rel_time) -</pre></blockquote> +<p><i>[ +Summit: +]</i></p> + +<blockquote> +Howard will open an issue. +</blockquote> + +<p><i>[ +2009-06-07 Daniel adds: +]</i></p> + + +<blockquote> +This issue cannot currently be resolved as suggested, because +that would render auto-detection of the return type +<tt>postdecrement_result</tt> invalid, see <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1084">1084</a>. +</blockquote> + + +<p><b>Proposed resolution:</b></p> <p> -when <tt>monotonic_clock</tt> is not required to exist? +Change 24.2.5 [bidirectional.iterators]: </p> +<blockquote> +<pre>concept BidirectionalIterator<typename X> : ForwardIterator<X> { + MoveConstructible postdecrement_result; + requires HasDereference<postdecrement_result> + && Convertible<HasDereference<postdecrement_result>::result_type, const value_type&> + && Convertible<postdecrement_result, const X&>; + X& operator--(X&); + postdecrement_result operator--(X& <ins>r</ins>, int)<del>;</del> <ins>{ + X tmp = r; + --r; + return tmp; + }</ins> +} +</pre></blockquote> + + + + + + +<hr> +<h3><a name="1086"></a>1086. Response to UK 284</h3> +<p><b>Section:</b> 24.6 [stream.iterators] <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>Opened:</b> 2009-03-22 <b>Last modified:</b> 2009-03-22</p> +<p><b>View all 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><b>Addresses UK 284</b></p> -<p><b>Proposed resolution:</b></p> <p> +The stream iterators need constraining with concepts/requrires clauses. </p> +<p><i>[ +Summit: +]</i></p> + +<blockquote> +We agree. To be handled by Howard, Martin and PJ. +</blockquote> + + +<p><b>Proposed resolution:</b></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> +<h3><a name="1087"></a>1087. Response to UK 301</h3> +<p><b>Section:</b> 25.4.5 [alg.replace] <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>Opened:</b> 2009-03-22 <b>Last modified:</b> 2009-06-11</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#alg.replace">active issues</a> in [alg.replace].</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#Review">Review</a> status.</p> <p><b>Discussion:</b></p> +<p><b>Addresses UK 301</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. +<tt>replace</tt> and <tt>replace_if</tt> have the requirement: <tt>OutputIterator<Iter, +Iter::reference></tt> Which implies they need to copy some values in the +range the algorithm is iterating over. This is not however the case, the +only thing that happens is <tt>const T&</tt>s might be copied over existing +elements (hence the <tt>OutputIterator<Iter, const T&></tt>. +</p> + +<p> +Remove <tt>OutputIterator<Iter, Iter::reference></tt> from <tt>replace</tt> +and <tt>replace_if</tt>. </p> +<p><i>[ +Summit: +]</i></p> + +<blockquote> +We agree. To be handled by Howard. +</blockquote> + <p><b>Proposed resolution:</b></p> <p> +Change in 25.2 [algorithms.syn] and 25.4.5 [alg.replace]: </p> +<blockquote><pre>template<ForwardIterator Iter, class T> + requires <del>OutputIterator<Iter, Iter::reference> + &&</del> OutputIterator<Iter, const T&> + && HasEqualTo<Iter::value_type, T> + void replace(Iter first, Iter last, + const T& old_value, const T& new_value); + +template<ForwardIterator Iter, Predicate<auto, Iter::value_type> Pred, class T> + requires <del>OutputIterator<Iter, Iter::reference> + &&</del> OutputIterator<Iter, const T&> + && CopyConstructible<Pred> + void replace_if(Iter first, Iter last, + Pred pred, const T& new_value); +</pre></blockquote> + <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> +<h3><a name="1088"></a>1088. Response to UK 342</h3> +<p><b>Section:</b> 30.6.6 [futures.promise] <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>Opened:</b> 2009-03-22 <b>Last modified:</b> 2009-03-22</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#futures.promise">active issues</a> in [futures.promise].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#futures.promise">issues</a> in [futures.promise].</p> +<p><b>View all 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><b>Addresses UK 342</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>: +<tt>std::promise</tt> is missing a non-member overload of <tt>swap</tt>. This is +inconsistent with other types that provide a <tt>swap</tt> member function. </p> +<p> +Add a non-member overload <tt>void swap(promise&& x,promise&& y){ x.swap(y); }</tt> +</p> + +<p><i>[ +Summit: +]</i></p> + <blockquote> -<tt>==</tt> is an equivalence relation. <tt>a.size() == b.size() && -equal(a.begin(), a.end(), b.begin()</tt> +Create an issue. Move to review, attention: Howard. Detlef will also +look into it. </blockquote> +<p><i>[ +Post Summit Daniel provided wording. +]</i></p> + + + +<p><b>Proposed resolution:</b></p> +<ol> +<li> <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. +In 30.6.6 [futures.promise], before p.1, immediately after class template +promise add: </p> +<blockquote><pre><ins> +template <class R> +void swap(promise<R>& x, promise<R>& y); +</ins> +</pre></blockquote> +</li> +<li> <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>. +Change 30.6.6 [futures.promise]/10 as indicated (to fix a circular definition): </p> +<blockquote> <p> -I propose to apply one of the following resolutions, which are described as: +-10- <i>Effects:</i> <del>swap(*this, other)</del><ins>Swaps the associated state +of <tt>*this</tt> and <tt>other</tt></ins> </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. +<p> +<ins><i>Throws:</i> Nothing.</ins> +</p> +</blockquote> </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. +<p> +After the last paragraph in 30.6.6 [futures.promise] add the following +prototype description: +</p> +<blockquote><pre><ins> +template <class R> +void swap(promise<R>& x, promise<R>& y); +</ins></pre> +<blockquote> +<p> +<ins><i>Effects:</i> <tt>x.swap(y)</tt></ins> +</p> +<p> +<ins><i>Throws:</i> Nothing.</ins> +</p> +</blockquote> +</blockquote> </li> + </ol> + + + + + + +<hr> +<h3><a name="1089"></a>1089. Response to JP 76</h3> +<p><b>Section:</b> 30 [thread] <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>Opened:</b> 2009-03-22 <b>Last modified:</b> 2009-03-22</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread">active issues</a> in [thread].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread">issues</a> in [thread].</p> +<p><b>View all 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><b>Addresses JP 76</b></p> + <p> -Both proposal choices are discussed, the preferred choice of the author is -to apply (A). +A description for "Throws: Nothing." are not unified. </p> +<p> +At the part without throw, "Throws: Nothing." should be described. +</p> -<p><b>Proposed resolution:</b></p> <p> -Common part: +Add "Throws: Nothing." to the following. </p> + <ul> <li> +30.3.1.6 [thread.thread.static] p1 +</li> +<li> +30.4.3.1 [thread.lock.guard] p4 +</li> +<li> +30.4.3.2.1 [thread.lock.unique.cons] p6 +</li> +<li> +30.5.1 [thread.condition.condvar] p7 and p8 +</li> +<li> +30.5.2 [thread.condition.condvarany] p6, p7, p19, p21 and p25 +</li> +</ul> + +<p><i>[ +Summit: +]</i></p> + +<blockquote> +Pass on to editor. +</blockquote> + +<p><i>[ +Post Summit: Editor declares this non-editorial. +]</i></p> + + + +<p><b>Proposed resolution:</b></p> + + + + + +<hr> +<h3><a name="1090"></a>1090. Missing description of <tt>packaged_task</tt> member <tt>swap</tt>, missing non-member <tt>swap</tt></h3> +<p><b>Section:</b> 30.6.8 [futures.task] <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>Opened:</b> 2009-03-22 <b>Last modified:</b> 2009-05-24</p> +<p><b>View all 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> -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"): +Class template <tt>packaged_task</tt> in 30.6.8 [futures.task] shows a member <tt>swap</tt> +declaration, but misses to +document it's effects (No prototype provided). Further on this class +misses to provide a non-member +swap. </p> + +<p><i>[ +Batavia (2009-05): +]</i></p> + <blockquote> -forwardlist comparison operators [forwardlist.compare] +<p> +Alisdair notes that paragraph 2 of the proposed resolution has already been +applied in the current Working Draft. +</p> +<p> +We note a pending <tt>future</tt>-related paper by Detlef; +we would like to wait for this paper before proceeding. +</p> +<p> +Move to Open. +</p> </blockquote> + +<p><i>[ +2009-05-24 Daniel removed part 2 of the proposed resolution. +]</i></p> + + + +<p><b>Proposed resolution:</b></p> +<ol> +<li> +<p> +In 30.6.8 [futures.task], immediately after the definition of class +template packaged_task add: +</p> +<blockquote><pre><ins> +template<class R, class... Argtypes> +void swap(packaged_task<R(ArgTypes...)>&, packaged_task<R(ArgTypes...)>&); +</ins> +</pre></blockquote> </li> -</ul> +</ol> +<ol start="3"> +<li> <p> -Option (A): +In 30.6.8 [futures.task], immediately after <tt>operator=</tt> prototype +description (After p. 8) add: </p> +<blockquote><pre><ins>void swap(packaged_task& other);</ins> +</pre> <blockquote> -<ul> +<p><ins> +<i>Effects:</i> Swaps the associated state of <tt>*this</tt> and <tt>other</tt>. +</ins></p> +<p><ins> +<i>Throws:</i> Nothing. +</ins></p> +</blockquote> +</blockquote> +</li> <li> <p> -Add to the new section [forwardlist.compare] the following paragraphs: +At the end of 30.6.8 [futures.task] (after p. 20), add add the following +prototype description: </p> +<blockquote><pre><ins> +template<class R, class... Argtypes> +void swap(packaged_task<R(ArgTypes...)>& x, packaged_task<R(ArgTypes...)>& y); +</ins></pre> <blockquote> -<pre>template <class T, class Allocator> -bool operator==(const forward_list<T,Allocator>& x, const forward_list<T,Allocator>& y); -</pre> +<p><ins> +<i>Effects:</i> <tt>x.swap(y)</tt> +</ins></p> +<p><ins> +<i>Throws:</i> Nothing. +</ins></p> +</blockquote> +</blockquote> +</li> +</ol> + + + + + +<hr> +<h3><a name="1091"></a>1091. Response to UK 246</h3> +<p><b>Section:</b> 23.4.2.2 [multimap.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> + <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2009-03-22 <b>Last modified:</b> 2009-05-23</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><b>Addresses UK 246</b></p> +<p> +The content of this sub-clause is purely trying to describe in words the +effect of the requires clauses on these operations, now that we have +Concepts. As such, the description is more confusing than the signature +itself. The semantic for these functions is adequately covered in the +requirements tables in 23.2.4 [associative.reqmts]. +</p> + +<p><i>[ +Beman adds: +]</i></p> + + +<blockquote> +Pete is clearly right that +this one is technical rather than editorial. +</blockquote> + +<p><i>[ +Batavia (2009-05): +]</i></p> + <blockquote> <p> -<i>Requires:</i> Type <tt>T</tt> is <tt>EqualityComparable</tt> ([equalitycomparable]). +We agree with the proposed resolution. </p> <p> -<i>Returns:</i> <tt>true</tt> if +Move to Review. </p> -<ul> +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +Strike 23.4.2.2 [multimap.modifiers] entirely +(but do NOT strike these signatures from the class template definition!). +</p> + + + + + +<hr> +<h3><a name="1092"></a>1092. Class template <tt>integral_constant</tt> should be a constrained template</h3> +<p><b>Section:</b> 20.6.3 [meta.help] <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>Opened:</b> 2009-03-22 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta.help">active issues</a> in [meta.help].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.help">issues</a> in [meta.help].</p> +<p><b>View all 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 first step to change the type traits predicates to constrained templates is to +constrain their common base template <tt>integral_constant</tt>. This can be done, +without enforcing depending classes to be constrained as well, but not +vice versa +without brute force <tt>late_check</tt> usages. The following proposed resolution depends +on the resolution of LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1019">1019</a>. +</p> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +Move to Open, pending a paper that looks at constraints +for the entirety of the type traits +and their relationship to the foundation concepts. +We recommend this be deferred +until after the next Committee Draft is issued. +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<ol> <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: +In 20.6.2 [meta.type.synop], Header <tt><type_traits></tt> +synopsis change as indicated: </p> -<blockquote><pre>*i == *(y.begin() + (i - x.begin())). +<blockquote><pre>namespace std { +// 20.5.3, helper class: +template <<del>class</del><ins>IntegralConstantExpressionType</ins> T, T v> struct integral_constant; </pre></blockquote> </li> <li> -if <tt>i == E</tt> then <tt>i == x.end() && (y.begin() + (i - x.begin())) == y.end()</tt>. +<p> +In 20.6.3 [meta.help] change as indicated: +</p> +<blockquote><pre>template <<del>class</del><ins>IntegralConstantExpressionType</ins> T, T v> +struct integral_constant { + static constexpr T value = v; + typedef T value_type; + typedef integral_constant<T,v> type; + constexpr operator value_type() { return value; } +}; +</pre></blockquote> </li> +</ol> + + + + + +<hr> +<h3><a name="1093"></a>1093. Multiple definitions for random_shuffle algorithm</h3> +<p><b>Section:</b> 25.4.12 [alg.random.shuffle] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> + <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-22 <b>Last modified:</b> 2009-06-09</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.random.shuffle">issues</a> in [alg.random.shuffle].</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> +There are a couple of issues with the declaration of the <tt>random_shuffle</tt> +algorithm accepting a random number engine. +</p> + +<ol type="i"> <li> -Otherwise, returns <tt>false</tt>. +The Iterators must be shuffle iterators, yet this requirement is missing. </li> -</ul> +<li> +The <tt>RandomNumberEngine</tt> concept is now provided by the random number +library +(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2836.pdf">n2836</a>) +and the placeholder should be removed. +</li> +</ol> + +<p><i>[ +2009-05-02 Daniel adds: +]</i></p> + + +<blockquote> <p> -<i>Throws:</i> Nothing unless an exception is thrown by the equality comparison. +this issue completes adding necessary requirement to the +third new <tt>random_shuffle</tt> overload. The current suggestion is: </p> + +<blockquote><pre>template<RandomAccessIterator Iter, UniformRandomNumberGenerator Rand> +requires ShuffleIterator<Iter> +void random_shuffle(Iter first, Iter last, Rand&& g); +</pre></blockquote> + <p> -<i>Complexity:</i> At most <tt>M</tt> comparisons. +IMO this is still insufficient and I suggest to add the requirement </p> -</blockquote> -<pre>template <class T, class Allocator> -bool operator!=(const forward_list<T,Allocator>& x, const forward_list<T,Allocator>& y); -</pre> +<blockquote><pre>Convertible<Rand::result_type, Iter::difference_type> +</pre></blockquote> +<p> +to the list (as the two other overloads already have). +</p> + +<p> +Rationale: +</p> + <blockquote> -<i>Returns:</i> <tt>!(x == y)</tt>. +<p> +Its true that this third overload is somewhat different from the remaining +two. Nevertheless we know from <tt>UniformRandomNumberGenerator</tt>, that +it's <tt>result_type</tt> is an integral type and that it satisfies +<tt>UnsignedIntegralLike<result_type></tt>. +</p> +<p> +To realize it's designated task, the algorithm has to invoke the +<tt>Callable</tt> aspect of <tt>g</tt> and needs to perform some algebra involving +it's <tt>min()/max()</tt> limits to compute another index value that +at this point is converted into <tt>Iter::difference_type</tt>. This is so, +because 24.2.6 [random.access.iterators] uses this type as argument +of it's algebraic operators. Alternatively consider the equivalent +iterator algorithms in 24.4 [iterator.operations] with the same result. +</p> +<p> +This argument leads us to the conclusion that we also need +<tt>Convertible<Rand::result_type, Iter::difference_type></tt> here. +</p> </blockquote> + </blockquote> -</li> -</ul> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +<p> +Alisdair notes that point (ii) has already been addressed. +</p> +<p> +We agree with the proposed resolution to point (i) +with Daniel's added requirement. +</p> +<p> +Move to Review. +</p> </blockquote> +<p><i>[ +2009-06-05 Daniel updated proposed wording as recommended in Batavia. +]</i></p> + + + +<p><b>Proposed resolution:</b></p> <p> -Option (B): +Change in 25.2 [algorithms.syn] and 25.4.12 [alg.random.shuffle]: </p> -<blockquote> -<ul> -<li> + +<blockquote><pre><del>concept UniformRandomNumberGenerator<typename Rand> { }</del> +template<RandomAccessIterator Iter, UniformRandomNumberGenerator Rand> + <ins>requires ShuffleIterator<Iter> && + Convertible<Rand::result_type, Iter::difference_type></ins> + void random_shuffle(Iter first, Iter last, Rand&& g); +</pre></blockquote> + + + + + + +<hr> +<h3><a name="1094"></a>1094. Response to JP 65 and JP 66</h3> +<p><b>Section:</b> 27.5.4.3 [iostate.flags] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> + <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2009-03-24 <b>Last modified:</b> 2009-05-23</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#Review">Review</a> status.</p> +<p><b>Discussion:</b></p> +<p><b>Addresses JP 65 and JP 66</b></p> + <p> -Add to the new section [forwardlist.compare] the following paragraphs: +Switch from "unspecified-bool-type" to "explicit operator bool() const". </p> + +<p> +Replace <tt>operator unspecified-bool-type() const;</tt>" with <tt>explicit operator bool() const;</tt> +</p> + +<p><i>[ +Batavia (2009-05): +]</i></p> + <blockquote> -<pre>template <class T, class Allocator> -bool operator==(const forward_list<T,Allocator>& x, const forward_list<T,Allocator>& y); +We agree with the proposed resolution. +Move to Review. +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +Change the synopis in 27.5.4 [ios]: +</p> + +<blockquote><pre><ins>explicit</ins> operator <del><i>unspecified-bool-type</i></del> <ins>bool</ins>() const; +</pre></blockquote> + +<p> +Change 27.5.4.3 [iostate.flags]: +</p> + +<blockquote><pre><ins>explicit</ins> operator <del><i>unspecified-bool-type</i></del> <ins>bool</ins>() const; </pre> + <blockquote> <p> -<i>Requires:</i> Type <tt>T</tt> is <tt>EqualityComparable</tt> ([equalitycomparable]). +-1- <i>Returns:</i> <ins><tt>!fail()</tt></ins> <del>If <tt>fail()</tt> 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.</del> </p> <p> -<i>Returns:</i> <tt>distance(x.begin(), x.end()) == distance(y.begin(), y.end()) -&& equal(x.begin(), x.end(), y.begin())</tt>. +<del>[<i>Note:</i> This conversion can be used in contexts where a bool is expected +(e.g., an <tt>if</tt> condition); however, implicit conversions (e.g., +to <tt>int</tt>) that can occur with <tt>bool</tt> are not allowed, +eliminating some sources of user error. One possible implementation +choice for this type is pointer-to-member. <i>-- end note</i>]</del> </p> </blockquote> -<pre>template <class T, class Allocator> -bool operator!=(const forward_list<T,Allocator>& x, const forward_list<T,Allocator>& y); -</pre> +</blockquote> + + + + + + + +<hr> +<h3><a name="1095"></a>1095. <i>Shared objects and the library</i> wording unclear</h3> +<p><b>Section:</b> 17.6.3.10 [res.on.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> + <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2009-03-27 <b>Last modified:</b> 2009-05-23</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> +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2775.htm">N2775</a>, +<i>Small library thread-safety revisions</i>, among other changes, removed a note from +17.6.3.10 [res.on.objects] that read: +</p> + <blockquote> -<i>Returns:</i> <tt>!(x == y)</tt>. +[<i>Note:</i> This prohibition against concurrent non-const access means that +modifying an object of a standard library type shared between threads +without using a locking mechanism may result in a data race. <i>--end note</i>.] </blockquote> + +<p> +That resulted in wording which is technically correct but can only be +understood by reading the lengthy and complex 17.6.4.7 [res.on.data.races] +Data race avoidance. This has the effect of making +17.6.3.10 [res.on.objects] unclear, and has already resulted in a query +to the LWG reflector. See c++std-lib-23194. +</p> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +<p> +The proposed wording seems to need a bit of tweaking +("really bad idea" isn't quite up to standardese). +We would like feedback +as to whether the original Note's removal was intentional. +</p> +<p> +Change the phrase "is a really bad idea" +to "risks undefined behavior" and +move to Review status. +</p> </blockquote> -</li> -</ul> + + +<p><b>Proposed resolution:</b></p> +<p> +Change 17.6.3.10 [res.on.objects] as indicated: +</p> + +<blockquote> +<p> +The behavior of a program is undefined if calls to standard library +functions from different threads may introduce a data race. The +conditions under which this may occur are specified in 17.6.4.7. +</p> +<p><ins> +[<i>Note:</i> Thus modifying an object of a standard library type shared between +threads risks undefined behavior unless objects of the type are explicitly +specified as being sharable without data races or the user supplies a +locking mechanism. <i>--end note</i>] +</ins></p> </blockquote> @@ -17930,28 +33704,31 @@ bool operator!=(const forward_list<T,Allocator>& x, const forward_list <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> +<h3><a name="1096"></a>1096. unconstrained rvalue ref parameters</h3> +<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> + <b>Submitter:</b> David Abrahams <b>Opened:</b> 2009-03-21 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</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#Open">Open</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! +TODO: Look at all cases of unconstrained rvalue ref parameters and check +that concept req'ts work when <tt>T</tt> deduced as reference. </p> <p> -This same issue also applies to: + We found some instances where that was not done correctly and we figure + the possibility of deducing <tt>T</tt> to be an lvalue reference was probably + overlooked elsewhere. </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><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +Move to Open, pending proposed wording from Dave for further review. +</blockquote> <p><b>Proposed resolution:</b></p> @@ -17963,114 +33740,421 @@ This same issue also applies to: <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> +<h3><a name="1097"></a>1097. #define __STDCPP_THREADS</h3> +<p><b>Section:</b> 18.2 [support.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> + <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2009-04-03 <b>Last modified:</b> 2009-05-23</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#Review">Review</a> status.</p> <p><b>Discussion:</b></p> +<p><b>Addresses DE 18</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>. +Freestanding implementations do not (necessarily) have + support for multiple threads (see 1.10 [intro.multithread]). + Applications and libraries may want to optimize for the + absence of threads. I therefore propose a preprocessor + macro to indicate whether multiple threads can occur. </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. +There is ample prior implementation experience for this + feature with various spellings of the macro name. For + example, gcc implicitly defines <tt>_REENTRANT</tt> + if multi-threading support is selected on the compiler + command-line. </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>? +While this is submitted as a library issue, it may be more + appropriate to add the macro in 16.8 cpp.predefined in the + core language. </p> +<p> +See also +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2693.html">N2693</a>. +</p> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +<p> +We agree with the issue, and believe it is properly a library issue. +</p> +<p> +We prefer that the macro be conditionally defined +as part of the <tt><thread></tt> header. +</p> +<p> +Move to Review. +</p> +</blockquote> + <p><b>Proposed resolution:</b></p> <p> +Insert a new subsection before 18.2 [support.types], entitled +"Feature Macros" (support.macros): </p> +<blockquote> +<p> +The standard library defines the following macros; no explicit +prior inclusion of any header file is necessary. +</p> +<blockquote> +<dl> +<dt><tt>__STDCPP_THREADS</tt></dt> +<dd> +The macro <tt>__STDCPP_THREADS</tt> shall be defined if and only if a + program can have more than one thread of execution (1.10 [intro.multithread]). +If the macro is defined, it shall have the same + value as the predefined macro <tt>__cplusplus</tt> (16.8 [cpp.predefined]). +</dd> +</dl> +</blockquote> +</blockquote> + <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> +<h3><a name="1098"></a>1098. definition of get_pointer_safety()</h3> +<p><b>Section:</b> 20.8.13.7 [util.dynamic.safety] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> + <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2009-04-03 <b>Last modified:</b> 2009-05-23</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.dynamic.safety">issues</a> in [util.dynamic.safety].</p> +<p><b>View all 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><b>Addresses DE 18</b></p> + <p> -There's an error in 29.4 [atomics.types.operations]/p9: + In 20.8.13.7 [util.dynamic.safety], <tt>get_pointer_safety()</tt> purports +to define behavior for + non-safely derived pointers (3.7.4.3 [basic.stc.dynamic.safety]). However, + the cited core-language section in paragraph 4 specifies undefined behavior + for the use of such pointer values. This seems an unfortunate near-contradiction. + I suggest to specify the term <i>relaxed pointer safety</i> in + the core language section and refer to it from the library description. + This issue deals with the library part, the corresponding core issue (c++std-core-13940) + deals with the core modifications. </p> +<p> +See also +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2693.html">N2693</a>. +</p> + +<p><i>[ +Batavia (2009-05): +]</i></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> +<p> +We recommend if this issue is to be moved, +the issue be moved concurrently with the cited Core issue. +</p> +<p> +We agree with the intent of the proposed resolution. +We would like input from garbage collection specialists. +</p> +<p> +Move to Open. +</p> +</blockquote> + + + +<p><b>Proposed resolution:</b></p> +<p> +In 20.8.13.7 [util.dynamic.safety] p16, replace the description of +<tt>get_pointer_safety()</tt> with: +</p> + +<blockquote> +<p> +<tt>pointer_safety get_pointer_safety();</tt> +</p> <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>. +<del><i>Returns:</i> an enumeration value indicating the implementation's treatment +of pointers that are not safely derived (3.7.4.3). Returns +<tt>pointer_safety::relaxed</tt> if pointers that are not safely derived will be +treated the same as pointers that are safely derived for the duration of +the program. Returns <tt>pointer_safety::preferred</tt> if pointers that are not +safely derived will be treated the same as pointers that are safely +derived for the duration of the program but allows the implementation to +hint that it could be desirable to avoid dereferencing pointers that are +not safely derived as described. [<i>Example:</i> <tt>pointer_safety::preferred</tt> +might be returned to detect if a leak detector is running to avoid +spurious leak reports. -- <i>end note</i>] Returns <tt>pointer_safety::strict</tt> if +pointers that are not safely derived might be treated differently than +pointers that are safely derived.</del> +</p> +<p><ins> +<i>Returns:</i> Returns <tt>pointer_safety::strict</tt> if the implementation has + strict pointer safety (3.7.4.3 [basic.stc.dynamic.safety]). It is + implementation-defined whether <tt>get_pointer_safety</tt> returns + <tt>pointer_safety::relaxed</tt> or <tt>pointer_safety::preferred</tt> if the + implementation has relaxed pointer safety + (3.7.4.3 [basic.stc.dynamic.safety]).<sup>Footnote</sup> +</ins></p> + +<p><ins> +<i>Throws:</i> nothing +</ins></p> + +<p><ins> +Footnote) <tt>pointer_safety::preferred</tt> might be returned to indicate to the + program that a leak detector is running so that the program can avoid + spurious leak reports. +</ins> </p> + </blockquote> </blockquote> + + + + +<hr> +<h3><a name="1099"></a>1099. Various issues</h3> +<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> + <b>Submitter:</b> David Abrahams <b>Opened:</b> 2009-03-21 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</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#Open">Open</a> status.</p> +<p><b>Discussion:</b></p> <p> -I believe that this should state +Notes </p> <blockquote> -shall not be <tt>memory_order_release</tt>. +<p> +[2009-03-21 Sat] p. 535 at the top we need MoveConstructible V1, +MoveConstructible V2 (where V1,V2 are defined on 539). Also make_tuple +on 550 +</p> +<p> +[2009-03-21 Sat] p1183 thread ctor, and in general, we need a way to +talk about "copiable from generalized rvalue ref argument" for cases +where we're going to forward and copy. +</p> +<blockquote> +<p> + This issue may well be quite large. Language in para 4 about "if + an lvalue" is wrong because types aren't expressions. +</p> +<p> + p1199, call_once has all the same issues. +</p> +</blockquote> +<p> +[2009-03-21 Sat] p869 InputIterator pointer type should not be required +to be convertible to const value_type*, rather it needs to have a +operator-> of its own that can be used for the value type. +</p> +<p> +[2009-03-21 Sat] p818 stack has the same problem with default ctor. +</p> +<p> +[2009-03-21 Sat] p816 priority_queue has the same sorts of problems as queue, only more so +</p> +<blockquote><pre> requires MoveConstructible<Cont> + explicit priority_queue(const Compare& x = Compare(), Cont&& = Cont()); +</pre> +<p> + Don't require MoveConstructible when default constructing Cont. + Also missing semantics for move ctor. +</p> +</blockquote> +<p> + [2009-03-21 Sat] Why are Allocators required to be CopyConstructible as + opposed to MoveConstructible? +</p> +<p> + [2009-03-21 Sat] p813 queue needs a separate default ctor (Cont needn't + be MoveConstructible). No documented semantics for move c'tor. Or + *any* of its 7 ctors! +</p> +<p> + [2009-03-21 Sat] std::array should have constructors for C++0x, + consequently must consider move construction. +</p> + +<p><i>[ +2009-05-01 Daniel adds: +]</i></p> + + +<blockquote> +This could be done as part of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1035">1035</a>, which already handles +deviation of <tt>std::array</tt> from container tables. </blockquote> <p> -There's also an error in 29.4 [atomics.types.operations]/p17: + [2009-03-21 Sat] p622 all messed up. </p> +<blockquote> +<p> + para 8 "implementation-defined" is the wrong term; should be "see + below" or something. +</p> +<p> + para 12 "will be selected" doesn't make any sense because we're not + talking about actual arg types. +</p> +<p> + paras 9-13 need to be totally rewritten for concepts. +</p> +</blockquote> + +<p> + [2009-03-21 Sat] Null pointer comparisons (p587) have all become + unconstrained. Need to fix that +</p> +<p> + [2009-03-21 Sat] mem_fun_t etc. definition doesn't match declaration. + We think CopyConstructible is the right reqt. +</p> +<p> + make_pair needs Constructible<V1, T1&&> requirements! +</p> +<p> + make_tuple needs something similar +</p> +<p> + tuple bug in synopsis: +</p> +<blockquote><pre> template <class... UTypes> + requires Constructible<Types, const UTypes&>... + template <class... UTypes> + requires Constructible<Types, RvalueOf<UTypes>::type>... +</pre> +<p> + Note: removal of MoveConstructible requirements in std::function makes + these routines unconstrained! +</p> +</blockquote> + +<p><i>[ +2009-05-02 Daniel adds: +]</i></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> ... +This part of the issue is already covered by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1077">1077</a>. </blockquote> + <p> -I believe this should state + these unique_ptr constructors are broken [ I think this is covered in "p622 all messed up" ] </p> +<blockquote><pre> unique_ptr(pointer p, implementation-defined d); + unique_ptr(pointer p, implementation-defined d); +</pre></blockquote> +<p> + multimap range constructor should not have MoveConstructible<value_type> requirement. +</p> +<blockquote> + same with insert(..., P&&); multiset has the same issue, as do + unordered_multiset and unordered_multimap. Review these! +</blockquote> + +</blockquote> + +<p><i>[ +Batavia (2009-05): +]</i></p> + <blockquote> -shall be replaced by the value <tt>memory_order_acquire</tt> ... +Move to Open, pending proposed wording from Dave for further review. </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> + + + + +<hr> +<h3><a name="1100"></a>1100. <tt>auto_ptr</tt> to <tt>unique_ptr</tt> conversion</h3> +<p><b>Section:</b> D.9 [depr.auto.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-04-25 <b>Last modified:</b> 2009-05-23</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Message c++std-lib-23182 led to a discussion in which several people +expressed interest in being able to convert an <tt>auto_ptr</tt> to a +<tt>unique_ptr</tt> without the need to call <tt>release</tt>. Below is +wording to accomplish this. +</p> + +<p><i>[ +Batavia (2009-05): +]</i></p> + <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>. +Pete believes it not a good idea to separate parts of a class's definition. +Therefore, if we do this, +it should be part of <tt>unique-ptr</tt>'s specification. +</p> +<p> +Alisdair believes the lvalue overload may be not necessary. +</p> +<p> +Marc believes it is more than just sugar, +as it does ease the transition to <tt>unique-ptr</tt>. +</p> +<p> +We agree with the resolution as presented. +Move to Tentatively Ready. </p> </blockquote> -</blockquote> + +<p><b>Proposed resolution:</b></p> <p> -Change 29.4 [atomics.types.operations]/p17: +Add to D.9 [depr.auto.ptr]: </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> ... +<p> +The following <tt>unique_ptr</tt> constructors are in addition to those specified +in 20.8.12.2.1 [unique.ptr.single.ctor]. +</p> +<pre>template <class T, class D> +class unique_ptr +{ +public: + template <class U> + requires SameType<D, default_delete<T>> + && Convertible<U*, T*> + unique_ptr(auto_ptr<U>& u); + template <class U> + requires SameType<D, default_delete<T>> + && Convertible<U*, T*> + unique_ptr(auto_ptr<U>&& u); +}; +</pre> +<p> +<i>Effects:</i> Constructs a <tt>unique_ptr</tt> with <tt>u.release()</tt>. +</p> + +<p> +<i>Postconditions:</i> <tt>get() == </tt> the value <tt>u.get()</tt> had before +the construciton, modulo any required offset adjustments resulting from the cast from +<tt>U*</tt> to <tt>T*</tt>. <tt>u.get() == nullptr</tt>. +</p> + +<p> +<i>Throws:</i> nothing. +</p> </blockquote> @@ -18079,68 +34163,195 @@ the value of failure is <tt>order</tt> except that a value of <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> +<h3><a name="1101"></a>1101. <tt>unique</tt> requirements</h3> +<p><b>Section:</b> 25.4.9 [alg.unique] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Tentatively NAD Editorial</a> + <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-04-25 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#alg.unique">active issues</a> in [alg.unique].</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#Tentatively%20NAD%20Editorial">Tentatively NAD Editorial</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: +From Message c++std-core-14160 Howard wrote: </p> -<ol> -<li> -<pre>template<class OutputIterator, class Size, class T> -void fill_n(OutputIterator first, Size n, const T& value);</pre></li> +<blockquote> +It was the intent of the rvalue reference proposal for unique to only require MoveAssignable: +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1860.html#25.2.9%20-%20Unique">N1860</a>. +</blockquote> -<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. +And Pete replied: </p> +<blockquote> +That was overridden by the subsequent changes made for concepts in +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2573.pdf">N2573</a>, +which reimposed the C++03 requirements. +</blockquote> + +<p> +My impression is that this overwrite was a simple (unintentional) mistake. +Wording below to correct it. +</p> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +<p> +Howard notes this issue resolves a discrepancy between the synopsis +and the description. +</p> +<p> +Move to NAD Editorial. +</p> +</blockquote> + <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 +Change 25.4.9 [alg.unique]: +</p> + +<blockquote><pre>template<ForwardIterator Iter> + requires OutputIterator<Iter, <ins>RvalueOf<</ins>Iter::reference<ins>>::type</ins>> + && EqualityComparable<Iter::value_type> + Iter unique(Iter first, Iter last); + +template<ForwardIterator Iter, EquivalenceRelation<auto, Iter::value_type> Pred> + requires OutputIterator<Iter, RvalueOf<Iter::reference>::type> + && CopyConstructible<Pred> + Iter unique(Iter first, Iter last, Pred pred); +</pre></blockquote> + +<p> +Note that the synopsis in 25.2 [algorithms.syn] is already correct. </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); + + + + + +<hr> +<h3><a name="1102"></a>1102. <tt>std::vector</tt>'s reallocation policy still unclear</h3> +<p><b>Section:</b> 23.3.6.2 [vector.capacity] <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>Opened:</b> 2009-04-20 <b>Last modified:</b> 2009-05-23</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#Review">Review</a> status.</p> +<p><b>Discussion:</b></p> +<p> +I have the impression that even the wording of current draft +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2857.pdf">N2857</a> +does insufficiently express the intent of <tt>vector</tt>'s +reallocation strategy. This has produced not too old library +implementations which release memory in the <tt>clear()</tt> function +and even modern articles about C++ programming cultivate +the belief that <tt>clear</tt> is allowed to do exactly this. A typical +example is something like this: +</p> + +<blockquote><pre>const int buf_size = ...; +std::vector<T> buf(buf_size); +for (int i = 0; i < some_condition; ++i) { + buf.resize(buf_size); + write_or_read_data(buf.data()); + buf.clear(); // Ensure that the next round get's 'zeroed' elements +} </pre></blockquote> <p> -Just after the effects clause p.2 add a new returns clause saying: +where still the myth is ubiquitous that <tt>buf</tt> might be +allowed to reallocate it's memory *inside* the <tt>for</tt> loop. +</p> +<p> +IMO the problem is due to the fact, that +</p> + +<ol type="a"> +<li> +the actual memory-reallocation stability of <tt>std::vector</tt> +is explained in 23.3.6.2 [vector.capacity]/3 and /6 which +are describing just the effects of the <tt>reserve</tt> +function, but in many examples (like above) there +is no explicit call to <tt>reserve</tt> involved. Further-more +23.3.6.2 [vector.capacity]/6 does only mention <em>insertions</em> +and never mentions the consequences of erasing +elements. +</li> +<li> +<p> +the effects clause of <tt>std::vector</tt>'s <tt>erase</tt> overloads in +23.3.6.4 [vector.modifiers]/4 is silent about capacity changes. This +easily causes a misunderstanding, because the counter +parting insert functions described in 23.3.6.4 [vector.modifiers]/2 +explicitly say, that </p> <blockquote> -<i>Returns:</i> <tt>first + n</tt> for <tt>fill_n</tt>. +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. </blockquote> +<p> +It requires a complex argumentation chain about four +different places in the standard to provide the - possibly +weak - proof that calling <tt>clear()</tt> also does <em>never</em> change +the capacity of the <tt>std::vector</tt> container. Since <tt>std::vector</tt> +is the de-facto replacement of C99's dynamic arrays this +type is near to a built-in type and it's specification should +be clear enough that usual programmers can trust their +own reading. +</p> </li> +</ol> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +<p> +Bill believes paragraph 1 of the proposed resolution is unnecessary +because it is already implied (even if tortuously) by the current wording. +</p> +<p> +Move to Review. +</p> +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p><i>[ +This is a minimum version. I also +suggest that the wording explaining the allocation strategy +of <tt>std::vector</tt> in 23.3.6.2 [vector.capacity]/3 and /6 is moved into +a separate sub paragraph of 23.3.6.2 [vector.capacity] <em>before</em> +any of the prototype's are discussed, but I cannot provide +reasonable wording changes now +]</i></p> + + +<ol> <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 +Change 23.3.6.2 [vector.capacity]/6 as follows: </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> +<blockquote> +It is guaranteed that no reallocation takes place during +insertions <ins>or erasures</ins> that happen after a call +to <tt>reserve()</tt> until the time when an insertion would make +the size of the vector greater than the value of <tt>capacity()</tt>. +</blockquote> +</li> +<li> <p> -Just after the effects clause p.1 add a new returns clause saying: +Change 23.3.6.4 [vector.modifiers]/4 as follows: </p> <blockquote> -<i>Returns:</i> <tt>first + n</tt> for <tt>generate_n</tt>. +<i>Effects:</i> <ins>The capacity shall remain unchanged and no reallocation shall +happen.</ins> +Invalidates iterators and references at or after the point +of the erase. </blockquote> </li> </ol> @@ -18150,257 +34361,667 @@ Just after the effects clause p.1 add a new returns clause saying: <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> +<h3><a name="1103"></a>1103. <tt>system_error</tt> constructor postcondition overly strict</h3> +<p><b>Section:</b> 19.5.5.2 [syserr.syserr.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-04-25 <b>Last modified:</b> 2009-05-23</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</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: +19.5.5.2 [syserr.syserr.members] says: </p> -<ul> -<li> + +<blockquote><pre>system_error(error_code ec, const string& what_arg); +</pre> +<blockquote> <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: +<i>Effects:</i> Constructs an object of class <tt>system_error</tt>. </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: +<i>Postconditions:</i> <tt>code() == ec</tt> and <tt>strcmp(runtime_error::what(), what_arg.c_str()) == 0</tt>. +</p> +</blockquote> +</blockquote> + +<p> +However the intent is for: </p> -<blockquote><pre>new (pv) T(std::forward<Args>(args)...), + +<blockquote><pre>std::system_error se(std::errc::not_a_directory, "In FooBar"); +... +se.what(); <font color="#c80000">// returns something along the lines of:</font> + <font color="#c80000">// "In FooBar: Not a directory"</font> </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. +The way the constructor postconditions are set up now, to achieve both +conformance, and the desired intent in the <tt>what()</tt> string, the +<tt>system_error</tt> constructor must store "In FooBar" in the base class, +and then form the desired output each time <tt>what()</tt> is called. Or +alternatively, store "In FooBar" in the base class, and store the desired +<tt>what()</tt> string in the derived <tt>system_error</tt>, and override +<tt>what()</tt> to return the string in the derived part. </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. +Both of the above implementations seem suboptimal to me. In one I'm computing +a new string every time <tt>what()</tt> is called. And since <tt>what()</tt> +can't propagate exceptions, the client may get a different string on different +calls. </p> +<p> +The second solution requires storing two strings instead of one. +</p> -<p><b>Proposed resolution:</b></p> <p> -Replace "<tt>new</tt>" with "<tt>::new</tt>" in: +What I would like to be able to do is form the desired <tt>what()</tt> string +once in the <tt>system_error</tt> constructor, and store <em>that</em> in the +base class. Now I'm: </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> +<ol> +<li>Computing the desired <tt>what()</tt> only once.</li> +<li>The base class <tt>what()</tt> definition is sufficient and nothrow.</li> +<li>I'm not storing multiple strings.</li> +</ol> +<p> +This is smaller code, smaller data, and faster. +</p> +<p> +<tt>ios_base::failure</tt> has the same issue. +</p> +<p><i>[ +Comments about this change received favorable comments from the <tt>system_error</tt> +designers. +]</i></p> -<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><i>[ +Batavia (2009-05): +]</i></p> + + +<blockquote> <p> -From 26.5.2.1 [valarray.cons], paragraph 2: +We agree with the proposed resolution. </p> +<p> +Move to Tentatively Ready. +</p> +</blockquote> -<blockquote><pre>explicit valarray(size_t); + +<p><b>Proposed resolution:</b></p> +<p> +In 19.5.5.2 [syserr.syserr.members], change the following constructor postconditions: +</p> + +<blockquote> +<pre>system_error(error_code ec, const string& what_arg); </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>. +-2- <i>Postconditions:</i> <tt>code() == ec</tt> +and <tt><del>strcmp(runtime_error::what(), what_arg.c_str()) == 0</del> +<ins>string(what()).find(what_arg) != string::npos</ins></tt>. +</blockquote> + +<pre>system_error(error_code ec, const char* what_arg); +</pre> +<blockquote> +-4- <i>Postconditions:</i> <tt>code() == ec</tt> +and <tt><del>strcmp(runtime_error::what(), what_arg) == 0</del> +<ins>string(what()).find(what_arg) != string::npos</ins></tt>. +</blockquote> + +<pre>system_error(error_code ec); +</pre> +<blockquote> +-6- <i>Postconditions:</i> <tt>code() == ec</tt> +<del>and <tt>strcmp(runtime_error::what(), ""</tt></del>. +</blockquote> + +<pre>system_error(int ev, const error_category& ecat, const string& what_arg); +</pre> +<blockquote> +-8- <i>Postconditions:</i> <tt>code() == error_code(ev, ecat)</tt> +and <tt><del>strcmp(runtime_error::what(), what_arg.c_str()) == 0</del> +<ins>string(what()).find(what_arg) != string::npos</ins></tt>. +</blockquote> + +<pre>system_error(int ev, const error_category& ecat, const char* what_arg); +</pre> +<blockquote> +-10- <i>Postconditions:</i> <tt>code() == error_code(ev, ecat)</tt> +and <tt><del>strcmp(runtime_error::what(), what_arg) == 0</del> +<ins>string(what()).find(what_arg) != string::npos</ins></tt>. +</blockquote> + +<pre>system_error(int ev, const error_category& ecat); +</pre> +<blockquote> +-12- <i>Postconditions:</i> <tt>code() == error_code(ev, ecat)</tt> +<del>and <tt>strcmp(runtime_error::what(), "") == 0</tt></del>. </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: +In 19.5.5.2 [syserr.syserr.members], change the description of <tt>what()</tt>: </p> <blockquote> -The elements of the array are constructed using the default constructor for the instantiating type <tt>T</tt>. +<pre>const char *what() const throw(); +</pre> +<blockquote> +<p> +-14- <i>Returns:</i> An NTBS incorporating <del><tt>runtime_error::what()</tt> and +<tt>code().message()</tt></del> <ins>the arguments supplied in the constructor</ins>. +</p> +<p> +[<i>Note:</i> <del>One possible implementation would be:</del> +<ins>The return NTBS might take the form: <tt>what_arg + ": " + code().message()</tt></ins> +</p> +<blockquote><pre><del> +if (msg.empty()) { + try { + string tmp = runtime_error::what(); + if (code()) { + if (!tmp.empty()) + tmp += ": "; + tmp += code().message(); + } + swap(msg, tmp); + } catch(...) { + return runtime_error::what(); + } +return msg.c_str(); +</del></pre></blockquote> +<p> +— <i>end note</i>] +</p> +</blockquote> </blockquote> + <p> -with +In 27.5.2.1.1 [ios::failure], change the synopsis: </p> + +<blockquote><pre>namespace std { + class ios_base::failure : public system_error { + public: + explicit failure(const string& msg, const error_code& ec = io_errc::stream); + explicit failure(const char* msg, const error_code& ec = io_errc::stream); + <del>virtual const char* what() const throw();</del> + }; +} +</pre></blockquote> + +<p> +In 27.5.2.1.1 [ios::failure], change the description of the constructors: +</p> + <blockquote> -The elements of the array are value-initialized. + +<pre>explicit failure(const string& msg, , const error_code& ec = io_errc::stream); +</pre> +<blockquote> +<p> +-3- <i>Effects:</i> Constructs an object of class <tt>failure</tt> +<ins>by constructing the base class with <tt>msg</tt> and <tt>ec</tt></ins>. +</p> +<p> +<del>-4- <i>Postcondition:</i> <tt>code() == ec</tt> and <tt>strcmp(what(), msg.c_str()) == 0</tt></del> +</p> </blockquote> +<pre>explicit failure(const char* msg, const error_code& ec = io_errc::stream); +</pre> +<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). +-5- <i>Effects:</i> Constructs an object of class <tt>failure</tt> +<ins>by constructing the base class with <tt>msg</tt> and <tt>ec</tt></ins>. +</p> +<p> +<del>-6- <i>Postcondition:</i> <tt>code() == ec and strcmp(what(), msg) == 0</tt></del> </p> +</blockquote> +</blockquote> -<p><b>Proposed resolution:</b></p> <p> -Change 26.5.2.1 [valarray.cons], paragraph 2: +In 27.5.2.1.1 [ios::failure], remove <tt>what</tt> (the base class definition +need not be repeated here). </p> <blockquote> -<pre>explicit valarray(size_t); +<pre><del>const char* what() const;</del> </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>. +<del>-7- <i>Returns:</i> The message <tt>msg</tt> with which the exception was created.</del> </blockquote> + </blockquote> + + + + + +<hr> +<h3><a name="1104"></a>1104. <tt>basic_ios::move</tt> should accept lvalues</h3> +<p><b>Section:</b> 27.5.4.2 [basic.ios.members] <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>Opened:</b> 2009-04-25 <b>Last modified:</b> 2009-05-23</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#Review">Review</a> status.</p> +<p><b>Discussion:</b></p> +<p> +With the rvalue reference changes in +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2844.html">N2844</a> +<tt>basic_ios::move</tt> no longer has the most convenient signature: +</p> + +<blockquote><pre>void move(basic_ios&& rhs); +</pre></blockquote> + <p> -Change 26.5.2.7 [valarray.members], paragraph 9: +This signature should be changed to accept lvalues. It does not need to be +overloaded to accept rvalues. This is a special case that only derived clients +will see. The generic <tt>move</tt> still needs to accept rvalues. </p> +<p><i>[ +Batavia (2009-05): +]</i></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>] +<p> +Tom prefers, on general principles, to provide both overloads. +Alisdair agrees. +</p> +<p> +Howard points out that there is no backward compatibility issue +as this is new to C++0X. +</p> +<p> +We agree that both overloads should be provided, +and Howard will provide the additional wording. +Move to Open. +</p> </blockquote> +<p><i>[ +2009-05-23 Howard adds: +]</i></p> + + +<blockquote> +Added overload, moved to Review. +</blockquote> + + + +<p><b>Proposed resolution:</b></p> +<p> +Add a signature to the existing prototype in the synopsis of 27.5.4 [ios] +and in 27.5.4.2 [basic.ios.members]: +</p> + +<blockquote><pre><ins>void move(basic_ios& rhs);</ins> +void move(basic_ios&& rhs); +</pre></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> +<h3><a name="1105"></a>1105. Shouldn't <tt>Range</tt> be an <tt>auto concept</tt></h3> +<p><b>Section:</b> 24.2.8 [iterator.concepts.range] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> + <b>Submitter:</b> David Abrahams <b>Opened:</b> 2009-04-23 <b>Last modified:</b> 2009-05-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><i>[ +2009-04-26 Herb adds: +]</i></p> + + +<blockquote> <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>. +Here's a common example: We have many ISV customers who have built lots of +in-house STL-like containers. Imagine that, for the past ten years, the user +has been happily using his <tt>XYZCorpContainer<T></tt> that has <tt>begin()</tt> and <tt>end()</tt> +and an iterator typedef, and indeed satisfies nearly all of <tt>Container</tt>, +though maybe not quite all just like <tt>valarray</tt>. The user upgrades to a +range-enabled version of a library, and now <tt>lib_algo( xyz.begin(), xyz.end());</tt> +no longer works -- compiler error. +</p> +<p> +Even though <tt>XYZCorpContainer</tt> matches the pre-conceptized version of the +algorithm, and has been working for years, it appears the user has to write +at least this: +</p> +<blockquote><pre>template<class T> concept_map Range<XYZCorpContainer<T>> {}; + +template<class T> concept_map Range<const XYZCorpContainer<T>> {}; +</pre></blockquote> +<p> +Is that correct? +</p> +<p> +But he may actually have to write this as we do for initializer list: +</p> +<blockquote><pre>template<class T> +concept_map Range<XYZCorpContainer<T>> { + typedef T* iterator; + iterator begin(XYZCorpContainer<T> c) { return c.begin(); } + iterator end(XYZCorpContainer<T> c) { return c.end(); } +}; + +template<class T> +concept_map Range<const XYZCorpContainer<T>> { + typedef T* iterator; + iterator begin(XYZCorpContainer<T> c) { return c.begin(); } + iterator end(XYZCorpContainer<T> c) { return c.end(); } +}; +</pre></blockquote> + +</blockquote> + +<p><i>[ +2009-04-28 Alisdair adds: +]</i></p> + + +<blockquote> +<p> +I recommend NAD, although remain concerned about header organisation. +</p> +<p> +A user container will satisfy the <tt>MemberContainer</tt> concept, which IS auto. +There is a concept_map for all <tt>MemberContainers</tt> to <tt>Container</tt>, and then a +further concept_map for all <tt>Container</tt> to <tt>Range</tt>, so the stated problem is not +actually true. User defined containers will automatically match the <tt>Range</tt> +concept without explicitly declaring a concept_map. +</p> +<p> +The problem is that they should now provide an additional two headers, +<tt><iterator_concepts></tt> and <tt><container_concepts></tt>. + The only difference from +making <tt>Range</tt> an auto concept would be this reduces to a single header, +<tt><iterator_concepts></tt>. </p> +<p> +I am strongly in favour of any resolution that tackles the issue of +explicitly requiring concept headers to make these concept maps available. +</p> +</blockquote> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +<p> +We observe there is a recent paper by Bjarne that overlaps this issue. +</p> +<p> +Alisdair continues to recommend NAD. +</p> +<p> +Move to Open, and recommend the issue be deferred until after the next +Committee Draft is issued. +</p> +</blockquote> <p><b>Proposed resolution:</b></p> + + + + + +<hr> +<h3><a name="1106"></a>1106. Multiple exceptions from connected <tt>shared_future::get()</tt>?</h3> +<p><b>Section:</b> 30.6.5 [future.shared_future] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> + <b>Submitter:</b> Thomas J. Gritzan <b>Opened:</b> 2009-04-03 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#future.shared_future">active issues</a> in [future.shared_future].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#future.shared_future">issues</a> in [future.shared_future].</p> +<p><b>View all 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> -Change 20.1.1 [utility.arg.requirements], paragraph 2: +It is not clear, if multiple threads are waiting in a +<tt>shared_future::get()</tt> call, if each will rethrow the stored exception. +</p> +<p> +Paragraph 9 reads: +</p> +<blockquote> +<i>Throws:</i> the stored exception, if an exception was stored and not +retrieved before. +</blockquote> +<p> +The "not retrieved before" suggests that only one exception is thrown, +but one exception for each call to <tt>get()</tt> is needed, and multiple calls +to <tt>get()</tt> even on the same <tt>shared_future</tt> object seem to be allowed. +</p> +<p> +I suggest removing "and not retrieved before" from the Throws paragraph. +I recommend adding a note that explains that multiple calls on <tt>get()</tt> are +allowed, and each call would result in an exception if an exception was +stored. </p> +<p><i>[ +Batavia (2009-05): +]</i></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]). +<p> +We note there is a pending paper by Detlef +on such <tt>future</tt>-related issues; +we would like to wait for his paper before proceeding. +</p> +<p> +Alisdair suggests we may want language to clarify that this +<tt>get()</tt> function can be called from several threads +with no need for explicit locking. +</p> +<p> +Move to Open. +</p> </blockquote> + +<p><b>Proposed resolution:</b></p> <p> -In all the following paragraphs in clause 23 [containers], replace "default constructed" with "value-initialized -(8.5 [dcl.init])": +Change 30.6.5 [future.shared_future]: </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> +<blockquote><pre>const R& shared_future::get() const; +R& shared_future<R&>::get() const; +void shared_future<void>::get() const; +</pre> +<blockquote> +<p>...</p> +<p> +-9- <i>Throws:</i> the stored exception, if an exception was stored<del> and not retrieved before</del>. +<ins> +[<i>Note:</i> Multiple calls on <tt>get()</tt> are +allowed, and each call would result in an exception if an exception was +stored. — <i>end note</i>] +</ins> +</p> +</blockquote> +</blockquote> + <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> +<h3><a name="1107"></a>1107. constructor <tt>shared_future(unique_future)</tt> by value?</h3> +<p><b>Section:</b> 30.6.5 [future.shared_future] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a> + <b>Submitter:</b> Thomas J. Gritzan <b>Opened:</b> 2009-04-03 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#future.shared_future">active issues</a> in [future.shared_future].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#future.shared_future">issues</a> in [future.shared_future].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p> <p><b>Discussion:</b></p> <p> -Is there any language in the current draft specifying the behaviour of the following snippet? +In the <tt>shared_future</tt> class definition in 30.6.5 [future.shared_future] +the move constructor +that constructs a <tt>shared_future</tt> from an <tt>unique_future</tt> receives the +parameter by value. In paragraph 3, the same constructor receives it as +const value. </p> -<blockquote><pre>unordered_set<int> s; -unordered_set<int>::local_iterator it = s.end(0); +<p> +I think that is a mistake and the constructor should take a r-value +reference: +</p> -// Iterate past end - the unspecified part -it++; +<blockquote><pre>shared_future(unique_future<R>&& rhs); </pre></blockquote> +<p><i>[ +Batavia (2009-05): +]</i></p> + +<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. +We agree with the proposed resolution. +</p> +<p> +Move to Tentatively Ready. </p> +</blockquote> <p><b>Proposed resolution:</b></p> <p> -Change Table 97 "Unordered associative container requirements" in 23.1.5 [unord.req]: +Change the synopsis in 30.6.5 [future.shared_future]: </p> +<blockquote><pre>shared_future(unique_future<R><ins>&&</ins> rhs); +</pre></blockquote> + +<p> +Change the definition of the constructor in 30.6.5 [future.shared_future]: +</p> + +<blockquote><pre>shared_future(<del>const</del> unique_future<R><ins>&&</ins> rhs); +</pre></blockquote> + + + + + + +<hr> +<h3><a name="1108"></a>1108. thread.req.exception overly constrains implementations</h3> +<p><b>Section:</b> 30.2.2 [thread.req.exception] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> + <b>Submitter:</b> Christopher Kohlhoff <b>Opened:</b> 2009-04-25 <b>Last modified:</b> 2009-05-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> +The current formulation of 30.2.2 [thread.req.exception]/2 reads: +</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> +The error_category of the <tt>error_code</tt> reported by such an +exception's <tt>code()</tt> member function is as specified in the error +condition Clause. +</blockquote> +<p> +This constraint on the code's associated <tt>error_categor</tt> means an +implementation must perform a mapping from the system-generated +error to a <tt>generic_category()</tt> error code. The problems with this +include: +</p> + +<ul> +<li> +The mapping is always performed, even if the resultant value is + never used. +</li> +<li> +<p> +The original error produced by the operating system is lost. +</p> +</li> +</ul> +<p> +The latter was one of Peter Dimov's main objections (in a private +email discussion) to the original <tt>error_code</tt>-only design, and led to +the creation of <tt>error_condition</tt> in the first place. Specifically, +<tt>error_code</tt> and <tt>error_condition</tt> are intended to perform the following +roles: +</p> +<ul> +<li> +<tt>error_code</tt> holds the original error produced by the operating + system. +</li> +<li> +<tt>error_condition</tt> and the generic category provide a set of well + known error constants that error codes may be tested against. +</li> +</ul> +<p> +Any mapping determining correspondence of the returned error code to +the conditions listed in the error condition clause falls under the +"latitude" granted to implementors in 19.5.1.5 [syserr.errcat.objects]. +(Although obviously their latitude is restricted a little by the +need to match the right error condition when returning an error code +from a library function.) +</p> +<p> +It is important that this <tt>error_code/error_condition</tt> usage is done +correctly for the thread library since it is likely to set the +pattern for future TR libraries that interact with the operating +system. +</p> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +Move to Open, and recommend the issue be deferred until after the next +Committee Draft is issued. +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +Change 30.2.2 [thread.req.exception]/2: +</p> + +<blockquote> +<p> +-2- <del>The <tt>error_category</tt> (19.5.1.1) of the <tt>error_code</tt> reported by +such an exception's <tt>code()</tt> member function +is as specified in the error condition Clause.</del> +<ins> +The <tt>error_code</tt> reported by such an exception's <tt>code()</tt> member +function shall compare equal to one of the conditions specified in +the function's error condition Clause. [<i>Example:</i> When the thread +constructor fails: +</ins> +</p> +<blockquote><pre><ins> +ec.category() == implementation-defined // probably system_category +ec == errc::resource_unavailable_try_again // holds true +</ins></pre></blockquote> + +<p><ins> +— <i>end example</i>] +</ins></p> + </blockquote> @@ -18409,167 +35030,822 @@ If the bucket is empty, then <tt>b.begin(n) == b.end(n)</tt>.</ins></td> <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> +<h3><a name="1109"></a>1109. <tt>std::includes</tt> should require <tt>CopyConstructible</tt> predicate</h3> +<p><b>Section:</b> 25.5.5.1 [includes] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Tentatively NAD Editorial</a> + <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-04-28 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#includes">active issues</a> in [includes].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#includes">issues</a> in [includes].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD%20Editorial">Tentatively NAD Editorial</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: +All the set operation algorithms require a <tt>CopyConstructible</tt> predicate, with +the exception of <tt>std::includes</tt>. This looks like a typo as much as anything, +given the general library requirement that predicates are copy +constructible, and wording style of other set-like operations. </p> +<p><i>[ +Batavia (2009-05): +]</i></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.[..] +We agree with the proposed resolution. +Move to NAD Editorial. </blockquote> + +<p><b>Proposed resolution:</b></p> +<p> +Change 25.2 [algorithms.syn] and 25.5.5.1 [includes]: +</p> + +<blockquote><pre>template<InputIterator Iter1, InputIterator Iter2, + <del>typename</del> <ins>CopyConstructible</ins> Compare> + requires Predicate<Compare, Iter1::value_type, Iter2::value_type> + && Predicate<Compare, Iter2::value_type, Iter1::value_type> + bool includes(Iter1 first1, Iter1 last1, + Iter2 first2, Iter2 last2, + Compare comp); +</pre></blockquote> + + + + + +<hr> +<h3><a name="1110"></a>1110. Is <tt>for_each</tt> overconstrained?</h3> +<p><b>Section:</b> 25.3.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> Alisdair Meredith <b>Opened:</b> 2009-04-29 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#alg.foreach">active issues</a> in [alg.foreach].</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 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: +Quoting working paper for reference (25.3.4 [alg.foreach]): </p> <blockquote> +<pre>template<InputIterator Iter, Callable<auto, Iter::reference> Function> + requires CopyConstructible<Function> + Function for_each(Iter first, Iter last, Function f); +</pre> +<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>.[..] +1 Effects: Applies f to the result of dereferencing every iterator in the + range [first,last), starting from first and proceeding to last - 1. </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>. +2 Returns: f. </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.[..] +3 Complexity: Applies f exactly last - first times. </p> </blockquote> +</blockquote> <p> -and table 97 says in the column "assertion...post-condition" for the -expression X::hasher: +P2 implies the passed object <tt>f</tt> should be invoked at each stage, rather than +some copy of <tt>f</tt>. This is important if the return value is to usefully +accumulate changes. So the requirements are an object of type <tt>Function</tt> can +be passed-by-value, invoked multiple times, and then return by value. In +this case, <tt>MoveConstructible</tt> is sufficient. This would open support for +move-only functors, which might become important in concurrent code as you +can assume there are no other references (copies) of a move-only type and so +freely use them concurrently without additional locks. </p> +<p><i>[ +See further discussion starting with c++std-lib-23686. +]</i></p> + + +<p><i>[ +Batavia (2009-05): +]</i></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>. +<p> +Pete suggests we may want to look at this in a broader context +involving other algorithms. +We should also consider the implications of parallelism. +</p> +<p> +Move to Open, and recommend the issue be deferred until after the next +Committee Draft is issued. +</p> </blockquote> + +<p><b>Proposed resolution:</b></p> +<p> +Change 25.2 [algorithms.syn] and 25.3.4 [alg.foreach]: +</p> + +<blockquote><pre>template<InputIterator Iter, Callable<auto, Iter::reference> Function> + requires <del>CopyConstructible</del> <ins>MoveConstructible</ins><Function> + Function for_each(Iter first, Iter last, Function f); +</pre></blockquote> + + + + + +<hr> +<h3><a name="1111"></a>1111. associative containers underconstrained</h3> +<p><b>Section:</b> 23.4 [associative] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> + <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-04-29 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative">active issues</a> in [associative].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative">issues</a> in [associative].</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 that 20.6 [function.objects]/1 defines as "Function objects are -objects with an <tt>operator()</tt> defined.[..]" +According to table 87 (n2857) the expression <tt>X::key_equal</tt> for an unordered +container shall return a value of type <tt>Pred</tt>, where <tt>Pred</tt> is an equivalence +relation. </p> + <p> -Does this restriction exist by design or is it an oversight? If an -oversight, I suggest that to apply -the following +However, all 4 containers constrain <tt>Pred</tt> to be merely a <tt>Predicate</tt>, +and not <tt>EquivalenceRelation</tt>. </p> +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +<p> +We agree with the proposed resolution. +</p> +<p> +Move to Review. +</p> +</blockquote> + <p><b>Proposed resolution:</b></p> <p> -In 23.1.5 [unord.req]/3, just after the second sentence which is written as +For ordered containers, replace +</p> +<blockquote><pre>Predicate<auto, Key, Key> Compare = less<Key> +</pre></blockquote> +<p> +with +</p> +<blockquote><pre>StrictWeakOrder<auto, Key, Key> Compare = less<Key> +</pre></blockquote> + +<p> +For unordered containers, replace +</p> +<blockquote><pre>Predicate<auto, Key, Key> Compare = less<Key> +</pre></blockquote> +<p> +with +</p> +<blockquote><pre>EquivalenceRelation<auto, Key, Key> Compare = less<Key> +</pre></blockquote> +<p> +As in the following declarations: </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>. +<p> +Associative containers 23.4 [associative] +</p> +<p> + 1 Headers <map> and <set>: +</p> +<p> + Header <map> synopsis +</p> +<blockquote><pre> namespace std { + template <ValueType Key, ValueType T, + <del>Predicate</del><ins>StrictWeakOrder</ins><auto, Key<del>, Key</del>> Compare = less<Key>, + Allocator Alloc = allocator<pair&lt;<b>const Key, T> > > + requires NothrowDestructible<Key> && NothrowDestructible<T> + && CopyConstructible<Compare> + && AllocatableElement<Alloc, Compare, const Compare&> + && AllocatableElement<Alloc, Compare, Compare&&> + class map; + + ... + + template <ValueType Key, ValueType T, + <del>Predicate</del><ins>StrictWeakOrder</ins><auto, Key<del>, Key</del>> Compare = less<Key>, + Allocator Alloc = allocator<pair&lt;<b>const Key, T> > > + requires NothrowDestructible<Key> && NothrowDestructible<T> + && CopyConstructible<Compare> + && AllocatableElement<Alloc, Compare, const Compare&> + && AllocatableElement<Alloc, Compare, Compare&&> + class multimap; + + ... + + } +</pre></blockquote> + +<p> + Header <set> synopsis +</p> +<blockquote><pre> namespace std { + template <ValueType Key, <del>Predicate</del><ins>StrictWeakOrder</ins><auto, Key<del>, Key</del>> Compare = less<Key>, + Allocator Alloc = allocator<Key> > + requires NothrowDestructible<Key> && CopyConstructible<Compare> + && AllocatableElement<Alloc, Compare, const Compare&> + && AllocatableElement<Alloc, Compare, Compare&&> + class set; + + ... + + template <ValueType Key, <del>Predicate</del><ins>StrictWeakOrder</ins><auto, Key<del>, Key</del>> Compare = less<Key>, + Allocator Alloc = allocator<Key> > + requires NothrowDestructible<Key> && CopyConstructible<Compare> + && AllocatableElement<Alloc, Compare, const Compare&> + && AllocatableElement<Alloc, Compare, Compare&&> + class multiset; + + ... + + } +</pre></blockquote> + +<p> + 23.4.1p2 Class template map [map] +</p> +<blockquote><pre> namespace std { + template <ValueType Key, ValueType T, + <del>Predicate</del><ins>StrictWeakOrder</ins><auto, Key<del>, Key</del>> Compare = less<Key>, + Allocator Alloc = allocator<pair&lt;<b>const Key, T> > > + requires NothrowDestructible<Key> && NothrowDestructible<T> + && CopyConstructible<Compare> + && AllocatableElement<Alloc, Compare, const Compare&> + && AllocatableElement<Alloc, Compare, Compare&&> + class map { + ... + }; + } +</pre></blockquote> + + +<p> + 23.4.2p2 Class template multimap [multimap] +</p> +<blockquote><pre> namespace std { + template <ValueType Key, ValueType T, + <del>Predicate</del><ins>StrictWeakOrder</ins><auto, Key<del>, Key</del>> Compare = less<Key>, + Allocator Alloc = allocator<pair&lt;<b>const Key, T> > > + requires NothrowDestructible<Key> && NothrowDestructible<T> + && CopyConstructible<Compare> + && AllocatableElement<Alloc, Compare, const Compare&> + && AllocatableElement<Alloc, Compare, Compare&&> + class multimap { + ... + }; + } +</pre></blockquote> + + +<p> + 23.4.3p2 Class template set [set] +</p> +<blockquote><pre> namespace std { + template <ValueType Key, <del>Predicate</del><ins>StrictWeakOrder</ins><auto, Key<del>, Key</del>> Compare = less<Key>, + Allocator Alloc = allocator<Key> > + requires NothrowDestructible<Key> && CopyConstructible<Compare> + && AllocatableElement<Alloc, Compare, const Compare&> + && AllocatableElement<Alloc, Compare, Compare&&> + class set { + ... + }; + } +</pre></blockquote> + + +<p> + 23.4.4p2 Class template multiset [multiset] +</p> +<blockquote><pre> namespace std { + template <ValueType Key, <del>Predicate</del><ins>StrictWeakOrder</ins><auto, Key<del>, Key</del>> Compare = less<Key>, + Allocator Alloc = allocator<Key> > + requires NothrowDestructible<Key> && CopyConstructible<Compare> + && AllocatableElement<Alloc, Compare, const Compare&> + && AllocatableElement<Alloc, Compare, Compare&&> + class multiset { + ... + }; + } +</pre></blockquote> + +<p> + 23.5 Unordered associative containers [unord] +</p> +<p> + 1 Headers <unordered_map> and <unordered_set>: +</p> +<p> + Header <unordered_map> synopsis +</p> +<blockquote><pre> namespace std { + // 23.5.1, class template unordered_map: + template <ValueType Key, + ValueType T, + Callable<auto, const Key&> Hash = hash<Key>, + <del>Predicate</del><ins>EquivalenceRelation</ins><auto, Key<del>, Key</del>> Pred = equal_to<Key>, + Allocator Alloc = allocator<pair&lt;<b>const Key, T> > > + requires NothrowDestructible<Key> && NothrowDestructible<T> + && SameType<Hash::result_type, size_t> + && CopyConstructible<Hash> && CopyConstructible<Pred> + && AllocatableElement<Alloc, Pred, const Pred&> + && AllocatableElement<Alloc, Pred, Pred&&> + && AllocatableElement<Alloc, Hash, const Hash&> + && AllocatableElement<Alloc, Hash, Hash&&> + class unordered_map; + + // 23.5.2, class template unordered_multimap: + template <ValueType Key, + ValueType T, + Callable<auto, const Key&> Hash = hash<Key>, + <del>Predicate</del><ins>EquivalenceRelation</ins><auto, Key<del>, Key</del>> Pred = equal_to<Key>, + Allocator Alloc = allocator<pair&lt;<b>const Key, T> > > + requires NothrowDestructible<Key> && NothrowDestructible<T> + && SameType<Hash::result_type, size_t> + && CopyConstructible<Hash> && CopyConstructible<Pred> + && AllocatableElement<Alloc, Pred, const Pred&> + && AllocatableElement<Alloc, Pred, Pred&&> + && AllocatableElement<Alloc, Hash, const Hash&> + && AllocatableElement<Alloc, Hash, Hash&&> + class unordered_multimap; + + ... + } +</pre></blockquote> + +<p> + Header <unordered_set> synopsis +</p> +<blockquote><pre> namespace std { + // 23.5.3, class template unordered_set: + template <ValueType Value, + Callable<auto, const Value&> Hash = hash<Value>, + <del>Predicate</del><ins>EquivalenceRelation</ins><auto, Value<del>, Value</del>> class Pred = equal_to<Value>, + Allocator Alloc = allocator<Value> > + requires NothrowDestructible<Value> + && SameType<Hash::result_type, size_t> + && CopyConstructible<Hash> && CopyConstructible<Pred> + && AllocatableElement<Alloc, Pred, const Pred&> + && AllocatableElement<Alloc, Pred, Pred&&> + && AllocatableElement<Alloc, Hash, const Hash&> + && AllocatableElement<Alloc, Hash, Hash&&> + class unordered_set; + + // 23.5.4, class template unordered_multiset: + template <ValueType Value, + Callable<auto, const Value&> Hash = hash<Value>, + <del>Predicate</del><ins>EquivalenceRelation</ins><auto, Value<del>, Value</del>> class Pred = equal_to<Value>, + Allocator Alloc = allocator<Value> > + requires NothrowDestructible<Value> + && SameType<Hash::result_type, size_t> + && CopyConstructible<Hash> && CopyConstructible<Pred> + && AllocatableElement<Alloc, Pred, const Pred&> + && AllocatableElement<Alloc, Pred, Pred&&> + && AllocatableElement<Alloc, Hash, const Hash&> + && AllocatableElement<Alloc, Hash, Hash&&> + class unordered_multiset; + + ... + } +</pre></blockquote> + +<p> + 23.5.1p3 Class template unordered_map [unord.map] +</p> +<blockquote><pre> namespace std { + template <ValueType Key, + ValueType T, + Callable<auto, const Key&> Hash = hash<Key>, + <del>Predicate</del><ins>EquivalenceRelation</ins><auto, Key<del>, Key</del>> Pred = equal_to<Key>, + Allocator Alloc = allocator<pair&lt;<b>const Key, T> > > + requires NothrowDestructible<Key> && NothrowDestructible<T> + && SameType<Hash::result_type, size_t> + && CopyConstructible<Hash> && CopyConstructible<Pred> + && AllocatableElement<Alloc, Pred, const Pred&> + && AllocatableElement<Alloc, Pred, Pred&&> + && AllocatableElement<Alloc, Hash, const Hash&> + && AllocatableElement<Alloc, Hash, Hash&&> + class unordered_map + { + ... + }; + } +</pre></blockquote> + +<p> + 23.5.2p3 Class template unordered_multimap [unord.multimap] +</p> +<blockquote><pre> namespace std { + template <ValueType Key, + ValueType T, + Callable<auto, const Key&> Hash = hash<Key>, + <del>Predicate</del><ins>EquivalenceRelation</ins><auto, Key<del>, Key</del>> Pred = equal_to<Key>, + Allocator Alloc = allocator<pair&lt;<b>const Key, T> > > + requires NothrowDestructible<Key> && NothrowDestructible<T> + && SameType<Hash::result_type, size_t> + && CopyConstructible<Hash> && CopyConstructible<Pred> + && AllocatableElement<Alloc, Pred, const Pred&> + && AllocatableElement<Alloc, Pred, Pred&&> + && AllocatableElement<Alloc, Hash, const Hash&> + && AllocatableElement<Alloc, Hash, Hash&&> + class unordered_multimap + { + ... + }; + } +</pre></blockquote> + +<p> + 23.5.3p3 Class template unordered_set [unord.set] +</p> +<blockquote><pre> namespace std { + template <ValueType Value, + Callable<auto, const Value&> Hash = hash<Value>, + <del>Predicate</del><ins>EquivalenceRelation</ins><auto, Value<del>, Value</del>> class Pred = equal_to<Value>, + Allocator Alloc = allocator<Value> > + requires NothrowDestructible<Value> + && SameType<Hash::result_type, size_t> + && CopyConstructible<Hash> && CopyConstructible<Pred> + && AllocatableElement<Alloc, Pred, const Pred&> + && AllocatableElement<Alloc, Pred, Pred&&> + && AllocatableElement<Alloc, Hash, const Hash&> + && AllocatableElement<Alloc, Hash, Hash&&> + class unordered_set + { + ... + }; + } +</pre></blockquote> +<p> + 23.5.4p3 Class template unordered_multiset [unord.multiset] +</p> +<blockquote><pre> namespace std { + template <ValueType Value, + Callable<auto, const Value&> Hash = hash<Value>, + <del>Predicate</del><ins>EquivalenceRelation</ins><auto, Value<del>, Value</del>> class Pred = equal_to<Value>, + Allocator Alloc = allocator<Value> > + requires NothrowDestructible<Value> + && SameType<Hash::result_type, size_t> + && CopyConstructible<Hash> && CopyConstructible<Pred> + && AllocatableElement<Alloc, Pred, const Pred&> + && AllocatableElement<Alloc, Pred, Pred&&> + && AllocatableElement<Alloc, Hash, const Hash&> + && AllocatableElement<Alloc, Hash, Hash&&> + class unordered_multiset + { + ... + }; + } +</pre></blockquote> + </blockquote> + + + + + +<hr> +<h3><a name="1112"></a>1112. bitsets and new style for loop</h3> +<p><b>Section:</b> 20.3.6 [template.bitset] <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>Opened:</b> 2009-05-06 <b>Last modified:</b> 2009-05-25</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#template.bitset">active issues</a> in [template.bitset].</p> +<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#Open">Open</a> status.</p> +<p><b>Discussion:</b></p> +<p> +<tt>Std::bitset</tt> is a homogeneous container-like sequence of bits, yet it does +not model the Range concept so cannot be used with the new for-loop syntax. +It is the only such type in the library that does NOT support the new for +loop. +</p> +<p> +The obvious reason is that bitset does not support iterators. +</p> +<p> +At least two reasonable solutions are available: +</p> +<ol type="i"> +<li> +Add an iterator interface to <tt>bitset</tt>, bringing its interface close to that +of <tt>std::array</tt> +</li> +<li> +Provide an unspecified concept_map for <tt>Range<bitset></tt>. +</li> +</ol> +<p> +The latter will still need some kind of iterator-like adapter for <tt>bitset</tt>, +but gives implementers greater freedom on the details. E.g. begin/end return +some type that simply invokes <tt>operator[]</tt> on the object it wraps, and +increments its index on <tt>operator++</tt>. A vendor can settle for <tt>InputIterator</tt> +support, rather than wrapping up a full <tt>RandomAccessIterator</tt>. +</p> +<p> +I have a mild preference for option (ii) as I think it is less work to +specify at this stage of the process, although (i) is probably more useful +in the long run. +</p> <p> -add one further sentence: +Hmm, my wording looks a little woolly, as it does not say what the element +type of the range is. Do I get a range of <tt>bool</tt>, <tt>bitset<N>::reference</tt>, or +something else entirely? </p> +<p> +I guess most users will assume the behaviour of reference, but expect to +work with <tt>bool</tt>. <tt>Bool</tt> is OK for read-only traversal, but you really need to +take a reference to a <tt>bitset::reference</tt> if you want to write back. +</p> + +<p><i>[ +Batavia (2009-05): +]</i></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. +Move to Open. +We further recommend this be deferred until after the next Committee Draft. </blockquote> +<p><i>[ +2009-05-25 Alisdair adds: +]</i></p> + + +<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] +I just stumbled over the <tt>Range concept_map</tt> for <tt>valarray</tt> and this should +probably set the precedent on how to write the wording. </p> + +<p><i>[ +Howard: I've replaced the proposed wording with Alisdair's suggestion. +]</i></p> + + +</blockquote> + + + +<p><b>Proposed resolution:</b></p> + +<p> +20.3.6.X bitset concept maps [bitset.concepts] (made up clause name/number) +</p> +<pre>template<size_t N> +concept_map Range<bitset<N>> { + typedef unspecified iterator; + iterator begin(bitset<N>& a); + iterator end(bitset<N>& a); +} + +template<typename T> +concept_map Range<const bitset<N>> { + typedef unspecified iterator; + iterator begin(const bitset<N>& a); + iterator end(const bitset<N>& a); +} +</pre> <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] +-1- <i>Note:</i> these concept_maps adapt <tt>bitset</tt> to the <tt>Range</tt> concept. </p> +<pre>typedef <i>unspecified</i> iterator; +</pre> + +<blockquote> +-2- <i>Requires:</i> <tt>iterator</tt> shall meet the requirements of the +<tt>RandomAccessIterator</tt> concept and <tt>iterator::reference</tt> +shall equal <tt>bitset<N>::reference</tt> or <tt>const bitset<N>::reference</tt>. +</blockquote> + +<pre>iterator begin(bitset<N>& a); +iterator begin(const bitset<N>& a); +</pre> + +<blockquote> +-3- <i>Returns:</i> an <tt>iterator</tt> referencing the first bit in the <tt>bitset</tt>. +</blockquote> + +<pre>iterator end(bitset<N>& a); +iterator end(const bitset<N>& a); +</pre> + +<blockquote> +-4- <i>Returns:</i> an <tt>iterator</tt> referencing one past the last bit in the <tt>bitset</tt>. +</blockquote> + + + + + + <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> +<h3><a name="1113"></a>1113. <tt>bitset::to_string</tt> could be simplified</h3> +<p><b>Section:</b> 20.3.6 [template.bitset] <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>Opened:</b> 2009-05-09 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#template.bitset">active issues</a> in [template.bitset].</p> +<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#Open">Open</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: +In <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#853">853</a> our resolution is changing the signature by adding two +defaulting arguments to 3 calls. In principle, this means that ABI breakage +is not an issue, while API is preserved. +</p> +<p> +With that observation, it would be very nice to use the new ability to +supply default template parameters to function templates to collapse all 3 +signatures into 1. In that spirit, this issue offers an alternative resolution +than that of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#853">853</a>. </p> +<p><i>[ +Batavia (2009-05): +]</i></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.[..] +Move to Open, +and look at the issue again after <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#853">853</a> has been accepted. +We further recommend this be deferred until after the next Committee Draft. </blockquote> + +<p><b>Proposed resolution:</b></p> + +<ol type="A"> +<li> +<p> +In 20.3.6 [template.bitset]/1 (class bitset) ammend: +</p> +<blockquote><pre>template <class charT <ins>= char</ins>, + class traits <ins>= char_traits<charT></ins>, + class Allocator <ins>= allocator<charT></ins>> + basic_string<charT, traits, Allocator> + to_string(charT zero = charT('0'), charT one = charT('1')) const; +<del>template <class charT, class traits> + basic_string<charT, traits, allocator<charT> > to_string() const; +template <class charT> + basic_string<charT, char_traits<charT>, allocator<charT> > to_string() const; +basic_string<char, char_traits<char>, allocator<char> > to_string() const;</del> +</pre></blockquote> +</li> +<li> <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>. +In 20.3.6.2 [bitset.members] prior to p35 ammend: </p> +<blockquote><pre>template <class charT <ins>= char</ins>, + class traits <ins>= char_traits<charT></ins>, + class Allocator <ins>= allocator<charT></ins>> + basic_string<charT, traits, Allocator> + to_string(charT zero = charT('0'), charT one = charT('1')) const; +</pre></blockquote> +</li> +<li> +Strike 20.3.6.2 [bitset.members] paragraphs 37 -> 39 (including signature +above 37) +</li> +</ol> + + + + + + +<hr> +<h3><a name="1114"></a>1114. Type traits underspecified</h3> +<p><b>Section:</b> 20.6 [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>Opened:</b> 2009-05-12 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta">active issues</a> in [meta].</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> -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. +Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#975">975</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1023">1023</a>. </p> +<p> +The current wording in 20.6.1 [meta.rqmts] is still unclear concerning +it's requirements on the type traits classes regarding ambiguities. +Specifically it's unclear +</p> + +<ul> +<li> +if a predicate trait (20.6.4 [meta.unary], 20.6.5 [meta.rel]) could derive from both +<tt>true_type</tt>/<tt>false_type</tt>. +</li> +<li> +if any of the type traits (20.6.1 [meta.rqmts], 20.6.4 [meta.unary], 20.6.5 [meta.rel]) could ambiguously derive +from the same specified result type. +</li> +<li> +if any of the type traits (20.6.1 [meta.rqmts], 20.6.4 [meta.unary], 20.6.5 [meta.rel]) could derive from other +<tt>integral_constant</tt> types making the contained names ambiguous +</li> +<li> +if any of the type traits (20.6.1 [meta.rqmts], 20.6.4 [meta.unary], 20.6.5 [meta.rel]) could have other base +classes that contain members hiding the name of the result type members +or make the contained member names ambiguous. +</li> +</ul> + +<p><i>[ +Batavia (2009-05): +]</i></p> + +<blockquote> +<p> +Alisdair would prefer to factor some of the repeated text, +but modulo a corner case or two, +he believes the proposed wording is otherwise substantially correct. +</p> +<p> +Move to Open. +</p> +</blockquote> <p><b>Proposed resolution:</b></p> +<p><i>[ +The usage of the notion of a <i>BaseCharacteristic</i> below +might be +useful in other places - e.g. to define the base class relation in +20.7.5 [refwrap], 20.7.15 [func.memfn], or 20.7.16.2 [func.wrap.func]. +In this case it's definition should probably +be moved to Clause 17 +]</i></p> + +<ol> +<li> +<p> +Change 20.6.1 [meta.rqmts]/1 as indicated: +</p> +<blockquote> +[..] It shall be <tt>DefaultConstructible</tt>, <tt>CopyConstructible</tt>, and publicly +<ins>and unambiguously</ins> derived, directly or indirectly, from +<ins>its <i>BaseCharacteristic</i>, which is</ins> a specialization of the +template <tt>integral_constant</tt> (20.6.3), with the arguments to the template +<tt>integral_constant</tt> determined by the requirements for the particular +property being described. <ins>The member names of the +<i>BaseCharacteristic</i> shall be unhidden and unambiguously +available in the <i>UnaryTypeTrait</i>.</ins> +</blockquote> +</li> +<li> +<p> +Change 20.6.1 [meta.rqmts]/2 as indicated: +</p> +<blockquote> +[..] It shall be <tt>DefaultConstructible</tt>, <tt>CopyConstructible</tt>, and publicly +<ins>and unambiguously</ins> derived, directly or indirectly, from +<del>an instance</del> <ins>its <i>BaseCharacteristic</i>, which is a +specialization</ins> of the template <tt>integral_constant</tt> (20.6.3), with +the arguments to the template <tt>integral_constant</tt> determined by the +requirements for the particular relationship being described. <ins>The +member names of the <i>BaseCharacteristic</i> shall be unhidden +and unambiguously available in the <i>BinaryTypeTrait</i>.</ins> +</blockquote> +</li> +<li> +<p> +Change 20.6.4 [meta.unary]/2 as indicated: +</p> +<blockquote> +Each of these templates shall be a <i>UnaryTypeTrait</i> (20.6.1), +<del>publicly derived directly or indirectly from <tt>true_type</tt> if the +corresponding condition is true, otherwise from <tt>false_type</tt></del> +<ins>where its <i>BaseCharacteristic</i> shall be <tt>true_type</tt> if the +corresponding condition is true, otherwise <tt>false_type</tt></ins>. +</blockquote> +</li> +<li> <p> -Change the first sentence of 26.6.5 [numeric.iota]/1: +Change 20.6.5 [meta.rel]/2 as indicated: </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. [..] +Each of these templates shall be a <i>BinaryTypeTrait</i> (20.6.1), +<del>publicly derived directly or indirectly from <tt>true_type</tt> if the +corresponding condition is true, otherwise from <tt>false_type</tt></del> +<ins>where its <i>BaseCharacteristic</i> shall be <tt>true_type</tt> if the +corresponding condition is true, otherwise <tt>false_type</tt></ins>. </blockquote> +</li> +</ol> @@ -18577,1141 +35853,2029 @@ convertible to <tt>ForwardIterator</tt>'s value type. [..] <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> +<h3><a name="1115"></a>1115. <tt>va_copy</tt> missing from Standard macros table</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#New">New</a> + <b>Submitter:</b> Miles Zhao <b>Opened:</b> 2009-05-23 <b>Last modified:</b> 2009-05-23</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#diff.library">issues</a> in [diff.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> -<tt>move_iterator</tt>'s <tt>operator[]</tt> is declared as: +In "Table 122 -- Standard macros" of C.2 [diff.library], which lists the 56 macros +inherited from C library, <tt>va_copy</tt> seems to be missing. But in +"Table 21 -- Header <tt><cstdarg></tt> synopsis" (18.10 [support.runtime]), there is. </p> -<blockquote><pre>reference operator[](difference_type n) const; -</pre></blockquote> +<p><b>Proposed resolution:</b></p> +<p> +Add <tt>va_copy</tt> to Table 122 -- Standard macros in C.2 [diff.library]. +</p> + + + + + +<hr> +<h3><a name="1116"></a>1116. Literal constructors for tuple</h3> +<p><b>Section:</b> 20.5.2 [tuple.tuple] <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>Opened:</b> 2009-05-23 <b>Last modified:</b> 2009-05-24</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#tuple.tuple">active issues</a> in [tuple.tuple].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple.tuple">issues</a> in [tuple.tuple].</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> -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>. +It is not currently possible to construct <tt>tuple</tt> literal values, +even if the elements are all literal types. This is because parameters +are passed to constructor by reference. +</p> +<p> +An alternative would be to pass all constructor arguments by value, where it +is known that *all* elements are literal types. This can be determined with +concepts, although note that the negative constraint really requires +factoring out a separate concept, as there is no way to provide an 'any of +these fails' constraint inline. +</p> +<p> +Note that we will have similar issues with <tt>pair</tt> (and +<tt>tuple</tt> constructors from <tt>pair</tt>) although I am steering +clear of that class while other constructor-related issues settle. </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: +Ammend the tuple class template declaration in 20.5.2 [tuple.tuple] as +follows +</p> + +<blockquote> +<p> +Add the following concept: </p> -<blockquote><pre><del>reference</del> <ins><i>unspecified</i></ins> operator[](difference_type n) const; +<blockquote><pre>auto concept AllLiteral< typename ... Types > { + requires LiteralType<Types>...; +} </pre></blockquote> +<p> +ammend the constructor +</p> + +<blockquote><pre><ins>template <class... UTypes> + requires AllLiteral<Types...> + && Constructible<Types, UTypes>... + explicit tuple(UTypes...);</ins> + +template <class... UTypes> + requires <ins>!AllLiteral<Types...></ins> + <ins>&&</ins> Constructible<Types, UTypes&&>... + explicit tuple(UTypes&&...); +</pre></blockquote> + +<p> +ammend the constructor +</p> + +<blockquote><pre><ins>template <class... UTypes> + requires AllLiteral<Types...> + && Constructible<Types, UTypes>... + tuple(tuple<UTypes...>);</ins> + +template <class... UTypes> + requires <ins>!AllLiteral<Types...></ins> + <ins>&&</ins> Constructible<Types, const UTypes&>... + tuple(const tuple<UTypes...>&); +</pre></blockquote> + +</blockquote> + +<p> +Update the same signatures in 20.5.2.1 [tuple.cnstr], paras 3 and 5. +</p> <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> +<h3><a name="1117"></a>1117. tuple copy constructor</h3> +<p><b>Section:</b> 20.5.2.1 [tuple.cnstr] <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>Opened:</b> 2009-05-23 <b>Last modified:</b> 2009-05-30</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#tuple.cnstr">active issues</a> in [tuple.cnstr].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple.cnstr">issues</a> in [tuple.cnstr].</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> +The copy constructor for the <tt>tuple</tt> template is constrained. This seems an +unusual strategy, as the copy constructor will be implicitly deleted if the +constraints are not met. This is exactly the same effect as requesting an +<tt>=default;</tt> constructor. The advantage of the latter is that it retains +triviality, and provides support for <tt>tuple</tt>s as literal types if issue +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1116">1116</a> is also accepted. +</p> +<p> +Actually, it might be worth checking with core if a constrained copy +constructor is treated as a constructor template, and as such does not +suppress the implicit generation of the copy constructor which would hide +the template in this case. +</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><i>[ +2009-05-27 Daniel adds: +]</i></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> +<blockquote> +This would solve one half of the suggested changes in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#801">801</a>. +</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>. +<p><b>Proposed resolution:</b></p> +<p> +Change 20.5.2 [tuple.tuple] and 20.5.2.1 [tuple.cnstr] p4: +</p> - <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> +<blockquote><pre><del>requires CopyConstructible<Types>...</del> tuple(const tuple&)<ins> = default</ins>; +</pre></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> +<hr> +<h3><a name="1118"></a>1118. tuple query APIs do not support cv-qualification</h3> +<p><b>Section:</b> 20.5.2.3 [tuple.helper] <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>Opened:</b> 2009-05-23 <b>Last modified:</b> 2009-05-25</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#tuple.helper">active issues</a> in [tuple.helper].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple.helper">issues</a> in [tuple.helper].</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 APIs <tt>tuple_size</tt> and <tt>tuple_element</tt> do not support +cv-qualified <tt>tuple</tt>s, <tt>pair</tt>s or <tt>array</tt>s. +</p> +<p> +The most generic solution would be to supply partial specializations once +for each cv-type in the <tt>tuple</tt> header. However, requiring this header for +cv-qualified <tt>pair</tt>s/<tt>array</tt>s seems unhelpful. The BSI editorial +suggestion (UK-198/US-69, +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2533.html">N2533</a>) +to merge <tt>tuple</tt> into <tt><utility></tt> would help with <tt>pair</tt>, +but not <tt>array</tt>. That might be resolved by making a dependency between the +<tt><array></tt> header and <tt><utility></tt>, or simply recognising +the dependency be fulfilled in a Remark. +</p> - - <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><i>[ +2009-05-24 Daniel adds: +]</i></p> - <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> - - +<blockquote> +<p> +All <tt>tuple_size</tt> templates with a base class need to derive publicly, e.g. +</p> + +<blockquote><pre>template <IdentityOf T> class tuple_size< const T > : + <ins>public</ins> tuple_size<T> {}; +</pre></blockquote> + +<p> +The same applies to the tuple_element class hierarchies. +</p> +<p> +What is actually meant with the comment +</p> +<blockquote> +this solution relies on 'metafunction forwarding' to inherit the +nested typename type +</blockquote> +<p> +? +</p> +<p> +I ask, because all base classes are currently unconstrained and their +instantiation is invalid in the constrained context of the <tt>tuple_element</tt> partial +template specializations. +</p> +</blockquote> + +<p><i>[ +2009-05-24 Alisdair adds: +]</i></p> + + +<blockquote> +<p> +I think a better solution might be to ask Pete editorially to change all +declarations of tupling APIs to use the struct specifier instead of class. +</p> +<p> +"metafunction forwarding" refers to the MPL metafunction protocol, where a +metafunction result is declared as a nested typedef with the name "type", +allowing metafunctions to be chained by means of inheritance. It is a +neater syntax than repeatedly declaring a typedef, and inheritance syntax is +slightly nicer when it comes to additional typename keywords. +</p> +<p> +The constrained template with an unconstrained base is a good observation +though. +</p> +</blockquote> + + + +<p><b>Proposed resolution:</b></p> +<p> +Add to 20.5.1 [tuple.general] p2 (Header <tt><tuple></tt> synopsis) +</p> + +<blockquote><pre>// 20.5.2.3, tuple helper classes: +template <IdentityOf T> class tuple_size; // undefined +<ins>template <IdentityOf T> class tuple_size< const T > : tuple_size<T> {};</ins> +<ins>template <IdentityOf T> class tuple_size< volatile T > : tuple_size<T> {};</ins> +<ins>template <IdentityOf T> class tuple_size< const volatile T > : tuple_size<T> {};</ins> + +template <VariableType... Types> class tuple_size<tuple<Types...> >; + +template <size_t I, IdentityOf T> class tuple_element; // undefined +<ins>template <size_t I, IdentityOf T> class tuple_element<I, const T>;</ins> +<ins>template <size_t I, IdentityOf T> class tuple_element<I, volatile T>;</ins> +<ins>template <size_t I, IdentityOf T> class tuple_element<I, const volatile T>;</ins> + +template <size_t I, VariableType... Types> + requires True<(I < sizeof...(Types))> class tuple_element<I, tuple<Types...> >; +</pre></blockquote> + +<p> +Add to 20.5.2.3 [tuple.helper] +</p> +<p><i>[ +(note that this solution relies on 'metafunction forwarding' to inherit the +nested typename type) +]</i></p> + + +<blockquote><pre>template <class... Types> +class tuple_size<tuple<Types...> > + : public integral_constant<size_t, sizeof...(Types)> { }; + +template <size_t I, class... Types> +requires True<(I < sizeof...(Types))> +class tuple_element<I, tuple<Types...> > { +public: + typedef TI type; +}; + +<ins>template <size_t I, IdentityOf T> + class tuple_element<I, const T> : add_const<tuple_element<I,T>> {};</ins> + +<ins>template <size_t I, IdentityOf T> + class tuple_element<I, volatile T> : add_volatile<tuple_element<I,T>> {};</ins> + +<ins>template <size_t I, IdentityOf T> + class tuple_element<I, const volatile T> : add_cv<tuple_element<I,T>> {};</ins> +</pre></blockquote> + + + + + +<hr> +<h3><a name="1119"></a>1119. tuple query APIs do not support references</h3> +<p><b>Section:</b> 20.5.2.3 [tuple.helper] <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>Opened:</b> 2009-05-23 <b>Last modified:</b> 2009-05-24</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#tuple.helper">active issues</a> in [tuple.helper].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple.helper">issues</a> in [tuple.helper].</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>tuple</tt> query APIs <tt>tuple_size</tt> and +<tt>tuple_element</tt> do not support references-to-tuples. This can be +annoying when a template deduced a parameter type to be a reference, +which must be explicitly stripped with <tt>remove_reference</tt> before calling +these APIs. +</p> +<p> +I am not proposing a resolution at this point, as there is a +combinatorial explosion with lvalue/rvalue references and +cv-qualification (see previous issue) that suggests some higher +refactoring is in order. This might be something to kick back over to +Core/Evolution. +</p> +<p> +Note that we have the same problem in numeric_limits. +</p> + + +<p><b>Proposed resolution:</b></p> + <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> +<h3><a name="1120"></a>1120. New type trait - remove_all</h3> +<p><b>Section:</b> 20.6 [meta] <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>Opened:</b> 2009-05-23 <b>Last modified:</b> 2009-05-24</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta">active issues</a> in [meta].</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#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>. +Sometimes it is necessary to remove all qualifiers from a type before +passing on to a further API. A good example would be calling the +<tt>tuple</tt> query APIs <tt>tuple_size</tt> or <tt>tuple_element</tt> +with a deduced type inside a function template. If the deduced type is +cv-qualified or a reference then the call will fail. The solution is to +chain calls to +<tt>remove_cv<remove_reference<T>::type>::type</tt>, and +note that the order matters. </p> +<p> +Suggest it would be helpful to add a new type trait, +<tt>remove_all</tt>, that removes all top-level qualifiers from a type +i.e. cv-qualification and any references. Define the term in such a way +that if additional qualifiers are added to the language, then +<tt>remove_all</tt> is defined as stripping those as well. +</p> + + +<p><b>Proposed resolution:</b></p> + + +<hr> +<h3><a name="1121"></a>1121. Support for multiple arguments</h3> +<p><b>Section:</b> 20.4.2 [ratio.arithmetic] <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>Opened:</b> 2009-05-25 <b>Last modified:</b> 2009-05-25</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#ratio.arithmetic">active issues</a> in [ratio.arithmetic].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ratio.arithmetic">issues</a> in [ratio.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> +Both add and multiply could sensibly be called with more than two arguments. +The variadic template facility makes such declarations simple, and is likely +to be frequently wrapped by end users if we do not supply the variant +ourselves. +</p> +<p> +We deliberately ignore divide at this point as it is not transitive. +Likewise, subtract places special meaning on the first argument so I do not +suggest extending that immediately. Both could be supported with analogous +wording to that for add/multiply below. +</p> +<p> +Note that the proposed resolution is potentially incompatible with that +proposed for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#921">921</a>, although the addition of the typedef to ratio would be +equally useful. +</p> + + <p><b>Proposed resolution:</b></p> -<ol> -<li> +<p><i>[ +note that this wording relies on 'metafunction forwarding' as described by +Boost MPL +]</i></p> + + <p> -In 26.4.8.5.1 [rand.dist.samp.discrete]/1, class <tt>discrete_distribution</tt>, -just <em>before</em> the member declaration +20.4 [ratio] p3 synopsis: change </p> -<blockquote><pre>explicit discrete_distribution(const param_type& parm); +<blockquote><pre>// ratio arithmetic +template <class R1, class R2<ins>, class ... RList</ins>> struct ratio_add; +template <class R1, class R2> struct ratio_subtract; +template <class R1, class R2<ins>, class ... RList</ins>> struct ratio_multiply; +template <class R1, class R2> struct ratio_divide; </pre></blockquote> <p> -insert +20.4.2 [ratio.arithmetic] p1: change </p> -<blockquote><pre>discrete_distribution(initializer_list<double> wl); +<blockquote><pre><ins>template <class R1, class R2, class ... RList> struct ratio_add + : ratio_add< R1, ratio_add<R2, RList...>> { +};</ins> + +template <class R1, class R2> struct ratio_add<ins><R1, R2></ins> { + typedef <i>see below</i> type; +}; </pre></blockquote> -</li> -<li> + +<p> +20.4.2 [ratio.arithmetic] p3: change +</p> + +<blockquote><pre><ins>template <class R1, class R2, class ... RList> struct ratio_multiply + : ratio_multiply< R1, ratio_ multiply <R2, RList...>> { +};</ins> + +template <class R1, class R2> struct ratio_ multiply<ins><R1, R2></ins> { + typedef <i>see below</i> type; +}; +</pre></blockquote> + + + + + + +<hr> +<h3><a name="1122"></a>1122. Ratio values should be constexpr</h3> +<p><b>Section:</b> 20.4.1 [ratio.ratio] <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>Opened:</b> 2009-05-25 <b>Last modified:</b> 2009-05-25</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#ratio.ratio">active issues</a> in [ratio.ratio].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ratio.ratio">issues</a> in [ratio.ratio].</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 values <tt>num</tt> and <tt>den</tt> in the <tt>ratio</tt> template +should be declared <tt>constexpr</tt>. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +20.4.1 [ratio.ratio] +</p> + +<blockquote><pre>namespace std { + template <intmax_t N, intmax_t D = 1> + class ratio { + public: + static const<ins>expr</ins> intmax_t num; + static const<ins>expr</ins> intmax_t den; + }; +} +</pre></blockquote> + + + + + + +<hr> +<h3><a name="1123"></a>1123. no requirement that standard streams be flushed</h3> +<p><b>Section:</b> 27.5.2.1.6 [ios::Init] <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>Opened:</b> 2009-05-14 <b>Last modified:</b> 2009-05-30</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#ios::Init">active issues</a> in [ios::Init].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios::Init">issues</a> in [ios::Init].</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 currently formulated, the standard doesn't require that there +is ever a flush of <tt>cout</tt>, etc. (This implies, for example, that +the classical hello, world program may have no output.) In the +current draft +(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdf">N2798</a>), +there is a requirement that the objects +be constructed before <tt>main</tt>, and before the dynamic +initialization of any non-local objects defined after the +inclusion of <tt><iostream></tt> in the same translation unit. The only +requirement that I can find concerning flushing, however, is in +27.5.2.1.6 [ios::Init], where the destructor of the last +<tt>std::ios_base::Init</tt> object flushes. But there is, as far as I +can see, no guarantee that such an object ever exists. +</p> +<p> +Also, the wording in [iostreams.objects] says that: +</p> +<blockquote> +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. +</blockquote> +<p> +In 27.5.2.1.6 [ios::Init], however, as an +effect of the constructor, it says that +</p> +<blockquote> +If <tt>init_cnt</tt> is zero, +the function stores the value one in <tt>init_cnt</tt>, then constructs +and initializes the objects <tt>cin</tt>, <tt>cout</tt>, <tt>cerr</tt>, <tt>clog</tt> +<tt>wcin</tt>, <tt>wcout</tt>, <tt>wcerr</tt>, and <tt>wclog</tt>" +</blockquote> + +<p> +which seems to forbid earlier +construction. +</p> + +<p> +(Note that with these changes, the exposition only "<tt>static +int init_cnt</tt>" in <tt>ios_base::Init</tt> can be dropped.) +</p> +<p> +Of course, a determined programmer can still inhibit the +flush with things like: +</p> +<blockquote><pre>new std::ios_base::Init ; // never deleted +</pre></blockquote> +<p> +or (in a function): +</p> +<blockquote><pre>std::ios_base::Init ensureConstruction ; +// ... +exit( EXIT_SUCCESS ) ; +</pre></blockquote> +<p> +Perhaps some words somewhere to the effect that all +<tt>std::ios_base::Init</tt> objects should have static lifetime +would be in order. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Change 27.4 [iostream.objects]/2: +</p> + +<blockquote> +-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>292</sup> The objects are not destroyed +during program execution.<sup>293</sup> +<del>If a translation unit includes +<tt><iostream></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> +<ins>The results of including <tt><iostream></tt> in a translation +unit shall be as if <tt><iostream></tt> defined an instance of +<tt>ios_base::Init</tt> with static lifetime. Similarly, the entire +program shall behave as if there were at least one instance of +<tt>ios_base::Init</tt> with static lifetime.</ins> +</blockquote> + <p> -Between p.4 and p.5 of the same section insert a new -paragraph as part of the new member description: +Change 27.5.2.1.6 [ios::Init]/3: </p> -<blockquote><pre>discrete_distribution(initializer_list<double> wl); +<blockquote> +<pre>Init(); </pre> +<blockquote> +-3- <i>Effects:</i> Constructs an object of class <tt>Init</tt>. +<del>If <tt>init_cnt</tt> is zero, the function stores the value one in +<tt>init_cnt</tt>, then constructs and initializes the objects +<tt>cin</tt>, <tt>cout</tt>, <tt>cerr</tt>, <tt>clog</tt> (27.4.1), +<tt>wcin</tt>, <tt>wcout</tt>, <tt>wcerr</tt>, and <tt>wclog</tt> +(27.4.2). In any case, the function then adds one to the value stored in +<tt>init_cnt</tt>.</del> +<ins>Constructs and initializes the objects <tt>cin</tt>, <tt>cout</tt>, +<tt>cerr</tt>, <tt>clog</tt>, <tt>wcin</tt>, <tt>wcout</tt>, +<tt>wcerr</tt> and <tt>wclog</tt> if they have not already been +constructed and initialized.</ins> +</blockquote> +</blockquote> +<p> +Change 27.5.2.1.6 [ios::Init]/4: +</p> + +<blockquote> +<pre>~Init(); +</pre> <blockquote> -<i>Effects:</i> Same as <tt>discrete_distribution(wl.begin(), wl.end())</tt>. +-4- <i>Effects:</i> Destroys an object of class <tt>Init</tt>. +<del>The function subtracts one from the value stored in <tt>init_cnt</tt> and, +if the resulting stored value is one,</del> +<ins>If there are no other instances of the class still in +existance,</ins> +calls <tt>cout.flush()</tt>, +<tt>cerr.flush()</tt>, <tt>clog.flush()</tt>, <tt>wcout.flush()</tt>, +<tt>wcerr.flush()</tt>, <tt>wclog.flush()</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> +<h3><a name="1124"></a>1124. Invalid definition of concept RvalueOf</h3> +<p><b>Section:</b> 20.2.1 [concept.transform] <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>Opened:</b> 2009-05-28 <b>Last modified:</b> 2009-05-30</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#concept.transform">active issues</a> in [concept.transform].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#concept.transform">issues</a> in [concept.transform].</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>. +A recent news group +<a href="http://groups.google.de/group/comp.std.c++/browse_frm/thread/8eb92768a19fb46f">article</a> +points to several defects in the +specification of reference-related concepts. +</p> +<p> +One problem of the concept <tt>RvalueOf</tt> as currently defined in +20.2.1 [concept.transform]: +</p> + +<blockquote><pre>concept RvalueOf<typename T> { + typename type = T&&; + requires ExplicitlyConvertible<T&,type> && Convertible<T&&,type>; +} + +template<typename T> concept_map RvalueOf<T&> { + typedef T&& type; +} +</pre></blockquote> + +<p> +is that if <tt>T</tt> is an lvalue-reference, the requirement +<tt>Convertible<T&&,type></tt> isn't satisfied for +lvalue-references, because after reference-collapsing in the concept +definition we have <tt>Convertible<T&,type></tt> in this case, +which isn't satisfied in the concept map template and also is not the +right constraint either. I think that the reporter is right that +<tt>SameType</tt> requirements should do the job and that we also should +use the new <tt>RvalueReference</tt> concept to specify a best matching +type requirement. </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 +In 20.2.1 [concept.transform] before p. 4 change as indicated: </p> -<blockquote><pre>explicit piecewise_constant_distribution(const param_type& parm); +<blockquote><pre>auto concept RvalueOf<typename T> { + <del>typename</del><ins>RvalueReference</ins> type = T&&; + requires <del>ExplicitlyConvertible<T&, type> && Convertible<T&&, type></del><ins>SameType<T&, type&></ins>; +} </pre></blockquote> + + + + +<hr> +<h3><a name="1125"></a>1125. ostream_iterator does not work with movable types</h3> +<p><b>Section:</b> 24.6.2.2 [ostream.iterator.ops] <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>Opened:</b> 2009-05-28 <b>Last modified:</b> 2009-05-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> -insert +<tt>ostream_iterator</tt> has not been updated to support moveable types, in a +similar manner to the insert iterators. +Note that this is not a problem for <tt>ostreambuf_iterator</tt>, as the types it is +restricted to dealing with do not support extra-efficient moving. </p> -<blockquote><pre>template<typename Func> -piecewise_constant_distribution(initializer_list<RealType> bl, Func fw); + +<p><b>Proposed resolution:</b></p> +<p> +Add second <tt>operator=</tt> overload to class <tt>template ostream_iterator</tt> +in 24.6.2 [ostream.iterator], para 2: +</p> + +<blockquote><pre>ostream_iterator<T,charT,traits>& operator=(const T& value); +<ins>ostream_iterator<T,charT,traits>& operator=(T&& value);</ins> </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: +Add a new paragraph: in 24.6.2.2 [ostream.iterator.ops]: </p> -<blockquote><pre>template<typename Func> -piecewise_constant_distribution(initializer_list<RealType> bl, Func fw); +<blockquote> +<pre>ostream_iterator& operator=(T&& value); </pre> - <blockquote> +<p> +-2- <i>Effects:</i> +</p> +<blockquote><pre>*out_stream << std::move(value); +if(delim != 0) + *out_stream << delim; +return (*this); +</pre></blockquote> +</blockquote> +</blockquote> + + + + + +<hr> +<h3><a name="1126"></a>1126. <tt>istreambuff_iterator::equal</tt> needs a const & parameter</h3> +<p><b>Section:</b> 24.6.3.5 [istreambuf.iterator::equal] <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>Opened:</b> 2009-05-28 <b>Last modified:</b> 2009-05-30</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#istreambuf.iterator::equal">active issues</a> in [istreambuf.iterator::equal].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istreambuf.iterator::equal">issues</a> in [istreambuf.iterator::equal].</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> -[p5_1] <i>Complexity:</i> Exactly <tt>nf = max(bl.size(), 1) - 1</tt> invocations of <tt>fw</tt>. +The <tt>equal</tt> member function of <tt>istreambuf_iterator</tt> is +declared <tt>const</tt>, but takes its argument by non-const reference. </p> +<p> +This is not compatible with the <tt>operator==</tt> free function overload, which is +defined in terms of calling <tt>equal</tt> yet takes both arguments by reference to +const. +</p> + +<p><i>[ +The proposed wording is consistent with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#110">110</a> with status TC1. +]</i></p> + + + +<p><b>Proposed resolution:</b></p> <p> -[p5_2] <i>Requires:</i> +Ammend in both:<br> +24.6.3 [istreambuf.iterator]<br> +24.6.3.5 [istreambuf.iterator::equal]<br> </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> +<blockquote><pre>bool equal(<ins>const </ins>istreambuf_iterator& b) const; +</pre></blockquote> + + + + + + +<hr> +<h3><a name="1127"></a>1127. rvalue references and iterator traits</h3> +<p><b>Section:</b> D.10.1 [iterator.traits] <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>Opened:</b> 2009-05-28 <b>Last modified:</b> 2009-05-30</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.traits">issues</a> in [iterator.traits].</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 deprecated support for <tt>iterator_traits</tt> and legacy (unconstrained) +iterators features the (exposition only) concept: +</p> + +<blockquote><pre>concept IsReference<typename T> { } // exposition only +template<typename T> concept_map IsReference<T&> { } +</pre></blockquote> +<p> +Now this looks exactly like the <tt>LvalueReference</tt> concept recently added to +clause 20, so I wonder if we should use that instead? +Then I consider the lack of rvalue-reference support, which means that +<tt>move_iterator</tt> would always flag as merely supporting the <tt>input_iterator_tag</tt> +category. This suggests we retain the exposition concept, but add a second +concept_map to support rvalue references. +</p> +<p> +I would suggest adding the extra concept_map is the right way forward, but +still wonder if the two exposition-only concepts in this clause might be +worth promoting to clause 20. That question might better be answered with a +fuller investigation of type_trait/concept unification though. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +In Iterator traits D.10.1 [iterator.traits] para 4 add: +</p> + +<blockquote><pre>concept IsReference<typename T> { } // exposition only +template<typename T> concept_map IsReference<T&> { } +<ins>template<typename T> concept_map IsReference<T&&> { }</ins> +</pre></blockquote> + + + + + + +<hr> +<h3><a name="1128"></a>1128. Missing definition of <tt>iterator_traits<T*></tt></h3> +<p><b>Section:</b> 24.3 [iterator.syn] <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>Opened:</b> 2009-05-28 <b>Last modified:</b> 2009-05-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> +The <tt><iterator></tt> header synopsis declares a partial specialization of +<tt>iterator_traits</tt> to support pointers, 24.3 [iterator.syn]. The implication +is that specialization will be described in D10, yet it did not follow the +rest of the deprecated material into this clause. +</p> +<p> +However, this is not as bad as it first seems! +There are partial specializations of <tt>iterator_traits</tt> for types that satisfy +the various Iterator concepts, and there are concept_maps for pointers to +explicitly support the <tt>RandomAccessIterator</tt> concept, so the required +template will be present - just not in the manner advertised. +</p> +<p> +I can see two obvious solutions: +</p> + +<ol type="i"> <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; +Restore the <tt>iterator_traits<T*></tt> partial specialization in D.10 </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>. +Remove the declaration of <tt>iterator_traits<T*></tt> from 24.3 synopsis </li> </ol> +<p> +I recommend option (ii) in the wording below +</p> +<p> +Option (ii) could be extended to strike all the declarations of deprecated +material from the synopsis, as it is effectively duplicating D.10 anyway. +This is the approach taken for deprecated library components in the 98/03 +standards. This is probably a matter best left to the Editor though. +</p> + +<p><b>Proposed resolution:</b></p> <p> -[p5_3] <i>Effects:</i> +In 24.3 [iterator.syn] strike: </p> -<ol type="a"> -<li> -<p>If <tt>nf == 0</tt>,</p> -<ol type="a"> +<blockquote><pre><del>template<class T> struct iterator_traits<T*>;</del> +</pre></blockquote> + + + + + + +<hr> +<h3><a name="1129"></a>1129. <tt>istream(buf)_iterator</tt> should support literal sentinel value</h3> +<p><b>Section:</b> 24.6.1.1 [istream.iterator.cons], 24.6.3 [istreambuf.iterator] <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>Opened:</b> 2009-05-30 <b>Last modified:</b> 2009-06-09</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>istream_iterator</tt> and <tt>istreambuf_iterator</tt> should support literal sentinel +values. The default constructor is frequently used to terminate ranges, and +could easily be a literal value for <tt>istreambuf_iterator</tt>, and +<tt>istream_iterator</tt> when iterating value types. A little more work using a +suitably sized/aligned char-array for storage (or an updated component like +<tt>boost::optional</tt> proposed for TR2) would allow <tt>istream_iterator</tt> to support +<tt>constexpr</tt> default constructor in all cases, although we might leave this +tweak as a QoI issue. Note that requiring <tt>constexpr</tt> be supported also +allows us to place no-throw guarantees on this constructor too. +</p> + +<p><i>[ +2009-06-02 Daniel adds: +]</i></p> + + +<blockquote> +<p> +I agree with the usefulness of the issue suggestion, but we need +to ensure that <tt>istream_iterator</tt> <em>can</em> satisfy be literal if needed. +Currently this is not clear, because 24.6.1 [istream.iterator]/3 declares +a copy constructor and a destructor and explains their semantic in +24.6.1.1 [istream.iterator.cons]/3+4. +</p> +<p> +The prototype semantic specification is ok (although it seems +somewhat redundant to me, because the semantic doesn't say +anything interesting in both cases), but for support of trivial class +types we also need a trivial copy constructor and destructor as of +9 [class]/6. The current non-informative specification of these +two special members suggests to remove their explicit declaration +in the class and add explicit wording that says that if <tt>T</tt> is +trivial a default constructed iterator is also literal, alternatively it +would be possible to mark both as defaulted and add explicit +(memberwise) wording that guarantees that they are trivial. +</p> +<p> +Btw.: I'm quite sure that the <tt>istreambuf_iterator</tt> additions to +ensure triviality are not sufficient as suggested, because the +library does not yet give general guarantees that a defaulted +special member declaration makes this member also trivial. +Note that e.g. the atomic types do give a general statement! +</p> +<p> +Finally there is a wording issue: There does not exist something +like a "literal constructor". The core language uses the term +"constexpr constructor" for this. +</p> +<p> +Suggestion: +</p> +<ol> <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 +<p> +Change 24.6.1 [istream.iterator]/3 as indicated: +</p> +<blockquote><pre><ins>constexpr</ins> istream_iterator(); +istream_iterator(istream_type& s); +istream_iterator(const istream_iterator<del><T,charT,traits,Distance></del>& x)<ins> = default</ins>; +~istream_iterator()<ins> = default</ins>; +</pre></blockquote> </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> +<p> +Change 24.6.1.1 [istream.iterator.cons]/1 as indicated: +</p> +<blockquote><pre><ins>constexpr</ins> istream_iterator(); +</pre> +<blockquote> +-1- <i>Effects:</i> Constructs the end-of-stream iterator. <ins>If <tt>T</tt> is a literal type, +then this constructor shall be a constexpr constructor.</ins> +</blockquote> +</blockquote> </li> - <li> -<p>Otherwise,</p> -<ol type="a"> +<p> +Change 24.6.1.1 [istream.iterator.cons]/3 as indicated: +</p> +<blockquote><pre>istream_iterator(const istream_iterator<del><T,charT,traits,Distance></del>& x)<ins> = default</ins>; +</pre> +<blockquote> +-3- <i>Effects:</i> Constructs a copy of <tt>x</tt>. <ins>If <tt>T</tt> is a literal type, then +this constructor shall be a trivial copy constructor.</ins> +</blockquote> +</blockquote> +</li> <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 +<p> +Change 24.6.1.1 [istream.iterator.cons]/4 as indicated: +</p> + +<blockquote><pre>~istream_iterator()<ins> = default</ins>; +</pre> +<blockquote> +-4- <i>Effects:</i> The iterator is destroyed. <ins>If <tt>T</tt> is a literal type, then +this destructor shall be a trivial +destructor.</ins> +</blockquote> +</blockquote> </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>) +<p> +Change 24.6.3 [istreambuf.iterator] before p. 1 as indicated: +</p> + +<blockquote><pre><ins>constexpr</ins> istreambuf_iterator() throw(); +<ins>istreambuf_iterator(const istreambuf_iterator&) throw() = default;</ins> +<ins>~istreambuf_iterator() throw() = default;</ins> </pre></blockquote> </li> -</ol> +<li> +<p> +Change 24.6.3 [istreambuf.iterator]/1 as indicated: +</p> +<blockquote> +[..] 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. <ins>All +specializations of <tt>istreambuf_iterator</tt> shall have a trivial copy +constructor, a constexpr default +constructor and a trivial destructor.</ins> +</blockquote> </li> +</ol> +</blockquote> -<li> + +<p><b>Proposed resolution:</b></p> <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: +24.6.1 [istream.iterator] para 3 </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. + +<blockquote><pre><ins>constexpr</ins> istream_iterator(); </pre></blockquote> -</li> -</ol> +<p> +24.6.1.1 [istream.iterator.cons] +</p> +<blockquote><pre><ins>constexpr</ins> istream_iterator(); +</pre> +<blockquote> +-1- <i>Effects:</i> Constructs the end-of-stream iterator. +<ins>If <tt>T</tt> is a literal type, then this constructor shall +be a literal constructor.</ins> </blockquote> </blockquote> -</li> -</ol> + +<p> +24.6.3 [istreambuf.iterator] +</p> + +<blockquote><pre><ins>constexpr</ins> istreambuf_iterator() throw(); +</pre></blockquote> + <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> +<h3><a name="1130"></a>1130. <tt>copy_exception</tt> name misleading</h3> +<p><b>Section:</b> 18.8.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> Peter Dimov <b>Opened:</b> 2009-05-13 <b>Last modified:</b> 2009-06-02</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> -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. +The naming of <tt>std::copy_exception</tt> misleads almost everyone +(experts included!) to think that it is the function that copies an +<tt>exception_ptr</tt>: </p> + +<blockquote><pre>exception_ptr p1 = current_exception(); +exception_ptr p2 = copy_exception( p1 ); +</pre></blockquote> + <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. +But this is not at all what it does. The above actually creates an +<tt>exception_ptr p2</tt> that contains a copy of <tt>p1</tt>, not of +the exception to which <tt>p1</tt> refers! </p> <p> -Due to earlier support for copy-on-write, we find the following -unnecessary limitations for C++0x: +This is, of course, all my fault; in my defence, I used <tt>copy_exception</tt> +because I was unable to think of a better name. +</p> +<p> +But I believe that, based on what we've seen so far, <em>any</em> other name would be better. +</p> +<p> +Therefore, I propose <tt>copy_exception</tt> to be renamed to +<tt>create_exception</tt>: </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> +<blockquote><pre>template<class E> exception_ptr create_exception(E e); +</pre></blockquote> + +<p> +with the following explanatory paragraph after it: +</p> + +<blockquote> +Creates an <tt>exception_ptr</tt> that refers to a copy of <tt>e</tt>. +</blockquote> + +<p><i>[ +2009-05-13 Daniel adds: +]</i></p> + + +<blockquote> +<p> +What about +</p> +<blockquote><pre>make_exception_ptr +</pre></blockquote> +<p> +in similarity to <tt>make_pair</tt> and <tt>make_tuple</tt>, <tt>make_error_code</tt> and +<tt>make_error_condition</tt>, or <tt>make_shared</tt>? Or, if a stronger symmetry to +<tt>current_exception</tt> is preferred: +</p> + +<blockquote><pre>make_exception +</pre></blockquote> +<p> +We have not a single <tt>create_*</tt> function in the library, it was always +<tt>make_*</tt> used. +</p> +</blockquote> + +<p><i>[ +2009-05-13 Peter adds: +]</i></p> + + +<blockquote> +<tt>make_exception_ptr</tt> works for me. +</blockquote> + +<p><i>[ +2009-06-02 Thomas J. Gritzan adds: +]</i></p> + + +<blockquote> +<p> +To avoid surprises and unwanted recursion, how about making a call to +<tt>std::make_exception_ptr</tt> with an <tt>exception_ptr</tt> illegal? +</p> +<p> +It might work like this: +</p> +<blockquote><pre>template<class E> +exception_ptr make_exception_ptr(E e); +template<> +exception_ptr make_exception_ptr<exception_ptr>(exception_ptr e) = delete; +</pre></blockquote> +</blockquote> + + + +<p><b>Proposed resolution:</b></p> +<p> +Change 18.8.5 [propagation]: +</p> + +<blockquote> +<pre>template<class E> exception_ptr <del>copy_exception</del><ins>make_exception_ptr</ins>(E e); +</pre> + +<blockquote> +<p> +-11- <i>Effects:</i> <ins>Creates an <tt>exception_ptr</tt> that refers +to a copy of <tt>e</tt>,</ins> as if +</p> + +<blockquote><pre>try { + throw e; +} catch(...) { + return current_exception(); +} +</pre></blockquote> + +<p>...</p> +</blockquote> + +</blockquote> + + + + + + +<hr> +<h3><a name="1131"></a>1131. C++0x does not need <tt>alignment_of</tt></h3> +<p><b>Section:</b> 20.6.4.3 [meta.unary.prop] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> + <b>Submitter:</b> Niels Dekker <b>Opened:</b> 2009-06-01 <b>Last modified:</b> 2009-06-02</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta.unary.prop">active issues</a> in [meta.unary.prop].</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#New">New</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The <tt>alignment_of</tt> template is no longer necessary, now that the +core language will provide <tt>alignof</tt>. Scott Meyers raised this +issue at comp.std.c++, +<a href="http://groups.google.com/group/comp.std.c++/browse_thread/thread/9b020306e803f08a">C++0x: alignof vs. alignment_of</a>, +May 21, 2009. In a reply, Daniel Krügler pointed out that +<tt>alignof</tt> was added to the working paper <i>after</i> +<tt>alignment_of</tt>. So it appears that <tt>alignment_of</tt> is only +part of the current Working Draft +(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2857.pdf">N2857</a>) +because it is in TR1. +</p> +<p> +Having both <tt>alignof</tt> and <tt>alignment_of</tt> would cause +unwanted confusion. In general, I think TR1 functionality should not be +brought into C++0x if it is entirely redundant with other C++0x language +or library features. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Remove from Header <type_traits> synopsis 20.6.2 [meta.type.synop]: +</p> +<blockquote><pre><del>template <class T> struct alignment_of;</del> +</pre></blockquote> + +<p> +Remove the first row of Table 34 ("Type property queries"), from +Type properties 20.6.4.3 [meta.unary.prop]: +</p> +<blockquote> +<table border="1"> +<caption>Table 34 -- Type property queries</caption> +<tbody><tr> +<td><del><tt>template <class T> struct alignment_of;</tt></del></td> +<td><del><tt>alignof(T)</tt>.</del><br> +<del><i>Precondition:</i> <tt>T</tt> shall be a complete type, a reference +type, or an array of unknown bound, but shall not be a function type or +(possibly cv-qualified) <tt>void</tt>.</del> +</td> +</tr> +</tbody></table> +</blockquote> + +<p> +Change text in Table 41 ("Other transformations"), from Other +transformations 20.6.7 [meta.trans.other], as follows: +</p> +<blockquote> +<table border="1"> +<caption>Table 41 -- Other transformations</caption> +<tbody><tr><td>...</td> +<td> + Align shall be equal to <tt> + <del>alignment_of<T>::value</del> + <ins>alignof(T)</ins> + </tt> for some type <tt>T</tt> or to <i>default-alignment</i>. +</td> +<td>...</td> +</tr></tbody></table> +</blockquote> + + + + + +<hr> +<h3><a name="1132"></a>1132. JP-30: nested exceptions</h3> +<p><b>Section:</b> 18.8.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> Seiji Hayashida <b>Opened:</b> 2009-06-01 <b>Last modified:</b> 2009-06-02</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#except.nested">active issues</a> in [except.nested].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#except.nested">issues</a> in [except.nested].</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><b>Addresses JP 30</b></p> + +<p> +C++0x <tt>nested_exception</tt> cannot handle a structured exception well. The +following codes show two types of tree structured exception handling. +</p> +<p> +The first one is based on <tt>nested_exception</tt> in C++0x, +while the second one is based on my library <tt>trickerr.h</tt> (in Japanese). +<a href="http://tricklib.com/cxx/dagger/trickerr.h">http://tricklib.com/cxx/dagger/trickerr.h</a> +</p> +<p> +Assume that Function <tt>A()</tt> calls two sub functions <tt>A_a()</tt> and <tt>A_b()</tt>, both might +throw tree structured exceptions, and <tt>A_b()</tt> must be called even if <tt>A_a()</tt> +throws an exception. +</p> +<p> +List A (code of tree structured exception handling based on nested_exception +in C++0x) +</p> + +<blockquote><pre>void A() +{ + try + { + std::vector<exception_ptr> exception_list; + try + { + // A_a() does a similar processing as A(). + A_a(); + } + catch(...) + { + exception_list.push_back(current_exception()); + } + + // ***The processing A() has to do even when A_a() fails. *** + try + { + // A_b() does a similar processing as A(). + A_b(); + } + catch(...) + { + exception_list.push_back(current_exception()); + } + if (!exception_list.empty()) + { + throw exception_list; + } + } + catch(...) + { + throw_with_nested(A_exception("someone error")); + } +} +void print_tree_exception(exception_ptr e, const std::string & indent ="") +{ + const char * indent_unit = " "; + const char * mark = "- "; + try + { + rethow_exception(e); + } + catch(const std::vector<exception_ptr> e) + { + for(std::vector<exception_ptr>::const_iterator i = e.begin(); i!=e.end(); ++i) + { + print_tree_exception(i, indent); + } + } + catch(const std::nested_exception e) + { + print_tree_exception(evil_i(e), indent +indent_unit); + } + catch(const std::exception e) + { + std::cout << indent << mark << e.what() << std::endl; + } + catch(...) + { + std::cout << indent << mark << "unknown exception" << std::endl; + } +} +int main(int, char * []) +{ + try + { + A(); + } + catch() + { + print_tree_exception(current_exception()); + } + return EXIT_SUCCESS; +} +</pre></blockquote> + +<p> +List B ( code of tree structured exception handling based on <tt>trickerr.h</tt>. ) +"trickerr.h" (in Japanese), refer to: +<a href="http://tricklib.com/cxx/dagger/trickerr.h">http://tricklib.com/cxx/dagger/trickerr.h</a>. +</p> + +<blockquote><pre>void A() +{ + tricklib::error_listener_type error_listener; + // A_a() is like A(). A_a() can throw tree structured exception. + A_a(); + + // *** It must do process so that A_a() throws exception in A(). *** + // A_b() is like A(). A_b() can throw tree structured exception. + A_b(); + + if (error_listener.has_error()) // You can write this "if block" in destructor + // of class derived from error_listener_type. + { + throw_error(new A_error("someone error",error_listener.listener_off().extract_pending_error())); + } +} +void print_tree_error(const tricklib::error_type &a_error, const std::string & indent = "") +{ + const char * indent_unit = " "; + const char * mark = "- "; + + tricklib::error_type error = a_error; + while(error) + { + std::cout << indent << mark << error->message << std::endl; + if (error->children) + { + print_tree_error(error->children, indent +indent_unit); + } + error = error->next; + } +} +int main(int, char * []) +{ + tricklib::error_thread_power error_thread_power_on; // This object is necessary per thread. + + try + { + A(); + } + catch(error_type error) + { + print_tree_error(error); + } + catch(...) + { + std::cout << "- unknown exception" << std::endl; + } + return EXIT_SUCCESS; +} +</pre></blockquote> + +<p> +Prospect +</p> +<p> +We will focus on the method A() since the other methods, also main(), occur +only once respectively. +</p> + +<ul> <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. + In the List A above (of the nested exception handling), it is hard to + find out an active reason to use the nested exception handling at this + scene. Rather, we can take a simpler description by throwing the entire + exception_list directly to the top level. </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. + The code in the same example gives us a kind of redundant impression, + which might have come from the fact that the try-throw-catch framework does + not assume a tree structured exception handling. </li> -</ol> +</ul> <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. +According to the above observation, we cannot help concluding that it is not +so easy to use the nested_exception handling as a tree structured exception +handling mechanism in a practical sense. +</p> +<p> +This text is based on the web page below (in Japanese). +<a href="http://d.hatena.ne.jp/wraith13/20081231/1230715424">http://d.hatena.ne.jp/wraith13/20081231/1230715424</a> </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> +</p> + + + + + +<hr> +<h3><a name="1133"></a>1133. Does N2844 break current specification of list::splice?</h3> +<p><b>Section:</b> 23.3.3.5 [forwardlist.ops], 23.3.4.4 [list.ops] <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>Opened:</b> 2009-05-09 <b>Last modified:</b> 2009-06-09</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#forwardlist.ops">active issues</a> in [forwardlist.ops].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forwardlist.ops">issues</a> in [forwardlist.ops].</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> +IIUC, +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2844.html">N2844</a> +means that lvalues will no longer bind to rvalue references. +Therefore, the current specification of <tt>list::splice</tt> (list +operations 23.3.4.4 [list.ops]) will be a breaking change of behaviour for existing +programs. That is because we changed the signature to swallow via an rvalue +reference rather than the lvalue reference used in 03. +</p> +<p> +Retaining this form would be safer, requiring an explicit move when splicing +from lvalues. However, this will break existing programs. +We have the same problem with <tt>forward_list</tt>, although without the risk of +breaking programs so here it might be viewed as a positive feature. +</p> +<p> +The problem signatures: +</p> +<blockquote><pre>void splice_after(const_iterator position, forward_list<T,Alloc>&& x); +void splice_after(const_iterator position, forward_list<T,Alloc>&& x, + const_iterator i); +void splice_after(const_iterator position, forward_list<T,Alloc>&& x, + const_iterator first, const_iterator last); + +void splice(const_iterator position, list<T,Alloc>&& x); +void splice(const_iterator position, list<T,Alloc>&& x, + const_iterator i); +void splice(const_iterator position, list<T,Alloc>&& x, + const_iterator first, const_iterator last); +</pre></blockquote> + +<b>Possible resolutions:</b> + +<p> +Option A. Add an additional (non-const) lvalue-reference +overload in each case +</p> +<p> +Option B. Change rvalue reference back to (non-const) +lvalue-reference overload in each case +</p> +<p> +Option C. Add an additional (non-const) lvalue-reference +overload in just the <tt>std::list</tt> cases +</p> +<p> +I think (B) would be very unfortunate, I really like the <tt>forward_list</tt> +behaviour in (C) but feel (A) is needed for consistency. +</p> +<p> +My actual preference would be NAD, ship with this as a breaking change as it +is a more explicit interface. I don't think that will fly though! +</p> + +<p> +See the thread starting with c++std-lib-23725 for more discussion. +</p> + + +<p><b>Proposed resolution:</b></p> + + + + + +<hr> +<h3><a name="1134"></a>1134. Redundant specification of stdint.h, fenv.h, tgmath.h, and maybe complex.h</h3> +<p><b>Section:</b> 18.4.2 [stdinth], 26.3.2 [fenv], 26.8 [c.math], 26.4.11 [cmplxh] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> + <b>Submitter:</b> Robert Klarer <b>Opened:</b> 2009-05-26 <b>Last modified:</b> 2009-06-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> +This is probably editorial. +</p> +<p> +The following items should be removed from the draft, because they're +redundant with Annex D, and they arguably make some *.h headers +non-deprecated: +</p> +<p> +18.4.2 [stdinth] (regarding <tt><stdint.h></tt>) +</p> +<p> +26.3.2 [fenv] (regarding <tt><fenv.h></tt> +</p> +<p> +Line 3 of 26.8 [c.math] (regarding <tt><tgmath.h></tt>) </p> +<p> +26.4.11 [cmplxh] (regarding <tt><complex.h></tt>, though the note in this subclause is not redundant) +</p> + +<p><i>[ +2009-06-10 Ganesh adds: +]</i></p> + + <blockquote> -<i>Throws:</i> Nothing. +While searching for <tt>stdint</tt> in the CD, I found that <tt><stdint.h></tt> is also +mentioned in 3.9.1 [basic.fundamental] /5. It guess it should refer to +<tt><cstdint></tt> instead. </blockquote> -</li> -<li> + +<p><b>Proposed resolution:</b></p> +<p> +Remove the section 18.4.2 [stdinth]. +</p> <p> -In 21.3.5 [string.access] <em>replace</em> p. 1 by the following <em>4</em> paragraghs: +Remove the section 26.3.2 [fenv]. +</p> +<p> +Remove 26.8 [c.math], p3: </p> <blockquote> +<del>-3- The header <tt><tgmath.h></tt> effectively includes the headers <tt><complex.h></tt> +and <tt><math.h></tt>.</del> +</blockquote> <p> -<i>Requires:</i> <tt>pos ≤ size()</tt>. +Remove the section 26.4.11 [cmplxh]. </p> + + + + + +<hr> +<h3><a name="1135"></a>1135. <tt>exception_ptr</tt> should support contextual conversion to <tt>bool</tt></h3> +<p><b>Section:</b> 18.8.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> Daniel Krügler <b>Opened:</b> 2007-06-06 <b>Last modified:</b> 2009-06-09</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> -<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. +As of +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2857.pdf">N2857</a> +18.8.5 [propagation]/5, the implementation-defined type +<tt>exception_ptr</tt> does provide the following ways to check whether +it is a null value: </p> +<blockquote><pre>void f(std::exception_ptr p) { + p == nullptr; + p == 0; + p == exception_ptr(); +} +</pre></blockquote> <p> -<i>Throws:</i> Nothing. +This is rather cumbersome way of checking for the null value +and I suggest to require support for evaluation in a boolean +context like so: </p> + +<blockquote><pre>void g(std::exception_ptr p) { + if (p) {} + !p; +} +</pre></blockquote> + + +<p><b>Proposed resolution:</b></p> <p> -<i>Complexity:</i> Constant time. +In section 18.8.5 [propagation] insert a new paragraph between p.5 and p.6: </p> + +<blockquote> +<ins> +An object <tt>e</tt> of type <tt>exception_ptr</tt> can be contextually converted to <tt>bool</tt>. +The effect shall be as if <tt>e != exception_ptr()</tt> had been evaluated in place +of <tt>e</tt>. There shall be no implicit conversion to arithmetic type, to +enumeration type or to pointer type. +</ins> </blockquote> -</li> -<li> + + + + +<hr> +<h3><a name="1136"></a>1136. Incomplete specification of <tt>nested_exception::rethrow_nested()</tt></h3> +<p><b>Section:</b> 18.8.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> Daniel Krügler <b>Opened:</b> 2007-06-06 <b>Last modified:</b> 2009-06-09</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#except.nested">active issues</a> in [except.nested].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#except.nested">issues</a> in [except.nested].</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 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: +It was recently mentioned in a newsgroup article +<a href="http://groups.google.de/group/comp.std.c++/msg/f82022aff68edf3d">http://groups.google.de/group/comp.std.c++/msg/f82022aff68edf3d</a> +that the specification of the member function <tt>rethrow_nested()</tt> of the +class <tt>nested_exception</tt> is incomplete, specifically it remains unclear +what happens, if member <tt>nested_ptr()</tt> returns a null value. In +18.8.6 [except.nested] we find only the following paragraph related to that: </p> +<blockquote><pre>void rethrow_nested() const; // [[noreturn]] +</pre> <blockquote> +-4- <i>Throws:</i> the stored exception captured by this <tt>nested_exception</tt> object. +</blockquote> +</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>. +This is a problem, because it is possible to create an object of +<tt>nested_exception</tt> with exactly such a state, e.g. </p> +<blockquote><pre>#include <exception> +#include <iostream> + +int main() try { + std::nested_exception e; // OK, calls current_exception() and stores it's null value + e.rethrow_nested(); // ? + std::cout << "A" << std::endl; +} +catch(...) { + std::cout << "B" << std::endl; +} +</pre></blockquote> <p> -<i>Throws:</i> Nothing. +I suggest to follow the proposal of the reporter, namely to invoke +<tt>terminate()</tt> if <tt>nested_ptr()</tt> return a null value of <tt>exception_ptr</tt> instead +of relying on the fallback position of undefined behavior. This would +be consistent to the behavior of a <tt>throw;</tt> statement when no +exception is being handled. </p> + + +<p><b>Proposed resolution:</b></p> <p> -<i>Complexity:</i> Constant time. +Change around 18.8.6 [except.nested]/4 as indicated: +</p> +<blockquote> +<p> +-4- <i>Throws:</i> the stored exception captured by this <tt>nested_exception</tt> +object<ins>, if <tt>nested_ptr() != nullptr</tt></ins> +</p> +<p> +<ins>- <i>Remarks:</i> If <tt>nested_ptr() == nullptr</tt>, <tt>terminate()</tt> +shall be called.</ins> </p> </blockquote> -</li> -</ol> -</li> -<li> -<ol start="4"> -<li> + + + + + +<hr> +<h3><a name="1137"></a>1137. Return type of <tt>conj</tt> and <tt>proj</tt></h3> +<p><b>Section:</b> 26.4.9 [cmplx.over] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> + <b>Submitter:</b> Marc Steinbach <b>Opened:</b> 2009-06-11 <b>Last modified:</b> 2009-06-14</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#cmplx.over">issues</a> in [cmplx.over].</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 21.3.5 [string.access] <em>replace</em> p.2 and p.3 by: +In clause 1, the Working Draft +(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2857.pdf">N2857</a>) +specifies overloads of the +functions </p> -<blockquote> +<blockquote><pre>arg, conj, imag, norm, proj, real +</pre></blockquote> <p> -<i>Requires:</i> <tt>pos ≤ size()</tt> +for non-complex arithmetic types (<tt>float</tt>, <tt>double</tt>, +<tt>long double</tt>, and integers). +The only requirement (clause 2) specifies type promotion of arguments. </p> <p> -<i>Throws:</i> <tt>out_of_range</tt> if <tt>pos > size()</tt>. +I strongly suggest to add the following requirement on the return types: </p> +<blockquote> +All the specified overloads must return real (i.e., non-complex) values, +specifically, the nested <tt>value_type</tt> of promoted arguments. </blockquote> -</li> -</ol> -</li> -</ol> +<p> +(This has no effect on <tt>arg</tt>, <tt>imag</tt>, <tt>norm</tt>, <tt>real</tt>: +they are real-valued anyway.) +</p> +<p><b>Rationale:</b></p> +<p> +Mathematically, <tt>conj()</tt> and <tt>proj()</tt>, like the transcendental functions, are +complex-valued in general but map the (extended) real line to itself. +In fact, both functions act as identity on the reals. +A typical user will expect <tt>conj()</tt> and <tt>proj()</tt> to preserve this essential +mathematical property in the same way as <tt>exp()</tt>, <tt>sin()</tt>, etc. +A typical use of <tt>conj()</tt>, e.g., is the generic scalar product of n-vectors: +</p> + +<blockquote><pre>template<typename T> +inline T +scalar_product(size_t n, T const* x, T const* y) { + T result = 0; + for (size_t i = 0; i < n; ++i) + result += std::conj(x[i]) * y[i]; + return result; +} +</pre></blockquote> +<p> +This will work equally well for real and complex floating-point types <tt>T</tt> if +<tt>conj()</tt> returns <tt>T</tt>. It will not work with real types if <tt>conj()</tt> +returns complex values. +</p> +<p> +Instead, the implementation of <tt>scalar_product</tt> becomes either less efficient +and less useful (if a complex result is always returned), or unnecessarily +complicated (if overloaded versions with proper return types are defined). +In the second case, <tt>conj()</tt> is not used with real arguments. +</p> +<p> +Any use of <tt>conj()</tt> I can think of would benefit from the proposed return type +requirement, in a similar way. +It will not harm use cases where a complex value is expected, because of +implicit conversion to complex. +Without the proposed return type guarantee, I find an overloaded <tt>conj()</tt> not +only useless but actually troublesome. +</p> +<p> +I believe that the same applies to <tt>proj()</tt>, althought up to now I had no need +for it. +</p> + + + +<p><b>Proposed resolution:</b></p> +<p> +Insert a new paragraph after 26.4.9 [cmplx.over]/2: +</p> + +<blockquote> +<ins> +All of the specified overloads shall have a return type which is the nested <tt>value_type</tt> of +the promoted arguments. +</ins> +</blockquote> <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> +<h3><a name="1138"></a>1138. unusal return value for operator+</h3> +<p><b>Section:</b> 21.4.8.1 [string::op+] <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>Opened:</b> 2009-06-12 <b>Last modified:</b> 2009-06-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> +<p> +Many of the <tt>basic_string operator+</tt> overloads return an rvalue-reference. Is +that really intended? +</p> +<p> +I'm considering it might be a mild performance tweak to avoid making +un-necessary copies of a cheaply movable type, but it opens risk to dangling +references in code like: +</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. +<blockquote><pre>auto && s = string{"x"} + string{y}; +</pre></blockquote> - </p> - <p> +<p> +and I'm not sure about: +</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. +<blockquote><pre>auto s = string{"x"} + string{y}; +</pre></blockquote> - </p> - <p> -There are also 203 occurrences of "<i>Throws:</i> Nothing." scattered -throughout the spec. +<p><b>Proposed resolution:</b></p> +<p> +Strike the <tt>&&</tt> from the return type in the following function +signatures: +</p> - </p> - <p> +<blockquote> +<p> +21.3 [string.classes] p2 Header Synopsis +</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. +<blockquote><pre>template<class charT, class traits, class Allocator> + basic_string<charT,traits,Allocator><del>&&</del> + operator+(basic_string<charT,traits,Allocator>&& lhs, + const basic_string<charT,traits,Allocator>& rhs); - </p> - <p> +template<class charT, class traits, class Allocator> + basic_string<charT,traits,Allocator><del>&&</del> + operator+(const basic_string<charT,traits,Allocator>& lhs, + basic_string<charT,traits,Allocator>&& rhs); -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. +template<class charT, class traits, class Allocator> + basic_string<charT,traits,Allocator><del>&&</del> + operator+(basic_string<charT,traits,Allocator>&& lhs, + basic_string<charT,traits,Allocator>&& rhs); - </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>: +template<class charT, class traits, class Allocator> + basic_string<charT,traits,Allocator><del>&&</del> + operator+(const charT* lhs, + basic_string<charT,traits,Allocator>&& rhs); - </p> - <blockquote> - <pre>template <class InputIterator, class ForwardIterator> -ForwardIterator -uninitialized_copy (InputIterator first, InputIterator last, ForwardIterator res) -{ - typedef iterator_traits<ForwardIterator>::value_type ValueType; +template<class charT, class traits, class Allocator> + basic_string<charT,traits,Allocator><del>&&</del> + operator+(charT lhs, basic_string<charT,traits,Allocator>&& rhs); - ForwardIterator start = res; +template<class charT, class traits, class Allocator> + basic_string<charT,traits,Allocator><del>&&</del> + operator+(basic_string<charT,traits,Allocator>&& lhs, + const charT* rhs); - try { - for (; first != last; ++first, ++res) - ::new (&*res) ValueType (*first); - } - catch (...) { - for (; start != res; --start) - (&*start)->~ValueType (); - throw; - } - return res; -} +template<class charT, class traits, class Allocator> + basic_string<charT,traits,Allocator><del>&&</del> + operator+(basic_string<charT,traits,Allocator>&& lhs, charT rhs); +</pre></blockquote> -struct SomeType { - SomeType (const SomeType&) <ins>throw ()</ins>; -}</pre> - </blockquote> - <p> +<p> +21.4.8.1 [string::op+] +</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): +<blockquote><pre>template<class charT, class traits, class Allocator> + basic_string<charT,traits,Allocator><del>&&</del> + operator+(basic_string<charT,traits,Allocator>&& lhs, + const basic_string<charT,traits,Allocator>& rhs); - </p> - <blockquote> - <pre>template <> SomeType* -uninitialized_copy (const SomeType *first, const SomeType *last, SomeType *res) -{ - for (; first != last; ++first, ++res) - ::new (res) SomeType (*first); +template<class charT, class traits, class Allocator> + basic_string<charT,traits,Allocator><del>&&</del> + operator+(const basic_string<charT,traits,Allocator>& lhs, + basic_string<charT,traits,Allocator>&& rhs); - return res; -}</pre> - </blockquote> - <p> +template<class charT, class traits, class Allocator> + basic_string<charT,traits,Allocator><del>&&</del> + operator+(basic_string<charT,traits,Allocator>&& lhs, + basic_string<charT,traits,Allocator>&& rhs); -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> +template<class charT, class traits, class Allocator> + basic_string<charT,traits,Allocator><del>&&</del> + operator+(const charT* lhs, + basic_string<charT,traits,Allocator>&& rhs); -For example, given the following definitions of -class <tt>MayThrow</tt> and <tt>WontThrow</tt> and the two -statements below: +template<class charT, class traits, class Allocator> + basic_string<charT,traits,Allocator><del>&&</del> + operator+(charT lhs, basic_string<charT,traits,Allocator>&& rhs); - </p> - <blockquote> - <pre>struct MayThrow { - MayThrow (); -}; +template<class charT, class traits, class Allocator> + basic_string<charT,traits,Allocator><del>&&</del> + operator+(basic_string<charT,traits,Allocator>&& lhs, + const charT* rhs); -struct WontThrow { - WontThrow () <ins>throw ()</ins>; -}; +template<class charT, class traits, class Allocator> + basic_string<charT,traits,Allocator><del>&&</del> + operator+(basic_string<charT,traits,Allocator>&& lhs, charT rhs); +</pre></blockquote> -MayThrow *a = new MayThrow [N]; -WontThrow *b = new WontThrow [N];</pre> +</blockquote> - </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. +<hr> +<h3><a name="1139"></a>1139. Response to US 93</h3> +<p><b>Section:</b> 30 [thread] <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>Opened:</b> 2009-06-15 <b>Last modified:</b> 2009-06-15</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread">active issues</a> in [thread].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread">issues</a> in [thread].</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> - <p> +<p><b>Addresses US 93, JP 79, UK 333, JP 81</b></p> -<b>Counterarguments:</b> +<p> +The thread chapter is not concept enabled. +</p> - </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> +<p><b>Proposed resolution:</b></p> -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. +<hr> +<h3><a name="1140"></a>1140. Response to US 84</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> Beman Dawes <b>Opened:</b> 2009-06-15 <b>Last modified:</b> 2009-06-15</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#numerics">active issues</a> in [numerics].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#numerics">issues</a> in [numerics].</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> - </li> - </ol> - - <p> +<p><b>Addresses US 84</b></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> +The numerics chapter is not concept enabled. +</p> - </p> - <p> +<p> +The portion of this comment dealing with random numbers was resolved by +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2836.pdf">N2836</a>, +which was accepted in Summit. +</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><b>Proposed resolution:</b></p> - </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> +<hr> +<h3><a name="1141"></a>1141. Response to US 85</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#New">New</a> + <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2009-06-15 <b>Last modified:</b> 2009-06-15</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#input.output">active issues</a> in [input.output].</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#New">New</a> status.</p> +<p><b>Discussion:</b></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><b>Addresses US 85, JP 67, JP 68, JP 69, JP 72</b></p> - </p> - <p> +<p> +The input/output chapter is not concept enabled. +</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><b>Proposed resolution:</b></p> + - </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> +<h3><a name="1142"></a>1142. Response to US 86</h3> +<p><b>Section:</b> 28 [re] <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>Opened:</b> 2009-06-15 <b>Last modified:</b> 2009-06-15</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#re">active issues</a> in [re].</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#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><b>Addresses US 86, UK 309, UK 310</b></p> - </p> - <blockquote> +<p> +The regular expressions chapter is not concept enabled. +</p> -<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><b>Proposed resolution:</b></p> - </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> +<hr> +<h3><a name="1143"></a>1143. Response to US 87</h3> +<p><b>Section:</b> 29 [atomics] <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>Opened:</b> 2009-06-15 <b>Last modified:</b> 2009-06-15</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#atomics">active issues</a> in [atomics].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics">issues</a> in [atomics].</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> -Change the <i>Requires</i> clause as follows: +<p><b>Addresses US 87, UK 311</b></p> - </p> - <blockquote> +<p> +The atomics chapter is not concept enabled. +</p> + +<p> +Needs to also consider issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#923">923</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#924">924</a>. +</p> + + + +<p><b>Proposed resolution:</b></p> -<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> - diff --git a/libstdc++-v3/doc/html/ext/lwg-closed.html b/libstdc++-v3/doc/html/ext/lwg-closed.html index a056c3e..2f26c18 100644 --- a/libstdc++-v3/doc/html/ext/lwg-closed.html +++ b/libstdc++-v3/doc/html/ext/lwg-closed.html @@ -14,11 +14,11 @@ del {background-color:#FFA0A0} <table> <tbody><tr> <td align="left">Doc. no.</td> -<td align="left">N2729=08-0239</td> +<td align="left">N2896=09-0086</td> </tr> <tr> <td align="left">Date:</td> -<td align="left">2008-08-24</td> +<td align="left">2009-06-21</td> </tr> <tr> <td align="left">Project:</td> @@ -29,9 +29,9 @@ del {background-color:#FFA0A0} <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> +<h1>C++ Standard Library Closed Issues List (Revision R65)</h1> - <p>Reference ISO/IEC IS 14882:1998(E)</p> + <p>Reference ISO/IEC IS 14882:2003(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> @@ -51,6 +51,148 @@ del {background-color:#FFA0A0} <h2>Revision History</h2> <ul> +<li>R65: +2009-06-19 pre-Frankfurt mailing. +<ul> +<li><b>Summary:</b><ul> +<li>378 open issues, up by 32.</li> +<li>765 closed issues, up by 0.</li> +<li>1143 issues total, up by 32.</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#1115">1115</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1116">1116</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1117">1117</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1118">1118</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1119">1119</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1120">1120</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1121">1121</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1122">1122</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1123">1123</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1124">1124</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1125">1125</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1126">1126</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1127">1127</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1128">1128</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1129">1129</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1130">1130</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1131">1131</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1132">1132</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1133">1133</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1134">1134</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1135">1135</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1136">1136</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1137">1137</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1138">1138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1139">1139</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1140">1140</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1141">1141</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1142">1142</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1143">1143</a>.</li> +<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1112">1112</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1113">1113</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1114">1114</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#937">937</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#696">696</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-active.html#727">727</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#900">900</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#911">911</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#916">916</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#917">917</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#920">920</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#933">933</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#935">935</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#941">941</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#947">947</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#951">951</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#953">953</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#954">954</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#955">955</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#956">956</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#977">977</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#978">978</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#985">985</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#989">989</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#996">996</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1033">1033</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1054">1054</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1056">1056</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1057">1057</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1059">1059</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1062">1062</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1068">1068</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1069">1069</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1071">1071</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1072">1072</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1076">1076</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1090">1090</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1092">1092</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1096">1096</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1098">1098</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1099">1099</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1105">1105</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1106">1106</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1108">1108</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1110">1110</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#817">817</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#971">971</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#992">992</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1004">1004</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1010">1010</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1012">1012</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1015">1015</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1019">1019</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#780">780</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#897">897</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#919">919</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#939">939</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#957">957</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#983">983</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1001">1001</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1080">1080</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1091">1091</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1093">1093</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1094">1094</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1095">1095</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1097">1097</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1102">1102</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1104">1104</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1111">1111</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#921">921</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#987">987</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1087">1087</a>.</li> +<li>Changed the following issues from New to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#568">568</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-active.html#785">785</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#903">903</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#912">912</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#918">918</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#946">946</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#995">995</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1074">1074</a>.</li> +<li>Changed the following issues from Open to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#458">458</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#644">644</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#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>.</li> +<li>Changed the following issues from Review to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#901">901</a>.</li> +<li>Changed the following issues from Tentatively Ready to Tentatively NAD: <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#988">988</a>.</li> +<li>Changed the following issues from New to Tentatively NAD Editorial: <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#862">862</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#927">927</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#945">945</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#952">952</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#969">969</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#972">972</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#973">973</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#979">979</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1058">1058</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1060">1060</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1061">1061</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1077">1077</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1101">1101</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1109">1109</a>.</li> +<li>Changed the following issues from Open to Tentatively NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#424">424</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#884">884</a>.</li> +<li>Changed the following issues from Review to Tentatively NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1023">1023</a>.</li> +<li>Changed the following issues from Open to Tentatively NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#96">96</a>.</li> +<li>Changed the following issues from New to Tentatively Ready: <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#898">898</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#906">906</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#910">910</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#913">913</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#914">914</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#915">915</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#925">925</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#974">974</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#976">976</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#981">981</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#982">982</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#984">984</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#990">990</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#998">998</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#999">999</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1063">1063</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1067">1067</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1070">1070</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1073">1073</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1100">1100</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1103">1103</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1107">1107</a>.</li> +<li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#814">814</a>.</li> +<li>Changed the following issues from Review to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#899">899</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#907">907</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#909">909</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#934">934</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#938">938</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#940">940</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#943">943</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#950">950</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#965">965</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#970">970</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#975">975</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#986">986</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#991">991</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#993">993</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#994">994</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#997">997</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1002">1002</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1006">1006</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1011">1011</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1013">1013</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1014">1014</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1021">1021</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1024">1024</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1037">1037</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1038">1038</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1039">1039</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1040">1040</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1044">1044</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1045">1045</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1065">1065</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1066">1066</a>.</li> +</ul></li> +</ul> +</li> +<li>R64: +2009-05-01 mid-term mailing. +<ul> +<li><b>Summary:</b><ul> +<li>346 open issues, up by 19.</li> +<li>765 closed issues, up by 0.</li> +<li>1111 issues total, up by 19.</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#1093">1093</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1094">1094</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1095">1095</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1096">1096</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1097">1097</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1098">1098</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1099">1099</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1100">1100</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1101">1101</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1102">1102</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1103">1103</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1104">1104</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1105">1105</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1106">1106</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1107">1107</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1108">1108</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1109">1109</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1110">1110</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1111">1111</a>.</li> +<li>Changed the following issues from DR to CD1: <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-defects.html#386">386</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#406">406</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#409">409</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#413">413</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#434">434</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#438">438</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#444">444</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#445">445</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#455">455</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#457">457</a>, <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-defects.html#469">469</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#533">533</a>.</li> +<li>Changed the following issues from Review to New: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1070">1070</a>.</li> +</ul></li> +</ul> +</li> +<li>R63: +2009-03-20 post-Summit mailing. +<ul> +<li><b>Summary:</b><ul> +<li>327 open issues, up by 96.</li> +<li>765 closed issues, up by 14.</li> +<li>1092 issues total, up by 110.</li> +</ul></li> +<li><b>Details:</b><ul> +<li>Added the following NAD Editorial issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1022">1022</a>.</li> +<li>Added the following NAD Future issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1025">1025</a>.</li> +<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#983">983</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#984">984</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#985">985</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#989">989</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#990">990</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#995">995</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#996">996</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#998">998</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#999">999</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1001">1001</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1033">1033</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1054">1054</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1056">1056</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1057">1057</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1058">1058</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1059">1059</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1060">1060</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1061">1061</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1062">1062</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1063">1063</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1067">1067</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1068">1068</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1069">1069</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1071">1071</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1072">1072</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1073">1073</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1074">1074</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1076">1076</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1077">1077</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1080">1080</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1090">1090</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1091">1091</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1092">1092</a>.</li> +<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#987">987</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1000">1000</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1007">1007</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1008">1008</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1016">1016</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1017">1017</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1018">1018</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1020">1020</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1026">1026</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1027">1027</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1028">1028</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1029">1029</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1030">1030</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1031">1031</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1032">1032</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1034">1034</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1035">1035</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1036">1036</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1041">1041</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1042">1042</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1046">1046</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1048">1048</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1051">1051</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1052">1052</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1053">1053</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1055">1055</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1064">1064</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1075">1075</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1078">1078</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1079">1079</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1081">1081</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1082">1082</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1083">1083</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1084">1084</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1085">1085</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1086">1086</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1087">1087</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1088">1088</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1089">1089</a>.</li> +<li>Added the following Review issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#986">986</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#991">991</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#992">992</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#993">993</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#994">994</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#997">997</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1002">1002</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1003">1003</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1004">1004</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1005">1005</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1006">1006</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1009">1009</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1010">1010</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1011">1011</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1012">1012</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1013">1013</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1014">1014</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1015">1015</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1019">1019</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1021">1021</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1023">1023</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1024">1024</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1037">1037</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1038">1038</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1039">1039</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1040">1040</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1043">1043</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1044">1044</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1045">1045</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1047">1047</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1049">1049</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1050">1050</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1065">1065</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1066">1066</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1070">1070</a>.</li> +<li>Added the following Tentatively Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#988">988</a>.</li> +<li>Changed the following issues from New to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#905">905</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#942">942</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#980">980</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#874">874</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#875">875</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#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#793">793</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#794">794</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#800">800</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#683">683</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#892">892</a>.</li> +<li>Changed the following issues from Ready to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#803">803</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#466">466</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#111">111</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#149">149</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#219">219</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#880">880</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#891">891</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#893">893</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#902">902</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#908">908</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#921">921</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#923">923</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#924">924</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#926">926</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#930">930</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#936">936</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#944">944</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#958">958</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#959">959</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#960">960</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#961">961</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#962">962</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#963">963</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#964">964</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#966">966</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#967">967</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#968">968</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#788">788</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#937">937</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#879">879</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#899">899</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#901">901</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#907">907</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#909">909</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#929">929</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#934">934</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#938">938</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#940">940</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#943">943</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#950">950</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#965">965</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#970">970</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#971">971</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#975">975</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#817">817</a>.</li> +<li>Changed the following issues from New to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#904">904</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#922">922</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#928">928</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#931">931</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#932">932</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#948">948</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#949">949</a>.</li> +<li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#890">890</a>.</li> +<li>Changed the following issues from Review to Tentatively Ready: <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-active.html#822">822</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#869">869</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#878">878</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#888">888</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#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#821">821</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#866">866</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#894">894</a>.</li> +</ul></li> +</ul> +</li> +<li>R62: +2009-02-06 pre-Summit mailing. +<ul> +<li><b>Summary:</b><ul> +<li>231 open issues, up by 44.</li> +<li>751 closed issues, up by 0.</li> +<li>982 issues total, up by 44.</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#939">939</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#940">940</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#941">941</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#942">942</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#943">943</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#944">944</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#945">945</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#946">946</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#947">947</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#948">948</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#949">949</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#950">950</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#951">951</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#952">952</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#953">953</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#954">954</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#955">955</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#956">956</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#957">957</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#958">958</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#959">959</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#960">960</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#961">961</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#962">962</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#963">963</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#964">964</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#965">965</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#966">966</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#967">967</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#968">968</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#969">969</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#970">970</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#971">971</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#972">972</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#973">973</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#974">974</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#975">975</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#976">976</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#977">977</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#978">978</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#979">979</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#980">980</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#981">981</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#982">982</a>.</li> +</ul></li> +</ul> +</li> +<li>R61: +2008-12-05 mid-term mailing. +<ul> +<li><b>Summary:</b><ul> +<li>187 open issues, up by 20.</li> +<li>751 closed issues, up by 0.</li> +<li>938 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-active.html#919">919</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#920">920</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#921">921</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#922">922</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#923">923</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#924">924</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#925">925</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#926">926</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#927">927</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#928">928</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#929">929</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#930">930</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#931">931</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#932">932</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#933">933</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#934">934</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#935">935</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#936">936</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#937">937</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#938">938</a>.</li> +</ul></li> +</ul> +</li> +<li>R60: +2008-10-03 post-San Francisco mailing. +<ul> +<li><b>Summary:</b><ul> +<li>167 open issues, down by 25.</li> +<li>751 closed issues, up by 65.</li> +<li>918 issues total, up by 40.</li> +</ul></li> +<li><b>Details:</b><ul> +<li>Added the following CD1 issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#882">882</a>.</li> +<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#879">879</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#880">880</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#891">891</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#893">893</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#897">897</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#898">898</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#899">899</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#900">900</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#901">901</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#902">902</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#903">903</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#904">904</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#905">905</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#906">906</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#907">907</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#908">908</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#909">909</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#910">910</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#911">911</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#912">912</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#913">913</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#914">914</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#915">915</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#916">916</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#917">917</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#918">918</a>.</li> +<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#881">881</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#883">883</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#884">884</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#885">885</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#886">886</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#887">887</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#889">889</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#890">890</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#895">895</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#896">896</a>.</li> +<li>Added the following Pending NAD Editorial issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#892">892</a>.</li> +<li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#894">894</a>.</li> +<li>Added the following Review issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#888">888</a>.</li> +<li>Changed the following issues from New to CD1: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#818">818</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#820">820</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#843">843</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#845">845</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#846">846</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#856">856</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#858">858</a>.</li> +<li>Changed the following issues from Ready to CD1: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#396">396</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#714">714</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#762">762</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#769">769</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#772">772</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#776">776</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#779">779</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#787">787</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#805">805</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#806">806</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#807">807</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#808">808</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#809">809</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#813">813</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#824">824</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#829">829</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#842">842</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#844">844</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#848">848</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#850">850</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#852">852</a>.</li> +<li>Changed the following issues from Review to CD1: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#23">23</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#698">698</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#709">709</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#804">804</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#823">823</a>.</li> +<li>Changed the following issues from WP to CD1: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#44">44</a>, <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#92">92</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#98">98</a>, <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#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#118">118</a>, <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#123">123</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#167">167</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#179">179</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#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#187">187</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#198">198</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#200">200</a>, <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#202">202</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#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#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#228">228</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#230">230</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#231">231</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#233">233</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#235">235</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#238">238</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#239">239</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#240">240</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#243">243</a>, <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#248">248</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#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#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-defects.html#256">256</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-defects.html#259">259</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#264">264</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#266">266</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#268">268</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#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#274">274</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#276">276</a>, <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#280">280</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#282">282</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#283">283</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#291">291</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#294">294</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#300">300</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#305">305</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#310">310</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#311">311</a>, <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#315">315</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#316">316</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#317">317</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#318">318</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#319">319</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#320">320</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#321">321</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#322">322</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#324">324</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#325">325</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#327">327</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#328">328</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#329">329</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#331">331</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#333">333</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#334">334</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#335">335</a>, <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-defects.html#337">337</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#338">338</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#339">339</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#340">340</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#341">341</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#345">345</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#346">346</a>, <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-defects.html#349">349</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#352">352</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#354">354</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#355">355</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#358">358</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#359">359</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#360">360</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#363">363</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#364">364</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#365">365</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#370">370</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#373">373</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#375">375</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#379">379</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#380">380</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#381">381</a>, <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#384">384</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#391">391</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#395">395</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#400">400</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#402">402</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#403">403</a>, <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-defects.html#405">405</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#407">407</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#410">410</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#411">411</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#412">412</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#414">414</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#415">415</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#420">420</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#425">425</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#426">426</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#428">428</a>, <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-defects.html#435">435</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#436">436</a>, <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#442">442</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#443">443</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#448">448</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#449">449</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#453">453</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#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#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#488">488</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#496">496</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#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#519">519</a>, <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#524">524</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</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#534">534</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>, <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#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-defects.html#550">550</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#552">552</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#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#566">566</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#574">574</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#577">577</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#581">581</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#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#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#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#612">612</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#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#619">619</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#628">628</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#638">638</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>, <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#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#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-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#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-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-defects.html#685">685</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#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-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>, <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#712">712</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> +<li>Changed the following issues from Open to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#670">670</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#849">849</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#855">855</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#871">871</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#454">454</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#832">832</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#811">811</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#812">812</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#841">841</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#864">864</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#870">870</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#872">872</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#299">299</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#484">484</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#556">556</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#676">676</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#724">724</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#742">742</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#532">532</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-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>.</li> +<li>Changed the following issues from New to Open: <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-active.html#751">751</a>, <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#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#819">819</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#836">836</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#838">838</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#857">857</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>, <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#873">873</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>.</li> +<li>Changed the following issues from Pending NAD Editorial to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#424">424</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#625">625</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#851">851</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#788">788</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#821">821</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#866">866</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#753">753</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#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#803">803</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#765">765</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#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#869">869</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#878">878</a>.</li> +<li>Changed the following issues from TC to TC1: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1">1</a>, <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#5">5</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#7">7</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#11">11</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#13">13</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#14">14</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#15">15</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#16">16</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#17">17</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#18">18</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#20">20</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#21">21</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#22">22</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#24">24</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#25">25</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#27">27</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#28">28</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#29">29</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#30">30</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#32">32</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#33">33</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#34">34</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#35">35</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#36">36</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#37">37</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#38">38</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#39">39</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#40">40</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#41">41</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#42">42</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#46">46</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#47">47</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#48">48</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#50">50</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#51">51</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#52">52</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#53">53</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#54">54</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#55">55</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#56">56</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#57">57</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#59">59</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</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#62">62</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#64">64</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#66">66</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#68">68</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#69">69</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#70">70</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#71">71</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#74">74</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#75">75</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#78">78</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#79">79</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#80">80</a>, <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#90">90</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#106">106</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#110">110</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#119">119</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#124">124</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#125">125</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#126">126</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#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-defects.html#137">137</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#139">139</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#141">141</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#148">148</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#150">150</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#151">151</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#152">152</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#154">154</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#155">155</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#156">156</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#158">158</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#160">160</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#161">161</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#168">168</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#169">169</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#172">172</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#173">173</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#174">174</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#175">175</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#176">176</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#189">189</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#193">193</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</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>.</li> +</ul></li> +</ul> +</li> <li>R59: 2008-08-22 pre-San Francisco mailing. <ul> @@ -60,7 +202,7 @@ del {background-color:#FFA0A0} <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> +<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#870">870</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#871">871</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.html#874">874</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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> @@ -73,11 +215,11 @@ del {background-color:#FFA0A0} <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>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-closed.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-defects.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> +<li>Changed the following issues from WP to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.html#709">709</a>.</li> </ul></li> </ul> </li> @@ -91,24 +233,24 @@ del {background-color:#FFA0A0} </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 New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#841">841</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#843">843</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#845">845</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-closed.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-closed.html#855">855</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.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 Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#842">842</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#844">844</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#848">848</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#850">850</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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 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-closed.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> +<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#714">714</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#769">769</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#772">772</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#779">779</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#787">787</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#805">805</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#806">806</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#807">807</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#808">808</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#809">809</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#813">813</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#824">824</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#396">396</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#698">698</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#804">804</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-closed.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-defects.html#23">23</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-defects.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-defects.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-defects.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> @@ -121,7 +263,7 @@ del {background-color:#FFA0A0} <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>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-defects.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-defects.html#820">820</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.html#823">823</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.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-closed.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> @@ -137,8 +279,8 @@ del {background-color:#FFA0A0} <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 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-closed.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-defects.html#804">804</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#805">805</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#806">806</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#807">807</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#808">808</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-closed.html#811">811</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#812">812</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#813">813</a>.</li> +<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#793">793</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.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> @@ -147,15 +289,15 @@ del {background-color:#FFA0A0} <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 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-defects.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-defects.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#724">724</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-defects.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-defects.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-defects.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-defects.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-active.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-active.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-defects.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-defects.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-defects.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 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-defects.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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> @@ -171,7 +313,7 @@ del {background-color:#FFA0A0} <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>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-defects.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-defects.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.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-defects.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-defects.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> @@ -189,7 +331,7 @@ del {background-color:#FFA0A0} <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>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-defects.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-defects.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> @@ -204,16 +346,16 @@ del {background-color:#FFA0A0} <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>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-defects.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-closed.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-defects.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-closed.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-defects.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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 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-defects.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-closed.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-closed.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 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-defects.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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 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-defects.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> @@ -229,7 +371,7 @@ del {background-color:#FFA0A0} <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> +<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.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> @@ -242,13 +384,13 @@ del {background-color:#FFA0A0} <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>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-defects.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-closed.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 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-closed.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> @@ -269,7 +411,7 @@ del {background-color:#FFA0A0} <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 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-defects.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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> @@ -286,12 +428,12 @@ del {background-color:#FFA0A0} <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>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-closed.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-defects.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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 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-active.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 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-active.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-active.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-active.html#149">149</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-active.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> @@ -313,11 +455,11 @@ del {background-color:#FFA0A0} <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>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-defects.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-closed.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-active.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 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-active.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> @@ -331,7 +473,7 @@ del {background-color:#FFA0A0} <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> +<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#611">611</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#613">613</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#614">614</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-active.html#617">617</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#619">619</a>.</li> </ul></li> </ul> </li> @@ -347,10 +489,10 @@ del {background-color:#FFA0A0} <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#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-closed.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> +<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-closed.html#594">594</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-active.html#597">597</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#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#604">604</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#605">605</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#606">606</a>, <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#609">609</a>.</li> </ul></li> </ul> </li> @@ -363,7 +505,7 @@ del {background-color:#FFA0A0} <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> +<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#584">584</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-defects.html#586">586</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#587">587</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-defects.html#589">589</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-closed.html#591">591</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#592">592</a>.</li> </ul></li> </ul> </li> @@ -376,7 +518,7 @@ del {background-color:#FFA0A0} <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>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-defects.html#576">576</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#578">578</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-active.html#580">580</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-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> @@ -391,9 +533,9 @@ del {background-color:#FFA0A0} <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>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-active.html#568">568</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#569">569</a>, <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-closed.html#571">571</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#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#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-defects.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#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#528">528</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> @@ -409,7 +551,7 @@ del {background-color:#FFA0A0} <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>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#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-active.html#539">539</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>, <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#543">543</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-defects.html#545">545</a>, <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-closed.html#547">547</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#548">548</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#550">550</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#552">552</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#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#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-closed.html#558">558</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-closed.html#560">560</a>, <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-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-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> @@ -424,7 +566,7 @@ del {background-color:#FFA0A0} <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> +<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#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-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#533">533</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#535">535</a>.</li> </ul></li> </ul> </li> @@ -440,7 +582,7 @@ Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.htm </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>. +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-defects.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: @@ -449,7 +591,7 @@ Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active </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 +for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#454">454</a> were moved to "DR" status, and all issues previously in "DR" status were moved to "WP". </li> <li>R35: @@ -497,7 +639,7 @@ Pre-Oxford mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22 <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 +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-defects.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> @@ -556,7 +698,7 @@ Changed status of issues 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-active.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. @@ -582,7 +724,7 @@ issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#265 <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 +<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-defects.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 @@ -635,7 +777,7 @@ in Dublin. (99-0016/N1193, 21 Apr 99) 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) +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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>, @@ -648,7 +790,7 @@ 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 +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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: @@ -669,7 +811,7 @@ format, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64 <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> + <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1997-12-04 <b>Last modified:</b> 2006-12-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>Paragraph 1 in "Effects", says "Calls @@ -680,7 +822,7 @@ exists.)</p> <p><b>Proposed resolution:</b></p> -<p>Change 20.5.4.3 [meta.unary.prop] paragraph 1 Effects from +<p>Change 20.6.4.3 [meta.unary.prop] paragraph 1 Effects from "Calls p->release()" to "Calls p.release()".</p> @@ -694,15 +836,15 @@ exists.)</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>Section:</b> 21.4 [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>Opened:</b> 1997-11-16 <b>Last modified:</b> 2006-12-27</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 +reference to 23.2 [container.requirements]. This should probably also have been done for strings. </p> @@ -719,8 +861,8 @@ 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>Section:</b> 27.5.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>Opened:</b> 1997-12-15 <b>Last modified:</b> 2006-12-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> @@ -745,8 +887,8 @@ 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>Section:</b> 22.4.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>Opened:</b> 1998-01-14 <b>Last modified:</b> 2006-12-30</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> @@ -769,8 +911,8 @@ intended here. </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>Section:</b> X [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>Opened:</b> 1998-02-23 <b>Last modified:</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#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> @@ -787,7 +929,7 @@ 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> +clear. See 23.2 [container.requirements], paragraph 8.</p> @@ -795,8 +937,8 @@ 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>Section:</b> 22.4.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>Opened:</b> 1998-06-01 <b>Last modified:</b> 2006-12-30</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> @@ -812,14 +954,14 @@ clear. See 23.1 [container.requirements], paragraph 8.</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>Section:</b> 27.8.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>Opened:</b> 1998-05-27 <b>Last modified:</b> 2006-12-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 +<p>"We are not sure how to interpret the CD2 (see 27.3 +[iostream.forward], 27.8.3.1 [ostringstream.cons], 27.8.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 @@ -847,8 +989,8 @@ 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>Section:</b> 27.7.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>Opened:</b> 1998-07-01 <b>Last modified:</b> 2006-12-27</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> @@ -873,7 +1015,7 @@ 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> + <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-08-18 <b>Last modified:</b> 2006-12-27</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> @@ -898,8 +1040,8 @@ 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>Section:</b> 21.4.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>Opened:</b> 1998-07-09 <b>Last modified:</b> 2006-12-30</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> @@ -937,13 +1079,14 @@ parameters whatsoever.</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>Section:</b> 22.4.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>Opened:</b> 1998-08-24 <b>Last modified:</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#locale.codecvt">active issues</a> in [locale.codecvt].</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 +<p>In 22.4.1.4 [locale.codecvt] par 3, and in 22.4.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> @@ -957,8 +1100,8 @@ contexts above.</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>Section:</b> 27.9.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>Opened:</b> 1998-08-27 <b>Last modified:</b> 2006-12-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> @@ -977,8 +1120,8 @@ 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>Section:</b> 26.6.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>Opened:</b> 1998-09-09 <b>Last modified:</b> 2007-10-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#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> @@ -1005,7 +1148,7 @@ One can't copy even from a const valarray eg:<br> 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 +26.6.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> @@ -1016,8 +1159,8 @@ 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>Section:</b> 26.6.5 [template.slice.array], 26.6.7 [template.gslice.array], 26.6.8 [template.mask.array], 26.6.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>Opened:</b> 1998-09-29 <b>Last modified:</b> 2006-12-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> @@ -1043,8 +1186,9 @@ otherwise possible. </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>Section:</b> 23.2.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>Opened:</b> 1998-09-29 <b>Last modified:</b> 2007-01-15</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</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> @@ -1070,8 +1214,8 @@ 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>Section:</b> 21.4.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>Opened:</b> 1998-09-29 <b>Last modified:</b> 2006-12-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>If I try</p> @@ -1103,7 +1247,7 @@ 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> + <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29 <b>Last modified:</b> 2006-12-27</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> @@ -1113,7 +1257,7 @@ traits::char_type?</p> <p><b>Rationale:</b></p> -<p>There is already wording in 21.1 [char.traits] paragraph 3 that +<p>There is already wording in 21.2 [char.traits] paragraph 3 that requires them to be the same.</p> @@ -1121,8 +1265,8 @@ 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>Section:</b> 21.4.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>Opened:</b> 1998-09-29 <b>Last modified:</b> 2006-12-30</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> @@ -1146,8 +1290,8 @@ exception) </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>Section:</b> 21.4.6.4 [string::insert], 21.4.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>Opened:</b> 1998-09-29 <b>Last modified:</b> 2006-12-27</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> @@ -1171,8 +1315,8 @@ 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>Section:</b> 21.4.6.4 [string::insert], 21.4.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>Opened:</b> 1998-09-29 <b>Last modified:</b> 2006-12-30</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> @@ -1193,8 +1337,8 @@ of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#8 <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>Section:</b> 26.6 [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>Opened:</b> 1998-09-29 <b>Last modified:</b> 2006-12-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> @@ -1230,8 +1374,8 @@ creates a temporary objects, which could be avoided without the cast. </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>Section:</b> 17.6.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>Opened:</b> 1998-01-22 <b>Last modified:</b> 2006-12-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>Is it a permitted extension for library implementors to add template parameters to @@ -1275,7 +1419,7 @@ may be provided by a non-Standard implementation class:</p> <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> +<p>Add a new subclause [presumably 17.4.4.9] following 17.6.4.10 [res.on.exception.handling]:</p> <blockquote> <p>17.4.4.9 Template Parameters</p> <p>A specialization of a @@ -1286,7 +1430,7 @@ may be provided by a non-Standard implementation class:</p> </blockquote> <p>Add "template parameters" to the list of subclauses at -the end of 17.4.4 [conforming] paragraph 1.</p> +the end of 17.6.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 @@ -1319,8 +1463,8 @@ of standard library class templates. <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>Section:</b> 17.6.4.5 [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>Opened:</b> 1998-10-07 <b>Last modified:</b> 2006-12-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 17.3.4.4/2 vs 17.3.4.7/0 there is a hole; an implementation could add virtual @@ -1351,7 +1495,7 @@ class vector_checking : public vector <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> +illegal. See 17.6.4.5 [member.functions] paragraph 2.</p> @@ -1359,7 +1503,7 @@ 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> + <b>Submitter:</b> AFNOR <b>Opened:</b> 1998-10-07 <b>Last modified:</b> 2006-12-27</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> @@ -1379,8 +1523,8 @@ 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>Section:</b> 24.5.1.2.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>Opened:</b> 1998-10-07 <b>Last modified:</b> 2006-12-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>The <, >, <=, >= comparison operator are wrong: they @@ -1401,8 +1545,10 @@ 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>Section:</b> 24.7 [insert.iterators], 24.6.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>Opened:</b> 1998-10-07 <b>Last modified:</b> 2006-12-27</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#insert.iterators">active issues</a> in [insert.iterators].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#insert.iterators">issues</a> in [insert.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>Overspecified For an insert iterator it, the expression *it is @@ -1422,8 +1568,8 @@ 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>Section:</b> 23.3.6 [vector], 23.3.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>Opened:</b> 1998-10-07 <b>Last modified:</b> 2007-02-19</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> @@ -1448,8 +1594,9 @@ expressed in a single line of code (where <tt>v</tt> is <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>Section:</b> 23.2.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>Opened:</b> 1998-10-07 <b>Last modified:</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#associative.reqmts">active issues</a> in [associative.reqmts].</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> @@ -1472,8 +1619,8 @@ container is O(1)!</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>Section:</b> 21.4.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>Opened:</b> 1998-10-07 <b>Last modified:</b> 2006-12-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#NAD">NAD</a> status.</p> <p><b>Discussion:</b></p> @@ -1495,10 +1642,10 @@ 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>Section:</b> 27.9 [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>Opened:</b> 1998-10-07 <b>Last modified:</b> 2008-01-05</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>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#454">454</a></p> <p><b>Discussion:</b></p> @@ -1518,8 +1665,8 @@ 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>Section:</b> 26.6.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>Opened:</b> 1998-10-07 <b>Last modified:</b> 2006-12-29</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> @@ -1547,60 +1694,9 @@ 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>Section:</b> 27.7.1.1 [istream], 27.7.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>Opened:</b> 1998-10-13 <b>Last modified:</b> 2006-12-27</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> @@ -1638,8 +1734,9 @@ desired functionality.</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>Section:</b> 20.3.6 [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>Opened:</b> 1998-11-06 <b>Last modified:</b> 2008-03-14</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#template.bitset">active issues</a> in [template.bitset].</p> <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> @@ -1683,13 +1780,13 @@ longer work.</p> <p><b>Proposed resolution:</b></p> -<p>Add to 23.3.5 [template.bitset] a bitset constructor declaration</p> +<p>Add to 20.3.6 [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> +<p>and in Section 20.3.6.1 [bitset.cons] add:</p> <blockquote> <pre>explicit bitset(const char* str);</pre> @@ -1710,15 +1807,15 @@ 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>Section:</b> 22.3.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>Opened:</b> 1998-12-15 <b>Last modified:</b> 2006-12-27</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> +<p>Also Section 22.4.1.1 [locale.ctype] says: </p> <blockquote> <p>The instantiations required in Table 51 (22.1.1.1.1) namely ctype<char> and @@ -1726,14 +1823,14 @@ ctype<wchar_t>. </p> native character set. </p> </blockquote> -<p>However, Section 22.2.1.3 [facet.ctype.special] +<p>However, Section 22.4.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> +22.4.1.3 [facet.ctype.special]. </p> <p><b>Rationale:</b></p> @@ -1745,8 +1842,8 @@ ctype<wchar_t> specialization. </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>Section:</b> 23.3.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>Opened:</b> 1999-03-06 <b>Last modified:</b> 2007-02-19</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> @@ -1763,8 +1860,8 @@ 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>Section:</b> 27.7.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>Opened:</b> 1999-03-06 <b>Last modified:</b> 2006-12-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>-1- Effects Constructs an object of class basic_iostream, assigning @@ -1794,51 +1891,14 @@ 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>Section:</b> 23.4.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>Opened:</b> 1999-04-14 <b>Last modified:</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#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> + <p>23.2 [container.requirements]<br> <br> expression return type pre/post-condition<br> @@ -1848,7 +1908,7 @@ not in the specialization. See issue <a href="http://www.open-std.org/jtc1/sc22/ T is assignable<br> <br> - 23.3.1 [map]<br> + 23.4.1 [map]<br> <br> A map satisfies all the requirements of a container.<br> <br> @@ -1876,7 +1936,7 @@ 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> + <b>Submitter:</b> Christophe de Dinechin <b>Opened:</b> 1999-05-04 <b>Last modified:</b> 2006-12-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>[depr.c.headers] paragraph 2 reads:</p> @@ -1987,8 +2047,8 @@ 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>Section:</b> 27.5.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>Opened:</b> 1999-05-12 <b>Last modified:</b> 2006-12-27</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> @@ -2014,93 +2074,20 @@ 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> +set. Consider Arabic or Hebrew, for example. See 22.4.2.2.2 [facet.num.put.virtuals] paragraph 19, Table 61 - Fill padding.</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>Section:</b> 27.5.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>Opened:</b> 1999-07-20 <b>Last modified:</b> 2007-01-15</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 +<p>According to paragraphs 2 and 4 of 27.5.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 @@ -2118,8 +2105,8 @@ character type used...</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>Section:</b> 27.7.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>Opened:</b> 1999-07-20 <b>Last modified:</b> 2007-01-15</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> @@ -2129,7 +2116,7 @@ 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 +have to conform to the "common requirements" from 27.7.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 @@ -2148,14 +2135,14 @@ output</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>Section:</b> 27.7.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>Opened:</b> 1999-07-20 <b>Last modified:</b> 2007-01-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#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 +input functions. As written, it seems that all functions in 27.7.1.3 [istream.unformatted] are unformatted input functions. However, it does not really make much sense to construct a sentry object for @@ -2183,13 +2170,13 @@ clarification should be used.</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>Section:</b> 27.7.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>Opened:</b> 1999-07-20 <b>Last modified:</b> 2007-01-15</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 +<p>From 27.7.2.6.1 [ostream.formatted.reqmts] it appears that all the functions +defined in 27.7.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 @@ -2204,8 +2191,8 @@ for output instead of input.</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>Section:</b> 26.4.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>Opened:</b> 1999-07-02 <b>Last modified:</b> 2006-12-27</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> @@ -2261,8 +2248,8 @@ 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>Section:</b> 27.4.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>Opened:</b> 1999-07-02 <b>Last modified:</b> 2006-12-27</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> @@ -2294,8 +2281,8 @@ 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>Section:</b> 26.6.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>Opened:</b> 1999-08-15 <b>Last modified:</b> 2008-03-11</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 @@ -2331,8 +2318,8 @@ 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>Section:</b> 25.5.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>Opened:</b> 1999-10-10 <b>Last modified:</b> 2006-12-27</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> @@ -2360,8 +2347,9 @@ 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>Section:</b> 23.2.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>Opened:</b> 1999-06-06 <b>Last modified:</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#associative.reqmts">active issues</a> in [associative.reqmts].</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> @@ -2406,7 +2394,7 @@ 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 +<p>In 23.2.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> @@ -2447,8 +2435,8 @@ 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>Section:</b> 27.5.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>Opened:</b> 1999-09-07 <b>Last modified:</b> 2006-12-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 classic iostreams, base class ios had an rdbuf function that returned a @@ -2493,20 +2481,20 @@ class <tt> rdbuf()</tt> always returns the original streambuf, whereas the base <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> +17.6.4.5 [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>Section:</b> 18.6.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>Opened:</b> 1998-12-15 <b>Last modified:</b> 2006-12-30</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> +<p>The example in 18.6.1.3 [new.delete.placement] paragraph 4 reads: </p> <blockquote> @@ -2530,8 +2518,8 @@ class <tt> rdbuf()</tt> always returns the original streambuf, whereas the base <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>Section:</b> X [allocator.requirements], 23.2 [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>Opened:</b> 1999-10-21 <b>Last modified:</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#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> @@ -2587,8 +2575,8 @@ called. </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>Section:</b> 27.7.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>Opened:</b> 2000-01-01 <b>Last modified:</b> 2007-01-15</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> @@ -2646,8 +2634,10 @@ 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>Section:</b> 24.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>Opened:</b> 2000-01-28 <b>Last modified:</b> 2008-09-30</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iterator.operations">active issues</a> in [iterator.operations].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.operations">issues</a> in [iterator.operations].</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 @@ -2680,7 +2670,7 @@ category?</p> <p><b>Rationale:</b></p> -<p>"Reachable" is defined in the standard in 24.1 [iterator.requirements] paragraph 6. +<p>"Reachable" is defined in the standard in 24.2 [iterator.concepts] paragraph 6. The definition is only in terms of operator++(). The LWG sees no defect in the standard.</p> @@ -2689,17 +2679,17 @@ 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>Section:</b> 18.3.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>Opened:</b> 2000-01-28 <b>Last modified:</b> 2006-12-27</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 +<p>In several places in 18.3.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 +<p>In 18.3.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 @@ -2721,8 +2711,8 @@ 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>Section:</b> 22.4.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>Opened:</b> 1999-11-02 <b>Last modified:</b> 2006-12-30</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> @@ -2736,7 +2726,7 @@ clause only describes one of the overloads. <p><b>Proposed resolution:</b></p> -<p>Change the returns clause in 22.2.1.3.2 [facet.ctype.char.members] +<p>Change the returns clause in 22.4.1.3.2 [facet.ctype.char.members] paragraph 10 from:</p> <p> Returns: do_widen(low, high, to).</p> @@ -2744,7 +2734,7 @@ paragraph 10 from:</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 +<p>Change the returns clause in 22.4.1.3.2 [facet.ctype.char.members] paragraph 11 from:</p> <p> Returns: do_narrow(low, high, to).</p> @@ -2764,8 +2754,8 @@ 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>Section:</b> 26.8 [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>Opened:</b> 2000-02-26 <b>Last modified:</b> 2006-12-29</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> @@ -2790,8 +2780,9 @@ 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>Section:</b> 23.2.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>Opened:</b> 2000-02-29 <b>Last modified:</b> 2006-12-27</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</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> @@ -2815,20 +2806,20 @@ too.</p> <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> +23.2.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>Section:</b> 27.7.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>Opened:</b> 2000-02-29 <b>Last modified:</b> 2006-12-30</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> +<p>27.7.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 @@ -2873,8 +2864,8 @@ 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>Section:</b> 25.5 [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>Opened:</b> 2000-03-06 <b>Last modified:</b> 2006-12-27</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> @@ -2908,65 +2899,18 @@ 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>Section:</b> 22.4.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>Opened:</b> 2000-04-24 <b>Last modified:</b> 2007-01-15</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 +<p>The description of the <tt>is()</tt> member in paragraph 4 of 22.4.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> +ie. the <tt>do_is()</tt> method as described in 22.4.1.1.2 [locale.ctype.virtuals] paragraph 1 does the right thing.</p> <p><b>Proposed resolution:</b></p> @@ -2990,8 +2934,8 @@ ie. the <tt>do_is()</tt> method as described in 22.2.1.1.2 [locale.ctype.virtual <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>Section:</b> 25.3.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>Opened:</b> 2000-05-02 <b>Last modified:</b> 2006-12-27</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> @@ -3031,8 +2975,8 @@ 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>Section:</b> 24.6.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>Opened:</b> 2000-05-02 <b>Last modified:</b> 2006-12-27</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> @@ -3065,8 +3009,9 @@ 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>Section:</b> 23.2.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>Opened:</b> 2000-05-19 <b>Last modified:</b> 2007-01-15</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</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> @@ -3154,7 +3099,8 @@ Change the words "right after" to "immediately before".</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> + <b>Submitter:</b> Joseph Gottman <b>Opened:</b> 2000-06-30 <b>Last modified:</b> 2006-12-29</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#auto.ptr">active issues</a> in [auto.ptr].</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> @@ -3195,8 +3141,8 @@ 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>Section:</b> 20.7.3 [base], D.10.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>Opened:</b> 2000-08-17 <b>Last modified:</b> 2006-12-29</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> @@ -3280,7 +3226,7 @@ want to pass temporaries as traits or tag types in generic code. <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> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-10-05 <b>Last modified:</b> 2007-01-15</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> @@ -3383,8 +3329,8 @@ 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>Section:</b> 18.8 [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>Opened:</b> 2000-10-10 <b>Last modified:</b> 2006-12-27</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> @@ -3444,8 +3390,8 @@ necessary. <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>Section:</b> X [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>Opened:</b> 2000-11-07 <b>Last modified:</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#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> @@ -3479,8 +3425,8 @@ 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>Section:</b> 23.2 [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>Opened:</b> 2000-11-27 <b>Last modified:</b> 2006-12-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> @@ -3508,7 +3454,7 @@ const_iterator unless the above it true. I suspect the former. <p><b>Proposed resolution:</b></p> <p> -In <b>Section:</b> 23.1 [container.requirements], +In <b>Section:</b> 23.2 [container.requirements], table 65, in the assertion/note pre/post condition for X::const_iterator, add the following: </p> @@ -3548,8 +3494,8 @@ have the same value type, but that is a new issue. (Issue <a href="http://www.op <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>Section:</b> 27.5.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>Opened:</b> 2000-12-30 <b>Last modified:</b> 2006-12-27</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> @@ -3603,7 +3549,7 @@ 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 +possible combination of bits. See for example Table 58, in 22.4.2.2.2 [facet.num.put.virtuals], noting the requirement in paragraph 6 of that section. </p> @@ -3618,8 +3564,8 @@ version of <tt>setf</tt>, to avoid unexpected behavior. <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>Section:</b> 26.8 [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>Opened:</b> 2000-12-30 <b>Last modified:</b> 2007-01-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> @@ -3689,8 +3635,8 @@ 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>Section:</b> 25.4.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>Opened:</b> 2001-01-04 <b>Last modified:</b> 2007-01-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#NAD">NAD</a> status.</p> <p><b>Discussion:</b></p> @@ -3758,12 +3704,13 @@ 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>Section:</b> 20.3.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>Opened:</b> 2001-01-14 <b>Last modified:</b> 2006-12-27</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#pairs">active issues</a> in [pairs].</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] +<p>The synopsis of the header <tt><utility></tt> in 20.3 [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 @@ -3773,10 +3720,10 @@ not mentioned at all. <p><b>Rationale:</b></p> -<p>20.2.1 [operators] paragraph 10 already specifies the semantics. +<p>20.3.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 +defined as specified in 20.3.1 [operators]. There should be no user confusion, since that paragraph happens to immediately precede the specification of <tt>pair</tt>.</p> @@ -3785,9 +3732,139 @@ specification of <tt>pair</tt>.</p> <hr> +<h3><a name="299"></a>299. Incorrect return types for iterator dereference</h3> +<p><b>Section:</b> 24.2.5 [bidirectional.iterators], 24.2.6 [random.access.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> John Potter <b>Opened:</b> 2001-01-22 <b>Last modified:</b> 2008-09-26</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#NAD%20Editorial">NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<p> +In section 24.2.5 [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.2.6 [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> + + + + +<p><b>Rationale:</b></p> +<p><i>[ +San Francisco: +]</i></p> + + +<blockquote> +Solved by +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/N2758.pdf">N2758</a>. +</blockquote> + + + + + + + +<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>Section:</b> 22.4.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>Opened:</b> 2001-01-25 <b>Last modified:</b> 2006-12-27</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> @@ -3857,10 +3934,10 @@ 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>Section:</b> 24.2 [iterator.concepts] <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>Opened:</b> 2001-02-05 <b>Last modified:</b> 2008-09-30</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iterator.concepts">active issues</a> in [iterator.concepts].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.concepts">issues</a> in [iterator.concepts].</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> @@ -3903,8 +3980,8 @@ buffered somewhere to make a legal input iterator. <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>Section:</b> 18.8.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>Opened:</b> 2001-04-03 <b>Last modified:</b> 2006-12-27</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> @@ -3953,8 +4030,8 @@ 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>Section:</b> 18.8.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>Opened:</b> 2001-04-11 <b>Last modified:</b> 2007-01-15</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> @@ -4000,8 +4077,8 @@ about when terminate() is called; it merely specifies which <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>Section:</b> 26.8 [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>Opened:</b> 2001-06-04 <b>Last modified:</b> 2008-03-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#NAD">NAD</a> status.</p> <p><b>Discussion:</b></p> @@ -4079,8 +4156,8 @@ The situation is not sufficiently severe to warrant a change. <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>Section:</b> 22.4.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>Opened:</b> 2001-07-05 <b>Last modified:</b> 2006-12-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>The definition of the moneypunct facet contains the typedefs char_type @@ -4091,7 +4168,7 @@ 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> +22.4.6.4 [locale.moneypunct.byname].</p> <p><b>Rationale:</b></p> @@ -4104,8 +4181,8 @@ 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>Section:</b> 22.3.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>Opened:</b> 2001-07-15 <b>Last modified:</b> 2006-12-27</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> @@ -4135,7 +4212,7 @@ belonging to the collate category from the German locale on AIX: <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 +this requirement (22.3.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, @@ -4154,14 +4231,14 @@ any other choice would be.</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>Section:</b> 27.5.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>Opened:</b> 2001-08-27 <b>Last modified:</b> 2006-12-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]. +Table 88 -- Position type requirements in 27.5.3 [fpos]. </p> @@ -4196,8 +4273,8 @@ report. Additionally, nobody saw a clear need for this extension; <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>Section:</b> 22.4.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>Opened:</b> 2001-10-13 <b>Last modified:</b> 2007-01-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> @@ -4214,7 +4291,7 @@ to format (or parse) in this manner. <p><b>Proposed resolution:</b></p> <p> -Insert into 22.2.3.1.2 [facet.numpunct.virtuals] paragraph 3, just before the last +Insert into 22.4.3.1.2 [facet.numpunct.virtuals] paragraph 3, just before the last sentence: </p> <blockquote><p> @@ -4240,8 +4317,9 @@ consensus in the LWG for action. <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>Section:</b> 20.3.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>Opened:</b> 2001-10-23 <b>Last modified:</b> 2008-01-05</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#pairs">active issues</a> in [pairs].</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> @@ -4255,7 +4333,7 @@ operator< on any pair type which contains a pointer. <p><b>Proposed resolution:</b></p> -<p>In 20.2.3 [pairs] paragraph 6, replace:</p> +<p>In 20.3.3 [pairs] paragraph 6, replace:</p> <pre> Returns: x.first < y.first || (!(y.first < x.first) && x.second < y.second). </pre> @@ -4288,8 +4366,8 @@ operator< on any pair type which contains a pointer. <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>Section:</b> 20.8.6.1 [allocator.members], X [allocator.requirements], 17.6.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>Opened:</b> 2001-10-25 <b>Last modified:</b> 2007-10-11</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> @@ -4353,7 +4431,7 @@ a.address(s) lines, respectively: <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 +is required to be CopyConstructible (X [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 @@ -4373,15 +4451,15 @@ exhibiting a problem.</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>Section:</b> 20.7 [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>Opened:</b> 2001-11-12 <b>Last modified:</b> 2007-04-24</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 +In 20.7 [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 +However in 20.7.11 [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. @@ -4392,7 +4470,7 @@ an editorial oversight. <p><b>Proposed resolution:</b></p> -<p>Change the synopsis to reflect the useage in 20.6.10 [negators]</p> +<p>Change the synopsis to reflect the useage in 20.7.11 [negators]</p> <p><i>[Curaçao: Since the language permits "struct", the LWG views this as NAD. They suggest, however, that the Project Editor @@ -4406,8 +4484,9 @@ 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>Section:</b> 20.3.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>Opened:</b> 2001-12-02 <b>Last modified:</b> 2008-01-05</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#pairs">active issues</a> in [pairs].</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> @@ -4461,8 +4540,8 @@ and thus moved from NAD Future to NAD Editorial. <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>Section:</b> 22.4.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>Opened:</b> 2002-01-23 <b>Last modified:</b> 2006-12-27</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> @@ -4509,7 +4588,7 @@ 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 +only" values in 22.4.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 @@ -4616,8 +4695,8 @@ 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>Section:</b> 26.8 [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>Opened:</b> 2002-02-26 <b>Last modified:</b> 2007-04-24</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> @@ -4677,8 +4756,8 @@ discussion concur.</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>Section:</b> 22.4.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>Opened:</b> 2002-03-12 <b>Last modified:</b> 2007-01-15</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> @@ -4732,7 +4811,8 @@ Change the first sentence of 22.2.2.2.2, p12 from <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> + <b>Submitter:</b> Walter Brown, Marc Paterno <b>Opened:</b> 2002-05-10 <b>Last modified:</b> 2006-12-27</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#input.output">active issues</a> in [input.output].</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> @@ -4855,13 +4935,13 @@ those terms, does not appear in the standard.]</i></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>Section:</b> 25.4.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>Opened:</b> 2002-05-13 <b>Last modified:</b> 2006-12-27</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 +remove_copy and remove_copy_if (25.4.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 @@ -4878,7 +4958,7 @@ result maintained, so the temporary is not required. 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. +25.4.8 [alg.remove] paragraph 6. </p> @@ -4892,12 +4972,12 @@ constructible. Otherwise copy constructible is not required." to <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>Section:</b> 21.4.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>Opened:</b> 2002-06-03 <b>Last modified:</b> 2007-04-24</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 +21.4.6.6 [string::replace] basic_string::replace, second signature, given in paragraph 1, has two "Throws" paragraphs (3 and 5). </p> @@ -4924,13 +5004,13 @@ part of the "Effects" paragraph. <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>Section:</b> 17.6.4.10 [res.on.exception.handling], 18.7.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>Opened:</b> 2002-07-22 <b>Last modified:</b> 2006-12-27</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 +<p>Paragraph 3 under clause 17.6.4.10 [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." @@ -4941,7 +5021,7 @@ 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 +18.7.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> @@ -4964,18 +5044,18 @@ Standard library components ...".</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>Section:</b> 22.4.6.3.1 [locale.moneypunct.members], 22.4.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>Opened:</b> 2002-08-08 <b>Last modified:</b> 2006-12-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 section 22.2.6.3.1 [locale.moneypunct.members], frac_digits() returns type +In section 22.4.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() +Similarly, in section 22.4.6.3.2 [locale.moneypunct.virtuals], do_frac_digits() should return "unsigned". </p> @@ -4997,13 +5077,13 @@ 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>Section:</b> 21.4.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>Opened:</b> 2002-08-16 <b>Last modified:</b> 2006-12-27</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, +Section 21.4.6.4 [string::insert], paragraph 4, contains the following, "Then throws length_error if size() >= npos - rlen." </p> @@ -5023,8 +5103,8 @@ 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>Section:</b> 22.3.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>Opened:</b> 2002-09-06 <b>Last modified:</b> 2006-12-30</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> @@ -5073,14 +5153,15 @@ out of scope? <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> + <b>Submitter:</b> Matt Austern <b>Opened:</b> 2002-10-23 <b>Last modified:</b> 2007-04-18</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</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 +25.3.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> @@ -5150,8 +5231,8 @@ then precisely describe and enforce the precise requirements. <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>Section:</b> 26.4 [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>Opened:</b> 2002-11-08 <b>Last modified:</b> 2008-02-27</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> @@ -5222,9 +5303,8 @@ 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>Section:</b> X [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>Opened:</b> 2002-10-24 <b>Last modified:</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#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> @@ -5290,20 +5370,20 @@ that &t and &u return the address of t and u, respectively. <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>Section:</b> 24.2.2 [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>Opened:</b> 2002-12-11 <b>Last modified:</b> 2006-12-27</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 - +In section 24.2.2 [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 +In section 24.6.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). @@ -5311,7 +5391,7 @@ what streambuf object they use</i>." (My emphasis). <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] +defined or the conditions for equality in 24.6.3.5 [istreambuf.iterator::equal] are incorrect. (Or both). </p> @@ -5332,7 +5412,7 @@ are incorrect. (Or both). </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> +f1 == f2 by 24.6.3.5 [istreambuf.iterator::equal].</p> <p>However, it is unlikely that *f1 will give the same value as *f2 except by accident.</p> @@ -5355,8 +5435,8 @@ of input iterators.</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>Section:</b> 22.4.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>Opened:</b> 2002-12-24 <b>Last modified:</b> 2008-07-02</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> @@ -5373,7 +5453,7 @@ characters as a result of operation on state? <p><b>Proposed resolution:</b></p> <p> -Add a note at the end of 22.2.1.4.2 [locale.codecvt.virtuals], +Add a note at the end of 22.4.1.4.2 [locale.codecvt.virtuals], paragraph 3: </p> @@ -5417,8 +5497,8 @@ correct. Proposed Disposition: NAD, Editorial <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>Section:</b> 27.7.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>Opened:</b> 2003-01-05 <b>Last modified:</b> 2006-12-27</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> @@ -5463,98 +5543,9 @@ can use alternative signatures that don't call widen. <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>Section:</b> 27.5.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>Opened:</b> 2003-09-18 <b>Last modified:</b> 2006-12-30</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> @@ -5595,8 +5586,8 @@ to <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>Section:</b> 18.8.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>Opened:</b> 2003-09-29 <b>Last modified:</b> 2006-12-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> @@ -5628,8 +5619,8 @@ ambiguity in understanding. <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>Section:</b> 27.7.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>Opened:</b> 2003-10-24 <b>Last modified:</b> 2006-12-27</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> @@ -5674,8 +5665,8 @@ conversions from C and the function pointer is converted to bool. <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>Section:</b> 22.4 [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>Opened:</b> 2003-11-02 <b>Last modified:</b> 2006-12-27</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> @@ -5731,8 +5722,8 @@ conversions from C and the function pointer is converted to bool. <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>Section:</b> 26.4.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>Opened:</b> 2003-11-05 <b>Last modified:</b> 2009-03-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> @@ -5751,7 +5742,7 @@ transcendentals, as discussed in issue <a href="http://www.open-std.org/jtc1/sc2 <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 +unspecified." (26.4.1 [complex.syn]) 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> @@ -5771,8 +5762,8 @@ 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>Section:</b> 22.3.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>Opened:</b> 2003-12-26 <b>Last modified:</b> 2007-01-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#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> @@ -5807,23 +5798,23 @@ Change the second template argument to InputIterator. <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>Section:</b> 23.4.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>Opened:</b> 2004-01-30 <b>Last modified:</b> 2009-05-01</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> 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> iterator find(const key_type&) const; </pre> <p> @@ -5844,21 +5835,22 @@ table, in this regard. <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>Section:</b> 23.2.4 [associative.reqmts], 23.4 [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>Opened:</b> 2004-01-30 <b>Last modified:</b> 2009-05-01</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</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> 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> iterator erase(iterator); + iterator erase(iterator, iterator); </pre> @@ -5880,13 +5872,13 @@ first element beyond the erased subrange. <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>Section:</b> 22.3.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>Opened:</b> 2004-01-30 <b>Last modified:</b> 2009-05-01</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; + locale::combine(const locale&) const; </pre> <p> is obliged to create a locale that has no name. This is overspecification @@ -5920,9 +5912,201 @@ standard facets. <hr> +<h3><a name="454"></a>454. basic_filebuf::open should accept wchar_t names</h3> +<p><b>Section:</b> 27.9.1.4 [filebuf.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>Opened:</b> 2004-01-30 <b>Last modified:</b> 2009-05-01</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#NAD">NAD</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> + +<p><i>[ +San Francisco: +]</i></p> + + +<blockquote> +Some existing implementations provide overload already. Expected +filesystem "path" object overloads neatly, without surprises; implying +NAD. +</blockquote> + + + + + + + +<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>Section:</b> 3.6.3 [basic.start.term], 18.4 [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>Opened:</b> 2004-03-23 <b>Last modified:</b> 2008-02-25</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> @@ -6074,57 +6258,9 @@ Bill agrees issue is no longer serious, and accepts NAD. <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> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2004-06-28 <b>Last modified:</b> 2007-04-18</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> @@ -6177,8 +6313,8 @@ corner cases. <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>Section:</b> 25.5.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>Opened:</b> 2004-06-30 <b>Last modified:</b> 2006-12-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> @@ -6201,8 +6337,8 @@ There is no "Returns:" clause for std::equal_range, which returns non-void. <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>Section:</b> 24.2.4 [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>Opened:</b> 2004-07-09 <b>Last modified:</b> 2007-01-15</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> @@ -6241,8 +6377,8 @@ 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>Section:</b> 24.2.4 [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>Opened:</b> 2004-07-11 <b>Last modified:</b> 2007-01-15</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> @@ -6294,8 +6430,8 @@ as the first line.</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>Section:</b> 23.2 [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>Opened:</b> 2004-08-01 <b>Last modified:</b> 2007-04-18</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> @@ -6343,8 +6479,8 @@ support that the eventual solution should make this code well formed. <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>Section:</b> 20.7.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>Opened:</b> 2004-08-19 <b>Last modified:</b> 2006-12-29</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> @@ -6408,8 +6544,9 @@ nonvirtual destructors.</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>Section:</b> 25.4.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>Opened:</b> 2004-08-30 <b>Last modified:</b> 2006-12-27</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#alg.unique">active issues</a> in [alg.unique].</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> @@ -6445,8 +6582,9 @@ 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>Section:</b> 20.3.3 [pairs], 20.5 [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>Opened:</b> 2004-09-14 <b>Last modified:</b> 2007-05-06</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#pairs">active issues</a> in [pairs].</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> @@ -6463,7 +6601,7 @@ list<double> > should not take O(1).</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>. +missed <tt>tuple</tt>. <tt>tuple::swap</tt> is being tracked by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#522">522</a>. ]</i></p> @@ -6487,8 +6625,8 @@ Recommend NAD, fixed by <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>Section:</b> 25.3 [alg.nonmodifying], 25.4 [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>Opened:</b> 2004-09-20 <b>Last modified:</b> 2007-01-15</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> @@ -6591,9 +6729,82 @@ operator that takes a T, or a T may be convertible to the type of *i. <hr> +<h3><a name="484"></a>484. Convertible to T</h3> +<p><b>Section:</b> 24.2.2 [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> Chris Jefferson <b>Opened:</b> 2004-09-16 <b>Last modified:</b> 2008-09-26</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> +<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> + + +<p><b>Rationale:</b></p> +<p><i>[ +San Francisco: +]</i></p> + + +<blockquote> +Solved by +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/N2758.pdf">N2758</a>. +</blockquote> + + + + + + + +<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>Section:</b> 25.5.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>Opened:</b> 2004-10-13 <b>Last modified:</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#alg.min.max">active issues</a> in [alg.min.max].</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> @@ -6615,8 +6826,8 @@ copy T.</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>Section:</b> X [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>Opened:</b> 2004-10-17 <b>Last modified:</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#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> @@ -6660,8 +6871,8 @@ be called! Doesn't that sound great? <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>Section:</b> 25.4.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>Opened:</b> 2004-12-12 <b>Last modified:</b> 2006-12-27</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> @@ -6859,8 +7070,9 @@ ISO/IEC 14882:2003. <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>Section:</b> 25.4.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>Opened:</b> 2004-12-12 <b>Last modified:</b> 2006-12-27</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#alg.unique">active issues</a> in [alg.unique].</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> @@ -7110,12 +7322,12 @@ 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>Section:</b> 23.3.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>Opened:</b> 2004-12-12 <b>Last modified:</b> 2007-02-19</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 +<p>In Section 23.3.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> @@ -7125,7 +7337,7 @@ current wording is defective for various reasons.</p> 1) Analysis of current wording: </p> -<p>23.2.4.4 [list.ops], paragraph 19:</p> +<p>23.3.4.4 [list.ops], paragraph 19:</p> <p> Current wording says: @@ -7139,7 +7351,7 @@ predicate argument) holds."</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> +wording of 23.3.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, @@ -7156,7 +7368,7 @@ 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: +23.3.4.4 [list.ops], paragraph 20: </p> <p> @@ -7173,7 +7385,7 @@ expressions ( "*i == *(i - 1)", "pred(*i, *(i -1))" ). </p> <p> -23.2.4.4 [list.ops], paragraph 21:</p> +23.3.4.4 [list.ops], paragraph 21:</p> <p> Current wording says: @@ -7212,7 +7424,7 @@ of DR 202, no impact on current code is expected.</p> 3) Proposed fixes:</p> <p> -Change 23.2.4.4 [list.ops], paragraph 19 to:</p> +Change 23.3.4.4 [list.ops], paragraph 19 to:</p> <p> "Effect: Erases all but the first element from every consecutive group @@ -7231,7 +7443,7 @@ 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 +This would also imply a change of 23.3.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 @@ -7251,7 +7463,7 @@ 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> +Change 23.3.4.4 [list.ops], paragraph 20 to:</p> <p> "Throws: Nothing unless an exception is thrown by *(i-1) == *i or @@ -7262,7 +7474,7 @@ 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], +23.3.4.4 [list.ops], paragraph 19. If 23.3.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 @@ -7271,7 +7483,7 @@ take this into account. c) Typos fixed.</p> <p> -Change 23.2.4.4 [list.ops], paragraph 21 to:</p> +Change 23.3.4.4 [list.ops], paragraph 21 to:</p> <p> "Complexity: If empty() == false, exactly size() - 1 applications of the @@ -7312,8 +7524,8 @@ 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>Section:</b> 24.2.2 [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>Opened:</b> 2004-12-13 <b>Last modified:</b> 2006-12-27</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> @@ -7352,8 +7564,9 @@ not guarantee the substitution property or referential transparency).</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>Section:</b> 23.2.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>Opened:</b> 2004-12-19 <b>Last modified:</b> 2006-12-27</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</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> @@ -7410,8 +7623,8 @@ last) and insert(first, last).</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>Section:</b> 25.5.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>Opened:</b> 2005-04-12 <b>Last modified:</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#NAD%20Editorial">NAD Editorial</a> status.</p> <p><b>Discussion:</b></p> <blockquote><p> @@ -7480,8 +7693,8 @@ This change has already been made. <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>Section:</b> 22.4.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>Opened:</b> 2005-05-24 <b>Last modified:</b> 2008-03-13</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> @@ -7505,8 +7718,8 @@ Contradiction. <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>Section:</b> 20.7.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>Opened:</b> 2005-06-07 <b>Last modified:</b> 2008-03-13</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> @@ -7577,8 +7790,8 @@ to detect overlapping memory situations. <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>Section:</b> X [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>Opened:</b> 2005-07-03 <b>Last modified:</b> 2008-03-13</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> @@ -7646,8 +7859,9 @@ Portland: Subsumed by N2111. <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>Section:</b> 26.5 [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>Opened:</b> 2005-07-03 <b>Last modified:</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#rand">active issues</a> in [rand].</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> @@ -7687,8 +7901,8 @@ Marc supports having min and max to satisfy generic programming interface. <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>Section:</b> 26.5.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>Opened:</b> 2005-07-03 <b>Last modified:</b> 2008-03-13</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> @@ -7728,8 +7942,8 @@ eliminated. <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>Section:</b> 26.5.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>Opened:</b> 2005-07-03 <b>Last modified:</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#NAD">NAD</a> status.</p> <p><b>Discussion:</b></p> <p> @@ -7759,8 +7973,8 @@ eliminated. <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>Section:</b> 26.5.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>Opened:</b> 2005-07-03 <b>Last modified:</b> 2008-03-13</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> @@ -7849,8 +8063,8 @@ eliminated. <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>Section:</b> 26.5.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>Opened:</b> 2005-07-03 <b>Last modified:</b> 2008-03-13</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> @@ -7939,8 +8153,8 @@ Portland: Subsumed by N2111. <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>Section:</b> 26.5.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>Opened:</b> 2005-07-03 <b>Last modified:</b> 2008-03-13</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> @@ -7992,8 +8206,8 @@ Berlin: N1932 adopts the proposed NAD. <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>Section:</b> 26.5.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>Opened:</b> 2005-07-03 <b>Last modified:</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#NAD%20Editorial">NAD Editorial</a> status.</p> <p><b>Discussion:</b></p> <p> @@ -8037,8 +8251,8 @@ Berlin: N1932 adopts the proposed NAD. <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>Section:</b> 26.5.1 [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>Opened:</b> 2005-07-03 <b>Last modified:</b> 2008-03-13</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> @@ -8111,8 +8325,8 @@ covers this. Already in WP. <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>Section:</b> 26.5.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>Opened:</b> 2005-07-03 <b>Last modified:</b> 2008-03-13</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> @@ -8149,8 +8363,8 @@ Portland: Subsumed by N2111. <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>Section:</b> X [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>Opened:</b> 2005-07-03 <b>Last modified:</b> 2008-03-13</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> @@ -8187,8 +8401,8 @@ Berlin: N1932 considers this NAD. This is a QOI issue. <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>Section:</b> 20.6.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>Opened:</b> 2005-07-11 <b>Last modified:</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#NAD%20Editorial">NAD Editorial</a> status.</p> <p><b>Discussion:</b></p> <p> @@ -8222,8 +8436,9 @@ 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>Section:</b> 23.2.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>Opened:</b> 2005-09-14 <b>Last modified:</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#sequence.reqmts">active issues</a> in [sequence.reqmts].</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> @@ -8357,8 +8572,8 @@ 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 +23.2.3 [sequence.reqmts], p4 says so.</li> +<li><tt>copy</tt> has to work, except where 25.4.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 @@ -8372,9 +8587,8 @@ template insert functions from self referencing.</li> <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>Section:</b> 23.5 [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>Opened:</b> 2005-10-12 <b>Last modified:</b> 2008-03-13</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> @@ -8449,8 +8663,8 @@ 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>Section:</b> 17.6.3.11 [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>Opened:</b> 2005-10-25 <b>Last modified:</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#NAD%20Editorial">NAD Editorial</a> status.</p> <p><b>Discussion:</b></p> <p> @@ -8543,9 +8757,10 @@ Alan provided the survey <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>Section:</b> 20.5.2.5 [tuple.rel], TR1 6.1.3.5 [tr.tuple.rel] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> + <b>Submitter:</b> David Abrahams <b>Opened:</b> 2005-11-29 <b>Last modified:</b> 2008-09-23</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple.rel">issues</a> in [tuple.rel].</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>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> @@ -8612,14 +8827,24 @@ algorithms). Dietmar will survey and work up proposed wording. Recommend NAD. This will be fixed with the next revision of concepts. </p> +<p><i>[ +San Francisco: +]</i></p> + + +<blockquote> +Solved by +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2770.pdf">N2770</a>. +</blockquote> + <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>Section:</b> 23.2 [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>Opened:</b> 2005-12-17 <b>Last modified:</b> 2007-04-18</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> @@ -8691,7 +8916,8 @@ Berlin: Some support, not universal, for respecting the explicit qualifier. <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> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2005-11-25 <b>Last modified:</b> 2007-04-24</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#diff.library">issues</a> in [diff.library].</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> @@ -8734,8 +8960,9 @@ Portland: Resolution is considered editorial. It will be incorporated into the <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>Section:</b> 26.5 [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>Opened:</b> 2006-01-10 <b>Last modified:</b> 2007-04-18</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand">active issues</a> in [rand].</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> @@ -8767,8 +8994,9 @@ Recommend NAD as the affected section is now gone and so the issue is moot. <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>Section:</b> 26.5.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>Opened:</b> 2006-01-10 <b>Last modified:</b> 2007-10-18</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.device">issues</a> in [rand.device].</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> @@ -8809,8 +9037,8 @@ Adopt the proposed resolution in <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>Section:</b> 26.5.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>Opened:</b> 2006-01-10 <b>Last modified:</b> 2007-04-24</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> @@ -8838,8 +9066,8 @@ Portland: Subsumed by N2111. <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>Section:</b> 18.4.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>Opened:</b> 2006-01-30 <b>Last modified:</b> 2007-07-02</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> @@ -8855,7 +9083,7 @@ probably should, consistently with C99, 7.18.1.4. <p><b>Proposed resolution:</b></p> <p> -Change 18.3.1 [cstdint.syn]: +Change 18.4.1 [cstdint.syn]: </p> <blockquote><pre>... @@ -8876,8 +9104,8 @@ 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>Section:</b> 18.3.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>Opened:</b> 2006-01-29 <b>Last modified:</b> 2007-01-15</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> @@ -8943,7 +9171,7 @@ value that will trap. <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> + <b>Submitter:</b> Paolo Carlini <b>Opened:</b> 2006-02-02 <b>Last modified:</b> 2007-04-24</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> @@ -8972,9 +9200,84 @@ Redmond: Editorial. <hr> +<h3><a name="556"></a>556. is Compare a BinaryPredicate?</h3> +<p><b>Section:</b> 25.5 [alg.sorting] <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>Opened:</b> 2006-02-05 <b>Last modified:</b> 2008-09-26</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%20Editorial">NAD Editorial</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> + + +<p><b>Rationale:</b></p> +<p><i>[ +San Francisco: +]</i></p> + + +<blockquote> +Solved by +(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2774.pdf">N2774</a>). +</blockquote> + + + + + + +<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>Section:</b> 18.4 [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>Opened:</b> 2006-02-06 <b>Last modified:</b> 2008-07-02</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> @@ -9064,8 +9367,8 @@ may not be unique if intmax_t==_longlong. <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>Section:</b> 24.2.2 [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>Opened:</b> 2006-02-09 <b>Last modified:</b> 2007-04-24</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> @@ -9112,8 +9415,8 @@ Portland: Editorial. <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>Section:</b> X [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>Opened:</b> 2006-02-17 <b>Last modified:</b> 2007-04-18</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> @@ -9251,8 +9554,8 @@ semantics of copying the allocator from one of the strings (<i>lhs</i> when ther <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>Section:</b> 27.5.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>Opened:</b> 2006-03-10 <b>Last modified:</b> 2006-12-30</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> @@ -9290,8 +9593,8 @@ committee meant. <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>Section:</b> 21.2 [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>Opened:</b> 2006-04-06 <b>Last modified:</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#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> @@ -9358,7 +9661,7 @@ Nobody has submitted the requested paper, so we move to NAD, as suggested by the <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> + <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2006-04-08 <b>Last modified:</b> 2007-07-02</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> @@ -9393,8 +9696,9 @@ 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>Section:</b> 26.5 [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>Opened:</b> 2006-04-11 <b>Last modified:</b> 2007-04-18</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand">active issues</a> in [rand].</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> @@ -9429,8 +9733,8 @@ is adopted. <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>Section:</b> 23.2.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>Opened:</b> 2006-06-13 <b>Last modified:</b> 2008-03-12</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> @@ -9517,8 +9821,8 @@ uses depend on the iterator being returned. <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>Section:</b> 26.8 [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>Opened:</b> 2006-06-15 <b>Last modified:</b> 2007-07-25</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> @@ -9555,8 +9859,8 @@ 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>Section:</b> 26.8 [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>Opened:</b> 2006-06-15 <b>Last modified:</b> 2007-07-25</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> @@ -9577,7 +9881,7 @@ T power( T x, int n ); <p><b>Rationale:</b></p> -Toronto: We already have double pow(integral, integral) from 26.7 [c.math] p11. +Toronto: We already have double pow(integral, integral) from 26.8 [c.math] p11. @@ -9586,7 +9890,7 @@ 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> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-06-22 <b>Last modified:</b> 2007-05-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> @@ -9618,8 +9922,9 @@ post Oxford: Noted that it is already fixed in <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>Section:</b> 20.6 [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>Opened:</b> 2006-08-10 <b>Last modified:</b> 2007-05-11</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta">active issues</a> in [meta].</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> @@ -9659,8 +9964,8 @@ current working draft. <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>Section:</b> 18.3.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>Opened:</b> 2006-08-08 <b>Last modified:</b> 2007-07-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#NAD%20Editorial">NAD Editorial</a> status.</p> <p><b>Discussion:</b></p> @@ -9728,8 +10033,8 @@ Recommend NAD / Editorial. The proposed resolution is accepted as editorial. <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>Section:</b> 27.9.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>Opened:</b> 2006-08-17 <b>Last modified:</b> 2008-07-02</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> @@ -9755,7 +10060,7 @@ correct for basic_ofstream. <p><b>Proposed resolution:</b></p> <p> -Change 27.8.1.9 [ifstream.members], p5: +Change 27.9.1.9 [ifstream.members], p5: </p> <blockquote><p> @@ -9766,7 +10071,7 @@ calls <tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt> </p></blockquote> <p> -Change 27.8.1.17 [fstream.members], p5: +Change 27.9.1.17 [fstream.members], p5: </p> <blockquote><p> @@ -9788,11 +10093,10 @@ Kona (2007): Proposed Disposition: NAD, Editorial <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>Section:</b> X [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> Niels Dekker <b>Opened:</b> 2006-11-02 <b>Last modified:</b> 2008-09-23</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>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 seems undesirable to define the Swappable requirement in terms of @@ -9925,14 +10229,24 @@ and will essentially rewrite this section and provide the desired semantics. </p> +<p><i>[ +San Francisco: +]</i></p> + + +<blockquote> +Solved by +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2774.pdf">N2774</a>. +</blockquote> + <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>Section:</b> 21.6 [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>Opened:</b> 2006-12-11 <b>Last modified:</b> 2007-04-24</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> @@ -9969,141 +10283,10 @@ Recommend NAD, editorial. Send to Pete. <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>Section:</b> 17.5.1.4 [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>Opened:</b> 2007-01-20 <b>Last modified:</b> 2008-02-25</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#structure.specifications">active issues</a> in [structure.specifications].</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> @@ -10111,10 +10294,10 @@ Reopened. 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 +are not mentioned in 17.5.1.4 [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). +17.5.1.2 [structure.summary], p2, and which they replace in many cases). </p> <p> @@ -10143,8 +10326,8 @@ Bellevue: Already resolved in current working paper. <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>Section:</b> 18.6.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>Opened:</b> 2007-01-23 <b>Last modified:</b> 2008-02-25</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> @@ -10153,7 +10336,7 @@ 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], +think we can put this escape hatch in 18.6.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 @@ -10176,13 +10359,112 @@ its resource limits", so no further escape hatch is necessary. <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#NAD%20Editorial">NAD Editorial</a> + <b>Submitter:</b> James Kanze <b>Opened:</b> 2007-01-31 <b>Last modified:</b> 2008-09-26</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#NAD%20Editorial">NAD Editorial</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.5.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> + + +<p><b>Rationale:</b></p> +<p><i>[ +post San Francisco: +]</i></p> + + +<blockquote> +Solved by +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/N2759.pdf">N2759</a>. +</blockquote> + + + + + + +<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>Section:</b> 20.7.16.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>Opened:</b> 2007-02-03 <b>Last modified:</b> 2007-07-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> -20.6.15.2.5 [func.wrap.func.targ], p4 says: +20.7.16.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 @@ -10198,7 +10480,7 @@ function <tt>type()</tt> in class template function nor in the global or <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. +void</tt> due to returns clause 20.7.16.2.5 [func.wrap.func.targ], p1. </li> </ol> @@ -10206,7 +10488,7 @@ void</tt> due to returns clause 20.6.15.2.5 [func.wrap.func.targ], p1. <p><b>Proposed resolution:</b></p> <p> -Change 20.6.15.2.5 [func.wrap.func.targ], p4: +Change 20.7.16.2.5 [func.wrap.func.targ], p4: </p> <blockquote><p> @@ -10227,8 +10509,8 @@ Pete: Agreed. It's editorial, so I'll fix it. <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>Section:</b> 26.6.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>Opened:</b> 2007-02-11 <b>Last modified:</b> 2007-07-02</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> @@ -10256,13 +10538,13 @@ Pete recommends editorial fix. <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>Section:</b> 26.8 [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>Opened:</b> 2007-02-13 <b>Last modified:</b> 2007-07-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> -26.7 [c.math], paragraph 10 has long lists of added signatures for float and long double +26.8 [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. @@ -10271,7 +10553,7 @@ overload. <p><b>Proposed resolution:</b></p> <p> -Change 26.7 [c.math], paragraph 10, +Change 26.8 [c.math], paragraph 10, </p> <blockquote><pre><del>float</del> <ins>int</ins> ilogb(float); @@ -10293,13 +10575,13 @@ Change 26.7 [c.math], paragraph 10, <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>Section:</b> 27.7.1.2.3 [istream::extractors], 27.7.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>Opened:</b> 2007-02-17 <b>Last modified:</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#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 +There already exist two active DR's for the wording of 27.7.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> @@ -10349,7 +10631,7 @@ 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 +I would like to add that its output counterpart in 27.7.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 @@ -10365,7 +10647,7 @@ compared to input:: <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. +an exception will be caught compared to 27.7.1.2.3 [istream::extractors]/14. </p> <p> @@ -10390,7 +10672,7 @@ imply that such an exception *should* be caught before. <p><b>Proposed resolution:</b></p> <p> -(a) In 27.6.1.2.3 [istream::extractors]/15 (N2134) change the sentence +(a) In 27.7.1.2.3 [istream::extractors]/15 (N2134) change the sentence </p> <blockquote><p> @@ -10405,7 +10687,7 @@ caught exception is rethrown. </p></blockquote> <p> -(b) In 27.6.2.6.3 [ostream.inserters]/8 (N2134) change the sentence: +(b) In 27.7.2.6.3 [ostream.inserters]/8 (N2134) change the sentence: </p> <blockquote> @@ -10437,14 +10719,13 @@ 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>Section:</b> 27.7.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>Opened:</b> 2007-02-18 <b>Last modified:</b> 2007-07-02</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> +The function <tt>f</tt> in para 4 (27.7.4 [ext.manip]) references an unknown <tt>strm</tt> in the following line: </p> @@ -10454,7 +10735,7 @@ in the following line: <p><b>Proposed resolution:</b></p> <p> -Change 27.6.4 [ext.manip], p4: +Change 27.7.4 [ext.manip], p4: </p> <blockquote><pre>mg.get(Iter(str.rdbuf()), Iter(), intl, str<del>m</del>, err, mon); @@ -10472,8 +10753,8 @@ Oxford: Editorial. <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>Section:</b> 27.9.1.9 [ifstream.members], 27.9.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>Opened:</b> 2007-02-20 <b>Last modified:</b> 2007-07-02</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> @@ -10520,7 +10801,7 @@ they where needed for that time). <p><b>Proposed resolution:</b></p> <p> -In 27.8.1.9 [ifstream.members], remove footnote: +In 27.9.1.9 [ifstream.members], remove footnote: </p> <blockquote><p> @@ -10528,7 +10809,7 @@ In 27.8.1.9 [ifstream.members], remove footnote: </p></blockquote> <p> -In 27.8.1.13 [ofstream.members], remove footnote: +In 27.9.1.13 [ofstream.members], remove footnote: </p> <blockquote><p> @@ -10542,17 +10823,17 @@ In 27.8.1.13 [ofstream.members], remove footnote: <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>Section:</b> 28.11 [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>Opened:</b> 2007-02-26 <b>Last modified:</b> 2008-03-12</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 +According to the description given in 28.11 [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 +Comparing the provided operations from 28.11 [re.results]/3 with the sequence/container tables 80 and 81 one recognizes the following missing operations: </p> @@ -10598,7 +10879,7 @@ should be added according to tables 80/81. <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] +Add the following members to the <tt>match_results</tt> synopsis after <tt>end()</tt> in 28.11 [re.results] para 3: </p> @@ -10607,7 +10888,7 @@ const_iterator cend() const; </pre></blockquote> <p> -In section 28.10.3 [re.results.acc] change: +In section 28.11.3 [re.results.acc] change: </p> <blockquote> @@ -10649,12 +10930,12 @@ Bellevue: Proposed wording now in the WP. <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>Section:</b> 28.12.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>Opened:</b> 2007-02-26 <b>Last modified:</b> 2007-07-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 +28.12.3 [re.alg.search]/5 declares </p> <blockquote><pre>template <class iterator, class charT, class traits> @@ -10668,7 +10949,7 @@ bool regex_search(iterator first, iterator last, 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: +28.5 [re.syn], which says: </p> <blockquote><pre>template <class BidirectionalIterator, class charT, class traits> @@ -10681,7 +10962,7 @@ bool regex_search(BidirectionalIterator first, BidirectionalIterator last, <p><b>Proposed resolution:</b></p> <p> -In 28.11.3 [re.alg.search]/5 replace all three occurences of param "iterator" with +In 28.12.3 [re.alg.search]/5 replace all three occurences of param "iterator" with "BidirectionalIterator" </p> @@ -10709,12 +10990,12 @@ 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>Section:</b> 28.13.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>Opened:</b> 2007-03-03 <b>Last modified:</b> 2007-07-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> -In 28.12.1.1 [re.regiter.cnstr]/2 the effects paragraph starts with: +In 28.13.1.1 [re.regiter.cnstr]/2 the effects paragraph starts with: </p> <blockquote> @@ -10744,7 +11025,7 @@ fix. <p><b>Proposed resolution:</b></p> <p> -In 28.12.1.1 [re.regiter.cnstr]/2 change the above quoted part by +In 28.13.1.1 [re.regiter.cnstr]/2 change the above quoted part by </p> <blockquote><p> @@ -10763,13 +11044,13 @@ constructor sets <tt>*this</tt> to the end-of-sequence iterator. <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>Section:</b> 28.13.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>Opened:</b> 2007-03-03 <b>Last modified:</b> 2007-07-02</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 +In 28.13.2.1 [re.tokiter.cnstr]/1+2 both the constructor declaration and the following text shows some obvious typos: </p> <p> @@ -10819,7 +11100,7 @@ by the parameter "m". <p><b>Proposed resolution:</b></p> <p> -Change 28.12.2.1 [re.tokiter.cnstr]/1: +Change 28.13.2.1 [re.tokiter.cnstr]/1: </p> <blockquote><pre>template <std::size_t N> regex_token_iterator(BidirectionalIterator a, BidirectionalIterator b, @@ -10830,7 +11111,7 @@ Change 28.12.2.1 [re.tokiter.cnstr]/1: </pre></blockquote> <p> -Change 28.12.2.1 [re.tokiter.cnstr]/2: +Change 28.13.2.1 [re.tokiter.cnstr]/2: </p> <blockquote><p> @@ -10844,7 +11125,7 @@ pointed to by the iterator range <tt>[&submatches, &submatches + </p></blockquote> <p> -Change 28.12.2.1 [re.tokiter.cnstr]/3: +Change 28.13.2.1 [re.tokiter.cnstr]/3: </p> <blockquote><p> @@ -10866,7 +11147,7 @@ constructor sets <tt>*this</tt> to an end-of-sequence iterator. <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> + <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2007-03-08 <b>Last modified:</b> 2008-02-25</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> @@ -10951,13 +11232,13 @@ Suggest a formal paper rather than a defect report is the correct way to proceed <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>Section:</b> 26.5.1 [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>Opened:</b> 2007-03-08 <b>Last modified:</b> 2007-07-02</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 +26.5.1 [rand.synopsis] the header <tt><random></tt> synopsis contains an unreasonable closing curly brace inside the <tt>subtract_with_carry_engine</tt> declaration. </p> @@ -10965,7 +11246,7 @@ contains an unreasonable closing curly brace inside the <p><b>Proposed resolution:</b></p> <p> -Change the current declaration in 26.4.2 [rand.synopsis] +Change the current declaration in 26.5.1 [rand.synopsis] </p> <blockquote><pre>template <class UIntType, size_t w<del>}</del>, size_t s, size_t r> @@ -10983,12 +11264,12 @@ Pete: Recommends editorial. <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>Section:</b> 17.6.2.2 [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>Opened:</b> 2007-03-14 <b>Last modified:</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#NAD">NAD</a> status.</p> <p><b>Discussion:</b></p> <p> -17.4.2.1 [using.headers] states: +17.6.2.2 [using.headers] states: </p> <blockquote><p> @@ -11079,13 +11360,13 @@ 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>Section:</b> 20.7 [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>Opened:</b> 2007-03-19 <b>Last modified:</b> 2007-08-05</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] +The header <tt><functional></tt> synopsis in 20.7 [function.objects] contains the following two free comparison operator templates for the <tt>function</tt> class template </p> @@ -11099,7 +11380,7 @@ void operator!=(const function<Function1>&, const function<Function <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 +template (see 20.7.16.2 [func.wrap.func] and [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> @@ -11108,7 +11389,7 @@ would lead to an ODR violation of the user. <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]) +the header <tt><functional></tt> synopsis (20.7 [function.objects]) </p> <blockquote><pre><del>template<class Function1, class Function2> @@ -11130,14 +11411,14 @@ 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>Section:</b> 22.4.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>Opened:</b> 2007-04-05 <b>Last modified:</b> 2007-07-25</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 +From Section 22.4.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. @@ -11229,7 +11510,7 @@ to remain intact when a failure occurs. <p><b>Proposed resolution:</b></p> <p> -Change 22.2.2.1.2 [facet.num.get.virtuals]: +Change 22.4.2.1.2 [facet.num.get.virtuals]: </p> <blockquote> @@ -11258,17 +11539,18 @@ 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>Section:</b> 17.5.1.4 [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>Opened:</b> 2007-04-16 <b>Last modified:</b> 2009-05-01</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#structure.specifications">active issues</a> in [structure.specifications].</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 +17.5.1.4 [structure.specifications] para 5 says </p> <blockquote><p> --5- Complexity requirements specified in the library +-5- Complexity requirements specified in the library clauses are upper bounds, and implementations that provide better complexity guarantees satisfy the requirements. </p></blockquote> @@ -11281,14 +11563,14 @@ objection has been raised: <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 +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 +formulae, we regard all the complexity requirements as subject to a "fudge factor" without any intrinsic upper bound. </p></blockquote> <p> -[Plum ref +[Plum ref _23213Y31 etc] </p> @@ -11307,14 +11589,707 @@ identified, and big-O notation always involves constant factors. <hr> +<h3><a name="670"></a>670. <tt>money_base::pattern</tt> and <tt>space</tt></h3> +<p><b>Section:</b> 22.4.6.3 [locale.moneypunct] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> + <b>Submitter:</b> Thomas Plum <b>Opened:</b> 2007-04-16 <b>Last modified:</b> 2008-09-22</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#836">836</a></p> +<p><b>Discussion:</b></p> +<p> +22.4.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.4.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> + + + + + +<hr> +<h3><a name="676"></a>676. Moving the unordered containers</h3> +<p><b>Section:</b> 23.5 [unord] <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> Howard Hinnant <b>Opened:</b> 2007-05-05 <b>Last modified:</b> 2008-09-26</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%20Editorial">NAD Editorial</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.5 [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.5.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.5.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.5.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.5.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.5.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.5.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.5.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.5.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.5.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.5.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.5.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.5.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.5.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> + +<p><b>Rationale:</b></p> +<p><i>[ +San Francisco: +]</i></p> + + +<blockquote> +Solved by +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2776.pdf">N2776</a>. +</blockquote> + + + + + + +<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>Section:</b> 28.13.2 [re.tokiter] <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> Eric Niebler <b>Opened:</b> 2007-06-02 <b>Last modified:</b> 2009-03-09</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>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.12.2 [re.tokiter], p3 says: +28.13.2 [re.tokiter], p3 says: </p> <blockquote> <p> @@ -11357,13 +12332,13 @@ Yep, looks like a typo/administrative fix to me. <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>Section:</b> 28.11 [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>Opened:</b> 2007-05-27 <b>Last modified:</b> 2008-03-12</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 +In 28.5 [re.syn] of N2284, two template functions are declared here: </p> <blockquote><pre>// 28.10, class template match_results: @@ -11405,7 +12380,7 @@ Kona (2007): Bill and Pete to add minor wording to that proposed in <p><b>Proposed resolution:</b></p> <p> -Add a new section after 28.10.6 [re.results.swap], which reads: +Add a new section after 28.11.6 [re.results.swap], which reads: </p> <p> 28.10.7 match_results non-member functions. @@ -11458,13 +12433,13 @@ Bellevue: Proposed wording now in WP. <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>Section:</b> 20.8.12.2.4 [unique.ptr.single.observers], 20.8.13.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>Opened:</b> 2007-06-14 <b>Last modified:</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#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 +five places. In three of those places (20.7.16.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> @@ -11492,8 +12467,8 @@ makes it irrelevant. <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: +of 20.8.12.2.4 [unique.ptr.single.observers] paragraph 11 and +20.8.13.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>. @@ -11510,13 +12485,13 @@ Kona (2007): Uncertain if <tt>nullptr</tt> will address this issue. <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>Section:</b> 26.8 [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>Opened:</b> 2007-06-10 <b>Last modified:</b> 2007-07-25</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]: +Quoting the latest draft (n2135), 26.8 [c.math]: </p> <blockquote> @@ -11534,7 +12509,7 @@ Shouldn't <tt>abs(long long)</tt> have <tt>long long</tt> as return type? <p><b>Proposed resolution:</b></p> <p> -Change 26.7 [c.math]: +Change 26.8 [c.math]: </p> <blockquote><pre><ins>long </ins>long abs(long long); // llabs() </pre></blockquote> @@ -11549,9 +12524,8 @@ 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>Section:</b> 19.5 [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>Opened:</b> 2007-06-24 <b>Last modified:</b> 2008-01-06</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> @@ -11560,12 +12534,12 @@ 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 +(section 19.5 [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 +<tt>std::invalid_argument</tt>, see 19.2 [std.exceptions]/p.3. This clash makes e.g. the following snippet invalid: </p> @@ -11611,9 +12585,172 @@ Fixed by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2422. <hr> +<h3><a name="704"></a>704. MoveAssignable requirement for container value type overly strict</h3> +<p><b>Section:</b> 23.2 [container.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> Howard Hinnant <b>Opened:</b> 2007-05-20 <b>Last modified:</b> 2008-09-26</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%20Editorial">NAD Editorial</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> + + + +<p><b>Rationale:</b></p> +<p><i>[ +post San Francisco: +]</i></p> + + +<blockquote> +Solved by +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2776.pdf">N2776</a>. +</blockquote> + + + + + + +<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>Section:</b> 18.8.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>Opened:</b> 2007-07-20 <b>Last modified:</b> 2008-02-25</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> @@ -11672,15 +12809,15 @@ implementation details. <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>Section:</b> 26.6.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> Daniel Krügler <b>Opened:</b> 2007-08-27 <b>Last modified:</b> 2008-09-22</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>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> 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 +the section 26.6.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 @@ -11690,7 +12827,7 @@ guarantees should be extended to the const overload case. <p><b>Proposed resolution:</b></p> <p> -Change 26.5.2.3 [valarray.access]: +Change 26.6.2.3 [valarray.access]: </p> <blockquote> @@ -11731,11 +12868,114 @@ of that array ends, whichever happens first. <hr> +<h3><a name="724"></a>724. <tt>DefaultConstructible</tt> is not defined</h3> +<p><b>Section:</b> X [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> Pablo Halpern <b>Opened:</b> 2007-09-12 <b>Last modified:</b> 2008-09-23</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 <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 X [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> + + + +<p><b>Rationale:</b></p> +<p><i>[ +San Francisco: +]</i></p> + +<blockquote> +We believe concepts will solve this problem +(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2774.pdf">N2774</a>). +</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>Section:</b> 23.2.3 [sequence.reqmts] <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>Opened:</b> 2007-09-16 <b>Last modified:</b> 2008-09-22</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#sequence.reqmts">active issues</a> in [sequence.reqmts].</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>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> Table 90: (Optional sequence container operations) states the @@ -11768,13 +13008,13 @@ Surely that's meant to be "operational semantics?" <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>Section:</b> X [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>Opened:</b> 2007-09-21 <b>Last modified:</b> 2008-02-27</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 +The 3rd table row in X [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 @@ -11793,11 +13033,11 @@ 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. +Additionally, the definition of s in X [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. +Similarly, the type of the seed in X [rand.req.adapt]/3 e) could be left unspecified. </p> <p> @@ -11818,9 +13058,9 @@ 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 +26.5.3 [rand.eng] and 26.5.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 +requirement in X [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, @@ -11855,7 +13095,7 @@ Stephan Tolksdorf adds pre-Bellevue: <blockquote> <p> -Change row 3 of table 105 "Random number engine requirements" in 26.4.1.3 [rand.req.eng]/3 +Change row 3 of table 105 "Random number engine requirements" in X [rand.req.eng]/3 </p> <blockquote> @@ -11864,7 +13104,7 @@ Creates an engine with initial state determined by </blockquote> <p> -Similarly, change 26.4.1.4 [rand.req.adapt]/3 e) +Similarly, change X [rand.req.adapt]/3 e) </p> <blockquote> @@ -11881,8 +13121,8 @@ When <tt>X::X</tt> is invoked with <del>an <tt>X::result_type</tt></del> value < <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>Section:</b> X [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>Opened:</b> 2007-09-21 <b>Last modified:</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#NAD">NAD</a> status.</p> <p><b>Discussion:</b></p> <p> @@ -11928,15 +13168,14 @@ for the proposed resolution. <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>Section:</b> 26.5.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>Opened:</b> 2007-09-21 <b>Last modified:</b> 2008-02-27</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 +discussed issue of the 26.5 [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. @@ -11953,7 +13192,7 @@ changes: <ol type="a"> <li> -Turn the interface specification of 26.4.7.1 [rand.util.seedseq]/2 into a "SeedSeq" requirement, where the +Turn the interface specification of 26.5.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). @@ -11975,8 +13214,8 @@ struct is_seed_seq<seed_seq> { static const bool value = true; } <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 +Change X [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.5.3 [rand.eng] appropriately (the actual implementation could be done using the SFINAE technique). </li> </ol> @@ -12003,9 +13242,85 @@ for the proposed resolution. <hr> +<h3><a name="732"></a>732. Defect in [rand.dist.samp.genpdf]</h3> +<p><b>Section:</b> X [rand.dist.samp.genpdf] <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> Stephan Tolksdorf <b>Opened:</b> 2007-09-21 <b>Last modified:</b> 2009-03-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#NAD%20Editorial">NAD Editorial</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> +X [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 X [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/2009/n2813.pdf">N2813</a> +for the proposed resolution. +</p> + + +<p><b>Rationale:</b></p> +Addressed by +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2836.pdf">N2836</a> "Wording Tweaks for Concept-enabled Random Number Generation in C++0X". + + + + + +<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>Section:</b> X [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>Opened:</b> 2007-09-21 <b>Last modified:</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#NAD">NAD</a> status.</p> <p><b>Discussion:</b></p> <p> @@ -12045,8 +13360,8 @@ for the proposed resolution. <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>Section:</b> 26.5.8.2.2 [rand.dist.bern.bin], 26.5.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>Opened:</b> 2007-09-21 <b>Last modified:</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#NAD">NAD</a> status.</p> <p><b>Discussion:</b></p> <p> @@ -12095,9 +13410,8 @@ for the proposed resolution. <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>Section:</b> 26.5.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>Opened:</b> 2007-09-21 <b>Last modified:</b> 2008-02-27</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> @@ -12193,7 +13507,7 @@ Stephan Tolksdorf adds pre-Bellevue: <blockquote> <p> -In 26.4.8.5.1 [rand.dist.samp.discrete]: +In 26.5.8.5.1 [rand.dist.samp.discrete]: </p> <p> @@ -12252,9 +13566,8 @@ as the weights . <i>-- end note</i>] <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>Section:</b> 26.5.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>Opened:</b> 2007-09-21 <b>Last modified:</b> 2008-02-27</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> @@ -12316,7 +13629,7 @@ Stephan Tolksdorf adds pre-Bellevue: <blockquote> <p> -In 26.4.8.5.2 [rand.dist.samp.pconst]: +In 26.5.8.5.2 [rand.dist.samp.pconst]: </p> <p> @@ -12383,9 +13696,9 @@ and change in para. 3 <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>Section:</b> 26.5.4.1 [rand.adapt.disc] <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> Stephan Tolksdorf <b>Opened:</b> 2007-09-21 <b>Last modified:</b> 2008-09-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> 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 @@ -12405,8 +13718,8 @@ for the proposed resolution. <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>Section:</b> 26.5.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>Opened:</b> 2007-09-21 <b>Last modified:</b> 2008-02-27</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> @@ -12445,8 +13758,8 @@ for the proposed resolution. <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>Section:</b> 20.8.13.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>Opened:</b> 2007-09-27 <b>Last modified:</b> 2008-02-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> @@ -12456,7 +13769,7 @@ The following issue was raised by Alf P. Steinbach in c.l.c++.mod: <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: +of 20.8 [memory] and 20.8.13.2.11 [util.smartptr.getdeleter] declare: </p> <blockquote><pre>template<class D, class T> D* get_deleter(shared_ptr<T> const& p); @@ -12471,7 +13784,7 @@ 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 +synopsis 20.7.16.2 [func.wrap.func] or in 20.7.16.2.5 [func.wrap.func.targ] - do properly mirror the const-state of the owner. </p> @@ -12479,7 +13792,7 @@ properly mirror the const-state of the owner. <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 +synopsis of 20.8 [memory] and in 20.8.13.2.11 [util.smartptr.getdeleter] by one of the following alternatives (A) or (B): </p> @@ -12548,9 +13861,180 @@ Concern this is similar to confusing "pointer to const" with "a constant pointer <hr> +<h3><a name="742"></a>742. Enabling <tt>swap</tt> for proxy iterators</h3> +<p><b>Section:</b> X [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> Howard Hinnant <b>Opened:</b> 2007-10-10 <b>Last modified:</b> 2008-09-26</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> +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 X [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> + + + +<p><b>Rationale:</b></p> +<p><i>[ +post San Francisco: +]</i></p> + + +<blockquote> +Solved by +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/N2758.pdf">N2758</a>. +</blockquote> + + + + + + +<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>Section:</b> 18.8.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>Opened:</b> 2007-10-10 <b>Last modified:</b> 2008-02-25</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> @@ -12592,8 +14076,9 @@ slicing involved. <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>Section:</b> 20.6.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>Opened:</b> 2007-10-10 <b>Last modified:</b> 2009-05-01</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta.unary.prop">active issues</a> in [meta.unary.prop].</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> @@ -12606,9 +14091,9 @@ For instance, is the following (non-polymorphic) type considered abstract? </p> <blockquote><pre>struct abstract { protected: - abstract(){} - abstract( abstract const & ) {} - ~abstract() {} + abstract(){} + abstract( abstract const & ) {} + ~abstract() {} }; </pre></blockquote> <p> @@ -12628,8 +14113,8 @@ Core has clarified that the definition abstract is adequate. Issue withdrawn by <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>Section:</b> 20.8.11.2 [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>Opened:</b> 2007-10-15 <b>Last modified:</b> 2008-07-02</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> @@ -12658,7 +14143,7 @@ Core has clarified that the definition abstract is adequate. Issue withdrawn by <p> similarily for N2369, and its corresponding section -20.7.10.1 [uninitialized.copy]. +20.8.11.2 [uninitialized.copy]. </p> <p> @@ -12690,7 +14175,7 @@ specification of <tt>std::copy</tt>). 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] +17.5.1.4 [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 @@ -12706,7 +14191,7 @@ for <tt>std::copy</tt>. <p><b>Proposed resolution:</b></p> <p> -Change the wording of the return clause to say (20.7.10.1 [uninitialized.copy]): +Change the wording of the return clause to say (20.8.11.2 [uninitialized.copy]): </p> <blockquote> @@ -12732,8 +14217,8 @@ occur. <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>Section:</b> 23.3.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>Opened:</b> 2007-10-31 <b>Last modified:</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#NAD%20Editorial">NAD Editorial</a> status.</p> <p><b>Discussion:</b></p> <p> @@ -12760,7 +14245,7 @@ Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html# <p><b>Proposed resolution:</b></p> <p> -Change 23.2.5.1.1 [queue.defn]: +Change 23.3.5.1.1 [queue.defn]: </p> <blockquote><pre><del>void push(const value_type& x) { c.push_back(x); }</del> @@ -12769,7 +14254,7 @@ Change 23.2.5.1.1 [queue.defn]: </pre></blockquote> <p> -Change 23.2.5.2 [priority.queue]: +Change 23.3.5.2 [priority.queue]: </p> <blockquote><pre><del>void push(const value_type& x) { c.push_back(x); }</del> @@ -12778,7 +14263,7 @@ Change 23.2.5.2 [priority.queue]: </pre></blockquote> <p> -Change 23.2.5.2.2 [priqueue.members]: +Change 23.3.5.2.2 [priqueue.members]: </p> <blockquote> @@ -12806,7 +14291,7 @@ push_heap(c.begin(), c.end(), comp); </blockquote> <p> -Change 23.2.5.3.1 [stack.defn]: +Change 23.3.5.3.1 [stack.defn]: </p> <blockquote><pre><del>void push(const value_type& x) { c.push_back(x); }</del> @@ -12828,13 +14313,13 @@ Addressed by <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>Section:</b> 23.3.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>Opened:</b> 2007-11-04 <b>Last modified:</b> 2008-07-02</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: +In the synopsis 23.3.6 [vector], there is the signature: </p> <blockquote><pre>void insert(const_iterator position, size_type n, T&& x); @@ -12848,14 +14333,14 @@ instead of: </pre></blockquote> <p> -23.2.6.4 [vector.modifiers] is fine. +23.3.6.4 [vector.modifiers] is fine. </p> <p><b>Proposed resolution:</b></p> <p> -Change the synopsis in 23.2.6 [vector]: +Change the synopsis in 23.3.6 [vector]: </p> <blockquote><pre>iterator insert(const_iterator position, const T& x); @@ -12870,8 +14355,9 @@ void insert(const_iterator position, size_type n, const T& x); <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>Section:</b> 23.2.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>Opened:</b> 2007-12-04 <b>Last modified:</b> 2008-03-12</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</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> @@ -12922,8 +14408,8 @@ For example to <tt>emplace_here</tt>, <tt>hint_emplace</tt>... <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>Section:</b> 23.2.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>Opened:</b> 2007-11-29 <b>Last modified:</b> 2008-03-12</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> @@ -12981,7 +14467,7 @@ for dubious benefit, and iterators are already constant time. <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: +Change the entry for <tt>equal_range</tt> in Table 93 (23.2.5 [unord.req]) as follows: </p> <table border="1"> <tbody><tr> @@ -13003,7 +14489,7 @@ Change the entry for <tt>equal_range</tt> in Table 93 (23.1.5 [unord.req]) as fo <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> + <b>Submitter:</b> Sylvain Pion <b>Opened:</b> 2007-12-28 <b>Last modified:</b> 2008-06-18</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> @@ -13108,7 +14594,7 @@ moved to NAD. <p><b>Proposed resolution:</b></p> <p> -Add the following rows to Table 90 "Optional sequence container operations", 23.1.3 [sequence.reqmts]: +Add the following rows to Table 90 "Optional sequence container operations", 23.2.3 [sequence.reqmts]: </p> <blockquote> @@ -13185,7 +14671,7 @@ Add the following rows to Table 90 "Optional sequence container operations", 23. </blockquote> <p> -Change the synopsis in 23.2.2 [deque]: +Change the synopsis in 23.3.2 [deque]: </p> <blockquote><pre><ins>void push_front(const T& x);</ins> @@ -13197,7 +14683,7 @@ template <class... Args> <ins>requires Constructible<T, Args&&. </pre></blockquote> <p> -Change 23.2.2.3 [deque.modifiers]: +Change 23.3.2.3 [deque.modifiers]: </p> <blockquote><pre><ins>void push_front(const T& x);</ins> @@ -13209,7 +14695,7 @@ template <class... Args> <ins>requires Constructible<T, Args&&. </pre></blockquote> <p> -Change the synopsis in 23.2.4 [list]: +Change the synopsis in 23.3.4 [list]: </p> <blockquote><pre><ins>void push_front(const T& x);</ins> @@ -13221,7 +14707,7 @@ template <class... Args> <ins>requires Constructible<T, Args&&. </pre></blockquote> <p> -Change 23.2.4.3 [list.modifiers]: +Change 23.3.4.3 [list.modifiers]: </p> <blockquote><pre><ins>void push_front(const T& x);</ins> @@ -13233,7 +14719,7 @@ template <class... Args> <ins>requires Constructible<T, Args&&. </pre></blockquote> <p> -Change the synopsis in 23.2.6 [vector]: +Change the synopsis in 23.3.6 [vector]: </p> <blockquote><pre><ins>void push_back(const T& x);</ins> @@ -13242,7 +14728,7 @@ template <class... Args> <ins>requires Constructible<T, Args&&. </pre></blockquote> <p> -Change 23.2.6.4 [vector.modifiers]: +Change 23.3.6.4 [vector.modifiers]: </p> <blockquote><pre><ins>void push_back(const T& x);</ins> @@ -13269,27 +14755,27 @@ If there is still an issue with pair, Howard should submit another issue. <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>Section:</b> 26.5.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>Opened:</b> 2008-01-14 <b>Last modified:</b> 2008-02-27</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 +26.5.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 +26.5.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. +26.5.8.1.2 [rand.dist.uni.real] <tt>uniform_real</tt>. Same issue as #2. </li> </ol> @@ -13313,8 +14799,8 @@ NAD. Withdrawn. <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>Section:</b> 30.4.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>Opened:</b> 2008-02-02 <b>Last modified:</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#NAD">NAD</a> status.</p> <p><b>Discussion:</b></p> <p> @@ -13360,7 +14846,7 @@ changing. NAD <p><b>Proposed resolution:</b></p> <p> -Change the synopsis in 30.3.3.2 [thread.lock.unique]: +Change the synopsis in 30.4.3.2 [thread.lock.unique]: </p> <blockquote><pre>template <class Mutex> @@ -13374,7 +14860,7 @@ public: </pre></blockquote> <p> -Change 30.3.3.2.3 [thread.lock.unique.mod]: +Change 30.4.3.2.3 [thread.lock.unique.mod]: </p> <blockquote><pre>mutex_type *<del>release</del> <ins>disown</ins>(); @@ -13386,8 +14872,9 @@ Change 30.3.3.2.3 [thread.lock.unique.mod]: <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>Section:</b> 20.9 [time] <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>Opened:</b> 2008-02-03 <b>Last modified:</b> 2008-09-30</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time">issues</a> in [time].</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> @@ -13512,8 +14999,8 @@ Addressed by <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>Section:</b> X [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>Opened:</b> 2008-02-09 <b>Last modified:</b> 2008-02-27</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> @@ -13542,9 +15029,8 @@ Overcome by the previous proposal. NAD mooted by resolution of <a href="http://w <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>Section:</b> 26.5.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>Opened:</b> 2008-02-09 <b>Last modified:</b> 2008-03-11</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> @@ -13587,7 +15073,7 @@ variates. <p><b>Proposed resolution:</b></p> <p> -Change synopsis in 26.4.8.5.2 [rand.dist.samp.pconst]: +Change synopsis in 26.5.8.5.2 [rand.dist.samp.pconst]: </p> <blockquote><pre>template <class RealType = double> @@ -13601,7 +15087,7 @@ public: </pre></blockquote> <p> -Change 26.4.8.5.2 [rand.dist.samp.pconst]/6: +Change 26.5.8.5.2 [rand.dist.samp.pconst]/6: </p> <blockquote><pre>vector<double> <del>densities</del> <ins>probabilities</ins>() const; @@ -13613,12 +15099,533 @@ Change 26.4.8.5.2 [rand.dist.samp.pconst]/6: <hr> +<h3><a name="793"></a>793. <tt>discrete_distribution</tt> missing constructor</h3> +<p><b>Section:</b> 26.5.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%20Editorial">NAD Editorial</a> + <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2008-02-09 <b>Last modified:</b> 2009-03-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.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%20Editorial">NAD Editorial</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> + +<p><b>Non-concept version of the proposed resolution</b></p> + +<ol> +<li> +<p> +In 26.5.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> + +<p><b>Concept version of the proposed resolution</b></p> + + +<ol> +<li> +<p> +In 26.5.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<Callable<auto, double> Func> + requires Convertible<Func::result_type, double> +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<Callable<auto, double> Func> + requires Convertible<Func::result_type, double> +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>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> + + + +<p><b>Rationale:</b></p> +Addressed by +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2836.pdf">N2836</a> "Wording Tweaks for Concept-enabled Random Number Generation in C++0X". + + + + + +<hr> +<h3><a name="794"></a>794. <tt>piecewise_constant_distribution</tt> missing constructor</h3> +<p><b>Section:</b> 26.5.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%20Editorial">NAD Editorial</a> + <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2008-02-09 <b>Last modified:</b> 2009-03-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.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%20Editorial">NAD Editorial</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-closed.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-closed.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> + +<p><b>Non-concept version of the proposed resolution</b></p> + +<ol> +<li> +<p> +In 26.5.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>Note:</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. <i>-- end note</i>] + </p> +</blockquote> +</blockquote> +</li> +</ol> + +<p><b>Concept version of the proposed resolution</b></p> + +<ol> +<li> +<p> +In 26.5.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<Callable<auto, RealType> Func> + requires Convertible<Func::result_type, double> +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<Callable<auto, RealType> Func> + requires Convertible<Func::result_type, double> +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> +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>Note:</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. <i>-- end note</i>] + </p> +</blockquote> +</blockquote> +</li> +</ol> + + + +<p><b>Rationale:</b></p> +Addressed by +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2836.pdf">N2836</a> "Wording Tweaks for Concept-enabled Random Number Generation in C++0X". + + + + + +<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>Section:</b> X [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>Opened:</b> 2008-02-09 <b>Last modified:</b> 2008-03-11</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>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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 @@ -13631,7 +15638,7 @@ Stephan Tolksdorf notes: <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>. +This appears to be a duplicate of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#732">732</a>. </blockquote> @@ -13644,8 +15651,8 @@ This appears to be a duplicate of <a href="http://www.open-std.org/jtc1/sc22/wg2 <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>Section:</b> 26.5.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>Opened:</b> 2008-02-09 <b>Last modified:</b> 2008-02-27</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> @@ -13668,7 +15675,7 @@ Submitter withdraws defect. <p><b>Proposed resolution:</b></p> <p> -Change 26.4.5 [rand.predef]/p5: +Change 26.5.5 [rand.predef]/p5: </p> <blockquote> @@ -13688,8 +15695,8 @@ object of type <tt>ranlux48_base</tt> shall produce the value <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>Section:</b> 26.5.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>Opened:</b> 2008-02-09 <b>Last modified:</b> 2008-02-27</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> @@ -13711,7 +15718,7 @@ Submitter withdraws defect. <p><b>Proposed resolution:</b></p> <p> -Change 26.4.5 [rand.predef]/p6: +Change 26.5.5 [rand.predef]/p6: </p> <blockquote> @@ -13731,8 +15738,8 @@ object of type <tt>ranlux48</tt> shall produce the value <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>Section:</b> 26.5.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>Opened:</b> 2008-02-18 <b>Last modified:</b> 2008-03-11</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> @@ -13748,7 +15755,7 @@ 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 +26.5.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 @@ -13761,7 +15768,7 @@ 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 +I propose that a paragraph or footnote is added to 26.5.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 @@ -13801,7 +15808,7 @@ Revisted: Agree that the fact that there is no practical difference means that n <p><b>Proposed resolution:</b></p> <p> -In 26.4.3.2 [rand.eng.mers]: +In 26.5.3.2 [rand.eng.mers]: </p> <blockquote> @@ -13831,9 +15838,94 @@ The textual representation of <tt>x<sub>i</sub></tt> consists of the values of <hr> +<h3><a name="800"></a>800. Issues in 26.4.7.1 [rand.util.seedseq](6)</h3> +<p><b>Section:</b> 26.5.7.1 [rand.util.seedseq] <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> Stephan Tolksdorf <b>Opened:</b> 2008-02-18 <b>Last modified:</b> 2009-03-09</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%20Editorial">NAD Editorial</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-closed.html#803">803</a> is accepted. +</p> + + + +<p><b>Proposed resolution:</b></p> +<p> +Replace 26.5.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> + + +<p><b>Rationale:</b></p> +Addressed by +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2836.pdf">N2836</a> "Wording Tweaks for Concept-enabled Random Number Generation in C++0X". + + + + + +<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>Section:</b> 26.5.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>Opened:</b> 2008-02-20 <b>Last modified:</b> 2008-03-17</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> @@ -13845,7 +15937,7 @@ The 10,000<sup>th</sup> value returned by <tt>knuth_b</tt> is supposed to be <p><b>Proposed resolution:</b></p> <p> -Change 26.4.5 [rand.predef]/p8: +Change 26.5.5 [rand.predef]/p8: </p> <blockquote> @@ -13869,9 +15961,386 @@ Bellevue: Submitter withdraws defect. "We got the wrong value for entirely the r <hr> +<h3><a name="803"></a>803. Simplification of <tt>seed_seq::seq_seq</tt></h3> +<p><b>Section:</b> 26.5.7.1 [rand.util.seedseq] <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> Charles Karney <b>Opened:</b> 2008-02-22 <b>Last modified:</b> 2009-03-09</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%20Editorial">NAD Editorial</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.5.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-closed.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-closed.html#800">800</a>) +</p> +</blockquote> + + + +<p><b>Proposed resolution:</b></p> +<p> +Change 26.5.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> + + +<p><b>Rationale:</b></p> +Addressed by +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2836.pdf">N2836</a> "Wording Tweaks for Concept-enabled Random Number Generation in C++0X". + + + + + +<hr> +<h3><a name="811"></a>811. <tt>pair</tt> of pointers no longer works with literal 0</h3> +<p><b>Section:</b> 20.3.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> Doug Gregor <b>Opened:</b> 2008-03-14 <b>Last modified:</b> 2008-09-26</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#pairs">active issues</a> in [pairs].</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> +<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><i>[ +San Francisco: +]</i></p> + + +<blockquote> +<p> +Suggested to resolve using pass-by-value for that case. +</p> +<p> +Side question: Should pair interoperate with tuples? Can construct a +tuple of a pair, but not a pair from a two-element tuple. +</p> +<p> +Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#885">885</a>. +</p> +</blockquote> + + + +<p><b>Proposed resolution:</b></p> +<p> +</p> + + +<p><b>Rationale:</b></p> +<p><i>[ +San Francisco: +]</i></p> + + +<blockquote> +Solved by +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2770.pdf">N2770</a>. +</blockquote> + + + + + + + +<hr> +<h3><a name="812"></a>812. unsolicited multithreading considered harmful?</h3> +<p><b>Section:</b> 25.5.1 [alg.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> Paul McKenney <b>Opened:</b> 2008-02-27 <b>Last modified:</b> 2008-09-17</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> +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> + + +<p><b>Rationale:</b></p> +This is already covered by 17.6.5.6/20 in N2723. + + + + + +<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>Section:</b> 22.4.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>Opened:</b> 2008-04-07 <b>Last modified:</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#NAD">NAD</a> status.</p> <p><b>Discussion:</b></p> <p> @@ -13930,8 +16399,8 @@ This is not a part of C99. LWG suggests submitting a paper may be appropriate. <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>Section:</b> 21.2.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>Opened:</b> 2008-04-23 <b>Last modified:</b> 2008-06-19</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> @@ -13939,7 +16408,7 @@ This is not a part of C99. LWG suggests submitting a paper may be appropriate. 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>. + 21.2.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 @@ -13954,9 +16423,9 @@ This is not a part of C99. LWG suggests submitting a paper may be appropriate. <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 + In 21.2.3.1 [char.traits.specializations.char], + 21.2.3.2 [char.traits.specializations.char16_t], + 21.2.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> @@ -13970,9 +16439,358 @@ Already fixed in WP. <hr> +<h3><a name="832"></a>832. Applying constexpr to System error support</h3> +<p><b>Section:</b> 19.5 [syserr] <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>Opened:</b> 2008-05-14 <b>Last modified:</b> 2008-09-17</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">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Initialization of objects of class <tt>error_code</tt> +(19.5.2 [syserr.errcode]) and class +<tt>error_condition</tt> (19.5.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-defects.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.5.2 [syserr.errcode]) and class +<tt>error_condition</tt> (19.5.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-defects.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-defects.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-defects.html#805">805</a> has not been applied, the names in this +proposal must be adjusted accordingly. +</p> + +<p> +Change 19.5.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.5.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.5.2.2 [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.5.2.3 [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.5.2.4 [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.5.2.5 [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.5.3.2 [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.5.3.3 [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.5.3.4 [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.5.3.5 [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.5 [syserr] System error support, change "<tt>category().</tt>" to "<tt>category()-></tt>". +Appears approximately six times. +</p> + +<p> +<i>[Partially Editorial]</i> In 19.5.4 [syserr.compare] Comparison operators, +paragraphs 2 and 4, change "<tt>category.equivalent(</tt>" to +"<tt>category()->equivalent(</tt>". +</p> + +<p> +Change 19.5.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.5.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> + + + +<p><b>Rationale:</b></p> +<p><i>[ +San Francisco: +]</i></p> + + +<blockquote> +NAD because Beman said so. +</blockquote> + + + + + +<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>Section:</b> 20.3.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>Opened:</b> 2008-05-23 <b>Last modified:</b> 2008-06-18</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#pairs">active issues</a> in [pairs].</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> @@ -13987,14 +16805,14 @@ help those cases where we use it as a return or argument type). <p><b>Proposed resolution:</b></p> <p> -Change the synopsis in 20.2 [utility] to read: +Change the synopsis in 20.3 [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: +Change 20.3.3 [pairs] to read: </p> <blockquote><pre>namespace std { @@ -14013,4 +16831,1597 @@ Change 20.2.3 [pairs] to read: +<hr> +<h3><a name="841"></a>841. cstdint.syn inconsistent with C99</h3> +<p><b>Section:</b> 18.4.1 [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> Martin Sebor <b>Opened:</b> 2008-05-17 <b>Last modified:</b> 2008-09-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#NAD%20Editorial">NAD Editorial</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="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.6.7 [meta.trans.other] <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>Opened:</b> 2008-06-05 <b>Last modified:</b> 2008-09-16</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#NAD">NAD</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.6.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.6.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> + + + +<p><b>Rationale:</b></p> +2008-9-16 San Francisco: Issue pulled by author prior to being reviewed by the LWG. + + + + + +<hr> +<h3><a name="855"></a>855. capacity() and reserve() for deque?</h3> +<p><b>Section:</b> 23.3.2.2 [deque.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Hervé Brönnimann <b>Opened:</b> 2008-06-11 <b>Last modified:</b> 2008-09-22</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#NAD">NAD</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><i>[ +San Francisco: +]</i></p> + + +<blockquote> +<p> +Hans: should the Returns clause for capacity read "1 Returns: A lower +bound..." rather than "1 Returns: An upper bound..." +</p> +<p> +Howard: maybe what's needed is capacity_front and capacity_back. In +fact, I think I implemented a deque that had these members as +implementation details. +</p> +</blockquote> + + + +<p><b>Proposed resolution:</b></p> + +<p> +Add new signatures to synopsis in 23.3.2 [deque]: +</p> + +<blockquote><pre>size_type capacity() const; +bool reserve(size_type n); +</pre></blockquote> + +<p> +Add new signatures to 23.3.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.3.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> + + +<p><b>Rationale:</b></p> +Complication outweighs the benefit. + + + + + +<hr> +<h3><a name="864"></a>864. Defect in atomic wording</h3> +<p><b>Section:</b> 29.6 [atomics.types.operations] <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> Anthony Williams <b>Opened:</b> 2008-07-10 <b>Last modified:</b> 2008-09-17</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#NAD%20Editorial">NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<p> +There's an error in 29.6 [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.6 [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.6 [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.6 [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> + + + +<p><b>Rationale:</b></p> +Already fixed by the time the LWG processed it. + + + + + +<hr> +<h3><a name="870"></a>870. Do unordered containers not support function pointers for predicate/hasher?</h3> +<p><b>Section:</b> 23.2.5 [unord.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> Daniel Krügler <b>Opened:</b> 2008-08-17 <b>Last modified:</b> 2008-09-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#NAD%20Editorial">NAD Editorial</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.2.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.2.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.7 [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.2.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> + + +<p><b>Rationale:</b></p> +<p><i>[ +San Francisco: +]</i></p> + + +<blockquote> +This is fixed by +<a href="" ref="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2776.pdf">N2776</a>. +</blockquote> + + + + + + +<hr> +<h3><a name="871"></a>871. Iota's requirements on T are too strong</h3> +<p><b>Section:</b> 26.7.5 [numeric.iota] <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>Opened:</b> 2008-08-20 <b>Last modified:</b> 2008-09-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> +According to the recent WP +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2691.pdf">N2691</a>, +26.7.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.7.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> + + + +<p><b>Rationale:</b></p> +<p><i>[ +post San Francisco: +]</i></p> + + +<blockquote> +Issue pulled by author prior to review. +</blockquote> + + + + + + +<hr> +<h3><a name="872"></a>872. <tt>move_iterator::operator[]</tt> has wrong return type</h3> +<p><b>Section:</b> 24.5.3.2.12 [move.iter.op.index] <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>Opened:</b> 2008-08-21 <b>Last modified:</b> 2008-09-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> +<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.5.3.1 [move.iterator] and 24.5.3.2.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> + + + +<p><b>Rationale:</b></p> +<p><i>[ +San Francisco: +]</i></p> + + +<blockquote> +NAD Editorial, see +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2777.pdf">N2777</a>. +</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.5.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%20Editorial">NAD Editorial</a> + <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-08-22 <b>Last modified:</b> 2009-03-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.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%20Editorial">NAD Editorial</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-closed.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.5.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> + + +<p><b>Rationale:</b></p> +Addressed by +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2836.pdf">N2836</a> "Wording Tweaks for Concept-enabled Random Number Generation in C++0X". + + + + + +<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.5.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%20Editorial">NAD Editorial</a> + <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-08-22 <b>Last modified:</b> 2009-03-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.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%20Editorial">NAD Editorial</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-closed.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-closed.html#793">793</a>. +</p> + + +<p><b>Proposed resolution:</b></p> +<p><b>Non-concept version of the proposed resolution</b></p> + +<ol> +<li> +<p> +In 26.5.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> + +<p><b>Concept version of the proposed resolution</b></p> + +<ol> +<li> +<p> +In 26.5.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<Callable<auto, RealType> Func> + requires Convertible<Func::result_type, double> +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<Callable<auto, RealType> Func> + requires Convertible<Func::result_type, double> +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> +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> + + + +<p><b>Rationale:</b></p> +Addressed by +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2836.pdf">N2836</a> "Wording Tweaks for Concept-enabled Random Number Generation in C++0X". + + + + + +<hr> +<h3><a name="892"></a>892. Forward_list issues...</h3> +<p><b>Section:</b> 23.3.3.5 [forwardlist.ops] <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> Ed Smith-Rowland <b>Opened:</b> 2008-09-15 <b>Last modified:</b> 2009-03-09</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#forwardlist.ops">active issues</a> in [forwardlist.ops].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forwardlist.ops">issues</a> in [forwardlist.ops].</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 was looking at the latest draft on <tt>forward_list</tt>. Especially the splice methods. +</p> +<p> +The first one splices a whole list after a given iterator in <tt>this</tt>. The name is <tt>splice_after</tt>. +I think in 23.3.3.5 [forwardlist.ops] paragraph 40 +change: +</p> +<blockquote> +<i>Effect:</i> Insert the contents of <tt>x</tt> <del>before</del> <ins>after</ins> <tt>position</tt>, ... +</blockquote> + +<p> +A deeper issue involves the complexity. <tt>forward_list</tt> has no <tt>size</tt> and we +don't know when we've reached the end except to walk up to it. To +splice we would need to hook the end of the source list to the item +after <tt>position</tt> in this list. This would involve walking length of the +source list until we got to the last dereference-able element in source. +There's no way we could do this in O(1) unless we stored a bogus end in +<tt>forward_list</tt>. +</p> +<p> +OTOH, the last version of <tt>splice_after</tt> with iterator ranges we could do +in O(1) because we know how to hook the end of the source range to ... +</p> +<p> +Unless I'm misconceiving the whole thing. Which is possible. I'll look at it again. +</p> +<p> +I'm pretty sure about the first part though. +</p> + +<p><i>[ +San Francisco: +]</i></p> + + +<blockquote> +<p> +This issue is more complicated than it looks. +</p> +<p> +paragraph 47: replace each <tt>(first, last) with (first, last]</tt> +</p> +<p> +add a statement after paragraph 48 that complexity is O(1) +</p> +<p> +remove the complexity statement from the first overload of splice_after +</p> +<p> +We may have the same problems with other modifiers, like erase_after. +Should it require that all iterators in the range (position, last] be +dereferenceable? +</p> +<p> +We do, however, like the proposed changes and consider them Editorial. +Move to NAD Editorial, Pending. Howard to open a new issue to handle the +problems with the complexity requirements. +</p> +<p> +Opened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#897">897</a>. +</p> +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +In 23.3.3.5 [forwardlist.ops] paragraph 40 +change: +</p> +<blockquote> +<i>Effect:</i> Insert the contents of <tt>x</tt> <del>before</del> <ins>after</ins> <tt>position</tt>, ... +</blockquote> + + + + + +<hr> +<h3><a name="905"></a>905. Mutex specification questions</h3> +<p><b>Section:</b> 30.4.1.1 [thread.mutex.class] <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>Opened:</b> 2008-09-18 <b>Last modified:</b> 2009-03-22</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.mutex.class">active issues</a> in [thread.mutex.class].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.mutex.class">issues</a> in [thread.mutex.class].</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#893">893</a></p> +<p><b>Discussion:</b></p> +<p> +A few questions on the current WP, +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>: +</p> +<p> +30.4.1 [thread.mutex.requirements]/24 says an expression +<tt>mut.unlock()</tt> "Throws: Nothing." I'm assuming that, per 17.6.3.11 [res.on.required], errors that violate the precondition "The +calling thread shall own the mutex" opens the door for throwing an +exception anyway, such as to report unbalanced unlock operations and +unlocking from a thread that does not have ownership. Right? +</p> +<p> +30.4.1.1 [thread.mutex.class]/3 (actually numbered paragraph "27" +in the WP; this is just a typo I think) says +</p> +<blockquote> +<p> +The behavior of a program is undefined if: +</p> +<ul> +<li>it destroys a <tt>mutex</tt> object owned by any thread,</li> +<li>a thread that owns a <tt>mutex</tt> object calls <tt>lock()</tt> or <tt>try_lock()</tt> on that object, or</li> +<li>a thread terminates while owning a <tt>mutex</tt> object.</li> +</ul> +</blockquote> + +<p> +As already discussed, I think the second bullet should be removed, and +such a <tt>lock()</tt> or <tt>try_lock()</tt> should fail with an +exception or returning <tt>false</tt>, respectively. +</p> +<p> +A potential addition to the list would be +</p> +<ul> +<li>a thread unlocks a <tt>mutex</tt> it does not have ownership of.</li> +</ul> +<p> +but without that the status quo text endorses the technique of the +program logically transferring ownership of a mutex to another thread +with correctness enforced by programming discipline. Was that intended? +</p> + +<p><i>[ +Summit: +]</i></p> + + +<blockquote> +<p> +Two resolutions: "not a defect" and "duplicate", as follows: +</p> +<ul> +<li> +30.4.1 [thread.mutex.requirements]/24: NAD. If the precondition +fails the program has undefined behaviour and therefore an +implementation may throw an exception already. +</li> +<li> +30.4.1.1 [thread.mutex.class]/3 bullet 2: Already addressed by issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#893">893</a>. +</li> +<li> +30.4.1.1 [thread.mutex.class]/3 proposed addition: NAD. This is +already covered by the mutex requirements, which have ownership as a +Precondition. +</li> +</ul> +</blockquote> + + +<p><b>Proposed resolution:</b></p> + + + + + + +<hr> +<h3><a name="937"></a>937. Atomics for standard typedef types</h3> +<p><b>Section:</b> 29 [atomics] <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> Clark Nelson <b>Opened:</b> 2008-12-05 <b>Last modified:</b> 2009-05-23</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#atomics">active issues</a> in [atomics].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics">issues</a> in [atomics].</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><b>Addresses US 89</b></p> + +<blockquote> +<p> +The types in the table "Atomics for standard typedef types" should be +typedefs, not classes. These semantics are necessary for compatibility +with C. +</p> + +<p> +Change the classes to typedefs. +</p> +</blockquote> + +<p> +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2427.html">N2427</a> +specified different requirements for atomic analogs of fundamental +integer types (such as <tt>atomic_int</tt>) and for atomic analogs of <tt><cstdint></tt> +typedefs (such as <tt>atomic_size_t</tt>). Specifically, <tt>atomic_int</tt> et al. were +specified to be distinct classes, whereas <tt>atomic_size_t</tt> et al. were +specified to be typedefs. Unfortunately, in applying +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2427.html">N2427</a> +to the WD, that distinction was erased, and the atomic analog of every <tt><cstdint></tt> +typedef is required to be a distinct class. +</p> + +<p> +It shouldn't be required that the atomic analog of every <tt><cstdint></tt> +typedef be a typedef for some fundamental integer type. After all, +<tt><cstdint></tt> is supposed to provide standard names for extended integer +types. So there was a problem in +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2427.html">N2427</a>, +which certainly could have been +interpreted to require that. But the status quo in the WD is even worse, +because it's unambiguously wrong. +</p> + +<p> +What is needed are words to require the existence of a bunch of type +names, without specifying whether they are class names or typedef names. +</p> + +<p><i>[ +Summit: +]</i></p> + + +<blockquote> +<p> +Change status to NAD, editorial. See US 89 comment notes above. +</p> +<p> +Direct the editor to turn the types into typedefs as proposed in the +comment. Paper approved by committee used typedefs, this appears to have +been introduced as an editorial change. Rationale: for compatibility +with C. +</p> +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +</p> + + + + + +<hr> +<h3><a name="942"></a>942. Atomics synopsis typo</h3> +<p><b>Section:</b> 29 [atomics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> + <b>Submitter:</b> Holger Grund <b>Opened:</b> 2008-12-19 <b>Last modified:</b> 2009-03-22</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#atomics">active issues</a> in [atomics].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics">issues</a> in [atomics].</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#880">880</a></p> +<p><b>Discussion:</b></p> + + + +<p> +I'm looking at 29 [atomics] and can't really make sense of a couple of things. +</p> +<p> +Firstly, there appears to be a typo in the <tt><cstdatomic></tt> synopsis: +</p> + +<blockquote> +<p> +The <tt>atomic_exchange</tt> overload taking an <tt>atomic_address</tt> +is missing the second parameter: +</p> + +<blockquote><pre>void* atomic_exchange(volatile atomic_address*); +</pre></blockquote> + +<p> +should be +</p> + +<blockquote><pre>void* atomic_exchange(volatile atomic_address*<ins>, void*</ins>); +</pre></blockquote> + +<p> +Note, that this is <em>not</em> covered by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#880">880</a> "Missing atomic exchange parameter", +which only talks about the <tt>atomic_bool</tt>. +</p> +</blockquote> + + + +<p><b>Proposed resolution:</b></p> +<p> +Change the synopsis in 29 [atomics]/2: +</p> + +<blockquote><pre>void* atomic_exchange(volatile atomic_address*<ins>, void*</ins>); +</pre></blockquote> + + + + + + +<hr> +<h3><a name="980"></a>980. <tt>mutex lock()</tt> missing error conditions</h3> +<p><b>Section:</b> 30.4.1 [thread.mutex.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Ion Gaztańaga <b>Opened:</b> 2009-02-07 <b>Last modified:</b> 2009-03-22</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.mutex.requirements">active issues</a> in [thread.mutex.requirements].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.mutex.requirements">issues</a> in [thread.mutex.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> +POSIX 2008 adds two return values for <tt>pthread_mutex_xxxlock()</tt>: +<tt>EOWNERDEAD</tt> (<tt>owner_dead</tt>) and <tt>ENOTRECOVERABLE</tt> +(<tt>state_not_recoverable</tt>). In the first case the mutex is locked, +in the second case the mutex is not locked. +</p> + +<p> +Throwing an exception in the first case can be incompatible with the use +of Locks, since the <tt>Lock::owns_lock()</tt> will be <tt>false</tt> when the lock is +being destroyed. +</p> + +<p> +Consider: +</p> + +<blockquote><pre>//Suppose mutex.lock() throws "owner_dead" +unique_lock ul(&mutex); +//mutex left locked if "owner_dead" is thrown +</pre></blockquote> + +<p> +Throwing an exception with <tt>owner_dead</tt> might be also undesirable if +robust-mutex support is added to C++ and the user has the equivalent of +<tt>pthread_mutex_consistent()</tt> to notify the user has fixed the corrupted +data and the mutex state should be marked consistent. +</p> + +<ol> +<li> +For <tt>state_not_recoverable</tt> add it to the list of Error conditions: +</li> +<li> +For <tt>owner_dead</tt>, no proposed resolution. +</li> +</ol> + +<p><i>[ +Summit: +]</i></p> + + +<blockquote> +Not a defect. Handling these error conditions is an implementation +detail and must be handled below the C++ interface. +</blockquote> + + + +<p><b>Proposed resolution:</b></p> + +<p> +Add to 30.4.1 [thread.mutex.requirements], p12: +</p> + +<blockquote> +<p> +-12- <i>Error conditions:</i> +</p> + +<ul> +<li> +<tt>operation_not_permitted</tt> -- if the thread does not have the necessary permission to change +the state of the mutex. +</li> +<li> +<tt>resource_deadlock_would_occur</tt> -- if the current thread already owns the mutex and is able +to detect it. +</li> +<li> +<tt>device_or_resource_busy</tt> -- if the mutex is already locked and blocking is not possible. +</li> +<li> +<ins><tt>state_not_recoverable</tt> -- if the state protected by the mutex is not recoverable.</ins> +</li> +</ul> +</blockquote> + + + + + +<hr> +<h3><a name="1022"></a>1022. Response to UK 212</h3> +<p><b>Section:</b> 20.8.13.7 [util.dynamic.safety] <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> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-03-12</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.dynamic.safety">issues</a> in [util.dynamic.safety].</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><b>Addresses UK 212</b></p> + +<p> +The pointer-safety API is nothing to do with smart pointers, so does not +belong in 20.8.13 [util.smartptr]. In fact it is a set of language +support features are really belongs in clause 18 [language.support], with the contents declared in a header that +deals with language-support of memory management. +</p> + +<p><i>[ +Summit: +]</i></p> + + +<blockquote>Agree in principle, but not with the proposed resolution. +We believe it +belongs either a subsection of either 20 [utilities] or 20.8 [memory] +as part of the general reorganization of 20 [utilities]. The +declaration should stay in +<tt><memory></tt>. +</blockquote> + + + +<p><b>Proposed resolution:</b></p> + + + + + +<hr> +<h3><a name="1025"></a>1025. Response to UK 208</h3> +<p><b>Section:</b> 20.7.17 [unord.hash] <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> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-03-12</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord.hash">active issues</a> in [unord.hash].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.hash">issues</a> in [unord.hash].</p> +<p><b>Discussion:</b></p> + +<p><b>Addresses UK 208</b></p> + +<p> +<tt>std::hash</tt> should be implemented for much more of the standard +library. In particular for <tt>pair</tt>, <tt>tuple</tt> and all the +standard containers. +</p> + + + +<p><b>Proposed resolution:</b></p> + + + + + </body></html>
\ No newline at end of file diff --git a/libstdc++-v3/doc/html/ext/lwg-defects.html b/libstdc++-v3/doc/html/ext/lwg-defects.html index 5951a98..5dedc13 100644 --- a/libstdc++-v3/doc/html/ext/lwg-defects.html +++ b/libstdc++-v3/doc/html/ext/lwg-defects.html @@ -14,11 +14,11 @@ del {background-color:#FFA0A0} <table> <tbody><tr> <td align="left">Doc. no.</td> -<td align="left">N2728=08-0238</td> +<td align="left">N2895=09-0085</td> </tr> <tr> <td align="left">Date:</td> -<td align="left">2008-08-24</td> +<td align="left">2009-06-21</td> </tr> <tr> <td align="left">Project:</td> @@ -29,9 +29,9 @@ del {background-color:#FFA0A0} <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> +<h1>C++ Standard Library Defect Report List (Revision R65)</h1> - <p>Reference ISO/IEC IS 14882:1998(E)</p> + <p>Reference ISO/IEC IS 14882:2003(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> @@ -51,6 +51,148 @@ del {background-color:#FFA0A0} <h2>Revision History</h2> <ul> +<li>R65: +2009-06-19 pre-Frankfurt mailing. +<ul> +<li><b>Summary:</b><ul> +<li>378 open issues, up by 32.</li> +<li>765 closed issues, up by 0.</li> +<li>1143 issues total, up by 32.</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#1115">1115</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1116">1116</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1117">1117</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1118">1118</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1119">1119</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1120">1120</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1121">1121</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1122">1122</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1123">1123</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1124">1124</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1125">1125</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1126">1126</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1127">1127</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1128">1128</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1129">1129</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1130">1130</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1131">1131</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1132">1132</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1133">1133</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1134">1134</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1135">1135</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1136">1136</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1137">1137</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1138">1138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1139">1139</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1140">1140</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1141">1141</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1142">1142</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1143">1143</a>.</li> +<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1112">1112</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1113">1113</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1114">1114</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#937">937</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#696">696</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-active.html#727">727</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#900">900</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#911">911</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#916">916</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#917">917</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#920">920</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#933">933</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#935">935</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#941">941</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#947">947</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#951">951</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#953">953</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#954">954</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#955">955</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#956">956</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#977">977</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#978">978</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#985">985</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#989">989</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#996">996</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1033">1033</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1054">1054</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1056">1056</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1057">1057</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1059">1059</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1062">1062</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1068">1068</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1069">1069</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1071">1071</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1072">1072</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1076">1076</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1090">1090</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1092">1092</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1096">1096</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1098">1098</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1099">1099</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1105">1105</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1106">1106</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1108">1108</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1110">1110</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#817">817</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#971">971</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#992">992</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1004">1004</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1010">1010</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1012">1012</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1015">1015</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1019">1019</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#780">780</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#897">897</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#919">919</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#939">939</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#957">957</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#983">983</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1001">1001</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1080">1080</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1091">1091</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1093">1093</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1094">1094</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1095">1095</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1097">1097</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1102">1102</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1104">1104</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1111">1111</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#921">921</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#987">987</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1087">1087</a>.</li> +<li>Changed the following issues from New to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#568">568</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-active.html#785">785</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#903">903</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#912">912</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#918">918</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#946">946</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#995">995</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1074">1074</a>.</li> +<li>Changed the following issues from Open to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#458">458</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#644">644</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#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>.</li> +<li>Changed the following issues from Review to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#901">901</a>.</li> +<li>Changed the following issues from Tentatively Ready to Tentatively NAD: <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#988">988</a>.</li> +<li>Changed the following issues from New to Tentatively NAD Editorial: <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#862">862</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#927">927</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#945">945</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#952">952</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#969">969</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#972">972</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#973">973</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#979">979</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1058">1058</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1060">1060</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1061">1061</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1077">1077</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1101">1101</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1109">1109</a>.</li> +<li>Changed the following issues from Open to Tentatively NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#424">424</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#884">884</a>.</li> +<li>Changed the following issues from Review to Tentatively NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1023">1023</a>.</li> +<li>Changed the following issues from Open to Tentatively NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#96">96</a>.</li> +<li>Changed the following issues from New to Tentatively Ready: <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#898">898</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#906">906</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#910">910</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#913">913</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#914">914</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#915">915</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#925">925</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#974">974</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#976">976</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#981">981</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#982">982</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#984">984</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#990">990</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#998">998</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#999">999</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1063">1063</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1067">1067</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1070">1070</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1073">1073</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1100">1100</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1103">1103</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1107">1107</a>.</li> +<li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#814">814</a>.</li> +<li>Changed the following issues from Review to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#899">899</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#907">907</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#909">909</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#934">934</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#938">938</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#940">940</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#943">943</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#950">950</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#965">965</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#970">970</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#975">975</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#986">986</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#991">991</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#993">993</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#994">994</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#997">997</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1002">1002</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1006">1006</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1011">1011</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1013">1013</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1014">1014</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1021">1021</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1024">1024</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1037">1037</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1038">1038</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1039">1039</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1040">1040</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1044">1044</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1045">1045</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1065">1065</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1066">1066</a>.</li> +</ul></li> +</ul> +</li> +<li>R64: +2009-05-01 mid-term mailing. +<ul> +<li><b>Summary:</b><ul> +<li>346 open issues, up by 19.</li> +<li>765 closed issues, up by 0.</li> +<li>1111 issues total, up by 19.</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#1093">1093</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1094">1094</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1095">1095</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1096">1096</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1097">1097</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1098">1098</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1099">1099</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1100">1100</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1101">1101</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1102">1102</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1103">1103</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1104">1104</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1105">1105</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1106">1106</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1107">1107</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1108">1108</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1109">1109</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1110">1110</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1111">1111</a>.</li> +<li>Changed the following issues from DR to CD1: <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-defects.html#386">386</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#406">406</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#409">409</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#413">413</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#434">434</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#438">438</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#444">444</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#445">445</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#455">455</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#457">457</a>, <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-defects.html#469">469</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#533">533</a>.</li> +<li>Changed the following issues from Review to New: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1070">1070</a>.</li> +</ul></li> +</ul> +</li> +<li>R63: +2009-03-20 post-Summit mailing. +<ul> +<li><b>Summary:</b><ul> +<li>327 open issues, up by 96.</li> +<li>765 closed issues, up by 14.</li> +<li>1092 issues total, up by 110.</li> +</ul></li> +<li><b>Details:</b><ul> +<li>Added the following NAD Editorial issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1022">1022</a>.</li> +<li>Added the following NAD Future issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1025">1025</a>.</li> +<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#983">983</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#984">984</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#985">985</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#989">989</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#990">990</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#995">995</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#996">996</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#998">998</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#999">999</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1001">1001</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1033">1033</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1054">1054</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1056">1056</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1057">1057</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1058">1058</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1059">1059</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1060">1060</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1061">1061</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1062">1062</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1063">1063</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1067">1067</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1068">1068</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1069">1069</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1071">1071</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1072">1072</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1073">1073</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1074">1074</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1076">1076</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1077">1077</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1080">1080</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1090">1090</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1091">1091</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1092">1092</a>.</li> +<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#987">987</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1000">1000</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1007">1007</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1008">1008</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1016">1016</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1017">1017</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1018">1018</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1020">1020</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1026">1026</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1027">1027</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1028">1028</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1029">1029</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1030">1030</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1031">1031</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1032">1032</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1034">1034</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1035">1035</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1036">1036</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1041">1041</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1042">1042</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1046">1046</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1048">1048</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1051">1051</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1052">1052</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1053">1053</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1055">1055</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1064">1064</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1075">1075</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1078">1078</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1079">1079</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1081">1081</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1082">1082</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1083">1083</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1084">1084</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1085">1085</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1086">1086</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1087">1087</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1088">1088</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1089">1089</a>.</li> +<li>Added the following Review issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#986">986</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#991">991</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#992">992</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#993">993</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#994">994</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#997">997</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1002">1002</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1003">1003</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1004">1004</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1005">1005</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1006">1006</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1009">1009</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1010">1010</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1011">1011</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1012">1012</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1013">1013</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1014">1014</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1015">1015</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1019">1019</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1021">1021</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1023">1023</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1024">1024</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1037">1037</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1038">1038</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1039">1039</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1040">1040</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1043">1043</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1044">1044</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1045">1045</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1047">1047</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1049">1049</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1050">1050</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1065">1065</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1066">1066</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1070">1070</a>.</li> +<li>Added the following Tentatively Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#988">988</a>.</li> +<li>Changed the following issues from New to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#905">905</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#942">942</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#980">980</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#874">874</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#875">875</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#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#793">793</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#794">794</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#800">800</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#683">683</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#892">892</a>.</li> +<li>Changed the following issues from Ready to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#803">803</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#466">466</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#111">111</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#149">149</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#219">219</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#880">880</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#891">891</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#893">893</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#902">902</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#908">908</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#921">921</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#923">923</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#924">924</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#926">926</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#930">930</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#936">936</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#944">944</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#958">958</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#959">959</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#960">960</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#961">961</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#962">962</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#963">963</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#964">964</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#966">966</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#967">967</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#968">968</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#788">788</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#937">937</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#879">879</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#899">899</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#901">901</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#907">907</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#909">909</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#929">929</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#934">934</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#938">938</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#940">940</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#943">943</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#950">950</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#965">965</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#970">970</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#971">971</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#975">975</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#817">817</a>.</li> +<li>Changed the following issues from New to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#904">904</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#922">922</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#928">928</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#931">931</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#932">932</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#948">948</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#949">949</a>.</li> +<li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#890">890</a>.</li> +<li>Changed the following issues from Review to Tentatively Ready: <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-active.html#822">822</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#869">869</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#878">878</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#888">888</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#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#821">821</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#866">866</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#894">894</a>.</li> +</ul></li> +</ul> +</li> +<li>R62: +2009-02-06 pre-Summit mailing. +<ul> +<li><b>Summary:</b><ul> +<li>231 open issues, up by 44.</li> +<li>751 closed issues, up by 0.</li> +<li>982 issues total, up by 44.</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#939">939</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#940">940</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#941">941</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#942">942</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#943">943</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#944">944</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#945">945</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#946">946</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#947">947</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#948">948</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#949">949</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#950">950</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#951">951</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#952">952</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#953">953</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#954">954</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#955">955</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#956">956</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#957">957</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#958">958</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#959">959</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#960">960</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#961">961</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#962">962</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#963">963</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#964">964</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#965">965</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#966">966</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#967">967</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#968">968</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#969">969</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#970">970</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#971">971</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#972">972</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#973">973</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#974">974</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#975">975</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#976">976</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#977">977</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#978">978</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#979">979</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#980">980</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#981">981</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#982">982</a>.</li> +</ul></li> +</ul> +</li> +<li>R61: +2008-12-05 mid-term mailing. +<ul> +<li><b>Summary:</b><ul> +<li>187 open issues, up by 20.</li> +<li>751 closed issues, up by 0.</li> +<li>938 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-active.html#919">919</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#920">920</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#921">921</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#922">922</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#923">923</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#924">924</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#925">925</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#926">926</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#927">927</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#928">928</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#929">929</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#930">930</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#931">931</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#932">932</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#933">933</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#934">934</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#935">935</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#936">936</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#937">937</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#938">938</a>.</li> +</ul></li> +</ul> +</li> +<li>R60: +2008-10-03 post-San Francisco mailing. +<ul> +<li><b>Summary:</b><ul> +<li>167 open issues, down by 25.</li> +<li>751 closed issues, up by 65.</li> +<li>918 issues total, up by 40.</li> +</ul></li> +<li><b>Details:</b><ul> +<li>Added the following CD1 issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#882">882</a>.</li> +<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#879">879</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#880">880</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#891">891</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#893">893</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#897">897</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#898">898</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#899">899</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#900">900</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#901">901</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#902">902</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#903">903</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#904">904</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#905">905</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#906">906</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#907">907</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#908">908</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#909">909</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#910">910</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#911">911</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#912">912</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#913">913</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#914">914</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#915">915</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#916">916</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#917">917</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#918">918</a>.</li> +<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#881">881</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#883">883</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#884">884</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#885">885</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#886">886</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#887">887</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#889">889</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#890">890</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#895">895</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#896">896</a>.</li> +<li>Added the following Pending NAD Editorial issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#892">892</a>.</li> +<li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#894">894</a>.</li> +<li>Added the following Review issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#888">888</a>.</li> +<li>Changed the following issues from New to CD1: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#818">818</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#820">820</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#843">843</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#845">845</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#846">846</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#856">856</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#858">858</a>.</li> +<li>Changed the following issues from Ready to CD1: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#396">396</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#714">714</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#762">762</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#769">769</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#772">772</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#776">776</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#779">779</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#787">787</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#805">805</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#806">806</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#807">807</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#808">808</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#809">809</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#813">813</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#824">824</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#829">829</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#842">842</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#844">844</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#848">848</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#850">850</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#852">852</a>.</li> +<li>Changed the following issues from Review to CD1: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#23">23</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#698">698</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#709">709</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#804">804</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#823">823</a>.</li> +<li>Changed the following issues from WP to CD1: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#44">44</a>, <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#92">92</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#98">98</a>, <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#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#118">118</a>, <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#123">123</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#167">167</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#179">179</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#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#187">187</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#198">198</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#200">200</a>, <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#202">202</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#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#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#228">228</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#230">230</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#231">231</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#233">233</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#235">235</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#238">238</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#239">239</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#240">240</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#243">243</a>, <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#248">248</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#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#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-defects.html#256">256</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-defects.html#259">259</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#264">264</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#266">266</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#268">268</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#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#274">274</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#276">276</a>, <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#280">280</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#282">282</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#283">283</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#291">291</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#294">294</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#300">300</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#305">305</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#310">310</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#311">311</a>, <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#315">315</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#316">316</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#317">317</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#318">318</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#319">319</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#320">320</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#321">321</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#322">322</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#324">324</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#325">325</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#327">327</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#328">328</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#329">329</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#331">331</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#333">333</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#334">334</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#335">335</a>, <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-defects.html#337">337</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#338">338</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#339">339</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#340">340</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#341">341</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#345">345</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#346">346</a>, <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-defects.html#349">349</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#352">352</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#354">354</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#355">355</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#358">358</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#359">359</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#360">360</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#363">363</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#364">364</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#365">365</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#370">370</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#373">373</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#375">375</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#379">379</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#380">380</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#381">381</a>, <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#384">384</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#391">391</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#395">395</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#400">400</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#402">402</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#403">403</a>, <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-defects.html#405">405</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#407">407</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#410">410</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#411">411</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#412">412</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#414">414</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#415">415</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#420">420</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#425">425</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#426">426</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#428">428</a>, <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-defects.html#435">435</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#436">436</a>, <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#442">442</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#443">443</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#448">448</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#449">449</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#453">453</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#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#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#488">488</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#496">496</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#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#519">519</a>, <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#524">524</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</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#534">534</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>, <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#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-defects.html#550">550</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#552">552</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#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#566">566</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#574">574</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#577">577</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#581">581</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#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#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#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#612">612</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#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#619">619</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#628">628</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#638">638</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>, <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#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#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-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#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-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-defects.html#685">685</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#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-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>, <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#712">712</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> +<li>Changed the following issues from Open to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#670">670</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#849">849</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#855">855</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#871">871</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#454">454</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#832">832</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#811">811</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#812">812</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#841">841</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#864">864</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#870">870</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#872">872</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#299">299</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#484">484</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#556">556</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#676">676</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#724">724</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#742">742</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#532">532</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-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>.</li> +<li>Changed the following issues from New to Open: <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-active.html#751">751</a>, <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#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#819">819</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#836">836</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#838">838</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#857">857</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>, <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#873">873</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>.</li> +<li>Changed the following issues from Pending NAD Editorial to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#424">424</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#625">625</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#851">851</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#788">788</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#821">821</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#866">866</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#753">753</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#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#803">803</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#765">765</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#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#869">869</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#878">878</a>.</li> +<li>Changed the following issues from TC to TC1: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1">1</a>, <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#5">5</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#7">7</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#11">11</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#13">13</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#14">14</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#15">15</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#16">16</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#17">17</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#18">18</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#20">20</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#21">21</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#22">22</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#24">24</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#25">25</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#27">27</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#28">28</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#29">29</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#30">30</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#32">32</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#33">33</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#34">34</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#35">35</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#36">36</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#37">37</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#38">38</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#39">39</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#40">40</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#41">41</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#42">42</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#46">46</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#47">47</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#48">48</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#50">50</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#51">51</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#52">52</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#53">53</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#54">54</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#55">55</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#56">56</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#57">57</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#59">59</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</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#62">62</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#64">64</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#66">66</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#68">68</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#69">69</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#70">70</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#71">71</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#74">74</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#75">75</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#78">78</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#79">79</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#80">80</a>, <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#90">90</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#106">106</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#110">110</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#119">119</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#124">124</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#125">125</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#126">126</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#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-defects.html#137">137</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#139">139</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#141">141</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#148">148</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#150">150</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#151">151</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#152">152</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#154">154</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#155">155</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#156">156</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#158">158</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#160">160</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#161">161</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#168">168</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#169">169</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#172">172</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#173">173</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#174">174</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#175">175</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#176">176</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#189">189</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#193">193</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</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>.</li> +</ul></li> +</ul> +</li> <li>R59: 2008-08-22 pre-San Francisco mailing. <ul> @@ -60,7 +202,7 @@ del {background-color:#FFA0A0} <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> +<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#870">870</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#871">871</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.html#874">874</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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> @@ -73,11 +215,11 @@ del {background-color:#FFA0A0} <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>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-closed.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-defects.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> +<li>Changed the following issues from WP to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.html#709">709</a>.</li> </ul></li> </ul> </li> @@ -91,24 +233,24 @@ del {background-color:#FFA0A0} </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 New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#841">841</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#843">843</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#845">845</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-closed.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-closed.html#855">855</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.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 Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#842">842</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#844">844</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#848">848</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#850">850</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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 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-closed.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> +<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#714">714</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#769">769</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#772">772</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#779">779</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#787">787</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#805">805</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#806">806</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#807">807</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#808">808</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#809">809</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#813">813</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#824">824</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#396">396</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#698">698</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#804">804</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-closed.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-defects.html#23">23</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-defects.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-defects.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-defects.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> @@ -121,7 +263,7 @@ del {background-color:#FFA0A0} <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>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-defects.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-defects.html#820">820</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.html#823">823</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.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-closed.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> @@ -137,8 +279,8 @@ del {background-color:#FFA0A0} <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 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-closed.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-defects.html#804">804</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#805">805</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#806">806</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#807">807</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#808">808</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-closed.html#811">811</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#812">812</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#813">813</a>.</li> +<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#793">793</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.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> @@ -147,15 +289,15 @@ del {background-color:#FFA0A0} <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 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-defects.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-defects.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#724">724</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-defects.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-defects.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-defects.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-defects.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-active.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-active.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-defects.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-defects.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-defects.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 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-defects.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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> @@ -171,7 +313,7 @@ del {background-color:#FFA0A0} <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>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-defects.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-defects.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.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-defects.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-defects.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> @@ -189,7 +331,7 @@ del {background-color:#FFA0A0} <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>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-defects.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-defects.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> @@ -204,16 +346,16 @@ del {background-color:#FFA0A0} <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>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-defects.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-closed.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-defects.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-closed.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-defects.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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 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-defects.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-closed.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-closed.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 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-defects.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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 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-defects.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> @@ -229,7 +371,7 @@ del {background-color:#FFA0A0} <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> +<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.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> @@ -242,13 +384,13 @@ del {background-color:#FFA0A0} <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>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-defects.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-closed.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 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-closed.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> @@ -269,7 +411,7 @@ del {background-color:#FFA0A0} <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 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-defects.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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> @@ -286,12 +428,12 @@ del {background-color:#FFA0A0} <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>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-closed.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-defects.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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 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-active.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 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-active.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-active.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-active.html#149">149</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-active.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> @@ -313,11 +455,11 @@ del {background-color:#FFA0A0} <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>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-defects.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-closed.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-active.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 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-active.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> @@ -331,7 +473,7 @@ del {background-color:#FFA0A0} <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> +<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#611">611</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#613">613</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#614">614</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-active.html#617">617</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#619">619</a>.</li> </ul></li> </ul> </li> @@ -347,10 +489,10 @@ del {background-color:#FFA0A0} <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#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-closed.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> +<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-closed.html#594">594</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-active.html#597">597</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#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#604">604</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#605">605</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#606">606</a>, <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#609">609</a>.</li> </ul></li> </ul> </li> @@ -363,7 +505,7 @@ del {background-color:#FFA0A0} <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> +<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#584">584</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-defects.html#586">586</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#587">587</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-defects.html#589">589</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-closed.html#591">591</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#592">592</a>.</li> </ul></li> </ul> </li> @@ -376,7 +518,7 @@ del {background-color:#FFA0A0} <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>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-defects.html#576">576</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#578">578</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-active.html#580">580</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-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> @@ -391,9 +533,9 @@ del {background-color:#FFA0A0} <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>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-active.html#568">568</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#569">569</a>, <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-closed.html#571">571</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#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#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-defects.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#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#528">528</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> @@ -409,7 +551,7 @@ del {background-color:#FFA0A0} <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>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#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-active.html#539">539</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>, <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#543">543</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-defects.html#545">545</a>, <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-closed.html#547">547</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#548">548</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#550">550</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#552">552</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#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#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-closed.html#558">558</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-closed.html#560">560</a>, <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-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-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> @@ -424,7 +566,7 @@ del {background-color:#FFA0A0} <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> +<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#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-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#533">533</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#535">535</a>.</li> </ul></li> </ul> </li> @@ -440,7 +582,7 @@ Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.htm </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>. +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-defects.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: @@ -449,7 +591,7 @@ Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active </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 +for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#454">454</a> were moved to "DR" status, and all issues previously in "DR" status were moved to "WP". </li> <li>R35: @@ -497,7 +639,7 @@ Pre-Oxford mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22 <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 +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-defects.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> @@ -556,7 +698,7 @@ Changed status of issues 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-active.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. @@ -582,7 +724,7 @@ issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#265 <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 +<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-defects.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 @@ -635,7 +777,7 @@ in Dublin. (99-0016/N1193, 21 Apr 99) 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) +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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>, @@ -648,7 +790,7 @@ 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 +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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: @@ -668,9 +810,9 @@ format, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64 <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>Section:</b> 17.6.2.3 [using.linkage] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Beman Dawes <b>Opened:</b> 1997-11-16 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 @@ -679,7 +821,7 @@ Morristown meeting.</p> <p><b>Proposed resolution:</b></p> -<p>Change 17.4.2.2 [using.linkage] paragraph 2 +<p>Change 17.6.2.3 [using.linkage] paragraph 2 from:</p> <blockquote> @@ -703,9 +845,10 @@ from:</p> <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>Section:</b> 18.5 [support.start.term] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Steve Clamage <b>Opened:</b> 1997-12-12 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#support.start.term">issues</a> in [support.start.term].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p> <p><b>Discussion:</b></p> <p>We appear not to have covered all the possibilities of exit processing with respect to @@ -836,10 +979,10 @@ 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>Section:</b> 21.4.6.8 [string::swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Jack Reeves <b>Opened:</b> 1997-12-11 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 @@ -863,7 +1006,7 @@ charT* s, size_type n2) const; each defined in terms of the corresponding constr <p><b>Proposed resolution:</b></p> -<p>Replace the compare signature in 21.3 [basic.string] +<p>Replace the compare signature in 21.4 [basic.string] (at the very end of the basic_string synopsis) which reads:</p> <blockquote> @@ -882,7 +1025,7 @@ charT* s, size_type n2) const; each defined in terms of the corresponding constr size_type n2) const;</tt></p> </blockquote> -<p>Replace the portion of 21.3.6.8 [string::swap] +<p>Replace the portion of 21.4.6.8 [string::swap] paragraphs 5 and 6 which read:</p> <blockquote> @@ -929,12 +1072,12 @@ 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>Section:</b> 21 [strings] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Matt Austern <b>Opened:</b> 1997-12-15 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p> <p><b>Discussion:</b></p> -<p>(1) In 21.3.6.4 [string::insert], the description of template +<p>(1) In 21.4.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 @@ -955,9 +1098,9 @@ possible const charT&. </p> 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> +21.4.6.8 [string::swap]</p> -<p>(6) In table 37, in section 21.1.1 [char.traits.require], +<p>(6) In table 37, in section 21.2.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 @@ -1010,9 +1153,9 @@ 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>Section:</b> 22.3.1.5 [locale.statics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Matt Austern <b>Opened:</b> 1997-12-24 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 @@ -1024,7 +1167,7 @@ such words anywhere. </p> <p><b>Proposed resolution:</b></p> -<p>Add a sentence at the end of 22.1.1.5 [locale.statics], +<p>Add a sentence at the end of 22.3.1.5 [locale.statics], paragraph 2: </p> <blockquote> @@ -1039,9 +1182,10 @@ paragraph 2: </p> <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>Section:</b> 18.6.1 [new.delete] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Steve Clamage <b>Opened:</b> 1998-01-04 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#new.delete">issues</a> in [new.delete].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 @@ -1106,10 +1250,11 @@ 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>Section:</b> 20.3.6 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-01-22 <b>Last modified:</b> 2008-09-26</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#template.bitset">active issues</a> in [template.bitset].</p> <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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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> @@ -1126,7 +1271,7 @@ 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]), +In the bitset synopsis (20.3.6 [template.bitset]), replace the member function <br> <br> <tt> reference operator[](size_t pos);<br> @@ -1136,7 +1281,7 @@ with the two member functions<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], +Add the following text at the end of 20.3.6.2 [bitset.members], immediately after paragraph 45:</p> <blockquote> @@ -1156,7 +1301,7 @@ immediately after paragraph 45:</p> <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]. +input" implies the desired semantics. See 27.7.1.2 [istream.formatted]. </p> @@ -1165,10 +1310,10 @@ input" implies the desired semantics. See 27.6.1.2 [istream.formatted]. <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>Section:</b> 27.7.1.2.3 [istream::extractors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> William M. Miller <b>Opened:</b> 1998-03-03 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 @@ -1176,7 +1321,7 @@ it's undefined. </p> <p><b>Proposed resolution:</b></p> -<p>In 27.6.1.2.3 [istream::extractors], replace "eos" with +<p>In 27.7.1.2.3 [istream::extractors], replace "eos" with "charT()"</p> @@ -1185,10 +1330,10 @@ it's undefined. </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>Section:</b> 22.3.1.3 [locale.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 @@ -1203,7 +1348,7 @@ 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 +<p>In 22.3.1 [locale] and also in 22.3.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> @@ -1215,17 +1360,17 @@ time, but the omission was not noticed. </p> <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>Section:</b> 22.3.1.3 [locale.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 +<p>In 22.3.1.3 [locale.members], paragraph 5, replace "<tt>locale(name())</tt>" with "<tt>locale(name().c_str())</tt>". </p> @@ -1236,10 +1381,11 @@ constructor, but there is no matching constructor. </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>Section:</b> 22.4.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2008-09-26</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.codecvt">active issues</a> in [locale.codecvt].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 @@ -1249,7 +1395,7 @@ 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> +from 22.4.1.3 [facet.ctype.special].</p> @@ -1257,11 +1403,11 @@ 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>Section:</b> 22.4.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 @@ -1306,7 +1452,7 @@ 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, +<p>In 22.4.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> @@ -1349,10 +1495,10 @@ change "&&" to "&".</p> <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>Section:</b> 22.4.2.1.1 [facet.num.get.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 @@ -1361,9 +1507,9 @@ 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] +<p>Add at the beginning of 22.4.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> +22.4.2.1 [locale.num.get].</p> @@ -1371,10 +1517,11 @@ another get member for bool&, copied from the entry in <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>Section:</b> 22.4.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2008-09-26</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.codecvt">active issues</a> in [locale.codecvt].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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> @@ -1388,7 +1535,7 @@ normatively what is done with the buffers. <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: +22.4.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, @@ -1408,9 +1555,9 @@ Change the entry for noconv in the table under paragraph 4 in section <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>Section:</b> 22.4.3.1.2 [facet.numpunct.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 @@ -1419,7 +1566,7 @@ 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 +<p>In 22.4.3.1.2 [facet.numpunct.virtuals], above paragraph 2, change "string_type" to "char_type". </p> @@ -1428,10 +1575,10 @@ described as returning a "string_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>Section:</b> 22.3.1.1.1 [locale.category] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2008-09-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#TC">TC</a> status.</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p> <p><b>Discussion:</b></p> <p>In the second table in the section, captioned "Required instantiations", the instantiations for codecvt_byname<> @@ -1440,7 +1587,7 @@ 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 +<p>Add in 22.3.1.1.1 [locale.category] to the table captioned "Required instantiations", in the category "ctype" the lines </p> @@ -1455,10 +1602,10 @@ codecvt_byname<wchar_t,char,mbstate_t> </pre> <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>Section:</b> 27.9.1.9 [ifstream.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 @@ -1469,7 +1616,7 @@ 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>In 27.9.1.9 [ifstream.members] paragraph 3, <i>and</i> in 27.9.1.13 [ofstream.members] paragraph 3, under open() effects, add a footnote: </p> <blockquote> @@ -1494,11 +1641,211 @@ believes to have been the original intent.</p> <hr> +<h3><a name="23"></a>23. Num_get overflow result</h3> +<p><b>Section:</b> 22.4.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2008-09-26</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#CD1">CD1</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.4.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.4.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.4.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="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>Section:</b> 22.4.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2008-09-26</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.codecvt">active issues</a> in [locale.codecvt].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 @@ -1508,8 +1855,8 @@ 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 +<p>In 22.4.1.4 [locale.codecvt], paragraph 3, change +"do_convert" to "do_in or do_out". Also, in 22.4.1.4.2 [locale.codecvt.virtuals], change "do_convert()" to "do_in or do_out". </p> @@ -1518,10 +1865,10 @@ 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>Section:</b> 21.4.8.9 [string.io] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 @@ -1530,7 +1877,7 @@ elsewhere; but this is inconsistent, as this allows no possibility of space for <p><b>Proposed resolution:</b></p> -<p>Change 21.3.8.9 [string.io] paragraph 4 from:<br> +<p>Change 21.4.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> @@ -1546,10 +1893,10 @@ to: <br> <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>Section:</b> 27.7.1.1.3 [istream::sentry] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p> <p><b>Discussion:</b></p> <p>In paragraph 6, the code in the example: </p> @@ -1576,7 +1923,7 @@ sequence without examining it.) </p> <p><b>Proposed resolution:</b></p> -<p>Remove the example above from 27.6.1.1.3 [istream::sentry] +<p>Remove the example above from 27.7.1.1.3 [istream::sentry] paragraph 6.</p> @@ -1594,10 +1941,10 @@ 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>Section:</b> 21.4.6.5 [string::erase] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 @@ -1606,7 +1953,7 @@ 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> +<p>In 21.4.6.5 [string::erase], paragraph 10, change: </p> <blockquote> <p>Returns: an iterator which points to the element immediately following _last_ prior to @@ -1626,10 +1973,10 @@ while 'd' has not been erased. </p> <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>Section:</b> 22.4.1.3.2 [facet.ctype.char.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 @@ -1645,7 +1992,7 @@ vec[]. </p> <p><b>Proposed resolution:</b></p> -<p>Change 22.2.1.3.2 [facet.ctype.char.members], paragraph 4, to read </p> +<p>Change 22.4.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] @@ -1658,21 +2005,21 @@ vec[]. </p> <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>Section:</b> 27.4.1 [narrow.stream.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p> <p><b>Discussion:</b></p> -<p>Sections 27.3.1 [narrow.stream.objects] and 27.3.2 [wide.stream.objects] mention +<p>Sections 27.4.1 [narrow.stream.objects] and 27.4.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], +basic_ios<>::init, defined in 27.5.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> +<p>In 27.4.1 [narrow.stream.objects] paragraph 2 and 5, change </p> <blockquote> <p>ios_base::init </p> @@ -1684,7 +2031,7 @@ paragraph 3. </p> <p>basic_ios<char>::init </p> </blockquote> -<p>Also, make a similar change in 27.3.2 [wide.stream.objects] except it +<p>Also, make a similar change in 27.4.2 [wide.stream.objects] except it should read </p> <blockquote> @@ -1697,17 +2044,17 @@ should read </p> <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>Section:</b> 22.3.1.1.1 [locale.category] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2008-09-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#TC">TC</a> status.</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 +<p>In 22.3.1.1.1 [locale.category], paragraph 2, change "<cctype>" to read "<clocale>". </p> @@ -1716,10 +2063,10 @@ where they are in fact defined elsewhere to appear in <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>Section:</b> 22.3.1 [locale] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 @@ -1729,7 +2076,7 @@ are manifestly assignable. </p> <p><b>Proposed resolution:</b></p> -<p>In 22.1.1 [locale] replace paragraph 6</p> +<p>In 22.3.1 [locale] replace paragraph 6</p> <blockquote> <p>An instance of <tt>locale</tt> is immutable; once a facet @@ -1752,9 +2099,9 @@ are manifestly assignable. </p> <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>Section:</b> 27.6.2.4.4 [streambuf.virt.pback] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 @@ -1771,7 +2118,7 @@ Specifically, the latter says it calls pbackfail if: </p> <p><b>Proposed resolution:</b></p> -<p>In 27.5.2.4.4 [streambuf.virt.pback], paragraph 1, change:</p> +<p>In 27.6.2.4.4 [streambuf.virt.pback], paragraph 1, change:</p> <blockquote> <p>"<tt>traits::eq(*gptr(),traits::to_char_type( c))</tt>"</p> @@ -1795,10 +2142,11 @@ 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>Section:</b> 22.4.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2008-09-26</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.codecvt">active issues</a> in [locale.codecvt].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 @@ -1813,7 +2161,7 @@ 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 +<p>In 22.4.1.4.2 [locale.codecvt.virtuals] paragraph 4, replace the definition in the table for the case of _error_ with </p> <blockquote> @@ -1826,10 +2174,10 @@ in the table for the case of _error_ with </p> <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>Section:</b> 22.4.2.2.2 [facet.num.put.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 @@ -1837,7 +2185,7 @@ ctype<charT>, but it has no such members. Note that this is also a problem <p><b>Proposed resolution:</b></p> -<p>In 22.2.2.2.2 [facet.num.put.virtuals], paragraph 19, in the Effects: +<p>In 22.4.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> @@ -1852,17 +2200,17 @@ string_type s = val ? np.truename() : np.falsename(); </pre> <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>Section:</b> 27.5 [iostreams.base] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p> <p><b>Discussion:</b></p> -<p>In 27.4.5.1 [fmtflags.manip], we have a definition for a manipulator +<p>In 27.5.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 +<p>Add to the synopsis for <ios> in 27.5 [iostreams.base], after the entry for "nouppercase", the prototypes: </p> <blockquote> @@ -1876,10 +2224,10 @@ ios_base& nounitbuf(ios_base& str); </pre> <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>Section:</b> 27.5.2.5 [ios.base.storage] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 @@ -1892,7 +2240,7 @@ member with a different index ... </p> <p><b>Proposed resolution:</b></p> -<p>Add in 27.4.2.5 [ios.base.storage], in both paragraph 2 and also in +<p>Add in 27.5.2.5 [ios.base.storage], in both paragraph 2 and also in paragraph 4, replace the sentence: </p> <blockquote> @@ -1917,10 +2265,10 @@ paragraph 4, replace the sentence: </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>Section:</b> 22.3.1 [locale] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p> <p><b>Discussion:</b></p> <p>In the overview of locale semantics, paragraph 4, is the sentence </p> @@ -1934,7 +2282,7 @@ from an old draft. </p> <p><b>Proposed resolution:</b></p> -<p>In 22.1.1 [locale], paragraph 4, delete the parenthesized +<p>In 22.3.1 [locale], paragraph 4, delete the parenthesized expression </p> <blockquote> @@ -1947,9 +2295,9 @@ expression </p> <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>Section:</b> 22.3.2 [locale.global.templates] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 @@ -1971,7 +2319,7 @@ reads: </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> + contains the public static member <tt>id</tt> as defined in 22.3.1.1.2 [locale.facet]. </p> </blockquote> <p><i>[ @@ -1989,9 +2337,9 @@ contains (not inherits) the public static member <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>Section:</b> 24.6.3.4 [istreambuf.iterator::op++] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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> @@ -2004,7 +2352,7 @@ return(tmp); </pre> <p><b>Proposed resolution:</b></p> -<p>In 24.5.3.4 [istreambuf.iterator::op++], delete the three lines of code at the +<p>In 24.6.3.4 [istreambuf.iterator::op++], delete the three lines of code at the end of paragraph 3. </p> @@ -2013,10 +2361,10 @@ 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>Section:</b> 22.4.8 [facets.examples] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 @@ -2024,7 +2372,7 @@ anything. </p> <p><b>Proposed resolution:</b></p> -<p>Delete 22.2.8 [facets.examples] paragraph 3 which begins "This +<p>Delete 22.4.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> @@ -2035,20 +2383,20 @@ 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>Section:</b> 27.5.2 [ios.base] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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, +<p>The description of ios_base::iword() and pword() in 27.5.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 +<p>Change the description in 27.5.2.5 [ios.base.storage] in paragraph 2, and also in paragraph 4, as follows. Replace</p> <blockquote> @@ -2075,11 +2423,11 @@ 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>Section:</b> 21.4 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p> <p><b>Discussion:</b></p> <p>The basic_string<> copy constructor: </p> @@ -2098,7 +2446,7 @@ 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 +<p> In 21.4 [basic.string], replace the declaration of the copy constructor as follows: </p> <blockquote> @@ -2107,7 +2455,7 @@ 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 +<p>In 21.4.1 [string.require], replace the copy constructor declaration as above. Add to paragraph 5, Effects:</p> <blockquote> @@ -2122,7 +2470,7 @@ 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 +<p>A. In 21.4 [basic.string], replace the declaration of the copy constructor as follows:</p> <blockquote> @@ -2132,7 +2480,7 @@ 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 +<p>In 21.4.1 [string.require], replace the copy constructor declaration as above. Add to paragraph 5, Effects: </p> <blockquote> @@ -2140,7 +2488,7 @@ as above. Add to paragraph 5, Effects: </p> value <tt>str.get_allocator()</tt>. </p> </blockquote> -<p>B. In 21.3 [basic.string], and also in 21.3.1 [string.require], replace +<p>B. In 21.4 [basic.string], and also in 21.4.1 [string.require], replace the declaration of the copy constructor as follows: </p> <blockquote> @@ -2164,10 +2512,11 @@ reflects the LWG consensus. <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>Section:</b> 27 [input.output] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2008-09-26</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#input.output">active issues</a> in [input.output].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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 == @@ -2415,9 +2764,9 @@ change uses of == and != to use the traits members instead. </p> <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>Section:</b> D.7 [depr.str.strstreams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Brendan Kehoe <b>Opened:</b> 1998-06-01 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p> <p><b>Discussion:</b></p><p>See lib-6522 and edit-814.</p> <p><b>Proposed resolution:</b></p> @@ -2448,10 +2797,10 @@ int_type:</p> <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>Section:</b> 27.5.2.3 [ios.base.locales] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-06-21 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 @@ -2461,7 +2810,7 @@ accident?</p> <p><b>Proposed resolution:</b></p> -<p>In 27.4.2.3 [ios.base.locales] swap paragraphs 2 and 4.</p> +<p>In 27.5.2.3 [ios.base.locales] swap paragraphs 2 and 4.</p> @@ -2469,10 +2818,10 @@ accident?</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>Section:</b> 27.5.2.1.1 [ios::failure] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-06-21 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 @@ -2480,7 +2829,7 @@ base class, exception, with exception(msg). Class exception (see <p><b>Proposed resolution:</b></p> -<p>Replace 27.4.2.1.1 [ios::failure], paragraph 2, with</p> +<p>Replace 27.5.2.1.1 [ios::failure], paragraph 2, with</p> <blockquote> <p>EFFECTS: Constructs an object of class <tt>failure</tt>.</p> @@ -2492,9 +2841,9 @@ base class, exception, with exception(msg). Class exception (see <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>Section:</b> 27.5.2.4 [ios.members.static] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-06-21 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p>Two problems</p> @@ -2510,7 +2859,7 @@ 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] +<p>Change the following sentence in 27.5.2.4 [ios.members.static] returns clause from:</p> <blockquote> @@ -2526,7 +2875,7 @@ returns clause from:</p> <tt>false</tt>.</p> </blockquote> -<p>Add the following immediately after 27.4.2.4 [ios.members.static], +<p>Add the following immediately after 27.5.2.4 [ios.members.static], paragraph 2:</p> <blockquote> @@ -2579,10 +2928,10 @@ 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>Section:</b> 27.5.2 [ios.base] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-06-21 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 @@ -2605,7 +2954,7 @@ semantics (e.g. what happens to the iarray and parray stuff). <p><b>Proposed resolution:</b></p> -<p>In 27.4.2 [ios.base], class ios_base, specify the copy +<p>In 27.5.2 [ios.base], class ios_base, specify the copy constructor and operator= members as being private.</p> @@ -2619,11 +2968,11 @@ 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>Section:</b> 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> David Vandevoorde <b>Opened:</b> 1998-06-23 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 @@ -2680,18 +3029,18 @@ 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>Section:</b> 27.5.3.2 [fpos.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-06-23 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p> <p><b>Discussion:</b></p> -<p>First, 27.4.4.1 [basic.ios.cons], table 89. This is pretty obvious: +<p>First, 27.5.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 +<p>Second, 27.5.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 @@ -2708,7 +3057,7 @@ arithmetic is possible.) </p> <p><b>Proposed resolution:</b></p> -<p>Change 27.4.4.1 [basic.ios.cons] table 89 title from +<p>Change 27.5.4.1 [basic.ios.cons] table 89 title from "ios_base() effects" to "basic_ios<>() effects". </p> @@ -2718,10 +3067,10 @@ 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>Section:</b> 27.5.4.1 [basic.ios.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-06-23 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 @@ -2729,7 +3078,7 @@ rdbuf().</p> <p><b>Proposed resolution:</b></p> -<p>Add after 27.4.4.1 [basic.ios.cons] paragraph 2:</p> +<p>Add after 27.5.4.1 [basic.ios.cons] paragraph 2:</p> <blockquote> <p><tt>virtual ~basic_ios();</tt></p> @@ -2740,7 +3089,7 @@ rdbuf().</p> <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 +clearly yes; it may be set via <tt>clear()</tt>. See 27.5.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> @@ -2751,10 +3100,10 @@ footnote which incorrectly said "<tt>rdbuf(0)</tt> does not set <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>Section:</b> 27.6.2.1 [streambuf.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-06-25 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 @@ -2763,7 +3112,7 @@ explicitly. </p> <p><b>Proposed resolution:</b></p> -<p>Add after 27.5.2.1 [streambuf.cons] paragraph 2:</p> +<p>Add after 27.6.2.1 [streambuf.cons] paragraph 2:</p> <blockquote> <p><tt>virtual ~basic_streambuf();</tt></p> @@ -2776,10 +3125,11 @@ explicitly. </p> <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>Section:</b> 27 [input.output] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-06-26 <b>Last modified:</b> 2008-09-26</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#input.output">active issues</a> in [input.output].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 @@ -2801,33 +3151,33 @@ 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> + <p>27.8.1.4 [stringbuf.virtuals], paragraph 14<br> + 27.9.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 +<p>In 27.6.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 +<p>In 27.6.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 +<p>In 27.8.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 +<p>In 27.9.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 +<p>In 27.9.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> @@ -2846,10 +3196,10 @@ stores an invalid stream position" to "the return value is <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>Section:</b> 27.6.2 [streambuf] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-06-29 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 @@ -2858,7 +3208,7 @@ 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> +27.6.2 [streambuf] class summary to <tt>streamsize</tt>.</p> @@ -2866,9 +3216,9 @@ return type is streamsize. </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>Section:</b> 21.2.3.4 [char.traits.specializations.wchar.t] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-07-01 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 @@ -2885,7 +3235,7 @@ 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 +<p>Remove the sentence in 21.2.3.4 [char.traits.specializations.wchar.t] paragraph 3 which begins "The types streampos and wstreampos may be different..." . </p> @@ -2895,9 +3245,9 @@ 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>Section:</b> 27.6.2.3.2 [streambuf.get.area] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-07-28 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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> @@ -2913,7 +3263,7 @@ 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> +<p>Change 27.6.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> @@ -2925,7 +3275,7 @@ former interpretation.)</p> <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 +<p>Make the same change to 27.6.2.3.3 [streambuf.put.area] paragraph 4 pbump effects.</p> @@ -2934,10 +3284,10 @@ 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>Section:</b> 27.7.1.2.1 [istream.formatted.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-08-03 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 @@ -2971,18 +3321,18 @@ that the "Common requirements" listed in section 27.6.1.2.1 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 +nonsensical to consider the functions defined in 27.7.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 +have to conform to the "common requirements" from 27.7.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 +that all functions in 27.7.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 @@ -3247,10 +3597,10 @@ 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>Section:</b> 27.7.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 @@ -3296,10 +3646,10 @@ 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>Section:</b> 27.7.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-08-06 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 @@ -3310,7 +3660,7 @@ 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 +<p>In 27.7.1.3 [istream.unformatted], paragraph 36, change "returns <tt>traits::eof()</tt>" to "returns <tt>-1</tt>". </p> @@ -3320,10 +3670,10 @@ traits::int_type while the return type of sync() is int. </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>Section:</b> 27.7.2.7 [ostream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-08-11 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 @@ -3363,10 +3713,10 @@ input, unformatted input, and formatted output. <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>Section:</b> 27.7.1.2.3 [istream::extractors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-08-11 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 @@ -3374,7 +3724,7 @@ elaboration of the first. </p> <p><b>Proposed resolution:</b></p> -<p>Replace 27.6.1.2.3 [istream::extractors], paragraph 13, which begins +<p>Replace 27.7.1.2.3 [istream::extractors], paragraph 13, which begins "If the function inserts no characters ..." with:</p> <blockquote> @@ -3392,10 +3742,10 @@ elaboration of the first. </p> <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>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#TC1">TC1</a> + <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-08-18 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 @@ -3421,10 +3771,10 @@ with:</p> <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>Section:</b> 27.7.1.2.3 [istream::extractors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Angelika Langer <b>Opened:</b> 1998-07-14 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 @@ -3437,7 +3787,7 @@ 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 +<p>27.7.1.2.3 [istream::extractors], paragraph 7, change the last list item from:</p> <blockquote><p> @@ -3459,10 +3809,10 @@ item from:</p> <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>Section:</b> 23.3.6 [vector] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Andrew Koenig <b>Opened:</b> 1998-07-29 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p> <p><b>Discussion:</b></p> <p>The issue is this: Must the elements of a vector be in contiguous memory?</p> @@ -3473,7 +3823,7 @@ debugging implementations)</p> <p><b>Proposed resolution:</b></p> -<p>Add the following text to the end of 23.2.6 [vector], +<p>Add the following text to the end of 23.3.6 [vector], paragraph 1. </p> <blockquote> @@ -3492,10 +3842,10 @@ 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> + already used for valarray (26.6.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 + because elements must be copyconstructible (23.2 [container.requirements] para 3) + and copyconstructible (X [utility.arg.requirements]) specifies requirements for operator&.</li> <li>There is no issue of one-past-the-end because of language rules.</li> </ul> @@ -3506,10 +3856,10 @@ directly defined in the standard. Discussion included:</p> <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>Section:</b> 18.8 [support.exception], 18.8.4 [uncaught] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Steve Clamage <b>Opened:</b> 1998-08-03 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p> <p><b>Discussion:</b></p> <p>In article 3E04@pratique.fr, Valentin Bonnard writes: </p> @@ -3523,20 +3873,20 @@ 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> +<p>In 15.5.3 [except.uncaught], paragraph 1, 18.8 [support.exception], +and 18.8.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>Section:</b> 22.4.5.1 [locale.time.get] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-13 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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, +is described in 22.4.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 @@ -3544,7 +3894,7 @@ value.</p> <p><b>Proposed resolution:</b></p> -<p>In 22.2.5.1 [locale.time.get], add an "end" argument to +<p>In 22.4.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&, @@ -3555,10 +3905,11 @@ the declaration of member do_monthname as follows:</p> <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>Section:</b> 22.4.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-09-08 <b>Last modified:</b> 2008-09-26</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.codecvt">active issues</a> in [locale.codecvt].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 @@ -3566,7 +3917,7 @@ 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 +<p>Replace 22.4.1.4.2 [locale.codecvt.virtuals] paragraph 11 with the following:</p> <blockquote><p> @@ -3582,11 +3933,12 @@ following:</p> <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> +<p><b>Section:</b> 22.4.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> <b>Submitter:</b> Matt -Austern <b>Date:</b> 1998-09-18</p> +Austern <b>Opened:</b> 1998-09-18 <b>Last modified:</b> 2008-09-26</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.codecvt">active issues</a> in [locale.codecvt].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 @@ -3602,7 +3954,7 @@ then we must also add text saying how <tt>do_length</tt> changes its <p><b>Proposed resolution:</b></p> -<p>In 22.2.1.4 [locale.codecvt], and also in 22.2.1.5 [locale.codecvt.byname], +<p>In 22.4.1.4 [locale.codecvt], and also in 22.4.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> @@ -3616,7 +3968,7 @@ change the <tt>stateT</tt> argument type on both member <p><tt>stateT&</tt></p> </blockquote> -<p>In 22.2.1.4.2 [locale.codecvt.virtuals], add to the definition for member +<p>In 22.4.1.4.2 [locale.codecvt.virtuals], add to the definition for member <tt>do_length</tt> a paragraph:</p> <blockquote> @@ -3631,10 +3983,11 @@ change the <tt>stateT</tt> argument type on both member <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>Section:</b> 22.4.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-09-25 <b>Last modified:</b> 2008-09-26</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.codecvt">active issues</a> in [locale.codecvt].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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 @@ -3670,8 +4023,8 @@ sequence of <i>M</i> external characters that maps to a sequence of 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 +<tt>codecvt::do_max_length</tt> (22.4.1.4.2 [locale.codecvt.virtuals], +paragraph 11) and <tt>basic_filebuf::underflow</tt> (27.9.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> @@ -3686,11 +4039,11 @@ 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> +<p>Add the following text as a new paragraph, following 22.4.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> +(27.9 [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> @@ -3754,16 +4107,16 @@ return value.]</i></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>Section:</b> 27.5.2 [ios.base] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 +<p>In the 27.5.2 [ios.base] synopsis change "event_call_back" to "event_callback". </p> @@ -3771,22 +4124,22 @@ return value.]</i></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>Section:</b> 26.4.1 [complex.syn], 26.4.7 [complex.value.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29 <b>Last modified:</b> 2009-03-21</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.syn">issues</a> in [complex.syn].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p> <p><b>Discussion:</b></p> -<p>In 26.3.1 [complex.synopsis] polar is declared as follows:</p> +<p>In 26.4.1 [complex.syn] 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> +<p>In 26.4.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> +<p>In 26.4.1 [complex.syn] change:</p> <pre> template<class T> complex<T> polar(const T&, const T&);</pre> <p>to:</p> @@ -3798,10 +4151,10 @@ return value.]</i></p> <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>Section:</b> 26.4.1 [complex.syn], 26.4.2 [complex] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29 <b>Last modified:</b> 2009-03-21</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.syn">issues</a> in [complex.syn].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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> @@ -3815,11 +4168,11 @@ class complex. This redundancy should be removed.</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>Section:</b> 21.4 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 @@ -3831,7 +4184,7 @@ lacks some clarifications here.</p> <p><b>Proposed resolution:</b></p> -<p>After 21.3 [basic.string] paragraph 4 ("The functions +<p>After 21.4 [basic.string] paragraph 4 ("The functions described in this clause...") add a new paragraph:</p> <blockquote> @@ -3849,10 +4202,11 @@ described in this clause...") add a new paragraph:</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>Section:</b> 21.4.1 [string.require] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29 <b>Last modified:</b> 2008-09-26</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#string.require">active issues</a> in [string.require].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p> <p><b>Discussion:</b></p> <p>The constructor from a range:</p> @@ -3866,7 +4220,7 @@ 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 +<p>In 21.4.1 [string.require], Strike throws paragraphs for constructors which say "Throws: length_error if n == npos."</p> @@ -3881,10 +4235,10 @@ resolution for issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-de <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>Section:</b> 21.4.8.9 [string.io] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p> <p><b>Discussion:</b></p> <p>The effect of operator >> for strings contain the following item:</p> @@ -3895,7 +4249,7 @@ character c.</p> <p><b>Proposed resolution:</b></p> -<p>In 21.3.8.9 [string.io] paragraph 1 Effects clause replace:</p> +<p>In 21.4.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> @@ -3913,10 +4267,10 @@ character c.</p> <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>Section:</b> 21.4.8.9 [string.io] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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 @@ -3925,7 +4279,7 @@ 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> +<p>In 21.4.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 @@ -3937,7 +4291,7 @@ 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 +Effects: Behaves as a formatted input function (27.7.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 @@ -3947,7 +4301,7 @@ 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> +<p>In 21.4.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, @@ -3957,7 +4311,7 @@ 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 +(27.7.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 @@ -3992,10 +4346,10 @@ 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>Section:</b> 25 [algorithms] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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 @@ -4101,12 +4455,12 @@ objects by algorithms is unspecified". Consider placing in <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>Section:</b> 24.2.2 [input.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> AFNOR <b>Opened:</b> 1998-10-07 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> -<p>Table 72 in 24.1.1 [input.iterators] specifies semantics for +<p>Table 72 in 24.2.2 [input.iterators] specifies semantics for <tt>*r++</tt> of:</p> <p> <tt>{ T tmp = *r; ++r; return tmp; }</tt></p> @@ -4125,7 +4479,7 @@ problem.</p> <p><b>Proposed resolution:</b></p> -<p>In Table 72 in 24.1.1 [input.iterators], change the return type +<p>In Table 72 in 24.2.2 [input.iterators], change the return type for <tt>*r++</tt> from <tt>T</tt> to "convertible to T".</p> @@ -4155,10 +4509,11 @@ for <tt>*r++</tt> from <tt>T</tt> to "convertible to T".</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>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> AFNOR <b>Opened:</b> 1998-10-07 <b>Last modified:</b> 2008-09-26</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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 @@ -4174,7 +4529,7 @@ 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 +<p>23.2 [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 @@ -4187,7 +4542,7 @@ 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 +<p>Option A. In 23.2.4 [associative.reqmts], paragraph 2, after first sentence, and before "In addition,...", add one line: </p> @@ -4195,7 +4550,7 @@ first sentence, and before "In addition,...", add one line: <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> +<p>Option B. Add three new sentences to 23.2.4 [associative.reqmts]:</p> <blockquote> <p>At the end of paragraph 5: "Keys in an associative container @@ -4207,7 +4562,7 @@ first sentence, and before "In addition,...", add one line: type."</p> </blockquote> -<p>Option C. To 23.1.4 [associative.reqmts], paragraph 3, which +<p>Option C. To 23.2.4 [associative.reqmts], paragraph 3, which currently reads:</p> <blockquote> @@ -4233,7 +4588,7 @@ currently reads:</p> <p><b>Proposed resolution:</b></p> -<p>Add the following to 23.1.4 [associative.reqmts] at +<p>Add the following to 23.2.4 [associative.reqmts] at the indicated location:</p> <blockquote> @@ -4280,10 +4635,10 @@ conversion from <tt>iterator</tt> to <tt>const_iterator</tt>. <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>Section:</b> 26.6.5 [template.slice.array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> AFNOR <b>Opened:</b> 1998-10-07 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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> @@ -4295,10 +4650,10 @@ 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> + <li>26.6.5 [template.slice.array]</li> + <li>26.6.7 [template.gslice.array]</li> + <li>26.6.8 [template.mask.array]</li> + <li>26.6.9 [template.indirect.array]</li> </ul> @@ -4307,10 +4662,10 @@ Remove the comment which says "// remainder implementation defined" from: <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>Section:</b> 18.7.1 [type.info] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> AFNOR <b>Opened:</b> 1998-10-07 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 @@ -4319,7 +4674,7 @@ not throw bad_alloc.</p> <p><b>Proposed resolution:</b></p> -<p>Add to 18.6.1 [type.info] paragraph 9 (exception::what notes +<p>Add to 18.7.1 [type.info] paragraph 9 (exception::what notes clause) the sentence:</p> <blockquote> @@ -4340,10 +4695,10 @@ returned by <tt>what()</tt>. <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>Section:</b> D.8 [depr.lib.binders] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Bjarne Stroustrup <b>Opened:</b> 1998-10-07 <b>Last modified:</b> 2008-09-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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p>There are no versions of binders that apply to non-const elements @@ -4460,18 +4815,18 @@ 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>Section:</b> 24.6.3 [istreambuf.iterator], 24.6.3.5 [istreambuf.iterator::equal] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-10-15 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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==, +"const", yet 24.6.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], +<p>In 24.6.3 [istreambuf.iterator] and also in 24.6.3.5 [istreambuf.iterator::equal], replace:</p> <blockquote> @@ -4490,9 +4845,9 @@ replace:</p> <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>Section:</b> 24.6.4.1 [ostreambuf.iter.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-10-20 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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) @@ -4501,7 +4856,7 @@ 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>In 24.6.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> @@ -4519,10 +4874,10 @@ reading:</p> <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>Section:</b> 18.6.1.3 [new.delete.placement] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Steve Clamage <b>Opened:</b> 1998-10-28 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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> @@ -4544,7 +4899,7 @@ 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: +18.6.1.3 [new.delete.placement] with: </p> <blockquote> @@ -4557,9 +4912,9 @@ likely to fail.</p> <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>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#TC1">TC1</a> + <b>Submitter:</b> Steve Clamage <b>Opened:</b> 1998-11-02 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p> <p><b>Discussion:</b></p> <p>D.7.4.1 strstream constructors paragraph 2 says: </p> @@ -4589,10 +4944,10 @@ 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>Section:</b> 27.7.2.6.2 [ostream.inserters.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-11-20 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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>, @@ -4710,10 +5065,10 @@ 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>Section:</b> 27.7.1.2.2 [istream.formatted.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-11-20 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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>, @@ -4725,7 +5080,7 @@ 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, +<p>According to section 22.4.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>, @@ -4736,7 +5091,7 @@ that 27.6.1.2.2 is using a nonexistent function for types <p><b>Proposed resolution:</b></p> -<p>In 27.6.1.2.2 [istream.formatted.arithmetic] Arithmetic Extractors, remove the +<p>In 27.7.1.2.2 [istream.formatted.arithmetic] Arithmetic Extractors, remove the two lines (1st and 3rd) which read:</p> <blockquote> <pre>operator>>(short& val); @@ -4780,12 +5135,12 @@ operator>>(int& val);</pre> <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>Section:</b> 17.6.4.10 [res.on.exception.handling] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Judy Ward <b>Opened:</b> 1998-12-15 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p> <p><b>Discussion:</b></p> -<p>Section 17.4.4.9 [res.on.exception.handling] states: </p> +<p>Section 17.6.4.10 [res.on.exception.handling] states: </p> <p>"An implementation may strengthen the exception-specification for a function by removing listed exceptions." </p> @@ -4809,7 +5164,7 @@ public: <p><b>Proposed resolution:</b></p> -<p>Change Section 17.4.4.9 [res.on.exception.handling] from:</p> +<p>Change Section 17.6.4.10 [res.on.exception.handling] from:</p> <p> "may strengthen the exception-specification for a function"</p> @@ -4825,10 +5180,10 @@ 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>Section:</b> 17.6.3.3 [reserved.names] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Judy Ward <b>Opened:</b> 1998-12-15 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p>The original issue asked whether a library implementor could @@ -4876,7 +5231,7 @@ 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> + <p>Append to 17.6.3.3 [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 @@ -4895,7 +5250,7 @@ different explicit instantiations might be harmless.</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> + note to the end of 17.6.3.3 [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 @@ -4940,10 +5295,10 @@ different explicit instantiations might be harmless.</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>Section:</b> 27.6.2 [streambuf] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Judy Ward <b>Opened:</b> 1998-12-15 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p> <p><b>Discussion:</b></p> <p>Section 27.5.2 describes the streambuf classes this way: </p> @@ -4963,7 +5318,7 @@ specialized for the type wchar_t. </p> <p><b>Proposed resolution:</b></p> -<p>Remove 27.5.2 [streambuf] paragraphs 2 and 3 (the above two +<p>Remove 27.6.2 [streambuf] paragraphs 2 and 3 (the above two sentences). </p> @@ -4977,17 +5332,17 @@ 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>Section:</b> 26.6.5.3 [slice.arr.fill], 26.6.7.3 [gslice.array.fill], 26.6.8.3 [mask.array.fill], 26.6.9.3 [indirect.array.fill] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Judy Ward <b>Opened:</b> 1998-12-15 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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> +26.6.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>but this one in Section 26.6.5.3 [slice.arr.fill] is not: </p> <p> <tt>void operator=(const T&); </tt></p> @@ -4996,7 +5351,7 @@ is not. For example, look at slice_array. This operator= in Section <p><b>Proposed resolution:</b></p> -<p>26.5.5 [template.slice.array] Template class slice_array</p> +<p>26.6.5 [template.slice.array] Template class slice_array</p> <blockquote> <p>In the class template definition for slice_array, replace the member @@ -5008,7 +5363,7 @@ is not. For example, look at slice_array. This operator= in Section </pre> </blockquote> -<p>26.5.5.3 [slice.arr.fill] slice_array fill function</p> +<p>26.6.5.3 [slice.arr.fill] slice_array fill function</p> <blockquote> <p>Change the function declaration</p> @@ -5019,7 +5374,7 @@ is not. For example, look at slice_array. This operator= in Section </pre> </blockquote> -<p>26.5.7 [template.gslice.array] Template class gslice_array</p> +<p>26.6.7 [template.gslice.array] Template class gslice_array</p> <blockquote> <p>In the class template definition for gslice_array, replace the member @@ -5031,7 +5386,7 @@ is not. For example, look at slice_array. This operator= in Section </pre> </blockquote> -<p>26.5.7.3 [gslice.array.fill] gslice_array fill function</p> +<p>26.6.7.3 [gslice.array.fill] gslice_array fill function</p> <blockquote> <p>Change the function declaration</p> @@ -5042,7 +5397,7 @@ is not. For example, look at slice_array. This operator= in Section </pre> </blockquote> -<p>26.5.8 [template.mask.array] Template class mask_array</p> +<p>26.6.8 [template.mask.array] Template class mask_array</p> <blockquote> <p>In the class template definition for mask_array, replace the member @@ -5054,7 +5409,7 @@ is not. For example, look at slice_array. This operator= in Section </pre> </blockquote> -<p>26.5.8.3 [mask.array.fill] mask_array fill function</p> +<p>26.6.8.3 [mask.array.fill] mask_array fill function</p> <blockquote> <p>Change the function declaration</p> @@ -5065,7 +5420,7 @@ is not. For example, look at slice_array. This operator= in Section </pre> </blockquote> -<p>26.5.9 [template.indirect.array] Template class indirect_array</p> +<p>26.6.9 [template.indirect.array] Template class indirect_array</p> <blockquote> <p>In the class template definition for indirect_array, replace the member @@ -5077,7 +5432,7 @@ is not. For example, look at slice_array. This operator= in Section </pre> </blockquote> -<p>26.5.9.3 [indirect.array.fill] indirect_array fill function</p> +<p>26.6.9.3 [indirect.array.fill] indirect_array fill function</p> <blockquote> <p>Change the function declaration</p> @@ -5106,18 +5461,18 @@ 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>Section:</b> 22.4.1.2 [locale.ctype.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Judy Ward <b>Opened:</b> 1998-12-15 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p> <p><b>Discussion:</b></p> -<p>In Section 22.2.1.2 [locale.ctype.byname] +<p>In Section 22.4.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 +<p>Change Section 22.4.1.2 [locale.ctype.byname] <tt>do_scan_is()</tt> and <tt>do_scan_not()</tt> to return a <tt> const charT*</tt>. </p> @@ -5127,20 +5482,20 @@ 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>Section:</b> 26.6.2 [template.valarray] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Judy Ward <b>Opened:</b> 1998-12-15 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p> <p><b>Discussion:</b></p> -<p>In Section 26.5.2 [template.valarray] valarray<T>::operator!() +<p>In Section 26.6.2 [template.valarray] valarray<T>::operator!() is -declared to return a valarray<T>, but in Section 26.5.2.5 +declared to return a valarray<T>, but in Section 26.6.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 +<p>Change in Section 26.6.2 [template.valarray] the declaration of <tt>operator!()</tt> so that the return type is <tt>valarray<bool></tt>. </p> @@ -5149,14 +5504,14 @@ latter appears to be correct. </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>Section:</b> 22.4.1.1.2 [locale.ctype.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Judy Ward <b>Opened:</b> 1998-12-15 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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> +<p>In Section 22.4.1.1.2 [locale.ctype.virtuals] change: </p> <pre> do_widen(do_narrow(c),0) == c</pre> @@ -5178,10 +5533,11 @@ latter appears to be correct. </p> <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>Section:</b> D.9.1 [auto.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Greg Colvin <b>Opened:</b> 1999-02-17 <b>Last modified:</b> 2008-09-26</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#auto.ptr">active issues</a> in [auto.ptr].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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> @@ -5219,7 +5575,7 @@ object parameter may be bound to an rvalue [13.3.3.1.4/3] <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], + <p>In 20.6.4 [meta.unary], paragraph 2, and 20.6.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> @@ -5227,17 +5583,17 @@ object parameter may be bound to an rvalue [13.3.3.1.4/3] <p><b>Proposed resolution:</b></p> -<p>In 20.5.4 [meta.unary], paragraph 2, move +<p>In 20.6.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 +<p>In 20.6.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> +<p>Also add the assignment operator to 20.6.4.3 [meta.unary.prop]: </p> <blockquote> <pre>auto_ptr& operator=(auto_ptr_ref<X> r) throw()</pre> @@ -5254,10 +5610,10 @@ a public assignment operator to the <tt>auto_ptr</tt> definition: </p> <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>Section:</b> 27.7.1.3 [istream.unformatted], 27.7.2.5 [ostream.seeks] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Angelika Langer <b>Opened:</b> 1999-02-22 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 @@ -5273,8 +5629,8 @@ 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> +27.7.1.3 [istream.unformatted] and to the Effects: clause of seekp() in +27.7.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>). @@ -5290,10 +5646,11 @@ stream state in case of failure.</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>Section:</b> 23.2.4 [associative.reqmts], 23.2.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Andrew Koenig <b>Opened:</b> 1999-03-02 <b>Last modified:</b> 2009-05-01</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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 @@ -5307,7 +5664,7 @@ 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 +In 23.2.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 @@ -5318,7 +5675,7 @@ is returned." </p> <p> -In 23.1.4 [associative.reqmts], in Table 69 Associative container +In 23.2.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 @@ -5327,10 +5684,10 @@ 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: +In 23.4.1 [map], in the <tt>map</tt> class synopsis; and +in 23.4.2 [multimap], in the <tt>multimap</tt> class synopsis; and +in 23.4.3 [set], in the <tt>set</tt> class synopsis; and +in 23.4.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); @@ -5370,9 +5727,9 @@ Redmond: formally voted into WP. <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>Section:</b> 23.3.4.2 [list.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 1999-03-06 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p> <p><b>Discussion:</b></p> <p>The description reads:</p> @@ -5389,7 +5746,7 @@ Redmond: formally voted into WP. <p><b>Proposed resolution:</b></p> -<p>Change 23.2.4.2 [list.capacity] paragraph 1 to:</p> +<p>Change 23.3.4.2 [list.capacity] paragraph 1 to:</p> <p>Effects:</p> @@ -5413,14 +5770,14 @@ 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>Section:</b> 23.4.1 [map] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 1999-03-06 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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, +<p>Insert in 23.4.1 [map], paragraph 2, after operator= in the map declaration:</p> <pre> allocator_type get_allocator() const;</pre> @@ -5430,9 +5787,9 @@ after operator= in the map declaration:</p> <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>Section:</b> 23.3.6.1 [vector.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 1999-03-06 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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> @@ -5442,7 +5799,7 @@ tradeoff for the implementor.</p> <p><b>Proposed resolution:</b></p> -<p>Change 23.2.6.1 [vector.cons], paragraph 1 to:</p> +<p>Change 23.3.6.1 [vector.cons], paragraph 1 to:</p> <p>-1- Complexity: The constructor template <class InputIterator> vector(InputIterator first, InputIterator last) @@ -5464,10 +5821,10 @@ is greater than or equal to 2. <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>Section:</b> 27.7.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 1999-03-06 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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 @@ -5540,12 +5897,12 @@ 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>Section:</b> 22.3.1 [locale] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Angelika Langer <b>Opened:</b> 1999-03-17 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p> <p><b>Discussion:</b></p> -<p>Section 22.1.1 [locale] says:</p> +<p>Section 22.3.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 @@ -5555,7 +5912,7 @@ 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]: +22.3.2 [locale.global.templates]: <br><br> template <class Facet> const Facet& use_facet(const locale& loc); <br> @@ -5581,10 +5938,11 @@ 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>Section:</b> 23.2.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Andrew Koenig <b>Opened:</b> 1999-03-30 <b>Last modified:</b> 2008-09-26</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#sequence.reqmts">active issues</a> in [sequence.reqmts].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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> @@ -5615,10 +5973,10 @@ with:</p> <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>Section:</b> 21.4.6.4 [string::insert], 21.4.6.6 [string::replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Arch Robison <b>Opened:</b> 1999-04-28 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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> @@ -5646,9 +6004,9 @@ proposed resolution.]</i></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>Section:</b> 25.5.8 [alg.lex.comparison] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 1999-06-20 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p> <p><b>Discussion:</b></p> <p>The lexicographical_compare complexity is specified as:<br> <br> @@ -5664,7 +6022,7 @@ 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> +<p>Change 25.5.8 [alg.lex.comparison] complexity to:</p> <blockquote><p> At most <tt>2*min((last1 - first1), (last2 - first2))</tt> applications of the corresponding comparison. @@ -5689,12 +6047,12 @@ right! (and Matt states this complexity in his book)</p> <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>Section:</b> 23.3.2.1 [deque.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Herb Sutter <b>Opened:</b> 1999-05-09 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 +<p>In 23.3.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> @@ -5719,7 +6077,7 @@ insert?</p> <p><b>Proposed resolution:</b></p> -<p>In 23.2.2.1 [deque.cons] paragraph 6, replace the Complexity description, including the +<p>In 23.3.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> @@ -5731,10 +6089,10 @@ typo):</p> <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>Section:</b> 26.4.6 [complex.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Angelika Langer <b>Opened:</b> 1999-05-12 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p> <p><b>Discussion:</b></p> <p>The extractor for complex numbers is specified as: </p> @@ -5794,7 +6152,7 @@ what the intent was. </p> <p><b>Proposed resolution:</b></p> -<p>After 26.3.6 [complex.ops] paragraph 14 (operator>>), add a +<p>After 26.4.6 [complex.ops] paragraph 14 (operator>>), add a Notes clause:</p> <blockquote> @@ -5818,10 +6176,10 @@ 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>Section:</b> 17.6.4.4 [global.functions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Lois Goldthwaite <b>Opened:</b> 1999-06-04 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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> @@ -5894,19 +6252,19 @@ was changed from "non-member" to "global or non-member. <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>Section:</b> 22.4.8 [facets.examples] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Jeremy Siek <b>Opened:</b> 1999-06-03 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p> <p><b>Discussion:</b></p> -<p>In 22.2.8 [facets.examples] paragraph 13, the do_truename() and +<p>In 22.4.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 +<p>In 22.4.8 [facets.examples] paragraph 13, insert "const" in two places:</p> <blockquote> <p><tt>string do_truename() const { return "Oui Oui!"; }<br> @@ -5918,15 +6276,15 @@ two places:</p> <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>Section:</b> 25.3.7 [alg.find.first.of] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Matt McClure <b>Opened:</b> 1999-06-30 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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> +<p>Change 25.3.7 [alg.find.first.of] paragraph 2 from:</p> <blockquote> <p>Returns: The first iterator i in the range [first1, last1) such @@ -5945,10 +6303,11 @@ that for some iterator j in the range [first2, last2) ...</p> <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>Section:</b> 23.2.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Ed Brey <b>Opened:</b> 1999-06-21 <b>Last modified:</b> 2008-09-26</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#sequence.reqmts">active issues</a> in [sequence.reqmts].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 @@ -5992,10 +6351,10 @@ iterators or certain kinds of iterators is unnecessary. <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>Section:</b> 22.4.1.1.2 [locale.ctype.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 1999-07-20 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 @@ -6004,7 +6363,7 @@ 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 +<p>In 22.4.1.1.2 [locale.ctype.virtuals] paragraphs 4 and 6, change the returns clause from:</p> <blockquote> <p>"... such that <tt>is(*p)</tt> @@ -6019,10 +6378,10 @@ 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>Section:</b> 22.4.1.3.2 [facet.ctype.char.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 1999-07-20 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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 @@ -6037,7 +6396,7 @@ 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] +<p>Change the returns clause in 22.4.1.3.2 [facet.ctype.char.members] paragraph 10 from:</p> <p> Returns: do_widen(low, high, to).</p> @@ -6045,7 +6404,7 @@ paragraph 10 from:</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> +<p>Change 22.4.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> @@ -6079,11 +6438,11 @@ 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>Section:</b> 22.4.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 1999-07-20 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 @@ -6093,7 +6452,7 @@ 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 +<p>In 22.4.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> @@ -6106,18 +6465,18 @@ Modifier table to say that for <tt>double</tt> a length modifier <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>Section:</b> 27.4 [iostream.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 1999-07-20 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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> +<tt>Init</tt> is defined. According to 27.4 [iostream.objects] paragraph 2 +it is defined as <tt>basic_ios::Init</tt>, according to 27.5.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 +<p>Change 27.4 [iostream.objects] paragraph 2 from "<tt>basic_ios::Init"</tt> to "<tt>ios_base::Init"</tt>.</p> @@ -6131,19 +6490,19 @@ 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>Section:</b> 27.5.2.3 [ios.base.locales] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 1999-07-20 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 +<tt>imbue()</tt>: in 27.5.2 [ios.base] the argument is passed as +<tt>locale const&</tt> (correct), in 27.5.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 +<p>In 27.5.2.3 [ios.base.locales] change the <tt>imbue</tt> argument from "<tt>locale const" to "locale const&".</tt></p> @@ -6152,10 +6511,10 @@ 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>Section:</b> 27.6.2.4.2 [streambuf.virt.buffer] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 1999-07-20 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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>: @@ -6170,7 +6529,7 @@ to do nothing.</p> <p><b>Proposed resolution:</b></p> -<p>Change 27.5.2.4.2 [streambuf.virt.buffer], paragraph 3, Default behavior, +<p>Change 27.6.2.4.2 [streambuf.virt.buffer], paragraph 3, Default behavior, to: "Default behavior: Does nothing. Returns this."</p> @@ -6178,9 +6537,9 @@ 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>Section:</b> 27.6.2.4.3 [streambuf.virt.get] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 1999-07-20 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 @@ -6191,7 +6550,7 @@ 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, +<p>Change 27.6.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> @@ -6201,10 +6560,10 @@ 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>Section:</b> 27.7.1.1 [istream] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 1999-07-20 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 @@ -6212,8 +6571,8 @@ is not defined. Probably, the referred function is <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], +<p>In 27.7.1.1 [istream], 27.7.1.3 [istream.unformatted], paragraph 1, +27.7.2.1 [ostream], paragraph 3, and 27.7.2.6.1 [ostream.formatted.reqmts], paragraph 1, change "<tt>exception()" to "exceptions()"</tt>.</p> @@ -6227,10 +6586,10 @@ 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>Section:</b> 27.7.1.2.2 [istream.formatted.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 1999-07-20 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 @@ -6238,7 +6597,7 @@ 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> +<p>Change 27.7.1.2.2 [istream.formatted.arithmetic] from:</p> <blockquote> <p>The first argument provides an object of the istream_iterator class...</p> </blockquote> @@ -6253,11 +6612,11 @@ an object of type <tt>istreambuf_iterator</tt>.</p> <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>Section:</b> 22.4.5.3.2 [locale.time.put.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Angelika Langer <b>Opened:</b> 1999-07-23 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 +<p>In 22.4.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 @@ -6269,7 +6628,7 @@ 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] +<p>Add the following note after 22.4.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 @@ -6287,10 +6646,10 @@ 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>Section:</b> 27.7.2.1 [ostream] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 1999-07-20 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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" @@ -6347,10 +6706,10 @@ 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>Section:</b> 27.7.2.6.4 [ostream.inserters.character] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 1999-07-20 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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 @@ -6362,7 +6721,7 @@ const*</tt>.</p> <p><b>Proposed resolution:</b></p> -<p>Change 27.6.2.6.4 [ostream.inserters.character] paragraph 4 from:</p> +<p>Change 27.7.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 @@ -6427,10 +6786,10 @@ 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>Section:</b> 27.7.2.7 [ostream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 1999-07-20 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 @@ -6438,7 +6797,7 @@ 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 +<p>In 27.7.2.7 [ostream.unformatted] paragraph 1, the first and last sentences, change the word "formatted" to "unformatted":</p> <blockquote> @@ -6452,15 +6811,15 @@ sentences, change the word "formatted" to <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>Section:</b> 27.8.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 1999-07-20 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 +member functions are not allowed to use <tt>xsputn()</tt> (see 27.7.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 @@ -6469,7 +6828,7 @@ 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 +<p>In 27.8.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 @@ -6483,13 +6842,13 @@ solution is to handle this in <tt>underflow()</tt>.</p> <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>Section:</b> 27.8.4 [stringstream] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 1999-07-20 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 +<p>The classes <tt>basic_stringstream</tt> (27.8.4 [stringstream]), +<tt>basic_istringstream</tt> (27.8.2 [istringstream]), and +<tt>basic_ostringstream</tt> (27.8.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> @@ -6497,8 +6856,8 @@ 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> +<tt>basic_ostringstream</tt> (27.8.3 [ostringstream]) and +<tt>basic_stringstream</tt> (27.8.4 [stringstream]) add:</p> <blockquote> <pre>typedef traits traits_type;</pre> </blockquote> @@ -6508,12 +6867,12 @@ not. This should be consistent.</p> <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>Section:</b> 27.9.1.5 [filebuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 1999-07-20 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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 +<p>Overridden virtual functions, seekpos()</p> <p>In 27.9.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 @@ -6574,14 +6933,14 @@ paragraph 14 from:</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>Section:</b> 27.7.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Greg Comeau, Dietmar Kühl <b>Opened:</b> 1999-07-23 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p> <p><b>Discussion:</b></p> -<p>In 27.6.1.1 [istream] the function +<p>In 27.7.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] +argument. However, in 27.7.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 @@ -6598,7 +6957,7 @@ 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 +<p>In 27.7.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> @@ -6607,16 +6966,16 @@ of <tt>int</tt> in the description of <tt>ignore()</tt> to <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>Section:</b> 27.9.1.5 [filebuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Greg Comeau, Dietmar Kühl <b>Opened:</b> 1999-07-23 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p> <p><b>Discussion:</b></p> <p> -In 27.8.1.1 [filebuf] the function <tt>setbuf()</tt> gets an +In 27.9.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 +27.9.1.5 [filebuf.virtuals] paragraph 9 the second argument is of type <tt>int</tt>. </p> @@ -6631,7 +6990,7 @@ as described in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-d <p><b>Proposed resolution:</b></p> -<p>In 27.8.1.5 [filebuf.virtuals] paragraph 9, change all uses of +<p>In 27.9.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> @@ -6640,10 +6999,10 @@ as described in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-d <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>Section:</b> D.6 [depr.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 1999-07-23 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 @@ -6660,10 +7019,10 @@ 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>Section:</b> D.6 [depr.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 1999-07-23 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p> <p><b>Discussion:</b></p> <p>According to paragraph 8 of this section, the methods <tt>basic_streambuf::pubseekpos()</tt>, @@ -6689,10 +7048,10 @@ argument is not specified.</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>Section:</b> D.6 [depr.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 1999-07-23 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 @@ -6711,11 +7070,11 @@ 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>Section:</b> 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Judy Ward <b>Opened:</b> 1998-07-02 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p>Currently the following will not compile on two well-known standard library implementations:</p> @@ -6791,7 +7150,7 @@ return i == ci; <p><b>Proposed resolution:</b></p> -<p>Insert this paragraph after 23.1 [container.requirements] paragraph 7:</p> +<p>Insert this paragraph after 23.2 [container.requirements] paragraph 7:</p> <blockquote> <p>In the expressions</p> <pre> i == j @@ -6833,11 +7192,148 @@ separate issue. (Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg <hr> +<h3><a name="180"></a>180. Container member iterator arguments constness has unintended consequences</h3> +<p><b>Section:</b> 21.4 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 1999-07-01 <b>Last modified:</b> 2008-09-26</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#CD1">CD1</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.4 [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.4.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.4.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="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>Section:</b> 20.3.3 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Andrew Koenig <b>Opened:</b> 1999-08-03 <b>Last modified:</b> 2008-09-26</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#pairs">active issues</a> in [pairs].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p> <p><b>Discussion:</b></p> <p>The claim has surfaced in Usenet that expressions such as<br> <br> @@ -6851,7 +7347,7 @@ I doubt anyone intended that behavior... <p><b>Proposed resolution:</b></p> -<p>In 20.2 [utility], paragraph 1 change the following +<p>In 20.3 [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> @@ -6860,7 +7356,7 @@ declaration of make_pair():</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> +<p> In 20.3.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> @@ -6893,14 +7389,15 @@ 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>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Al Stevens <b>Opened:</b> 1999-08-15 <b>Last modified:</b> 2008-09-26</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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> +example, 17.6.3.6 [replacement.functions] paragraph 2:</p> <blockquote> <pre> operator new(size_t) operator new(size_t, const std::nothrow_t&) @@ -6910,7 +7407,7 @@ example, 17.4.3.5 [replacement.functions] paragraph 2:</p> <p><b>Proposed resolution:</b></p> -<p> In 17.4.3.5 [replacement.functions] paragraph 2: replace:</p> +<p> In 17.6.3.6 [replacement.functions] paragraph 2: replace:</p> <blockquote> <p><tt> - operator new(size_t)<br> - operator new(size_t, const std::nothrow_t&)<br> @@ -6987,7 +7484,7 @@ declaration of template <class charT> class ctype.<br> <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> +ptrdiff_t meant anyway because, according to 17.6.3.3.4 [extern.types],</p> <blockquote><p> For each type T from the Standard C library, the types ::T and std::T @@ -7020,12 +7517,12 @@ 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>Section:</b> 27.7.3 [std.manip] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Andy Sawyer <b>Opened:</b> 1999-07-07 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> -<p>27.6.3 [std.manip] paragraph 3 says (clause numbering added for +<p>27.7.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 @@ -7055,7 +7552,7 @@ basic_ostream as out"&</p> <p><b>Proposed resolution:</b></p> -<p>Replace section 27.6.3 [std.manip] except paragraph 1 with the +<p>Replace section 27.7.3 [std.manip] except paragraph 1 with the following:</p> <blockquote> <p>2- The type designated smanip in each of the following function @@ -7220,10 +7717,10 @@ 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>Section:</b> 18.3.1.5 [numeric.special] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Gabriel Dos Reis <b>Opened:</b> 1999-07-21 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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" @@ -7266,7 +7763,7 @@ 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> +<p>Append to the end of 18.3.1.5 [numeric.special]:</p> <blockquote> <p>The specialization for bool shall be provided as follows:</p> <pre> namespace std { @@ -7326,12 +7823,12 @@ 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>Section:</b> 20.7 [function.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> UK Panel <b>Opened:</b> 1999-07-26 <b>Last modified:</b> 2008-09-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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> -<p>Paragraph 4 of 20.6 [function.objects] says:</p> +<p>Paragraph 4 of 20.7 [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 @@ -7358,17 +7855,17 @@ not required elsewhere.</p> <p><b>Proposed resolution:</b></p> -<p>In 20.6 [function.objects] paragraph 1, remove the sentence:</p> +<p>In 20.7 [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> +<p>Remove 20.7 [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> +<p>In 20.7 [function.objects] paragraph 4, remove the sentence:</p> <blockquote> <p>The corresponding functions will inline the addition and the negation.</p> @@ -7385,12 +7882,12 @@ not required elsewhere.</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>Section:</b> 20.3.6.2 [bitset.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Darin Adler <b>Opened:</b> 1999-08-13 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> -<p>In section 23.3.5.2 [bitset.members], paragraph 13 defines the +<p>In section 20.3.6.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 @@ -7402,7 +7899,7 @@ 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> +<p>In 20.3.6 [template.bitset] Para 1 Replace:</p> <blockquote> <pre>bitset<N>& set(size_t pos, int val = true ); </pre> </blockquote> @@ -7410,7 +7907,7 @@ translating 0 to false and any non-zero value to true.</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> +<p>In 20.3.6.2 [bitset.members] Para 12(.5) Replace:</p> <blockquote> <pre>bitset<N>& set(size_t pos, int val = 1 );</pre> </blockquote> @@ -7439,10 +7936,10 @@ 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>Section:</b> 25.4.3 [alg.swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Andrew Koenig <b>Opened:</b> 1999-08-14 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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 @@ -7510,10 +8007,10 @@ 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>Section:</b> 27.5.2.2 [fmtflags.state] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Andrew Koenig <b>Opened:</b> 1999-08-25 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 @@ -7529,7 +8026,7 @@ 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 +<p>Remove from 27.5.2.2 [fmtflags.state], paragraph 9, the text "(number of digits after the decimal point)".</p> @@ -7537,9 +8034,9 @@ correct the statement in 27.4.2.2</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>Section:</b> 25.5.6 [alg.heap.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Markus Mauhart <b>Opened:</b> 1999-09-24 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 @@ -7562,7 +8059,7 @@ priority AND time).</p> <p><b>Proposed resolution:</b></p> -<p>Change 25.3.6 [alg.heap.operations] property (1) from:</p> +<p>Change 25.5.6 [alg.heap.operations] property (1) from:</p> <blockquote> <p>(1) *a is the largest element</p> </blockquote> @@ -7577,10 +8074,10 @@ priority AND time).</p> <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>Section:</b> 27.7.1.1.3 [istream::sentry] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Matt Austern <b>Opened:</b> 1999-10-13 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 @@ -7588,9 +8085,9 @@ 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 +<p>On the one hand, nothing in 27.7.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 +other hand, 27.7.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 @@ -7636,11 +8133,11 @@ returns <tt>traits::eof()</tt>, the function calls <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>Section:</b> 24.2 [iterator.concepts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Beman Dawes <b>Opened:</b> 1999-11-03 <b>Last modified:</b> 2008-09-30</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iterator.concepts">active issues</a> in [iterator.concepts].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.concepts">issues</a> in [iterator.concepts].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> Is a pointer or reference obtained from an iterator still valid after @@ -7688,14 +8185,14 @@ 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 +change. The definition of reverse_iterator::operator*(), 24.5.1.2.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 +<p>The definition of reverse_iterator::operator->(), 24.5.1.2.4 [reverse.iter.op.star], which returns a pointer, defines effects:</p> <blockquote> <pre>return &(operator*());</pre> @@ -7709,13 +8206,13 @@ implementation.</p> <p><b>Proposed resolution:</b></p> -<p>Add a new paragraph to 24.1 [iterator.requirements]:</p> +<p>Add a new paragraph to 24.2 [iterator.concepts]:</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> +<p>Replace paragraph 1 of 24.5.1.2.3 [reverse.iter.conv] with:</p> <blockquote> <p><b>Effects:</b></p> @@ -7728,7 +8225,7 @@ previously obtained from that iterator. [<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 +24.2 [iterator.concepts].) The name of this member variable is shown for exposition only. <i>--end note</i>] </p> </blockquote> @@ -7746,7 +8243,7 @@ reformulated yet again to reflect this reality.]</i></p> 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 +However, this issue is related to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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> @@ -7778,11 +8275,11 @@ 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>Section:</b> X [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Matt Austern <b>Opened:</b> 1999-11-19 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p> <p><b>Discussion:</b></p> <p> Suppose that <tt>A</tt> is a class that conforms to the @@ -7814,10 +8311,10 @@ would be over-specification to mandate the return value. <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>Section:</b> 24.2.4 [forward.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Matt Austern <b>Opened:</b> 1999-11-19 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> In table 74, the return type of the expression <tt>*a</tt> is given @@ -7842,7 +8339,7 @@ otherwise <tt>const U&</tt>". <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 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#180">180</a> has already been declared NAD Future for that very reason.]</i></p> @@ -7860,10 +8357,10 @@ 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>Section:</b> 18.3.1 [limits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Stephen Cleary <b>Opened:</b> 1999-12-21 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> In some places in this section, the terms "fundamental types" and @@ -7882,7 +8379,7 @@ specializations of numeric_limits. <p><b>Proposed resolution:</b></p> <p> -Change 18.2 [support.limits] to: +Change 18.3 [support.limits] to: </p> <blockquote> @@ -7895,7 +8392,7 @@ characteristics of implementation-dependent <del>fundamental</del> </blockquote> <p> -Change 18.2.1 [limits] to: +Change 18.3.1 [limits] to: </p> <blockquote> @@ -7918,7 +8415,7 @@ as <tt>complex<T></tt> (26.3.2), shall not have specializations. </blockquote> <p> -Change 18.2.1.1 [numeric.limits] to: +Change 18.3.1.1 [numeric.limits] to: </p> <blockquote> @@ -7936,10 +8433,11 @@ which do not.</del> <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>Section:</b> 25.4.9 [alg.unique] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Andrew Koenig <b>Opened:</b> 2000-01-13 <b>Last modified:</b> 2008-09-26</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#alg.unique">active issues</a> in [alg.unique].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> What should unique() do if you give it a predicate that is not an @@ -8009,7 +8507,7 @@ In fact, the SGI implementation of unique() does neither: It yields 1, <p><b>Proposed resolution:</b></p> -<p>Change 25.2.9 [alg.unique] paragraph 1 to:</p> +<p>Change 25.4.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 @@ -8044,7 +8542,7 @@ 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> +25.4.9 [alg.unique] paragraph 1 to:</p> <blockquote><p> For a nonempty range, eliminates all but the first element from every @@ -8073,10 +8571,10 @@ 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>Section:</b> 18.6.1.1 [new.delete.single] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 1999-08-29 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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 @@ -8370,11 +8868,11 @@ his customers. <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>Section:</b> 24.2 [iterator.concepts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Stephen Cleary <b>Opened:</b> 2000-02-02 <b>Last modified:</b> 2008-09-30</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iterator.concepts">active issues</a> in [iterator.concepts].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.concepts">issues</a> in [iterator.concepts].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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> @@ -8389,7 +8887,7 @@ 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> +<p>Change 24.2 [iterator.concepts] paragraph 5, the last sentence, from:</p> <blockquote> <p>Dereferenceable and past-the-end values are always non-singular.</p> </blockquote> @@ -8410,13 +8908,13 @@ iterators. Null pointers are singular. <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>Section:</b> 21.4 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Igor Stauder <b>Opened:</b> 2000-02-11 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p> <p><b>Discussion:</b></p> -<p>In Section 21.3 [basic.string] the basic_string member function +<p>In Section 21.4 [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); @@ -8431,7 +8929,7 @@ basic_string<charT,traits,Allocator>&</p> <p><b>Proposed resolution:</b></p> -<p>In Section 21.3 [basic.string] change the basic_string member +<p>In Section 21.4 [basic.string] change the basic_string member function declarations push_back, assign, and swap to:</p> <blockquote> <pre>void push_back(charT c); @@ -8453,10 +8951,10 @@ change. <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>Section:</b> 25 [algorithms] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Lisa Lippincott <b>Opened:</b> 2000-02-15 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p> <p><b>Discussion:</b></p> <p>In paragraph 9 of section 25 [algorithms], it is written:</p> <blockquote> @@ -8484,10 +8982,10 @@ 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>Section:</b> 21.4.8.9 [string.io] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Scott Snyder <b>Opened:</b> 2000-02-04 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 @@ -8502,14 +9000,14 @@ 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 +which do include this requirement. (See sections 27.7.1.2 [istream.formatted] and 27.7.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> +of getline (istream&, string&, charT) in section 21.4.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> +<p>Insert new paragraph after paragraph 2 in section 21.4.8.9 [string.io]:</p> <blockquote> <p>If the function extracts no characters, it calls @@ -8522,10 +9020,11 @@ is.setstate(ios::failbit) which may throw ios_base::failure <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>Section:</b> 25.5.7 [alg.min.max] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 2000-02-26 <b>Last modified:</b> 2008-09-26</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#alg.min.max">active issues</a> in [alg.min.max].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 @@ -8534,7 +9033,7 @@ 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 +<p>In 25.5.7 [alg.min.max] - Minimum and maximum, paragraphs 7 and 9, append: Returns last if first==last.</p> @@ -8549,10 +9048,10 @@ 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>Section:</b> 23.4.3 [set], 23.4.4 [multiset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Judy Ward <b>Opened:</b> 2000-02-28 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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 @@ -8567,7 +9066,7 @@ and multiset do not, all they have is:</p> <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> +equal_range() in section 23.4.3 [set] and section 23.4.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> @@ -8590,10 +9089,10 @@ 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>Section:</b> 22.4.8 [facets.examples] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-02-29 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 @@ -8644,9 +9143,9 @@ declared above.</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>Section:</b> 27.5.2.7 [ios.base.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Jonathan Schilling, Howard Hinnant <b>Opened:</b> 2000-03-13 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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> @@ -8696,11 +9195,11 @@ initializations have taken place, the behavior is undefined.</p> <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>Section:</b> 22.4.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Matt Austern <b>Opened:</b> 2000-03-14 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p>Stage 2 processing of numeric conversion is broken.</p> @@ -8744,10 +9243,11 @@ 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>Section:</b> 17.5.1.4 [structure.specifications] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Judy Ward <b>Opened:</b> 2000-03-17 <b>Last modified:</b> 2008-09-26</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#structure.specifications">active issues</a> in [structure.specifications].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p> <p><b>Discussion:</b></p> <p>Section 21.3.6.8 describes the basic_string::compare function this way:</p> <blockquote> @@ -8764,7 +9264,7 @@ int compare(size_type pos1, size_type n1, </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> +section 21.4.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 @@ -8775,7 +9275,7 @@ missing?</p> <p><b>Proposed resolution:</b></p> -<p>In 17.3.1.3 [structure.specifications] paragraph 3, the footnote 148 attached to +<p>In 17.5.1.4 [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> @@ -8798,15 +9298,15 @@ 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>Section:</b> 25.4.10 [alg.reverse] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2000-03-21 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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> +<p>In 25.4.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. @@ -8822,10 +9322,11 @@ footnote.</p> <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>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Ed Brey <b>Opened:</b> 2000-03-23 <b>Last modified:</b> 2008-09-26</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</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 @@ -8849,10 +9350,10 @@ 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>Section:</b> 17.6.4.4 [global.functions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2000-04-01 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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> @@ -8916,7 +9417,7 @@ 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> +17.6.4.4 [global.functions]:</p> <blockquote> <p>Unless otherwise specified, no global or non-member function in the @@ -8981,10 +9482,10 @@ resolution for this issue is in accordance with Howard's paper.]</i></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>Section:</b> 17.6.3.3 [reserved.names] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2000-04-01 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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 @@ -9163,7 +9664,7 @@ resolution is the one proposed by Howard.]</i></p> (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, + to <tt>swap</tt>. Also, in 26.6.3.3 [valarray.transcend] paragraph 1, state that the valarray transcendentals use unqualified lookup.</p> @@ -9172,10 +9673,10 @@ resolution is the one proposed by Howard.]</i></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>Section:</b> 25.4.3 [alg.swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a> + <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2000-04-09 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC1">TC1</a> status.</p> <p><b>Discussion:</b></p> <p>25.2.2 reads:</p> <blockquote> @@ -9225,17 +9726,17 @@ resolution is the one proposed by Howard.]</i></p> <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>Section:</b> 22.4 [locale.categories] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 2000-04-20 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> -<p>The sections 22.2.1.2 [locale.ctype.byname], 22.2.1.5 +<p>The sections 22.4.1.2 [locale.ctype.byname], 22.4.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] +sref ref="22.2.1.6", 22.4.3.2 [locale.numpunct.byname], 22.4.4.2 +[locale.collate.byname], 22.4.5.4 [locale.time.put.byname], 22.4.6.4 +[locale.moneypunct.byname], and 22.4.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 @@ -9357,12 +9858,12 @@ specialization it is not virtual.</p> ~messages_byname(); // virtual }; }</pre> -<p>Remove section 22.2.1.4 [locale.codecvt] completely (because in +<p>Remove section 22.4.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> +the LWG to solve the underlying problems raised by issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#138">138</a>.]</i></p> <p><i>[Copenhagen: proposed resolution was revised slightly, to remove @@ -9376,9 +9877,11 @@ 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>Section:</b> 17.6.1.1 [contents] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Steve Clamage <b>Opened:</b> 2000-04-19 <b>Last modified:</b> 2008-09-26</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#contents">active issues</a> in [contents].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#contents">issues</a> in [contents].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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> @@ -9441,10 +9944,11 @@ 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>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2000-04-26 <b>Last modified:</b> 2008-09-26</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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 @@ -9454,21 +9958,21 @@ 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> +specified. For example, X [rand.req].</p> <p><b>Proposed resolution:</b></p> -<p>In 23.1 [container.requirements] table 65 for value_type: +<p>In 23.2 [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 +<p>In 23.2.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>In 24.2.3 [output.iterators] paragraph 1, change: </p> <blockquote> <p> A class or a built-in type X satisfies the requirements of an @@ -9487,7 +9991,7 @@ Table 73: </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 +the LWG. He asks that the 25.4.5 [alg.replace] and 25.4.6 [alg.fill] changes be studied carefully, as it is not clear that CopyConstructible is really a requirement and may be overspecification.]</i></p> @@ -9511,10 +10015,10 @@ 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>Section:</b> 22.4.2.2.2 [facet.num.put.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> James Kanze, Stephen Clamage <b>Opened:</b> 2000-04-25 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p>What is the following program supposed to output?</p> <pre>#include <iostream> @@ -9558,7 +10062,7 @@ 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 +Replace 22.4.2.2.2 [facet.num.put.virtuals], paragraph 11, with the following sentence: </p> <blockquote><p> @@ -9594,10 +10098,10 @@ 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>Section:</b> 17.6.3.3 [reserved.names] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2000-04-18 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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 @@ -9647,10 +10151,11 @@ 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>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Andrew Koenig <b>Opened:</b> 2000-04-30 <b>Last modified:</b> 2008-09-26</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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> @@ -9755,7 +10260,7 @@ is no longer needed (or reflected in the proposed wording below). <p> Change the indicated rows of the "Associative container requirements" Table in -23.1.4 [associative.reqmts] to: +23.2.4 [associative.reqmts] to: </p> <p></p><center> @@ -9798,10 +10303,10 @@ logarithmic in general, but amortized constant if <tt>t</tt> is inserted right < <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>Section:</b> 20.8.6.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 2000-04-24 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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 @@ -9816,9 +10321,9 @@ return <tt>void</tt>.</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>Section:</b> 24.5.1.1 [reverse.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 2000-04-24 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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 @@ -9826,7 +10331,7 @@ should do.</p> <p><b>Proposed resolution:</b></p> - <p>In section 24.4.1.3.1 [reverse.iter.cons] add the following + <p>In section 24.5.1.2.1 [reverse.iter.cons] add the following paragraph:</p> <blockquote> <p><tt>reverse_iterator()</tt></p> @@ -9846,10 +10351,10 @@ should do.</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>Section:</b> 23.3.2.1 [deque.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 2000-04-24 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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 @@ -9868,9 +10373,9 @@ would have to be <tt>last - first</tt>.</p> <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>Section:</b> 27.8.1.1 [stringbuf.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 2000-05-11 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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 @@ -9905,10 +10410,11 @@ 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>Section:</b> 25.4.9 [alg.unique] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Angelika Langer <b>Opened:</b> 2000-05-15 <b>Last modified:</b> 2008-09-26</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#alg.unique">active issues</a> in [alg.unique].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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 @@ -9938,7 +10444,7 @@ twice.</p> <p><b>Proposed resolution:</b></p> -<p>Change both complexity sections in 25.2.9 [alg.unique] to:</p> +<p>Change both complexity sections in 25.4.9 [alg.unique] to:</p> <blockquote><p>Complexity: For nonempty ranges, exactly last - first - 1 applications of the corresponding predicate.</p></blockquote> @@ -9950,9 +10456,10 @@ 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>Section:</b> 25.3.8 [alg.adjacent.find] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Angelika Langer <b>Opened:</b> 2000-05-15 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.adjacent.find">issues</a> in [alg.adjacent.find].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p>The complexity section of adjacent_find is defective:</p> @@ -9990,7 +10497,7 @@ 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> +<p>Change the complexity section in 25.3.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 @@ -10009,10 +10516,11 @@ 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>Section:</b> 25.4.9 [alg.unique] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Angelika Langer <b>Opened:</b> 2000-05-15 <b>Last modified:</b> 2008-09-26</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#alg.unique">active issues</a> in [alg.unique].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p>Some popular implementations of unique_copy() create temporary @@ -10024,7 +10532,7 @@ the value type is CopyConstructible and Assignable.</p> 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> +is accumulate(), X [rand.req].</p> <p>Since the specifications of unique() and unique_copy() do not require CopyConstructible and Assignable of the InputIterator's value @@ -10078,10 +10586,10 @@ minor as not to require re-review. <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>Section:</b> 25.4.4 [alg.transform], 26.5 [rand] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Angelika Langer <b>Opened:</b> 2000-05-15 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p>The algorithms transform(), accumulate(), inner_product(), partial_sum(), and adjacent_difference() require that the function @@ -10266,10 +10774,10 @@ 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>Section:</b> 27.7.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-05-15 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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 @@ -10326,12 +10834,12 @@ 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>Section:</b> 23.3.6.4 [vector.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Lisa Lippincott <b>Opened:</b> 2000-06-06 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> -<p>Paragraph 2 of 23.2.6.4 [vector.modifiers] describes the complexity +<p>Paragraph 2 of 23.3.6.4 [vector.modifiers] describes the complexity of <tt>vector::insert</tt>:</p> <blockquote><p> @@ -10352,7 +10860,7 @@ 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], +complexity of inserting multiple elements (23.3.2.3 [deque.modifiers], paragraph 3):</p> <blockquote><p> @@ -10368,7 +10876,7 @@ paragraph 3):</p> <p><b>Proposed resolution:</b></p> -<p>Change Paragraph 2 of 23.2.6.4 [vector.modifiers] to</p> +<p>Change Paragraph 2 of 23.3.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. @@ -10379,7 +10887,7 @@ paragraph 3):</p> <tt>rotate</tt>.]</i></p> -<p>Change 23.2.2.3 [deque.modifiers], paragraph 3, to:</p> +<p>Change 23.3.2.3 [deque.modifiers], paragraph 3, to:</p> <blockquote><p> Complexity: The complexity is linear in the number of elements @@ -10404,9 +10912,9 @@ paragraph 3):</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>Section:</b> 22.4.5 [category.time] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-06-22 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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. @@ -10434,13 +10942,13 @@ 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>Section:</b> 23.3.4.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Brian Parker <b>Opened:</b> 2000-07-14 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> -Section 23.2.4.4 [list.ops] states that +Section 23.3.4.4 [list.ops] states that </p> <pre> void splice(iterator position, list<T, Allocator>& x); </pre> @@ -10457,14 +10965,14 @@ after <tt>splice</tt>. <p><b>Proposed resolution:</b></p> -<p>Add a footnote to 23.2.4.4 [list.ops], paragraph 1:</p> +<p>Add a footnote to 23.3.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> +<p>In 23.3.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 @@ -10473,7 +10981,7 @@ 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> +<p>In 23.3.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 @@ -10483,7 +10991,7 @@ to refer to this same element but as a member of *this. Iterators to *i behave as iterators into *this, not into x. </p></blockquote> -<p>In 23.2.4.4 [list.ops], replace paragraph 12 with:</p> +<p>In 23.3.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). @@ -10509,9 +11017,9 @@ 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>Section:</b> 27.8.1 [stringbuf] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-07-28 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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 @@ -10533,10 +11041,10 @@ basic_stringstream (27.7.4) the typedef:</p> <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>Section:</b> 27.8 [string.streams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-07-28 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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(). @@ -10579,11 +11087,11 @@ issue is stylistic rather than a matter of correctness.</p> <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>Section:</b> 26.6.2.1 [valarray.cons], 26.6.2.2 [valarray.assign] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Robert Klarer <b>Opened:</b> 2000-07-31 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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 @@ -10661,53 +11169,53 @@ classes are almost entirely useless.</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> + public in the slice_array class template definition in 26.6.5 [template.slice.array] </li> +<li> remove paragraph 3 of 26.6.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> remove the first sentence of paragraph 1 of 26.6.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> + 26.6.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> + public in the gslice_array class template definition in 26.6.7 [template.gslice.array] </li> +<li> remove the note in paragraph 3 of 26.6.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> remove the first sentence of paragraph 1 of 26.6.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> + 26.6.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> + public in the mask_array class template definition in 26.6.8 [template.mask.array] </li> +<li> remove the note in paragraph 2 of 26.6.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> remove the first sentence of paragraph 1 of 26.6.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> + 26.6.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> + public in the indirect_array class definition in 26.6.9 [template.indirect.array]</li> +<li> remove the note in paragraph 2 of 26.6.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> remove the first sentence of paragraph 1 of 26.6.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> + 26.6.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 @@ -10733,9 +11241,9 @@ 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>Section:</b> 19.2 [std.exceptions], 27.5.2.1.1 [ios::failure] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2000-08-01 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> Many of the standard exception types which implementations are @@ -10836,8 +11344,8 @@ 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: +throw: change the postconditions of 19.2.2 [domain.error] paragraph 3 +and 19.2.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 @@ -10856,7 +11364,7 @@ throw, the string must compare equal to the argument.</li> <p><b>Proposed resolution:</b></p> <p> -Change 19.1.1 [logic.error] +Change 19.2.1 [logic.error] </p> <blockquote> @@ -10884,7 +11392,7 @@ Change 19.1.1 [logic.error] </blockquote> <p> -Change 19.1.2 [domain.error] +Change 19.2.2 [domain.error] </p> <blockquote> @@ -10912,7 +11420,7 @@ Change 19.1.2 [domain.error] </blockquote> <p> -Change 19.1.3 [invalid.argument] +Change 19.2.3 [invalid.argument] </p> <blockquote> @@ -10940,7 +11448,7 @@ Change 19.1.3 [invalid.argument] </blockquote> <p> -Change 19.1.4 [length.error] +Change 19.2.4 [length.error] </p> <blockquote> @@ -10968,7 +11476,7 @@ Change 19.1.4 [length.error] </blockquote> <p> -Change 19.1.5 [out.of.range] +Change 19.2.5 [out.of.range] </p> <blockquote> @@ -10996,7 +11504,7 @@ Change 19.1.5 [out.of.range] </blockquote> <p> -Change 19.1.6 [runtime.error] +Change 19.2.6 [runtime.error] </p> <blockquote> @@ -11024,7 +11532,7 @@ Change 19.1.6 [runtime.error] </blockquote> <p> -Change 19.1.7 [range.error] +Change 19.2.7 [range.error] </p> <blockquote> @@ -11052,7 +11560,7 @@ Change 19.1.7 [range.error] </blockquote> <p> -Change 19.1.8 [overflow.error] +Change 19.2.8 [overflow.error] </p> <blockquote> @@ -11080,7 +11588,7 @@ Change 19.1.8 [overflow.error] </blockquote> <p> -Change 19.1.9 [underflow.error] +Change 19.2.9 [underflow.error] </p> <blockquote> @@ -11108,7 +11616,7 @@ Change 19.1.9 [underflow.error] </blockquote> <p> -Change 27.4.2.1.1 [ios::failure] +Change 27.5.2.1.1 [ios::failure] </p> <blockquote> @@ -11183,11 +11691,11 @@ the need to explicit include or construct a <tt>std::string</tt>. <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>Section:</b> 27.5.4.2 [basic.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-08-21 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> 27.4.4.2, p17 says @@ -11214,11 +11722,11 @@ copyfmt_event. <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>Section:</b> X [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Matt Austern <b>Opened:</b> 2000-08-22 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> From lib-7752: @@ -11324,10 +11832,10 @@ issue to Ready status to be voted into the WP at Kona. <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>Section:</b> 21.4.4 [string.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Chris Newton <b>Opened:</b> 2000-08-27 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> <i>Paraphrased from a message that Chris Newton posted to comp.std.c++:</i> @@ -11358,10 +11866,10 @@ In section 21.3.4, paragraph 1, change <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>Section:</b> 24.6.1.2 [istream.iterator.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-08-27 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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 @@ -11384,10 +11892,10 @@ given the Effects clause below (since a temporary is returned). The <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>Section:</b> 24.6.1.2 [istream.iterator.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-08-27 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> 24.5.1, p3 lists the synopsis for @@ -11421,9 +11929,9 @@ Add paragraph 7 to the end of section 24.5.1.2 with the following text: <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>Section:</b> 17.5.2.1.3 [bitmask.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2000-09-03 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> The ~ operation should be applied after the cast to int_type. @@ -11452,11 +11960,11 @@ to: <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>Section:</b> 21.4 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Kevlin Henney <b>Opened:</b> 2000-09-04 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> The note in paragraph 6 suggests that the invalidation rules for @@ -11534,10 +12042,11 @@ Change the following sentence in 21.3 paragraph 5 from <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>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> John Potter <b>Opened:</b> 2000-09-07 <b>Last modified:</b> 2008-09-26</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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> @@ -11588,10 +12097,11 @@ linear in some special cases. <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>Section:</b> 20.3.3 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-09-11 <b>Last modified:</b> 2008-09-26</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#pairs">active issues</a> in [pairs].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> I don't see any requirements on the types of the elements of the @@ -11638,9 +12148,9 @@ 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>Section:</b> 18.8.2.1 [bad.exception] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-09-24 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> The synopsis for std::bad_exception lists the function ~bad_exception() @@ -11652,10 +12162,10 @@ clause is missing). <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]). +<tt>bad_alloc</tt> (18.6.2.1 [bad.alloc]), +<tt>bad_cast</tt> (18.7.3 [bad.cast]), +<tt>bad_typeid</tt> (18.7.4 [bad.typeid]), +and <tt>bad_exception</tt> (18.8.2.1 [bad.exception]). </p> @@ -11673,10 +12183,10 @@ described in clause 19. <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>Section:</b> 22.3.1 [locale] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-10-05 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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 @@ -11704,10 +12214,10 @@ are missing.</p> <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>Section:</b> 25.5.3 [alg.binary.search] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Matt Austern <b>Opened:</b> 2000-10-18 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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> @@ -11971,9 +12481,9 @@ 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>Section:</b> 27.7.1.5 [iostreamclass] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-11-02 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> Class template basic_iostream has no typedefs. The typedefs it @@ -11985,7 +12495,7 @@ basic_iostream<T>::traits_type is ambiguous. <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> +27.7.1.5 [iostreamclass], immediately after <tt>public</tt>:</p> <pre> // types: typedef charT char_type; @@ -12000,10 +12510,10 @@ basic_iostream<T>::traits_type is ambiguous. <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>Section:</b> 27.5.4.3 [iostate.flags] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-11-02 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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> @@ -12029,10 +12539,11 @@ Add parentheses like so: rdstate()==(state|ios_base::badbit). <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>Section:</b> 27 [input.output] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-11-02 <b>Last modified:</b> 2008-09-26</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#input.output">active issues</a> in [input.output].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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. @@ -12049,11 +12560,11 @@ 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>Section:</b> X [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-11-02 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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 @@ -12121,10 +12632,10 @@ 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>Section:</b> 22.4.2.1.1 [facet.num.get.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Matt Austern <b>Opened:</b> 2000-11-02 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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(). @@ -12166,7 +12677,7 @@ the arguments it was given. <p><b>Proposed resolution:</b></p> -<p>In 22.2.2.1.1 [facet.num.get.members], change</p> +<p>In 22.4.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> @@ -12180,15 +12691,15 @@ the arguments it was given. <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>Section:</b> 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2000-11-07 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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, +Assignable. 23.4.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. @@ -12336,13 +12847,13 @@ implement <tt>vector::push_back</tt> in terms of <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>Section:</b> 23.3.4.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2000-11-27 <b>Last modified:</b> 2008-09-30</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> -Section 23.2.4.4 [list.ops] states that +Section 23.3.4.4 [list.ops] states that </p> <pre> void splice(iterator position, list<T, Allocator>& x); </pre> @@ -12370,7 +12881,7 @@ introduce separate terms for the two kinds of "validity." <p><b>Proposed resolution:</b></p> -<p>Add the following text to the end of section 24.1 [iterator.requirements], +<p>Add the following text to the end of section 24.2 [iterator.concepts], after paragraph 5:</p> <blockquote><p> An <i>invalid</i> iterator is an iterator that may be @@ -12406,9 +12917,9 @@ the wording. Dave provided new wording.]</i></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>Section:</b> 24.5.1 [reverse.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Steve Cleary <b>Opened:</b> 2000-11-27 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> This came from an email from Steve Cleary to Fergus in reference to @@ -12435,7 +12946,7 @@ that, I don't see how <i>any</i> user code could break." <p><b>Proposed resolution:</b></p> <p> -<b>Section:</b> 24.4.1.1 [reverse.iterator] +<b>Section:</b> 24.5.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.: @@ -12461,7 +12972,7 @@ add/change the following declarations:</p> </pre> <p> Also make the addition/changes for these signatures in -24.4.1.3 [reverse.iter.ops]. +24.5.1.2 [reverse.iter.ops]. </p> <p><i>[ @@ -12486,15 +12997,16 @@ this solution is safe and correct. <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>Section:</b> 25.5.7 [alg.min.max] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-12-02 <b>Last modified:</b> 2008-09-26</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#alg.min.max">active issues</a> in [alg.min.max].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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]). +and <tt>CopyConstructible</tt> (X [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. @@ -12517,10 +13029,10 @@ is unnecessary. <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>Section:</b> 22.4.2.2.2 [facet.num.put.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2000-12-05 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> Paragraph 16 mistakenly singles out integral types for inserting @@ -12535,7 +13047,7 @@ point numbers described under 22.2.3.1/2. <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]. +using the method described in 22.4.3.1.2 [facet.numpunct.virtuals]. </p></blockquote> <p>To:</p> @@ -12543,7 +13055,7 @@ using the method described in 22.2.3.1.2 [facet.numpunct.virtuals]. <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]. +using the method described in 22.4.3.1.2 [facet.numpunct.virtuals]. </p></blockquote> <p><i>[ @@ -12575,10 +13087,11 @@ 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>Section:</b> 25.4.5 [alg.replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-12-15 <b>Last modified:</b> 2008-09-26</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#alg.replace">active issues</a> in [alg.replace].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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> @@ -12737,15 +13250,15 @@ imposing a greater restriction that what the standard currently says <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>Section:</b> 20.7.8 [comparisons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-12-26 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> -<p>The example in 20.6.7 [comparisons], p6 shows how to use the C +<p>The example in 20.7.8 [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 +"C++"</tt> linkage [17.6.2.3 [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. @@ -12753,7 +13266,7 @@ well-formed is unspecified. <p><b>Proposed resolution:</b></p> -<p>Change 20.6.7 [comparisons] paragraph 6 from:</p> +<p>Change 20.7.8 [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++"); @@ -12792,12 +13305,12 @@ 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>Section:</b> 27.9.1.7 [ifstream.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-12-31 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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>27.9.1.7 [ifstream.cons], p2, 27.9.1.11 [ofstream.cons], p2, and +27.9.1.15 [fstream.cons], p2 say about the effects of each constructor: </p> <p>... If that function returns a null pointer, calls @@ -12805,7 +13318,7 @@ it corresponds to the new code fragment.]</i></p> </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 +exception due to the requirement in 27.5.4.1 [basic.ios.cons], p3 that <tt>exceptions()</tt> be initialized to <tt>ios_base::goodbit</tt>. </p> @@ -12821,10 +13334,10 @@ paragraphs mentioned above. <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>Section:</b> 25.6 [alg.c.library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Judy Ward <b>Opened:</b> 2000-12-30 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> The <cstdlib> header file contains prototypes for bsearch and @@ -12851,9 +13364,9 @@ the type size_t <cstdlib> to Table 97 (section C.2). <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>Section:</b> 19.4 [errno] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Judy Ward <b>Opened:</b> 2000-12-30 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> ISO/IEC 9899:1990/Amendment1:1994 Section 4.3 States: "The list @@ -12880,10 +13393,10 @@ and Table 95 (section C.2) "Standard Macros" to include EILSEQ. <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>Section:</b> 25.5.5 [alg.set.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Matt Austern <b>Opened:</b> 2001-01-03 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> The standard library contains four algorithms that compute set @@ -12937,7 +13450,7 @@ same way. <p><b>Proposed resolution:</b></p> -<p>Add the following to the end of 25.3.5.2 [set.union] paragraph 5:</p> +<p>Add the following to the end of 25.5.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 @@ -12947,7 +13460,7 @@ 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> +<p>Add the following to the end of 25.5.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 @@ -12955,7 +13468,7 @@ 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] +<p>Add a new paragraph, <b>Notes</b>, after 25.5.5.4 [set.difference] paragraph 4:</p> <blockquote><p> If [first1, last1) contains <i>m</i> elements that are equivalent to each @@ -12964,7 +13477,7 @@ 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] +<p>Add a new paragraph, <b>Notes</b>, after 25.5.5.5 [set.symmetric.difference] paragraph 4:</p> <blockquote><p> If [first1, last1) contains <i>m</i> elements that are equivalent to @@ -12996,11 +13509,11 @@ m</i> of these elements from [first2, last2) if <i>m</i> < <i>n</i>. <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>Section:</b> 27.5.4.2 [basic.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-01-05 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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 @@ -13036,11 +13549,11 @@ objects of <tt>rhs</tt>, except that... <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>Section:</b> 17.6.3.3.1 [macro.names] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> James Kanze <b>Opened:</b> 2001-01-11 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> -<p>Paragraph 2 of 17.4.3.2.1 [macro.names] reads: "A +<p>Paragraph 2 of 17.6.3.3.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> @@ -13056,12 +13569,12 @@ 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, +example. In light of 17.6.4.2 [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> +<p>For 17.6.3.3.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 @@ -13095,10 +13608,10 @@ it isn't stringent enough.</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>Section:</b> 26.8 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2001-01-12 <b>Last modified:</b> 2008-09-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#WP">WP</a> status.</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> Table 80 lists the contents of the <cmath> header. It does not @@ -13111,7 +13624,7 @@ of <tt>abs()</tt> should be defined in <cmath>. <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], +of functions "(abs(), div(), rand(), srand())" from 26.6 [numarray], paragraph 1. </p> @@ -13133,9 +13646,9 @@ putting in <cstdlib>. That's issue <a href="http://www.open-std.org/jtc1/ <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>Section:</b> 20.7.9 [logical.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-01-06 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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> @@ -13216,9 +13729,9 @@ 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>Section:</b> 18.6.1.2 [new.delete.array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> John A. Pedretti <b>Opened:</b> 2001-01-10 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> The default behavior of <tt>operator delete[]</tt> described in 18.5.1.2, p12 - @@ -13244,7 +13757,7 @@ For a null value of <i><tt>ptr</tt></i> , does nothing. 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]). +call to <tt>operator delete[](void*)</tt> (17.6.3.9 [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>. @@ -13266,13 +13779,13 @@ or <tt>operator delete(<i>ptr</i>, std::nothrow)</tt> respectively. <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>Section:</b> 23.3.4.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> John Pedretti <b>Opened:</b> 2001-01-23 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> -The "Effects" clause for list::merge() (23.2.4.4 [list.ops], p23) +The "Effects" clause for list::merge() (23.3.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 @@ -13281,7 +13794,7 @@ unintended in this case. <p><b>Proposed resolution:</b></p> -<p>In 23.2.4.4 [list.ops], replace paragraps 23-25 with:</p> +<p>In 23.3.4.4 [list.ops], replace paragraps 23-25 with:</p> <blockquote> <p> 23 Effects: if (&x == this) does nothing; otherwise, merges the two @@ -13310,7 +13823,7 @@ effects. </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 +the problems in 23.3.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 @@ -13327,10 +13840,11 @@ list" is excessively vague.]</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>Section:</b> 21.4.1 [string.require] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-01-27 <b>Last modified:</b> 2008-09-26</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#string.require">active issues</a> in [string.require].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> The effects clause for the basic_string template ctor in 21.3.1, p15 @@ -13365,9 +13879,9 @@ a mistake. <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>Section:</b> 20.3.6.3 [bitset.operators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Matt Austern <b>Opened:</b> 2001-02-05 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> In 23.3.5.3, we are told that <tt>bitset</tt>'s input operator @@ -13484,10 +13998,10 @@ 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>Section:</b> 22.4.1.5 [locale.codecvt.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2001-01-24 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p>22.2.1.5/3 introduces codecvt in part with:</p> @@ -13612,10 +14126,10 @@ example, and it would rule out a fixed-width encoding of UCS-4.</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>Section:</b> 18.2 [support.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Steve Clamage <b>Opened:</b> 2001-02-21 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p>Spliced together from reflector messages c++std-lib-8294 and -8295:</p> @@ -13650,16 +14164,16 @@ 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>Section:</b> 23.3.4 [list] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2001-03-13 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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. +The standard is currently inconsistent in 23.3.4.2 [list.capacity] +paragraph 1 and 23.3.4.3 [list.modifiers] paragraph 1. 23.2.3.3/1, for example, says: </p> @@ -13922,18 +14436,19 @@ and it was deliberately not adopted. Nevertheless, the LWG believes <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>Section:</b> 27 [input.output] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-03-15 <b>Last modified:</b> 2008-09-26</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#input.output">active issues</a> in [input.output].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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 +streams (27.8 [string.streams]) and the headers <cstdio> and +<cwchar> for File streams (27.9 [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 +subclauses. According to 17.6.1.1 [contents], only such headers are to be listed in the summary. </p> @@ -13945,7 +14460,7 @@ 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> +section 27.9 [file.streams], including 27.9.2 [c.files].]</i></p> @@ -13954,10 +14469,10 @@ 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>Section:</b> 17.6.1.2 [headers], 19.4 [errno] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Steve Clamage <b>Opened:</b> 2001-03-21 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> Exactly how should errno be declared in a conforming C++ header? @@ -14057,13 +14572,13 @@ to be a macro.</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>Section:</b> 27.7.2.1 [ostream] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Andy Sawyer <b>Opened:</b> 2001-03-21 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> -<p>In 27.6.2.1 [ostream], the synopsis of class basic_ostream says:</p> +<p>In 27.7.2.1 [ostream], the synopsis of class basic_ostream says:</p> <pre> // partial specializationss template<class traits> @@ -14080,14 +14595,14 @@ to be a macro.</p> <p><b>Proposed resolution:</b></p> -<p>In the synopsis in 27.6.2.1 [ostream], remove the +<p>In the synopsis in 27.7.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]. +27.7.2.6.4 [ostream.inserters.character]. </p> <p><i>[ -Pre-Redmond: added 27.6.2.6.4 [ostream.inserters.character] because of Martin's +Pre-Redmond: added 27.7.2.6.4 [ostream.inserters.character] because of Martin's comment in c++std-lib-8939. ]</i></p> @@ -14099,13 +14614,14 @@ comment in c++std-lib-8939. <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>Section:</b> 20 [utilities] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-03-29 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#utilities">issues</a> in [utilities].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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> +<cstdlib> and <cstring> that are discussed in 20.6.5 [meta.rel].</p> <p><b>Proposed resolution:</b></p> @@ -14118,13 +14634,13 @@ 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>Section:</b> 23.3.4.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Andy Sawyer <b>Opened:</b> 2001-05-01 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> -23.2.4.4 [list.ops], Para 21 describes the complexity of +23.3.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)". @@ -14145,10 +14661,11 @@ Change the "range" from (last - first) to [first, last). <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>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-05-04 <b>Last modified:</b> 2008-09-26</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p>Table 69 says this about a_uniq.insert(t):</p> @@ -14177,10 +14694,11 @@ takes place... <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>Section:</b> 22 [localization] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-05-04 <b>Last modified:</b> 2008-09-26</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#localization">active issues</a> in [localization].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> The localization section of the standard refers to specializations of @@ -14243,9 +14761,9 @@ 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>Section:</b> 22.4.3.2 [locale.numpunct.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-05-12 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p>The definition of the numpunct_byname template contains the following comment:</p> @@ -14271,16 +14789,16 @@ resolution of library issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs <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>Section:</b> 18.6.1.1 [new.delete.single], 18.6.1.2 [new.delete.array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2001-05-15 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> -<p>The standard specifies 17.3.1.3 [structure.specifications] that "Required +<p>The standard specifies 17.5.1.4 [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" +<p>The standard specifies 17.5.1.4 [structure.specifications] that "Requires" elements describe "the preconditions for calling the function."</p> <p>In the sections noted below, the current wording specifies @@ -14291,7 +14809,7 @@ 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> +<p>In 18.6.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> @@ -14302,7 +14820,7 @@ should be specified as "Requires".</p> earlier call ...</p> </blockquote> -<p>In 18.5.1.2 [new.delete.array] Para 11 Change:</p> +<p>In 18.6.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> @@ -14319,13 +14837,13 @@ should be specified as "Requires".</p> <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>Section:</b> 23.3.4.1 [list.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2001-05-17 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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 +Section 23.3.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> @@ -14351,7 +14869,7 @@ Metrowerks and SGI recycle nodes, Dinkumware and Rogue Wave don't. <p><b>Proposed resolution:</b></p> -<p>Change 23.2.4.1 [list.cons]/7 from:</p> +<p>Change 23.3.4.1 [list.cons]/7 from:</p> <blockquote> <p>Effects:</p> @@ -14367,7 +14885,7 @@ Metrowerks and SGI recycle nodes, Dinkumware and Rogue Wave don't. <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), +<p>In 23.2.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 @@ -14378,7 +14896,7 @@ add two new rows:</p> of t. </pre> -<p>Change 23.2.4.1 [list.cons]/8 from:</p> +<p>Change 23.3.4.1 [list.cons]/8 from:</p> <blockquote> <p>Effects:</p> @@ -14416,11 +14934,11 @@ 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>Section:</b> 22.4.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Kevin Djang <b>Opened:</b> 2001-05-17 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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 @@ -14447,11 +14965,11 @@ to be "A length modifier is added ..." <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>Section:</b> 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Matt Austern <b>Opened:</b> 2001-05-17 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> It's widely assumed that, if X is a container, @@ -14494,10 +15012,10 @@ requires that iterator_traits<const int*>::value_type is int. <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>Section:</b> 24.2.3 [output.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2001-06-07 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p>Table 73 suggests that output iterators have value types. It @@ -14627,10 +15145,10 @@ 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>Section:</b> 22.4.6.3.2 [locale.moneypunct.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-07-02 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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() @@ -14692,10 +15210,10 @@ integers, not ASCII characters. <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>Section:</b> 22.3.1.1.1 [locale.category] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Tiki Wan <b>Opened:</b> 2001-07-06 <b>Last modified:</b> 2008-09-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#WP">WP</a> status.</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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 @@ -14708,7 +15226,7 @@ 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> +22.3.1.1.1 [locale.category], change</p> <pre> time_get<wchar_t, OutputIterator> time_get_byname<wchar_t, OutputIterator> </pre> @@ -14727,9 +15245,9 @@ 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>Section:</b> 22.4.6.2.2 [locale.money.put.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-07-07 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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 @@ -14751,18 +15269,18 @@ modifier.</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>Section:</b> 23.3.6.2 [vector.capacity], 23.3.6.4 [vector.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Anthony Williams <b>Opened:</b> 2001-07-13 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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]. +a reallocation of a vector in Section 23.3.6.2 [vector.capacity] and +section 23.3.6.4 [vector.modifiers]. </p> -<p>23.2.6.2 [vector.capacity],p5 says:</p> +<p>23.3.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 @@ -14782,7 +15300,7 @@ greater than the size specified in the most recent call to reserve(). <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> +<p>However, the previous paragraphs (23.3.6.2 [vector.capacity], p1-2) state:</p> <blockquote> <p> (capacity) Returns: The total number of elements the vector @@ -14798,7 +15316,7 @@ of capacity() otherwise... <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: +up by 23.3.6.4 [vector.modifiers], p1: </p> <blockquote><p> (insert) Notes: Causes reallocation if the new size is greater than the old @@ -14813,7 +15331,7 @@ than the old capacity, I think the intent is clear. <p><b>Proposed resolution:</b></p> -<p>Change the wording of 23.2.6.2 [vector.capacity] paragraph 5 to:</p> +<p>Change the wording of 23.3.6.2 [vector.capacity] paragraph 5 to:</p> <blockquote><p> Notes: Reallocation invalidates all the references, pointers, and @@ -14846,13 +15364,13 @@ 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>Section:</b> 27.5.2.1.1 [ios::failure] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> PremAnand M. Rao <b>Opened:</b> 2001-08-23 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> -With the change in 17.4.4.9 [res.on.exception.handling] to state +With the change in 17.6.4.10 [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>) @@ -14867,7 +15385,7 @@ and the following declaration of ~failure() in ios_base::failure }; } </pre> -<p>the class failure cannot be implemented since in 18.6.1 [type.info] the destructor of class exception has an empty +<p>the class failure cannot be implemented since in 18.7.1 [type.info] the destructor of class exception has an empty exception specification:</p> <pre> namespace std { class exception { @@ -14896,11 +15414,11 @@ 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>Section:</b> 27.7.2.8 [ostream.manip] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> PremAnand M. Rao <b>Opened:</b> 2001-08-27 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> -<p>A footnote in 27.6.2.8 [ostream.manip] states:</p> +<p>A footnote in 27.7.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 @@ -14927,7 +15445,7 @@ the behavior one way or the other. <p><b>Proposed resolution:</b></p> -<p>Remove footnote 300 from section 27.6.2.8 [ostream.manip].</p> +<p>Remove footnote 300 from section 27.7.2.8 [ostream.manip].</p> <p><b>Rationale:</b></p> @@ -14945,10 +15463,10 @@ 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>Section:</b> 23.4.1.2 [map.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Andrea Griffini <b>Opened:</b> 2001-09-02 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> The current standard describes map::operator[] using a @@ -15028,7 +15546,7 @@ non-conforming. <p><b>Proposed resolution:</b></p> <p> -Replace 23.3.1.2 [map.access] paragraph 1 with +Replace 23.4.1.2 [map.access] paragraph 1 with </p> <blockquote> <p> @@ -15068,12 +15586,12 @@ we are no longer defining <tt>operator[]</tt> in terms of <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>Section:</b> 21.2.1 [char.traits.require] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Andy Sawyer <b>Opened:</b> 2001-09-06 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> -Table 37, in 21.1.1 [char.traits.require], descibes char_traits::assign +Table 37, in 21.2.1 [char.traits.require], descibes char_traits::assign as: </p> <pre> X::assign(c,d) assigns c = d. @@ -15118,14 +15636,15 @@ and char_traits<wchar_t> in 21.1.3.2...) <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>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Detlef Vollmann <b>Opened:</b> 2001-09-05 <b>Last modified:</b> 2008-09-26</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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 +<p>17.6.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 @@ -15136,7 +15655,7 @@ 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 +<p>To 17.6.1.2 [headers] Table 11, C++ Library Headers, add "<strstream>".</p> <p>In the following places, change "clauses 17 through 27" to "clauses @@ -15146,15 +15665,15 @@ library (though a deprecated one).</p> <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> +<li>17.5 [description] Method of description (Informative)/1</li> +<li>17.5.2.1.4 [character.seq] Character sequences/1/bullet 2</li> +<li>17.5.2.2 [functions.within.classes] Functions within classes/1</li> +<li>17.5.2.3 [objects.within.classes] Private members/1/(2 places)</li> +<li>17.6 [requirements] Library-wide requirements/1</li> +<li>17.6.1.2 [headers] Headers/4</li> +<li>17.6.3.6 [replacement.functions] Replacement functions/1</li> +<li>17.6.4.4 [global.functions] Global or non-member functions/2</li> +<li>17.6.4.8 [protection.within.classes] Protection within classes/1</li> </ul> @@ -15165,17 +15684,18 @@ library (though a deprecated one).</p> <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>Section:</b> 25.4.5 [alg.replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Detlef Vollmann <b>Opened:</b> 2001-09-07 <b>Last modified:</b> 2008-09-26</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#alg.replace">active issues</a> in [alg.replace].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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 +In section 25.4.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 +instead of "Iterator". According to 17.5.2.1 [type.descriptions] p1 the parameter name conveys real normative meaning. </p> @@ -15189,17 +15709,17 @@ parameter name conveys real normative meaning. <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>Section:</b> 22.4 [locale.categories] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-09-17 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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 +From Stage 2 processing in 22.4.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 +within a number, but 22.4.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> @@ -15209,14 +15729,14 @@ 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++ core language (the syntax of integer-literals is given in 2.14.2 +[lex.icon], that of floating-point-literals in 2.14.4 [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> +<p>Change the first part of 22.4.3.1 [locale.numpunct] paragraph 2 from:</p> <blockquote> <p> The syntax for number formats is as follows, where <tt>digit</tt> @@ -15253,10 +15773,10 @@ Integer values have the format: <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 +<p>It's not clear whether the format described in 22.4.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 +numeric processing in 22.4.2.1.2 [facet.num.get.virtuals]. The proposed resolution removes all mention of "whitespace" from that format.</p> @@ -15265,14 +15785,14 @@ 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>Section:</b> 22.4.1 [category.ctype], 17.5.2.1.3 [bitmask.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-09-17 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> -<p>The ctype_category::mask type is declared to be an enum in 22.2.1 +<p>The ctype_category::mask type is declared to be an enum in 22.4.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 +likely referring to the definition of bitmask type in 17.5.2.1.3 [bitmask.types], p1. However, the said definition only applies to clause 27, making the reference in 22.2.1 somewhat dubious. </p> @@ -15283,7 +15803,7 @@ clause 27, making the reference in 22.2.1 somewhat dubious. <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]). + as an integer type, or as a bitset (20.3.6 [template.bitset]). </p></blockquote> <p>to read</p> <blockquote><p> @@ -15323,7 +15843,7 @@ following (note, in particluar, the cross-reference to 17.3.2.1.2 in } </pre> -<p>The type <tt>mask</tt> is a bitmask type (17.3.2.1.2 [bitmask.types]).</p> +<p>The type <tt>mask</tt> is a bitmask type (17.5.2.1.3 [bitmask.types]).</p> </blockquote> <p><i>[Curaçao: The LWG notes that T above should be bold-italics to be @@ -15339,10 +15859,10 @@ 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>Section:</b> 22.3.1.1.1 [locale.category] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-09-18 <b>Last modified:</b> 2008-09-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#WP">WP</a> status.</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> It's unclear whether 22.1.1.1.1, p3 says that @@ -15392,7 +15912,7 @@ to hold only for specializations of <tt>Facet</tt> from Table 52 on <p><b>Proposed resolution:</b></p> -<p>In 22.1.1.1.1 [locale.category], paragraph 3, change +<p>In 22.3.1.1.1 [locale.category], paragraph 3, change "that is a member of a standard category" to "shown in Table 51".</p> @@ -15411,10 +15931,10 @@ 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>Section:</b> 23.3.6.2 [vector.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Anthony Williams <b>Opened:</b> 2001-09-27 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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> @@ -15424,7 +15944,7 @@ an empty one:</p> // vec is now empty, with minimal capacity </pre> -<p>However, the wording of 23.2.6.2 [vector.capacity]paragraph 5 prevents +<p>However, the wording of 23.3.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 @@ -15433,7 +15953,7 @@ 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> +complexity (23.2 [container.requirements] note to table 65).</p> <p>This is an important issue, as reallocation affects the validity of references and iterators.</p> @@ -15457,7 +15977,7 @@ referred to one vector now refer to the other, and vice-versa.</li> <p><b>Proposed resolution:</b></p> -<p>Add a new paragraph after 23.2.6.2 [vector.capacity] paragraph 5:</p> +<p>Add a new paragraph after 23.3.6.2 [vector.capacity] paragraph 5:</p> <blockquote> <pre> void swap(vector<T,Allocator>& x); </pre> @@ -15486,20 +16006,20 @@ the two vectors, including their reallocation guarantees. <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>Section:</b> 21.6 [c.strings] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Clark Nelson <b>Opened:</b> 2001-10-19 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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 +declares struct tm as an incomplete type. However, table 48 in 21.6 [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> +<p>In section 21.6 [c.strings], add "tm" to table 48.</p> @@ -15507,11 +16027,11 @@ declares struct tm as an incomplete type. However, table 48 in 21.5 <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>Section:</b> 24.2 [iterator.concepts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Jeremy Siek <b>Opened:</b> 2001-10-20 <b>Last modified:</b> 2008-09-30</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iterator.concepts">active issues</a> in [iterator.concepts].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.concepts">issues</a> in [iterator.concepts].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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 @@ -15526,7 +16046,7 @@ 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 +<p>In 24.2 [iterator.concepts] 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> @@ -15561,15 +16081,15 @@ 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>Section:</b> 22.3.1.1.1 [locale.category] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> P.J. Plauger, Nathan Myers <b>Opened:</b> 2001-10-23 <b>Last modified:</b> 2008-09-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#WP">WP</a> status.</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> -In 22.1.1.1.1 [locale.category] paragraph 1, the category members +In 22.3.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> +in 17.5.2.1.3 [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 @@ -15590,7 +16110,7 @@ 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> +<p>Replace the first two paragraphs of 22.3.1.1 [locale.types] with:</p> <blockquote> <pre> typedef int category; </pre> @@ -15637,7 +16157,7 @@ shown in Table 51: <blockquote> <p><b>Option 2:</b> <br> -Replace the first paragraph of 22.1.1.1 [locale.types] with:</p> +Replace the first paragraph of 22.3.1.1 [locale.types] with:</p> <blockquote> <p> Valid category values include the enumerated values. In addition, the @@ -15664,9 +16184,9 @@ of the other enumerated values; implementations may add extra categories.] <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>Section:</b> 24.6.2 [ostream.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Andy Sawyer <b>Opened:</b> 2001-10-24 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p>24.5.2 [lib.ostream.iterator] states:</p> <pre> [...] @@ -15682,7 +16202,7 @@ 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 +In 24.6.2 [ostream.iterator], replace <tt>const char* delim</tt> with <tt>const charT* delim</tt>. </p> @@ -15692,9 +16212,9 @@ In 24.5.2 [ostream.iterator], replace <tt>const char* delim</tt> with <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>Section:</b> 21.2.2 [char.traits.typedefs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-12-02 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> <i>(1)</i> @@ -15748,10 +16268,11 @@ 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>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Hans Aberg <b>Opened:</b> 2001-12-17 <b>Last modified:</b> 2008-09-26</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> Discussions in the thread "Associative container lower/upper bound @@ -15788,7 +16309,7 @@ the intention (and not possible with the "const" versions). <p><b>Proposed resolution:</b></p> -<p>Change Table 69 of section 23.1.4 [associative.reqmts] indicated entries +<p>Change Table 69 of section 23.2.4 [associative.reqmts] indicated entries to:</p> <blockquote> @@ -15814,10 +16335,11 @@ key greater than k, or a.end() if such an element is not found. <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>Section:</b> 23.2.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Yaroslav Mironov <b>Opened:</b> 2002-01-23 <b>Last modified:</b> 2008-09-26</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#sequence.reqmts">active issues</a> in [sequence.reqmts].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p>Table 68 "Optional Sequence Operations" in 23.1.1/12 @@ -15896,11 +16418,11 @@ LWG would like a new issue opened.]</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>Section:</b> 22.4.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2002-03-12 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> I don't think <tt>thousands_sep</tt> is being treated correctly after @@ -15957,9 +16479,9 @@ Change the first sentence of 22.2.2.1.2, p9 from <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>Section:</b> 22.4.2.2.1 [facet.num.put.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2002-03-12 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p>22.2.2.2.1, p1:</p> @@ -16008,11 +16530,11 @@ the following: <p><b>Proposed resolution:</b></p> -<p>In 22.2.2.2.2 [facet.num.put.virtuals], just above paragraph 1, remove +<p>In 22.4.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 +In 22.4.2.2.2 [facet.num.put.virtuals], p23, make the following changes </p> <blockquote><p> @@ -16053,10 +16575,10 @@ be a requirement of gratuitous inefficiency. <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>Section:</b> 22.3.1 [locale] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2002-03-12 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> 22.1.1, p7 (copied below) allows iostream formatters and extractors @@ -16103,10 +16625,10 @@ prevents locale from being implemented efficiently. <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>Section:</b> D.8 [depr.lib.binders] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Andrew Demkin <b>Opened:</b> 2002-04-26 <b>Last modified:</b> 2008-09-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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> The definition of bind1st() (D.8 [depr.lib.binders]) can result in @@ -16167,10 +16689,10 @@ as a reinterpret_cast, thus masking the error. <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>Section:</b> 27.5.2.1.1 [ios::failure] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Walter Brown and Marc Paterno <b>Opened:</b> 2002-05-20 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> The destructor of ios_base::failure should have an empty throw @@ -16194,13 +16716,13 @@ declared in this way. <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>Section:</b> 27.6.2.4.2 [streambuf.virt.buffer] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Walter Brown, Marc Paterno <b>Opened:</b> 2002-05-10 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> -27.5.2.4.2 [streambuf.virt.buffer] paragraph 1 is inconsistent with the Effects +27.6.2.4.2 [streambuf.virt.buffer] paragraph 1 is inconsistent with the Effects clause for seekoff. </p> @@ -16240,10 +16762,11 @@ for each class derived from basic_streambuf in this clause <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>Section:</b> 27 [input.output] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Walter Brown, Marc Paterno <b>Opened:</b> 2002-05-10 <b>Last modified:</b> 2008-09-26</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#input.output">active issues</a> in [input.output].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> Some stream and streambuf member functions are declared non-const, @@ -16293,10 +16816,10 @@ 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>Section:</b> 27.4 [iostream.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Ruslan Abdikeev <b>Opened:</b> 2002-07-08 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> Is it safe to use standard iostream objects from constructors of @@ -16365,7 +16888,7 @@ mention of an _instance_ of ios_base::Init in Standard. <p><b>Proposed resolution:</b></p> -<p>Add to 27.3 [iostream.objects], p2, immediately before the last sentence +<p>Add to 27.4 [iostream.objects], p2, immediately before the last sentence of the paragraph, the following two sentences:</p> <blockquote><p> @@ -16405,13 +16928,13 @@ 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>Section:</b> 27.7.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Ray Lischner <b>Opened:</b> 2002-07-15 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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 +27.7.1.3 [istream.unformatted]), paragraph 15. The description for the get function with the following signature:</p> @@ -16451,11 +16974,11 @@ with the following signature:</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>Section:</b> 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Frank Compagner <b>Opened:</b> 2002-07-20 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> The requirements for multiset and multimap containers (23.1 @@ -16514,7 +17037,7 @@ erase_if() member function that much greater. <p><b>Proposed resolution:</b></p> -<p>Add the following to the end of 23.1.4 [associative.reqmts] paragraph 4: +<p>Add the following to the end of 23.2.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> @@ -16545,24 +17068,24 @@ wording.]</i></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>Section:</b> 27.7.1.2.1 [istream.formatted.reqmts], 27.7.2.6.1 [ostream.formatted.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Keith Baker <b>Opened:</b> 2002-07-23 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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] +In 27.7.1.2.1 [istream.formatted.reqmts] and 27.7.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? +exception() is the constructor to class std::exception in 18.7.1 [type.info] that has no return type. Should member function +exceptions() found in 27.5.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 +In 27.7.1.2.1 [istream.formatted.reqmts] and 27.7.2.6.1 [ostream.formatted.reqmts], change "(exception()&badbit) != 0" to "(exceptions()&badbit) != 0". </p> @@ -16576,13 +17099,13 @@ In 27.6.1.2.1 [istream.formatted.reqmts] and 27.6.2.6.1 [ostream.formatted.reqmt <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>Section:</b> 27.8.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Ray Lischner <b>Opened:</b> 2002-08-14 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> -In Section 27.7.1.4 [stringbuf.virtuals]: Table 90, Table 91, and paragraph +In Section 27.8.1.4 [stringbuf.virtuals]: Table 90, Table 91, and paragraph 14 all contain references to "basic_ios::" which should be "ios_base::". </p> @@ -16602,13 +17125,13 @@ paragraph 14 to "ios_base". <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>Section:</b> 27.8.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Ray Lischner <b>Opened:</b> 2002-08-14 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> -In Section 27.7.1.4 [stringbuf.virtuals], Table 90, the implication is that +In Section 27.8.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> @@ -16652,10 +17175,10 @@ are both true, but case 3 is false. <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>Section:</b> 22.4.1.1.2 [locale.ctype.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2002-09-06 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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. @@ -16686,7 +17209,7 @@ footnote 224.) <p><b>Proposed resolution:</b></p> <p> -Replace the last sentence of 22.2.1.1.2 [locale.ctype.virtuals], p11 with the +Replace the last sentence of 22.4.1.1.2 [locale.ctype.virtuals], p11 with the following text: </p> <pre> For any named ctype category with a ctype<char> facet ctc @@ -16708,13 +17231,13 @@ following text: <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>Section:</b> 22.4.1.5 [locale.codecvt.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2002-09-06 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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 +Tables 53 and 54 in 22.4.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. @@ -16746,10 +17269,10 @@ elements was needed to terminate a sequence given the value of state." <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>Section:</b> 22.4.1.5 [locale.codecvt.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2002-09-06 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> All but one codecvt member functions that take a state_type argument @@ -16810,10 +17333,10 @@ values, or that choose to detect any other kind of error, may return <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>Section:</b> 24.2.5 [bidirectional.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> ysapir (submitted via comp.std.c++) <b>Opened:</b> 2002-10-17 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> Following a discussion on the boost list regarding end iterators and @@ -16826,8 +17349,8 @@ with that discussion. 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. +the "Lists by Index" mentions only DR <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#299">299</a> on section +24.1.4, and DR <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#299">299</a> is not related to this issue. </p> <p> @@ -16879,13 +17402,13 @@ Change the guarantee to "postcondition: r is dereferenceable." <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>Section:</b> 25.5.3.3 [equal.range] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Hans Bos <b>Opened:</b> 2002-10-18 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> -Section 25.3.3.3 [equal.range] +Section 25.5.3.3 [equal.range] states that at most 2 * log(last - first) + 1 comparisons are allowed for equal_range. </p> @@ -16924,13 +17447,13 @@ but 2log(distance) + 4 for the worst case). <p><b>Proposed resolution:</b></p> -<p>In 25.3.3.1 [lower.bound]/4, change <tt>log(last - first) + 1</tt> +<p>In 25.5.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> +<p>In 25.5.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> +<p>In 25.5.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> @@ -16951,11 +17474,11 @@ to <tt>2*log<sub>2</sub>(last - first) + <i>O</i>(1)</tt>.</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>Section:</b> 24.5.1.2.11 [reverse.iter.op-=] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Matt Austern <b>Opened:</b> 2002-10-23 <b>Last modified:</b> 2009-05-01</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> -<p>In 24.4.1.3.11 [reverse.iter.op-=], <tt>reverse_iterator<>::operator[]</tt> +<p>In 24.5.1.2.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> @@ -16967,7 +17490,7 @@ which is the same as <tt>iterator_traits<Iterator>::reference</tt>. 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 +<p>With the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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 @@ -16981,7 +17504,7 @@ which is the same as <tt>iterator_traits<Iterator>::reference</tt>. <p><b>Proposed resolution:</b></p> -<p>In 24.4.1.2 [reverse.iter.requirements] change:</p> +<p>In [reverse.iter.requirements] change:</p> <blockquote> <pre>reference operator[](difference_type n) const; @@ -16991,7 +17514,7 @@ which is the same as <tt>iterator_traits<Iterator>::reference</tt>. <p>to:</p> <blockquote> -<pre><b><i>unspecified</i></b> operator[](difference_type n) const; // see 24.1.5 [random.access.iterators] +<pre><b><i>unspecified</i></b> operator[](difference_type n) const; // see 24.2.6 [random.access.iterators] </pre> </blockquote> @@ -17013,11 +17536,168 @@ Comments from Dave Abrahams: IMO we should resolve 386 by just saying <hr> +<h3><a name="387"></a>387. std::complex over-encapsulated</h3> +<p><b>Section:</b> 26.4 [complex.numbers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Gabriel Dos Reis <b>Opened:</b> 2002-11-08 <b>Last modified:</b> 2008-09-26</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#CD1">CD1</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.4 [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.4.2 [complex] and 26.4.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.4.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.4.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.4.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="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>Section:</b> 26.6.2.3 [valarray.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Gabriel Dos Reis <b>Opened:</b> 2002-11-08 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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> @@ -17061,8 +17741,8 @@ 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> +<p>In the class synopsis in 26.6.2 [template.valarray], and in +26.6.2.3 [valarray.access] just above paragraph 1, change</p> <pre> T operator[](size_t const); </pre> <p>to</p> @@ -17088,19 +17768,19 @@ 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>Section:</b> 22.3.3.2 [conversions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> James Kanze <b>Opened:</b> 2002-12-10 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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]. +const in the header file synopsis in section 22.3 [locales]. </p> <p><b>Proposed resolution:</b></p> -<p>In 22.1.3.2 [conversions], remove <tt>const</tt> from the function +<p>In 22.3.3.2 [conversions], remove <tt>const</tt> from the function declarations of std::toupper and std::tolower</p> @@ -17111,20 +17791,20 @@ const in the header file synopsis in section 22.1 [locales]. <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>Section:</b> 26.8 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> James Kanze <b>Opened:</b> 2003-01-03 <b>Last modified:</b> 2008-09-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#WP">WP</a> status.</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> -In 26.7 [c.math], the C++ standard refers to the C standard for the +In 26.8 [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 +In 25.4.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 @@ -17164,14 +17844,148 @@ implementation is permitted to use <tt>rand</tt>.] <hr> +<h3><a name="396"></a>396. what are characters zero and one</h3> +<p><b>Section:</b> 20.3.6.1 [bitset.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-01-05 <b>Last modified:</b> 2008-09-26</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#CD1">CD1</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-defects.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 +20.3.6.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 20.3.6.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 20.3.6.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 20.3.6.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 20.3.6.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="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>Section:</b> 20.8.6.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Markus Mauhart <b>Opened:</b> 2003-02-27 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> -20.7.5.1 [allocator.members] allocator members, contains +20.8.6.1 [allocator.members] allocator members, contains the following 3 lines: </p> @@ -17199,11 +18013,11 @@ Replace "((T*) p)" with "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>Section:</b> X [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Markus Mauhart <b>Opened:</b> 2003-02-27 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> I think that in par2 of [default.con.req] the last two @@ -17283,21 +18097,21 @@ issue to Ready status to be voted into the WP at Kona. <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>Section:</b> X [allocator.requirements], 20.8.6.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Markus Mauhart <b>Opened:</b> 2003-02-27 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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]. +20.8.6.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> +<p>20.8.6.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); @@ -17350,38 +18164,38 @@ Replace "new" with "::new" in both cases. <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>Section:</b> 21.4.6.8 [string::swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2003-03-25 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> -std::basic_string, 21.3 [basic.string] paragraph 2 says that +std::basic_string, 21.4 [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 +Section 23.2 [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 +Eric Niebler points out that 21.4 [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 +disallowed by 23.2 [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. +basic_string meet 23.2 [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 +specified by 23.2 [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 @@ -17391,7 +18205,7 @@ exception-safe code. <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 +possible to reasonably meet the 23.2 [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. @@ -17405,7 +18219,7 @@ address, prejudice, or otherwise impact that concern. <p><b>Proposed resolution:</b></p> <p> -In 21.3.6.8 [string::swap], add a throws clause: +In 21.4.6.8 [string::swap], add a throws clause: </p> <p> @@ -17418,9 +18232,9 @@ Throws: Shall not throw exceptions. <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>Section:</b> 17.6.3.6 [replacement.functions], 18.6.1 [new.delete] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Matt Austern <b>Opened:</b> 2003-04-24 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> The eight basic dynamic memory allocation functions (single-object @@ -17432,12 +18246,12 @@ in preference to the implementation's definition. <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]. +replacement functions: 17.6.3.6 [replacement.functions], 18.6.1.1 [new.delete.single] +and 18.6.1.2 [new.delete.array], and 3.7.3 [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 + be declared inline. 18.6.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 @@ -17450,7 +18264,7 @@ and 18.5.1.2 [new.delete.array], and 3.7.2 [basic.stc.auto]. <p><b>Proposed resolution:</b></p> <p> -Add a new sentence to the end of 17.4.3.5 [replacement.functions] paragraph 3: +Add a new sentence to the end of 17.6.3.6 [replacement.functions] paragraph 3: "The program's definitions shall not be specified as <tt>inline</tt>. No diagnostic is required." </p> @@ -17475,13 +18289,13 @@ believed to be of limited value. <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>Section:</b> 25.6 [alg.c.library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Ray Lischner <b>Opened:</b> 2003-04-08 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> -Section 25.4 [alg.c.library] describes bsearch and qsort, from the C +Section 25.6 [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. @@ -17490,7 +18304,7 @@ qsort sorts the array by copying bytes, which requires POD. <p><b>Proposed resolution:</b></p> <p> -In 25.4 [alg.c.library] paragraph 4, just after the declarations and +In 25.6 [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 @@ -17507,10 +18321,10 @@ type." <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>Section:</b> 23.3.6.4 [vector.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2003-04-27 <b>Last modified:</b> 2009-05-01</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> There is a possible defect in the standard: the standard text was @@ -17524,7 +18338,7 @@ existing implementation. <p><b>Proposed resolution:</b></p> -<p>Replace 23.2.6.4 [vector.modifiers] paragraph 1 with:</p> +<p>Replace 23.3.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 @@ -17543,14 +18357,14 @@ existing implementation. <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>Section:</b> 24.2 [iterator.concepts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Nathan Myers <b>Opened:</b> 2003-06-03 <b>Last modified:</b> 2008-09-30</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iterator.concepts">active issues</a> in [iterator.concepts].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.concepts">issues</a> in [iterator.concepts].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> -Clause 24.1 [iterator.requirements], paragraph 5, says that the only expression +Clause 24.2 [iterator.concepts], 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 @@ -17572,13 +18386,13 @@ of a non-singular value to an iterator that holds a singular value." <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>Section:</b> 27.9.1.9 [ifstream.members], 27.9.1.13 [ofstream.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Nathan Myers <b>Opened:</b> 2003-06-03 <b>Last modified:</b> 2009-05-01</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> -A strict reading of 27.8.1 [fstreams] shows that opening or +A strict reading of 27.9.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, @@ -17597,7 +18411,7 @@ language, those considerations no longer apply. <p><b>Proposed resolution:</b></p> -<p>Change 27.8.1.9 [ifstream.members], para. 3 from:</p> +<p>Change 27.9.1.9 [ifstream.members], para. 3 from:</p> <blockquote><p> Calls rdbuf()->open(s,mode|in). If that function returns a null @@ -17612,7 +18426,7 @@ 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> +<p>Change 27.9.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 @@ -17626,7 +18440,7 @@ 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> +<p>Change 27.9.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 @@ -17662,22 +18476,22 @@ flags.]</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>Section:</b> 23.3.4.1 [list.cons], 23.3.4.3 [list.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Hans Bos <b>Opened:</b> 2003-06-07 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> -Sections 23.2.4.1 [list.cons] and 23.2.4.3 [list.modifiers] list +Sections 23.3.4.1 [list.cons] and 23.3.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] +stack. Only the semantics for queue::operator== (23.3.4.1 [list.cons] par2) and queue::operator< (23.3.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] +<p>Add the following new paragraphs after 23.3.4.1 [list.cons] paragraph 3:</p> <blockquote> @@ -17700,7 +18514,7 @@ par3) are defined. </blockquote> -<p>Add the following paragraphs at the end of 23.2.4.3 [list.modifiers]:</p> +<p>Add the following paragraphs at the end of 23.3.4.3 [list.modifiers]:</p> <blockquote> @@ -17746,13 +18560,13 @@ 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>Section:</b> 25.5.5 [alg.set.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Daniel Frey <b>Opened:</b> 2003-07-09 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> -25.3.5 [alg.set.operations] paragraph 1 reads: +25.5.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 @@ -17774,14 +18588,14 @@ set_intersection(), not union() and intersection(). <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>Section:</b> 27.5.4.3 [iostate.flags] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-07-10 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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 +The Effects clause in 27.5.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> & @@ -17791,7 +18605,7 @@ exceptions()) == 0, returns. ..." <p><b>Proposed resolution:</b></p> <p> -In 27.4.4.3 [iostate.flags] paragraph 5, replace "If (rdstate() & +In 27.5.4.3 [iostate.flags] paragraph 5, replace "If (rdstate() & exceptions()) == 0" with "If ((state | (rdbuf() ? goodbit : badbit)) & exceptions()) == 0". </p> @@ -17810,10 +18624,10 @@ exceptions()) == 0" with "If ((state | (rdbuf() ? goodbit : badbit)) <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>Section:</b> 27.7.1.2.3 [istream::extractors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Bo Persson <b>Opened:</b> 2003-07-13 <b>Last modified:</b> 2009-05-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#DR">DR</a> status.</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> The second sentence of the proposed resolution says: @@ -17868,10 +18682,10 @@ then the caught exception is rethrown. <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>Section:</b> 23.3.6.4 [vector.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Matt Austern <b>Opened:</b> 2003-08-19 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> Consider the following code fragment: @@ -17923,7 +18737,7 @@ techniques.) <p><b>Proposed resolution:</b></p> <p> -In 23.2.6.4 [vector.modifiers] paragraph 3, change "Invalidates all the +In 23.3.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". @@ -17943,9 +18757,9 @@ erase". <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>Section:</b> 27.7.1.4 [istream.manip] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> According to 27.6.1.4, the ws() manipulator is not required to construct @@ -17961,7 +18775,7 @@ doesn't affect the stream's gcount). <p><b>Proposed resolution:</b></p> <p> -Add to 27.6.1.4 [istream.manip], immediately before the first sentence +Add to 27.7.1.4 [istream.manip], immediately before the first sentence of paragraph 1, the following text: </p> @@ -17982,9 +18796,9 @@ of paragraph 1, the following text: <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>Section:</b> 18.3.2 [c.limits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> @@ -18037,7 +18851,7 @@ where the actual type is easily detectable by overload resolution. <p><b>Proposed resolution:</b></p> <p> -Change 18.2.2 [c.limits], paragraph 2: +Change 18.3.2 [c.limits], paragraph 2: </p> <blockquote><p> @@ -18052,10 +18866,10 @@ to match the type to which they refer.<i>--end note</i>]</ins> <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>Section:</b> 27.9.1 [fstreams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> 7.19.1, p2, of C99 requires that the FILE type only be declared in @@ -18071,7 +18885,7 @@ allowed to just declare it without providing a full definition? <p><b>Proposed resolution:</b></p> -<p>In the first sentence of 27.8.1 [fstreams] paragraph 2, change +<p>In the first sentence of 27.9.1 [fstreams] paragraph 2, change "defined" to "declared".</p> @@ -18086,10 +18900,10 @@ allowed to just declare it without providing a full definition? <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>Section:</b> 17.6.3.3 [reserved.names] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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 @@ -18106,7 +18920,7 @@ the program) by relying on the "as if" rule. <p><b>Proposed resolution:</b></p> <p> - Add the following sentence to 17.4.3.2 [reserved.names], p1: + Add the following sentence to 17.6.3.3 [reserved.names], p1: </p> <blockquote><p> @@ -18154,9 +18968,9 @@ 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>Section:</b> 20.8.9 [temporary.buffer] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> The standard is not clear about the requirements on the value returned from @@ -18169,7 +18983,7 @@ is when the argument is less than 0. <p><b>Proposed resolution:</b></p> -<p>Change 20.5.3 [meta.help] paragraph 2 from "...or a pair of 0 +<p>Change 20.6.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> @@ -18180,10 +18994,10 @@ no storage can be obtained or if <i>n</i> <= 0."</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>Section:</b> 25.3.12 [alg.search], 25.4.6 [alg.fill], 25.4.7 [alg.generate] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> The complexity requirements for these function templates are incorrect @@ -18260,10 +19074,10 @@ or 0 otherwise) assignments. <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>Section:</b> 21.4.6.5 [string::erase] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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) @@ -18282,7 +19096,7 @@ which is most likely not the intent. <p><b>Proposed resolution:</b></p> -<p>Remove 21.3.6.5 [string::erase] paragraph 5.</p> +<p>Remove 21.4.6.5 [string::erase] paragraph 5.</p> <p><b>Rationale:</b></p> @@ -18298,10 +19112,10 @@ which is most likely not the intent. <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>Section:</b> 27.8.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Christian W Brock <b>Opened:</b> 2003-09-24 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p>27.7.1.3 par 8 says:</p> <blockquote><p> @@ -18519,7 +19333,7 @@ newoff + off to the next pointer xnext . <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] +uninitialized character (as defined in 27.8.1.3 [stringbuf.members] paragraph 1), the positioning operation fails. Otherwise, the function assigns xbeg + newoff + off to the next pointer xnext . </p> @@ -18584,10 +19398,10 @@ 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>Section:</b> 20.3.6.2 [bitset.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-10-15 <b>Last modified:</b> 2009-05-01</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> It has been pointed out a number of times that the bitset to_string() member @@ -18639,10 +19453,10 @@ to_string() member function template:</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>Section:</b> 21.4.8.9 [string.io] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-10-15 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> @@ -18703,9 +19517,9 @@ iostreams where the operator does truncate). <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>Section:</b> 22.3.1.1.2 [locale.facet] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-10-15 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> Is "const std::ctype<char>" a valid template argument to has_facet, use_facet, @@ -18737,13 +19551,14 @@ 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>Section:</b> 23.2.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2003-10-20 <b>Last modified:</b> 2009-05-01</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#sequence.reqmts">active issues</a> in [sequence.reqmts].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> -<p>Section 23.1.3 [sequence.reqmts], paragraphs 9-11, fixed up the problem +<p>Section 23.2.3 [sequence.reqmts], paragraphs 9-11, fixed up the problem noticed with statements like:</p> <pre>vector<int> v(10, 1); </pre> @@ -18941,7 +19756,7 @@ T implicit_cast(const U& u) <p><b>Proposed resolution:</b></p> -<p>Replace 23.1.3 [sequence.reqmts] paragraphs 9 - 11 with:</p> +<p>Replace 23.2.3 [sequence.reqmts] paragraphs 9 - 11 with:</p> <p>For every sequence defined in this clause and in clause lib.strings:</p> @@ -19077,20 +19892,20 @@ implicitly convertible to B. <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>Section:</b> 27.5.3 [fpos] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Vincent Leloup <b>Opened:</b> 2003-11-17 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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. +In section 27.5.3.1 [fpos.members] fpos<stateT>::state() is declared +non const, but in section 27.5.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 +In section 27.5.3.1 [fpos.members], change the declaration of <tt>fpos<stateT>::state()</tt> to const. </p> @@ -19100,14 +19915,14 @@ In section 27.4.3.1 [fpos.members], change the declaration of <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>Section:</b> 27.7.2.4 [ostream::sentry] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Vincent Leloup <b>Opened:</b> 2003-11-18 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> -In section 27.6.2.4 [ostream::sentry] paragraph 4, in description part +In section 27.7.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. @@ -19116,7 +19931,7 @@ const. <p><b>Proposed resolution:</b></p> <p> -In section 27.6.2.4 [ostream::sentry] paragraph 4, change the declaration +In section 27.7.2.4 [ostream::sentry] paragraph 4, change the declaration of <tt>sentry::operator bool()</tt> to const. </p> @@ -19126,13 +19941,13 @@ of <tt>sentry::operator bool()</tt> to const. <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>Section:</b> 27.9.1.4 [filebuf.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Vincent Leloup <b>Opened:</b> 2003-11-20 <b>Last modified:</b> 2008-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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> -In section 27.8.1.4 [filebuf.members] par6, in effects description of +In section 27.9.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> @@ -19149,13 +19964,13 @@ Change overflow(EOF) to overflow(traits::eof()). <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>Section:</b> 27.9.1 [fstreams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Vincent Leloup <b>Opened:</b> 2003-11-20 <b>Last modified:</b> 2009-05-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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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 +<p>27.9.1.9 [ifstream.members] p1, 27.9.1.13 [ofstream.members] p1, +27.9.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> @@ -19208,9 +20023,10 @@ LWG issue <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>Section:</b> D.10.1 [iterator.traits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2003-12-09 <b>Last modified:</b> 2009-05-01</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.traits">issues</a> in [iterator.traits].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> The standard places no restrictions at all on the reference type @@ -19305,7 +20121,7 @@ so I've changed the wording to say that those types may be <p><b>Proposed resolution:</b></p> -<p>In 24.3.1 [iterator.traits], after:</p> +<p>In D.10.1 [iterator.traits], after:</p> <blockquote><p> be defined as the iterator's difference type, value type and iterator @@ -19324,7 +20140,7 @@ 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> +<p>In D.10.1 [iterator.traits], change:</p> <blockquote><p> In the case of an output iterator, the types</p> @@ -19345,7 +20161,7 @@ iterator_traits<Iterator>::pointer <p>may be defined as <tt>void</tt>.</p> </blockquote> -<p>In 24.5.3 [istreambuf.iterator], change:</p> +<p>In 24.6.3 [istreambuf.iterator], change:</p> <blockquote> <pre>typename traits::off_type, charT*, charT&> </pre> @@ -19373,10 +20189,11 @@ needed to be changed. <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>Section:</b> 24.2.6 [random.access.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2004-01-07 <b>Last modified:</b> 2008-09-26</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#random.access.iterators">active issues</a> in [random.access.iterators].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> Table 76, the random access iterator requirement table, says that the @@ -19397,10 +20214,10 @@ Change the return type to "convertible to T const&". <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>Section:</b> 18.2 [support.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Pete Becker <b>Opened:</b> 2004-01-15 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p>Original text:</p> <blockquote><p> @@ -19439,10 +20256,10 @@ undefined." <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>Section:</b> 27.8.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Bill Plauger <b>Opened:</b> 2004-01-30 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <pre> pos_type basic_stringbuf::seekoff(off_type, ios_base::seekdir, ios_base::openmode); @@ -19482,10 +20299,10 @@ is nonzero, the positioning operation fails. <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>Section:</b> 27.4 [iostream.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Bill Plauger <b>Opened:</b> 2004-01-30 <b>Last modified:</b> 2009-05-01</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> Both cerr::tie() and wcerr::tie() are obliged to be null at program @@ -19524,10 +20341,10 @@ Its state is otherwise the same as required for basic_ios<wchar_t>::init <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>Section:</b> 17.6.1.2 [headers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Bill Plauger <b>Opened:</b> 2004-01-30 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p>The C++ Standard effectively requires that the traditional C headers @@ -19615,7 +20432,7 @@ declaring C names in headers. <p><b>Proposed resolution:</b></p> <p> -Add to 17.4.1.2 [headers], para. 4: +Add to 17.6.1.2 [headers], para. 4: </p> <blockquote><p> @@ -19643,7 +20460,7 @@ as if each name placed in the Standard library namespace by the corresponding 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 +namespace scope (3.3.6 [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> @@ -19664,10 +20481,10 @@ names within the namespace <tt>std</tt>.</ins> <i>-- end example</i>] <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>Section:</b> 20.3.6.1 [bitset.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Dag Henriksson <b>Opened:</b> 2004-01-30 <b>Last modified:</b> 2009-05-01</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> The constructor from unsigned long says it initializes "the first M @@ -19684,7 +20501,7 @@ guaranteed to have any corresponding bit values in val. <p><b>Proposed resolution:</b></p> -<p>In 23.3.5.1 [bitset.cons] paragraph 2, change "M is the smaller of +<p>In 20.3.6.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 @@ -19697,10 +20514,10 @@ guaranteed to have any corresponding bit values in val. <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>Section:</b> 27.9.1 [fstreams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Ben Hutchings <b>Opened:</b> 2004-04-01 <b>Last modified:</b> 2009-05-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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> The second parameters of the non-default constructor and of the open @@ -19714,14 +20531,14 @@ that it is intended to be callable with one argument. <p><b>Proposed resolution:</b></p> -<p>In 27.8.1.15 [fstream.cons], change</p> +<p>In 27.9.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> +<p>In 27.9.1.17 [fstream.members], change</p> <pre> void open(const char*s, ios_base::openmode mode); </pre> <p>to</p> @@ -19735,9 +20552,9 @@ that it is intended to be callable with one argument. <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>Section:</b> 22.4.5.1.2 [locale.time.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Bill Plauger <b>Opened:</b> 2004-03-23 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> Template time_get currently contains difficult, if not impossible, @@ -19840,10 +20657,10 @@ An implementation may also accept additional implementation-defined formats. <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>Section:</b> 23.3.6 [vector], 23.4.1 [map] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Thorsten Ottosen <b>Opened:</b> 2004-05-12 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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> @@ -19870,14 +20687,14 @@ at() (which will then throw if the vector is empty). </li> <p><b>Proposed resolution:</b></p> -<p>In 23.2.6 [vector], add the following to the <tt>vector</tt> +<p>In 23.3.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> +<p>Add a new subsection of 23.3.6 [vector]:</p> <blockquote> <p>23.2.4.x <tt>vector</tt> data access</p> <pre> pointer data(); @@ -19889,13 +20706,13 @@ at() (which will then throw if the vector is empty). </li> <p><b>Throws:</b> Nothing.</p> </blockquote> -<p>In 23.3.1 [map], add the following to the <tt>map</tt> +<p>In 23.4.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> +<p>Add the following to 23.4.1.2 [map.access]:</p> <blockquote> <pre> T& at(const key_type& x); const T& at(const key_type& x) const; @@ -19921,15 +20738,15 @@ synopsis immediately after the line for operator[]:</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>Section:</b> 17.6.1.2 [headers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Steve Clamage <b>Opened:</b> 2004-06-03 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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 +<p>Section 17.6.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> @@ -19968,9 +20785,9 @@ or <ciso646> has no effect. </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>Section:</b> 21.2.3.1 [char.traits.specializations.char] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2004-06-28 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> @@ -20019,10 +20836,10 @@ imposed by Table 37 on compare() when char is signed. <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>Section:</b> 27.5.4.3 [iostate.flags] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2004-06-28 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p>The program below is required to compile but when run it typically @@ -20091,10 +20908,10 @@ the value need not be valid. <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>Section:</b> 23.3.6 [vector] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2004-06-28 <b>Last modified:</b> 2009-05-01</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> @@ -20118,10 +20935,10 @@ vector<bool> from [lib.vector.bool]. <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>Section:</b> 27.7.2.6.4 [ostream.inserters.character] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2004-07-01 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> @@ -20142,10 +20959,11 @@ I propose to strike the Footnote. <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>Section:</b> 25.3.4 [alg.foreach] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Stephan T. Lavavej, Jaakko Jarvi <b>Opened:</b> 2004-07-09 <b>Last modified:</b> 2008-09-26</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#alg.foreach">active issues</a> in [alg.foreach].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> It is not clear whether the function object passed to for_each is allowed to @@ -20207,7 +21025,7 @@ 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 +<p>Add a nonnormative note to the Effects in 25.3.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. @@ -20227,10 +21045,10 @@ passed to it. <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>Section:</b> 24.2.4 [forward.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2004-07-11 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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> @@ -20296,9 +21114,9 @@ This is a defect because it constrains an lvalue to returning a modifiable lvalu <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>Section:</b> 25.4.11 [alg.rotate] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2004-11-22 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> rotate takes 3 iterators: first, middle and last which point into a @@ -20345,14 +21163,14 @@ a significant benefit to the change. ForwardIterator last); </pre></blockquote> -<p>In 25.2.11 [alg.rotate], change:</p> +<p>In 25.4.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> +<p>In 25.4.11 [alg.rotate] insert a new paragraph after p1:</p> <blockquote> <p><b>Returns</b>: <tt>first + (last - middle)</tt>.</p> @@ -20382,10 +21200,11 @@ Toronto: moved to Ready. <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>Section:</b> 22 [localization] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2005-01-10 <b>Last modified:</b> 2008-09-26</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#localization">active issues</a> in [localization].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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 @@ -20421,7 +21240,7 @@ for Intl.</li> </ul> <p><b>Proposed resolution:</b></p> -<p>Change 17.3.2.1 [type.descriptions], paragraph 1, from:</p> +<p>Change 17.5.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 @@ -20458,13 +21277,13 @@ requirements of charT (described in 21 [strings]). <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>Section:</b> 23.3.6 [vector] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> richard@ex-parrot.com <b>Opened:</b> 2005-02-10 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> -In the synopsis of the std::vector<bool> specialisation in 23.2.6 [vector], +In the synopsis of the std::vector<bool> specialisation in 23.3.6 [vector], the non-template assign() function has the signature</p> <pre> void assign( size_type n, const T& t ); @@ -20482,10 +21301,10 @@ the non-template assign() function has the signature</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>Section:</b> 18.3.1.2 [numeric.limits.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2005-03-02 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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> @@ -20545,10 +21364,10 @@ at runtime. <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>Section:</b> X [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#CD1">CD1</a> + <b>Submitter:</b> Walter Brown <b>Opened:</b> 2005-07-03 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> Table 17: Random distribution requirements @@ -20586,10 +21405,11 @@ Berlin: Voted to WP. N1932 adopts the proposed resolution: see Table 5 row 1. <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>Section:</b> 26.5 [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#CD1">CD1</a> + <b>Submitter:</b> Walter Brown <b>Opened:</b> 2005-07-03 <b>Last modified:</b> 2008-09-26</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand">active issues</a> in [rand].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> Paragraph 11 of [tr.rand.var] equires that the member template @@ -20628,10 +21448,10 @@ Precondition: <tt>distribution().operator()(e,value)</tt> is well-formed. <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>Section:</b> 26.5.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#CD1">CD1</a> + <b>Submitter:</b> Walter Brown <b>Opened:</b> 2005-07-03 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> The fifth of these engines with predefined parameters, ranlux64_base_01, @@ -20712,11 +21532,11 @@ just above paragraph 5. <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>Section:</b> 23.2.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#CD1">CD1</a> + <b>Submitter:</b> Matt Austern <b>Opened:</b> 2005-07-03 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> Issue 371 deals with stability of multiset/multimap under insert and erase @@ -20743,7 +21563,7 @@ Wording for the proposed resolution is taken from the equivalent text for associ </p> <p> -Change 23.1.5 [unord.req], Unordered associative containers, paragraph 6 to: +Change 23.2.5 [unord.req], Unordered associative containers, paragraph 6 to: </p> <blockquote><p> @@ -20759,7 +21579,7 @@ preserve the relative ordering of equivalent elements.</ins> </p></blockquote> <p> -Change 23.1.5 [unord.req], Unordered associative containers, paragraph 8 to: +Change 23.2.5 [unord.req], Unordered associative containers, paragraph 8 to: </p> <blockquote> @@ -20781,11 +21601,11 @@ preserves the relative ordering of equivalent elements.</ins></p> <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>Section:</b> 23.3.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#CD1">CD1</a> + <b>Submitter:</b> Pete Becker <b>Opened:</b> 2005-07-03 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> <tt>array<>::data()</tt> is present in the class synopsis, but not documented. @@ -20816,9 +21636,9 @@ of <tt>data()</tt> is unspecified. <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>Section:</b> 20.7.12.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#CD1">CD1</a> + <b>Submitter:</b> Pete Becker <b>Opened:</b> 2005-07-03 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> In the original proposal for binders, the return type of bind() when @@ -20859,9 +21679,10 @@ Peter provided wording. <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>Section:</b> 20.7.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#CD1">CD1</a> + <b>Submitter:</b> Pete Becker <b>Opened:</b> 2005-07-03 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#refwrap">issues</a> in [refwrap].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> 2.1.2/3, second bullet item currently says that reference_wrapper<T> is @@ -20929,11 +21750,113 @@ function's cv-qualifiers); the type <tt>T1</tt> is <tt><i>cv</i> T0*</tt></ins> <hr> +<h3><a name="522"></a>522. Tuple doesn't define swap</h3> +<p><b>Section:</b> 20.5 [tuple], TR1 6.1 [tr.tuple] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Andy Koenig <b>Opened:</b> 2005-07-03 <b>Last modified:</b> 2008-09-26</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#CD1">CD1</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.5 [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.5.2 [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="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>Section:</b> 28 [re] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Eric Niebler <b>Opened:</b> 2005-07-01 <b>Last modified:</b> 2008-09-26</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#re">active issues</a> in [re].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> This defect is also being discussed on the Boost developers list. The @@ -21008,11 +21931,11 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a <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>Section:</b> 20.7.12.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#CD1">CD1</a> + <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2005-10-01 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> The original bind proposal gives the guarantee that tr1::bind(f, t1, @@ -21076,7 +21999,7 @@ throws an exception. <p><b>Proposed resolution:</b></p> <p> -In 20.6.11.1.3 [func.bind.bind], add a new paragraph after p2: +In 20.7.12.1.3 [func.bind.bind], add a new paragraph after p2: </p> <blockquote> @@ -21085,7 +22008,7 @@ 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: +In 20.7.12.1.3 [func.bind.bind], add a new paragraph after p4: </p> <blockquote> @@ -21100,17 +22023,17 @@ in the <tt>BoundArgs...</tt> pack expansion throws an exception. <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>Section:</b> 21.4 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Matt Austern <b>Opened:</b> 2005-11-15 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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] +<p>We almost require contiguity already. Clause 23.4.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> @@ -21125,7 +22048,7 @@ in the <tt>BoundArgs...</tt> pack expansion throws an exception. <p><b>Proposed resolution:</b></p> -<p>Add the following text to the end of 21.3 [basic.string], +<p>Add the following text to the end of 21.4 [basic.string], paragraph 2. </p> <blockquote> @@ -21154,10 +22077,10 @@ more design choices. <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>Section:</b> 27.7.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2005-11-23 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> The array forms of unformatted input functions don't seem to have well-defined @@ -21230,10 +22153,10 @@ writing to out of bounds memory when <tt>n == 0</tt>. Martin provided fix. <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>Section:</b> 20.8.13.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#CD1">CD1</a> + <b>Submitter:</b> Paolo Carlini <b>Opened:</b> 2005-11-09 <b>Last modified:</b> 2009-05-01</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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> @@ -21261,11 +22184,11 @@ If <tt><del>*this</del> <ins>p</ins></tt> <i>owns</i> a deleter <tt>d</tt>... <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>Section:</b> 21.4 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2005-11-16 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> OK, we all know std::basic_string is bloated and already has way too @@ -21396,10 +22319,10 @@ Berlin: Has support. Alisdair provided wording. <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>Section:</b> 21.4.6.8 [string::swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2005-12-14 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> std::string::swap currently says for effects and postcondition: @@ -21443,10 +22366,10 @@ characters that <del>were</del> <ins>was</ins> in <tt><i>s</i></tt>, <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>Section:</b> 27.7.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Paolo Carlini <b>Opened:</b> 2006-02-12 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> In the most recent working draft, I'm still seeing: @@ -21497,10 +22420,11 @@ After 27.6.2.4p3 change: <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>Section:</b> 25.4.9 [alg.unique] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2006-02-09 <b>Last modified:</b> 2008-09-26</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#alg.unique">active issues</a> in [alg.unique].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> I believe I botched the resolution of @@ -21555,10 +22479,10 @@ Otherwise CopyConstructible is not required. <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>Section:</b> 20.8.13.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#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2005-10-15 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> I'm trying to reconcile the note in tr.util.smartptr.shared.obs, p6 @@ -21613,11 +22537,11 @@ definition) of the function shall be well-formed.</ins> <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>Section:</b> 20.8.13.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#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2005-10-16 <b>Last modified:</b> 2008-09-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#WP">WP</a> status.</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> Is the void specialization of the template assignment operator taking @@ -21694,10 +22618,10 @@ public: <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>Section:</b> 20.8.13.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#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2005-10-18 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> Peter Dimov wrote: @@ -21734,7 +22658,7 @@ capture the intent. <p><b>Proposed resolution:</b></p> <p> -Change 20.7.12.2.5 [util.smartptr.shared.obs] p12: +Change 20.8.13.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 @@ -21742,7 +22666,7 @@ 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: +Change 20.8.13.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 @@ -21755,9 +22679,9 @@ debugging and testing purposes, not for production code.</del> --<i>end note</i> <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>Section:</b> 26.6.4 [class.slice] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2005-11-03 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> If one explicitly constructs a slice or glice with the default @@ -21797,11 +22721,11 @@ There is a similar question and wording for gslice at 26.3.6.1p1. <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><i>[Martin suggests removing the second sentence in 26.6.4.1 [cons.slice] as well.]</i></p> <p> -Change 26.5.4.1 [cons.slice]: +Change 26.6.4.1 [cons.slice]: </p> <blockquote><p> @@ -21813,7 +22737,7 @@ takes a start, length, and stride parameter. </p></blockquote> <p> -Change 26.5.6.1 [gslice.cons]: +Change 26.6.6.1 [gslice.cons]: </p> <blockquote><p> @@ -21831,10 +22755,10 @@ lengths, and strides, as explained in the previous section. <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>Section:</b> 20.8.13.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#CD1">CD1</a> + <b>Submitter:</b> Matt Austern <b>Opened:</b> 2006-01-10 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> The description of ~shared_ptr doesn't say when the shared_ptr's deleter, if @@ -21849,7 +22773,7 @@ instances). We should say which it is. <p><b>Proposed resolution:</b></p> <p> -Add after the first sentence of 20.7.12.2.11 [util.smartptr.getdeleter]/1: +Add after the first sentence of 20.8.13.2.11 [util.smartptr.getdeleter]/1: </p> <blockquote> <p> @@ -21869,10 +22793,10 @@ This can happen if the implementation doesn't destroy the deleter until all <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>Section:</b> 26.8 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2006-01-12 <b>Last modified:</b> 2008-09-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#WP">WP</a> status.</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> Assuming we adopt the @@ -21984,7 +22908,7 @@ wording provided. <p><b>Proposed resolution:</b></p> <p> -Change 26.7 [c.math] p10: +Change 26.8 [c.math] p10: </p> <blockquote> @@ -22007,9 +22931,9 @@ The added signatures are: <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>Section:</b> 26.4.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#CD1">CD1</a> + <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2006-01-23 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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> @@ -22068,9 +22992,10 @@ note</i>]</ins> <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>Section:</b> 25.4.12 [alg.random.shuffle] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-01-25 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.random.shuffle">issues</a> in [alg.random.shuffle].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> ...is specified to shuffle its range by calling swap but not how @@ -22109,14 +23034,14 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a <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>Section:</b> 18.3.1 [limits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-02-19 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> -18.2.1 [limits], p2 requires implementations to provide specializations of the +18.3.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 @@ -22159,7 +23084,7 @@ template <class T> class numeric_limits<const volatile T>; <p> -Add a new paragraph to the end of 18.2.1.1 [numeric.limits], with the following +Add a new paragraph to the end of 18.3.1.1 [numeric.limits], with the following text: </p> @@ -22184,9 +23109,9 @@ automatically. <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>Section:</b> 24.7.6.5 [inserter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2006-02-21 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> The declaration of <tt>std::inserter</tt> is: @@ -22350,10 +23275,10 @@ correct in the absence of concepts. Proposed Disposition: Ready <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>Section:</b> 27.8 [string.streams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-02-23 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> @@ -22445,10 +23370,10 @@ Kona (2007) Moved to Ready. <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>Section:</b> 27.8.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-02-23 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> According to Table 92 (unchanged by issue 432), when <code>(way == @@ -22503,10 +23428,10 @@ Kona (2007) Moved to Ready. <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>Section:</b> 27.7.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-02-23 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> @@ -22575,10 +23500,10 @@ location of the array. <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>Section:</b> 27.7 [iostream.format] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-02-25 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> @@ -22642,10 +23567,10 @@ Kona (2007): Proposed Disposition: Ready <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>Section:</b> 27.4 [iostream.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Pete Becker <b>Opened:</b> 2006-04-18 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> lib.iostream.objects requires that the standard stream objects are never @@ -22662,7 +23587,7 @@ not destroyed during program execution." <p><b>Proposed resolution:</b></p> <p> -Change 27.3 [iostream.objects]/1: +Change 27.4 [iostream.objects]/1: </p> <blockquote> @@ -22682,7 +23607,7 @@ objects defined later in that translation unit</del>. <p><i>[ -Kona (2007): From 27.3 [iostream.objects]/2, strike the words "...and these stream objects +Kona (2007): From 27.4 [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 @@ -22694,9 +23619,10 @@ Disposition: Review <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>Section:</b> 20.8.13.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#CD1">CD1</a> + <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2006-04-23 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared.dest">issues</a> in [util.smartptr.shared.dest].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> [tr.util.smartptr.shared.dest] says in its second bullet: @@ -22772,10 +23698,10 @@ after <tt>*this</tt> is destroyed. <i>--end note</i>] <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>Section:</b> 25.3.7 [alg.find.first.of] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Doug Gregor <b>Opened:</b> 2006-04-25 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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 @@ -22825,9 +23751,9 @@ template<class <del>ForwardIterator1</del><ins>InputIterator1</ins>, class Fo <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>Section:</b> 25.5.3.2 [upper.bound] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Seungbeom Kim <b>Opened:</b> 2006-05-03 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> ISO/IEC 14882:2003 says: @@ -22875,10 +23801,10 @@ conditions hold: <tt>!(value < *j)</tt> or <tt><i>comp</i>(<i>value</i>, *j) <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>Section:</b> 20.8.6.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-05-17 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> @@ -22934,10 +23860,10 @@ adjacent element is often a good choice to pass for this argument.</del> <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>Section:</b> 27.7.2.7 [ostream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-06-14 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> @@ -22998,10 +23924,10 @@ Kona (2007): Proposed Disposition: Ready <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>Section:</b> 21.4.8.9 [string.io] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-06-22 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> @@ -23081,11 +24007,11 @@ indicates a failure. <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>Section:</b> 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2006-08-02 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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> @@ -23142,10 +24068,10 @@ easy to fix this up as a safety net and as a clear statement of intent. <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>Section:</b> 18.4 [cstdint], TR1 8.22 [tr.c99.cstdint] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Walter Brown <b>Opened:</b> 2006-08-28 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> Clause 18.3 of the current Working Paper (N2009) deals with the new C++ headers @@ -23185,10 +24111,10 @@ particular, the symbols __STDC_LIMIT_MACROS and __STDC_CONSTANT_MACROS <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>Section:</b> 26.4.7 [complex.value.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Stefan Große Pawig <b>Opened:</b> 2006-09-24 <b>Last modified:</b> 2009-03-21</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> TR1 introduced, in the C compatibility chapter, the function @@ -23305,14 +24231,14 @@ Bill believes that abs() is a suitable overload. We should remove fabs(). <p><b>Proposed resolution:</b></p> <p> -Change the synopsis in 26.3.1 [complex.synopsis]: +Change the synopsis in 26.4.1 [complex.syn]: </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: +Remove 26.4.7 [complex.value.ops], p7: </p> <blockquote> @@ -23338,13 +24264,13 @@ Proposed Disposition: Ready <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>Section:</b> 27.9.1.4 [filebuf.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Thomas Plum <b>Opened:</b> 2006-09-26 <b>Last modified:</b> 2008-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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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 +In testing 27.9.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> @@ -23390,7 +24316,7 @@ the same thing as "a+" already proposed in the issue. <p><b>Proposed resolution:</b></p> <p> -Add to the table "File open modes" in 27.8.1.4 [filebuf.members]: +Add to the table "File open modes" in 27.9.1.4 [filebuf.members]: </p> <blockquote> @@ -23476,7 +24402,7 @@ Kona (2007) Added proposed wording and moved to Review. <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> + <b>Submitter:</b> Daniel Krugler <b>Opened:</b> 2006-05-28 <b>Last modified:</b> 2007-04-21</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> @@ -23555,7 +24481,7 @@ Change the <b>Returns:</b> clause in 3.2.4.4 to: <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> + <b>Submitter:</b> Daniel Krugler <b>Opened:</b> 2006-05-28 <b>Last modified:</b> 2007-04-21</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> @@ -23613,7 +24539,7 @@ decimal128 is a <em>decimal128</em> number, which is encoded in 16 consecutive < <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> + <b>Submitter:</b> Daniel Krugler <b>Opened:</b> 2006-05-28 <b>Last modified:</b> 2007-04-21</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> @@ -23646,7 +24572,7 @@ Change "3.9.1 Additions to <code><cwchar></code> synopsis" to: <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> + <b>Submitter:</b> Daniel Krugler <b>Opened:</b> 2006-05-28 <b>Last modified:</b> 2007-04-21</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> @@ -23688,7 +24614,7 @@ In "3.3 Additions to header <code><limits></code>" change numeric_limits&l <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> + <b>Submitter:</b> Daniel Krugler <b>Opened:</b> 2006-05-28 <b>Last modified:</b> 2007-04-21</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> @@ -23717,7 +24643,7 @@ collectively described as the <i>basic floating types</i></ins>. <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> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-05-28 <b>Last modified:</b> 2007-04-21</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> @@ -23836,7 +24762,7 @@ Change "3.2.4.1 construct/copy/destroy" as follows: <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> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-05-28 <b>Last modified:</b> 2007-07-25</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> @@ -23958,7 +24884,7 @@ Redmond: We would prefer to rename "extended" to "decimal". <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> + <b>Submitter:</b> Robert Klarer <b>Opened:</b> 2006-10-17 <b>Last modified:</b> 2007-04-21</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> @@ -24013,11 +24939,10 @@ floating-point types <code>decimal32</code>, <code>decimal64</code>, and <code>d <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>Section:</b> 26.5.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Charles Karney <b>Opened:</b> 2006-10-26 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> Short seed vectors of 32-bit quantities all result in different states. However @@ -24065,11 +24990,10 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a <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>Section:</b> 26.5.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Charles Karney <b>Opened:</b> 2006-10-26 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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 @@ -24101,9 +25025,9 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a <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>Section:</b> 26.5.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#CD1">CD1</a> + <b>Submitter:</b> Walter E. Brown <b>Opened:</b> 2006-11-02 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> In preparing N2111, an error on my part resulted in the omission of the @@ -24137,9 +25061,9 @@ and accept my apologies for the oversight. <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>Section:</b> 20.7.16.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#CD1">CD1</a> + <b>Submitter:</b> Scott Meyers <b>Opened:</b> 2006-11-02 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> My suggestion is that implementers of both tr1::function and its @@ -24208,9 +25132,10 @@ function pointer (a "bound member function").</ins> <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>Section:</b> 17.6.3.8 [res.on.functions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Nicola Musatti <b>Opened:</b> 2006-11-13 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#res.on.functions">issues</a> in [res.on.functions].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> In the latest available draft standard @@ -24276,10 +25201,10 @@ component</ins>. </li> <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>Section:</b> 18.3.1.2 [numeric.limits.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Chris Jefferson <b>Opened:</b> 2006-11-10 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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 @@ -24312,7 +25237,7 @@ happens to b modulo? A: the standard already seems to require that. <p><b>Proposed resolution:</b></p> <p> -Suggest 18.2.1.2 [numeric.limits.members], paragraph 57 is amended to: +Suggest 18.3.1.2 [numeric.limits.members], paragraph 57 is amended to: </p> <blockquote><p> @@ -24331,13 +25256,13 @@ differs from the true value by an integer multiple of <tt>(max() - min() + <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>Section:</b> 18.3.1.5 [numeric.special] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Bo Persson <b>Opened:</b> 2006-11-20 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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 +Section 18.3.1.5 [numeric.special] starts out by saying that "All members shall be provided for all specializations." </p> <p> @@ -24379,7 +25304,7 @@ We are also missing a statement regarding for what specializations this member h <p><b>Proposed resolution:</b></p> <p> -Change and add after 18.2.1.2 [numeric.limits.members], p11: +Change and add after 18.3.1.2 [numeric.limits.members], p11: </p> <blockquote> @@ -24396,7 +25321,7 @@ differ <del>by only one epsilon</del> are always differentiated. </blockquote> <p> -Change 18.2.1.5 [numeric.special], p2: +Change 18.3.1.5 [numeric.special], p2: </p> <blockquote><pre>template<> class numeric_limits<float> { @@ -24409,7 +25334,7 @@ public: </pre></blockquote> <p> -Change 18.2.1.5 [numeric.special], p3: +Change 18.3.1.5 [numeric.special], p3: </p> <blockquote><pre>template<> class numeric_limits<bool> { @@ -24429,10 +25354,10 @@ public: <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>Section:</b> 22.4.1.2 [locale.ctype.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Bo Persson <b>Opened:</b> 2006-12-16 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> Section 22.2.1.2 defines the ctype_byname class template. It contains the @@ -24458,9 +25383,9 @@ as this is a dependent type, it should obviously be <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>Section:</b> 26.6.2.7 [valarray.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Gabriel Dos Reis <b>Opened:</b> 2007-01-10 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> I would respectfully request an issue be opened with the intention to @@ -24470,7 +25395,7 @@ clarify the wording for <tt>size() == 0</tt> for <tt>cshift</tt>. <p><b>Proposed resolution:</b></p> <p> -Change 26.5.2.7 [valarray.members], paragraph 10: +Change 26.6.2.7 [valarray.members], paragraph 10: </p> <blockquote> @@ -24515,15 +25440,16 @@ Kona (2007) Changed proposed wording, added rationale and set to Review. <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>Section:</b> 18.10 [support.runtime] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Lawrence Crowl <b>Opened:</b> 2007-01-12 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#support.runtime">issues</a> in [support.runtime].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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 +18.10 [support.runtime] -4- Other runtime support </p> <blockquote><p> The function signature <tt>longjmp(jmp_buf jbuf, int val)</tt> has more restricted @@ -24549,7 +25475,7 @@ caught only at the point of the setjmp, the behavior is undefined." 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 +In 18.10 [support.runtime] paragraph 4, change </p> <blockquote><p> @@ -24569,11 +25495,11 @@ undefined behavior if replacing the <tt>setjmp</tt> and <tt>longjmp</tt> by <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>Section:</b> 26.6.2.1 [valarray.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-01-20 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> @@ -24598,7 +25524,7 @@ language. <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]): +Reword the <i>Effects</i> clause and <i>Footnote 280</i> as follows (26.6.2.1 [valarray.cons]): </p> <blockquote> @@ -24639,10 +25565,10 @@ function. <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>Section:</b> 26.6 [numarray] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-01-20 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> @@ -24696,8 +25622,8 @@ 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: +Change the signature in 26.6.5 [template.slice.array] and +26.6.5.1 [slice.arr.assign] as follows: </p> <blockquote><pre> @@ -24706,8 +25632,8 @@ Change the signature in 26.5.5 [template.slice.array] and </pre></blockquote> <p> -Change the signature in 26.5.7 [template.gslice.array] and -26.5.7.1 [gslice.array.assign] as follows: +Change the signature in 26.6.7 [template.gslice.array] and +26.6.7.1 [gslice.array.assign] as follows: </p> <blockquote><pre> @@ -24716,7 +25642,7 @@ Change the signature in 26.5.7 [template.gslice.array] and </pre></blockquote> <p> -Change the signature in 26.5.8 [template.mask.array] and 26.5.8.1 [mask.array.assign] as +Change the signature in 26.6.8 [template.mask.array] and 26.6.8.1 [mask.array.assign] as follows: </p> @@ -24726,8 +25652,8 @@ follows: </pre></blockquote> <p> -Change the signature in 26.5.9 [template.indirect.array] and -26.5.9.1 [indirect.array.assign] as follows: +Change the signature in 26.6.9 [template.indirect.array] and +26.6.9.1 [indirect.array.assign] as follows: </p> <blockquote><pre> @@ -24746,9 +25672,9 @@ Kona (2007) Added const qualification to the return types and set to Ready. <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>Section:</b> 27.9.1.17 [fstream.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-01-20 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> @@ -24773,7 +25699,7 @@ 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]. +17.6.4.10 [res.on.exception.handling]. </p> <p> @@ -24841,7 +25767,7 @@ to catch and swallow any exceptions thrown by <code>close()</code>. <p> Specifically, we propose to make the following edits in -27.8.1.4 [filebuf.members]: +27.9.1.4 [filebuf.members]: </p> <blockquote> @@ -24873,7 +25799,7 @@ rethrown after closing the file.</ins> </blockquote> <p> -And to make the following edits in 27.8.1.2 [filebuf.cons]. +And to make the following edits in 27.9.1.2 [filebuf.cons]. </p> <blockquote> @@ -24888,7 +25814,7 @@ And to make the following edits in 27.8.1.2 [filebuf.cons]. <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> +17.6.4.10 [res.on.exception.handling]).</ins> </p> </blockquote> @@ -24899,13 +25825,13 @@ the exception is caught but not rethrown (see <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>Section:</b> 27.2.1 [iostream.limits.imbue] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-01-20 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> -27.1.1 [iostream.limits.imbue] specifies that "no function described in +27.2.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." @@ -24925,7 +25851,7 @@ to do just that: call <code>basic_streambuf::imbue()</code>. 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: +change 27.2.1 [iostream.limits.imbue], p1 to read: </p> <blockquote><p> @@ -24943,9 +25869,9 @@ causes any instance of <code>basic_ios::imbue</code> or <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>Section:</b> 26.6.2.2 [valarray.assign] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-01-20 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> @@ -24958,7 +25884,7 @@ undefined behavior. <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 +on <code>slice_array</code> et al (26.6.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. @@ -25016,7 +25942,7 @@ the thread starting at c++std-lib-17786. 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: +<i>Requires</i> clause to 26.6.2.2 [valarray.assign] as follows: </p> <blockquote><p> @@ -25036,7 +25962,7 @@ to implement <code>valarray</code> efficiently. <p><b>Proposed resolution:</b></p> <p> -Insert new paragraph into 26.5.2.2 [valarray.assign]: +Insert new paragraph into 26.6.2.2 [valarray.assign]: </p> <blockquote> @@ -25062,13 +25988,13 @@ These operators allow the results of a generalized subscripting operation to be <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>Section:</b> 28.9 [re.regex] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Bo Persson <b>Opened:</b> 2007-01-23 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> -Section 28.8 [re.regex] lists a constructor +Section 28.9 [re.regex] lists a constructor </p> <blockquote><pre>template<class InputIterator> @@ -25077,14 +26003,14 @@ basic_regex(InputIterator first, InputIterator last, </pre></blockquote> <p> -However, in section 28.8.2 [re.regex.construct], this constructor takes a +However, in section 28.9.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]: +Change 28.9.2 [re.regex.construct]: </p> <blockquote><pre>template <class <del>ForwardIterator</del> <ins>InputIterator</ins>> @@ -25098,16 +26024,110 @@ Change 28.8.2 [re.regex.construct]: <hr> +<h3><a name="629"></a>629. complex<t> insertion and locale dependence</t></h3> +<p><b>Section:</b> 26.4.6 [complex.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Gabriel Dos Reis <b>Opened:</b> 2007-01-28 <b>Last modified:</b> 2008-09-26</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#CD1">CD1</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.4.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="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>Section:</b> 20.8.6.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2007-02-07 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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: +20.8.6.1 [allocator.members] says: </p> <blockquote> <pre>pointer address(reference <i>x</i>) const;</pre> @@ -25119,7 +26139,7 @@ Change 28.8.2 [re.regex.construct]: </blockquote> <p> -20.7.5.1 [allocator.members] defines <tt>CopyConstructible</tt> which currently not +20.8.6.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 @@ -25150,7 +26170,7 @@ is expected to make use of <tt>allocator::address</tt> mandatory for containers. <p><b>Proposed resolution:</b></p> <p> -Change 20.7.5.1 [allocator.members]: +Change 20.8.6.1 [allocator.members]: </p> <blockquote> @@ -25192,12 +26212,12 @@ issue to Ready status to be voted into the WP at Kona. <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>Section:</b> 23.3.2.3 [deque.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Steve LoBasso <b>Opened:</b> 2007-02-17 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> -The standard states at 23.2.2.3 [deque.modifiers]/4: +The standard states at 23.3.2.3 [deque.modifiers]/4: </p> <blockquote><pre>deque erase(...) </pre> @@ -25243,7 +26263,7 @@ iterators. <p><b>Proposed resolution:</b></p> <p> -Change 23.2.2.3 [deque.modifiers], p4: +Change 23.3.2.3 [deque.modifiers], p4: </p> <blockquote> @@ -25288,13 +26308,13 @@ Spertus to evaluate and, if need be, file an issue. <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>Section:</b> 27.7.2.6.2 [ostream.inserters.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-02-17 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> -The arithmetic inserters are described in 27.6.2.6.2 [ostream.inserters.arithmetic]. +The arithmetic inserters are described in 27.7.2.6.2 [ostream.inserters.arithmetic]. Although the section starts with a listing of the inserters including the new ones: </p> @@ -25321,7 +26341,7 @@ back. <p><b>Proposed resolution:</b></p> <p> -In 27.6.2.6.2 [ostream.inserters.arithmetic]/1 change the third sentence +In 27.7.2.6.2 [ostream.inserters.arithmetic]/1 change the third sentence </p> <blockquote> @@ -25337,9 +26357,9 @@ occurs as if it performed the following code fragment: <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>Section:</b> 27.9.1.1 [filebuf], 22.4.2.2.2 [facet.num.put.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-02-20 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> The current standard 14882:2003(E) as well as N2134 have the @@ -25348,7 +26368,7 @@ defects: </p> <p> -27.8.1.1 [filebuf]/5 says: +27.9.1.1 [filebuf]/5 says: </p> <blockquote> @@ -25367,13 +26387,13 @@ 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>. +A similar issue arises in 22.4.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 +In 27.9.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> = @@ -25381,7 +26401,7 @@ In 27.8.1.1 [filebuf]/5 change the "as if" code </pre></blockquote> <p> -In 22.2.2.2.2 [facet.num.put.virtuals]/15 (This is para 5 in N2134) change +In 22.4.2.2.2 [facet.num.put.virtuals]/15 (This is para 5 in N2134) change </p> <blockquote> @@ -25403,21 +26423,21 @@ A local variable <tt><i>punct</i></tt> is initialized via <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>Section:</b> 28.11.4 [re.results.form] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-02-26 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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 +28.11.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. +as const in 28.11 [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]. +in section 28.11.4 [re.results.form]. </p> @@ -25426,24 +26446,24 @@ in section 28.10.4 [re.results.form]. <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>Section:</b> 28.13.2 [re.tokiter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-03-05 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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 +Both the class definition of regex_token_iterator (28.13.2 +[re.tokiter]/6) and the latter member specifications (28.13.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). +unexpectedly also declared as non-const in 28.13.2 [re.tokiter]/6 +as well as in (28.13.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 +1) In (28.13.2 [re.tokiter]/6) change the current declarations </p> <blockquote><pre>bool operator==(const regex_token_iterator&) <ins>const</ins>; @@ -25453,7 +26473,7 @@ const value_type* operator->() <ins>const</ins>; </pre></blockquote> <p> -2) In 28.12.2.2 [re.tokiter.comp] change the following declarations +2) In 28.13.2.2 [re.tokiter.comp] change the following declarations </p> <blockquote><pre>bool operator==(const regex_token_iterator& right) <ins>const</ins>; @@ -25461,7 +26481,7 @@ 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 +3) In 28.13.2.3 [re.tokiter.deref] change the following declarations </p> <blockquote><pre>const value_type& operator*() <ins>const</ins>; @@ -25481,17 +26501,17 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a <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>Section:</b> 28.13.2.1 [re.tokiter.cnstr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-03-05 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> -The text provided in 28.12.2.1 [re.tokiter.cnstr]/2+3 describes +The text provided in 28.13.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 +an issue, if one takes 28.13.2 [re.tokiter]/9 into account, which explains the notion of a "current match" by saying: </p> @@ -25510,7 +26530,7 @@ are legal arguments or not - it seems they are not. <p><b>Proposed resolution:</b></p> <p> Add the following precondition paragraph just before the current -28.12.2.1 [re.tokiter.cnstr]/2: +28.13.2.1 [re.tokiter.cnstr]/2: </p> <blockquote><p> @@ -25530,22 +26550,22 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a <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>Section:</b> 28.13.1 [re.regiter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-03-05 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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) +<p>Both the class definition of regex_iterator (28.13.1 [re.regiter]/1) +and the latter member specification (28.13.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). +unexpectedly also declared as non-const in 28.13.1 [re.regiter]/1 +as well as in (28.13.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 +1) In (28.13.1 [re.regiter]/1) change the current declarations </p> <blockquote><pre>bool operator==(const regex_iterator&) <ins>const</ins>; @@ -25555,7 +26575,7 @@ const value_type* operator->() <ins>const</ins>; </pre></blockquote> <p> -2) In 28.12.1.3 [re.regiter.deref] change the following declarations +2) In 28.13.1.3 [re.regiter.deref] change the following declarations </p> <blockquote><pre>const value_type& operator*() <ins>const</ins>; @@ -25563,7 +26583,7 @@ const value_type* operator->() <ins>const</ins>; </pre></blockquote> <p> -3) In 28.12.1.2 [re.regiter.comp] change the following declarations +3) In 28.13.1.2 [re.regiter.comp] change the following declarations </p> <blockquote><pre>bool operator==(const regex_iterator& right) <ins>const</ins>; @@ -25583,13 +26603,13 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a <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>Section:</b> X [rand.req.eng] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-03-08 <b>Last modified:</b> 2009-05-01</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> -Table 98 and para 5 in 26.4.1.3 [rand.req.eng] specify +Table 98 and para 5 in X [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 @@ -25630,41 +26650,41 @@ public: RanNumEngine() : state(42) {} bool operator==(RanNumEngine other) const { - return state == other.state; + 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; + 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; + //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 + 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 + RanNumEngine x; + s << x; + RanNumEngine v; + s >> v; + assert(x == v); // Fails: 42 == 34 } </pre></blockquote> @@ -25713,13 +26733,13 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a <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>Section:</b> 26.5.7.2 [rand.util.canonical] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-03-08 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> -In 26.4.2 [rand.synopsis] we have the declaration +In 26.5.1 [rand.synopsis] we have the declaration </p> <blockquote><pre>template<class RealType, class UniformRandomNumberGenerator, @@ -25762,12 +26782,12 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a <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>Section:</b> 20.7 [function.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2007-04-02 <b>Last modified:</b> 2008-09-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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> -<p>Section 20.6 [function.objects] provides <span id="st" name="st" class="st">function</span> +<p>Section 20.7 [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 @@ -25786,7 +26806,7 @@ 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 +<p>To 20.7 [function.objects], Function objects, paragraph 2, add to the header <functional> synopsis:</p> <blockquote> <pre>template <class T> struct bit_and; @@ -25823,13 +26843,13 @@ template <class T> struct bit_xor;</pre> <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>Section:</b> 27.7.1.2.2 [istream.formatted.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-04-01 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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 +To the more drastic changes of 27.7.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> @@ -25845,7 +26865,7 @@ beginning of the if-statement to be valid C++. <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 +27.7.2.6.2 [ostream.inserters.arithmetic], is a deliberate decision or an oversight. </li> @@ -25856,7 +26876,7 @@ oversight. <ol> <li> <p> -In 27.6.1.2.2 [istream.formatted.arithmetic]/2 change the current as-if code fragment +In 27.7.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; @@ -25872,7 +26892,7 @@ setstate(err); </pre></blockquote> <p> -Similarily in 27.6.1.2.2 [istream.formatted.arithmetic]/3 change the current as-if fragment +Similarily in 27.7.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; @@ -25909,13 +26929,13 @@ is deliberate. <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>Section:</b> 22.4.1.4.2 [locale.codecvt.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Thomas Plum <b>Opened:</b> 2007-04-16 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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>): +22.4.1.4.2 [locale.codecvt.virtuals], para 7 says (regarding <tt>do_unshift</tt>): </p> <blockquote><p> @@ -25944,7 +26964,7 @@ instantiations of <tt>codecvt</tt>, it is overly restrictive to say that <p><b>Proposed resolution:</b></p> <p> -Change 22.2.1.4.2 [locale.codecvt.virtuals], p7: +Change 22.4.1.4.2 [locale.codecvt.virtuals], p7: </p> <blockquote> @@ -25964,13 +26984,13 @@ mbstate_t></tt> stores no characters.</del> <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>Section:</b> 22.4.1.4.2 [locale.codecvt.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Thomas Plum <b>Opened:</b> 2007-04-16 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> -22.2.1.4.2 [locale.codecvt.virtuals], para 8 says: +22.4.1.4.2 [locale.codecvt.virtuals], para 8 says: </p> <blockquote><p> @@ -25995,7 +27015,7 @@ C functions do. <p><b>Proposed resolution:</b></p> <p> -Change 22.2.1.4.2 [locale.codecvt.virtuals], p8: +Change 22.4.1.4.2 [locale.codecvt.virtuals], p8: </p> <blockquote> @@ -26013,13 +27033,13 @@ Change 22.2.1.4.2 [locale.codecvt.virtuals], p8: <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>Section:</b> 22.4.6.3.2 [locale.moneypunct.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Thomas Plum <b>Opened:</b> 2007-04-16 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> -22.2.6.3.2 [locale.moneypunct.virtuals], para 4 footnote 257 says +22.4.6.3.2 [locale.moneypunct.virtuals], para 4 footnote 257 says </p> <blockquote><p> @@ -26045,7 +27065,7 @@ four characters long. <p><b>Proposed resolution:</b></p> <p> -Change footnote 253 in 22.2.6.3.2 [locale.moneypunct.virtuals]: +Change footnote 253 in 22.4.6.3.2 [locale.moneypunct.virtuals]: </p> <blockquote> @@ -26062,11 +27082,10 @@ four characters long, usually three letters and a space. <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>Section:</b> X [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2007-05-04 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> The current <tt>Swappable</tt> is: @@ -26153,7 +27172,7 @@ between two different types for the case that one is binding to a user-defined < <p><b>Proposed resolution:</b></p> <p> -Change 20.1.1 [utility.arg.requirements]: +Change X [utility.arg.requirements]: </p> <blockquote> @@ -26207,7 +27226,7 @@ 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 +this issue, and open a separated issue (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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, @@ -26222,10 +27241,10 @@ swap to be rvalues). <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>Section:</b> 20.8.12 [unique.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2007-05-04 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> Since the publication of @@ -26344,7 +27363,7 @@ the proposed resolutions below. <li> <p> -Change 20.7.11.2 [unique.ptr.single]: +Change 20.8.12.2 [unique.ptr.single]: </p> <blockquote><pre>template <class T, class D = default_delete<T>> class unique_ptr { @@ -26355,7 +27374,7 @@ Change 20.7.11.2 [unique.ptr.single]: </pre></blockquote> <p> -Change 20.7.11.2.4 [unique.ptr.single.observers]: +Change 20.8.12.2.4 [unique.ptr.single.observers]: </p> <blockquote><pre><del>T&</del> <ins>typename add_lvalue_reference<T>::type</ins> operator*() const; @@ -26365,7 +27384,7 @@ Change 20.7.11.2.4 [unique.ptr.single.observers]: <li> <p> -Change 20.7.11.2 [unique.ptr.single]: +Change 20.8.12.2 [unique.ptr.single]: </p> <blockquote><pre>template <class T, class D = default_delete<T>> class unique_ptr { @@ -26397,7 +27416,7 @@ and <tt>CopyAssignable</tt>. </p> <p> -Change 20.7.11.2.1 [unique.ptr.single.ctor]: +Change 20.8.12.2.1 [unique.ptr.single.ctor]: </p> <blockquote><pre>unique_ptr(<del>T*</del> <ins>pointer</ins> p); @@ -26437,7 +27456,7 @@ internally stored deleter which was constructed from </p> <p> -Change 20.7.11.2.3 [unique.ptr.single.asgn]: +Change 20.8.12.2.3 [unique.ptr.single.asgn]: </p> <blockquote> @@ -26450,7 +27469,7 @@ convertible to <del><tt>T*</tt></del> <ins>pointer</ins>. </blockquote> <p> -Change 20.7.11.2.4 [unique.ptr.single.observers]: +Change 20.8.12.2.4 [unique.ptr.single.observers]: </p> <blockquote> @@ -26460,7 +27479,7 @@ Change 20.7.11.2.4 [unique.ptr.single.observers]: </blockquote> <p> -Change 20.7.11.2.5 [unique.ptr.single.modifiers]: +Change 20.8.12.2.5 [unique.ptr.single.modifiers]: </p> <blockquote> @@ -26470,7 +27489,7 @@ Change 20.7.11.2.5 [unique.ptr.single.modifiers]: </blockquote> <p> -Change 20.7.11.3 [unique.ptr.runtime]: +Change 20.8.12.3 [unique.ptr.runtime]: </p> <blockquote><pre>template <class T, class D> class unique_ptr<T[], D> { @@ -26490,7 +27509,7 @@ public: </pre></blockquote> <p> -Change 20.7.11.3.1 [unique.ptr.runtime.ctor]: +Change 20.8.12.3.1 [unique.ptr.runtime.ctor]: </p> <blockquote> @@ -26509,7 +27528,7 @@ these members. <i>-- end note</i>] </blockquote> <p> -Change 20.7.11.3.3 [unique.ptr.runtime.modifiers]: +Change 20.8.12.3.3 [unique.ptr.runtime.modifiers]: </p> <blockquote> @@ -26529,7 +27548,7 @@ templated overload. <i>-- end note</i>] <li> <p> -Change 20.7.11.2.1 [unique.ptr.single.ctor]: +Change 20.8.12.2.1 [unique.ptr.single.ctor]: </p> <blockquote> @@ -26563,11 +27582,11 @@ required)</ins>. <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>Section:</b> 20.8.13.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2007-05-05 <b>Last modified:</b> 2008-09-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#WP">WP</a> status.</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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 @@ -26579,7 +27598,7 @@ and to interoperate with <tt>unique_ptr</tt> as it does with <tt>auto_ptr</tt>. <p><b>Proposed resolution:</b></p> <p> -Change 20.7.12.2 [util.smartptr.shared] as follows: +Change 20.8.13.2 [util.smartptr.shared] as follows: </p> <blockquote> @@ -26593,7 +27612,7 @@ template<class Y, class D> shared_ptr& operator=(unique_ptr<Y,D> </blockquote> <p> -Change 20.7.12.2.1 [util.smartptr.shared.const] as follows: +Change 20.8.13.2.1 [util.smartptr.shared.const] as follows: </p> <blockquote> @@ -26601,7 +27620,7 @@ Change 20.7.12.2.1 [util.smartptr.shared.const] as follows: </blockquote> <p> -Add to 20.7.12.2.1 [util.smartptr.shared.const]: +Add to 20.8.13.2.1 [util.smartptr.shared.const]: </p> <blockquote> @@ -26622,7 +27641,7 @@ Add to 20.7.12.2.1 [util.smartptr.shared.const]: </blockquote> <p> -Change 20.7.12.2.3 [util.smartptr.shared.assign] as follows: +Change 20.8.13.2.3 [util.smartptr.shared.assign] as follows: </p> <blockquote> @@ -26630,7 +27649,7 @@ Change 20.7.12.2.3 [util.smartptr.shared.assign] as follows: </blockquote> <p> -Add to 20.7.12.2.3 [util.smartptr.shared.assign]: +Add to 20.8.13.2.3 [util.smartptr.shared.assign]: </p> <blockquote> @@ -26659,12 +27678,121 @@ whether <tt>shared_ptr</tt> needs an rvalue <tt>swap</tt>. <hr> +<h3><a name="675"></a>675. Move assignment of containers</h3> +<p><b>Section:</b> 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2007-05-05 <b>Last modified:</b> 2008-09-26</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#CD1">CD1</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.2 [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="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>Section:</b> 26.5.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Charles Karney <b>Opened:</b> 2007-05-15 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> <tt>seed_seq::randomize</tt> provides a mechanism for initializing random number @@ -26765,13 +27893,13 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a <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>Section:</b> X [rand.req.eng] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Charles Karney <b>Opened:</b> 2007-05-15 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> -Section 26.4.1.3 [rand.req.eng] Random number engine requirements: +Section X [rand.req.eng] Random number engine requirements: </p> <p> @@ -26789,7 +27917,7 @@ the case <tt>q.size() == 0</tt>. This is undesirable for 4 reasons: <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 +paragraphs 26.5.3.1 [rand.eng.lcong] p5, 26.5.3.2 [rand.eng.mers] p8, and 26.5.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> @@ -26820,9 +27948,10 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a <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>Section:</b> 23.3 [sequences] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2007-06-11 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequences">issues</a> in [sequences].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> The C++98 standard specifies that one member function alone of the containers @@ -26902,7 +28031,7 @@ CodeWarrior library with no reports of problems which I am aware of. <p><b>Proposed resolution:</b></p> <p> -Change 23.2.2 [deque], p2: +Change 23.3.2 [deque], p2: </p> <blockquote><pre>class deque { @@ -26911,14 +28040,14 @@ Change 23.2.2 [deque], p2: </pre></blockquote> <p> -Change 23.2.2.2 [deque.capacity], p3: +Change 23.3.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: +Change 23.3.4 [list], p2: </p> <blockquote><pre>class list { @@ -26927,14 +28056,14 @@ Change 23.2.4 [list], p2: </pre></blockquote> <p> -Change 23.2.4.2 [list.capacity], p3: +Change 23.3.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: +Change 23.3.6 [vector], p2: </p> <blockquote><pre>class vector { @@ -26943,7 +28072,7 @@ Change 23.2.6 [vector], p2: </pre></blockquote> <p> -Change 23.2.6.2 [vector.capacity], p11: +Change 23.3.6.2 [vector.capacity], p11: </p> <blockquote><pre>void resize(size_type sz, <ins>const </ins>T<ins>&</ins> c); @@ -26956,14 +28085,14 @@ Change 23.2.6.2 [vector.capacity], p11: <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>Section:</b> 24.5.3.1 [move.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2007-06-11 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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]. +in 24.5.3.2.5 [move.iter.op.ref]. </p> <blockquote><pre>template <class Iterator> @@ -27007,7 +28136,7 @@ finds a non-class type, the second solution avoids the issue of an overloaded <p><b>Proposed resolution:</b></p> <p> -Change the synopsis in 24.4.3.1 [move.iterator]: +Change the synopsis in 24.5.3.1 [move.iterator]: </p> <blockquote><pre>typedef <del>typename iterator_traits<</del>Iterator<del>>::pointer</del> pointer; @@ -27020,19 +28149,19 @@ Change the synopsis in 24.4.3.1 [move.iterator]: <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>Section:</b> 28.10.2 [re.submatch.op] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Nozomu Katoo <b>Opened:</b> 2007-05-27 <b>Last modified:</b> 2009-05-01</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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.: +In 28.10.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); + bool operator==(typename iterator_traits<BiIter>::value_type const& lhs, + const sub_match<BiIter>& rhs); </pre> <blockquote> <p> @@ -27044,9 +28173,9 @@ operator functions numbered 31-42 seem impossible to compare. E.g.: <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>. +of <tt>std::basic_string<char></tt>. However, the behaviour of comparison between +these two types is not defined in 21.4.8 [string.nonmembers] of N2284. + This applies when <tt>wchar_t*</tt> is used as <tt>BiIter</tt>. </p> @@ -27068,26 +28197,27 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a <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>Section:</b> 28.9.2 [re.regex.construct] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Eric Niebler <b>Opened:</b> 2007-06-03 <b>Last modified:</b> 2009-05-01</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.regex.construct">issues</a> in [re.regex.construct].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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 +Looking at N2284, 28.9 [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); + 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: +In 28.9.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); + basic_regex(ForwardIterator first, ForwardIterator last, + flag_type f = regex_constants::ECMAScript); </pre></blockquote> <p> @@ -27101,7 +28231,7 @@ John adds: <blockquote> <p> -I think either could be implemented? Although an input iterator would +I think either could be implemented? Although an input iterator would probably require an internal copy of the string being made. </p> <p> @@ -27129,9 +28259,9 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a <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>Section:</b> 24.5.1.2.19 [reverse.iter.opdiff], 24.5.3.2.14 [move.iter.nonmember] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Bo Persson <b>Opened:</b> 2007-06-10 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> In C++03 the difference between two <tt>reverse_iterators</tt> @@ -27143,7 +28273,7 @@ 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] +In the current draft, the operator is defined as 24.5.1.2.19 [reverse.iter.opdiff] </p> <blockquote><pre>template<class Iterator1, class Iterator2> typename reverse_iterator<Iterator>::difference_type @@ -27161,13 +28291,13 @@ 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]. +24.5.3.2.14 [move.iter.nonmember]. </p> <p><b>Proposed resolution:</b></p> <p> -Change the synopsis in 24.4.1.1 [reverse.iterator]: +Change the synopsis in 24.5.1.1 [reverse.iterator]: </p> <blockquote> @@ -27179,7 +28309,7 @@ Change the synopsis in 24.4.1.1 [reverse.iterator]: </blockquote> <p> -Change 24.4.1.3.19 [reverse.iter.opdiff]: +Change 24.5.1.2.19 [reverse.iter.opdiff]: </p> <blockquote> @@ -27197,7 +28327,7 @@ Change 24.4.1.3.19 [reverse.iter.opdiff]: <p> -Change the synopsis in 24.4.3.1 [move.iterator]: +Change the synopsis in 24.5.3.1 [move.iterator]: </p> <blockquote> @@ -27209,7 +28339,7 @@ Change the synopsis in 24.4.3.1 [move.iterator]: </blockquote> <p> -Change 24.4.3.3.14 [move.iter.nonmember]: +Change 24.5.3.2.14 [move.iter.nonmember]: </p> <blockquote> @@ -27238,10 +28368,11 @@ goes in. <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>Section:</b> 20.8.13.2.1 [util.smartptr.shared.const], 20.8.13.3.1 [util.smartptr.weak.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2007-05-10 <b>Last modified:</b> 2009-02-02</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#util.smartptr.shared.const">active issues</a> in [util.smartptr.shared.const].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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 @@ -27254,7 +28385,7 @@ void f( shared_ptr<int> ); int main() { - f( shared_ptr<double>() ); // ambiguous + f( shared_ptr<double>() ); // ambiguous } </pre></blockquote> @@ -27267,7 +28398,7 @@ overload resolution when the pointer types are compatible. <p><b>Proposed resolution:</b></p> <p> -In 20.7.12.2.1 [util.smartptr.shared.const], change: +In 20.8.13.2.1 [util.smartptr.shared.const], change: </p> <blockquote><p> @@ -27278,7 +28409,7 @@ to <tt>T*</tt>. </p></blockquote> <p> -In 20.7.12.3.1 [util.smartptr.weak.const], change: +In 20.8.13.3.1 [util.smartptr.weak.const], change: </p> <blockquote> @@ -27304,10 +28435,10 @@ overload resolution unless</ins> <tt>Y*</tt> <del>shall be</del> <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>Section:</b> 20.7.5.1 [refwrap.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2007-05-10 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> The constructor of <tt>reference_wrapper</tt> is currently <tt>explicit</tt>. The primary @@ -27333,11 +28464,174 @@ proposed resolution of the previous issue is accepted, remove the <hr> +<h3><a name="691"></a>691. const_local_iterator cbegin, cend missing from TR1</h3> +<p><b>Section:</b> 23.5 [unord], TR1 6.3 [tr.hash] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Joaquín M López Muńoz <b>Opened:</b> 2007-06-14 <b>Last modified:</b> 2008-09-26</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#CD1">CD1</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.2.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.5.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.5.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.5.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.5.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.7.4 [ext.manip] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-06-22 <b>Last modified:</b> 2008-09-26</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#CD1">CD1</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.7.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.7.1.2.1 [istream.formatted.reqmts]). +</p></blockquote> +<p> +Also change p4 of 27.7.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="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>Section:</b> 20.3.6 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-06-22 <b>Last modified:</b> 2008-09-26</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#template.bitset">active issues</a> in [template.bitset].</p> <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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> The <code>bitset</code> class template provides the member function @@ -27360,7 +28654,7 @@ the first word with a zero bit). <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, +defintion of the <code>bitset</code> template in 20.3.6 [template.bitset], p1, right above the declaration of <code>any()</code> as shown below: </p> @@ -27372,7 +28666,7 @@ 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: +Add a description of the new member function to the end of 20.3.6.2 [bitset.members] with the following text: </p> <blockquote><p> <code>bool all() const;</code> @@ -27413,10 +28707,11 @@ is one</del><ins><code>count() == 0</code></ins>. <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>Section:</b> 20.3.6 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-06-22 <b>Last modified:</b> 2008-09-26</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#template.bitset">active issues</a> in [template.bitset].</p> <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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> Objects of the <code>bitset</code> class template specializations can @@ -27453,7 +28748,7 @@ explicit bitset( </pre> </blockquote> <p> -Make a corresponding change in 23.3.5.1 [bitset.cons], p2: +Make a corresponding change in 20.3.6.1 [bitset.cons], p2: </p> <blockquote> <p> @@ -27476,7 +28771,7 @@ 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: +in 20.3.6 [template.bitset], p1, as shown below: </p> <blockquote> <pre>// element access: @@ -27489,7 +28784,7 @@ 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], +And add a description of the new member function to 20.3.6.2 [bitset.members], below the description of the existing <code>to_ulong()</code> (if possible), with the following text: </p> @@ -27513,9 +28808,9 @@ cannot be represented as type <code>unsigned long long</code>. <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>Section:</b> 22.4.1.3 [facet.ctype.special] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-06-22 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> The <code>ctype<char>::classic_table()</code> static member @@ -27552,7 +28847,7 @@ function <code>table()</code>. 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: +specialization in 22.4.1.3 [facet.ctype.special] as shown below: </p> <blockquote> <pre> static locale::id id; @@ -27572,11 +28867,90 @@ virtual char do_toupper(char c) const; <hr> +<h3><a name="698"></a>698. <tt>system_error</tt> needs <tt>const char*</tt> constructors</h3> +<p><b>Section:</b> 19.5.5.1 [syserr.syserr.overview] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-06-24 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> +<p><b>Discussion:</b></p> +<p> +In 19.5.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.2 [std.exceptions], +or <tt>ios_base::failure</tt> in 27.5.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-closed.html#832">832</a> has been accepted and applied to the working paper. +</p> + +<p> +Change 19.5.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.5.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="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>Section:</b> 26.5 [rand] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2007-07-01 <b>Last modified:</b> 2008-09-26</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand">active issues</a> in [rand].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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> @@ -27612,11 +28986,10 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a <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>Section:</b> 20.3.2 [forward] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2007-07-01 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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> @@ -27629,7 +29002,7 @@ if we could avoid this name clash for backward compatibility. <p><b>Proposed resolution:</b></p> <p> -Change 20.2.2 [forward]: +Change 20.3.2 [forward]: </p> <blockquote> @@ -27658,10 +29031,10 @@ Change 20.2.2 [forward]: <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>Section:</b> 23.4.1.2 [map.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Joe Gottman <b>Opened:</b> 2007-07-03 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> <tt>map::at()</tt> need a complexity specification. @@ -27670,7 +29043,7 @@ Change 20.2.2 [forward]: <p><b>Proposed resolution:</b></p> <p> -Add the following to the specification of <tt>map::at()</tt>, 23.3.1.2 [map.access]: +Add the following to the specification of <tt>map::at()</tt>, 23.4.1.2 [map.access]: </p> <blockquote> <p> @@ -27684,14 +29057,14 @@ Add the following to the specification of <tt>map::at()</tt>, 23.3.1.2 [map.acce <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>Section:</b> 20.6.7 [meta.trans.other] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Thorsten Ottosen <b>Opened:</b> 2007-07-08 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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]. +The current working draft has a type-trait <tt>decay</tt> in 20.6.7 [meta.trans.other]. </p> <p> @@ -27705,7 +29078,7 @@ cv-qualification, as pass-by-value does. <p><b>Proposed resolution:</b></p> <p> -In 20.5.7 [meta.trans.other] change the last sentence: +In 20.6.7 [meta.trans.other] change the last sentence: </p> <blockquote><p> @@ -27713,7 +29086,7 @@ Otherwise the member typedef <tt>type</tt> equals <tt><ins>remove_cv<</ins>U </p></blockquote> <p> -In 20.4.1.3 [tuple.creation]/1 change: +In 20.5.2.2 [tuple.creation]/1 change: </p> <blockquote><p> @@ -27736,14 +29109,15 @@ is <tt>X&</tt> if <tt>Ui</tt> equals <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>Section:</b> 20.3.3 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Thorsten Ottosen <b>Opened:</b> 2007-07-08 <b>Last modified:</b> 2008-09-26</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#pairs">active issues</a> in [pairs].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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]. +The current draft has <tt>make_pair()</tt> in 20.3.3 [pairs]/16 +and <tt>make_tuple()</tt> in 20.5.2.2 [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 @@ -27755,7 +29129,7 @@ confusion. <p><b>Proposed resolution:</b></p> <p> -In 20.2 [utility] change the synopsis for make_pair() to read +In 20.3 [utility] change the synopsis for make_pair() to read </p> <blockquote><pre>template <class T1, class T2> @@ -27763,8 +29137,8 @@ In 20.2 [utility] change the synopsis for make_pair() to read </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: +In 20.3.3 [pairs]/16 change the declaration to match the above synopsis. +Then change the 20.3.3 [pairs]/17 to: </p> <blockquote> @@ -27784,12 +29158,78 @@ Then change the 20.2.3 [pairs]/17 to: <hr> +<h3><a name="709"></a>709. <tt>char_traits::not_eof</tt> has wrong signature</h3> +<p><b>Section:</b> 21.2.3 [char.traits.specializations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Bo Persson <b>Opened:</b> 2007-08-13 <b>Last modified:</b> 2008-09-26</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#CD1">CD1</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The changes made for <tt>constexpr</tt> in 21.2.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.2.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.2.3.1 [char.traits.specializations.char], +21.2.3.2 [char.traits.specializations.char16_t], 21.2.3.3 [char.traits.specializations.char32_t], +and 21.2.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="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>Section:</b> 20.8.13.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2007-08-24 <b>Last modified:</b> 2008-09-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#WP">WP</a> status.</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> A discussion on @@ -27819,7 +29259,7 @@ editor should consider rewording "If w is the return value...", e. g. as <p><b>Proposed resolution:</b></p> <p> -Add to 20.7.12.2.1 [util.smartptr.shared.const]: +Add to 20.8.13.2.1 [util.smartptr.shared.const]: </p> <blockquote> @@ -27835,7 +29275,7 @@ shall be empty. <ins><tt>r.get() == 0</tt>.</ins> </blockquote> <p> -Add to 20.7.12.2.10 [util.smartptr.shared.cast]: +Add to 20.8.13.2.10 [util.smartptr.shared.cast]: </p> <blockquote> @@ -27878,7 +29318,7 @@ the aliasing constructor as follows: </p> <p> -Change 20.7.12.2.10 [util.smartptr.shared.cast]: +Change 20.8.13.2.10 [util.smartptr.shared.cast]: </p> <blockquote> @@ -27925,16 +29365,15 @@ in the aliasing constructor postcondition "by reference". <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>Section:</b> 26.5.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Marc Paterno <b>Opened:</b> 2007-08-25 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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]. +in other parts of 26.5 [rand]. As a side effect of resolving related issues, all such references to <tt>seed_seq::size()</tt> will have been excised. @@ -27968,14 +29407,105 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a <hr> +<h3><a name="713"></a>713. <tt>sort()</tt> complexity is too lax</h3> +<p><b>Section:</b> 25.5.1.1 [sort] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Matt Austern <b>Opened:</b> 2007-08-30 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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.5.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.3.12 [alg.search] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Matt Austern <b>Opened:</b> 2007-08-30 <b>Last modified:</b> 2008-09-26</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#CD1">CD1</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The complexity for <tt>search_n</tt> (25.3.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="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>Section:</b> 25.5.7 [alg.min.max] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Matt Austern <b>Opened:</b> 2007-08-30 <b>Last modified:</b> 2008-09-26</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#alg.min.max">active issues</a> in [alg.min.max].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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 * +The complexity for <tt>minmax_element</tt> (25.5.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 @@ -27986,7 +29516,7 @@ well known technique that does better: see section 9.1 of CLRS <p><b>Proposed resolution:</b></p> <p> -Change 25.3.7 [alg.min.max] to: +Change 25.5.7 [alg.min.max] to: </p> <blockquote> @@ -28021,14 +29551,97 @@ corresponding <del>comparisons</del> <ins>predicate, where <tt>N</tt> is <tt>dis <hr> +<h3><a name="720"></a>720. Omissions in constexpr usages</h3> +<p><b>Section:</b> 23.3.1 [array], 20.3.6 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-08-25 <b>Last modified:</b> 2008-09-26</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#CD1">CD1</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.3.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 20.3.6 [template.bitset]/p. 1 change</p> +<blockquote><pre><ins>constexpr</ins> bool test(size_t pos ) const; +</pre></blockquote> + +<p> +and in 20.3.6.2 [bitset.members] change +</p> + +<blockquote><pre><ins>constexpr</ins> bool test(size_t pos ) const; +</pre></blockquote> + +</li> +</ol> + + + + + +<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>Section:</b> 26.8 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-08-27 <b>Last modified:</b> 2008-09-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#WP">WP</a> status.</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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 +In the listing of 26.8 [c.math], table 108: Header <tt><cmath></tt> synopsis I miss the following C99 functions (from 7.12.11.2): </p> @@ -28044,7 +29657,7 @@ listed anywhere else) <p><b>Proposed resolution:</b></p> <p> -In 26.7 [c.math], table 108, section "Functions", add <tt>nanf</tt> and <tt>nanl</tt> +In 26.8 [c.math], table 108, section "Functions", add <tt>nanf</tt> and <tt>nanl</tt> just after the existing entry <tt>nan</tt>. </p> @@ -28053,10 +29666,251 @@ just after the existing entry <tt>nan</tt>. <hr> +<h3><a name="728"></a>728. Problem in [rand.eng.mers]/6</h3> +<p><b>Section:</b> 26.5.3.2 [rand.eng.mers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Stephan Tolksdorf <b>Opened:</b> 2007-09-21 <b>Last modified:</b> 2008-09-26</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#CD1">CD1</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="734"></a>734. Unnecessary restriction in [rand.dist.norm.chisq]</h3> +<p><b>Section:</b> 26.5.8.4.3 [rand.dist.norm.chisq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Stephan Tolksdorf <b>Opened:</b> 2007-09-21 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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.5.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.5.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.5.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="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>Section:</b> X [unique.ptr.compiletime] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Herb Sutter <b>Opened:</b> 2007-10-04 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> Please don't provide <tt>*_ptr<T[N]></tt>. It doesn't enable any useful @@ -28120,7 +29974,7 @@ straw poll unanimous move to Ready. <p><b>Proposed resolution:</b></p> <p> -Change the synopsis under 20.7.11 [unique.ptr] p2: +Change the synopsis under 20.8.12 [unique.ptr] p2: </p> <blockquote><pre>... @@ -28135,13 +29989,13 @@ template<class T, class D> class unique_ptr<T[], D>; </pre></blockquote> <p> -Remove the entire section 20.7.11.1.3 [unique.ptr.dltr.dflt2] <b><tt>default_delete<T[N]></tt></b>. +Remove the entire section 20.8.12.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]. +Remove the entire section X [unique.ptr.compiletime] <b><tt>unique_ptr</tt> for array objects with a compile time length</b> +and its subsections: [unique.ptr.compiletime.dtor], [unique.ptr.compiletime.observers], + [unique.ptr.compiletime.modifiers]. </p> @@ -28151,9 +30005,9 @@ and its subsections: 20.7.11.4.1 [unique.ptr.compiletime.dtor], 20.7.11.4.2 [uni <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>Section:</b> 20.8.13.2.9 [util.smartptr.shared.spec] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2007-10-10 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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: @@ -28193,7 +30047,7 @@ Adopt issue as written. <p><b>Proposed resolution:</b></p> <p> -Change the synopsis in 20.7.12.2 [util.smartptr.shared]: +Change the synopsis in 20.8.13.2 [util.smartptr.shared]: </p> <blockquote><pre>void swap(shared_ptr&<ins>&</ins> r); @@ -28204,14 +30058,14 @@ template<class T> void swap(shared_ptr<T>& a, shared_ptr<T> </pre></blockquote> <p> -Change 20.7.12.2.4 [util.smartptr.shared.mod]: +Change 20.8.13.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]: +Change 20.8.13.2.9 [util.smartptr.shared.spec]: </p> <blockquote><pre>template<class T> void swap(shared_ptr<T>& a, shared_ptr<T>& b); @@ -28225,11 +30079,11 @@ template<class T> void swap(shared_ptr<T>& a, shared_ptr<T> <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>Section:</b> 18.8.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2007-10-10 <b>Last modified:</b> 2008-09-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#WP">WP</a> status.</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> Without some lifetime guarantee, it is hard to know how this type can be @@ -28271,7 +30125,7 @@ Move to Open. <p><b>Proposed resolution:</b></p> <p> -Change 18.7.5 [propagation]/7: +Change 18.8.5 [propagation]/7: </p> <blockquote> @@ -28294,11 +30148,11 @@ each time it is called. <i>--end note</i>] <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>Section:</b> 18.8.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2007-10-10 <b>Last modified:</b> 2008-09-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#WP">WP</a> status.</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> I understand that the attempt to copy an exception may run out of memory, @@ -28350,7 +30204,7 @@ Accept the broad view and move to ready <p><b>Proposed resolution:</b></p> <p> -Add the following exemption clause to 17.4.4.9 [res.on.exception.handling]: +Add the following exemption clause to 17.6.4.10 [res.on.exception.handling]: </p> <blockquote> @@ -28365,10 +30219,11 @@ exception handler for the base type. <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>Section:</b> 20.6.4.3 [meta.unary.prop] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2007-10-10 <b>Last modified:</b> 2008-09-26</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta.unary.prop">active issues</a> in [meta.unary.prop].</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> Unfortunately a class can have multiple copy constructors, and I believe to @@ -28388,7 +30243,7 @@ For instance: <p><b>Proposed resolution:</b></p> <p> -Change 20.5.4.3 [meta.unary.prop]: +Change 20.6.4.3 [meta.unary.prop]: </p> <blockquote> @@ -28434,11 +30289,188 @@ throw any exceptions or <tt>T</tt> is an array of such a class type. <hr> +<h3><a name="752"></a>752. Allocator complexity requirement</h3> +<p><b>Section:</b> X [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> Hans Boehm <b>Opened:</b> 2007-10-11 <b>Last modified:</b> 2009-03-09</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> +Did LWG recently discuss X [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 X [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> X [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> Yechezkel Mett <b>Opened:</b> 2007-10-14 <b>Last modified:</b> 2009-03-09</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 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 X [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.3.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.3 [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="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>Section:</b> 23.3.6.2 [vector.capacity], 21.4.4 [string.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2007-10-31 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> A <tt>std::vector</tt> can be shrunk-to-fit via the swap idiom: @@ -28489,9 +30521,9 @@ takes no arguments to keep the solution simple and focused. <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: +To Class template basic_string 21.4 [basic.string] synopsis, +Class template vector 23.3.6 [vector] synopsis, and Class +vector<bool> 23.3.7 [vector.bool] synopsis, add: </p> <blockquote><pre> @@ -28499,8 +30531,8 @@ 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: +To basic_string capacity 21.4.4 [string.capacity] and vector +capacity 23.3.6.2 [vector.capacity], add: </p> <blockquote> @@ -28515,7 +30547,7 @@ allow latitude for implementation-specific optimizations. </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>. +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#850">850</a> has been added to deal with this issue with respect to <tt>deque</tt>. ]</i></p> @@ -28524,15 +30556,257 @@ allow latitude for implementation-specific optimizations. <hr> +<h3><a name="758"></a>758. <tt>shared_ptr</tt> and <tt>nullptr</tt></h3> +<p><b>Section:</b> 20.8.13.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> Joe Gottman <b>Opened:</b> 2007-10-31 <b>Last modified:</b> 2009-03-09</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> +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.8.13.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> +In 20.8.13.2 [util.smartptr.shared] p4, add to the definition/synopsis +of <tt>shared_ptr</tt>: +</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> +In 20.8.13.2.1 [util.smartptr.shared.const] 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> +(reusing the following paragraphs 20.8.13.2.1 [util.smartptr.shared.const]/9-13 that speak of p.) +</p> + +<p> +In 20.8.13.2.1 [util.smartptr.shared.const]/10, change +</p> + +<blockquote> +<i>Effects:</i> Constructs a <tt>shared_ptr</tt> object that <i>owns</i> the +<del>pointer</del> <ins>object</ins> <tt>p</tt> and the deleter <tt>d</tt>. The second +constructor shall use a copy of <tt>a</tt> to allocate memory for internal use. +</blockquote> + + +<p><b>Rationale:</b></p> +<p><i>[ +San Francisco: +]</i></p> + + +<blockquote> +"pointer" is changed to "object" to handle the fact that nullptr_t isn't a pointer. +</blockquote> + + + + + + +<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>Section:</b> 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2007-11-06 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> -23.1 [container.requirements] says: +23.2 [container.requirements] says: </p> <blockquote> @@ -28557,7 +30831,7 @@ an element of that container; no diagnostic required. <p><b>Proposed resolution:</b></p> <p> -Change 23.1 [container.requirements]: +Change 23.2 [container.requirements]: </p> <blockquote> @@ -28576,9 +30850,9 @@ diagnostic required. <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>Section:</b> 23.5.1.2 [unord.map.elem] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Joe Gottman <b>Opened:</b> 2007-11-15 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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 @@ -28593,7 +30867,7 @@ in <tt>std::unordered_map</tt>. <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]): +Add the following functions to the definition of <tt>unordered_map</tt> under "lookup" (23.5.1 [unord.map]): </p> <blockquote><pre>mapped_type& at(const key_type& k); @@ -28601,7 +30875,7 @@ const mapped_type &at(const key_type &k) const; </pre></blockquote> <p> -Add the following definitions to 23.4.1.2 [unord.map.elem]: +Add the following definitions to 23.5.1.2 [unord.map.elem]: </p> <blockquote> @@ -28631,15 +30905,320 @@ Bellevue: Editorial note: the "(unique)" differs from map. <hr> +<h3><a name="762"></a>762. <tt>std::unique_ptr</tt> requires complete type?</h3> +<p><b>Section:</b> 20.8.12 [unique.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-11-30 <b>Last modified:</b> 2008-09-26</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#CD1">CD1</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.6.3.8 [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 X [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.8.12.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.8.12 [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.8.12.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.8.12.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.8.12.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.8.12.2.1 [unique.ptr.single.ctor]/17: No changes necessary. +</li> +<li> +<p>20.8.12.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.8.12.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.8.12.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.8.12.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.8.12.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.8.12.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.8.12.2.5 [unique.ptr.single.modifiers]/1: No changes necessary. +</li> + +<li> +<p> +20.8.12.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.8.12.2.5 [unique.ptr.single.modifiers]/7: No changes necessary. +</li> + +<li> +<p> +20.8.12.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="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>Section:</b> 23.2 [container.requirements], 23.2.5.1 [unord.req.except] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Ion Gaztańaga <b>Opened:</b> 2007-12-22 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> -23.1 [container.requirements]p10 states: +23.2 [container.requirements]p10 states: </p> <blockquote> @@ -28657,12 +31236,12 @@ additional requirements: </blockquote> <p> -23.2.2.3 [deque.modifiers] and 23.2.6.4 [vector.modifiers] offer +23.3.2.3 [deque.modifiers] and 23.3.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 +<tt>erase()</tt> members. However, 23.2 [container.requirements]p10 +does not mention 23.2.5.1 [unord.req.except] that specifies exception safety guarantees -for unordered containers. In addition, 23.1.5.1 [unord.req.except]p1 +for unordered containers. In addition, 23.2.5.1 [unord.req.except]p1 offers the following guaratee for <tt>erase()</tt>: </p> @@ -28677,9 +31256,9 @@ Summary: </p> <p> -According to 23.1 [container.requirements]p10 no +According to 23.2 [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 +specified. Although does not explicitly mention 23.2.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> @@ -28723,7 +31302,7 @@ exception or swallow it, leaving the object registered. <p><b>Proposed resolution:</b></p> <p> -Create a new sub-section of 23.1.4 [associative.reqmts] (perhaps [associative.req.except]) titled "Exception +Create a new sub-section of 23.2.4 [associative.reqmts] (perhaps [associative.req.except]) titled "Exception safety guarantees". </p> @@ -28748,7 +31327,7 @@ assignment operator of the container's Pred object (if any). </blockquote> <p> -Change 23.1.5.1 [unord.req.except]p1: +Change 23.2.5.1 [unord.req.except]p1: </p> <blockquote> @@ -28760,7 +31339,7 @@ unless that exception is thrown by the container's Hash or Pred object </blockquote> <p> -Change 23.1 [container.requirements]p10 to add references to new sections: +Change 23.2 [container.requirements]p10 to add references to new sections: </p> <blockquote> @@ -28771,7 +31350,7 @@ the following additional requirements: </blockquote> <p> -Change 23.1 [container.requirements]p10 referring to <tt>swap</tt>: +Change 23.2 [container.requirements]p10 referring to <tt>swap</tt>: </p> <blockquote> @@ -28791,14 +31370,15 @@ Compare object (if any; see [associative.reqmts])</del>. <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>Section:</b> 29.5.3 [atomics.types.generic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Alberto Ganesh Barbati <b>Opened:</b> 2007-12-28 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types.generic">issues</a> in [atomics.types.generic].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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 +in section 29.5.3 [atomics.types.generic], the following specialization of the template <tt>atomic<></tt> is provided for pointers: </p> @@ -28882,7 +31462,7 @@ initialization. <p><b>Proposed resolution:</b></p> <p> -Change the synopsis in 29.3.3 [atomics.types.generic]: +Change the synopsis in 29.5.3 [atomics.types.generic]: </p> <blockquote><pre>template <class T> struct atomic<T*> : atomic_address { @@ -28916,10 +31496,100 @@ Change the synopsis in 29.3.3 [atomics.types.generic]: <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.7.16.2 [func.wrap.func] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-01-10 <b>Last modified:</b> 2008-09-26</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#func.wrap.func">active issues</a> in [func.wrap.func].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.wrap.func">issues</a> in [func.wrap.func].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> +<p><b>Discussion:</b></p> +<p> +N2461 already replaced in 20.7.16.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.7 [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.7.16.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.7.16.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.7.16.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.7.16.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="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>Section:</b> 20.7.16 [func.wrap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-01-10 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> It is expected that typical implementations of <tt>std::function</tt> will @@ -28931,7 +31601,7 @@ this class to rvalue swappability. <p><b>Proposed resolution:</b></p> <p> -In 20.6 [function.objects], header <tt><functional></tt> synopsis, just below of +In 20.7 [function.objects], header <tt><functional></tt> synopsis, just below of </p> <blockquote><pre>template<class R, class... ArgTypes> @@ -28943,14 +31613,14 @@ template<class R, class... ArgTypes> </pre></blockquote> <p> -In 20.6.15.2 [func.wrap.func] class <tt>function</tt> definition, change +In 20.7.16.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 +In 20.7.16.2 [func.wrap.func], just below of </p> <blockquote><pre>template <class R, class... ArgTypes> @@ -28962,14 +31632,14 @@ template <class R, class... ArgTypes> </pre></blockquote> <p> -In 20.6.15.2.2 [func.wrap.func.mod] change +In 20.7.16.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 +In 20.7.16.2.7 [func.wrap.func.alg] add the two overloads </p> <blockquote><pre><ins>template<class R, class... ArgTypes> @@ -28984,10 +31654,157 @@ template<class R, class... ArgTypes> <hr> +<h3><a name="771"></a>771. Impossible throws clause in [string.conversions]</h3> +<p><b>Section:</b> 21.5 [string.conversions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-01-13 <b>Last modified:</b> 2008-09-26</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#CD1">CD1</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The new <tt>to_string</tt> and <tt>to_wstring</tt> functions described in 21.5 [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.3 [string.classes] is correct in this +regard). +</p> + + + +<p><b>Proposed resolution:</b></p> +<p> +In 21.5 [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.5 [string.conversions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-01-13 <b>Last modified:</b> 2008-09-26</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#CD1">CD1</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The return clause 21.5 [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.5 [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.5 [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="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>Section:</b> 20.5.2.3 [tuple.helper] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-01-16 <b>Last modified:</b> 2008-09-26</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#tuple.helper">active issues</a> in [tuple.helper].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple.helper">issues</a> in [tuple.helper].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> The tuple element access API identifies the element in the sequence @@ -29023,7 +31840,7 @@ problem as all elements are of type <code>T</code>. <p><b>Proposed resolution:</b></p> <p> -Update header <utility> synopsis in 20.2 [utility] +Update header <utility> synopsis in 20.3 [utility] </p> <pre><em>// 20.2.3, tuple-like access to pair:</em> template <class T> class tuple_size; @@ -29039,7 +31856,7 @@ 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> +Update <strong>20.3.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>&); @@ -29058,7 +31875,7 @@ template<<del>int</del><ins>size_t</ins> I, class T1, class T2> <p> -Update header <tuple> synopsis in 20.4 [tuple] with a APIs as below: +Update header <tuple> synopsis in 20.5 [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...> >; @@ -29071,7 +31888,7 @@ template <<del>int</del><ins>size_t</ins> I, class ... types> </pre> <p> -Update <strong>20.4.1.4 [tuple.helper] Tuple helper classes</strong> +Update <strong>20.5.2.3 [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...> > { @@ -29085,7 +31902,7 @@ public: 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> +Update <strong>20.5.2.4 [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); @@ -29110,7 +31927,7 @@ typename tuple_element<I, tuple<Types...> >::type const& get(con <p> -Update header <array> synopsis in 20.2 [utility] +Update header <array> synopsis in 20.3 [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> @@ -29125,7 +31942,7 @@ template <<del>int</del><ins>size_t</ins> I, class T, size_t N> </pre> <p> -Update <strong>23.2.1.6 [array.tuple] Tuple interface to class template array</strong> +Update <strong>23.3.1.7 [array.tuple] Tuple interface to class template array</strong> </p> <pre>tuple_element<<ins>size_t </ins>I, array<T, N> >::type </pre> @@ -29170,11 +31987,105 @@ for pair is also unnecessary. <hr> +<h3><a name="776"></a>776. Undescribed assign function of std::array</h3> +<p><b>Section:</b> 23.3.1 [array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-01-20 <b>Last modified:</b> 2008-09-26</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#CD1">CD1</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The class template array synopsis in 23.3.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.3.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.3.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="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>Section:</b> 29.6 [atomics.types.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Lawrence Crowl <b>Opened:</b> 2008-01-21 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> The load functions are defined as @@ -29245,10 +32156,10 @@ C A::load(memory_order order = memory_order_seq_cst) <ins>const</ins> volatile; <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>Section:</b> 20.3.6.1 [bitset.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Thorsten Ottosen <b>Opened:</b> 2008-01-24 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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> @@ -29271,14 +32182,14 @@ to std::bitset. <p><b>Proposed resolution:</b></p> <p> -Add to synopsis in 23.3.5 [template.bitset] +Add to synopsis in 20.3.6 [template.bitset] </p> <blockquote><pre>explicit bitset( const char* str ); </pre></blockquote> <p> -Add to synopsis in 23.3.5.1 [bitset.cons] +Add to synopsis in 20.3.6.1 [bitset.cons] </p> <blockquote><pre>explicit bitset( const char* str ); @@ -29294,14 +32205,44 @@ Add to synopsis in 23.3.5.1 [bitset.cons] <hr> +<h3><a name="779"></a>779. Resolution of #283 incomplete</h3> +<p><b>Section:</b> 25.4.8 [alg.remove] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-01-25 <b>Last modified:</b> 2008-09-26</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#CD1">CD1</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.4.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="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>Section:</b> 26.4.7 [complex.value.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-01-26 <b>Last modified:</b> 2009-03-21</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> -A comparision of the N2461 header <tt><complex></tt> synopsis ([complex.synopsis]) +A comparision of the N2461 header <tt><complex></tt> synopsis ([complex.syn]) with the C99 standard (ISO 9899, 2nd edition and the two corrigenda) show some complex functions that are missing in C++. These are: </p> @@ -29328,7 +32269,7 @@ function). <p> Please note also that the current entry <tt>polar</tt> -in 26.3.9 [cmplx.over]/1 +in 26.4.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 @@ -29339,7 +32280,7 @@ this function. <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>: +In 26.4.1 [complex.syn] 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>&); @@ -29348,7 +32289,7 @@ 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: +In 26.4.7 [complex.value.ops] just after p.6 (return clause of <tt>conj</tt>) add: </p> <blockquote> @@ -29362,7 +32303,7 @@ subclause 7.3.9.4." </blockquote> <p> -In 26.3.9 [cmplx.over]/1, add one further entry <tt>proj</tt> to +In 26.4.9 [cmplx.over]/1, add one further entry <tt>proj</tt> to the overload list. </p> @@ -29383,11 +32324,10 @@ imag real <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>Section:</b> 26.5.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-01-27 <b>Last modified:</b> 2009-05-01</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> Part of the resolution of n2423, issue 8 was the proposal to @@ -29412,7 +32352,7 @@ 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). +provided (14.9.1 [temp.arg.explicit]/7). </p> <p> @@ -29442,7 +32382,7 @@ Proposed Resolution: Accept Solution A. </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. +Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#803">803</a> claims to make this issue moot. </p> @@ -29451,7 +32391,7 @@ Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#803"> <ol type="A"> <li> <p> -In 26.4.7.1 [rand.util.seedseq]/2, class <tt>seed_seq</tt> synopsis replace: +In 26.5.7.1 [rand.util.seedseq]/2, class <tt>seed_seq</tt> synopsis replace: </p> <blockquote><pre>class seed_seq @@ -29474,20 +32414,20 @@ p.3 and p.4. <li> <p> -In 26.4.7.1 [rand.util.seedseq]/2, class <tt>seed_seq</tt> synopsis <em>and</em> in the +In 26.5.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); + 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 +In 26.5.1 [rand.synopsis], header <tt><random></tt> synopsis, immediately after the +class <tt>seed_seq</tt> declaration <em>and</em> in 26.5.7.1 [rand.util.seedseq]/2, immediately after the class <tt>seed_seq</tt> definition add: </p> @@ -29496,7 +32436,7 @@ after the class <tt>seed_seq</tt> definition add: </pre></blockquote> <p> -In 26.4.7.1 [rand.util.seedseq], just before p.5 insert two paragraphs: +In 26.5.7.1 [rand.util.seedseq], just before p.5 insert two paragraphs: </p> <blockquote> @@ -29513,7 +32453,7 @@ is called by the function <tt>make_seed_seq</tt>. </blockquote> <p> -In 26.4.7.1 [rand.util.seedseq], just after the last paragraph add: +In 26.5.7.1 [rand.util.seedseq], just after the last paragraph add: </p> <blockquote> @@ -29540,9 +32480,10 @@ where <tt>u</tt> is used to construct an object <tt>s</tt> of implementation-def <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>Section:</b> 30.3.1.1 [thread.thread.id] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Hans Boehm <b>Opened:</b> 2008-02-01 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.thread.id">issues</a> in [thread.thread.id].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> The current working paper @@ -29598,7 +32539,7 @@ example: <p><b>Proposed resolution:</b></p> <p> -Add a sentence to 30.2.1.1 [thread.thread.id]/p1: +Add a sentence to 30.3.1.1 [thread.thread.id]/p1: </p> <blockquote> @@ -29623,11 +32564,65 @@ terminated thread that can no longer be joined.</ins> <hr> +<h3><a name="787"></a>787. complexity of <tt>binary_search</tt></h3> +<p><b>Section:</b> 25.5.3.4 [binary.search] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-09-08 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> +<p><b>Discussion:</b></p> +<p> +In 25.5.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.5.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="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>Section:</b> X [rand.adapt.xor] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2008-02-09 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> <tt>xor_combine_engine(result_type)</tt> should be <tt>explicit</tt>. (Obvious oversight.) @@ -29650,10 +32645,10 @@ adapter. <p><b>Proposed resolution:</b></p> <p> -Remove xor_combine_engine from synopsis of 26.4.2 [rand.synopsis]. +Remove xor_combine_engine from synopsis of 26.5.1 [rand.synopsis]. </p> <p> -Remove 26.4.4.4 [rand.adapt.xor] <tt>xor_combine_engine</tt>. +Remove X [rand.adapt.xor] <tt>xor_combine_engine</tt>. </p> @@ -29662,11 +32657,10 @@ Remove 26.4.4.4 [rand.adapt.xor] <tt>xor_combine_engine</tt>. <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>Section:</b> 26.5.8.5.2 [rand.dist.samp.pconst] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2008-02-09 <b>Last modified:</b> 2008-09-26</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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> <p><b>Discussion:</b></p> <p> <tt>piecewise_constant_distribution</tt> is undefined for a range with just one @@ -29676,7 +32670,7 @@ endpoint. (Probably should be the same as an empty range.) <p><b>Proposed resolution:</b></p> <p> -Change 26.4.8.5.2 [rand.dist.samp.pconst] paragraph 3b: +Change 26.5.8.5.2 [rand.dist.samp.pconst] paragraph 3b: </p> <blockquote> @@ -29689,10 +32683,10 @@ b) If <tt>firstB == lastB</tt> <ins>or the sequence <tt>w</tt> has the length ze <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>Section:</b> D.8 [depr.lib.binders] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-02-14 <b>Last modified:</b> 2008-09-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>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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> @@ -29775,4 +32769,2702 @@ public: +<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.5 [syserr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-02-24 <b>Last modified:</b> 2008-09-26</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#CD1">CD1</a> status.</p> +<p><b>Discussion:</b></p> +<ol type="A"> +<li> +<p> +19.5.2.2 [syserr.errcode.overview]/1, class <tt>error_code</tt> and +19.5.3.2 [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.5.2.4 [syserr.errcode.modifiers] and 19.5.3.4 [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.5.1.2 [syserr.errcat.virtuals]/10, 19.5.2.5 [syserr.errcode.observers]/8, and +19.5.3.5 [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-defects.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-closed.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-closed.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.5.2.2 [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.5.2.3 [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.5.2.4 [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.5.2.5 [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.5.3.2 [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.5.3.3 [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-defects.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.5.3.4 [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.5.3.5 [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.5.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.5.2.5 [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.5.3.5 [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.5 [syserr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2008-02-24 <b>Last modified:</b> 2008-09-26</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#CD1">CD1</a> status.</p> +<p><b>Discussion:</b></p> +<p> +19.5 [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.5 [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.5 [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.5 [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.5.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.5.2.6 [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.5.3.6 [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.8.12.2.5 [unique.ptr.single.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2008-03-13 <b>Last modified:</b> 2008-09-26</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unique.ptr.single.modifiers">active issues</a> in [unique.ptr.single.modifiers].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr.single.modifiers">issues</a> in [unique.ptr.single.modifiers].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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.8.12.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.8.12.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.5.2.1 [tuple.cnstr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2008-03-13 <b>Last modified:</b> 2008-09-26</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#tuple.cnstr">active issues</a> in [tuple.cnstr].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple.cnstr">issues</a> in [tuple.cnstr].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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.5.2.1 [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.3.2 [forward] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2008-03-13 <b>Last modified:</b> 2008-09-26</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#CD1">CD1</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.4.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.3.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.4.3 [alg.swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Niels Dekker <b>Opened:</b> 2008-02-28 <b>Last modified:</b> 2008-09-26</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#CD1">CD1</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 X [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.4.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="813"></a>813. "empty" undefined for <tt>shared_ptr</tt></h3> +<p><b>Section:</b> 20.8.13.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Matt Austern <b>Opened:</b> 2008-02-26 <b>Last modified:</b> 2008-09-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#CD1">CD1</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Several places in 20.8.13.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.8.13.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="818"></a>818. wording for memory ordering</h3> +<p><b>Section:</b> 29.3 [atomics.order] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2008-03-22 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.order">issues</a> in [atomics.order].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> +<p><b>Discussion:</b></p> +<p> +29.3 [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.6 [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.3 [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.6 [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.6 [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><i>[ +San Francisco: +]</i></p> + + +<blockquote> +<p> +Boehm: "I don't think that this changes anything terribly substantive, +but it improves the text." +</p> +<p> +Note that "Rephrase the table in as [sic] follows..." should read +"Replace the table in [atomics.order] with the following...." +</p> +<p> +The proposed resolution needs more work. Crowl volunteered to address +all of the atomics issues in one paper. +</p> + +<p> +This issue is addressed in +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2783.html">N2783</a>. +</p> +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +edit 29.3 [atomics.order], paragraph 1 as follows. +</p> + +<blockquote> +<p> +The enumeration <code>memory_order</code> +specifies the detailed regular (non-atomic) memory synchronization order +as defined in <del>Clause 1.7</del> <ins>section 1.10</ins> +and may provide for operation ordering. +Its enumerated values and their meanings are as follows: +</p> +<blockquote> +<dl> +<dt><ins>For <code>memory_order_relaxed</code>,</ins></dt> +<dd><ins>no operation orders memory.</ins></dd> +<dt><ins>For <code>memory_order_release</code>, +<code>memory_order_acq_rel</code>, +and <code>memory_order_seq_cst</code>,</ins></dt> +<dd><ins>a store operation performs a release operation +on the affected memory location.</ins></dd> +<dt><ins>For <code>memory_order_consume</code>,</ins></dt> +<dd><ins>a load operation performs a consume operation +on the affected memory location.</ins></dd> +<dt><ins>For <code>memory_order_acquire</code>, +<code>memory_order_acq_rel</code>, +and <code>memory_order_seq_cst</code>,</ins></dt> +<dd><ins>a load operation performs an acquire operation +on the affected memory location.</ins></dd> +</dl> +</blockquote> +</blockquote> + +<p> +remove table 136 in 29.3 [atomics.order]. +</p> + +<blockquote> +<table border="1"> +<caption><del>Table 136 — memory_order effects</del></caption> +<tbody><tr><th><del>Element</del></th><th><del>Meaning</del></th></tr> +<tr><td valign="top"><del><code>memory_order_relaxed</code></del></td> +<td valign="top"><del>the operation does not order memory</del></td></tr> +<tr><td valign="top"><del><code>memory_order_release</code></del></td> +<td valign="top"><del>the operation +performs a release operation on the affected memory location, +thus making regular memory writes visible to other threads +through the atomic variable to which it is applied</del></td></tr> +<tr><td valign="top"><del><code>memory_order_acquire</code></del></td> +<td valign="top"><del>the operation +performs an acquire operation on the affected memory location, +thus making regular memory writes in other threads +released through the atomic variable to which it is applied +visible to the current thread</del></td></tr> +<tr><td valign="top"><del><code>memory_order_consume</code></del></td> +<td valign="top"><del>the operation +performs a consume operation on the affected memory location, +thus making regular memory writes in other threads +released through the atomic variable to which it is applied +visible to the regular memory reads +that are dependencies of this consume operation.</del></td></tr> +<tr><td valign="top"><del><code>memory_order_acq_rel</code></del></td> +<td valign="top"><del>the operation has both acquire and release semantics</del></td></tr> +<tr><td valign="top"><del><code>memory_order_seq_cst</code></del></td> +<td valign="top"><del>the operation has both acquire and release semantics, +and, in addition, has sequentially-consistent operation ordering</del></td></tr> +</tbody></table> +</blockquote> + +<p> +edit 29.3 [atomics.order], paragraph 2 as follows. +</p> + +<blockquote> +<p> +<del>The <code>memory_order_seq_cst</code> operations that load a value +are acquire operations on the affected locations. +The <code>memory_order_seq_cst</code> operations that store a value +are release operations on the affected locations. +In addition, in a consistent execution, +there</del> <ins>There</ins> <del>must be</del> <ins>is</ins> +a single total order <var>S</var> +on all <code>memory_order_seq_cst</code> operations, +consistent with the happens before order +and modification orders for all affected locations, +such that each <code>memory_order_seq_cst</code> operation +observes either the last preceding modification +according to this order <var>S</var>, +or the result of an operation that is not <code>memory_order_seq_cst</code>. +[<i>Note:</i> +Although it is not explicitly required that <var>S</var> 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>] +</p> +</blockquote> + + + + + + +<hr> +<h3><a name="820"></a>820. <tt>current_exception()</tt>'s interaction with throwing copy ctors</h3> +<p><b>Section:</b> 18.8.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2008-03-26 <b>Last modified:</b> 2008-09-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#CD1">CD1</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.8.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.8.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> + + + +<p><b>Rationale:</b></p> +<p><i>[ +San Francisco: +]</i></p> + + +<blockquote> +<p> +Pete: there may be an implied assumption in the proposed wording that +current_exception() copies the existing exception object; the +implementation may not actually do that. +</p> +<p> +Pete will make the required editorial tweaks to rectify this. +</p> +</blockquote> + + + + + +<hr> +<h3><a name="821"></a>821. Minor cleanup : <tt>unique_ptr</tt></h3> +<p><b>Section:</b> 20.8.12.3.3 [unique.ptr.runtime.modifiers] <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>Opened:</b> 2008-03-30 <b>Last modified:</b> 2009-03-09</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</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.8.12.3 [unique.ptr.runtime] +</p> + +<blockquote> +<pre>// modifiers +pointer release(); +void reset(pointer p = pointer()); +<ins>void reset( nullptr_t );</ins> +<ins>template< typename U > void reset( U ) = delete;</ins> +void swap(unique_ptr&& u); +</pre> +</blockquote> + +<p> +Update 20.8.12.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-defects.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="823"></a>823. <tt>identity<void></tt> seems broken</h3> +<p><b>Section:</b> 20.3.2 [forward] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Walter Brown <b>Opened:</b> 2008-04-09 <b>Last modified:</b> 2008-09-26</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#CD1">CD1</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.3.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.3.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.4.8.9 [string.io] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-04-10 <b>Last modified:</b> 2008-09-26</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#CD1">CD1</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.3 [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.4.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.3 [string.classes] is correct, and the first of the two +signatures in 21.4.8.9 [string.io] should be deleted. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Delete the first of the two signatures in 21.4.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="829"></a>829. current_exception wording unclear about exception type</h3> +<p><b>Section:</b> 18.8.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2008-04-20 <b>Last modified:</b> 2008-09-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#CD1">CD1</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.8.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="842"></a>842. ConstructibleAsElement and bit containers</h3> +<p><b>Section:</b> 23.2 [container.requirements], 23.3.7 [vector.bool], 20.3.6 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2008-06-03 <b>Last modified:</b> 2008-09-26</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#CD1">CD1</a> status.</p> +<p><b>Discussion:</b></p> +<p> +23.2 [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.3.7 [vector.bool]) and <tt>bitset<N></tt> +(20.3.6 [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.2 [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.3.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.2 [container.requirements]) is not used to construct these values</ins>. +</blockquote> + +<p> +Move 20.3.6 [template.bitset] to clause 20. +</p> + + + + + + +<hr> +<h3><a name="843"></a>843. Reference Closure</h3> +<p><b>Section:</b> 20.7.18.1 [func.referenceclosure.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Lawrence Crowl <b>Opened:</b> 2008-06-02 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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.7.18 [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.7.18.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.4.9 [cmplx.over] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2008-06-03 <b>Last modified:</b> 2009-03-21</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#cmplx.over">issues</a> in [cmplx.over].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The current working draft is in an inconsistent state. +</p> + +<p> +26.4.8 [complex.transcendentals] says that: +</p> + +<blockquote> +<tt>pow(complex<float>(), int())</tt> returns a <tt>complex<float></tt>. +</blockquote> + +<p> +26.4.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.4.1 [complex.syn] and in 26.4.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.5 [atomics.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-06-03 <b>Last modified:</b> 2008-09-26</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#CD1">CD1</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The atomic classes (and class templates) are required to support aggregate +initialization (29.5.1 [atomics.types.integral]p2 / 29.5.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><i>[ +San Francisco: +]</i></p> + + +<blockquote> +<p> +The preferred approach to resolving this is to remove the explicit +specifiers from the atomic integral type constructors. +</p> +<p> +Lawrence will provide wording. +</p> +<p> +This issue is addressed in +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2783.html">N2783</a>. +</p> +</blockquote> + + + +<p><b>Proposed resolution:</b></p> +<p> +within the synopsis in 29.5.1 [atomics.types.integral] edit as follows. +</p> + +<blockquote><pre><code> +.... +typedef struct atomic_bool { +.... + constexpr <del>explicit</del> atomic_bool(bool); +.... +typedef struct atomic_<var>itype</var> { +.... + constexpr <del>explicit</del> atomic_<var>itype</var>(<var>integral</var>); +.... +</code></pre></blockquote> + +<p> +edit 29.5.1 [atomics.types.integral] paragraph 2 as follows. +</p> + +<blockquote> +The atomic integral types shall have standard layout. +They shall each have a trivial default constructor, +a constexpr <del>explicit</del> value constructor, +a deleted copy constructor, +a deleted copy assignment operator, +and a trivial destructor. +They shall each support aggregate initialization syntax. +</blockquote> + +<p> +within the synopsis of 29.5.2 [atomics.types.address] edit as follows. +</p> + +<blockquote><pre><code> +.... +typedef struct atomic_address { +.... + constexpr <del>explicit</del> atomic_address(void*); +.... +</code></pre></blockquote> + +<p> +edit 29.5.2 [atomics.types.address] paragraph 1 as follows. +</p> + +<blockquote> +The type <code>atomic_address</code> shall have standard layout. +It shall have a trivial default constructor, +a constexpr <del>explicit</del> value constructor, +a deleted copy constructor, +a deleted copy assignment operator, +and a trivial destructor. +It shall support aggregate initialization syntax. +</blockquote> + +<p> +within the synopsis of 29.5.3 [atomics.types.generic] edit as follows. +</p> + +<blockquote><pre><code> +.... +template <class T> struct atomic { +.... + constexpr <del>explicit</del> atomic(T); +.... +template <> struct atomic<<var>integral</var>> : atomic_<var>itype</var> { +.... + constexpr <del>explicit</del> atomic(<var>integral</var>); +.... +template <> struct atomic<T*> : atomic_address { +.... + constexpr <del>explicit</del> atomic(T*); +.... +</code></pre></blockquote> + +<p> +edit 29.5.3 [atomics.types.generic] paragraph 2 as follows. +</p> + +<blockquote> +Specializations of the <code>atomic</code> template +shall have a deleted copy constructor, +a deleted copy assignment operator, +and a constexpr <del>explicit</del> value constructor. +</blockquote> + + + + + + +<hr> +<h3><a name="846"></a>846. No definition for constructor</h3> +<p><b>Section:</b> 29.5 [atomics.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-06-03 <b>Last modified:</b> 2008-09-26</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#CD1">CD1</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The atomic classes and class templates (29.5.1 [atomics.types.integral] / +29.5.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><i>[ +San Francisco: +]</i></p> + + +<blockquote> +<p> +Lawrence will provide wording. +</p> +<p> +This issue is addressed in +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2783.html">N2783</a>. +</p> +</blockquote> + + +<p><b>Proposed resolution:</b></p> + +<p> +before the description of ...<code>is_lock_free</code>, +that is before 29.6 [atomics.types.operations] paragraph 4, +add the following description. +</p> + +<blockquote> +<pre><code> +constexpr <var>A</var>::<var>A</var>(<var>C</var> desired); +</code></pre> +<dl> +<dt><i>Effects:</i></dt> +<dd> +Initializes the object with the value <code>desired</code>. +[<i>Note:</i> +Construction is not atomic. +—<i>end note</i>] +</dd> +</dl> +</blockquote> + + + + + +<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.7.17 [unord.hash] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Thorsten Ottosen <b>Opened:</b> 2008-06-05 <b>Last modified:</b> 2008-09-26</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord.hash">active issues</a> in [unord.hash].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.hash">issues</a> in [unord.hash].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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.7 [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.7.17 [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="850"></a>850. Should <tt>shrink_to_fit</tt> apply to <tt>std::deque</tt>?</h3> +<p><b>Section:</b> 23.3.2.2 [deque.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Niels Dekker <b>Opened:</b> 2008-06-05 <b>Last modified:</b> 2008-09-26</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#CD1">CD1</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.3.2 [deque] synopsis, add: +</p> +<blockquote><pre>void shrink_to_fit(); +</pre></blockquote> + +<p> +To deque capacity 23.3.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="852"></a>852. unordered containers <tt>begin(n)</tt> mistakenly <tt>const</tt></h3> +<p><b>Section:</b> 23.5 [unord] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Robert Klarer <b>Opened:</b> 2008-06-12 <b>Last modified:</b> 2008-09-26</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#CD1">CD1</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.5.1 [unord.map], 23.5.2 [unord.multimap], and 23.5.4 [unord.multiset]: +</p> + +<blockquote><pre>local_iterator begin(size_type n)<del> const</del>; +</pre></blockquote> + + + + + +<hr> +<h3><a name="856"></a>856. Removal of <tt>aligned_union</tt></h3> +<p><b>Section:</b> 20.6.7 [meta.trans.other] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2008-06-12 <b>Last modified:</b> 2008-09-26</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#CD1">CD1</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.6.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.6.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="858"></a>858. Wording for Minimal Support for Garbage Collection</h3> +<p><b>Section:</b> 20.8.13.7 [util.dynamic.safety] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Pete Becker <b>Opened:</b> 2008-06-21 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.dynamic.safety">issues</a> in [util.dynamic.safety].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</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><i>[ +San Francisco: +]</i></p> + + +<blockquote> +<p> +Nick: what does "shall be live" mean? +</p> +<p> +Hans: I can provide an appropriate cross-reference to the Project Editor +to clarify the intent. +</p> +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +In 20.8.13.7 [util.dynamic.safety] +(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2670.htm">N2670</a>, +Minimal Support for Garbage Collection) +</p> +<p> +Add at the beginning, before paragraph 39 +</p> + +<blockquote> +A complete object is <i>declared reachable</i> while the number of calls +to <tt>declare_reachable</tt> with an argument referencing the object exceeds the +number of <tt>undeclare_reachable</tt> calls with pointers to the same complete +object. +</blockquote> + +<p> +Change paragraph 42 (Requires clause for <tt>undeclare_reachable</tt>) +</p> + +<blockquote> +If <tt>p</tt> is not null, <del><tt>declare_reachable(p)</tt> was previously called</del> +<ins>the complete object referenced by <tt>p</tt> shall have +been previously declared reachable</ins>, and shall +be live <ins>(3.8 [basic.life])</ins> from the time of the call until the last <tt>undeclare_reachable(p)</tt> +call on the object. +</blockquote> + +<p> +Change the first sentence in paragraph 44 (Effects clause for +<tt>undeclare_reachable</tt>): +</p> + +<blockquote> +<i>Effects:</i> +<del>Once the number of calls to +<tt>undeclare_reachable(p)</tt> equals the number of calls to +<tt>declare_reachable(p)</tt> +for all non-null <tt>p</tt> referencing +the argument is no longer declared reachable. When this happens, +pointers to the object referenced by p may not be subsequently +dereferenced.</del> +<ins> +After a call to <tt>undeclare_reachable(p)</tt>, if <tt>p</tt> is not null and the object <tt>q</tt> +referenced by <tt>p</tt> is no longer declared reachable, then +dereferencing any pointer to <tt>q</tt> that is not safely derived +results in undefined behavior. +</ins> ... +</blockquote> + +<p> +Change the final note: +</p> +<p> +[<i>Note:</i> It is expected that calls to <tt>declare_reachable(p)</tt> +will consume a small amount of memory<ins>, in addition to that occupied +by the referenced object, </ins> until the matching call to +<tt>undeclare_reachable(p)</tt> is encountered. <del>In addition, the +referenced object cannot be deallocated during this period, and garbage +collecting implementations will not be able to collect the object while +it is declared reachable.</del> Long running programs should arrange +that calls <ins>for short-lived objects</ins> are matched. <i>--end +note</i>] +</p> + + + + + + +<hr> +<h3><a name="866"></a>866. Qualification of placement new-expressions</h3> +<p><b>Section:</b> 20.8.11 [specialized.algorithms], 20.8.13.2.6 [util.smartptr.shared.create] <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>Opened:</b> 2008-07-14 <b>Last modified:</b> 2009-03-09</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#specialized.algorithms">issues</a> in [specialized.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> +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.8.6.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.8.11 [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.8.13.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><i>[ +San Francisco: +]</i></p> + + +<blockquote> +Detlef: If we move this to Ready, it's likely that we'll forget about +the side comment about the <tt>HasPlacementNew</tt> concept. +</blockquote> + +<p><i>[ +post San Francisco: +]</i></p> + + +<blockquote> +Daniel: <tt>HasPlacementNew</tt> has been removed from +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2774.pdf">N2774 (Foundational Concepts)</a>. +</blockquote> + + + +<p><b>Proposed resolution:</b></p> +<p> +Replace "<tt>new</tt>" with "<tt>::new</tt>" in: +</p> +<ul> +<li> +20.8.11.2 [uninitialized.copy], paragraphs 1 and 3 +</li> +<li> +20.8.11.3 [uninitialized.fill] paragraph 1 +</li> +<li> +20.8.11.4 [uninitialized.fill.n] paragraph 1 +</li> +<li> +20.8.13.2.6 [util.smartptr.shared.create] once in paragraph 1 and twice in paragraph 2. +</li> +</ul> + + + + + + +<hr> +<h3><a name="882"></a>882. <tt>duration</tt> non-member arithmetic requirements</h3> +<p><b>Section:</b> 20.9.3.5 [time.duration.nonmember] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a> + <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2008-09-08 <b>Last modified:</b> 2008-09-26</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.duration.nonmember">issues</a> in [time.duration.nonmember].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p> +<p><b>Discussion:</b></p> +<p> +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2661.htm">N2661</a> +specified the following requirements for the non-member <tt>duration</tt> +arithmetic: +</p> + +<blockquote> + +<pre>template <class Rep1, class Period, class Rep2> + duration<typename common_type<Rep1, Rep2>::type, Period> + operator*(const duration<Rep1, Period>& d, const Rep2& s); +</pre> +<blockquote> +<i>Requires:</i> Let <tt>CR</tt> represent the <tt>common_type</tt> of <tt>Rep1</tt> and +<tt>Rep2</tt>. Both <tt>Rep1</tt> and <tt>Rep2</tt> shall be implicitly convertible +to CR, diagnostic required. +</blockquote> + +<pre>template <class Rep1, class Period, class Rep2> + duration<typename common_type<Rep1, Rep2>::type, Period> + operator*(const Rep1& s, const duration<Rep2, Period>& d); +</pre> + +<blockquote> +<i>Requires:</i> Let <tt>CR</tt> represent the <tt>common_type</tt> of +<tt>Rep1</tt> and <tt>Rep2</tt>. Both <tt>Rep1</tt> and <tt>Rep2</tt> +shall be implicitly convertible to <tt>CR</tt>, diagnostic required. +</blockquote> + +<pre>template <class Rep1, class Period, class Rep2> + duration<typename common_type<Rep1, Rep2>::type, Period> + operator/(const duration<Rep1, Period>& d, const Rep2& s); +</pre> + +<blockquote> +<i>Requires:</i> Let <tt>CR</tt> represent the <tt>common_type</tt> of +<tt>Rep1</tt> and <tt>Rep2</tt>. Both <tt>Rep1</tt> and <tt>Rep2</tt> shall be +implicitly convertible to <tt>CR</tt>, and <tt>Rep2</tt> shall not be an +instantiation of <tt>duration</tt>, diagnostic required. +</blockquote> + +</blockquote> + +<p> +During transcription into the working paper, the requirements clauses on these +three functions was changed to: +</p> + +<blockquote> +<i>Requires:</i> <tt>CR(Rep1, Rep2)</tt> shall exist. Diagnostic required. +</blockquote> + +<p> +This is a non editorial change with respect to +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2661.htm">N2661</a> +as user written representations which are used in <tt>duration</tt> need not be +implicitly convertible to or from arithmetic types in order to interoperate with +<tt>duration</tt>s based on arithmetic types. An explicit conversion will do +fine for most expressions as long as there exists a <tt>common_type</tt> specialization +relating the user written representation and the arithmetic type. For example: +</p> + +<blockquote><pre>class saturate +{ +public: + explicit saturate(long long i); + ... +}; + +namespace std { + +template <> +struct common_type<saturate, long long> +{ + typedef saturate type; +}; + +template <> +struct common_type<long long, saturate> +{ + typedef saturate type; +}; + +} // std + +millisecond ms(3); // integral-based duration +duration<saturate, milli> my_ms = ms; // ok, even with explicit conversions +my_ms = my_ms + ms; // ok, even with explicit conversions +</pre></blockquote> + +<p> +However, when dealing with multiplication of a duration and its representation, +implicit convertibility is required between the rhs and the lhs's representation +for the member <tt>*=</tt> operator: +</p> + +<blockquote><pre>template <class Rep, class Period = ratio<1>> +class duration { +public: + ... + duration& operator*=(const rep& rhs); + ... +}; +... +ms *= 2; // ok, 2 is implicitly convertible to long long +my_ms *= saturate(2); // ok, rhs is lhs's representation +my_ms *= 2; // error, 2 is not implicitly convertible to saturate +</pre></blockquote> + +<p> +The last line does not (and should not) compile. And we want non-member multiplication +to have the same behavior as member arithmetic: +</p> + +<blockquote><pre>my_ms = my_ms * saturate(2); // ok, rhs is lhs's representation +my_ms = my_ms * 2; // <em>should be</em> error, 2 is not implicitly convertible to saturate +</pre></blockquote> + +<p> +The requirements clauses of +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2661.htm">N2661</a> +make the last line an error as expected. However the latest working draft at +this time +(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>) +allows the last line to compile. +</p> + +<p> +All that being said, there does appear to be an error in these requirements clauses +as specified by +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2661.htm">N2661</a>. +</p> + +<blockquote> +<i>Requires:</i> ... <em>Both</em> <tt>Rep1</tt> and <tt>Rep2</tt> shall be implicitly convertible +to CR, diagnostic required. +</blockquote> + +<p> +It is not necessary for both <tt>Rep</tt>s to be <i>implicitly</i> convertible to +the <tt>CR</tt>. It is only necessary for the rhs <tt>Rep</tt> to be implicitly +convertible to the <tt>CR</tt>. The <tt>Rep</tt> within the <tt>duration</tt> +should be allowed to only be explicitly convertible to the <tt>CR</tt>. The +explicit-conversion-requirement is covered under 20.9.3.7 [time.duration.cast]. +</p> + + + +<p><b>Proposed resolution:</b></p> +<p> +Change the requirements clauses under 20.9.3.5 [time.duration.nonmember]: +</p> + +<blockquote> + +<pre>template <class Rep1, class Period, class Rep2> + duration<typename common_type<Rep1, Rep2>::type, Period> + operator*(const duration<Rep1, Period>& d, const Rep2& s); +</pre> + +<blockquote> +<i>Requires:</i> <del><tt>CR(Rep1, Rep2)</tt> shall exist.</del> +<ins><tt>Rep2</tt> shall be implicitly convertible to <tt>CR(Rep1, Rep2)</tt>.</ins> +Diagnostic required. +</blockquote> + +<pre>template <class Rep1, class Period, class Rep2> + duration<typename common_type<Rep1, Rep2>::type, Period> + operator*(const Rep1& s, const duration<Rep2, Period>& d); +</pre> + +<blockquote> +<i>Require<ins>s</ins><del>d behavior</del>:</i> <del><tt>CR(Rep1, Rep2)</tt> shall exist.</del> +<ins><tt>Rep1</tt> shall be implicitly convertible to <tt>CR(Rep1, Rep2)</tt>.</ins> +Diagnostic required. +</blockquote> + +<pre>template <class Rep1, class Period, class Rep2> + duration<typename common_type<Rep1, Rep2>::type, Period> + operator/(const duration<Rep1, Period>& d, const Rep2& s); +</pre> + +<blockquote> +<i>Requires:</i> <del><tt>CR(Rep1, Rep2)</tt> shall exist</del> +<ins><tt>Rep2</tt> shall be implicitly convertible to <tt>CR(Rep1, Rep2)</tt></ins> +and <tt>Rep2</tt> shall not +be an instantiation of <tt>duration</tt>. Diagnostic required. +</blockquote> + +</blockquote> + + + + + +<hr> +<h3><a name="894"></a>894. longjmp and destructors</h3> +<p><b>Section:</b> 18.10 [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, Alisdair Meredith <b>Opened:</b> 2008-09-17 <b>Last modified:</b> 2009-03-09</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#support.runtime">issues</a> in [support.runtime].</p> +<p><b>View all issues with</b> <a 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 interaction between <tt>longjmp</tt> and exceptions seems unnecessarily +restrictive and not in keeping with existing practice. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Edit paragraph 4 of 18.10 [support.runtime] as follows: +</p> + +<blockquote> +The function signature <tt>longjmp(jmp_buf jbuf, int val)</tt> has more +restricted behavior in this International Standard. A +<tt>setjmp/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 <del>destroy</del> +<ins>invoke any non-trivial destructors for</ins> +any automatic objects. +</blockquote> + + + + + </body></html>
\ No newline at end of file diff --git a/libstdc++-v3/doc/xml/manual/intro.xml b/libstdc++-v3/doc/xml/manual/intro.xml index 9523195..560a0b5 100644 --- a/libstdc++-v3/doc/xml/manual/intro.xml +++ b/libstdc++-v3/doc/xml/manual/intro.xml @@ -262,7 +262,7 @@ requirements of the license of GCC. <listitem><para>Re-opening a file stream does <emphasis>not</emphasis> clear the state flags. </para></listitem></varlistentry> - <varlistentry><term><ulink url="../ext/lwg-active.html#23">23</ulink>: + <varlistentry><term><ulink url="../ext/lwg-defects.html#23">23</ulink>: <emphasis>Num_get overflow result</emphasis> </term> <listitem><para>Implement the proposed resolution. @@ -461,7 +461,7 @@ requirements of the license of GCC. is specified in the conversion specification. </para></listitem></varlistentry> - <varlistentry><term><ulink url="../ext/lwg-active.html#233">233</ulink>: + <varlistentry><term><ulink url="../ext/lwg-defects.html#233">233</ulink>: <emphasis>Insertion hints in associative containers</emphasis> </term> <listitem><para>Implement N1780, first check before then check after, insert as close @@ -576,7 +576,7 @@ requirements of the license of GCC. <listitem><para>Add const overloads of <code>is_open</code>. </para></listitem></varlistentry> - <varlistentry><term><ulink url="../ext/lwg-active.html#387">387</ulink>: + <varlistentry><term><ulink url="../ext/lwg-defects.html#387">387</ulink>: <emphasis>std::complex over-encapsulated</emphasis> </term> <listitem><para>Add the <code>real(T)</code> and <code>imag(T)</code> @@ -592,7 +592,7 @@ requirements of the license of GCC. <listitem><para>Change it to return a <code>const T&</code>. </para></listitem></varlistentry> - <varlistentry><term><ulink url="../ext/lwg-active.html#396">396</ulink>: + <varlistentry><term><ulink url="../ext/lwg-defects.html#396">396</ulink>: <emphasis>what are characters zero and one</emphasis> </term> <listitem><para>Implement the proposed resolution. @@ -723,7 +723,7 @@ requirements of the license of GCC. <listitem><para>Add the missing operations. </para></listitem></varlistentry> - <varlistentry><term><ulink url="../ext/lwg-active.html#691">691</ulink>: + <varlistentry><term><ulink url="../ext/lwg-defects.html#691">691</ulink>: <emphasis>const_local_iterator cbegin, cend missing from TR1</emphasis> </term> <listitem><para>In C++0x mode add cbegin(size_type) and cend(size_type) @@ -760,7 +760,7 @@ requirements of the license of GCC. <listitem><para>Implement the int -> size_t replacements. </para></listitem></varlistentry> - <varlistentry><term><ulink url="../ext/lwg-active.html#776">776</ulink>: + <varlistentry><term><ulink url="../ext/lwg-defects.html#776">776</ulink>: <emphasis>Undescribed assign function of std::array</emphasis> </term> <listitem><para>In C++0x mode, remove assign, add fill. @@ -772,13 +772,13 @@ requirements of the license of GCC. <listitem><para>In C++0x mode, add std::proj. </para></listitem></varlistentry> - <varlistentry><term><ulink url="../ext/lwg-active.html#809">809</ulink>: + <varlistentry><term><ulink url="../ext/lwg-defects.html#809">809</ulink>: <emphasis>std::swap should be overloaded for array types</emphasis> </term> <listitem><para>Add the overload. </para></listitem></varlistentry> - <varlistentry><term><ulink url="../ext/lwg-active.html#844">844</ulink>: + <varlistentry><term><ulink url="../ext/lwg-defects.html#844">844</ulink>: <emphasis>complex pow return type is ambiguous</emphasis> </term> <listitem><para>In C++0x mode, remove the pow(complex<T>, int) signature. |