1<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
2<html><head>
3<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
4
5
6<title>C++ Standard Library Defect Report List</title>
7<style type="text/css">
8p {text-align:justify}
9li {text-align:justify}
10blockquote.note
11{
12    background-color:#E0E0E0;
13    padding-left: 15px;
14    padding-right: 15px;
15    padding-top: 1px;
16    padding-bottom: 1px;
17}
18ins {background-color:#A0FFA0}
19del {background-color:#FFA0A0}
20</style>
21</head><body>
22<table>
23<tbody><tr>
24<td align="left">Doc. no.</td>
25<td align="left">N3012=09-0202</td>
26</tr>
27<tr>
28<td align="left">Date:</td>
29<td align="left">2009-11-08</td>
30</tr>
31<tr>
32<td align="left">Project:</td>
33<td align="left">Programming Language C++</td>
34</tr>
35<tr>
36<td align="left">Reply to:</td>
37<td align="left">Howard Hinnant &lt;<a href="mailto:howard.hinnant@gmail.com">howard.hinnant@gmail.com</a>&gt;</td>
38</tr>
39</tbody></table>
40<h1>C++ Standard Library Defect Report List (Revision R68)</h1>
41
42  <p>Reference ISO/IEC IS 14882:2003(E)</p>
43  <p>Also see:</p>
44    <ul>
45      <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html">Table of Contents</a> for all library issues.</li>
46      <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html">Index by Section</a> for all library issues.</li>
47      <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html">Index by Status</a> for all library issues.</li>
48      <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html">Library Active Issues List</a></li>
49      <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html">Library Closed Issues List</a></li>
50    </ul>
51  <p>This document contains only library issues which have been closed
52  by the Library Working Group (LWG) after being found to be defects
53  in the standard.  That is, issues which have a status of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>,
54  <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>, or <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#RR">RR</a>. See the
55  <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html">Library Closed Issues List</a> for issues closed as non-defects.  See the
56  <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html">Library Active Issues List</a> for active issues and more information.  The
57  introductory material in that document also applies to this
58  document.</p>
59
60<h2>Revision History</h2>
61<ul>
62<li>R68: 
632009-11-06 post-Santa Cruz mailing.
64<ul>
65<li><b>Summary:</b><ul>
66<li>205 open issues, down by 77.</li>
67<li>1055 closed issues, up by 120.</li>
68<li>1260 issues total, up by 43.</li>
69</ul></li>
70<li><b>Details:</b><ul>
71<li>Added the following Dup issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1230">1230</a>.</li>
72<li>Added the following NAD issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1229">1229</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1236">1236</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1243">1243</a>.</li>
73<li>Added the following NAD Editorial issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1232">1232</a>.</li>
74<li>Added the following NAD Future issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1235">1235</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1242">1242</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1248">1248</a>.</li>
75<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1218">1218</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1219">1219</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1221">1221</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1222">1222</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1223">1223</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1224">1224</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1225">1225</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1234">1234</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1240">1240</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1244">1244</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1245">1245</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1246">1246</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1249">1249</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1250">1250</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1251">1251</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1252">1252</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1253">1253</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1254">1254</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1255">1255</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1256">1256</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1257">1257</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1258">1258</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1259">1259</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1260">1260</a>.</li>
76<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1228">1228</a>.</li>
77<li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1227">1227</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1237">1237</a>.</li>
78<li>Added the following Review issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1247">1247</a>.</li>
79<li>Added the following Tentatively NAD Editorial issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1233">1233</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1239">1239</a>.</li>
80<li>Added the following Tentatively NAD Future issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1238">1238</a>.</li>
81<li>Added the following Tentatively Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1220">1220</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1226">1226</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1231">1231</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1241">1241</a>.</li>
82<li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1132">1132</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1148">1148</a>.</li>
83<li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#96">96</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#458">458</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#916">916</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#917">917</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#919">919</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#955">955</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#977">977</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1009">1009</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1020">1020</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1035">1035</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1042">1042</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1051">1051</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1064">1064</a>.</li>
84<li>Changed the following issues from Review to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#930">930</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1091">1091</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1102">1102</a>.</li>
85<li>Changed the following issues from Tentatively NAD to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#588">588</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#617">617</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#971">971</a>.</li>
86<li>Changed the following issues from Tentatively NAD Future to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1062">1062</a>.</li>
87<li>Changed the following issues from NAD Concepts to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1143">1143</a>.</li>
88<li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1116">1116</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1117">1117</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1122">1122</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1129">1129</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1145">1145</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1146">1146</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1147">1147</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1155">1155</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1166">1166</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1172">1172</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1174">1174</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1179">1179</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1195">1195</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1196">1196</a>.</li>
89<li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#431">431</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#580">580</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#635">635</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#719">719</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#823">823</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#827">827</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#879">879</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#880">880</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#908">908</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#923">923</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#924">924</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#926">926</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#944">944</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#947">947</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#958">958</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1046">1046</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1048">1048</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1054">1054</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1055">1055</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1075">1075</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1088">1088</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1160">1160</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1161">1161</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1162">1162</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1163">1163</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1165">1165</a>.</li>
90<li>Changed the following issues from Review to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#828">828</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#897">897</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#976">976</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1043">1043</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1047">1047</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1049">1049</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1050">1050</a>.</li>
91<li>Changed the following issues from New to NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1120">1120</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1150">1150</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1184">1184</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1203">1203</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1217">1217</a>.</li>
92<li>Changed the following issues from Open to NAD Future: <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#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#851">851</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#933">933</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#935">935</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#936">936</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#961">961</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1041">1041</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1053">1053</a>.</li>
93<li>Changed the following issues from Tentatively NAD Future to NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1031">1031</a>.</li>
94<li>Changed the following issues from New to Open: <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#1151">1151</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1153">1153</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1156">1156</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1171">1171</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1173">1173</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1183">1183</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1191">1191</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1211">1211</a>.</li>
95<li>Changed the following issues from Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#430">430</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#834">834</a>.</li>
96<li>Changed the following issues from Review to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#397">397</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#408">408</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#835">835</a>.</li>
97<li>Changed the following issues from Tentatively NAD to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#625">625</a>.</li>
98<li>Changed the following issues from New to Ready: <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#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#1144">1144</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1177">1177</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1194">1194</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1204">1204</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1216">1216</a>.</li>
99<li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#296">296</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-active.html#485">485</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#816">816</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#865">865</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#920">920</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#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#960">960</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#974">974</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#1011">1011</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#1079">1079</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1098">1098</a>.</li>
100<li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#473">473</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#836">836</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#868">868</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#889">889</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#921">921</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#954">954</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#962">962</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#983">983</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#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#1100">1100</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#1157">1157</a>.</li>
101<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1130">1130</a>.</li>
102<li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#556">556</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#631">631</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#727">727</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#929">929</a>.</li>
103<li>Changed the following issues from Open to Tentatively NAD: <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#1099">1099</a>.</li>
104<li>Changed the following issues from New to Tentatively NAD Concepts: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1186">1186</a>.</li>
105<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#1115">1115</a>.</li>
106<li>Changed the following issues from New to Tentatively NAD Future: <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#1201">1201</a>.</li>
107<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#1112">1112</a>.</li>
108<li>Changed the following issues from New to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1126">1126</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#1152">1152</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1158">1158</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1189">1189</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1192">1192</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1208">1208</a>.</li>
109<li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#987">987</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#1071">1071</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#1108">1108</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>
110<li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#149">149</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#419">419</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#498">498</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#564">564</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#565">565</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#659">659</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#696">696</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#711">711</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#716">716</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#723">723</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#788">788</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#822">822</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#838">838</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#847">847</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#857">857</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#859">859</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#876">876</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#881">881</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#883">883</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#886">886</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#934">934</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1004">1004</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1178">1178</a>.</li>
111<li>Changed the following issues from Tentatively Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1012">1012</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1019">1019</a>.</li>
112</ul></li>
113</ul>
114</li>
115<li>R67: 
1162009-09-25 pre-Santa Cruz mailing.
117<ul>
118<li><b>Summary:</b><ul>
119<li>282 open issues, up by 32.</li>
120<li>935 closed issues, down by 1.</li>
121<li>1217 issues total, up by 31.</li>
122</ul></li>
123<li><b>Details:</b><ul>
124<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1187">1187</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1188">1188</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1189">1189</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1190">1190</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1191">1191</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1192">1192</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1193">1193</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1194">1194</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1195">1195</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1196">1196</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1197">1197</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1198">1198</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1199">1199</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1200">1200</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1201">1201</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1202">1202</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1203">1203</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1204">1204</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1205">1205</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1206">1206</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1207">1207</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1208">1208</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1209">1209</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1210">1210</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1211">1211</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1212">1212</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1213">1213</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1214">1214</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1215">1215</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1216">1216</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1217">1217</a>.</li>
125<li>Changed the following issues from NAD to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#296">296</a>.</li>
126<li>Changed the following issues from WP to Pending WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#970">970</a>.</li>
127<li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#976">976</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1052">1052</a>.</li>
128<li>Changed the following issues from Ready to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#780">780</a>.</li>
129</ul></li>
130</ul>
131</li>
132<li>R66: 
1332009-07-31 post-Frankfurt mailing.
134<ul>
135<li><b>Summary:</b><ul>
136<li>250 open issues, down by 128.</li>
137<li>936 closed issues, up by 171.</li>
138<li>1186 issues total, up by 43.</li>
139</ul></li>
140<li><b>Details:</b><ul>
141<li>Added the following NAD issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1164">1164</a>.</li>
142<li>Added the following NAD Concepts issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1149">1149</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1167">1167</a>.</li>
143<li>Added the following NAD Editorial issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1168">1168</a>.</li>
144<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1144">1144</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1145">1145</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1146">1146</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1147">1147</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1148">1148</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1150">1150</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1151">1151</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1152">1152</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1153">1153</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1154">1154</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1155">1155</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1156">1156</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1158">1158</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1159">1159</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1166">1166</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1169">1169</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1170">1170</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1171">1171</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1172">1172</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1173">1173</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1174">1174</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1175">1175</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1176">1176</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1177">1177</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1179">1179</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1180">1180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1181">1181</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1182">1182</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1183">1183</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1184">1184</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1185">1185</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1186">1186</a>.</li>
145<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1160">1160</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1161">1161</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1162">1162</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1163">1163</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1165">1165</a>.</li>
146<li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1178">1178</a>.</li>
147<li>Added the following Review issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1157">1157</a>.</li>
148<li>Changed the following issues from Open to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#750">750</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#895">895</a>.</li>
149<li>Changed the following issues from Open to NAD: <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#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#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#290">290</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#309">309</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#342">342</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#343">343</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#382">382</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#394">394</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#398">398</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#417">417</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#418">418</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#421">421</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#459">459</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#492">492</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#502">502</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#503">503</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#546">546</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#573">573</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#582">582</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#585">585</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#597">597</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#606">606</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#614">614</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#632">632</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#721">721</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#747">747</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#751">751</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#833">833</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#941">941</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#992">992</a>.</li>
150<li>Changed the following issues from Review to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1003">1003</a>.</li>
151<li>Changed the following issues from Tentatively NAD to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#568">568</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#644">644</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#701">701</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#702">702</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#785">785</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#863">863</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#901">901</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#903">903</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#946">946</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#988">988</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#995">995</a>.</li>
152<li>Changed the following issues from Tentatively Ready to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1002">1002</a>.</li>
153<li>Changed the following issues from New to NAD Concepts: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1124">1124</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1127">1127</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1128">1128</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1139">1139</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1140">1140</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1141">1141</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1142">1142</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1143">1143</a>.</li>
154<li>Changed the following issues from Open to NAD Concepts: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#902">902</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#989">989</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1000">1000</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1007">1007</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1010">1010</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1015">1015</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1016">1016</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1017">1017</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1018">1018</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1026">1026</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1027">1027</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1028">1028</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1029">1029</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1032">1032</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1036">1036</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1057">1057</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1059">1059</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1072">1072</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1078">1078</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1081">1081</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1082">1082</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1083">1083</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1084">1084</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1085">1085</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1086">1086</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1092">1092</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1096">1096</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1105">1105</a>.</li>
155<li>Changed the following issues from Review to NAD Concepts: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1001">1001</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1005">1005</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1080">1080</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1087">1087</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1111">1111</a>.</li>
156<li>Changed the following issues from Tentatively NAD to NAD Concepts: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#912">912</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#918">918</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1074">1074</a>.</li>
157<li>Changed the following issues from Tentatively NAD Editorial to NAD Concepts: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#927">927</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1109">1109</a>.</li>
158<li>Changed the following issues from Tentatively Ready to NAD Concepts: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#906">906</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#913">913</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#914">914</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#928">928</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1024">1024</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1063">1063</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1067">1067</a>.</li>
159<li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#718">718</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#873">873</a>.</li>
160<li>Changed the following issues from Tentatively NAD Editorial to 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#825">825</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#830">830</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#837">837</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#862">862</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#867">867</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#884">884</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#945">945</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#952">952</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#969">969</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#972">972</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#973">973</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#979">979</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1023">1023</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1058">1058</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1060">1060</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1061">1061</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1077">1077</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1101">1101</a>.</li>
161<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#1013">1013</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1107">1107</a>.</li>
162<li>Changed the following issues from Open to NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#255">255</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#423">423</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#523">523</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#708">708</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#839">839</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#877">877</a>.</li>
163<li>Changed the following issues from CD1 to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#823">823</a>.</li>
164<li>Changed the following issues from NAD Editorial to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#556">556</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#594">594</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#676">676</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-active.html#724">724</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#811">811</a>, <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#872">872</a>.</li>
165<li>Changed the following issues from Review to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#879">879</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#919">919</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#939">939</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-closed.html#1009">1009</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1093">1093</a>.</li>
166<li>Changed the following issues from Tentatively NAD to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#458">458</a>.</li>
167<li>Changed the following issues from Tentatively NAD Future to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#96">96</a>.</li>
168<li>Changed the following issues from Tentatively Ready to Open: <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#915">915</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#940">940</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-closed.html#976">976</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#1011">1011</a>.</li>
169<li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#149">149</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#419">419</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#430">430</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#498">498</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#564">564</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#565">565</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#659">659</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#696">696</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#711">711</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#716">716</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#723">723</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#788">788</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-defects.html#838">838</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#847">847</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#857">857</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#859">859</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#876">876</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#881">881</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#883">883</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#886">886</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1004">1004</a>.</li>
170<li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#780">780</a>.</li>
171<li>Changed the following issues from Tentatively NAD to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#822">822</a>.</li>
172<li>Changed the following issues from Tentatively Ready to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#934">934</a>.</li>
173<li>Changed the following issues from NAD to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#871">871</a>.</li>
174<li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#397">397</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#408">408</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#473">473</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#836">836</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#889">889</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-closed.html#930">930</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#962">962</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>
175<li>Changed the following issues from Tentatively NAD to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#668">668</a>.</li>
176<li>Changed the following issues from Tentatively Ready to Review: <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#1100">1100</a>.</li>
177<li>Changed the following issues from Open to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#588">588</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#617">617</a>, <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#971">971</a>.</li>
178<li>Changed the following issues from Open to Tentatively NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1031">1031</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1062">1062</a>.</li>
179<li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1012">1012</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1019">1019</a>.</li>
180<li>Changed the following issues from Tentatively Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#765">765</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#810">810</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#814">814</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#853">853</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#869">869</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#878">878</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#888">888</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#890">890</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#898">898</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#899">899</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#904">904</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#907">907</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#909">909</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#922">922</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#925">925</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#931">931</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#938">938</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#943">943</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#948">948</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#949">949</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#965">965</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#970">970</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#975">975</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#981">981</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#982">982</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#984">984</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#986">986</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#990">990</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#991">991</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#993">993</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#994">994</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#997">997</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#998">998</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1006">1006</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1014">1014</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1021">1021</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1037">1037</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1038">1038</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1039">1039</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1040">1040</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1044">1044</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1045">1045</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1065">1065</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1066">1066</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1070">1070</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1073">1073</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1103">1103</a>.</li>
181</ul></li>
182</ul>
183</li>
184<li>R65: 
1852009-06-19 pre-Frankfurt mailing.
186<ul>
187<li><b>Summary:</b><ul>
188<li>378 open issues, up by 32.</li>
189<li>765 closed issues, up by 0.</li>
190<li>1143 issues total, up by 32.</li>
191</ul></li>
192<li><b>Details:</b><ul>
193<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-closed.html#1116">1116</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.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-closed.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-closed.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-closed.html#1127">1127</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1128">1128</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.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-closed.html#1139">1139</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1140">1140</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1141">1141</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1142">1142</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1143">1143</a>.</li>
194<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>
195<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>
196<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#696">696</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-closed.html#916">916</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.html#933">933</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#935">935</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#941">941</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.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-closed.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-closed.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-closed.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-closed.html#1057">1057</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1059">1059</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.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-closed.html#1092">1092</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.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>
197<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-closed.html#971">971</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#992">992</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1004">1004</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1010">1010</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1012">1012</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1015">1015</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1019">1019</a>.</li>
198<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-closed.html#897">897</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.html#1001">1001</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1080">1080</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.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-closed.html#1111">1111</a>.</li>
199<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-closed.html#1087">1087</a>.</li>
200<li>Changed the following issues from New to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#568">568</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#701">701</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#702">702</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#785">785</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#863">863</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#903">903</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#912">912</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#918">918</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#946">946</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#995">995</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1074">1074</a>.</li>
201<li>Changed the following issues from Open to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#458">458</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#644">644</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#669">669</a>.</li>
202<li>Changed the following issues from Review to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#901">901</a>.</li>
203<li>Changed the following issues from Tentatively Ready to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#822">822</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#988">988</a>.</li>
204<li>Changed the following issues from New to Tentatively NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#837">837</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#862">862</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#867">867</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#927">927</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#945">945</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#952">952</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#969">969</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#972">972</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#973">973</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#979">979</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1058">1058</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1060">1060</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1061">1061</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1077">1077</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1101">1101</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1109">1109</a>.</li>
205<li>Changed the following issues from Open to Tentatively 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#825">825</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#830">830</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#884">884</a>.</li>
206<li>Changed the following issues from Review to Tentatively NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1023">1023</a>.</li>
207<li>Changed the following issues from Open to Tentatively NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#96">96</a>.</li>
208<li>Changed the following issues from New to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#810">810</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#898">898</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.html#913">913</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-defects.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-closed.html#976">976</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#981">981</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#982">982</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#984">984</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#990">990</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-closed.html#1063">1063</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1067">1067</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1070">1070</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.html#1103">1103</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1107">1107</a>.</li>
209<li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#814">814</a>.</li>
210<li>Changed the following issues from Review to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#899">899</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#907">907</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#909">909</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#934">934</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.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-defects.html#965">965</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#970">970</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#975">975</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#986">986</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#991">991</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#993">993</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#994">994</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#997">997</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1002">1002</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-closed.html#1013">1013</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1014">1014</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1021">1021</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1024">1024</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1037">1037</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1038">1038</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1039">1039</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1040">1040</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1044">1044</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1045">1045</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1065">1065</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1066">1066</a>.</li>
211</ul></li>
212</ul>
213</li>
214<li>R64: 
2152009-05-01 mid-term mailing.
216<ul>
217<li><b>Summary:</b><ul>
218<li>346 open issues, up by 19.</li>
219<li>765 closed issues, up by 0.</li>
220<li>1111 issues total, up by 19.</li>
221</ul></li>
222<li><b>Details:</b><ul>
223<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-closed.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-closed.html#1101">1101</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1102">1102</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-closed.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-closed.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-closed.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-closed.html#1111">1111</a>.</li>
224<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>
225<li>Changed the following issues from Review to New: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1070">1070</a>.</li>
226</ul></li>
227</ul>
228</li>
229<li>R63: 
2302009-03-20 post-Summit mailing.
231<ul>
232<li><b>Summary:</b><ul>
233<li>327 open issues, up by 96.</li>
234<li>765 closed issues, up by 14.</li>
235<li>1092 issues total, up by 110.</li>
236</ul></li>
237<li><b>Details:</b><ul>
238<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>
239<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>
240<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-defects.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-closed.html#989">989</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#990">990</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-defects.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-closed.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-closed.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-closed.html#1057">1057</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1058">1058</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1059">1059</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1060">1060</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1061">1061</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1062">1062</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1063">1063</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.html#1072">1072</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1073">1073</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.html#1077">1077</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.html#1091">1091</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1092">1092</a>.</li>
241<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-closed.html#1000">1000</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.html#1016">1016</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1017">1017</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1018">1018</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1020">1020</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1026">1026</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1027">1027</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1028">1028</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.html#1031">1031</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.html#1035">1035</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1036">1036</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1041">1041</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1042">1042</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1046">1046</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1048">1048</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.html#1053">1053</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1055">1055</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1064">1064</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1075">1075</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.html#1081">1081</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1082">1082</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1083">1083</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1084">1084</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1085">1085</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1086">1086</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1087">1087</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1088">1088</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1089">1089</a>.</li>
242<li>Added the following Review issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#986">986</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#991">991</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#992">992</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#993">993</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#994">994</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#997">997</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1002">1002</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1003">1003</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1004">1004</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1005">1005</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1006">1006</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1009">1009</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-defects.html#1012">1012</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1013">1013</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1014">1014</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1015">1015</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1019">1019</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1021">1021</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1023">1023</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1024">1024</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1037">1037</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1038">1038</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1039">1039</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1040">1040</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1043">1043</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1044">1044</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1045">1045</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1047">1047</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1049">1049</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1050">1050</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1065">1065</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1066">1066</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1070">1070</a>.</li>
243<li>Added the following Tentatively Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#988">988</a>.</li>
244<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>
245<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>
246<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>
247<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>
248<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>
249<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>
250<li>Changed the following issues from NAD to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#466">466</a>.</li>
251<li>Changed the following issues from NAD Future to Open: <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#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#149">149</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#219">219</a>.</li>
252<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.html#902">902</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.html#923">923</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#924">924</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#926">926</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#930">930</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#936">936</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#944">944</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.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>
253<li>Changed the following issues from Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#788">788</a>.</li>
254<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>
255<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#879">879</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#899">899</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#901">901</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#907">907</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.html#934">934</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.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-defects.html#965">965</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#970">970</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#971">971</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#975">975</a>.</li>
256<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>
257<li>Changed the following issues from New to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#904">904</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#922">922</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#928">928</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.html#948">948</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#949">949</a>.</li>
258<li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#890">890</a>.</li>
259<li>Changed the following issues from Review to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#765">765</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#822">822</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#853">853</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#869">869</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#878">878</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#888">888</a>.</li>
260<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>
261</ul></li>
262</ul>
263</li>
264<li>R62: 
2652009-02-06 pre-Summit mailing.
266<ul>
267<li><b>Summary:</b><ul>
268<li>231 open issues, up by 44.</li>
269<li>751 closed issues, up by 0.</li>
270<li>982 issues total, up by 44.</li>
271</ul></li>
272<li><b>Details:</b><ul>
273<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-closed.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-defects.html#943">943</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#944">944</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#945">945</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#946">946</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#947">947</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#948">948</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-closed.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-closed.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-closed.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-closed.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-defects.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-closed.html#969">969</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#970">970</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#971">971</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#972">972</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-defects.html#975">975</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#976">976</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.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-defects.html#981">981</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#982">982</a>.</li>
274</ul></li>
275</ul>
276</li>
277<li>R61: 
2782008-12-05 mid-term mailing.
279<ul>
280<li><b>Summary:</b><ul>
281<li>187 open issues, up by 20.</li>
282<li>751 closed issues, up by 0.</li>
283<li>938 issues total, up by 20.</li>
284</ul></li>
285<li><b>Details:</b><ul>
286<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-defects.html#922">922</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#923">923</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#924">924</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#925">925</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#926">926</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#927">927</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.html#930">930</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-closed.html#933">933</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#934">934</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#935">935</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-defects.html#938">938</a>.</li>
287</ul></li>
288</ul>
289</li>
290<li>R60: 
2912008-10-03 post-San Francisco mailing.
292<ul>
293<li><b>Summary:</b><ul>
294<li>167 open issues, down by 25.</li>
295<li>751 closed issues, up by 65.</li>
296<li>918 issues total, up by 40.</li>
297</ul></li>
298<li><b>Details:</b><ul>
299<li>Added the following CD1 issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#882">882</a>.</li>
300<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#879">879</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.html#897">897</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#898">898</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-closed.html#901">901</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#902">902</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#903">903</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-closed.html#906">906</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#907">907</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#908">908</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-closed.html#912">912</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#913">913</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.html#916">916</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#917">917</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#918">918</a>.</li>
301<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#881">881</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#883">883</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-defects.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-defects.html#890">890</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#895">895</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#896">896</a>.</li>
302<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>
303<li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#894">894</a>.</li>
304<li>Added the following Review issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#888">888</a>.</li>
305<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>
306<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>
307<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-closed.html#823">823</a>.</li>
308<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>
309<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>
310<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-active.html#871">871</a>.</li>
311<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>
312<li>Changed the following issues from New to NAD Editorial: <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-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-active.html#870">870</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#872">872</a>.</li>
313<li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#556">556</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#676">676</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-active.html#724">724</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#742">742</a>.</li>
314<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-active.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>
315<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#721">721</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#751">751</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-closed.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-defects.html#838">838</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#847">847</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#857">857</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-closed.html#873">873</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#876">876</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#877">877</a>.</li>
316<li>Changed the following issues from Pending NAD Editorial to Open: <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-active.html#625">625</a>.</li>
317<li>Changed the following issues from Review to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#851">851</a>.</li>
318<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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>
319<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>
320<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>
321<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#765">765</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#822">822</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.html#869">869</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#878">878</a>.</li>
322<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>
323</ul></li>
324</ul>
325</li>
326<li>R59: 
3272008-08-22 pre-San Francisco mailing.
328<ul>
329<li><b>Summary:</b><ul>
330<li>192 open issues, up by 9.</li>
331<li>686 closed issues, up by 0.</li>
332<li>878 issues total, up by 9.</li>
333</ul></li>
334<li><b>Details:</b><ul>
335<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-closed.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-defects.html#876">876</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#877">877</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#878">878</a>.</li>
336</ul></li>
337</ul>
338</li>
339<li>R58: 
3402008-07-28 mid-term mailing.
341<ul>
342<li><b>Summary:</b><ul>
343<li>183 open issues, up by 12.</li>
344<li>686 closed issues, down by 4.</li>
345<li>869 issues total, up by 8.</li>
346</ul></li>
347<li><b>Details:</b><ul>
348<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#862">862</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.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-defects.html#869">869</a>.</li>
349<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>
350<li>Changed the following issues from Pending WP to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#644">644</a>.</li>
351<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>
352<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>
353</ul></li>
354</ul>
355</li>
356<li>R57: 
3572008-06-27 post-Sophia Antipolis mailing.
358<ul>
359<li><b>Summary:</b><ul>
360<li>171 open issues, down by 20.</li>
361<li>690 closed issues, up by 43.</li>
362<li>861 issues total, up by 23.</li>
363</ul></li>
364<li><b>Details:</b><ul>
365<li>Added the following NAD issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#840">840</a>.</li>
366<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-defects.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-defects.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-defects.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-defects.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>
367<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#839">839</a>.</li>
368<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>
369<li>Added the following Review issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#851">851</a>.</li>
370<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>
371<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>
372<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>
373<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>
374<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-closed.html#825">825</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#830">830</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#833">833</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#834">834</a>.</li>
375<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>
376<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-defects.html#711">711</a>.</li>
377<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>
378<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>
379<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>
380<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-closed.html#823">823</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#828">828</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#832">832</a>.</li>
381<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>
382<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>
383<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>
384</ul></li>
385</ul>
386</li>
387<li>R56: 
3882008-05-16 pre-Sophia Antipolis mailing.
389<ul>
390<li><b>Summary:</b><ul>
391<li>191 open issues, up by 24.</li>
392<li>647 closed issues, up by 1.</li>
393<li>838 issues total, up by 25.</li>
394</ul></li>
395<li><b>Details:</b><ul>
396<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.html#822">822</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.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-closed.html#827">827</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.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-closed.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-closed.html#837">837</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#838">838</a>.</li>
397<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>
398</ul></li>
399</ul>
400</li>
401<li>R55: 
4022008-03-14 post-Bellevue mailing.
403<ul>
404<li><b>Summary:</b><ul>
405<li>167 open issues, down by 39.</li>
406<li>646 closed issues, up by 65.</li>
407<li>813 issues total, up by 26.</li>
408</ul></li>
409<li><b>Details:</b><ul>
410<li>Added the following Dup issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#795">795</a>.</li>
411<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>
412<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.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-closed.html#812">812</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#813">813</a>.</li>
413<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>
414<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>
415<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>
416<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>
417<li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#729">729</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#730">730</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#731">731</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#733">733</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#735">735</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#736">736</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#737">737</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#739">739</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#741">741</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#745">745</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#748">748</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#763">763</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#764">764</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#773">773</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#784">784</a>.</li>
418<li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#388">388</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#462">462</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#579">579</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#707">707</a>.</li>
419<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>
420<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>
421<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>
422<li>Changed the following issues from NAD Future to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#128">128</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#190">190</a>.</li>
423<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#617">617</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#718">718</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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#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-active.html#742">742</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#747">747</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.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>
424<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-active.html#676">676</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#688">688</a>.</li>
425<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>
426<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-active.html#625">625</a>.</li>
427<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>
428<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>
429<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>
430<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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>
431<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>
432<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>
433<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>
434</ul></li>
435</ul>
436</li>
437<li>R54: 
4382008-02-01 pre-Bellevue mailing.
439<ul>
440<li><b>Summary:</b><ul>
441<li>206 open issues, up by 23.</li>
442<li>581 closed issues, up by 0.</li>
443<li>787 issues total, up by 23.</li>
444</ul></li>
445<li><b>Details:</b><ul>
446<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-closed.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>
447<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>
448<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>
449<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>
450<li>Changed the following issues from NAD Future to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#388">388</a>.</li>
451<li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a>.</li>
452</ul></li>
453</ul>
454</li>
455<li>R53: 
4562007-12-09 mid-term mailing.
457<ul>
458<li><b>Summary:</b><ul>
459<li>183 open issues, up by 11.</li>
460<li>581 closed issues, down by 1.</li>
461<li>764 issues total, up by 10.</li>
462</ul></li>
463<li><b>Details:</b><ul>
464<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-closed.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>
465<li>Changed the following issues from NAD to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#463">463</a>.</li>
466<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>
467</ul></li>
468</ul>
469</li>
470<li>R52: 
4712007-10-19 post-Kona mailing.
472<ul>
473<li><b>Summary:</b><ul>
474<li>172 open issues, up by 4.</li>
475<li>582 closed issues, up by 27.</li>
476<li>754 issues total, up by 31.</li>
477</ul></li>
478<li><b>Details:</b><ul>
479<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-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-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-closed.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-closed.html#750">750</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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>
480<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>
481<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>
482<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>
483<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-defects.html#564">564</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#565">565</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#573">573</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#585">585</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-defects.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#632">632</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-defects.html#659">659</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-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-closed.html#708">708</a>.</li>
484<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>
485<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>
486<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-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-defects.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>
487<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>
488<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>
489<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>
490<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>
491<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>
492</ul></li>
493</ul>
494</li>
495<li>R51: 
4962007-09-09 pre-Kona mailing.
497<ul>
498<li><b>Summary:</b><ul>
499<li>168 open issues, up by 15.</li>
500<li>555 closed issues, up by 0.</li>
501<li>723 issues total, up by 15.</li>
502</ul></li>
503<li><b>Details:</b><ul>
504<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-defects.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-defects.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-closed.html#718">718</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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#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-defects.html#723">723</a>.</li>
505</ul></li>
506</ul>
507</li>
508<li>R50: 
5092007-08-05 post-Toronto mailing.
510<ul>
511<li><b>Summary:</b><ul>
512<li>153 open issues, down by 5.</li>
513<li>555 closed issues, up by 17.</li>
514<li>708 issues total, up by 12.</li>
515</ul></li>
516<li><b>Details:</b><ul>
517<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-closed.html#701">701</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.html#708">708</a>.</li>
518<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>
519<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>
520<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>
521<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>
522<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>
523<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>
524<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>
525<li>Changed the following issues from Ready to Pending WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#644">644</a>.</li>
526<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>
527<li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#488">488</a>.</li>
528<li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a>.</li>
529<li>Changed the following issues from Ready to TRDec: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#604">604</a>.</li>
530<li>Changed the following issues from DR to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#453">453</a>.</li>
531<li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#551">551</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#566">566</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#640">640</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#643">643</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#646">646</a>.</li>
532</ul></li>
533</ul>
534</li>
535<li>R49: 
5362007-06-23 pre-Toronto mailing.
537<ul>
538<li><b>Summary:</b><ul>
539<li>158 open issues, up by 13.</li>
540<li>538 closed issues, up by 7.</li>
541<li>696 issues total, up by 20.</li>
542</ul></li>
543<li><b>Details:</b><ul>
544<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-defects.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-defects.html#696">696</a>.</li>
545<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>
546<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>
547<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>
548<li>Changed the following issues from New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#636">636</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#642">642</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#648">648</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#649">649</a>.</li>
549</ul></li>
550</ul>
551</li>
552<li>R48: 
5532007-05-06 post-Oxford mailing.
554<ul>
555<li><b>Summary:</b><ul>
556<li>145 open issues, down by 33.</li>
557<li>531 closed issues, up by 53.</li>
558<li>676 issues total, up by 20.</li>
559</ul></li>
560<li><b>Details:</b><ul>
561<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-defects.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-closed.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-active.html#676">676</a>.</li>
562<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>
563<li>Changed the following issues from Tentatively Ready to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#385">385</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#466">466</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#470">470</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#547">547</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#560">560</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>.</li>
564<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>
565<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>
566<li>Changed the following issues from NAD_Future to NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#77">77</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#105">105</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#111">111</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#116">116</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#128">128</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-closed.html#190">190</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#219">219</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#353">353</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#388">388</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#390">390</a>.</li>
567<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>
568<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>
569<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-active.html#594">594</a>.</li>
570<li>Changed the following issues from Tentatively Ready to Pending WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#258">258</a>.</li>
571<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#566">566</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#640">640</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#643">643</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#644">644</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#646">646</a>.</li>
572<li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#551">551</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#604">604</a>.</li>
573<li>Changed the following issues from Ready to TRDec: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#598">598</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#599">599</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#600">600</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#601">601</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#602">602</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#603">603</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#605">605</a>.</li>
574<li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#543">543</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#545">545</a>.</li>
575<li>Changed the following issues from Tentatively Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#201">201</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#206">206</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#254">254</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#416">416</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#422">422</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#456">456</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#575">575</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#576">576</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#578">578</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#586">586</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#589">589</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#593">593</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#609">609</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#610">610</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#611">611</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#613">613</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#616">616</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#619">619</a>.</li>
576</ul></li>
577</ul>
578</li>
579<li>R47: 
5802007-03-09 pre-Oxford mailing.
581<ul>
582<li><b>Summary:</b><ul>
583<li>178 open issues, up by 37.</li>
584<li>478 closed issues, up by 0.</li>
585<li>656 issues total, up by 37.</li>
586</ul></li>
587<li><b>Details:</b><ul>
588<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-defects.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-closed.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-closed.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-closed.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>
589<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>
590<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-closed.html#580">580</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.html#614">614</a>.</li>
591<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-active.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>
592<li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#201">201</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#206">206</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#254">254</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#258">258</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#385">385</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#416">416</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#422">422</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#456">456</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#466">466</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#470">470</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#482">482</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>.</li>
593<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>
594</ul></li>
595</ul>
596</li>
597<li>R46: 
5982007-01-12 mid-term mailing.
599<ul>
600<li><b>Summary:</b><ul>
601<li>141 open issues, up by 11.</li>
602<li>478 closed issues, down by 1.</li>
603<li>619 issues total, up by 10.</li>
604</ul></li>
605<li><b>Details:</b><ul>
606<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-closed.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-closed.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>
607</ul></li>
608</ul>
609</li>
610<li>R45: 
6112006-11-03 post-Portland mailing.
612<ul>
613<li><b>Summary:</b><ul>
614<li>130 open issues, up by 0.</li>
615<li>479 closed issues, up by 17.</li>
616<li>609 issues total, up by 17.</li>
617</ul></li>
618<li><b>Details:</b><ul>
619<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>
620<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>
621<li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#569">569</a> to Dup.</li>
622<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-closed.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-closed.html#597">597</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#606">606</a> to Open.</li>
623<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>
624<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>
625<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-active.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-closed.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-closed.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>
626</ul></li>
627</ul>
628</li>
629<li>R44: 
6302006-09-08 pre-Portland mailing.
631<ul>
632<li><b>Summary:</b><ul>
633<li>130 open issues, up by 6.</li>
634<li>462 closed issues, down by 1.</li>
635<li>592 issues total, up by 5.</li>
636</ul></li>
637<li><b>Details:</b><ul>
638<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-closed.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-closed.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>
639</ul></li>
640</ul>
641</li>
642<li>R43: 
6432006-06-23 mid-term mailing.
644<ul>
645<li><b>Summary:</b><ul>
646<li>124 open issues, up by 14.</li>
647<li>463 closed issues, down by 1.</li>
648<li>587 issues total, up by 13.</li>
649</ul></li>
650<li><b>Details:</b><ul>
651<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-closed.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-closed.html#582">582</a>.</li>
652<li>Reopened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#255">255</a>.</li>
653<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>
654</ul></li>
655</ul>
656</li>
657<li>R42: 
6582006-04-21 post-Berlin mailing.
659<ul>
660<li><b>Summary:</b><ul>
661<li>110 open issues, down by 16.</li>
662<li>464 closed issues, up by 24.</li>
663<li>574 issues total, up by 8.</li>
664</ul></li>
665<li><b>Details:</b><ul>
666<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#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>
667<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>
668<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#502">502</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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>
669<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>
670<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>
671<li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a> to Review.</li>
672</ul></li>
673</ul>
674</li>
675<li>R41: 
6762006-02-24 pre-Berlin mailing.
677<ul>
678<li><b>Summary:</b><ul>
679<li>126 open issues, up by 31.</li>
680<li>440 closed issues, up by 0.</li>
681<li>566 issues total, up by 31.</li>
682</ul></li>
683<li><b>Details:</b><ul>
684<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-closed.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-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-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-defects.html#564">564</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#565">565</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#566">566</a>.</li>
685<li>Moved <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#342">342</a> from Ready to Open.</li>
686<li>Reopened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#309">309</a>.</li>
687</ul></li>
688</ul>
689</li>
690<li>R40: 
6912005-12-16 mid-term mailing.
692<ul>
693<li><b>Summary:</b><ul>
694<li>95 open issues.</li>
695<li>440 closed issues.</li>
696<li>535 issues total.</li>
697</ul></li>
698<li><b>Details:</b><ul>
699<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>
700</ul></li>
701</ul>
702</li>
703<li>R39: 
7042005-10-14 post-Mont Tremblant mailing.
705Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#528">528</a>.
706Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#280">280</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#461">461</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#464">464</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#465">465</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#467">467</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#468">468</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#474">474</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#496">496</a> from Ready to WP as per the vote from Mont Tremblant.
707Moved 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-closed.html#342">342</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#362">362</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#369">369</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#371">371</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#376">376</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#475">475</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#495">495</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#497">497</a> from Review to Ready.
708Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#498">498</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#506">506</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#509">509</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#510">510</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#511">511</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#513">513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#514">514</a> from New to Open.
709Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#505">505</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#507">507</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#508">508</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#519">519</a> from New to Ready.
710Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#500">500</a> from New to NAD.
711Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a> from New to Review.
712</li>
713<li>R38: 
7142005-07-03 pre-Mont Tremblant mailing.
715Merged 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>.
716Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#523">523</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#523">523</a>
717</li>
718<li>R37: 
7192005-06 mid-term mailing.
720Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#498">498</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#503">503</a>.
721</li>
722<li>R36: 
7232005-04 post-Lillehammer mailing. All issues in "ready" status except
724for <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
725previously in "DR" status were moved to "WP".
726</li>
727<li>R35: 
7282005-03 pre-Lillehammer mailing.
729</li>
730<li>R34: 
7312005-01 mid-term mailing.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#488">488</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#494">494</a>.
732</li>
733<li>R33: 
7342004-11 post-Redmond mailing. Reflects actions taken in Redmond.
735</li>
736<li>R32: 
7372004-09 pre-Redmond mailing: reflects new proposed resolutions and
738new issues received after the 2004-07 mailing.  Added
739new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#481">481</a>.
740</li>
741<li>R31: 
7422004-07 mid-term mailing: reflects new proposed resolutions and
743new issues received after the post-Sydney mailing.  Added
744new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#463">463</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>.
745</li>
746<li>R30: 
747Post-Sydney mailing: reflects decisions made at the Sydney meeting.
748Voted all "Ready" issues from R29 into the working paper.
749Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#460">460</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#462">462</a>.
750</li>
751<li>R29: 
752Pre-Sydney mailing.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#441">441</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#457">457</a>.
753</li>
754<li>R28: 
755Post-Kona mailing: reflects decisions made at the Kona meeting.
756Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#432">432</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#440">440</a>.
757</li>
758<li>R27: 
759Pre-Kona mailing.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#404">404</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#431">431</a>.
760</li>
761<li>R26: 
762Post-Oxford mailing: reflects decisions made at the Oxford meeting.
763All issues in Ready status were voted into DR status.  All issues in
764DR status were voted into WP status.
765</li>
766<li>R25: 
767Pre-Oxford mailing.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#390">390</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#402">402</a>.
768</li>
769<li>R24: 
770Post-Santa Cruz mailing: reflects decisions made at the Santa Cruz
771meeting.  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
772moved 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
773at 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
774concerns with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a> involve wording.
775</li>
776<li>R23: 
777Pre-Santa Cruz mailing.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#367">367</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#382">382</a>.
778Moved issues in the TC to TC status.
779</li>
780<li>R22: 
781Post-Cura�ao mailing.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#362">362</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#366">366</a>.
782</li>
783<li>R21: 
784Pre-Cura�ao mailing.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#351">351</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#361">361</a>.
785</li>
786<li>R20: 
787Post-Redmond mailing; reflects actions taken in Redmond.  Added
788new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#336">336</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a>, of which issues 
789<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#347">347</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a> were added since Redmond, hence
790not discussed at the meeting.  
791
792All Ready issues were moved to DR status, with the exception of issues
793<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#284">284</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#241">241</a>, and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#267">267</a>.
794
795Noteworthy issues discussed at Redmond include 
796<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#120">120</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#202">202</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a>, 
797<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#270">270</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#253">253</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#254">254</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>.
798</li>
799<li>R19: 
800Pre-Redmond mailing.  Added new issues 
801<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#335">335</a>.
802</li>
803<li>R18: 
804Post-Copenhagen mailing; reflects actions taken in Copenhagen.
805Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#312">312</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#317">317</a>, and discussed
806new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#271">271</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#314">314</a>.
807
808Changed status of issues
809<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#103">103</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#118">118</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#136">136</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#153">153</a>
810<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#165">165</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#171">171</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#183">183</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#184">184</a>
811<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#185">185</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#186">186</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#214">214</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#221">221</a>
812<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#234">234</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#237">237</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#243">243</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#248">248</a>
813<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#251">251</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#252">252</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#256">256</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#260">260</a>
814<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#261">261</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#262">262</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#263">263</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#265">265</a>
815<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#268">268</a>
816to DR.
817
818Changed status of issues
819<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#49">49</a>  <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#109">109</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#117">117</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#182">182</a>
820<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#228">228</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#230">230</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#232">232</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#235">235</a>
821<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#238">238</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#241">241</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#242">242</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#250">250</a>
822<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#259">259</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#264">264</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#266">266</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#267">267</a>
823<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#271">271</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#272">272</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#273">273</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#275">275</a>
824<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#281">281</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#284">284</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#285">285</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#286">286</a>
825<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#288">288</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#292">292</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#295">295</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#297">297</a>
826<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#298">298</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#301">301</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#303">303</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#306">306</a>
827<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#307">307</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#308">308</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#312">312</a>
828to Ready.
829
830Closed issues 
831<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>
832<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>
833<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#314">314</a>
834as NAD.
835
836</li>
837<li>R17: 
838Pre-Copenhagen mailing.  Converted issues list to XML.  Added proposed
839resolutions for issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#49">49</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#76">76</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#91">91</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#235">235</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#250">250</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#267">267</a>.
840Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#278">278</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#311">311</a>.
841</li>
842<li>R16:  
843post-Toronto mailing; reflects actions taken in Toronto. Added new
844issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#265">265</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#277">277</a>.  Changed status of issues
845<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#3">3</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#8">8</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#9">9</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#19">19</a>,
846<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#26">26</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#31">31</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#61">61</a>,
847<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#63">63</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#86">86</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#108">108</a>,
848<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>,
849<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#122">122</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#127">127</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#129">129</a>,
850<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#134">134</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#137">137</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#142">142</a>,
851<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>,
852<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#159">159</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#164">164</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#170">170</a>,
853<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#181">181</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#199">199</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#208">208</a>,
854<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>,
855<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>,
856<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>,
857<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
858issue <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
859<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
860issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#70">70</a>: signature should be changed both places it
861appears. Fixed issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#160">160</a>: previous version didn't fix
862the bug in enough places.
863</li>
864<li>R15: 
865pre-Toronto mailing. Added issues
866<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#264">264</a>. Some small HTML formatting
867changes so that we pass Weblint tests.
868</li>
869<li>R14: 
870post-Tokyo II mailing; reflects committee actions taken in
871Tokyo. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#228">228</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#232">232</a>. (00-0019R1/N1242)
872</li>
873<li>R13: 
874pre-Tokyo II updated: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#212">212</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#227">227</a>.
875</li>
876<li>R12: 
877pre-Tokyo II mailing: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#199">199</a> to
878<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#211">211</a>. Added "and paragraph 5" to the proposed resolution
879of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#29">29</a>.  Add further rationale to issue
880<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#178">178</a>.
881</li>
882<li>R11: 
883post-Kona mailing: Updated to reflect LWG and full committee actions
884in Kona (99-0048/N1224). Note changed resolution of issues
885<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#4">4</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#38">38</a>. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#196">196</a>
886to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#198">198</a>. Closed issues list split into "defects" and
887"closed" documents.  Changed the proposed resolution of issue
888<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#4">4</a> to NAD, and changed the wording of proposed resolution
889of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#38">38</a>.
890</li>
891<li>R10: 
892pre-Kona updated.  Added proposed resolutions <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>,
893<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#86">86</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#91">91</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#92">92</a>,
894<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#109">109</a>. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#190">190</a> to
895<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a>. (99-0033/D1209, 14 Oct 99)
896</li>
897<li>R9: 
898pre-Kona mailing.  Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a> to
899<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#189">189</a>. Issues list split into separate "active" and
900"closed" documents. (99-0030/N1206, 25 Aug 99)
901</li>
902<li>R8: 
903post-Dublin mailing. Updated to reflect LWG and full committee actions
904in Dublin. (99-0016/N1193, 21 Apr 99)
905</li>
906<li>R7: 
907pre-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>,
908<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>,
909<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>,
910<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)
911</li>
912<li>R6: 
913pre-Dublin mailing. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#127">127</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#128">128</a>,
914and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#129">129</a>.  (99-0007/N1194, 22 Feb 99)
915</li>
916<li>R5: 
917update issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#103">103</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#112">112</a>; added issues
918<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#114">114</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#126">126</a>. Format revisions to prepare
919for making list public. (30 Dec 98)
920</li>
921<li>R4: 
922post-Santa Cruz II updated: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#110">110</a>,
923<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
924issues corrected. (22 Oct 98)
925</li>
926<li>R3: 
927post-Santa Cruz II: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#94">94</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#109">109</a>
928added, many issues updated to reflect LWG consensus (12 Oct 98)
929</li>
930<li>R2: 
931pre-Santa Cruz II: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#73">73</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#93">93</a> added,
932issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#17">17</a> updated. (29 Sep 98)
933</li>
934<li>R1: 
935Correction to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#55">55</a> resolution, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</a> code
936format, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64">64</a> title. (17 Sep 98)
937</li>
938</ul>
939
940<h2>Defect Reports</h2>
941<hr>
942<h3><a name="1"></a>1. C library linkage editing oversight</h3>
943<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>
944 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 1997-11-16  <b>Last modified:</b> 2008-09-26</p>
945<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>
946<p><b>Discussion:</b></p>
947<p>The change specified in the proposed resolution below did not make
948it into the Standard. This change was accepted in principle at the
949London meeting, and the exact wording below was accepted at the
950Morristown meeting.</p>
951
952
953<p><b>Proposed resolution:</b></p>
954<p>Change 17.6.2.3 [using.linkage] paragraph 2
955from:</p>
956
957<blockquote>
958  <p>It is unspecified whether a name from the Standard C library
959  declared with external linkage has either extern "C" or
960  extern "C++" linkage.</p>
961</blockquote>
962
963<p>to:</p>
964
965<blockquote>
966  <p>Whether a name from the Standard C library declared with external
967  linkage has extern "C" or extern "C++" linkage
968  is implementation defined. It is recommended that an implementation
969  use extern "C++" linkage for this purpose.</p>
970</blockquote>
971
972
973
974
975
976<hr>
977<h3><a name="3"></a>3. Atexit registration during atexit() call is not described</h3>
978<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>
979 <b>Submitter:</b> Steve Clamage <b>Opened:</b> 1997-12-12  <b>Last modified:</b> 2008-09-26</p>
980<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>
981<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>
982<p><b>Discussion:</b></p>
983<p>We appear not to have covered all the possibilities of
984 exit processing with respect to
985atexit registration. <br>
986<br>
987Example 1: (C and C++)</p>
988
989<pre>    #include &lt;stdlib.h&gt;
990    void f1() { }
991    void f2() { atexit(f1); }
992    
993    int main()
994    {
995        atexit(f2); // the only use of f2
996        return 0; // for C compatibility
997    }</pre>
998
999<p>At program exit, f2 gets called due to its registration in
1000main. Running f2 causes f1 to be newly registered during the exit
1001processing. Is this a valid program? If so, what are its
1002semantics?</p>
1003
1004<p>
1005Interestingly, neither the C standard, nor the C++ draft standard nor
1006the forthcoming C9X Committee Draft says directly whether you can
1007register a function with atexit during exit processing.</p>
1008
1009<p>
1010All 3 standards say that functions are run in reverse order of their
1011registration. Since f1 is registered last, it ought to be run first,
1012but by the time it is registered, it is too late to be first.</p>
1013
1014<p>If the program is valid, the standards are self-contradictory about
1015its semantics.</p>
1016
1017<p>Example 2: (C++ only)</p>
1018
1019<pre>    
1020    void F() { static T t; } // type T has a destructor
1021
1022    int main()
1023    {
1024        atexit(F); // the only use of F
1025    }
1026</pre>
1027
1028<p>Function F registered with atexit has a local static variable t,
1029and F is called for the first time during exit processing. A local
1030static object is initialized the first time control flow passes
1031through its definition, and all static objects are destroyed during
1032exit processing. Is the code valid? If so, what are its semantics?</p>
1033
1034<p>
1035Section 18.3 "Start and termination" says that if a function
1036F is registered with atexit before a static object t is initialized, F
1037will not be called until after t's destructor completes.</p>
1038
1039<p>
1040In example 2, function F is registered with atexit before its local
1041static object O could possibly be initialized. On that basis, it must
1042not be called by exit processing until after O's destructor
1043completes. But the destructor cannot be run until after F is called,
1044since otherwise the object could not be constructed in the first
1045place.</p>
1046
1047<p>If the program is valid, the standard is self-contradictory about
1048its semantics.</p>
1049
1050<p>I plan to submit Example 1 as a public comment on the C9X CD, with
1051a recommendation that the results be undefined. (Alternative: make it
1052unspecified. I don't think it is worthwhile to specify the case where
1053f1 itself registers additional functions, each of which registers
1054still more functions.)</p>
1055
1056<p>I think we should resolve the situation in the whatever way the C
1057committee decides. </p>
1058
1059<p>For Example 2, I recommend we declare the results undefined.</p>
1060
1061<p><i>[See reflector message lib-6500 for further discussion.]</i></p>
1062
1063
1064
1065
1066<p><b>Proposed resolution:</b></p>
1067<p>Change section 18.3/8 from:</p>
1068<blockquote><p>
1069  First, objects with static storage duration are destroyed and
1070  functions registered by calling atexit are called. Objects with
1071  static storage duration are destroyed in the reverse order of the
1072  completion of their constructor.  (Automatic objects are not
1073  destroyed as a result of calling exit().) Functions registered with
1074  atexit are called in the reverse order of their registration.  A
1075  function registered with atexit before an object obj1 of static
1076  storage duration is initialized will not be called until obj1's
1077  destruction has completed. A function registered with atexit after
1078  an object obj2 of static storage duration is initialized will be
1079  called before obj2's destruction starts.
1080</p></blockquote>
1081<p>to:</p>
1082<blockquote><p>
1083  First, objects with static storage duration are destroyed and
1084  functions registered by calling atexit are called. Non-local objects
1085  with static storage duration are destroyed in the reverse order of
1086  the completion of their constructor. (Automatic objects are not
1087  destroyed as a result of calling exit().) Functions registered with
1088  atexit are called in the reverse order of their registration, except
1089  that a function is called after any previously registered functions
1090  that had already been called at the time it was registered. A
1091  function registered with atexit before a non-local object obj1 of
1092  static storage duration is initialized will not be called until
1093  obj1's destruction has completed. A function registered with atexit
1094  after a non-local object obj2 of static storage duration is
1095  initialized will be called before obj2's destruction starts. A local
1096  static object obj3 is destroyed at the same time it would be if a
1097  function calling the obj3 destructor were registered with atexit at
1098  the completion of the obj3 constructor.
1099</p></blockquote>
1100
1101
1102<p><b>Rationale:</b></p>
1103<p>See 99-0039/N1215, October 22, 1999, by Stephen D. Clamage for the analysis
1104supporting to the proposed resolution.</p>
1105
1106
1107
1108
1109
1110<hr>
1111<h3><a name="5"></a>5. String::compare specification questionable</h3>
1112<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>
1113 <b>Submitter:</b> Jack Reeves <b>Opened:</b> 1997-12-11  <b>Last modified:</b> 2008-09-26</p>
1114<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>
1115<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>
1116<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#87">87</a></p>
1117<p><b>Discussion:</b></p>
1118<p>At the very end of the basic_string class definition is the signature: int
1119compare(size_type pos1, size_type n1, const charT* s, size_type n2 = npos) const; In the
1120following text this is defined as: returns
1121basic_string&lt;charT,traits,Allocator&gt;(*this,pos1,n1).compare(
1122basic_string&lt;charT,traits,Allocator&gt;(s,n2); </p>
1123
1124<p>Since the constructor basic_string(const charT* s, size_type n, const Allocator&amp; a
1125= Allocator()) clearly requires that s != NULL and n &lt; npos and further states that it
1126throws length_error if n == npos, it appears the compare() signature above should always
1127throw length error if invoked like so: str.compare(1, str.size()-1, s); where 's' is some
1128null terminated character array. </p>
1129
1130<p>This appears to be a typo since the obvious intent is to allow either the call above or
1131something like: str.compare(1, str.size()-1, s, strlen(s)-1); </p>
1132
1133<p>This would imply that what was really intended was two signatures int compare(size_type
1134pos1, size_type n1, const charT* s) const int compare(size_type pos1, size_type n1, const
1135charT* s, size_type n2) const; each defined in terms of the corresponding constructor. </p>
1136
1137
1138<p><b>Proposed resolution:</b></p>
1139<p>Replace the compare signature in 21.4 [basic.string]
1140(at the very end of the basic_string synopsis) which reads:</p>
1141
1142<blockquote>
1143  <p><tt>int compare(size_type pos1, size_type n1,<br>
1144  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; const charT* s,
1145  size_type n2 = npos) const;</tt></p>
1146</blockquote>
1147
1148<p>with:</p>
1149
1150<blockquote>
1151  <p><tt>int compare(size_type pos1, size_type n1,<br>
1152  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; const charT* s) const;<br>
1153  int compare(size_type pos1, size_type n1,<br>
1154  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; const charT* s,
1155  size_type n2) const;</tt></p>
1156</blockquote>
1157
1158<p>Replace the portion of 21.4.6.8 [string::swap]
1159paragraphs 5 and 6 which read:</p>
1160
1161<blockquote>
1162  <p><tt>int compare(size_type pos, size_type n1,<br>
1163  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; charT * s, size_type n2
1164  = npos) const;<br>
1165  </tt>Returns:<tt><br>
1166  basic_string&lt;charT,traits,Allocator&gt;(*this, pos, n1).compare(<br>
1167  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
1168  basic_string&lt;charT,traits,Allocator&gt;( s, n2))</tt></p>
1169</blockquote>
1170
1171<p>with:</p>
1172
1173<blockquote>
1174  <p><tt>int compare(size_type pos, size_type n1,<br>
1175  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; const charT * s) const;<br>
1176  </tt>Returns:<tt><br>
1177  basic_string&lt;charT,traits,Allocator&gt;(*this, pos, n1).compare(<br>
1178  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
1179  basic_string&lt;charT,traits,Allocator&gt;( s ))<br>
1180  <br>
1181  int compare(size_type pos, size_type n1,<br>
1182  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; const charT * s,
1183  size_type n2) const;<br>
1184  </tt>Returns:<tt><br>
1185  basic_string&lt;charT,traits,Allocator&gt;(*this, pos, n1).compare(<br>
1186  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
1187  basic_string&lt;charT,traits,Allocator&gt;( s, n2))</tt></p>
1188</blockquote>
1189
1190<p>Editors please note that in addition to splitting the signature, the third argument
1191becomes const, matching the existing synopsis.</p>
1192
1193
1194<p><b>Rationale:</b></p>
1195<p>While the LWG dislikes adding signatures, this is a clear defect in
1196the Standard which must be fixed.&nbsp; The same problem was also
1197identified in issues 7 (item 5) and 87.</p>
1198
1199
1200
1201
1202
1203<hr>
1204<h3><a name="7"></a>7. String clause minor problems</h3>
1205<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>
1206 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1997-12-15  <b>Last modified:</b> 2008-09-26</p>
1207<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>
1208<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>
1209<p><b>Discussion:</b></p>
1210<p>(1) In 21.4.6.4 [string::insert], the description of template
1211&lt;class InputIterator&gt; insert(iterator, InputIterator,
1212InputIterator) makes no sense. It refers to a member function that
1213doesn't exist. It also talks about the return value of a void
1214function. </p>
1215
1216<p>(2) Several versions of basic_string::replace don't appear in the
1217class synopsis. </p>
1218
1219<p>(3) basic_string::push_back appears in the synopsis, but is never
1220described elsewhere.  In the synopsis its argument is const charT,
1221which doesn't makes much sense; it should probably be charT, or
1222possible const charT&amp;. </p>
1223
1224<p>(4) basic_string::pop_back is missing. </p>
1225
1226<p>(5) int compare(size_type pos, size_type n1, charT* s, size_type n2
1227= npos) make no sense. First, it's const charT* in the synopsis and
1228charT* in the description. Second, given what it says in RETURNS,
1229leaving out the final argument will always result in an exception
1230getting thrown. This is paragraphs 5 and 6 of 
123121.4.6.8 [string::swap]</p>
1232
1233<p>(6) In table 37, in section 21.2.1 [char.traits.require],
1234there's a note for X::move(s, p, n). It says "Copies correctly
1235even where p is in [s, s+n)". This is correct as far as it goes,
1236but it doesn't go far enough; it should also guarantee that the copy
1237is correct even where s in in [p, p+n). These are two orthogonal
1238guarantees, and neither one follows from the other. Both guarantees
1239are necessary if X::move is supposed to have the same sort of
1240semantics as memmove (which was clearly the intent), and both
1241guarantees are necessary if X::move is actually supposed to be
1242useful. </p>
1243
1244
1245<p><b>Proposed resolution:</b></p>
1246<p>ITEM 1: In 21.3.5.4 [lib.string::insert], change paragraph 16 to <br>
1247<br>
1248&nbsp;&nbsp;&nbsp; EFFECTS: Equivalent to insert(p - begin(), basic_string(first, last)).<br>
1249<br>
1250ITEM 2:&nbsp; Not a defect; the Standard is clear.. There are ten versions of replace() in
1251the synopsis, and ten versions in 21.3.5.6 [lib.string::replace].<br>
1252<br>
1253ITEM 3: Change the declaration of push_back in the string synopsis (21.3,
1254[lib.basic.string]) from:</p>
1255
1256<p>&nbsp;&nbsp;&nbsp;&nbsp; void push_back(const charT)<br>
1257<br>
1258to<br>
1259<br>
1260&nbsp;&nbsp;&nbsp;&nbsp; void push_back(charT)<br>
1261<br>
1262Add the following text immediately after 21.3.5.2 [lib.string::append], paragraph 10.<br>
1263<br>
1264&nbsp;&nbsp;&nbsp; void basic_string::push_back(charT c);<br>
1265&nbsp;&nbsp;&nbsp; EFFECTS: Equivalent to append(static_cast&lt;size_type&gt;(1), c);<br>
1266<br>
1267ITEM 4: Not a defect. The omission appears to have been deliberate.<br>
1268<br>
1269ITEM 5: Duplicate; see issue 5 (and 87).<br>
1270<br>
1271ITEM 6: In table 37, Replace:<br>
1272<br>
1273&nbsp;&nbsp;&nbsp; "Copies correctly even where p is in [s, s+n)."<br>
1274<br>
1275with:<br>
1276<br>
1277&nbsp;&nbsp;&nbsp;&nbsp; "Copies correctly even where the ranges [p, p+n) and [s,
1278s+n) overlap."</p>
1279
1280
1281
1282
1283
1284<hr>
1285<h3><a name="8"></a>8. Locale::global lacks guarantee</h3>
1286<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>
1287 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1997-12-24  <b>Last modified:</b> 2008-09-26</p>
1288<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>
1289<p><b>Discussion:</b></p>
1290<p>It appears there's an important guarantee missing from clause
129122. We're told that invoking locale::global(L) sets the C locale if L
1292has a name. However, we're not told whether or not invoking
1293setlocale(s) sets the global C++ locale. </p>
1294
1295<p>The intent, I think, is that it should not, but I can't find any
1296such words anywhere. </p>
1297
1298
1299<p><b>Proposed resolution:</b></p>
1300<p>Add a sentence at the end of 22.3.1.5 [locale.statics],
1301paragraph 2:&nbsp; </p>
1302
1303<blockquote>
1304  <p>No library function other than <tt>locale::global()</tt> shall affect 
1305  the value returned by <tt>locale()</tt>. </p>
1306
1307</blockquote>
1308
1309
1310
1311
1312
1313<hr>
1314<h3><a name="9"></a>9. Operator new(0) calls should not yield the same pointer</h3>
1315<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>
1316 <b>Submitter:</b> Steve Clamage <b>Opened:</b> 1998-01-04  <b>Last modified:</b> 2008-09-26</p>
1317<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>
1318<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>
1319<p><b>Discussion:</b></p>
1320<p>Scott Meyers, in a comp.std.c++ posting: I just noticed that
1321section 3.7.3.1 of CD2 seems to allow for the possibility that all
1322calls to operator new(0) yield the same pointer, an implementation
1323technique specifically prohibited by ARM 5.3.3.Was this prohibition
1324really lifted? Does the FDIS agree with CD2 in the regard? [Issues
1325list maintainer's note: the IS is the same.]</p>
1326
1327
1328<p><b>Proposed resolution:</b></p>
1329<p>Change the last paragraph of 3.7.3 from:</p>
1330<blockquote>
1331  <p>Any allocation and/or deallocation functions defined in a C++ program shall
1332  conform to the semantics specified in 3.7.3.1 and 3.7.3.2.</p>
1333</blockquote>
1334<p>to:</p>
1335<blockquote>
1336  <p>Any allocation and/or deallocation functions defined in a C++ program,
1337  including the default versions in the library, shall conform to the semantics
1338  specified in 3.7.3.1 and 3.7.3.2.</p>
1339</blockquote>
1340<p>Change 3.7.3.1/2, next-to-last sentence, from :</p>
1341<blockquote>
1342  <p>If the size of the space requested is zero, the value returned shall not be
1343  a null pointer value (4.10).</p>
1344</blockquote>
1345<p>to:</p>
1346<blockquote>
1347  <p>Even if the size of the space requested is zero, the request can fail. If
1348  the request succeeds, the value returned shall be a non-null pointer value
1349  (4.10) p0 different from any previously returned value p1, unless that value
1350  p1 was since passed to an operator delete.</p>
1351</blockquote>
1352<p>5.3.4/7 currently reads:</p>
1353<blockquote>
1354  <p>When the value of the expression in a direct-new-declarator is zero, the
1355  allocation function is called to allocate an array with no elements. The
1356  pointer returned by the new-expression is non-null. [Note: If the library
1357  allocation function is called, the pointer returned is distinct from the
1358  pointer to any other object.]</p>
1359</blockquote>
1360<p>Retain the first sentence, and delete the remainder.</p>
1361<p>18.5.1 currently has no text. Add the following:</p>
1362<blockquote>
1363  <p>Except where otherwise specified, the provisions of 3.7.3 apply to the
1364  library versions of operator new and operator delete.</p>
1365</blockquote>
1366<p>To 18.5.1.3, add the following text:</p>
1367<blockquote>
1368  <p>The provisions of 3.7.3 do not apply to these reserved placement forms of
1369  operator new and operator delete.</p>
1370</blockquote>
1371
1372
1373<p><b>Rationale:</b></p>
1374<p>See 99-0040/N1216, October 22, 1999, by Stephen D. Clamage for the analysis
1375supporting to the proposed resolution.</p>
1376
1377
1378
1379
1380
1381<hr>
1382<h3><a name="11"></a>11. Bitset minor problems</h3>
1383<p><b>Section:</b> 20.3.7 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
1384 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-01-22  <b>Last modified:</b> 2008-09-26</p>
1385<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>
1386<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>
1387<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>
1388<p><b>Discussion:</b></p>
1389<p>(1) bitset&lt;&gt;::operator[] is mentioned in the class synopsis (23.3.5), but it is
1390not documented in 23.3.5.2. </p>
1391
1392<p>(2) The class synopsis only gives a single signature for bitset&lt;&gt;::operator[],
1393reference operator[](size_t pos). This doesn't make much sense. It ought to be overloaded
1394on const. reference operator[](size_t pos); bool operator[](size_t pos) const. </p>
1395
1396<p>(3) Bitset's stream input function (23.3.5.3) ought to skip all whitespace before
1397trying to extract 0s and 1s. The standard doesn't explicitly say that, though. This should
1398go in the Effects clause.</p>
1399
1400
1401<p><b>Proposed resolution:</b></p>
1402<p>ITEMS 1 AND 2:<br>
1403<br>
1404In the bitset synopsis (20.3.7 [template.bitset]), 
1405replace the member function <br>
1406<br>
1407<tt>&nbsp;&nbsp;&nbsp; reference operator[](size_t pos);<br>
1408</tt><br>
1409with the two member functions<br>
1410<br>
1411<tt>&nbsp;&nbsp;&nbsp; bool operator[](size_t pos) const; <br>
1412&nbsp;&nbsp;&nbsp; reference operator[](size_t pos); <br>
1413</tt><br>
1414Add the following text at the end of 20.3.7.2 [bitset.members], 
1415immediately after paragraph 45:</p>
1416
1417<blockquote>
1418  <p><tt>bool operator[](size_t pos) const;</tt><br>
1419  Requires: pos is valid<br>
1420  Throws: nothing<br>
1421  Returns: <tt>test(pos)</tt><br>
1422  <br>
1423  <tt>bitset&lt;N&gt;::reference operator[](size_t pos);</tt> <br>
1424  Requires: pos is valid<br>
1425  Throws: nothing<br>
1426  Returns: An object of type <tt>bitset&lt;N&gt;::reference</tt> such that <tt>(*this)[pos]
1427  == this-&gt;test(pos)</tt>, and such that <tt>(*this)[pos] = val</tt> is equivalent to <tt>this-&gt;set(pos,
1428  val);</tt></p>
1429</blockquote>
1430
1431
1432<p><b>Rationale:</b></p>
1433<p>The LWG believes Item 3 is not a defect. "Formatted
1434input" implies the desired semantics. See 27.7.1.2 [istream.formatted].
1435</p>
1436
1437
1438
1439
1440
1441<hr>
1442<h3><a name="13"></a>13. Eos refuses to die</h3>
1443<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>
1444 <b>Submitter:</b> William M. Miller <b>Opened:</b> 1998-03-03  <b>Last modified:</b> 2008-09-26</p>
1445<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>
1446<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>
1447<p><b>Discussion:</b></p>
1448<p>In 27.6.1.2.3, there is a reference to "eos", which is
1449the only one in the whole draft (at least using Acrobat search), so
1450it's undefined. </p>
1451
1452
1453<p><b>Proposed resolution:</b></p>
1454<p>In 27.7.1.2.3 [istream::extractors], replace "eos" with
1455"charT()"</p>
1456
1457
1458
1459
1460
1461<hr>
1462<h3><a name="14"></a>14. Locale::combine should be const</h3>
1463<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>
1464 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06  <b>Last modified:</b> 2008-09-26</p>
1465<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>
1466<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>
1467<p><b>Discussion:</b></p>
1468<p>locale::combine is the only member function of locale (other than constructors and
1469destructor) that is not const. There is no reason for it not to be const, and good reasons
1470why it should have been const. Furthermore, leaving it non-const conflicts with 22.1.1
1471paragraph 6: "An instance of a locale is immutable." </p>
1472
1473<p>History: this member function originally was a constructor. it happened that the
1474interface it specified had no corresponding language syntax, so it was changed to a member
1475function. As constructors are never const, there was no "const" in the interface
1476which was transformed into member "combine". It should have been added at that
1477time, but the omission was not noticed. </p>
1478
1479
1480<p><b>Proposed resolution:</b></p>
1481<p>In 22.3.1 [locale] and also in 22.3.1.3 [locale.members], add 
1482"const" to the declaration of member combine: </p>
1483<blockquote>
1484  <pre>template &lt;class Facet&gt; locale combine(const locale&amp; other) const; </pre>
1485</blockquote>
1486
1487
1488
1489
1490
1491<hr>
1492<h3><a name="15"></a>15. Locale::name requirement inconsistent</h3>
1493<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>
1494 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06  <b>Last modified:</b> 2008-09-26</p>
1495<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>
1496<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>
1497<p><b>Discussion:</b></p>
1498<p>locale::name() is described as returning a string that can be passed to a locale
1499constructor, but there is no matching constructor. </p>
1500
1501
1502<p><b>Proposed resolution:</b></p>
1503<p>In 22.3.1.3 [locale.members], paragraph 5, replace
1504"<tt>locale(name())</tt>" with
1505"<tt>locale(name().c_str())</tt>".
1506</p>
1507
1508
1509
1510
1511
1512<hr>
1513<h3><a name="16"></a>16. Bad ctype_byname&lt;char&gt; decl</h3>
1514<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>
1515 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06  <b>Last modified:</b> 2008-09-26</p>
1516<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>
1517<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>
1518<p><b>Discussion:</b></p>
1519<p>The new virtual members ctype_byname&lt;char&gt;::do_widen and do_narrow did not get
1520edited in properly. Instead, the member do_widen appears four times, with wrong argument
1521lists. </p>
1522
1523
1524<p><b>Proposed resolution:</b></p>
1525<p>The correct declarations for the overloaded members
1526<tt>do_narrow</tt> and <tt>do_widen</tt> should be copied 
1527from 22.4.1.3 [facet.ctype.special].</p>
1528
1529
1530
1531
1532
1533<hr>
1534<h3><a name="17"></a>17. Bad bool parsing</h3>
1535<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>
1536 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06  <b>Last modified:</b> 2008-09-26</p>
1537<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>
1538<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>
1539<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>
1540<p><b>Discussion:</b></p>
1541<p>This section describes the process of parsing a text boolean value from the input
1542stream. It does not say it recognizes either of the sequences "true" or
1543"false" and returns the corresponding bool value; instead, it says it recognizes
1544only one of those sequences, and chooses which according to the received value of a
1545reference argument intended for returning the result, and reports an error if the other
1546sequence is found. (!) Furthermore, it claims to get the names from the ctype&lt;&gt;
1547facet rather than the numpunct&lt;&gt; facet, and it examines the "boolalpha"
1548flag wrongly; it doesn't define the value "loc"; and finally, it computes
1549wrongly whether to use numeric or "alpha" parsing.<br>
1550<br>
1551I believe the correct algorithm is "as if": </p>
1552
1553<pre>  // in, err, val, and str are arguments.
1554  err = 0;
1555  const numpunct&lt;charT&gt;&amp; np = use_facet&lt;numpunct&lt;charT&gt; &gt;(str.getloc());
1556  const string_type t = np.truename(), f = np.falsename();
1557  bool tm = true, fm = true;
1558  size_t pos = 0;
1559  while (tm &amp;&amp; pos &lt; t.size() || fm &amp;&amp; pos &lt; f.size()) {
1560    if (in == end) { err = str.eofbit; }
1561    bool matched = false;
1562    if (tm &amp;&amp; pos &lt; t.size()) {
1563      if (!err &amp;&amp; t[pos] == *in) matched = true;
1564      else tm = false;
1565    }
1566    if (fm &amp;&amp; pos &lt; f.size()) {
1567      if (!err &amp;&amp; f[pos] == *in) matched = true;
1568      else fm = false;
1569    }
1570    if (matched) { ++in; ++pos; }
1571    if (pos &gt; t.size()) tm = false;
1572    if (pos &gt; f.size()) fm = false;
1573  }
1574  if (tm == fm || pos == 0) { err |= str.failbit; }
1575  else                      { val = tm; }
1576  return in;</pre>
1577
1578<p>Notice this works reasonably when the candidate strings are both empty, or equal, or
1579when one is a substring of the other. The proposed text below captures the logic of the
1580code above.</p>
1581
1582
1583<p><b>Proposed resolution:</b></p>
1584<p>In 22.4.2.1.2 [facet.num.get.virtuals], in the first line of paragraph 14,
1585change "&amp;&amp;" to "&amp;".</p>
1586
1587<p>Then, replace paragraphs 15 and 16 as follows:</p>
1588
1589<blockquote>
1590
1591  <p>Otherwise target sequences are determined "as if" by
1592  calling the members <tt>falsename()</tt> and
1593  <tt>truename()</tt> of the facet obtained by
1594  <tt>use_facet&lt;numpunct&lt;charT&gt;&nbsp;&gt;(str.getloc())</tt>.  
1595  Successive characters in the range <tt>[in,end)</tt> (see
1596  [lib.sequence.reqmts]) are obtained and matched against
1597  corresponding positions in the target sequences only as necessary to
1598  identify a unique match. The input iterator <tt>in</tt> is
1599  compared to <tt>end</tt> only when necessary to obtain a
1600  character. If and only if a target sequence is uniquely matched,
1601  <tt>val</tt> is set to the corresponding value.</p>
1602
1603</blockquote>
1604
1605<blockquote>
1606  <p>The <tt>in</tt> iterator is always left pointing one position beyond the last character
1607  successfully matched. If <tt>val</tt> is set, then err is set to <tt>str.goodbit</tt>; or to
1608  <tt>str.eofbit</tt> if, when seeking another character to match, it is found that
1609  <tt>(in==end)</tt>. If <tt>val</tt> is not set, then <i>err</i> is set to <tt>str.failbit</tt>; or to
1610  <tt>(str.failbit|str.eofbit)</tt>if
1611  the reason for the failure was that <tt>(in==end)</tt>. [Example: for targets
1612  <tt>true</tt>:"a" and <tt>false</tt>:"abb", the input sequence "a" yields
1613  <tt>val==true</tt> and <tt>err==str.eofbit</tt>; the input sequence "abc" yields
1614  <tt>err=str.failbit</tt>, with <tt>in</tt> ending at the 'c' element. For targets
1615  <tt>true</tt>:"1"
1616  and <tt>false</tt>:"0", the input sequence "1" yields <tt>val==true</tt>
1617  and <tt>err=str.goodbit</tt>. For empty targets (""), any input sequence yields
1618  <tt>err==str.failbit</tt>. --end example]</p>
1619</blockquote>
1620
1621
1622
1623
1624
1625<hr>
1626<h3><a name="18"></a>18. Get(...bool&amp;) omitted</h3>
1627<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>
1628 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06  <b>Last modified:</b> 2008-09-26</p>
1629<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>
1630<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>
1631<p><b>Discussion:</b></p>
1632<p>In the list of num_get&lt;&gt; non-virtual members on page 22-23, the member
1633that parses bool values was omitted from the list of definitions of non-virtual
1634members, though it is listed in the class definition and the corresponding
1635virtual is listed everywhere appropriate. </p>
1636
1637
1638<p><b>Proposed resolution:</b></p>
1639<p>Add at the beginning of 22.4.2.1.1 [facet.num.get.members]
1640another get member for bool&amp;, copied from the entry in 
164122.4.2.1 [locale.num.get].</p>
1642
1643
1644
1645
1646
1647<hr>
1648<h3><a name="19"></a>19. "Noconv" definition too vague</h3>
1649<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>
1650 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06  <b>Last modified:</b> 2008-09-26</p>
1651<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>
1652<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>
1653<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#10">10</a></p>
1654<p><b>Discussion:</b></p>
1655<p>
1656In the definitions of codecvt&lt;&gt;::do_out and do_in, they are
1657specified to return noconv if "no conversion is
1658needed". This definition is too vague, and does not say
1659normatively what is done with the buffers.
1660</p>
1661
1662
1663<p><b>Proposed resolution:</b></p>
1664<p>
1665Change the entry for noconv in the table under paragraph 4 in section 
166622.4.1.4.2 [locale.codecvt.virtuals] to read:
1667</p>
1668<blockquote>
1669  <p><tt>noconv</tt>: <tt>internT</tt> and <tt>externT</tt> are the same type,
1670  and input sequence is identical to converted sequence.</p>
1671</blockquote>
1672<p>Change the Note in paragraph 2 to normative text as follows:</p>
1673<blockquote>
1674  <p>If returns <tt>noconv</tt>, <tt>internT</tt> and <tt>externT</tt> are the
1675  same type and the converted sequence is identical to the input sequence <tt>[from,from_next)</tt>.
1676  <tt>to_next</tt> is set equal to <tt>to</tt>, the value of <tt>state</tt> is
1677  unchanged, and there are no changes to the values in <tt>[to, to_limit)</tt>.</p>
1678</blockquote>
1679
1680
1681
1682
1683
1684<hr>
1685<h3><a name="20"></a>20. Thousands_sep returns wrong type</h3>
1686<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>
1687 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06  <b>Last modified:</b> 2008-09-26</p>
1688<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>
1689<p><b>Discussion:</b></p>
1690<p>The synopsis for numpunct&lt;&gt;::do_thousands_sep, and the
1691definition of numpunct&lt;&gt;::thousands_sep which calls it, specify
1692that it returns a value of type char_type. Here it is erroneously
1693described as returning a "string_type". </p>
1694
1695
1696<p><b>Proposed resolution:</b></p>
1697<p>In 22.4.3.1.2 [facet.numpunct.virtuals], above paragraph 2, change 
1698"string_type" to "char_type". </p>
1699
1700
1701
1702
1703
1704<hr>
1705<h3><a name="21"></a>21. Codecvt_byname&lt;&gt; instantiations</h3>
1706<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>
1707 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06  <b>Last modified:</b> 2008-09-26</p>
1708<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>
1709<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>
1710<p><b>Discussion:</b></p>
1711<p>In the second table in the section, captioned "Required
1712instantiations", the instantiations for codecvt_byname&lt;&gt;
1713have been omitted. These are necessary to allow users to construct a
1714locale by name from facets. </p>
1715
1716
1717<p><b>Proposed resolution:</b></p>
1718<p>Add in 22.3.1.1.1 [locale.category] to the table captioned
1719"Required instantiations", in the category "ctype"
1720the lines </p>
1721
1722<blockquote>
1723  <pre>codecvt_byname&lt;char,char,mbstate_t&gt;,
1724codecvt_byname&lt;wchar_t,char,mbstate_t&gt; </pre>
1725</blockquote>
1726
1727
1728
1729
1730
1731<hr>
1732<h3><a name="22"></a>22. Member open vs. flags</h3>
1733<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>
1734 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06  <b>Last modified:</b> 2008-09-26</p>
1735<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>
1736<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>
1737<p><b>Discussion:</b></p>
1738<p>The description of basic_istream&lt;&gt;::open leaves unanswered questions about how it
1739responds to or changes flags in the error status for the stream. A strict reading
1740indicates that it ignores the bits and does not change them, which confuses users who do
1741not expect eofbit and failbit to remain set after a successful open. There are three
1742reasonable resolutions: 1) status quo 2) fail if fail(), ignore eofbit 3) clear failbit
1743and eofbit on call to open(). </p>
1744
1745
1746<p><b>Proposed resolution:</b></p>
1747<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:
1748</p>
1749
1750<blockquote>
1751  <p>A successful open does not change the error state.</p>
1752</blockquote>
1753
1754
1755<p><b>Rationale:</b></p>
1756<p>This may seem surprising to some users, but it's just an instance
1757of a general rule: error flags are never cleared by the
1758implementation. The only way error flags are are ever cleared is if
1759the user explicitly clears them by hand.</p>
1760
1761<p>The LWG believed that preserving this general rule was
1762important enough so that an exception shouldn't be made just for this
1763one case.  The resolution of this issue clarifies what the LWG
1764believes to have been the original intent.</p>
1765
1766
1767
1768
1769
1770
1771<hr>
1772<h3><a name="23"></a>23. Num_get overflow result</h3>
1773<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>
1774 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06  <b>Last modified:</b> 2008-09-26</p>
1775<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>
1776<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>
1777<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
1778<p><b>Discussion:</b></p>
1779<p>The current description of numeric input does not account for the
1780possibility of overflow. This is an implicit result of changing the
1781description to rely on the definition of scanf() (which fails to
1782report overflow), and conflicts with the documented behavior of
1783traditional and current implementations. </p>
1784
1785<p>Users expect, when reading a character sequence that results in a
1786value unrepresentable in the specified type, to have an error
1787reported. The standard as written does not permit this. </p>
1788
1789<p><b>Further comments from Dietmar:</b></p>
1790
1791<p>
1792I don't feel comfortable with the proposed resolution to issue 23: It
1793kind of simplifies the issue to much. Here is what is going on:
1794</p>
1795
1796<p>
1797Currently, the behavior of numeric overflow is rather counter intuitive
1798and hard to trace, so I will describe it briefly:
1799</p>
1800
1801<ul>
1802  <li>
1803    According to 22.4.2.1.2 [facet.num.get.virtuals]
1804    paragraph 11 <tt>failbit</tt> is set if <tt>scanf()</tt> would
1805    return an input error; otherwise a value is converted to the rules
1806    of <tt>scanf</tt>.
1807  </li>
1808  <li> 
1809    <tt>scanf()</tt> is defined in terms of <tt>fscanf()</tt>. 
1810  </li>
1811  <li>
1812    <tt>fscanf()</tt> returns an input failure if during conversion no
1813    character matching the conversion specification could be extracted
1814    before reaching EOF. This is the only reason for <tt>fscanf()</tt>
1815    to fail due to an input error and clearly does not apply to the case
1816    of overflow.
1817  </li>
1818  <li>
1819    Thus, the conversion is performed according to the rules of
1820    <tt>fscanf()</tt> which basically says that <tt>strtod</tt>,
1821    <tt>strtol()</tt>, etc. are to be used for the conversion.
1822  </li>
1823  <li>
1824    The <tt>strtod()</tt>, <tt>strtol()</tt>, etc. functions consume as
1825    many matching characters as there are and on overflow continue to
1826    consume matching characters but also return a value identical to
1827    the maximum (or minimum for signed types if there was a leading minus)
1828    value of the corresponding type and set <tt>errno</tt> to <tt>ERANGE</tt>.
1829  </li>
1830  <li>
1831    Thus, according to the current wording in the standard, overflows
1832    can be detected! All what is to be done is to check <tt>errno</tt>
1833    after reading an element and, of course, clearing <tt>errno</tt>
1834    before trying a conversion. With the current wording, it can be
1835    detected whether the overflow was due to a positive or negative
1836    number for signed types.
1837  </li>
1838</ul>
1839
1840<p><b>Further discussion from Redmond:</b></p>
1841
1842<p>The basic problem is that we've defined our behavior,
1843including our error-reporting behavior, in terms of C90.  However,
1844C90's method of reporting overflow in scanf is not technically an
1845"input error".  The <tt>strto_*</tt> functions are more precise.</p>
1846
1847<p>There was general consensus that <tt>failbit</tt> should be set
1848upon overflow.  We considered three options based on this:</p>
1849<ol>
1850<li>Set failbit upon conversion error (including overflow), and 
1851    don't store any value.</li>
1852<li>Set failbit upon conversion error, and also set <tt>errno</tt> to 
1853    indicated the precise nature of the error.</li>
1854<li>Set failbit upon conversion error.  If the error was due to
1855    overflow, store +-numeric_limits&lt;T&gt;::max() as an
1856    overflow indication.</li>
1857</ol>
1858
1859<p>Straw poll: (1) 5; (2) 0; (3) 8.</p>
1860
1861
1862<p>Discussed at Lillehammer.  General outline of what we want the
1863  solution to look like: we want to say that overflow is an error, and
1864  provide a way to distinguish overflow from other kinds of errors.
1865  Choose candidate field the same way scanf does, but don't describe
1866  the rest of the process in terms of format.  If a finite input field
1867  is too large (positive or negative) to be represented as a finite
1868  value, then set failbit and assign the nearest representable value.
1869  Bill will provide wording.</p>
1870
1871<p>
1872Discussed at Toronto:
1873<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2327.pdf">N2327</a>
1874is in alignment with the direction we wanted to go with in Lillehammer.  Bill
1875to work on.
1876</p>
1877
1878
1879
1880<p><b>Proposed resolution:</b></p>
1881
1882<p>
1883Change 22.4.2.1.2 [facet.num.get.virtuals], end of p3:
1884</p>
1885
1886<blockquote>
1887<p>
1888<b>Stage 3:</b> <del>The result of stage 2 processing can be one of</del>
1889<ins>The sequence of <tt>char</tt>s accumulated in stage 2 (the field) is
1890converted to a numeric value by the rules of one of the functions declared
1891in the header <tt>&lt;cstdlib&gt;</tt>:</ins>
1892</p>
1893<ul>
1894<li>
1895<del>A sequence of <tt>char</tt>s has been accumulated in stage 2 that is
1896converted (according to the rules of <tt>scanf</tt>) to a value of the
1897type of <i>val</i>. This value is stored in <i>val</i> and <tt>ios_base::goodbit</tt> is
1898stored in <i>err</i>.</del>
1899<ins>For a signed integer value, the function <tt>strtoll</tt>.</ins>
1900</li>
1901<li>
1902<del>The sequence of <tt>char</tt>s accumulated in stage 2 would have caused
1903<tt>scanf</tt> to report an input failure. <tt>ios_base::failbit</tt> is
1904assigned to <i>err</i>.</del>
1905<ins>For an unsigned integer value, the function <tt>strtoull</tt>.</ins>
1906</li>
1907<li>
1908<ins>For a floating-point value, the function <tt>strtold</tt>.</ins>
1909</li>
1910</ul>
1911<p>
1912<ins>The numeric value to be stored can be one of:</ins>
1913</p>
1914<ul>
1915<li><ins>zero, if the conversion function fails to convert the entire field.
1916<tt>ios_base::failbit</tt> is assigned to err.</ins></li>
1917<li><ins>the most positive representable value, if the field represents a value
1918too large positive to be represented in <i>val</i>. <tt>ios_base::failbit</tt> is assigned
1919to <i>err</i>.</ins></li>
1920<li><ins>the most negative representable value (zero for unsigned integer), if
1921the field represents a value too large negative to be represented in <i>val</i>.
1922<tt>ios_base::failbit</tt> is assigned to <i>err</i>.</ins></li>
1923<li><ins>the converted value, otherwise.</ins></li>
1924</ul>
1925
1926<p><ins>
1927The resultant numeric value is stored in <i>val</i>.
1928</ins></p>
1929</blockquote>
1930
1931<p>
1932Change 22.4.2.1.2 [facet.num.get.virtuals], p6-p7:
1933</p>
1934
1935<blockquote>
1936<pre>iter_type do_get(iter_type <i>in</i>, iter_type <i>end</i>, ios_base&amp; <i>str</i>, 
1937                 ios_base::iostate&amp; <i>err</i>, bool&amp; <i>val</i>) const;
1938</pre>
1939<blockquote>
1940<p>
1941-6- <i>Effects:</i> If
1942<tt>(<i>str</i>.flags()&amp;ios_base::boolalpha)==0</tt> then input
1943proceeds as it would for a <tt>long</tt> except that if a value is being
1944stored into <i>val</i>, the value is determined according to the
1945following: If the value to be stored is 0 then <tt>false</tt> is stored.
1946If the value is 1 then <tt>true</tt> is stored. Otherwise
1947<del><tt><i>err</i>|=ios_base::failbit</tt> is performed and no value</del> <ins><tt>true</tt></ins> is
1948stored<del>.</del> <ins>and <tt>ios_base::failbit</tt> is assigned to <i>err</i>.</ins>
1949</p>
1950<p>
1951-7- Otherwise target sequences are determined "as if" by calling the
1952members <tt>falsename()</tt> and <tt>truename()</tt> of the facet
1953obtained by <tt>use_facet&lt;numpunct&lt;charT&gt;
1954&gt;(<i>str</i>.getloc())</tt>. Successive characters in the range
1955<tt>[<i>in</i>,<i>end</i>)</tt> (see 23.1.1) are obtained and matched
1956against corresponding positions in the target sequences only as
1957necessary to identify a unique match. The input iterator <i>in</i> is
1958compared to <i>end</i> only when necessary to obtain a character. If <del>and
1959only if</del> a target sequence is uniquely matched, <i>val</i> is set to the
1960corresponding value. <ins>Otherwise <tt>false</tt> is stored and <tt>ios_base::failbit</tt>
1961is assigned to <i>err</i>.</ins>
1962</p>
1963</blockquote>
1964</blockquote>
1965
1966
1967
1968
1969
1970<hr>
1971<h3><a name="24"></a>24. "do_convert" doesn't exist</h3>
1972<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>
1973 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06  <b>Last modified:</b> 2008-09-26</p>
1974<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>
1975<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>
1976<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#72">72</a></p>
1977<p><b>Discussion:</b></p>
1978<p>The description of codecvt&lt;&gt;::do_out and do_in mentions a
1979symbol "do_convert" which is not defined in the
1980standard. This is a leftover from an edit, and should be "do_in
1981and do_out". </p>
1982
1983
1984<p><b>Proposed resolution:</b></p>
1985<p>In 22.4.1.4 [locale.codecvt], paragraph 3, change
1986"do_convert" to "do_in or do_out". Also, in 22.4.1.4.2 [locale.codecvt.virtuals], change "do_convert()" to "do_in
1987or do_out". </p>
1988
1989
1990
1991
1992
1993<hr>
1994<h3><a name="25"></a>25. String operator&lt;&lt; uses width() value wrong</h3>
1995<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>
1996 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06  <b>Last modified:</b> 2008-09-26</p>
1997<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>
1998<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>
1999<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#67">67</a></p>
2000<p><b>Discussion:</b></p>
2001<p>In the description of operator&lt;&lt; applied to strings, the standard says that uses
2002the smaller of os.width() and str.size(), to pad "as described in stage 3"
2003elsewhere; but this is inconsistent, as this allows no possibility of space for padding. </p>
2004
2005
2006<p><b>Proposed resolution:</b></p>
2007<p>Change 21.4.8.9 [string.io]  paragraph 4 from:<br>
2008<br>
2009&nbsp;&nbsp;&nbsp; "... where <tt>n</tt> is the smaller of <tt>os.width()</tt> and <tt>str.size()</tt>;
2010..."<br>
2011<br>
2012to: <br>
2013<br>
2014&nbsp;&nbsp;&nbsp; "... where <tt>n</tt> is the larger of <tt>os.width()</tt> and <tt>str.size()</tt>;
2015..."</p>
2016
2017
2018
2019
2020
2021<hr>
2022<h3><a name="26"></a>26. Bad sentry example</h3>
2023<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>
2024 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06  <b>Last modified:</b> 2008-09-26</p>
2025<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>
2026<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>
2027<p><b>Discussion:</b></p>
2028<p>In paragraph 6, the code in the example: </p>
2029
2030<pre>  template &lt;class charT, class traits = char_traits&lt;charT&gt; &gt;
2031  basic_istream&lt;charT,traits&gt;::sentry(
2032           basic_istream&lt;charT,traits&gt;&amp; is, bool noskipws = false) {
2033      ...
2034      int_type c;
2035      typedef ctype&lt;charT&gt; ctype_type;
2036      const ctype_type&amp; ctype = use_facet&lt;ctype_type&gt;(is.getloc());
2037      while ((c = is.rdbuf()-&gt;snextc()) != traits::eof()) {
2038        if (ctype.is(ctype.space,c)==0) {
2039          is.rdbuf()-&gt;sputbackc (c);
2040          break;
2041        }
2042      }
2043      ...
2044   }</pre>
2045
2046<p>fails to demonstrate correct use of the facilities described. In
2047particular, it fails to use traits operators, and specifies incorrect
2048semantics. (E.g. it specifies skipping over the first character in the
2049sequence without examining it.) </p>
2050
2051
2052<p><b>Proposed resolution:</b></p>
2053<p>Remove the example above from 27.7.1.1.3 [istream::sentry]
2054paragraph 6.</p>
2055
2056
2057<p><b>Rationale:</b></p>
2058<p>The originally proposed replacement code for the example was not
2059correct. The LWG tried in Kona and again in Tokyo to correct it
2060without success. In Tokyo, an implementor reported that actual working
2061code ran over one page in length and was quite complicated. The LWG
2062decided that it would be counter-productive to include such a lengthy
2063example, which might well still contain errors.</p>
2064
2065
2066
2067
2068
2069<hr>
2070<h3><a name="27"></a>27. String::erase(range) yields wrong iterator</h3>
2071<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>
2072 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06  <b>Last modified:</b> 2008-09-26</p>
2073<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>
2074<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>
2075<p><b>Discussion:</b></p>
2076<p>The string::erase(iterator first, iterator last) is specified to return an element one
2077place beyond the next element after the last one erased. E.g. for the string
2078"abcde", erasing the range ['b'..'d') would yield an iterator for element 'e',
2079while 'd' has not been erased. </p>
2080
2081
2082<p><b>Proposed resolution:</b></p>
2083<p>In 21.4.6.5 [string::erase], paragraph 10, change: </p>
2084
2085<blockquote>
2086  <p>Returns: an iterator which points to the element immediately following _last_ prior to
2087  the element being erased. </p>
2088</blockquote>
2089
2090<p>to read </p>
2091
2092<blockquote>
2093  <p>Returns: an iterator which points to the element pointed to by _last_ prior to the
2094  other elements being erased. </p>
2095</blockquote>
2096
2097
2098
2099
2100
2101<hr>
2102<h3><a name="28"></a>28. Ctype&lt;char&gt;is ambiguous</h3>
2103<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>
2104 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06  <b>Last modified:</b> 2008-09-26</p>
2105<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>
2106<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>
2107<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#236">236</a></p>
2108<p><b>Discussion:</b></p>
2109<p>The description of the vector form of ctype&lt;char&gt;::is can be interpreted to mean
2110something very different from what was intended. Paragraph 4 says </p>
2111
2112<blockquote>
2113  <p>Effects: The second form, for all *p in the range [low, high), assigns vec[p-low] to
2114  table()[(unsigned char)*p]. </p>
2115</blockquote>
2116
2117<p>This is intended to copy the value indexed from table()[] into the place identified in
2118vec[]. </p>
2119
2120
2121<p><b>Proposed resolution:</b></p>
2122<p>Change 22.4.1.3.2 [facet.ctype.char.members], paragraph 4, to read </p>
2123
2124<blockquote>
2125  <p>Effects: The second form, for all *p in the range [low, high), assigns into vec[p-low]
2126  the value table()[(unsigned char)*p]. </p>
2127</blockquote>
2128
2129
2130
2131
2132
2133<hr>
2134<h3><a name="29"></a>29. Ios_base::init doesn't exist</h3>
2135<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>
2136 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06  <b>Last modified:</b> 2008-09-26</p>
2137<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>
2138<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>
2139<p><b>Discussion:</b></p>
2140<p>Sections 27.4.1 [narrow.stream.objects] and 27.4.2 [wide.stream.objects] mention
2141a function ios_base::init, which is not defined. Probably they mean
2142basic_ios&lt;&gt;::init, defined in 27.5.4.1 [basic.ios.cons],
2143paragraph 3. </p>
2144
2145
2146<p><b>Proposed resolution:</b></p>
2147<p>[R12: modified to include paragraph 5.]</p>
2148
2149<p>In 27.4.1 [narrow.stream.objects] paragraph 2 and 5, change </p>
2150
2151<blockquote>
2152  <p>ios_base::init </p>
2153</blockquote>
2154
2155<p>to </p>
2156
2157<blockquote>
2158  <p>basic_ios&lt;char&gt;::init </p>
2159</blockquote>
2160
2161<p>Also, make a similar change in 27.4.2 [wide.stream.objects] except it
2162should read </p>
2163
2164<blockquote>
2165  <p>basic_ios&lt;wchar_t&gt;::init </p>
2166</blockquote>
2167
2168
2169
2170
2171
2172<hr>
2173<h3><a name="30"></a>30. Wrong header for LC_*</h3>
2174<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>
2175 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06  <b>Last modified:</b> 2008-09-26</p>
2176<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>
2177<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>
2178<p><b>Discussion:</b></p>
2179<p>Paragraph 2 implies that the C macros LC_CTYPE etc. are defined in &lt;cctype&gt;,
2180where they are in fact defined elsewhere to appear in &lt;clocale&gt;. </p>
2181
2182
2183<p><b>Proposed resolution:</b></p>
2184<p>In 22.3.1.1.1 [locale.category], paragraph 2, change
2185"&lt;cctype&gt;" to read "&lt;clocale&gt;". </p>
2186
2187
2188
2189
2190
2191<hr>
2192<h3><a name="31"></a>31. Immutable locale values</h3>
2193<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>
2194 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06  <b>Last modified:</b> 2008-09-26</p>
2195<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>
2196<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>
2197<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#378">378</a></p>
2198<p><b>Discussion:</b></p>
2199<p>Paragraph 6, says "An instance of <tt>locale</tt> is
2200<i>immutable</i>; once a facet reference is obtained from it,
2201...". This has caused some confusion, because locale variables
2202are manifestly assignable. </p>
2203
2204
2205<p><b>Proposed resolution:</b></p>
2206<p>In 22.3.1 [locale] replace paragraph 6</p>
2207
2208<blockquote>
2209  <p>An instance of <tt>locale</tt> is immutable; once a facet
2210  reference is obtained from it, that reference remains usable as long
2211  as the locale value itself exists.</p>
2212</blockquote>
2213
2214<p>with</p>
2215
2216<blockquote>
2217  <p>Once a facet reference is obtained from a locale object by
2218  calling use_facet&lt;&gt;, that reference remains usable, and the
2219  results from member functions of it may be cached and re-used, as
2220  long as some locale object refers to that facet.</p>
2221</blockquote>
2222
2223
2224
2225
2226
2227<hr>
2228<h3><a name="32"></a>32. Pbackfail description inconsistent</h3>
2229<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>
2230 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06  <b>Last modified:</b> 2008-09-26</p>
2231<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>
2232<p><b>Discussion:</b></p>
2233<p>The description of the required state before calling virtual member
2234basic_streambuf&lt;&gt;::pbackfail requirements is inconsistent with the conditions
2235described in 27.5.2.2.4 [lib.streambuf.pub.pback] where member sputbackc calls it.
2236Specifically, the latter says it calls pbackfail if: </p>
2237
2238<p>&nbsp;&nbsp;&nbsp; traits::eq(c,gptr()[-1]) is false </p>
2239
2240<p>where pbackfail claims to require: </p>
2241
2242<p>&nbsp;&nbsp;&nbsp; traits::eq(*gptr(),traits::to_char_type(c)) returns false </p>
2243
2244<p>It appears that the pbackfail description is wrong. </p>
2245
2246
2247<p><b>Proposed resolution:</b></p>
2248<p>In 27.6.2.4.4 [streambuf.virt.pback], paragraph 1, change:</p>
2249
2250<blockquote>
2251  <p>"<tt>traits::eq(*gptr(),traits::to_char_type( c))</tt>"</p>
2252</blockquote>
2253
2254<p>to </p>
2255
2256<blockquote>
2257  <p>"<tt>traits::eq(traits::to_char_type(c),gptr()[-1])</tt>"
2258  </p>
2259</blockquote>
2260
2261
2262<p><b>Rationale:</b></p>
2263<p>Note deliberate reordering of arguments for clarity in addition to the correction of
2264the argument value.</p>
2265
2266
2267
2268
2269
2270<hr>
2271<h3><a name="33"></a>33. Codecvt&lt;&gt; mentions from_type</h3>
2272<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>
2273 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06  <b>Last modified:</b> 2008-09-26</p>
2274<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>
2275<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>
2276<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#43">43</a></p>
2277<p><b>Discussion:</b></p>
2278<p>In the table defining the results from do_out and do_in, the specification for the
2279result <i>error</i> says </p>
2280
2281<blockquote>
2282  <p>encountered a from_type character it could not convert </p>
2283</blockquote>
2284
2285<p>but from_type is not defined. This clearly is intended to be an externT for do_in, or
2286an internT for do_out. </p>
2287
2288
2289<p><b>Proposed resolution:</b></p>
2290<p>In 22.4.1.4.2 [locale.codecvt.virtuals] paragraph 4, replace the definition
2291in the table for the case of _error_ with </p>
2292
2293<blockquote>
2294  <p>encountered a character in <tt>[from,from_end)</tt> that it could not convert. </p>
2295</blockquote>
2296
2297
2298
2299
2300
2301<hr>
2302<h3><a name="34"></a>34. True/falsename() not in ctype&lt;&gt;</h3>
2303<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>
2304 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06  <b>Last modified:</b> 2008-09-26</p>
2305<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#facet.num.put.virtuals">active issues</a> in [facet.num.put.virtuals].</p>
2306<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>
2307<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>
2308<p><b>Discussion:</b></p>
2309<p>In paragraph 19, Effects:, members truename() and falsename are used from facet
2310ctype&lt;charT&gt;, but it has no such members. Note that this is also a problem in
231122.2.2.1.2, addressed in (4). </p>
2312
2313
2314<p><b>Proposed resolution:</b></p>
2315<p>In 22.4.2.2.2 [facet.num.put.virtuals], paragraph 19, in the Effects:
2316clause for member put(...., bool), replace the initialization of the
2317string_type value s as follows: </p>
2318
2319<blockquote>
2320  <pre>const numpunct&amp; np = use_facet&lt;numpunct&lt;charT&gt; &gt;(loc);
2321string_type s = val ? np.truename() : np.falsename(); </pre>
2322</blockquote>
2323
2324
2325
2326
2327
2328<hr>
2329<h3><a name="35"></a>35. No manipulator unitbuf in synopsis</h3>
2330<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>
2331 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06  <b>Last modified:</b> 2008-09-26</p>
2332<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostreams.base">issues</a> in [iostreams.base].</p>
2333<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>
2334<p><b>Discussion:</b></p>
2335<p>In 27.5.5.1 [fmtflags.manip], we have a definition for a manipulator
2336named "unitbuf". Unlike other manipulators, it's not listed
2337in synopsis. Similarly for "nounitbuf". </p>
2338
2339
2340<p><b>Proposed resolution:</b></p>
2341<p>Add to the synopsis for &lt;ios&gt; in 27.5 [iostreams.base], after
2342the entry for "nouppercase", the prototypes: </p>
2343
2344<blockquote>
2345  <pre>ios_base&amp; unitbuf(ios_base&amp; str);
2346ios_base&amp; nounitbuf(ios_base&amp; str); </pre>
2347</blockquote>
2348
2349
2350
2351
2352
2353<hr>
2354<h3><a name="36"></a>36. Iword &amp; pword storage lifetime omitted</h3>
2355<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>
2356 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06  <b>Last modified:</b> 2008-09-26</p>
2357<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>
2358<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>
2359<p><b>Discussion:</b></p>
2360<p>In the definitions for ios_base::iword and pword, the lifetime of the storage is
2361specified badly, so that an implementation which only keeps the last value stored appears
2362to conform. In particular, it says: </p>
2363
2364<p>The reference returned may become invalid after another call to the object's iword
2365member with a different index ... </p>
2366
2367<p>This is not idle speculation; at least one implementation was done this way. </p>
2368
2369
2370<p><b>Proposed resolution:</b></p>
2371<p>Add in 27.5.2.5 [ios.base.storage], in both paragraph 2 and also in
2372paragraph 4, replace the sentence: </p>
2373
2374<blockquote>
2375  <p>The reference returned may become invalid after another call to the object's iword
2376  [pword] member with a different index, after a call to its copyfmt member, or when the
2377  object is destroyed. </p>
2378</blockquote>
2379
2380<p>with: </p>
2381
2382<blockquote>
2383  <p>The reference returned is invalid after any other operations on the object. However,
2384  the value of the storage referred to is retained, so that until the next call to copyfmt,
2385  calling iword [pword] with the same index yields another reference to the same value. </p>
2386</blockquote>
2387
2388<p>substituting "iword" or "pword" as appropriate. </p>
2389
2390
2391
2392
2393
2394<hr>
2395<h3><a name="37"></a>37. Leftover "global" reference</h3>
2396<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>
2397 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06  <b>Last modified:</b> 2008-09-26</p>
2398<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>
2399<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>
2400<p><b>Discussion:</b></p>
2401<p>In the overview of locale semantics, paragraph 4, is the sentence </p>
2402
2403<blockquote>
2404  <p>If Facet is not present in a locale (or, failing that, in the global locale), it throws
2405  the standard exception bad_cast. </p>
2406</blockquote>
2407
2408<p>This is not supported by the definition of use_facet&lt;&gt;, and represents semantics
2409from an old draft. </p>
2410
2411
2412<p><b>Proposed resolution:</b></p>
2413<p>In 22.3.1 [locale], paragraph 4, delete the parenthesized
2414expression </p>
2415
2416<blockquote>
2417  <p>(or, failing that, in the global locale) </p>
2418</blockquote>
2419
2420
2421
2422
2423
2424<hr>
2425<h3><a name="38"></a>38. Facet definition incomplete</h3>
2426<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>
2427 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06  <b>Last modified:</b> 2008-09-26</p>
2428<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>
2429<p><b>Discussion:</b></p>
2430<p>It has been noticed by Esa Pulkkinen that the definition of
2431"facet" is incomplete. In particular, a class derived from
2432another facet, but which does not define a member <i>id</i>, cannot
2433safely serve as the argument <i>F</i> to use_facet&lt;F&gt;(loc),
2434because there is no guarantee that a reference to the facet instance
2435stored in <i>loc</i> is safely convertible to <i>F</i>. </p>
2436
2437
2438<p><b>Proposed resolution:</b></p>
2439<p>In the definition of std::use_facet&lt;&gt;(), replace the text in paragraph 1 which
2440reads: </p>
2441
2442<blockquote>
2443  <p>Get a reference to a facet of a locale. </p>
2444</blockquote>
2445
2446<p>with: </p>
2447
2448<blockquote>
2449  <p>Requires: <tt>Facet</tt> is a facet class whose definition
2450  contains the public static member <tt>id</tt> as defined in 22.3.1.1.2 [locale.facet]. </p>
2451</blockquote>
2452
2453<p><i>[
2454Kona: strike as overspecification the text "(not inherits)"
2455from the original resolution, which read "... whose definition
2456contains (not inherits) the public static member
2457<tt>id</tt>..."
2458]</i></p>
2459
2460
2461
2462
2463
2464
2465
2466<hr>
2467<h3><a name="39"></a>39. istreambuf_iterator&lt;&gt;::operator++(int) definition garbled</h3>
2468<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>
2469 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06  <b>Last modified:</b> 2008-09-26</p>
2470<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>
2471<p><b>Discussion:</b></p>
2472<p>Following the definition of istreambuf_iterator&lt;&gt;::operator++(int) in paragraph
24733, the standard contains three lines of garbage text left over from a previous edit. </p>
2474
2475<blockquote>
2476  <pre>istreambuf_iterator&lt;charT,traits&gt; tmp = *this;
2477sbuf_-&gt;sbumpc();
2478return(tmp); </pre>
2479</blockquote>
2480
2481
2482<p><b>Proposed resolution:</b></p>
2483<p>In 24.6.3.4 [istreambuf.iterator::op++], delete the three lines of code at the
2484end of paragraph 3. </p>
2485
2486
2487
2488
2489
2490<hr>
2491<h3><a name="40"></a>40. Meaningless normative paragraph in examples</h3>
2492<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>
2493 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06  <b>Last modified:</b> 2008-09-26</p>
2494<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>
2495<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>
2496<p><b>Discussion:</b></p>
2497<p>Paragraph 3 of the locale examples is a description of part of an
2498implementation technique that has lost its referent, and doesn't mean
2499anything. </p>
2500
2501
2502<p><b>Proposed resolution:</b></p>
2503<p>Delete 22.4.8 [facets.examples] paragraph 3 which begins "This
2504initialization/identification system depends...", or (at the
2505editor's option) replace it with a place-holder to keep the paragraph
2506numbering the same. </p>
2507
2508
2509
2510
2511
2512<hr>
2513<h3><a name="41"></a>41. Ios_base needs clear(), exceptions()</h3>
2514<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>
2515 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06  <b>Last modified:</b> 2008-09-26</p>
2516<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>
2517<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>
2518<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#157">157</a></p>
2519<p><b>Discussion:</b></p>
2520<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,
2521which may throw an exception". However, ios_base offers no
2522interface to set or to test badbit; those interfaces are defined in
2523basic_ios&lt;&gt;. </p>
2524
2525
2526<p><b>Proposed resolution:</b></p>
2527<p>Change the description in 27.5.2.5 [ios.base.storage] in
2528paragraph 2, and also in paragraph 4, as follows. Replace</p>
2529
2530<blockquote>
2531  <p>If the function fails it sets badbit, which may throw an exception.</p>
2532</blockquote>
2533
2534<p>with</p>
2535
2536<blockquote>
2537  <p>If the function fails, and <tt>*this</tt> is a base sub-object of
2538  a <tt>basic_ios&lt;&gt;</tt> object or sub-object, the effect is
2539  equivalent to calling <tt>basic_ios&lt;&gt;::setstate(badbit)</tt>
2540  on the derived object (which may throw <tt>failure</tt>).</p>
2541</blockquote>
2542
2543<p><i>[Kona: LWG reviewed wording; setstate(failbit) changed to
2544setstate(badbit).]</i></p>
2545
2546
2547
2548
2549
2550
2551
2552<hr>
2553<h3><a name="42"></a>42. String ctors specify wrong default allocator</h3>
2554<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>
2555 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06  <b>Last modified:</b> 2008-09-26</p>
2556<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>
2557<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>
2558<p><b>Discussion:</b></p>
2559<p>The basic_string&lt;&gt; copy constructor: </p>
2560
2561<pre>basic_string(const basic_string&amp; str, size_type pos = 0,
2562             size_type n = npos, const Allocator&amp; a = Allocator()); </pre>
2563
2564<p>specifies an Allocator argument default value that is
2565counter-intuitive. The natural choice for a the allocator to copy from
2566is str.get_allocator(). Though this cannot be expressed in
2567default-argument notation, overloading suffices. </p>
2568
2569<p>Alternatively, the other containers in Clause 23 (deque, list,
2570vector) do not have this form of constructor, so it is inconsistent,
2571and an evident source of confusion, for basic_string&lt;&gt; to have
2572it, so it might better be removed. </p>
2573
2574
2575<p><b>Proposed resolution:</b></p>
2576<p> In 21.4 [basic.string], replace the declaration of the copy
2577constructor as follows: </p>
2578
2579<blockquote>
2580  <pre>basic_string(const basic_string&amp; str);
2581basic_string(const basic_string&amp; str, size_type pos, size_type n = npos,
2582             const Allocator&amp; a = Allocator());</pre>
2583</blockquote>
2584
2585<p>In 21.4.1 [string.require], replace the copy constructor declaration
2586as above. Add to paragraph 5, Effects:</p>
2587
2588<blockquote>
2589  <p>In the first form, the Allocator value used is copied from
2590  <tt>str.get_allocator()</tt>.</p>
2591</blockquote>
2592
2593
2594<p><b>Rationale:</b></p>
2595<p>The LWG believes the constructor is actually broken, rather than
2596just an unfortunate design choice.</p>
2597
2598<p>The LWG considered two other possible resolutions:</p>
2599
2600<p>A. In 21.4 [basic.string], replace the declaration of the copy
2601constructor as follows:</p>
2602
2603<blockquote>
2604  <pre>basic_string(const basic_string&amp; str, size_type pos = 0,
2605             size_type n = npos);
2606basic_string(const basic_string&amp; str, size_type pos,
2607             size_type n, const Allocator&amp; a); </pre>
2608</blockquote>
2609
2610<p>In 21.4.1 [string.require], replace the copy constructor declaration
2611as above. Add to paragraph 5, Effects: </p>
2612
2613<blockquote>
2614  <p>When no <tt>Allocator</tt> argument is provided, the string is constructed using the
2615  value <tt>str.get_allocator()</tt>. </p>
2616</blockquote>
2617
2618<p>B. In 21.4 [basic.string], and also in 21.4.1 [string.require], replace
2619the declaration of the copy constructor as follows: </p>
2620
2621<blockquote>
2622  <pre>basic_string(const basic_string&amp; str, size_type pos = 0,
2623             size_type n = npos); </pre>
2624</blockquote>
2625
2626<p>The proposed resolution reflects the original intent of the LWG. It
2627was also noted by Pete Becker that this fix "will cause
2628a small amount of existing code to now work correctly."</p>
2629
2630<p><i>[
2631Kona: issue editing snafu fixed - the proposed resolution now correctly
2632reflects the LWG consensus.
2633]</i></p>
2634
2635
2636
2637
2638
2639
2640<hr>
2641<h3><a name="44"></a>44. Iostreams use operator== on int_type values</h3>
2642<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>
2643 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-06  <b>Last modified:</b> 2008-09-26</p>
2644<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>
2645<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
2646<p><b>Discussion:</b></p>
2647<p>Many of the specifications for iostreams specify that character
2648values or their int_type equivalents are compared using operators ==
2649or !=, though in other places traits::eq() or traits::eq_int_type is
2650specified to be used throughout. This is an inconsistency; we should
2651change uses of == and != to use the traits members instead. </p>
2652
2653
2654<p><b>Proposed resolution:</b></p>
2655
2656<p><i>[Pre-Kona: Dietmar supplied wording]</i></p>
2657
2658
2659<p>List of changes to clause 27:</p>
2660<ol>
2661<li>
2662   In lib.basic.ios.members paragraph 13 (postcondition clause for
2663   'fill(cT)') change
2664
2665<blockquote><pre>     fillch == fill()
2666</pre></blockquote>
2667
2668   to
2669
2670<blockquote><pre>     traits::eq(fillch, fill())
2671</pre></blockquote>
2672
2673
2674</li>
2675<li>
2676   In lib.istream.unformatted paragraph 7 (effects clause for
2677   'get(cT,streamsize,cT)'), third bullet, change
2678
2679<blockquote><pre>     c == delim for the next available input character c
2680</pre></blockquote>
2681
2682   to
2683
2684<blockquote><pre>     traits::eq(c, delim) for the next available input character c
2685</pre></blockquote>
2686
2687</li>
2688<li>
2689   In lib.istream.unformatted paragraph 12 (effects clause for
2690   'get(basic_streambuf&lt;cT,Tr&gt;&amp;,cT)'), third bullet, change
2691
2692<blockquote><pre>     c == delim for the next available input character c
2693</pre></blockquote>
2694
2695   to
2696
2697<blockquote><pre>     traits::eq(c, delim) for the next available input character c
2698</pre></blockquote>
2699
2700</li>
2701<li>
2702   In lib.istream.unformatted paragraph 17 (effects clause for
2703   'getline(cT,streamsize,cT)'), second bullet, change
2704
2705<blockquote><pre>     c == delim for the next available input character c
2706</pre></blockquote>
2707
2708   to
2709
2710<blockquote><pre>     traits::eq(c, delim) for the next available input character c
2711  </pre></blockquote>
2712
2713</li>
2714<li>
2715   In lib.istream.unformatted paragraph 24 (effects clause for
2716   'ignore(int,int_type)'), second bullet, change
2717
2718<blockquote><pre>     c == delim for the next available input character c
2719</pre></blockquote>
2720
2721   to
2722
2723<blockquote><pre>     traits::eq_int_type(c, delim) for the next available input
2724     character c
2725</pre></blockquote>
2726  
2727</li>
2728<li>
2729   In lib.istream.unformatted paragraph 25 (notes clause for
2730   'ignore(int,int_type)'), second bullet, change
2731
2732<blockquote><pre>     The last condition will never occur if delim == traits::eof()
2733</pre></blockquote>
2734
2735   to
2736
2737<blockquote><pre>     The last condition will never occur if
2738     traits::eq_int_type(delim, traits::eof()).
2739</pre></blockquote>
2740
2741</li>
2742<li>
2743   In lib.istream.sentry paragraph 6 (example implementation for the
2744   sentry constructor) change
2745
2746<blockquote><pre>     while ((c = is.rdbuf()-&gt;snextc()) != traits::eof()) {
2747</pre></blockquote>
2748
2749   to
2750
2751<blockquote><pre>     while (!traits::eq_int_type(c = is.rdbuf()-&gt;snextc(), traits::eof())) {
2752</pre></blockquote>
2753
2754</li>
2755</ol>
2756
2757<p>List of changes to Chapter 21:</p>
2758
2759<ol>
2760<li>
2761   In lib.string::find paragraph 1 (effects clause for find()),
2762   second bullet, change
2763
2764<blockquote><pre>     at(xpos+I) == str.at(I) for all elements ...
2765</pre></blockquote>
2766
2767   to
2768
2769<blockquote><pre>     traits::eq(at(xpos+I), str.at(I)) for all elements ...
2770</pre></blockquote>
2771
2772</li>
2773<li>
2774   In lib.string::rfind paragraph 1 (effects clause for rfind()),
2775   second bullet, change
2776
2777<blockquote><pre>     at(xpos+I) == str.at(I) for all elements ...
2778</pre></blockquote>
2779
2780   to
2781
2782<blockquote><pre>     traits::eq(at(xpos+I), str.at(I)) for all elements ...
2783</pre></blockquote>
2784
2785</li>
2786<li>
2787   In lib.string::find.first.of paragraph 1 (effects clause for
2788   find_first_of()), second bullet, change
2789
2790<blockquote><pre>     at(xpos+I) == str.at(I) for all elements ...
2791</pre></blockquote>
2792
2793   to
2794
2795<blockquote><pre>     traits::eq(at(xpos+I), str.at(I)) for all elements ...
2796</pre></blockquote>
2797
2798</li>
2799<li>
2800   In lib.string::find.last.of paragraph 1 (effects clause for
2801   find_last_of()), second bullet, change
2802
2803<blockquote><pre>     at(xpos+I) == str.at(I) for all elements ...
2804</pre></blockquote>
2805
2806   to
2807
2808<blockquote><pre>     traits::eq(at(xpos+I), str.at(I)) for all elements ...
2809</pre></blockquote>
2810
2811</li>
2812<li>
2813   In lib.string::find.first.not.of paragraph 1 (effects clause for
2814   find_first_not_of()), second bullet, change
2815
2816<blockquote><pre>     at(xpos+I) == str.at(I) for all elements ...
2817</pre></blockquote>
2818
2819   to
2820
2821<blockquote><pre>     traits::eq(at(xpos+I), str.at(I)) for all elements ...
2822</pre></blockquote>
2823</li>
2824
2825<li>
2826   In lib.string::find.last.not.of paragraph 1 (effects clause for
2827   find_last_not_of()), second bullet, change
2828
2829<blockquote><pre>     at(xpos+I) == str.at(I) for all elements ...
2830</pre></blockquote>
2831
2832   to
2833
2834<blockquote><pre>     traits::eq(at(xpos+I), str.at(I)) for all elements ...
2835</pre></blockquote>
2836</li>
2837
2838<li>
2839   In lib.string.ios paragraph 5 (effects clause for getline()),
2840   second bullet, change
2841
2842<blockquote><pre>     c == delim for the next available input character c 
2843</pre></blockquote>
2844
2845   to
2846
2847<blockquote><pre>     traits::eq(c, delim) for the next available input character c 
2848</pre></blockquote>
2849</li>
2850
2851</ol>
2852
2853<p>Notes:</p>
2854<ul>
2855<li>
2856  Fixing this issue highlights another sloppyness in
2857  lib.istream.unformatted paragraph 24: this clause mentions a "character"
2858  which is then compared to an 'int_type' (see item 5. in the list
2859  below). It is not clear whether this requires explicit words and
2860  if so what these words are supposed to be. A similar issue exists,
2861  BTW, for operator*() of istreambuf_iterator which returns the result
2862  of sgetc() as a character type (see lib.istreambuf.iterator::op*
2863  paragraph 1), and for operator++() of istreambuf_iterator which
2864  passes the result of sbumpc() to a constructor taking a char_type
2865  (see lib.istreambuf.iterator::operator++ paragraph 3). Similarily, the
2866  assignment operator ostreambuf_iterator passes a char_type to a function
2867  taking an int_type (see lib.ostreambuf.iter.ops paragraph 1).
2868</li>
2869<li>
2870  It is inconsistent to use comparisons using the traits functions in
2871  Chapter 27 while not using them in Chapter 21, especially as some
2872  of the inconsistent uses actually involve streams (eg. getline() on
2873  streams). To avoid leaving this issue open still longer due to this
2874  inconsistency (it is open since 1998), a list of changes to Chapter
2875  21 is below.
2876</li>
2877<li>
2878  In Chapter 24 there are several places with statements like "the end
2879  of stream is reached (streambuf_type::sgetc() returns traits::eof())"
2880  (lib.istreambuf.iterator paragraph 1, lib.ostreambuf.iter.ops
2881  paragraph 5). It is unclear whether these should be clarified to use
2882  traits::eq_int_type() for detecting traits::eof().
2883</li>
2884</ul>
2885
2886
2887
2888
2889
2890
2891<hr>
2892<h3><a name="46"></a>46. Minor Annex D errors</h3>
2893<p><b>Section:</b> D.8 [depr.str.strstreams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
2894 <b>Submitter:</b> Brendan Kehoe <b>Opened:</b> 1998-06-01  <b>Last modified:</b> 2008-09-26</p>
2895<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>
2896<p><b>Discussion:</b></p><p>See lib-6522 and edit-814.</p>
2897
2898<p><b>Proposed resolution:</b></p>
2899<p>Change D.8.1 [depr.strstreambuf] (since streambuf is a typedef of
2900basic_streambuf&lt;char&gt;) from:</p>
2901
2902<pre>         virtual streambuf&lt;char&gt;* setbuf(char* s, streamsize n);</pre>
2903
2904<p>to:</p>
2905
2906<pre>         virtual streambuf* setbuf(char* s, streamsize n);</pre>
2907
2908<p>In D.8.4 [depr.strstream] insert the semicolon now missing after
2909int_type:</p>
2910
2911<pre>     namespace std {
2912       class strstream
2913         : public basic_iostream&lt;char&gt; {
2914       public:
2915         // Types
2916         typedef char                                char_type;
2917         typedef typename char_traits&lt;char&gt;::int_type int_type
2918         typedef typename char_traits&lt;char&gt;::pos_type pos_type;</pre>
2919
2920
2921
2922
2923
2924<hr>
2925<h3><a name="47"></a>47. Imbue() and getloc() Returns clauses swapped</h3>
2926<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>
2927 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-06-21  <b>Last modified:</b> 2008-09-26</p>
2928<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>
2929<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>
2930<p><b>Discussion:</b></p>
2931<p>Section 27.4.2.3 specifies how imbue() and getloc() work. That
2932section has two RETURNS clauses, and they make no sense as
2933stated. They make perfect sense, though, if you swap them. Am I
2934correct in thinking that paragraphs 2 and 4 just got mixed up by
2935accident?</p>
2936
2937
2938<p><b>Proposed resolution:</b></p>
2939<p>In 27.5.2.3 [ios.base.locales] swap paragraphs 2 and 4.</p>
2940
2941
2942
2943
2944
2945<hr>
2946<h3><a name="48"></a>48. Use of non-existent exception constructor</h3>
2947<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>
2948 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-06-21  <b>Last modified:</b> 2008-09-26</p>
2949<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>
2950<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>
2951<p><b>Discussion:</b></p>
2952<p>27.4.2.1.1, paragraph 2, says that class failure initializes the
2953base class, exception, with exception(msg). Class exception (see
295418.6.1) has no such constructor.</p>
2955
2956
2957<p><b>Proposed resolution:</b></p>
2958<p>Replace 27.5.2.1.1 [ios::failure], paragraph 2, with</p>
2959
2960<blockquote>
2961  <p>EFFECTS: Constructs an object of class <tt>failure</tt>.</p>
2962</blockquote>
2963
2964
2965
2966
2967
2968<hr>
2969<h3><a name="49"></a>49. Underspecification of ios_base::sync_with_stdio</h3>
2970<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>
2971 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-06-21  <b>Last modified:</b> 2008-09-26</p>
2972<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
2973<p><b>Discussion:</b></p>
2974<p>Two problems</p>
2975
2976<p>(1) 27.4.2.4 doesn't say what ios_base::sync_with_stdio(f)
2977returns. Does it return f, or does it return the previous
2978synchronization state? My guess is the latter, but the standard
2979doesn't say so.</p>
2980
2981<p>(2) 27.4.2.4 doesn't say what it means for streams to be
2982synchronized with stdio.  Again, of course, I can make some
2983guesses. (And I'm unhappy about the performance implications of those
2984guesses, but that's another matter.)</p>
2985
2986
2987<p><b>Proposed resolution:</b></p>
2988<p>Change the following sentence in 27.5.2.4 [ios.members.static]
2989returns clause from:</p>
2990
2991<blockquote>
2992  <p><tt>true</tt> if the standard iostream objects (27.3) are
2993  synchronized and otherwise returns <tt>false</tt>.</p>
2994</blockquote>
2995
2996<p>to:</p>
2997
2998<blockquote>
2999  <p><tt>true</tt> if the previous state of the standard iostream
3000  objects (27.3) was synchronized and otherwise returns
3001  <tt>false</tt>.</p>
3002</blockquote>
3003
3004<p>Add the following immediately after 27.5.2.4 [ios.members.static],
3005paragraph 2:</p>
3006
3007<blockquote>
3008<p>When a standard iostream object str is <i>synchronized</i> with a
3009standard stdio stream f, the effect of inserting a character c by</p>
3010<pre>  fputc(f, c);
3011</pre>
3012
3013<p>is the same as the effect of</p>
3014<pre>  str.rdbuf()-&gt;sputc(c);
3015</pre>
3016
3017<p>for any sequence of characters; the effect of extracting a
3018character c by</p>
3019<pre>  c = fgetc(f);
3020</pre>
3021
3022<p>is the same as the effect of:</p>
3023<pre>  c = str.rdbuf()-&gt;sbumpc(c);
3024</pre>
3025
3026<p>for any sequences of characters; and the effect of pushing
3027back a character c by</p>
3028<pre>  ungetc(c, f);
3029</pre>
3030
3031<p>is the same as the effect of</p>
3032<pre>  str.rdbuf()-&gt;sputbackc(c);
3033</pre>
3034
3035<p>for any sequence of characters.  [<i>Footnote</i>: This implies
3036that operations on a standard iostream object can be mixed arbitrarily
3037with operations on the corresponding stdio stream.  In practical
3038terms, synchronization usually means that a standard iostream object
3039and a standard stdio object share a buffer. <i>--End Footnote</i>]</p>
3040</blockquote>
3041
3042<p><i>[pre-Copenhagen: PJP and Matt contributed the definition
3043of "synchronization"]</i></p>
3044
3045
3046<p><i>[post-Copenhagen: proposed resolution was revised slightly:
3047text was added in the non-normative footnote to say that operations
3048on the two streams can be mixed arbitrarily.]</i></p>
3049
3050
3051
3052
3053
3054
3055<hr>
3056<h3><a name="50"></a>50. Copy constructor and assignment operator of ios_base</h3>
3057<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>
3058 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-06-21  <b>Last modified:</b> 2008-09-26</p>
3059<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>
3060<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>
3061<p><b>Discussion:</b></p>
3062<p>As written, ios_base has a copy constructor and an assignment
3063operator. (Nothing in the standard says it doesn't have one, and all
3064classes have copy constructors and assignment operators unless you
3065take specific steps to avoid them.) However, nothing in 27.4.2 says
3066what the copy constructor and assignment operator do. </p>
3067
3068<p>My guess is that this was an oversight, that ios_base is, like
3069basic_ios, not supposed to have a copy constructor or an assignment
3070operator.</p>
3071
3072<p>
3073Jerry Schwarz comments: Yes, its an oversight, but in the opposite
3074sense to what you're suggesting. At one point there was a definite
3075intention that you could copy ios_base. It's an easy way to save the
3076entire state of a stream for future use. As you note, to carry out
3077that intention would have required a explicit description of the
3078semantics (e.g. what happens to the iarray and parray stuff).
3079</p>
3080
3081
3082<p><b>Proposed resolution:</b></p>
3083<p>In 27.5.2 [ios.base], class ios_base, specify the copy
3084constructor and operator= members as being private.</p>
3085
3086
3087<p><b>Rationale:</b></p>
3088<p>The LWG believes the difficulty of specifying correct semantics
3089outweighs any benefit of allowing ios_base objects to be copyable.</p>
3090
3091
3092
3093
3094
3095<hr>
3096<h3><a name="51"></a>51. Requirement to not invalidate iterators missing</h3>
3097<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>
3098 <b>Submitter:</b> David Vandevoorde <b>Opened:</b> 1998-06-23  <b>Last modified:</b> 2008-09-26</p>
3099<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>
3100<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>
3101<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>
3102<p><b>Discussion:</b></p>
3103<p>The std::sort algorithm can in general only sort a given sequence
3104by moving around values. The list&lt;&gt;::sort() member on the other
3105hand could move around values or just update internal pointers. Either
3106method can leave iterators into the list&lt;&gt; dereferencable, but
3107they would point to different things. </p>
3108
3109<p>Does the FDIS mandate anywhere which method should be used for
3110list&lt;&gt;::sort()?</p>
3111
3112<p>Matt Austern comments:</p>
3113
3114<p>I think you've found an omission in the standard. </p>
3115
3116<p>The library working group discussed this point, and there was
3117supposed to be a general requirement saying that list, set, map,
3118multiset, and multimap may not invalidate iterators, or change the
3119values that iterators point to, except when an operation does it
3120explicitly. So, for example, insert() doesn't invalidate any iterators
3121and erase() and remove() only invalidate iterators pointing to the
3122elements that are being erased. </p>
3123
3124<p>I looked for that general requirement in the FDIS, and, while I
3125found a limited form of it for the sorted associative containers, I
3126didn't find it for list. It looks like it just got omitted. </p>
3127
3128<p>The intention, though, is that list&lt;&gt;::sort does not
3129invalidate any iterators and does not change the values that any
3130iterator points to. There would be no reason to have the member
3131function otherwise.</p>
3132
3133
3134<p><b>Proposed resolution:</b></p>
3135<p>Add a new paragraph at the end of 23.1:</p>
3136
3137<blockquote>
3138  <p>Unless otherwise specified (either explicitly or by defining a function in terms of
3139  other functions), invoking a container member function or passing a container as an
3140  argument to a library function shall not invalidate iterators to, or change the values of,
3141  objects within that container. </p>
3142</blockquote>
3143
3144
3145<p><b>Rationale:</b></p>
3146<p>This was US issue CD2-23-011; it was accepted in London but the
3147change was not made due to an editing oversight. The wording in the
3148proposed resolution below is somewhat updated from CD2-23-011,
3149particularly the addition of the phrase "or change the values
3150of"</p>
3151
3152
3153
3154
3155
3156<hr>
3157<h3><a name="52"></a>52. Small I/O problems</h3>
3158<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>
3159 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-06-23  <b>Last modified:</b> 2008-09-26</p>
3160<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>
3161<p><b>Discussion:</b></p>
3162<p>First, 27.5.4.1 [basic.ios.cons], table 89. This is pretty obvious:
3163it should be titled "basic_ios&lt;&gt;() effects", not
3164"ios_base() effects". </p>
3165
3166<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
3167resolution.]</p>
3168
3169<p>Second, 27.5.3.2 [fpos.operations] table 88 . There are a couple
3170different things wrong with it, some of which I've already discussed
3171with Jerry, but the most obvious mechanical sort of error is that it
3172uses expressions like P(i) and p(i), without ever defining what sort
3173of thing "i" is.
3174</p>
3175
3176<p>(The other problem is that it requires support for streampos
3177arithmetic. This is impossible on some systems, i.e. ones where file
3178position is a complicated structure rather than just a number. Jerry
3179tells me that the intention was to require syntactic support for
3180streampos arithmetic, but that it wasn't actually supposed to do
3181anything meaningful except on platforms, like Unix, where genuine
3182arithmetic is possible.) </p>
3183
3184
3185<p><b>Proposed resolution:</b></p>
3186<p>Change 27.5.4.1 [basic.ios.cons] table 89 title from
3187"ios_base() effects" to "basic_ios&lt;&gt;()
3188effects". </p>
3189
3190
3191
3192
3193
3194<hr>
3195<h3><a name="53"></a>53. Basic_ios destructor unspecified</h3>
3196<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>
3197 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-06-23  <b>Last modified:</b> 2008-09-26</p>
3198<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>
3199<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>
3200<p><b>Discussion:</b></p>
3201<p>There's nothing in 27.4.4 saying what basic_ios's destructor does.
3202The important question is whether basic_ios::~basic_ios() destroys
3203rdbuf().</p>
3204
3205
3206<p><b>Proposed resolution:</b></p>
3207<p>Add after 27.5.4.1 [basic.ios.cons] paragraph 2:</p>
3208
3209<blockquote>
3210  <p><tt>virtual ~basic_ios();</tt></p>
3211  <p><b>Notes</b>: The destructor does not destroy <tt>rdbuf()</tt>.</p>
3212</blockquote>
3213
3214
3215<p><b>Rationale:</b></p> 
3216<p>The LWG reviewed the additional question of whether or not
3217<tt>rdbuf(0)</tt> may set <tt>badbit</tt>.  The answer is
3218clearly 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
3219by the LWG, which removed from the original proposed resolution a
3220footnote which incorrectly said "<tt>rdbuf(0)</tt> does not set
3221<tt>badbit</tt>".</p>
3222
3223
3224
3225
3226
3227<hr>
3228<h3><a name="54"></a>54. Basic_streambuf's destructor</h3>
3229<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>
3230 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-06-25  <b>Last modified:</b> 2008-09-26</p>
3231<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>
3232<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>
3233<p><b>Discussion:</b></p>
3234<p>The class synopsis for basic_streambuf shows a (virtual)
3235destructor, but the standard doesn't say what that destructor does. My
3236assumption is that it does nothing, but the standard should say so
3237explicitly. </p>
3238
3239
3240<p><b>Proposed resolution:</b></p>
3241<p>Add after 27.6.2.1 [streambuf.cons] paragraph 2:</p>
3242
3243<blockquote>
3244  <p><tt>virtual&nbsp; ~basic_streambuf();</tt></p>
3245  <p><b>Effects</b>: None.</p>
3246</blockquote>
3247
3248
3249
3250
3251
3252<hr>
3253<h3><a name="55"></a>55. Invalid stream position is undefined</h3>
3254<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>
3255 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-06-26  <b>Last modified:</b> 2008-09-26</p>
3256<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>
3257<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>
3258<p><b>Discussion:</b></p>
3259<p>Several member functions in clause 27 are defined in certain
3260circumstances to return an "invalid stream position", a term
3261that is defined nowhere in the standard. Two places (27.5.2.4.2,
3262paragraph 4, and 27.8.1.4, paragraph 15) contain a cross-reference to
3263a definition in _lib.iostreams.definitions_, a nonexistent
3264section. </p>
3265
3266<p>I suspect that the invalid stream position is just supposed to be
3267pos_type(-1).  Probably best to say explicitly in (for example)
326827.5.2.4.2 that the return value is pos_type(-1), rather than to use
3269the term "invalid stream position", define that term
3270somewhere, and then put in a cross-reference. </p>
3271
3272<p>The phrase "invalid stream position" appears ten times in
3273the C++ Standard.  In seven places it refers to a return value, and it
3274should be changed. In three places it refers to an argument, and it
3275should not be changed. Here are the three places where "invalid
3276stream position" should not be changed:</p>
3277
3278<blockquote>
3279  <p>27.8.1.4 [stringbuf.virtuals], paragraph 14<br>
3280  27.9.1.5 [filebuf.virtuals], paragraph 14<br>
3281  D.8.1.3 [depr.strstreambuf.virtuals], paragraph 17
3282  </p>
3283</blockquote>
3284
3285
3286<p><b>Proposed resolution:</b></p>
3287<p>In 27.6.2.4.2 [streambuf.virt.buffer], paragraph 4, change "Returns an
3288object of class pos_type that stores an invalid stream position
3289(_lib.iostreams.definitions_)" to "Returns
3290<tt>pos_type(off_type(-1))</tt>".
3291</p>
3292
3293<p>In 27.6.2.4.2 [streambuf.virt.buffer], paragraph 6, change "Returns
3294an object of class pos_type that stores an invalid stream
3295position" to "Returns <tt>pos_type(off_type(-1))</tt>".</p>
3296
3297<p>In 27.8.1.4 [stringbuf.virtuals], paragraph 13, change "the object
3298stores an invalid stream position" to "the return value is
3299<tt>pos_type(off_type(-1))</tt>". </p>
3300
3301<p>In 27.9.1.5 [filebuf.virtuals], paragraph 13, change "returns an
3302invalid stream position (27.4.3)" to "returns
3303<tt>pos_type(off_type(-1))</tt>" </p>
3304
3305<p>In 27.9.1.5 [filebuf.virtuals], paragraph 15, change "Otherwise
3306returns an invalid stream position (_lib.iostreams.definitions_)"
3307to "Otherwise returns <tt>pos_type(off_type(-1))</tt>"
3308</p>
3309
3310<p>In D.8.1.3 [depr.strstreambuf.virtuals], paragraph 15, change "the object
3311stores an invalid stream position" to "the return value is
3312<tt>pos_type(off_type(-1))</tt>" </p>
3313
3314<p>In D.8.1.3 [depr.strstreambuf.virtuals], paragraph 18, change "the object
3315stores an invalid stream position" to "the return value is
3316<tt>pos_type(off_type(-1))</tt>"</p>
3317
3318
3319
3320
3321
3322<hr>
3323<h3><a name="56"></a>56. Showmanyc's return type</h3>
3324<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>
3325 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-06-29  <b>Last modified:</b> 2008-09-26</p>
3326<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>
3327<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>
3328<p><b>Discussion:</b></p>
3329<p>The class summary for basic_streambuf&lt;&gt;, in 27.5.2, says that
3330showmanyc has return type int. However, 27.5.2.4.3 says that its
3331return type is streamsize. </p>
3332
3333
3334<p><b>Proposed resolution:</b></p>
3335<p>Change <tt>showmanyc</tt>'s return type in the
333627.6.2 [streambuf] class summary to <tt>streamsize</tt>.</p>
3337
3338
3339
3340
3341
3342<hr>
3343<h3><a name="57"></a>57. Mistake in char_traits</h3>
3344<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>
3345 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-07-01  <b>Last modified:</b> 2008-09-26</p>
3346<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>
3347<p><b>Discussion:</b></p>
3348<p>21.1.3.2, paragraph 3, says "The types streampos and
3349wstreampos may be different if the implementation supports no shift
3350encoding in narrow-oriented iostreams but supports one or more shift
3351encodings in wide-oriented streams". </p>
3352
3353<p>That's wrong: the two are the same type. The &lt;iosfwd&gt; summary
3354in 27.2 says that streampos and wstreampos are, respectively, synonyms
3355for fpos&lt;char_traits&lt;char&gt;::state_type&gt; and
3356fpos&lt;char_traits&lt;wchar_t&gt;::state_type&gt;, and, flipping back
3357to clause 21, we see in 21.1.3.1 and 21.1.3.2 that
3358char_traits&lt;char&gt;::state_type and
3359char_traits&lt;wchar_t&gt;::state_type must both be mbstate_t. </p>
3360
3361
3362<p><b>Proposed resolution:</b></p>
3363<p>Remove the sentence in 21.2.3.4 [char.traits.specializations.wchar.t] paragraph 3 which
3364begins "The types streampos and wstreampos may be
3365different..." . </p>
3366
3367
3368
3369
3370
3371<hr>
3372<h3><a name="59"></a>59. Ambiguity in specification of gbump</h3>
3373<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>
3374 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-07-28  <b>Last modified:</b> 2008-09-26</p>
3375<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>
3376<p><b>Discussion:</b></p>
3377<p>27.5.2.3.1 says that basic_streambuf::gbump() "Advances the
3378next pointer for the input sequence by n." </p>
3379
3380<p>The straightforward interpretation is that it is just gptr() +=
3381n. An alternative interpretation, though, is that it behaves as if it
3382calls sbumpc n times. (The issue, of course, is whether it might ever
3383call underflow.) There is a similar ambiguity in the case of
3384pbump. </p>
3385
3386<p>(The "classic" AT&amp;T implementation used the
3387former interpretation.)</p>
3388
3389
3390<p><b>Proposed resolution:</b></p>
3391<p>Change 27.6.2.3.2 [streambuf.get.area] paragraph 4 gbump effects from:</p>
3392
3393<blockquote>
3394  <p>Effects: Advances the next pointer for the input sequence by n.</p>
3395</blockquote>
3396
3397<p>to:</p>
3398
3399<blockquote>
3400  <p>Effects: Adds <tt>n</tt> to the next pointer for the input sequence.</p>
3401</blockquote>
3402
3403<p>Make the same change to 27.6.2.3.3 [streambuf.put.area] paragraph 4 pbump
3404effects.</p>
3405
3406
3407
3408
3409
3410<hr>
3411<h3><a name="60"></a>60. What is a formatted input function?</h3>
3412<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>
3413 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-08-03  <b>Last modified:</b> 2008-09-26</p>
3414<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>
3415<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>
3416<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>
3417<p><b>Discussion:</b></p>
3418<p>Paragraph 1 of 27.6.1.2.1 contains general requirements for all
3419formatted input functions. Some of the functions defined in section
342027.6.1.2 explicitly say that those requirements apply ("Behaves
3421like a formatted input member (as described in 27.6.1.2.1)"), but
3422others don't. The question: is 27.6.1.2.1 supposed to apply to
3423everything in 27.6.1.2, or only to those member functions that
3424explicitly say "behaves like a formatted input member"? Or
3425to put it differently: are we to assume that everything that appears
3426in a section called "Formatted input functions" really is a
3427formatted input function? I assume that 27.6.1.2.1 is intended to
3428apply to the arithmetic extractors (27.6.1.2.2), but I assume that it
3429is not intended to apply to extractors like </p>
3430
3431<pre>    basic_istream&amp; operator&gt;&gt;(basic_istream&amp; (*pf)(basic_istream&amp;));</pre>
3432
3433<p>and </p>
3434
3435<pre>    basic_istream&amp; operator&gt;&gt;(basic_streammbuf*);</pre>
3436
3437<p>There is a similar ambiguity for unformatted input, formatted output, and unformatted
3438output. </p>
3439
3440<p>Comments from Judy Ward: It seems like the problem is that the
3441basic_istream and basic_ostream operator &lt;&lt;()'s that are used
3442for the manipulators and streambuf* are in the wrong section and
3443should have their own separate section or be modified to make it clear
3444that the "Common requirements" listed in section 27.6.1.2.1
3445(for basic_istream) and section 27.6.2.5.1 (for basic_ostream) do not
3446apply to them. </p>
3447
3448<p>Additional comments from Dietmar K�hl: It appears to be somewhat
3449nonsensical to consider the functions defined in 27.7.1.2.3
3450[istream::extractors] paragraphs 1 to 5 to be "Formatted input
3451function" but since these functions are defined in a section
3452labeled "Formatted input functions" it is unclear to me
3453whether these operators are considered formatted input functions which
3454have to conform to the "common requirements" from 27.7.1.2.1
3455[istream.formatted.reqmts]: If this is the case, all manipulators, not
3456just <tt>ws</tt>, would skip whitespace unless <tt>noskipws</tt> is
3457set (... but setting <tt>noskipws</tt> using the manipulator syntax
3458would also skip whitespace :-)</p> <p>It is not clear which functions
3459are to be considered unformatted input functions. As written, it seems
3460that all functions in 27.7.1.3 [istream.unformatted] are unformatted input
3461functions. However, it does not really make much sense to construct a
3462sentry object for <tt>gcount()</tt>, <tt>sync()</tt>, ... Also it is
3463unclear what happens to the <tt>gcount()</tt> if
3464eg. <tt>gcount()</tt>, <tt>putback()</tt>, <tt>unget()</tt>, or
3465<tt>sync()</tt> is called: These functions don't extract characters,
3466some of them even "unextract" a character. Should this still
3467be reflected in <tt>gcount()</tt>? Of course, it could be read as if
3468after a call to <tt>gcount()</tt> <tt>gcount()</tt> return <tt>0</tt>
3469(the last unformatted input function, <tt>gcount()</tt>, didn't
3470extract any character) and after a call to <tt>putback()</tt>
3471<tt>gcount()</tt> returns <tt>-1</tt> (the last unformatted input
3472function <tt>putback()</tt> did "extract" back into the
3473stream). Correspondingly for <tt>unget()</tt>. Is this what is
3474intended?  If so, this should be clarified. Otherwise, a corresponding
3475clarification should be used.</p>
3476
3477
3478<p><b>Proposed resolution:</b></p>
3479<p>
3480In 27.6.1.2.2 [lib.istream.formatted.arithmetic], paragraph 1.
3481Change the beginning of the second sentence from "The conversion
3482occurs" to "These extractors behave as formatted input functions (as
3483described in 27.6.1.2.1).  After a sentry object is constructed,
3484the conversion occurs"
3485</p>
3486
3487<p>
3488In 27.6.1.2.3, [lib.istream::extractors], before paragraph 1.
3489Add an effects clause.  "Effects: None.  This extractor does
3490not behave as a formatted input function (as described in
349127.6.1.2.1).
3492</p>
3493
3494<p>
3495In 27.6.1.2.3, [lib.istream::extractors], paragraph 2.  Change the
3496effects clause to "Effects: Calls pf(*this).  This extractor does not
3497behave as a formatted input function (as described in 27.6.1.2.1).
3498</p>
3499
3500<p>
3501In 27.6.1.2.3, [lib.istream::extractors], paragraph 4.  Change the
3502effects clause to "Effects: Calls pf(*this).  This extractor does not
3503behave as a formatted input function (as described in 27.6.1.2.1).
3504</p>
3505
3506<p>
3507In 27.6.1.2.3, [lib.istream::extractors], paragraph 12.  Change the
3508first two sentences from "If sb is null, calls setstate(failbit),
3509which may throw ios_base::failure (27.4.4.3).  Extracts characters
3510from *this..." to "Behaves as a formatted input function (as described
3511in 27.6.1.2.1).  If sb is null, calls setstate(failbit), which may
3512throw ios_base::failure (27.4.4.3).  After a sentry object is
3513constructed, extracts characters from *this...".
3514</p>
3515
3516<p>
3517In 27.6.1.3, [lib.istream.unformatted], before paragraph 2.  Add an
3518effects clause.  "Effects: none. This member function does not behave
3519as an unformatted input function (as described in 27.6.1.3, paragraph 1)."
3520</p>
3521
3522<p>
3523In 27.6.1.3, [lib.istream.unformatted], paragraph 3.  Change the
3524beginning of the first sentence of the effects clause from "Extracts a
3525character" to "Behaves as an unformatted input function (as described
3526in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts a
3527character"
3528</p>
3529
3530<p>
3531In 27.6.1.3, [lib.istream.unformatted], paragraph 5.  Change the
3532beginning of the first sentence of the effects clause from "Extracts a
3533character" to "Behaves as an unformatted input function (as described
3534in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts a
3535character"
3536</p>
3537
3538<p>
3539In 27.6.1.3, [lib.istream.unformatted], paragraph 7.  Change the
3540beginning of the first sentence of the effects clause from "Extracts
3541characters" to "Behaves as an unformatted input function (as described
3542in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts
3543characters"
3544</p>
3545
3546<p>
3547[No change needed in paragraph 10, because it refers to paragraph 7.]
3548</p>
3549
3550<p>
3551In 27.6.1.3, [lib.istream.unformatted], paragraph 12.  Change the
3552beginning of the first sentence of the effects clause from "Extracts
3553characters" to "Behaves as an unformatted input function (as described
3554in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts
3555characters"
3556</p>
3557
3558<p>
3559[No change needed in paragraph 15.]
3560</p>
3561
3562<p>
3563In 27.6.1.3, [lib.istream.unformatted], paragraph 17.  Change the
3564beginning of the first sentence of the effects clause from "Extracts
3565characters" to "Behaves as an unformatted input function (as described
3566in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts
3567characters"
3568</p>
3569
3570<p>
3571[No change needed in paragraph 23.]
3572</p>
3573
3574<p>
3575In 27.6.1.3, [lib.istream.unformatted], paragraph 24.  Change the
3576beginning of the first sentence of the effects clause from "Extracts
3577characters" to "Behaves as an unformatted input function (as described
3578in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts
3579characters"
3580</p>
3581
3582<p>
3583In 27.6.1.3, [lib.istream.unformatted], before paragraph 27.  Add an
3584Effects clause: "Effects: Behaves as an unformatted input function (as
3585described in 27.6.1.3, paragraph 1).  After constructing a sentry
3586object, reads but does not extract the current input character."
3587</p>
3588
3589<p>
3590In 27.6.1.3, [lib.istream.unformatted], paragraph 28.  Change the
3591first sentence of the Effects clause from "If !good() calls" to
3592Behaves as an unformatted input function (as described in 27.6.1.3,
3593paragraph 1).  After constructing a sentry object, if !good() calls"
3594</p>
3595
3596<p>
3597In 27.6.1.3, [lib.istream.unformatted], paragraph 30.  Change the
3598first sentence of the Effects clause from "If !good() calls" to
3599"Behaves as an unformatted input function (as described in 27.6.1.3,
3600paragraph 1).  After constructing a sentry object, if !good() calls"
3601</p>
3602
3603<p>
3604In 27.6.1.3, [lib.istream.unformatted], paragraph 32.  Change the
3605first sentence of the Effects clause from "If !good() calls..." to
3606"Behaves as an unformatted input function (as described in 27.6.1.3,
3607paragraph 1).  After constructing a sentry object, if !good()
3608calls..."  Add a new sentence to the end of the Effects clause:
3609"[Note: this function extracts no characters, so the value returned
3610by the next call to gcount() is 0.]"
3611</p>
3612
3613<p>
3614In 27.6.1.3, [lib.istream.unformatted], paragraph 34.  Change the
3615first sentence of the Effects clause from "If !good() calls" to
3616"Behaves as an unformatted input function (as described in 27.6.1.3,
3617paragraph 1).  After constructing a sentry object, if !good() calls".
3618Add a new sentence to the end of the Effects clause: "[Note: this
3619function extracts no characters, so the value returned by the next
3620call to gcount() is 0.]"
3621</p>
3622
3623<p>
3624In 27.6.1.3, [lib.istream.unformatted], paragraph 36.  Change the
3625first sentence of the Effects clause from "If !rdbuf() is" to "Behaves
3626as an unformatted input function (as described in 27.6.1.3, paragraph
36271), except that it does not count the number of characters extracted
3628and does not affect the value returned by subsequent calls to
3629gcount().  After constructing a sentry object, if rdbuf() is"
3630</p>
3631
3632<p>
3633In 27.6.1.3, [lib.istream.unformatted], before paragraph 37.  Add an
3634Effects clause: "Effects: Behaves as an unformatted input function (as
3635described in 27.6.1.3, paragraph 1), except that it does not count the
3636number of characters extracted and does not affect the value returned
3637by subsequent calls to gcount()."  Change the first sentence of
3638paragraph 37 from "if fail()" to "after constructing a sentry object,
3639if fail()".
3640</p>
3641
3642<p>
3643In 27.6.1.3, [lib.istream.unformatted], paragraph 38.  Change the
3644first sentence of the Effects clause from "If fail()" to "Behaves
3645as an unformatted input function (as described in 27.6.1.3, paragraph
36461), except that it does not count the number of characters extracted
3647and does not affect the value returned by subsequent calls to
3648gcount().  After constructing a sentry object, if fail()
3649</p>
3650
3651<p>
3652In 27.6.1.3, [lib.istream.unformatted], paragraph 40.  Change the
3653first sentence of the Effects clause from "If fail()" to "Behaves
3654as an unformatted input function (as described in 27.6.1.3, paragraph
36551), except that it does not count the number of characters extracted
3656and does not affect the value returned by subsequent calls to
3657gcount().  After constructing a sentry object, if fail()
3658</p>
3659
3660<p>
3661In 27.6.2.5.2 [lib.ostream.inserters.arithmetic], paragraph 1.  Change
3662the beginning of the third sentence from "The formatting conversion"
3663to "These extractors behave as formatted output functions (as
3664described in 27.6.2.5.1).  After the sentry object is constructed, the
3665conversion occurs".
3666</p>
3667
3668<p>
3669In 27.6.2.5.3 [lib.ostream.inserters], before paragraph 1.  Add an
3670effects clause: "Effects: None. Does not behave as a formatted output
3671function (as described in 27.6.2.5.1).".
3672</p>
3673
3674<p>
3675In 27.6.2.5.3 [lib.ostream.inserters], paragraph 2.  Change the
3676effects clause to "Effects: calls pf(*this).  This extractor does not
3677behave as a formatted output function (as described in 27.6.2.5.1).".
3678</p>
3679
3680<p>
3681In 27.6.2.5.3 [lib.ostream.inserters], paragraph 4.  Change the
3682effects clause to "Effects: calls pf(*this).  This extractor does not
3683behave as a formatted output function (as described in 27.6.2.5.1).".
3684</p>
3685
3686<p>
3687In 27.6.2.5.3 [lib.ostream.inserters], paragraph 6.  Change the first
3688sentence from "If sb" to "Behaves as a formatted output function (as
3689described in 27.6.2.5.1).  After the sentry object is constructed, if
3690sb".
3691</p>
3692
3693<p>
3694In 27.6.2.6 [lib.ostream.unformatted], paragraph 2.  Change the first
3695sentence from "Inserts the character" to "Behaves as an unformatted
3696output function (as described in 27.6.2.6, paragraph 1).  After
3697constructing a sentry object, inserts the character".
3698</p>
3699
3700<p>
3701In 27.6.2.6 [lib.ostream.unformatted], paragraph 5.  Change the first
3702sentence from "Obtains characters" to "Behaves as an unformatted
3703output function (as described in 27.6.2.6, paragraph 1).  After
3704constructing a sentry object, obtains characters".
3705</p>
3706
3707<p>
3708In 27.6.2.6 [lib.ostream.unformatted], paragraph 7.  Add a new
3709sentence at the end of the paragraph: "Does not behave as an
3710unformatted output function (as described in 27.6.2.6, paragraph 1)."
3711</p>
3712
3713
3714<p><b>Rationale:</b></p>
3715<p>See J16/99-0043==WG21/N1219, Proposed Resolution to Library Issue 60,
3716by Judy Ward and Matt Austern.  This proposed resolution is section
3717VI of that paper.</p>
3718
3719
3720
3721
3722
3723<hr>
3724<h3><a name="61"></a>61. Ambiguity in iostreams exception policy</h3>
3725<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>
3726 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-08-06  <b>Last modified:</b> 2008-09-26</p>
3727<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>
3728<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>
3729<p><b>Discussion:</b></p>
3730<p>The introduction to the section on unformatted input (27.6.1.3)
3731says that every unformatted input function catches all exceptions that
3732were thrown during input, sets badbit, and then conditionally rethrows
3733the exception. That seems clear enough. Several of the specific
3734functions, however, such as get() and read(), are documented in some
3735circumstances as setting eofbit and/or failbit. (The standard notes,
3736correctly, that setting eofbit or failbit can sometimes result in an
3737exception being thrown.) The question: if one of these functions
3738throws an exception triggered by setting failbit, is this an exception
3739"thrown during input" and hence covered by 27.6.1.3, or does
374027.6.1.3 only refer to a limited class of exceptions? Just to make
3741this concrete, suppose you have the following snippet. </p>
3742
3743<pre>  
3744  char buffer[N];
3745  istream is;
3746  ...
3747  is.exceptions(istream::failbit); // Throw on failbit but not on badbit.
3748  is.read(buffer, N);</pre>
3749
3750<p>Now suppose we reach EOF before we've read N characters. What
3751iostate bits can we expect to be set, and what exception (if any) will
3752be thrown? </p>
3753
3754
3755<p><b>Proposed resolution:</b></p>
3756<p>
3757In 27.6.1.3, paragraph 1, after the sentence that begins
3758"If an exception is thrown...", add the following
3759parenthetical comment: "(Exceptions thrown from 
3760<tt>basic_ios&lt;&gt;::clear()</tt> are not caught or rethrown.)"
3761</p>
3762
3763
3764<p><b>Rationale:</b></p>
3765<p>The LWG looked to two alternative wordings, and choose the proposed
3766resolution as better standardese.</p>
3767
3768
3769
3770
3771
3772<hr>
3773<h3><a name="62"></a>62. <tt>Sync</tt>'s return value</h3>
3774<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>
3775 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-08-06  <b>Last modified:</b> 2008-09-26</p>
3776<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>
3777<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>
3778<p><b>Discussion:</b></p>
3779<p>The Effects clause for sync() (27.6.1.3, paragraph 36) says that it
3780"calls rdbuf()-&gt;pubsync() and, if that function returns -1
3781... returns traits::eof()." </p>
3782
3783<p>That looks suspicious, because traits::eof() is of type
3784traits::int_type while the return type of sync() is int. </p>
3785
3786
3787<p><b>Proposed resolution:</b></p>
3788<p>In 27.7.1.3 [istream.unformatted], paragraph 36, change "returns
3789<tt>traits::eof()</tt>" to "returns <tt>-1</tt>".
3790</p>
3791
3792
3793
3794
3795
3796<hr>
3797<h3><a name="63"></a>63. Exception-handling policy for unformatted output</h3>
3798<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>
3799 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-08-11  <b>Last modified:</b> 2008-09-26</p>
3800<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>
3801<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>
3802<p><b>Discussion:</b></p>
3803<p>Clause 27 details an exception-handling policy for formatted input,
3804unformatted input, and formatted output. It says nothing for
3805unformatted output (27.6.2.6). 27.6.2.6 should either include the same
3806kind of exception-handling policy as in the other three places, or
3807else it should have a footnote saying that the omission is
3808deliberate. </p>
3809
3810
3811<p><b>Proposed resolution:</b></p>
3812<p>
3813In 27.6.2.6, paragraph 1, replace the last sentence ("In any
3814case, the unformatted output function ends by destroying the sentry
3815object, then returning the value specified for the formatted output
3816function.") with the following text:
3817</p>
3818<blockquote><p>
3819If an exception is thrown during output, then <tt>ios::badbit</tt> is
3820turned on [Footnote: without causing an <tt>ios::failure</tt> to be
3821thrown.] in <tt>*this</tt>'s error state. If <tt>(exceptions() &amp;
3822badbit) != 0</tt> then the exception is rethrown.  In any case, the
3823unformatted output function ends by destroying the sentry object,
3824then, if no exception was thrown, returning the value specified for
3825the formatted output function.
3826</p></blockquote>
3827
3828
3829<p><b>Rationale:</b></p>
3830<p>
3831This exception-handling policy is consistent with that of formatted
3832input, unformatted input, and formatted output.
3833</p>
3834
3835
3836
3837
3838
3839<hr>
3840<h3><a name="64"></a>64. Exception handling in <tt>basic_istream::operator&gt;&gt;(basic_streambuf*)</tt></h3>
3841<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>
3842 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-08-11  <b>Last modified:</b> 2008-09-26</p>
3843<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>
3844<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>
3845<p><b>Discussion:</b></p>
3846<p>27.6.1.2.3, paragraph 13, is ambiguous. It can be interpreted two
3847different ways, depending on whether the second sentence is read as an
3848elaboration of the first. </p>
3849
3850
3851<p><b>Proposed resolution:</b></p>
3852<p>Replace 27.7.1.2.3 [istream::extractors], paragraph 13, which begins
3853"If the function inserts no characters ..." with:</p>
3854
3855<blockquote>
3856  <p>If the function inserts no characters, it calls
3857  <tt>setstate(failbit)</tt>, which may throw
3858  <tt>ios_base::failure</tt> (27.4.4.3). If it inserted no characters
3859  because it caught an exception thrown while extracting characters
3860  from <tt>sb</tt> and <tt>failbit</tt> is on in <tt>exceptions()</tt>
3861  (27.4.4.3), then the caught exception is rethrown. </p>
3862</blockquote>
3863
3864
3865
3866
3867
3868<hr>
3869<h3><a name="66"></a>66. Strstreambuf::setbuf</h3>
3870<p><b>Section:</b> D.8.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>
3871 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-08-18  <b>Last modified:</b> 2008-09-26</p>
3872<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>
3873<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>
3874<p><b>Discussion:</b></p>
3875<p>D.7.1.3, paragraph 19, says that strstreambuf::setbuf
3876"Performs an operation that is defined separately for each class
3877derived from strstreambuf". This is obviously an incorrect
3878cut-and-paste from basic_streambuf. There are no classes derived from
3879strstreambuf. </p>
3880
3881
3882<p><b>Proposed resolution:</b></p>
3883<p>D.8.1.3 [depr.strstreambuf.virtuals], paragraph 19, replace the setbuf effects
3884clause which currently says "Performs an operation that is
3885defined separately for each class derived from strstreambuf"
3886with:</p>
3887
3888<blockquote>
3889  <p><b>Effects</b>: implementation defined, except that
3890  <tt>setbuf(0,0)</tt> has no effect.</p>
3891</blockquote>
3892
3893
3894
3895
3896
3897<hr>
3898<h3><a name="68"></a>68. Extractors for char* should store null at end</h3>
3899<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>
3900 <b>Submitter:</b> Angelika Langer <b>Opened:</b> 1998-07-14  <b>Last modified:</b> 2008-09-26</p>
3901<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>
3902<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>
3903<p><b>Discussion:</b></p>
3904<p>Extractors for char* (27.6.1.2.3) do not store a null character
3905after the extracted character sequence whereas the unformatted
3906functions like get() do. Why is this?</p>
3907
3908<p>Comment from Jerry Schwarz: There is apparently an editing
3909glitch. You'll notice that the last item of the list of what stops
3910extraction doesn't make any sense. It was supposed to be the line that
3911said a null is stored.</p>
3912
3913
3914<p><b>Proposed resolution:</b></p>
3915<p>27.7.1.2.3 [istream::extractors], paragraph 7, change the last list
3916item from:</p>
3917
3918<blockquote><p>
3919  A null byte (<tt>charT()</tt>) in the next position, which may be
3920  the first position if no characters were extracted.
3921</p></blockquote>
3922
3923<p>to become a new paragraph which reads:</p>
3924
3925<blockquote><p>
3926  Operator&gt;&gt; then stores a null byte (<tt>charT()</tt>) in the
3927  next position, which may be the first position if no characters were
3928  extracted.
3929</p></blockquote>
3930
3931
3932
3933
3934
3935<hr>
3936<h3><a name="69"></a>69. Must elements of a vector be contiguous?</h3>
3937<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>
3938 <b>Submitter:</b> Andrew Koenig <b>Opened:</b> 1998-07-29  <b>Last modified:</b> 2008-09-26</p>
3939<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>
3940<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>
3941<p><b>Discussion:</b></p>
3942<p>The issue is this: Must the elements of a vector be in contiguous memory?</p>
3943
3944<p>(Please note that this is entirely separate from the question of
3945whether a vector iterator is required to be a pointer; the answer to
3946that question is clearly "no," as it would rule out
3947debugging implementations)</p>
3948
3949
3950<p><b>Proposed resolution:</b></p>
3951<p>Add the following text to the end of 23.3.6 [vector],
3952paragraph 1. </p>
3953
3954<blockquote>
3955  <p>The elements of a vector are stored contiguously, meaning that if
3956  v is a <tt>vector&lt;T, Allocator&gt;</tt> where T is some type
3957  other than <tt>bool</tt>, then it obeys the identity <tt>&amp;v[n]
3958  == &amp;v[0] + n</tt> for all <tt>0 &lt;= n &lt; v.size()</tt>.</p>
3959</blockquote>
3960
3961
3962<p><b>Rationale:</b></p>
3963<p>The LWG feels that as a practical matter the answer is clearly
3964"yes".  There was considerable discussion as to the best way
3965to express the concept of "contiguous", which is not
3966directly defined in the standard.  Discussion included:</p>
3967
3968<ul>
3969  <li>An operational definition similar to the above proposed resolution is 
3970    already used for valarray (26.6.2.3 [valarray.access]).</li>
3971  <li>There is no need to explicitly consider a user-defined operator&amp; 
3972    because elements must be copyconstructible (23.2 [container.requirements] para 3) 
3973    and copyconstructible (20.2.1 [utility.arg.requirements]) specifies
3974    requirements for operator&amp;.</li>
3975  <li>There is no issue of one-past-the-end because of language rules.</li>
3976</ul>
3977
3978
3979
3980
3981
3982<hr>
3983<h3><a name="70"></a>70. Uncaught_exception() missing throw() specification</h3>
3984<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>
3985 <b>Submitter:</b> Steve Clamage <b>Opened:</b> 1998-08-03  <b>Last modified:</b> 2008-09-26</p>
3986<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>
3987<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>
3988<p><b>Discussion:</b></p>
3989<p>In article 3E04@pratique.fr, Valentin Bonnard writes: </p>
3990
3991<p>uncaught_exception() doesn't have a throw specification.</p>
3992
3993<p>It is intentional ? Does it means that one should be prepared to
3994handle exceptions thrown from uncaught_exception() ?</p>
3995
3996<p>uncaught_exception() is called in exception handling contexts where
3997exception safety is very important.</p>
3998
3999
4000<p><b>Proposed resolution:</b></p>
4001<p>In 15.5.3 [except.uncaught], paragraph 1, 18.8 [support.exception],
4002and 18.8.4 [uncaught], add "throw()" to uncaught_exception().</p>
4003
4004
4005
4006
4007<hr>
4008<h3><a name="71"></a>71. Do_get_monthname synopsis missing argument</h3>
4009<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>
4010 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-13  <b>Last modified:</b> 2008-09-26</p>
4011<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>
4012<p><b>Discussion:</b></p>
4013<p>The locale facet member <tt>time_get&lt;&gt;::do_get_monthname</tt>
4014is described in 22.4.5.1.2 [locale.time.get.virtuals] with five arguments,
4015consistent with do_get_weekday and with its specified use by member
4016get_monthname. However, in the synopsis, it is specified instead with
4017four arguments. The missing argument is the "end" iterator
4018value.</p>
4019
4020
4021<p><b>Proposed resolution:</b></p>
4022<p>In 22.4.5.1 [locale.time.get], add an "end" argument to
4023the declaration of member do_monthname as follows:</p>
4024
4025<pre>  virtual iter_type do_get_monthname(iter_type s, iter_type end, ios_base&amp;,
4026                                     ios_base::iostate&amp; err, tm* t) const;</pre>
4027
4028
4029
4030
4031<hr>
4032<h3><a name="74"></a>74. Garbled text for <tt>codecvt::do_max_length</tt></h3>
4033<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>
4034 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-09-08  <b>Last modified:</b> 2008-09-26</p>
4035<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>
4036<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>
4037<p><b>Discussion:</b></p>
4038<p>The text of <tt>codecvt::do_max_length</tt>'s "Returns"
4039clause (22.2.1.5.2, paragraph 11) is garbled. It has unbalanced
4040parentheses and a spurious <b>n</b>.</p>
4041
4042
4043<p><b>Proposed resolution:</b></p>
4044<p>Replace 22.4.1.4.2 [locale.codecvt.virtuals] paragraph 11 with the
4045following:</p>
4046
4047<blockquote><p>
4048  <b>Returns</b>: The maximum value that
4049  <tt>do_length(state, from, from_end, 1)</tt> can return for any
4050  valid range <tt>[from, from_end)</tt> and <tt>stateT</tt> value
4051  <tt>state</tt>. The specialization <tt>codecvt&lt;char, char,
4052  mbstate_t&gt;::do_max_length()</tt> returns 1.
4053</p></blockquote>
4054
4055
4056
4057
4058<hr>
4059<h3><a name="75"></a>75. Contradiction in <tt>codecvt::length</tt>'s argument types</h3>
4060<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>
4061 <b>Submitter:</b>  Matt
4062Austern <b>Opened:</b> 1998-09-18  <b>Last modified:</b> 2008-09-26</p>
4063<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>
4064<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>
4065<p><b>Discussion:</b></p>
4066<p>The class synopses for classes <tt>codecvt&lt;&gt;</tt> (22.2.1.5)
4067and <tt>codecvt_byname&lt;&gt;</tt> (22.2.1.6) say that the first
4068parameter of the member functions <tt>length</tt> and
4069<tt>do_length</tt> is of type <tt>const stateT&amp;</tt>. The member
4070function descriptions, however (22.2.1.5.1, paragraph 6; 22.2.1.5.2,
4071paragraph 9) say that the type is <tt>stateT&amp;</tt>.  Either the
4072synopsis or the summary must be changed. </p>
4073
4074<p>If (as I believe) the member function descriptions are correct,
4075then we must also add text saying how <tt>do_length</tt> changes its
4076<tt>stateT</tt> argument. </p>
4077
4078
4079<p><b>Proposed resolution:</b></p>
4080<p>In 22.4.1.4 [locale.codecvt], and also in 22.4.1.5 [locale.codecvt.byname],
4081change the <tt>stateT</tt> argument type on both member
4082<tt>length()</tt> and member <tt>do_length()</tt> from </p>
4083
4084<blockquote>
4085  <p><tt>const stateT&amp;</tt></p>
4086</blockquote>
4087
4088<p>to</p>
4089
4090<blockquote>
4091  <p><tt>stateT&amp;</tt></p>
4092</blockquote>
4093
4094<p>In 22.4.1.4.2 [locale.codecvt.virtuals], add to the definition for member
4095<tt>do_length</tt> a paragraph:</p>
4096
4097<blockquote>
4098  <p>Effects: The effect on the <tt>state</tt> argument is ``as if''
4099  it called <tt>do_in(state, from, from_end, from, to, to+max,
4100  to)</tt> for <tt>to</tt> pointing to a buffer of at least
4101  <tt>max</tt> elements.</p>
4102</blockquote>
4103
4104
4105
4106
4107<hr>
4108<h3><a name="76"></a>76. Can a <tt>codecvt</tt> facet always convert one internal character at a time?</h3>
4109<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>
4110 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-09-25  <b>Last modified:</b> 2008-09-26</p>
4111<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>
4112<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
4113<p><b>Discussion:</b></p>
4114<p>This issue concerns the requirements on classes derived from
4115<tt>codecvt</tt>, including user-defined classes. What are the
4116restrictions on the conversion from external characters
4117(e.g. <tt>char</tt>) to internal characters (e.g. <tt>wchar_t</tt>)?
4118Or, alternatively, what assumptions about <tt>codecvt</tt> facets can
4119the I/O library make? </p>
4120
4121<p>The question is whether it's possible to convert from internal
4122characters to external characters one internal character at a time,
4123and whether, given a valid sequence of external characters, it's
4124possible to pick off internal characters one at a time. Or, to put it
4125differently: given a sequence of external characters and the
4126corresponding sequence of internal characters, does a position in the
4127internal sequence correspond to some position in the external
4128sequence? </p>
4129
4130<p>To make this concrete, suppose that <tt>[first, last)</tt> is a
4131sequence of <i>M</i> external characters and that <tt>[ifirst,
4132ilast)</tt> is the corresponding sequence of <i>N</i> internal
4133characters, where <i>N &gt; 1</i>. That is, <tt>my_encoding.in()</tt>,
4134applied to <tt>[first, last)</tt>, yields <tt>[ifirst,
4135ilast)</tt>. Now the question: does there necessarily exist a
4136subsequence of external characters, <tt>[first, last_1)</tt>, such
4137that the corresponding sequence of internal characters is the single
4138character <tt>*ifirst</tt>?
4139</p>
4140
4141<p>(What a "no" answer would mean is that
4142<tt>my_encoding</tt> translates sequences only as blocks. There's a
4143sequence of <i>M</i> external characters that maps to a sequence of
4144<i>N</i> internal characters, but that external sequence has no
4145subsequence that maps to <i>N-1</i> internal characters.) </p>
4146
4147<p>Some of the wording in the standard, such as the description of
4148<tt>codecvt::do_max_length</tt> (22.4.1.4.2 [locale.codecvt.virtuals],
4149paragraph 11) and <tt>basic_filebuf::underflow</tt> (27.9.1.5 [filebuf.virtuals], paragraph 3) suggests that it must always be
4150possible to pick off internal characters one at a time from a sequence
4151of external characters. However, this is never explicitly stated one
4152way or the other. </p>
4153
4154<p>This issue seems (and is) quite technical, but it is important if
4155we expect users to provide their own encoding facets. This is an area
4156where the standard library calls user-supplied code, so a well-defined
4157set of requirements for the user-supplied code is crucial. Users must
4158be aware of the assumptions that the library makes. This issue affects
4159positioning operations on <tt>basic_filebuf</tt>, unbuffered input,
4160and several of <tt>codecvt</tt>'s member functions. </p>
4161
4162
4163<p><b>Proposed resolution:</b></p>
4164<p>Add the following text as a new paragraph, following 22.4.1.4.2 [locale.codecvt.virtuals] paragraph 2:</p>
4165
4166<blockquote>
4167<p>A <tt>codecvt</tt> facet that is used by <tt>basic_filebuf</tt>
4168(27.9 [file.streams]) must have the property that if</p>
4169<pre>    do_out(state, from, from_end, from_next, to, to_lim, to_next)
4170</pre>
4171<p>would return <tt>ok</tt>, where <tt>from != from_end</tt>, then </p>
4172<pre>    do_out(state, from, from + 1, from_next, to, to_end, to_next)
4173</pre>
4174<p>must also return <tt>ok</tt>, and that if</p>
4175<pre>    do_in(state, from, from_end, from_next, to, to_lim, to_next)
4176</pre>
4177<p>would return <tt>ok</tt>, where <tt>to != to_lim</tt>, then</p>
4178<pre>    do_in(state, from, from_end, from_next, to, to + 1, to_next)
4179</pre>
4180<p>must also return <tt>ok</tt>.  [<i>Footnote:</i> Informally, this
4181means that <tt>basic_filebuf</tt> assumes that the mapping from
4182internal to external characters is 1 to N: a <tt>codecvt</tt> that is
4183used by <tt>basic_filebuf</tt> must be able to translate characters
4184one internal character at a time.  <i>--End Footnote</i>]</p>
4185</blockquote>
4186
4187<p><i>[Redmond: Minor change in proposed resolution.  Original
4188proposed resolution talked about "success", with a parenthetical
4189comment that success meant returning <tt>ok</tt>.  New wording
4190removes all talk about "success", and just talks about the
4191return value.]</i></p>
4192
4193
4194
4195
4196<p><b>Rationale:</b></p>
4197
4198  <p>The proposed resoluion says that conversions can be performed one
4199  internal character at a time.  This rules out some encodings that
4200  would otherwise be legal.  The alternative answer would mean there
4201  would be some internal positions that do not correspond to any
4202  external file position.</p>
4203  <p>
4204  An example of an encoding that this rules out is one where the
4205  <tt>internT</tt> and <tt>externT</tt> are of the same type, and
4206  where the internal sequence <tt>c1 c2</tt> corresponds to the
4207  external sequence <tt>c2 c1</tt>.
4208  </p>
4209  <p>It was generally agreed that <tt>basic_filebuf</tt> relies
4210  on this property: it was designed under the assumption that
4211  the external-to-internal mapping is N-to-1, and it is not clear
4212  that <tt>basic_filebuf</tt> is implementable without that 
4213  restriction.
4214  </p>
4215  <p>
4216  The proposed resolution is expressed as a restriction on
4217  <tt>codecvt</tt> when used by <tt>basic_filebuf</tt>, rather
4218  than a blanket restriction on all <tt>codecvt</tt> facets,
4219  because <tt>basic_filebuf</tt> is the only other part of the 
4220  library that uses <tt>codecvt</tt>.  If a user wants to define
4221  a <tt>codecvt</tt> facet that implements a more general N-to-M
4222  mapping, there is no reason to prohibit it, so long as the user
4223  does not expect <tt>basic_filebuf</tt> to be able to use it.
4224  </p>
4225
4226
4227
4228
4229
4230<hr>
4231<h3><a name="78"></a>78. Typo: event_call_back</h3>
4232<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>
4233 <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29  <b>Last modified:</b> 2008-09-26</p>
4234<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>
4235<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>
4236<p><b>Discussion:</b></p>
4237<p>typo: event_call_back should be event_callback &nbsp; </p>
4238
4239
4240<p><b>Proposed resolution:</b></p>
4241<p>In the 27.5.2 [ios.base] synopsis change
4242"event_call_back" to "event_callback". </p>
4243
4244
4245
4246
4247<hr>
4248<h3><a name="79"></a>79. Inconsistent declaration of polar()</h3>
4249<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>
4250 <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29  <b>Last modified:</b> 2009-03-21</p>
4251<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>
4252<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>
4253<p><b>Discussion:</b></p>
4254<p>In 26.4.1 [complex.syn] polar is declared as follows:</p>
4255<pre>   template&lt;class T&gt; complex&lt;T&gt; polar(const T&amp;, const T&amp;); </pre>
4256
4257<p>In 26.4.7 [complex.value.ops] it is declared as follows:</p>
4258<pre>   template&lt;class T&gt; complex&lt;T&gt; polar(const T&amp; rho, const T&amp; theta = 0); </pre>
4259
4260<p>Thus whether the second parameter is optional is not clear. </p>
4261
4262
4263<p><b>Proposed resolution:</b></p>
4264<p>In 26.4.1 [complex.syn] change:</p>
4265<pre>   template&lt;class T&gt; complex&lt;T&gt; polar(const T&amp;, const T&amp;);</pre>
4266
4267<p>to:</p>
4268<pre>   template&lt;class T&gt; complex&lt;T&gt; polar(const T&amp; rho, const T&amp; theta = 0); </pre>
4269
4270
4271
4272
4273
4274<hr>
4275<h3><a name="80"></a>80. Global Operators of complex declared twice</h3>
4276<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>
4277 <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29  <b>Last modified:</b> 2009-03-21</p>
4278<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>
4279<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>
4280<p><b>Discussion:</b></p>
4281<p>Both 26.2.1 and 26.2.2 contain declarations of global operators for
4282class complex. This redundancy should be removed.</p>
4283
4284
4285<p><b>Proposed resolution:</b></p>
4286<p>Reduce redundancy according to the general style of the standard. </p>
4287
4288
4289
4290
4291<hr>
4292<h3><a name="83"></a>83. String::npos vs. string::max_size()</h3>
4293<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>
4294 <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29  <b>Last modified:</b> 2008-09-26</p>
4295<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>
4296<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>
4297<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#89">89</a></p>
4298<p><b>Discussion:</b></p>
4299<p>Many string member functions throw if size is getting or exceeding
4300npos. However, I wonder why they don't throw if size is getting or
4301exceeding max_size() instead of npos.  May be npos is known at compile
4302time, while max_size() is known at runtime. However, what happens if
4303size exceeds max_size() but not npos, then? It seems the standard
4304lacks some clarifications here.</p>
4305
4306
4307<p><b>Proposed resolution:</b></p>
4308<p>After 21.4 [basic.string] paragraph 4 ("The functions
4309described in this clause...") add a new paragraph:</p>
4310
4311<blockquote>
4312  <p>For any string operation, if as a result of the operation, <tt> size()</tt> would exceed
4313  <tt> max_size()</tt> then
4314  the operation throws <tt>length_error</tt>.</p>
4315</blockquote>
4316
4317
4318<p><b>Rationale:</b></p>
4319<p>The LWG believes length_error is the correct exception to throw.</p>
4320
4321
4322
4323
4324<hr>
4325<h3><a name="86"></a>86. String constructors don't describe exceptions</h3>
4326<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>
4327 <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29  <b>Last modified:</b> 2008-09-26</p>
4328<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>
4329<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>
4330<p><b>Discussion:</b></p>
4331<p>The constructor from a range:</p>
4332
4333<pre>template&lt;class InputIterator&gt; 
4334         basic_string(InputIterator begin, InputIterator end, 
4335                      const Allocator&amp; a = Allocator());</pre>
4336
4337<p>lacks a throws clause. However, I would expect that it throws
4338according to the other constructors if the numbers of characters in
4339the range equals npos (or exceeds max_size(), see above). </p>
4340
4341
4342<p><b>Proposed resolution:</b></p>
4343<p>In 21.4.1 [string.require], Strike throws paragraphs for
4344constructors which say "Throws: length_error if n ==
4345npos."</p>
4346
4347
4348<p><b>Rationale:</b></p>
4349<p>Throws clauses for length_error if n == npos are no longer needed
4350because they are subsumed by the general wording added by the
4351resolution for issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>.</p>
4352
4353
4354
4355
4356<hr>
4357<h3><a name="90"></a>90. Incorrect description of operator &gt;&gt; for strings</h3>
4358<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>
4359 <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29  <b>Last modified:</b> 2008-09-26</p>
4360<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>
4361<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>
4362<p><b>Discussion:</b></p>
4363<p>The effect of operator &gt;&gt; for strings contain the following item:</p>
4364
4365<p>&nbsp;&nbsp;&nbsp; <tt>isspace(c,getloc())</tt> is true for the next available input
4366character c.</p>
4367
4368<p>Here <tt>getloc()</tt> has to be replaced by <tt>is.getloc()</tt>. </p>
4369
4370
4371<p><b>Proposed resolution:</b></p>
4372<p>In 21.4.8.9 [string.io] paragraph 1 Effects clause replace:</p>
4373
4374<blockquote>
4375  <p><tt>isspace(c,getloc())</tt> is true for the next available input character c.</p>
4376</blockquote>
4377
4378<p>with:</p>
4379
4380<blockquote>
4381  <p><tt>isspace(c,is.getloc())</tt> is true for the next available input character c.</p>
4382</blockquote>
4383
4384
4385
4386
4387
4388<hr>
4389<h3><a name="91"></a>91. Description of operator&gt;&gt; and getline() for string&lt;&gt; might cause endless loop</h3>
4390<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>
4391 <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29  <b>Last modified:</b> 2008-09-26</p>
4392<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>
4393<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
4394<p><b>Discussion:</b></p>
4395<p>Operator &gt;&gt; and getline() for strings read until eof()
4396in the input stream is true. However, this might never happen, if the
4397stream can't read anymore without reaching EOF. So shouldn't it be
4398changed into that it reads until !good() ? </p>
4399
4400
4401<p><b>Proposed resolution:</b></p>
4402<p>In 21.4.8.9 [string.io], paragraph 1, replace:</p>
4403<blockquote><p>
4404Effects: Begins by constructing a sentry object k as if k were
4405constructed by typename basic_istream&lt;charT,traits&gt;::sentry k( is). If
4406bool( k) is true, it calls str.erase() and then extracts characters
4407from is and appends them to str as if by calling str.append(1, c). If
4408is.width() is greater than zero, the maximum number n of characters
4409appended is is.width(); otherwise n is str.max_size(). Characters are
4410extracted and appended until any of the following occurs:
4411</p></blockquote>
4412<p>with:</p>
4413<blockquote><p>
4414Effects: Behaves as a formatted input function (27.7.1.2.1
4415[istream.formatted.reqmts]). After constructing a sentry object, if the
4416sentry converts to true, calls str.erase() and then extracts
4417characters from is and appends them to str as if by calling
4418str.append(1,c). If is.width() is greater than zero, the maximum
4419number n of characters appended is is.width(); otherwise n is
4420str.max_size(). Characters are extracted and appended until any of the
4421following occurs:
4422</p></blockquote>
4423
4424<p>In 21.4.8.9 [string.io], paragraph 6, replace</p>
4425<blockquote><p>
4426Effects: Begins by constructing a sentry object k as if by typename
4427basic_istream&lt;charT,traits&gt;::sentry k( is, true). If bool( k) is true,
4428it calls str.erase() and then extracts characters from is and appends
4429them to str as if by calling str.append(1, c) until any of the
4430following occurs:
4431</p></blockquote>
4432<p>with:</p>
4433<blockquote><p>Effects: Behaves as an unformatted input function
4434(27.7.1.3 [istream.unformatted]), except that it does not affect the
4435value returned
4436by subsequent calls to basic_istream&lt;&gt;::gcount(). After
4437constructing a sentry object, if the sentry converts to true, calls
4438str.erase() and then extracts characters from is and appends them to
4439str as if by calling str.append(1,c) until any of the following
4440occurs:
4441</p></blockquote>
4442
4443<p><i>[Redmond: Made changes in proposed resolution.  <tt>operator&gt;&gt;</tt>
4444should be a formatted input function, not an unformatted input function.
4445<tt>getline</tt> should not be required to set <tt>gcount</tt>, since
4446there is no mechanism for <tt>gcount</tt> to be set except by one of
4447<tt>basic_istream</tt>'s member functions.]</i></p>
4448
4449
4450<p><i>[Cura�ao: Nico agrees with proposed resolution.]</i></p>
4451
4452
4453
4454
4455<p><b>Rationale:</b></p>
4456<p>The real issue here is whether or not these string input functions
4457get their characters from a streambuf, rather than by calling an
4458istream's member functions, a streambuf signals failure either by
4459returning eof or by throwing an exception; there are no other
4460possibilities.  The proposed resolution makes it clear that these two
4461functions do get characters from a streambuf.</p>
4462
4463
4464
4465
4466
4467<hr>
4468<h3><a name="92"></a>92. Incomplete Algorithm Requirements</h3>
4469<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>
4470 <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29  <b>Last modified:</b> 2008-09-26</p>
4471<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#algorithms">active issues</a> in [algorithms].</p>
4472<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>
4473<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
4474<p><b>Discussion:</b></p>
4475<p>The standard does not state, how often a function object is copied,
4476called, or the order of calls inside an algorithm. This may lead to
4477surprising/buggy behavior. Consider the following example: </p>
4478
4479<pre>class Nth {    // function object that returns true for the nth element 
4480  private: 
4481    int nth;     // element to return true for 
4482    int count;   // element counter 
4483  public: 
4484    Nth (int n) : nth(n), count(0) { 
4485    } 
4486    bool operator() (int) { 
4487        return ++count == nth; 
4488    } 
4489}; 
4490.... 
4491// remove third element 
4492    list&lt;int&gt;::iterator pos; 
4493    pos = remove_if(coll.begin(),coll.end(),  // range 
4494                    Nth(3)),                  // remove criterion 
4495    coll.erase(pos,coll.end()); </pre>
4496
4497<p>This call, in fact removes the 3rd <b>AND the 6th</b> element. This
4498happens because the usual implementation of the algorithm copies the
4499function object internally: </p>
4500
4501<pre>template &lt;class ForwIter, class Predicate&gt; 
4502ForwIter std::remove_if(ForwIter beg, ForwIter end, Predicate op) 
4503{ 
4504    beg = find_if(beg, end, op); 
4505    if (beg == end) { 
4506        return beg; 
4507    } 
4508    else { 
4509        ForwIter next = beg; 
4510        return remove_copy_if(++next, end, beg, op); 
4511    } 
4512} </pre>
4513
4514<p>The algorithm uses find_if() to find the first element that should
4515be removed. However, it then uses a copy of the passed function object
4516to process the resulting elements (if any). Here, Nth is used again
4517and removes also the sixth element. This behavior compromises the
4518advantage of function objects being able to have a state. Without any
4519cost it could be avoided (just implement it directly instead of
4520calling find_if()). </p>
4521
4522
4523<p><b>Proposed resolution:</b></p>
4524
4525<p>Add a new paragraph following 25 [algorithms] paragraph 8:</p>
4526<blockquote><p>
4527[Note: Unless otherwise specified, algorithms that take function
4528objects as arguments are permitted to copy those function objects
4529freely.  Programmers for whom object identity is important should
4530consider using a wrapper class that points to a noncopied
4531implementation object, or some equivalent solution.]
4532</p></blockquote>
4533
4534<p><i>[Dublin: Pete Becker felt that this may not be a defect,
4535but rather something that programmers need to be educated about.
4536There was discussion of adding wording to the effect that the number
4537and order of calls to function objects, including predicates, not
4538affect the behavior of the function object.]</i></p>
4539
4540
4541<p><i>[Pre-Kona: Nico comments: It seems the problem is that we don't
4542have a clear statement of "predicate" in the
4543standard. People including me seemed to think "a function
4544returning a Boolean value and being able to be called by an STL
4545algorithm or be used as sorting criterion or ... is a
4546predicate". But a predicate has more requirements: It should
4547never change its behavior due to a call or being copied. IMHO we have
4548to state this in the standard. If you like, see section 8.1.4 of my
4549library book for a detailed discussion.]</i></p>
4550
4551
4552<p><i>[Kona: Nico will provide wording to the effect that "unless
4553otherwise specified, the number of copies of and calls to function
4554objects by algorithms is unspecified".&nbsp; Consider placing in
455525 [algorithms] after paragraph 9.]</i></p>
4556
4557
4558<p><i>[Santa Cruz: The standard doesn't currently guarantee that
4559  functions object won't be copied, and what isn't forbidden is
4560  allowed.  It is believed (especially since implementations that were
4561  written in concert with the standard do make copies of function
4562  objects) that this was intentional.  Thus, no normative change is
4563  needed.  What we should put in is a non-normative note suggesting to
4564  programmers that if they want to guarantee the lack of copying they
4565  should use something like the <tt>ref</tt> wrapper.]</i></p>
4566
4567
4568<p><i>[Oxford: Matt provided wording.]</i></p>
4569
4570
4571
4572
4573
4574
4575
4576
4577<hr>
4578<h3><a name="98"></a>98. Input iterator requirements are badly written</h3>
4579<p><b>Section:</b> 24.2.1 [input.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
4580 <b>Submitter:</b> AFNOR <b>Opened:</b> 1998-10-07  <b>Last modified:</b> 2008-09-26</p>
4581<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>
4582<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
4583<p><b>Discussion:</b></p>
4584<p>Table 72 in 24.2.1 [input.iterators] specifies semantics for
4585<tt>*r++</tt> of:</p>
4586
4587<p>&nbsp;&nbsp; <tt>{ T tmp = *r; ++r; return tmp; }</tt></p>
4588
4589<p>There are two problems with this.  First, the return type is
4590specified to be "T", as opposed to something like "convertible to T".
4591This is too specific: we want to allow *r++ to return an lvalue.</p>
4592
4593<p>Second, writing the semantics in terms of code misleadingly
4594suggests that the effects *r++ should precisely replicate the behavior
4595of this code, including side effects.  (Does this mean that *r++
4596should invoke the copy constructor exactly as many times as the sample
4597code above would?) See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#334">334</a> for a similar
4598problem.</p>
4599
4600
4601
4602<p><b>Proposed resolution:</b></p>
4603<p>In Table 72 in 24.2.1 [input.iterators], change the return type
4604for <tt>*r++</tt> from <tt>T</tt> to "convertible to T".</p>
4605
4606
4607<p><b>Rationale:</b></p>
4608<p>This issue has two parts: the return type, and the number of times
4609  the copy constructor is invoked.</p>
4610
4611<p>The LWG believes the the first part is a real issue.  It's
4612  inappropriate for the return type to be specified so much more
4613  precisely for *r++ than it is for *r.  In particular, if r is of
4614  (say) type <tt>int*</tt>, then *r++ isn't <tt>int</tt>,
4615  but <tt>int&amp;</tt>.</p>
4616
4617<p>The LWG does not believe that the number of times the copy
4618  constructor is invoked is a real issue.  This can vary in any case,
4619  because of language rules on copy constructor elision.  That's too
4620  much to read into these semantics clauses.</p>
4621
4622<p>Additionally, as Dave Abrahams pointed out (c++std-lib-13703): since 
4623   we're told (24.1/3) that forward iterators satisfy all the requirements
4624   of input iterators, we can't impose any requirements in the Input
4625   Iterator requirements table that forward iterators don't satisfy.</p>
4626
4627
4628
4629
4630
4631<hr>
4632<h3><a name="103"></a>103. set::iterator is required to be modifiable, but this allows modification of keys</h3>
4633<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>
4634 <b>Submitter:</b> AFNOR <b>Opened:</b> 1998-10-07  <b>Last modified:</b> 2008-09-26</p>
4635<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>
4636<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>
4637<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
4638<p><b>Discussion:</b></p>
4639<p>Set::iterator is described as implementation-defined with a
4640reference to the container requirement; the container requirement says
4641that const_iterator is an iterator pointing to const T and iterator an
4642iterator pointing to T.</p>
4643
4644<p>23.1.2 paragraph 2 implies that the keys should not be modified to
4645break the ordering of elements. But that is not clearly
4646specified. Especially considering that the current standard requires
4647that iterator for associative containers be different from
4648const_iterator. Set, for example, has the following: </p>
4649
4650<p><tt>typedef implementation defined iterator;<br>
4651&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // See _lib.container.requirements_</tt></p>
4652
4653<p>23.2 [container.requirements] actually requires that iterator type pointing
4654to T (table 65). Disallowing user modification of keys by changing the
4655standard to require an iterator for associative container to be the
4656same as const_iterator would be overkill since that will unnecessarily
4657significantly restrict the usage of associative container. A class to
4658be used as elements of set, for example, can no longer be modified
4659easily without either redesigning the class (using mutable on fields
4660that have nothing to do with ordering), or using const_cast, which
4661defeats requiring iterator to be const_iterator. The proposed solution
4662goes in line with trusting user knows what he is doing. </p>
4663
4664<p><b>Other Options Evaluated:</b> </p>
4665
4666<p>Option A.&nbsp;&nbsp; In 23.2.4 [associative.reqmts], paragraph 2, after
4667first sentence, and before "In addition,...", add one line:
4668</p>
4669
4670<blockquote>
4671  <p>Modification of keys shall not change their strict weak ordering. </p>
4672</blockquote>
4673
4674<p>Option B.&nbsp;Add three new sentences to 23.2.4 [associative.reqmts]:</p>
4675
4676<blockquote>
4677  <p>At the end of paragraph 5: "Keys in an associative container
4678  are immutable." At the end of paragraph 6: "For
4679  associative containers where the value type is the same as the key
4680  type, both <tt>iterator</tt> and <tt>const_iterator</tt> are
4681  constant iterators. It is unspecified whether or not
4682  <tt>iterator</tt> and <tt>const_iterator</tt> are the same
4683  type."</p>
4684</blockquote>
4685
4686<p>Option C.&nbsp;To 23.2.4 [associative.reqmts], paragraph 3, which
4687currently reads:</p>
4688
4689<blockquote>
4690  <p>The phrase ``equivalence of keys'' means the equivalence relation imposed by the
4691  comparison and not the operator== on keys. That is, two keys k1 and k2 in the same
4692  container are considered to be equivalent if for the comparison object comp, comp(k1, k2)
4693  == false &amp;&amp; comp(k2, k1) == false.</p>
4694</blockquote>
4695
4696<p>&nbsp; add the following:</p>
4697
4698<blockquote>
4699  <p>For any two keys k1 and k2 in the same container, comp(k1, k2) shall return the same
4700  value whenever it is evaluated. [Note: If k2 is removed from the container and later
4701  reinserted, comp(k1, k2) must still return a consistent value but this value may be
4702  different than it was the first time k1 and k2 were in the same container. This is
4703  intended to allow usage like a string key that contains a filename, where comp compares
4704  file contents; if k2 is removed, the file is changed, and the same k2 (filename) is
4705  reinserted, comp(k1, k2) must again return a consistent value but this value may be
4706  different than it was the previous time k2 was in the container.]</p>
4707</blockquote>
4708
4709
4710
4711<p><b>Proposed resolution:</b></p>
4712<p>Add the following to 23.2.4 [associative.reqmts] at
4713the indicated location:</p>
4714
4715<blockquote>
4716  <p>At the end of paragraph 3: "For any two keys k1 and k2 in the same container,
4717  calling comp(k1, k2) shall always return the same
4718  value."</p>
4719  <p>At the end of paragraph 5: "Keys in an associative container are immutable."</p>
4720  <p>At the end of paragraph 6: "For associative containers where the value type is the
4721  same as the key type, both <tt>iterator</tt> and <tt>const_iterator</tt> are constant
4722  iterators. It is unspecified whether or not <tt>iterator</tt> and <tt>const_iterator</tt>
4723  are the same type."</p>
4724</blockquote>
4725
4726
4727<p><b>Rationale:</b></p>
4728<p>Several arguments were advanced for and against allowing set elements to be
4729mutable as long as the ordering was not effected. The argument which swayed the
4730LWG was one of safety; if elements were mutable, there would be no compile-time
4731way to detect of a simple user oversight which caused ordering to be
4732modified.  There was a report that this had actually happened in practice,
4733and had been painful to diagnose.  If users need to modify elements,
4734it is possible to use mutable members or const_cast.</p>
4735
4736<p>Simply requiring that keys be immutable is not sufficient, because the comparison
4737object may indirectly (via pointers) operate on values outside of the keys.</p>
4738
4739<p>
4740The types <tt>iterator</tt> and <tt>const_iterator</tt> are permitted
4741to be different types to allow for potential future work in which some
4742member functions might be overloaded between the two types.  No such
4743member functions exist now, and the LWG believes that user functionality
4744will not be impaired by permitting the two types to be the same.  A
4745function that operates on both iterator types can be defined for 
4746<tt>const_iterator</tt> alone, and can rely on the automatic
4747conversion from <tt>iterator</tt> to <tt>const_iterator</tt>.
4748</p>
4749
4750<p><i>[Tokyo: The LWG crafted the proposed resolution and rationale.]</i></p>
4751
4752
4753
4754
4755
4756
4757<hr>
4758<h3><a name="106"></a>106. Numeric library private members are implementation defined</h3>
4759<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>
4760 <b>Submitter:</b> AFNOR <b>Opened:</b> 1998-10-07  <b>Last modified:</b> 2008-09-26</p>
4761<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>
4762<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>
4763<p><b>Discussion:</b></p>
4764<p>This is the only place in the whole standard where the implementation has to document
4765something private.</p>
4766
4767
4768<p><b>Proposed resolution:</b></p>
4769<p>
4770Remove the comment which says "// remainder implementation defined" from:
4771</p>
4772
4773<ul>
4774  <li>26.6.5 [template.slice.array]</li>
4775  <li>26.6.7 [template.gslice.array]</li>
4776  <li>26.6.8 [template.mask.array]</li>
4777  <li>26.6.9 [template.indirect.array]</li>
4778</ul>
4779
4780
4781
4782
4783
4784<hr>
4785<h3><a name="108"></a>108. Lifetime of exception::what() return unspecified</h3>
4786<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>
4787 <b>Submitter:</b> AFNOR <b>Opened:</b> 1998-10-07  <b>Last modified:</b> 2008-09-26</p>
4788<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>
4789<p><b>Discussion:</b></p>
4790<p>In 18.6.1, paragraphs 8-9, the lifetime of the return value of
4791exception::what() is left unspecified. This issue has implications
4792with exception safety of exception handling: some exceptions should
4793not throw bad_alloc.</p>
4794
4795
4796<p><b>Proposed resolution:</b></p>
4797<p>Add to 18.7.1 [type.info] paragraph 9 (exception::what notes
4798clause) the sentence:</p>
4799
4800<blockquote>
4801  <p>The return value remains valid until the exception object from which it is obtained is
4802  destroyed or a non-const member function of the exception object is called.</p>
4803</blockquote>
4804
4805
4806<p><b>Rationale:</b></p>
4807<p>If an exception object has non-const members, they may be used
4808to set internal state that should affect the contents of the string
4809returned by <tt>what()</tt>.
4810</p>
4811
4812
4813
4814
4815
4816<hr>
4817<h3><a name="109"></a>109. Missing binders for non-const sequence elements</h3>
4818<p><b>Section:</b> D.9 [depr.lib.binders] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
4819 <b>Submitter:</b> Bjarne Stroustrup <b>Opened:</b> 1998-10-07  <b>Last modified:</b> 2008-09-26</p>
4820<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>
4821<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
4822<p><b>Discussion:</b></p>
4823
4824<p>There are no versions of binders that apply to non-const elements
4825of a sequence. This makes examples like for_each() using bind2nd() on
4826page 521 of "The C++ Programming Language (3rd)"
4827non-conforming. Suitable versions of the binders need to be added.</p>
4828
4829<p>Further discussion from Nico:</p>
4830
4831<p>What is probably meant here is shown in the following example:</p>
4832
4833<pre>class Elem { 
4834  public: 
4835    void print (int i) const { } 
4836    void modify (int i) { } 
4837}; </pre>
4838<pre>int main() 
4839{ 
4840    vector&lt;Elem&gt; coll(2); 
4841    for_each (coll.begin(), coll.end(), bind2nd(mem_fun_ref(&amp;Elem::print),42));    // OK 
4842    for_each (coll.begin(), coll.end(), bind2nd(mem_fun_ref(&amp;Elem::modify),42));   // ERROR 
4843}</pre>
4844
4845<p>The error results from the fact that bind2nd() passes its first
4846argument (the argument of the sequence) as constant reference. See the
4847following typical implementation:</p>
4848
4849<blockquote>
4850  <pre>template &lt;class Operation&gt; 
4851class binder2nd 
4852  : public unary_function&lt;typename Operation::first_argument_type, 
4853                          typename Operation::result_type&gt; { 
4854protected: 
4855  Operation op; 
4856  typename Operation::second_argument_type value; 
4857public: 
4858  binder2nd(const Operation&amp; o, 
4859            const typename Operation::second_argument_type&amp; v) 
4860      : op(o), value(v) {} </pre>
4861  <pre> typename Operation::result_type 
4862  operator()(const typename Operation::first_argument_type&amp; x) const { 
4863    return op(x, value); 
4864  } 
4865};</pre>
4866</blockquote>
4867
4868<p>The solution is to overload operator () of bind2nd for non-constant arguments:</p>
4869
4870<blockquote>
4871  <pre>template &lt;class Operation&gt; 
4872class binder2nd 
4873  : public unary_function&lt;typename Operation::first_argument_type, 
4874                          typename Operation::result_type&gt; { 
4875protected: 
4876  Operation op; 
4877  typename Operation::second_argument_type value; 
4878public: 
4879  binder2nd(const Operation&amp; o, 
4880            const typename Operation::second_argument_type&amp; v) 
4881      : op(o), value(v) {} </pre>
4882  <pre> typename Operation::result_type 
4883  operator()(const typename Operation::first_argument_type&amp; x) const { 
4884    return op(x, value); 
4885  } 
4886  typename Operation::result_type 
4887  operator()(typename Operation::first_argument_type&amp; x) const { 
4888    return op(x, value); 
4889  } 
4890};</pre>
4891</blockquote>
4892
4893
4894<p><b>Proposed resolution:</b></p>
4895
4896<p><b>Howard believes there is a flaw</b> in this resolution.
4897See c++std-lib-9127.  We may need to reopen this issue.</p>
4898
4899<p>In D.9 [depr.lib.binders] in the declaration of binder1st after:</p>
4900<blockquote>
4901  <p><tt>typename Operation::result_type<br>
4902  &nbsp;operator()(const typename Operation::second_argument_type&amp; x) const;</tt></p>
4903</blockquote>
4904<p>insert:</p>
4905<blockquote>
4906  <p><tt>typename Operation::result_type<br>
4907  &nbsp;operator()(typename Operation::second_argument_type&amp; x) const;</tt></p>
4908</blockquote>
4909<p>In D.9 [depr.lib.binders] in the declaration of binder2nd after:</p>
4910<blockquote>
4911  <p><tt>typename Operation::result_type<br>
4912  &nbsp;operator()(const typename Operation::first_argument_type&amp; x) const;</tt></p>
4913</blockquote>
4914<p>insert:</p>
4915<blockquote>
4916  <p><tt>typename Operation::result_type<br>
4917  &nbsp;operator()(typename Operation::first_argument_type&amp; x) const;</tt></p>
4918</blockquote>
4919
4920<p><i>[Kona: The LWG discussed this at some length.It was agreed that
4921this is a mistake in the design, but there was no consensus on whether
4922it was a defect in the Standard.  Straw vote: NAD - 5.  Accept
4923proposed resolution - 3.  Leave open - 6.]</i></p>
4924
4925
4926<p><i>[Copenhagen: It was generally agreed that this was a defect.
4927Strap poll: NAD - 0.  Accept proposed resolution - 10. 
4928Leave open - 1.]</i></p>
4929
4930
4931
4932
4933
4934
4935
4936<hr>
4937<h3><a name="110"></a>110. istreambuf_iterator::equal not const</h3>
4938<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>
4939 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-10-15  <b>Last modified:</b> 2008-09-26</p>
4940<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>
4941<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>
4942<p><b>Discussion:</b></p>
4943<p>Member istreambuf_iterator&lt;&gt;::equal is not declared
4944"const", yet 24.6.3.6 [istreambuf.iterator::op==] says that operator==,
4945which is const, calls it. This is contradictory. </p>
4946
4947
4948<p><b>Proposed resolution:</b></p>
4949<p>In 24.6.3 [istreambuf.iterator] and also in 24.6.3.5 [istreambuf.iterator::equal],
4950replace:</p>
4951
4952<blockquote>
4953  <pre>bool equal(istreambuf_iterator&amp; b);</pre>
4954</blockquote>
4955
4956<p>with:</p>
4957
4958<blockquote>
4959  <pre>bool equal(const istreambuf_iterator&amp; b) const;</pre>
4960</blockquote>
4961
4962
4963
4964
4965
4966<hr>
4967<h3><a name="112"></a>112. Minor typo in <tt>ostreambuf_iterator</tt> constructor</h3>
4968<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>
4969 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-10-20  <b>Last modified:</b> 2008-09-26</p>
4970<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>
4971<p><b>Discussion:</b></p>
4972<p>The <b>requires</b> clause for <tt>ostreambuf_iterator</tt>'s
4973constructor from an <tt>ostream_type</tt> (24.5.4.1, paragraph 1)
4974reads "<i>s</i> is not null". However, <i>s</i> is a
4975reference, and references can't be null. </p>
4976
4977
4978<p><b>Proposed resolution:</b></p>
4979<p>In 24.6.4.1 [ostreambuf.iter.cons]:</p>
4980
4981<p>Move the current paragraph 1, which reads "Requires: s is not
4982null.", from the first constructor to the second constructor.</p>
4983
4984<p>Insert a new paragraph 1 Requires clause for the first constructor
4985reading:</p>
4986
4987<blockquote>
4988  <p><b>Requires</b>: <tt>s.rdbuf()</tt> is not null.</p>
4989</blockquote>
4990
4991
4992
4993
4994
4995<hr>
4996<h3><a name="114"></a>114. Placement forms example in error twice</h3>
4997<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>
4998 <b>Submitter:</b> Steve Clamage <b>Opened:</b> 1998-10-28  <b>Last modified:</b> 2008-09-26</p>
4999<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>
5000<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>
5001<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#196">196</a></p>
5002<p><b>Discussion:</b></p>
5003<p>Section 18.5.1.3 contains the following example: </p>
5004
5005<pre>[Example: This can be useful for constructing an object at a known address:
5006        char place[sizeof(Something)];
5007        Something* p = new (place) Something();
5008 -end example]</pre>
5009
5010<p>First code line: "place" need not have any special alignment, and the
5011following constructor could fail due to misaligned data.</p>
5012
5013<p>Second code line: Aren't the parens on Something() incorrect?&nbsp; [Dublin: the LWG
5014believes the () are correct.]</p>
5015
5016<p>Examples are not normative, but nevertheless should not show code that is invalid or
5017likely to fail.</p>
5018
5019
5020<p><b>Proposed resolution:</b></p>
5021<p>Replace the first line of code in the example in 
502218.6.1.3 [new.delete.placement] with:
5023</p>
5024
5025<blockquote>
5026  <pre>void* place = operator new(sizeof(Something));</pre>
5027</blockquote>
5028
5029
5030
5031
5032
5033<hr>
5034<h3><a name="115"></a>115. Typo in strstream constructors</h3>
5035<p><b>Section:</b> D.8.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>
5036 <b>Submitter:</b> Steve Clamage <b>Opened:</b> 1998-11-02  <b>Last modified:</b> 2008-09-26</p>
5037<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>
5038<p><b>Discussion:</b></p>
5039<p>D.7.4.1 strstream constructors paragraph 2 says: </p>
5040
5041<blockquote>
5042  <p>Effects: Constructs an object of class strstream, initializing the base class with
5043  iostream(&amp; sb) and initializing sb with one of the two constructors: </p>
5044  <p>- If mode&amp;app==0, then s shall designate the first element of an array of n
5045  elements. The constructor is strstreambuf(s, n, s). </p>
5046  <p>- If mode&amp;app==0, then s shall designate the first element of an array of n
5047  elements that contains an NTBS whose first element is designated by s. The constructor is
5048  strstreambuf(s, n, s+std::strlen(s)).</p>
5049</blockquote>
5050
5051<p>Notice the second condition is the same as the first. I think the second condition
5052should be "If mode&amp;app==app", or "mode&amp;app!=0", meaning that
5053the append bit is set.</p>
5054
5055
5056<p><b>Proposed resolution:</b></p>
5057<p>In D.8.3.1 [depr.ostrstream.cons] paragraph 2 and D.8.4.1 [depr.strstream.cons]
5058paragraph 2, change the first condition to <tt>(mode&amp;app)==0</tt>
5059and the second condition to <tt>(mode&amp;app)!=0</tt>.</p>
5060
5061
5062
5063
5064
5065<hr>
5066<h3><a name="117"></a>117. <tt>basic_ostream</tt> uses nonexistent <tt>num_put</tt> member functions</h3>
5067<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>
5068 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-11-20  <b>Last modified:</b> 2008-09-26</p>
5069<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>
5070<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
5071<p><b>Discussion:</b></p>
5072<p>The <b>effects</b> clause for numeric inserters says that
5073insertion of a value <tt>x</tt>, whose type is either <tt>bool</tt>,
5074<tt>short</tt>, <tt>unsigned short</tt>, <tt>int</tt>, <tt>unsigned
5075int</tt>, <tt>long</tt>, <tt>unsigned long</tt>, <tt>float</tt>,
5076<tt>double</tt>, <tt>long double</tt>, or <tt>const void*</tt>, is
5077delegated to <tt>num_put</tt>, and that insertion is performed as if
5078through the following code fragment: </p>
5079
5080<pre>bool failed = use_facet&lt;
5081   num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt; 
5082   &gt;(getloc()).put(*this, *this, fill(), val). failed();</pre>
5083
5084<p>This doesn't work, because <tt>num_put&lt;&gt;</tt>::put is only
5085overloaded for the types <tt>bool</tt>, <tt>long</tt>, <tt>unsigned
5086long</tt>, <tt>double</tt>, <tt>long double</tt>, and <tt>const
5087void*</tt>. That is, the code fragment in the standard is incorrect
5088(it is diagnosed as ambiguous at compile time) for the types
5089<tt>short</tt>, <tt>unsigned short</tt>, <tt>int</tt>, <tt>unsigned
5090int</tt>, and <tt>float</tt>. </p>
5091
5092<p>We must either add new member functions to <tt>num_put</tt>, or
5093else change the description in <tt>ostream</tt> so that it only calls
5094functions that are actually there. I prefer the latter. </p>
5095
5096
5097<p><b>Proposed resolution:</b></p>
5098<p>Replace 27.6.2.5.2, paragraph 1 with the following: </p>
5099
5100<blockquote>
5101<p>
5102The classes num_get&lt;&gt; and num_put&lt;&gt; handle locale-dependent numeric
5103formatting and parsing.  These inserter functions use the imbued
5104locale value to perform numeric formatting.  When val is of type bool,
5105long, unsigned long, double, long double, or const void*, the
5106formatting conversion occurs as if it performed the following code
5107fragment:
5108</p>
5109
5110<pre>bool failed = use_facet&lt;
5111   num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
5112   &gt;(getloc()).put(*this, *this, fill(), val). failed();
5113</pre>
5114
5115<p>
5116When val is of type short the formatting conversion occurs as if it
5117performed the following code fragment:
5118</p>
5119
5120<pre>ios_base::fmtflags baseflags = ios_base::flags() &amp; ios_base::basefield;
5121bool failed = use_facet&lt;
5122   num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
5123   &gt;(getloc()).put(*this, *this, fill(),
5124      baseflags == ios_base::oct || baseflags == ios_base::hex
5125         ? static_cast&lt;long&gt;(static_cast&lt;unsigned short&gt;(val))
5126         : static_cast&lt;long&gt;(val)). failed();
5127</pre>
5128
5129<p>
5130When val is of type int the formatting conversion occurs as if it performed
5131the following code fragment:
5132</p>
5133
5134<pre>ios_base::fmtflags baseflags = ios_base::flags() &amp; ios_base::basefield;
5135bool failed = use_facet&lt;
5136   num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
5137   &gt;(getloc()).put(*this, *this, fill(),
5138      baseflags == ios_base::oct || baseflags == ios_base::hex
5139         ? static_cast&lt;long&gt;(static_cast&lt;unsigned int&gt;(val))
5140         : static_cast&lt;long&gt;(val)). failed();
5141</pre>
5142
5143<p>
5144When val is of type unsigned short or unsigned int the formatting conversion
5145occurs as if it performed the following code fragment:
5146</p>
5147
5148<pre>bool failed = use_facet&lt;
5149   num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
5150   &gt;(getloc()).put(*this, *this, fill(), static_cast&lt;unsigned long&gt;(val)).
5151failed();
5152</pre>
5153
5154<p>
5155When val is of type float the formatting conversion occurs as if it
5156performed the following code fragment:
5157</p>
5158
5159<pre>bool failed = use_facet&lt;
5160   num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
5161   &gt;(getloc()).put(*this, *this, fill(), static_cast&lt;double&gt;(val)).
5162failed();
5163</pre>
5164
5165</blockquote>
5166
5167<p><i>[post-Toronto: This differs from the previous proposed
5168resolution; PJP provided the new wording.  The differences are in
5169signed short and int output.]</i></p>
5170
5171
5172
5173<p><b>Rationale:</b></p>
5174<p>The original proposed resolution was to cast int and short to long,
5175unsigned int and unsigned short to unsigned long, and float to double,
5176thus ensuring that we don't try to use nonexistent num_put&lt;&gt;
5177member functions.  The current proposed resolution is more
5178complicated, but gives more expected results for hex and octal output
5179of signed short and signed int.  (On a system with 16-bit short, for
5180example, printing short(-1) in hex format should yield 0xffff.)</p>
5181
5182
5183
5184
5185
5186<hr>
5187<h3><a name="118"></a>118. <tt>basic_istream</tt> uses nonexistent <tt>num_get</tt> member functions</h3>
5188<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>
5189 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-11-20  <b>Last modified:</b> 2008-09-26</p>
5190<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>
5191<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
5192<p><b>Discussion:</b></p>
5193<p>Formatted input is defined for the types <tt>short</tt>, <tt>unsigned short</tt>, <tt>int</tt>,
5194<tt>unsigned int</tt>, <tt>long</tt>, <tt>unsigned long</tt>, <tt>float</tt>, <tt>double</tt>,
5195<tt>long double</tt>, <tt>bool</tt>, and <tt>void*</tt>. According to section 27.6.1.2.2,
5196formatted input of a value <tt>x</tt> is done as if by the following code fragment: </p>
5197
5198<pre>typedef num_get&lt; charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget; 
5199iostate err = 0; 
5200use_facet&lt; numget &gt;(loc).get(*this, 0, *this, err, val); 
5201setstate(err);</pre>
5202
5203<p>According to section 22.4.2.1.1 [facet.num.get.members], however,
5204<tt>num_get&lt;&gt;::get()</tt> is only overloaded for the types
5205<tt>bool</tt>, <tt>long</tt>, <tt>unsigned short</tt>, <tt>unsigned
5206int</tt>, <tt>unsigned long</tt>, <tt>unsigned long</tt>,
5207<tt>float</tt>, <tt>double</tt>, <tt>long double</tt>, and
5208<tt>void*</tt>. Comparing the lists from the two sections, we find
5209that 27.6.1.2.2 is using a nonexistent function for types
5210<tt>short</tt> and <tt>int</tt>. </p>
5211
5212
5213<p><b>Proposed resolution:</b></p>
5214<p>In 27.7.1.2.2 [istream.formatted.arithmetic] Arithmetic Extractors, remove the
5215two lines (1st and 3rd) which read:</p>
5216<blockquote>
5217  <pre>operator&gt;&gt;(short&amp; val);
5218...
5219operator&gt;&gt;(int&amp; val);</pre>
5220</blockquote>
5221
5222<p>And add the following at the end of that section (27.6.1.2.2) :</p>
5223
5224<blockquote>
5225  <pre>operator&gt;&gt;(short&amp; val);</pre>
5226  <p>The conversion occurs as if performed by the following code fragment (using
5227  the same notation as for the preceding code fragment):</p>
5228  <pre>  typedef num_get&lt; charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget;
5229  iostate err = 0;
5230  long lval;
5231  use_facet&lt; numget &gt;(loc).get(*this, 0, *this, err, lval);
5232        if (err == 0
5233                &amp;&amp; (lval &lt; numeric_limits&lt;short&gt;::min() || numeric_limits&lt;short&gt;::max() &lt; lval))
5234                err = ios_base::failbit;
5235  setstate(err);</pre>
5236  <pre>operator&gt;&gt;(int&amp; val);</pre>
5237  <p>The conversion occurs as if performed by the following code fragment (using
5238  the same notation as for the preceding code fragment):</p>
5239  <pre>  typedef num_get&lt; charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget;
5240  iostate err = 0;
5241  long lval;
5242  use_facet&lt; numget &gt;(loc).get(*this, 0, *this, err, lval);
5243        if (err == 0
5244                &amp;&amp; (lval &lt; numeric_limits&lt;int&gt;::min() || numeric_limits&lt;int&gt;::max() &lt; lval))
5245                err = ios_base::failbit;
5246  setstate(err);</pre>
5247</blockquote>
5248
5249<p><i>[Post-Tokyo: PJP provided the above wording.]</i></p>
5250
5251
5252
5253
5254
5255
5256<hr>
5257<h3><a name="119"></a>119. Should virtual functions be allowed to strengthen the exception specification?</h3>
5258<p><b>Section:</b> 17.6.4.11 [res.on.exception.handling] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
5259 <b>Submitter:</b> Judy Ward <b>Opened:</b> 1998-12-15  <b>Last modified:</b> 2008-09-26</p>
5260<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>
5261<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>
5262<p><b>Discussion:</b></p>
5263<p>Section 17.6.4.11 [res.on.exception.handling] states: </p>
5264
5265<p>"An implementation may strengthen the exception-specification
5266for a function by removing listed exceptions." </p>
5267
5268<p>The problem is that if an implementation is allowed to do this for
5269virtual functions, then a library user cannot write a class that
5270portably derives from that class. </p>
5271
5272<p>For example, this would not compile if ios_base::failure::~failure
5273had an empty exception specification: </p>
5274
5275<pre>#include &lt;ios&gt;
5276#include &lt;string&gt;
5277
5278class D : public std::ios_base::failure {
5279public:
5280        D(const std::string&amp;);
5281        ~D(); // error - exception specification must be compatible with 
5282              // overridden virtual function ios_base::failure::~failure()
5283};</pre>
5284
5285
5286<p><b>Proposed resolution:</b></p>
5287<p>Change Section 17.6.4.11 [res.on.exception.handling] from:</p>
5288
5289<p>&nbsp;&nbsp;&nbsp;&nbsp; "may strengthen the
5290exception-specification for a function"</p>
5291
5292<p>to:</p>
5293
5294<p>&nbsp;&nbsp;&nbsp;&nbsp; "may strengthen the
5295exception-specification for a non-virtual function". </p>
5296
5297
5298
5299
5300
5301<hr>
5302<h3><a name="120"></a>120. Can an implementor add specializations?</h3>
5303<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>
5304 <b>Submitter:</b> Judy Ward <b>Opened:</b> 1998-12-15  <b>Last modified:</b> 2008-09-26</p>
5305<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>
5306<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
5307<p><b>Discussion:</b></p>
5308
5309<p>The original issue asked whether a library implementor could
5310specialize standard library templates for built-in types.  (This was
5311an issue because users are permitted to explicitly instantiate
5312standard library templates.)</p>
5313
5314<p>Specializations are no longer a problem, because of the resolution
5315to core issue 259.  Under the proposed resolution, it will be legal
5316for a translation unit to contain both a specialization and an
5317explicit instantiation of the same template, provided that the
5318specialization comes first.  In such a case, the explicit
5319instantiation will be ignored.  Further discussion of library issue
5320120 assumes that the core 259 resolution will be adopted.</p>
5321
5322<p>However, as noted in lib-7047, one piece of this issue still
5323remains: what happens if a standard library implementor explicitly
5324instantiates a standard library templates?  It's illegal for a program
5325to contain two different explicit instantiations of the same template
5326for the same type in two different translation units (ODR violation),
5327and the core working group doesn't believe it is practical to relax
5328that restriction.</p>
5329
5330<p>The issue, then, is: are users allowed to explicitly instantiate
5331standard library templates for non-user defined types?  The status quo
5332answer is 'yes'.  Changing it to 'no' would give library implementors
5333more freedom.</p>
5334
5335<p>This is an issue because, for performance reasons, library
5336implementors often need to explicitly instantiate standard library
5337templates.  (for example, std::basic_string&lt;char&gt;)  Does giving
5338users freedom to explicitly instantiate standard library templates for
5339non-user defined types make it impossible or painfully difficult for
5340library implementors to do this?</p>
5341
5342<p>John Spicer suggests, in lib-8957, that library implementors have a
5343mechanism they can use for explicit instantiations that doesn't
5344prevent users from performing their own explicit instantiations: put
5345each explicit instantiation in its own object file.  (Different
5346solutions might be necessary for Unix DSOs or MS-Windows DLLs.)  On
5347some platforms, library implementors might not need to do anything
5348special: the "undefined behavior" that results from having two
5349different explicit instantiations might be harmless.</p>
5350
5351
5352
5353<p><b>Proposed resolution:</b></p>
5354  <p>Append to 17.6.3.3 [reserved.names] paragraph 1: </p>
5355  <blockquote><p>
5356    A program may explicitly instantiate any templates in the standard
5357    library only if the declaration depends on the name of a user-defined
5358    type of external linkage and the instantiation meets the standard library
5359    requirements for the original template.
5360  </p></blockquote>
5361
5362<p><i>[Kona: changed the wording from "a user-defined name" to "the name of
5363  a user-defined type"]</i></p>
5364
5365
5366
5367
5368<p><b>Rationale:</b></p>
5369<p>The LWG considered another possible resolution:</p>
5370<blockquote>
5371  <p>In light of the resolution to core issue 259, no normative changes
5372  in the library clauses are necessary.  Add the following non-normative
5373  note to the end of 17.6.3.3 [reserved.names] paragraph 1:</p>
5374  <blockquote><p>
5375    [<i>Note:</i> A program may explicitly instantiate standard library
5376    templates, even when an explicit instantiation does not depend on
5377    a user-defined name. <i>--end note</i>]
5378  </p></blockquote>
5379</blockquote>
5380
5381<p>The LWG rejected this because it was believed that it would make
5382  it unnecessarily difficult for library implementors to write
5383  high-quality implementations.  A program may not include an
5384  explicit instantiation of the same template, for the same template
5385  arguments, in two different translation units.  If users are
5386  allowed to provide explicit instantiations of Standard Library
5387  templates for built-in types, then library implementors aren't,
5388  at least not without nonportable tricks.</p>
5389
5390<p>The most serious problem is a class template that has writeable
5391  static member variables.  Unfortunately, such class templates are
5392  important and, in existing Standard Library implementations, are
5393  often explicitly specialized by library implementors: locale facets,
5394  which have a writeable static member variable <tt>id</tt>.  If a
5395  user's explicit instantiation collided with the implementations
5396  explicit instantiation, iostream initialization could cause locales
5397  to be constructed in an inconsistent state.</p>
5398
5399<p>One proposed implementation technique was for Standard Library
5400  implementors to provide explicit instantiations in separate object
5401  files, so that they would not be picked up by the linker when the
5402  user also provides an explicit instantiation.  However, this
5403  technique only applies for Standard Library implementations that
5404  are packaged as static archives.  Most Standard Library
5405  implementations nowadays are packaged as dynamic libraries, so this
5406  technique would not apply.</p>
5407
5408<p>The Committee is now considering standardization of dynamic
5409  linking.  If there are such changes in the future, it may be
5410  appropriate to revisit this issue later.</p>
5411
5412
5413
5414
5415
5416<hr>
5417<h3><a name="122"></a>122. streambuf/wstreambuf description should not say they are specializations</h3>
5418<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>
5419 <b>Submitter:</b> Judy Ward <b>Opened:</b> 1998-12-15  <b>Last modified:</b> 2008-09-26</p>
5420<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>
5421<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>
5422<p><b>Discussion:</b></p>
5423<p>Section 27.5.2 describes the streambuf classes this way: </p>
5424
5425<blockquote>
5426
5427<p>The class streambuf is a specialization of the template class basic_streambuf
5428specialized for the type char. </p>
5429
5430<p>The class wstreambuf is a specialization of the template class basic_streambuf
5431specialized for the type wchar_t. </p>
5432
5433</blockquote>
5434
5435<p>This implies that these classes must be template specializations, not typedefs. </p>
5436
5437<p>It doesn't seem this was intended, since Section 27.5 has them declared as typedefs. </p>
5438
5439
5440<p><b>Proposed resolution:</b></p>
5441<p>Remove 27.6.2 [streambuf] paragraphs 2 and 3 (the above two
5442sentences). </p>
5443
5444
5445<p><b>Rationale:</b></p>
5446<p>The <tt>streambuf</tt>  synopsis already has a declaration for the
5447typedefs and that is sufficient. </p>
5448
5449
5450
5451
5452
5453<hr>
5454<h3><a name="123"></a>123. Should valarray helper arrays fill functions be const?</h3>
5455<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>
5456 <b>Submitter:</b> Judy Ward <b>Opened:</b> 1998-12-15  <b>Last modified:</b> 2008-09-26</p>
5457<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
5458<p><b>Discussion:</b></p>
5459<p>One of the operator= in the valarray helper arrays is const and one
5460is not. For example, look at slice_array. This operator= in Section
546126.6.5.1 [slice.arr.assign] is const: </p>
5462
5463<p>&nbsp;&nbsp;&nbsp; <tt>void operator=(const valarray&lt;T&gt;&amp;) const;</tt> </p>
5464
5465<p>but this one in Section 26.6.5.3 [slice.arr.fill] is not: </p>
5466
5467<p>&nbsp;&nbsp;&nbsp; <tt>void operator=(const T&amp;); </tt></p>
5468
5469<p>The description of the semantics for these two functions is similar. </p>
5470
5471
5472<p><b>Proposed resolution:</b></p>
5473
5474<p>26.6.5 [template.slice.array] Template class slice_array</p>
5475<blockquote>
5476
5477   <p>In the class template definition for slice_array, replace the member
5478   function declaration</p>
5479    <pre>      void operator=(const T&amp;);
5480    </pre>
5481   <p>with</p>
5482    <pre>      void operator=(const T&amp;) const;
5483    </pre>
5484</blockquote>
5485
5486<p>26.6.5.3 [slice.arr.fill] slice_array fill function</p>
5487<blockquote>
5488
5489   <p>Change the function declaration</p>
5490    <pre>      void operator=(const T&amp;);
5491    </pre>
5492   <p>to</p>
5493    <pre>      void operator=(const T&amp;) const;
5494    </pre>
5495</blockquote>
5496
5497<p>26.6.7 [template.gslice.array] Template class gslice_array</p>
5498<blockquote>
5499
5500   <p>In the class template definition for gslice_array, replace the member
5501   function declaration</p>
5502    <pre>      void operator=(const T&amp;);
5503    </pre>
5504   <p>with</p>
5505    <pre>      void operator=(const T&amp;) const;
5506    </pre>
5507</blockquote>
5508
5509<p>26.6.7.3 [gslice.array.fill] gslice_array fill function</p>
5510<blockquote>
5511
5512   <p>Change the function declaration</p>
5513    <pre>      void operator=(const T&amp;);
5514    </pre>
5515   <p>to</p>
5516    <pre>      void operator=(const T&amp;) const;
5517    </pre>
5518</blockquote>
5519
5520<p>26.6.8 [template.mask.array] Template class mask_array</p>
5521<blockquote>
5522
5523   <p>In the class template definition for mask_array, replace the member
5524   function declaration</p>
5525    <pre>      void operator=(const T&amp;);
5526    </pre>
5527   <p>with</p>
5528    <pre>      void operator=(const T&amp;) const;
5529    </pre>
5530</blockquote>
5531
5532<p>26.6.8.3 [mask.array.fill] mask_array fill function</p>
5533<blockquote>
5534
5535   <p>Change the function declaration</p>
5536    <pre>      void operator=(const T&amp;);
5537    </pre>
5538   <p>to</p>
5539    <pre>      void operator=(const T&amp;) const;
5540    </pre>
5541</blockquote>
5542
5543<p>26.6.9 [template.indirect.array] Template class indirect_array</p>
5544<blockquote>
5545
5546   <p>In the class template definition for indirect_array, replace the member
5547   function declaration</p>
5548    <pre>      void operator=(const T&amp;);
5549    </pre>
5550   <p>with</p>
5551    <pre>      void operator=(const T&amp;) const;
5552    </pre>
5553</blockquote>
5554
5555<p>26.6.9.3 [indirect.array.fill] indirect_array fill function</p>
5556<blockquote>
5557
5558   <p>Change the function declaration</p>
5559    <pre>      void operator=(const T&amp;);
5560    </pre>
5561   <p>to</p>
5562    <pre>      void operator=(const T&amp;) const;
5563    </pre>
5564</blockquote>
5565
5566
5567<p><i>[Redmond: Robert provided wording.]</i></p>
5568
5569
5570
5571
5572<p><b>Rationale:</b></p>
5573<p>There's no good reason for one version of operator= being const and
5574another one not.  Because of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#253">253</a>, this now
5575matters: these functions are now callable in more circumstances.  In
5576many existing implementations, both versions are already const.</p>
5577
5578
5579
5580
5581
5582<hr>
5583<h3><a name="124"></a>124. ctype_byname&lt;charT&gt;::do_scan_is &amp; do_scan_not return type should be const charT*</h3>
5584<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>
5585 <b>Submitter:</b> Judy Ward <b>Opened:</b> 1998-12-15  <b>Last modified:</b> 2008-09-26</p>
5586<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>
5587<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>
5588<p><b>Discussion:</b></p>
5589<p>In Section 22.4.1.2 [locale.ctype.byname]
5590ctype_byname&lt;charT&gt;::do_scan_is() and do_scan_not() are declared
5591to return a const char* not a const charT*. </p>
5592
5593
5594<p><b>Proposed resolution:</b></p>
5595<p>Change Section 22.4.1.2 [locale.ctype.byname] <tt>do_scan_is()</tt> and
5596<tt>do_scan_not()</tt> to return a <tt> const
5597charT*</tt>. </p>
5598
5599
5600
5601
5602
5603<hr>
5604<h3><a name="125"></a>125. valarray&lt;T&gt;::operator!() return type is inconsistent</h3>
5605<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>
5606 <b>Submitter:</b> Judy Ward <b>Opened:</b> 1998-12-15  <b>Last modified:</b> 2008-09-26</p>
5607<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>
5608<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>
5609<p><b>Discussion:</b></p>
5610<p>In Section 26.6.2 [template.valarray] valarray&lt;T&gt;::operator!()
5611is
5612declared to return a valarray&lt;T&gt;, but in Section 26.6.2.5
5613[valarray.unary] it is declared to return a valarray&lt;bool&gt;. The
5614latter appears to be correct. </p>
5615
5616
5617<p><b>Proposed resolution:</b></p>
5618<p>Change in Section 26.6.2 [template.valarray] the declaration of
5619<tt>operator!()</tt> so that the return type is
5620<tt>valarray&lt;bool&gt;</tt>. </p>
5621
5622
5623
5624
5625<hr>
5626<h3><a name="126"></a>126. typos in Effects clause of ctype::do_narrow()</h3>
5627<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>
5628 <b>Submitter:</b> Judy Ward <b>Opened:</b> 1998-12-15  <b>Last modified:</b> 2008-09-26</p>
5629<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>
5630<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>
5631<p><b>Discussion:</b></p><p>Typos in 22.2.1.1.2 need to be fixed.</p>
5632
5633<p><b>Proposed resolution:</b></p>
5634<p>In Section 22.4.1.1.2 [locale.ctype.virtuals] change: </p>
5635
5636<pre>   do_widen(do_narrow(c),0) == c</pre>
5637
5638<p>to:</p>
5639
5640<pre>   do_widen(do_narrow(c,0)) == c</pre>
5641
5642<p>and change:</p>
5643
5644<pre>   (is(M,c) || !ctc.is(M, do_narrow(c),dfault) )</pre>
5645
5646<p>to:</p>
5647
5648<pre>   (is(M,c) || !ctc.is(M, do_narrow(c,dfault)) )</pre>
5649
5650
5651
5652
5653
5654<hr>
5655<h3><a name="127"></a>127. auto_ptr&lt;&gt; conversion issues</h3>
5656<p><b>Section:</b> D.10.1 [auto.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
5657 <b>Submitter:</b> Greg Colvin <b>Opened:</b> 1999-02-17  <b>Last modified:</b> 2008-09-26</p>
5658<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>
5659<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>
5660<p><b>Discussion:</b></p>
5661<p>There are two problems with the current <tt>auto_ptr</tt> wording
5662in the standard: </p>
5663
5664<p>First, the <tt>auto_ptr_ref</tt> definition cannot be nested
5665because <tt>auto_ptr&lt;Derived&gt;::auto_ptr_ref</tt> is unrelated to
5666<tt>auto_ptr&lt;Base&gt;::auto_ptr_ref</tt>.  <i>Also submitted by
5667Nathan Myers, with the same proposed resolution.</i></p>
5668
5669<p>Second, there is no <tt>auto_ptr</tt> assignment operator taking an
5670<tt>auto_ptr_ref</tt> argument. </p>
5671
5672<p>I have discussed these problems with my proposal coauthor, Bill
5673Gibbons, and with some compiler and library implementors, and we
5674believe that these problems are not desired or desirable implications
5675of the standard. </p>
5676
5677<p>25 Aug 1999: The proposed resolution now reflects changes suggested
5678by Dave Abrahams, with Greg Colvin's concurrence; 1) changed
5679"assignment operator" to "public assignment
5680operator", 2) changed effects to specify use of release(), 3)
5681made the conversion to auto_ptr_ref const. </p>
5682
5683<p>2 Feb 2000: Lisa Lippincott comments: [The resolution of] this issue
5684states that the conversion from auto_ptr to auto_ptr_ref should
5685be const.  This is not acceptable, because it would allow
5686initialization and assignment from _any_ const auto_ptr!  It also
5687introduces an implementation difficulty in writing this conversion
5688function -- namely, somewhere along the line, a const_cast will be
5689necessary to remove that const so that release() may be called.  This
5690may result in undefined behavior [7.1.5.1/4]. The conversion
5691operator does not have to be const, because a non-const implicit
5692object parameter may be bound to an rvalue [13.3.3.1.4/3]
5693[13.3.1/5]. </p>
5694
5695  <p>Tokyo: The LWG removed the following from the proposed resolution:</p>
5696
5697  <p>In 20.6.4 [meta.unary], paragraph 2, and 20.6.4.3 [meta.unary.prop], 
5698  paragraph 2, make the conversion to auto_ptr_ref const:</p>
5699  <blockquote>
5700    <pre>template&lt;class Y&gt; operator auto_ptr_ref&lt;Y&gt;() const throw();</pre>
5701  </blockquote>
5702
5703
5704<p><b>Proposed resolution:</b></p>
5705<p>In 20.6.4 [meta.unary], paragraph 2, move
5706the <tt>auto_ptr_ref</tt> definition to namespace scope.</p>
5707
5708<p>In 20.6.4 [meta.unary], paragraph 2, add
5709a public assignment operator to the <tt>auto_ptr</tt> definition: </p>
5710
5711<blockquote>
5712  <pre>auto_ptr&amp; operator=(auto_ptr_ref&lt;X&gt; r) throw();</pre>
5713</blockquote>
5714
5715<p>Also add the assignment operator to 20.6.4.3 [meta.unary.prop]: </p>
5716
5717<blockquote>
5718  <pre>auto_ptr&amp; operator=(auto_ptr_ref&lt;X&gt; r) throw()</pre>
5719
5720  <p><b>Effects:</b> Calls <tt>reset(p.release())</tt> for the <tt>auto_ptr
5721  p</tt> that <tt>r</tt> holds a reference to.<br>
5722  <b>Returns: </b><tt>*this</tt>.</p>
5723
5724</blockquote>
5725
5726
5727
5728
5729
5730<hr>
5731<h3><a name="129"></a>129. Need error indication from seekp() and seekg()</h3>
5732<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>
5733 <b>Submitter:</b> Angelika Langer <b>Opened:</b> 1999-02-22  <b>Last modified:</b> 2008-09-26</p>
5734<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>
5735<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>
5736<p><b>Discussion:</b></p>
5737<p>Currently, the standard does not specify how seekg() and seekp()
5738indicate failure. They are not required to set failbit, and they can't
5739return an error indication because they must return *this, i.e. the
5740stream. Hence, it is undefined what happens if they fail. And they
5741<i>can</i> fail, for instance, when a file stream is disconnected from the
5742underlying file (is_open()==false) or when a wide character file
5743stream must perform a state-dependent code conversion, etc. </p>
5744
5745<p>The stream functions seekg() and seekp() should set failbit in the
5746stream state in case of failure.</p>
5747
5748
5749<p><b>Proposed resolution:</b></p>
5750<p>Add to the Effects: clause of&nbsp; seekg() in 
575127.7.1.3 [istream.unformatted] and to the Effects: clause of seekp() in
575227.7.2.5 [ostream.seeks]: </p>
5753
5754<blockquote>
5755  <p>In case of failure, the function calls <tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt>).
5756  </p>
5757</blockquote>
5758
5759
5760<p><b>Rationale:</b></p>
5761<p>Setting failbit is the usual error reporting mechanism for streams</p>
5762
5763
5764
5765
5766<hr>
5767<h3><a name="130"></a>130. Return type of container::erase(iterator) differs for associative containers</h3>
5768<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>
5769 <b>Submitter:</b> Andrew Koenig <b>Opened:</b> 1999-03-02  <b>Last modified:</b> 2009-05-01</p>
5770<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>
5771<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>
5772<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
5773<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#451">451</a></p>
5774<p><b>Discussion:</b></p>
5775<p>Table 67 (23.1.1) says that container::erase(iterator) returns an
5776iterator. Table 69 (23.1.2) says that in addition to this requirement,
5777associative containers also say that container::erase(iterator)
5778returns void.  That's not an addition; it's a change to the
5779requirements, which has the effect of making associative containers
5780fail to meet the requirements for containers.</p>
5781
5782
5783<p><b>Proposed resolution:</b></p>
5784
5785<p>
5786In 23.2.4 [associative.reqmts], in Table 69 Associative container
5787requirements, change the return type of <tt>a.erase(q)</tt> from
5788<tt>void</tt> to <tt>iterator</tt>.  Change the
5789assertion/not/pre/post-condition from "erases the element pointed to
5790by <tt>q</tt>" to "erases the element pointed to by <tt>q</tt>.
5791Returns an iterator pointing to the element immediately following q
5792prior to the element being erased. If no such element exists, a.end()
5793is returned."
5794</p>
5795
5796<p>
5797In 23.2.4 [associative.reqmts], in Table 69 Associative container
5798requirements, change the return type of <tt>a.erase(q1, q2)</tt>
5799from <tt>void</tt> to <tt>iterator</tt>.  Change the
5800assertion/not/pre/post-condition from "erases the elements in the
5801range <tt>[q1, q2)</tt>" to "erases the elements in the range <tt>[q1,
5802q2)</tt>.  Returns q2."
5803</p>
5804
5805<p>
5806In 23.4.1 [map], in the <tt>map</tt> class synopsis; and 
5807in 23.4.2 [multimap], in the <tt>multimap</tt> class synopsis; and
5808in 23.4.3 [set], in the <tt>set</tt> class synopsis; and
5809in 23.4.4 [multiset], in the <tt>multiset</tt> class synopsis:
5810change the signature of the first <tt>erase</tt> overload to
5811</p>
5812<pre>   iterator erase(iterator position);
5813</pre>
5814<p>and change the signature of the third <tt>erase</tt> overload to</p>
5815<pre>  iterator erase(iterator first, iterator last); 
5816</pre>
5817
5818
5819<p><i>[Pre-Kona: reopened at the request of Howard Hinnant]</i></p>
5820
5821
5822<p><i>[Post-Kona: the LWG agrees the return type should be
5823<tt>iterator</tt>, not <tt>void</tt>.  (Alex Stepanov agrees too.)
5824Matt provided wording.]</i></p>
5825
5826
5827<p><i>[
5828 Sydney: the proposed wording went in the right direction, but it
5829 wasn't good enough. We want to return an iterator from the range form
5830 of erase as well as the single-iterator form. Also, the wording is
5831 slightly different from the wording we have for sequences; there's no
5832 good reason for having a difference.  Matt provided new wording,
5833(reflected above) which we will review at the next meeting.
5834]</i></p>
5835
5836
5837<p><i>[
5838Redmond:  formally voted into WP.
5839]</i></p>
5840
5841
5842
5843
5844
5845
5846
5847<hr>
5848<h3><a name="132"></a>132. list::resize description uses random access iterators</h3>
5849<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>
5850 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 1999-03-06  <b>Last modified:</b> 2008-09-26</p>
5851<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>
5852<p><b>Discussion:</b></p>
5853<p>The description reads:</p>
5854
5855<p>-1- Effects:</p>
5856
5857<pre>         if (sz &gt; size())
5858           insert(end(), sz-size(), c);
5859         else if (sz &lt; size())
5860           erase(begin()+sz, end());
5861         else
5862           ;                           //  do nothing</pre>
5863
5864<p>Obviously list::resize should not be specified in terms of random access iterators.</p>
5865
5866
5867<p><b>Proposed resolution:</b></p>
5868<p>Change 23.3.4.2 [list.capacity] paragraph 1 to:</p>
5869
5870<p>Effects:</p>
5871
5872<pre>         if (sz &gt; size())
5873           insert(end(), sz-size(), c);
5874         else if (sz &lt; size())
5875         {
5876           iterator i = begin();
5877           advance(i, sz);
5878           erase(i, end());
5879         }</pre>
5880
5881<p><i>[Dublin: The LWG asked Howard to discuss exception safety offline
5882with David Abrahams. They had a discussion and believe there is
5883no issue of exception safety with the proposed resolution.]</i></p>
5884
5885
5886
5887
5888
5889
5890<hr>
5891<h3><a name="133"></a>133. map missing get_allocator()</h3>
5892<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>
5893 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 1999-03-06  <b>Last modified:</b> 2008-09-26</p>
5894<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>
5895<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>
5896<p><b>Discussion:</b></p><p>The title says it all.</p>
5897
5898<p><b>Proposed resolution:</b></p>
5899<p>Insert in 23.4.1 [map], paragraph 2,
5900after operator= in the map declaration:</p>
5901
5902<pre>    allocator_type get_allocator() const;</pre>
5903
5904
5905
5906
5907<hr>
5908<h3><a name="134"></a>134. vector constructors over specified</h3>
5909<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>
5910 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 1999-03-06  <b>Last modified:</b> 2008-09-26</p>
5911<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>
5912<p><b>Discussion:</b></p>
5913<p>The complexity description says: "It does at most 2N calls to the copy constructor
5914of T and logN reallocations if they are just input iterators ...".</p>
5915
5916<p>This appears to be overly restrictive, dictating the precise memory/performance
5917tradeoff for the implementor.</p>
5918
5919
5920<p><b>Proposed resolution:</b></p>
5921<p>Change 23.3.6.1 [vector.cons], paragraph 1 to:</p>
5922
5923<p>-1- Complexity: The constructor template &lt;class
5924InputIterator&gt; vector(InputIterator first, InputIterator last)
5925makes only N calls to the copy constructor of T (where N is the
5926distance between first and last) and no reallocations if iterators
5927first and last are of forward, bidirectional, or random access
5928categories. It makes order N calls to the copy constructor of T and
5929order logN reallocations if they are just input iterators.
5930</p>
5931
5932
5933<p><b>Rationale:</b></p>
5934<p>"at most 2N calls" is correct only if the growth factor
5935is greater than or equal to 2.
5936</p>
5937
5938
5939
5940
5941<hr>
5942<h3><a name="136"></a>136. seekp, seekg setting wrong streams?</h3>
5943<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>
5944 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 1999-03-06  <b>Last modified:</b> 2008-09-26</p>
5945<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>
5946<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
5947<p><b>Discussion:</b></p>
5948<p>I may be misunderstanding the intent, but should not seekg set only
5949the input stream and seekp set only the output stream? The description
5950seems to say that each should set both input and output streams. If
5951that's really the intent, I withdraw this proposal.</p>
5952
5953
5954<p><b>Proposed resolution:</b></p>
5955<p>In section 27.6.1.3 change:</p>
5956
5957<pre>basic_istream&lt;charT,traits&gt;&amp; seekg(pos_type pos);
5958Effects: If fail() != true, executes rdbuf()-&gt;pubseekpos(pos). </pre>
5959
5960<p>To:</p>
5961
5962<pre>basic_istream&lt;charT,traits&gt;&amp; seekg(pos_type pos);
5963Effects: If fail() != true, executes rdbuf()-&gt;pubseekpos(pos, ios_base::in). </pre>
5964
5965<p>In section 27.6.1.3 change:</p>
5966
5967<pre>basic_istream&lt;charT,traits&gt;&amp; seekg(off_type&amp; off, ios_base::seekdir dir);
5968Effects: If fail() != true, executes rdbuf()-&gt;pubseekoff(off, dir). </pre>
5969
5970<p>To:</p>
5971
5972<pre>basic_istream&lt;charT,traits&gt;&amp; seekg(off_type&amp; off, ios_base::seekdir dir);
5973Effects: If fail() != true, executes rdbuf()-&gt;pubseekoff(off, dir, ios_base::in). </pre>
5974
5975<p>In section 27.6.2.4, paragraph 2 change:</p>
5976
5977<pre>-2- Effects: If fail() != true, executes rdbuf()-&gt;pubseekpos(pos). </pre>
5978
5979<p>To:</p>
5980
5981<pre>-2- Effects: If fail() != true, executes rdbuf()-&gt;pubseekpos(pos, ios_base::out). </pre>
5982
5983<p>In section 27.6.2.4, paragraph 4 change:</p>
5984
5985<pre>-4- Effects: If fail() != true, executes rdbuf()-&gt;pubseekoff(off, dir). </pre>
5986
5987<p>To:</p>
5988
5989<pre>-4- Effects: If fail() != true, executes rdbuf()-&gt;pubseekoff(off, dir, ios_base::out). </pre>
5990
5991<p><i>[Dublin: Dietmar K�hl thinks this is probably correct, but would
5992like the opinion of more iostream experts before taking action.]</i></p>
5993
5994
5995<p><i>[Tokyo: Reviewed by the LWG. PJP noted that although his docs are
5996incorrect, his implementation already implements the Proposed
5997Resolution.]</i></p>
5998
5999
6000<p><i>[Post-Tokyo: Matt Austern comments:<br>
6001Is it a problem with basic_istream and basic_ostream, or is it a problem
6002with basic_stringbuf?
6003We could resolve the issue either by changing basic_istream and
6004basic_ostream, or by changing basic_stringbuf. I prefer the latter
6005change (or maybe both changes): I don't see any reason for the standard to
6006require that std::stringbuf s(std::string("foo"), std::ios_base::in);
6007s.pubseekoff(0, std::ios_base::beg); must fail.<br>
6008This requirement is a bit weird. There's no similar requirement
6009for basic_streambuf&lt;&gt;::seekpos, or for basic_filebuf&lt;&gt;::seekoff or
6010basic_filebuf&lt;&gt;::seekpos.]</i></p>
6011
6012
6013
6014
6015
6016
6017<hr>
6018<h3><a name="137"></a>137. Do use_facet and has_facet look in the global locale?</h3>
6019<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>
6020 <b>Submitter:</b> Angelika Langer <b>Opened:</b> 1999-03-17  <b>Last modified:</b> 2008-09-26</p>
6021<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>
6022<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>
6023<p><b>Discussion:</b></p>
6024<p>Section 22.3.1 [locale] says:</p>
6025
6026<p>-4- In the call to use_facet&lt;Facet&gt;(loc), the type argument
6027chooses a facet, making available all members of the named type. If
6028Facet is not present in a locale (or, failing that, in the global
6029locale), it throws the standard exception bad_cast. A C++ program can
6030check if a locale implements a particular facet with the template
6031function has_facet&lt;Facet&gt;(). </p>
6032
6033<p>This contradicts the specification given in section 
603422.3.2 [locale.global.templates]:
6035<br><br>
6036template &lt;class&nbsp; Facet&gt; const&nbsp; Facet&amp; use_facet(const
6037locale&amp;&nbsp; loc); <br>
6038<br>
6039-1- Get a reference to a facet of a locale. <br>
6040-2- Returns: a reference to the corresponding facet of loc, if present. <br>
6041-3- Throws: bad_cast if has_facet&lt;Facet&gt;(loc) is false. <br>
6042-4- Notes: The reference returned remains valid at least as long as any copy of loc exists
6043</p>
6044
6045
6046<p><b>Proposed resolution:</b></p>
6047<p>Remove the phrase "(or, failing that, in the global locale)"
6048from section 22.1.1. </p>
6049
6050
6051<p><b>Rationale:</b></p>
6052<p>Needed for consistency with the way locales are handled elsewhere
6053in the standard.</p>
6054
6055
6056
6057
6058<hr>
6059<h3><a name="139"></a>139. Optional sequence operation table description unclear</h3>
6060<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>
6061 <b>Submitter:</b> Andrew Koenig <b>Opened:</b> 1999-03-30  <b>Last modified:</b> 2008-09-26</p>
6062<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>
6063<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>
6064<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>
6065<p><b>Discussion:</b></p>
6066<p>The sentence introducing the Optional sequence operation table
6067(23.1.1 paragraph 12) has two problems:</p>
6068
6069<p>A. It says ``The operations in table 68 are provided only for the containers for which
6070they take constant time.''<br>
6071<br>
6072That could be interpreted in two ways, one of them being ``Even though table 68 shows
6073particular operations as being provided, implementations are free to omit them if they
6074cannot implement them in constant time.''<br>
6075<br>
6076B. That paragraph says nothing about amortized constant time, and it should.&nbsp;</p>
6077
6078
6079<p><b>Proposed resolution:</b></p>
6080<p>Replace the wording in 23.1.1 paragraph 12&nbsp; which begins ``The operations in table 68 are provided only..."
6081with:</p>
6082
6083<blockquote>
6084  <p>Table 68 lists sequence operations that are provided for some types of sequential
6085  containers but not others. An implementation shall provide these operations for all
6086  container types shown in the ``container'' column, and shall implement them so as to take
6087  amortized constant time.</p>
6088</blockquote>
6089
6090
6091
6092
6093<hr>
6094<h3><a name="141"></a>141. basic_string::find_last_of, find_last_not_of say pos instead of xpos</h3>
6095<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>
6096 <b>Submitter:</b> Arch Robison <b>Opened:</b> 1999-04-28  <b>Last modified:</b> 2008-09-26</p>
6097<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>
6098<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>
6099<p><b>Discussion:</b></p>
6100<p>Sections 21.3.6.4 paragraph 1 and 21.3.6.6 paragraph 1 surely have misprints where they
6101say:<br>
6102<br>
6103&#8212; <tt>xpos &lt;= pos</tt> and <tt>pos &lt; size();</tt></p>
6104
6105<p>Surely the document meant to say ``<tt>xpos &lt; size()</tt>'' in both places.</p>
6106
6107<p><i>[Judy Ward also sent in this issue for 21.3.6.4 with the same
6108proposed resolution.]</i></p>
6109
6110
6111
6112<p><b>Proposed resolution:</b></p>
6113<p>Change Sections 21.3.6.4 paragraph 1 and 21.3.6.6 paragraph 1, the line which says:<br>
6114<br>
6115&#8212; <tt>xpos &lt;= pos</tt> and <tt>pos &lt; size();<br>
6116<br>
6117</tt>to:<br>
6118<tt><br>
6119</tt>&#8212; <tt>xpos &lt;= pos</tt> and <tt>xpos &lt; size();</tt></p>
6120
6121
6122
6123
6124<hr>
6125<h3><a name="142"></a>142. lexicographical_compare complexity wrong</h3>
6126<p><b>Section:</b> 25.4.8 [alg.lex.comparison] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
6127 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 1999-06-20  <b>Last modified:</b> 2008-09-26</p>
6128<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>
6129<p><b>Discussion:</b></p>
6130<p>The lexicographical_compare complexity is specified as:<br>
6131<br>
6132&nbsp;&nbsp;&nbsp;&nbsp; "At most min((last1 - first1), (last2 - first2))
6133applications of the corresponding comparison."<br>
6134<br>
6135The best I can do is twice that expensive.</p>
6136
6137<p>Nicolai Josuttis comments in lib-6862: You mean, to check for
6138equality you have to check both &lt; and &gt;? Yes, IMO you are
6139right! (and Matt states this complexity in his book)</p>
6140
6141
6142
6143<p><b>Proposed resolution:</b></p>
6144<p>Change 25.4.8 [alg.lex.comparison] complexity to:</p>
6145    <blockquote><p>
6146    At most <tt>2*min((last1 - first1), (last2 - first2))</tt>
6147    applications of the corresponding comparison.
6148    </p></blockquote>
6149
6150<p>Change the example at the end of paragraph 3 to read:</p>
6151    <blockquote><p>
6152    [Example:<br>
6153    <br>
6154    &nbsp;&nbsp;&nbsp; for ( ; first1 != last1 &amp;&amp; first2 != last2 ;
6155    ++first1, ++first2) {<br>
6156    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (*first1 &lt; *first2) return true;<br>
6157    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (*first2 &lt; *first1) return false;<br>
6158    &nbsp;&nbsp;&nbsp; }<br>
6159    &nbsp;&nbsp;&nbsp; return first1 == last1 &amp;&amp; first2 != last2;<br>
6160    &nbsp;&nbsp;&nbsp;<br>
6161    --end example]
6162    </p></blockquote>
6163
6164
6165
6166
6167<hr>
6168<h3><a name="144"></a>144. Deque constructor complexity wrong </h3>
6169<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>
6170 <b>Submitter:</b> Herb Sutter <b>Opened:</b> 1999-05-09  <b>Last modified:</b> 2008-09-26</p>
6171<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>
6172<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>
6173<p><b>Discussion:</b></p>
6174<p>In 23.3.2.1 [deque.cons] paragraph 6, the deque ctor that takes an iterator range appears
6175to have complexity requirements which are incorrect, and which contradict the
6176complexity requirements for insert(). I suspect that the text in question,
6177below, was taken from vector:</p>
6178<blockquote>
6179  <p>Complexity: If the iterators first and last are forward iterators,
6180  bidirectional iterators, or random access iterators the constructor makes only
6181  N calls to the copy constructor, and performs no reallocations, where N is
6182  last - first.</p>
6183</blockquote>
6184<p>The word "reallocations" does not really apply to deque. Further,
6185all of the following appears to be spurious:</p>
6186<blockquote>
6187  <p>It makes at most 2N calls to the copy constructor of T and log N
6188  reallocations if they are input iterators.1)</p>
6189  <p>1) The complexity is greater in the case of input iterators because each
6190  element must be added individually: it is impossible to determine the distance
6191  between first abd last before doing the copying.</p>
6192</blockquote>
6193<p>This makes perfect sense for vector, but not for deque. Why should deque gain
6194an efficiency advantage from knowing in advance the number of elements to
6195insert?</p>
6196
6197
6198<p><b>Proposed resolution:</b></p>
6199<p>In 23.3.2.1 [deque.cons] paragraph 6, replace the Complexity description, including the
6200footnote, with the following text (which also corrects the "abd"
6201typo):</p>
6202<blockquote>
6203  <p>Complexity: Makes last - first calls to the copy constructor of T.</p>
6204</blockquote>
6205
6206
6207
6208
6209<hr>
6210<h3><a name="146"></a>146. complex&lt;T&gt; Inserter and Extractor need sentries</h3>
6211<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>
6212 <b>Submitter:</b> Angelika Langer <b>Opened:</b> 1999-05-12  <b>Last modified:</b> 2008-09-26</p>
6213<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>
6214<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>
6215<p><b>Discussion:</b></p>
6216<p>The extractor for complex numbers is specified as:&nbsp;</p>
6217
6218<blockquote>
6219
6220<p>     template&lt;class T, class charT, class traits&gt;&nbsp;<br>
6221     basic_istream&lt;charT, traits&gt;&amp;&nbsp;<br>
6222     operator&gt;&gt;(basic_istream&lt;charT, traits&gt;&amp;  is, complex&lt;T&gt;&amp;  x);<br>
6223&nbsp;<br>
6224Effects: Extracts a complex number x of the form: u, (u), or (u,v),
6225where u is the real part and v is the imaginary part
6226(lib.istream.formatted).&nbsp;<br>
6227Requires: The input values be convertible to T. If bad input is
6228encountered, calls is.setstate(ios::failbit) (which may throw
6229ios::failure (lib.iostate.flags).&nbsp;<br>
6230Returns: is .</p>
6231
6232</blockquote>
6233<p>Is it intended that the extractor for complex numbers does not skip
6234whitespace, unlike all other extractors in the standard library do?
6235Shouldn't a sentry be used?&nbsp;<br>
6236<br>
6237The inserter for complex numbers is specified as:</p>
6238
6239<blockquote>
6240
6241<p>     template&lt;class T, class charT, class traits&gt;&nbsp;<br>
6242     basic_ostream&lt;charT, traits&gt;&amp;&nbsp;<br>
6243     operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp;  o, const complex&lt;T&gt;&amp;  x);<br>
6244<br>
6245Effects: inserts the complex number x onto the stream o as if it were implemented as follows:<br>
6246<br>
6247     template&lt;class T, class charT, class traits&gt;&nbsp;<br>
6248     basic_ostream&lt;charT, traits&gt;&amp;&nbsp;<br>
6249     operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; o, const complex&lt;T&gt;&amp; x)&nbsp;<br>
6250     {&nbsp;<br>
6251             basic_ostringstream&lt;charT, traits&gt; s;&nbsp;<br>
6252             s.flags(o.flags());&nbsp;<br>
6253             s.imbue(o.getloc());&nbsp;<br>
6254             s.precision(o.precision());&nbsp;<br>
6255             s &lt;&lt; '(' &lt;&lt; x.real() &lt;&lt; "," &lt;&lt; x.imag() &lt;&lt; ')';&nbsp;<br>
6256             return o &lt;&lt; s.str();&nbsp;<br>
6257     }</p>
6258
6259</blockquote>
6260
6261<p>Is it intended that the inserter for complex numbers ignores the
6262field width and does not do any padding? If, with the suggested
6263implementation above, the field width were set in the stream then the
6264opening parentheses would be adjusted, but the rest not, because the
6265field width is reset to zero after each insertion.</p>
6266
6267<p>I think that both operations should use sentries, for sake of
6268consistency with the other inserters and extractors in the
6269library. Regarding the issue of padding in the inserter, I don't know
6270what the intent was.&nbsp;</p>
6271
6272
6273<p><b>Proposed resolution:</b></p>
6274<p>After 26.4.6 [complex.ops] paragraph 14 (operator&gt;&gt;), add a
6275Notes clause:</p>
6276
6277<blockquote>
6278
6279<p>Notes: This extraction is performed as a series of simpler
6280extractions. Therefore, the skipping of whitespace is specified to be the
6281same for each of the simpler extractions.</p>
6282
6283</blockquote>
6284
6285
6286<p><b>Rationale:</b></p>
6287<p>For extractors, the note is added to make it clear that skipping whitespace
6288follows an "all-or-none" rule.</p>
6289
6290<p>For inserters, the LWG believes there is no defect; the standard is correct
6291as written.</p>
6292
6293
6294
6295
6296<hr>
6297<h3><a name="147"></a>147. Library Intro refers to global functions that aren't global</h3>
6298<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>
6299 <b>Submitter:</b> Lois Goldthwaite <b>Opened:</b> 1999-06-04  <b>Last modified:</b> 2008-09-26</p>
6300<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>
6301<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>
6302<p><b>Discussion:</b></p>
6303<p>The library had many global functions until 17.4.1.1 [lib.contents]
6304paragraph 2 was added: </p>
6305
6306<blockquote>
6307
6308<p>All library entities except macros, operator new and operator
6309delete are defined within the namespace std or namespaces nested
6310within namespace std. </p>
6311
6312</blockquote>
6313
6314<p>It appears "global function" was never updated in the following: </p>
6315
6316<blockquote>
6317
6318<p>17.4.4.3 - Global functions [lib.global.functions]<br>
6319<br>
6320-1- It is unspecified whether any global functions in the C++ Standard
6321Library are defined as inline (dcl.fct.spec).<br>
6322<br>
6323-2- A call to a global function signature described in Clauses
6324lib.language.support through lib.input.output behaves the same as if
6325the implementation declares no additional global function
6326signatures.*<br>
6327<br>
6328    [Footnote: A valid C++ program always calls the expected library
6329    global function. An implementation may also define additional
6330    global functions that would otherwise not be called by a valid C++
6331    program. --- end footnote]<br>
6332<br>
6333-3- A global function cannot be declared by the implementation as
6334taking additional default arguments.&nbsp;<br>
6335<br>
633617.4.4.4 - Member functions [lib.member.functions]<br>
6337<br>
6338-2- An implementation can declare additional non-virtual member
6339function signatures within a class: </p>
6340
6341  <blockquote>
6342
6343<p>-- by adding arguments with default values to a member function
6344signature; The same latitude does not extend to the implementation of
6345virtual or global functions, however. </p>
6346
6347  </blockquote>
6348</blockquote>
6349
6350
6351<p><b>Proposed resolution:</b></p>
6352<p>     Change "global" to "global or non-member" in:</p>
6353<blockquote>
6354  <p>17.4.4.3 [lib.global.functions] section title,<br>
6355  17.4.4.3 [lib.global.functions] para 1,<br>
6356  17.4.4.3 [lib.global.functions] para 2 in 2 places plus 2 
6357           places in the footnote,<br>
6358  17.4.4.3 [lib.global.functions] para 3,<br>
6359  17.4.4.4 [lib.member.functions] para 2</p>
6360</blockquote>
6361
6362
6363<p><b>Rationale:</b></p>
6364<p>
6365Because operator new and delete are global, the proposed resolution
6366was changed from "non-member" to "global or non-member.
6367</p>
6368
6369
6370
6371
6372<hr>
6373<h3><a name="148"></a>148. Functions in the example facet BoolNames should be const</h3>
6374<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>
6375 <b>Submitter:</b> Jeremy Siek <b>Opened:</b> 1999-06-03  <b>Last modified:</b> 2008-09-26</p>
6376<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>
6377<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>
6378<p><b>Discussion:</b></p>
6379<p>In 22.4.8 [facets.examples] paragraph 13, the do_truename() and
6380do_falsename() functions in the example facet BoolNames should be
6381const. The functions they are overriding in
6382numpunct_byname&lt;char&gt; are const. </p>
6383
6384
6385<p><b>Proposed resolution:</b></p>
6386<p>In 22.4.8 [facets.examples] paragraph 13, insert "const" in
6387two places:</p>
6388<blockquote>
6389  <p><tt>string do_truename() const { return "Oui Oui!"; }<br>
6390  string do_falsename() const { return "Mais Non!"; }</tt></p>
6391</blockquote>
6392
6393
6394
6395
6396<hr>
6397<h3><a name="149"></a>149. Insert should return iterator to first element inserted</h3>
6398<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#WP">WP</a>
6399 <b>Submitter:</b> Andrew Koenig <b>Opened:</b> 1999-06-28  <b>Last modified:</b> 2009-10-26</p>
6400<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>
6401<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>
6402<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
6403<p><b>Discussion:</b></p>
6404<p>Suppose that c and c1 are sequential containers and i is an
6405iterator that refers to an element of c.  Then I can insert a copy of
6406c1's elements into c ahead of element i by executing </p>
6407
6408<blockquote>
6409
6410<pre>c.insert(i, c1.begin(), c1.end());</pre>
6411
6412</blockquote>
6413
6414<p>If c is a vector, it is fairly easy for me to find out where the
6415newly inserted elements are, even though i is now invalid: </p>
6416
6417<blockquote>
6418
6419<pre>size_t i_loc = i - c.begin();
6420c.insert(i, c1.begin(), c1.end());</pre>
6421
6422</blockquote>
6423
6424<p>and now the first inserted element is at c.begin()+i_loc and one
6425past the last is at c.begin()+i_loc+c1.size().<br>
6426<br>
6427But what if c is a list? I can still find the location of one past the
6428last inserted element, because i is still valid. To find the location
6429of the first inserted element, though, I must execute something like </p>
6430
6431<blockquote>
6432
6433<pre>for (size_t n = c1.size(); n; --n)
6434   --i;</pre>
6435
6436</blockquote>
6437
6438<p>because i is now no longer a random-access iterator.<br>
6439<br>
6440Alternatively, I might write something like </p>
6441
6442<blockquote>
6443
6444<pre>bool first = i == c.begin();
6445list&lt;T&gt;::iterator j = i;
6446if (!first) --j;
6447c.insert(i, c1.begin(), c1.end());
6448if (first)
6449   j = c.begin();
6450else
6451   ++j;</pre>
6452
6453</blockquote>
6454
6455<p>which, although wretched, requires less overhead.<br>
6456<br>
6457But I think the right solution is to change the definition of insert
6458so that instead of returning void, it returns an iterator that refers
6459to the first element inserted, if any, and otherwise is a copy of its
6460first argument.&nbsp; </p>
6461
6462<p><i>[
6463Summit:
6464]</i></p>
6465
6466
6467<blockquote>
6468Reopened by Alisdair.
6469</blockquote>
6470
6471<p><i>[
6472Post Summit Alisdair adds:
6473]</i></p>
6474
6475
6476<blockquote>
6477<p>
6478In addition to the original rationale for C++03, this change also gives a
6479consistent interface for all container insert operations i.e. they all
6480return an iterator to the (first) inserted item.
6481</p>
6482
6483<p>
6484Proposed wording provided.
6485</p>
6486</blockquote>
6487
6488<p><i>[
64892009-07 Frankfurt
6490]</i></p>
6491
6492
6493<blockquote>
6494<p>
6495Q: why isn't this change also proposed for associative containers?
6496</p>
6497
6498<p>
6499A: The returned iterator wouldn't necessarily point to a contiguous range.
6500</p>
6501
6502<p>
6503Moved to Ready.
6504</p>
6505</blockquote>
6506
6507
6508
6509<p><b>Proposed resolution:</b></p>
6510<p>
6511<sef ref="[sequence.reqmts]"> Table 83
6512change return type from <tt>void</tt> to <tt>iterator</tt> for the following rows:
6513</sef></p>
6514
6515<blockquote>
6516<table border="1">
6517<caption>Table 83 -- Sequence container requirements (in addition to container)</caption>
6518<tbody><tr>
6519<th>Expression</th>
6520<th>Return type</th>
6521<th>Assertion/note pre-/post-condition</th>
6522</tr>
6523<tr>
6524<td>
6525<tt>a.insert(p,n,t)</tt>
6526</td>
6527<td>
6528<tt><del>void</del> <ins>iterator</ins></tt>
6529</td>
6530<td>
6531Inserts <tt>n</tt> copies of <tt>t</tt> before <tt>p</tt>.
6532</td>
6533</tr>
6534
6535<tr>
6536<td>
6537<tt>a.insert(p,i,j)</tt>
6538</td>
6539<td>
6540<tt><del>void</del> <ins>iterator</ins></tt>
6541</td>
6542<td>
6543Each iterator in the range <tt>[i,j)</tt> shall be 
6544dereferenced exactly once. 
6545pre: <tt>i</tt> and <tt>j</tt> are not iterators into <tt>a</tt>. 
6546Inserts copies of elements in <tt>[i, j)</tt> before <tt>p</tt>
6547</td>
6548</tr>
6549
6550<tr>
6551<td>
6552<tt>a.insert(p,il)</tt>
6553</td>
6554<td>
6555<tt><del>void</del> <ins>iterator</ins></tt>
6556</td>
6557<td>
6558<tt>a.insert(p, il.begin(), il.end())</tt>.
6559</td>
6560</tr>
6561</tbody></table>
6562</blockquote>
6563
6564<p>
6565Add after p6 23.2.3 [sequence.reqmts]:
6566</p>
6567
6568<blockquote>
6569<p>-6- ...</p>
6570
6571<p><ins>
6572The iterator returned from <tt>a.insert(p,n,t)</tt> points to the copy of the
6573first element inserted into <tt>a</tt>, or <tt>p</tt> if <tt>n == 0</tt>.
6574</ins></p>
6575
6576<p><ins>
6577The iterator returned from <tt>a.insert(p,i,j)</tt> points to the copy of the
6578first element inserted into <tt>a</tt>, or <tt>p</tt> if <tt>i == j</tt>.
6579</ins></p>
6580
6581<p><ins>
6582The iterator returned from <tt>a.insert(p,il)</tt> points to the copy of the
6583first element inserted into <tt>a</tt>, or <tt>p</tt> if <tt>il</tt> is empty.
6584</ins></p>
6585
6586</blockquote>
6587
6588<p>
6589p2 23.3.2 [deque] Update class definition, change return type
6590from <tt>void</tt> to <tt>iterator</tt>:
6591</p>
6592
6593<blockquote><pre><del>void</del> <ins>iterator</ins> insert(const_iterator position, size_type n, const T&amp; x);
6594template &lt;class InputIterator&gt;
6595  <del>void</del> <ins>iterator</ins> insert(const_iterator position, InputIterator first, InputIterator last);
6596  <del>void</del> <ins>iterator</ins> insert(const_iterator position, initializer_list&lt;T&gt;);
6597</pre></blockquote>
6598
6599<p>
660023.3.2.3 [deque.modifiers] change return type from <tt>void</tt> to <tt>iterator</tt> on following declarations:
6601</p>
6602
6603<blockquote><pre>  <del>void</del> <ins>iterator</ins> insert(const_iterator position, size_type n, const T&amp; x);
6604template &lt;class InputIterator&gt;
6605  <del>void</del> <ins>iterator</ins> insert(const_iterator position, InputIterator first, InputIterator last);
6606</pre></blockquote>
6607
6608<p>
6609Add the following (missing) declaration
6610</p>
6611
6612<blockquote><pre><ins>iterator insert(const_iterator position, initializer_list&lt;T&gt;);</ins>
6613</pre></blockquote>
6614
6615<p>
661623.3.3 [forwardlist] Update class definition, change return type
6617from <tt>void</tt> to <tt>iterator</tt>:
6618</p>
6619
6620<blockquote><pre><del>void</del> <ins>iterator</ins> insert_after(const_iterator position, initializer_list&lt;T&gt; il);
6621<del>void</del> <ins>iterator</ins> insert_after(const_iterator position, size_type n, const T&amp; x);
6622template &lt;class InputIterator&gt;
6623  <del>void</del> <ins>iterator</ins> insert_after(const_iterator position, InputIterator first, InputIterator last);
6624</pre></blockquote>
6625
6626<p>
6627p8 23.3.3.4 [forwardlist.modifiers] change return type from <tt>void</tt> to <tt>iterator</tt>:
6628</p>
6629
6630<blockquote><pre><del>void</del> <ins>iterator</ins> insert_after(const_iterator position, size_type n, const T&amp; x);
6631</pre></blockquote>
6632
6633<p>
6634Add paragraph:
6635</p>
6636
6637<blockquote>
6638Returns: position.
6639</blockquote>
6640
6641<p>
6642p10 23.3.3.4 [forwardlist.modifiers] change return type from <tt>void</tt> to <tt>iterator</tt>:
6643</p>
6644
6645<blockquote><pre>template &lt;class InputIterator&gt;
6646  <del>void</del> <ins>iterator</ins> insert_after(const_iterator position, InputIterator first, InputIterator last);
6647</pre></blockquote>
6648
6649<p>
6650Add paragraph:
6651</p>
6652
6653<blockquote>
6654Returns: position.
6655</blockquote>
6656
6657<p>
6658p12 23.3.3.4 [forwardlist.modifiers] change return type from <tt>void</tt> to <tt>iterator</tt> on following declarations:
6659</p>
6660
6661<blockquote><pre><del>void</del> <ins>iterator</ins> insert_after(const_iterator position, initializer_list&lt;T&gt; il);
6662</pre></blockquote>
6663
6664<p>
6665change return type from <tt>void</tt> to <tt>iterator</tt> on following declarations:
6666</p>
6667
6668<p>
6669p2 23.3.4 [list] Update class definition, change return type from <tt>void</tt> to <tt>iterator</tt>:
6670</p>
6671
6672<blockquote><pre><del>void</del> <ins>iterator</ins> insert(const_iterator position, size_type n, const T&amp; x);
6673
6674template &lt;class InputIterator&gt;
6675<del>void</del> <ins>iterator</ins> insert(const_iterator position, InputIterator first, InputIterator last);
6676
6677<del>void</del> <ins>iterator</ins> insert(const_iterator position, initializer_list&lt;T&gt;);
6678</pre></blockquote>
6679
6680<p>
668123.3.4.3 [list.modifiers] change return type from <tt>void</tt> to <tt>iterator</tt> on following declarations:
6682</p>
6683
6684<blockquote><pre><del>void</del> <ins>iterator</ins> insert(const_iterator position, size_type n, const T&amp; x);
6685
6686template &lt;class InputIterator&gt;
6687  <del>void</del> <ins>iterator</ins> insert(const_iterator position, InputIterator first, InputIterator last);
6688</pre></blockquote>
6689
6690<p>
6691Add the following (missing) declaration
6692</p>
6693
6694<blockquote><pre>iterator insert(const_iterator position, initializer_list&lt;T&gt;);
6695</pre></blockquote>
6696
6697<p>
6698p2 23.3.6 [vector]
6699</p>
6700
6701<p>
6702Update class definition, change return type from <tt>void</tt> to <tt>iterator</tt>:
6703</p>
6704
6705<blockquote><pre><del>void</del> <ins>iterator</ins> insert(const_iterator position, T&amp;&amp; x);
6706
6707<del>void</del> <ins>iterator</ins> insert(const_iterator position, size_type n, const T&amp; x);
6708
6709template &lt;class InputIterator&gt;
6710  <del>void</del> <ins>iterator</ins> insert(const_iterator position, InputIterator first, InputIterator last);
6711
6712<del>void</del> <ins>iterator</ins> insert(const_iterator position, initializer_list&lt;T&gt;);
6713</pre></blockquote>
6714
6715<p>
671623.3.6.4 [vector.modifiers] change return type from <tt>void</tt> to <tt>iterator</tt> on following declarations:
6717</p>
6718
6719<blockquote><pre><del>void</del> <ins>iterator</ins> insert(const_iterator position, size_type n, const T&amp; x);
6720
6721template &lt;class InputIterator&gt;
6722  <del>void</del> <ins>iterator</ins> insert(const_iterator position, InputIterator first, InputIterator last);
6723</pre></blockquote>
6724
6725<p>
6726Add the following (missing) declaration
6727</p>
6728
6729<blockquote><pre>iterator insert(const_iterator position, initializer_list&lt;T&gt;);
6730</pre></blockquote>
6731
6732
6733<p>
6734p1 23.3.7 [vector.bool] Update class definition, change return type from <tt>void</tt> to <tt>iterator</tt>:
6735</p>
6736
6737<blockquote><pre><del>void</del> <ins>iterator</ins> insert (const_iterator position, size_type n, const bool&amp; x);
6738
6739template &lt;class InputIterator&gt;
6740  <del>void</del> <ins>iterator</ins> insert(const_iterator position, InputIterator first, InputIterator last);
6741
6742  <del>void</del> <ins>iterator</ins> insert(const_iterator position, initializer_list&lt;bool&gt; il);
6743</pre></blockquote>
6744
6745<p>
6746p5 21.4 [basic.string] Update class definition, change return type from <tt>void</tt> to <tt>iterator</tt>:
6747</p>
6748
6749<blockquote><pre><del>void</del> <ins>iterator</ins> insert(const_iterator p, size_type n, charT c);
6750
6751template&lt;class InputIterator&gt;
6752  <del>void</del> <ins>iterator</ins> insert(const_iterator p, InputIterator first, InputIterator last);
6753
6754<del>void</del> <ins>iterator</ins> insert(const_iterator p, initializer_list&lt;charT&gt;);
6755</pre></blockquote>
6756
6757<p>
6758p13 21.4.6.4 [string::insert] change return type from <tt>void</tt> to <tt>iterator</tt>:
6759</p>
6760
6761<blockquote><pre><del>void</del> <ins>iterator</ins> insert(const_iterator p, size_type n, charT c);
6762</pre></blockquote>
6763
6764<p>
6765Add paragraph:
6766</p>
6767
6768<blockquote>
6769<i>Returns:</i> an iterator which refers to the copy of the first inserted
6770character, or <tt>p</tt> if <tt>n == 0</tt>.
6771</blockquote>
6772
6773<p>
6774p15 21.4.6.4 [string::insert] change return type from <tt>void</tt> to <tt>iterator</tt>:
6775</p>
6776
6777<blockquote><pre>template&lt;class InputIterator&gt;
6778  <del>void</del> <ins>iterator</ins> insert(const_iterator p, InputIterator first, InputIterator last);
6779</pre></blockquote>
6780
6781<p>
6782Add paragraph:
6783</p>
6784
6785<blockquote>
6786<i>Returns:</i> an iterator which refers to the copy of the first inserted
6787character, or <tt>p</tt> if <tt>first == last</tt>.
6788</blockquote>
6789
6790<p>
6791p17 21.4.6.4 [string::insert] change return type from <tt>void</tt> to <tt>iterator</tt>:
6792</p>
6793
6794<blockquote><pre><del>void</del> <ins>iterator</ins> insert(const_iterator p, initializer_list&lt;charT&gt; il);
6795</pre></blockquote>
6796
6797<p>
6798Add paragraph:
6799</p>
6800
6801<blockquote>
6802<i>Returns:</i> an iterator which refers to the copy of the first inserted
6803character, or <tt>p</tt> if <tt>il</tt> is empty.
6804</blockquote>
6805
6806
6807
6808<p><b>Rationale:</b></p>
6809
6810<p><i>[
6811The following was the C++98/03 rationale and does not necessarily apply to the
6812proposed resolution in the C++0X time frame:
6813]</i></p>
6814
6815
6816<blockquote>
6817<p>The LWG believes this was an intentional design decision and so is
6818not a defect. It may be worth revisiting for the next standard.</p>
6819</blockquote>
6820
6821
6822
6823
6824<hr>
6825<h3><a name="150"></a>150. Find_first_of says integer instead of iterator </h3>
6826<p><b>Section:</b> 25.2.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>
6827 <b>Submitter:</b> Matt McClure <b>Opened:</b> 1999-06-30  <b>Last modified:</b> 2008-09-26</p>
6828<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>
6829<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>
6830<p><b>Discussion:</b></p>
6831
6832
6833<p><b>Proposed resolution:</b></p>
6834<p>Change 25.2.7 [alg.find.first.of] paragraph 2 from:</p>
6835
6836<blockquote>
6837<p>Returns: The first iterator i in the range [first1, last1) such
6838that for some integer j in the range [first2, last2) ...</p>
6839</blockquote>
6840
6841<p>to:</p>
6842
6843<blockquote>
6844<p>Returns: The first iterator i in the range [first1, last1) such
6845that for some iterator j in the range [first2, last2) ...</p>
6846</blockquote>
6847
6848
6849
6850
6851<hr>
6852<h3><a name="151"></a>151. Can't currently clear() empty container</h3>
6853<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>
6854 <b>Submitter:</b> Ed Brey <b>Opened:</b> 1999-06-21  <b>Last modified:</b> 2008-09-26</p>
6855<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>
6856<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>
6857<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>
6858<p><b>Discussion:</b></p>
6859<p>For both sequences and associative containers, a.clear() has the
6860semantics of erase(a.begin(),a.end()), which is undefined for an empty
6861container since erase(q1,q2) requires that q1 be dereferenceable
6862(23.1.1,3 and 23.1.2,7).  When the container is empty, a.begin() is
6863not dereferenceable.<br>
6864<br>
6865The requirement that q1 be unconditionally dereferenceable causes many
6866operations to be intuitively undefined, of which clearing an empty
6867container is probably the most dire.<br>
6868<br>
6869Since q1 and q2 are only referenced in the range [q1, q2), and [q1,
6870q2) is required to be a valid range, stating that q1 and q2 must be
6871iterators or certain kinds of iterators is unnecessary.
6872</p>
6873
6874
6875<p><b>Proposed resolution:</b></p>
6876<p>In 23.1.1, paragraph 3, change:</p>
6877<blockquote>
6878  <p>p and q2 denote valid iterators to a, q and q1 denote valid dereferenceable iterators to a, [q1, q2) denotes a valid range</p>
6879</blockquote>
6880<p>to:</p>
6881<blockquote>
6882  <p>p denotes a valid iterator to a, q denotes a valid dereferenceable iterator to a, [q1, q2) denotes a valid range
6883  in a</p>
6884</blockquote>
6885<p>In 23.1.2, paragraph 7, change:</p>
6886<blockquote>
6887  <p>p and q2 are valid iterators to a, q and q1 are valid dereferenceable
6888  iterators to a, [q1, q2) is a valid range</p>
6889</blockquote>
6890<p>to</p>
6891<blockquote>
6892  <p>p is a valid iterator to a, q is a valid dereferenceable iterator to a, [q1, q2) is a valid range
6893  into a</p>
6894</blockquote>
6895
6896
6897
6898
6899<hr>
6900<h3><a name="152"></a>152. Typo in <tt>scan_is()</tt> semantics</h3>
6901<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>
6902 <b>Submitter:</b> Dietmar K�hl <b>Opened:</b> 1999-07-20  <b>Last modified:</b> 2008-09-26</p>
6903<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>
6904<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>
6905<p><b>Discussion:</b></p>
6906<p>The semantics of <tt>scan_is()</tt> (paragraphs 4 and 6) is not exactly described
6907because there is no function <tt>is()</tt> which only takes a character as
6908argument. Also, in the effects clause (paragraph 3), the semantic is also kept
6909vague.</p>
6910
6911
6912<p><b>Proposed resolution:</b></p>
6913<p>In 22.4.1.1.2 [locale.ctype.virtuals] paragraphs 4 and 6, change the returns
6914clause from:</p>
6915<blockquote>
6916  <p>"... such that <tt>is(*p)</tt>
6917would..."</p>
6918</blockquote>
6919<p>to:&nbsp; "... such that <tt>is(m, *p)</tt>
6920 would...."</p>
6921
6922
6923
6924
6925
6926<hr>
6927<h3><a name="153"></a>153. Typo in <tt>narrow()</tt> semantics</h3>
6928<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>
6929 <b>Submitter:</b> Dietmar K�hl <b>Opened:</b> 1999-07-20  <b>Last modified:</b> 2008-09-26</p>
6930<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>
6931<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
6932<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#207">207</a></p>
6933<p><b>Discussion:</b></p>
6934<p>The description of the array version of <tt>narrow()</tt> (in
6935paragraph 11) is flawed: There is no member <tt>do_narrow()</tt> which
6936takes only three arguments because in addition to the range a default
6937character is needed.</p>
6938
6939<p>Additionally, for both <tt>widen</tt> and <tt>narrow</tt> we have
6940two signatures followed by a <b>Returns</b> clause that only addresses
6941one of them.</p>
6942
6943
6944
6945<p><b>Proposed resolution:</b></p>
6946<p>Change the returns clause in 22.4.1.3.2 [facet.ctype.char.members]
6947paragraph 10 from:</p>
6948<p>&nbsp;&nbsp;&nbsp; Returns: do_widen(low, high, to).</p>
6949
6950<p>to:</p>
6951<p>&nbsp;&nbsp;&nbsp; Returns: do_widen(c) or do_widen(low, high, to), 
6952respectively.</p>
6953
6954<p>Change 22.4.1.3.2 [facet.ctype.char.members] paragraph 10 and 11 from:</p>
6955<pre>        char        narrow(char c, char /*dfault*/) const;
6956        const char* narrow(const char* low, const char* high,
6957                           char /*dfault*/, char* to) const;</pre>
6958<pre>        Returns: do_narrow(low, high, to).</pre>
6959<p>to:</p>
6960<pre>        char        narrow(char c, char dfault) const;
6961        const char* narrow(const char* low, const char* high,
6962                           char dfault, char* to) const;</pre>
6963<pre>        Returns: do_narrow(c, dfault) or
6964                 do_narrow(low, high, dfault, to), respectively.</pre>
6965
6966<p><i>[Kona: 1) the problem occurs in additional places, 2) a user
6967defined version could be different.]</i></p>
6968
6969
6970<p><i>[Post-Tokyo: Dietmar provided the above wording at the request of
6971the LWG. He could find no other places the problem occurred. He
6972asks for clarification of the Kona "a user defined
6973version..." comment above.  Perhaps it was a circuitous way of
6974saying "dfault" needed to be uncommented?]</i></p>
6975
6976
6977<p><i>[Post-Toronto: the issues list maintainer has merged in the
6978proposed resolution from issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#207">207</a>, which addresses the
6979same paragraphs.]</i></p>
6980
6981
6982
6983
6984
6985
6986<hr>
6987<h3><a name="154"></a>154. Missing <tt>double</tt> specifier for <tt>do_get()</tt></h3>
6988<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>
6989 <b>Submitter:</b> Dietmar K�hl <b>Opened:</b> 1999-07-20  <b>Last modified:</b> 2008-09-26</p>
6990<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>
6991<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>
6992<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>
6993<p><b>Discussion:</b></p>
6994<p>The table in paragraph 7 for the length modifier does not list the length
6995modifier <tt>l</tt> to be applied if the type is <tt>double</tt>. Thus, the
6996standard asks the implementation to do undefined things when using <tt>scanf()</tt>
6997(the missing length modifier for <tt>scanf()</tt> when scanning <tt>double</tt>s
6998is actually a problem I found quite often in production code, too).</p>
6999
7000
7001<p><b>Proposed resolution:</b></p>
7002<p>In 22.4.2.1.2 [facet.num.get.virtuals], paragraph 7, add a row in the Length
7003Modifier table to say that for <tt>double</tt> a length modifier
7004<tt>l</tt> is to be used.</p>
7005
7006
7007<p><b>Rationale:</b></p>
7008<p>The standard makes an embarrassing beginner's mistake.</p>
7009
7010
7011
7012
7013<hr>
7014<h3><a name="155"></a>155. Typo in naming the class defining the class <tt>Init</tt></h3>
7015<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>
7016 <b>Submitter:</b> Dietmar K�hl <b>Opened:</b> 1999-07-20  <b>Last modified:</b> 2008-09-26</p>
7017<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>
7018<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>
7019<p><b>Discussion:</b></p>
7020<p>There are conflicting statements about where the class
7021<tt>Init</tt> is defined. According to 27.4 [iostream.objects] paragraph 2
7022it 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>
7023
7024
7025<p><b>Proposed resolution:</b></p>
7026<p>Change 27.4 [iostream.objects] paragraph 2 from
7027"<tt>basic_ios::Init"</tt> to
7028"<tt>ios_base::Init"</tt>.</p>
7029
7030
7031<p><b>Rationale:</b></p>
7032<p>Although not strictly wrong, the standard was misleading enough to warrant
7033the change.</p>
7034
7035
7036
7037
7038<hr>
7039<h3><a name="156"></a>156. Typo in <tt>imbue()</tt> description</h3>
7040<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>
7041 <b>Submitter:</b> Dietmar K�hl <b>Opened:</b> 1999-07-20  <b>Last modified:</b> 2008-09-26</p>
7042<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>
7043<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>
7044<p><b>Discussion:</b></p>
7045<p>There is a small discrepancy between the declarations of
7046<tt>imbue()</tt>: in 27.5.2 [ios.base] the argument is passed as
7047<tt>locale const&amp;</tt> (correct), in 27.5.2.3 [ios.base.locales] it
7048is passed as <tt>locale const</tt> (wrong).</p>
7049
7050
7051<p><b>Proposed resolution:</b></p>
7052<p>In 27.5.2.3 [ios.base.locales] change the <tt>imbue</tt> argument
7053from "<tt>locale const" to "locale
7054const&amp;".</tt></p>
7055
7056
7057
7058
7059<hr>
7060<h3><a name="158"></a>158. Underspecified semantics for <tt>setbuf()</tt></h3>
7061<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>
7062 <b>Submitter:</b> Dietmar K�hl <b>Opened:</b> 1999-07-20  <b>Last modified:</b> 2008-09-26</p>
7063<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>
7064<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>
7065<p><b>Discussion:</b></p>
7066<p>The default behavior of <tt>setbuf()</tt> is described only for the
7067situation that <tt>gptr() != 0 &amp;&amp; gptr() != egptr()</tt>:
7068namely to do nothing.  What has to be done in other situations&nbsp;
7069is not described although there is actually only one reasonable
7070approach, namely to do nothing, too.</p> 
7071
7072<p>Since changing the buffer would almost certainly mess up most
7073buffer management of derived classes unless these classes do it
7074themselves, the default behavior of <tt>setbuf()</tt> should always be
7075to do nothing.</p>
7076
7077
7078<p><b>Proposed resolution:</b></p>
7079<p>Change 27.6.2.4.2 [streambuf.virt.buffer], paragraph 3, Default behavior,
7080to: "Default behavior: Does nothing. Returns this."</p>
7081
7082
7083
7084
7085<hr>
7086<h3><a name="159"></a>159. Strange use of <tt>underflow()</tt></h3>
7087<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>
7088 <b>Submitter:</b> Dietmar K�hl <b>Opened:</b> 1999-07-20  <b>Last modified:</b> 2008-09-26</p>
7089<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>
7090<p><b>Discussion:</b></p>
7091<p>The description of the meaning of the result of
7092<tt>showmanyc()</tt> seems to be rather strange: It uses calls to
7093<tt>underflow()</tt>. Using <tt>underflow()</tt> is strange because
7094this function only reads the current character but does not extract
7095it, <tt>uflow()</tt> would extract the current character. This should
7096be fixed to use <tt>sbumpc()</tt> instead.</p>
7097
7098
7099<p><b>Proposed resolution:</b></p>
7100<p>Change 27.6.2.4.3 [streambuf.virt.get] paragraph 1,
7101<tt>showmanyc()</tt>returns clause, by replacing the word
7102"supplied" with the words "extracted from the
7103stream".</p>
7104
7105
7106
7107
7108<hr>
7109<h3><a name="160"></a>160. Typo: Use of non-existing function <tt>exception()</tt></h3>
7110<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>
7111 <b>Submitter:</b> Dietmar K�hl <b>Opened:</b> 1999-07-20  <b>Last modified:</b> 2008-09-26</p>
7112<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>
7113<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>
7114<p><b>Discussion:</b></p>
7115<p>The paragraph 4 refers to the function <tt>exception()</tt> which
7116is not defined. Probably, the referred function is
7117<tt>basic_ios&lt;&gt;::exceptions()</tt>.</p>
7118
7119
7120<p><b>Proposed resolution:</b></p>
7121<p>In 27.7.1.1 [istream], 27.7.1.3 [istream.unformatted], paragraph 1,
712227.7.2.1 [ostream], paragraph 3, and 27.7.2.6.1 [ostream.formatted.reqmts],
7123paragraph 1, change "<tt>exception()" to
7124"exceptions()"</tt>.</p>
7125
7126<p><i>[Note to Editor: "exceptions" with an "s"
7127is the correct spelling.]</i></p>
7128
7129
7130
7131
7132
7133
7134<hr>
7135<h3><a name="161"></a>161. Typo: <tt>istream_iterator</tt> vs. <tt>istreambuf_iterator</tt></h3>
7136<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>
7137 <b>Submitter:</b> Dietmar K�hl <b>Opened:</b> 1999-07-20  <b>Last modified:</b> 2008-09-26</p>
7138<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>
7139<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>
7140<p><b>Discussion:</b></p>
7141<p>The note in the second paragraph pretends that the first argument
7142is an object of type <tt>istream_iterator</tt>. This is wrong: It is
7143an object of type <tt>istreambuf_iterator</tt>.</p>
7144
7145
7146<p><b>Proposed resolution:</b></p>
7147<p>Change 27.7.1.2.2 [istream.formatted.arithmetic] from:</p>
7148<blockquote>
7149  <p>The first argument provides an object of the istream_iterator class...</p>
7150</blockquote>
7151<p>to</p>
7152<blockquote>
7153  <p>The first argument provides an object of the istreambuf_iterator class...</p>
7154</blockquote>
7155
7156
7157
7158
7159
7160<hr>
7161<h3><a name="164"></a>164. do_put() has apparently unused fill argument</h3>
7162<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>
7163 <b>Submitter:</b> Angelika Langer <b>Opened:</b> 1999-07-23  <b>Last modified:</b> 2008-09-26</p>
7164<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>
7165<p><b>Discussion:</b></p>
7166<p>In 22.4.5.3.2 [locale.time.put.virtuals] the do_put() function is specified
7167as taking a fill character as an argument, but the description of the
7168function does not say whether the character is used at all and, if so,
7169in which way. The same holds for any format control parameters that
7170are accessible through the ios_base&amp; argument, such as the
7171adjustment or the field width. Is strftime() supposed to use the fill
7172character in any way? In any case, the specification of
7173time_put.do_put() looks inconsistent to me.<br> <br> Is the
7174signature of do_put() wrong, or is the effects clause incomplete?</p>
7175
7176
7177<p><b>Proposed resolution:</b></p>
7178<p>Add the following note after 22.4.5.3.2 [locale.time.put.virtuals]
7179paragraph 2:</p>
7180<blockquote>
7181  <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
7182  for this argument. --end Note]</p>
7183</blockquote>
7184
7185
7186<p><b>Rationale:</b></p>
7187<p>The LWG felt that while the normative text was correct,
7188users need some guidance on what to pass for the <tt>fill</tt>
7189argument since the standard doesn't say how it's used.</p>
7190
7191
7192
7193
7194<hr>
7195<h3><a name="165"></a>165. <tt>xsputn()</tt>, <tt>pubsync()</tt> never called by <tt>basic_ostream</tt> members?</h3>
7196<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>
7197 <b>Submitter:</b> Dietmar K�hl <b>Opened:</b> 1999-07-20  <b>Last modified:</b> 2008-09-26</p>
7198<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>
7199<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
7200<p><b>Discussion:</b></p>
7201<p>Paragraph 2 explicitly states that none of the <tt>basic_ostream</tt>
7202functions falling into one of the groups "formatted output functions"
7203and "unformatted output functions" calls any stream buffer function
7204which might call a virtual function other than <tt>overflow()</tt>. Basically
7205this is fine but this implies that <tt>sputn()</tt> (this function would call
7206the virtual function <tt>xsputn()</tt>) is never called by any of the standard
7207output functions. Is this really intended? At minimum it would be convenient to
7208call <tt>xsputn()</tt> for strings... Also, the statement that <tt>overflow()</tt>
7209is the only virtual member of <tt>basic_streambuf</tt> called is in conflict
7210with the definition of <tt>flush()</tt> which calls <tt>rdbuf()-&gt;pubsync()</tt>
7211and thereby the virtual function <tt>sync()</tt> (<tt>flush()</tt> is listed
7212under "unformatted output functions").</p>
7213<p>In addition, I guess that the sentence starting with "They may use other
7214public members of <tt>basic_ostream</tt> ..." probably was intended to
7215start with "They may use other public members of <tt>basic_streamuf</tt>..."
7216although the problem with the virtual members exists in both cases.</p>
7217<p>I see two obvious resolutions:</p>
7218<ol>
7219  <li>state in a footnote that this means that <tt>xsputn()</tt> will never be
7220    called by any ostream member and that this is intended.</li>
7221  <li>relax the restriction and allow calling <tt>overflow()</tt> and <tt>xsputn()</tt>.
7222    Of course, the problem with <tt>flush()</tt> has to be resolved in some way.</li>
7223</ol>
7224
7225
7226<p><b>Proposed resolution:</b></p>
7227<p>Change the last sentence of 27.6.2.1 (lib.ostream) paragraph 2 from:</p>
7228<blockquote>
7229  <p>They may use other public members of basic_ostream except that they do not
7230  invoke any virtual members of rdbuf() except overflow().</p>
7231</blockquote>
7232<p>to:</p>
7233<blockquote>
7234  <p>They may use other public members of basic_ostream except that they shall
7235  not invoke any virtual members of rdbuf() except overflow(), xsputn(), and
7236  sync().</p>
7237</blockquote>
7238
7239<p><i>[Kona: the LWG believes this is a problem. Wish to ask Jerry or
7240PJP why the standard is written this way.]</i></p>
7241
7242
7243<p><i>[Post-Tokyo: Dietmar supplied wording at the request of the
7244LWG. He comments: The rules can be made a little bit more specific if
7245necessary be explicitly spelling out what virtuals are allowed to be
7246called from what functions and eg to state specifically that flush()
7247is allowed to call sync() while other functions are not.]</i></p>
7248
7249
7250
7251
7252
7253
7254<hr>
7255<h3><a name="167"></a>167. Improper use of <tt>traits_type::length()</tt></h3>
7256<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>
7257 <b>Submitter:</b> Dietmar K�hl <b>Opened:</b> 1999-07-20  <b>Last modified:</b> 2008-09-26</p>
7258<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>
7259<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
7260<p><b>Discussion:</b></p>
7261<p>Paragraph 4 states that the length is determined using
7262<tt>traits::length(s)</tt>.  Unfortunately, this function is not
7263defined for example if the character type is <tt>wchar_t</tt> and the
7264type of <tt>s</tt> is <tt>char const*</tt>. Similar problems exist if
7265the character type is <tt>char</tt> and the type of <tt>s</tt> is
7266either <tt>signed char const*</tt> or <tt>unsigned char
7267const*</tt>.</p>
7268
7269
7270<p><b>Proposed resolution:</b></p>
7271<p>Change 27.7.2.6.4 [ostream.inserters.character] paragraph 4 from:</p>
7272<blockquote>
7273  <p>Effects: Behaves like an formatted inserter (as described in
7274  lib.ostream.formatted.reqmts) of out. After a sentry object is
7275  constructed it inserts characters. The number of characters starting
7276  at s to be inserted is traits::length(s). Padding is determined as
7277  described in lib.facet.num.put.virtuals. The traits::length(s)
7278  characters starting at s are widened using out.widen
7279  (lib.basic.ios.members). The widened characters and any required
7280  padding are inserted into out. Calls width(0).</p>
7281</blockquote>
7282<p>to:</p>
7283<blockquote>
7284  <p>Effects: Behaves like a formatted inserter (as described in
7285  lib.ostream.formatted.reqmts) of out. After a sentry object is
7286  constructed it inserts <i>n</i> characters starting at <i>s</i>,
7287  where <i>n</i> is the number that would be computed as if by:</p>
7288  <ul>
7289  <li>traits::length(s) for the overload where the first argument is of
7290    type basic_ostream&lt;charT, traits&gt;&amp; and the second is
7291    of type const charT*, and also for the overload where the first
7292    argument is of type basic_ostream&lt;char, traits&gt;&amp; and
7293    the second is of type const char*.</li>
7294  <li>std::char_traits&lt;char&gt;::length(s) 
7295    for the overload where the first argument is of type 
7296    basic_ostream&lt;charT, traits&gt;&amp; and the second is of type
7297    const char*.</li>
7298  <li>traits::length(reinterpret_cast&lt;const char*&gt;(s)) 
7299    for the other two overloads.</li>
7300  </ul>
7301  <p>Padding is determined as described in
7302  lib.facet.num.put.virtuals. The <i>n</i> characters starting at
7303  <i>s</i> are widened using out.widen (lib.basic.ios.members).  The
7304  widened characters and any required padding are inserted into
7305  out. Calls width(0).</p>
7306</blockquote>
7307
7308<p><i>[Santa Cruz: Matt supplied new wording]</i></p>
7309
7310
7311<p><i>[Kona: changed "where <i>n</i> is" to " where <i>n</i> is the
7312  number that would be computed as if by"]</i></p>
7313 
7314
7315
7316
7317<p><b>Rationale:</b></p>
7318<p>We have five separate cases.  In two of them we can use the
7319user-supplied traits class without any fuss.  In the other three we
7320try to use something as close to that user-supplied class as possible.
7321In two cases we've got a traits class that's appropriate for
7322char and what we've got is a const signed char* or a const
7323unsigned char*; that's close enough so we can just use a reinterpret
7324cast, and continue to use the user-supplied traits class.  Finally,
7325there's one case where we just have to give up: where we've got a
7326traits class for some arbitrary charT type, and we somehow have to
7327deal with a const char*.  There's nothing better to do but fall back
7328to char_traits&lt;char&gt;</p>
7329
7330
7331
7332
7333
7334<hr>
7335<h3><a name="168"></a>168. Typo: formatted vs. unformatted</h3>
7336<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>
7337 <b>Submitter:</b> Dietmar K�hl <b>Opened:</b> 1999-07-20  <b>Last modified:</b> 2008-09-26</p>
7338<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>
7339<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>
7340<p><b>Discussion:</b></p>
7341<p>The first paragraph begins with a descriptions what has to be done
7342in <i>formatted</i> output functions. Probably this is a typo and the
7343paragraph really want to describe unformatted output functions...</p>
7344
7345
7346<p><b>Proposed resolution:</b></p>
7347<p>In 27.7.2.7 [ostream.unformatted] paragraph 1, the first and last
7348sentences, change the word "formatted" to
7349"unformatted":</p>
7350<blockquote>
7351  <p>"Each <b>unformatted </b> output function begins ..."<br>
7352  "... value specified for the <b>unformatted </b>  output 
7353  function."</p>
7354</blockquote>
7355
7356
7357
7358
7359<hr>
7360<h3><a name="169"></a>169. Bad efficiency of <tt>overflow()</tt> mandated</h3>
7361<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>
7362 <b>Submitter:</b> Dietmar K�hl <b>Opened:</b> 1999-07-20  <b>Last modified:</b> 2008-09-26</p>
7363<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>
7364<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>
7365<p><b>Discussion:</b></p>
7366<p>Paragraph 8, Notes, of this section seems to mandate an extremely
7367inefficient way of buffer handling for <tt>basic_stringbuf</tt>,
7368especially in view of the restriction that <tt>basic_ostream</tt>
7369member functions are not allowed to use <tt>xsputn()</tt> (see 27.7.2.1 [ostream]): For each character to be inserted, a new buffer
7370is to be created.</p> 
7371<p>Of course, the resolution below requires some handling of
7372simultaneous input and output since it is no longer possible to update
7373<tt>egptr()</tt> whenever <tt>epptr()</tt> is changed. A possible
7374solution is to handle this in <tt>underflow()</tt>.</p>
7375
7376
7377<p><b>Proposed resolution:</b></p>
7378<p>In 27.8.1.4 [stringbuf.virtuals] paragraph 8, Notes, insert the words
7379"at least" as in the following:</p>
7380<blockquote>
7381  <p>To make a write position available, the function reallocates (or initially
7382  allocates) an array object with a sufficient number of elements to hold the
7383  current array object (if any), plus <b>at least</b> one additional write
7384  position.</p>
7385</blockquote>
7386
7387
7388
7389
7390<hr>
7391<h3><a name="170"></a>170. Inconsistent definition of <tt>traits_type</tt></h3>
7392<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>
7393 <b>Submitter:</b> Dietmar K�hl <b>Opened:</b> 1999-07-20  <b>Last modified:</b> 2008-09-26</p>
7394<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>
7395<p><b>Discussion:</b></p>
7396<p>The classes <tt>basic_stringstream</tt> (27.8.4 [stringstream]),
7397<tt>basic_istringstream</tt> (27.8.2 [istringstream]), and
7398<tt>basic_ostringstream</tt> (27.8.3 [ostringstream]) are inconsistent
7399in their definition of the type <tt>traits_type</tt>: For
7400<tt>istringstream</tt>, this type is defined, for the other two it is
7401not. This should be consistent.</p>
7402
7403
7404<p><b>Proposed resolution:</b></p>
7405<p><b>Proposed resolution:</b></p> <p>To the declarations of
7406<tt>basic_ostringstream</tt> (27.8.3 [ostringstream]) and
7407<tt>basic_stringstream</tt> (27.8.4 [stringstream]) add:</p>
7408<blockquote>
7409<pre>typedef traits traits_type;</pre>
7410</blockquote>
7411
7412
7413
7414
7415<hr>
7416<h3><a name="171"></a>171. Strange <tt>seekpos()</tt> semantics due to joint position</h3>
7417<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>
7418 <b>Submitter:</b> Dietmar K�hl <b>Opened:</b> 1999-07-20  <b>Last modified:</b> 2008-09-26</p>
7419<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>
7420<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
7421<p><b>Discussion:</b></p>
7422<p>Overridden virtual functions, seekpos()</p> <p>In 27.9.1.1 [filebuf] paragraph 3, it is stated that a joint input and
7423output position is maintained by <tt>basic_filebuf</tt>. Still, the
7424description of <tt>seekpos()</tt> seems to talk about different file
7425positions. In particular, it is unclear (at least to me) what is
7426supposed to happen to the output buffer (if there is one) if only the
7427input position is changed. The standard seems to mandate that the
7428output buffer is kept and processed as if there was no positioning of
7429the output position (by changing the input position). Of course, this
7430can be exactly what you want if the flag <tt>ios_base::ate</tt> is
7431set. However, I think, the standard should say something like
7432this:</p>
7433<ul>
7434  <li>If <tt>(which &amp; mode) == 0</tt> neither read nor write position is
7435    changed and the call fails. Otherwise, the joint read and write position is
7436    altered to correspond to <tt>sp</tt>.</li>
7437  <li>If there is an output buffer, the output sequences is updated and any
7438    unshift sequence is written before the position is altered.</li>
7439  <li>If there is an input buffer, the input sequence is updated after the
7440    position is altered.</li>
7441</ul>
7442<p>Plus the appropriate error handling, that is...</p>
7443
7444
7445<p><b>Proposed resolution:</b></p>
7446<p>Change the unnumbered paragraph in 27.8.1.4 (lib.filebuf.virtuals) before
7447paragraph 14 from:</p>
7448<blockquote>
7449  <p>pos_type seekpos(pos_type sp, ios_base::openmode = ios_base::in |
7450  ios_base::out);</p>
7451  <p>Alters the file position, if possible, to correspond to the position stored
7452  in sp (as described below).</p>
7453  <p>- if (which&amp;ios_base::in)!=0, set the file position to sp, then update
7454  the input sequence</p>
7455  <p>- if (which&amp;ios_base::out)!=0, then update the output sequence, write
7456  any unshift sequence, and set the file position to sp.</p>
7457</blockquote>
7458<p>to:</p>
7459<blockquote>
7460  <p>pos_type seekpos(pos_type sp, ios_base::openmode = ios_base::in |
7461  ios_base::out);</p>
7462  <p>Alters the file position, if possible, to correspond to the position stored
7463  in sp (as described below). Altering the file position performs as follows:</p>
7464  <p>1. if (om &amp; ios_base::out)!=0, then update the output sequence and
7465  write any unshift sequence;</p>
7466  <p>2. set the file position to sp;</p>
7467  <p>3. if (om &amp; ios_base::in)!=0, then update the input sequence;</p>
7468  <p>where om is the open mode passed to the last call to open(). The operation
7469  fails if is_open() returns false.</p>
7470</blockquote>
7471
7472<p><i>[Kona: Dietmar is working on a proposed resolution.]</i></p>
7473
7474<p><i>[Post-Tokyo: Dietmar supplied the above wording.]</i></p>
7475
7476
7477
7478
7479
7480
7481<hr>
7482<h3><a name="172"></a>172. Inconsistent types for <tt>basic_istream::ignore()</tt></h3>
7483<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>
7484 <b>Submitter:</b> Greg Comeau, Dietmar K�hl <b>Opened:</b> 1999-07-23  <b>Last modified:</b> 2008-09-26</p>
7485<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>
7486<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>
7487<p><b>Discussion:</b></p>
7488<p>In 27.7.1.1 [istream] the function
7489<tt>ignore()</tt> gets an object of type <tt>streamsize</tt> as first
7490argument. However, in 27.7.1.3 [istream.unformatted]
7491paragraph 23 the first argument is of type <tt>int.</tt></p>
7492
7493<p>As far as I can see this is not really a contradiction because
7494everything is consistent if <tt>streamsize</tt> is typedef to be
7495<tt>int</tt>. However, this is almost certainly not what was
7496intended. The same thing happened to <tt>basic_filebuf::setbuf()</tt>,
7497as described in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#173">173</a>.</p>
7498
7499<p>Darin Adler also
7500submitted this issue, commenting: Either 27.6.1.1 should be modified
7501to show a first parameter of type int, or 27.6.1.3 should be modified
7502to show a first parameter of type streamsize and use
7503numeric_limits&lt;streamsize&gt;::max.</p>
7504
7505
7506<p><b>Proposed resolution:</b></p>
7507<p>In 27.7.1.3 [istream.unformatted] paragraph 23 and 24, change both uses
7508of <tt>int</tt> in the description of <tt>ignore()</tt> to
7509<tt>streamsize</tt>.</p>
7510
7511
7512
7513
7514<hr>
7515<h3><a name="173"></a>173. Inconsistent types for <tt>basic_filebuf::setbuf()</tt></h3>
7516<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>
7517 <b>Submitter:</b> Greg Comeau, Dietmar K�hl <b>Opened:</b> 1999-07-23  <b>Last modified:</b> 2008-09-26</p>
7518<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>
7519<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>
7520<p><b>Discussion:</b></p>
7521
7522<p>
7523In 27.9.1.1 [filebuf] the function <tt>setbuf()</tt> gets an
7524object of type <tt>streamsize</tt> as second argument. However, in
752527.9.1.5 [filebuf.virtuals] paragraph 9 the second argument is of type
7526<tt>int</tt>.
7527</p>
7528
7529<p>
7530As far as I can see this is not really a contradiction because
7531everything is consistent if <tt>streamsize</tt> is typedef to be
7532<tt>int</tt>. However, this is almost certainly not what was
7533intended. The same thing happened to <tt>basic_istream::ignore()</tt>,
7534as described in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#172">172</a>.
7535</p>
7536
7537
7538
7539<p><b>Proposed resolution:</b></p>
7540<p>In 27.9.1.5 [filebuf.virtuals] paragraph 9, change all uses of
7541<tt>int</tt> in the description of <tt>setbuf()</tt> to
7542<tt>streamsize</tt>.</p>
7543
7544
7545
7546
7547<hr>
7548<h3><a name="174"></a>174. Typo: <tt>OFF_T</tt> vs. <tt>POS_T</tt></h3>
7549<p><b>Section:</b> D.7 [depr.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
7550 <b>Submitter:</b> Dietmar K�hl <b>Opened:</b> 1999-07-23  <b>Last modified:</b> 2008-09-26</p>
7551<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>
7552<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>
7553<p><b>Discussion:</b></p>
7554<p>According to paragraph 1 of this section, <tt>streampos</tt> is the
7555type <tt>OFF_T</tt>, the same type as <tt>streamoff</tt>. However, in
7556paragraph 6 the <tt>streampos</tt> gets the type <tt>POS_T</tt></p>
7557
7558
7559<p><b>Proposed resolution:</b></p>
7560<p>Change D.7 [depr.ios.members] paragraph 1 from "<tt>typedef
7561OFF_T streampos;</tt>" to "<tt>typedef POS_T
7562streampos;</tt>"</p>
7563
7564
7565
7566
7567<hr>
7568<h3><a name="175"></a>175. Ambiguity for <tt>basic_streambuf::pubseekpos()</tt> and a few other functions.</h3>
7569<p><b>Section:</b> D.7 [depr.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
7570 <b>Submitter:</b> Dietmar K�hl <b>Opened:</b> 1999-07-23  <b>Last modified:</b> 2008-09-26</p>
7571<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>
7572<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>
7573<p><b>Discussion:</b></p>
7574<p>According to paragraph 8 of this section, the methods
7575<tt>basic_streambuf::pubseekpos()</tt>,
7576<tt>basic_ifstream::open()</tt>, and <tt>basic_ofstream::open</tt>
7577"may" be overloaded by a version of this function taking the
7578type <tt>ios_base::open_mode</tt> as last argument argument instead of
7579<tt>ios_base::openmode</tt> (<tt>ios_base::open_mode</tt> is defined
7580in this section to be an alias for one of the integral types). The
7581clause specifies, that the last argument has a default argument in
7582three cases.  However, this generates an ambiguity with the overloaded
7583version because now the arguments are absolutely identical if the last
7584argument is not specified.</p>
7585
7586
7587<p><b>Proposed resolution:</b></p>
7588<p>In D.7 [depr.ios.members] paragraph 8, remove the default arguments for
7589<tt>basic_streambuf::pubseekpos()</tt>,
7590<tt>basic_ifstream::open()</tt>, and
7591<tt>basic_ofstream::open().</tt></p>
7592
7593
7594
7595
7596<hr>
7597<h3><a name="176"></a>176. <tt>exceptions()</tt> in <tt>ios_base</tt>...?</h3>
7598<p><b>Section:</b> D.7 [depr.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
7599 <b>Submitter:</b> Dietmar K�hl <b>Opened:</b> 1999-07-23  <b>Last modified:</b> 2008-09-26</p>
7600<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>
7601<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>
7602<p><b>Discussion:</b></p>
7603<p>The "overload" for the function <tt>exceptions()</tt> in
7604paragraph 8 gives the impression that there is another function of
7605this function defined in class <tt>ios_base</tt>. However, this is not
7606the case. Thus, it is hard to tell how the semantics (paragraph 9) can
7607be implemented: "Call the corresponding member function specified
7608in clause 27 [input.output]."</p>
7609
7610
7611<p><b>Proposed resolution:</b></p>
7612<p>In D.7 [depr.ios.members] paragraph 8, move the declaration of the
7613function <tt>exceptions()</tt>into class <tt>basic_ios</tt>.</p>
7614
7615
7616
7617
7618<hr>
7619<h3><a name="179"></a>179. Comparison of const_iterators to iterators doesn't work</h3>
7620<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>
7621 <b>Submitter:</b> Judy Ward <b>Opened:</b> 1998-07-02  <b>Last modified:</b> 2008-09-26</p>
7622<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>
7623<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>
7624<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
7625<p><b>Discussion:</b></p>
7626<p>Currently the following will not compile on two well-known standard
7627library implementations:</p>
7628
7629<blockquote>
7630  <pre>#include &lt;set&gt;
7631using namespace std;
7632
7633void f(const set&lt;int&gt; &amp;s)
7634{
7635  set&lt;int&gt;::iterator i;
7636  if (i==s.end()); // s.end() returns a const_iterator
7637}</pre>
7638</blockquote>
7639
7640<p>
7641The reason this doesn't compile is because operator== was implemented
7642as a member function of the nested classes set:iterator and
7643set::const_iterator, and there is no conversion from const_iterator to
7644iterator. Surprisingly, (s.end() == i) does work, though, because of
7645the conversion from iterator to const_iterator.
7646</p>
7647
7648<p>
7649I don't see a requirement anywhere in the standard that this must
7650work. Should there be one?  If so, I think the requirement would need
7651to be added to the tables in section 24.1.1. I'm not sure about the
7652wording.  If this requirement existed in the standard, I would think
7653that implementors would have to make the comparison operators
7654non-member functions.</p>
7655
7656<p>This issues was also raised on comp.std.c++ by Darin
7657Adler.&nbsp; The example given was:</p>
7658
7659<blockquote>
7660  <pre>bool check_equal(std::deque&lt;int&gt;::iterator i,
7661std::deque&lt;int&gt;::const_iterator ci)
7662{
7663return i == ci;
7664}</pre>
7665</blockquote>
7666
7667<p>Comment from John Potter:</p>
7668<blockquote>
7669    <p>
7670    In case nobody has noticed, accepting it will break reverse_iterator.
7671    </p>
7672
7673    <p>
7674    The fix is to make the comparison operators templated on two types.
7675    </p>
7676
7677    <pre>    template &lt;class Iterator1, class Iterator2&gt;
7678    bool operator== (reverse_iterator&lt;Iterator1&gt; const&amp; x,
7679                     reverse_iterator&lt;Iterator2&gt; const&amp; y);
7680    </pre>
7681
7682    <p>
7683    Obviously:  return x.base() == y.base();
7684    </p>
7685
7686    <p>
7687    Currently, no reverse_iterator to const_reverse_iterator compares are
7688    valid.
7689    </p>
7690
7691    <p>
7692    BTW, I think the issue is in support of bad code.  Compares should be
7693    between two iterators of the same type.  All std::algorithms require
7694    the begin and end iterators to be of the same type. 
7695    </p>
7696</blockquote>
7697
7698
7699<p><b>Proposed resolution:</b></p>
7700<p>Insert this paragraph after 23.2 [container.requirements] paragraph 7:</p>
7701<blockquote>
7702  <p>In the expressions</p>
7703  <pre>    i == j
7704    i != j
7705    i &lt; j
7706    i &lt;= j
7707    i &gt;= j
7708    i &gt; j
7709    i - j
7710  </pre>
7711  <p>Where i and j denote objects of a container's iterator type,
7712  either or both may be replaced by an object of the container's
7713  const_iterator type referring to the same element with no
7714  change in semantics.</p>
7715</blockquote>
7716
7717<p><i>[post-Toronto: Judy supplied a proposed resolution saying that
7718<tt>iterator</tt> and <tt>const_iterator</tt> could be freely mixed in
7719iterator comparison and difference operations.]</i></p>
7720
7721
7722<p><i>[Redmond: Dave and Howard supplied a new proposed resolution which
7723explicitly listed expressions; there was concern that the previous
7724proposed resolution was too informal.]</i></p>
7725
7726
7727
7728<p><b>Rationale:</b></p>
7729<p>
7730The LWG believes it is clear that the above wording applies only to
7731the nested types <tt>X::iterator</tt> and <tt>X::const_iterator</tt>,
7732where <tt>X</tt> is a container.  There is no requirement that
7733<tt>X::reverse_iterator</tt> and <tt>X::const_reverse_iterator</tt>
7734can be mixed.  If mixing them is considered important, that's a
7735separate issue.  (Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#280">280</a>.)
7736</p>
7737
7738
7739
7740
7741<hr>
7742<h3><a name="180"></a>180. Container member iterator arguments constness has unintended consequences</h3>
7743<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>
7744 <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 1999-07-01  <b>Last modified:</b> 2008-09-26</p>
7745<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>
7746<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
7747<p><b>Discussion:</b></p>
7748<p>It is the constness of the container which should control whether
7749it can be modified through a member function such as erase(), not the
7750constness of the iterators. The iterators only serve to give
7751positioning information.</p>
7752
7753<p>Here's a simple and typical example problem which is currently very
7754difficult or impossible to solve without the change proposed
7755below.</p>
7756
7757<p>Wrap a standard container C in a class W which allows clients to
7758find and read (but not modify) a subrange of (C.begin(), C.end()]. The
7759only modification clients are allowed to make to elements in this
7760subrange is to erase them from C through the use of a member function
7761of W.</p>
7762
7763<p><i>[
7764post Bellevue, Alisdair adds:
7765]</i></p>
7766
7767
7768<blockquote>
7769<p>
7770This issue was implemented by
7771<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2350.pdf">N2350</a>
7772for everything but <tt>basic_string</tt>.
7773</p>
7774
7775<p>
7776Note that the specific example in this issue (<tt>basic_string</tt>) is the one place
7777we forgot to amend in
7778<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2350.pdf">N2350</a>,
7779so we might open this issue for that
7780single container?
7781</p>
7782</blockquote>
7783
7784<p><i>[
7785Sophia Antipolis:
7786]</i></p>
7787
7788
7789<blockquote>
7790<p>
7791This was a fix that was intended for all standard library containers,
7792and has been done for other containers, but string was missed.
7793</p>
7794<p>
7795The wording updated.
7796</p>
7797<p>
7798We did not make the change in <tt>replace</tt>, because this change would affect
7799the implementation because the string may be written into. This is an
7800issue that should be taken up by concepts.
7801</p>
7802<p>
7803We note that the supplied wording addresses the initializer list provided in
7804<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2679.pdf">N2679</a>.
7805</p>
7806</blockquote>
7807
7808
7809
7810<p><b>Proposed resolution:</b></p>
7811<p>
7812Update the following signature in the <tt>basic_string</tt> class template definition in
781321.4 [basic.string], p5:
7814</p>
7815<blockquote><pre>namespace std {
7816  template&lt;class charT, class traits = char_traits&lt;charT&gt;,
7817    class Allocator = allocator&lt;charT&gt; &gt;
7818  class basic_string {
7819
7820    ...
7821
7822    iterator insert(<ins>const_</ins>iterator p, charT c);
7823    void insert(<ins>const_</ins>iterator p, size_type n, charT c);
7824    template&lt;class InputIterator&gt;
7825      void insert(<ins>const_</ins>iterator p, InputIterator first, InputIterator last);
7826    void insert(<ins>const_</ins>iterator <ins>p</ins>, initializer_list&lt;charT&gt;);
7827
7828    ...
7829
7830    iterator erase(<ins>const_</ins>iterator <ins>const_</ins>position);
7831    iterator erase(<ins>const_</ins>iterator first, <ins>const_</ins>iterator last);
7832
7833    ...
7834
7835  };
7836}
7837</pre></blockquote>
7838
7839<p>
7840Update the following signatures in 21.4.6.4 [string::insert]:
7841</p>
7842
7843<blockquote><pre>iterator insert(<ins>const_</ins>iterator p, charT c);
7844void insert(<ins>const_</ins>iterator p, size_type n, charT c);
7845template&lt;class InputIterator&gt;
7846  void insert(<ins>const_</ins>iterator p, InputIterator first, InputIterator last);
7847void insert(<ins>const_</ins>iterator <ins>p</ins>, initializer_list&lt;charT&gt;);
7848</pre></blockquote>
7849
7850<p>
7851Update the following signatures in 21.4.6.5 [string::erase]:
7852</p>
7853
7854<blockquote><pre>iterator erase(<ins>const_</ins>iterator <ins>const_</ins>position);
7855iterator erase(<ins>const_</ins>iterator first, <ins>const_</ins>iterator last);
7856</pre></blockquote>
7857
7858
7859
7860<p><b>Rationale:</b></p>
7861<p>The issue was discussed at length. It was generally agreed that 1)
7862There is no major technical argument against the change (although
7863there is a minor argument that some obscure programs may break), and
78642) Such a change would not break const correctness. The concerns about
7865making the change were 1) it is user detectable (although only in
7866boundary cases), 2) it changes a large number of signatures, and 3) it
7867seems more of a design issue that an out-and-out defect.</p>
7868
7869<p>The LWG believes that this issue should be considered as part of a
7870general review of const issues for the next revision of the
7871standard. Also see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#200">200</a>.</p>
7872
7873
7874
7875
7876<hr>
7877<h3><a name="181"></a>181. make_pair() unintended behavior</h3>
7878<p><b>Section:</b> 20.3.4 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
7879 <b>Submitter:</b> Andrew Koenig <b>Opened:</b> 1999-08-03  <b>Last modified:</b> 2008-09-26</p>
7880<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>
7881<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>
7882<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>
7883<p><b>Discussion:</b></p>
7884<p>The claim has surfaced in Usenet that expressions such as<br>
7885<br>
7886&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <tt>make_pair("abc", 3)</tt><br>
7887<br>
7888are illegal, notwithstanding their use in examples, because template instantiation tries to bind the first template
7889parameter to <tt> const char (&amp;)[4]</tt>, which type is uncopyable.<br>
7890<br>
7891I doubt anyone intended that behavior...
7892</p>
7893
7894
7895<p><b>Proposed resolution:</b></p>
7896<p>In 20.3 [utility], paragraph 1 change the following
7897declaration of make_pair():</p>
7898<blockquote>
7899  <pre>template &lt;class T1, class T2&gt; pair&lt;T1,T2&gt; make_pair(const T1&amp;, const T2&amp;);</pre>
7900</blockquote>
7901<p>to:</p>
7902<blockquote>
7903  <pre>template &lt;class T1, class T2&gt; pair&lt;T1,T2&gt; make_pair(T1, T2);</pre>
7904</blockquote>
7905<p>  In 20.3.4 [pairs] paragraph 7 and the line before, change:</p>
7906<blockquote>
7907<pre>template &lt;class T1, class T2&gt;
7908pair&lt;T1, T2&gt; make_pair(const T1&amp; x, const T2&amp; y);</pre>
7909</blockquote>
7910<p>to:</p>
7911<blockquote>
7912<pre>template &lt;class T1, class T2&gt;
7913pair&lt;T1, T2&gt; make_pair(T1 x, T2 y);</pre>
7914</blockquote>
7915<p>and add the following footnote to the effects clause:</p>
7916<blockquote>
7917  <p> According to 12.8 [class.copy], an implementation is permitted
7918  to not perform a copy of an argument, thus avoiding unnecessary
7919  copies.</p>
7920</blockquote>
7921
7922
7923<p><b>Rationale:</b></p>
7924<p>Two potential fixes were suggested by Matt Austern and Dietmar
7925K�hl, respectively, 1) overloading with array arguments, and 2) use of
7926a reference_traits class with a specialization for arrays.  Andy
7927Koenig suggested changing to pass by value. In discussion, it appeared
7928that this was a much smaller change to the standard that the other two
7929suggestions, and any efficiency concerns were more than offset by the
7930advantages of the solution. Two implementors reported that the
7931proposed resolution passed their test suites.</p>
7932
7933
7934
7935
7936<hr>
7937<h3><a name="182"></a>182. Ambiguous references to size_t</h3>
7938<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>
7939 <b>Submitter:</b> Al Stevens <b>Opened:</b> 1999-08-15  <b>Last modified:</b> 2008-09-26</p>
7940<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>
7941<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>
7942<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
7943<p><b>Discussion:</b></p>
7944<p>Many references to <tt> size_t</tt> throughout the document
7945omit the <tt> std::</tt> namespace qualification.</p> <p>For
7946example, 17.6.3.6 [replacement.functions] paragraph 2:</p>
7947<blockquote>
7948<pre> operator new(size_t)
7949 operator new(size_t, const std::nothrow_t&amp;)
7950 operator new[](size_t)
7951 operator new[](size_t, const std::nothrow_t&amp;)</pre>
7952</blockquote>
7953
7954
7955<p><b>Proposed resolution:</b></p>
7956<p>   In 17.6.3.6 [replacement.functions] paragraph 2: replace:</p>
7957<blockquote>
7958<p><tt>     - operator new(size_t)<br>
7959     - operator new(size_t, const std::nothrow_t&amp;)<br>
7960     - operator new[](size_t)<br>
7961     - operator new[](size_t, const std::nothrow_t&amp;)</tt></p>
7962</blockquote>
7963<p>    by:</p>
7964<blockquote>
7965<pre>- operator new(std::size_t)
7966- operator new(std::size_t, const std::nothrow_t&amp;)
7967- operator new[](std::size_t)
7968- operator new[](std::size_t, const std::nothrow_t&amp;)</pre>
7969</blockquote>
7970<p>In [lib.allocator.requirements] 20.1.5, paragraph 4: replace:</p>
7971<blockquote>
7972  <p>The typedef members pointer, const_pointer, size_type, and difference_type
7973  are required to be T*, T const*, size_t, and ptrdiff_t, respectively.</p>
7974</blockquote>
7975<p>&nbsp;by:</p>
7976<blockquote>
7977  <p>The typedef members pointer, const_pointer, size_type, and difference_type
7978  are required to be T*, T const*, std::size_t, and std::ptrdiff_t,
7979  respectively.</p>
7980</blockquote>
7981<p>In [lib.allocator.members] 20.4.1.1, paragraphs 3 and 6: replace:</p>
7982<blockquote>
7983  <p>3 Notes: Uses ::operator new(size_t) (18.4.1).</p>
7984  <p>6 Note: the storage is obtained by calling ::operator new(size_t), but it
7985  is unspecified when or how often this function is called. The use of hint is
7986  unspecified, but intended as an aid to locality if an implementation so
7987  desires.</p>
7988</blockquote>
7989<p>by:</p>
7990<blockquote>
7991  <p>3 Notes: Uses ::operator new(std::size_t) (18.4.1).</p>
7992  <p>6 Note: the storage is obtained by calling ::operator new(std::size_t), but
7993  it is unspecified when or how often this function is called. The use of hint
7994  is unspecified, but intended as an aid to locality if an implementation so
7995  desires.</p>
7996</blockquote>
7997<p>In [lib.char.traits.require] 21.1.1, paragraph 1: replace:</p>
7998<blockquote>
7999  <p>In Table 37, X denotes a Traits class defining types and functions for the
8000  character container type CharT; c and d denote values of type CharT; p and q
8001  denote values of type const CharT*; s denotes a value of type CharT*; n, i and
8002  j denote values of type size_t; e and f denote values of type X::int_type; pos
8003  denotes a value of type X::pos_type; and state denotes a value of type X::state_type.</p>
8004</blockquote>
8005<p>by:</p>
8006<blockquote>
8007  <p>In Table 37, X denotes a Traits class defining types and functions for the
8008  character container type CharT; c and d denote values of type CharT; p and q
8009  denote values of type const CharT*; s denotes a value of type CharT*; n, i and
8010  j denote values of type std::size_t; e and f denote values of type X::int_type;
8011  pos denotes a value of type X::pos_type; and state denotes a value of type X::state_type.</p>
8012</blockquote>
8013<p>In [lib.char.traits.require] 21.1.1, table 37: replace the return type of
8014X::length(p): "size_t" by "std::size_t".</p>
8015<p>   In [lib.std.iterator.tags] 24.3.3, paragraph 2:    replace:<br>
8016&nbsp;&nbsp;&nbsp; typedef ptrdiff_t difference_type;<br>
8017    by:<br>
8018&nbsp;&nbsp;&nbsp; typedef std::ptrdiff_t difference_type;</p>
8019<p> In [lib.locale.ctype] 22.2.1.1 put namespace std { ...} around the
8020declaration of template &lt;class charT&gt; class ctype.<br>
8021<br>
8022   In [lib.iterator.traits] 24.3.1, paragraph 2    put namespace std { ...} around the declaration of:<br>
8023<br>
8024&nbsp;&nbsp;&nbsp; template&lt;class Iterator&gt; struct iterator_traits<br>
8025&nbsp;&nbsp;&nbsp; template&lt;class T&gt; struct iterator_traits&lt;T*&gt;<br>
8026&nbsp;&nbsp;&nbsp; template&lt;class T&gt; struct iterator_traits&lt;const T*&gt;</p>
8027
8028
8029<p><b>Rationale:</b></p>
8030<p>The LWG believes correcting names like <tt>size_t</tt> and
8031<tt>ptrdiff_t</tt> to <tt>std::size_t</tt> and <tt>std::ptrdiff_t</tt>
8032to be essentially editorial.  There there can't be another size_t or
8033ptrdiff_t meant anyway because, according to 17.6.3.3.4 [extern.types],</p>
8034
8035<blockquote><p>
8036For each type T from the Standard C library, the types ::T and std::T
8037are reserved to the implementation and, when defined, ::T shall be
8038identical to std::T.
8039</p></blockquote>
8040
8041<p>The issue is treated as a Defect Report to make explicit the Project
8042Editor's authority to make this change.</p>
8043
8044<p><i>[Post-Tokyo: Nico Josuttis provided the above wording at the
8045request of the LWG.]</i></p>
8046
8047
8048<p><i>[Toronto: This is tangentially related to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a>, but only tangentially: the intent of this issue is to
8049address use of the name <tt>size_t</tt> in contexts outside of
8050namespace std, such as in the description of <tt>::operator new</tt>.
8051The proposed changes should be reviewed to make sure they are
8052correct.]</i></p>
8053
8054
8055<p><i>[pre-Copenhagen: Nico has reviewed the changes and believes
8056them to be correct.]</i></p>
8057
8058
8059
8060
8061
8062
8063
8064<hr>
8065<h3><a name="183"></a>183. I/O stream manipulators don't work for wide character streams</h3>
8066<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>
8067 <b>Submitter:</b> Andy Sawyer <b>Opened:</b> 1999-07-07  <b>Last modified:</b> 2008-09-26</p>
8068<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>
8069<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
8070<p><b>Discussion:</b></p>
8071<p>27.7.3 [std.manip] paragraph 3 says (clause numbering added for
8072exposition):</p>
8073<blockquote>
8074<p>Returns: An object s of unspecified type such that if [1] out is an (instance
8075of) basic_ostream then the expression out&lt;&lt;s behaves as if f(s) were
8076called, and if [2] in is an (instance of) basic_istream then the expression
8077in&gt;&gt;s behaves as if f(s) were called. Where f can be defined as: ios_base&amp;
8078f(ios_base&amp; str, ios_base::fmtflags mask) { // reset specified flags
8079str.setf(ios_base::fmtflags(0), mask); return str; } [3] The expression
8080out&lt;&lt;s has type ostream&amp; and value out. [4] The expression in&gt;&gt;s
8081has type istream&amp; and value in.</p>
8082</blockquote>
8083<p>Given the definitions [1] and [2] for out and in, surely [3] should read:
8084"The expression out &lt;&lt; s has type basic_ostream&amp; ..." and
8085[4] should read: "The expression in &gt;&gt; s has type basic_istream&amp;
8086..."</p>
8087<p>If the wording in the standard is correct, I can see no way of implementing
8088any of the manipulators so that they will work with wide character streams.</p>
8089<p>e.g. wcout &lt;&lt; setbase( 16 );</p>
8090<p>Must have value 'wcout' (which makes sense) and type 'ostream&amp;' (which
8091doesn't).</p>
8092<p>The same "cut'n'paste" type also seems to occur in Paras 4,5,7 and
80938. In addition, Para 6 [setfill] has a similar error, but relates only to
8094ostreams.</p>
8095<p>I'd be happier if there was a better way of saying this, to make it clear
8096that the value of the expression is "the same specialization of
8097basic_ostream as out"&amp;</p>
8098
8099
8100<p><b>Proposed resolution:</b></p>
8101<p>Replace section 27.7.3 [std.manip] except paragraph 1 with the
8102following:</p>
8103<blockquote>
8104<p>2- The type designated smanip in each of the following function
8105descriptions is implementation-specified and may be different for each
8106function.<br>
8107<br>
8108<tt>smanip resetiosflags(ios_base::fmtflags mask);</tt><br>
8109<br>
8110-3- Returns: An object s of unspecified type such that if out is an
8111instance of basic_ostream&lt;charT,traits&gt; then the expression
8112out&lt;&lt;s behaves
8113as if f(s, mask) were called, or if in is an instance of
8114basic_istream&lt;charT,traits&gt; then the expression in&gt;&gt;s
8115behaves as if
8116f(s, mask) were called. The function f can be defined as:*<br>
8117<br>
8118[Footnote: The expression cin &gt;&gt; resetiosflags(ios_base::skipws)
8119clears ios_base::skipws in the format flags stored in the
8120basic_istream&lt;charT,traits&gt; object cin (the same as cin &gt;&gt;
8121noskipws), and the expression cout &lt;&lt;
8122resetiosflags(ios_base::showbase) clears
8123ios_base::showbase in the format flags stored in the
8124basic_ostream&lt;charT,traits&gt; object cout (the same as cout
8125&lt;&lt;
8126noshowbase). --- end footnote]<br>
8127<br>
8128&nbsp;&nbsp;&nbsp;&nbsp; <tt>ios_base&amp; f(ios_base&amp; str, ios_base::fmtflags mask)<br>
8129&nbsp;&nbsp; {<br>
8130&nbsp;&nbsp; //  reset specified flags<br>
8131&nbsp;&nbsp; str.setf(ios_base::fmtflags(0), mask);<br>
8132&nbsp;&nbsp; return str;<br>
8133&nbsp;&nbsp; }<br>
8134</tt><br>
8135The expression out&lt;&lt;s has type basic_ostream&lt;charT,traits&gt;&amp; and value out.
8136The expression in&gt;&gt;s has type basic_istream&lt;charT,traits&gt;&amp; and value in.<br>
8137<br>
8138&nbsp;<tt>smanip setiosflags(ios_base::fmtflags mask);</tt><br>
8139<br>
8140-4- Returns: An object s of unspecified type such that if out is an
8141instance of basic_ostream&lt;charT,traits&gt; then the expression
8142out&lt;&lt;s behaves
8143as if f(s, mask) were called, or if in is an instance of
8144basic_istream&lt;charT,traits&gt; then the expression in&gt;&gt;s
8145behaves as if f(s,
8146mask) were called. The function f can be defined as:<br>
8147<br>
8148&nbsp;&nbsp;&nbsp;&nbsp; <tt>ios_base&amp; f(ios_base&amp; str, ios_base::fmtflags mask)<br>
8149&nbsp;&nbsp; {<br>
8150&nbsp;&nbsp; //  set specified flags<br>
8151&nbsp;&nbsp; str.setf(mask);<br>
8152&nbsp;&nbsp; return str;<br>
8153&nbsp;&nbsp; }<br>
8154</tt><br>
8155The expression out&lt;&lt;s has type basic_ostream&lt;charT,traits&gt;&amp; and value out.
8156The expression in&gt;&gt;s has type basic_istream&lt;charT,traits&gt;&amp; and value in.<br>
8157<br>
8158<tt>smanip setbase(int base);</tt><br>
8159<br>
8160-5- Returns: An object s of unspecified type such that if out is an
8161instance of basic_ostream&lt;charT,traits&gt; then the expression
8162out&lt;&lt;s behaves
8163as if f(s, base) were called, or if in is an instance of
8164basic_istream&lt;charT,traits&gt; then the expression in&gt;&gt;s
8165behaves as if f(s,
8166base) were called. The function f can be defined as:<br>
8167<br>
8168&nbsp;&nbsp;&nbsp;&nbsp; <tt>ios_base&amp; f(ios_base&amp; str, int base)<br>
8169&nbsp;&nbsp; {<br>
8170&nbsp;&nbsp; //  set  basefield<br>
8171&nbsp;&nbsp; str.setf(base ==  8 ? ios_base::oct :<br>
8172&nbsp;&nbsp; base == 10 ? ios_base::dec :<br>
8173&nbsp;&nbsp; base == 16 ? ios_base::hex :<br>
8174&nbsp;&nbsp; ios_base::fmtflags(0), ios_base::basefield);<br>
8175&nbsp;&nbsp; return str;<br>
8176&nbsp;&nbsp; }<br>
8177</tt><br>
8178The expression out&lt;&lt;s has type basic_ostream&lt;charT,traits&gt;&amp; and value out.
8179The expression in&gt;&gt;s has type basic_istream&lt;charT,traits&gt;&amp; and value in.<br>
8180<br>
8181<tt>smanip setfill(char_type c);<br>
8182</tt><br>
8183-6- Returns: An object s of unspecified type such that if out is (or is
8184derived from) basic_ostream&lt;charT,traits&gt; and c has type charT
8185then the
8186expression out&lt;&lt;s behaves as if f(s, c) were called. The function
8187f can be
8188defined as:<br>
8189<br>
8190&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <tt>template&lt;class charT, class traits&gt;<br>
8191&nbsp;&nbsp; basic_ios&lt;charT,traits&gt;&amp; f(basic_ios&lt;charT,traits&gt;&amp; str, charT c)<br>
8192&nbsp;&nbsp; {<br>
8193&nbsp;&nbsp; //  set fill character<br>
8194&nbsp;&nbsp; str.fill(c);<br>
8195&nbsp;&nbsp; return str;<br>
8196&nbsp;&nbsp; }<br>
8197</tt><br>
8198The expression out&lt;&lt;s has type basic_ostream&lt;charT,traits&gt;&amp; and value out.<br>
8199<br>
8200<tt>smanip setprecision(int n);</tt><br>
8201<br>
8202-7- Returns: An object s of unspecified type such that if out is an
8203instance of basic_ostream&lt;charT,traits&gt; then the expression
8204out&lt;&lt;s behaves
8205as if f(s, n) were called, or if in is an instance of
8206basic_istream&lt;charT,traits&gt; then the expression in&gt;&gt;s
8207behaves as if f(s, n)
8208were called. The function f can be defined as:<br>
8209<br>
8210&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <tt>ios_base&amp; f(ios_base&amp; str, int n)<br>
8211&nbsp;&nbsp; {<br>
8212&nbsp;&nbsp; //  set precision<br>
8213&nbsp;&nbsp; str.precision(n);<br>
8214&nbsp;&nbsp; return str;<br>
8215&nbsp;&nbsp; }<br>
8216</tt><br>
8217The expression out&lt;&lt;s has type basic_ostream&lt;charT,traits&gt;&amp; and value out.
8218The expression in&gt;&gt;s has type basic_istream&lt;charT,traits&gt;&amp; and value in<br>
8219.<br>
8220<tt>smanip setw(int n);<br>
8221</tt><br>
8222-8- Returns: An object s of unspecified type such that if out is an
8223instance of basic_ostream&lt;charT,traits&gt; then the expression
8224out&lt;&lt;s behaves
8225as if f(s, n) were called, or if in is an instance of
8226basic_istream&lt;charT,traits&gt; then the expression in&gt;&gt;s
8227behaves as if f(s, n)
8228were called. The function f can be defined as:<br>
8229<br>
8230&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <tt>ios_base&amp; f(ios_base&amp; str, int n)<br>
8231&nbsp;&nbsp; {<br>
8232&nbsp;&nbsp; //  set width<br>
8233&nbsp;&nbsp; str.width(n);<br>
8234&nbsp;&nbsp; return str;<br>
8235&nbsp;&nbsp; }<br>
8236</tt><br>
8237The expression out&lt;&lt;s has type
8238basic_ostream&lt;charT,traits&gt;&amp; and value out.  The expression
8239in&gt;&gt;s has type basic_istream&lt;charT,traits&gt;&amp; and value
8240in.
8241</p>
8242</blockquote>
8243
8244<p><i>[Kona: Andy Sawyer and Beman Dawes will work to improve the wording of
8245the proposed resolution.]</i></p>
8246
8247
8248<p><i>[Tokyo - The LWG noted that issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#216">216</a> involves
8249the same paragraphs.]</i></p>
8250
8251
8252<p><i>[Post-Tokyo: The issues list maintainer combined the proposed
8253resolution of this issue with the proposed resolution for issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#216">216</a> as they both involved the same paragraphs, and were so
8254intertwined that dealing with them separately appear fraught with
8255error.  The full text was supplied by Bill Plauger; it was cross
8256checked against changes supplied by Andy Sawyer. It should be further
8257checked by the LWG.]</i></p>
8258
8259
8260
8261
8262
8263
8264<hr>
8265<h3><a name="184"></a>184. numeric_limits&lt;bool&gt; wording problems</h3>
8266<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>
8267 <b>Submitter:</b> Gabriel Dos Reis <b>Opened:</b> 1999-07-21  <b>Last modified:</b> 2008-09-26</p>
8268<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>
8269<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
8270<p><b>Discussion:</b></p>
8271<p>bools are defined by the standard to be of integer types, as per
82723.9.1 [basic.fundamental] paragraph 7.  However "integer types"
8273seems to have a special meaning for the author of 18.2. The net effect
8274is an unclear and confusing specification for
8275numeric_limits&lt;bool&gt; as evidenced below.</p>
8276
8277<p>18.2.1.2/7 says numeric_limits&lt;&gt;::digits is, for built-in integer
8278types, the number of non-sign bits in the representation.</p>
8279
8280<p>4.5/4 states that a bool promotes to int ; whereas 4.12/1 says any non zero
8281arithmetical value converts to true.</p>
8282
8283<p>I don't think it makes sense at all to require
8284numeric_limits&lt;bool&gt;::digits and numeric_limits&lt;bool&gt;::digits10 to
8285be meaningful.</p>
8286
8287<p>The standard defines what constitutes a signed (resp. unsigned) integer
8288types. It doesn't categorize bool as being signed or unsigned. And the set of
8289values of bool type has only two elements.</p>
8290
8291<p>I don't think it makes sense to require numeric_limits&lt;bool&gt;::is_signed
8292to be meaningful.</p>
8293
8294<p>18.2.1.2/18 for numeric_limits&lt;integer_type&gt;::radix&nbsp; says:</p>
8295<blockquote>
8296  <p>For integer types, specifies the base of the representation.186)</p>
8297</blockquote>
8298
8299<p>This disposition is at best misleading and confusing for the standard
8300requires a "pure binary numeration system" for integer types as per
83013.9.1/7</p>
8302
8303<p>The footnote 186) says: "Distinguishes types with base other than 2 (e.g
8304BCD)."&nbsp; This also erroneous as the standard never defines any integer
8305types with base representation other than 2.</p>
8306
8307<p>Furthermore, numeric_limits&lt;bool&gt;::is_modulo and
8308numeric_limits&lt;bool&gt;::is_signed have similar problems.</p>
8309
8310
8311<p><b>Proposed resolution:</b></p>
8312<p>Append to the end of 18.3.1.5 [numeric.special]:</p>
8313<blockquote>
8314  <p>The specialization for bool shall be provided as follows:</p>
8315  <pre>    namespace std {
8316       template&lt;&gt; class numeric_limits&lt;bool&gt; {
8317       public:
8318         static const bool is_specialized = true;
8319         static bool min() throw() { return false; }
8320         static bool max() throw() { return true; }
8321
8322         static const int  digits = 1;
8323         static const int  digits10 = 0;
8324         static const bool is_signed = false;
8325         static const bool is_integer = true;
8326         static const bool is_exact = true;
8327         static const int  radix = 2;
8328         static bool epsilon() throw() { return 0; }
8329         static bool round_error() throw() { return 0; }
8330
8331         static const int  min_exponent = 0;
8332         static const int  min_exponent10 = 0;
8333         static const int  max_exponent = 0;
8334         static const int  max_exponent10 = 0;
8335
8336         static const bool has_infinity = false;
8337         static const bool has_quiet_NaN = false;
8338         static const bool has_signaling_NaN = false;
8339         static const float_denorm_style has_denorm = denorm_absent;
8340         static const bool has_denorm_loss = false;
8341         static bool infinity() throw() { return 0; }
8342         static bool quiet_NaN() throw() { return 0; }
8343         static bool signaling_NaN() throw() { return 0; }
8344         static bool denorm_min() throw() { return 0; }
8345
8346         static const bool is_iec559 = false;
8347         static const bool is_bounded = true;
8348         static const bool is_modulo = false;
8349
8350         static const bool traps = false;
8351         static const bool tinyness_before = false;
8352         static const float_round_style round_style = round_toward_zero;
8353       };
8354     }</pre>
8355</blockquote>
8356
8357<p><i>[Tokyo:&nbsp; The LWG desires wording that specifies exact values
8358rather than more general wording in the original proposed
8359resolution.]</i></p>
8360
8361
8362<p><i>[Post-Tokyo:&nbsp; At the request of the LWG in Tokyo, Nico
8363Josuttis provided the above wording.]</i></p>
8364
8365
8366
8367
8368
8369
8370<hr>
8371<h3><a name="185"></a>185. Questionable use of term "inline"</h3>
8372<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>
8373 <b>Submitter:</b> UK Panel <b>Opened:</b> 1999-07-26  <b>Last modified:</b> 2008-09-26</p>
8374<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>
8375<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
8376<p><b>Discussion:</b></p>
8377<p>Paragraph 4 of 20.7 [function.objects] says:</p>
8378<blockquote>
8379  <p>&nbsp;[Example: To negate every element of a: transform(a.begin(), a.end(),
8380  a.begin(), negate&lt;double&gt;()); The corresponding functions will inline
8381  the addition and the negation. end example]</p>
8382</blockquote>
8383<p>(Note: The "addition" referred to in the above is in para 3) we can
8384find no other wording, except this (non-normative) example which suggests that
8385any "inlining" will take place in this case.</p>
8386<p>Indeed both:</p>
8387<blockquote>
8388  <p>17.4.4.3 Global Functions [lib.global.functions] 1 It is
8389  unspecified whether any global functions in the C++ Standard Library
8390  are defined as inline (7.1.2).</p>
8391</blockquote>
8392<p>and</p>
8393<blockquote>
8394  <p>17.4.4.4 Member Functions [lib.member.functions] 1 It is
8395  unspecified whether any member functions in the C++ Standard Library
8396  are defined as inline (7.1.2).</p>
8397</blockquote>
8398<p>take care to state that this may indeed NOT be the case.</p>
8399<p>Thus the example "mandates" behavior that is explicitly
8400not required elsewhere.</p>
8401
8402
8403<p><b>Proposed resolution:</b></p>
8404<p>In 20.7 [function.objects] paragraph 1, remove the sentence:</p>
8405<blockquote>
8406<p>They are important for the effective use of the library.</p>
8407</blockquote>
8408<p>Remove 20.7 [function.objects] paragraph 2, which reads:</p>
8409<blockquote>
8410  <p> Using function objects together with function templates
8411  increases the expressive power of the library as well as making the
8412  resulting code much more efficient.</p>
8413</blockquote>
8414<p>In 20.7 [function.objects] paragraph 4, remove the sentence:</p>
8415<blockquote>
8416  <p>The corresponding functions will inline the addition and the
8417  negation.</p>
8418</blockquote>
8419
8420<p><i>[Kona: The LWG agreed there was a defect.]</i></p>
8421
8422<p><i>[Tokyo: The LWG crafted the proposed resolution.]</i></p>
8423
8424
8425
8426
8427
8428
8429<hr>
8430<h3><a name="186"></a>186. bitset::set() second parameter should be bool</h3>
8431<p><b>Section:</b> 20.3.7.2 [bitset.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
8432 <b>Submitter:</b> Darin Adler <b>Opened:</b> 1999-08-13  <b>Last modified:</b> 2008-09-26</p>
8433<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>
8434<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
8435<p><b>Discussion:</b></p>
8436<p>In section 20.3.7.2 [bitset.members], paragraph 13 defines the
8437bitset::set operation to take a second parameter of type int. The
8438function tests whether this value is non-zero to determine whether to
8439set the bit to true or false. The type of this second parameter should
8440be bool. For one thing, the intent is to specify a Boolean value. For
8441another, the result type from test() is bool. In addition, it's
8442possible to slice an integer that's larger than an int. This can't
8443happen with bool, since conversion to bool has the semantic of
8444translating 0 to false and any non-zero value to true.</p>
8445
8446
8447<p><b>Proposed resolution:</b></p>
8448<p>In 20.3.7 [template.bitset] Para 1 Replace:</p>
8449<blockquote>
8450<pre>bitset&lt;N&gt;&amp; set(size_t pos, int val = true ); </pre>
8451</blockquote>
8452<p>With:</p>
8453<blockquote>
8454  <pre>bitset&lt;N&gt;&amp; set(size_t pos, bool val = true );</pre>
8455</blockquote>
8456<p>In 20.3.7.2 [bitset.members] Para 12(.5) Replace:</p>
8457<blockquote>
8458  <pre>bitset&lt;N&gt;&amp; set(size_t pos, int val = 1 );</pre>
8459</blockquote>
8460<p>With:</p>
8461<blockquote>
8462  <pre>bitset&lt;N&gt;&amp; set(size_t pos, bool val = true );</pre>
8463</blockquote>
8464
8465<p><i>[Kona: The LWG agrees with the description.&nbsp; Andy Sawyer will work
8466on better P/R wording.]</i></p>
8467
8468<p><i>[Post-Tokyo: Andy provided the above wording.]</i></p>
8469
8470
8471
8472<p><b>Rationale:</b></p>
8473<p><tt>bool</tt> is a better choice.  It is believed that binary
8474compatibility is not an issue, because this member function is
8475usually implemented as <tt>inline</tt>, and because it is already
8476the case that users cannot rely on the type of a pointer to a
8477nonvirtual member of a standard library class.</p>
8478
8479
8480
8481
8482
8483<hr>
8484<h3><a name="187"></a>187. iter_swap underspecified</h3>
8485<p><b>Section:</b> 25.3.3 [alg.swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
8486 <b>Submitter:</b> Andrew Koenig <b>Opened:</b> 1999-08-14  <b>Last modified:</b> 2008-09-26</p>
8487<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>
8488<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
8489<p><b>Discussion:</b></p>
8490<p>The description of iter_swap in 25.2.2 paragraph 7,says that it
8491``exchanges the values'' of the objects to which two iterators
8492refer.<br> <br> What it doesn't say is whether it does so using swap
8493or using the assignment operator and copy constructor.<br> <br> This
8494question is an important one to answer, because swap is specialized to
8495work efficiently for standard containers.<br> For example:</p>
8496<blockquote>
8497<pre>vector&lt;int&gt; v1, v2;
8498iter_swap(&amp;v1, &amp;v2);</pre>
8499</blockquote>
8500<p>Is this call to iter_swap equivalent to calling swap(v1, v2)?&nbsp;
8501Or is it equivalent to</p>
8502<blockquote>
8503<pre>{
8504vector&lt;int&gt; temp = v1;
8505v1 = v2;
8506v2 = temp;
8507}</pre>
8508</blockquote>
8509<p>The first alternative is O(1); the second is O(n).</p>
8510<p>A LWG member, Dave Abrahams, comments:</p>
8511<blockquote>
8512<p>Not an objection necessarily, but I want to point out the cost of
8513that requirement:</p>
8514  <blockquote>
8515<p><tt>iter_swap(list&lt;T&gt;::iterator, list&lt;T&gt;::iterator)</tt></p>
8516  </blockquote>
8517<p>can currently be specialized to be more efficient than
8518iter_swap(T*,T*) for many T (by using splicing). Your proposal would
8519make that optimization illegal.&nbsp;</p>
8520</blockquote>
8521
8522<p><i>[Kona: The LWG notes the original need for iter_swap was proxy iterators
8523which are no longer permitted.]</i></p>
8524
8525
8526
8527<p><b>Proposed resolution:</b></p>
8528<p>Change the effect clause of iter_swap in 25.2.2 paragraph 7 from:</p>
8529<blockquote>
8530<p>Exchanges the values pointed to by the two iterators a and b.</p>
8531</blockquote>
8532<p>to</p>
8533<blockquote>
8534<p><tt>swap(*a, *b)</tt>.</p>
8535</blockquote>
8536
8537
8538
8539<p><b>Rationale:</b></p>
8540<p>It's useful to say just what <tt>iter_swap</tt> does.  There may be
8541  some iterators for which we want to specialize <tt>iter_swap</tt>,
8542  but the fully general version should have a general specification.</p>
8543
8544<p>Note that in the specific case of <tt>list&lt;T&gt;::iterator</tt>,
8545iter_swap should not be specialized as suggested above.  That would do
8546much more than exchanging the two iterators' values: it would change
8547predecessor/successor relationships, possibly moving the iterator from
8548one list to another.  That would surely be inappropriate.</p>
8549
8550
8551
8552
8553
8554<hr>
8555<h3><a name="189"></a>189. setprecision() not specified correctly</h3>
8556<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>
8557 <b>Submitter:</b> Andrew Koenig <b>Opened:</b> 1999-08-25  <b>Last modified:</b> 2008-09-26</p>
8558<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>
8559<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>
8560<p><b>Discussion:</b></p>
8561<p>27.4.2.2 paragraph 9 claims that setprecision() sets the precision,
8562and includes a parenthetical note saying that it is the number of
8563digits after the decimal point.<br>
8564<br>
8565This claim is not strictly correct.  For example, in the default
8566floating-point output format, setprecision sets the number of
8567significant digits printed, not the number of digits after the decimal
8568point.<br>
8569<br>
8570I would like the committee to look at the definition carefully and
8571correct the statement in 27.4.2.2</p>
8572
8573
8574<p><b>Proposed resolution:</b></p>
8575<p>Remove from 27.5.2.2 [fmtflags.state], paragraph 9, the text
8576"(number of digits after the decimal point)".</p>
8577
8578
8579
8580
8581<hr>
8582<h3><a name="193"></a>193. Heap operations description incorrect</h3>
8583<p><b>Section:</b> 25.4.6 [alg.heap.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
8584 <b>Submitter:</b> Markus Mauhart <b>Opened:</b> 1999-09-24  <b>Last modified:</b> 2008-09-26</p>
8585<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>
8586<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#216">216</a></p>
8587<p><b>Discussion:</b></p>
8588<p>25.3.6 [lib.alg.heap.operations] states two key properties of a heap [a,b), the first of them
8589is<br>
8590<br>
8591&nbsp;&nbsp;&nbsp; `"(1) *a is the largest element"<br>
8592<br>
8593I think this is incorrect and should be changed to the wording in the proposed
8594resolution.</p>
8595<p>Actually there are two independent changes:</p>
8596<blockquote>
8597  <p>A-"part of largest equivalence class" instead of "largest", cause 25.3
8598  [lib.alg.sorting] asserts "strict weak ordering" for all its sub clauses.</p>
8599  <p>B-Take
8600'an oldest' from that equivalence class, otherwise the heap functions
8601could not be used for a priority queue as explained in 23.2.3.2.2
8602[lib.priqueue.members] (where I assume that a "priority queue" respects
8603priority AND time).</p>
8604</blockquote>
8605
8606
8607<p><b>Proposed resolution:</b></p>
8608<p>Change 25.4.6 [alg.heap.operations] property (1) from:</p>
8609<blockquote>
8610  <p>(1) *a is the largest element</p>
8611</blockquote>
8612<p>to:</p>
8613<blockquote>
8614  <p>(1) There is no element greater than <tt>*a</tt></p>
8615</blockquote>
8616
8617
8618
8619
8620
8621<hr>
8622<h3><a name="195"></a>195. Should <tt>basic_istream::sentry</tt>'s constructor ever set eofbit?</h3>
8623<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>
8624 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1999-10-13  <b>Last modified:</b> 2008-09-26</p>
8625<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>
8626<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>
8627<p><b>Discussion:</b></p>
8628<p>Suppose that <tt>is.flags() &amp; ios_base::skipws</tt> is nonzero.
8629What should <tt>basic_istream&lt;&gt;::sentry</tt>'s constructor do if it
8630reaches eof while skipping whitespace?  27.6.1.1.2/5 suggests it
8631should set failbit. Should it set eofbit as well?  The standard
8632doesn't seem to answer that question.</p>
8633
8634<p>On the one hand, nothing in 27.7.1.1.3 [istream::sentry] says that
8635<tt>basic_istream&lt;&gt;::sentry</tt> should ever set eofbit.  On the
8636other hand, 27.7.1.1 [istream] paragraph 4 says that if
8637extraction from a <tt>streambuf</tt> "returns
8638<tt>traits::eof()</tt>, then the input function, except as explicitly
8639noted otherwise, completes its actions and does
8640<tt>setstate(eofbit)"</tt>.  So the question comes down to
8641whether <tt>basic_istream&lt;&gt;::sentry</tt>'s constructor is an
8642input function.</p>
8643
8644<p>Comments from Jerry Schwarz:</p>
8645<blockquote>
8646<p>It was always my intention that eofbit should be set any time that a
8647virtual returned something to indicate eof, no matter what reason
8648iostream code had for calling the virtual.</p>
8649<p>
8650The motivation for this is that I did not want to require streambufs
8651to behave consistently if their virtuals are called after they have
8652signaled eof.</p>
8653<p>
8654The classic case is a streambuf reading from a UNIX file.  EOF isn't
8655really a state for UNIX file descriptors.  The convention is that a
8656read on UNIX returns 0 bytes to indicate "EOF", but the file
8657descriptor isn't shut down in any way and future reads do not
8658necessarily also return 0 bytes.  In particular, you can read from
8659tty's on UNIX even after they have signaled "EOF".  (It
8660isn't always understood that a ^D on UNIX is not an EOF indicator, but
8661an EOL indicator.  By typing a "line" consisting solely of
8662^D you cause a read to return 0 bytes, and by convention this is
8663interpreted as end of file.)</p>
8664</blockquote>
8665
8666
8667<p><b>Proposed resolution:</b></p>
8668<p>Add a sentence to the end of 27.6.1.1.2 paragraph 2:</p>
8669<blockquote>
8670<p>If <tt>is.rdbuf()-&gt;sbumpc()</tt> or <tt>is.rdbuf()-&gt;sgetc()</tt>
8671returns <tt>traits::eof()</tt>, the function calls
8672<tt>setstate(failbit | eofbit)</tt> (which may throw
8673<tt>ios_base::failure</tt>).
8674</p>
8675</blockquote>
8676
8677
8678
8679
8680<hr>
8681<h3><a name="198"></a>198. Validity of pointers and references unspecified after iterator destruction</h3>
8682<p><b>Section:</b> X [iterator.concepts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
8683 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 1999-11-03  <b>Last modified:</b> 2008-09-30</p>
8684<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>
8685<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
8686<p><b>Discussion:</b></p>
8687<p>
8688Is a pointer or reference obtained from an iterator still valid after
8689destruction of the iterator?
8690</p>
8691<p>
8692Is a pointer or reference obtained from an iterator still valid after the value
8693of the iterator changes?
8694</p>
8695<blockquote>
8696<pre>#include &lt;iostream&gt;
8697#include &lt;vector&gt;
8698#include &lt;iterator&gt;
8699
8700int main()
8701{
8702    typedef std::vector&lt;int&gt; vec_t;
8703    vec_t v;
8704    v.push_back( 1 );
8705
8706    // Is a pointer or reference obtained from an iterator still
8707    // valid after destruction of the iterator?
8708    int * p = &amp;*v.begin();
8709    std::cout &lt;&lt; *p &lt;&lt; '\n';  // OK?
8710
8711    // Is a pointer or reference obtained from an iterator still
8712    // valid after the value of the iterator changes?
8713    vec_t::iterator iter( v.begin() );
8714    p = &amp;*iter++;
8715    std::cout &lt;&lt; *p &lt;&lt; '\n';  // OK?
8716
8717    return 0;
8718}
8719</pre>
8720</blockquote>
8721
8722<p>The standard doesn't appear to directly address these
8723questions. The standard needs to be clarified. At least two real-world
8724cases have been reported where library implementors wasted
8725considerable effort because of the lack of clarity in the
8726standard. The question is important because requiring pointers and
8727references to remain valid has the effect for practical purposes of
8728prohibiting iterators from pointing to cached rather than actual
8729elements of containers.</p>
8730
8731<p>The standard itself assumes that pointers and references obtained
8732from an iterator are still valid after iterator destruction or
8733change. The definition of reverse_iterator::operator*(), 24.5.1.3.3 [reverse.iter.conv], which returns a reference, defines
8734effects:</p>
8735
8736<blockquote>
8737  <pre>Iterator tmp = current;
8738return *--tmp;</pre>
8739</blockquote>
8740<p>The definition of reverse_iterator::operator-&gt;(), 24.5.1.3.4
8741[reverse.iter.op.star], which returns a pointer, defines effects:</p>
8742<blockquote>
8743  <pre>return &amp;(operator*());</pre>
8744</blockquote>
8745
8746<p>Because the standard itself assumes pointers and references remain
8747valid after iterator destruction or change, the standard should say so
8748explicitly. This will also reduce the chance of user code breaking
8749unexpectedly when porting to a different standard library
8750implementation.</p>
8751
8752
8753<p><b>Proposed resolution:</b></p>
8754<p>Add a new paragraph to X [iterator.concepts]:</p>
8755<blockquote><p>
8756Destruction of an iterator may invalidate pointers and references
8757previously obtained from that iterator.
8758</p></blockquote>
8759
8760<p>Replace paragraph 1 of 24.5.1.3.3 [reverse.iter.conv] with:</p>
8761
8762<blockquote>
8763<p><b>Effects:</b></p>
8764<pre>  this-&gt;tmp = current;
8765  --this-&gt;tmp;
8766  return *this-&gt;tmp;
8767</pre>
8768
8769<p>
8770[<i>Note:</i> This operation must use an auxiliary member variable,
8771rather than a temporary variable, to avoid returning a reference that
8772persists beyond the lifetime of its associated iterator.  (See
8773X [iterator.concepts].)  The name of this member variable is shown for
8774exposition only.  <i>--end note</i>]
8775</p>
8776</blockquote>
8777
8778<p><i>[Post-Tokyo: The issue has been reformulated purely
8779in terms of iterators.]</i></p>
8780
8781
8782<p><i>[Pre-Toronto: Steve Cleary pointed out the no-invalidation
8783assumption by reverse_iterator. The issue and proposed resolution was
8784reformulated yet again to reflect this reality.]</i></p>
8785
8786
8787<p><i>[Copenhagen: Steve Cleary pointed out that reverse_iterator
8788assumes its underlying iterator has persistent pointers and
8789references.  Andy Koenig pointed out that it is possible to rewrite
8790reverse_iterator so that it no longer makes such an assupmption.
8791However, 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
8792decide it is intentional that <tt>p[n]</tt> may return by value
8793instead of reference when <tt>p</tt> is a Random Access Iterator,
8794other changes in reverse_iterator will be necessary.]</i></p>
8795
8796
8797
8798<p><b>Rationale:</b></p>
8799<p>This issue has been discussed extensively.  Note that it is
8800<i>not</i> an issue about the behavior of predefined iterators.  It is
8801asking whether or not user-defined iterators are permitted to have
8802transient pointers and references.  Several people presented examples
8803of useful user-defined iterators that have such a property; examples
8804include a B-tree iterator, and an "iota iterator" that doesn't point
8805to memory.  Library implementors already seem to be able to cope with
8806such iterators: they take pains to avoid forming references to memory
8807that gets iterated past.  The only place where this is a problem is
8808<tt>reverse_iterator</tt>, so this issue changes
8809<tt>reverse_iterator</tt> to make it work.</p>
8810
8811<p>This resolution does not weaken any guarantees provided by
8812predefined iterators like <tt>list&lt;int&gt;::iterator</tt>.
8813Clause 23 should be reviewed to make sure that guarantees for
8814predefined iterators are as strong as users expect.</p>
8815
8816
8817
8818
8819
8820
8821<hr>
8822<h3><a name="199"></a>199. What does <tt>allocate(0)</tt> return?</h3>
8823<p><b>Section:</b> 20.2.2 [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
8824 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1999-11-19  <b>Last modified:</b> 2008-09-26</p>
8825<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>
8826<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>
8827<p><b>Discussion:</b></p>
8828<p>
8829Suppose that <tt>A</tt> is a class that conforms to the
8830Allocator requirements of Table 32, and <tt>a</tt> is an
8831object of class <tt>A</tt>  What should be the return
8832value of <tt>a.allocate(0)</tt>?  Three reasonable
8833possibilities: forbid the argument <tt>0</tt>, return
8834a null pointer, or require that the return value be a
8835unique non-null pointer.
8836</p>
8837
8838
8839<p><b>Proposed resolution:</b></p>
8840<p>
8841Add a note to the <tt>allocate</tt> row of Table 32:
8842"[<i>Note:</i> If <tt>n == 0</tt>, the return value is unspecified. <i>--end note</i>]"</p>
8843
8844
8845<p><b>Rationale:</b></p>
8846<p>A key to understanding this issue is that the ultimate use of
8847allocate() is to construct an iterator, and that iterator for zero
8848length sequences must be the container's past-the-end
8849representation.  Since this already implies special case code, it
8850would be over-specification to mandate the return value.
8851</p>
8852
8853
8854
8855
8856<hr>
8857<h3><a name="200"></a>200. Forward iterator requirements don't allow constant iterators</h3>
8858<p><b>Section:</b> 24.2.3 [forward.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
8859 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1999-11-19  <b>Last modified:</b> 2008-09-26</p>
8860<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>
8861<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
8862<p><b>Discussion:</b></p>
8863<p>
8864In table 74, the return type of the expression <tt>*a</tt> is given
8865as <tt>T&amp;</tt>, where <tt>T</tt> is the iterator's value type.
8866For constant iterators, however, this is wrong.  ("Value type"
8867is never defined very precisely, but it is clear that the value type
8868of, say, <tt>std::list&lt;int&gt;::const_iterator</tt> is supposed to be
8869<tt>int</tt>, not <tt>const int</tt>.)
8870</p>
8871
8872
8873<p><b>Proposed resolution:</b></p>
8874<p>
8875In table 74, in the <tt>*a</tt> and <tt>*r++</tt> rows, change the
8876return type from "<tt>T&amp;</tt>" to "<tt>T&amp;</tt>
8877if <tt>X</tt> is mutable, otherwise <tt>const T&amp;</tt>".
8878In the <tt>a-&gt;m</tt> row, change the return type from
8879"<tt>U&amp;</tt>" to "<tt>U&amp;</tt> if <tt>X</tt> is mutable,
8880otherwise <tt>const U&amp;</tt>".
8881</p>
8882
8883<p><i>[Tokyo: The LWG believes this is the tip of a larger iceberg;
8884there are multiple const problems with the STL portion of the library
8885and that these should be addressed as a single package.&nbsp; Note
8886that 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
8887that very reason.]</i></p>
8888
8889
8890<p><i>[Redmond: the LWG thinks this is separable from other constness
8891issues.  This issue is just cleanup; it clarifies language that was
8892written before we had iterator_traits.  Proposed resolution was
8893modified: the original version only discussed *a.  It was pointed out
8894that we also need to worry about *r++ and a-&gt;m.]</i></p>
8895
8896
8897
8898
8899
8900
8901
8902<hr>
8903<h3><a name="201"></a>201. Numeric limits terminology wrong</h3>
8904<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>
8905 <b>Submitter:</b> Stephen Cleary <b>Opened:</b> 1999-12-21  <b>Last modified:</b> 2008-09-26</p>
8906<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>
8907<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
8908<p><b>Discussion:</b></p>
8909<p>
8910In some places in this section, the terms "fundamental types" and
8911"scalar types" are used when the term "arithmetic types" is intended.
8912The current usage is incorrect because void is a fundamental type and
8913pointers are scalar types, neither of which should have
8914specializations of numeric_limits.
8915</p>
8916<p><i>[Lillehammer: it remains true that numeric_limits is using
8917  imprecise language. However, none of the proposals for changed
8918  wording are clearer.  A redesign of numeric_limits is needed, but this
8919  is more a task than an open issue.]</i></p>
8920
8921
8922
8923<p><b>Proposed resolution:</b></p>
8924
8925<p>
8926Change 18.3 [support.limits] to:
8927</p>
8928
8929<blockquote>
8930<p>
8931-1- The headers <tt>&lt;limits&gt;</tt>, <tt>&lt;climits&gt;</tt>,
8932<tt>&lt;cfloat&gt;</tt>, and <tt>&lt;cinttypes&gt;</tt> supply
8933characteristics of implementation-dependent <del>fundamental</del>
8934<ins>arithmetic</ins> types (3.9.1).
8935</p>
8936</blockquote>
8937
8938<p>
8939Change 18.3.1 [limits] to:
8940</p>
8941
8942<blockquote>
8943<p>
8944-1- The <tt>numeric_limits</tt> component provides a C++ program with
8945information about various properties of the implementation's
8946representation of the <del>fundamental</del> <ins>arithmetic</ins>
8947types.
8948</p>
8949<p>
8950-2- Specializations shall be provided for each <del>fundamental</del>
8951<ins>arithmetic</ins> type, both floating point and integer, including
8952<tt>bool</tt>. The member <tt>is_specialized</tt> shall be <tt>true</tt>
8953for all such specializations of <tt>numeric_limits</tt>.
8954</p>
8955<p>
8956-4- Non-<del>fundamental</del><ins>arithmetic</ins> standard types, such
8957as <tt>complex&lt;T&gt;</tt> (26.3.2), shall not have specializations.
8958</p>
8959</blockquote>
8960
8961<p>
8962Change 18.3.1.1 [numeric.limits] to:
8963</p>
8964
8965<blockquote>
8966<p>
8967<del>-1- The member <tt>is_specialized</tt> makes it possible to distinguish
8968between fundamental types, which have specializations, and non-scalar types,
8969which do not.</del>
8970</p>
8971</blockquote>
8972
8973
8974
8975
8976
8977
8978<hr>
8979<h3><a name="202"></a>202. unique() effects unclear when predicate not an equivalence relation</h3>
8980<p><b>Section:</b> 25.3.9 [alg.unique] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
8981 <b>Submitter:</b> Andrew Koenig <b>Opened:</b> 2000-01-13  <b>Last modified:</b> 2008-09-26</p>
8982<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>
8983<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
8984<p><b>Discussion:</b></p>
8985<p>
8986What should unique() do if you give it a predicate that is not an
8987equivalence relation?  There are at least two plausible answers:
8988</p>
8989
8990<blockquote>
8991
8992<p>
8993   1. You can't, because 25.2.8 says that it it "eliminates all but
8994   the first element from every consecutive group of equal
8995   elements..." and it wouldn't make sense to interpret "equal" as
8996   meaning anything but an equivalence relation.  [It also doesn't
8997   make sense to interpret "equal" as meaning ==, because then there
8998   would never be any sense in giving a predicate as an argument at
8999   all.]
9000</p>
9001
9002<p>
9003   2. The word "equal" should be interpreted to mean whatever the
9004   predicate says, even if it is not an equivalence relation
9005   (and in particular, even if it is not transitive).
9006</p>
9007
9008</blockquote>
9009
9010<p>
9011The example that raised this question is from Usenet:
9012</p>
9013
9014<blockquote>
9015
9016<pre>int f[] = { 1, 3, 7, 1, 2 };
9017int* z = unique(f, f+5, greater&lt;int&gt;());</pre>
9018
9019</blockquote>
9020
9021<p>
9022If one blindly applies the definition using the predicate
9023greater&lt;int&gt;, and ignore the word "equal", you get:
9024</p>
9025
9026<blockquote>
9027
9028<p>
9029    Eliminates all but the first element from every consecutive group    
9030    of elements referred to by the iterator i in the range [first, last)    
9031    for which *i &gt; *(i - 1).
9032</p>
9033
9034</blockquote>
9035
9036<p>
9037The first surprise is the order of the comparison.  If we wanted to
9038allow for the predicate not being an equivalence relation, then we
9039should surely compare elements the other way: pred(*(i - 1), *i).  If
9040we do that, then the description would seem to say: "Break the
9041sequence into subsequences whose elements are in strictly increasing
9042order, and keep only the first element of each subsequence".  So the
9043result would be 1, 1, 2.  If we take the description at its word, it
9044would seem to call for strictly DEcreasing order, in which case the
9045result should be 1, 3, 7, 2.<br>
9046<br>
9047In fact, the SGI implementation of unique() does neither: It yields 1,
90483, 7.
9049</p>
9050
9051
9052<p><b>Proposed resolution:</b></p>
9053<p>Change 25.3.9 [alg.unique] paragraph 1 to:</p>
9054<blockquote><p>
9055For a nonempty range, eliminates all but the first element from every
9056consecutive group of equivalent elements referred to by the iterator
9057<tt>i</tt> in the range [first+1, last) for which the following
9058conditions hold: <tt>*(i-1) == *i</tt> or <tt>pred(*(i-1), *i) !=
9059false</tt>.
9060</p></blockquote>
9061
9062<p>
9063Also insert a new paragraph, paragraph 2a, that reads: "Requires: The
9064comparison function must be an equivalence relation."
9065</p>
9066
9067<p><i>[Redmond: discussed arguments for and against requiring the
9068comparison function to be an equivalence relation.  Straw poll:
906914-2-5.  First number is to require that it be an equivalence
9070relation, second number is to explicitly not require that it be an
9071equivalence relation, third number is people who believe they need
9072more time to consider the issue.  A separate issue: Andy Sawyer
9073pointed out that "i-1" is incorrect, since "i" can refer to the first
9074iterator in the range.  Matt provided wording to address this
9075problem.]</i></p>
9076
9077
9078<p><i>[Cura�ao: The LWG changed "... the range (first,
9079last)..." to "...  the range [first+1, last)..." for
9080clarity. They considered this change close enough to editorial to not
9081require another round of review.]</i></p>
9082
9083
9084
9085
9086<p><b>Rationale:</b></p>
9087<p>The LWG also considered an alternative resolution: change 
908825.3.9 [alg.unique] paragraph 1 to:</p>
9089
9090<blockquote><p>
9091For a nonempty range, eliminates all but the first element from every
9092consecutive group of elements referred to by the iterator
9093<tt>i</tt> in the range (first, last) for which the following
9094conditions hold: <tt>*(i-1) == *i</tt> or <tt>pred(*(i-1), *i) !=
9095false</tt>.
9096</p></blockquote>
9097
9098<p>
9099Also insert a new paragraph, paragraph 1a, that reads: "Notes: The
9100comparison function need not be an equivalence relation."
9101</p>
9102
9103
9104<p>Informally: the proposed resolution imposes an explicit requirement
9105that the comparison function be an equivalence relation.  The
9106alternative resolution does not, and it gives enough information so
9107that the behavior of unique() for a non-equivalence relation is
9108specified.  Both resolutions are consistent with the behavior of
9109existing implementations.</p>
9110
9111
9112
9113
9114
9115<hr>
9116<h3><a name="206"></a>206. operator new(size_t, nothrow) may become unlinked to ordinary operator new if ordinary version replaced</h3>
9117<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>
9118 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 1999-08-29  <b>Last modified:</b> 2008-09-26</p>
9119<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>
9120<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
9121<p><b>Discussion:</b></p>
9122<p>As specified, the implementation of the nothrow version of operator
9123new does not necessarily call the ordinary operator new, but may
9124instead simply call the same underlying allocator and return a null
9125pointer instead of throwing an exception in case of failure.</p>
9126
9127<p>Such an implementation breaks code that replaces the ordinary
9128version of new, but not the nothrow version. If the ordinary version
9129of new/delete is replaced, and if the replaced delete is not
9130compatible with pointers returned from the library versions of new,
9131then when the replaced delete receives a pointer allocated by the
9132library new(nothrow), crash follows.</p>
9133
9134<p>The fix appears to be that the lib version of new(nothrow) must
9135call the ordinary new. Thus when the ordinary new gets replaced, the
9136lib version will call the replaced ordinary new and things will
9137continue to work.</p>
9138
9139<p>An alternative would be to have the ordinary new call
9140new(nothrow). This seems sub-optimal to me as the ordinary version of
9141new is the version most commonly replaced in practice. So one would
9142still need to replace both ordinary and nothrow versions if one wanted
9143to replace the ordinary version.</p>
9144
9145<p>Another alternative is to put in clear text that if one version is
9146replaced, then the other must also be replaced to maintain
9147compatibility. Then the proposed resolution below would just be a
9148quality of implementation issue. There is already such text in
9149paragraph 7 (under the new(nothrow) version). But this nuance is
9150easily missed if one reads only the paragraphs relating to the
9151ordinary new.</p>
9152
9153<p>
9154<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2158.html">N2158</a>
9155has been written explaining the rationale for the proposed resolution below.
9156</p>
9157
9158
9159
9160<p><b>Proposed resolution:</b></p>
9161<p>
9162Change 18.5.1.1 [new.delete.single]:
9163</p>
9164
9165<blockquote>
9166<pre>void* operator new(std::size_t <i>size</i>, const std::nothrow_t&amp;) throw();
9167</pre>
9168<blockquote>
9169<p>
9170-5- <i>Effects:</i> Same as above, except that it is called by a placement
9171version of a <i>new-expression</i> when a C++ program prefers a null pointer result as
9172an error indication, instead of a <tt>bad_alloc</tt> exception.
9173</p>
9174
9175<p>
9176-6- <i>Replaceable:</i> a C++ program may define a function with this function
9177signature that displaces the default version defined by the C++ Standard
9178library.
9179</p>
9180
9181<p>
9182-7- <i>Required behavior:</i> Return a non-null pointer to suitably aligned
9183storage (3.7.4), or else return a null pointer. This nothrow version of operator
9184new returns a pointer obtained as if acquired from the <ins>(possibly
9185replaced)</ins> ordinary version. This requirement is binding on a replacement
9186version of this function.
9187</p>
9188
9189<p>
9190-8- <i>Default behavior:</i>
9191</p>
9192<ul>
9193<li><ins>
9194Calls <tt>operator new(<i>size</i>)</tt>.
9195</ins></li>
9196<li><ins>
9197If the call to <tt>operator new(<i>size</i>)</tt> returns normally, returns
9198the result of that call, else
9199</ins></li>
9200<li><ins>
9201if the call to <tt>operator new(<i>size</i>)</tt> throws an exception, returns
9202a null pointer.
9203</ins></li>
9204<li><del>
9205Executes a loop: Within the loop, the function first attempts to allocate the
9206requested storage. Whether the attempt involves a call to the Standard C library
9207function <tt>malloc</tt> is unspecified.
9208</del></li>
9209<li><del>
9210Returns a pointer to the allocated storage if the attempt is successful.
9211Otherwise, if the last argument to <tt>set_new_handler()</tt> was a null
9212pointer, return a null pointer.
9213</del></li>
9214<li><del>
9215Otherwise, the function calls the current <i>new_handler</i> (18.5.2.2). If the
9216called function returns, the loop repeats.
9217</del></li>
9218<li><del>
9219The loop terminates when an attempt to allocate the requested storage is
9220successful or when a called <i>new_handler</i> function does not return. If the
9221called <i>new_handler</i> function terminates by throwing a <tt>bad_alloc
9222exception</tt>, the function returns a null pointer.
9223</del></li>
9224</ul>
9225<p>
9226-9- [<i>Example:</i>
9227</p>
9228<blockquote><pre>T* p1 = new T;                 <i>// throws bad_alloc if it fails</i>
9229T* p2 = new(nothrow) T;        <i>// returns 0 if it fails</i>
9230</pre></blockquote>
9231<p>
9232--<i>end example</i>]
9233</p>
9234</blockquote>
9235
9236<pre>void operator delete(void* <i>ptr</i>) throw();
9237<del>void operator delete(void* <i>ptr</i>, const std::nothrow_t&amp;) throw();</del>
9238</pre>
9239
9240<blockquote>
9241<p>
9242-10- <i>Effects:</i> The <i>deallocation function</i> (3.7.4.2) called by a
9243<i>delete-expression</i> to render the value of <tt><i>ptr</i></tt> invalid.
9244</p>
9245<p>
9246-11- <i>Replaceable:</i> a C++ program may define a function with this function
9247signature that displaces the default version defined by the C++ Standard
9248library.
9249</p>
9250<p>
9251-12- <i>Requires:</i> the value of <tt><i>ptr</i></tt> is null or the value
9252returned by an earlier call to the <del>default</del> <ins>(possibly
9253replaced)</ins> <tt>operator new(std::size_t)</tt> or <tt>operator
9254new(std::size_t, const std::nothrow_t&amp;)</tt>.
9255</p>
9256<p>
9257-13- <i>Default behavior:</i>
9258</p>
9259<ul>
9260<li>
9261For a null value of <tt><i>ptr</i></tt>, do nothing.
9262</li>
9263<li>
9264Any other value of <tt><i>ptr</i></tt> shall be a value returned earlier by a
9265call to the default <tt>operator new</tt>, which was not invalidated by an
9266intervening call to <tt>operator delete(void*)</tt> (17.4.3.7). For such a
9267non-null value of <tt><i>ptr</i></tt>, reclaims storage allocated by the earlier
9268call to the default <tt>operator new</tt>.
9269</li>
9270</ul>
9271<p>
9272-14- <i>Remarks:</i>  It is unspecified under what conditions part or all of
9273such reclaimed storage is allocated by a subsequent call to <tt>operator
9274new</tt> or any of <tt>calloc</tt>, <tt>malloc</tt>, or <tt>realloc</tt>,
9275declared in <tt>&lt;cstdlib&gt;</tt>.
9276</p>
9277</blockquote>
9278
9279<pre><ins>void operator delete(void* <i>ptr</i>, const std::nothrow_t&amp;) throw();</ins>
9280</pre>
9281
9282<blockquote>
9283<p><ins>
9284-15- <i>Effects:</i> Same as above, except that it is called by the
9285implementation when an exception propagates from a nothrow placement version
9286of the <i>new-expression</i> (i.e. when the constructor throws an exception).
9287</ins></p>
9288<p><ins>
9289-16- <i>Replaceable:</i> a C++ program may define a function with this function
9290signature that displaces the default version defined by the C++ Standard
9291library.
9292</ins></p>
9293<p><ins>
9294-17- <i>Requires:</i> the value of <tt><i>ptr</i></tt> is null or the
9295value returned by an earlier call to the (possibly replaced) <tt>operator
9296new(std::size_t)</tt> or <tt>operator new(std::size_t, const
9297std::nothrow_t&amp;)</tt>. </ins></p>
9298<p><ins>
9299-18- <i>Default behavior:</i> Calls <tt>operator delete(<i>ptr</i>)</tt>.
9300</ins></p>
9301</blockquote>
9302
9303</blockquote>
9304
9305<p>
9306Change 18.5.1.2 [new.delete.array]
9307</p>
9308
9309<blockquote>
9310<pre>void* operator new[](std::size_t <i>size</i>, const std::nothrow_t&amp;) throw();
9311</pre>
9312
9313<blockquote>
9314<p>
9315-5- <i>Effects:</i> Same as above, except that it is called by a placement
9316version of a <i>new-expression</i> when a C++ program prefers a null pointer result as
9317an error indication, instead of a <tt>bad_alloc</tt> exception.
9318</p>
9319
9320<p>
9321-6- <i>Replaceable:</i>  a C++ program can define a function with this function
9322signature that displaces the default version defined by the C++ Standard
9323library.
9324</p>
9325
9326<p>
9327-7- <i>Required behavior:</i> <del>Same as for operator <tt>new(std::size_t,
9328const std::nothrow_t&amp;)</tt>. This nothrow version of operator <tt>new[]</tt>
9329returns a pointer obtained as if acquired from the ordinary version.</del>
9330<ins>Return a non-null pointer to suitably aligned storage (3.7.4), or else
9331return a null pointer. This nothrow version of operator new returns a pointer
9332obtained as if acquired from the (possibly replaced) <tt>operator
9333new[](std::size_t <i>size</i>)</tt>. This requirement is binding on a
9334replacement version of this function.</ins>
9335</p>
9336
9337<p>
9338-8- <i>Default behavior:</i> <del>Returns <tt>operator new(<i>size</i>,
9339nothrow)</tt>.</del>
9340</p>
9341
9342<ul>
9343<li><ins>
9344Calls <tt>operator new[](<i>size</i>)</tt>.
9345</ins></li>
9346<li><ins>
9347If the call to <tt>operator new[](<i>size</i>)</tt> returns normally, returns
9348the result of that call, else
9349</ins></li>
9350<li><ins>
9351if the call to <tt>operator new[](<i>size</i>)</tt> throws an exception, returns
9352a null pointer.
9353</ins></li>
9354</ul>
9355</blockquote>
9356
9357<pre>void operator delete[](void* <i>ptr</i>) throw(); 
9358void operator delete[](void* <i>ptr</i>, const std::nothrow_t&amp;) throw();
9359</pre>
9360
9361<blockquote>
9362<p>
9363-9- <i>Effects:</i> The <i>deallocation function</i> (3.7.4.2) called by the
9364array form of a <i>delete-expression</i> to render the value of
9365<tt><i>ptr</i></tt> invalid.
9366</p>
9367
9368<p>
9369-10- <i>Replaceable:</i> a C++ program can define a function with this function
9370signature that displaces the default version defined by the C++ Standard
9371library.
9372</p>
9373
9374<p>
9375-11- <i>Requires:</i> the value of
9376<tt><i>ptr</i></tt> is null or the value returned by an earlier call to
9377<tt>operator new[](std::size_t)</tt> or <tt>operator new[](std::size_t, const
9378std::nothrow_t&amp;)</tt>.
9379</p>
9380
9381<p>
9382-12- <i>Default behavior:</i> Calls <tt>operator delete(<i>ptr</i>)</tt> or
9383<tt>operator delete<ins>[]</ins>(<i>ptr</i><del>, std::nothrow</del>)</tt> respectively.
9384</p>
9385</blockquote>
9386
9387</blockquote>
9388
9389
9390
9391<p><b>Rationale:</b></p>
9392<p>Yes, they may become unlinked, and that is by design. If a user
9393replaces one, the user should also replace the other.</p>
9394
9395<p><i>[
9396Reopened due to a gcc conversation between Howard, Martin and Gaby.  Forwarding
9397or not is visible behavior to the client and it would be useful for the client
9398to know which behavior it could depend on.
9399]</i></p>
9400
9401
9402<p><i>[
9403Batavia: Robert voiced serious reservations about backwards compatibility for
9404his customers.
9405]</i></p>
9406
9407
9408
9409
9410
9411
9412<hr>
9413<h3><a name="208"></a>208. Unnecessary restriction on past-the-end iterators</h3>
9414<p><b>Section:</b> X [iterator.concepts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
9415 <b>Submitter:</b> Stephen Cleary <b>Opened:</b> 2000-02-02  <b>Last modified:</b> 2008-09-30</p>
9416<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>
9417<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>
9418<p><b>Discussion:</b></p>
9419<p>In 24.1 paragraph 5, it is stated ". . . Dereferenceable and
9420past-the-end values are always non-singular."</p>
9421<p>This places an unnecessary restriction on past-the-end iterators for
9422containers with forward iterators (for example, a singly-linked list). If the
9423past-the-end value on such a container was a well-known singular value, it would
9424still satisfy all forward iterator requirements.</p>
9425<p>Removing this restriction would allow, for example, a singly-linked list
9426without a "footer" node.</p>
9427<p>This would have an impact on existing code that expects past-the-end
9428iterators obtained from different (generic) containers being not equal.</p>
9429
9430
9431<p><b>Proposed resolution:</b></p>
9432<p>Change X [iterator.concepts] paragraph 5, the last sentence, from:</p>
9433<blockquote>
9434<p>Dereferenceable and past-the-end values are always non-singular.</p>
9435</blockquote>
9436<p>to:</p>
9437<blockquote>
9438<p>Dereferenceable values are always non-singular.&nbsp;</p>
9439</blockquote>
9440
9441
9442<p><b>Rationale:</b></p>
9443<p>For some kinds of containers, including singly linked lists and
9444zero-length vectors, null pointers are perfectly reasonable past-the-end
9445iterators.  Null pointers are singular.
9446</p>
9447
9448
9449
9450
9451<hr>
9452<h3><a name="209"></a>209. basic_string declarations inconsistent</h3>
9453<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>
9454 <b>Submitter:</b> Igor Stauder <b>Opened:</b> 2000-02-11  <b>Last modified:</b> 2008-09-26</p>
9455<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>
9456<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>
9457<p><b>Discussion:</b></p>
9458<p>In Section 21.4 [basic.string] the basic_string member function
9459declarations use a consistent style except for the following functions:</p>
9460<blockquote>
9461  <pre>void push_back(const charT);
9462basic_string&amp; assign(const basic_string&amp;);
9463void swap(basic_string&lt;charT,traits,Allocator&gt;&amp;);</pre>
9464</blockquote>
9465<p>- push_back, assign, swap: missing argument name&nbsp;<br>
9466- push_back: use of const with charT (i.e. POD type passed by value
9467not by reference - should be charT or const charT&amp; )<br>
9468- swap: redundant use of template parameters in argument
9469basic_string&lt;charT,traits,Allocator&gt;&amp;</p>
9470
9471
9472<p><b>Proposed resolution:</b></p>
9473<p>In Section 21.4 [basic.string] change the basic_string member
9474function declarations push_back, assign, and swap to:</p>
9475<blockquote>
9476  <pre>void push_back(charT c); 
9477
9478basic_string&amp; assign(const basic_string&amp; str);
9479void swap(basic_string&amp; str);</pre>
9480</blockquote>
9481
9482
9483<p><b>Rationale:</b></p>
9484<p>Although the standard is in general not consistent in declaration
9485style, the basic_string declarations are consistent other than the
9486above.  The LWG felt that this was sufficient reason to merit the
9487change.
9488</p>
9489
9490
9491
9492
9493<hr>
9494<h3><a name="210"></a>210. distance first and last confused</h3>
9495<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>
9496 <b>Submitter:</b> Lisa Lippincott <b>Opened:</b> 2000-02-15  <b>Last modified:</b> 2008-09-26</p>
9497<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#algorithms">active issues</a> in [algorithms].</p>
9498<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>
9499<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>
9500<p><b>Discussion:</b></p>
9501<p>In paragraph 9 of section 25 [algorithms], it is written:</p>
9502<blockquote>
9503  <p>      In the description of the algorithms operators + and - are used
9504           for some of the iterator categories for which they do not have to
9505           be defined. In these cases the semantics of [...] a-b is the same
9506           as of<br>
9507  <br>
9508  &nbsp;&nbsp;&nbsp;&nbsp; <tt>return distance(a, b);</tt></p>
9509</blockquote>
9510
9511
9512<p><b>Proposed resolution:</b></p>
9513<p>On the last line of paragraph 9 of section 25 [algorithms] change
9514<tt>"a-b"</tt> to <tt>"b-a".</tt></p>
9515
9516
9517<p><b>Rationale:</b></p>
9518<p>There are two ways to fix the defect; change the description to b-a
9519or change the return to distance(b,a).  The LWG preferred the
9520former for consistency.</p>
9521
9522
9523
9524
9525<hr>
9526<h3><a name="211"></a>211. operator&gt;&gt;(istream&amp;, string&amp;) doesn't set failbit</h3>
9527<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>
9528 <b>Submitter:</b> Scott Snyder <b>Opened:</b> 2000-02-04  <b>Last modified:</b> 2008-09-26</p>
9529<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>
9530<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>
9531<p><b>Discussion:</b></p>
9532<p>The description of the stream extraction operator for std::string (section
953321.3.7.9 [lib.string.io]) does not contain a requirement that failbit be set in
9534the case that the operator fails to extract any characters from the input
9535stream.</p>
9536<p>This implies that the typical construction</p>
9537<blockquote>
9538  <pre>std::istream is;
9539std::string str;
9540...
9541while (is &gt;&gt; str) ... ;</pre>
9542</blockquote>
9543<p>(which tests failbit) is not required to terminate at EOF.</p>
9544<p>Furthermore, this is inconsistent with other extraction operators,
9545which do include this requirement. (See sections 27.7.1.2 [istream.formatted] and 27.7.1.3 [istream.unformatted]), where this
9546requirement is present, either explicitly or implicitly, for the
9547extraction operators. It is also present explicitly in the description
9548of getline (istream&amp;, string&amp;, charT) in section 21.4.8.9 [string.io] paragraph 8.)</p>
9549
9550
9551<p><b>Proposed resolution:</b></p>
9552<p>Insert new paragraph after paragraph 2 in section 21.4.8.9 [string.io]:</p>
9553<blockquote>
9554
9555<p>If the function extracts no characters, it calls
9556is.setstate(ios::failbit) which may throw ios_base::failure
9557(27.4.4.3).</p>
9558</blockquote>
9559
9560
9561
9562
9563<hr>
9564<h3><a name="212"></a>212. Empty range behavior unclear for several algorithms</h3>
9565<p><b>Section:</b> 25.4.7 [alg.min.max] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
9566 <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 2000-02-26  <b>Last modified:</b> 2008-09-26</p>
9567<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>
9568<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>
9569<p><b>Discussion:</b></p>
9570<p>The standard doesn't specify what min_element() and max_element() shall
9571return if the range is empty (first equals last). The usual implementations
9572return last. This problem seems also apply to partition(), stable_partition(),
9573next_permutation(), and prev_permutation().</p>
9574
9575
9576<p><b>Proposed resolution:</b></p>
9577<p>In 25.4.7 [alg.min.max] - Minimum and maximum, paragraphs 7 and
95789, append: Returns last if first==last.</p>
9579
9580
9581<p><b>Rationale:</b></p>
9582<p>The LWG looked in some detail at all of the above mentioned
9583algorithms, but believes that except for min_element() and
9584max_element() it is already clear that last is returned if first ==
9585last.</p>
9586
9587
9588
9589
9590<hr>
9591<h3><a name="214"></a>214. set::find() missing const overload</h3>
9592<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>
9593 <b>Submitter:</b> Judy Ward <b>Opened:</b> 2000-02-28  <b>Last modified:</b> 2008-09-26</p>
9594<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>
9595<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
9596<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#450">450</a></p>
9597<p><b>Discussion:</b></p>
9598<p>The specification for the associative container requirements in
9599Table 69 state that the find member function should "return
9600iterator; const_iterator for constant a". The map and multimap
9601container descriptions have two overloaded versions of find, but set
9602and multiset do not, all they have is:</p>
9603<blockquote>
9604  <pre>iterator find(const key_type &amp; x) const;</pre>
9605</blockquote>
9606
9607
9608<p><b>Proposed resolution:</b></p>
9609<p>Change the prototypes for find(), lower_bound(), upper_bound(), and
9610equal_range() in section 23.4.3 [set] and section 23.4.4 [multiset] to each have two overloads:</p>
9611<blockquote>
9612  <pre>iterator find(const key_type &amp; x);
9613const_iterator find(const key_type &amp; x) const;</pre>
9614  <pre>iterator lower_bound(const key_type &amp; x);
9615const_iterator lower_bound(const key_type &amp; x) const;</pre>
9616  <pre>iterator upper_bound(const key_type &amp; x);
9617const_iterator upper_bound(const key_type &amp; x) const;</pre>
9618  <pre>pair&lt;iterator, iterator&gt; equal_range(const key_type &amp; x);
9619pair&lt;const_iterator, const_iterator&gt; equal_range(const key_type &amp; x) const;</pre>
9620</blockquote>
9621
9622<p><i>[Tokyo: At the request of the LWG, Judy Ward provided wording
9623extending the proposed resolution to lower_bound, upper_bound, and
9624equal_range.]</i></p>
9625
9626
9627
9628
9629
9630
9631<hr>
9632<h3><a name="217"></a>217. Facets example (Classifying Japanese characters) contains errors</h3>
9633<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>
9634 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-02-29  <b>Last modified:</b> 2008-09-26</p>
9635<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>
9636<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>
9637<p><b>Discussion:</b></p>
9638<p>The example in 22.2.8, paragraph 11 contains the following errors:</p>
9639<p>1) The member function `My::JCtype::is_kanji()' is non-const; the function
9640must be const in order for it to be callable on a const object (a reference to
9641which which is what std::use_facet&lt;&gt;() returns).</p>
9642<p>2) In file filt.C, the definition of `JCtype::id' must be qualified with the
9643name of the namespace `My'.</p>
9644<p>3) In the definition of `loc' and subsequently in the call to use_facet&lt;&gt;()
9645in main(), the name of the facet is misspelled: it should read `My::JCtype'
9646rather than `My::JCType'.</p>
9647
9648
9649<p><b>Proposed resolution:</b></p>
9650<p>Replace the "Classifying Japanese characters" example in 22.2.8,
9651paragraph 11 with the following:</p>
9652<pre>#include &lt;locale&gt;</pre>
9653<pre>namespace My {
9654    using namespace std;
9655    class JCtype : public locale::facet {
9656    public:
9657        static locale::id id;     //  required for use as a new locale facet
9658        bool is_kanji (wchar_t c) const;
9659        JCtype() {}
9660    protected:
9661        ~JCtype() {}
9662    };
9663}</pre>
9664<pre>//  file:  filt.C
9665#include &lt;iostream&gt;
9666#include &lt;locale&gt;
9667#include "jctype"                 //  above
9668std::locale::id My::JCtype::id;   //  the static  JCtype  member
9669declared above.</pre>
9670<pre>int main()
9671{
9672    using namespace std;
9673    typedef ctype&lt;wchar_t&gt; wctype;
9674    locale loc(locale(""),              //  the user's preferred locale...
9675               new My::JCtype);         //  and a new feature ...
9676    wchar_t c = use_facet&lt;wctype&gt;(loc).widen('!');
9677    if (!use_facet&lt;My::JCtype&gt;(loc).is_kanji(c))
9678        cout &lt;&lt; "no it isn't!" &lt;&lt; endl;
9679    return 0;
9680}</pre>
9681
9682
9683
9684
9685<hr>
9686<h3><a name="220"></a>220. ~ios_base() usage valid?</h3>
9687<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>
9688 <b>Submitter:</b> Jonathan Schilling, Howard Hinnant <b>Opened:</b> 2000-03-13  <b>Last modified:</b> 2008-09-26</p>
9689<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>
9690<p><b>Discussion:</b></p>
9691<p>The pre-conditions for the ios_base destructor are described in 27.4.2.7
9692paragraph 2:</p>
9693<blockquote>
9694  <p>Effects: Destroys an object of class ios_base. Calls each registered
9695  callback pair (fn,index) (27.4.2.6) as (*fn)(erase_event,*this,index) at such
9696  time that any ios_base member function called from within fn has well defined
9697  results.</p>
9698</blockquote>
9699<p>But what is not clear is: If no callback functions were ever registered, does
9700it matter whether the ios_base members were ever initialized?</p>
9701<p>For instance, does this program have defined behavior:</p>
9702<blockquote>
9703  <pre>#include &lt;ios&gt;</pre>
9704  <pre>class D : public std::ios_base { };</pre>
9705  <pre>int main() { D d; }</pre>
9706</blockquote>
9707<p>It seems that registration of a callback function would surely affect the
9708state of an ios_base. That is, when you register a callback function with an
9709ios_base, the ios_base must record that fact somehow.</p>
9710<p>But if after construction the ios_base is in an indeterminate state, and that
9711state is not made determinate before the destructor is called, then how would
9712the destructor know if any callbacks had indeed been registered? And if the
9713number of callbacks that had been registered is indeterminate, then is not the
9714behavior of the destructor undefined?</p>
9715<p>By comparison, the basic_ios class description in 27.4.4.1 paragraph 2 makes
9716it explicit that destruction before initialization results in undefined
9717behavior.</p>
9718
9719
9720<p><b>Proposed resolution:</b></p>
9721<p>Modify 27.4.2.7 paragraph 1 from</p>
9722<blockquote>
9723  <p>Effects: Each ios_base member has an indeterminate value after
9724  construction.</p>
9725</blockquote>
9726<p>to</p>
9727<blockquote>
9728  <p>Effects: Each ios_base member has an indeterminate
9729value after construction. These members must be initialized by calling
9730basic_ios::init. If an ios_base object is destroyed before these
9731initializations have taken place, the behavior is undefined.</p>
9732</blockquote>
9733
9734
9735
9736
9737<hr>
9738<h3><a name="221"></a>221. num_get&lt;&gt;::do_get stage 2 processing broken</h3>
9739<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>
9740 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2000-03-14  <b>Last modified:</b> 2008-09-26</p>
9741<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>
9742<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>
9743<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
9744<p><b>Discussion:</b></p>
9745<p>Stage 2 processing of numeric conversion is broken.</p>
9746
9747<p>Table 55 in 22.2.2.1.2 says that when basefield is 0 the integral
9748conversion specifier is %i. A %i specifier determines a number's base
9749by its prefix (0 for octal, 0x for hex), so the intention is clearly
9750that a 0x prefix is allowed.  Paragraph 8 in the same section,
9751however, describes very precisely how characters are processed. (It
9752must be done "as if" by a specified code fragment.) That
9753description does not allow a 0x prefix to be recognized.</p>
9754
9755<p>Very roughly, stage 2 processing reads a char_type ct. It converts
9756ct to a char, not by using narrow but by looking it up in a
9757translation table that was created by widening the string literal
9758"0123456789abcdefABCDEF+-". The character "x" is
9759not found in that table, so it can't be recognized by stage 2
9760processing.</p>
9761
9762
9763<p><b>Proposed resolution:</b></p>
9764<p>In 22.2.2.1.2 paragraph 8, replace the line:</p>
9765<blockquote>
9766  <pre>static const char src[] = "0123456789abcdefABCDEF+-";</pre>
9767</blockquote>
9768<p>with the line:</p>
9769<blockquote>
9770  <pre>static const char src[] = "0123456789abcdefxABCDEFX+-";</pre>
9771</blockquote>
9772
9773
9774<p><b>Rationale:</b></p>
9775<p>If we're using the technique of widening a string literal, the
9776string literal must contain every character we wish to recognize.
9777This technique has the consequence that alternate representations
9778of digits will not be recognized.  This design decision was made
9779deliberately, with full knowledge of that limitation.</p>
9780
9781
9782
9783
9784
9785<hr>
9786<h3><a name="222"></a>222. Are throw clauses necessary if a throw is already implied by the effects clause?</h3>
9787<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>
9788 <b>Submitter:</b> Judy Ward <b>Opened:</b> 2000-03-17  <b>Last modified:</b> 2008-09-26</p>
9789<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>
9790<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>
9791<p><b>Discussion:</b></p>
9792<p>Section 21.3.6.8 describes the basic_string::compare function this way:</p>
9793<blockquote>
9794  <pre>21.3.6.8 - basic_string::compare [lib.string::compare]
9795
9796int compare(size_type pos1, size_type n1,
9797                const basic_string&lt;charT,traits,Allocator&gt;&amp;  str ,
9798                size_type  pos2 , size_type  n2 ) const;
9799
9800-4- Returns: 
9801
9802    basic_string&lt;charT,traits,Allocator&gt;(*this,pos1,n1).compare(
9803                 basic_string&lt;charT,traits,Allocator&gt;(str,pos2,n2)) .</pre>
9804</blockquote>
9805<p>and the constructor that's implicitly called by the above is
9806defined to throw an out-of-range exception if pos &gt; str.size(). See
9807section 21.4.1 [string.require] paragraph 4.</p>
9808
9809<p>On the other hand, the compare function descriptions themselves don't have
9810"Throws: " clauses and according to 17.3.1.3, paragraph 3, elements
9811that do not apply to a function are omitted.</p>
9812<p>So it seems there is an inconsistency in the standard -- are the
9813"Effects" clauses correct, or are the "Throws" clauses
9814missing?</p>
9815
9816
9817<p><b>Proposed resolution:</b></p>
9818<p>In 17.5.1.4 [structure.specifications] paragraph 3, the footnote 148 attached to
9819the sentence "Descriptions of function semantics contain the
9820following elements (as appropriate):", insert the word
9821"further" so that the foot note reads:</p>
9822<blockquote>
9823  <p>To save space, items that do not apply to a function are
9824  omitted. For example, if a function does not specify any further
9825  preconditions, there will be no "Requires" paragraph.</p>
9826</blockquote>
9827
9828
9829<p><b>Rationale:</b></p>
9830<p>The standard is somewhat inconsistent, but a failure to note a
9831throw condition in a throws clause does not grant permission not to
9832throw.  The inconsistent wording is in a footnote, and thus
9833non-normative. The proposed resolution from the LWG clarifies the
9834footnote.</p>
9835
9836
9837
9838
9839<hr>
9840<h3><a name="223"></a>223. reverse algorithm should use iter_swap rather than swap</h3>
9841<p><b>Section:</b> 25.3.10 [alg.reverse] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
9842 <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2000-03-21  <b>Last modified:</b> 2008-09-26</p>
9843<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>
9844<p><b>Discussion:</b></p>
9845<p>Shouldn't the effects say "applies iter_swap to all pairs..."?</p>
9846
9847
9848<p><b>Proposed resolution:</b></p>
9849<p>In 25.3.10 [alg.reverse], replace:</p>
9850  <blockquote><p>
9851  Effects: For each non-negative integer i &lt;= (last - first)/2, 
9852  applies swap to all pairs of iterators first + i, (last - i) - 1.
9853  </p></blockquote>
9854<p>with:</p>
9855  <blockquote><p>
9856  Effects: For each non-negative integer i &lt;= (last - first)/2, 
9857  applies iter_swap to all pairs of iterators first + i, (last - i) - 1.
9858  </p></blockquote>
9859
9860
9861
9862
9863<hr>
9864<h3><a name="224"></a>224. clear() complexity for associative containers refers to undefined N</h3>
9865<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>
9866 <b>Submitter:</b> Ed Brey <b>Opened:</b> 2000-03-23  <b>Last modified:</b> 2008-09-26</p>
9867<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>
9868<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>
9869<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>
9870<p><b>Discussion:</b></p>
9871<p>In the associative container requirements table in 23.1.2 paragraph 7,
9872a.clear() has complexity "log(size()) + N". However, the meaning of N
9873is not defined.</p>
9874
9875
9876<p><b>Proposed resolution:</b></p>
9877<p>In the associative container requirements table in 23.1.2 paragraph
98787, the complexity of a.clear(), change "log(size()) + N" to
9879"linear in <tt>size()</tt>".</p>
9880
9881
9882<p><b>Rationale:</b></p>
9883<p>It's the "log(size())", not the "N", that is in
9884error: there's no difference between <i>O(N)</i> and <i>O(N +
9885log(N))</i>.  The text in the standard is probably an incorrect
9886cut-and-paste from the range version of <tt>erase</tt>.</p>
9887
9888
9889
9890
9891<hr>
9892<h3><a name="225"></a>225. std:: algorithms use of other unqualified algorithms</h3>
9893<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>
9894 <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2000-04-01  <b>Last modified:</b> 2008-09-26</p>
9895<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>
9896<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
9897<p><b>Discussion:</b></p>
9898<p>Are algorithms in std:: allowed to use other algorithms without qualification, so functions in
9899user namespaces might be found through Koenig lookup?</p>
9900<p>For example, a popular standard library implementation includes this
9901implementation of std::unique:</p>
9902<blockquote>
9903<pre>namespace std {
9904    template &lt;class _ForwardIter&gt;
9905    _ForwardIter unique(_ForwardIter __first, _ForwardIter __last) {
9906      __first = adjacent_find(__first, __last);
9907      return unique_copy(__first, __last, __first);
9908    }
9909    }</pre>
9910</blockquote>
9911<p>Imagine two users on opposite sides of town, each using unique on his own
9912sequences bounded by my_iterators . User1 looks at his standard library
9913implementation and says, "I know how to implement a more efficient
9914unique_copy for my_iterators", and writes:</p>
9915<blockquote>
9916<pre>namespace user1 {
9917    class my_iterator;
9918    // faster version for my_iterator
9919    my_iterator unique_copy(my_iterator, my_iterator, my_iterator);
9920    }</pre>
9921</blockquote>
9922<p>user1::unique_copy() is selected by Koenig lookup, as he intended.</p>
9923<p>User2 has other needs, and writes:</p>
9924<blockquote>
9925<pre>namespace user2 {
9926    class my_iterator;
9927    // Returns true iff *c is a unique copy of *a and *b.
9928    bool unique_copy(my_iterator a, my_iterator b, my_iterator c);
9929    }</pre>
9930</blockquote>
9931<p>User2 is shocked to find later that his fully-qualified use of
9932std::unique(user2::my_iterator, user2::my_iterator, user2::my_iterator) fails to
9933compile (if he's lucky). Looking in the standard, he sees the following Effects
9934clause for unique():</p>
9935<blockquote>
9936  <p>Effects: Eliminates all but the first element from every consecutive group
9937  of equal elements referred to by the iterator i in the range [first, last) for
9938  which the following corresponding conditions hold: *i == *(i - 1) or pred(*i,
9939  *(i - 1)) != false</p>
9940</blockquote>
9941<p>The standard gives user2 absolutely no reason to think he can interfere with
9942std::unique by defining names in namespace user2. His standard library has been
9943built with the template export feature, so he is unable to inspect the
9944implementation. User1 eventually compiles his code with another compiler, and
9945his version of unique_copy silently stops being called. Eventually, he realizes
9946that he was depending on an implementation detail of his library and had no
9947right to expect his unique_copy() to be called portably.</p>
9948<p>On the face of it, and given above scenario, it may seem obvious that the
9949implementation of unique() shown is non-conforming because it uses unique_copy()
9950rather than ::std::unique_copy(). Most standard library implementations,
9951however, seem to disagree with this notion.</p>
9952<p> <i>[Tokyo:&nbsp; Steve Adamczyk from
9953the core working group indicates that "std::" is sufficient;&nbsp;
9954leading "::" qualification is not required because any namespace
9955qualification is sufficient to suppress Koenig lookup.]</i></p>
9956
9957
9958<p><b>Proposed resolution:</b></p>
9959<p>Add a paragraph and a note at the end of 
996017.6.4.4 [global.functions]:</p>
9961<blockquote>
9962
9963<p>Unless otherwise specified, no global or non-member function in the
9964standard library shall use a function from another namespace which is
9965found through <i>argument-dependent name lookup</i> (3.4.2 [basic.lookup.argdep]).</p>
9966
9967<p>[Note: the phrase "unless otherwise specified" is intended to
9968allow Koenig lookup in cases like that of ostream_iterators:<br>
9969
9970<br>
9971  Effects:</p>
9972  <blockquote>
9973<p>*out_stream &lt;&lt; value;<br>
9974      if(delim != 0) *out_stream &lt;&lt; delim;<br>
9975      return (*this);</p>
9976    <p>--end note]</p>
9977  </blockquote>
9978</blockquote>
9979
9980<p><i>[Tokyo: The LWG agrees that this is a defect in the standard, but
9981is as yet unsure if the proposed resolution is the best
9982solution. Furthermore, the LWG believes that the same problem of
9983unqualified library names applies to wording in the standard itself,
9984and has opened issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a> accordingly. Any resolution of
9985issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a> should be coordinated with the resolution of
9986issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a>.]</i></p>
9987
9988
9989<p><i>[Toronto: The LWG is not sure if this is a defect in the
9990standard.  Most LWG members believe that an implementation of
9991<tt>std::unique</tt> like the one quoted in this issue is already
9992illegal, since, under certain circumstances, its semantics are not
9993those specified in the standard.  The standard's description of
9994<tt>unique</tt> does not say that overloading <tt>adjacent_find</tt>
9995should have any effect.]</i></p>
9996
9997
9998<p><i>[Cura�ao: An LWG-subgroup spent an afternoon working on issues
9999225, 226, and 229.  Their conclusion was that the issues should be
10000separated into an LWG portion (Howard's paper, N1387=02-0045), and a
10001EWG portion (Dave will write a proposal). The LWG and EWG had
10002(separate) discussions of this plan the next day.  The proposed
10003resolution for this issue is in accordance with Howard's paper.]</i></p>
10004
10005
10006
10007
10008<p><b>Rationale:</b></p>
10009<p>It could be argued that this proposed isn't strictly necessary,
10010  that the Standard doesn't grant implementors license to write a
10011  standard function that behaves differently than specified in the
10012  Standard just because of an unrelated user-defined name in some
10013  other namespace.  However, this is at worst a clarification.  It is
10014  surely right that algorithsm shouldn't pick up random names, that
10015  user-defined names should have no effect unless otherwise specified.
10016  Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a> deals with the question of when it is
10017  appropriate for the standard to explicitly specify otherwise.</p>
10018
10019
10020
10021
10022
10023<hr>
10024<h3><a name="226"></a>226. User supplied specializations or overloads of namespace std function templates</h3>
10025<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>
10026 <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2000-04-01  <b>Last modified:</b> 2008-09-26</p>
10027<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>
10028<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
10029<p><b>Discussion:</b></p>
10030<p>The issues are:&nbsp;</p>
10031<p>1. How can a 3rd party library implementor (lib1) write a version of a standard
10032algorithm which is specialized to work with his own class template?&nbsp;</p>
10033<p>2. How can another library implementor (lib2) write a generic algorithm which 
10034will take advantage of the specialized algorithm in lib1?</p>
10035<p>This appears to be the only viable answer under current language rules:</p>
10036<blockquote>
10037  <pre>namespace lib1
10038{
10039    // arbitrary-precision numbers using T as a basic unit
10040    template &lt;class T&gt;
10041    class big_num { //...
10042    };
10043    </pre>
10044  <pre>    // defining this in namespace std is illegal (it would be an
10045    // overload), so we hope users will rely on Koenig lookup
10046    template &lt;class T&gt;
10047    void swap(big_int&lt;T&gt;&amp;, big_int&lt;T&gt;&amp;);
10048}</pre>
10049  <pre>#include &lt;algorithm&gt;
10050namespace lib2
10051{
10052    template &lt;class T&gt;
10053    void generic_sort(T* start, T* end)
10054    {
10055            ...
10056        // using-declaration required so we can work on built-in types
10057        using std::swap;
10058        // use Koenig lookup to find specialized algorithm if available
10059        swap(*x, *y);
10060    }
10061}</pre>
10062</blockquote>
10063<p>This answer has some drawbacks. First of all, it makes writing lib2 difficult
10064and somewhat slippery. The implementor needs to remember to write the
10065using-declaration, or generic_sort will fail to compile when T is a built-in
10066type. The second drawback is that the use of this style in lib2 effectively
10067"reserves" names in any namespace which defines types which may
10068eventually be used with lib2. This may seem innocuous at first when applied to
10069names like swap, but consider more ambiguous names like unique_copy() instead.
10070It is easy to imagine the user wanting to define these names differently in his
10071own namespace. A definition with semantics incompatible with the standard
10072library could cause serious problems (see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a>).</p>
10073<p>Why, you may ask, can't we just partially specialize std::swap()? It's
10074because the language doesn't allow for partial specialization of function
10075templates. If you write:</p>
10076<blockquote>
10077  <pre>namespace std
10078{
10079    template &lt;class T&gt;
10080    void swap(lib1::big_int&lt;T&gt;&amp;, lib1::big_int&lt;T&gt;&amp;);
10081}</pre>
10082</blockquote>
10083<p>You have just overloaded std::swap, which is illegal under the current
10084language rules. On the other hand, the following full specialization is legal:</p>
10085<blockquote>
10086  <pre>namespace std
10087{
10088    template &lt;&gt;
10089    void swap(lib1::other_type&amp;, lib1::other_type&amp;);
10090}</pre>
10091</blockquote>
10092
10093<p>This issue reflects concerns raised by the "Namespace issue
10094with specialized swap" thread on comp.lang.c++.moderated. A
10095similar set of concerns was earlier raised on the boost.org mailing
10096list and the ACCU-general mailing list.  Also see library reflector
10097message c++std-lib-7354.</p>
10098
10099<p>
10100J. C. van Winkel points out (in c++std-lib-9565) another unexpected
10101fact: it's impossible to output a container of std::pair's using copy
10102and an ostream_iterator, as long as both pair-members are built-in or
10103std:: types.  That's because a user-defined operator&lt;&lt; for (for
10104example) std::pair&lt;const std::string, int&gt; will not be found:
10105lookup for operator&lt;&lt; will be performed only in namespace std.
10106Opinions differed on whether or not this was a defect, and, if so,
10107whether the defect is that something is wrong with user-defined
10108functionality and std, or whether it's that the standard library does
10109not provide an operator&lt;&lt; for std::pair&lt;&gt;.
10110</p>
10111
10112
10113
10114<p><b>Proposed resolution:</b></p>
10115
10116<p>Adopt the wording proposed in Howard Hinnant's paper
10117  N1523=03-0106, "Proposed Resolution To LWG issues 225, 226, 229".</p>
10118
10119
10120<p><i>[Tokyo: Summary, "There is no conforming way to extend
10121std::swap for user defined templates."&nbsp; The LWG agrees that
10122there is a problem.  Would like more information before
10123proceeding. This may be a core issue.  Core issue 229 has been opened
10124to discuss the core aspects of this problem. It was also noted that
10125submissions regarding this issue have been received from several
10126sources, but too late to be integrated into the issues list.
10127]</i></p>
10128
10129
10130<p><i>[Post-Tokyo: A paper with several proposed resolutions,
10131J16/00-0029==WG21/N1252, "Shades of namespace std functions
10132" by Alan Griffiths, is in the Post-Tokyo mailing. It
10133should be considered a part of this issue.]</i></p>
10134
10135
10136<p><i>[Toronto: Dave Abrahams and Peter Dimov have proposed a
10137resolution that involves core changes: it would add partial
10138specialization of function template.  The Core Working Group is
10139reluctant to add partial specialization of function templates.  It is
10140viewed as a large change, CWG believes that proposal presented leaves
10141some syntactic issues unanswered; if the CWG does add partial
10142specialization of function templates, it wishes to develop its own
10143proposal.  The LWG continues to believe that there is a serious
10144problem: there is no good way for users to force the library to use
10145user specializations of generic standard library functions, and in
10146certain cases (e.g. transcendental functions called by
10147<tt>valarray</tt> and <tt>complex</tt>) this is important.  Koenig
10148lookup isn't adequate, since names within the library must be
10149qualified with <tt>std</tt> (see issue 225), specialization doesn't
10150work (we don't have partial specialization of function templates), and
10151users aren't permitted to add overloads within namespace std.
10152]</i></p>
10153
10154
10155<p><i>[Copenhagen: Discussed at length, with no consensus.  Relevant
10156papers in the pre-Copenhagen mailing: N1289, N1295, N1296.  Discussion
10157focused on four options. (1) Relax restrictions on overloads within
10158namespace std. (2) Mandate that the standard library use unqualified
10159calls for <tt>swap</tt> and possibly other functions.  (3) Introduce
10160helper class templates for <tt>swap</tt> and possibly other functions.
10161(4) Introduce partial specialization of function templates.  Every
10162option had both support and opposition.  Straw poll (first number is
10163support, second is strongly opposed): (1) 6, 4; (2) 6, 7; (3) 3, 8;
10164(4) 4, 4.]</i></p>
10165
10166
10167<p><i>[Redmond: Discussed, again no consensus.  Herb presented an
10168argument that a user who is defining a type <tt>T</tt> with an
10169associated <tt>swap</tt> should not be expected to put that
10170<tt>swap</tt> in namespace std, either by overloading or by partial
10171specialization.  The argument is that <tt>swap</tt> is part of
10172<tt>T</tt>'s interface, and thus should to in the same namespace as
10173<tt>T</tt> and only in that namespace.  If we accept this argument,
10174the consequence is that standard library functions should use
10175unqualified call of <tt>swap</tt>.  (And which other functions? Any?)
10176A small group (Nathan, Howard, Jeremy, Dave, Matt, Walter, Marc) will
10177try to put together a proposal before the next meeting.]</i></p>
10178
10179
10180<p><i>[Cura�ao: An LWG-subgroup spent an afternoon working on issues
10181225, 226, and 229.  Their conclusion was that the issues should be
10182separated into an LWG portion (Howard's paper, N1387=02-0045), and a
10183EWG portion (Dave will write a proposal). The LWG and EWG had
10184(separate) discussions of this plan the next day.  The proposed
10185resolution is the one proposed by Howard.]</i></p>
10186
10187
10188<p><i>[Santa Cruz: the LWG agreed with the general direction of
10189  Howard's paper, N1387.  (Roughly: Koenig lookup is disabled unless
10190  we say otherwise; this issue is about when we do say otherwise.)
10191  However, there were concerns about wording.  Howard will provide new
10192  wording.  Bill and Jeremy will review it.]</i></p>
10193
10194
10195<p><i>[Kona: Howard proposed the new wording.  The LWG accepted his
10196  proposed resolution.]</i></p>
10197
10198
10199
10200
10201<p><b>Rationale:</b></p>
10202<p>Informally: introduce a Swappable concept, and specify that the
10203  value types of the iterators passed to certain standard algorithms
10204  (such as iter_swap, swap_ranges, reverse, rotate, and sort) conform
10205  to that concept.  The Swappable concept will make it clear that
10206  these algorithms use unqualified lookup for the calls
10207  to <tt>swap</tt>.  Also, in 26.6.3.3 [valarray.transcend] paragraph 1,
10208  state that the valarray transcendentals use unqualified lookup.</p>
10209
10210
10211
10212
10213
10214<hr>
10215<h3><a name="227"></a>227. std::swap() should require CopyConstructible or DefaultConstructible arguments</h3>
10216<p><b>Section:</b> 25.3.3 [alg.swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC1">TC1</a>
10217 <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2000-04-09  <b>Last modified:</b> 2008-09-26</p>
10218<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>
10219<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>
10220<p><b>Discussion:</b></p>
10221<p>25.2.2 reads:</p>
10222<blockquote>
10223  <p><tt>  template&lt;class T&gt; void swap(T&amp; a, T&amp; b);</tt><br>
10224  <br>
10225  Requires:    Type T is Assignable (_lib.container.requirements_).<br>
10226  Effects:    Exchanges values stored in two locations.</p>
10227</blockquote>
10228<p>The only reasonable** generic implementation of swap requires construction of a 
10229   new temporary copy of one of its arguments:</p>
10230<blockquote>
10231<pre>template&lt;class T&gt; void swap(T&amp; a, T&amp; b);
10232  {
10233      T tmp(a);
10234      a = b;
10235      b = tmp;
10236  }</pre>
10237</blockquote>
10238<p>But a type which is only Assignable cannot be swapped by this implementation.</p>
10239<p>**Yes, there's also an unreasonable implementation which would require T to be 
10240   DefaultConstructible instead of CopyConstructible. I don't think this is worthy 
10241   of consideration:</p>
10242<blockquote>
10243<pre>template&lt;class T&gt; void swap(T&amp; a, T&amp; b);
10244{
10245    T tmp;
10246    tmp = a;
10247    a = b;
10248    b = tmp;
10249}</pre>
10250</blockquote>
10251
10252
10253<p><b>Proposed resolution:</b></p>
10254<p>Change 25.2.2 paragraph 1 from:</p>
10255<blockquote>
10256<p>  Requires: Type T is Assignable (23.1).</p>
10257</blockquote>
10258<p>to:</p>
10259<blockquote>
10260<p>  Requires: Type T is CopyConstructible (20.1.3) and Assignable (23.1)</p>
10261</blockquote>
10262
10263
10264
10265
10266
10267<hr>
10268<h3><a name="228"></a>228. Incorrect specification of "..._byname" facets</h3>
10269<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>
10270 <b>Submitter:</b> Dietmar K�hl <b>Opened:</b> 2000-04-20  <b>Last modified:</b> 2008-09-26</p>
10271<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>
10272<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
10273<p><b>Discussion:</b></p>
10274<p>The sections 22.4.1.2 [locale.ctype.byname], 22.4.1.5
10275[locale.codecvt.byname],
10276sref ref="22.2.1.6", 22.4.3.2 [locale.numpunct.byname], 22.4.4.2
10277[locale.collate.byname], 22.4.5.4 [locale.time.put.byname], 22.4.6.4
10278[locale.moneypunct.byname], and 22.4.7.2 [locale.messages.byname]
10279overspecify the
10280definitions of the "..._byname" classes by listing a bunch
10281of virtual functions. At the same time, no semantics of these
10282functions are defined. Real implementations do not define these
10283functions because the functional part of the facets is actually
10284implemented in the corresponding base classes and the constructor of
10285the "..._byname" version just provides suitable date used by
10286these implementations. For example, the 'numpunct' methods just return
10287values from a struct. The base class uses a statically initialized
10288struct while the derived version reads the contents of this struct
10289from a table. However, no virtual function is defined in
10290'numpunct_byname'.</p>
10291
10292<p>For most classes this does not impose a problem but specifically
10293for 'ctype' it does: The specialization for 'ctype_byname&lt;char&gt;'
10294is required because otherwise the semantics would change due to the
10295virtual functions defined in the general version for 'ctype_byname':
10296In 'ctype&lt;char&gt;' the method 'do_is()' is not virtual but it is
10297made virtual in both 'ctype&lt;cT&gt;' and 'ctype_byname&lt;cT&gt;'.
10298Thus, a class derived from 'ctype_byname&lt;char&gt;' can tell whether
10299this class is specialized or not under the current specification:
10300Without the specialization, 'do_is()' is virtual while with
10301specialization it is not virtual.</p>
10302
10303
10304<p><b>Proposed resolution:</b></p>
10305<p>&nbsp; Change section 22.2.1.2 (lib.locale.ctype.byname) to become:</p>
10306<pre>     namespace std {
10307       template &lt;class charT&gt;
10308       class ctype_byname : public ctype&lt;charT&gt; {
10309       public:
10310         typedef ctype&lt;charT&gt;::mask mask;
10311         explicit ctype_byname(const char*, size_t refs = 0);
10312       protected:
10313        ~ctype_byname();             //  virtual
10314       };
10315     }</pre>
10316<p>&nbsp; Change section 22.2.1.6 (lib.locale.codecvt.byname) to become:</p>
10317<pre>    namespace std {
10318      template &lt;class internT, class externT, class stateT&gt;
10319      class codecvt_byname : public codecvt&lt;internT, externT, stateT&gt; {
10320      public:
10321       explicit codecvt_byname(const char*, size_t refs = 0);
10322      protected:
10323      ~codecvt_byname();             //  virtual
10324       };
10325     }
10326</pre>
10327<p>&nbsp; Change section 22.2.3.2 (lib.locale.numpunct.byname) to become:</p>
10328<pre>     namespace std {
10329       template &lt;class charT&gt;
10330       class numpunct_byname : public numpunct&lt;charT&gt; {
10331     //  this class is specialized for  char  and  wchar_t.
10332       public:
10333         typedef charT                char_type;
10334         typedef basic_string&lt;charT&gt;  string_type;
10335         explicit numpunct_byname(const char*, size_t refs = 0);
10336       protected:
10337        ~numpunct_byname();          //  virtual
10338       };
10339     }</pre>
10340<p>&nbsp; Change section 22.2.4.2 (lib.locale.collate.byname) to become:</p>
10341<pre>     namespace std {
10342       template &lt;class charT&gt;
10343       class collate_byname : public collate&lt;charT&gt; {
10344       public:
10345         typedef basic_string&lt;charT&gt; string_type;
10346         explicit collate_byname(const char*, size_t refs = 0);
10347       protected:
10348        ~collate_byname();           //  virtual
10349       };
10350     }</pre>
10351<p>&nbsp; Change section 22.2.5.2 (lib.locale.time.get.byname) to become:</p>
10352<pre>     namespace std {
10353       template &lt;class charT, class InputIterator = istreambuf_iterator&lt;charT&gt; &gt;
10354       class time_get_byname : public time_get&lt;charT, InputIterator&gt; {
10355       public:
10356         typedef time_base::dateorder dateorder;
10357         typedef InputIterator        iter_type</pre>
10358<pre>         explicit time_get_byname(const char*, size_t refs = 0);
10359       protected:
10360        ~time_get_byname();          //  virtual
10361       };
10362     }</pre>
10363<p>&nbsp; Change section 22.2.5.4 (lib.locale.time.put.byname) to become:</p>
10364<pre>     namespace std {
10365       template &lt;class charT, class OutputIterator = ostreambuf_iterator&lt;charT&gt; &gt;
10366       class time_put_byname : public time_put&lt;charT, OutputIterator&gt;
10367       {
10368       public:
10369         typedef charT          char_type;
10370         typedef OutputIterator iter_type;</pre>
10371<pre>         explicit time_put_byname(const char*, size_t refs = 0);
10372       protected:
10373        ~time_put_byname();          //  virtual
10374       };
10375     }"</pre>
10376<p>&nbsp; Change section 22.2.6.4 (lib.locale.moneypunct.byname) to become:</p>
10377<pre>     namespace std {
10378       template &lt;class charT, bool Intl = false&gt;
10379       class moneypunct_byname : public moneypunct&lt;charT, Intl&gt; {
10380       public:
10381         typedef money_base::pattern pattern;
10382         typedef basic_string&lt;charT&gt; string_type;</pre>
10383<pre>         explicit moneypunct_byname(const char*, size_t refs = 0);
10384       protected:
10385        ~moneypunct_byname();        //  virtual
10386       };
10387     }</pre>
10388<p>&nbsp; Change section 22.2.7.2 (lib.locale.messages.byname) to become:</p>
10389<pre>     namespace std {
10390       template &lt;class charT&gt;
10391       class messages_byname : public messages&lt;charT&gt; {
10392       public:
10393         typedef messages_base::catalog catalog;
10394         typedef basic_string&lt;charT&gt;    string_type;</pre>
10395<pre>         explicit messages_byname(const char*, size_t refs = 0);
10396       protected:
10397        ~messages_byname();          //  virtual
10398       };
10399     }</pre>
10400<p>Remove section 22.4.1.4 [locale.codecvt] completely (because in
10401this case only those members are defined to be virtual which are
10402defined to be virtual in 'ctype&lt;cT&gt;'.)</p>
10403
10404<p><i>[Post-Tokyo: Dietmar K�hl submitted this issue at the request of
10405the 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>
10406
10407
10408<p><i>[Copenhagen: proposed resolution was revised slightly, to remove
10409three last virtual functions from <tt>messages_byname</tt>.]</i></p>
10410
10411
10412
10413
10414
10415
10416
10417<hr>
10418<h3><a name="229"></a>229. Unqualified references of other library entities</h3>
10419<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>
10420 <b>Submitter:</b> Steve Clamage <b>Opened:</b> 2000-04-19  <b>Last modified:</b> 2008-09-26</p>
10421<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>
10422<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
10423<p><b>Discussion:</b></p>
10424<p>Throughout the library chapters, the descriptions of library entities refer
10425to other library entities without necessarily qualifying the names.</p>
10426
10427<p>For example, section 25.2.2 "Swap" describes the effect of
10428swap_ranges in terms of the unqualified name "swap". This section
10429could reasonably be interpreted to mean that the library must be implemented so
10430as to do a lookup of the unqualified name "swap", allowing users to
10431override any ::std::swap function when Koenig lookup applies.</p>
10432
10433<p>Although it would have been best to use explicit qualification with
10434"::std::" throughout, too many lines in the standard would have to be
10435adjusted to make that change in a Technical Corrigendum.</p>
10436
10437<p>Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#182">182</a>, which addresses qualification of
10438<tt>size_t</tt>, is a special case of this.
10439</p>
10440
10441
10442<p><b>Proposed resolution:</b></p>
10443<p>To section 17.4.1.1 "Library contents" Add the following paragraph:</p>
10444<blockquote>
10445  <p>Whenever a name x defined in the standard library is mentioned, the name x
10446  is assumed to be fully qualified as ::std::x, unless explicitly described
10447  otherwise. For example, if the Effects section for library function F is
10448  described as calling library function G, the function ::std::G is meant.</p>
10449</blockquote>
10450
10451<p><i>[Post-Tokyo: Steve Clamage submitted this issue at the request of
10452the LWG to solve a problem in the standard itself similar to the
10453problem within implementations of library identified by issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a>.  Any resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a> should be
10454coordinated with the resolution of this issue.]</i></p>
10455
10456
10457<p><i>[post-Toronto: Howard is undecided about whether it is
10458appropriate for all standard library function names referred to in
10459other standard library functions to be explicitly qualified by
10460<tt>std</tt>: it is common advice that users should define global
10461functions that operate on their class in the same namespace as the 
10462class, and this requires argument-dependent lookup if those functions
10463are intended to be called by library code.  Several LWG members are
10464concerned that valarray appears to require argument-dependent lookup,
10465but that the wording may not be clear enough to fall under
10466"unless explicitly described otherwise".]</i></p>
10467
10468
10469<p><i>[Cura�ao: An LWG-subgroup spent an afternoon working on issues
10470225, 226, and 229.  Their conclusion was that the issues should be
10471separated into an LWG portion (Howard's paper, N1387=02-0045), and a
10472EWG portion (Dave will write a proposal). The LWG and EWG had
10473(separate) discussions of this plan the next day.  This paper resolves
10474issues 225 and 226.  In light of that resolution, the proposed
10475resolution for the current issue makes sense.]</i></p>
10476
10477
10478
10479
10480
10481
10482
10483<hr>
10484<h3><a name="230"></a>230. Assignable specified without also specifying CopyConstructible</h3>
10485<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>
10486 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2000-04-26  <b>Last modified:</b> 2008-09-26</p>
10487<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>
10488<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>
10489<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
10490<p><b>Discussion:</b></p>
10491<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
10492Assignable was specified without also specifying
10493CopyConstructible. The LWG asked that the standard be searched to
10494determine if the same defect existed elsewhere.</p>
10495
10496<p>There are a number of places (see proposed resolution below) where
10497Assignable is specified without also specifying
10498CopyConstructible. There are also several cases where both are
10499specified. For example, X [rand.req].</p>
10500
10501
10502<p><b>Proposed resolution:</b></p>
10503<p>In  23.2 [container.requirements] table 65 for value_type:
10504change "T is Assignable" to "T is CopyConstructible and
10505Assignable"
10506</p>
10507
10508<p>In 23.2.4 [associative.reqmts] table 69 X::key_type; change
10509"Key is Assignable" to "Key is
10510CopyConstructible and Assignable"<br>
10511</p>
10512
10513<p>In 24.2.2 [output.iterators] paragraph 1, change:
10514</p>
10515<blockquote>
10516<p> A class or a built-in type X satisfies the requirements of an
10517output iterator if X is an Assignable type (23.1) and also the
10518following expressions are valid, as shown in Table 73:
10519</p>
10520</blockquote>
10521<p>to:
10522</p>
10523<blockquote>
10524<p> A class or a built-in type X satisfies the requirements of an
10525output iterator if X is a CopyConstructible (20.1.3) and Assignable
10526type (23.1) and also the following expressions are valid, as shown in
10527Table 73:
10528</p>
10529</blockquote>
10530
10531<p><i>[Post-Tokyo: Beman Dawes submitted this issue at the request of
10532the LWG.  He asks that the 25.3.5 [alg.replace] and 25.3.6 [alg.fill] changes be studied carefully, as it is not clear that
10533CopyConstructible is really a requirement and may be
10534overspecification.]</i></p>
10535
10536
10537<p><i>[Portions of the resolution for issue 230 have been superceded by
10538the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#276">276</a>.]</i></p>
10539
10540
10541
10542
10543<p><b>Rationale:</b></p>
10544<p>The original proposed resolution also included changes to input
10545iterator, fill, and replace.  The LWG believes that those changes are
10546not necessary.  The LWG considered some blanket statement, where an
10547Assignable type was also required to be Copy Constructible, but
10548decided against this because fill and replace really don't require the
10549Copy Constructible property.</p>
10550
10551
10552
10553
10554<hr>
10555<h3><a name="231"></a>231. Precision in iostream?</h3>
10556<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>
10557 <b>Submitter:</b> James Kanze, Stephen Clamage <b>Opened:</b> 2000-04-25  <b>Last modified:</b> 2008-09-26</p>
10558<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#facet.num.put.virtuals">active issues</a> in [facet.num.put.virtuals].</p>
10559<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>
10560<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
10561<p><b>Discussion:</b></p>
10562<p>What is the following program supposed to output?</p>
10563<pre>#include &lt;iostream&gt;
10564
10565    int
10566    main()
10567    {
10568        std::cout.setf( std::ios::scientific , std::ios::floatfield ) ;
10569        std::cout.precision( 0 ) ;
10570        std::cout &lt;&lt; 1.00 &lt;&lt; '\n' ;
10571        return 0 ;
10572    }</pre>
10573<p>From my C experience, I would expect "1e+00"; this is what 
10574<tt>printf("%.0e" , 1.00 );</tt> does. G++ outputs 
10575"1.000000e+00".</p>
10576
10577<p>The only indication I can find in the standard is 22.2.2.2.2/11,
10578where it says "For conversion from a floating-point type, if
10579(flags &amp; fixed) != 0 or if str.precision() &gt; 0, then
10580str.precision() is specified in the conversion specification."
10581This is an obvious error, however, fixed is not a mask for a field,
10582but a value that a multi-bit field may take -- the results of and'ing
10583fmtflags with ios::fixed are not defined, at least not if
10584ios::scientific has been set. G++'s behavior corresponds to what might
10585happen if you do use (flags &amp; fixed) != 0 with a typical
10586implementation (floatfield == 3 &lt;&lt; something, fixed == 1
10587&lt;&lt; something, and scientific == 2 &lt;&lt; something).</p>
10588
10589<p>Presumably, the intent is either (flags &amp; floatfield) != 0, or
10590(flags &amp; floatfield) == fixed; the first gives something more or
10591less like the effect of precision in a printf floating point
10592conversion. Only more or less, of course. In order to implement printf
10593formatting correctly, you must know whether the precision was
10594explicitly set or not. Say by initializing it to -1, instead of 6, and
10595stating that for floating point conversions, if precision &lt; -1, 6
10596will be used, for fixed point, if precision &lt; -1, 1 will be used,
10597etc. Plus, of course, if precision == 0 and flags &amp; floatfield ==
105980, 1 should be = used. But it probably isn't necessary to emulate all
10599of the anomalies of printf:-).</p>
10600
10601
10602<p><b>Proposed resolution:</b></p>
10603<p>
10604Replace 22.4.2.2.2 [facet.num.put.virtuals], paragraph 11, with the following 
10605sentence:
10606</p>
10607<blockquote><p>
10608For conversion from a floating-point type,
10609<tt><i>str</i>.precision()</tt> is specified in the conversion
10610specification.
10611</p></blockquote>
10612
10613
10614<p><b>Rationale:</b></p>
10615<p>The floatfield determines whether numbers are formatted as if
10616with %f, %e, or %g.  If the <tt>fixed</tt> bit is set, it's %f,
10617if <tt>scientific</tt> it's %e, and if both bits are set, or 
10618neither, it's %g.</p>
10619<p>Turning to the C standard, a precision of 0 is meaningful
10620for %f and %e.  For %g, precision 0 is taken to be the same as 
10621precision 1.</p>
10622<p>The proposed resolution has the effect that if neither
10623<tt>fixed</tt> nor <tt>scientific</tt> is set we'll be
10624specifying a precision of 0, which will be internally
10625turned into 1.  There's no need to call it out as a special
10626case.</p>
10627<p>The output of the above program will be "1e+00".</p>
10628
10629<p><i>[Post-Cura�ao: Howard provided improved wording covering the case
10630where precision is 0 and mode is %g.]</i></p>
10631
10632
10633
10634
10635
10636
10637
10638<hr>
10639<h3><a name="232"></a>232. "depends" poorly defined in 17.4.3.1</h3>
10640<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>
10641 <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2000-04-18  <b>Last modified:</b> 2008-09-26</p>
10642<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>
10643<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
10644<p><b>Discussion:</b></p>
10645<p>17.4.3.1/1 uses the term "depends" to limit the set of allowed
10646specializations of standard templates to those that "depend on a
10647user-defined name of external linkage."</p>
10648<p>This term, however, is not adequately defined, making it possible to
10649construct a specialization that is, I believe, technically legal according to
1065017.4.3.1/1, but that specializes a standard template for a built-in type such as
10651'int'.</p>
10652<p>The following code demonstrates the problem:</p>
10653<blockquote>
10654  <pre>#include &lt;algorithm&gt;</pre>
10655  <pre>template&lt;class T&gt; struct X
10656{
10657 typedef T type;
10658};</pre>
10659  <pre>namespace std
10660{
10661 template&lt;&gt; void swap(::X&lt;int&gt;::type&amp; i, ::X&lt;int&gt;::type&amp; j);
10662}</pre>
10663</blockquote>
10664
10665
10666<p><b>Proposed resolution:</b></p>
10667<p>Change "user-defined name" to "user-defined
10668type".</p>
10669
10670
10671<p><b>Rationale:</b></p>
10672<p>This terminology is used in section 2.5.2 and 4.1.1 of <i>The C++
10673Programming Language</i>.  It disallows the example in the issue,
10674since the underlying type itself is not user-defined.  The only
10675possible problem I can see is for non-type templates, but there's no
10676possible way for a user to come up with a specialization for bitset,
10677for example, that might not have already been specialized by the
10678implementor?</p>
10679
10680<p><i>[Toronto: this may be related to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#120">120</a>.]</i></p>
10681
10682
10683<p><i>[post-Toronto: Judy provided the above proposed resolution and
10684rationale.]</i></p>
10685
10686
10687
10688
10689
10690
10691<hr>
10692<h3><a name="233"></a>233. Insertion hints in associative containers</h3>
10693<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>
10694 <b>Submitter:</b> Andrew Koenig <b>Opened:</b> 2000-04-30  <b>Last modified:</b> 2008-09-26</p>
10695<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>
10696<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>
10697<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
10698<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>
10699<p><b>Discussion:</b></p>
10700<p>
10701If <tt>mm</tt> is a multimap and <tt>p</tt> is an iterator
10702into the multimap, then <tt>mm.insert(p, x)</tt> inserts
10703<tt>x</tt> into <tt>mm</tt> with <tt>p</tt> as a hint as
10704to where it should go.  Table 69 claims that the execution time is
10705amortized constant if the insert winds up taking place adjacent to
10706<tt>p</tt>, but does not say when, if ever, this is guaranteed to
10707happen.  All it says it that <tt>p</tt> is a hint as to where to
10708insert.
10709</p>
10710<p>
10711The question is whether there is any guarantee about the relationship
10712between <tt>p</tt> and the insertion point, and, if so, what it
10713is.
10714</p>
10715<p>
10716I believe the present state is that there is no guarantee: The user
10717can supply <tt>p</tt>, and the implementation is allowed to
10718disregard it entirely.
10719</p>
10720
10721<p><b>Additional comments from Nathan:</b><br>
10722
10723The vote [in Redmond] was on whether to elaborately specify the use of
10724the hint, or to require behavior only if the value could be inserted
10725adjacent to the hint.  I would like to ensure that we have a chance to
10726vote for a deterministic treatment: "before, if possible, otherwise
10727after, otherwise anywhere appropriate", as an alternative to the
10728proposed "before or after, if possible, otherwise [...]".
10729</p>
10730
10731<p><i>[Toronto: there was general agreement that this is a real defect:
10732when inserting an element x into a multiset that already contains
10733several copies of x, there is no way to know whether the hint will be
10734used.  The proposed resolution was that the new element should always
10735be inserted as close to the hint as possible.  So, for example, if
10736there is a subsequence of equivalent values, then providing a.begin()
10737as the hint means that the new element should be inserted before the
10738subsequence even if a.begin() is far away.  JC van Winkel supplied
10739precise wording for this proposed resolution, and also for an
10740alternative resolution in which hints are only used when they are
10741adjacent to the insertion point.]</i></p>
10742
10743
10744<p><i>[Copenhagen: the LWG agreed to the original proposed resolution,
10745in which an insertion hint would be used even when it is far from the
10746insertion point.  This was contingent on seeing a example
10747implementation showing that it is possible to implement this
10748requirement without loss of efficiency.  John Potter provided such a
10749example implementation.]</i></p>
10750
10751
10752<p><i>[Redmond: The LWG was reluctant to adopt the proposal that
10753emerged from Copenhagen: it seemed excessively complicated, and went
10754beyond fixing the defect that we identified in Toronto.  PJP provided
10755the new wording described in this issue.  Nathan agrees that we
10756shouldn't adopt the more detailed semantics, and notes: "we know that
10757you can do it efficiently enough with a red-black tree, but there are
10758other (perhaps better) balanced tree techniques that might differ
10759enough to make the detailed semantics hard to satisfy."]</i></p>
10760
10761
10762<p><i>[Cura�ao: Nathan should give us the alternative wording he
10763suggests so the LWG can decide between the two options.]</i></p>
10764
10765
10766<p><i>[Lillehammer: The LWG previously rejected the more detailed
10767  semantics, because it seemed more loike a new feature than like
10768  defect fixing.  We're now more sympathetic to it, but we (especially
10769  Bill) are still worried about performance.  N1780 describes a naive
10770  algorithm, but it's not clear whether there is a non-naive
10771  implementation. Is it possible to implement this as efficently as
10772  the current version of insert?]</i></p>
10773
10774
10775<p><i>[Post Lillehammer:
10776<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1780.html">N1780</a>
10777updated in post meeting mailing with
10778feedback from Lillehammer with more information regarding performance.
10779]</i></p>
10780
10781
10782<p><i>[
10783Batavia:
10784<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1780.html">1780</a>
10785accepted with minor wording changes in the proposed wording (reflected in the
10786proposed resolution below).  Concerns about the performance of the algorithm
10787were satisfactorily met by
10788<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1780.html">1780</a>.
10789<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#371">371</a> already handles the stability of equal ranges
10790and so that part of the resolution from
10791<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1780.html">1780</a>
10792is no longer needed (or reflected in the proposed wording below).
10793]</i></p>
10794
10795
10796
10797
10798<p><b>Proposed resolution:</b></p>
10799
10800<p>
10801Change the indicated rows of the "Associative container requirements" Table in
1080223.2.4 [associative.reqmts] to:
10803</p>
10804
10805<p></p><center>
10806<table border="1">
10807<caption>Associative container requirements</caption>
10808<tbody><tr><th>expression</th> <th>return type</th>
10809<th>assertion/note<br>pre/post-condition</th>
10810<th>complexity</th></tr>
10811<tr><td><tt>a_eq.insert(t)</tt></td>
10812<td><tt>iterator</tt></td>
10813<td>
10814inserts <tt>t</tt> and returns the iterator pointing to the newly inserted
10815element. <ins>If a range containing elements equivalent to <tt>t</tt> exists in
10816<tt>a_eq</tt>, <tt>t</tt> is inserted at the end of that range.</ins>
10817</td>
10818<td>
10819logarithmic
10820</td></tr>
10821<tr><td><tt>a.insert(p,t)</tt></td>
10822<td><tt>iterator</tt></td>
10823<td>
10824inserts <tt>t</tt> if and only if there is no element with key equivalent to the
10825key of <tt>t</tt> in containers with unique keys; always inserts <tt>t</tt> in containers
10826with equivalent keys. always returns the iterator pointing to the element with key
10827equivalent to the key of <tt>t</tt>. <del>iterator <tt>p</tt> is a hint pointing to where
10828the insert should start to search.</del> <ins><tt>t</tt> is inserted as close as possible
10829to the position just prior to <tt>p</tt>.</ins>
10830</td>
10831<td>
10832logarithmic in general, but amortized constant if <tt>t</tt> is inserted right <del>after</del>
10833 <ins>before</ins> <tt>p</tt>.
10834</td></tr>
10835</tbody></table>
10836</center>
10837
10838
10839
10840
10841
10842
10843<hr>
10844<h3><a name="234"></a>234. Typos in allocator definition</h3>
10845<p><b>Section:</b> 20.8.8.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
10846 <b>Submitter:</b> Dietmar K�hl <b>Opened:</b> 2000-04-24  <b>Last modified:</b> 2008-09-26</p>
10847<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>
10848<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
10849<p><b>Discussion:</b></p>
10850<p>In paragraphs 12 and 13 the effects of <tt>construct()</tt> and
10851<tt>destruct()</tt> are described as returns but the functions actually
10852return <tt>void</tt>.</p>
10853
10854
10855<p><b>Proposed resolution:</b></p>
10856<p>Substitute "Returns" by "Effect".</p>
10857
10858
10859
10860
10861<hr>
10862<h3><a name="235"></a>235. No specification of default ctor for reverse_iterator</h3>
10863<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>
10864 <b>Submitter:</b> Dietmar K�hl <b>Opened:</b> 2000-04-24  <b>Last modified:</b> 2008-09-26</p>
10865<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
10866<p><b>Discussion:</b></p>
10867<p>The declaration of <tt>reverse_iterator</tt> lists a default
10868constructor.  However, no specification is given what this constructor
10869should do.</p>
10870
10871
10872<p><b>Proposed resolution:</b></p>
10873  <p>In section 24.5.1.3.1 [reverse.iter.cons] add the following
10874  paragraph:</p>
10875      <blockquote>
10876      <p><tt>reverse_iterator()</tt></p>
10877
10878      <p>Default initializes <tt>current</tt>. Iterator operations
10879      applied to the resulting iterator have defined behavior if and
10880      only if the corresponding operations are defined on a default
10881      constructed iterator of type <tt>Iterator</tt>.</p>
10882      </blockquote>
10883  <p><i>[pre-Copenhagen: Dietmar provide wording for proposed
10884  resolution.]</i></p>
10885
10886
10887
10888
10889
10890
10891<hr>
10892<h3><a name="237"></a>237. Undefined expression in complexity specification</h3>
10893<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>
10894 <b>Submitter:</b> Dietmar K�hl <b>Opened:</b> 2000-04-24  <b>Last modified:</b> 2008-09-26</p>
10895<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>
10896<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
10897<p><b>Discussion:</b></p>
10898<p>The complexity specification in paragraph 6 says that the complexity
10899is linear in <tt>first - last</tt>. Even if <tt>operator-()</tt> is
10900defined on iterators this term is in general undefined because it
10901would have to be <tt>last - first</tt>.</p>
10902
10903
10904<p><b>Proposed resolution:</b></p>
10905  <p>Change paragraph 6 from</p>
10906     <blockquote><p>Linear in <i>first - last</i>.</p></blockquote>
10907  <p>to become</p>
10908     <blockquote><p>Linear in <i>distance(first, last)</i>.</p></blockquote>
10909
10910
10911
10912
10913<hr>
10914<h3><a name="238"></a>238. Contradictory results of stringbuf initialization.</h3>
10915<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>
10916 <b>Submitter:</b> Dietmar K�hl <b>Opened:</b> 2000-05-11  <b>Last modified:</b> 2008-09-26</p>
10917<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#stringbuf.cons">issues</a> in [stringbuf.cons].</p>
10918<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
10919<p><b>Discussion:</b></p>
10920<p>In 27.7.1.1 paragraph 4 the results of calling the constructor of
10921'basic_stringbuf' are said to be <tt>str() == str</tt>. This is fine
10922that far but consider this code:</p>
10923
10924<pre>  std::basic_stringbuf&lt;char&gt; sbuf("hello, world", std::ios_base::openmode(0));
10925  std::cout &lt;&lt; "'" &lt;&lt; sbuf.str() &lt;&lt; "'\n";
10926</pre>
10927
10928<p>Paragraph 3 of 27.7.1.1 basically says that in this case neither
10929the output sequence nor the input sequence is initialized and
10930paragraph 2 of 27.7.1.2 basically says that <tt>str()</tt> either
10931returns the input or the output sequence. None of them is initialized,
10932ie. both are empty, in which case the return from <tt>str()</tt> is
10933defined to be <tt>basic_string&lt;cT&gt;()</tt>.</p>
10934
10935<p>However, probably only test cases in some testsuites will detect this
10936"problem"...</p>
10937
10938
10939<p><b>Proposed resolution:</b></p>
10940<p>Remove 27.7.1.1 paragraph 4.</p>
10941
10942
10943<p><b>Rationale:</b></p>
10944<p>We could fix 27.7.1.1 paragraph 4, but there would be no point.  If
10945we fixed it, it would say just the same thing as text that's already
10946in the standard.</p>
10947
10948
10949
10950
10951<hr>
10952<h3><a name="239"></a>239. Complexity of unique() and/or unique_copy incorrect</h3>
10953<p><b>Section:</b> 25.3.9 [alg.unique] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
10954 <b>Submitter:</b> Angelika Langer <b>Opened:</b> 2000-05-15  <b>Last modified:</b> 2008-09-26</p>
10955<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>
10956<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
10957<p><b>Discussion:</b></p>
10958<p>The complexity of unique and unique_copy are inconsistent with each
10959other and inconsistent with the implementations.&nbsp; The standard
10960specifies:</p>
10961
10962<p>for unique():</p>
10963
10964<blockquote><p>-3- Complexity: If the range (last - first) is not empty, exactly
10965(last - first) - 1 applications of the corresponding predicate, otherwise
10966no applications of the predicate.</p></blockquote>
10967
10968<p>for unique_copy():</p>
10969
10970<blockquote><p>-7- Complexity: Exactly last - first applications of the corresponding
10971predicate.</p></blockquote>
10972
10973<p>
10974The implementations do it the other way round: unique() applies the
10975predicate last-first times and unique_copy() applies it last-first-1
10976times.</p>
10977
10978<p>As both algorithms use the predicate for pair-wise comparison of
10979sequence elements I don't see a justification for unique_copy()
10980applying the predicate last-first times, especially since it is not
10981specified to which pair in the sequence the predicate is applied
10982twice.</p>
10983
10984
10985<p><b>Proposed resolution:</b></p>
10986<p>Change both complexity sections in 25.3.9 [alg.unique] to:</p>
10987
10988<blockquote><p>Complexity: For nonempty ranges, exactly last - first - 1
10989applications of the corresponding predicate.</p></blockquote>
10990
10991
10992
10993
10994
10995
10996<hr>
10997<h3><a name="240"></a>240. Complexity of adjacent_find() is meaningless</h3>
10998<p><b>Section:</b> 25.2.8 [alg.adjacent.find] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
10999 <b>Submitter:</b> Angelika Langer <b>Opened:</b> 2000-05-15  <b>Last modified:</b> 2008-09-26</p>
11000<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>
11001<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
11002<p><b>Discussion:</b></p>
11003<p>The complexity section of adjacent_find is defective:</p>
11004
11005<blockquote>
11006<pre>template &lt;class ForwardIterator&gt;
11007ForwardIterator adjacent_find(ForwardIterator first, ForwardIterator last
11008                              BinaryPredicate pred);
11009</pre>
11010
11011<p>-1- Returns: The first iterator i such that both i and i + 1 are in
11012the range [first, last) for which the following corresponding
11013conditions hold: *i == *(i + 1), pred(*i, *(i + 1)) != false. Returns
11014last if no such iterator is found.</p>
11015
11016<p>-2- Complexity: Exactly find(first, last, value) - first applications
11017of the corresponding predicate.
11018</p>
11019</blockquote>
11020
11021<p>In the Complexity section, it is not defined what "value"
11022is supposed to mean. My best guess is that "value" means an
11023object for which one of the conditions pred(*i,value) or
11024pred(value,*i) is true, where i is the iterator defined in the Returns
11025section. However, the value type of the input sequence need not be
11026equality-comparable and for this reason the term find(first, last,
11027value) - first is meaningless.</p>
11028
11029<p>A term such as find_if(first, last, bind2nd(pred,*i)) - first or
11030find_if(first, last, bind1st(pred,*i)) - first might come closer to
11031the intended specification.  Binders can only be applied to function
11032objects that have the function call operator declared const, which is
11033not required of predicates because they can have non-const data
11034members. For this reason, a specification using a binder could only be
11035an "as-if" specification.</p>
11036
11037
11038<p><b>Proposed resolution:</b></p>
11039<p>Change the complexity section in 25.2.8 [alg.adjacent.find] to:</p>
11040<blockquote><p>
11041For a nonempty range, exactly <tt>min((<i>i</i> - <i>first</i>) + 1,
11042(<i>last</i> - <i>first</i>) - 1)</tt> applications of the
11043corresponding predicate, where <i>i</i> is <tt>adjacent_find</tt>'s
11044return value.
11045</p></blockquote>
11046
11047<p><i>[Copenhagen: the original resolution specified an upper
11048bound.  The LWG preferred an exact count.]</i></p>
11049
11050
11051
11052
11053
11054
11055
11056<hr>
11057<h3><a name="241"></a>241. Does unique_copy() require CopyConstructible and Assignable?</h3>
11058<p><b>Section:</b> 25.3.9 [alg.unique] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
11059 <b>Submitter:</b> Angelika Langer <b>Opened:</b> 2000-05-15  <b>Last modified:</b> 2008-09-26</p>
11060<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>
11061<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
11062<p><b>Discussion:</b></p>
11063
11064<p>Some popular implementations of unique_copy() create temporary
11065copies of values in the input sequence, at least if the input iterator
11066is a pointer.  Such an implementation is built on the assumption that
11067the value type is CopyConstructible and Assignable.</p>
11068
11069<p>It is common practice in the standard that algorithms explicitly
11070specify any additional requirements that they impose on any of the
11071types used by the algorithm. An example of an algorithm that creates
11072temporary copies and correctly specifies the additional requirements
11073is accumulate(), X [rand.req].</p>
11074
11075<p>Since the specifications of unique() and unique_copy() do not
11076require CopyConstructible and Assignable of the InputIterator's value
11077type the above mentioned implementations are not standard-compliant. I
11078cannot judge whether this is a defect in the standard or a defect in
11079the implementations.</p>
11080
11081
11082<p><b>Proposed resolution:</b></p>
11083<p>In 25.2.8 change:</p>
11084
11085<blockquote><p>
11086-4- Requires: The ranges [first, last) and [result, result+(last-first))
11087shall not overlap.
11088</p></blockquote>
11089
11090<p>to:</p>
11091
11092<blockquote>
11093  <p>-4- Requires: The ranges [first, last) and [result,
11094  result+(last-first)) shall not overlap. The expression *result =
11095  *first must be valid. If neither InputIterator nor OutputIterator
11096  meets the requirements of forward iterator then the value type of
11097  InputIterator must be copy constructible. Otherwise copy
11098  constructible is not required. </p>
11099</blockquote>
11100
11101<p><i>[Redmond: the original proposed resolution didn't impose an
11102explicit requirement that the iterator's value type must be copy
11103constructible, on the grounds that an input iterator's value type must
11104always be copy constructible.  Not everyone in the LWG thought that
11105this requirement was clear from table 72.  It has been suggested that
11106it might be possible to implement <tt>unique_copy</tt> without
11107requiring assignability, although current implementations do impose
11108that requirement.  Howard provided new wording.]</i></p>
11109
11110
11111<p><i>[
11112Cura�ao: The LWG changed the PR editorially to specify
11113"neither...nor...meet..." as clearer than
11114"both...and...do not meet...". Change believed to be so
11115minor as not to require re-review.
11116]</i></p>
11117
11118
11119
11120
11121
11122
11123
11124
11125<hr>
11126<h3><a name="242"></a>242. Side effects of function objects</h3>
11127<p><b>Section:</b> 25.3.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>
11128 <b>Submitter:</b> Angelika Langer <b>Opened:</b> 2000-05-15  <b>Last modified:</b> 2008-09-26</p>
11129<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>
11130<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
11131<p><b>Discussion:</b></p>
11132<p>The algorithms transform(), accumulate(), inner_product(),
11133partial_sum(), and adjacent_difference() require that the function
11134object supplied to them shall not have any side effects.</p>
11135
11136<p>The standard defines a side effect in 1.9 [intro.execution] as:</p>
11137<blockquote><p>-7- Accessing an object designated by a volatile lvalue (basic.lval),
11138modifying an object, calling a library I/O function, or calling a function
11139that does any of those operations are all side effects, which are changes
11140in the state of the execution environment.</p></blockquote>
11141
11142<p>As a consequence, the function call operator of a function object supplied
11143to any of the algorithms listed above cannot modify data members, cannot
11144invoke any function that has a side effect, and cannot even create and
11145modify temporary objects.&nbsp; It is difficult to imagine a function object
11146that is still useful under these severe limitations. For instance, any
11147non-trivial transformator supplied to transform() might involve creation
11148and modification of temporaries, which is prohibited according to the current
11149wording of the standard.</p>
11150
11151<p>On the other hand, popular implementations of these algorithms exhibit
11152uniform and predictable behavior when invoked with a side-effect-producing
11153function objects. It looks like the strong requirement is not needed for
11154efficient implementation of these algorithms.</p>
11155
11156<p>The requirement of&nbsp; side-effect-free function objects could be
11157replaced by a more relaxed basic requirement (which would hold for all
11158function objects supplied to any algorithm in the standard library):</p>
11159<blockquote><p>A function objects supplied to an algorithm shall not invalidate
11160any iterator or sequence that is used by the algorithm. Invalidation of
11161the sequence includes destruction of the sorting order if the algorithm
11162relies on the sorting order (see section 25.3 - Sorting and related operations
11163[lib.alg.sorting]).</p></blockquote>
11164
11165<p>I can't judge whether it is intended that the function objects supplied
11166to transform(), accumulate(), inner_product(), partial_sum(), or adjacent_difference()
11167shall not modify sequence elements through dereferenced iterators.</p>
11168
11169<p>It is debatable whether this issue is a defect or a change request.
11170Since the consequences for user-supplied function objects are drastic and
11171limit the usefulness of the algorithms significantly I would consider it
11172a defect.</p>
11173
11174
11175<p><b>Proposed resolution:</b></p>
11176
11177<p><i>Things to notice about these changes:</i></p>
11178
11179<ol>
11180<li> <i>The fully-closed ("[]" as opposed to half-closed "[)" ranges
11181     are intentional. we want to prevent side-effects from
11182     invalidating the end iterators.</i></li>
11183
11184<li> <i>That has the unintentional side-effect of prohibiting
11185     modification of the end element as a side-effect. This could
11186     conceivably be significant in some cases.</i></li>
11187
11188<li> <i>The wording also prevents side-effects from modifying elements
11189     of the output sequence. I can't imagine why anyone would want
11190     to do this, but it is arguably a restriction that implementors
11191     don't need to place on users.</i></li>
11192
11193<li> <i>Lifting the restrictions imposed in #2 and #3 above is possible
11194     and simple, but would require more verbiage.</i></li>
11195</ol>
11196
11197<p>Change 25.2.3/2 from:</p>
11198
11199<blockquote><p>
11200   -2- Requires: op and binary_op shall not have any side effects.
11201</p></blockquote>
11202
11203<p>to:</p>
11204
11205<blockquote><p>
11206  -2- Requires: in the ranges [first1, last1], [first2, first2 +
11207  (last1 - first1)] and [result, result + (last1- first1)], op and
11208  binary_op shall neither modify elements nor invalidate iterators or
11209  subranges.
11210  [Footnote: The use of fully closed ranges is intentional --end footnote]
11211</p></blockquote>
11212
11213
11214<p>Change 25.2.3/2 from:</p>
11215
11216<blockquote><p>
11217   -2- Requires: op and binary_op shall not have any side effects. 
11218</p></blockquote>
11219
11220<p>to:</p>
11221
11222<blockquote><p>
11223  -2- Requires: op and binary_op shall not invalidate iterators or
11224   subranges, or modify elements in the ranges [first1, last1],
11225   [first2, first2 + (last1 - first1)], and [result, result + (last1
11226   - first1)].
11227  [Footnote: The use of fully closed ranges is intentional --end footnote]
11228</p></blockquote>
11229
11230
11231<p>Change 26.4.1/2 from:</p>
11232
11233<blockquote><p>
11234  -2- Requires: T must meet the requirements of CopyConstructible
11235   (lib.copyconstructible) and Assignable (lib.container.requirements)
11236   types. binary_op shall not cause side effects.
11237</p></blockquote>
11238
11239<p>to:</p>
11240
11241<blockquote><p>
11242  -2- Requires: T must meet the requirements of CopyConstructible
11243   (lib.copyconstructible) and Assignable
11244   (lib.container.requirements) types. In the range [first, last],
11245   binary_op shall neither modify elements nor invalidate iterators
11246   or subranges.
11247  [Footnote: The use of a fully closed range is intentional --end footnote]
11248</p></blockquote>
11249
11250<p>Change 26.4.2/2 from:</p>
11251
11252<blockquote><p>
11253  -2- Requires: T must meet the requirements of CopyConstructible
11254   (lib.copyconstructible) and Assignable (lib.container.requirements)
11255   types. binary_op1 and binary_op2 shall not cause side effects.
11256</p></blockquote>
11257
11258<p>to:</p>
11259
11260<blockquote><p>
11261  -2- Requires: T must meet the requirements of CopyConstructible
11262   (lib.copyconstructible) and Assignable (lib.container.requirements)
11263   types. In the ranges [first, last] and [first2, first2 + (last -
11264   first)], binary_op1 and binary_op2 shall neither modify elements
11265   nor invalidate iterators or subranges.
11266  [Footnote: The use of fully closed ranges is intentional --end footnote]
11267</p></blockquote>
11268
11269
11270<p>Change 26.4.3/4 from:</p>
11271
11272<blockquote><p>
11273  -4- Requires: binary_op is expected not to have any side effects.
11274</p></blockquote>
11275
11276<p>to:</p>
11277
11278<blockquote><p>
11279  -4- Requires: In the ranges [first, last] and [result, result +
11280   (last - first)], binary_op shall neither modify elements nor
11281   invalidate iterators or subranges.
11282  [Footnote: The use of fully closed ranges is intentional --end footnote]
11283</p></blockquote>
11284
11285<p>Change 26.4.4/2 from:</p>
11286
11287<blockquote><p>
11288  -2- Requires: binary_op shall not have any side effects.
11289</p></blockquote>
11290
11291<p>to:</p>
11292
11293<blockquote><p>
11294  -2- Requires: In the ranges [first, last] and [result, result +
11295   (last - first)], binary_op shall neither modify elements nor
11296   invalidate iterators or subranges.
11297  [Footnote: The use of fully closed ranges is intentional --end footnote]
11298</p></blockquote>
11299
11300<p><i>[Toronto: Dave Abrahams supplied wording.]</i></p>
11301
11302
11303<p><i>[Copenhagen: Proposed resolution was modified slightly. Matt
11304added footnotes pointing out that the use of closed ranges was
11305intentional.]</i></p>
11306
11307
11308
11309
11310
11311
11312
11313<hr>
11314<h3><a name="243"></a>243. <tt>get</tt> and <tt>getline</tt> when sentry reports failure</h3>
11315<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>
11316 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-05-15  <b>Last modified:</b> 2008-09-26</p>
11317<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>
11318<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
11319<p><b>Discussion:</b></p>
11320<p>basic_istream&lt;&gt;::get(), and basic_istream&lt;&gt;::getline(),
11321are unclear with respect to the behavior and side-effects of the named
11322functions in case of an error.</p>
11323
11324<p>27.6.1.3, p1 states that "... If the sentry object returns
11325true, when converted to a value of type bool, the function endeavors
11326to obtain the requested input..." It is not clear from this (or
11327the rest of the paragraph) what precisely the behavior should be when
11328the sentry ctor exits by throwing an exception or when the sentry
11329object returns false.  In particular, what is the number of characters
11330extracted that gcount() returns supposed to be?</p>
11331
11332<p>27.6.1.3 p8 and p19 say about the effects of get() and getline():
11333"...  In any case, it then stores a null character (using
11334charT()) into the next successive location of the array." Is not
11335clear whether this sentence applies if either of the conditions above
11336holds (i.e., when sentry fails).</p>
11337
11338
11339<p><b>Proposed resolution:</b></p>
11340<p>Add to 27.6.1.3, p1 after the sentence</p>
11341
11342<blockquote><p>
11343"... If the sentry object returns true, when converted to a value of
11344type bool, the function endeavors to obtain the requested input."
11345</p></blockquote>
11346
11347<p>the following</p>
11348
11349
11350<blockquote><p>
11351"Otherwise, if the sentry constructor exits by throwing an exception or
11352if the sentry object returns false, when converted to a value of type
11353bool, the function returns without attempting to obtain any input. In
11354either case the number of extracted characters is set to 0; unformatted
11355input functions taking a character array of non-zero size as an argument
11356shall also store a null character (using charT()) in the first location
11357of the array."
11358</p></blockquote>
11359
11360
11361<p><b>Rationale:</b></p>
11362<p>Although the general philosophy of the input functions is that the
11363argument should not be modified upon failure, <tt>getline</tt>
11364historically added a terminating null unconditionally.  Most
11365implementations still do that.  Earlier versions of the draft standard
11366had language that made this an unambiguous requirement; those words
11367were moved to a place where their context made them less clear.  See
11368Jerry Schwarz's message c++std-lib-7618.</p>
11369
11370
11371
11372
11373<hr>
11374<h3><a name="247"></a>247. <tt>vector</tt>, <tt>deque::insert</tt> complexity</h3>
11375<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>
11376 <b>Submitter:</b> Lisa Lippincott <b>Opened:</b> 2000-06-06  <b>Last modified:</b> 2008-09-26</p>
11377<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>
11378<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
11379<p><b>Discussion:</b></p>
11380<p>Paragraph 2 of 23.3.6.4 [vector.modifiers] describes the complexity
11381of <tt>vector::insert</tt>:</p>
11382
11383   <blockquote><p>
11384   Complexity: If first and last are forward iterators, bidirectional
11385   iterators, or random access iterators, the complexity is linear in
11386   the number of elements in the range [first, last) plus the distance
11387   to the end of the vector. If they are input iterators, the complexity
11388   is proportional to the number of elements in the range [first, last)
11389   times the distance to the end of the vector.
11390   </p></blockquote>
11391
11392<p>First, this fails to address the non-iterator forms of
11393<tt>insert</tt>.</p>
11394
11395<p>Second, the complexity for input iterators misses an edge case --
11396it requires that an arbitrary number of elements can be added at
11397the end of a <tt>vector</tt> in constant time.</p>
11398
11399<p>I looked to see if <tt>deque</tt> had a similar problem, and was
11400surprised to find that <tt>deque</tt> places no requirement on the
11401complexity of inserting multiple elements (23.3.2.3 [deque.modifiers],
11402paragraph 3):</p>
11403
11404   <blockquote><p>
11405   Complexity: In the worst case, inserting a single element into a
11406   deque takes time linear in the minimum of the distance from the
11407   insertion point to the beginning of the deque and the distance
11408   from the insertion point to the end of the deque. Inserting a
11409   single element either at the beginning or end of a deque always
11410   takes constant time and causes a single call to the copy constructor
11411   of T.
11412   </p></blockquote>
11413
11414
11415<p><b>Proposed resolution:</b></p>
11416
11417<p>Change Paragraph 2 of 23.3.6.4 [vector.modifiers] to</p>
11418   <blockquote><p>
11419   Complexity: The complexity is linear in the number of elements 
11420   inserted plus the distance to the end of the vector.
11421   </p></blockquote>
11422
11423   <p><i>[For input iterators, one may achieve this complexity by first
11424   inserting at the end of the <tt>vector</tt>, and then using
11425   <tt>rotate</tt>.]</i></p>
11426
11427
11428<p>Change 23.3.2.3 [deque.modifiers], paragraph 3, to:</p>
11429
11430   <blockquote><p>
11431   Complexity: The complexity is linear in the number of elements 
11432   inserted plus the shorter of the distances to the beginning and
11433   end of the deque.  Inserting a single element at either the
11434   beginning or the end of a deque causes a single call to the copy
11435   constructor of T.
11436   </p></blockquote>
11437
11438
11439
11440<p><b>Rationale:</b></p>
11441<p>This is a real defect, and proposed resolution fixes it: some
11442  complexities aren't specified that should be.  This proposed
11443  resolution does constrain deque implementations (it rules out the
11444  most naive possible implementations), but the LWG doesn't see a
11445  reason to permit that implementation.</p>
11446
11447
11448
11449
11450
11451<hr>
11452<h3><a name="248"></a>248. time_get fails to set eofbit</h3>
11453<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>
11454 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-06-22  <b>Last modified:</b> 2008-09-26</p>
11455<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
11456<p><b>Discussion:</b></p>
11457<p>There is no requirement that any of time_get member functions set
11458ios::eofbit when they reach the end iterator while parsing their input.
11459Since members of both the num_get and money_get facets are required to
11460do so (22.2.2.1.2, and 22.2.6.1.2, respectively), time_get members
11461should follow the same requirement for consistency.</p>
11462
11463
11464<p><b>Proposed resolution:</b></p>
11465<p>Add paragraph 2 to section 22.2.5.1 with the following text:</p>
11466
11467<blockquote><p>
11468If the end iterator is reached during parsing by any of the get()
11469member functions, the member sets ios_base::eofbit in err.
11470</p></blockquote>
11471
11472
11473<p><b>Rationale:</b></p>
11474<p>Two alternative resolutions were proposed.  The LWG chose this one
11475because it was more consistent with the way eof is described for other
11476input facets.</p>
11477
11478
11479
11480
11481<hr>
11482<h3><a name="250"></a>250. splicing invalidates iterators</h3>
11483<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>
11484 <b>Submitter:</b> Brian Parker  <b>Opened:</b> 2000-07-14  <b>Last modified:</b> 2008-09-26</p>
11485<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#list.ops">active issues</a> in [list.ops].</p>
11486<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>
11487<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
11488<p><b>Discussion:</b></p>
11489<p>
11490Section 23.3.4.4 [list.ops] states that
11491</p>
11492<pre>  void splice(iterator position, list&lt;T, Allocator&gt;&amp; x);
11493</pre>
11494<p>
11495<i>invalidates</i> all iterators and references to list <tt>x</tt>.
11496</p>
11497
11498<p>
11499This is unnecessary and defeats an important feature of splice. In
11500fact, the SGI STL guarantees that iterators to <tt>x</tt> remain valid
11501after <tt>splice</tt>.
11502</p>
11503
11504
11505<p><b>Proposed resolution:</b></p>
11506
11507<p>Add a footnote to 23.3.4.4 [list.ops], paragraph 1:</p>
11508<blockquote><p>
11509[<i>Footnote:</i> As specified in  [default.con.req], paragraphs
115104-5, the semantics described in this clause applies only to the case
11511where allocators compare equal.  --end footnote]
11512</p></blockquote>
11513
11514<p>In 23.3.4.4 [list.ops], replace paragraph 4 with:</p>
11515<blockquote><p>
11516Effects: Inserts the contents of x before position and x becomes 
11517empty.  Pointers and references to the moved elements of x now refer to 
11518those same elements but as members of *this.  Iterators referring to the 
11519moved elements will continue to refer to their elements, but they now 
11520behave as iterators into *this, not into x.
11521</p></blockquote>
11522
11523<p>In 23.3.4.4 [list.ops], replace paragraph 7 with:</p>
11524<blockquote><p>
11525Effects: Inserts an element pointed to by i from list x before 
11526position and removes the element from x. The result is unchanged if 
11527position == i or position == ++i.  Pointers and references to *i continue 
11528to refer to this same element but as a member of *this.  Iterators to *i 
11529(including i itself) continue to refer to the same element, but now 
11530behave as iterators into *this, not into x.
11531</p></blockquote>
11532
11533<p>In 23.3.4.4 [list.ops], replace paragraph 12 with:</p>
11534<blockquote><p>
11535Requires: [first, last) is a valid range in x. The result is 
11536undefined if position is an iterator in the range [first, last).  
11537Pointers and references to the moved elements of x now refer to those 
11538same elements but as members of *this.  Iterators referring to the moved 
11539elements will continue to refer to their elements, but they now behave as 
11540iterators into *this, not into x.
11541</p></blockquote>
11542
11543<p><i>[pre-Copenhagen: Howard provided wording.]</i></p>
11544
11545
11546
11547<p><b>Rationale:</b></p>
11548<p>The original proposed resolution said that iterators and references
11549would remain "valid".  The new proposed resolution clarifies what that
11550means.  Note that this only applies to the case of equal allocators.
11551From  [default.con.req] paragraph 4, the behavior of list when
11552allocators compare nonequal is outside the scope of the standard.</p>
11553
11554
11555
11556
11557<hr>
11558<h3><a name="251"></a>251. basic_stringbuf missing allocator_type</h3>
11559<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>
11560 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-07-28  <b>Last modified:</b> 2008-09-26</p>
11561<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
11562<p><b>Discussion:</b></p>
11563<p>The synopsis for the template class <tt>basic_stringbuf</tt>
11564doesn't list a typedef for the template parameter
11565<tt>Allocator</tt>. This makes it impossible to determine the type of
11566the allocator at compile time. It's also inconsistent with all other
11567template classes in the library that do provide a typedef for the
11568<tt>Allocator</tt> parameter.</p>
11569
11570
11571<p><b>Proposed resolution:</b></p>
11572<p>Add to the synopses of the class templates basic_stringbuf (27.7.1),
11573basic_istringstream (27.7.2), basic_ostringstream (27.7.3), and 
11574basic_stringstream (27.7.4) the typedef:</p>
11575<pre>  typedef Allocator allocator_type;
11576</pre>
11577
11578
11579
11580
11581<hr>
11582<h3><a name="252"></a>252. missing casts/C-style casts used in iostreams</h3>
11583<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>
11584 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-07-28  <b>Last modified:</b> 2008-09-26</p>
11585<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>
11586<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
11587<p><b>Discussion:</b></p>
11588<p>27.7.2.2, p1 uses a C-style cast rather than the more appropriate
11589const_cast&lt;&gt; in the Returns clause for basic_istringstream&lt;&gt;::rdbuf().
11590The same C-style cast is being used in 27.7.3.2, p1, D.7.2.2, p1, and
11591D.7.3.2, p1, and perhaps elsewhere. 27.7.6, p1 and D.7.2.2, p1 are missing
11592the cast altogether.</p>
11593
11594<p>C-style casts have not been deprecated, so the first part of this
11595issue is stylistic rather than a matter of correctness.</p>
11596
11597
11598<p><b>Proposed resolution:</b></p>
11599<p>In 27.7.2.2, p1 replace </p>
11600<pre>  -1- Returns: (basic_stringbuf&lt;charT,traits,Allocator&gt;*)&amp;sb.</pre>
11601
11602<p>with</p>
11603<pre>  -1- Returns: const_cast&lt;basic_stringbuf&lt;charT,traits,Allocator&gt;*&gt;(&amp;sb).</pre>
11604
11605
11606<p>In 27.7.3.2, p1 replace</p>
11607<pre>  -1- Returns: (basic_stringbuf&lt;charT,traits,Allocator&gt;*)&amp;sb.</pre>
11608
11609<p>with</p>
11610<pre>  -1- Returns: const_cast&lt;basic_stringbuf&lt;charT,traits,Allocator&gt;*&gt;(&amp;sb).</pre>
11611
11612<p>In 27.7.6, p1, replace</p>
11613<pre>  -1- Returns: &amp;sb</pre>
11614
11615<p>with</p>
11616<pre>  -1- Returns: const_cast&lt;basic_stringbuf&lt;charT,traits,Allocator&gt;*&gt;(&amp;sb).</pre>
11617
11618<p>In D.7.2.2, p1 replace</p>
11619<pre>  -2- Returns: &amp;sb. </pre>
11620
11621<p>with</p>
11622<pre>  -2- Returns: const_cast&lt;strstreambuf*&gt;(&amp;sb).</pre>
11623
11624
11625
11626
11627<hr>
11628<h3><a name="253"></a>253. valarray helper functions are almost entirely useless</h3>
11629<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>
11630 <b>Submitter:</b> Robert Klarer <b>Opened:</b> 2000-07-31  <b>Last modified:</b> 2008-09-26</p>
11631<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>
11632<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
11633<p><b>Discussion:</b></p>
11634<p>This discussion is adapted from message c++std-lib-7056 posted
11635November 11, 1999.  I don't think that anyone can reasonably claim
11636that the problem described below is NAD.</p>
11637
11638<p>These valarray constructors can never be called:</p>
11639
11640<pre>   template &lt;class T&gt;
11641         valarray&lt;T&gt;::valarray(const slice_array&lt;T&gt; &amp;);
11642   template &lt;class T&gt;
11643         valarray&lt;T&gt;::valarray(const gslice_array&lt;T&gt; &amp;);
11644   template &lt;class T&gt;
11645         valarray&lt;T&gt;::valarray(const mask_array&lt;T&gt; &amp;);
11646   template &lt;class T&gt;
11647         valarray&lt;T&gt;::valarray(const indirect_array&lt;T&gt; &amp;);
11648</pre>
11649
11650<p>Similarly, these valarray assignment operators cannot be
11651called:</p>
11652
11653<pre>     template &lt;class T&gt;
11654     valarray&lt;T&gt; valarray&lt;T&gt;::operator=(const slice_array&lt;T&gt; &amp;);
11655     template &lt;class T&gt;
11656     valarray&lt;T&gt; valarray&lt;T&gt;::operator=(const gslice_array&lt;T&gt; &amp;);
11657     template &lt;class T&gt;
11658     valarray&lt;T&gt; valarray&lt;T&gt;::operator=(const mask_array&lt;T&gt; &amp;);
11659     template &lt;class T&gt;
11660     valarray&lt;T&gt; valarray&lt;T&gt;::operator=(const indirect_array&lt;T&gt; &amp;);
11661</pre>
11662
11663<p>Please consider the following example:</p>
11664
11665<pre>   #include &lt;valarray&gt;
11666   using namespace std;
11667
11668   int main()
11669   {
11670       valarray&lt;double&gt; va1(12);
11671       valarray&lt;double&gt; va2(va1[slice(1,4,3)]); // line 1
11672   }
11673</pre>
11674
11675
11676<p>Since the valarray va1 is non-const, the result of the sub-expression
11677va1[slice(1,4,3)] at line 1 is an rvalue of type const
11678std::slice_array&lt;double&gt;.  This slice_array rvalue is then used to
11679construct va2.  The constructor that is used to construct va2 is
11680declared like this:</p>
11681
11682<pre>     template &lt;class T&gt;
11683     valarray&lt;T&gt;::valarray(const slice_array&lt;T&gt; &amp;);
11684</pre>
11685
11686<p>Notice the constructor's const reference parameter.  When the
11687constructor is called, a slice_array must be bound to this reference.
11688The rules for binding an rvalue to a const reference are in 8.5.3,
11689paragraph 5 (see also 13.3.3.1.4).  Specifically, paragraph 5
11690indicates that a second slice_array rvalue is constructed (in this
11691case copy-constructed) from the first one; it is this second rvalue
11692that is bound to the reference parameter.  Paragraph 5 also requires
11693that the constructor that is used for this purpose be callable,
11694regardless of whether the second rvalue is elided.  The
11695copy-constructor in this case is not callable, however, because it is
11696private.  Therefore, the compiler should report an error.</p>
11697
11698<p>Since slice_arrays are always rvalues, the valarray constructor that has a
11699parameter of type const slice_array&lt;T&gt; &amp; can never be called.  The
11700same reasoning applies to the three other constructors and the four
11701assignment operators that are listed at the beginning of this post.
11702Furthermore, since these functions cannot be called, the valarray helper
11703classes are almost entirely useless.</p>
11704
11705
11706<p><b>Proposed resolution:</b></p>
11707<p>slice_array:</p>
11708<ul>
11709<li> Make the copy constructor and copy-assignment operator declarations
11710     public in the slice_array class template definition in 26.6.5 [template.slice.array] </li>
11711<li> remove paragraph 3 of 26.6.5 [template.slice.array]</li>
11712<li> remove the copy constructor declaration from  [cons.slice.arr]</li>
11713<li> change paragraph 1 of  [cons.slice.arr] to read "This constructor is declared
11714    to be private.  This constructor need not be defined."</li>
11715<li> remove the first sentence of paragraph 1 of 26.6.5.1 [slice.arr.assign]</li>
11716<li> Change the first three words of the second sentence of paragraph 1 of
11717    26.6.5.1 [slice.arr.assign] to "These assignment operators have"</li>
11718</ul>
11719
11720<p>gslice_array:</p>
11721<ul>
11722<li> Make the copy constructor and copy-assignment operator declarations
11723    public in the gslice_array class template definition in 26.6.7 [template.gslice.array] </li>
11724<li> remove the note in paragraph 3 of 26.6.7 [template.gslice.array]</li>
11725<li> remove the copy constructor declaration from  [gslice.array.cons]</li>
11726<li> change paragraph 1 of  [gslice.array.cons] to read "This constructor is declared
11727    to be private.  This constructor need not be defined."</li>
11728<li> remove the first sentence of paragraph 1 of 26.6.7.1 [gslice.array.assign]</li>
11729<li> Change the first three words of the second sentence of paragraph 1 of
11730    26.6.7.1 [gslice.array.assign] to "These assignment operators have"</li>
11731</ul>
11732
11733<p>mask_array:</p>
11734<ul>
11735<li> Make the copy constructor and copy-assignment operator declarations
11736    public in the mask_array class template definition in 26.6.8 [template.mask.array] </li>
11737<li> remove the note in paragraph 2 of 26.6.8 [template.mask.array]</li>
11738<li> remove the copy constructor declaration from  [mask.array.cons]</li>
11739<li> change paragraph 1 of  [mask.array.cons] to read "This constructor is declared
11740    to be private.  This constructor need not be defined."</li>
11741<li> remove the first sentence of paragraph 1 of 26.6.8.1 [mask.array.assign]</li>
11742<li> Change the first three words of the second sentence of paragraph 1 of
11743    26.6.8.1 [mask.array.assign] to "These assignment operators have"</li>
11744</ul>
11745
11746<p>indirect_array:</p>
11747<ul>
11748<li>Make the copy constructor and copy-assignment operator declarations
11749    public in the indirect_array class definition in 26.6.9 [template.indirect.array]</li>
11750<li> remove the note in paragraph 2 of 26.6.9 [template.indirect.array]</li>
11751<li> remove the copy constructor declaration from  [indirect.array.cons]</li>
11752<li> change the descriptive text in  [indirect.array.cons] to read "This constructor is
11753    declared to be private.  This constructor need not be defined."</li>
11754<li> remove the first sentence of paragraph 1 of 26.6.9.1 [indirect.array.assign]</li>
11755<li> Change the first three words of the second sentence of paragraph 1 of
11756    26.6.9.1 [indirect.array.assign] to "These assignment operators have"</li>
11757</ul>
11758<p><i>[Proposed resolution was modified in Santa Cruz: explicitly make
11759copy constructor and copy assignment operators public, instead of
11760removing them.]</i></p>
11761
11762
11763
11764<p><b>Rationale:</b></p>
11765<p>Keeping the valarray constructors private is untenable.  Merely
11766making valarray a friend of the helper classes isn't good enough,
11767because access to the copy constructor is checked in the user's
11768environment.</p>
11769
11770<p>Making the assignment operator public is not strictly necessary to
11771solve this problem.  A majority of the LWG <i>(straw poll: 13-4)</i>
11772believed we should make the assignment operators public, in addition
11773to the copy constructors, for reasons of symmetry and user
11774expectation.</p>
11775
11776
11777
11778
11779
11780<hr>
11781<h3><a name="254"></a>254. Exception types in clause 19 are constructed from <tt>std::string</tt></h3>
11782<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>
11783 <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2000-08-01  <b>Last modified:</b> 2008-09-26</p>
11784<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
11785<p><b>Discussion:</b></p>
11786<p>
11787Many of the standard exception types which implementations are
11788required to throw are constructed with a const std::string&amp;
11789parameter. For example:
11790</p>
11791
11792<pre>     19.1.5  Class out_of_range                          [lib.out.of.range]
11793     namespace std {
11794       class out_of_range : public logic_error {
11795       public:
11796         explicit out_of_range(const string&amp; what_arg);
11797       };
11798     }
11799
11800   1 The class out_of_range defines the type of objects  thrown  as  excep-
11801     tions to report an argument value not in its expected range.
11802
11803     out_of_range(const string&amp; what_arg);
11804
11805     Effects:
11806       Constructs an object of class out_of_range.
11807     Postcondition:
11808       strcmp(what(), what_arg.c_str()) == 0.
11809</pre>
11810
11811<p>
11812There are at least two problems with this:
11813</p>
11814<ol>
11815<li>A program which is low on memory may end up throwing
11816std::bad_alloc instead of out_of_range because memory runs out while
11817constructing the exception object.</li>
11818<li>An obvious implementation which stores a std::string data member
11819may end up invoking terminate() during exception unwinding because the
11820exception object allocates memory (or rather fails to) as it is being
11821copied.</li>
11822</ol>
11823
11824<p>
11825There may be no cure for (1) other than changing the interface to
11826out_of_range, though one could reasonably argue that (1) is not a
11827defect. Personally I don't care that much if out-of-memory is reported
11828when I only have 20 bytes left, in the case when out_of_range would
11829have been reported. People who use exception-specifications might care
11830a lot, though.
11831</p>
11832
11833<p>
11834There is a cure for (2), but it isn't completely obvious. I think a
11835note for implementors should be made in the standard. Avoiding
11836possible termination in this case shouldn't be left up to chance.  The
11837cure is to use a reference-counted "string" implementation
11838in the exception object. I am not necessarily referring to a
11839std::string here; any simple reference-counting scheme for a NTBS
11840would do.
11841</p>
11842
11843<p><b>Further discussion, in email:</b></p>
11844
11845<p>
11846...I'm not so concerned about (1). After all, a library implementation
11847can add const char* constructors as an extension, and users don't
11848<i>need</i> to avail themselves of the standard exceptions, though this is
11849a lame position to be forced into.  FWIW, std::exception and
11850std::bad_alloc don't require a temporary basic_string.
11851</p>
11852
11853<p>
11854...I don't think the fixed-size buffer is a solution to the problem,
11855strictly speaking, because you can't satisfy the postcondition
11856<br>
11857    <tt>&nbsp;&nbsp;strcmp(what(), what_arg.c_str()) == 0</tt>
11858<br>
11859For all values of what_arg (i.e. very long values). That means that
11860the only truly conforming solution requires a dynamic allocation.
11861</p>
11862
11863<p><b>Further discussion, from Redmond:</b></p>
11864
11865<p>The most important progress we made at the Redmond meeting was
11866realizing that there are two separable issues here: the const
11867string&amp; constructor, and the copy constructor.  If a user writes
11868something like <tt>throw std::out_of_range("foo")</tt>, the const
11869string&amp; constructor is invoked before anything gets thrown.  The
11870copy constructor is potentially invoked during stack unwinding.</p>
11871
11872<p>The copy constructor is a more serious problem, becuase failure
11873during stack unwinding invokes <tt>terminate</tt>.  The copy
11874constructor must be nothrow. <i>Cura�ao: Howard thinks this
11875requirement may already be present.</i></p>
11876
11877<p>The fundamental problem is that it's difficult to get the nothrow
11878requirement to work well with the requirement that the exception
11879objects store a string of unbounded size, particularly if you also try
11880to make the const string&amp; constructor nothrow.  Options discussed
11881include:</p>
11882
11883<ul>
11884<li>Limit the size of a string that exception objects are required to
11885throw: change the postconditions of 19.2.2 [domain.error] paragraph 3
11886and 19.2.6 [runtime.error] paragraph 3 to something like this:
11887"strncmp(what(), what_arg._str(), N) == 0, where N is an
11888implementation defined constant no smaller than 256".</li>
11889<li>Allow the const string&amp; constructor to throw, but not the
11890copy constructor.  It's the implementor's responsibility to get it
11891right.  (An implementor might use a simple refcount class.)</li>
11892<li>Compromise between the two: an implementation is not allowed to
11893throw if the string's length is less than some N, but, if it doesn't
11894throw, the string must compare equal to the argument.</li>
11895<li>Add a new constructor that takes a const char*</li>
11896</ul>
11897
11898<p>(Not all of these options are mutually exclusive.)</p>
11899
11900
11901
11902<p><b>Proposed resolution:</b></p>
11903
11904<p>
11905Change 19.2.1 [logic.error]
11906</p>
11907
11908<blockquote>
11909<pre>namespace std {
11910  class logic_error : public exception {
11911  public:
11912    explicit logic_error(const string&amp; <i>what_arg</i>);
11913    <ins>explicit logic_error(const char* <i>what_arg</i>);</ins>
11914  };
11915}
11916</pre>
11917<p>...</p>
11918<p>
11919<ins><tt>logic_error(const char* <i>what_arg</i>);</tt></ins>
11920</p>
11921<blockquote>
11922<p><ins>
11923-4- <i>Effects:</i> Constructs an object of class <tt>logic_error</tt>.
11924</ins></p>
11925<p><ins>
11926-5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>.
11927</ins></p>
11928</blockquote>
11929
11930</blockquote>
11931
11932<p>
11933Change 19.2.2 [domain.error]
11934</p>
11935
11936<blockquote>
11937<pre>namespace std {
11938  class domain_error : public logic_error {
11939  public:
11940    explicit domain_error(const string&amp; <i>what_arg</i>);
11941    <ins>explicit domain_error(const char* <i>what_arg</i>);</ins>
11942  };
11943}
11944</pre>
11945<p>...</p>
11946<p>
11947<ins><tt>domain_error(const char* <i>what_arg</i>);</tt></ins>
11948</p>
11949<blockquote>
11950<p><ins>
11951-4- <i>Effects:</i> Constructs an object of class <tt>domain_error</tt>.
11952</ins></p>
11953<p><ins>
11954-5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>.
11955</ins></p>
11956
11957</blockquote>
11958</blockquote>
11959
11960<p>
11961Change 19.2.3 [invalid.argument]
11962</p>
11963
11964<blockquote>
11965<pre>namespace std {
11966  class invalid_argument : public logic_error {
11967  public:
11968    explicit invalid_argument(const string&amp; <i>what_arg</i>);
11969    <ins>explicit invalid_argument(const char* <i>what_arg</i>);</ins>
11970  };
11971}
11972</pre>
11973<p>...</p>
11974<p>
11975<ins><tt>invalid_argument(const char* <i>what_arg</i>);</tt></ins>
11976</p>
11977<blockquote>
11978<p><ins>
11979-4- <i>Effects:</i> Constructs an object of class <tt>invalid_argument</tt>.
11980</ins></p>
11981<p><ins>
11982-5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>.
11983</ins></p>
11984</blockquote>
11985
11986</blockquote>
11987
11988<p>
11989Change 19.2.4 [length.error]
11990</p>
11991
11992<blockquote>
11993<pre>namespace std {
11994  class length_error : public logic_error {
11995  public:
11996    explicit length_error(const string&amp; <i>what_arg</i>);
11997    <ins>explicit length_error(const char* <i>what_arg</i>);</ins>
11998  };
11999}
12000</pre>
12001<p>...</p>
12002<p>
12003<ins><tt>length_error(const char* <i>what_arg</i>);</tt></ins>
12004</p>
12005<blockquote>
12006<p><ins>
12007-4- <i>Effects:</i> Constructs an object of class <tt>length_error</tt>.
12008</ins></p>
12009<p><ins>
12010-5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>.
12011</ins></p>
12012</blockquote>
12013
12014</blockquote>
12015
12016<p>
12017Change 19.2.5 [out.of.range]
12018</p>
12019
12020<blockquote>
12021<pre>namespace std {
12022  class out_of_range : public logic_error {
12023  public:
12024    explicit out_of_range(const string&amp; <i>what_arg</i>);
12025    <ins>explicit out_of_range(const char* <i>what_arg</i>);</ins>
12026  };
12027}
12028</pre>
12029<p>...</p>
12030<p>
12031<ins><tt>out_of_range(const char* <i>what_arg</i>);</tt></ins>
12032</p>
12033<blockquote>
12034<p><ins>
12035-4- <i>Effects:</i> Constructs an object of class <tt>out_of_range</tt>.
12036</ins></p>
12037<p><ins>
12038-5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>.
12039</ins></p>
12040</blockquote>
12041
12042</blockquote>
12043
12044<p>
12045Change 19.2.6 [runtime.error]
12046</p>
12047
12048<blockquote>
12049<pre>namespace std {
12050  class runtime_error : public exception {
12051  public:
12052    explicit runtime_error(const string&amp; <i>what_arg</i>);
12053    <ins>explicit runtime_error(const char* <i>what_arg</i>);</ins>
12054  };
12055}
12056</pre>
12057<p>...</p>
12058<p>
12059<ins><tt>runtime_error(const char* <i>what_arg</i>);</tt></ins>
12060</p>
12061<blockquote>
12062<p><ins>
12063-4- <i>Effects:</i> Constructs an object of class <tt>runtime_error</tt>.
12064</ins></p>
12065<p><ins>
12066-5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>.
12067</ins></p>
12068</blockquote>
12069
12070</blockquote>
12071
12072<p>
12073Change 19.2.7 [range.error]
12074</p>
12075
12076<blockquote>
12077<pre>namespace std {
12078  class range_error : public runtime_error {
12079  public:
12080    explicit range_error(const string&amp; <i>what_arg</i>);
12081    <ins>explicit range_error(const char* <i>what_arg</i>);</ins>
12082  };
12083}
12084</pre>
12085<p>...</p>
12086<p>
12087<ins><tt>range_error(const char* <i>what_arg</i>);</tt></ins>
12088</p>
12089<blockquote>
12090<p><ins>
12091-4- <i>Effects:</i> Constructs an object of class <tt>range_error</tt>.
12092</ins></p>
12093<p><ins>
12094-5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>.
12095</ins></p>
12096</blockquote>
12097
12098</blockquote>
12099
12100<p>
12101Change 19.2.8 [overflow.error]
12102</p>
12103
12104<blockquote>
12105<pre>namespace std {
12106  class overflow_error : public runtime_error {
12107  public:
12108    explicit overflow_error(const string&amp; <i>what_arg</i>);
12109    <ins>explicit overflow_error(const char* <i>what_arg</i>);</ins>
12110  };
12111}
12112</pre>
12113<p>...</p>
12114<p>
12115<ins><tt>overflow_error(const char* <i>what_arg</i>);</tt></ins>
12116</p>
12117<blockquote>
12118<p><ins>
12119-4- <i>Effects:</i> Constructs an object of class <tt>overflow_error</tt>.
12120</ins></p>
12121<p><ins>
12122-5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>.
12123</ins></p>
12124</blockquote>
12125
12126</blockquote>
12127
12128<p>
12129Change 19.2.9 [underflow.error]
12130</p>
12131
12132<blockquote>
12133<pre>namespace std {
12134  class underflow_error : public runtime_error {
12135  public:
12136    explicit underflow_error(const string&amp; <i>what_arg</i>);
12137    <ins>explicit underflow_error(const char* <i>what_arg</i>);</ins>
12138  };
12139}
12140</pre>
12141<p>...</p>
12142<p>
12143<ins><tt>underflow_error(const char* <i>what_arg</i>);</tt></ins>
12144</p>
12145<blockquote>
12146<p><ins>
12147-4- <i>Effects:</i> Constructs an object of class <tt>underflow_error</tt>.
12148</ins></p>
12149<p><ins>
12150-5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>.
12151</ins></p>
12152</blockquote>
12153
12154</blockquote>
12155
12156<p>
12157Change 27.5.2.1.1 [ios::failure]
12158</p>
12159
12160<blockquote>
12161<pre>namespace std {
12162  class ios_base::failure : public exception {
12163  public:
12164    explicit failure(const string&amp; <i>msg</i>);
12165    <ins>explicit failure(const char* <i>msg</i>);</ins>
12166    virtual const char* what() const throw();
12167};
12168}
12169</pre>
12170<p>...</p>
12171<p>
12172<ins><tt>failure(const char* <i>msg</i>);</tt></ins>
12173</p>
12174<blockquote>
12175<p><ins>
12176-4- <i>Effects:</i> Constructs an object of class <tt>failure</tt>.
12177</ins></p>
12178<p><ins>
12179-5- <i>Postcondition:</i> <tt>strcmp(what(), <i>msg</i>) == 0</tt>.
12180</ins></p>
12181</blockquote>
12182
12183</blockquote>
12184
12185
12186
12187<p><b>Rationale:</b></p>
12188
12189<p>Throwing a bad_alloc while trying to construct a message for another
12190exception-derived class is not necessarily a bad thing.  And the
12191bad_alloc constructor already has a no throw spec on it (18.4.2.1).</p>
12192
12193<p><b>Future:</b></p>
12194
12195<p>All involved would like to see const char* constructors added, but
12196this should probably be done for C++0X as opposed to a DR.</p>
12197
12198<p>I believe the no throw specs currently decorating these functions
12199could be improved by some kind of static no throw spec checking
12200mechanism (in a future C++ language).  As they stand, the copy
12201constructors might fail via a call to unexpected.  I think what is
12202intended here is that the copy constructors can't fail.</p>
12203
12204<p><i>[Pre-Sydney: reopened at the request of Howard Hinnant.
12205  Post-Redmond: James Kanze noticed that the copy constructors of
12206  exception-derived classes do not have nothrow clauses.  Those
12207  classes have no copy constructors declared, meaning the
12208  compiler-generated implicit copy constructors are used, and those
12209  compiler-generated constructors might in principle throw anything.]</i></p>
12210
12211
12212<p><i>[
12213Batavia:  Merged copy constructor and assignment operator spec into <tt>exception</tt>
12214and added <tt>ios::failure</tt> into the proposed resolution.
12215]</i></p>
12216
12217
12218<p><i>[
12219Oxford:  The proposed resolution simply addresses the issue of constructing
12220the exception objects with <tt>const char*</tt> and string literals without
12221the need to explicit include or construct a <tt>std::string</tt>.
12222]</i></p>
12223
12224
12225
12226
12227
12228
12229
12230<hr>
12231<h3><a name="256"></a>256. typo in 27.4.4.2, p17: copy_event does not exist</h3>
12232<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>
12233 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-08-21  <b>Last modified:</b> 2008-09-26</p>
12234<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>
12235<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>
12236<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
12237<p><b>Discussion:</b></p>
12238<p>
1223927.4.4.2, p17 says
12240</p>
12241
12242<blockquote><p>
12243-17- Before copying any parts of rhs, calls each registered callback
12244pair (fn,index) as (*fn)(erase_event,*this,index). After all parts but
12245exceptions() have been replaced, calls each callback pair that was
12246copied from rhs as (*fn)(copy_event,*this,index). 
12247</p></blockquote>
12248
12249<p>
12250The name copy_event isn't defined anywhere. The intended name was
12251copyfmt_event.
12252</p>
12253
12254
12255<p><b>Proposed resolution:</b></p>
12256<p>Replace copy_event with copyfmt_event in the named paragraph.</p>
12257
12258
12259
12260
12261<hr>
12262<h3><a name="258"></a>258. Missing allocator requirement</h3>
12263<p><b>Section:</b> 20.2.2 [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
12264 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2000-08-22  <b>Last modified:</b> 2008-09-26</p>
12265<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>
12266<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
12267<p><b>Discussion:</b></p>
12268<p>
12269From lib-7752:
12270</p>
12271
12272<p>
12273I've been assuming (and probably everyone else has been assuming) that
12274allocator instances have a particular property, and I don't think that
12275property can be deduced from anything in Table 32.
12276</p>
12277
12278<p>
12279I think we have to assume that allocator type conversion is a
12280homomorphism.  That is, if x1 and x2 are of type X, where
12281X::value_type is T, and if type Y is X::template
12282rebind&lt;U&gt;::other, then Y(x1) == Y(x2) if and only if x1 == x2.
12283</p>
12284
12285<p>
12286Further discussion: Howard Hinnant writes, in lib-7757:
12287</p>
12288
12289<p>
12290I think I can prove that this is not provable by Table 32.  And I agree 
12291it needs to be true except for the "and only if".  If x1 != x2, I see no 
12292reason why it can't be true that Y(x1) == Y(x2).  Admittedly I can't 
12293think of a practical instance where this would happen, or be valuable.  
12294But I also don't see a need to add that extra restriction.  I think we 
12295only need:
12296</p>
12297
12298<blockquote><p>
12299     if (x1 == x2) then Y(x1) == Y(x2)
12300</p></blockquote>
12301
12302<p>
12303If we decide that == on allocators is transitive, then I think I can 
12304prove the above.  But I don't think == is necessarily transitive on 
12305allocators.  That is:
12306</p>
12307
12308<p>
12309Given x1 == x2  and x2 == x3, this does not mean x1 == x3.
12310</p>
12311
12312<p>Example:</p>
12313
12314<blockquote>
12315<p>
12316x1 can deallocate pointers from:  x1, x2, x3    <br>
12317x2 can deallocate pointers from:  x1, x2, x4    <br>
12318x3 can deallocate pointers from:  x1, x3        <br>
12319x4 can deallocate pointers from:  x2, x4 
12320</p>
12321
12322<p>
12323x1 == x2, and x2 == x4, but x1 != x4
12324</p>
12325</blockquote>
12326<p><i>[Toronto: LWG members offered multiple opinions.  One
12327opinion is that it should not be required that <tt>x1 == x2</tt>
12328implies <tt>Y(x1) == Y(x2)</tt>, and that it should not even be
12329required that <tt>X(x1) == x1</tt>.  Another opinion is that 
12330the second line from the bottom in table 32 already implies the
12331desired property.  This issue should be considered in light of
12332other issues related to allocator instances.]</i></p>
12333
12334
12335
12336<p><b>Proposed resolution:</b></p>
12337<p>
12338Accept proposed wording from
12339<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2436.pdf">N2436</a> part 3.
12340</p>
12341
12342
12343<p><i>[Lillehammer: Same conclusion as before: this should be
12344  considered as part of an allocator redesign, not solved on its own.]</i></p>
12345
12346
12347<p><i>[
12348Batavia:  An allocator redesign is not forthcoming and thus we fixed this one issue.
12349]</i></p>
12350
12351
12352<p><i>[
12353Toronto:  Reopened at the request of the project editor (Pete) because the proposed
12354wording did not fit within the indicated table.  The intent of the resolution remains
12355unchanged.  Pablo to work with Pete on improved wording.
12356]</i></p>
12357
12358
12359<p><i>[
12360Kona (2007): The LWG adopted the proposed resolution of N2387 for this issue which
12361was subsequently split out into a separate paper N2436 for the purposes of voting.
12362The resolution in N2436 addresses this issue.  The LWG voted to accelerate this
12363issue to Ready status to be voted into the WP at Kona.
12364]</i></p>
12365
12366
12367
12368
12369
12370<hr>
12371<h3><a name="259"></a>259. <tt>basic_string::operator[]</tt> and const correctness</h3>
12372<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>
12373 <b>Submitter:</b> Chris Newton  <b>Opened:</b> 2000-08-27  <b>Last modified:</b> 2008-09-26</p>
12374<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>
12375<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
12376<p><b>Discussion:</b></p>
12377<p>
12378<i>Paraphrased from a message that Chris Newton posted to comp.std.c++:</i>
12379</p>
12380
12381<p>
12382The standard's description of <tt>basic_string&lt;&gt;::operator[]</tt>
12383seems to violate const correctness.
12384</p>
12385
12386<p>
12387The standard (21.3.4/1) says that "If <tt>pos &lt; size()</tt>,
12388returns <tt>data()[pos]</tt>." The types don't work.  The
12389return value of <tt>data()</tt> is <tt>const charT*</tt>, but
12390<tt>operator[]</tt> has a non-const version whose return type is <tt>reference</tt>.
12391</p>
12392
12393
12394<p><b>Proposed resolution:</b></p>
12395<p>
12396In section 21.3.4, paragraph 1, change
12397"<tt>data()[<i>pos</i>]</tt>" to "<tt>*(begin() +
12398<i>pos</i>)</tt>".
12399</p>
12400
12401
12402
12403
12404<hr>
12405<h3><a name="260"></a>260. Inconsistent return type of <tt>istream_iterator::operator++(int)</tt></h3>
12406<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>
12407 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-08-27  <b>Last modified:</b> 2008-09-26</p>
12408<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>
12409<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
12410<p><b>Discussion:</b></p>
12411<p>The synopsis of istream_iterator::operator++(int) in 24.5.1 shows
12412it as returning the iterator by value. 24.5.1.2, p5 shows the same
12413operator as returning the iterator by reference. That's incorrect
12414given the Effects clause below (since a temporary is returned). The
12415`&amp;' is probably just a typo.</p>
12416
12417
12418<p><b>Proposed resolution:</b></p>
12419<p>Change the declaration in 24.5.1.2, p5 from</p>
12420 <pre> istream_iterator&lt;T,charT,traits,Distance&gt;&amp; operator++(int);
12421 </pre>
12422<p>to</p>
12423 <pre> istream_iterator&lt;T,charT,traits,Distance&gt; operator++(int);
12424 </pre>
12425<p>(that is, remove the `&amp;').</p>
12426
12427
12428
12429
12430<hr>
12431<h3><a name="261"></a>261. Missing description of <tt>istream_iterator::operator!=</tt></h3>
12432<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>
12433 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-08-27  <b>Last modified:</b> 2008-09-26</p>
12434<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>
12435<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
12436<p><b>Discussion:</b></p>
12437<p>
1243824.5.1, p3 lists the synopsis for
12439</p>
12440
12441<pre>   template &lt;class T, class charT, class traits, class Distance&gt;
12442        bool operator!=(const istream_iterator&lt;T,charT,traits,Distance&gt;&amp; x,
12443                        const istream_iterator&lt;T,charT,traits,Distance&gt;&amp; y);
12444</pre>
12445
12446<p>
12447but there is no description of what the operator does (i.e., no Effects
12448or Returns clause) in 24.5.1.2.
12449</p>
12450
12451
12452<p><b>Proposed resolution:</b></p>
12453<p>
12454Add paragraph 7 to the end of section 24.5.1.2 with the following text:
12455</p>
12456
12457<pre>   template &lt;class T, class charT, class traits, class Distance&gt;
12458        bool operator!=(const istream_iterator&lt;T,charT,traits,Distance&gt;&amp; x,
12459                        const istream_iterator&lt;T,charT,traits,Distance&gt;&amp; y);
12460</pre>
12461
12462<p>-7- Returns: !(x == y).</p>
12463
12464
12465
12466
12467<hr>
12468<h3><a name="262"></a>262. Bitmask operator ~ specified incorrectly</h3>
12469<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>
12470 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2000-09-03  <b>Last modified:</b> 2008-09-26</p>
12471<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
12472<p><b>Discussion:</b></p>
12473<p>
12474The ~ operation should be applied after the cast to int_type.
12475</p>
12476
12477
12478<p><b>Proposed resolution:</b></p>
12479<p>
12480Change 17.3.2.1.2 [lib.bitmask.types] operator~ from:
12481</p>
12482
12483<pre>   bitmask operator~ ( bitmask X )
12484     { return static_cast&lt; bitmask&gt;(static_cast&lt;int_type&gt;(~ X)); }
12485</pre>
12486
12487<p>
12488to:
12489</p>
12490
12491<pre>   bitmask operator~ ( bitmask X )
12492     { return static_cast&lt; bitmask&gt;(~static_cast&lt;int_type&gt;(X)); }
12493</pre>
12494
12495
12496
12497
12498<hr>
12499<h3><a name="263"></a>263. Severe restriction on <tt>basic_string</tt> reference counting</h3>
12500<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>
12501 <b>Submitter:</b> Kevlin Henney <b>Opened:</b> 2000-09-04  <b>Last modified:</b> 2008-09-26</p>
12502<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>
12503<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
12504<p><b>Discussion:</b></p>
12505<p>
12506The note in paragraph 6 suggests that the invalidation rules for
12507references, pointers, and iterators in paragraph 5 permit a reference-
12508counted implementation (actually, according to paragraph 6, they permit
12509a "reference counted implementation", but this is a minor editorial fix).
12510</p>
12511
12512<p>
12513However, the last sub-bullet is so worded as to make a reference-counted
12514implementation unviable. In the following example none of the
12515conditions for iterator invalidation are satisfied:
12516</p>
12517
12518<pre>    // first example: "*******************" should be printed twice
12519    string original = "some arbitrary text", copy = original;
12520    const string &amp; alias = original;
12521
12522    string::const_iterator i = alias.begin(), e = alias.end();
12523    for(string::iterator j = original.begin(); j != original.end(); ++j)
12524        *j = '*';
12525    while(i != e)
12526        cout &lt;&lt; *i++;
12527    cout &lt;&lt; endl;
12528    cout &lt;&lt; original &lt;&lt; endl;
12529</pre>
12530
12531<p>
12532Similarly, in the following example:
12533</p>
12534
12535<pre>    // second example: "some arbitrary text" should be printed out
12536    string original = "some arbitrary text", copy = original;
12537    const string &amp; alias = original;
12538
12539    string::const_iterator i = alias.begin();
12540    original.begin();
12541    while(i != alias.end())
12542        cout &lt;&lt; *i++;
12543</pre>
12544
12545<p>
12546I have tested this on three string implementations, two of which were
12547reference counted. The reference-counted implementations gave
12548"surprising behavior" because they invalidated iterators on
12549the first call to non-const begin since construction. The current
12550wording does not permit such invalidation because it does not take
12551into account the first call since construction, only the first call
12552since various member and non-member function calls.
12553</p>
12554
12555
12556<p><b>Proposed resolution:</b></p>
12557<p>
12558Change the following sentence in 21.3 paragraph 5 from
12559</p>
12560
12561<blockquote><p>
12562    Subsequent to any of the above uses except the forms of insert() and
12563    erase() which return iterators, the first call to non-const member
12564    functions operator[](), at(), begin(), rbegin(), end(), or rend().
12565</p></blockquote>
12566
12567<p>to</p>
12568
12569<blockquote><p>
12570    Following construction or any of the above uses, except the forms of
12571    insert() and erase() that return iterators, the first call to non-
12572    const member functions operator[](), at(), begin(), rbegin(), end(),
12573    or rend().
12574</p></blockquote>
12575
12576
12577
12578
12579<hr>
12580<h3><a name="264"></a>264. Associative container <tt>insert(i, j)</tt> complexity requirements are not feasible.</h3>
12581<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>
12582 <b>Submitter:</b> John Potter <b>Opened:</b> 2000-09-07  <b>Last modified:</b> 2008-09-26</p>
12583<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>
12584<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>
12585<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
12586<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#102">102</a></p>
12587<p><b>Discussion:</b></p>
12588<p>
12589Table 69 requires linear time if [i, j) is sorted.  Sorted is necessary but not sufficient.
12590Consider inserting a sorted range of even integers into a set&lt;int&gt; containing the odd
12591integers in the same range.
12592</p>
12593
12594<p><i>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#102">102</a></i></p>
12595
12596
12597<p><b>Proposed resolution:</b></p>
12598<p>
12599In Table 69, in section 23.1.2, change the complexity clause for
12600insertion of a range from "N log(size() + N) (N is the distance
12601from i to j) in general; linear if [i, j) is sorted according to
12602value_comp()" to "N log(size() + N), where N is the distance
12603from i to j".
12604</p>
12605
12606<p><i>[Copenhagen: Minor fix in proposed resolution: fixed unbalanced
12607parens in the revised wording.]</i></p>
12608
12609
12610
12611
12612<p><b>Rationale:</b></p>
12613<p>
12614Testing for valid insertions could be less efficient than simply
12615inserting the elements when the range is not both sorted and between
12616two adjacent existing elements; this could be a QOI issue.
12617</p>
12618
12619<p> 
12620The LWG considered two other options: (a) specifying that the
12621complexity was linear if [i, j) is sorted according to value_comp()
12622and between two adjacent existing elements; or (b) changing to
12623Klog(size() + N) + (N - K) (N is the distance from i to j and K is the
12624number of elements which do not insert immediately after the previous
12625element from [i, j) including the first).  The LWG felt that, since
12626we can't guarantee linear time complexity whenever the range to be
12627inserted is sorted, it's more trouble than it's worth to say that it's
12628linear in some special cases.
12629</p>
12630
12631
12632
12633
12634<hr>
12635<h3><a name="265"></a>265. std::pair::pair() effects overly restrictive</h3>
12636<p><b>Section:</b> 20.3.4 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
12637 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-09-11  <b>Last modified:</b> 2008-09-26</p>
12638<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>
12639<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>
12640<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
12641<p><b>Discussion:</b></p>
12642<p>
12643I don't see any requirements on the types of the elements of the
12644std::pair container in 20.2.2. From the descriptions of the member
12645functions it appears that they must at least satisfy the requirements of
1264620.1.3 [lib.copyconstructible] and 20.1.4 [lib.default.con.req], and in
12647the case of the [in]equality operators also the requirements of 20.1.1
12648[lib.equalitycomparable] and 20.1.2 [lib.lessthancomparable].
12649</p>
12650
12651<p>
12652I believe that the the CopyConstructible requirement is unnecessary in
12653the case of 20.2.2, p2.
12654</p>
12655
12656
12657<p><b>Proposed resolution:</b></p>
12658<p>Change the Effects clause in 20.2.2, p2 from</p>
12659
12660<blockquote><p>
12661-2- <b>Effects</b>: Initializes its members as if implemented: <tt> pair() :
12662first(T1()), second(T2()) {} </tt>
12663</p></blockquote>
12664
12665<p>to</p>
12666
12667<blockquote><p>
12668-2- <b>Effects</b>: Initializes its members as if implemented: <tt> pair() :
12669first(), second() {} </tt>
12670</p></blockquote>
12671
12672
12673<p><b>Rationale:</b></p>
12674<p>The existing specification of pair's constructor appears to be a
12675historical artifact: there was concern that pair's members be properly
12676zero-initialized when they are built-in types.  At one time there was
12677uncertainty about whether they would be zero-initialized if the
12678default constructor was written the obvious way.  This has been
12679clarified by core issue 178, and there is no longer any doubt that
12680the straightforward implementation is correct.</p>
12681
12682
12683
12684
12685<hr>
12686<h3><a name="266"></a>266. bad_exception::~bad_exception() missing Effects clause</h3>
12687<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>
12688 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-09-24  <b>Last modified:</b> 2008-09-26</p>
12689<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
12690<p><b>Discussion:</b></p>
12691<p>
12692The synopsis for std::bad_exception lists the function ~bad_exception()
12693but there is no description of what the function does (the Effects
12694clause is missing).
12695</p>
12696
12697
12698<p><b>Proposed resolution:</b></p>
12699<p>
12700Remove the destructor from the class synopses of 
12701<tt>bad_alloc</tt> (18.6.2.1 [bad.alloc]),
12702<tt>bad_cast</tt> (18.7.2 [bad.cast]),
12703<tt>bad_typeid</tt> (18.7.3 [bad.typeid]),
12704and <tt>bad_exception</tt> (18.8.2.1 [bad.exception]).
12705</p>
12706
12707
12708<p><b>Rationale:</b></p>
12709<p>
12710This is a general problem with the exception classes in clause 18. 
12711The proposed resolution is to remove the destructors from the class
12712synopses, rather than to document the destructors' behavior, because
12713removing them is more consistent with how exception classes are
12714described in clause 19.
12715</p>
12716
12717
12718
12719
12720<hr>
12721<h3><a name="268"></a>268. Typo in locale synopsis</h3>
12722<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>
12723 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-10-05  <b>Last modified:</b> 2008-09-26</p>
12724<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>
12725<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
12726<p><b>Discussion:</b></p>
12727<p>The synopsis of the class std::locale in 22.1.1 contains two typos:
12728the semicolons after the declarations of the default ctor
12729locale::locale() and the copy ctor locale::locale(const locale&amp;)
12730are missing.</p>
12731
12732
12733<p><b>Proposed resolution:</b></p>
12734<p>Add the missing semicolons, i.e., change</p>
12735
12736<pre>    //  construct/copy/destroy:
12737        locale() throw()
12738        locale(const locale&amp; other) throw()
12739</pre>
12740
12741<p>in the synopsis in 22.1.1 to</p>
12742
12743<pre>    //  construct/copy/destroy:
12744        locale() throw();
12745        locale(const locale&amp; other) throw();
12746</pre>
12747
12748
12749
12750
12751<hr>
12752<h3><a name="270"></a>270. Binary search requirements overly strict</h3>
12753<p><b>Section:</b> 25.4.3 [alg.binary.search] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
12754 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2000-10-18  <b>Last modified:</b> 2008-09-26</p>
12755<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>
12756<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
12757<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#472">472</a></p>
12758<p><b>Discussion:</b></p>
12759<p>
12760Each of the four binary search algorithms (lower_bound, upper_bound,
12761equal_range, binary_search) has a form that allows the user to pass a
12762comparison function object.  According to 25.3, paragraph 2, that
12763comparison function object has to be a strict weak ordering.
12764</p>
12765
12766<p>
12767This requirement is slightly too strict.  Suppose we are searching
12768through a sequence containing objects of type X, where X is some
12769large record with an integer key.  We might reasonably want to look
12770up a record by key, in which case we would want to write something
12771like this:
12772</p>
12773<pre>    struct key_comp {
12774      bool operator()(const X&amp; x, int n) const {
12775        return x.key() &lt; n;
12776      }
12777    }
12778
12779    std::lower_bound(first, last, 47, key_comp());
12780</pre>
12781
12782<p>
12783key_comp is not a strict weak ordering, but there is no reason to
12784prohibit its use in lower_bound.
12785</p>
12786
12787<p>
12788There's no difficulty in implementing lower_bound so that it allows
12789the use of something like key_comp.  (It will probably work unless an
12790implementor takes special pains to forbid it.)  What's difficult is
12791formulating language in the standard to specify what kind of
12792comparison function is acceptable.  We need a notion that's slightly
12793more general than that of a strict weak ordering, one that can encompass
12794a comparison function that involves different types.  Expressing that
12795notion may be complicated.
12796</p>
12797
12798<p><i>Additional questions raised at the Toronto meeting:</i></p>
12799<ul>
12800<li> Do we really want to specify what ordering the implementor must
12801     use when calling the function object?  The standard gives 
12802     specific expressions when describing these algorithms, but it also
12803     says that other expressions (with different argument order) are
12804     equivalent.</li>
12805<li> If we are specifying ordering, note that the standard uses both
12806     orderings when describing <tt>equal_range</tt>.</li>
12807<li> Are we talking about requiring these algorithms to work properly
12808     when passed a binary function object whose two argument types
12809     are not the same, or are we talking about requirements when
12810     they are passed a binary function object with several overloaded
12811     versions of <tt>operator()</tt>?</li>
12812<li> The definition of a strict weak ordering does not appear to give
12813     any guidance on issues of overloading; it only discusses expressions,
12814     and all of the values in these expressions are of the same type.
12815     Some clarification would seem to be in order.</li>
12816</ul>
12817
12818<p><i>Additional discussion from Copenhagen:</i></p>
12819<ul>
12820<li>It was generally agreed that there is a real defect here: if
12821the predicate is merely required to be a Strict Weak Ordering, then
12822it's possible to pass in a function object with an overloaded
12823operator(), where the version that's actually called does something
12824completely inappropriate.  (Such as returning a random value.)</li>
12825
12826<li>An alternative formulation was presented in a paper distributed by
12827David Abrahams at the meeting, "Binary Search with Heterogeneous
12828Comparison", J16-01/0027 = WG21 N1313: Instead of viewing the
12829predicate as a Strict Weak Ordering acting on a sorted sequence, view
12830the predicate/value pair as something that partitions a sequence.
12831This is almost equivalent to saying that we should view binary search
12832as if we are given a unary predicate and a sequence, such that f(*p)
12833is true for all p below a specific point and false for all p above it.
12834The proposed resolution is based on that alternative formulation.</li>
12835</ul>
12836
12837
12838<p><b>Proposed resolution:</b></p>
12839
12840<p>Change 25.3 [lib.alg.sorting] paragraph 3 from:</p>
12841
12842<blockquote><p>
12843  3 For all algorithms that take Compare, there is a version that uses
12844  operator&lt; instead. That is, comp(*i, *j) != false defaults to *i &lt;
12845  *j != false. For the algorithms to work correctly, comp has to
12846  induce a strict weak ordering on the values.
12847</p></blockquote>
12848
12849<p>to:</p>
12850
12851<blockquote><p>
12852  3 For all algorithms that take Compare, there is a version that uses
12853  operator&lt; instead. That is, comp(*i, *j) != false defaults to *i
12854  &lt; *j != false. For algorithms other than those described in
12855  lib.alg.binary.search (25.3.3) to work correctly, comp has to induce
12856  a strict weak ordering on the values.
12857</p></blockquote>
12858
12859<p>Add the following paragraph after 25.3 [lib.alg.sorting] paragraph 5:</p>
12860
12861<blockquote><p>
12862  -6- A sequence [start, finish) is partitioned with respect to an
12863  expression f(e) if there exists an integer n such that
12864  for all 0 &lt;= i &lt; distance(start, finish), f(*(begin+i)) is true if
12865  and only if i &lt; n.
12866</p></blockquote>
12867
12868<p>Change 25.3.3 [lib.alg.binary.search] paragraph 1 from:</p>
12869
12870<blockquote><p>
12871  -1- All of the algorithms in this section are versions of binary
12872   search and assume that the sequence being searched is in order
12873   according to the implied or explicit comparison function. They work
12874   on non-random access iterators minimizing the number of
12875   comparisons, which will be logarithmic for all types of
12876   iterators. They are especially appropriate for random access
12877   iterators, because these algorithms do a logarithmic number of
12878   steps through the data structure. For non-random access iterators
12879   they execute a linear number of steps.
12880</p></blockquote>
12881
12882<p>to:</p>
12883
12884<blockquote><p>
12885   -1- All of the algorithms in this section are versions of binary
12886    search and assume that the sequence being searched is partitioned
12887    with respect to an expression formed by binding the search key to
12888    an argument of the implied or explicit comparison function. They
12889    work on non-random access iterators minimizing the number of
12890    comparisons, which will be logarithmic for all types of
12891    iterators. They are especially appropriate for random access
12892    iterators, because these algorithms do a logarithmic number of
12893    steps through the data structure. For non-random access iterators
12894    they execute a linear number of steps.
12895</p></blockquote>
12896
12897<p>Change 25.3.3.1 [lib.lower.bound] paragraph 1 from:</p>
12898
12899<blockquote><p>
12900   -1- Requires: Type T is LessThanComparable
12901    (lib.lessthancomparable). 
12902</p></blockquote>
12903
12904<p>to:</p>
12905
12906<blockquote><p>
12907   -1- Requires: The elements e of [first, last) are partitioned with
12908   respect to the expression e &lt; value or comp(e, value)
12909</p></blockquote>
12910
12911
12912<p>Remove 25.3.3.1 [lib.lower.bound] paragraph 2:</p>
12913
12914<blockquote><p>
12915   -2- Effects: Finds the first position into which value can be
12916    inserted without violating the ordering. 
12917</p></blockquote>
12918
12919<p>Change 25.3.3.2 [lib.upper.bound] paragraph 1 from:</p>
12920
12921<blockquote><p>
12922  -1- Requires: Type T is LessThanComparable (lib.lessthancomparable).
12923</p></blockquote>
12924
12925<p>to:</p>
12926
12927<blockquote><p>
12928   -1- Requires: The elements e of [first, last) are partitioned with
12929   respect to the expression !(value &lt; e) or !comp(value, e)
12930</p></blockquote>
12931
12932<p>Remove 25.3.3.2 [lib.upper.bound] paragraph 2:</p>
12933
12934<blockquote><p>
12935   -2- Effects: Finds the furthermost position into which value can be
12936    inserted without violating the ordering.
12937</p></blockquote>
12938
12939<p>Change 25.3.3.3 [lib.equal.range] paragraph 1 from:</p>
12940
12941<blockquote><p>
12942   -1- Requires: Type T is LessThanComparable
12943    (lib.lessthancomparable).
12944</p></blockquote>
12945
12946<p>to:</p>
12947
12948<blockquote><p>
12949   -1- Requires: The elements e of [first, last) are partitioned with
12950   respect to the expressions e &lt; value and !(value &lt; e) or
12951   comp(e, value) and !comp(value, e).  Also, for all elements e of
12952   [first, last), e &lt; value implies !(value &lt; e) or comp(e,
12953   value) implies !comp(value, e)
12954</p></blockquote>
12955
12956<p>Change 25.3.3.3 [lib.equal.range] paragraph 2 from:</p>
12957
12958<blockquote><p>
12959   -2- Effects: Finds the largest subrange [i, j) such that the value
12960    can be inserted at any iterator k in it without violating the
12961    ordering. k satisfies the corresponding conditions: !(*k &lt; value)
12962    &amp;&amp; !(value &lt; *k) or comp(*k, value) == false &amp;&amp; comp(value, *k) ==
12963    false.
12964</p></blockquote>
12965
12966<p>to:</p>
12967
12968<pre>   -2- Returns: 
12969         make_pair(lower_bound(first, last, value),
12970                   upper_bound(first, last, value))
12971       or
12972         make_pair(lower_bound(first, last, value, comp),
12973                   upper_bound(first, last, value, comp))
12974</pre>
12975
12976<p>Change 25.3.3.3 [lib.binary.search] paragraph 1 from:</p>
12977
12978<blockquote><p>
12979   -1- Requires: Type T is LessThanComparable
12980    (lib.lessthancomparable).
12981</p></blockquote>
12982
12983<p>to:</p>
12984
12985<blockquote><p>
12986   -1- Requires: The elements e of [first, last) are partitioned with
12987   respect to the expressions e &lt; value and !(value &lt; e) or comp(e,
12988   value) and !comp(value, e). Also, for all elements e of [first,
12989   last), e &lt; value implies !(value &lt; e) or comp(e, value) implies
12990   !comp(value, e)
12991</p></blockquote>
12992
12993<p><i>[Copenhagen: Dave Abrahams provided this wording]</i></p>
12994
12995
12996<p><i>[Redmond: Minor changes in wording.  (Removed "non-negative", and
12997changed the "other than those described in" wording.) Also, the LWG
12998decided to accept the "optional" part.]</i></p>
12999
13000
13001
13002
13003<p><b>Rationale:</b></p>
13004<p>The proposed resolution reinterprets binary search. Instead of
13005thinking about searching for a value in a sorted range, we view that
13006as an important special case of a more general algorithm: searching
13007for the partition point in a partitioned range.</p>
13008
13009<p>We also add a guarantee that the old wording did not: we ensure
13010that the upper bound is no earlier than the lower bound, that
13011the pair returned by equal_range is a valid range, and that the first
13012part of that pair is the lower bound.</p>
13013
13014
13015
13016
13017
13018<hr>
13019<h3><a name="271"></a>271. basic_iostream missing typedefs</h3>
13020<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>
13021 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-11-02  <b>Last modified:</b> 2008-09-26</p>
13022<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
13023<p><b>Discussion:</b></p>
13024<p>
13025Class template basic_iostream has no typedefs.  The typedefs it
13026inherits from its base classes can't be used, since (for example)
13027basic_iostream&lt;T&gt;::traits_type is ambiguous.
13028</p>
13029
13030
13031<p><b>Proposed resolution:</b></p>
13032
13033<p>Add the following to basic_iostream's class synopsis in 
1303427.7.1.5 [iostreamclass], immediately after <tt>public</tt>:</p>
13035
13036<pre>  // types:
13037  typedef charT                     char_type;
13038  typedef typename traits::int_type int_type;
13039  typedef typename traits::pos_type pos_type;
13040  typedef typename traits::off_type off_type;
13041  typedef traits                    traits_type;
13042</pre>
13043
13044
13045
13046
13047<hr>
13048<h3><a name="272"></a>272. Missing parentheses around subexpression</h3>
13049<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>
13050 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-11-02  <b>Last modified:</b> 2008-09-26</p>
13051<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>
13052<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
13053<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#569">569</a></p>
13054<p><b>Discussion:</b></p>
13055<p>
1305627.4.4.3, p4 says about the postcondition of the function: If
13057rdbuf()!=0 then state == rdstate(); otherwise
13058rdstate()==state|ios_base::badbit.
13059</p>
13060
13061<p>
13062The expression on the right-hand-side of the operator==() needs to be
13063parenthesized in order for the whole expression to ever evaluate to
13064anything but non-zero.
13065</p>
13066
13067
13068<p><b>Proposed resolution:</b></p>
13069<p>
13070Add parentheses like so: rdstate()==(state|ios_base::badbit).
13071</p>
13072
13073
13074
13075
13076<hr>
13077<h3><a name="273"></a>273. Missing ios_base qualification on members of a dependent class</h3>
13078<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>
13079 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-11-02  <b>Last modified:</b> 2008-09-26</p>
13080<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>
13081<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
13082<p><b>Discussion:</b></p>
13083<p>27.5.2.4.2, p4, and 27.8.1.6, p2, 27.8.1.7, p3, 27.8.1.9, p2,
1308427.8.1.10, p3 refer to in and/or out w/o ios_base:: qualification.
13085That's incorrect since the names are members of a dependent base
13086class (14.6.2 [temp.dep]) and thus not visible.</p>
13087
13088
13089<p><b>Proposed resolution:</b></p>
13090<p>Qualify the names with the name of the class of which they are
13091members, i.e., ios_base.</p>
13092
13093
13094
13095
13096<hr>
13097<h3><a name="274"></a>274. a missing/impossible allocator requirement</h3>
13098<p><b>Section:</b> 20.2.2 [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
13099 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-11-02  <b>Last modified:</b> 2008-09-26</p>
13100<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>
13101<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
13102<p><b>Discussion:</b></p>
13103<p>
13104I see that table 31 in 20.1.5, p3 allows T in std::allocator&lt;T&gt; to be of
13105any type. But the synopsis in 20.4.1 calls for allocator&lt;&gt;::address() to
13106be overloaded on reference and const_reference, which is ill-formed for
13107all T = const U. In other words, this won't work:
13108</p>
13109
13110<p>
13111template class std::allocator&lt;const int&gt;;
13112</p>
13113
13114<p>
13115The obvious solution is to disallow specializations of allocators on
13116const types. However, while containers' elements are required to be
13117assignable (which rules out specializations on const T's), I think that
13118allocators might perhaps be potentially useful for const values in other
13119contexts. So if allocators are to allow const types a partial
13120specialization of std::allocator&lt;const T&gt; would probably have to be
13121provided.
13122</p>
13123
13124
13125<p><b>Proposed resolution:</b></p>
13126<p>Change the text in row 1, column 2 of table 32 in 20.1.5, p3 from</p>
13127
13128    <blockquote><p>
13129    any type
13130    </p></blockquote>
13131
13132<p>to</p>
13133    <blockquote><p>
13134    any non-const, non-reference type
13135    </p></blockquote>
13136
13137<p><i>[Redmond: previous proposed resolution was "any non-const,
13138non-volatile, non-reference type".  Got rid of the "non-volatile".]</i></p>
13139
13140
13141
13142
13143<p><b>Rationale:</b></p>
13144<p>
13145Two resolutions were originally proposed: one that partially
13146specialized std::allocator for const types, and one that said an
13147allocator's value type may not be const.  The LWG chose the second.
13148The first wouldn't be appropriate, because allocators are intended for
13149use by containers, and const value types don't work in containers.
13150Encouraging the use of allocators with const value types would only
13151lead to unsafe code.
13152</p>
13153<p>
13154The original text for proposed resolution 2 was modified so that it
13155also forbids volatile types and reference types.
13156</p>
13157
13158<p><i>[Cura�ao: LWG double checked and believes volatile is correctly
13159excluded from the PR.]</i></p>
13160
13161
13162
13163
13164
13165
13166
13167<hr>
13168<h3><a name="275"></a>275. Wrong type in num_get::get() overloads</h3>
13169<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>
13170 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2000-11-02  <b>Last modified:</b> 2008-09-26</p>
13171<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>
13172<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
13173<p><b>Discussion:</b></p>
13174<p>
13175In 22.2.2.1.1, we have a list of overloads for num_get&lt;&gt;::get().
13176There are eight overloads, all of which are identical except for the
13177last parameter.  The overloads are: 
13178</p>
13179<ul>
13180<li> long&amp; </li>
13181<li> unsigned short&amp; </li>
13182<li> unsigned int&amp; </li>
13183<li> unsigned long&amp; </li>
13184<li> short&amp; </li>
13185<li> double&amp; </li>
13186<li> long double&amp; </li>
13187<li> void*&amp; </li>
13188</ul>
13189
13190<p>
13191There is a similar list, in 22.2.2.1.2, of overloads for
13192num_get&lt;&gt;::do_get().  In this list, the last parameter has
13193the types: 
13194</p>
13195<ul>
13196<li> long&amp; </li>
13197<li> unsigned short&amp; </li>
13198<li> unsigned int&amp; </li>
13199<li> unsigned long&amp; </li>
13200<li> float&amp; </li>
13201<li> double&amp; </li>
13202<li> long double&amp; </li>
13203<li> void*&amp; </li>
13204</ul>
13205
13206<p>
13207These two lists are not identical.  They should be, since
13208<tt>get</tt> is supposed to call <tt>do_get</tt> with exactly
13209the arguments it was given.
13210</p>
13211
13212
13213<p><b>Proposed resolution:</b></p>
13214<p>In 22.4.2.1.1 [facet.num.get.members], change</p>
13215<pre>  iter_type get(iter_type in, iter_type end, ios_base&amp; str,
13216                ios_base::iostate&amp; err, short&amp; val) const;
13217</pre>
13218<p>to</p>
13219<pre>  iter_type get(iter_type in, iter_type end, ios_base&amp; str,
13220                ios_base::iostate&amp; err, float&amp; val) const;
13221</pre>
13222
13223
13224
13225
13226<hr>
13227<h3><a name="276"></a>276. Assignable requirement for container value type overly strict</h3>
13228<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>
13229 <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2000-11-07  <b>Last modified:</b> 2008-09-26</p>
13230<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>
13231<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>
13232<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
13233<p><b>Discussion:</b></p>
13234<p>
1323523.1/3 states that the objects stored in a container must be
13236Assignable.  23.4.1 [map], paragraph 2,
13237states that map satisfies all requirements for a container, while in
13238the same time defining value_type as pair&lt;const Key, T&gt; - a type
13239that is not Assignable.
13240</p>
13241
13242<p>
13243It should be noted that there exists a valid and non-contradictory
13244interpretation of the current text. The wording in 23.1/3 avoids 
13245mentioning value_type, referring instead to "objects stored in a
13246container." One might argue that map does not store objects of
13247type map::value_type, but of map::mapped_type instead, and that the
13248Assignable requirement applies to map::mapped_type, not
13249map::value_type.
13250</p>
13251
13252<p>
13253However, this makes map a special case (other containers store objects of
13254type value_type) and the Assignable requirement is needlessly restrictive in
13255general.
13256</p>
13257
13258<p>
13259For example, the proposed resolution of active library issue 
13260<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#103">103</a> is to make set::iterator a constant iterator; this
13261means that no set operations can exploit the fact that the stored
13262objects are Assignable.
13263</p>
13264
13265<p>
13266This is related to, but slightly broader than, closed issue
13267<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a>.
13268</p>
13269
13270
13271<p><b>Proposed resolution:</b></p>
13272<p>23.1/3: Strike the trailing part of the sentence:</p>
13273    <blockquote><p>
13274    , and the additional requirements of Assignable types from 23.1/3
13275    </p></blockquote>
13276<p>so that it reads:</p>
13277    <blockquote><p>
13278    -3- The type of objects stored in these components must meet the 
13279    requirements of CopyConstructible types (lib.copyconstructible).
13280    </p></blockquote>
13281
13282<p>23.1/4: Modify to make clear that this requirement is not for all 
13283containers.  Change to:</p>
13284
13285<blockquote><p>
13286-4- Table 64 defines the Assignable requirement.  Some containers 
13287require this property of the types to be stored in the container.  T is 
13288the type used to instantiate the container. t is a value of T, and u is 
13289a value of (possibly const) T.
13290</p></blockquote>
13291
13292<p>23.1, Table 65: in the first row, change "T is Assignable" to "T is
13293CopyConstructible".</p>
13294
13295<p>23.2.1/2: Add sentence for Assignable requirement.  Change to:</p>
13296
13297<blockquote><p>
13298-2- A deque satisfies all of the requirements of a container and of a 
13299reversible container (given in tables in lib.container.requirements) and 
13300of a sequence, including the optional sequence requirements 
13301(lib.sequence.reqmts).  In addition to the requirements on the stored 
13302object described in 23.1[lib.container.requirements], the stored object 
13303must also meet the requirements of Assignable.  Descriptions are 
13304provided here only for operations on deque that are not described in one 
13305of these tables or for operations where there is additional semantic 
13306information.
13307</p></blockquote>
13308
13309<p>23.2.2/2:  Add Assignable requirement to specific methods of list.  
13310Change to:</p>
13311
13312<blockquote>
13313<p>-2- A list satisfies all of the requirements of a container and of a 
13314reversible container (given in two tables in lib.container.requirements) 
13315and of a sequence, including most of the the optional sequence 
13316requirements (lib.sequence.reqmts). The exceptions are the operator[] 
13317and at member functions, which are not provided. 
13318
13319[Footnote: These member functions are only provided by containers whose 
13320iterators are random access iterators. --- end foonote]
13321</p>
13322
13323<p>list does not require the stored type T to be Assignable unless the 
13324following methods are instantiated:
13325
13326[Footnote: Implementors are permitted but not required to take advantage 
13327of T's Assignable properties for these methods. -- end foonote]
13328</p>
13329<pre>     list&lt;T,Allocator&gt;&amp; operator=(const list&lt;T,Allocator&gt;&amp;  x );
13330     template &lt;class InputIterator&gt;
13331       void assign(InputIterator first, InputIterator last);
13332     void assign(size_type n, const T&amp; t);
13333</pre>
13334
13335
13336<p>Descriptions are provided here only for operations on list that are not 
13337described in one of these tables or for operations where there is 
13338additional semantic information.</p>
13339</blockquote>
13340
13341<p>23.2.4/2:   Add sentence for Assignable requirement.  Change to:</p>
13342
13343<blockquote><p>
13344-2- A vector satisfies all of the requirements of a container and of a 
13345reversible container (given in two tables in lib.container.requirements) 
13346and of a sequence, including most of the optional sequence requirements 
13347(lib.sequence.reqmts). The exceptions are the push_front and pop_front 
13348member functions, which are not provided.  In addition to the 
13349requirements on the stored object described in 
1335023.1[lib.container.requirements], the stored object must also meet the 
13351requirements of Assignable.  Descriptions are provided here only for 
13352operations on vector that are not described in one of these tables or 
13353for operations where there is additional semantic information.
13354</p></blockquote>
13355
13356
13357<p><b>Rationale:</b></p>
13358<p>list, set, multiset, map, multimap are able to store non-Assignables.
13359However, there is some concern about <tt>list&lt;T&gt;</tt>:
13360although in general there's no reason for T to be Assignable, some
13361implementations of the member functions <tt>operator=</tt> and
13362<tt>assign</tt> do rely on that requirement.  The LWG does not want
13363to forbid such implementations.</p>
13364
13365<p>Note that the type stored in a standard container must still satisfy
13366the requirements of the container's allocator; this rules out, for
13367example, such types as "const int".  See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#274">274</a>
13368for more details.
13369</p>
13370
13371<p>In principle we could also relax the "Assignable" requirement for
13372individual <tt>vector</tt> member functions, such as
13373<tt>push_back</tt>.  However, the LWG did not see great value in such
13374selective relaxation.  Doing so would remove implementors' freedom to
13375implement <tt>vector::push_back</tt> in terms of
13376<tt>vector::insert</tt>.</p>
13377
13378
13379
13380
13381
13382<hr>
13383<h3><a name="278"></a>278. What does iterator validity mean?</h3>
13384<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>
13385 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2000-11-27  <b>Last modified:</b> 2008-09-30</p>
13386<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#list.ops">active issues</a> in [list.ops].</p>
13387<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>
13388<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
13389<p><b>Discussion:</b></p>
13390<p>
13391Section 23.3.4.4 [list.ops] states that
13392</p>
13393<pre>  void splice(iterator position, list&lt;T, Allocator&gt;&amp; x);
13394</pre>
13395<p>
13396<i>invalidates</i> all iterators and references to list <tt>x</tt>.
13397</p>
13398
13399<p>
13400But what does the C++ Standard mean by "invalidate"?  You
13401can still dereference the iterator to a spliced list element, but
13402you'd better not use it to delimit a range within the original
13403list. For the latter operation, it has definitely lost some of its
13404validity.
13405</p>
13406
13407<p>
13408If we accept the proposed resolution to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#250">250</a>,
13409then we'd better clarify that a "valid" iterator need no
13410longer designate an element within the same container as it once did.
13411We then have to clarify what we mean by invalidating a past-the-end
13412iterator, as when a vector or string grows by reallocation. Clearly,
13413such an iterator has a different kind of validity. Perhaps we should
13414introduce separate terms for the two kinds of "validity."
13415</p>
13416
13417
13418<p><b>Proposed resolution:</b></p>
13419<p>Add the following text to the end of section X [iterator.concepts],
13420after paragraph 5:</p>
13421<blockquote><p>
13422An <i>invalid</i> iterator is an iterator that may be
13423singular. [Footnote: This definition applies to pointers, since
13424pointers are iterators. The effect of dereferencing an iterator that
13425has been invalidated is undefined.]
13426</p></blockquote>
13427
13428<p><i>[post-Copenhagen: Matt provided wording.]</i></p>
13429
13430
13431<p><i>[Redmond: General agreement with the intent, some objections to
13432the wording.  Dave provided new wording.]</i></p>
13433
13434
13435
13436<p><b>Rationale:</b></p>
13437<p>This resolution simply defines a term that the Standard uses but
13438  never defines, "invalid", in terms of a term that is defined,
13439  "singular".</p>
13440
13441<p>Why do we say "may be singular", instead of "is singular"?  That's
13442  becuase a valid iterator is one that is known to be nonsingular.
13443  Invalidating an iterator means changing it in such a way that it's
13444  no longer known to be nonsingular.  An example: inserting an
13445  element into the middle of a vector is correctly said to invalidate
13446  all iterators pointing into the vector.  That doesn't necessarily
13447  mean they all become singular.</p>
13448
13449
13450
13451
13452
13453<hr>
13454<h3><a name="280"></a>280. Comparison of reverse_iterator to const reverse_iterator</h3>
13455<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>
13456 <b>Submitter:</b> Steve Cleary <b>Opened:</b> 2000-11-27  <b>Last modified:</b> 2008-09-26</p>
13457<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
13458<p><b>Discussion:</b></p>
13459<p>
13460This came from an email from Steve Cleary to Fergus in reference to
13461issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#179">179</a>. The library working group briefly discussed
13462this in Toronto and believed it should be a separate issue.  There was
13463also some reservations about whether this was a worthwhile problem to
13464fix.
13465</p>
13466
13467<p>
13468Steve said: "Fixing reverse_iterator. std::reverse_iterator can
13469(and should) be changed to preserve these additional
13470requirements." He also said in email that it can be done without
13471breaking user's code: "If you take a look at my suggested
13472solution, reverse_iterator doesn't have to take two parameters; there
13473is no danger of breaking existing code, except someone taking the
13474address of one of the reverse_iterator global operator functions, and
13475I have to doubt if anyone has ever done that. . .  <i>But</i>, just in
13476case they have, you can leave the old global functions in as well --
13477they won't interfere with the two-template-argument functions.  With
13478that, I don't see how <i>any</i> user code could break."
13479</p>
13480
13481
13482<p><b>Proposed resolution:</b></p>
13483<p>
13484<b>Section:</b> 24.5.1.1 [reverse.iterator]
13485add/change the following declarations:</p>
13486<pre>  A) Add a templated assignment operator, after the same manner
13487        as the templated copy constructor, i.e.:
13488
13489  template &lt; class U &gt;
13490  reverse_iterator &lt; Iterator &gt;&amp; operator=(const reverse_iterator&lt; U &gt;&amp; u);
13491
13492  B) Make all global functions (except the operator+) have
13493  two template parameters instead of one, that is, for
13494  operator ==, !=, &lt;, &gt;, &lt;=, &gt;=, - replace:
13495
13496       template &lt; class Iterator &gt;
13497       typename reverse_iterator&lt; Iterator &gt;::difference_type operator-(
13498                 const reverse_iterator&lt; Iterator &gt;&amp; x,
13499                 const reverse_iterator&lt; Iterator &gt;&amp; y);
13500
13501  with:
13502
13503      template &lt; class Iterator1, class Iterator2 &gt;
13504      typename reverse_iterator &lt; Iterator1 &gt;::difference_type operator-(
13505                 const reverse_iterator &lt; Iterator1 &gt; &amp; x,
13506                 const reverse_iterator &lt; Iterator2 &gt; &amp; y);
13507</pre>
13508<p>
13509Also make the addition/changes for these signatures in 
1351024.5.1.3 [reverse.iter.ops].
13511</p>
13512
13513<p><i>[
13514Copenhagen: The LWG is concerned that the proposed resolution 
13515introduces new overloads.  Experience shows that introducing
13516overloads is always risky, and that it would be inappropriate to
13517make this change without implementation experience.  It may be
13518desirable to provide this feature in a different way.
13519]</i></p>
13520
13521
13522<p><i>[
13523Lillehammer: We now have implementation experience, and agree that
13524this solution is safe and correct.
13525]</i></p>
13526
13527
13528
13529
13530
13531
13532
13533<hr>
13534<h3><a name="281"></a>281. std::min() and max() requirements overly restrictive</h3>
13535<p><b>Section:</b> 25.4.7 [alg.min.max] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
13536 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-12-02  <b>Last modified:</b> 2008-09-26</p>
13537<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>
13538<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
13539<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#486">486</a></p>
13540<p><b>Discussion:</b></p>
13541<p>The requirements in 25.3.7, p1 and 4 call for T to satisfy the
13542requirements of <tt>LessThanComparable</tt> ( [lessthancomparable])
13543and <tt>CopyConstructible</tt> (20.2.1 [utility.arg.requirements]).
13544Since the functions take and return their arguments and result by
13545const reference, I believe the <tt>CopyConstructible</tt> requirement
13546is unnecessary.
13547</p>
13548
13549
13550<p><b>Proposed resolution:</b></p>
13551<p>Remove the <tt>CopyConstructible</tt> requirement. Specifically, replace
1355225.3.7, p1 with</p>
13553<p><b>-1- Requires:</b> Type T is <tt>LessThanComparable</tt> 
13554( [lessthancomparable]).
13555</p>
13556<p>and replace 25.3.7, p4 with</p>
13557<p><b>-4- Requires:</b> Type T is <tt>LessThanComparable</tt> 
13558( [lessthancomparable]).
13559</p>
13560
13561
13562
13563
13564<hr>
13565<h3><a name="282"></a>282. What types does numpunct grouping refer to?</h3>
13566<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>
13567 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2000-12-05  <b>Last modified:</b> 2008-09-26</p>
13568<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#facet.num.put.virtuals">active issues</a> in [facet.num.put.virtuals].</p>
13569<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>
13570<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
13571<p><b>Discussion:</b></p>
13572<p>
13573Paragraph 16 mistakenly singles out integral types for inserting 
13574thousands_sep() characters.  This conflicts with the syntax for floating 
13575point numbers described under 22.2.3.1/2.
13576</p>
13577
13578
13579<p><b>Proposed resolution:</b></p>
13580<p>Change paragraph 16 from:</p>
13581
13582<blockquote><p>
13583For integral types, punct.thousands_sep() characters are inserted into 
13584the sequence as determined by the value returned by punct.do_grouping() 
13585using the method described in 22.4.3.1.2 [facet.numpunct.virtuals].
13586</p></blockquote>
13587
13588<p>To:</p>
13589
13590<blockquote><p>
13591For arithmetic types, punct.thousands_sep() characters are inserted into 
13592the sequence as determined by the value returned by punct.do_grouping() 
13593using the method described in 22.4.3.1.2 [facet.numpunct.virtuals].
13594</p></blockquote>
13595
13596<p><i>[
13597Copenhagen: Opinions were divided about whether this is actually an
13598inconsistency, but at best it seems to have been unintentional.  This
13599is only an issue for floating-point output: The standard is
13600unambiguous that implementations must parse thousands_sep characters
13601when performing floating-point.  The standard is also unambiguous that
13602this requirement does not apply to the "C" locale.
13603]</i></p>
13604
13605
13606<p><i>[
13607A survey of existing practice is needed; it is believed that some
13608implementations do insert thousands_sep characters for floating-point
13609output and others fail to insert thousands_sep characters for 
13610floating-point input even though this is unambiguously required by the
13611standard.
13612]</i></p>
13613
13614
13615<p><i>[Post-Cura�ao: the above proposed resolution is the consensus of
13616Howard, Bill, Pete, Benjamin, Nathan, Dietmar, Boris, and Martin.]</i></p>
13617
13618
13619
13620
13621
13622
13623<hr>
13624<h3><a name="283"></a>283. std::replace() requirement incorrect/insufficient</h3>
13625<p><b>Section:</b> 25.3.5 [alg.replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
13626 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-12-15  <b>Last modified:</b> 2008-09-26</p>
13627<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>
13628<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
13629<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#483">483</a></p>
13630<p><b>Discussion:</b></p>
13631<p>
13632(revision of the further discussion)
13633There are a number of problems with the requires clauses for the
13634algorithms in 25.1 and 25.2. The requires clause of each algorithm
13635should describe the necessary and sufficient requirements on the inputs
13636to the algorithm such that the algorithm compiles and runs properly.
13637Many of the requires clauses fail to do this. Here is a summary of the kinds
13638of mistakes:
13639</p>
13640
13641<ol>
13642<li>
13643Use of EqualityComparable, which only puts requirements on a single
13644type, when in fact an equality operator is required between two
13645different types, typically either T and the iterator's value type
13646or between the value types of two different iterators.
13647</li>
13648<li>
13649Use of Assignable for T when in fact what was needed is Assignable
13650for the value_type of the iterator, and convertability from T to the
13651value_type of the iterator. Or for output iterators, the requirement
13652should be that T is writable to the iterator (output iterators do
13653not have value types).
13654</li>
13655</ol>
13656
13657<p>
13658Here is the list of algorithms that contain mistakes:
13659</p>
13660
13661<ul>
13662<li>25.1.2 std::find</li>
13663<li>25.1.6 std::count</li>
13664<li>25.1.8 std::equal</li>
13665<li>25.1.9 std::search, std::search_n</li>
13666<li>25.2.4 std::replace, std::replace_copy</li>
13667<li>25.2.5 std::fill</li>
13668<li>25.2.7 std::remove, std::remove_copy</li>
13669</ul>
13670
13671<p>
13672Also, in the requirements for EqualityComparable, the requirement that
13673the operator be defined for const objects is lacking.
13674</p>
13675
13676
13677
13678<p><b>Proposed resolution:</b></p>
13679
13680<p>20.1.1 Change p1 from</p>
13681
13682<p>In Table 28, <tt>T</tt> is a type to be supplied by a C++ program
13683instantiating a template, <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> are
13684values of type <tt>T</tt>.
13685</p>
13686
13687<p>to</p>
13688
13689<p>
13690In Table 28, <tt>T</tt> is a type to be supplied by a C++ program
13691instantiating a template, <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> are
13692values of type <tt>const T</tt>.
13693</p>
13694
13695<p>25 Between p8 and p9</p>
13696
13697<p>Add the following sentence:</p>
13698
13699<p>When the description of an algorithm gives an expression such as
13700<tt>*first == value</tt> for a condition, it is required that the expression
13701evaluate to either true or false in boolean contexts.</p>
13702
13703<p>25.1.2 Change p1 by deleting the requires clause.</p>
13704
13705<p>25.1.6 Change p1 by deleting the requires clause.</p>
13706
13707<p>25.1.9</p>
13708
13709<p>Change p4 from</p>
13710
13711<p>-4- Requires: Type <tt>T</tt> is <tt>EqualityComparable</tt>
13712(20.1.1), type Size is convertible to integral type (4.7.12.3).
13713</p>
13714
13715<p>to</p>
13716
13717<p>-4- Requires: The type <tt>Size</tt> is convertible to integral
13718type (4.7.12.3).</p>
13719
13720<p>25.2.4 Change p1 from</p>
13721
13722<p>-1- Requires: Type <tt>T</tt> is <tt>Assignable</tt> (23.1 ) (and, for <tt>replace()</tt>, <tt>EqualityComparable</tt> (20.1.1 )).</p>
13723
13724<p>to</p>
13725
13726<p>-1- Requires: The expression <tt>*first = new_value</tt> must be valid.</p>
13727
13728<p>and change p4 from</p>
13729
13730<p>-4- Requires: Type <tt>T</tt> is <tt>Assignable</tt> (23.1) (and,
13731for <tt>replace_copy()</tt>, <tt>EqualityComparable</tt>
13732(20.1.1)). The ranges <tt>[first, last)</tt> and <tt>[result, result +
13733(last - first))</tt> shall not overlap.</p>
13734
13735<p>to</p>
13736
13737<p>-4- Requires: The results of the expressions <tt>*first</tt> and
13738<tt>new_value</tt> must be writable to the result output iterator. The
13739ranges <tt>[first, last)</tt> and <tt>[result, result + (last -
13740first))</tt> shall not overlap.</p>
13741
13742
13743<p>25.2.5 Change p1 from</p>
13744
13745<p>-1- Requires: Type <tt>T</tt> is <tt>Assignable</tt> (23.1). The
13746type <tt>Size</tt> is convertible to an integral type (4.7.12.3).</p>
13747
13748<p>to</p>
13749
13750<p>-1- Requires: The expression <tt>value</tt> must be is writable to
13751the output iterator. The type <tt>Size</tt> is convertible to an
13752integral type (4.7.12.3).</p>
13753
13754<p>25.2.7 Change p1 from</p>
13755
13756<p>-1- Requires: Type <tt>T</tt> is <tt>EqualityComparable</tt> (20.1.1).</p>
13757
13758<p>to</p>
13759
13760<p>
13761-1- Requires: The value type of the iterator must be
13762<tt>Assignable</tt> (23.1).
13763</p>
13764
13765
13766
13767<p><b>Rationale:</b></p>
13768<p>
13769The general idea of the proposed solution is to remove the faulty
13770requires clauses and let the returns and effects clauses speak for
13771themselves. That is, the returns clauses contain expressions that must
13772be valid, and therefore already imply the correct requirements. In
13773addition, a sentence is added at the beginning of chapter 25 saying
13774that expressions given as conditions must evaluate to true or false in
13775a boolean context. An alternative would be to say that the type of
13776these condition expressions must be literally bool, but that would be
13777imposing a greater restriction that what the standard currently says
13778(which is convertible to bool).
13779</p>
13780
13781
13782
13783
13784
13785<hr>
13786<h3><a name="284"></a>284. unportable example in 20.3.7, p6</h3>
13787<p><b>Section:</b> 20.7.7 [comparisons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
13788 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-12-26  <b>Last modified:</b> 2008-09-26</p>
13789<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
13790<p><b>Discussion:</b></p>
13791<p>The example in 20.7.7 [comparisons], p6 shows how to use the C
13792library function <tt>strcmp()</tt> with the function pointer adapter
13793<tt>ptr_fun()</tt>. But since it's unspecified whether the C library
13794functions have <tt>extern "C"</tt> or <tt>extern
13795"C++"</tt> linkage [17.6.2.3 [using.linkage]], and since
13796function pointers with different the language linkage specifications
13797(7.5 [dcl.link]) are incompatible, whether this example is
13798well-formed is unspecified.
13799</p>
13800
13801
13802<p><b>Proposed resolution:</b></p>
13803<p>Change 20.7.7 [comparisons] paragraph 6 from:</p>
13804<blockquote>
13805  <p>[<i>Example:</i></p>
13806  <pre>    replace_if(v.begin(), v.end(), not1(bind2nd(ptr_fun(strcmp), "C")), "C++");
13807  </pre>
13808  <p>replaces each <tt>C</tt> with <tt>C++</tt> in sequence <tt>v</tt>.</p>
13809</blockquote>
13810
13811
13812<p>to:</p>
13813<blockquote>
13814  <p>[<i>Example:</i></p>
13815  <pre>    int compare(const char*, const char*);
13816    replace_if(v.begin(), v.end(),
13817               not1(bind2nd(ptr_fun(compare), "abc")), "def");
13818  </pre>
13819  <p>replaces each <tt>abc</tt> with <tt>def</tt> in sequence <tt>v</tt>.</p>
13820</blockquote>
13821
13822<p>Also, remove footnote 215 in that same paragraph.</p>
13823
13824<p><i>[Copenhagen: Minor change in the proposed resolution.  Since this
13825issue deals in part with C and C++ linkage, it was believed to be too
13826confusing for the strings in the example to be "C" and "C++".
13827]</i></p>
13828
13829
13830<p><i>[Redmond: More minor changes.  Got rid of the footnote (which
13831seems to make a sweeping normative requirement, even though footnotes
13832aren't normative), and changed the sentence after the footnote so that
13833it corresponds to the new code fragment.]</i></p>
13834
13835
13836
13837
13838
13839
13840<hr>
13841<h3><a name="285"></a>285. minor editorial errors in fstream ctors</h3>
13842<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>
13843 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-12-31  <b>Last modified:</b> 2008-09-26</p>
13844<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
13845<p><b>Discussion:</b></p>
13846<p>27.9.1.7 [ifstream.cons], p2, 27.9.1.11 [ofstream.cons], p2, and
1384727.9.1.15 [fstream.cons], p2 say about the effects of each constructor:
13848</p>
13849
13850<p>... If that function returns a null pointer, calls
13851<tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt>).
13852</p>
13853
13854<p>The parenthetical note doesn't apply since the ctors cannot throw an
13855exception due to the requirement in 27.5.4.1 [basic.ios.cons], p3 
13856that <tt>exceptions()</tt> be initialized to <tt>ios_base::goodbit</tt>.
13857</p>
13858
13859
13860<p><b>Proposed resolution:</b></p>
13861<p>
13862Strike the parenthetical note from the Effects clause in each of the
13863paragraphs mentioned above.
13864</p>
13865
13866
13867
13868
13869<hr>
13870<h3><a name="286"></a>286. &lt;cstdlib&gt; requirements missing size_t typedef</h3>
13871<p><b>Section:</b> 25.5 [alg.c.library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
13872 <b>Submitter:</b> Judy Ward <b>Opened:</b> 2000-12-30  <b>Last modified:</b> 2008-09-26</p>
13873<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>
13874<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
13875<p><b>Discussion:</b></p>
13876<p>
13877The &lt;cstdlib&gt; header file contains prototypes for bsearch and
13878qsort (C++ Standard section 25.4 paragraphs 3 and 4) and other
13879prototypes (C++ Standard section 21.4 paragraph 1 table 49) that
13880require the typedef size_t. Yet size_t is not listed in the
13881&lt;cstdlib&gt; synopsis table 78 in section 25.4.
13882</p>
13883
13884
13885<p><b>Proposed resolution:</b></p>
13886<p>
13887Add the type size_t to Table 78 (section 25.4) and add
13888the type size_t &lt;cstdlib&gt; to Table 97 (section C.2).
13889</p>
13890
13891
13892<p><b>Rationale:</b></p>
13893<p>Since size_t is in &lt;stdlib.h&gt;, it must also be in &lt;cstdlib&gt;.</p>
13894
13895
13896
13897
13898
13899<hr>
13900<h3><a name="288"></a>288. &lt;cerrno&gt; requirements missing macro EILSEQ</h3>
13901<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>
13902 <b>Submitter:</b> Judy Ward <b>Opened:</b> 2000-12-30  <b>Last modified:</b> 2008-09-26</p>
13903<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
13904<p><b>Discussion:</b></p>
13905<p>
13906ISO/IEC 9899:1990/Amendment1:1994 Section 4.3 States: "The list
13907of macros defined in &lt;errno.h&gt; is adjusted to include a new
13908macro, EILSEQ"
13909</p>
13910
13911<p>
13912ISO/IEC 14882:1998(E) section 19.3 does not refer
13913to the above amendment.
13914</p>
13915
13916
13917
13918<p><b>Proposed resolution:</b></p>
13919<p>
13920Update Table 26 (section 19.3) "Header  &lt;cerrno&gt; synopsis"
13921and Table 95 (section C.2) "Standard Macros" to include EILSEQ.
13922</p>
13923
13924
13925
13926
13927
13928<hr>
13929<h3><a name="291"></a>291. Underspecification of set algorithms</h3>
13930<p><b>Section:</b> 25.4.5 [alg.set.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
13931 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2001-01-03  <b>Last modified:</b> 2008-09-26</p>
13932<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>
13933<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
13934<p><b>Discussion:</b></p>
13935<p>
13936The standard library contains four algorithms that compute set
13937operations on sorted ranges: <tt>set_union</tt>, <tt>set_intersection</tt>,
13938<tt>set_difference</tt>, and <tt>set_symmetric_difference</tt>.  Each
13939of these algorithms takes two sorted ranges as inputs, and writes the
13940output of the appropriate set operation to an output range.  The elements
13941in the output range are sorted.
13942</p>
13943
13944<p>
13945The ordinary mathematical definitions are generalized so that they
13946apply to ranges containing multiple copies of a given element.  Two
13947elements are considered to be "the same" if, according to an
13948ordering relation provided by the user, neither one is less than the
13949other.  So, for example, if one input range contains five copies of an
13950element and another contains three, the output range of <tt>set_union</tt>
13951will contain five copies, the output range of
13952<tt>set_intersection</tt> will contain three, the output range of
13953<tt>set_difference</tt> will contain two, and the output range of
13954<tt>set_symmetric_difference</tt> will contain two.
13955</p>
13956
13957<p>
13958Because two elements can be "the same" for the purposes
13959of these set algorithms, without being identical in other respects
13960(consider, for example, strings under case-insensitive comparison),
13961this raises a number of unanswered questions:
13962</p>
13963
13964<ul>
13965<li>If we're copying an element that's present in both of the
13966input ranges, which one do we copy it from?</li>
13967<li>If there are <i>n</i> copies of an element in the relevant
13968input range, and the output range will contain fewer copies (say
13969<i>m</i>) which ones do we choose?  The first <i>m</i>, or the last
13970<i>m</i>, or something else?</li>
13971<li>Are these operations stable?  That is, does a run of equivalent
13972elements appear in the output range in the same order as as it
13973appeared in the input range(s)?</li>
13974</ul>
13975
13976<p>
13977The standard should either answer these questions, or explicitly
13978say that the answers are unspecified.  I prefer the former option,
13979since, as far as I know, all existing implementations behave the
13980same way.
13981</p>
13982
13983
13984
13985<p><b>Proposed resolution:</b></p>
13986
13987<p>Add the following to the end of 25.4.5.2 [set.union] paragraph 5:</p>
13988<blockquote><p>
13989If [first1, last1) contains <i>m</i> elements that are equivalent to
13990each other and [first2, last2) contains <i>n</i> elements that are
13991equivalent to them, then max(<i>m</i>, <i>n</i>) of these elements
13992will be copied to the output range: all <i>m</i> of these elements
13993from [first1, last1), and the last max(<i>n-m</i>, 0) of them from
13994[first2, last2), in that order.
13995</p></blockquote>
13996
13997<p>Add the following to the end of 25.4.5.3 [set.intersection] paragraph 5:</p>
13998<blockquote><p>
13999If [first1, last1) contains <i>m</i> elements that are equivalent to each
14000other and [first2, last2) contains <i>n</i> elements that are
14001equivalent to them, the first min(<i>m</i>, <i>n</i>) of those 
14002elements from [first1, last1) are copied to the output range.
14003</p></blockquote>
14004
14005<p>Add a new paragraph, <b>Notes</b>, after 25.4.5.4 [set.difference]
14006paragraph 4:</p>
14007<blockquote><p>
14008If [first1, last1) contains <i>m</i> elements that are equivalent to each
14009other and [first2, last2) contains <i>n</i> elements that are
14010equivalent to them, the last max(<i>m-n</i>, 0) elements from 
14011[first1, last1) are copied to the output range.
14012</p></blockquote>
14013
14014<p>Add a new paragraph, <b>Notes</b>, after 25.4.5.5 [set.symmetric.difference]
14015paragraph 4:</p>
14016<blockquote><p>
14017If [first1, last1) contains <i>m</i> elements that are equivalent to
14018each other and [first2, last2) contains <i>n</i> elements that are
14019equivalent to them, then |<i>m - n</i>| of those elements will be
14020copied to the output range: the last <i>m - n</i> of these elements
14021from [first1, last1) if <i>m</i> &gt; <i>n</i>, and the last <i>n -
14022m</i> of these elements from [first2, last2) if <i>m</i> &lt; <i>n</i>.
14023</p></blockquote>
14024
14025<p><i>[Santa Cruz: it's believed that this language is clearer than
14026  what's in the Standard.  However, it's also believed that the
14027  Standard may already make these guarantees (although not quite in
14028  these words).  Bill and Howard will check and see whether they think
14029  that some or all of these changes may be redundant.  If so, we may
14030  close this issue as NAD.]</i></p>
14031
14032
14033
14034
14035<p><b>Rationale:</b></p>
14036<p>For simple cases, these descriptions are equivalent to what's
14037  already in the Standard.  For more complicated cases, they describe
14038  the behavior of existing implementations.</p>
14039
14040
14041
14042
14043
14044<hr>
14045<h3><a name="292"></a>292. effects of a.copyfmt (a)</h3>
14046<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>
14047 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-01-05  <b>Last modified:</b> 2008-09-26</p>
14048<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>
14049<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>
14050<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
14051<p><b>Discussion:</b></p>
14052<p>The Effects clause of the member function <tt>copyfmt()</tt> in
1405327.4.4.2, p15 doesn't consider the case where the left-hand side
14054argument is identical to the argument on the right-hand side, that is
14055<tt>(this == &amp;rhs)</tt>.  If the two arguments are identical there
14056is no need to copy any of the data members or call any callbacks
14057registered with <tt>register_callback()</tt>.  Also, as Howard Hinnant
14058points out in message c++std-lib-8149 it appears to be incorrect to
14059allow the object to fire <tt>erase_event</tt> followed by
14060<tt>copyfmt_event</tt> since the callback handling the latter event
14061may inadvertently attempt to access memory freed by the former.
14062</p>
14063
14064
14065<p><b>Proposed resolution:</b></p>
14066<p>Change the Effects clause in 27.4.4.2, p15 from</p>
14067
14068<blockquote><p>
14069<b>-15- Effects:</b>Assigns to the member objects of <tt>*this</tt>
14070the corresponding member objects of <tt>rhs</tt>, except that...
14071</p></blockquote>
14072
14073<p>to</p>
14074
14075<blockquote><p>
14076<b>-15- Effects:</b>If <tt>(this == &amp;rhs)</tt> does nothing. Otherwise
14077assigns to the member objects of <tt>*this</tt> the corresponding member
14078objects of <tt>rhs</tt>, except that...
14079</p></blockquote>
14080
14081
14082
14083
14084<hr>
14085<h3><a name="294"></a>294. User defined macros and standard headers</h3>
14086<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>
14087 <b>Submitter:</b> James Kanze <b>Opened:</b> 2001-01-11  <b>Last modified:</b> 2008-09-26</p>
14088<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
14089<p><b>Discussion:</b></p>
14090<p>Paragraph 2 of 17.6.3.3.1 [macro.names] reads: "A
14091translation unit that includes a header shall not contain any macros
14092that define names declared in that header." As I read this, it
14093would mean that the following program is legal:</p>
14094
14095<pre>  #define npos 3.14
14096  #include &lt;sstream&gt;
14097</pre>
14098
14099<p>since npos is not defined in &lt;sstream&gt;.  It is, however, defined
14100in &lt;string&gt;, and it is hard to imagine an implementation in
14101which &lt;sstream&gt; didn't include &lt;string&gt;.</p>
14102
14103<p>I think that this phrase was probably formulated before it was
14104decided that a standard header may freely include other standard
14105headers.  The phrase would be perfectly appropriate for C, for
14106example.  In light of 17.6.4.2 [res.on.headers] paragraph 1, however,
14107it isn't stringent enough.</p>
14108
14109
14110<p><b>Proposed resolution:</b></p>
14111<p>For 17.6.3.3.1 [macro.names], replace the current wording, which reads:</p>
14112<blockquote>
14113     <p>Each name defined as a macro in a header is reserved to the
14114     implementation for any use if the translation unit includes
14115     the header.168)</p>
14116
14117     <p>A translation unit that includes a header shall not contain any
14118     macros that define names declared or defined in that header. Nor shall
14119     such a translation unit define macros for names lexically
14120     identical to keywords.</p>
14121
14122     <p>168) It is not permissible to remove a library macro definition by
14123     using the #undef directive.</p>
14124</blockquote>
14125
14126<p>with the wording:</p>
14127
14128<blockquote>
14129     <p>A translation unit that includes a standard library header shall not
14130     #define or #undef names declared in any standard library header.</p>
14131
14132     <p>A translation unit shall not #define or #undef names lexically
14133     identical to keywords.</p>
14134</blockquote>
14135
14136<p><i>[Lillehammer: Beman provided new wording]</i></p>
14137
14138
14139
14140
14141
14142
14143<hr>
14144<h3><a name="295"></a>295. Is abs defined in &lt;cmath&gt;?</h3>
14145<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>
14146 <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2001-01-12  <b>Last modified:</b> 2008-09-26</p>
14147<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>
14148<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
14149<p><b>Discussion:</b></p>
14150<p>
14151Table 80 lists the contents of the &lt;cmath&gt; header.  It does not
14152list <tt>abs()</tt>.  However, 26.5, paragraph 6, which lists added 
14153signatures present in &lt;cmath&gt;, does say that several overloads
14154of <tt>abs()</tt> should be defined in &lt;cmath&gt;.
14155</p>
14156
14157
14158<p><b>Proposed resolution:</b></p>
14159<p>
14160Add <tt>abs</tt> to Table 80.  Also, remove the parenthetical list
14161of functions "(abs(), div(), rand(), srand())" from 26.6 [numarray],
14162paragraph 1.
14163</p>
14164
14165<p><i>[Copenhagen: Modified proposed resolution so that it also gets
14166rid of that vestigial list of functions in paragraph 1.]</i></p>
14167
14168
14169
14170
14171<p><b>Rationale:</b></p>
14172<p>All this DR does is fix a typo; it's uncontroversial.  A 
14173separate question is whether we're doing the right thing in 
14174putting some overloads in &lt;cmath&gt; that we aren't also 
14175putting in &lt;cstdlib&gt;.  That's issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>.</p>
14176
14177
14178
14179
14180
14181<hr>
14182<h3><a name="297"></a>297. const_mem_fun_t&lt;&gt;::argument_type should be const T*</h3>
14183<p><b>Section:</b> 20.7.8 [logical.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
14184 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-01-06  <b>Last modified:</b> 2008-09-26</p>
14185<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
14186<p><b>Discussion:</b></p>
14187<p>The class templates <tt>const_mem_fun_t</tt> in 20.5.8, p8 and
14188<tt>const_mem_fun1_t</tt>
14189in 20.5.8, p9 derive from <tt>unary_function&lt;T*, S&gt;</tt>, and
14190<tt>binary_function&lt;T*,
14191A, S&gt;</tt>, respectively. Consequently, their <tt>argument_type</tt>, and
14192<tt>first_argument_type</tt>
14193members, respectively, are both defined to be <tt>T*</tt> (non-const).
14194However, their function call member operator takes a <tt>const T*</tt>
14195argument. It is my opinion that <tt>argument_type</tt> should be <tt>const
14196T*</tt> instead, so that one can easily refer to it in generic code. The
14197example below derived from existing code fails to compile due to the
14198discrepancy:
14199</p>
14200
14201<p><tt>template &lt;class T&gt;</tt>
14202<br><tt>void foo (typename T::argument_type arg)&nbsp;&nbsp; // #1</tt>
14203<br><tt>{</tt>
14204<br><tt>&nbsp;&nbsp;&nbsp; typename T::result_type (T::*pf) (typename
14205T::argument_type)
14206const =&nbsp;&nbsp; // #2</tt>
14207<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &amp;T::operator();</tt>
14208<br><tt>}</tt>
14209</p>
14210
14211<p><tt>struct X { /* ... */ };</tt></p>
14212
14213<p><tt>int main ()</tt>
14214<br><tt>{</tt>
14215<br><tt>&nbsp;&nbsp;&nbsp; const X x;</tt>
14216<br><tt>&nbsp;&nbsp;&nbsp; foo&lt;std::const_mem_fun_t&lt;void, X&gt;
14217&gt;(&amp;x);&nbsp;&nbsp;
14218// #3</tt>
14219<br><tt>}</tt>
14220</p>
14221
14222<p>#1 <tt>foo()</tt> takes a plain unqualified <tt>X*</tt> as an argument
14223<br>#2 the type of the pointer is incompatible with the type of the member
14224function
14225<br>#3 the address of a constant being passed to a function taking a non-const
14226<tt>X*</tt>
14227</p>
14228
14229
14230<p><b>Proposed resolution:</b></p>
14231<p>Replace the top portion of the definition of the class template
14232const_mem_fun_t in 20.5.8, p8
14233</p>
14234<p><tt>template &lt;class S, class T&gt; class const_mem_fun_t</tt>
14235<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : public
14236unary_function&lt;T*, S&gt; {</tt>
14237</p>
14238<p>with</p>
14239<p><tt>template &lt;class S, class T&gt; class const_mem_fun_t</tt>
14240<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : public
14241unary_function&lt;<b>const</b> T*, S&gt; {</tt>
14242</p>
14243<p>Also replace the top portion of the definition of the class template
14244const_mem_fun1_t in 20.5.8, p9</p>
14245<p><tt>template &lt;class S, class T, class A&gt; class const_mem_fun1_t</tt>
14246<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : public
14247binary_function&lt;T*, A, S&gt; {</tt>
14248</p>
14249<p>with</p>
14250<p><tt>template &lt;class S, class T, class A&gt; class const_mem_fun1_t</tt>
14251<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : public
14252binary_function&lt;<b>const</b> T*, A, S&gt; {</tt>
14253</p>
14254
14255
14256<p><b>Rationale:</b></p>
14257<p>This is simply a contradiction: the <tt>argument_type</tt> typedef,
14258and the argument type itself, are not the same.</p>
14259
14260
14261
14262
14263
14264<hr>
14265<h3><a name="298"></a>298. ::operator delete[] requirement incorrect/insufficient</h3>
14266<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>
14267 <b>Submitter:</b> John A. Pedretti <b>Opened:</b> 2001-01-10  <b>Last modified:</b> 2008-09-26</p>
14268<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
14269<p><b>Discussion:</b></p>
14270<p>
14271The default behavior of <tt>operator delete[]</tt> described in 18.5.1.2, p12 -
14272namely that for non-null value of <i>ptr</i>, the operator reclaims storage
14273allocated by the earlier call to the default <tt>operator new[]</tt> - is not
14274correct in all cases. Since the specified <tt>operator new[]</tt> default
14275behavior is to call <tt>operator new</tt> (18.5.1.2, p4, p8), which can be
14276replaced, along with <tt>operator delete</tt>, by the user, to implement their
14277own memory management, the specified default behavior of<tt> operator
14278delete[]</tt> must be to call <tt>operator delete</tt>.
14279</p>
14280
14281
14282<p><b>Proposed resolution:</b></p>
14283<p>Change 18.5.1.2, p12 from</p>
14284<blockquote><p>
14285<b>-12-</b> <b>Default behavior:</b></p>
14286<ul>
14287<li>
14288For a null value of <i><tt>ptr</tt></i> , does nothing.
14289</li>
14290<li>
14291Any other value of <i><tt>ptr</tt></i> shall be a value returned
14292earlier by a call to the default <tt>operator new[](std::size_t)</tt>.
14293[Footnote: The value must not have been invalidated by an intervening
14294call to <tt>operator delete[](void*)</tt> (17.6.3.9 [res.on.arguments]).
14295--- end footnote]
14296For such a non-null value of <i><tt>ptr</tt></i> , reclaims storage
14297allocated by the earlier call to the default <tt>operator new[]</tt>.
14298</li>
14299</ul>
14300</blockquote>
14301
14302<p>to</p>
14303
14304<blockquote><p>
14305<b>-12-</b> <b>Default behavior: </b>Calls <tt>operator
14306delete(</tt><i>ptr</i>)
14307or <tt>operator delete(<i>ptr</i>, std::nothrow)</tt> respectively.
14308</p></blockquote>
14309<p>and expunge paragraph 13.</p>
14310
14311
14312
14313
14314<hr>
14315<h3><a name="300"></a>300. list::merge() specification incomplete</h3>
14316<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>
14317 <b>Submitter:</b> John Pedretti <b>Opened:</b> 2001-01-23  <b>Last modified:</b> 2008-09-26</p>
14318<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#list.ops">active issues</a> in [list.ops].</p>
14319<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>
14320<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
14321<p><b>Discussion:</b></p>
14322<p>
14323The "Effects" clause for list::merge() (23.3.4.4 [list.ops], p23)
14324appears to be incomplete: it doesn't cover the case where the argument
14325list is identical to *this (i.e., this == &amp;x). The requirement in the
14326note in p24 (below) is that x be empty after the merge which is surely
14327unintended in this case.
14328</p>
14329
14330
14331<p><b>Proposed resolution:</b></p>
14332<p>In 23.3.4.4 [list.ops], replace paragraps 23-25 with:</p>
14333<blockquote>
14334<p>
1433523 Effects: if (&amp;x == this) does nothing; otherwise, merges the two
14336sorted ranges [begin(), end()) and [x.begin(), x.end()).  The result
14337is a range in which the elements will be sorted in non-decreasing
14338order according to the ordering defined by comp; that is, for every
14339iterator i in the range other than the first, the condition comp(*i,
14340*(i - 1)) will be false.
14341</p>
14342
14343<p>
1434424 Notes: Stable: if (&amp;x != this), then for equivalent elements in the
14345two original ranges, the elements from the original range [begin(),
14346end()) always precede the elements from the original range [x.begin(),
14347x.end()).  If (&amp;x != this) the range [x.begin(), x.end()) is empty
14348after the merge.
14349</p>
14350
14351<p>
1435225 Complexity: At most size() + x.size() - 1 applications of comp if
14353(&amp;x !  = this); otherwise, no applications of comp are performed.  If
14354an exception is thrown other than by a comparison there are no
14355effects.
14356</p>
14357
14358</blockquote>
14359
14360<p><i>[Copenhagen: The original proposed resolution did not fix all of
14361the problems in 23.3.4.4 [list.ops], p22-25.  Three different
14362paragraphs (23, 24, 25) describe the effects of <tt>merge</tt>.
14363Changing p23, without changing the other two, appears to introduce
14364contradictions.  Additionally, "merges the argument list into the
14365list" is excessively vague.]</i></p>
14366
14367
14368<p><i>[Post-Cura�ao: Robert Klarer provided new wording.]</i></p>
14369
14370
14371
14372
14373
14374
14375
14376<hr>
14377<h3><a name="301"></a>301. basic_string template ctor effects clause omits allocator argument</h3>
14378<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>
14379 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-01-27  <b>Last modified:</b> 2008-09-26</p>
14380<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>
14381<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
14382<p><b>Discussion:</b></p>
14383<p>
14384The effects clause for the basic_string template ctor in 21.3.1, p15
14385leaves out the third argument of type Allocator. I believe this to be
14386a mistake.
14387</p>
14388
14389
14390<p><b>Proposed resolution:</b></p>
14391<p>Replace</p>
14392
14393<blockquote>
14394    <p><b>-15- Effects:</b> If <i><tt>InputIterator</tt></i> is an integral
14395    type, equivalent to</p>
14396
14397    <blockquote><p><tt>basic_string(static_cast&lt;size_type&gt;(begin),
14398    static_cast&lt;value_type&gt;(end))</tt></p></blockquote>
14399</blockquote>
14400
14401<p>with</p>
14402
14403<blockquote>
14404    <p><b>-15- Effects:</b> If <i><tt>InputIterator</tt></i> is an integral
14405    type, equivalent to</p>
14406
14407    <blockquote><p><tt>basic_string(static_cast&lt;size_type&gt;(begin),
14408    static_cast&lt;value_type&gt;(end), <b>a</b>)</tt></p></blockquote>
14409</blockquote>
14410
14411
14412
14413
14414<hr>
14415<h3><a name="303"></a>303. Bitset input operator underspecified</h3>
14416<p><b>Section:</b> 20.3.7.3 [bitset.operators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
14417 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2001-02-05  <b>Last modified:</b> 2008-09-26</p>
14418<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
14419<p><b>Discussion:</b></p>
14420<p>
14421In 23.3.5.3, we are told that <tt>bitset</tt>'s input operator
14422"Extracts up to <i>N</i> (single-byte) characters from
14423<i>is</i>.", where <i>is</i> is a stream of type
14424<tt>basic_istream&lt;charT, traits&gt;</tt>.
14425</p>
14426
14427<p>
14428The standard does not say what it means to extract single byte
14429characters from a stream whose character type, <tt>charT</tt>, is in
14430general not a single-byte character type.  Existing implementations
14431differ.
14432</p>
14433
14434<p>
14435A reasonable solution will probably involve <tt>widen()</tt> and/or
14436<tt>narrow()</tt>, since they are the supplied mechanism for
14437converting a single character between <tt>char</tt> and 
14438arbitrary <tt>charT</tt>.
14439</p>
14440
14441<p>Narrowing the input characters is not the same as widening the
14442literals <tt>'0'</tt> and <tt>'1'</tt>, because there may be some
14443locales in which more than one wide character maps to the narrow
14444character <tt>'0'</tt>.  Narrowing means that alternate
14445representations may be used for bitset input, widening means that
14446they may not be.</p>
14447
14448<p>Note that for numeric input, <tt>num_get&lt;&gt;</tt>
14449(22.2.2.1.2/8) compares input characters to widened version of narrow
14450character literals.</p>
14451
14452<p>From Pete Becker, in c++std-lib-8224:</p>
14453<blockquote>
14454<p>
14455Different writing systems can have different representations for the
14456digits that represent 0 and 1. For example, in the Unicode representation
14457of the Devanagari script (used in many of the Indic languages) the digit 0
14458is 0x0966, and the digit 1 is 0x0967. Calling narrow would translate those
14459into '0' and '1'. But Unicode also provides the ASCII values 0x0030 and
144600x0031 for for the Latin representations of '0' and '1', as well as code
14461points for the same numeric values in several other scripts (Tamil has no
14462character for 0, but does have the digits 1-9), and any of these values
14463would also be narrowed to '0' and '1'.
14464</p>
14465
14466<p>...</p>
14467
14468<p>
14469It's fairly common to intermix both native and Latin
14470representations of numbers in a document. So I think the rule has to be
14471that if a wide character represents a digit whose value is 0 then the bit
14472should be cleared; if it represents a digit whose value is 1 then the bit
14473should be set; otherwise throw an exception. So in a Devanagari locale,
14474both 0x0966 and 0x0030 would clear the bit, and both 0x0967 and 0x0031
14475would set it. Widen can't do that. It would pick one of those two values,
14476and exclude the other one.
14477</p>
14478
14479</blockquote>
14480
14481<p>From Jens Maurer, in c++std-lib-8233:</p>
14482
14483<blockquote>
14484<p>
14485Whatever we decide, I would find it most surprising if
14486bitset conversion worked differently from int conversion
14487with regard to alternate local representations of
14488numbers.
14489</p>
14490
14491<p>Thus, I think the options are:</p>
14492<ul>
14493 <li> Have a new defect issue for 22.2.2.1.2/8 so that it will
14494require the use of narrow().</li>
14495
14496 <li> Have a defect issue for bitset() which describes clearly
14497that widen() is to be used.</li>
14498</ul>
14499</blockquote>
14500
14501
14502
14503<p><b>Proposed resolution:</b></p>
14504
14505    <p>Replace the first two sentences of paragraph 5 with:</p>
14506
14507    <blockquote><p>
14508    Extracts up to <i>N</i> characters from <i>is</i>. Stores these
14509    characters in a temporary object <i>str</i> of type
14510    <tt>basic_string&lt;charT, traits&gt;</tt>, then evaluates the
14511    expression <tt><i>x</i> = bitset&lt;N&gt;(<i>str</i>)</tt>.
14512    </p></blockquote>
14513
14514    <p>Replace the third bullet item in paragraph 5 with:</p>
14515    <ul><li>
14516    the next input character is neither <tt><i>is</i>.widen(0)</tt>
14517    nor <tt><i>is</i>.widen(1)</tt> (in which case the input character
14518    is not extracted).
14519    </li></ul>
14520
14521
14522
14523<p><b>Rationale:</b></p>
14524<p>Input for <tt>bitset</tt> should work the same way as numeric
14525input.  Using <tt>widen</tt> does mean that alternative digit
14526representations will not be recognized, but this was a known 
14527consequence of the design choice.</p>
14528
14529
14530
14531
14532
14533<hr>
14534<h3><a name="305"></a>305. Default behavior of codecvt&lt;wchar_t, char, mbstate_t&gt;::length()</h3>
14535<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>
14536 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2001-01-24  <b>Last modified:</b> 2008-09-26</p>
14537<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>
14538<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
14539<p><b>Discussion:</b></p>
14540<p>22.2.1.5/3 introduces codecvt in part with:</p>
14541
14542<blockquote><p>
14543  codecvt&lt;wchar_t,char,mbstate_t&gt; converts between the native
14544  character sets for tiny and wide characters. Instantiations on
14545  mbstate_t perform conversion between encodings known to the library
14546  implementor.
14547</p></blockquote>
14548
14549<p>But 22.2.1.5.2/10 describes do_length in part with:</p>
14550
14551<blockquote><p>
14552  ... codecvt&lt;wchar_t, char, mbstate_t&gt; ... return(s) the lesser of max and 
14553  (from_end-from).
14554</p></blockquote>
14555
14556<p>
14557The semantics of do_in and do_length are linked.  What one does must
14558be consistent with what the other does.  22.2.1.5/3 leads me to
14559believe that the vendor is allowed to choose the algorithm that
14560codecvt&lt;wchar_t,char,mbstate_t&gt;::do_in performs so that it makes
14561his customers happy on a given platform.  But 22.2.1.5.2/10 explicitly
14562says what codecvt&lt;wchar_t,char,mbstate_t&gt;::do_length must
14563return.  And thus indirectly specifies the algorithm that
14564codecvt&lt;wchar_t,char,mbstate_t&gt;::do_in must perform.  I believe
14565that this is not what was intended and is a defect.
14566</p>
14567
14568<p>Discussion from the -lib reflector:
14569
14570<br>This proposal would have the effect of making the semantics of
14571all of the virtual functions in <tt>codecvt&lt;wchar_t, char,
14572mbstate_t&gt;</tt> implementation specified.  Is that what we want, or
14573do we want to mandate specific behavior for the base class virtuals
14574and leave the implementation specified behavior for the codecvt_byname
14575derived class?  The tradeoff is that former allows implementors to
14576write a base class that actually does something useful, while the
14577latter gives users a way to get known and specified---albeit
14578useless---behavior, and is consistent with the way the standard
14579handles other facets.  It is not clear what the original intention
14580was.</p>
14581
14582<p>
14583Nathan has suggest a compromise: a character that is a widened version
14584of the characters in the basic execution character set must be
14585converted to a one-byte sequence, but there is no such requirement
14586for characters that are not part of the basic execution character set.
14587</p>
14588
14589
14590<p><b>Proposed resolution:</b></p>
14591<p>
14592Change 22.2.1.5.2/5 from:
14593</p>
14594<p>
14595The instantiations required in Table 51 (lib.locale.category), namely
14596codecvt&lt;wchar_t,char,mbstate_t&gt; and
14597codecvt&lt;char,char,mbstate_t&gt;, store no characters. Stores no more
14598than (to_limit-to) destination elements. It always leaves the to_next
14599pointer pointing one beyond the last element successfully stored.
14600</p>
14601<p>
14602to:
14603</p>
14604<p>
14605Stores no more than (to_limit-to) destination elements, and leaves the
14606to_next pointer pointing one beyond the last element successfully
14607stored.  codecvt&lt;char,char,mbstate_t&gt; stores no characters.
14608</p>
14609
14610<p>Change 22.2.1.5.2/10 from:</p>
14611
14612<blockquote><p>
14613-10- Returns: (from_next-from) where from_next is the largest value in
14614the range [from,from_end] such that the sequence of values in the
14615range [from,from_next) represents max or fewer valid complete
14616characters of type internT. The instantiations required in Table 51
14617(21.1.1.1.1), namely codecvt&lt;wchar_t, char, mbstate_t&gt; and
14618codecvt&lt;char, char, mbstate_t&gt;, return the lesser of max and
14619(from_end-from).
14620</p></blockquote>
14621
14622<p>to:</p>
14623
14624<blockquote><p>
14625-10- Returns: (from_next-from) where from_next is the largest value in 
14626the range [from,from_end] such that the sequence of values in the range 
14627[from,from_next) represents max or fewer valid complete characters of 
14628type internT. The instantiation codecvt&lt;char, char, mbstate_t&gt; returns 
14629the lesser of max and (from_end-from). 
14630</p></blockquote>
14631
14632<p><i>[Redmond: Nathan suggested an alternative resolution: same as
14633above, but require that, in the default encoding, a character from the
14634basic execution character set would map to a single external
14635character.  The straw poll was 8-1 in favor of the proposed
14636resolution.]</i></p>
14637
14638
14639
14640
14641<p><b>Rationale:</b></p>
14642<p>The default encoding should be whatever users of a given platform
14643would expect to be the most natural.  This varies from platform to
14644platform.  In many cases there is a preexisting C library, and users
14645would expect the default encoding to be whatever C uses in the default
14646"C" locale.  We could impose a guarantee like the one Nathan suggested
14647(a character from the basic execution character set must map to a
14648single external character), but this would rule out important
14649encodings that are in common use: it would rule out JIS, for
14650example, and it would rule out a fixed-width encoding of UCS-4.</p>
14651
14652<p><i>[Cura�ao: fixed rationale typo at the request of Ichiro Koshida;
14653"shift-JIS" changed to "JIS".]</i></p>
14654
14655
14656
14657
14658
14659
14660
14661<hr>
14662<h3><a name="306"></a>306. offsetof macro and non-POD types</h3>
14663<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>
14664 <b>Submitter:</b> Steve Clamage <b>Opened:</b> 2001-02-21  <b>Last modified:</b> 2008-09-26</p>
14665<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>
14666<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
14667<p><b>Discussion:</b></p> 
14668<p>Spliced together from reflector messages c++std-lib-8294 and -8295:</p>
14669
14670<p>18.1, paragraph 5, reads: "The macro <tt>offsetof</tt>
14671accepts a restricted set of <i>type</i> arguments in this
14672International Standard. <i>type</i> shall be a POD structure or a POD
14673union (clause 9). The result of applying the offsetof macro to a field
14674that is a static data member or a function member is
14675undefined."</p>
14676
14677<p>For the POD requirement, it doesn't say "no diagnostic
14678required" or "undefined behavior". I read 1.4 [intro.compliance], paragraph 1, to mean that a diagnostic is required.
14679It's not clear whether this requirement was intended.  While it's
14680possible to provide such a diagnostic, the extra complication doesn't
14681seem to add any value.
14682</p>
14683
14684
14685<p><b>Proposed resolution:</b></p>
14686<p>Change 18.1, paragraph 5, to "If <i>type</i> is not a POD
14687structure or a POD union the results are undefined."</p>
14688
14689<p><i>[Copenhagen: straw poll was 7-4 in favor.  It was generally
14690agreed that requiring a diagnostic was inadvertent, but some LWG
14691members thought that diagnostics should be required whenever
14692possible.]</i></p>
14693
14694
14695
14696
14697
14698
14699<hr>
14700<h3><a name="307"></a>307. Lack of reference typedefs in container adaptors</h3>
14701<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>
14702 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2001-03-13  <b>Last modified:</b> 2008-09-26</p>
14703<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
14704<p><b>Discussion:</b></p>
14705
14706<p>From reflector message c++std-lib-8330.  See also lib-8317.</p>
14707
14708<p>
14709The standard is currently inconsistent in 23.3.4.2 [list.capacity]
14710paragraph 1 and 23.3.4.3 [list.modifiers] paragraph 1.
1471123.2.3.3/1, for example, says:
14712</p>
14713
14714<blockquote><p>
14715-1- Any sequence supporting operations back(), push_back() and pop_back() 
14716can be used to instantiate stack. In particular, vector (lib.vector), list 
14717(lib.list) and deque (lib.deque) can be used. 
14718</p></blockquote>
14719
14720<p>But this is false: vector&lt;bool&gt; can not be used, because the
14721container adaptors return a T&amp; rather than using the underlying
14722container's reference type.</p>
14723
14724<p>This is a contradiction that can be fixed by:</p>
14725
14726<ol>
14727<li>Modifying these paragraphs to say that vector&lt;bool&gt;
14728    is an exception.</li>
14729<li>Removing the vector&lt;bool&gt; specialization.</li>
14730<li>Changing the return types of stack and priority_queue to use 
14731    reference typedef's.</li>
14732</ol>
14733
14734<p>
14735I propose 3.  This does not preclude option 2 if we choose to do it
14736later (see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#96">96</a>); the issues are independent.  Option
147373 offers a small step towards support for proxied containers.  This
14738small step fixes a current contradiction, is easy for vendors to
14739implement, is already implemented in at least one popular lib, and
14740does not break any code.
14741</p>
14742
14743
14744
14745<p><b>Proposed resolution:</b></p>
14746<p>Summary: Add reference and const_reference typedefs to queue,
14747priority_queue and stack.  Change return types of "value_type&amp;" to
14748"reference".  Change return types of "const value_type&amp;" to
14749"const_reference".  Details:</p>
14750
14751<p>Change 23.2.3.1/1 from:</p>
14752
14753<pre>  namespace std {
14754    template &lt;class T, class Container = deque&lt;T&gt; &gt;
14755    class queue {
14756    public:
14757      typedef typename Container::value_type            value_type;
14758      typedef typename Container::size_type             size_type;
14759      typedef          Container                        container_type;
14760    protected:
14761      Container c;
14762
14763    public:
14764      explicit queue(const Container&amp; = Container());
14765
14766      bool      empty() const             { return c.empty(); }
14767      size_type size()  const             { return c.size(); }
14768      value_type&amp;       front()           { return c.front(); }
14769      const value_type&amp; front() const     { return c.front(); }
14770      value_type&amp;       back()            { return c.back(); }
14771      const value_type&amp; back() const      { return c.back(); }
14772      void push(const value_type&amp; x)      { c.push_back(x); }
14773      void pop()                          { c.pop_front(); }
14774    };
14775</pre>
14776
14777<p>to:</p>
14778
14779<pre>  namespace std {
14780    template &lt;class T, class Container = deque&lt;T&gt; &gt;
14781    class queue {
14782    public:
14783      typedef typename Container::value_type            value_type;
14784      typedef typename Container::reference             reference;
14785      typedef typename Container::const_reference       const_reference;
14786      typedef typename Container::value_type            value_type;
14787      typedef typename Container::size_type             size_type;
14788      typedef          Container                        container_type;
14789    protected:
14790      Container c;
14791
14792    public:
14793      explicit queue(const Container&amp; = Container());
14794
14795      bool      empty() const             { return c.empty(); }
14796      size_type size()  const             { return c.size(); }
14797      reference         front()           { return c.front(); }
14798      const_reference   front() const     { return c.front(); }
14799      reference         back()            { return c.back(); }
14800      const_reference   back() const      { return c.back(); }
14801      void push(const value_type&amp; x)      { c.push_back(x); }
14802      void pop()                          { c.pop_front(); }
14803    };
14804</pre>
14805
14806<p>Change 23.2.3.2/1 from:</p>
14807
14808<pre>  namespace std {
14809    template &lt;class T, class Container = vector&lt;T&gt;,
14810              class Compare = less&lt;typename Container::value_type&gt; &gt;
14811    class priority_queue {
14812    public:
14813      typedef typename Container::value_type            value_type;
14814      typedef typename Container::size_type             size_type;
14815      typedef          Container                        container_type;
14816    protected:
14817      Container c;
14818      Compare comp;
14819
14820    public:
14821      explicit priority_queue(const Compare&amp; x = Compare(),
14822                              const Container&amp; = Container());
14823      template &lt;class InputIterator&gt;
14824        priority_queue(InputIterator first, InputIterator last,
14825                       const Compare&amp; x = Compare(),
14826                       const Container&amp; = Container());
14827
14828      bool      empty() const       { return c.empty(); }
14829      size_type size()  const       { return c.size(); }
14830      const value_type&amp; top() const { return c.front(); }
14831      void push(const value_type&amp; x);
14832      void pop();
14833    };
14834                                  //  no equality is provided
14835  }
14836</pre>
14837
14838<p>to:</p>
14839
14840<pre>  namespace std {
14841    template &lt;class T, class Container = vector&lt;T&gt;,
14842              class Compare = less&lt;typename Container::value_type&gt; &gt;
14843    class priority_queue {
14844    public:
14845      typedef typename Container::value_type            value_type;
14846      typedef typename Container::reference             reference;
14847      typedef typename Container::const_reference       const_reference;
14848      typedef typename Container::size_type             size_type;
14849      typedef          Container                        container_type;
14850    protected:
14851      Container c;
14852      Compare comp;
14853
14854    public:
14855      explicit priority_queue(const Compare&amp; x = Compare(),
14856                              const Container&amp; = Container());
14857      template &lt;class InputIterator&gt;
14858        priority_queue(InputIterator first, InputIterator last,
14859                       const Compare&amp; x = Compare(),
14860                       const Container&amp; = Container());
14861
14862      bool      empty() const       { return c.empty(); }
14863      size_type size()  const       { return c.size(); }
14864      const_reference   top() const { return c.front(); }
14865      void push(const value_type&amp; x);
14866      void pop();
14867    };
14868                                  //  no equality is provided
14869  }
14870</pre>
14871
14872<p>And change 23.2.3.3/1 from:</p>
14873
14874<pre>  namespace std {
14875    template &lt;class T, class Container = deque&lt;T&gt; &gt;
14876    class stack {
14877    public:
14878      typedef typename Container::value_type            value_type;
14879      typedef typename Container::size_type             size_type;
14880      typedef          Container                        container_type;
14881    protected:
14882      Container c;
14883
14884    public:
14885      explicit stack(const Container&amp; = Container());
14886
14887      bool      empty() const             { return c.empty(); }
14888      size_type size()  const             { return c.size(); }
14889      value_type&amp;       top()             { return c.back(); }
14890      const value_type&amp; top() const       { return c.back(); }
14891      void push(const value_type&amp; x)      { c.push_back(x); }
14892      void pop()                          { c.pop_back(); }
14893    };
14894
14895    template &lt;class T, class Container&gt;
14896      bool operator==(const stack&lt;T, Container&gt;&amp; x,
14897                      const stack&lt;T, Container&gt;&amp; y);
14898    template &lt;class T, class Container&gt;
14899      bool operator&lt; (const stack&lt;T, Container&gt;&amp; x,
14900                      const stack&lt;T, Container&gt;&amp; y);
14901    template &lt;class T, class Container&gt;
14902      bool operator!=(const stack&lt;T, Container&gt;&amp; x,
14903                      const stack&lt;T, Container&gt;&amp; y);
14904    template &lt;class T, class Container&gt;
14905      bool operator&gt; (const stack&lt;T, Container&gt;&amp; x,
14906                      const stack&lt;T, Container&gt;&amp; y);
14907    template &lt;class T, class Container&gt;
14908      bool operator&gt;=(const stack&lt;T, Container&gt;&amp; x,
14909                      const stack&lt;T, Container&gt;&amp; y);
14910    template &lt;class T, class Container&gt;
14911      bool operator&lt;=(const stack&lt;T, Container&gt;&amp; x,
14912                      const stack&lt;T, Container&gt;&amp; y);
14913  }
14914</pre>
14915
14916<p>to:</p>
14917
14918<pre>  namespace std {
14919    template &lt;class T, class Container = deque&lt;T&gt; &gt;
14920    class stack {
14921    public:
14922      typedef typename Container::value_type            value_type;
14923      typedef typename Container::reference             reference;
14924      typedef typename Container::const_reference       const_reference;
14925      typedef typename Container::size_type             size_type;
14926      typedef          Container                        container_type;
14927    protected:
14928      Container c;
14929
14930    public:
14931      explicit stack(const Container&amp; = Container());
14932
14933      bool      empty() const             { return c.empty(); }
14934      size_type size()  const             { return c.size(); }
14935      reference         top()             { return c.back(); }
14936      const_reference   top() const       { return c.back(); }
14937      void push(const value_type&amp; x)      { c.push_back(x); }
14938      void pop()                          { c.pop_back(); }
14939    };
14940
14941    template &lt;class T, class Container&gt;
14942      bool operator==(const stack&lt;T, Container&gt;&amp; x,
14943                      const stack&lt;T, Container&gt;&amp; y);
14944    template &lt;class T, class Container&gt;
14945      bool operator&lt; (const stack&lt;T, Container&gt;&amp; x,
14946                      const stack&lt;T, Container&gt;&amp; y);
14947    template &lt;class T, class Container&gt;
14948      bool operator!=(const stack&lt;T, Container&gt;&amp; x,
14949                      const stack&lt;T, Container&gt;&amp; y);
14950    template &lt;class T, class Container&gt;
14951      bool operator&gt; (const stack&lt;T, Container&gt;&amp; x,
14952                      const stack&lt;T, Container&gt;&amp; y);
14953    template &lt;class T, class Container&gt;
14954      bool operator&gt;=(const stack&lt;T, Container&gt;&amp; x,
14955                      const stack&lt;T, Container&gt;&amp; y);
14956    template &lt;class T, class Container&gt;
14957      bool operator&lt;=(const stack&lt;T, Container&gt;&amp; x,
14958                      const stack&lt;T, Container&gt;&amp; y);
14959  }
14960</pre>
14961
14962<p><i>[Copenhagen: This change was discussed before the IS was released
14963and it was deliberately not adopted.  Nevertheless, the LWG believes
14964(straw poll: 10-2) that it is a genuine defect.]</i></p>
14965
14966
14967
14968
14969
14970
14971<hr>
14972<h3><a name="308"></a>308. Table 82 mentions unrelated headers</h3>
14973<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>
14974 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-03-15  <b>Last modified:</b> 2008-09-26</p>
14975<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>
14976<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
14977<p><b>Discussion:</b></p>
14978<p>
14979Table 82 in section 27 mentions the header &lt;cstdlib&gt; for String
14980streams (27.8 [string.streams]) and the headers &lt;cstdio&gt; and
14981&lt;cwchar&gt; for File streams (27.9 [file.streams]). It's not clear
14982why these headers are mentioned in this context since they do not
14983define any of the library entities described by the
14984subclauses. According to 17.6.1.1 [contents], only such headers
14985are to be listed in the summary.
14986</p>
14987
14988
14989<p><b>Proposed resolution:</b></p>
14990<p>Remove &lt;cstdlib&gt; and &lt;cwchar&gt; from
14991Table 82.</p>
14992
14993<p><i>[Copenhagen: changed the proposed resolution slightly.  The
14994original proposed resolution also said to remove &lt;cstdio&gt; from
14995Table 82.  However, &lt;cstdio&gt; is mentioned several times within
14996section 27.9 [file.streams], including 27.9.2 [c.files].]</i></p>
14997
14998
14999
15000
15001
15002
15003<hr>
15004<h3><a name="310"></a>310. Is errno a macro?</h3>
15005<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>
15006 <b>Submitter:</b> Steve Clamage <b>Opened:</b> 2001-03-21  <b>Last modified:</b> 2008-09-26</p>
15007<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>
15008<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
15009<p><b>Discussion:</b></p>
15010  <p>
15011  Exactly how should errno be declared in a conforming C++ header?
15012  </p>
15013
15014  <p>
15015  The C standard says in 7.1.4 that it is unspecified whether errno is a
15016  macro or an identifier with external linkage.  In some implementations
15017  it can be either, depending on compile-time options.  (E.g., on
15018  Solaris in multi-threading mode, errno is a macro that expands to a
15019  function call, but is an extern int otherwise.  "Unspecified" allows
15020  such variability.)
15021  </p>
15022
15023  <p>The C++ standard:</p>
15024  <ul>
15025  <li>17.4.1.2 says in a note that errno must be macro in C. (false)</li>
15026  <li>17.4.3.1.3 footnote 166 says errno is reserved as an external 
15027      name (true), and implies that it is an identifier.</li>
15028  <li>19.3 simply lists errno as a macro (by what reasoning?) and goes
15029      on to say that the contents of of C++ &lt;errno.h&gt; are the
15030      same as in C, begging the question.</li>
15031  <li>C.2, table 95 lists errno as a macro, without comment.</li>
15032  </ul>
15033
15034  <p>I find no other references to errno.</p>
15035
15036  <p>We should either explicitly say that errno must be a macro, even
15037  though it need not be a macro in C, or else explicitly leave it
15038  unspecified.  We also need to say something about namespace std. 
15039  A user who includes &lt;cerrno&gt; needs to know whether to write
15040  <tt>errno</tt>, or <tt>::errno</tt>, or <tt>std::errno</tt>, or
15041  else &lt;cerrno&gt; is useless.</p>
15042
15043  <p>Two acceptable fixes:</p>
15044  <ul>
15045    <li><p>errno must be a macro. This is trivially satisfied by adding<br>
15046        &nbsp;&nbsp;#define errno (::std::errno)<br>
15047        to the headers if errno is not already a macro. You then always
15048        write errno without any scope qualification, and it always expands
15049        to a correct reference. Since it is always a macro, you know to
15050        avoid using errno as a local identifer.</p></li>
15051    <li><p>errno is in the global namespace. This fix is inferior, because
15052        ::errno is not guaranteed to be well-formed.</p></li>
15053  </ul>
15054
15055  <p><i>[
15056    This issue was first raised in 1999, but it slipped through 
15057    the cracks.
15058  ]</i></p>
15059
15060
15061
15062<p><b>Proposed resolution:</b></p>
15063  <p>Change the Note in section 17.4.1.2p5 from</p>
15064
15065    <blockquote><p>
15066    Note: the names defined as macros in C include the following:
15067    assert, errno, offsetof, setjmp, va_arg, va_end, and va_start.
15068    </p></blockquote>
15069
15070  <p>to</p>
15071
15072    <blockquote><p>
15073    Note: the names defined as macros in C include the following:
15074    assert, offsetof, setjmp, va_arg, va_end, and va_start.
15075    </p></blockquote>
15076
15077  <p>In section 19.3, change paragraph 2 from</p>
15078
15079    <blockquote><p>
15080    The contents are the same as the Standard C library header
15081    &lt;errno.h&gt;.
15082    </p></blockquote>
15083
15084  <p>to</p>
15085
15086    <blockquote><p>
15087    The contents are the same as the Standard C library header 
15088    &lt;errno.h&gt;, except that errno shall be defined as a macro.
15089    </p></blockquote>
15090
15091
15092<p><b>Rationale:</b></p>
15093<p>C++ must not leave it up to the implementation to decide whether or
15094not a name is a macro; it must explicitly specify exactly which names
15095are required to be macros.  The only one that really works is for it
15096to be a macro.</p>
15097
15098<p><i>[Cura�ao: additional rationale added.]</i></p>
15099
15100
15101
15102
15103
15104
15105
15106<hr>
15107<h3><a name="311"></a>311. Incorrect wording in basic_ostream class synopsis</h3>
15108<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>
15109 <b>Submitter:</b> Andy Sawyer <b>Opened:</b> 2001-03-21  <b>Last modified:</b> 2008-09-26</p>
15110<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>
15111<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
15112<p><b>Discussion:</b></p>
15113
15114<p>In 27.7.2.1 [ostream], the synopsis of class basic_ostream says:</p>
15115
15116<pre>  // partial specializationss
15117  template&lt;class traits&gt;
15118    basic_ostream&lt;char,traits&gt;&amp; operator&lt;&lt;( basic_ostream&lt;char,traits&gt;&amp;,
15119                                            const char * );
15120</pre>
15121
15122<p>Problems:</p>
15123<ul>
15124<li>Too many 's's at the end of "specializationss" </li>
15125<li>This is an overload, not a partial specialization</li>
15126</ul>
15127
15128
15129
15130<p><b>Proposed resolution:</b></p>
15131<p>In the synopsis in 27.7.2.1 [ostream], remove the 
15132<i>// partial specializationss</i> comment.  Also remove the same 
15133comment (correctly spelled, but still incorrect) from the synopsis in 
1513427.7.2.6.4 [ostream.inserters.character].
15135</p>
15136
15137<p><i>[
15138Pre-Redmond: added 27.7.2.6.4 [ostream.inserters.character] because of Martin's
15139comment in c++std-lib-8939.
15140]</i></p>
15141
15142
15143
15144
15145
15146
15147
15148<hr>
15149<h3><a name="312"></a>312. Table 27 is missing headers</h3>
15150<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>
15151 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-03-29  <b>Last modified:</b> 2008-09-26</p>
15152<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>
15153<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
15154<p><b>Discussion:</b></p>
15155<p>Table 27 in section 20 lists the header &lt;memory&gt; (only) for
15156Memory (lib.memory) but neglects to mention the headers
15157&lt;cstdlib&gt; and &lt;cstring&gt; that are discussed in 20.6.5 [meta.rel].</p>
15158
15159
15160<p><b>Proposed resolution:</b></p>
15161<p>Add &lt;cstdlib&gt; and &lt;cstring&gt; to Table 27, in the same row
15162as &lt;memory&gt;.</p>
15163
15164
15165
15166
15167
15168<hr>
15169<h3><a name="315"></a>315. Bad "range" in list::unique complexity</h3>
15170<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>
15171 <b>Submitter:</b> Andy Sawyer <b>Opened:</b> 2001-05-01  <b>Last modified:</b> 2008-09-26</p>
15172<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#list.ops">active issues</a> in [list.ops].</p>
15173<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>
15174<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
15175<p><b>Discussion:</b></p>
15176<p>
1517723.3.4.4 [list.ops], Para 21 describes the complexity of
15178list::unique as: "If the range (last - first) is not empty, exactly
15179(last - first) -1 applications of the corresponding predicate,
15180otherwise no applications of the predicate)".
15181</p>
15182
15183<p>
15184"(last - first)" is not a range.
15185</p>
15186
15187
15188<p><b>Proposed resolution:</b></p>
15189<p>
15190Change the "range" from (last - first) to [first, last).
15191</p>
15192
15193
15194
15195
15196<hr>
15197<h3><a name="316"></a>316. Vague text in Table 69</h3>
15198<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>
15199 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-05-04  <b>Last modified:</b> 2008-09-26</p>
15200<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>
15201<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>
15202<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
15203<p><b>Discussion:</b></p>
15204<p>Table 69 says this about a_uniq.insert(t):</p>
15205
15206<blockquote><p>
15207inserts t if and only if there is no element in the container with key
15208equivalent to the key of t. The bool component of the returned pair 
15209indicates whether the insertion takes place and the iterator component of the
15210pair points to the element with key equivalent to the key of t.
15211</p></blockquote>
15212
15213<p>The description should be more specific about exactly how the bool component
15214indicates whether the insertion takes place.</p>
15215
15216
15217<p><b>Proposed resolution:</b></p>
15218<p>Change the text in question to</p>
15219
15220<blockquote><p>
15221...The bool component of the returned pair is true if and only if the insertion
15222takes place...
15223</p></blockquote>
15224
15225
15226
15227
15228
15229<hr>
15230<h3><a name="317"></a>317. Instantiation vs. specialization of facets</h3>
15231<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>
15232 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-05-04  <b>Last modified:</b> 2008-09-26</p>
15233<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>
15234<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
15235<p><b>Discussion:</b></p>
15236<p>
15237The localization section of the standard refers to specializations of
15238the facet templates as instantiations even though the required facets
15239are typically specialized rather than explicitly (or implicitly)
15240instantiated. In the case of ctype&lt;char&gt; and
15241ctype_byname&lt;char&gt; (and the wchar_t versions), these facets are
15242actually required to be specialized. The terminology should be
15243corrected to make it clear that the standard doesn't mandate explicit
15244instantiation (the term specialization encompasses both explicit
15245instantiations and specializations).
15246</p>
15247
15248
15249<p><b>Proposed resolution:</b></p>
15250<p>
15251In the following paragraphs, replace all occurrences of the word
15252instantiation or instantiations with specialization or specializations,
15253respectively:
15254</p>
15255
15256<blockquote><p>
1525722.1.1.1.1, p4, Table 52, 22.2.1.1, p2, 22.2.1.5, p3, 22.2.1.5.1, p5,
1525822.2.1.5.2, p10, 22.2.2, p2, 22.2.3.1, p1, 22.2.3.1.2, p1, p2 and p3, 
1525922.2.4.1, p1, 22.2.4.1.2, p1, 22,2,5, p1, 22,2,6, p2, 22.2.6.3.2, p7, and
15260Footnote 242.
15261</p></blockquote>
15262
15263<p>And change the text in 22.1.1.1.1, p4 from</p>
15264
15265<blockquote><p>
15266    An implementation is required to provide those instantiations
15267    for facet templates identified as members of a category, and
15268    for those shown in Table 52:
15269</p></blockquote>
15270
15271<p>to</p>
15272
15273<blockquote><p>
15274    An implementation is required to provide those specializations...
15275</p></blockquote>
15276
15277<p><i>[Nathan will review these changes, and will look for places where
15278explicit specialization is necessary.]</i></p>
15279
15280
15281
15282
15283<p><b>Rationale:</b></p>
15284<p>This is a simple matter of outdated language.  The language to
15285describe templates was clarified during the standardization process,
15286but the wording in clause 22 was never updated to reflect that
15287change.</p>
15288
15289
15290
15291
15292
15293
15294
15295<hr>
15296<h3><a name="318"></a>318. Misleading comment in definition of numpunct_byname</h3>
15297<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>
15298 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-05-12  <b>Last modified:</b> 2008-09-26</p>
15299<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
15300<p><b>Discussion:</b></p>
15301<p>The definition of the numpunct_byname template contains the following
15302comment:</p>
15303
15304<pre>    namespace std {
15305        template &lt;class charT&gt;
15306        class numpunct_byname : public numpunct&lt;charT&gt; {
15307    // this class is specialized for char and wchar_t.
15308        ...
15309</pre>
15310
15311<p>There is no documentation of the specializations and it seems
15312conceivable that an implementation will not explicitly specialize the
15313template at all, but simply provide the primary template.</p>
15314
15315
15316<p><b>Proposed resolution:</b></p>
15317<p>Remove the comment from the text in 22.2.3.2 and from the proposed
15318resolution of library issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#228">228</a>.</p>
15319
15320
15321
15322
15323<hr>
15324<h3><a name="319"></a>319. Storage allocation wording confuses "Required behavior", "Requires"</h3>
15325<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>
15326 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2001-05-15  <b>Last modified:</b> 2008-09-26</p>
15327<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>
15328<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
15329<p><b>Discussion:</b></p>
15330<p>The standard specifies 17.5.1.4 [structure.specifications] that "Required
15331behavior" elements describe "the semantics of a function definition
15332provided by either the implementation or a C++ program."</p>
15333
15334<p>The standard specifies 17.5.1.4 [structure.specifications] that "Requires"
15335elements describe "the preconditions for calling the function."</p>
15336
15337<p>In the sections noted below, the current wording specifies
15338"Required Behavior" for what are actually preconditions, and thus
15339should be specified as "Requires".</p>
15340
15341
15342
15343<p><b>Proposed resolution:</b></p>
15344
15345<p>In 18.6.1.1 [new.delete.single] Para 12 Change:</p>
15346<blockquote>
15347  <p>Required behavior: accept a value of ptr that is null or that was
15348  returned by an earlier call ...</p>
15349</blockquote>
15350<p>to:</p>
15351<blockquote>
15352  <p>Requires: the value of ptr is null or the value returned by an
15353  earlier call ...</p>
15354</blockquote>
15355
15356<p>In 18.6.1.2 [new.delete.array] Para 11 Change:</p>
15357<blockquote>
15358  <p>Required behavior: accept a value of ptr that is null or that was
15359  returned by an earlier call ...</p>
15360</blockquote>
15361<p>to:</p>
15362<blockquote>
15363  <p>Requires: the value of ptr is null or the value returned by an
15364  earlier call ...</p>
15365</blockquote>
15366
15367
15368
15369
15370
15371<hr>
15372<h3><a name="320"></a>320. list::assign overspecified</h3>
15373<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>
15374 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2001-05-17  <b>Last modified:</b> 2008-09-26</p>
15375<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>
15376<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
15377<p><b>Discussion:</b></p>
15378<p>
15379Section 23.3.4.1 [list.cons], paragraphs 6-8 specify that list assign (both forms) have
15380the "effects" of a call to erase followed by a call to insert.
15381</p>
15382
15383<p>
15384I would like to document that implementers have the freedom to implement 
15385assign by other methods, as long as the end result is the same and the 
15386exception guarantee is as good or better than the basic guarantee.
15387</p>
15388
15389<p>
15390The motivation for this is to use T's assignment operator to recycle
15391existing nodes in the list instead of erasing them and reallocating
15392them with new values.  It is also worth noting that, with careful
15393coding, most common cases of assign (everything but assignment with
15394true input iterators) can elevate the exception safety to strong if
15395T's assignment has a nothrow guarantee (with no extra memory cost).
15396Metrowerks does this.  However I do not propose that this subtlety be
15397standardized.  It is a QoI issue.  </p>
15398
15399<p>Existing practise:
15400Metrowerks and SGI recycle nodes, Dinkumware and Rogue Wave don't.
15401</p>
15402
15403
15404<p><b>Proposed resolution:</b></p>
15405<p>Change 23.3.4.1 [list.cons]/7 from:</p>
15406
15407<blockquote>
15408<p>Effects:</p>
15409
15410<pre>   erase(begin(), end());
15411   insert(begin(), first, last);
15412</pre>
15413</blockquote>
15414
15415<p>to:</p>
15416
15417<blockquote>
15418<p>Effects: Replaces the contents of the list with the range [first, last).</p>
15419</blockquote>
15420
15421<p>In 23.2.3 [sequence.reqmts], in Table 67 (sequence requirements), 
15422add two new rows:</p>
15423<pre>      a.assign(i,j)     void      pre: i,j are not iterators into a.
15424                                  Replaces elements in a with a copy
15425                                  of [i, j).
15426
15427      a.assign(n,t)     void      pre: t is not a reference into a.
15428                                  Replaces elements in a with n copies
15429                                  of t.
15430</pre>
15431
15432<p>Change 23.3.4.1 [list.cons]/8 from:</p>
15433
15434<blockquote>
15435<p>Effects:</p>
15436<pre>   erase(begin(), end());
15437   insert(begin(), n, t);
15438</pre>
15439</blockquote>
15440<p>to:</p>
15441
15442<blockquote>
15443<p>Effects: Replaces the contents of the list with n copies of t.</p>
15444</blockquote>
15445
15446<p><i>[Redmond: Proposed resolution was changed slightly.  Previous
15447version made explicit statement about exception safety, which wasn't
15448consistent with the way exception safety is expressed elsewhere.
15449Also, the change in the sequence requirements is new.  Without that
15450change, the proposed resolution would have required that assignment of
15451a subrange would have to work.  That too would have been
15452overspecification; it would effectively mandate that assignment use a
15453temporary.  Howard provided wording.
15454]</i></p>
15455
15456
15457<p><i>[Cura�ao: Made editorial improvement in wording; changed
15458"Replaces elements in a with copies of elements in [i, j)."
15459with "Replaces the elements of a with a copy of [i, j)."
15460Changes not deemed serious enough to requre rereview.]</i></p>
15461
15462
15463
15464
15465
15466
15467
15468<hr>
15469<h3><a name="321"></a>321. Typo in num_get</h3>
15470<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>
15471 <b>Submitter:</b> Kevin Djang <b>Opened:</b> 2001-05-17  <b>Last modified:</b> 2008-09-26</p>
15472<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>
15473<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>
15474<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
15475<p><b>Discussion:</b></p>
15476<p>
15477Section 22.2.2.1.2 at p7 states that "A length specifier is added to
15478the conversion function, if needed, as indicated in Table 56."
15479However, Table 56 uses the term "length modifier", not "length
15480specifier".
15481</p>
15482
15483
15484<p><b>Proposed resolution:</b></p>
15485<p>
15486In 22.2.2.1.2 at p7, change the text "A length specifier is added ..."
15487to be "A length modifier is added ..."
15488</p>
15489
15490
15491<p><b>Rationale:</b></p>
15492<p>C uses the term "length modifier".  We should be consistent.</p>
15493
15494
15495
15496
15497
15498
15499<hr>
15500<h3><a name="322"></a>322. iterator and const_iterator should have the same value type</h3>
15501<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>
15502 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2001-05-17  <b>Last modified:</b> 2008-09-26</p>
15503<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>
15504<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>
15505<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
15506<p><b>Discussion:</b></p>
15507<p>
15508It's widely assumed that, if X is a container,
15509iterator_traits&lt;X::iterator&gt;::value_type and
15510iterator_traits&lt;X::const_iterator&gt;::value_type should both be
15511X::value_type.  However, this is nowhere stated.  The language in
15512Table 65 is not precise about the iterators' value types (it predates
15513iterator_traits), and could even be interpreted as saying that
15514iterator_traits&lt;X::const_iterator&gt;::value_type should be "const
15515X::value_type".
15516</p>
15517
15518<p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#279">279</a>.</p>
15519
15520
15521<p><b>Proposed resolution:</b></p>
15522<p>In Table 65 ("Container Requirements"), change the return type for
15523X::iterator to "iterator type whose value type is T".  Change the
15524return type for X::const_iterator to "constant iterator type whose
15525value type is T".</p>
15526
15527
15528<p><b>Rationale:</b></p>
15529<p>
15530This belongs as a container requirement, rather than an iterator
15531requirement, because the whole notion of iterator/const_iterator
15532pairs is specific to containers' iterator.
15533</p>
15534<p>
15535It is existing practice that (for example) 
15536iterator_traits&lt;list&lt;int&gt;::const_iterator&gt;::value_type
15537is "int", rather than "const int".  This is consistent with
15538the way that const pointers are handled: the standard already 
15539requires that iterator_traits&lt;const int*&gt;::value_type is int.
15540</p>
15541
15542
15543
15544
15545
15546<hr>
15547<h3><a name="324"></a>324. Do output iterators have value types?</h3>
15548<p><b>Section:</b> 24.2.2 [output.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
15549 <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2001-06-07  <b>Last modified:</b> 2008-09-26</p>
15550<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>
15551<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
15552<p><b>Discussion:</b></p>
15553
15554<p>Table 73 suggests that output iterators have value types.  It 
15555requires the expression "*a = t".  Additionally, although Table 73
15556never lists "a = t" or "X(a) = t" in the "expressions" column, it
15557contains a note saying that "a = t" and "X(a) = t" have equivalent
15558(but nowhere specified!) semantics.</p>
15559
15560<p>According to 24.1/9, t is supposed to be "a value of value type
15561T":</p>
15562
15563    <blockquote><p>
15564    In the following sections, a and b denote values of X, n denotes a
15565    value of the difference type Distance, u, tmp, and m denote
15566    identifiers, r denotes a value of X&amp;, t denotes a value of
15567    value type T.
15568    </p></blockquote>
15569
15570<p>Two other parts of the standard that are relevant to whether
15571output iterators have value types:</p>
15572
15573<ul>
15574    <li>24.1/1 says "All iterators i support the expression *i,
15575    resulting in a value of some class, enumeration, or built-in type
15576    T, called the value type of the iterator".</li>
15577
15578    <li>
15579    24.3.1/1, which says "In the case of an output iterator, the types
15580    iterator_traits&lt;Iterator&gt;::difference_type
15581    iterator_traits&lt;Iterator&gt;::value_type are both defined as void."
15582    </li>
15583</ul>
15584
15585<p>The first of these passages suggests that "*i" is supposed to
15586return a useful value, which contradicts the note in 24.1.2/2 saying
15587that the only valid use of "*i" for output iterators is in an
15588expression of the form "*i = t".  The second of these passages appears
15589to contradict Table 73, because it suggests that "*i"'s return value
15590should be void.  The second passage is also broken in the case of a an
15591iterator type, like non-const pointers, that satisfies both the output
15592iterator requirements and the forward iterator requirements.</p>
15593
15594<p>What should the standard say about <tt>*i</tt>'s return value when
15595i is an output iterator, and what should it say about that t is in the
15596expression "*i = t"?  Finally, should the standard say anything about
15597output iterators' pointer and reference types?</p>
15598
15599
15600
15601<p><b>Proposed resolution:</b></p>
15602<p>24.1 p1, change</p>
15603
15604<blockquote>
15605<p>All iterators <tt>i</tt> support the expression <tt>*i</tt>, resulting
15606in a value of some class, enumeration, or built-in type <tt>T</tt>,
15607called the value type of the iterator.</p>
15608</blockquote>
15609
15610<p>to</p>
15611
15612<blockquote>
15613<p>All input iterators <tt>i</tt> support the expression <tt>*i</tt>,
15614resulting in a value of some class, enumeration, or built-in type
15615<tt>T</tt>, called the value type of the iterator. All output
15616iterators support the expression <tt>*i = o</tt> where <tt>o</tt> is a
15617value of some type that is in the set of types that are <i>writable</i> to
15618the particular iterator type of <tt>i</tt>.
15619</p>
15620</blockquote>
15621
15622<p>24.1 p9, add</p>
15623
15624<blockquote>
15625<p><tt>o</tt> denotes a value of some type that is writable to the
15626output iterator.
15627</p>
15628</blockquote>
15629
15630<p>Table 73, change</p>
15631
15632<blockquote>
15633<pre>*a = t
15634</pre>
15635</blockquote>
15636
15637<p>to</p>
15638
15639<blockquote>
15640<pre>*r = o
15641</pre>
15642</blockquote>
15643
15644<p>and change</p>
15645
15646<blockquote>
15647<pre>*r++ = t
15648</pre>
15649</blockquote>
15650
15651<p>to</p>
15652
15653<blockquote>
15654<pre>*r++ = o
15655</pre>
15656</blockquote>
15657
15658<p><i>[post-Redmond: Jeremy provided wording]</i></p>
15659
15660
15661
15662
15663<p><b>Rationale:</b></p>
15664<p>The LWG considered two options: change all of the language that
15665seems to imply that output iterators have value types, thus making it
15666clear that output iterators have no value types, or else define value
15667types for output iterator consistently.  The LWG chose the former
15668option, because it seems clear that output iterators were never
15669intended to have value types.  This was a deliberate design decision,
15670and any language suggesting otherwise is simply a mistake.</p>
15671
15672<p>A future revision of the standard may wish to revisit this design
15673decision.</p>
15674
15675
15676
15677
15678
15679<hr>
15680<h3><a name="325"></a>325. Misleading text in moneypunct&lt;&gt;::do_grouping</h3>
15681<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>
15682 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-07-02  <b>Last modified:</b> 2008-09-26</p>
15683<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>
15684<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
15685<p><b>Discussion:</b></p>
15686<p>The Returns clause in 22.2.6.3.2, p3 says about
15687moneypunct&lt;charT&gt;::do_grouping()
15688</p>
15689
15690<blockquote><p>
15691    Returns: A pattern defined identically as the result of
15692    numpunct&lt;charT&gt;::do_grouping().241)
15693</p></blockquote>
15694
15695<p>Footnote 241 then reads</p>
15696
15697<blockquote><p>
15698    This is most commonly the value "\003" (not "3").
15699</p></blockquote>
15700
15701<p>
15702The returns clause seems to imply that the two member functions must
15703return an identical value which in reality may or may not be true,
15704since the facets are usually implemented in terms of struct std::lconv
15705and return the value of the grouping and mon_grouping, respectively.
15706The footnote also implies that the member function of the moneypunct
15707facet (rather than the overridden virtual functions in moneypunct_byname)
15708most commonly return "\003", which contradicts the C standard which
15709specifies the value of "" for the (most common) C locale.
15710</p>
15711
15712
15713
15714<p><b>Proposed resolution:</b></p>
15715<p>Replace the text in Returns clause in 22.2.6.3.2, p3 with the following:</p>
15716
15717<blockquote><p>
15718    Returns: A pattern defined identically as, but not necessarily
15719    equal to, the result of numpunct&lt;charT&gt;::do_grouping().241)
15720</p></blockquote>
15721
15722<p>and replace the text in Footnote 241 with the following:</p>
15723
15724<blockquote><p>
15725    To specify grouping by 3s the value is "\003", not "3".
15726</p></blockquote>
15727
15728
15729<p><b>Rationale:</b></p>
15730<p>
15731The fundamental problem is that the description of the locale facet
15732virtuals serves two purposes: describing the behavior of the base
15733class, and describing the meaning of and constraints on the behavior
15734in arbitrary derived classes.  The new wording makes that separation a
15735little bit clearer.  The footnote (which is nonnormative) is not
15736supposed to say what the grouping is in the "C" locale or in any other
15737locale. It is just a reminder that the values are interpreted as small
15738integers, not ASCII characters.
15739</p>
15740
15741
15742
15743
15744<hr>
15745<h3><a name="327"></a>327. Typo in time_get facet in table 52</h3>
15746<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>
15747 <b>Submitter:</b> Tiki Wan <b>Opened:</b> 2001-07-06  <b>Last modified:</b> 2008-09-26</p>
15748<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>
15749<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
15750<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#447">447</a></p>
15751<p><b>Discussion:</b></p>
15752<p>The <tt>wchar_t</tt> versions of <tt>time_get</tt> and
15753<tt>time_get_byname</tt> are listed incorrectly in table 52,
15754required instantiations.  In both cases the second template
15755parameter is given as OutputIterator.  It should instead be
15756InputIterator, since these are input facets.</p>
15757
15758
15759<p><b>Proposed resolution:</b></p>
15760<p>
15761In table 52, required instantiations, in 
1576222.3.1.1.1 [locale.category], change</p>
15763<pre>    time_get&lt;wchar_t, OutputIterator&gt;
15764    time_get_byname&lt;wchar_t, OutputIterator&gt;
15765</pre>
15766<p>to</p>
15767<pre>    time_get&lt;wchar_t, InputIterator&gt;
15768    time_get_byname&lt;wchar_t, InputIterator&gt;
15769</pre>
15770
15771<p><i>[Redmond: Very minor change in proposed resolution.  Original had
15772a typo, wchart instead of wchar_t.]</i></p>
15773
15774
15775
15776
15777
15778
15779<hr>
15780<h3><a name="328"></a>328. Bad sprintf format modifier in money_put&lt;&gt;::do_put()</h3>
15781<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>
15782 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-07-07  <b>Last modified:</b> 2008-09-26</p>
15783<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
15784<p><b>Discussion:</b></p>
15785<p>The sprintf format string , "%.01f" (that's the digit one), in the
15786description of the do_put() member functions of the money_put facet in
1578722.2.6.2.2, p1 is incorrect. First, the f format specifier is wrong
15788for values of type long double, and second, the precision of 01
15789doesn't seem to make sense. What was most likely intended was
15790"%.0Lf"., that is a precision of zero followed by the L length
15791modifier.</p>
15792
15793
15794<p><b>Proposed resolution:</b></p>
15795<p>Change the format string to "%.0Lf".</p>
15796
15797
15798<p><b>Rationale:</b></p><p>Fixes an obvious typo</p>
15799
15800
15801
15802
15803<hr>
15804<h3><a name="329"></a>329. vector capacity, reserve and reallocation</h3>
15805<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>
15806 <b>Submitter:</b> Anthony Williams <b>Opened:</b> 2001-07-13  <b>Last modified:</b> 2008-09-26</p>
15807<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>
15808<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
15809<p><b>Discussion:</b></p>
15810<p>
15811There is an apparent contradiction about which circumstances can cause
15812a reallocation of a vector in Section 23.3.6.2 [vector.capacity] and
15813section 23.3.6.4 [vector.modifiers].
15814</p>
15815
15816<p>23.3.6.2 [vector.capacity],p5 says:</p>
15817<blockquote><p>
15818Notes: Reallocation invalidates all the references, pointers, and iterators
15819referring to the elements in the sequence. It is guaranteed that no
15820reallocation takes place during insertions that happen after a call to
15821reserve() until the time when an insertion would make the size of the vector
15822greater than the size specified in the most recent call to reserve().
15823</p></blockquote>
15824
15825<p>Which implies if I do</p>
15826
15827<pre>  std::vector&lt;int&gt; vec;
15828  vec.reserve(23);
15829  vec.reserve(0);
15830  vec.insert(vec.end(),1);
15831</pre>
15832
15833<p>then the implementation may reallocate the vector for the insert,
15834as the size specified in the previous call to reserve was zero.</p>
15835
15836<p>However, the previous paragraphs (23.3.6.2 [vector.capacity], p1-2) state:</p>
15837<blockquote>
15838<p>
15839(capacity) Returns: The total number of elements the vector
15840can hold without requiring reallocation
15841</p>
15842<p>
15843...After reserve(), capacity() is greater or equal to the
15844argument of reserve if reallocation happens; and equal to the previous value
15845of capacity() otherwise...
15846</p>
15847</blockquote>
15848
15849<p>
15850This implies that vec.capacity() is still 23, and so the insert()
15851should not require a reallocation, as vec.size() is 0. This is backed
15852up by 23.3.6.4 [vector.modifiers], p1:
15853</p>
15854<blockquote><p>
15855(insert) Notes: Causes reallocation if the new size is greater than the old
15856capacity.
15857</p></blockquote>
15858
15859<p>
15860Though this doesn't rule out reallocation if the new size is less
15861than the old capacity, I think the intent is clear.
15862</p>
15863
15864
15865
15866<p><b>Proposed resolution:</b></p>
15867<p>Change the wording of 23.3.6.2 [vector.capacity] paragraph 5 to:</p>
15868
15869<blockquote><p>
15870Notes: Reallocation invalidates all the references, pointers, and
15871iterators referring to the elements in the sequence. It is guaranteed
15872that no reallocation takes place during insertions that happen after a
15873call to reserve() until the time when an insertion would make the size
15874of the vector greater than the value of capacity().
15875</p></blockquote>
15876
15877<p><i>[Redmond: original proposed resolution was modified slightly.  In
15878the original, the guarantee was that there would be no reallocation
15879until the size would be greater than the value of capacity() after the
15880most recent call to reserve().  The LWG did not believe that the
15881"after the most recent call to reserve()" added any useful
15882information.]</i></p>
15883
15884
15885
15886
15887<p><b>Rationale:</b></p>
15888<p>There was general agreement that, when reserve() is called twice in
15889succession and the argument to the second invocation is smaller than
15890the argument to the first, the intent was for the second invocation to
15891have no effect.  Wording implying that such cases have an effect on
15892reallocation guarantees was inadvertant.</p>
15893
15894
15895
15896
15897
15898<hr>
15899<h3><a name="331"></a>331. bad declaration of destructor for ios_base::failure</h3>
15900<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>
15901 <b>Submitter:</b> PremAnand M. Rao <b>Opened:</b> 2001-08-23  <b>Last modified:</b> 2008-09-26</p>
15902<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>
15903<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
15904<p><b>Discussion:</b></p>
15905<p>
15906With the change in 17.6.4.11 [res.on.exception.handling] to state
15907   "An implementation may strengthen the exception-specification for a 
15908    non-virtual function by removing listed exceptions."
15909(issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#119">119</a>)
15910and the following declaration of ~failure() in ios_base::failure
15911</p>
15912<pre>    namespace std {
15913       class ios_base::failure : public exception {
15914       public:
15915           ...
15916           virtual ~failure();
15917           ...
15918       };
15919     }
15920</pre>
15921<p>the class failure cannot be implemented since in 18.7.1 [type.info] the destructor of class exception has an empty
15922exception specification:</p>
15923<pre>    namespace std {
15924       class exception {
15925       public:
15926         ...
15927         virtual ~exception() throw();
15928         ...
15929       };
15930     }
15931</pre>
15932
15933
15934<p><b>Proposed resolution:</b></p>
15935<p>Remove the declaration of ~failure().</p>
15936
15937
15938<p><b>Rationale:</b></p>
15939<p>The proposed resolution is consistent with the way that destructors
15940of other classes derived from <tt>exception</tt> are handled.</p>
15941
15942
15943
15944
15945
15946
15947
15948<hr>
15949<h3><a name="333"></a>333. does endl imply synchronization with the device?</h3>
15950<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>
15951 <b>Submitter:</b> PremAnand M. Rao <b>Opened:</b> 2001-08-27  <b>Last modified:</b> 2008-09-26</p>
15952<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
15953<p><b>Discussion:</b></p>
15954<p>A footnote in 27.7.2.8 [ostream.manip] states:</p>
15955<blockquote><p>
15956    [Footnote: The effect of executing cout &lt;&lt; endl is to insert a 
15957     newline character in the output sequence controlled by cout, then 
15958     synchronize it with any external file with which it might be 
15959     associated. --- end foonote]
15960</p></blockquote>
15961
15962<p>
15963Does the term "file" here refer to the external device?
15964This leads to some implementation ambiguity on systems with fully 
15965buffered files where a newline does not cause a flush to the device.
15966</p>
15967
15968<p>
15969Choosing to sync with the device leads to significant performance
15970penalties for each call to endl, while not sync-ing leads to
15971errors under special circumstances.
15972</p>
15973
15974<p>
15975I could not find any other statement that explicitly defined
15976the behavior one way or the other.
15977</p>
15978
15979
15980<p><b>Proposed resolution:</b></p>
15981<p>Remove footnote 300 from section 27.7.2.8 [ostream.manip].</p>
15982
15983
15984<p><b>Rationale:</b></p>
15985<p>We already have normative text saying what <tt>endl</tt> does: it
15986inserts a newline character and calls <tt>flush</tt>.  This footnote
15987is at best redundant, at worst (as this issue says) misleading,
15988because it appears to make promises about what <tt>flush</tt>
15989does.</p>
15990
15991
15992
15993
15994
15995
15996
15997<hr>
15998<h3><a name="334"></a>334. map::operator[] specification forces inefficient implementation</h3>
15999<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>
16000 <b>Submitter:</b> Andrea Griffini <b>Opened:</b> 2001-09-02  <b>Last modified:</b> 2008-09-26</p>
16001<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>
16002<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
16003<p><b>Discussion:</b></p>
16004<p>
16005The current standard describes map::operator[] using a
16006code example. That code example is however quite
16007inefficient because it requires several useless copies
16008of both the passed key_type value and of default
16009constructed mapped_type instances.
16010My opinion is that was not meant by the comitee to
16011require all those temporary copies. 
16012</p>
16013
16014<p>Currently map::operator[] behaviour is specified as: </p>
16015<pre>  Returns:
16016    (*((insert(make_pair(x, T()))).first)).second.
16017</pre>
16018  
16019<p>
16020This specification however uses make_pair that is a
16021template function of which parameters in this case
16022will be deduced being of type const key_type&amp; and
16023const T&amp;. This will create a pair&lt;key_type,T&gt; that
16024isn't the correct type expected by map::insert so
16025another copy will be required using the template
16026conversion constructor available in pair to build
16027the required pair&lt;const key_type,T&gt; instance.
16028</p>
16029
16030<p>If we consider calling of key_type copy constructor
16031and mapped_type default constructor and copy
16032constructor as observable behaviour (as I think we
16033should) then the standard is in this place requiring
16034two copies of a key_type element plus a default
16035construction and two copy construction of a mapped_type
16036(supposing the addressed element is already present
16037in the map; otherwise at least another copy
16038construction for each type). 
16039</p>
16040
16041<p>A simple (half) solution would be replacing the description with:</p>
16042<pre>  Returns:
16043    (*((insert(value_type(x, T()))).first)).second.
16044</pre>
16045
16046<p>This will remove the wrong typed pair construction that
16047requires one extra copy of both key and value.</p>
16048
16049<p>However still the using of map::insert requires temporary
16050objects while the operation, from a logical point of view,
16051doesn't require any. </p>
16052
16053<p>I think that a better solution would be leaving free an
16054implementer to use a different approach than map::insert
16055that, because of its interface, forces default constructed
16056temporaries and copies in this case.
16057The best solution in my opinion would be just requiring
16058map::operator[] to return a reference to the mapped_type
16059part of the contained element creating a default element
16060with the specified key if no such an element is already
16061present in the container. Also a logarithmic complexity
16062requirement should be specified for the operation.
16063</p>
16064
16065<p>
16066This would allow library implementers to write alternative
16067implementations not using map::insert and reaching optimal
16068performance in both cases of the addressed element being
16069present or absent from the map (no temporaries at all and
16070just the creation of a new pair inside the container if
16071the element isn't present).
16072Some implementer has already taken this option but I think
16073that the current wording of the standard rules that as
16074non-conforming. 
16075</p>
16076
16077
16078
16079<p><b>Proposed resolution:</b></p>
16080
16081<p>
16082Replace 23.4.1.2 [map.access] paragraph 1 with
16083</p>
16084<blockquote>
16085<p>
16086-1- Effects:  If there is no key equivalent to x in the map, inserts 
16087value_type(x, T()) into the map.
16088</p>
16089<p>
16090-2- Returns: A reference to the mapped_type corresponding to x in *this.
16091</p>
16092<p>
16093-3- Complexity: logarithmic.
16094</p>
16095</blockquote>
16096
16097<p><i>[This is the second option mentioned above.  Howard provided
16098wording.  We may also wish to have a blanket statement somewhere in
16099clause 17 saying that we do not intend the semantics of sample code
16100fragments to be interpreted as specifing exactly how many copies are
16101made.  See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#98">98</a> for a similar problem.]</i></p>
16102
16103
16104
16105
16106<p><b>Rationale:</b></p>
16107<p>
16108This is the second solution described above; as noted, it is
16109consistent with existing practice.
16110</p>
16111
16112<p>Note that we now need to specify the complexity explicitly, because
16113we are no longer defining <tt>operator[]</tt> in terms of
16114<tt>insert</tt>.</p>
16115
16116
16117
16118
16119
16120<hr>
16121<h3><a name="335"></a>335. minor issue with char_traits, table 37</h3>
16122<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>
16123 <b>Submitter:</b> Andy Sawyer <b>Opened:</b> 2001-09-06  <b>Last modified:</b> 2008-09-26</p>
16124<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
16125<p><b>Discussion:</b></p>
16126<p>
16127Table 37, in 21.2.1 [char.traits.require], descibes char_traits::assign
16128as:
16129</p>
16130<pre>  X::assign(c,d)   assigns c = d.
16131</pre>
16132
16133<p>And para 1 says:</p>
16134
16135<blockquote><p>
16136 [...] c and d denote values of type CharT [...]
16137</p></blockquote>
16138
16139<p>
16140Naturally, if c and d are <i>values</i>, then the assignment is
16141(effectively) meaningless. It's clearly intended that (in the case of
16142assign, at least), 'c' is intended to be a reference type.
16143</p>
16144
16145<p>I did a quick survey of the four implementations I happened to have
16146lying around, and sure enough they all have signatures:</p>
16147<pre>    assign( charT&amp;, const charT&amp; );
16148</pre>
16149
16150<p>(or the equivalent). It's also described this way in Nico's book.
16151(Not to mention the synopses of char_traits&lt;char&gt; in 21.1.3.1
16152and char_traits&lt;wchar_t&gt; in 21.1.3.2...)
16153</p>
16154
16155
16156<p><b>Proposed resolution:</b></p>
16157<p>Add the following to 21.1.1 para 1:</p>
16158<blockquote><p>
16159 r denotes an lvalue of CharT
16160</p></blockquote>
16161
16162<p>and change the description of assign in the table to:</p>
16163<pre>  X::assign(r,d)   assigns r = d
16164</pre>
16165
16166
16167
16168
16169
16170<hr>
16171<h3><a name="336"></a>336. Clause 17 lack of references to deprecated headers</h3>
16172<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>
16173 <b>Submitter:</b> Detlef Vollmann <b>Opened:</b> 2001-09-05  <b>Last modified:</b> 2008-09-26</p>
16174<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>
16175<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>
16176<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
16177<p><b>Discussion:</b></p>
16178<p>From c++std-edit-873:</p>
16179
16180<p>17.6.1.2 [headers], Table 11.  In this table, the header
16181&lt;strstream&gt; is missing.</p>
16182
16183<p>This shows a general problem: The whole clause 17 refers quite
16184often to clauses 18 through 27, but D.7 is also a part of the standard
16185library (though a deprecated one).</p>
16186
16187
16188
16189<p><b>Proposed resolution:</b></p>
16190
16191<p>To 17.6.1.2 [headers] Table 11, C++ Library Headers, add
16192"&lt;strstream&gt;".</p>
16193
16194<p>In the following places, change "clauses 17 through 27" to "clauses
1619517 through 27 and Annex D":</p>
16196
16197<ul>
16198<li>1.2 [intro.refs] Normative references/1/footnote 1</li>
16199<li>1.3 [intro.defs] Definitions/1</li>
16200<li>7 [dcl.dcl] Library introduction/9</li>
16201<li>17.5 [description] Method of description (Informative)/1</li>
16202<li>17.5.2.1.4 [character.seq] Character sequences/1/bullet 2</li>
16203<li>17.5.2.2 [functions.within.classes] Functions within classes/1</li>
16204<li>17.5.2.3 [objects.within.classes] Private members/1/(2 places)</li>
16205<li>17.6 [requirements] Library-wide requirements/1</li>
16206<li>17.6.1.2 [headers] Headers/4</li>
16207<li>17.6.3.6 [replacement.functions] Replacement functions/1</li>
16208<li>17.6.4.4 [global.functions] Global or non-member functions/2</li>
16209<li>17.6.4.9 [protection.within.classes] Protection within classes/1</li>
16210</ul>
16211
16212
16213
16214
16215
16216
16217
16218<hr>
16219<h3><a name="337"></a>337. replace_copy_if's template parameter should be InputIterator</h3>
16220<p><b>Section:</b> 25.3.5 [alg.replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
16221 <b>Submitter:</b> Detlef Vollmann <b>Opened:</b> 2001-09-07  <b>Last modified:</b> 2008-09-26</p>
16222<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>
16223<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
16224<p><b>Discussion:</b></p>
16225<p>From c++std-edit-876:</p>
16226
16227<p>
16228In section 25.3.5 [alg.replace] before p4: The name of the first
16229parameter of template replace_copy_if should be "InputIterator"
16230instead of "Iterator".  According to 17.5.2.1 [type.descriptions] p1 the
16231parameter name conveys real normative meaning.
16232</p>
16233
16234
16235<p><b>Proposed resolution:</b></p>
16236<p>Change <tt>Iterator</tt> to <tt>InputIterator</tt>.</p>
16237
16238
16239
16240
16241
16242<hr>
16243<h3><a name="338"></a>338.  is whitespace allowed between `-' and a digit?</h3>
16244<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>
16245 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-09-17  <b>Last modified:</b> 2008-09-26</p>
16246<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>
16247<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
16248<p><b>Discussion:</b></p>
16249<p>
16250From Stage 2 processing in 22.4.2.1.2 [facet.num.get.virtuals], p8 and 9 (the
16251original text or the text corrected by the proposed resolution of
16252issue <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
16253within a number, but 22.4.3.1 [locale.numpunct], p2, which gives the
16254format for integer and floating point values, says that whitespace is
16255optional between a plusminus and a sign.
16256</p>
16257
16258<p>
16259The text needs to be clarified to either consistently allow or
16260disallow whitespace between a plusminus and a sign. It might be
16261worthwhile to consider the fact that the C library stdio facility does
16262not permit whitespace embedded in numbers and neither does the C or
16263C++ core language (the syntax of integer-literals is given in 2.14.2
16264[lex.icon], that of floating-point-literals in 2.14.4 [lex.fcon] of the
16265C++ standard).
16266</p>
16267
16268
16269<p><b>Proposed resolution:</b></p>
16270<p>Change the first part of 22.4.3.1 [locale.numpunct] paragraph 2 from:</p>
16271<blockquote>
16272<p>
16273The syntax for number formats is as follows, where <tt>digit</tt>
16274represents the radix set specified by the <tt>fmtflags</tt> argument
16275value, <tt>whitespace</tt> is as determined by the facet
16276<tt>ctype&lt;charT&gt;</tt> (22.2.1.1), and <tt>thousands-sep</tt> and
16277<tt>decimal-point</tt> are the results of corresponding
16278<tt>numpunct&lt;charT&gt;</tt> members.  Integer values have the
16279format:
16280</p>
16281<pre>  integer   ::= [sign] units
16282  sign      ::= plusminus [whitespace]
16283  plusminus ::= '+' | '-'
16284  units     ::= digits [thousands-sep units]
16285  digits    ::= digit [digits]
16286</pre>
16287</blockquote>
16288<p>to:</p>
16289<blockquote>
16290<p>
16291The syntax for number formats is as follows, where <tt>digit</tt>
16292represents the radix set specified by the <tt>fmtflags</tt> argument
16293value, and <tt>thousands-sep</tt> and <tt>decimal-point</tt> are the
16294results of corresponding <tt>numpunct&lt;charT&gt;</tt> members.
16295Integer values have the format:
16296</p>
16297<pre>  integer   ::= [sign] units
16298  sign      ::= plusminus
16299  plusminus ::= '+' | '-'
16300  units     ::= digits [thousands-sep units]
16301  digits    ::= digit [digits]
16302</pre>
16303</blockquote>
16304
16305
16306<p><b>Rationale:</b></p>
16307<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
16308standard says how, or whether, it's used.  However, there's no reason
16309for it to differ gratuitously from the very specific description of
16310numeric processing in 22.4.2.1.2 [facet.num.get.virtuals].  The proposed
16311resolution removes all mention of "whitespace" from that format.</p>
16312
16313
16314
16315
16316
16317<hr>
16318<h3><a name="339"></a>339. definition of bitmask type restricted to clause 27</h3>
16319<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>
16320 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-09-17  <b>Last modified:</b> 2008-09-26</p>
16321<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>
16322<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
16323<p><b>Discussion:</b></p>
16324<p>The ctype_category::mask type is declared to be an enum in 22.4.1
16325[category.ctype] with p1 then stating that it is a bitmask type, most
16326likely referring to the definition of bitmask type in 17.5.2.1.3
16327[bitmask.types], p1. However, the said definition only applies to
16328clause 27, making the reference in 22.2.1 somewhat dubious.
16329</p>
16330
16331
16332<p><b>Proposed resolution:</b></p>
16333<p>Clarify 17.3.2.1.2, p1 by changing the current text from</p>
16334    <blockquote><p>
16335    Several types defined in clause 27 are bitmask types. Each bitmask type
16336    can be implemented as an enumerated type that overloads certain operators,
16337    as an integer type, or as a bitset (20.3.7 [template.bitset]).
16338    </p></blockquote>
16339<p>to read</p>
16340    <blockquote><p>
16341    Several types defined in clauses lib.language.support through 
16342    lib.input.output and Annex D are bitmask types. Each bitmask type can
16343    be implemented as an enumerated type that overloads certain operators,
16344    as an integer  type, or as a bitset (lib.template.bitset).
16345    </p></blockquote>
16346
16347<p>
16348Additionally, change the definition in 22.2.1 to adopt the same
16349convention as in clause 27 by replacing the existing text with the
16350following (note, in particluar, the cross-reference to 17.3.2.1.2 in
1635122.2.1, p1):
16352</p>
16353
16354<blockquote>
16355<p>22.2.1 The ctype category [lib.category.ctype]</p>
16356<pre>namespace std {
16357    class ctype_base {
16358    public:
16359        typedef <b><i>T</i></b> mask;
16360
16361        // numeric values are for exposition only.
16362        static const mask space = 1 &lt;&lt; 0;
16363        static const mask print = 1 &lt;&lt; 1;
16364        static const mask cntrl = 1 &lt;&lt; 2;
16365        static const mask upper = 1 &lt;&lt; 3;
16366        static const mask lower = 1 &lt;&lt; 4;
16367        static const mask alpha = 1 &lt;&lt; 5;
16368        static const mask digit = 1 &lt;&lt; 6;
16369        static const mask punct = 1 &lt;&lt; 7;
16370        static const mask xdigit = 1 &lt;&lt; 8;
16371        static const mask alnum = alpha | digit;
16372        static const mask graph = alnum | punct;
16373    };
16374}
16375</pre>
16376
16377<p>The type <tt>mask</tt> is a bitmask type (17.5.2.1.3 [bitmask.types]).</p>
16378</blockquote>
16379
16380<p><i>[Cura�ao: The LWG notes that T above should be bold-italics to be
16381consistent with the rest of the standard.]</i></p>
16382
16383
16384
16385
16386
16387
16388
16389
16390
16391<hr>
16392<h3><a name="340"></a>340. interpretation of <tt>has_facet&lt;Facet&gt;(loc)</tt></h3>
16393<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>
16394 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-09-18  <b>Last modified:</b> 2008-09-26</p>
16395<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>
16396<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
16397<p><b>Discussion:</b></p>
16398<p>
16399It's unclear whether 22.1.1.1.1, p3 says that
16400<tt>has_facet&lt;Facet&gt;(loc)</tt> returns true for any <tt>Facet</tt>
16401from Table 51 or whether it includes Table 52 as well:
16402</p>
16403
16404<blockquote><p>
16405For any locale <tt>loc</tt> either constructed, or returned by
16406locale::classic(), and any facet <tt>Facet</tt> that is a member of a
16407standard category, <tt>has_facet&lt;Facet&gt;(loc)</tt> is true. Each
16408locale member function which takes a <tt>locale::category</tt>
16409argument operates on the corresponding set of facets.
16410</p></blockquote>
16411
16412<p>
16413It seems that it comes down to which facets are considered to be members of a
16414standard category. Intuitively, I would classify all the facets in Table 52 as
16415members of their respective standard categories, but there are an unbounded set
16416of them...
16417</p>
16418
16419<p>
16420The paragraph implies that, for instance, <tt>has_facet&lt;num_put&lt;C,
16421OutputIterator&gt; &gt;(loc)</tt> must always return true. I don't think that's
16422possible. If it were, then <tt>use_facet&lt;num_put&lt;C, OutputIterator&gt;
16423&gt;(loc)</tt> would have to return a reference to a distinct object for each
16424valid specialization of <tt>num_put&lt;C, OutputIteratory&gt;</tt>, which is
16425clearly impossible.
16426</p>
16427
16428<p>
16429On the other hand, if none of the facets in Table 52 is a member of a standard
16430category then none of the locale member functions that operate on entire
16431categories of facets will work properly.
16432</p>
16433
16434<p>
16435It seems that what p3 should mention that it's required (permitted?)
16436to hold only for specializations of <tt>Facet</tt> from Table 52 on
16437<tt>C</tt> from the set { <tt>char</tt>, <tt>wchar_t</tt> }, and
16438<tt>InputIterator</tt> and <tt>OutputIterator</tt> from the set of
16439{
16440{i,o}<tt>streambuf_iterator</tt>&lt;{<tt>char</tt>,<tt>wchar_t</tt>}<tt>&gt;</tt>
16441}.
16442</p>
16443
16444
16445<p><b>Proposed resolution:</b></p>
16446<p>In 22.3.1.1.1 [locale.category], paragraph 3, change
16447"that is a member of a standard category" to "shown in Table 51".</p>
16448
16449
16450<p><b>Rationale:</b></p>
16451<p>The facets in Table 52 are an unbounded set.  Locales should not be
16452required to contain an infinite number of facets.</p> 
16453
16454<p>It's not necessary to talk about which values of InputIterator and
16455OutputIterator must be supported.  Table 51 already contains a
16456complete list of the ones we need.</p>
16457
16458
16459
16460
16461
16462
16463<hr>
16464<h3><a name="341"></a>341. Vector reallocation and swap</h3>
16465<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>
16466 <b>Submitter:</b> Anthony Williams <b>Opened:</b> 2001-09-27  <b>Last modified:</b> 2008-09-26</p>
16467<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>
16468<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
16469<p><b>Discussion:</b></p>
16470<p>It is a common idiom to reduce the capacity of a vector by swapping it with
16471an empty one:</p>
16472<pre>  std::vector&lt;SomeType&gt; vec;
16473  // fill vec with data
16474  std::vector&lt;SomeType&gt;().swap(vec);
16475  // vec is now empty, with minimal capacity
16476</pre>
16477
16478<p>However, the wording of 23.3.6.2 [vector.capacity]paragraph 5 prevents
16479the capacity of a vector being reduced, following a call to
16480reserve(). This invalidates the idiom, as swap() is thus prevented
16481from 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
16482requires the temporary to be expanded to cater for the contents of
16483vec, and the contents be copied across. This is a linear-time
16484operation.</p>
16485
16486<p>However, the container requirements state that swap must have constant
16487complexity (23.2 [container.requirements] note to table 65).</p>
16488
16489<p>This is an important issue, as reallocation affects the validity of
16490references and iterators.</p>
16491
16492<p>If the wording of 23.2.4.2p5 is taken to be the desired intent, then
16493references and iterators remain valid after a call to swap, if they refer to
16494an element before the new end() of the vector into which they originally
16495pointed, in which case they refer to the element at the same index position.
16496Iterators and references that referred to an element whose index position
16497was beyond the new end of the vector are invalidated.</p>
16498
16499<p>If the note to table 65 is taken as the desired intent, then there are two
16500possibilities with regard to iterators and references:</p>
16501
16502<ol>
16503<li>All Iterators and references into both vectors are invalidated.</li>
16504<li>Iterators and references into either vector remain valid, and remain
16505pointing to the same element. Consequently iterators and references that
16506referred to one vector now refer to the other, and vice-versa.</li>
16507</ol>
16508
16509
16510<p><b>Proposed resolution:</b></p>
16511<p>Add a new paragraph after 23.3.6.2 [vector.capacity] paragraph 5:</p>
16512<blockquote>
16513<pre>  void swap(vector&lt;T,Allocator&gt;&amp; x);
16514</pre>
16515<p><b>Effects:</b> Exchanges the contents and capacity() of <tt>*this</tt>
16516with that of <tt>x</tt>.</p>
16517<p><b>Complexity:</b> Constant time.</p>
16518</blockquote>
16519
16520<p><i>[This solves the problem reported for this issue.  We may also
16521have a problem with a circular definition of swap() for other
16522containers.]</i></p>
16523
16524
16525
16526
16527<p><b>Rationale:</b></p>
16528<p>
16529swap should be constant time.  The clear intent is that it should just
16530do pointer twiddling, and that it should exchange all properties of
16531the two vectors, including their reallocation guarantees.
16532</p>
16533
16534
16535
16536
16537
16538<hr>
16539<h3><a name="345"></a>345. type tm in &lt;cwchar&gt;</h3>
16540<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>
16541 <b>Submitter:</b> Clark Nelson <b>Opened:</b> 2001-10-19  <b>Last modified:</b> 2008-09-26</p>
16542<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>
16543<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
16544<p><b>Discussion:</b></p>
16545<p>C99, and presumably amendment 1 to C90, specify that &lt;wchar.h&gt;
16546declares struct tm as an incomplete type. However, table 48 in 21.6
16547[c.strings] does not mention the type tm as being declared in
16548&lt;cwchar&gt;. Is this omission intentional or accidental?
16549</p>
16550
16551
16552<p><b>Proposed resolution:</b></p>
16553<p>In section 21.6 [c.strings], add "tm" to table 48.</p>
16554
16555
16556
16557
16558
16559<hr>
16560<h3><a name="346"></a>346. Some iterator member functions should be const</h3>
16561<p><b>Section:</b> X [iterator.concepts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
16562 <b>Submitter:</b> Jeremy Siek <b>Opened:</b> 2001-10-20  <b>Last modified:</b> 2008-09-30</p>
16563<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>
16564<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
16565<p><b>Discussion:</b></p>
16566<p>Iterator member functions and operators that do not change the state
16567of the iterator should be defined as const member functions or as
16568functions that take iterators either by const reference or by
16569value. The standard does not explicitly state which functions should
16570be const.  Since this a fairly common mistake, the following changes
16571are suggested to make this explicit.</p>
16572
16573<p>The tables almost indicate constness properly through naming: r
16574for non-const and a,b for const iterators. The following changes
16575make this more explicit and also fix a couple problems.</p>
16576
16577
16578<p><b>Proposed resolution:</b></p>
16579<p>In X [iterator.concepts] Change the first section of p9 from
16580"In the following sections, a and b denote values of X..." to
16581"In the following sections, a and b denote values of type const X...".</p>
16582
16583<p>In Table 73, change</p>
16584<pre>    a-&gt;m   U&amp;         ...
16585</pre>
16586
16587<p>to</p>
16588
16589<pre>    a-&gt;m   const U&amp;   ...
16590    r-&gt;m   U&amp;         ...
16591</pre>
16592
16593<p>In Table 73 expression column, change</p>
16594
16595<pre>    *a = t
16596</pre>
16597
16598<p>to</p>
16599
16600<pre>    *r = t
16601</pre>
16602
16603<p><i>[Redmond: The container requirements should be reviewed to see if
16604the same problem appears there.]</i></p>
16605
16606
16607
16608
16609
16610
16611
16612<hr>
16613<h3><a name="347"></a>347. locale::category and bitmask requirements</h3>
16614<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>
16615 <b>Submitter:</b> P.J. Plauger, Nathan Myers <b>Opened:</b> 2001-10-23  <b>Last modified:</b> 2008-09-26</p>
16616<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>
16617<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
16618<p><b>Discussion:</b></p>
16619<p>
16620In 22.3.1.1.1 [locale.category] paragraph 1, the category members
16621are described as bitmask elements.  In fact, the bitmask requirements
16622in 17.5.2.1.3 [bitmask.types] don't seem quite right: <tt>none</tt>
16623and <tt>all</tt> are bitmask constants, not bitmask elements.</p>
16624
16625<p>In particular, the requirements for <tt>none</tt> interact poorly
16626with the requirement that the LC_* constants from the C library must
16627be recognizable as C++ locale category constants.  LC_* values should
16628not be mixed with these values to make category values.</p>
16629
16630<p>We have two options for the proposed resolution.  Informally:
16631option 1 removes the requirement that LC_* values be recognized as
16632category arguments.  Option 2 changes the category type so that this
16633requirement is implementable, by allowing <tt>none</tt> to be some
16634value such as 0x1000 instead of 0.</p>
16635
16636<p>Nathan writes: "I believe my proposed resolution [Option 2] merely
16637re-expresses the status quo more clearly, without introducing any
16638changes beyond resolving the DR.</p>
16639
16640
16641
16642<p><b>Proposed resolution:</b></p>
16643<p>Replace the first two paragraphs of 22.3.1.1 [locale.types] with:</p>
16644<blockquote>
16645<pre>    typedef int category;
16646</pre>
16647
16648<p>Valid category values include the <tt>locale</tt> member bitmask
16649elements <tt>collate</tt>, <tt>ctype</tt>, <tt>monetary</tt>,
16650<tt>numeric</tt>, <tt>time</tt>, and <tt>messages</tt>, each of which
16651represents a single locale category. In addition, <tt>locale</tt> member
16652bitmask constant <tt>none</tt> is defined as zero and represents no
16653category. And locale member bitmask constant <tt>all</tt> is defined such that
16654the expression</p>
16655<pre>    (collate | ctype | monetary | numeric | time | messages | all) == all
16656</pre>
16657<p>
16658is <tt>true</tt>, and represents the union of all categories.  Further
16659the expression <tt>(X | Y)</tt>, where <tt>X</tt> and <tt>Y</tt> each
16660represent a single category, represents the union of the two
16661categories.
16662</p>
16663
16664<p>
16665<tt>locale</tt> member functions expecting a <tt>category</tt>
16666argument require one of the <tt>category</tt> values defined above, or
16667the union of two or more such values. Such a <tt>category</tt>
16668argument identifies a set of locale categories. Each locale category,
16669in turn, identifies a set of locale facets, including at least those
16670shown in Table 51:
16671</p>
16672</blockquote>
16673<p><i>[Cura�ao: need input from locale experts.]</i></p>
16674
16675
16676
16677
16678<p><b>Rationale:</b></p>
16679
16680<p>The LWG considered, and rejected, an alternate proposal (described
16681  as "Option 2" in the discussion).  The main reason for rejecting it
16682  was that library implementors were concerened about implementation
16683  difficult, given that getting a C++ library to work smoothly with a
16684  separately written C library is already a delicate business.  Some
16685  library implementers were also concerned about the issue of adding
16686  extra locale categories.</p>
16687
16688<blockquote>
16689<p><b>Option 2:</b> <br>
16690Replace the first paragraph of 22.3.1.1 [locale.types] with:</p>
16691<blockquote>
16692<p>
16693Valid category values include the enumerated values.  In addition, the
16694result of applying commutative operators | and &amp; to any two valid 
16695values is valid, and results in the setwise union and intersection, 
16696respectively, of the argument categories.  The values <tt>all</tt> and 
16697<tt>none</tt> are defined such that for any valid value <tt>cat</tt>, the
16698expressions <tt>(cat | all == all)</tt>, <tt>(cat &amp; all == cat)</tt>,
16699<tt>(cat | none == cat)</tt> and <tt>(cat &amp; none == none)</tt> are 
16700true.  For non-equal values <tt>cat1</tt> and <tt>cat2</tt> of the
16701remaining enumerated values, <tt>(cat1 &amp; cat2 == none)</tt> is true.
16702For any valid categories <tt>cat1</tt> and <tt>cat2</tt>, the result
16703of <tt>(cat1 &amp; ~cat2)</tt> is valid, and equals the setwise union of 
16704those categories found in <tt>cat1</tt> but not found in <tt>cat2</tt>.
16705[Footnote: it is not required that <tt>all</tt> equal the setwise union
16706of the other enumerated values; implementations may add extra categories.]
16707</p>
16708</blockquote>
16709</blockquote>
16710
16711
16712
16713
16714
16715<hr>
16716<h3><a name="349"></a>349. Minor typographical error in ostream_iterator</h3>
16717<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>
16718 <b>Submitter:</b> Andy Sawyer <b>Opened:</b> 2001-10-24  <b>Last modified:</b> 2008-09-26</p>
16719<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
16720<p><b>Discussion:</b></p>
16721<p>24.5.2 [lib.ostream.iterator] states:</p>
16722<pre>    [...]
16723
16724    private:
16725    // basic_ostream&lt;charT,traits&gt;* out_stream; exposition only
16726    // const char* delim; exposition only
16727</pre>
16728
16729<p>Whilst it's clearly marked "exposition only", I suspect 'delim'
16730should be of type 'const charT*'.</p>
16731
16732
16733<p><b>Proposed resolution:</b></p>
16734<p>
16735In 24.6.2 [ostream.iterator], replace <tt>const char* delim</tt> with
16736<tt>const charT* delim</tt>.
16737</p>
16738
16739
16740
16741
16742
16743<hr>
16744<h3><a name="352"></a>352. missing fpos requirements</h3>
16745<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>
16746 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-12-02  <b>Last modified:</b> 2008-09-26</p>
16747<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#char.traits.typedefs">issues</a> in [char.traits.typedefs].</p>
16748<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
16749<p><b>Discussion:</b></p>
16750<p>
16751<i>(1)</i>
16752There are no requirements on the <tt>stateT</tt> template parameter of
16753<tt>fpos</tt> listed in 27.4.3. The interface appears to require that
16754the type be at least Assignable and CopyConstructible (27.4.3.1, p1),
16755and I think also DefaultConstructible (to implement the operations in
16756Table 88).
16757</p>
16758<p>
1675921.1.2, p3, however, only requires that
16760<tt>char_traits&lt;charT&gt;::state_type</tt> meet the requirements of
16761CopyConstructible types.
16762</p>
16763<p>
16764<i>(2)</i>
16765Additionally, the <tt>stateT</tt> template argument has no
16766corresponding typedef in fpos which might make it difficult to use in
16767generic code.
16768</p>
16769
16770
16771<p><b>Proposed resolution:</b></p>
16772<p>
16773Modify 21.1.2, p4 from
16774</p>
16775<p>
16776    Requires: <tt>state_type</tt> shall meet the requirements of
16777              CopyConstructible types (20.1.3).
16778</p>
16779<p>
16780    Requires: state_type shall meet the requirements of Assignable
16781              (23.1, p4), CopyConstructible (20.1.3), and
16782              DefaultConstructible  (20.1.4) types.
16783</p>
16784
16785
16786
16787<p><b>Rationale:</b></p>
16788<p>The LWG feels this is two issues, as indicated above. The first is
16789a defect---std::basic_fstream is unimplementable without these
16790additional requirements---and the proposed resolution fixes it.  The
16791second is questionable; who would use that typedef?  The class
16792template fpos is used only in a very few places, all of which know the
16793state type already.  Unless motivation is provided, the second should
16794be considered NAD.</p>
16795
16796
16797
16798
16799
16800<hr>
16801<h3><a name="354"></a>354. Associative container lower/upper bound requirements</h3>
16802<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>
16803 <b>Submitter:</b> Hans Aberg <b>Opened:</b> 2001-12-17  <b>Last modified:</b> 2008-09-26</p>
16804<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>
16805<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>
16806<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
16807<p><b>Discussion:</b></p>
16808<p>
16809Discussions in the thread "Associative container lower/upper bound
16810requirements" on comp.std.c++ suggests that there is a defect in the
16811C++ standard, Table 69 of section 23.1.2, "Associative containers",
16812[lib.associative.reqmts].  It currently says:</p>
16813
16814<blockquote>
16815<p>
16816a.find(k): returns an iterator pointing to an element with the key equivalent to
16817k, or a.end() if such an element is not found.
16818</p>
16819
16820<p>
16821a.lower_bound(k): returns an iterator pointing to the first element with
16822key not less than k.
16823</p>
16824
16825<p>
16826a.upper_bound(k): returns an iterator pointing to the first element with
16827key greater than k.
16828</p>
16829</blockquote>
16830
16831<p>
16832We have "or a.end() if such an element is not found" for
16833<tt>find</tt>, but not for <tt>upper_bound</tt> or
16834<tt>lower_bound</tt>.  As the text stands, one would be forced to
16835insert a new element into the container and return an iterator to that
16836in case the sought iterator does not exist, which does not seem to be
16837the intention (and not possible with the "const" versions).
16838</p>
16839
16840
16841<p><b>Proposed resolution:</b></p>
16842
16843<p>Change Table 69 of section 23.2.4 [associative.reqmts] indicated entries
16844to:</p>
16845
16846<blockquote>
16847<p>
16848a.lower_bound(k): returns an iterator pointing to the first element with
16849key not less than k, or a.end() if such an element is not found.
16850</p>
16851
16852<p>
16853a.upper_bound(k): returns an iterator pointing to the first element with
16854key greater than k, or a.end() if such an element is not found.
16855</p>
16856</blockquote>
16857
16858<p><i>[Cura�ao: LWG reviewed PR.]</i></p>
16859
16860
16861
16862
16863
16864
16865
16866
16867<hr>
16868<h3><a name="355"></a>355. Operational semantics for a.back()</h3>
16869<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>
16870 <b>Submitter:</b> Yaroslav Mironov <b>Opened:</b> 2002-01-23  <b>Last modified:</b> 2008-09-26</p>
16871<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>
16872<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>
16873<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
16874<p><b>Discussion:</b></p>
16875
16876<p>Table 68 "Optional Sequence Operations" in 23.1.1/12
16877specifies operational semantics for "a.back()" as
16878"*--a.end()", which may be ill-formed <i>[because calling
16879operator-- on a temporary (the return) of a built-in type is
16880ill-formed]</i>, provided a.end() returns a simple pointer rvalue
16881(this is almost always the case for std::vector::end(), for
16882example). Thus, the specification is not only incorrect, it
16883demonstrates a dangerous construct: "--a.end()" may
16884successfully compile and run as intended, but after changing the type
16885of the container or the mode of compilation it may produce
16886compile-time error. </p>
16887
16888
16889
16890<p><b>Proposed resolution:</b></p>
16891<p>Change the specification in table 68 "Optional Sequence
16892Operations" in 23.1.1/12 for "a.back()" from</p>
16893
16894
16895<blockquote><pre>*--a.end()
16896</pre></blockquote>
16897
16898<p>to</p>
16899
16900<blockquote><pre>  { iterator tmp = a.end(); --tmp; return *tmp; }
16901</pre></blockquote>
16902
16903<p>and the specification for "a.pop_back()" from</p>
16904
16905<blockquote><pre>a.erase(--a.end())
16906</pre></blockquote>
16907
16908<p>to</p>
16909
16910<blockquote><pre>  { iterator tmp = a.end(); --tmp; a.erase(tmp); }
16911</pre></blockquote>
16912
16913<p><i>[Cura�ao: LWG changed PR from "{ X::iterator tmp =
16914a.end(); return *--tmp; }" to "*a.rbegin()", and from
16915"{ X::iterator tmp = a.end(); a.erase(--tmp); }" to
16916"a.erase(rbegin())".]</i></p>
16917
16918
16919<p><i>[There is a second possible defect; table 68 "Optional
16920Sequence Operations" in the "Operational Semantics"
16921column uses operations present only in the "Reversible
16922Container" requirements, yet there is no stated dependency
16923between these separate requirements tables. Ask in Santa Cruz if the
16924LWG would like a new issue opened.]</i></p>
16925
16926
16927<p><i>[Santa Cruz: the proposed resolution is even worse than what's in
16928  the current standard: erase is undefined for reverse iterator.  If
16929  we're going to make the change, we need to define a temporary and
16930  use operator--.  Additionally, we don't know how prevalent this is:
16931  do we need to make this change in more than one place?  Martin has
16932  volunteered to review the standard and see if this problem occurs
16933  elsewhere.]</i></p>
16934
16935
16936<p><i>[Oxford: Matt provided new wording to address the concerns raised
16937  in Santa Cruz.  It does not appear that this problem appears
16938  anywhere else in clauses 23 or 24.]</i></p>
16939
16940
16941<p><i>[Kona: In definition of operational semantics of back(), change
16942"*tmp" to "return *tmp;"]</i></p>
16943
16944
16945
16946
16947
16948
16949
16950<hr>
16951<h3><a name="358"></a>358. interpreting <tt>thousands_sep</tt> after a <tt>decimal_point</tt></h3>
16952<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>
16953 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2002-03-12  <b>Last modified:</b> 2008-09-26</p>
16954<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>
16955<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>
16956<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
16957<p><b>Discussion:</b></p>
16958<p>
16959I don't think <tt>thousands_sep</tt> is being treated correctly after
16960decimal_point has been seen. Since grouping applies only to the
16961integral part of the number, the first such occurrence should, IMO,
16962terminate Stage 2. (If it does not terminate it, then 22.2.2.1.2, p12
16963and 22.2.3.1.2, p3 need to explain how <tt>thousands_sep</tt> is to be
16964interpreted in the fractional part of a number.)
16965</p>
16966
16967<p>
16968The easiest change I can think of that resolves this issue would be
16969something like below.
16970</p>
16971
16972
16973<p><b>Proposed resolution:</b></p>
16974<p>
16975Change the first sentence of 22.2.2.1.2, p9 from
16976</p>
16977
16978<blockquote><p>
16979    If discard is true then the position of the character is
16980    remembered, but the character is otherwise ignored. If it is not
16981    discarded, then a check is made to determine if c is allowed as
16982    the next character of an input field of the conversion specifier
16983    returned by stage 1. If so it is accumulated.
16984</p></blockquote>
16985
16986<p>to</p>
16987
16988<blockquote><p>
16989    If <tt>discard</tt> is true, then if <tt>'.'</tt> has not yet been
16990    accumulated, then the position of the character is remembered, but
16991    the character is otherwise ignored. Otherwise, if <tt>'.'</tt> has
16992    already been accumulated, the character is discarded and Stage 2
16993     terminates. ...
16994</p></blockquote>
16995
16996
16997
16998<p><b>Rationale:</b></p>
16999<p>We believe this reflects the intent of the Standard.  Thousands sep
17000  characters after the decimal point are not useful in any locale.
17001  Some formatting conventions do group digits that follow the decimal
17002  point, but they usually introduce a different grouping character
17003  instead of reusing the thousand sep character.  If we want to add
17004  support for such conventions, we need to do so explicitly.</p>
17005
17006
17007
17008
17009
17010
17011<hr>
17012<h3><a name="359"></a>359. num_put&lt;&gt;::do_put (..., bool) undocumented</h3>
17013<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>
17014 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2002-03-12  <b>Last modified:</b> 2008-09-26</p>
17015<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
17016<p><b>Discussion:</b></p>
17017<p>22.2.2.2.1, p1:</p>
17018
17019    <pre>    iter_type put (iter_type out, ios_base&amp; str, char_type fill,
17020                   bool val) const;
17021    ...
17022
17023    1   Returns: do_put (out, str, fill, val).
17024    </pre>
17025
17026<p>AFAICS, the behavior of do_put (..., bool) is not documented anywhere,
17027however, 22.2.2.2.2, p23:</p>
17028
17029<blockquote>
17030<pre>iter_type put (iter_type out, ios_base&amp; str, char_type fill,
17031               bool val) const;
17032</pre>
17033
17034
17035        <p>Effects: If (str.flags() &amp; ios_base::boolalpha) == 0 then do
17036             out = do_put(out, str, fill, (int)val)
17037           Otherwise do</p>
17038<pre>             string_type s =
17039                 val ? use_facet&lt;ctype&lt;charT&gt; &gt;(loc).truename()
17040                     : use_facet&lt;ctype&lt;charT&gt; &gt;(loc).falsename();
17041</pre>
17042           <p>and then insert the characters of s into out. <i>out</i>.</p>
17043</blockquote>
17044
17045<p>
17046This means that the bool overload of <tt>do_put()</tt> will never be called,
17047which contradicts the first paragraph. Perhaps the declaration
17048should read <tt>do_put()</tt>, and not <tt>put()</tt>?
17049</p>
17050
17051<p>
17052Note also that there is no <b>Returns</b> clause for this function, which
17053should probably be corrected, just as should the second occurrence
17054of <i>"out."</i> in the text.
17055</p>
17056
17057<p>
17058I think the least invasive change to fix it would be something like
17059the following:
17060</p>
17061
17062
17063<p><b>Proposed resolution:</b></p>
17064<p>In 22.4.2.2.2 [facet.num.put.virtuals], just above paragraph 1, remove
17065  the <tt>bool</tt> overload.</p>
17066
17067<p>
17068In 22.4.2.2.2 [facet.num.put.virtuals], p23, make the following changes
17069</p>
17070
17071<blockquote><p>
17072     Replace <tt>put()</tt> with <tt>do_put()</tt> in the declaration
17073     of the member function.
17074</p></blockquote>
17075
17076<blockquote><p>
17077    Change the <b>Effects</b> clause to a <b>Returns</b> clause (to
17078    avoid the requirement to call <tt>do_put(..., int)</tt> from <tt>
17079    do_put (..., bool))</tt>
17080    like so:
17081</p></blockquote>
17082
17083<blockquote><p>
17084    23   <b>Returns</b>: If <tt>(str.flags() &amp;
17085         ios_base::boolalpha) == 0</tt> then
17086         <tt>do_put (out, str, fill, (long)val)</tt>
17087         Otherwise the function obtains a string <tt>s</tt> as if by</p>
17088<pre>             string_type s =
17089                val ? use_facet&lt;ctype&lt;charT&gt; &gt;(loc).truename()
17090                    : use_facet&lt;ctype&lt;charT&gt; &gt;(loc).falsename();
17091</pre>
17092         <p>and then inserts each character <tt>c</tt> of s into out via
17093           <tt>*out++ = c</tt>
17094         and returns <tt>out</tt>.</p>
17095</blockquote>
17096
17097
17098
17099<p><b>Rationale:</b></p><p>
17100This fixes a couple of obvious typos, and also fixes what appears to
17101be a requirement of gratuitous inefficiency.
17102</p>
17103
17104
17105
17106
17107<hr>
17108<h3><a name="360"></a>360. locale mandates inefficient implementation</h3>
17109<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>
17110 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2002-03-12  <b>Last modified:</b> 2008-09-26</p>
17111<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>
17112<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
17113<p><b>Discussion:</b></p>
17114<p>
1711522.1.1, p7 (copied below) allows iostream formatters and extractors
17116to make assumptions about the values returned from facet members.
17117However, such assumptions are apparently not guaranteed to hold
17118in other cases (e.g., when the facet members are being called directly
17119rather than as a result of iostream calls, or between successive
17120calls to the same iostream functions with no interevening calls to
17121<tt>imbue()</tt>, or even when the facet member functions are called
17122from other member functions of other facets). This restriction
17123prevents locale from being implemented efficiently.
17124</p>
17125
17126
17127<p><b>Proposed resolution:</b></p>
17128<p>Change the first sentence in 22.1.1, p7 from</p>
17129<blockquote><p>
17130    In successive calls to a locale facet member function during
17131    a call to an iostream inserter or extractor or a streambuf member
17132    function, the returned result shall be identical. [Note: This
17133    implies that such results may safely be reused without calling
17134    the locale facet member function again, and that member functions
17135    of iostream classes cannot safely call <tt>imbue()</tt>
17136    themselves, except as specified elsewhere. --end note]
17137</p></blockquote>
17138
17139<p>to</p>
17140
17141<blockquote><p>
17142    In successive calls to a locale facet member function on a facet
17143    object installed in the same locale, the returned result shall be
17144    identical. ...
17145</p></blockquote>
17146
17147
17148
17149<p><b>Rationale:</b></p>
17150<p>This change is reasonable becuase it clarifies the intent of this
17151  part of the standard.</p>
17152
17153
17154
17155
17156
17157<hr>
17158<h3><a name="362"></a>362. bind1st/bind2nd type safety</h3>
17159<p><b>Section:</b> D.9 [depr.lib.binders] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
17160 <b>Submitter:</b> Andrew Demkin <b>Opened:</b> 2002-04-26  <b>Last modified:</b> 2008-09-26</p>
17161<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>
17162<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
17163<p><b>Discussion:</b></p>
17164<p>
17165The definition of bind1st() (D.9 [depr.lib.binders]) can result in
17166the construction of an unsafe binding between incompatible pointer
17167types. For example, given a function whose first parameter type is
17168'pointer to T', it's possible without error to bind an argument of
17169type 'pointer to U' when U does not derive from T:
17170</p>
17171<pre>   foo(T*, int);
17172
17173   struct T {};
17174   struct U {};
17175
17176   U u;
17177
17178   int* p;
17179   int* q;
17180
17181   for_each(p, q, bind1st(ptr_fun(foo), &amp;u));    // unsafe binding
17182</pre>
17183
17184<p>
17185The definition of bind1st() includes a functional-style conversion to
17186map its argument to the expected argument type of the bound function
17187(see below):
17188</p>
17189<pre>  typename Operation::first_argument_type(x)
17190</pre>
17191
17192<p>A functional-style conversion (D.9 [depr.lib.binders]) is defined to
17193be
17194semantically equivalent to an explicit cast expression (D.9
17195[depr.lib.binders]), which may (according to 5.4, paragraph 5) be
17196interpreted
17197as a reinterpret_cast, thus masking the error.
17198</p>
17199
17200<p>The problem and proposed change also apply to D.9 [depr.lib.binders].</p>
17201
17202
17203<p><b>Proposed resolution:</b></p>
17204<p>Add this sentence to the end of D.9 [depr.lib.binders]/1:
17205  "Binders <tt>bind1st</tt> and <tt>bind2nd</tt> are deprecated in
17206  favor of <tt>std::tr1::bind</tt>."</p>
17207
17208<p>(Notes to editor: (1) when and if tr1::bind is incorporated into
17209  the standard, "std::tr1::bind" should be changed to "std::bind". (2)
17210  20.5.6 should probably be moved to Annex D.</p>
17211
17212
17213<p><b>Rationale:</b></p>
17214<p>There is no point in fixing bind1st and bind2nd.  tr1::bind is a
17215  superior solution.  It solves this problem and others.</p>
17216
17217
17218
17219
17220
17221<hr>
17222<h3><a name="363"></a>363. Missing exception specification in 27.4.2.1.1</h3>
17223<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>
17224 <b>Submitter:</b> Walter Brown and Marc Paterno <b>Opened:</b> 2002-05-20  <b>Last modified:</b> 2008-09-26</p>
17225<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>
17226<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
17227<p><b>Discussion:</b></p>
17228<p>
17229The destructor of ios_base::failure should have an empty throw
17230specification, because the destructor of its base class, exception, is
17231declared in this way.
17232</p>
17233
17234
17235<p><b>Proposed resolution:</b></p>
17236<p>Change the destructor to</p>
17237<pre>  virtual ~failure() throw();
17238</pre>
17239
17240
17241<p><b>Rationale:</b></p>
17242<p>Fixes an obvious glitch.  This is almost editorial.</p>
17243
17244
17245
17246
17247
17248<hr>
17249<h3><a name="364"></a>364. Inconsistent wording in 27.5.2.4.2</h3>
17250<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>
17251 <b>Submitter:</b> Walter Brown, Marc Paterno <b>Opened:</b> 2002-05-10  <b>Last modified:</b> 2008-09-26</p>
17252<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>
17253<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
17254<p><b>Discussion:</b></p>
17255<p>
1725627.6.2.4.2 [streambuf.virt.buffer] paragraph 1 is inconsistent with the Effects
17257clause for seekoff.
17258</p>
17259
17260
17261<p><b>Proposed resolution:</b></p>
17262<p>
17263Make this paragraph, the Effects clause for setbuf, consistent in wording
17264with the Effects clause for seekoff in paragraph 3 by amending paragraph 1
17265to indicate the purpose of setbuf:
17266</p>
17267
17268<p>Original text:</p>
17269
17270<blockquote><p>
172711 Effects: Performs an operation that is defined separately for each
17272class derived from basic_streambuf in this clause (27.7.1.3, 27.8.1.4).
17273</p></blockquote>
17274
17275<p>Proposed text:</p>
17276
17277<blockquote><p>
172781 Effects: Influences stream buffering in a way that is defined separately
17279for each class derived from basic_streambuf in this clause
17280(27.7.1.3, 27.8.1.4).
17281</p></blockquote>
17282
17283
17284
17285<p><b>Rationale:</b></p>
17286<p>The LWG doesn't believe there is any normative difference between
17287  the existing wording and what's in the proposed resolution, but the
17288  change may make the intent clearer.</p>
17289
17290
17291
17292
17293
17294<hr>
17295<h3><a name="365"></a>365. Lack of const-qualification in clause 27</h3>
17296<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>
17297 <b>Submitter:</b> Walter Brown, Marc Paterno <b>Opened:</b> 2002-05-10  <b>Last modified:</b> 2008-09-26</p>
17298<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>
17299<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
17300<p><b>Discussion:</b></p>
17301<p>
17302Some stream and streambuf member functions are declared non-const,
17303even thought they appear only to report information rather than to
17304change an object's logical state.  They should be declared const.  See
17305document N1360 for details and rationale.
17306</p>
17307
17308<p>The list of member functions under discussion: <tt>in_avail</tt>,
17309<tt>showmanyc</tt>, <tt>tellg</tt>, <tt>tellp</tt>, <tt>is_open</tt>.</p>
17310
17311<p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#73">73</a></p>
17312
17313
17314
17315<p><b>Proposed resolution:</b></p>
17316<p>In 27.8.1.5, 27.8.1.7, 27.8.1.8, 27.8.1.10, 27.8.1.11, and 27.8.1.13</p>
17317<p>Replace</p>
17318<pre>  bool is_open();
17319</pre>
17320<p>with</p>
17321<pre>  bool is_open() const;
17322</pre>
17323
17324
17325<p><b>Rationale:</b></p>
17326<p>Of the changes proposed in N1360, the only one that is safe is
17327changing the filestreams' is_open to const.  The LWG believed that
17328this was NAD the first time it considered this issue (issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#73">73</a>), but now thinks otherwise.  The corresponding streambuf
17329member function, after all,is already const.</p>
17330
17331<p>The other proposed changes are less safe, because some streambuf
17332functions that appear merely to report a value do actually perform
17333mutating operations.  It's not even clear that they should be
17334considered "logically const", because streambuf has two interfaces, a
17335public one and a protected one.  These functions may, and often do,
17336change the state as exposed by the protected interface, even if the
17337state exposed by the public interface is unchanged.</p>
17338
17339<p>Note that implementers can make this change in a binary compatible
17340way by providing both overloads; this would be a conforming extension.</p>
17341
17342
17343
17344
17345
17346
17347<hr>
17348<h3><a name="369"></a>369. io stream objects and static ctors</h3>
17349<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>
17350 <b>Submitter:</b> Ruslan Abdikeev <b>Opened:</b> 2002-07-08  <b>Last modified:</b> 2008-09-26</p>
17351<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>
17352<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
17353<p><b>Discussion:</b></p>
17354<p>
17355Is it safe to use standard iostream objects from constructors of
17356static objects?  Are standard iostream objects constructed and are
17357their associations established at that time?
17358</p>
17359
17360<p>Surpisingly enough, Standard does NOT require that.</p>
17361
17362<p>
1736327.3/2 [lib.iostream.objects] guarantees that standard iostream
17364objects are constructed and their associations are established before
17365the body of main() begins execution.  It also refers to ios_base::Init
17366class as the panacea for constructors of static objects.
17367</p>
17368
17369<p>
17370However, there's nothing in 27.3 [lib.iostream.objects],
17371in 27.4.2 [lib.ios.base], and in 27.4.2.1.6 [lib.ios::Init],
17372that would require implementations to allow access to standard
17373iostream objects from constructors of static objects.
17374</p>
17375
17376<p>Details:</p>
17377
17378<p>Core text refers to some magic object ios_base::Init, which will
17379be discussed below:</p>
17380
17381<blockquote><p>
17382    "The [standard iostream] objects are constructed, and their
17383    associations are established at some time prior to or during
17384    first time an object of class basic_ios&lt;charT,traits&gt;::Init
17385    is constructed, and in any case before the body of main
17386    begins execution." (27.3/2 [lib.iostream.objects])
17387</p></blockquote>
17388
17389<p>
17390The first <i>non-normative</i> footnote encourages implementations
17391to initialize standard iostream objects earlier than required.
17392</p>
17393
17394<p>However, the second <i>non-normative</i> footnote makes an explicit
17395and unsupported claim:</p>
17396
17397<blockquote><p>
17398  "Constructors and destructors for static objects can access these
17399  [standard iostream] objects to read input from stdin or write output
17400  to stdout or stderr." (27.3/2 footnote 265 [lib.iostream.objects])
17401</p></blockquote>
17402
17403<p>
17404The only bit of magic is related to that ios_base::Init class.  AFAIK,
17405the rationale behind ios_base::Init was to bring an instance of this
17406class to each translation unit which #included &lt;iostream&gt; or
17407related header.  Such an inclusion would support the claim of footnote
17408quoted above, because in order to use some standard iostream object it
17409is necessary to #include &lt;iostream&gt;.
17410</p>
17411
17412<p>
17413However, while Standard explicitly describes ios_base::Init as
17414an appropriate class for doing the trick, I failed to found a
17415mention of an _instance_ of ios_base::Init in Standard.
17416</p>
17417
17418
17419<p><b>Proposed resolution:</b></p>
17420
17421<p>Add to 27.4 [iostream.objects], p2, immediately before the last sentence
17422of the paragraph, the following two sentences:</p>
17423
17424<blockquote><p>
17425If a translation unit includes &lt;iostream&gt;, or explicitly
17426constructs an ios_base::Init object, these stream objects shall
17427be constructed before dynamic initialization of non-local
17428objects defined later in that translation unit, and these stream
17429objects shall be destroyed after the destruction of dynamically
17430initialized non-local objects defined later in that translation unit.
17431</p></blockquote>
17432
17433<p><i>[Lillehammer: Matt provided wording.]</i></p>
17434
17435<p><i>[Mont Tremblant: Matt provided revised wording.]</i></p>
17436
17437
17438
17439<p><b>Rationale:</b></p>
17440<p>
17441The original proposed resolution unconditionally required
17442implementations to define an ios_base::Init object of some
17443implementation-defined name in the header &lt;iostream&gt;. That's an
17444overspecification. First, defining the object may be unnecessary
17445and even detrimental to performance if an implementation can
17446guarantee that the 8 standard iostream objects will be initialized
17447before any other user-defined object in a program. Second, there
17448is no need to require implementations to document the name of the
17449object.</p>
17450
17451<p>
17452The new proposed resolution gives users guidance on what they need to
17453do to ensure that stream objects are constructed during startup.</p>
17454
17455
17456
17457
17458
17459<hr>
17460<h3><a name="370"></a>370. Minor error in basic_istream::get</h3>
17461<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>
17462 <b>Submitter:</b> Ray Lischner <b>Opened:</b> 2002-07-15  <b>Last modified:</b> 2008-09-26</p>
17463<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>
17464<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
17465<p><b>Discussion:</b></p>
17466<p>Defect report for description of basic_istream::get (section
1746727.7.1.3 [istream.unformatted]), paragraph 15. The description for the
17468get function
17469with the following signature:</p>
17470
17471<pre>  basic_istream&lt;charT,traits&gt;&amp; get(basic_streambuf&lt;char_type,traits&gt;&amp;
17472  sb);
17473</pre>
17474
17475<p>is incorrect. It reads</p>
17476
17477<blockquote><p>
17478  Effects: Calls get(s,n,widen('\n'))
17479</p></blockquote>
17480
17481<p>which I believe should be:</p>
17482
17483<blockquote><p>
17484  Effects: Calls get(sb,widen('\n'))
17485</p></blockquote>
17486
17487
17488<p><b>Proposed resolution:</b></p>
17489<p>Change the <b>Effects</b> paragraph to:</p>
17490<blockquote><p>
17491  Effects: Calls get(sb,this-&gt;widen('\n'))
17492</p></blockquote>
17493
17494<p><i>[Pre-Oxford: Minor correction from Howard: replaced 'widen' 
17495      with 'this-&gt;widen'.]</i></p>
17496
17497
17498
17499
17500<p><b>Rationale:</b></p><p>Fixes an obvious typo.</p>
17501
17502
17503
17504
17505<hr>
17506<h3><a name="371"></a>371. Stability of multiset and multimap member functions</h3>
17507<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>
17508 <b>Submitter:</b> Frank Compagner <b>Opened:</b> 2002-07-20  <b>Last modified:</b> 2008-09-26</p>
17509<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>
17510<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>
17511<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
17512<p><b>Discussion:</b></p>
17513<p>
17514The requirements for multiset and multimap containers (23.1
17515[lib.containers.requirements], 23.1.2 [lib.associative.reqmnts],
1751623.3.2 [lib.multimap] and 23.3.4 [lib.multiset]) make no mention of
17517the stability of the required (mutating) member functions. It appears
17518the standard allows these functions to reorder equivalent elements of
17519the container at will, yet the pervasive red-black tree implementation
17520appears to provide stable behaviour.
17521</p>
17522
17523<p>This is of most concern when considering the behaviour of erase().
17524A stability requirement would guarantee the correct working of the
17525following 'idiom' that removes elements based on a certain predicate
17526function.
17527</p>
17528
17529<pre>  multimap&lt;int, int&gt; m;
17530  multimap&lt;int, int&gt;::iterator i = m.begin();
17531  while (i != m.end()) {
17532      if (pred(i))
17533          m.erase (i++);
17534      else
17535          ++i;
17536  }
17537</pre>
17538
17539<p>
17540Although clause 23.1.2/8 guarantees that i remains a valid iterator
17541througout this loop, absence of the stability requirement could
17542potentially result in elements being skipped. This would make
17543this code incorrect, and, furthermore, means that there is no way
17544of erasing these elements without iterating first over the entire
17545container, and second over the elements to be erased. This would
17546be unfortunate, and have a negative impact on both performance and
17547code simplicity.
17548</p>
17549
17550<p>
17551If the stability requirement is intended, it should be made explicit
17552(probably through an extra paragraph in clause 23.1.2).
17553</p>
17554<p>
17555If it turns out stability cannot be guaranteed, i'd argue that a
17556remark or footnote is called for (also somewhere in clause 23.1.2) to
17557warn against relying on stable behaviour (as demonstrated by the code
17558above).  If most implementations will display stable behaviour, any
17559problems emerging on an implementation without stable behaviour will
17560be hard to track down by users. This would also make the need for an
17561erase_if() member function that much greater.
17562</p>
17563
17564<p>This issue is somewhat related to LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#130">130</a>.</p>
17565
17566
17567
17568<p><b>Proposed resolution:</b></p>
17569
17570<p>Add the following to the end of 23.2.4 [associative.reqmts] paragraph 4: 
17571"For <tt>multiset</tt> and <tt>multimap</tt>, <tt>insert</tt>and <tt>erase</tt>
17572  are <i>stable</i>: they preserve the relative ordering of equivalent
17573  elements.</p> 
17574
17575<p><i>[Lillehammer: Matt provided wording]</i></p>
17576
17577<p><i>[Joe Gottman points out that the provided wording does not address
17578multimap and multiset.  N1780 also addresses this issue and suggests
17579wording.]</i></p>
17580
17581
17582<p><i>[Mont Tremblant: Changed set and map to multiset and multimap.]</i></p>
17583
17584
17585
17586
17587<p><b>Rationale:</b></p>
17588<p>The LWG agrees that this guarantee is necessary for common user
17589  idioms to work, and that all existing implementations provide this
17590  property.  Note that this resolution guarantees stability for
17591  multimap and multiset, not for all associative containers in
17592  general.</p>
17593
17594
17595
17596
17597
17598
17599<hr>
17600<h3><a name="373"></a>373. Are basic_istream and basic_ostream to use (exceptions()&amp;badbit) != 0 ?</h3>
17601<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>
17602 <b>Submitter:</b> Keith Baker <b>Opened:</b> 2002-07-23  <b>Last modified:</b> 2008-09-26</p>
17603<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>
17604<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
17605<p><b>Discussion:</b></p>
17606
17607<p>
17608In 27.7.1.2.1 [istream.formatted.reqmts] and 27.7.2.6.1 [ostream.formatted.reqmts]
17609(exception()&amp;badbit) != 0 is used in testing for rethrow, yet
17610exception() is the constructor to class std::exception in 18.7.1 [type.info] that has no return type. Should member function
17611exceptions() found in 27.5.4 [ios] be used instead?
17612</p>
17613
17614
17615
17616<p><b>Proposed resolution:</b></p>
17617<p>
17618In 27.7.1.2.1 [istream.formatted.reqmts] and 27.7.2.6.1 [ostream.formatted.reqmts], change
17619"(exception()&amp;badbit) != 0" to "(exceptions()&amp;badbit) != 0".
17620</p>
17621
17622
17623<p><b>Rationale:</b></p>
17624<p>Fixes an obvious typo.</p>
17625
17626
17627
17628
17629
17630<hr>
17631<h3><a name="375"></a>375. basic_ios should be ios_base in 27.7.1.3</h3>
17632<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>
17633 <b>Submitter:</b> Ray Lischner <b>Opened:</b> 2002-08-14  <b>Last modified:</b> 2008-09-26</p>
17634<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>
17635<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
17636<p><b>Discussion:</b></p>
17637<p>
17638In Section 27.8.1.4 [stringbuf.virtuals]: Table 90, Table 91, and paragraph
1763914 all contain references to "basic_ios::" which should be
17640"ios_base::".
17641</p>
17642
17643
17644<p><b>Proposed resolution:</b></p>
17645<p>
17646Change all references to "basic_ios" in Table 90, Table 91, and
17647paragraph 14 to "ios_base".
17648</p>
17649
17650
17651<p><b>Rationale:</b></p><p>Fixes an obvious typo.</p>
17652
17653
17654
17655
17656<hr>
17657<h3><a name="376"></a>376. basic_streambuf semantics</h3>
17658<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>
17659 <b>Submitter:</b> Ray Lischner <b>Opened:</b> 2002-08-14  <b>Last modified:</b> 2008-09-26</p>
17660<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>
17661<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
17662<p><b>Discussion:</b></p>
17663<p>
17664In Section 27.8.1.4 [stringbuf.virtuals], Table 90, the implication is that
17665the four conditions should be mutually exclusive, but they are not.
17666The first two cases, as written, are subcases of the third.</p>
17667
17668<p>
17669As written, it is unclear what should be the result if cases 1 and 2
17670are both true, but case 3 is false.
17671</p>
17672
17673
17674
17675<p><b>Proposed resolution:</b></p>
17676
17677<p>Rewrite these conditions as:</p>
17678<blockquote>
17679<p>
17680  (which &amp; (ios_base::in|ios_base::out)) == ios_base::in
17681</p>
17682
17683<p>
17684  (which &amp; (ios_base::in|ios_base::out)) == ios_base::out
17685</p>
17686
17687<p>
17688  (which &amp; (ios_base::in|ios_base::out)) == 
17689(ios_base::in|ios_base::out)
17690   and way == either ios_base::beg or ios_base::end
17691</p>
17692
17693<p>Otherwise</p>
17694</blockquote>
17695
17696
17697
17698<p><b>Rationale:</b></p>
17699<p>It's clear what we wanted to say, we just failed to say it.  This
17700  fixes it.</p>
17701
17702
17703
17704
17705
17706<hr>
17707<h3><a name="379"></a>379. nonsensical ctype::do_widen() requirement</h3>
17708<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>
17709 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2002-09-06  <b>Last modified:</b> 2008-09-26</p>
17710<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>
17711<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
17712<p><b>Discussion:</b></p>
17713<p>
17714The last sentence in 22.2.1.1.2, p11 below doesn't seem to make sense.
17715</p>
17716<pre>  charT do_widen (char c) const;
17717
17718  -11- Effects: Applies the simplest reasonable transformation from
17719       a char value or sequence of char values to the corresponding
17720       charT value or values. The only characters for which unique
17721       transformations are required are those in the basic source
17722       character set (2.2). For any named ctype category with a
17723       ctype&lt;charT&gt; facet ctw and valid ctype_base::mask value
17724       M (is(M, c) || !ctw.is(M, do_widen(c))) is true.
17725</pre>
17726<p>
17727Shouldn't the last sentence instead read
17728</p>
17729<pre>       For any named ctype category with a ctype&lt;char&gt; facet ctc
17730       and valid ctype_base::mask value M
17731       (ctc.is(M, c) || !is(M, do_widen(c))) is true.
17732</pre>
17733<p>
17734I.e., if the narrow character c is not a member of a class of
17735characters then neither is the widened form of c. (To paraphrase
17736footnote 224.)
17737</p>
17738
17739
17740<p><b>Proposed resolution:</b></p>
17741<p>
17742Replace the last sentence of 22.4.1.1.2 [locale.ctype.virtuals], p11 with the
17743following text:
17744</p>
17745<pre>       For any named ctype category with a ctype&lt;char&gt; facet ctc
17746       and valid ctype_base::mask value M,
17747       (ctc.is(M, c) || !is(M, do_widen(c))) is true.
17748</pre>
17749
17750<p><i>[Kona: Minor edit. Added a comma after the <i>M</i> for clarity.]</i></p>
17751
17752
17753
17754
17755<p><b>Rationale:</b></p>
17756<p>The LWG believes this is just a typo, and that this is the correct fix.</p>
17757
17758
17759
17760
17761
17762<hr>
17763<h3><a name="380"></a>380. typos in codecvt tables 53 and 54</h3>
17764<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>
17765 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2002-09-06  <b>Last modified:</b> 2008-09-26</p>
17766<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>
17767<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
17768<p><b>Discussion:</b></p>
17769<p>
17770Tables 53 and 54 in 22.4.1.5 [locale.codecvt.byname] are both titled "convert
17771result values," when surely "do_in/do_out result values" must have
17772been intended for Table 53 and "do_unshift result values" for Table
1777354.
17774</p>
17775<p>
17776Table 54, row 3 says that the meaning of partial is "more characters
17777needed to be supplied to complete termination." The function is not
17778supplied any characters, it is given a buffer which it fills with
17779characters or, more precisely, destination elements (i.e., an escape
17780sequence). So partial means that space for more than (to_limit - to)
17781destination elements was needed to terminate a sequence given the
17782value of state.
17783</p>
17784
17785
17786<p><b>Proposed resolution:</b></p>
17787<p>
17788Change the title of Table 53 to "do_in/do_out result values" and
17789the title of Table 54 to "do_unshift result values."
17790</p>
17791<p>
17792Change the text in Table 54, row 3 (the <b>partial</b> row), under the
17793heading Meaning, to "space for more than (to_limit - to) destination
17794elements was needed to terminate a sequence given the value of state."
17795</p>
17796
17797
17798
17799
17800<hr>
17801<h3><a name="381"></a>381. detection of invalid mbstate_t in codecvt</h3>
17802<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>
17803 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2002-09-06  <b>Last modified:</b> 2008-09-26</p>
17804<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>
17805<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
17806<p><b>Discussion:</b></p>
17807<p>
17808All but one codecvt member functions that take a state_type argument
17809list as one of their preconditions that the state_type argument have
17810a valid value. However, according to 22.2.1.5.2, p6,
17811codecvt::do_unshift() is the only codecvt member that is supposed to
17812return error if the state_type object is invalid.
17813</p>
17814
17815<p>
17816It seems to me that the treatment of state_type by all codecvt member
17817functions should be the same and the current requirements should be
17818changed. Since the detection of invalid state_type values may be
17819difficult in general or computationally expensive in some specific
17820cases, I propose the following:
17821</p>
17822
17823
17824<p><b>Proposed resolution:</b></p>
17825<p>
17826Add a new paragraph before 22.2.1.5.2, p5, and after the function
17827declaration below
17828</p>
17829<pre>    result do_unshift(stateT&amp; state,
17830    externT* to, externT* to_limit, externT*&amp; to_next) const;
17831</pre>
17832<p>
17833as follows:
17834</p>
17835<pre>    Requires: (to &lt;= to_end) well defined and true; state initialized,
17836    if at the beginning of a sequence, or else equal to the result of
17837    converting the preceding characters in the sequence.
17838</pre>
17839<p>
17840and change the text in Table 54, row 4, the <b>error</b> row, under
17841the heading Meaning, from
17842</p>
17843<pre>    state has invalid value
17844</pre>
17845<p>
17846to
17847</p>
17848<pre>    an unspecified error has occurred
17849</pre>
17850
17851
17852<p><b>Rationale:</b></p>
17853<p>The intent is that implementations should not be required to detect
17854invalid state values; such a requirement appears nowhere else.  An
17855invalid state value is a precondition violation, <i>i.e.</i> undefined
17856behavior.  Implementations that do choose to detect invalid state
17857values, or that choose to detect any other kind of error, may return
17858<b>error</b> as an indication.</p>
17859
17860
17861
17862
17863
17864<hr>
17865<h3><a name="383"></a>383. Bidirectional iterator assertion typo</h3>
17866<p><b>Section:</b> 24.2.4 [bidirectional.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
17867 <b>Submitter:</b> ysapir (submitted via comp.std.c++) <b>Opened:</b> 2002-10-17  <b>Last modified:</b> 2008-09-26</p>
17868<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>
17869<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
17870<p><b>Discussion:</b></p>
17871<p>
17872Following a discussion on the boost list regarding end iterators and
17873the possibility of performing operator--() on them, it seems to me
17874that there is a typo in the standard.  This typo has nothing to do
17875with that discussion.
17876</p>
17877
17878<p>
17879I have checked this newsgroup, as well as attempted a search of the
17880Active/Defect/Closed Issues List on the site for the words "s is
17881derefer" so I believe this has not been proposed before.  Furthermore,
17882the "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
1788324.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.
17884</p>
17885
17886<p>
17887The standard makes the following assertion on bidirectional iterators,
17888in section 24.1.4 [lib.bidirectional.iterators], Table 75:
17889</p>
17890
17891<pre>                         operational  assertion/note
17892expression  return type   semantics    pre/post-condition
17893
17894--r          X&amp;                        pre: there exists s such
17895                                       that r == ++s.
17896                                       post: s is dereferenceable.
17897                                       --(++r) == r.
17898                                       --r == --s implies r == s.
17899                                       &amp;r == &amp;--r.
17900</pre>
17901
17902<p>
17903(See <a href="http://aspn.activestate.com/ASPN/Mail/Message/boost/1395763">http://aspn.activestate.com/ASPN/Mail/Message/boost/1395763</a>.)
17904</p>
17905
17906<p>
17907In particular, "s is dereferenceable" seems to be in error.  It seems
17908that the intention was to say "r is dereferenceable".
17909</p>
17910
17911<p>
17912If it were to say "r is dereferenceable" it would
17913make perfect sense.  Since s must be dereferenceable prior to
17914operator++, then the natural result of operator-- (to undo operator++)
17915would be to make r dereferenceable.  Furthermore, without other
17916assertions, and basing only on precondition and postconditions, we
17917could not otherwise know this.  So it is also interesting information.
17918</p>
17919
17920
17921
17922<p><b>Proposed resolution:</b></p>
17923<p>
17924Change the guarantee to "postcondition: r is dereferenceable."
17925</p>
17926
17927
17928<p><b>Rationale:</b></p><p>Fixes an obvious typo</p>
17929
17930
17931
17932
17933<hr>
17934<h3><a name="384"></a>384. equal_range has unimplementable runtime complexity</h3>
17935<p><b>Section:</b> 25.4.3.3 [equal.range] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
17936 <b>Submitter:</b> Hans Bos <b>Opened:</b> 2002-10-18  <b>Last modified:</b> 2008-09-26</p>
17937<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>
17938<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
17939<p><b>Discussion:</b></p>
17940<p>
17941Section 25.4.3.3 [equal.range]
17942states that at most 2 * log(last - first) + 1
17943comparisons are allowed for equal_range.
17944</p>
17945
17946<p>It is not possible to implement equal_range with these constraints.</p>
17947
17948<p>In a range of one element as in:</p>
17949<pre>    int x = 1;
17950    equal_range(&amp;x, &amp;x + 1, 1)
17951</pre>
17952
17953<p>it is easy to see that at least 2 comparison operations are needed.</p>
17954
17955<p>For this case at most 2 * log(1) + 1 = 1 comparison is allowed.</p>
17956
17957<p>I have checked a few libraries and they all use the same (nonconforming)
17958algorithm for equal_range that has a complexity of</p>
17959<pre>     2* log(distance(first, last)) + 2.
17960</pre>
17961<p>I guess this is the algorithm that the standard assumes for equal_range.</p>
17962
17963<p>
17964It is easy to see that 2 * log(distance) + 2 comparisons are enough
17965since equal range can be implemented with lower_bound and upper_bound
17966(both log(distance) + 1).
17967</p>
17968
17969<p>
17970I think it is better to require something like 2log(distance) + O(1)  (or
17971even logarithmic as multiset::equal_range).
17972Then an implementation has more room to optimize for certain cases (e.g.
17973have log(distance) characteristics when at most match is found in the range
17974but 2log(distance) + 4 for the worst case).
17975</p>
17976
17977
17978
17979<p><b>Proposed resolution:</b></p>
17980<p>In 25.4.3.1 [lower.bound]/4, change <tt>log(last - first) + 1</tt>
17981to <tt>log<sub>2</sub>(last - first) + <i>O</i>(1)</tt>.</p>
17982
17983<p>In 25.4.3.2 [upper.bound]/4, change <tt>log(last - first) + 1</tt>
17984to <tt>log<sub>2</sub>(last - first) + <i>O</i>(1)</tt>.</p>
17985
17986<p>In 25.4.3.3 [equal.range]/4, change <tt>2*log(last - first) + 1</tt>
17987to <tt>2*log<sub>2</sub>(last - first) + <i>O</i>(1)</tt>.</p>
17988
17989<p><i>[Matt provided wording]</i></p>
17990
17991
17992
17993<p><b>Rationale:</b></p>
17994<p>The LWG considered just saying <i>O</i>(log n) for all three, but
17995  decided that threw away too much valuable information.  The fact
17996  that lower_bound is twice as fast as equal_range is important.
17997  However, it's better to allow an arbitrary additive constant than to
17998  specify an exact count.  An exact count would have to
17999  involve <tt>floor</tt> or <tt>ceil</tt>.  It would be too easy to
18000  get this wrong, and don't provide any substantial value for users.</p>
18001
18002
18003
18004
18005<hr>
18006<h3><a name="386"></a>386. Reverse iterator's operator[] has impossible return type</h3>
18007<p><b>Section:</b> 24.5.1.3.11 [reverse.iter.op-=] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
18008 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2002-10-23  <b>Last modified:</b> 2009-05-01</p>
18009<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
18010<p><b>Discussion:</b></p>
18011<p>In 24.5.1.3.11 [reverse.iter.op-=], <tt>reverse_iterator&lt;&gt;::operator[]</tt> 
18012is specified as having a return type of <tt>reverse_iterator::reference</tt>,
18013which is the same as <tt>iterator_traits&lt;Iterator&gt;::reference</tt>.
18014(Where <tt>Iterator</tt> is the underlying iterator type.)</p>
18015
18016<p>The trouble is that <tt>Iterator</tt>'s own operator[] doesn't
18017  necessarily have a return type
18018  of <tt>iterator_traits&lt;Iterator&gt;::reference</tt>.   Its
18019  return type is merely required to be convertible
18020  to <tt>Iterator</tt>'s value type.  The return type specified for
18021  reverse_iterator's operator[] would thus appear to be impossible.</p>
18022
18023<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
18024  <tt>a[n]</tt> will continue to be required (for random access
18025  iterators) to be convertible to the value type, and also <tt>a[n] =
18026  t</tt> will be a valid expression.  Implementations of
18027  <tt>reverse_iterator</tt> will likely need to return a proxy from
18028  <tt>operator[]</tt> to meet these requirements. As mentioned in the
18029  comment from Dave Abrahams, the simplest way to specify that
18030  <tt>reverse_iterator</tt> meet this requirement to just mandate
18031  it and leave the return type of <tt>operator[]</tt> unspecified.</p>
18032
18033
18034
18035<p><b>Proposed resolution:</b></p>
18036
18037<p>In 24.5.1.2 [reverse.iter.requirements] change:</p>
18038
18039<blockquote>
18040<pre>reference operator[](difference_type n) const;
18041</pre>
18042</blockquote>
18043
18044<p>to:</p>
18045
18046<blockquote>
18047<pre><b><i>unspecified</i></b> operator[](difference_type n) const; // see 24.2.5 [random.access.iterators]
18048</pre>
18049</blockquote>
18050
18051
18052
18053
18054<p><i>[
18055Comments from Dave Abrahams: IMO we should resolve 386 by just saying
18056    that the return type of reverse_iterator's operator[] is
18057    unspecified, allowing the random access iterator requirements to
18058    impose an appropriate return type.  If we accept 299's proposed
18059    resolution (and I think we should), the return type will be
18060    readable and writable, which is about as good as we can do.
18061]</i></p>
18062
18063
18064
18065
18066
18067
18068<hr>
18069<h3><a name="387"></a>387. std::complex over-encapsulated</h3>
18070<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>
18071 <b>Submitter:</b> Gabriel Dos Reis <b>Opened:</b> 2002-11-08  <b>Last modified:</b> 2008-09-26</p>
18072<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>
18073<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
18074<p><b>Discussion:</b></p>
18075<p>
18076The absence of explicit description of std::complex&lt;T&gt; layout
18077makes it imposible to reuse existing software developed in traditional
18078languages like Fortran or C with unambigous and commonly accepted
18079layout assumptions.  There ought to be a way for practitioners to
18080predict with confidence the layout of std::complex&lt;T&gt; whenever T
18081is a numerical datatype.  The absence of ways to access individual
18082parts of a std::complex&lt;T&gt; object as lvalues unduly promotes
18083severe pessimizations. For example, the only way to change,
18084independently, the real and imaginary parts is to write something like
18085</p>
18086
18087<pre>complex&lt;T&gt; z;
18088// ...
18089// set the real part to r
18090z = complex&lt;T&gt;(r, z.imag());
18091// ...
18092// set the imaginary part to i
18093z = complex&lt;T&gt;(z.real(), i);
18094</pre>
18095
18096<p>
18097At this point, it seems appropriate to recall that a complex number
18098is, in effect, just a pair of numbers with no particular invariant to
18099maintain.  Existing practice in numerical computations has it that a
18100complex number datatype is usually represented by Cartesian
18101coordinates. Therefore the over-encapsulation put in the specification
18102of std::complex&lt;&gt; is not justified.
18103</p>
18104
18105
18106
18107<p><b>Proposed resolution:</b></p>
18108<p>Add the following requirements to 26.4 [complex.numbers] as 26.3/4:</p>
18109<blockquote>
18110<p>If z is an lvalue expression of type cv std::complex&lt;T&gt; then</p>
18111
18112<ul>
18113<li>the expression reinterpret_cast&lt;cv T(&amp;)[2]&gt;(z)
18114is well-formed; and</li>
18115<li>reinterpret_cast&lt;cv T(&amp;)[2]&gt;(z)[0]designates the
18116real part of z; and</li>
18117<li>reinterpret_cast&lt;cv T(&amp;)[2]&gt;(z)[1]designates the
18118imaginary part of z.</li>
18119</ul>
18120
18121<p>
18122Moreover, if a is an expression of pointer type cv complex&lt;T&gt;*
18123and the expression a[i] is well-defined for an integer expression
18124i then:
18125</p>
18126
18127<ul>
18128<li>reinterpret_cast&lt;cv T*&gt;(a)[2*i] designates the real
18129part of a[i]; and</li>
18130<li>reinterpret_cast&lt;cv T*&gt;(a)[2*i+1] designates the
18131imaginary part of a[i].</li>
18132</ul>
18133</blockquote>
18134
18135<p>
18136In 26.4.2 [complex] and 26.4.3 [complex.special] add the following member functions
18137(changing <tt>T</tt> to concrete types as appropriate for the specializations).
18138</p>
18139
18140<blockquote><pre>void real(T);
18141void imag(T);
18142</pre></blockquote>
18143
18144<p>
18145Add to 26.4.4 [complex.members]
18146</p>
18147
18148<blockquote>
18149<pre>T real() const;
18150</pre>
18151<blockquote>
18152<i>Returns:</i> the value of the real component
18153</blockquote>
18154<pre>void real(T val);
18155</pre>
18156<blockquote>
18157Assigns val to the real component.
18158</blockquote>
18159<pre>T imag() const;
18160</pre>
18161<blockquote>
18162<i>Returns:</i> the value of the imaginary component
18163</blockquote>
18164<pre>void imag(T val);
18165</pre>
18166<blockquote>
18167Assigns val to the imaginary component.
18168</blockquote>
18169</blockquote>
18170
18171<p><i>[Kona: The layout guarantee is absolutely necessary for C
18172  compatibility.  However, there was disagreement about the other part
18173  of this proposal: retrieving elements of the complex number as
18174  lvalues.  An alternative: continue to have real() and imag() return
18175  rvalues, but add set_real() and set_imag().  Straw poll: return
18176  lvalues - 2, add setter functions - 5.  Related issue: do we want
18177  reinterpret_cast as the interface for converting a complex to an
18178  array of two reals, or do we want to provide a more explicit way of
18179  doing it?  Howard will try to resolve this issue for the next
18180  meeting.]</i></p>
18181
18182
18183<p><i>[pre-Sydney: Howard summarized the options in n1589.]</i></p>
18184
18185
18186<p><i>[
18187Bellevue:
18188]</i></p>
18189
18190
18191<blockquote>
18192Second half of proposed wording replaced and moved to Ready.
18193</blockquote>
18194
18195<p><i>[
18196Pre-Sophia Antipolis, Howard adds:
18197]</i></p>
18198
18199
18200<blockquote>
18201Added the members to 26.4.3 [complex.special] and changed from Ready to Review.
18202</blockquote>
18203
18204<p><i>[
18205Post-Sophia Antipolis:
18206]</i></p>
18207
18208
18209<blockquote>
18210Moved from WP back to Ready so that the "and 26.4.3 [complex.special]" in the proposed
18211resolution can be officially applied.
18212</blockquote>
18213
18214
18215
18216<p><b>Rationale:</b></p>
18217<p>The LWG believes that C99 compatibility would be enough
18218justification for this change even without other considerations.  All
18219existing implementations already have the layout proposed here.</p>
18220
18221
18222
18223
18224
18225<hr>
18226<h3><a name="389"></a>389. Const overload of valarray::operator[] returns by value</h3>
18227<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>
18228 <b>Submitter:</b> Gabriel Dos Reis <b>Opened:</b> 2002-11-08  <b>Last modified:</b> 2008-09-26</p>
18229<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>
18230<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
18231<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#77">77</a></p>
18232<p><b>Discussion:</b></p>
18233<p>Consider the following program:</p>
18234<pre>    #include &lt;iostream&gt;
18235    #include &lt;ostream&gt;
18236    #include &lt;vector&gt;
18237    #include &lt;valarray&gt;
18238    #include &lt;algorithm&gt;
18239    #include &lt;iterator&gt;
18240    template&lt;typename Array&gt;
18241    void print(const Array&amp; a)
18242    {
18243    using namespace std;
18244    typedef typename Array::value_type T;
18245    copy(&amp;a[0], &amp;a[0] + a.size(),
18246    ostream_iterator&lt;T&gt;(std::cout, " "));
18247    }
18248    template&lt;typename T, unsigned N&gt;
18249    unsigned size(T(&amp;)[N]) { return N; }
18250    int main()
18251    {
18252    double array[] = { 0.89, 9.3, 7, 6.23 };
18253    std::vector&lt;double&gt; v(array, array + size(array));
18254    std::valarray&lt;double&gt; w(array, size(array));
18255    print(v); // #1
18256    std::cout &lt;&lt; std::endl;
18257    print(w); // #2
18258    std::cout &lt;&lt; std::endl;
18259    }
18260</pre>
18261
18262<p>While the call numbered #1 succeeds, the call numbered #2 fails
18263because the const version of the member function
18264valarray&lt;T&gt;::operator[](size_t) returns a value instead of a
18265const-reference. That seems to be so for no apparent reason, no
18266benefit. Not only does that defeats users' expectation but it also
18267does hinder existing software (written either in C or Fortran)
18268integration within programs written in C++.  There is no reason why
18269subscripting an expression of type valarray&lt;T&gt; that is const-qualified
18270should not return a const T&amp;.</p>
18271
18272
18273<p><b>Proposed resolution:</b></p>
18274<p>In the class synopsis in 26.6.2 [template.valarray], and in
1827526.6.2.3 [valarray.access] just above paragraph 1, change</p>
18276<pre>  T operator[](size_t const);
18277</pre>
18278<p>to</p>
18279<pre>  const T&amp; operator[](size_t const);
18280</pre>
18281
18282<p><i>[Kona: fixed a minor typo: put semicolon at the end of the line
18283  wehre it belongs.]</i></p>
18284
18285
18286
18287
18288<p><b>Rationale:</b></p>
18289<p>Return by value seems to serve no purpose.  Valaray was explicitly
18290designed to have a specified layout so that it could easily be
18291integrated with libraries in other languages, and return by value
18292defeats that purpose.  It is believed that this change will have no
18293impact on allowable optimizations.</p>
18294
18295
18296
18297
18298
18299<hr>
18300<h3><a name="391"></a>391. non-member functions specified as const</h3>
18301<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>
18302 <b>Submitter:</b> James Kanze <b>Opened:</b> 2002-12-10  <b>Last modified:</b> 2008-09-26</p>
18303<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
18304<p><b>Discussion:</b></p>
18305<p>
18306The specifications of toupper and tolower both specify the functions as
18307const, althought they are not member functions, and are not specified as
18308const in the header file synopsis in section 22.3 [locales].
18309</p>
18310
18311
18312<p><b>Proposed resolution:</b></p>
18313<p>In 22.3.3.2 [conversions], remove <tt>const</tt> from the function
18314  declarations of std::toupper and std::tolower</p>
18315
18316
18317<p><b>Rationale:</b></p><p>Fixes an obvious typo</p>
18318
18319
18320
18321
18322<hr>
18323<h3><a name="395"></a>395. inconsistencies in the definitions of rand() and random_shuffle()</h3>
18324<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>
18325 <b>Submitter:</b> James Kanze <b>Opened:</b> 2003-01-03  <b>Last modified:</b> 2008-09-26</p>
18326<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>
18327<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
18328<p><b>Discussion:</b></p>
18329<p>
18330In 26.8 [c.math], the C++ standard refers to the C standard for the
18331definition of rand(); in the C standard, it is written that "The
18332implementation shall behave as if no library function calls the rand
18333function."
18334</p>
18335
18336<p>
18337In 25.3.12 [alg.random.shuffle], there is no specification as to
18338how the two parameter version of the function generates its random
18339value.  I believe that all current implementations in fact call rand()
18340(in contradiction with the requirement avove); if an implementation does
18341not call rand(), there is the question of how whatever random generator
18342it does use is seeded.  Something is missing.
18343</p>
18344
18345
18346
18347<p><b>Proposed resolution:</b></p>
18348<p>
18349In [lib.c.math], add a paragraph specifying that the C definition of
18350rand shal be modified to say that "Unless otherwise specified, the
18351implementation shall behave as if no library function calls the rand
18352function."
18353</p>
18354
18355<p>
18356In [lib.alg.random.shuffle], add a sentence to the effect that "In
18357the two argument form of the function, the underlying source of
18358random numbers is implementation defined. [Note: in particular, an
18359implementation is permitted to use <tt>rand</tt>.]
18360</p>
18361
18362
18363<p><b>Rationale:</b></p>
18364<p>The original proposed resolution proposed requiring the
18365  two-argument from of <tt>random_shuffle</tt> to
18366  use <tt>rand</tt>. We don't want to do that, because some existing
18367  implementations already use something else: gcc
18368  uses <tt>lrand48</tt>, for example.  Using <tt>rand</tt> presents a
18369  problem if the number of elements in the sequence is greater than
18370  RAND_MAX.</p> 
18371
18372
18373
18374
18375
18376<hr>
18377<h3><a name="396"></a>396. what are characters zero and one</h3>
18378<p><b>Section:</b> 20.3.7.1 [bitset.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
18379 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-01-05  <b>Last modified:</b> 2008-09-26</p>
18380<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>
18381<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
18382<p><b>Discussion:</b></p>
18383    <p>
1838423.3.5.1, p6 [lib.bitset.cons] talks about a generic character
18385having the value of 0 or 1 but there is no definition of what
18386that means for charT other than char and wchar_t. And even for
18387those two types, the values 0 and 1 are not actually what is
18388intended -- the values '0' and '1' are. This, along with the
18389converse problem in the description of to_string() in 23.3.5.2,
18390p33, looks like a defect remotely related to DR 303.
18391    </p>
18392    <p>
18393http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#303
18394    </p>
18395    <pre>23.3.5.1:
18396  -6-  An element of the constructed string has value zero if the
18397       corresponding character in str, beginning at position pos,
18398       is 0. Otherwise, the element has the value one.
18399    </pre>
18400    <pre>23.3.5.2:
18401  -33-  Effects: Constructs a string object of the appropriate
18402        type and initializes it to a string of length N characters.
18403        Each character is determined by the value of its
18404        corresponding bit position in *this. Character position N
18405        ?- 1 corresponds to bit position zero. Subsequent decreasing
18406        character positions correspond to increasing bit positions.
18407        Bit value zero becomes the character 0, bit value one becomes
18408        the character 1.
18409    </pre>
18410    <p>
18411Also note the typo in 23.3.5.1, p6: the object under construction
18412is a bitset, not a string.
18413    </p>
18414
18415<p><i>[
18416Sophia Antipolis:
18417]</i></p>
18418
18419
18420<blockquote>
18421<p>
18422We note that <tt>bitset</tt> has been moved from section 23 to section 20, by
18423another issue (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#842">842</a>) previously resolved at this meeting.
18424</p>
18425<p>
18426Disposition: move to ready.
18427</p>
18428<p>
18429We request that Howard submit a separate issue regarding the three to_string overloads.
18430</p>
18431</blockquote>
18432
18433  
18434
18435<p><b>Proposed resolution:</b></p>
18436<p>Change the constructor's function declaration immediately before 
1843720.3.7.1 [bitset.cons] p3 to:</p>
18438<pre>    template &lt;class charT, class traits, class Allocator&gt;
18439    explicit
18440    bitset(const basic_string&lt;charT, traits, Allocator&gt;&amp; str,
18441           typename basic_string&lt;charT, traits, Allocator&gt;::size_type pos = 0,
18442           typename basic_string&lt;charT, traits, Allocator&gt;::size_type n =
18443             basic_string&lt;charT, traits, Allocator&gt;::npos,
18444           charT zero = charT('0'), charT one = charT('1'))
18445</pre>
18446<p>Change the first two sentences of 20.3.7.1 [bitset.cons] p6 to: "An
18447element of the constructed string has value 0 if the corresponding
18448character in <i>str</i>, beginning at position <i>pos</i>,
18449is <i>zero</i>. Otherwise, the element has the value 1.</p>
18450
18451<p>Change the text of the second sentence in 23.3.5.1, p5 to read:
18452    "The function then throws invalid_argument if any of the rlen
18453    characters in str beginning at position pos is other than <i>zero</i>
18454    or <i>one</i>. The function uses traits::eq() to compare the character
18455    values."
18456</p>
18457
18458<p>Change the declaration of the <tt>to_string</tt> member function
18459  immediately before 20.3.7.2 [bitset.members] p33 to:</p>
18460<pre>    template &lt;class charT, class traits, class Allocator&gt;
18461    basic_string&lt;charT, traits, Allocator&gt; 
18462    to_string(charT zero = charT('0'), charT one = charT('1')) const;
18463</pre>
18464<p>Change the last sentence of 20.3.7.2 [bitset.members] p33 to: "Bit
18465  value 0 becomes the character <tt><i>zero</i></tt>, bit value 1 becomes the
18466  character <tt><i>one</i></tt>.</p>
18467<p>Change 20.3.7.3 [bitset.operators] p8 to:</p>
18468<p><b>Returns</b>:</p> 
18469<pre>  os &lt;&lt; x.template to_string&lt;charT,traits,allocator&lt;charT&gt; &gt;(
18470      use_facet&lt;ctype&lt;charT&gt; &gt;(<i>os</i>.getloc()).widen('0'),
18471      use_facet&lt;ctype&lt;charT&gt; &gt;(<i>os</i>.getloc()).widen('1'));
18472</pre>
18473
18474
18475<p><b>Rationale:</b></p>
18476<p>There is a real problem here: we need the character values of '0'
18477  and '1', and we have no way to get them since strings don't have
18478  imbued locales. In principle the "right" solution would be to
18479  provide an extra object, either a ctype facet or a full locale,
18480  which would be used to widen '0' and '1'. However, there was some
18481  discomfort about using such a heavyweight mechanism.  The proposed
18482  resolution allows those users who care about this issue to get it
18483  right.</p>
18484<p>We fix the inserter to use the new arguments.  Note that we already
18485  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>
18486
18487
18488
18489<p><i>[
18490post Bellevue:
18491]</i></p>
18492
18493
18494<blockquote>
18495We are happy with the resolution as proposed, and we move this to Ready.
18496</blockquote>
18497
18498<p><i>[
18499Howard adds:
18500]</i></p>
18501
18502
18503<blockquote>
18504The proposed wording neglects the 3 newer to_string overloads.
18505</blockquote>
18506
18507
18508
18509
18510<hr>
18511<h3><a name="400"></a>400. redundant type cast in lib.allocator.members</h3>
18512<p><b>Section:</b> 20.8.8.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
18513 <b>Submitter:</b> Markus Mauhart <b>Opened:</b> 2003-02-27  <b>Last modified:</b> 2008-09-26</p>
18514<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>
18515<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
18516<p><b>Discussion:</b></p>
18517<p>
1851820.8.8.1 [allocator.members] allocator members, contains
18519the following 3 lines:
18520</p>
18521
18522<pre>  12 Returns: new((void *) p) T( val)
18523     void destroy(pointer p);
18524  13 Returns: ((T*) p)-&gt;~T()
18525</pre>
18526
18527<p>
18528The type cast "(T*) p" in the last line is redundant cause
18529we know that std::allocator&lt;T&gt;::pointer is a typedef for T*.
18530</p>
18531
18532
18533<p><b>Proposed resolution:</b></p>
18534<p>
18535Replace "((T*) p)" with "p".
18536</p>
18537
18538
18539<p><b>Rationale:</b></p><p>Just a typo, this is really editorial.</p>
18540
18541
18542
18543
18544<hr>
18545<h3><a name="401"></a>401.  incorrect type casts in table 32 in lib.allocator.requirements</h3>
18546<p><b>Section:</b> 20.2.2 [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
18547 <b>Submitter:</b> Markus Mauhart <b>Opened:</b> 2003-02-27  <b>Last modified:</b> 2008-09-26</p>
18548<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>
18549<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
18550<p><b>Discussion:</b></p>
18551<p>
18552I think that in par2 of  [default.con.req] the last two
18553lines of table 32 contain two incorrect type casts. The lines are ...
18554</p>
18555
18556<pre>  a.construct(p,t)   Effect: new((void*)p) T(t)
18557  a.destroy(p)       Effect: ((T*)p)?-&gt;~T()
18558</pre>
18559
18560<p>
18561.... with the prerequisits coming from the preceding two paragraphs, especially
18562from table 31:
18563</p>
18564
18565<pre>  alloc&lt;T&gt;             a     ;// an allocator for T
18566  alloc&lt;T&gt;::pointer    p     ;// random access iterator
18567                              // (may be different from T*)
18568  alloc&lt;T&gt;::reference  r = *p;// T&amp;
18569  T const&amp;             t     ;
18570</pre>
18571
18572<p>
18573For that two type casts ("(void*)p" and "(T*)p") to be well-formed
18574this would require then conversions to T* and void* for all
18575alloc&lt;T&gt;::pointer, so it would implicitely introduce extra
18576requirements for alloc&lt;T&gt;::pointer, additionally to the only
18577current requirement (being a random access iterator).
18578</p>
18579
18580
18581<p><b>Proposed resolution:</b></p>
18582
18583<p>
18584Accept proposed wording from
18585<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2436.pdf">N2436</a> part 1.
18586</p>
18587
18588<p>
18589Note: Actually I would prefer to replace "((T*)p)?-&gt;dtor_name" with
18590"p?-&gt;dtor_name", but AFAICS this is not possible cause of an omission
18591in 13.5.6 [over.ref] (for which I have filed another DR on 29.11.2002).
18592</p>
18593
18594<p><i>[Kona: The LWG thinks this is somewhere on the border between
18595  Open and NAD.  The intend is clear: <tt>construct</tt> constructs an
18596  object at the location <i>p</i>.  It's reading too much into the
18597  description to think that literally calling <tt>new</tt> is
18598  required.  Tweaking this description is low priority until we can do
18599  a thorough review of allocators, and, in particular, allocators with
18600  non-default pointer types.]</i></p>
18601
18602
18603<p><i>[
18604Batavia:  Proposed resolution changed to less code and more description.
18605]</i></p>
18606
18607
18608<p><i>[
18609post Oxford:  This would be rendered NAD Editorial by acceptance of
18610<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2257.html">N2257</a>.
18611]</i></p>
18612
18613
18614<p><i>[
18615Kona (2007): The LWG adopted the proposed resolution of N2387 for this issue which
18616was subsequently split out into a separate paper N2436 for the purposes of voting.
18617The resolution in N2436 addresses this issue.  The LWG voted to accelerate this
18618issue to Ready status to be voted into the WP at Kona.
18619]</i></p>
18620
18621
18622
18623
18624
18625
18626
18627<hr>
18628<h3><a name="402"></a>402. wrong new expression in [some_]allocator::construct</h3>
18629<p><b>Section:</b> 20.2.2 [allocator.requirements], 20.8.8.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
18630 <b>Submitter:</b> Markus Mauhart <b>Opened:</b> 2003-02-27  <b>Last modified:</b> 2008-09-26</p>
18631<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>
18632<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
18633<p><b>Discussion:</b></p>
18634<p>
18635This applies to the new expression that is contained in both par12 of
1863620.8.8.1 [allocator.members] and in par2 (table 32) of  [default.con.req].
18637I think this new expression is wrong, involving unintended side
18638effects.
18639</p>
18640
18641
18642<p>20.8.8.1 [allocator.members]  contains the following 3 lines:</p>
18643
18644<pre>  11 Returns: the largest value N for which the call allocate(N,0) might succeed.
18645     void construct(pointer p, const_reference val);
18646  12 Returns: new((void *) p) T( val)
18647</pre>
18648
18649
18650<p> [default.con.req] in table 32 has the following line:</p>
18651<pre>  a.construct(p,t)   Effect: new((void*)p) T(t)
18652</pre>
18653
18654<p>
18655.... with the prerequisits coming from the preceding two paragraphs,
18656especially from table 31:
18657</p>
18658
18659<pre>  alloc&lt;T&gt;             a     ;// an allocator for T
18660  alloc&lt;T&gt;::pointer    p     ;// random access iterator
18661                              // (may be different from T*)
18662  alloc&lt;T&gt;::reference  r = *p;// T&amp;
18663  T const&amp;             t     ;
18664</pre>
18665
18666<p>
18667Cause of using "new" but not "::new", any existing "T::operator new"
18668function will hide the global placement new function. When there is no
18669"T::operator new" with adequate signature,
18670every_alloc&lt;T&gt;::construct(..) is ill-formed, and most
18671std::container&lt;T,every_alloc&lt;T&gt;&gt; use it; a workaround
18672would be adding placement new and delete functions with adequate
18673signature and semantic to class T, but class T might come from another
18674party. Maybe even worse is the case when T has placement new and
18675delete functions with adequate signature but with "unknown" semantic:
18676I dont like to speculate about it, but whoever implements
18677any_container&lt;T,any_alloc&gt; and wants to use construct(..)
18678probably must think about it.
18679</p>
18680
18681
18682<p><b>Proposed resolution:</b></p>
18683<p>
18684Replace "new" with "::new" in both cases.
18685</p>
18686
18687
18688
18689
18690
18691
18692
18693<hr>
18694<h3><a name="403"></a>403. basic_string::swap should not throw exceptions</h3>
18695<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>
18696 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2003-03-25  <b>Last modified:</b> 2008-09-26</p>
18697<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>
18698<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
18699<p><b>Discussion:</b></p>
18700
18701<p>
18702std::basic_string, 21.4 [basic.string] paragraph 2 says that
18703basic_string "conforms to the requirements of a Sequence, as specified
18704in (23.1.1)." The sequence requirements specified in (23.1.1) to not
18705include any prohibition on swap members throwing exceptions.
18706</p>
18707
18708<p>
18709Section 23.2 [container.requirements] paragraph 10 does limit conditions under
18710which exceptions may be thrown, but applies only to "all container
18711types defined in this clause" and so excludes basic_string::swap
18712because it is defined elsewhere.
18713</p>
18714
18715<p>
18716Eric Niebler points out that 21.4 [basic.string] paragraph 5 explicitly
18717permits basic_string::swap to invalidates iterators, which is
18718disallowed by 23.2 [container.requirements] paragraph 10. Thus the standard would
18719be contradictory if it were read or extended to read as having
18720basic_string meet 23.2 [container.requirements] paragraph 10 requirements.
18721</p>
18722
18723<p>
18724Yet several LWG members have expressed the belief that the original
18725intent was that basic_string::swap should not throw exceptions as
18726specified by 23.2 [container.requirements] paragraph 10, and that the standard is
18727unclear on this issue. The complexity of basic_string::swap is
18728specified as "constant time", indicating the intent was to avoid
18729copying (which could cause a bad_alloc or other exception). An
18730important use of swap is to ensure that exceptions are not thrown in
18731exception-safe code.
18732</p>
18733
18734<p>
18735Note: There remains long standing concern over whether or not it is
18736possible to reasonably meet the 23.2 [container.requirements] paragraph 10 swap
18737requirements when allocators are unequal. The specification of
18738basic_string::swap exception requirements is in no way intended to
18739address, prejudice, or otherwise impact that concern.
18740</p>
18741
18742
18743
18744
18745
18746
18747
18748<p><b>Proposed resolution:</b></p>
18749<p>
18750In 21.4.6.8 [string::swap], add a throws clause:
18751</p>
18752
18753<p>
18754Throws: Shall not throw exceptions.
18755</p>
18756
18757
18758
18759
18760
18761<hr>
18762<h3><a name="404"></a>404. May a replacement allocation function be declared inline?</h3>
18763<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>
18764 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2003-04-24  <b>Last modified:</b> 2008-09-26</p>
18765<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
18766<p><b>Discussion:</b></p>
18767<p>
18768The eight basic dynamic memory allocation functions (single-object
18769and array versions of ::operator new and ::operator delete, in the
18770ordinary and nothrow forms) are replaceable.  A C++ program may
18771provide an alternative definition for any of them, which will be used
18772in preference to the implementation's definition.  
18773</p>
18774
18775<p>
18776Three different parts of the standard mention requirements on
18777replacement functions: 17.6.3.6 [replacement.functions], 18.6.1.1 [new.delete.single]
18778and 18.6.1.2 [new.delete.array], and 3.7.3 [basic.stc.auto].
18779</p>
18780
18781<p>None of these three places say whether a replacement function may
18782  be declared inline.  18.6.1.1 [new.delete.single] paragraph 2 specifies a
18783  signature for the replacement function, but that's not enough:
18784  the <tt>inline</tt> specifier is not part of a function's signature.
18785  One might also reason from 7.1.2 [dcl.fct.spec] paragraph 2, which
18786  requires that "an inline function shall be defined in every
18787  translation unit in which it is used," but this may not be quite
18788  specific enough either.  We should either explicitly allow or
18789  explicitly forbid inline replacement memory allocation
18790  functions.</p>
18791
18792
18793<p><b>Proposed resolution:</b></p>
18794<p>
18795Add a new sentence to the end of 17.6.3.6 [replacement.functions] paragraph 3:
18796"The program's definitions shall not be specified as <tt>inline</tt>.
18797No diagnostic is required."
18798</p>
18799
18800<p><i>[Kona: added "no diagnostic is required"]</i></p>
18801
18802
18803
18804
18805<p><b>Rationale:</b></p>
18806<p>
18807The fact that <tt>inline</tt> isn't mentioned appears to have been
18808nothing more than an oversight.  Existing implementations do not
18809permit inline functions as replacement memory allocation functions.
18810Providing this functionality would be difficult in some cases, and is
18811believed to be of limited value.
18812</p>
18813
18814
18815
18816
18817
18818<hr>
18819<h3><a name="405"></a>405. qsort and POD</h3>
18820<p><b>Section:</b> 25.5 [alg.c.library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
18821 <b>Submitter:</b> Ray Lischner <b>Opened:</b> 2003-04-08  <b>Last modified:</b> 2008-09-26</p>
18822<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>
18823<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
18824<p><b>Discussion:</b></p>
18825<p>
18826Section 25.5 [alg.c.library] describes bsearch and qsort, from the C
18827standard library. Paragraph 4 does not list any restrictions on qsort,
18828but it should limit the base parameter to point to POD.  Presumably,
18829qsort sorts the array by copying bytes, which requires POD.
18830</p>
18831
18832
18833<p><b>Proposed resolution:</b></p>
18834<p>
18835In 25.5 [alg.c.library] paragraph 4, just after the declarations and
18836before the nonnormative note, add these words: "both of which have the
18837same behavior as the original declaration.  The behavior is undefined
18838unless the objects in the array pointed to by <i>base</i> are of POD
18839type."
18840</p>
18841
18842<p><i>[Something along these lines is clearly necessary.  Matt
18843  provided wording.]</i></p>
18844
18845
18846
18847
18848
18849
18850<hr>
18851<h3><a name="406"></a>406. vector::insert(s) exception safety</h3>
18852<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>
18853 <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2003-04-27  <b>Last modified:</b> 2009-05-01</p>
18854<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>
18855<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
18856<p><b>Discussion:</b></p>
18857<p>
18858There is a possible defect in the standard: the standard text was
18859never intended to prevent arbitrary ForwardIterators, whose operations
18860may throw exceptions, from being passed, and it also wasn't intended
18861to require a temporary buffer in the case where ForwardIterators were
18862passed (and I think most implementations don't use one).  As is, the
18863standard appears to impose requirements that aren't met by any
18864existing implementation.
18865</p>
18866
18867
18868<p><b>Proposed resolution:</b></p>
18869<p>Replace 23.3.6.4 [vector.modifiers] paragraph 1 with:</p>
18870<blockquote><p>
18871  1- Notes: Causes reallocation if the new size is greater than the
18872  old capacity. If no reallocation happens, all the iterators and
18873  references before the insertion point remain valid. If an exception
18874  is thrown other than by the copy constructor or assignment operator
18875  of T or by any InputIterator operation there are no effects.
18876</p></blockquote>
18877
18878<p><i>[We probably need to say something similar for deque.]</i></p>
18879
18880
18881
18882
18883
18884
18885
18886<hr>
18887<h3><a name="407"></a>407. Can singular iterators be destroyed?</h3>
18888<p><b>Section:</b> X [iterator.concepts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
18889 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 2003-06-03  <b>Last modified:</b> 2008-09-30</p>
18890<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>
18891<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
18892<p><b>Discussion:</b></p>
18893<p>
18894Clause X [iterator.concepts], paragraph 5, says that the only expression
18895that is defined for a singular iterator is "an assignment of a
18896non-singular value to an iterator that holds a singular value".  This 
18897means that destroying a singular iterator (e.g. letting an automatic
18898variable go out of scope) is technically undefined behavior.  This
18899seems overly strict, and probably unintentional.
18900</p>
18901
18902
18903<p><b>Proposed resolution:</b></p>
18904<p>
18905Change the sentence in question to "... the only exceptions are
18906destroying an iterator that holds a singular value, or the assignment
18907of a non-singular value to an iterator that holds a singular value."
18908</p>
18909
18910
18911
18912
18913
18914<hr>
18915<h3><a name="409"></a>409. Closing an fstream should clear error state</h3>
18916<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>
18917 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 2003-06-03  <b>Last modified:</b> 2009-05-01</p>
18918<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>
18919<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
18920<p><b>Discussion:</b></p>
18921<p>
18922A strict reading of 27.9.1 [fstreams] shows that opening or
18923closing a basic_[io]fstream does not affect the error bits.  This
18924means, for example, that if you read through a file up to EOF, and
18925then close the stream and reopen it at the beginning of the file,
18926the EOF bit in the stream's error state is still set.  This is
18927counterintuitive.
18928</p>
18929<p>
18930The LWG considered this issue once before, as issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#22">22</a>,
18931and put in a footnote to clarify that the strict reading was indeed
18932correct.  We did that because we believed the standard was
18933unambiguous and consistent, and that we should not make architectural
18934changes in a TC.  Now that we're working on a new revision of the
18935language, those considerations no longer apply.
18936</p>
18937
18938
18939<p><b>Proposed resolution:</b></p>
18940
18941<p>Change 27.9.1.9 [ifstream.members], para. 3 from:</p>
18942
18943<blockquote><p>
18944Calls rdbuf()-&gt;open(s,mode|in). If that function returns a null
18945pointer, calls setstate(failbit) (which may throw ios_base::failure
18946[Footnote: (lib.iostate.flags)].
18947</p></blockquote>
18948
18949<p>to:</p>
18950
18951<blockquote><p>Calls rdbuf()-&gt;open(s,mode|in). If that function
18952returns a null pointer, calls setstate(failbit) (which may throw
18953ios_base::failure [Footnote: (lib.iostate.flags)), else calls clear().
18954</p></blockquote>
18955
18956<p>Change 27.9.1.13 [ofstream.members], para. 3 from:</p>
18957
18958<blockquote><p>Calls rdbuf()-&gt;open(s,mode|out). If that function
18959returns a null pointer, calls setstate(failbit) (which may throw
18960ios_base::failure [Footnote: (lib.iostate.flags)).
18961</p></blockquote>
18962
18963<p>to:</p>
18964
18965<blockquote><p>Calls rdbuf()-&gt;open(s,mode|out). If that function
18966returns a null pointer, calls setstate(failbit) (which may throw
18967ios_base::failure [Footnote: (lib.iostate.flags)), else calls clear().
18968</p></blockquote>
18969
18970<p>Change 27.9.1.17 [fstream.members], para. 3 from:</p>
18971
18972<blockquote><p>Calls rdbuf()-&gt;open(s,mode), If that function returns
18973a null pointer, calls setstate(failbit), (which may throw
18974ios_base::failure). (lib.iostate.flags) )
18975</p></blockquote>
18976
18977<p>to:</p>
18978
18979<blockquote><p>Calls rdbuf()-&gt;open(s,mode), If that function returns
18980a null pointer, calls setstate(failbit), (which may throw
18981ios_base::failure). (lib.iostate.flags) ), else calls clear().
18982</p></blockquote>
18983
18984
18985
18986<p><i>[Kona: the LWG agrees this is a good idea.  Post-Kona: Bill
18987provided wording.  He suggests having open, not close, clear the error
18988flags.]</i></p>
18989
18990
18991<p><i>[Post-Sydney: Howard provided a new proposed resolution.  The
18992  old one didn't make sense because it proposed to fix this at the
18993  level of basic_filebuf, which doesn't have access to the stream's
18994  error state.  Howard's proposed resolution fixes this at the level
18995  of the three fstream class template instead.]</i></p>
18996
18997
18998
18999
19000
19001
19002
19003
19004<hr>
19005<h3><a name="410"></a>410. Missing semantics for stack and queue comparison operators</h3>
19006<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>
19007 <b>Submitter:</b> Hans Bos <b>Opened:</b> 2003-06-07  <b>Last modified:</b> 2008-09-26</p>
19008<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>
19009<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
19010<p><b>Discussion:</b></p>
19011<p>
19012Sections 23.3.4.1 [list.cons] and 23.3.4.3 [list.modifiers] list
19013comparison operators (==, !=, &lt;, &lt;=, &gt;, =&gt;) for queue and
19014stack.  Only the semantics for queue::operator== (23.3.4.1 [list.cons] par2) and queue::operator&lt; (23.3.4.1 [list.cons]
19015par3) are defined.
19016</p>
19017
19018
19019<p><b>Proposed resolution:</b></p>
19020
19021<p>Add the following new paragraphs after 23.3.4.1 [list.cons]
19022  paragraph 3:</p>
19023
19024<blockquote>
19025
19026<pre>  operator!=
19027</pre>
19028<p>Returns: <tt>x.c != y.c</tt></p>
19029
19030<pre>  operator&gt;
19031</pre>
19032<p>Returns: <tt>x.c &gt; y.c</tt></p>
19033
19034<pre>  operator&lt;=
19035</pre>
19036<p>Returns: <tt>x.c &lt;= y.c</tt></p>
19037
19038<pre>  operator&gt;=
19039</pre>
19040<p>Returns: <tt>x.c &gt;= y.c</tt></p>
19041
19042</blockquote>
19043
19044<p>Add the following paragraphs at the end of 23.3.4.3 [list.modifiers]:</p>
19045
19046<blockquote>
19047
19048<pre>  operator==
19049</pre>
19050<p>Returns: <tt>x.c == y.c</tt></p>
19051
19052<pre>  operator&lt;
19053</pre>
19054<p>Returns: <tt>x.c &lt; y.c</tt></p>
19055
19056<pre>  operator!=
19057</pre>
19058<p>Returns: <tt>x.c != y.c</tt></p>
19059
19060<pre>  operator&gt;
19061</pre>
19062<p>Returns: <tt>x.c &gt; y.c</tt></p>
19063
19064<pre>  operator&lt;=
19065</pre>
19066<p>Returns: <tt>x.c &lt;= y.c</tt></p>
19067
19068<pre>  operator&gt;=
19069</pre>
19070<p>Returns: <tt>x.c &gt;= y.c</tt></p>
19071
19072</blockquote>
19073
19074
19075<p><i>[Kona: Matt provided wording.]</i></p>
19076
19077
19078
19079
19080<p><b>Rationale:</b></p>
19081<p>There isn't any real doubt about what these operators are
19082supposed to do, but we ought to spell it out.</p>
19083
19084
19085
19086
19087
19088<hr>
19089<h3><a name="411"></a>411. Wrong names of set member functions</h3>
19090<p><b>Section:</b> 25.4.5 [alg.set.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
19091 <b>Submitter:</b> Daniel Frey <b>Opened:</b> 2003-07-09  <b>Last modified:</b> 2008-09-26</p>
19092<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>
19093<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
19094<p><b>Discussion:</b></p>
19095<p>
1909625.4.5 [alg.set.operations] paragraph 1 reads:
19097"The semantics of the set operations are generalized to multisets in a 
19098standard way by defining union() to contain the maximum number of 
19099occurrences of every element, intersection() to contain the minimum, and 
19100so on."
19101</p>
19102
19103<p>
19104This is wrong.  The name of the functions are set_union() and
19105set_intersection(), not union() and intersection().
19106</p>
19107
19108
19109<p><b>Proposed resolution:</b></p>
19110<p>Change that sentence to use the correct names.</p>
19111
19112
19113
19114
19115
19116<hr>
19117<h3><a name="412"></a>412. Typo in 27.4.4.3</h3>
19118<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>
19119 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-07-10  <b>Last modified:</b> 2008-09-26</p>
19120<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>
19121<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
19122<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#429">429</a></p>
19123<p><b>Discussion:</b></p>
19124<p>
19125The Effects clause in 27.5.4.3 [iostate.flags] paragraph 5 says that the
19126function only throws if the respective bits are already set prior to
19127the function call. That's obviously not the intent. The typo ought to
19128be corrected and the text reworded as: "If (<i>state</i> &amp;
19129exceptions()) == 0, returns. ..."
19130</p>
19131
19132
19133<p><b>Proposed resolution:</b></p>
19134<p>
19135In 27.5.4.3 [iostate.flags] paragraph 5, replace "If (rdstate() &amp;
19136exceptions()) == 0" with "If ((state | (rdbuf() ? goodbit : badbit))
19137&amp; exceptions()) == 0".
19138</p>
19139
19140<p><i>[Kona: the original proposed resolution wasn't quite right.  We
19141  really do mean rdstate(); the ambiguity is that the wording in the
19142  standard doesn't make it clear whether we mean rdstate() before
19143  setting the new state, or rdsate() after setting it.  We intend the
19144  latter, of course. Post-Kona: Martin provided wording.]</i></p>
19145
19146
19147
19148
19149
19150
19151
19152<hr>
19153<h3><a name="413"></a>413. Proposed resolution to LDR#64 still wrong</h3>
19154<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>
19155 <b>Submitter:</b> Bo Persson <b>Opened:</b> 2003-07-13  <b>Last modified:</b> 2009-05-01</p>
19156<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>
19157<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
19158<p><b>Discussion:</b></p>
19159<p>
19160The second sentence of the proposed resolution says:
19161</p>
19162
19163<p>
19164"If it inserted no characters because it caught an exception thrown
19165while extracting characters from sb and ..."
19166</p>
19167
19168<p>
19169However, we are not extracting from sb, but extracting from the
19170basic_istream (*this) and inserting into sb. I can't really tell if
19171"extracting" or "sb" is a typo.
19172</p>
19173
19174<p><i>[
19175Sydney: Definitely a real issue. We are, indeed, extracting characters
19176from an istream and not from sb. The problem was there in the FDIS and
19177wasn't fixed by issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64">64</a>. Probably what was intended was
19178to have *this instead of sb. We're talking about the exception flag
19179state of a basic_istream object, and there's only one basic_istream
19180object in this discussion, so that would be a consistent
19181interpretation.  (But we need to be careful: the exception policy of
19182this member function must be consistent with that of other
19183extractors.)  PJP will provide wording.
19184]</i></p>
19185
19186
19187
19188
19189<p><b>Proposed resolution:</b></p>
19190<p>Change the sentence from:</p>
19191
19192<blockquote><p>
19193If it inserted no characters because it caught an exception thrown
19194while extracting characters from sb and failbit is on in exceptions(),
19195then the caught exception is rethrown.
19196</p></blockquote>
19197
19198<p>to:</p>
19199
19200<blockquote><p>
19201If it inserted no characters because it caught an exception thrown
19202while extracting characters from *this and failbit is on in exceptions(),
19203then the caught exception is rethrown.
19204</p></blockquote>
19205
19206
19207
19208
19209
19210<hr>
19211<h3><a name="414"></a>414. Which iterators are invalidated by v.erase()?</h3>
19212<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>
19213 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2003-08-19  <b>Last modified:</b> 2008-09-26</p>
19214<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>
19215<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
19216<p><b>Discussion:</b></p>
19217<p>
19218Consider the following code fragment:
19219</p>
19220<blockquote>
19221<pre>int A[8] = { 1,3,5,7,9,8,4,2 };
19222std::vector&lt;int&gt; v(A, A+8);
19223
19224std::vector&lt;int&gt;::iterator i1 = v.begin() + 3;
19225std::vector&lt;int&gt;::iterator i2 = v.begin() + 4;
19226v.erase(i1);
19227</pre>
19228</blockquote>
19229
19230<p>
19231Which iterators are invalidated by <tt>v.erase(i1)</tt>: i1, i2,
19232both, or neither?
19233</p>
19234
19235<p>
19236On all existing implementations that I know of, the status of i1 and
19237i2 is the same: both of them will be iterators that point to some
19238elements of the vector (albeit not the same elements they did
19239before).  You won't get a crash if you use them.  Depending on 
19240exactly what you mean by "invalidate", you might say that neither one
19241has been invalidated because they still point to <i>something</i>,
19242or you might say that both have been invalidated because in both
19243cases the elements they point to have been changed out from under the
19244iterator.
19245</p>
19246
19247<p>
19248The standard doesn't say either of those things.  It says that erase
19249invalidates all iterators and references "after the point of the
19250erase".  This doesn't include i1, since it's at the point of the
19251erase instead of after it.  I can't think of any sensible definition
19252of invalidation by which one can say that i2 is invalidated but i1
19253isn't.
19254</p>
19255
19256<p>
19257(This issue is important if you try to reason about iterator validity
19258based only on the guarantees in the standard, rather than reasoning
19259from typical implementation techniques.  Strict debugging modes,
19260which some programmers find useful, do not use typical implementation
19261techniques.)
19262</p>
19263
19264
19265<p><b>Proposed resolution:</b></p>
19266<p>
19267In 23.3.6.4 [vector.modifiers] paragraph 3, change "Invalidates all the
19268iterators and references after the point of the erase" to
19269"Invalidates iterators and references at or after the point of the
19270erase". 
19271</p>
19272
19273
19274<p><b>Rationale:</b></p>
19275<p>I believe this was essentially a typographical error, and that it
19276  was taken for granted that erasing an element invalidates iterators
19277  that point to it.  The effects clause in question treats iterators
19278  and references in parallel, and it would seem counterintuitive to
19279  say that a reference to an erased value remains valid.</p>
19280
19281
19282
19283
19284
19285<hr>
19286<h3><a name="415"></a>415. behavior of std::ws</h3>
19287<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>
19288 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18  <b>Last modified:</b> 2008-09-26</p>
19289<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
19290<p><b>Discussion:</b></p>
19291<p>
19292According to 27.6.1.4, the ws() manipulator is not required to construct
19293the sentry object. The manipulator is also not a member function so the
19294text in 27.6.1, p1 through 4 that describes the exception policy for
19295istream member functions does not apply. That seems inconsistent with
19296the rest of extractors and all the other input functions (i.e., ws will
19297not cause a tied stream to be flushed before extraction, it doesn't check
19298the stream's exceptions or catch exceptions thrown during input, and it
19299doesn't affect the stream's gcount).
19300</p>
19301
19302
19303<p><b>Proposed resolution:</b></p>
19304<p>
19305Add to 27.7.1.4 [istream.manip], immediately before the first sentence
19306of paragraph 1, the following text:
19307</p>
19308
19309    <blockquote><p>
19310    Behaves as an unformatted input function (as described in
19311    27.6.1.3, paragraph 1), except that it does not count the number
19312    of characters extracted and does not affect the value returned by
19313    subsequent calls to is.gcount(). After constructing a sentry
19314    object...  
19315    </p></blockquote>
19316
19317<p><i>[Post-Kona: Martin provided wording]</i></p>
19318
19319
19320
19321
19322
19323
19324<hr>
19325<h3><a name="416"></a>416. definitions of XXX_MIN and XXX_MAX macros in climits</h3>
19326<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>
19327 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18  <b>Last modified:</b> 2008-09-26</p>
19328<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
19329<p><b>Discussion:</b></p>
19330        <p>
19331
19332Given two overloads of the function foo(), one taking an argument of type
19333int and the other taking a long, which one will the call foo(LONG_MAX)
19334resolve to? The expected answer should be foo(long), but whether that
19335is true depends on the #defintion of the LONG_MAX macro, specifically
19336its type. This issue is about the fact that the type of these macros
19337is not actually required to be the same as the the type each respective
19338limit.
19339<br>
19340
19341Section 18.2.2 of the C++ Standard does not specify the exact types of
19342the XXX_MIN and XXX_MAX macros #defined in the &lt;climits&gt; and &lt;limits.h&gt;
19343headers such as INT_MAX and LONG_MAX and instead defers to the C standard.
19344<br>
19345
19346Section 5.2.4.2.1, p1 of the C standard specifies that "The values [of
19347these constants] shall be replaced by constant expressions suitable for use
19348in #if preprocessing directives. Moreover, except for CHAR_BIT and MB_LEN_MAX,
19349the following shall be replaced by expressions that have the same type as
19350would an expression that is an object of the corresponding type converted
19351according to the integer promotions."
19352<br>
19353
19354The "corresponding type converted according to the integer promotions" for
19355LONG_MAX is, according to 6.4.4.1, p5 of the C standard, the type of long
19356converted to the first of the following set of types that can represent it:
19357int, long int, long long int. So on an implementation where (sizeof(long)
19358== sizeof(int)) this type is actually int, while on an implementation where
19359(sizeof(long) &gt; sizeof(int)) holds this type will be long.
19360<br>
19361
19362This is not an issue in C since the type of the macro cannot be detected
19363by any conforming C program, but it presents a portability problem in C++
19364where the actual type is easily detectable by overload resolution.
19365
19366        </p>
19367<p><i>[Kona: the LWG does not believe this is a defect.  The C macro
19368  definitions are what they are; we've got a better
19369  mechanism, <tt>std::numeric_limits</tt>, that is specified more
19370  precisely than the C limit macros.  At most we should add a
19371  nonnormative note recommending that users who care about the exact
19372  types of limit quantities should use &lt;limits&gt; instead of
19373  &lt;climits&gt;.]</i></p>
19374
19375
19376    
19377
19378<p><b>Proposed resolution:</b></p>
19379
19380<p>
19381Change 18.3.2 [c.limits], paragraph 2:
19382</p>
19383
19384<blockquote><p>
19385-2- The contents are the same as the Standard C library header <tt>&lt;limits.h&gt;</tt>.
19386<ins>[<i>Note:</i> The types of the macros in <tt>&lt;climits&gt;</tt> are not guaranteed
19387to match the type to which they refer.<i>--end note</i>]</ins>
19388</p></blockquote>
19389
19390
19391
19392
19393
19394<hr>
19395<h3><a name="419"></a>419. istream extractors not setting failbit if eofbit is already set</h3>
19396<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#WP">WP</a>
19397 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18  <b>Last modified:</b> 2009-10-26</p>
19398<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>
19399<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
19400<p><b>Discussion:</b></p>
19401        <p>
19402
1940327.7.1.1.3 [istream::sentry], p2 says that istream::sentry ctor prepares for input if is.good()
19404is true. p4 then goes on to say that the ctor sets the sentry::ok_ member to
19405true if the stream state is good after any preparation. 27.7.1.2.1 [istream.formatted.reqmts], p1 then
19406says that a formatted input function endeavors to obtain the requested input
19407if the sentry's operator bool() returns true.
19408
19409Given these requirements, no formatted extractor should ever set failbit if
19410the initial stream rdstate() == eofbit. That is contrary to the behavior of
19411all implementations I tested. The program below prints out
19412
19413eof = 1, fail = 0
19414eof = 1, fail = 1
19415
19416on all of them.
19417        </p>
19418<pre>
19419#include &lt;sstream&gt;
19420#include &lt;cstdio&gt;
19421
19422int main()
19423{
19424    std::istringstream strm ("1");
19425
19426    int i = 0;
19427
19428    strm &gt;&gt; i;
19429
19430    std::printf ("eof = %d, fail = %d\n",
19431                 !!strm.eof (), !!strm.fail ());
19432
19433    strm &gt;&gt; i;
19434
19435    std::printf ("eof = %d, fail = %d\n",
19436                 !!strm.eof (), !!strm.fail ());
19437}
19438
19439</pre>
19440        <p>
19441<br>
19442
19443Comments from Jerry Schwarz (c++std-lib-11373):
19444<br>
19445
19446Jerry Schwarz wrote:
19447<br>
19448
19449I don't know where (if anywhere) it says it in the standard, but the
19450formatted extractors are supposed to set failbit if they don't extract
19451any characters. If they didn't then simple loops like
19452<br>
19453
19454while (cin &gt;&gt; x);
19455<br>
19456
19457would loop forever.
19458<br>
19459
19460Further comments from Martin Sebor:
19461<br>
19462
19463The question is which part of the extraction should prevent this from happening
19464by setting failbit when eofbit is already set. It could either be the sentry
19465object or the extractor. It seems that most implementations have chosen to
19466set failbit in the sentry [...] so that's the text that will need to be
19467corrected. 
19468
19469        </p>
19470<p>
19471Pre Berlin:  This issue is related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#342">342</a>.  If the sentry
19472sets <tt>failbit</tt> when it finds <tt>eofbit</tt> already set, then
19473you can never seek away from the end of stream.
19474</p>
19475<p>Kona: Possibly NAD.  If eofbit is set then good() will return false.  We
19476  then set <i>ok</i> to false.  We believe that the sentry's
19477  constructor should always set failbit when <i>ok</i> is false, and
19478  we also think the standard already says that.  Possibly it could be
19479  clearer.</p> 
19480
19481
19482<p><i>[
194832009-07 Frankfurt
19484]</i></p>
19485
19486
19487<blockquote>
19488Moved to Ready.
19489</blockquote>
19490
19491    
19492
19493<p><b>Proposed resolution:</b></p>
19494<p>
19495Change 27.7.1.1.3 [istream::sentry], p2 to:
19496</p>
19497
19498<blockquote>
19499<pre>explicit sentry(basic_istream&lt;charT,traits&gt;&amp; <i>is</i> , bool <i>noskipws</i> = false);</pre>
19500<p>
19501-2- <i>Effects:</i> If <tt>is.good()</tt> is <del><tt>true</tt></del>
19502<ins><tt>false</tt></ins>, <ins>calls <tt>is.setstate(failbit)</tt>. 
19503Otherwise</ins> prepares for formatted or unformatted input. ...
19504</p>
19505</blockquote>
19506
19507
19508
19509
19510
19511
19512<hr>
19513<h3><a name="420"></a>420. is std::FILE a complete type?</h3>
19514<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>
19515 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18  <b>Last modified:</b> 2008-09-26</p>
19516<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>
19517<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
19518<p><b>Discussion:</b></p>
19519<p>
195207.19.1, p2, of C99 requires that the FILE type only be declared in
19521&lt;stdio.h&gt;.  None of the (implementation-defined) members of the
19522struct is mentioned anywhere for obvious reasons.
19523</p>
19524
19525<p>
19526C++ says in 27.8.1, p2 that FILE is a type that's defined in &lt;cstdio&gt;. Is
19527it really the intent that FILE be a complete type or is an implementation
19528allowed to just declare it without providing a full definition?
19529</p>
19530
19531
19532<p><b>Proposed resolution:</b></p>
19533<p>In the first sentence of 27.9.1 [fstreams] paragraph 2, change
19534  "defined" to "declared".</p>
19535
19536
19537<p><b>Rationale:</b></p>
19538<p>We don't want to impose any restrictions beyond what the C standard
19539  already says. We don't want to make anything implementation defined,
19540  because that imposes new requirements in implementations.</p>
19541
19542
19543
19544
19545
19546<hr>
19547<h3><a name="422"></a>422. explicit specializations of member functions of class templates</h3>
19548<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>
19549 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18  <b>Last modified:</b> 2008-09-26</p>
19550<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>
19551<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
19552<p><b>Discussion:</b></p>
19553<p>
19554It has been suggested that 17.4.3.1, p1 may or may not allow programs to
19555explicitly specialize members of standard templates on user-defined types.
19556The answer to the question might have an impact where library requirements
19557are given using the "as if" rule. I.e., if programs are allowed to specialize
19558member functions they will be able to detect an implementation's strict
19559conformance to Effects clauses that describe the behavior of the function
19560in terms of the other member function (the one explicitly specialized by
19561the program) by relying on the "as if" rule.
19562</p>
19563
19564
19565<p><b>Proposed resolution:</b></p>
19566
19567<p>
19568  Add the following sentence to 17.6.3.3 [reserved.names], p1:
19569</p>
19570
19571<blockquote><p>
19572It is undefined for a C++ program to add declarations or definitions to
19573namespace std or namespaces within namespace <tt>std</tt> unless otherwise specified. A
19574program may add template specializations for any standard library template to
19575namespace <tt>std</tt>. Such a specialization (complete or partial) of a standard library
19576template results in undefined behavior unless the declaration depends on a
19577user-defined type of external linkage and unless the specialization meets the
19578standard library requirements for the original template.<sup>168)</sup>
19579<ins>A program has undefined behavior if it declares</ins>
19580</p>
19581<ul>
19582<li><ins>an explicit specialization of any member function of a standard
19583            library class template, or</ins></li>
19584<li><ins>an explicit specialization of any member function template of a
19585            standard library class or class template, or</ins></li>
19586<li><ins>an explicit or partial specialization of any member class
19587            template of a standard library class or class template.</ins></li>
19588</ul>
19589<p>
19590A program may explicitly instantiate any templates in the standard library only
19591if the declaration depends on the name of a user-defined type of external
19592linkage and the instantiation meets the standard library requirements for the
19593original template.
19594</p></blockquote>
19595
19596<p><i>[Kona: straw poll was 6-1 that user programs should not be
19597  allowed to specialize individual member functions of standard
19598  library class templates, and that doing so invokes undefined
19599  behavior. Post-Kona: Martin provided wording.]</i></p>
19600
19601
19602<p><i>[Sydney: The LWG agrees that the standard shouldn't permit users
19603to specialize individual member functions unless they specialize the
19604whole class, but we're not sure these words say what we want them to;
19605they could be read as prohibiting the specialization of any standard
19606library class templates. We need to consult with CWG to make sure we
19607use the right wording.]</i></p>
19608
19609
19610
19611
19612
19613
19614<hr>
19615<h3><a name="425"></a>425. return value of std::get_temporary_buffer</h3>
19616<p><b>Section:</b> 20.8.11 [temporary.buffer] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
19617 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18  <b>Last modified:</b> 2008-09-26</p>
19618<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
19619<p><b>Discussion:</b></p>
19620<p>
19621The standard is not clear about the requirements on the value returned from
19622a call to get_temporary_buffer(0). In particular, it fails to specify whether
19623the call should return a distinct pointer each time it is called (like
19624operator new), or whether the value is unspecified (as if returned by
19625malloc). The standard also fails to mention what the required behavior
19626is when the argument is less than 0.
19627</p>
19628
19629
19630<p><b>Proposed resolution:</b></p>
19631<p>Change 20.6.3 [meta.help] paragraph 2 from "...or a pair of 0
19632values if no storage can be obtained" to "...or a pair of 0 values if
19633no storage can be obtained or if <i>n</i> &lt;= 0."</p>
19634<p><i>[Kona: Matt provided wording]</i></p>
19635
19636
19637
19638
19639
19640<hr>
19641<h3><a name="426"></a>426. search_n(), fill_n(), and generate_n() with negative n</h3>
19642<p><b>Section:</b> 25.2.12 [alg.search], 25.3.6 [alg.fill], 25.3.7 [alg.generate] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
19643 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18  <b>Last modified:</b> 2008-09-26</p>
19644<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>
19645<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
19646<p><b>Discussion:</b></p>
19647<p>
19648The complexity requirements for these function templates are incorrect
19649(or don't even make sense) for negative n:</p>
19650
19651<p>25.1.9, p7 (search_n):
19652<br>
19653Complexity: At most (last1 - first1) * count applications
19654of the corresponding predicate.</p>
19655
19656<p>25.2.5, p3 (fill_n):
19657<br>
19658Complexity: Exactly last - first (or n) assignments.</p>
19659
19660<p>25.2.6, p3 (generate_n):
19661<br>
19662Complexity: Exactly last - first (or n) assignments.</p>
19663
19664<p>
19665In addition, the Requirements or the Effects clauses for the latter two
19666templates don't say anything about the behavior when n is negative.
19667</p>
19668
19669
19670<p><b>Proposed resolution:</b></p>
19671<p>Change 25.1.9, p7 to</p>
19672
19673<blockquote><p>
19674Complexity: At most (last1 - first1) * count applications
19675of the corresponding predicate if count is positive,
19676or 0 otherwise.
19677</p></blockquote>
19678
19679<p>Change 25.2.5, p2 to</p>
19680<blockquote><p>
19681Effects: Assigns value through all the iterators in the range [first,
19682last), or [first, first + n) if n is positive, none otherwise.
19683</p></blockquote>
19684
19685<p>Change 25.2.5, p3 to:</p>
19686<blockquote><p>
19687Complexity: Exactly last - first (or n if n is positive,
19688or 0 otherwise) assignments.
19689</p></blockquote>
19690
19691<p>
19692Change 25.2.6, p1 
19693to (notice the correction for the misspelled "through"):
19694</p>
19695<blockquote><p>
19696Effects: Invokes the function object genand assigns the return
19697value of gen through all the iterators in the range [first, last),
19698or [first, first + n) if n is positive, or [first, first)
19699otherwise.
19700</p></blockquote>
19701
19702<p>Change 25.2.6, p3 to:</p>
19703<blockquote><p>
19704Complexity: Exactly last - first (or n if n is positive,
19705or 0 otherwise) assignments.
19706</p></blockquote>
19707
19708
19709<p><b>Rationale:</b></p>
19710<p>Informally, we want to say that whenever we see a negative number
19711  we treat it the same as if it were zero.  We believe the above
19712  changes do that (although they may not be the minimal way of saying
19713  so).  The LWG considered and rejected the alternative of saying that
19714  negative numbers are undefined behavior.</p>
19715
19716
19717
19718
19719
19720<hr>
19721<h3><a name="428"></a>428. string::erase(iterator) validity</h3>
19722<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>
19723 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18  <b>Last modified:</b> 2008-09-26</p>
19724<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>
19725<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
19726<p><b>Discussion:</b></p>
19727<p>
1972823.1.1, p3 along with Table 67 specify as a prerequisite for a.erase(q)
19729that q must be a valid dereferenceable iterator into the sequence a.
19730</p>
19731
19732<p>
19733However, 21.3.5.5, p5 describing string::erase(p) only requires that
19734p be a valid iterator.
19735</p>
19736
19737<p>
19738This may be interepreted as a relaxation of the general requirement,
19739which is most likely not the intent.
19740</p>
19741
19742
19743<p><b>Proposed resolution:</b></p>
19744<p>Remove 21.4.6.5 [string::erase] paragraph 5.</p>
19745
19746
19747<p><b>Rationale:</b></p>
19748<p>The LWG considered two options: changing the string requirements to
19749  match the general container requirements, or just removing the
19750  erroneous string requirements altogether.  The LWG chose the latter
19751  option, on the grounds that duplicating text always risks the
19752  possibility that it might be duplicated incorrectly.</p>
19753
19754
19755
19756
19757
19758<hr>
19759<h3><a name="432"></a>432. stringbuf::overflow() makes only one write position available</h3>
19760<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>
19761 <b>Submitter:</b> Christian W Brock <b>Opened:</b> 2003-09-24  <b>Last modified:</b> 2008-09-26</p>
19762<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>
19763<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
19764<p><b>Discussion:</b></p>
19765<p>27.7.1.3 par 8 says:</p>
19766<blockquote><p>
19767Notes: The function can make a write position available only if
19768    ( mode &amp; ios_base::out) != 0. To make a write position
19769    available, the function reallocates (or initially allocates) an
19770    array object with a sufficient number of elements to hold the
19771    current array object (if any), plus one additional write position.
19772    If ( mode &amp; ios_base::in) != 0, the function alters the read end
19773    pointer egptr() to point just past the new write position (as
19774    does the write end pointer epptr()).
19775</p></blockquote>
19776
19777<p>
19778The sentences "plus one additional write position." and especially
19779    "(as does the write end pointer epptr())" COULD by interpreted
19780    (and is interpreted by at least my library vendor) as:
19781</p>
19782
19783<blockquote><p>
19784    post-condition: epptr() == pptr()+1
19785</p></blockquote>
19786
19787<p>
19788This WOULD force sputc() to call the virtual overflow() each time.
19789</p>
19790
19791<p>The proposed change also affects Defect Report 169.</p>
19792
19793
19794
19795<p><b>Proposed resolution:</b></p>
19796<p>27.7.1.1/2 Change:</p>
19797
19798<blockquote><p>
197992- Notes: The function allocates no array object.
19800</p></blockquote>
19801
19802<p>
19803to:
19804</p>
19805
19806<blockquote><p>
198072- Postcondition: str() == "".
19808</p></blockquote>
19809
19810<p>
1981127.7.1.1/3 Change:
19812</p>
19813
19814<blockquote>
19815<p>
19816-3- Effects: Constructs an object of class basic_stringbuf,
19817initializing the base class with basic_streambuf()
19818(lib.streambuf.cons), and initializing mode with which . Then copies
19819the content of str into the basic_stringbuf underlying character
19820sequence and initializes the input and output sequences according to
19821which. If which &amp; ios_base::out is true, initializes the output
19822sequence with the underlying sequence. If which &amp; ios_base::in is
19823true, initializes the input sequence with the underlying sequence.
19824</p>
19825</blockquote>
19826
19827<p>to:</p>
19828
19829<blockquote>
19830<p>
19831-3- Effects: Constructs an object of class basic_stringbuf,
19832initializing the base class with basic_streambuf()
19833(lib.streambuf.cons), and initializing mode with which. Then copies
19834the content of str into the basic_stringbuf underlying character
19835sequence. If which &amp; ios_base::out is true, initializes the output
19836sequence such that pbase() points to the first underlying character,
19837epptr() points one past the last underlying character, and if (which &amp;
19838ios_base::ate) is true, pptr() is set equal to
19839epptr() else pptr() is set equal to pbase(). If which &amp; ios_base::in
19840is true, initializes the input sequence such that eback() and gptr()
19841point to the first underlying character and egptr() points one past
19842the last underlying character.
19843</p>
19844</blockquote>
19845
19846<p>27.7.1.2/1 Change:</p>
19847
19848<blockquote>
19849<p>
19850-1- Returns: A basic_string object whose content is equal to the
19851basic_stringbuf underlying character sequence. If the buffer is only
19852created in input mode, the underlying character sequence is equal to
19853the input sequence; otherwise, it is equal to the output sequence. In
19854case of an empty underlying character sequence, the function returns
19855basic_string&lt;charT,traits,Allocator&gt;().
19856</p>
19857</blockquote>
19858
19859<p>to:</p>
19860
19861<blockquote>
19862<p>
19863-1- Returns: A basic_string object whose content is equal to the
19864basic_stringbuf underlying character sequence. If the basic_stringbuf
19865was created only in input mode, the resultant basic_string contains
19866the character sequence in the range [eback(), egptr()).  If the
19867basic_stringbuf was created with (which &amp; ios_base::out) being true
19868then the resultant basic_string contains the character sequence in the
19869range [pbase(), high_mark) where high_mark represents the position one
19870past the highest initialized character in the buffer.  Characters can
19871be initialized either through writing to the stream, or by
19872constructing the basic_stringbuf with a basic_string, or by calling
19873the str(basic_string) member function.  In the case of calling the
19874str(basic_string) member function, all characters initialized prior to
19875the call are now considered uninitialized (except for those
19876characters re-initialized by the new basic_string).  Otherwise the
19877basic_stringbuf has been created in neither input nor output mode and
19878a zero length basic_string is returned.
19879</p>
19880</blockquote>
19881
19882<p>
1988327.7.1.2/2 Change:
19884</p>
19885
19886<blockquote>
19887<p>
19888-2- Effects: If the basic_stringbuf's underlying character sequence is
19889not empty, deallocates it. Then copies the content of s into the
19890basic_stringbuf underlying character sequence and initializes the
19891input and output sequences according to the mode stored when creating
19892the basic_stringbuf object. If (mode&amp;ios_base::out) is true, then
19893initializes the output sequence with the underlying sequence. If
19894(mode&amp;ios_base::in) is true, then initializes the input sequence with
19895the underlying sequence.
19896</p>
19897</blockquote>
19898
19899<p>to:</p>
19900
19901<blockquote>
19902<p>
19903-2- Effects: Copies the content of s into the basic_stringbuf
19904underlying character sequence. If mode &amp; ios_base::out is true,
19905initializes the output sequence such that pbase() points to the first
19906underlying character, epptr() points one past the last underlying
19907character, and if (mode &amp; ios_base::ate) is true,
19908pptr() is set equal to epptr() else pptr() is set equal to pbase(). If
19909mode &amp; ios_base::in is true, initializes the input sequence such that
19910eback() and gptr() point to the first underlying character and egptr()
19911points one past the last underlying character.
19912</p>
19913</blockquote>
19914
19915<p>Remove 27.2.1.2/3.  (Same rationale as issue 238: incorrect and unnecessary.)</p>
19916
19917<p>27.7.1.3/1 Change:</p>
19918
19919<blockquote>
19920<p>
199211- Returns: If the input sequence has a read position available,
19922returns traits::to_int_type(*gptr()).  Otherwise, returns
19923traits::eof().
19924</p>
19925</blockquote>
19926
19927<p>to:</p>
19928
19929<blockquote>
19930<p>
199311- Returns: If the input sequence has a read position available,
19932returns traits::to_int_type(*gptr()).  Otherwise, returns
19933traits::eof().  Any character in the underlying buffer which has been
19934initialized is considered to be part of the input sequence.
19935</p>
19936</blockquote>
19937
19938<p>27.7.1.3/9 Change:</p>
19939
19940<blockquote>
19941<p>
19942-9- Notes: The function can make a write position available only if (
19943mode &amp; ios_base::out) != 0. To make a write position available, the
19944function reallocates (or initially allocates) an array object with a
19945sufficient number of elements to hold the current array object (if
19946any), plus one additional write position. If ( mode &amp; ios_base::in) !=
199470, the function alters the read end pointer egptr() to point just past
19948the new write position (as does the write end pointer epptr()).
19949</p>
19950</blockquote>
19951
19952<p>to:</p>
19953
19954<blockquote>
19955<p>
19956-9- The function can make a write position available only if ( mode &amp;
19957ios_base::out) != 0. To make a write position available, the function
19958reallocates (or initially allocates) an array object with a sufficient
19959number of elements to hold the current array object (if any), plus one
19960additional write position. If ( mode &amp; ios_base::in) != 0, the
19961function alters the read end pointer egptr() to point just past the
19962new write position.
19963</p>
19964</blockquote>
19965
19966<p>27.7.1.3/12 Change:</p>
19967
19968<blockquote>
19969<p>
19970-12- _ If (newoff + off) &lt; 0, or (xend - xbeg) &lt; (newoff + off), the
19971positioning operation fails. Otherwise, the function assigns xbeg +
19972newoff + off to the next pointer xnext .
19973</p>
19974</blockquote>
19975
19976<p>to:</p>
19977
19978<blockquote>
19979<p>
19980-12- _ If (newoff + off) &lt; 0, or if (newoff + off) refers to an
19981uninitialized character (as defined in 27.8.1.3 [stringbuf.members]
19982paragraph 1), the positioning operation fails. Otherwise, the function
19983assigns xbeg + newoff + off to the next pointer xnext .
19984</p>
19985</blockquote>
19986
19987<p><i>[post-Kona: Howard provided wording.  At Kona the LWG agreed that
19988  something along these lines was a good idea, but the original
19989  proposed resolution didn't say enough about the effect of various
19990  member functions on the underlying character sequences.]</i></p>
19991
19992
19993
19994
19995<p><b>Rationale:</b></p>
19996<p>The current basic_stringbuf description is over-constrained in such
19997a way as to prohibit vendors from making this the high-performance
19998in-memory stream it was meant to be.  The fundamental problem is that
19999the pointers: eback(), gptr(), egptr(), pbase(), pptr(), epptr() are
20000observable from a derived client, and the current description
20001restricts the range [pbase(), epptr()) from being grown geometrically.
20002This change allows, but does not require, geometric growth of this
20003range.</p>
20004
20005<p>Backwards compatibility issues: These changes will break code that
20006derives from basic_stringbuf, observes epptr(), and depends upon
20007[pbase(), epptr()) growing by one character on each call to overflow()
20008(i.e. test suites).  Otherwise there are no backwards compatibility
20009issues.</p>
20010
20011<p>27.7.1.1/2: The non-normative note is non-binding, and if it were
20012binding, would be over specification.  The recommended change focuses
20013on the important observable fact.</p>
20014
20015<p>27.7.1.1/3: This change does two things: 1.  It describes exactly
20016what must happen in terms of the sequences.  The terms "input
20017sequence" and "output sequence" are not well defined.  2.  It
20018introduces a common extension: open with app or ate mode.  I concur
20019with issue 238 that paragraph 4 is both wrong and unnecessary.</p>
20020
20021<p>27.7.1.2/1: This change is the crux of the efficiency issue.  The
20022resultant basic_string is not dependent upon epptr(), and thus
20023implementors are free to grow the underlying buffer geometrically
20024during overflow() *and* place epptr() at the end of that buffer.</p>
20025
20026<p>27.7.1.2/2:  Made consistent with the proposed 27.7.1.1/3.</p>
20027
20028<p>27.7.1.3/1: Clarifies that characters written to the stream beyond
20029the initially specified string are available for reading in an i/o
20030basic_streambuf.</p>
20031
20032<p>27.7.1.3/9: Made normative by removing "Notes:", and removed the
20033trailing parenthetical comment concerning epptr().</p>
20034
20035<p>27.7.1.3/12: Restricting the positioning to [xbeg, xend) is no
20036longer allowable since [pbase(), epptr()) may now contain
20037uninitialized characters.  Positioning is only allowable over the
20038initialized range.</p>
20039
20040
20041
20042
20043
20044<hr>
20045<h3><a name="434"></a>434. bitset::to_string() hard to use</h3>
20046<p><b>Section:</b> 20.3.7.2 [bitset.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
20047 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-10-15  <b>Last modified:</b> 2009-05-01</p>
20048<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>
20049<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
20050<p><b>Discussion:</b></p>
20051<p>
20052It has been pointed out a number of times that the bitset to_string() member
20053function template is tedious to use since callers must explicitly specify the
20054entire template argument list (3 arguments). At least two implementations
20055provide a number of overloads of this template to make it easier to use.
20056</p>
20057
20058
20059
20060<p><b>Proposed resolution:</b></p>
20061<p>In order to allow callers to specify no template arguments at all, just the
20062first one (charT), or the first 2 (charT and traits), in addition to all
20063three template arguments, add the following three overloads to both the
20064interface (declarations only) of the class template bitset as well as to
20065section 23.3.5.2, immediately after p34, the Returns clause of the existing
20066to_string() member function template:</p>
20067
20068<pre>    template &lt;class charT, class traits&gt;
20069    basic_string&lt;charT, traits, allocator&lt;charT&gt; &gt;
20070    to_string () const;
20071
20072    -34.1- Returns: to_string&lt;charT, traits, allocator&lt;charT&gt; &gt;().
20073
20074    template &lt;class charT&gt;
20075    basic_string&lt;charT, char_traits&lt;charT&gt;, allocator&lt;charT&gt; &gt;
20076    to_string () const;
20077
20078    -34.2- Returns: to_string&lt;charT, char_traits&lt;charT&gt;, allocator&lt;charT&gt; &gt;().
20079
20080    basic_string&lt;char, char_traits&lt;char&gt;, allocator&lt;char&gt; &gt;
20081    to_string () const;
20082
20083    -34.3- Returns: to_string&lt;char, char_traits&lt;char&gt;, allocator&lt;char&gt; &gt;().
20084</pre>
20085
20086<p><i>[Kona: the LWG agrees that this is an improvement over the
20087  status quo.  Dietmar thought about an alternative using a proxy
20088  object but now believes that the proposed resolution above is the
20089  right choice.
20090]</i></p>
20091
20092
20093
20094
20095
20096
20097
20098
20099<hr>
20100<h3><a name="435"></a>435. bug in DR 25</h3>
20101<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>
20102 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-10-15  <b>Last modified:</b> 2008-09-26</p>
20103<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>
20104<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
20105<p><b>Discussion:</b></p>
20106
20107<p>
20108It has been pointed out that the proposed resolution in DR 25 may not be
20109quite up to snuff: <br>
20110http://gcc.gnu.org/ml/libstdc++/2003-09/msg00147.html
20111http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#25<br>
20112</p>
20113
20114<p>
20115It looks like Petur is right. The complete corrected text is copied below.
20116I think we may have have been confused by the reference to 22.2.2.2.2 and
20117the subsequent description of `n' which actually talks about the second
20118argument to sputn(), not about the number of fill characters to pad with.
20119</p>
20120
20121<p>
20122So the question is: was the original text correct? If the intent was to
20123follow classic iostreams then it most likely wasn't, since setting width()
20124to less than the length of the string doesn't truncate it on output. This
20125is also the behavior of most implementations (except for SGI's standard
20126iostreams where the operator does truncate).
20127</p>
20128
20129
20130
20131<p><b>Proposed resolution:</b></p>
20132<p>Change the text in 21.3.7.9, p4 from</p>
20133    <blockquote><p>
20134    If bool(k) is true, inserts characters as if by calling
20135    os.rdbuf()-&gt;sputn(str.data(), n), padding as described in stage 3
20136    of lib.facet.num.put.virtuals, where n is the larger of os.width()
20137    and str.size(); 
20138    </p></blockquote>
20139<p>to</p>
20140    <blockquote><p>
20141    If bool(k) is true, determines padding as described in
20142    lib.facet.num.put.virtuals, and then inserts the resulting
20143    sequence of characters <tt>seq</tt> as if by calling
20144    <tt>os.rdbuf()-&gt;sputn(seq, n)</tt>, where <tt>n</tt> is the larger of
20145    <tt>os.width()</tt> and <tt>str.size()</tt>;
20146     </p></blockquote>
20147
20148<p><i>[Kona: it appears that neither the original wording, DR25, nor the
20149  proposed resolution, is quite what we want.  We want to say that
20150  the string will be output, padded to os.width() if necessary.  We
20151  don't want to duplicate the padding rules in clause 22, because
20152  they're complicated, but we need to be careful because they weren't
20153  quite written with quite this case in mind.  We need to say what
20154  the character sequence is, and then defer to clause 22.  Post-Kona:
20155  Benjamin provided wording.]</i></p>
20156
20157
20158
20159
20160
20161
20162
20163<hr>
20164<h3><a name="436"></a>436. are cv-qualified facet types valid facets?</h3>
20165<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>
20166 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-10-15  <b>Last modified:</b> 2008-09-26</p>
20167<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
20168<p><b>Discussion:</b></p>
20169<p>
20170Is "const std::ctype&lt;char&gt;" a valid template argument to has_facet, use_facet,
20171and the locale template ctor? And if so, does it designate the same Facet as
20172the non-const "std::ctype&lt;char&gt;?" What about "volatile std::ctype&lt;char&gt;?"
20173Different implementations behave differently: some fail to compile, others
20174accept such types but behave inconsistently.
20175</p>
20176
20177
20178<p><b>Proposed resolution:</b></p>
20179<p>Change 22.1.1.1.2, p1 to read:</p>
20180
20181<p>Template parameters in this clause which are required to be facets
20182are those named Facet in declarations. A program that passes a type
20183that is not a facet, or a type that refers to volatile-qualified
20184facet, as an (explicit or deduced) template parameter to a locale
20185function expecting a facet, is ill-formed.  A const-qualified facet is
20186a valid template argument to any locale function that expects a Facet
20187template parameter.</p>
20188
20189<p><i>[Kona: changed the last sentence from a footnote to normative
20190text.]</i></p>
20191
20192
20193
20194
20195
20196
20197<hr>
20198<h3><a name="438"></a>438. Ambiguity in the "do the right thing" clause</h3>
20199<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>
20200 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2003-10-20  <b>Last modified:</b> 2009-05-01</p>
20201<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>
20202<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>
20203<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
20204<p><b>Discussion:</b></p>
20205
20206<p>Section 23.2.3 [sequence.reqmts], paragraphs 9-11, fixed up the problem
20207noticed with statements like:</p>
20208<pre>vector&lt;int&gt; v(10, 1);
20209</pre>
20210
20211<p>The intent of the above statement was to construct with:</p>
20212<pre>vector(size_type, const value_type&amp;);
20213</pre>
20214
20215<p>but early implementations failed to compile as they bound to:</p>
20216<pre>template &lt;class InputIterator&gt;
20217vector(InputIterator f, InputIterator l);
20218</pre>
20219<p>instead.</p>
20220
20221<p>Paragraphs 9-11 say that if InputIterator is an integral type, then the
20222member template constructor will have the same effect as:</p>
20223<pre>vector&lt;static_cast&lt;size_type&gt;(f), static_cast&lt;value_type&gt;(l));
20224</pre>
20225<p>(and similarly for the other member template functions of sequences).</p>
20226
20227<p>There is also a note that describes one implementation technique:</p>
20228<blockquote><p>
20229   One way that sequence implementors can satisfy this requirement is to
20230   specialize the member template for every integral type.
20231</p></blockquote>
20232
20233<p>This might look something like:</p>
20234<blockquote>
20235<pre>template &lt;class T&gt;
20236struct vector
20237{
20238     typedef unsigned size_type;
20239
20240     explicit vector(size_type) {}
20241     vector(size_type, const T&amp;) {}
20242
20243     template &lt;class I&gt;
20244     vector(I, I);
20245
20246     // ...
20247};
20248
20249template &lt;class T&gt;
20250template &lt;class I&gt;
20251vector&lt;T&gt;::vector(I, I) { ... }
20252
20253template &lt;&gt;
20254template &lt;&gt;
20255vector&lt;int&gt;::vector(int, int) { ... }
20256
20257template &lt;&gt;
20258template &lt;&gt;
20259vector&lt;int&gt;::vector(unsigned, unsigned) { ... }
20260
20261//  ...
20262</pre>
20263</blockquote>
20264
20265<p>Label this solution 'A'.</p>
20266
20267<p>The standard also says:</p>
20268<blockquote><p>
20269 Less cumbersome implementation techniques also exist.
20270</p></blockquote>
20271<p>
20272A popular technique is to not specialize as above, but instead catch
20273every call with the member template, detect the type of InputIterator,
20274and then redirect to the correct logic.  Something like:
20275</p>
20276<blockquote>
20277<pre>template &lt;class T&gt;
20278template &lt;class I&gt;
20279vector&lt;T&gt;::vector(I f, I l)
20280{
20281     choose_init(f, l, int2type&lt;is_integral&lt;I&gt;::value&gt;());
20282}
20283
20284template &lt;class T&gt;
20285template &lt;class I&gt;
20286vector&lt;T&gt;::choose_init(I f, I l, int2type&lt;false&gt;)
20287{
20288    // construct with iterators
20289}
20290
20291template &lt;class T&gt;
20292template &lt;class I&gt;
20293vector&lt;T&gt;::choose_init(I f, I l, int2type&lt;true&gt;)
20294{
20295    size_type sz = static_cast&lt;size_type&gt;(f);
20296    value_type v = static_cast&lt;value_type&gt;(l);
20297    // construct with sz,v
20298}
20299</pre>
20300</blockquote>
20301
20302<p>Label this solution 'B'.</p>
20303
20304<p>Both of these solutions solve the case the standard specifically
20305mentions:</p>
20306<pre>vector&lt;int&gt; v(10, 1);  // ok, vector size 10, initialized to 1
20307</pre>
20308
20309<p>
20310However, (and here is the problem), the two solutions have different
20311behavior in some cases where the value_type of the sequence is not an
20312integral type.  For example consider:
20313</p>
20314<blockquote><pre>     pair&lt;char, char&gt;                     p('a', 'b');
20315     vector&lt;vector&lt;pair&lt;char, char&gt; &gt; &gt;   d('a', 'b');
20316</pre></blockquote>
20317<p>
20318The second line of this snippet is likely an error.  Solution A catches
20319the error and refuses to compile.  The reason is that there is no
20320specialization of the member template constructor that looks like:
20321</p>
20322<pre>template &lt;&gt;
20323template &lt;&gt;
20324vector&lt;vector&lt;pair&lt;char, char&gt; &gt; &gt;::vector(char, char) { ... }
20325</pre>
20326
20327<p>
20328So the expression binds to the unspecialized member template
20329constructor, and then fails (compile time) because char is not an
20330InputIterator.
20331</p>
20332
20333<p>
20334Solution B compiles the above example though.  'a' is casted to an
20335unsigned integral type and used to size the outer vector.  'b' is
20336static casted to the inner vector using it's explicit constructor:
20337</p>
20338
20339<pre>explicit vector(size_type n);
20340</pre>
20341
20342<p>
20343and so you end up with a static_cast&lt;size_type&gt;('a') by
20344static_cast&lt;size_type&gt;('b') matrix.
20345</p>
20346
20347<p>
20348It is certainly possible that this is what the coder intended.  But the
20349explicit qualifier on the inner vector has been thwarted at any rate.
20350</p>
20351
20352<p>
20353The standard is not clear whether the expression:
20354</p>
20355
20356<pre>     vector&lt;vector&lt;pair&lt;char, char&gt; &gt; &gt;   d('a', 'b');
20357</pre>
20358
20359<p>
20360(and similar expressions) are:
20361</p>
20362
20363<ol>
20364<li>  undefined behavior.</li>
20365<li>  illegal and must be rejected.</li>
20366<li>  legal and must be accepted.</li>
20367</ol>
20368
20369<p>My preference is listed in the order presented.</p>
20370
20371<p>There are still other techniques for implementing the requirements of
20372paragraphs 9-11, namely the "restricted template technique" (e.g.
20373enable_if).  This technique is the most compact and easy way of coding
20374the requirements, and has the behavior of #2 (rejects the above
20375expression).
20376</p>
20377
20378<p>
20379Choosing 1 would allow all implementation techniques I'm aware of.
20380Choosing 2 would allow only solution 'A' and the enable_if technique.
20381Choosing 3 would allow only solution 'B'.
20382</p>
20383
20384<p>
20385Possible wording for a future standard if we wanted to actively reject
20386the expression above would be to change "static_cast" in paragraphs
203879-11 to "implicit_cast" where that is defined by:
20388</p>
20389
20390<blockquote>
20391<pre>template &lt;class T, class U&gt;
20392inline
20393T implicit_cast(const U&amp; u)
20394{
20395     return u;
20396}
20397</pre>
20398</blockquote>
20399
20400
20401
20402<p><b>Proposed resolution:</b></p>
20403
20404<p>Replace 23.2.3 [sequence.reqmts] paragraphs 9 - 11 with:</p>
20405
20406<p>For every sequence defined in this clause and in clause lib.strings:</p>
20407
20408<ul>
20409  <li>
20410    <p>If the constructor</p>
20411       <pre>       template &lt;class InputIterator&gt;
20412       X(InputIterator f, InputIterator l,
20413         const allocator_type&amp; a = allocator_type())
20414       </pre>
20415    <p>is called with a type InputIterator that does not qualify as
20416    an input iterator, then the constructor will behave as if the
20417    overloaded constructor:</p>
20418       <pre>       X(size_type, const value_type&amp; = value_type(),
20419         const allocator_type&amp; = allocator_type())
20420       </pre>
20421    <p>were called instead, with the arguments static_cast&lt;size_type&gt;(f), l and a, respectively.</p>
20422  </li>
20423
20424  <li>
20425    <p>If the member functions of the forms:</p>
20426       <pre>       template &lt;class InputIterator&gt;          //  such as  insert()
20427       rt fx1(iterator p, InputIterator f, InputIterator l);
20428
20429       template &lt;class InputIterator&gt;          //  such as  append(), assign()
20430       rt fx2(InputIterator f, InputIterator l);
20431
20432       template &lt;class InputIterator&gt;          //  such as  replace()
20433       rt fx3(iterator i1, iterator i2, InputIterator f, InputIterator l);
20434       </pre>
20435    <p>are called with a type InputIterator that does not qualify as
20436    an input iterator, then these functions will behave as if the
20437    overloaded member functions:</p>
20438       <pre>       rt fx1(iterator, size_type, const value_type&amp;);
20439
20440       rt fx2(size_type, const value_type&amp;);
20441
20442       rt fx3(iterator, iterator, size_type, const value_type&amp;);
20443       </pre>
20444    <p>were called instead, with the same arguments.</p>
20445  </li>
20446</ul>
20447
20448<p>In the previous paragraph the alternative binding will fail if f 
20449is not implicitly convertible to X::size_type or if l is not implicitly 
20450convertible to X::value_type.</p>
20451
20452<p>
20453The extent to which an implementation determines that a type cannot be
20454an input iterator is unspecified, except that as a minimum integral
20455types shall not qualify as input iterators.
20456</p>
20457
20458
20459
20460<p><i>[
20461Kona: agreed that the current standard requires <tt>v('a', 'b')</tt>
20462to be accepted, and also agreed that this is surprising behavior.  The
20463LWG considered several options, including something like
20464implicit_cast, which doesn't appear to be quite what we want.  We
20465considered Howards three options: allow acceptance or rejection,
20466require rejection as a compile time error, and require acceptance.  By
20467straw poll (1-6-1), we chose to require a compile time error.
20468Post-Kona: Howard provided wording.
20469]</i></p>
20470
20471
20472<p><i>[
20473Sydney: The LWG agreed with this general direction, but there was some
20474discomfort with the wording in the original proposed resolution.
20475Howard submitted new wording, and we will review this again in
20476Redmond.
20477]</i></p>
20478
20479
20480<p><i>[Redmond: one very small change in wording: the first argument
20481  is cast to size_t.  This fixes the problem of something like
20482  <tt>vector&lt;vector&lt;int&gt; &gt;(5, 5)</tt>, where int is not 
20483  implicitly convertible to the value type.]</i></p>
20484
20485
20486
20487
20488<p><b>Rationale:</b></p>
20489<p>The proposed resolution fixes:</p>
20490
20491<pre>  vector&lt;int&gt; v(10, 1);
20492</pre>
20493
20494<p>
20495since as integral types 10 and 1 must be disqualified as input
20496iterators and therefore the (size,value) constructor is called (as
20497if).</p>
20498
20499<p>The proposed resolution breaks:</p>
20500
20501<pre>  vector&lt;vector&lt;T&gt; &gt; v(10, 1);
20502</pre>
20503
20504<p>
20505because the integral type 1 is not *implicitly* convertible to
20506vector&lt;T&gt;.  The wording above requires a diagnostic.</p>
20507
20508<p>
20509The proposed resolution leaves the behavior of the following code
20510unspecified.
20511</p>
20512
20513<pre>  struct A
20514  {
20515    operator int () const {return 10;}
20516  };
20517
20518  struct B
20519  {
20520    B(A) {}
20521  };
20522
20523  vector&lt;B&gt; v(A(), A());
20524</pre>
20525
20526<p>
20527The implementation may or may not detect that A is not an input
20528iterator and employee the (size,value) constructor.  Note though that
20529in the above example if the B(A) constructor is qualified explicit,
20530then the implementation must reject the constructor as A is no longer
20531implicitly convertible to B.
20532</p>
20533
20534
20535
20536
20537
20538<hr>
20539<h3><a name="441"></a>441. Is fpos::state const?</h3>
20540<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>
20541 <b>Submitter:</b> Vincent Leloup <b>Opened:</b> 2003-11-17  <b>Last modified:</b> 2008-09-26</p>
20542<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>
20543<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
20544<p><b>Discussion:</b></p>
20545<p>
20546In section 27.5.3.1 [fpos.members] fpos&lt;stateT&gt;::state() is declared
20547non const, but in section 27.5.3 [fpos] it is declared const.
20548</p>
20549
20550
20551<p><b>Proposed resolution:</b></p>
20552<p>
20553In section 27.5.3.1 [fpos.members], change the declaration of 
20554<tt>fpos&lt;stateT&gt;::state()</tt> to const.
20555</p>
20556
20557
20558
20559
20560
20561<hr>
20562<h3><a name="442"></a>442. sentry::operator bool() inconsistent signature</h3>
20563<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>
20564 <b>Submitter:</b> Vincent Leloup <b>Opened:</b> 2003-11-18  <b>Last modified:</b> 2008-09-26</p>
20565<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>
20566<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
20567<p><b>Discussion:</b></p>
20568<p>
20569In section 27.7.2.4 [ostream::sentry] paragraph 4, in description part
20570basic_ostream&lt;charT, traits&gt;::sentry::operator bool() is declared
20571as non const, but in section 27.6.2.3, in synopsis it is declared
20572const.
20573</p>
20574
20575
20576<p><b>Proposed resolution:</b></p>
20577<p>
20578In section 27.7.2.4 [ostream::sentry] paragraph 4, change the declaration
20579of <tt>sentry::operator bool()</tt> to const.
20580</p>
20581
20582
20583
20584
20585
20586<hr>
20587<h3><a name="443"></a>443. filebuf::close() inconsistent use of EOF</h3>
20588<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>
20589 <b>Submitter:</b> Vincent Leloup <b>Opened:</b> 2003-11-20  <b>Last modified:</b> 2008-09-26</p>
20590<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>
20591<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
20592<p><b>Discussion:</b></p>
20593<p>
20594In section 27.9.1.4 [filebuf.members] par6, in effects description of
20595basic_filebuf&lt;charT, traits&gt;::close(), overflow(EOF) is used twice;
20596should be overflow(traits::eof()).
20597</p>
20598
20599
20600<p><b>Proposed resolution:</b></p>
20601<p>
20602Change overflow(EOF) to overflow(traits::eof()).
20603</p>
20604
20605
20606
20607
20608
20609<hr>
20610<h3><a name="444"></a>444. Bad use of casts in fstream</h3>
20611<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>
20612 <b>Submitter:</b> Vincent Leloup <b>Opened:</b> 2003-11-20  <b>Last modified:</b> 2009-05-01</p>
20613<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>
20614<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
20615<p><b>Discussion:</b></p>
20616<p>27.9.1.9 [ifstream.members] p1, 27.9.1.13 [ofstream.members] p1,
2061727.9.1.17 [fstream.members] p1 seems have same problem as exposed in
20618LWG issue
20619<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#252">252</a>.
20620</p>
20621
20622
20623<p><b>Proposed resolution:</b></p>
20624
20625<p><i>[Sydney: Genuine defect. 27.8.1.13 needs a cast to cast away
20626 constness. The other two places are stylistic: we could change the
20627 C-style casts to const_cast. Post-Sydney: Howard provided wording.
20628]</i></p>
20629
20630
20631<p>Change 27.8.1.7/1 from:</p>
20632<blockquote><p>
20633  Returns: (basic_filebuf&lt;charT,traits&gt;*)&amp;sb.
20634</p></blockquote>
20635
20636<p>to:</p>
20637<blockquote><p>
20638  Returns: const_cast&lt;basic_filebuf&lt;charT,traits&gt;*&gt;(&amp;sb).
20639</p></blockquote>
20640
20641<p>Change 27.8.1.10/1 from:</p>
20642<blockquote><p>
20643  Returns: (basic_filebuf&lt;charT,traits&gt;*)&amp;sb.
20644</p></blockquote>
20645
20646<p>to:</p>
20647<blockquote><p>
20648  Returns: const_cast&lt;basic_filebuf&lt;charT,traits&gt;*&gt;(&amp;sb).
20649</p></blockquote>
20650
20651<p>Change 27.8.1.13/1 from:</p>
20652<blockquote><p>
20653  Returns: &amp;sb.
20654</p></blockquote>
20655
20656<p>to:</p>
20657<blockquote><p>
20658  Returns: const_cast&lt;basic_filebuf&lt;charT,traits&gt;*&gt;(&amp;sb).
20659</p></blockquote>
20660
20661
20662
20663
20664
20665
20666
20667
20668<hr>
20669<h3><a name="445"></a>445. iterator_traits::reference unspecified for some iterator categories</h3>
20670<p><b>Section:</b> 24.4.1 [iterator.traits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
20671 <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2003-12-09  <b>Last modified:</b> 2009-05-01</p>
20672<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>
20673<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
20674<p><b>Discussion:</b></p>
20675<p>
20676The standard places no restrictions at all on the reference type
20677of input, output, or forward iterators (for forward iterators it
20678only specifies that *x must be value_type&amp; and doesn't mention
20679the reference type).  Bidirectional iterators' reference type is
20680restricted only by implication, since the base iterator's
20681reference type is used as the return type of reverse_iterator's
20682operator*, which must be T&amp; in order to be a conforming forward
20683iterator.
20684</p>
20685
20686<p>
20687Here's what I think we ought to be able to expect from an input
20688or forward iterator's reference type R, where a is an iterator
20689and V is its value_type
20690</p>
20691
20692<ul>
20693  <li>
20694      *a is convertible to R
20695  </li>
20696
20697  <li>
20698      R is convertible to V
20699  </li>
20700
20701  <li>
20702      static_cast&lt;V&gt;(static_cast&lt;R&gt;(*a)) is equivalent to
20703      static_cast&lt;V&gt;(*a) 
20704  </li>
20705</ul>
20706
20707<p>A mutable forward iterator ought to satisfy, for x of type V:</p>
20708  <pre>      { R r = *a; r = x; } is equivalent to *a = x;
20709  </pre>
20710
20711<p>
20712I think these requirements capture existing container iterators
20713(including vector&lt;bool&gt;'s), but render istream_iterator invalid;
20714its reference type would have to be changed to a constant
20715reference.
20716</p>
20717
20718
20719<p>
20720(Jeremy Siek) During the discussion in Sydney, it was felt that a
20721simpler long term solution for this was needed. The solution proposed
20722was to require <tt>reference</tt> to be the same type as <tt>*a</tt>
20723and <tt>pointer</tt> to be the same type as <tt>a-&gt;</tt>.  Most
20724iterators in the Standard Library already meet this requirement. Some
20725iterators are output iterators, and do not need to meet the
20726requirement, and others are only specified through the general
20727iterator requirements (which will change with this resolution). The
20728sole case where there is an explicit definition of the reference type
20729that will need to change is <tt>istreambuf_iterator</tt> which returns
20730<tt>charT</tt> from <tt>operator*</tt> but has a reference type of
20731<tt>charT&amp;</tt>. We propose changing the reference type of
20732<tt>istreambuf_iterator</tt> to <tt>charT</tt>.
20733</p>
20734
20735<p>The other option for resolving the issue with <tt>pointer</tt>,
20736  mentioned in the note below, is to remove <tt>pointer</tt>
20737  altogether. I prefer placing requirements on <tt>pointer</tt> to
20738  removing it for two reasons. First, <tt>pointer</tt> will become
20739  useful for implementing iterator adaptors and in particular,
20740  <tt>reverse_iterator</tt> will become more well defined. Second,
20741  removing <tt>pointer</tt> is a rather drastic and publicly-visible
20742  action to take.</p>
20743
20744<p>The proposed resolution technically enlarges the requirements for
20745iterators, which means there are existing iterators (such as
20746<tt>istreambuf_iterator</tt>, and potentially some programmer-defined
20747iterators) that will no longer meet the requirements. Will this break
20748existing code? The scenario in which it would is if an algorithm
20749implementation (say in the Standard Library) is changed to rely on
20750<tt>iterator_traits::reference</tt>, and then is used with one of the
20751iterators that do not have an appropriately defined
20752<tt>iterator_traits::reference</tt>.
20753</p>
20754
20755
20756<p>The proposed resolution makes one other subtle change. Previously,
20757it was required that output iterators have a <tt>difference_type</tt>
20758and <tt>value_type</tt> of <tt>void</tt>, which means that a forward
20759iterator could not be an output iterator. This is clearly a mistake,
20760so I've changed the wording to say that those types may be
20761<tt>void</tt>.
20762</p>
20763
20764
20765
20766<p><b>Proposed resolution:</b></p>
20767
20768<p>In 24.4.1 [iterator.traits], after:</p>
20769
20770<blockquote><p>
20771be defined as the iterator's difference type, value type and iterator
20772category, respectively.
20773</p></blockquote>
20774
20775<p>add</p>
20776
20777<blockquote><p>
20778In addition, the types</p>
20779<pre>iterator_traits&lt;Iterator&gt;::reference
20780iterator_traits&lt;Iterator&gt;::pointer
20781</pre>
20782<p>must be defined as the iterator's reference and pointer types, that
20783is, the same type as the type of <tt>*a</tt> and <tt>a-&gt;</tt>,
20784respectively.</p>
20785</blockquote>
20786
20787<p>In 24.4.1 [iterator.traits], change:</p>
20788
20789<blockquote><p>
20790In the case of an output iterator, the types</p>
20791<pre>iterator_traits&lt;Iterator&gt;::difference_type
20792iterator_traits&lt;Iterator&gt;::value_type
20793</pre>
20794<p>are both defined as <tt>void</tt>.</p>
20795</blockquote>
20796
20797<p>to:</p>
20798<blockquote><p>
20799In the case of an output iterator, the types</p>
20800<pre>iterator_traits&lt;Iterator&gt;::difference_type
20801iterator_traits&lt;Iterator&gt;::value_type
20802iterator_traits&lt;Iterator&gt;::reference
20803iterator_traits&lt;Iterator&gt;::pointer
20804</pre>
20805<p>may be defined as <tt>void</tt>.</p>
20806</blockquote>
20807
20808<p>In 24.6.3 [istreambuf.iterator], change:</p>
20809<blockquote>
20810<pre>typename traits::off_type, charT*, charT&amp;&gt;
20811</pre>
20812</blockquote>
20813<p>to:</p>
20814<blockquote>
20815<pre>typename traits::off_type, charT*, charT&gt;
20816</pre>
20817</blockquote>
20818
20819<p><i>[
20820Redmond: there was concern in Sydney that this might not be the only place
20821where things were underspecified and needed to be changed.  Jeremy
20822reviewed iterators in the standard and confirmed that nothing else
20823needed to be changed.
20824]</i></p>
20825
20826
20827
20828
20829
20830
20831
20832
20833
20834<hr>
20835<h3><a name="448"></a>448. Random Access Iterators over abstract classes</h3>
20836<p><b>Section:</b> 24.2.5 [random.access.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
20837 <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2004-01-07  <b>Last modified:</b> 2008-09-26</p>
20838<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>
20839<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
20840<p><b>Discussion:</b></p>
20841<p>
20842Table 76, the random access iterator requirement table, says that the
20843return type of a[n] must be "convertible to T".  When an iterator's
20844value_type T is an abstract class, nothing is convertible to T.
20845Surely this isn't an intended restriction?
20846</p>
20847
20848
20849<p><b>Proposed resolution:</b></p>
20850<p>
20851Change the return type to "convertible to T const&amp;".
20852</p>
20853
20854
20855
20856
20857
20858<hr>
20859<h3><a name="449"></a>449. Library Issue 306 Goes Too Far</h3>
20860<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>
20861 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2004-01-15  <b>Last modified:</b> 2008-09-26</p>
20862<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>
20863<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
20864<p><b>Discussion:</b></p>
20865<p>Original text:</p>
20866<blockquote><p>
20867The macro offsetof accepts a restricted set of type arguments in this
20868International Standard. type shall be a POD structure or a POD union
20869(clause 9). The result of applying the offsetof macro to a field that
20870is a static data member or a function member is undefined."
20871</p></blockquote>
20872
20873<p>Revised text:</p>
20874<blockquote><p>
20875"If type is not a POD structure or a POD union the results are undefined."
20876</p></blockquote>
20877
20878<p>
20879Looks to me like the revised text should have replaced only the second
20880sentence. It doesn't make sense standing alone.
20881</p>
20882
20883
20884
20885<p><b>Proposed resolution:</b></p>
20886<p>Change 18.1, paragraph 5, to:</p>
20887
20888<blockquote><p>
20889The macro offsetof accepts a restricted set of type arguments in this
20890International Standard.  If type is not a POD structure or a POD union
20891the results are undefined.  The result of applying the offsetof macro
20892to a field that is a static data member or a function member is
20893undefined."
20894</p></blockquote>
20895
20896
20897
20898
20899
20900<hr>
20901<h3><a name="453"></a>453. basic_stringbuf::seekoff need not always fail for an empty stream</h3>
20902<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>
20903 <b>Submitter:</b> Bill Plauger <b>Opened:</b> 2004-01-30  <b>Last modified:</b> 2008-09-26</p>
20904<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>
20905<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
20906<p><b>Discussion:</b></p>
20907<pre>  pos_type basic_stringbuf::seekoff(off_type, ios_base::seekdir,
20908                                    ios_base::openmode);
20909</pre>
20910<p>
20911is obliged to fail if nothing has been inserted into the stream. This
20912is unnecessary and undesirable. It should be permissible to seek to
20913an effective offset of zero.</p>
20914
20915<p><i>[
20916 Sydney: Agreed that this is an annoying problem: seeking to zero should be
20917 legal. Bill will provide wording.
20918]</i></p>
20919
20920
20921
20922
20923<p><b>Proposed resolution:</b></p>
20924<p>Change the sentence from:</p>
20925<blockquote><p>
20926For a sequence to be positioned, if its next pointer (either
20927gptr() or pptr()) is a null pointer, the positioning operation
20928fails.
20929</p></blockquote>
20930
20931<p>to:</p>
20932
20933<blockquote><p>
20934For a sequence to be positioned, if its next pointer (either
20935gptr() or pptr()) is a null pointer and the new offset newoff
20936is nonzero, the positioning operation fails.
20937</p></blockquote>
20938
20939
20940
20941
20942
20943<hr>
20944<h3><a name="455"></a>455. cerr::tie() and wcerr::tie() are overspecified</h3>
20945<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>
20946 <b>Submitter:</b> Bill Plauger <b>Opened:</b> 2004-01-30  <b>Last modified:</b> 2009-05-01</p>
20947<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>
20948<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
20949<p><b>Discussion:</b></p>
20950<p>
20951Both cerr::tie() and wcerr::tie() are obliged to be null at program
20952startup. This is overspecification and overkill. It is both traditional
20953and useful to tie cerr to cout, to ensure that standard output is drained
20954whenever an error message is written. This behavior should at least be
20955permitted if not required. Same for wcerr::tie().
20956</p>
20957
20958
20959<p><b>Proposed resolution:</b></p>
20960
20961<p>Add to the description of cerr:</p>
20962<blockquote><p>
20963After the object cerr is initialized, cerr.tie() returns &amp;cout.
20964Its state is otherwise the same as required for basic_ios&lt;char&gt;::init
20965(lib.basic.ios.cons).
20966</p></blockquote>
20967
20968<p>Add to the description of wcerr:</p>
20969
20970<blockquote><p>
20971After the object wcerr is initialized, wcerr.tie() returns &amp;wcout.
20972Its state is otherwise the same as required for basic_ios&lt;wchar_t&gt;::init
20973(lib.basic.ios.cons).
20974</p></blockquote>
20975
20976<p><i>[Sydney: straw poll (3-1): we should <i>require</i>, not just
20977  permit, cout and cerr to be tied on startup.  Pre-Redmond: Bill will
20978  provide wording.]</i></p>
20979
20980
20981
20982
20983
20984
20985<hr>
20986<h3><a name="456"></a>456. Traditional C header files are overspecified</h3>
20987<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>
20988 <b>Submitter:</b> Bill Plauger <b>Opened:</b> 2004-01-30  <b>Last modified:</b> 2008-09-26</p>
20989<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>
20990<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
20991<p><b>Discussion:</b></p>
20992
20993<p>The C++ Standard effectively requires that the traditional C headers
20994(of the form &lt;xxx.h&gt;) be defined in terms of the newer C++
20995headers (of the form &lt;cxxx&gt;). Clauses 17.4.1.2/4 and D.5 combine
20996to require that:</p>
20997
20998<ul>
20999 <li>Including the header &lt;cxxx&gt; declares a C name in namespace std.</li>
21000
21001 <li> Including the header &lt;xxx.h&gt; declares a C name in namespace std
21002    (effectively by including &lt;cxxx&gt;), then imports it into the global
21003    namespace with an individual using declaration.</li>
21004</ul>
21005
21006<p>
21007The rules were left in this form despited repeated and heated objections
21008from several compiler vendors. The C headers are often beyond the direct
21009control of C++ implementors. In some organizations, it's all they can do
21010to get a few #ifdef __cplusplus tests added. Third-party library vendors
21011can perhaps wrap the C headers. But neither of these approaches supports
21012the drastic restructuring required by the C++ Standard. As a result, it is
21013still widespread practice to ignore this conformance requirement, nearly
21014seven years after the committee last debated this topic. Instead, what is
21015often implemented is:
21016</p>
21017
21018<ul>
21019 <li> Including the header &lt;xxx.h&gt; declares a C name in the
21020 global namespace.</li> 
21021
21022 <li> Including the header &lt;cxxx&gt; declares a C name in the
21023 global namespace (effectively by including &lt;xxx.h&gt;), then
21024 imports it into namespace std with an individual using declaration.</li>
21025</ul>
21026
21027<p>
21028The practical benefit for implementors with the second approach is that
21029they can use existing C library headers, as they are pretty much obliged
21030to do. The practical cost for programmers facing a mix of implementations
21031is that they have to assume weaker rules:</p>
21032
21033<ul>
21034  <li> If you want to assuredly declare a C name in the global
21035  namespace, include &lt;xxx.h&gt;. You may or may not also get the
21036  declaration in namespace std.</li>
21037
21038  <li> If you want to assuredly declare a C name in namespace std,
21039  include &lt;cxxx&gt;. You may or may not also get the declaration in
21040  the global namespace.</li>
21041</ul>
21042
21043<p>
21044There also exists the <i>possibility</i> of subtle differences due to
21045Koenig lookup, but there are so few non-builtin types defined in the C
21046headers that I've yet to see an example of any real problems in this
21047area.
21048</p>
21049
21050<p>
21051It is worth observing that the rate at which programmers fall afoul of
21052these differences has remained small, at least as measured by newsgroup
21053postings and our own bug reports. (By an overwhelming margin, the
21054commonest problem is still that programmers include &lt;string&gt; and can't
21055understand why the typename string isn't defined -- this a decade after
21056the committee invented namespace std, nominally for the benefit of all
21057programmers.)
21058</p>
21059
21060<p>
21061We should accept the fact that we made a serious mistake and rectify it,
21062however belatedly, by explicitly allowing either of the two schemes for
21063declaring C names in headers.
21064</p>
21065
21066<p><i>[Sydney: This issue has been debated many times, and will
21067  certainly have to be discussed in full committee before any action
21068  can be taken.  However, the preliminary sentiment of the LWG was in
21069  favor of the change.  (6 yes, 0 no, 2 abstain) Robert Klarer
21070  suggests that we might also want to undeprecate the
21071  C-style <tt>.h</tt> headers.]</i></p>
21072
21073
21074
21075
21076<p><b>Proposed resolution:</b></p>
21077<p>
21078Add to 17.6.1.2 [headers], para. 4:
21079</p>
21080
21081<blockquote><p>
21082Except as noted in clauses 18 through 27 and Annex D, the contents of each
21083header <i>cname</i> shall be the same as that of the corresponding header
21084<i>name.h</i>, as specified in ISO/IEC 9899:1990 Programming Languages C (Clause
210857), or ISO/IEC:1990 Programming Languages-C AMENDMENT 1: C Integrity, (Clause
210867), as appropriate, as if by inclusion. In the C++ Standard Library, however,
21087the declarations <del>and definitions</del> (except for names which are defined
21088as macros in C) are within namespace scope (3.3.5) of the namespace std. 
21089<ins>It is unspecified whether these names are first declared within the global
21090namespace scope and are then injected into namespace std by explicit
21091using-declarations (7.3.3 [namespace.udecl]).</ins>
21092</p></blockquote>
21093
21094<p>
21095Change D.6 [depr.c.headers], para. 2-3:
21096</p>
21097
21098<blockquote>
21099<p>
21100-2- Every C header, each of which has a name of the form <i>name.h</i>, behaves
21101as if each name placed in the Standard library namespace by the corresponding
21102<i>cname</i> header is <del>also</del> placed within the <ins>global</ins>
21103namespace scope<ins>.</ins> <del>of the namespace <tt>std</tt> and is followed
21104by an explicit <i>using-declaration</i> (7.3.3 [namespace.udecl]).</del>
21105<ins>It is unspecified whether these names are first declared or defined within
21106namespace scope (3.3.6 [basic.scope.namespace]) of the namespace
21107<tt>std</tt> and are then injected into the global namespace scope by explicit
21108using-declarations (7.3.3 [namespace.udecl]).</ins>
21109</p>
21110<p>
21111-3- [<i>Example:</i> The header <tt>&lt;cstdlib&gt;</tt> <ins>assuredly</ins>
21112provides its declarations and definitions within the namespace <tt>std</tt>.
21113<ins>It may also provide these names within the global namespace.</ins> The
21114header <tt>&lt;stdlib.h&gt;</tt> <del>makes these available also in</del>
21115<ins>assuredly provides the same declarations and definitions within</ins> the
21116global namespace, much as in the C Standard. <ins>It may also provide these
21117names within the namespace <tt>std</tt>.</ins> <i>-- end example</i>]
21118</p>
21119</blockquote>
21120
21121
21122
21123
21124
21125<hr>
21126<h3><a name="457"></a>457. bitset constructor: incorrect number of initialized bits</h3>
21127<p><b>Section:</b> 20.3.7.1 [bitset.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
21128 <b>Submitter:</b> Dag Henriksson <b>Opened:</b> 2004-01-30  <b>Last modified:</b> 2009-05-01</p>
21129<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>
21130<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
21131<p><b>Discussion:</b></p>
21132<p>
21133The constructor from unsigned long says it initializes "the first M
21134bit positions to the corresponding bit values in val. M is the smaller
21135of N and the value CHAR_BIT * sizeof(unsigned long)."
21136</p>
21137
21138<p>
21139Object-representation vs. value-representation strikes again. CHAR_BIT *
21140sizeof (unsigned long) does not give us the number of bits an unsigned long
21141uses to hold the value. Thus, the first M bit position above is not
21142guaranteed to have any corresponding bit values in val.
21143</p>
21144
21145
21146<p><b>Proposed resolution:</b></p>
21147<p>In 20.3.7.1 [bitset.cons] paragraph 2, change "M is the smaller of
21148  N and the value CHAR_BIT * sizeof (unsigned long). (249)" to
21149  "<tt>M</tt> is the smaller of <tt>N</tt> and the number of bits in
21150  the value representation (section 3.9 [basic.types]) of <tt>unsigned
21151  long</tt>."
21152</p>
21153
21154
21155
21156
21157
21158<hr>
21159<h3><a name="460"></a>460. Default modes missing from basic_fstream member specifications</h3>
21160<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>
21161 <b>Submitter:</b> Ben Hutchings <b>Opened:</b> 2004-04-01  <b>Last modified:</b> 2009-05-01</p>
21162<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>
21163<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
21164<p><b>Discussion:</b></p>
21165<p>
21166The second parameters of the non-default constructor and of the open
21167member function for basic_fstream, named "mode", are optional
21168according to the class declaration in 27.8.1.11 [lib.fstream].  The
21169specifications of these members in 27.8.1.12 [lib.fstream.cons] and
2117027.8.1.13 lib.fstream.members] disagree with this, though the
21171constructor declaration has the "explicit" function-specifier implying
21172that it is intended to be callable with one argument.
21173</p>
21174
21175
21176<p><b>Proposed resolution:</b></p>
21177<p>In 27.9.1.15 [fstream.cons], change</p>
21178<pre>  explicit basic_fstream(const char* s, ios_base::openmode mode); 
21179</pre>
21180<p>to</p>
21181<pre>  explicit basic_fstream(const char* s,
21182                         ios_base::openmode mode = ios_base::in|ios_base::out);
21183</pre>
21184<p>In 27.9.1.17 [fstream.members], change</p>
21185<pre>  void open(const char*s, ios_base::openmode mode); 
21186</pre>
21187<p>to</p>
21188<pre>  void open(const char*s,
21189            ios_base::openmode mode = ios_base::in|ios_base::out);
21190</pre>
21191
21192
21193
21194
21195
21196<hr>
21197<h3><a name="461"></a>461. time_get hard or impossible to implement</h3>
21198<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>
21199 <b>Submitter:</b> Bill Plauger <b>Opened:</b> 2004-03-23  <b>Last modified:</b> 2008-09-26</p>
21200<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
21201<p><b>Discussion:</b></p>
21202<p>
21203Template time_get currently contains difficult, if not impossible,
21204requirements for do_date_order, do_get_time, and do_get_date. All require
21205the implementation to scan a field generated by the %x or %X conversion
21206specifier in strftime. Yes, do_date_order can always return no_order, but
21207that doesn't help the other functions. The problem is that %x can be
21208nearly anything, and it can vary widely with locales. It's horribly
21209onerous to have to parse "third sunday after Michaelmas in the year of
21210our Lord two thousand and three," but that's what we currently ask of
21211do_get_date. More practically, it leads some people to think that if
21212%x produces 10.2.04, we should know to look for dots as separators. Still
21213not easy.
21214</p>
21215
21216<p>
21217Note that this is the <i>opposite</i> effect from the intent stated in the
21218footnote earlier in this subclause:
21219</p>
21220
21221<blockquote><p>
21222"In other words, user confirmation is required for reliable parsing of
21223user-entered dates and times, but machine-generated formats can be
21224parsed reliably. This allows parsers to be aggressive about interpreting
21225user variations on standard formats."
21226</p></blockquote>
21227
21228<p>
21229We should give both implementers and users an easier and more reliable
21230alternative: provide a (short) list of alternative delimiters and say
21231what the default date order is for no_order. For backward compatibility,
21232and maximum latitude, we can permit an implementation to parse whatever
21233%x or %X generates, but we shouldn't require it.
21234</p>
21235
21236
21237<p><b>Proposed resolution:</b></p>
21238
21239<p><b>In the description:</b></p>
21240<pre>iter_type do_get_time(iter_type s, iter_type end, ios_base&amp; str,
21241        ios_base::iostate&amp; err, tm* t) const;
21242</pre>
21243
21244<p>
212452 Effects: Reads characters starting at suntil it has extracted those
21246struct tm members, and remaining format characters, used by
21247time_put&lt;&gt;::put to produce the format specified by 'X', or until it
21248encounters an error or end of sequence.
21249</p>
21250
21251<p><b>change:</b> 'X'</p>
21252
21253<p><b>to:</b> "%H:%M:%S"</p>
21254
21255
21256<p>Change</p>
21257<pre>iter_type do_get_date(iter_type s, iter_type end, ios_base&amp; str,
21258        ios_base::iostate&amp; err, tm* t) const;
21259
212604 Effects: Reads characters starting at s until it has extracted those
21261struct tm members, and remaining format characters, used by
21262time_put&lt;&gt;::put to produce the format specified by 'x', or until it
21263encounters an error.
21264</pre>
21265
21266<p>to</p>
21267<pre>iter_type do_get_date(iter_type s, iter_type end, ios_base&amp; str,
21268        ios_base::iostate&amp; err, tm* t) const;
21269</pre>
21270
21271<p>
212724 Effects: Reads characters starting at s until it has extracted those
21273struct tm members, and remaining format characters, used by
21274time_put&lt;&gt;::put to produce one of the following formats, or until it
21275encounters an error. The format depends on the value returned by
21276date_order() as follows:
21277</p>
21278
21279<pre>        date_order()  format
21280
21281        no_order      "%m/%d/%y"
21282        dmy           "%d/%m/%y"
21283        mdy           "%m/%d/%y"
21284        ymd           "%y/%m/%d"
21285        ydm           "%y/%d/%m"
21286</pre>
21287<p>
21288An implementation may also accept additional implementation-defined formats.
21289</p>
21290
21291<p><i>[Redmond: agreed that this is a real problem.  The solution is
21292  probably to match C99's parsing rules.  Bill provided wording.
21293]</i></p>
21294
21295
21296
21297
21298
21299
21300
21301<hr>
21302<h3><a name="464"></a>464. Suggestion for new member functions in standard containers</h3>
21303<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>
21304 <b>Submitter:</b> Thorsten Ottosen <b>Opened:</b> 2004-05-12  <b>Last modified:</b> 2008-09-26</p>
21305<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>
21306<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
21307<p><b>Discussion:</b></p>
21308
21309<p>To add slightly more convenience to vector&lt;T&gt; and map&lt;Key,T&gt; we should consider to add</p>
21310<ol>
21311<li> add vector&lt;T&gt;::data() member (const and non-const version)
21312semantics: if( empty() ) return 0; else return buffer_;</li>
21313<li> add map&lt;Key,T&gt;::at( const Key&amp; k ) member (const and non-const version)
21314<i>semantics</i>: iterator i = find( k ); if( i != end() ) return *i; else throw range_error();</li>
21315</ol>
21316
21317<p>Rationale:</p>
21318
21319<ul>
21320<li>To obtain a pointer to the vector's buffer, one must use either
21321operator[]() (which can give undefined behavior for empty vectors) or
21322at() (which will then throw if the vector is empty). </li>
21323<li>tr1::array&lt;T,sz&gt; already has a data() member</li>
21324<li>e cannot use operator[]() when T is not DefaultDonstructible</li>
21325<li>Neither when the map is const.</li>
21326<li>when we want to make sure we don't add an element accidently</li>
21327<li>when it should be considered an error if a key is not in the map</li>
21328</ul>
21329
21330
21331
21332<p><b>Proposed resolution:</b></p>
21333<p>In 23.3.6 [vector], add the following to the <tt>vector</tt>
21334  synopsis after "element access" and before "modifiers":</p>
21335<pre>  // <i>[lib.vector.data] data access</i>
21336  pointer       data();
21337  const_pointer data() const;
21338</pre>
21339
21340<p>Add a new subsection of 23.3.6 [vector]:</p>
21341<blockquote>
21342<p>23.2.4.x <tt>vector</tt> data access</p>
21343<pre>   pointer       data();
21344   const_pointer data() const;
21345</pre>
21346<p><b>Returns:</b> A pointer such that [data(), data() + size()) is a valid
21347   range.  For a non-empty vector, data() == &amp;front().</p>
21348<p><b>Complexity:</b> Constant time.</p>
21349<p><b>Throws:</b> Nothing.</p>
21350</blockquote>
21351
21352<p>In 23.4.1 [map], add the following to the <tt>map</tt>
21353synopsis immediately after the line for operator[]:</p>
21354<pre>  T&amp;       at(const key_type&amp; x);
21355  const T&amp; at(const key_type&amp; x) const;
21356</pre>
21357
21358<p>Add the following to 23.4.1.2 [map.access]:</p>
21359<blockquote>
21360<pre>  T&amp;       at(const key_type&amp; x);
21361  const T&amp; at(const key_type&amp; x) const;
21362</pre>
21363
21364<p><b>Returns:</b> A reference to the element whose key is equivalent
21365  to x, if such an element is present in the map.</p>
21366<p><b>Throws:</b> <tt>out_of_range</tt> if no such element is present.</p>
21367
21368</blockquote>
21369
21370
21371
21372<p><b>Rationale:</b></p>
21373<p>Neither of these additions provides any new functionality but the
21374  LWG agreed that they are convenient, especially for novices.  The
21375  exception type chosen for <tt>at</tt>, <tt>std::out_of_range</tt>,
21376  was chosen to match <tt>vector::at</tt>.</p>
21377
21378
21379
21380
21381
21382<hr>
21383<h3><a name="465"></a>465. Contents of &lt;ciso646&gt;</h3>
21384<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>
21385 <b>Submitter:</b> Steve Clamage <b>Opened:</b> 2004-06-03  <b>Last modified:</b> 2008-09-26</p>
21386<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>
21387<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
21388<p><b>Discussion:</b></p>
21389<p>C header &lt;iso646.h&gt; defines macros for some operators, such as
21390not_eq for !=.</p>
21391
21392<p>Section 17.6.1.2 [headers] "Headers" says that except as noted in
21393clauses 18 through 27, the &lt;cname&gt; C++ header contents are the same
21394as the C header &lt;name.h&gt;. In particular, table 12 lists
21395&lt;ciso646&gt; as a C++ header.</p>
21396
21397<p>I don't find any other mention of &lt;ciso646&gt;, or any mention of
21398&lt;iso646.h&gt;, in clauses 17 thorough 27. That implies that the
21399contents of &lt;ciso646&gt; are the same as C header &lt;iso646.h&gt;.</p>
21400
21401<p>Annex C (informative, not normative) in [diff.header.iso646.h] C.2.2.2
21402"Header &lt;iso646.h&gt;" says that the alternative tokens are not
21403defined as macros in &lt;ciso646&gt;, but does not mention the contents
21404of &lt;iso646.h&gt;.</p>
21405
21406<p>I don't find any normative text to support C.2.2.2.</p>
21407
21408
21409
21410<p><b>Proposed resolution:</b></p>
21411<p>Add to section 17.4.1.2 Headers [lib.headers] a new paragraph after
21412  paragraph 6 (the one about functions must be functions):</p> 
21413
21414<blockquote>
21415<p>Identifiers that are keywords or operators in C++ shall not be defined
21416as macros in C++ standard library headers. 
21417[Footnote:In particular, including the standard header &lt;iso646.h&gt;
21418or &lt;ciso646&gt; has no effect. </p>
21419</blockquote>
21420
21421<p><i>[post-Redmond: Steve provided wording.]</i></p>
21422
21423
21424
21425
21426
21427
21428
21429<hr>
21430<h3><a name="467"></a>467. char_traits::lt(), compare(), and memcmp()</h3>
21431<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>
21432 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2004-06-28  <b>Last modified:</b> 2008-09-26</p>
21433<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
21434<p><b>Discussion:</b></p>
21435
21436<p>
21437Table 37 describes the requirements on Traits::compare() in terms of
21438those on Traits::lt(). 21.1.3.1, p6 requires char_traits&lt;char&gt;::lt()
21439to yield the same result as operator&lt;(char, char).
21440</p>
21441
21442<p>
21443Most, if not all, implementations of char_traits&lt;char&gt;::compare()
21444call memcmp() for efficiency. However, the C standard requires both
21445memcmp() and strcmp() to interpret characters under comparison as
21446unsigned, regardless of the signedness of char. As a result, all
21447these char_traits implementations fail to meet the requirement
21448imposed by Table 37 on compare() when char is signed.
21449</p>
21450
21451
21452<p>Read email thread starting with c++std-lib-13499 for more. </p>
21453
21454
21455<p><b>Proposed resolution:</b></p>
21456
21457
21458<p>Change 21.1.3.1, p6 from</p>
21459<blockquote><p>
21460    The two-argument members assign, eq, and lt are defined identically
21461    to the built-in operators =, ==, and &lt; respectively.
21462</p></blockquote>
21463<p>to</p>
21464<blockquote><p>
21465  The two-argument member assign is defined identically to
21466  the built-in operator =. The two
21467  argument members eq and lt are defined identically to
21468  the built-in operators == and &lt; for type unsigned char.
21469</p></blockquote>
21470
21471<p><i>[Redmond: The LWG agreed with this general direction, but we
21472  also need to change <tt>eq</tt> to be consistent with this change.
21473  Post-Redmond: Martin provided wording.]</i></p>
21474
21475
21476
21477
21478
21479
21480<hr>
21481<h3><a name="468"></a>468. unexpected consequences of ios_base::operator void*()</h3>
21482<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>
21483 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2004-06-28  <b>Last modified:</b> 2008-09-26</p>
21484<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>
21485<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
21486<p><b>Discussion:</b></p>
21487
21488<p>The program below is required to compile but when run it typically
21489produces unexpected results due to the user-defined conversion from
21490std::cout or any object derived from basic_ios to void*.
21491</p>
21492
21493<pre>    #include &lt;cassert&gt;
21494    #include &lt;iostream&gt;
21495
21496    int main ()
21497    {
21498        assert (std::cin.tie () == std::cout);
21499        // calls std::cout.ios::operator void*()
21500    }
21501</pre>
21502
21503
21504<p><b>Proposed resolution:</b></p>
21505
21506<p>
21507Replace std::basic_ios&lt;charT, traits&gt;::operator void*() with another
21508conversion operator to some unspecified type that is guaranteed not
21509to be convertible to any other type except for bool (a pointer-to-member
21510might be one such suitable type). In addition, make it clear that the
21511pointer type need not be a pointer to a complete type and when non-null,
21512the value need not be valid.
21513</p>
21514
21515<p>Specifically, change in [lib.ios] the signature of</p>
21516<pre>    operator void*() const;
21517</pre>
21518<p>to</p>
21519<pre>    operator unspecified-bool-type() const;
21520</pre>
21521<p>and change [lib.iostate.flags], p1 from</p>
21522<pre>    operator void*() const;
21523</pre>
21524<p>to</p>
21525<pre>operator unspecified-bool-type() const;
21526
21527     -1- Returns: if fail() then a value that will evaluate false in a
21528      boolean context; otherwise a value that will evaluate true in a
21529      boolean context. The value type returned shall not be
21530      convertible to int.
21531
21532     -2- [Note: This conversion can be used in contexts where a bool
21533      is expected (e.g., an if condition); however, implicit
21534      conversions (e.g., to int) that can occur with bool are not
21535      allowed, eliminating some sources of user error. One possible
21536      implementation choice for this type is pointer-to-member.  - end
21537      note]
21538</pre>
21539
21540<p><i>[Redmond: 5-4 straw poll in favor of doing this.]</i></p>
21541
21542<p><i>[Lillehammer: Doug provided revised wording for
21543  "unspecified-bool-type".]</i></p>
21544 
21545
21546
21547
21548
21549
21550
21551
21552<hr>
21553<h3><a name="469"></a>469. vector&lt;bool&gt; ill-formed relational operators</h3>
21554<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>
21555 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2004-06-28  <b>Last modified:</b> 2009-05-01</p>
21556<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>
21557<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
21558<p><b>Discussion:</b></p>
21559
21560<p>
21561The overloads of relational operators for vector&lt;bool&gt; specified
21562in [lib.vector.bool] are redundant (they are semantically identical
21563to those provided for the vector primary template) and may even be
21564diagnosed as ill-formed (refer to Daveed Vandevoorde's explanation
21565in c++std-lib-13647).
21566</p>
21567
21568
21569
21570<p><b>Proposed resolution:</b></p>
21571<p>
21572Remove all overloads of overloads of relational operators for
21573vector&lt;bool&gt; from [lib.vector.bool].
21574</p>
21575
21576
21577
21578
21579<hr>
21580<h3><a name="474"></a>474. confusing Footnote 297</h3>
21581<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>
21582 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2004-07-01  <b>Last modified:</b> 2008-09-26</p>
21583<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>
21584<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
21585<p><b>Discussion:</b></p>
21586
21587<p>
21588I think Footnote 297 is confused. The paragraph it applies to seems
21589quite clear in that widen() is only called if the object is not a char
21590stream (i.e., not basic_ostream&lt;char&gt;), so it's irrelevant what the
21591value of widen(c) is otherwise.
21592</p>
21593
21594
21595<p><b>Proposed resolution:</b></p>
21596<p>
21597I propose to strike the Footnote.
21598</p>
21599
21600
21601
21602
21603<hr>
21604<h3><a name="475"></a>475. May the function object passed to for_each modify the elements of the iterated sequence?</h3>
21605<p><b>Section:</b> 25.2.4 [alg.foreach] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
21606 <b>Submitter:</b> Stephan T. Lavavej, Jaakko Jarvi <b>Opened:</b> 2004-07-09  <b>Last modified:</b> 2008-09-26</p>
21607<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>
21608<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
21609<p><b>Discussion:</b></p>
21610<p>
21611It is not clear whether the function object passed to for_each is allowed to
21612modify the elements of the sequence being iterated over.
21613</p>
21614
21615<p>
21616for_each is classified without explanation in [lib.alg.nonmodifying], "25.1
21617Non-modifying sequence operations". 'Non-modifying sequence operation' is
21618never defined.
21619</p>
21620
21621<p>
2162225(5) says: "If an algorithm's Effects section says that a value pointed to
21623by any iterator passed as an argument is modified, then that algorithm has
21624an additional type requirement: The type of that argument shall satisfy the
21625requirements of a mutable iterator (24.1)."
21626</p>
21627
21628<p>for_each's Effects section does not mention whether arguments can be
21629modified:</p>
21630
21631<blockquote><p>
21632  "Effects: Applies f to the result of dereferencing every iterator in the
21633   range [first, last), starting from first and proceeding to last - 1."
21634</p></blockquote>
21635
21636<p>
21637Every other algorithm in [lib.alg.nonmodifying] is "really" non-modifying in
21638the sense that neither the algorithms themselves nor the function objects
21639passed to the algorithms may modify the sequences or elements in any way.
21640This DR affects only for_each.
21641</p>
21642
21643<p>
21644We suspect that for_each's classification in "non-modifying sequence
21645operations" means that the algorithm itself does not inherently modify the
21646sequence or the elements in the sequence, but that the function object
21647passed to it may modify the elements it operates on. 
21648</p>
21649
21650<p>
21651The original STL document by Stepanov and Lee explicitly prohibited the
21652function object from modifying its argument.
21653The "obvious" implementation of for_each found in several standard library 
21654implementations, however, does not impose this restriction.
21655As a result, we suspect that the use of for_each with function objects that modify
21656their arguments is wide-spread. 
21657If the restriction was reinstated, all such code would become non-conforming.
21658Further, none of the other algorithms in the Standard
21659could serve the purpose of for_each (transform does not guarantee the order in
21660which its function object is called). 
21661</p>
21662
21663<p>
21664We suggest that the standard be clarified to explicitly allow the function object 
21665passed to for_each modify its argument.</p>
21666
21667
21668
21669<p><b>Proposed resolution:</b></p>
21670<p>Add a nonnormative note to the Effects in 25.2.4 [alg.foreach]: If
21671the type of 'first' satisfies the requirements of a mutable iterator,
21672'f' may apply nonconstant functions through the dereferenced iterators
21673passed to it.
21674</p>
21675
21676
21677
21678<p><b>Rationale:</b></p>
21679<p>The LWG believes that nothing in the standard prohibits function
21680  objects that modify the sequence elements. The problem is that
21681  for_each is in a secion entitled "nonmutating algorithms", and the
21682  title may be confusing.  A nonnormative note should clarify that.</p>
21683
21684
21685
21686
21687
21688<hr>
21689<h3><a name="478"></a>478. Should forward iterator requirements table have a line for r-&gt;m?</h3>
21690<p><b>Section:</b> 24.2.3 [forward.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
21691 <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2004-07-11  <b>Last modified:</b> 2008-09-26</p>
21692<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>
21693<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
21694<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#477">477</a></p>
21695<p><b>Discussion:</b></p>
21696<p>
21697The Forward Iterator requirements table contains the following:
21698</p>
21699<pre> expression  return type         operational  precondition
21700                                  semantics
21701  ==========  ==================  ===========  ==========================
21702  a-&gt;m        U&amp; if X is mutable, (*a).m       pre: (*a).m is well-defined.
21703              otherwise const U&amp;
21704
21705  r-&gt;m        U&amp;                  (*r).m       pre: (*r).m is well-defined.
21706</pre>
21707
21708<p>The second line may be unnecessary.  Paragraph 11 of
21709  [lib.iterator.requirements] says:
21710</p>
21711
21712<blockquote><p>
21713   In the following sections, a and b denote values of type const X, n
21714   denotes a value of the difference type Distance, u, tmp, and m
21715   denote identifiers, r denotes a value of X&amp;, t denotes a value of
21716   value type T, o denotes a value of some type that is writable to
21717   the output iterator.
21718</p></blockquote>
21719
21720<p>
21721Because operators can be overloaded on an iterator's const-ness, the
21722current requirements allow iterators to make many of the operations
21723specified using the identifiers a and b invalid for non-const
21724iterators.</p>
21725
21726<p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#477">477</a></p>
21727
21728
21729<p><b>Proposed resolution:</b></p>
21730
21731<p>Remove the "r-&gt;m" line from the Forward Iterator requirements
21732table. Change</p>
21733<blockquote><p>
21734    "const X"
21735</p></blockquote>
21736
21737<p> to </p>
21738
21739<blockquote><p>
21740    "X or const X" 
21741</p></blockquote>
21742
21743<p>in paragraph 11 of [lib.iterator.requirements].</p>
21744
21745
21746
21747
21748<p><b>Rationale:</b></p>
21749<p>
21750This is a defect because it constrains an lvalue to returning a modifiable lvalue.
21751</p>
21752
21753
21754
21755
21756
21757<hr>
21758<h3><a name="488"></a>488. rotate throws away useful information</h3>
21759<p><b>Section:</b> 25.3.11 [alg.rotate] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
21760 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2004-11-22  <b>Last modified:</b> 2008-09-26</p>
21761<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
21762<p><b>Discussion:</b></p>
21763<p>
21764rotate takes 3 iterators:  first, middle and last which point into a
21765sequence, and rearranges the sequence such that the subrange [middle,
21766last) is now at the beginning of the sequence and the subrange [first,
21767middle) follows.  The return type is void. 
21768</p>
21769
21770<p>
21771In many use cases of rotate, the client needs to know where the
21772subrange [first, middle) starts after the rotate is performed.  This
21773might look like: 
21774</p>
21775<pre>  rotate(first, middle, last);
21776  Iterator i = advance(first, distance(middle, last));
21777</pre>
21778
21779<p>
21780Unless the iterators are random access, the computation to find the
21781start of the subrange [first, middle) has linear complexity.  However,
21782it is not difficult for rotate to return this information with
21783negligible additional computation expense.  So the client could code: 
21784</p>
21785<pre>  Iterator i = rotate(first, middle, last);
21786</pre>
21787
21788<p>
21789and the resulting program becomes significantly more efficient.
21790</p>
21791
21792<p>
21793While the backwards compatibility hit with this change is not zero, it
21794is very small (similar to that of lwg <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#130">130</a>), and there is
21795a significant benefit to the change. 
21796</p>
21797
21798
21799
21800<p><b>Proposed resolution:</b></p>
21801<p>In 25 [algorithms] p2, change:</p>
21802
21803<blockquote><pre>  template&lt;class ForwardIterator&gt;
21804    <del>void</del> <ins>ForwardIterator</ins> rotate(ForwardIterator first, ForwardIterator middle,
21805                ForwardIterator last);
21806</pre></blockquote>
21807
21808<p>In 25.3.11 [alg.rotate], change:</p>
21809
21810<blockquote><pre>  template&lt;class ForwardIterator&gt;
21811    <del>void</del> <ins>ForwardIterator</ins> rotate(ForwardIterator first, ForwardIterator middle,
21812                ForwardIterator last);
21813</pre></blockquote>
21814
21815<p>In 25.3.11 [alg.rotate] insert a new paragraph after p1:</p>
21816
21817<blockquote>
21818<p><b>Returns</b>: <tt>first + (last - middle)</tt>.</p>
21819</blockquote>
21820
21821<p><i>[
21822The LWG agrees with this idea, but has one quibble: we want to make
21823sure not to give the impression that the function "advance" is
21824actually called, just that the nth iterator is returned.  (Calling
21825advance is observable behavior, since users can specialize it for
21826their own iterators.)  Howard will provide wording.
21827]</i></p>
21828
21829
21830<p><i>[Howard provided wording for mid-meeting-mailing Jun. 2005.]</i></p>
21831
21832
21833<p><i>[
21834Toronto: moved to Ready.
21835]</i></p>
21836
21837
21838
21839
21840
21841
21842
21843<hr>
21844<h3><a name="495"></a>495. Clause 22 template parameter requirements</h3>
21845<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>
21846 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2005-01-10  <b>Last modified:</b> 2008-09-26</p>
21847<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>
21848<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
21849<p><b>Discussion:</b></p>
21850<p>It appears that there are no requirements specified for many of the
21851template parameters in clause 22. It looks like this issue has never
21852come up, except perhaps for Facet.</p>
21853
21854<p>Clause 22 isn't even listed in 17.3.2.1 [lib.type.descriptions],
21855either, which is the wording that allows requirements on template
21856parameters to be identified by name.</p>
21857
21858<p>So one issue is that 17.3.2.1 [lib.type.descriptions] Should be
21859changed to cover clause 22. A better change, which will cover us in
21860the future, would be to say that it applies to all the library
21861clauses. Then if a template gets added to any library clause we are
21862covered.</p>
21863
21864<p>charT, InputIterator, and other names with requirements defined
21865elsewhere are fine, assuming the 17.3.2.1 [lib.type.descriptions] fix.
21866But there are a few template arguments names which I don't think have
21867requirements given elsewhere:</p>
21868
21869<ul>
21870<li>internT and externT.  The fix is to add wording saying that internT
21871and externT must meet the same requirements as template arguments
21872named charT.</li>
21873
21874<li>stateT.  I'm not sure about this one. There already is some wording,
21875but it seems a bit vague.</li>
21876
21877<li>Intl.  [lib.locale.moneypunct.byname] The fix for this one is to
21878rename "Intl" to "International". The name is important because other
21879text identifies the requirements for the name International but not
21880for Intl.</li>
21881</ul>
21882
21883<p><b>Proposed resolution:</b></p>
21884<p>Change 17.5.2.1 [type.descriptions], paragraph 1, from:</p>
21885<blockquote><p>
21886The Requirements subclauses may describe names that are used to
21887specify constraints on template arguments.153) These names are used in
21888clauses 20, 23, 25, and 26 to describe the types that may be supplied
21889as arguments by a C++ program when instantiating template components
21890from the library. 
21891</p></blockquote>
21892<p>to:</p>
21893<blockquote><p>
21894The Requirements subclauses may describe names that are used to
21895specify constraints on template arguments.153) These names are used in
21896library clauses to describe the types that may be supplied as
21897arguments by a C++ program when instantiating template components from
21898the library.
21899</p></blockquote>
21900
21901<p>In the front matter of class 22, locales, add:</p>
21902<blockquote><p>
21903Template parameter types internT and externT shall meet the
21904requirements of charT (described in 21 [strings]).
21905</p></blockquote>
21906
21907
21908<p><b>Rationale:</b></p>
21909<p>
21910 Again, a blanket clause isn't blanket enough. Also, we've got a
21911 couple of names that we don't have blanket requirement statements
21912 for. The only issue is what to do about stateT. This wording is
21913 thin, but probably adequate.</p>
21914
21915
21916
21917
21918
21919<hr>
21920<h3><a name="496"></a>496. Illegal use of "T" in vector&lt;bool&gt;</h3>
21921<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>
21922 <b>Submitter:</b> richard@ex-parrot.com <b>Opened:</b> 2005-02-10  <b>Last modified:</b> 2008-09-26</p>
21923<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>
21924<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
21925<p><b>Discussion:</b></p>
21926<p>
21927In the synopsis of the std::vector&lt;bool&gt; specialisation in 23.3.6 [vector],
21928the non-template assign() function has the signature</p>
21929
21930<pre>  void assign( size_type n, const T&amp; t );
21931</pre>
21932
21933<p>The type, T, is not defined in this context.</p>
21934
21935
21936<p><b>Proposed resolution:</b></p>
21937<p>Replace "T" with "value_type".</p>
21938
21939
21940
21941
21942
21943<hr>
21944<h3><a name="497"></a>497. meaning of numeric_limits::traps for floating point types</h3>
21945<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>
21946 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2005-03-02  <b>Last modified:</b> 2008-09-26</p>
21947<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>
21948<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
21949<p><b>Discussion:</b></p>
21950
21951<p>18.2.1.2, p59 says this much about the traps member of numeric_limits:</p>
21952
21953<blockquote>
21954<p>static const bool traps;<br>
21955-59- true if trapping is implemented for the type.204)
21956<br>
21957Footnote 204: Required by LIA-1.
21958</p>
21959</blockquote>
21960
21961<p>It's not clear what is meant by "is implemented" here.</p>
21962
21963<p>
21964In the context of floating point numbers it seems reasonable to expect
21965to be able to use traps to determine whether a program can "safely" use
21966infinity(), quiet_NaN(), etc., in arithmetic expressions, that is
21967without causing a trap (i.e., on UNIX without having to worry about
21968getting a signal). When traps is true, I would expect any of the
21969operations in section 7 of IEEE 754 to cause a trap (and my program
21970to get a SIGFPE). So, for example, on Alpha, I would expect traps
21971to be true by default (unless I compiled my program with the -ieee
21972option), false by default on most other popular architectures,
21973including IA64, MIPS, PA-RISC, PPC, SPARC, and x86 which require
21974traps to be explicitly enabled by the program.
21975</p>
21976
21977<p>
21978Another possible interpretation of p59 is that traps should be true
21979on any implementation that supports traps regardless of whether they
21980are enabled by default or not. I don't think such an interpretation
21981makes the traps member very useful, even though that is how traps is
21982implemented on several platforms. It is also the only way to implement
21983traps on platforms that allow programs to enable and disable trapping
21984at runtime.
21985</p>
21986
21987
21988<p><b>Proposed resolution:</b></p>
21989<p>Change p59 to read:</p>
21990<blockquote><p>True if, at program startup, there exists a value of the type that
21991  would cause an arithmetic operation using that value to trap.</p></blockquote>
21992
21993
21994<p><b>Rationale:</b></p>
21995<p>
21996 Real issue, since trapping can be turned on and off. Unclear what a
21997 static query can say about a dynamic issue. The real advice we should
21998 give users is to use cfenv for these sorts of queries. But this new
21999 proposed resolution is at least consistent and slightly better than
22000 nothing.</p>
22001
22002
22003
22004
22005
22006<hr>
22007<h3><a name="498"></a>498. Requirements for partition() and stable_partition() too strong</h3>
22008<p><b>Section:</b> 25.3.13 [alg.partitions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
22009 <b>Submitter:</b> Sean Parent, Joe Gottman <b>Opened:</b> 2005-05-04  <b>Last modified:</b> 2009-10-26</p>
22010<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
22011<p><b>Discussion:</b></p>
22012<p>
22013Problem:
22014The iterator requirements for partition() and stable_partition() [25.2.12]
22015are listed as BidirectionalIterator, however, there are efficient algorithms
22016for these functions that only require ForwardIterator that have been known
22017since before the standard existed. The SGI implementation includes these (see
22018<a href="http://www.sgi.com/tech/stl/partition.html">http://www.sgi.com/tech/stl/partition.html</a>
22019and
22020<a href="http://www.sgi.com/tech/stl/stable_partition.html">http://www.sgi.com/tech/stl/stable_partition.html</a>).
22021</p>
22022
22023<p><i>[
220242009-04-30 Alisdair adds:
22025]</i></p>
22026
22027
22028<blockquote>
22029<p>
22030Now we have concepts this is easier to express!
22031</p>
22032<p>
22033Proposed resolution:
22034</p>
22035<p>
22036Add the following signature to:
22037</p>
22038<p>
22039Header <tt>&lt;algorithm&gt;</tt> synopsis  [algorithms.syn]<br>
22040p3 Partitions 25.3.13 [alg.partitions]
22041</p>
22042<blockquote><pre> template&lt;ForwardIterator Iter, Predicate&lt;auto, Iter::value_type&gt; Pred&gt;
22043   requires ShuffleIterator&lt;Iter&gt;
22044         &amp;&amp; CopyConstructible&lt;Pred&gt;
22045   Iter partition(Iter first, Iter last, Pred pred);
22046</pre></blockquote>
22047
22048<p>
22049Update p3 Partitions 25.3.13 [alg.partitions]:
22050</p>
22051
22052<blockquote>
22053<p>
22054<i>Complexity:</i> <del>At most <tt>(last - first)/2</tt> swaps. Exactly <tt>last - first</tt>
22055applications of the predicate
22056are done.</del>
22057<ins>
22058If <tt>Iter</tt> satisfies <tt>BidirectionalIterator</tt>, at most <tt>(last -
22059first)/2</tt> swaps. Exactly <tt>last - first</tt> applications of the predicate
22060are done.
22061</ins>
22062</p>
22063<p><ins>
22064If <tt>Iter</tt> merely satisfied <tt>ForwardIterator</tt> at most <tt>(last - first)</tt> swaps
22065are done. Exactly <tt>(last - first)</tt> applications of the predicate are done.
22066</ins></p>
22067</blockquote>
22068
22069<p>
22070[Editorial note: I looked for existing precedent in how we might call out
22071distinct overloads overloads from a set of constrained templates, but there
22072is not much existing practice to lean on.   advance/distance were the only
22073algorithms I could find, and that wording is no clearer.]
22074</p>
22075
22076</blockquote>
22077
22078<p><i>[
220792009-07 Frankfurt
22080]</i></p>
22081
22082
22083<blockquote>
22084<p>
22085Hinnant: if you want to partition your std::forward_list, you'll need
22086partition() to accept ForwardIterators.
22087</p>
22088<p>
22089No objection to Ready.
22090</p>
22091<p>
22092Move to Ready.
22093</p>
22094</blockquote>
22095
22096
22097
22098<p><b>Proposed resolution:</b></p>
22099<p>
22100Change 25.2.12 from </p>
22101<blockquote><pre>template&lt;class BidirectionalIterator, class Predicate&gt; 
22102BidirectionalIterator partition(BidirectionalIterato r first, 
22103                                BidirectionalIterator last, 
22104                                Predicate pred); 
22105</pre></blockquote>
22106<p>to </p>
22107<blockquote><pre>template&lt;class ForwardIterator, class Predicate&gt; 
22108ForwardIterator partition(ForwardIterator first, 
22109                          ForwardIterator last, 
22110                          Predicate pred); 
22111</pre></blockquote>
22112<p>Change the complexity from </p>
22113
22114<blockquote><p>
22115At most (last - first)/2 swaps are done. Exactly (last - first) 
22116applications of the predicate are done. 
22117</p></blockquote>
22118
22119<p>to </p>
22120
22121<blockquote><p>
22122If ForwardIterator is a bidirectional_iterator, at most (last - first)/2 
22123swaps are done; otherwise at most (last - first) swaps are done. Exactly 
22124(last - first) applications of the predicate are done. 
22125</p></blockquote>
22126
22127
22128
22129<p><b>Rationale:</b></p>
22130<p>
22131Partition is a "foundation" algorithm useful in many contexts (like sorting
22132as just one example) - my motivation for extending it to include forward
22133iterators is foward_list - without this extension you can't partition an foward_list
22134(without writing your own partition). Holes like this in the standard
22135library weaken the argument for generic programming (ideally I'd be able
22136to provide a library that would refine std::partition() to other concepts
22137without fear of conflicting with other libraries doing the same - but
22138that is a digression). I consider the fact that partition isn't defined
22139to work for ForwardIterator a minor embarrassment.
22140</p>
22141
22142<p><i>[Mont Tremblant: Moved to Open, request motivation and use cases
22143by next meeting. Sean provided further rationale by post-meeting
22144mailing.]</i></p>
22145
22146
22147
22148
22149
22150
22151
22152<hr>
22153<h3><a name="505"></a>505. Result_type in random distribution requirements</h3>
22154<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>
22155 <b>Submitter:</b> Walter Brown <b>Opened:</b> 2005-07-03  <b>Last modified:</b> 2008-09-26</p>
22156<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>
22157<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
22158<p><b>Discussion:</b></p>
22159<p>
22160Table 17: Random distribution requirements
22161</p>
22162<p>
22163Row 1 requires that each random distribution provide a nested type "input_type";
22164this type denotes the type of the values that the distribution consumes.
22165</p>
22166<p>
22167Inspection of all distributions in [tr.rand.dist] reveals that each distribution
22168provides a second typedef ("result_type") that denotes the type of the values the
22169distribution produces when called.  
22170</p>
22171
22172
22173<p><b>Proposed resolution:</b></p>
22174<p>
22175It seems to me that this is also a requirement
22176for all distributions and should therefore be  indicated as such via a new second
22177row to this table 17:
22178</p>
22179<table border="1" cellpadding="5">
22180<tbody><tr><td>X::result_type</td><td>T</td><td>---</td><td>compile-time</td></tr>
22181</tbody></table>
22182
22183<p><i>[
22184Berlin:  Voted to WP.  N1932 adopts the proposed resolution:  see Table 5 row 1.
22185]</i></p>
22186
22187
22188
22189
22190
22191
22192
22193<hr>
22194<h3><a name="507"></a>507. Missing requirement for variate_generator::operator()</h3>
22195<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>
22196 <b>Submitter:</b> Walter Brown <b>Opened:</b> 2005-07-03  <b>Last modified:</b> 2008-09-26</p>
22197<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>
22198<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
22199<p><b>Discussion:</b></p>
22200<p>
22201Paragraph 11 of [tr.rand.var] equires that the member template
22202</p>
22203<blockquote><pre>template&lt;class T&gt; result_type operator() (T value);
22204</pre></blockquote>
22205<p>
22206return
22207</p>
22208<blockquote><pre>distribution()(e, value)
22209</pre></blockquote>
22210<p>
22211However, not all distributions have an operator() with a corresponding signature.
22212</p>
22213
22214<p><i>[
22215Berlin:  As a working group we voted in favor of N1932 which makes this moot:
22216variate_generator has been eliminated.  Then in full committee we voted to give
22217this issue WP status (mistakenly).
22218]</i></p>
22219
22220
22221
22222
22223<p><b>Proposed resolution:</b></p>
22224<p>
22225We therefore  recommend that we insert the following precondition before paragraph 11:
22226</p>
22227<blockquote><p>
22228Precondition:  <tt>distribution().operator()(e,value)</tt> is well-formed.
22229</p></blockquote>
22230
22231
22232
22233
22234
22235<hr>
22236<h3><a name="508"></a>508. Bad parameters for ranlux64_base_01</h3>
22237<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>
22238 <b>Submitter:</b> Walter Brown <b>Opened:</b> 2005-07-03  <b>Last modified:</b> 2008-09-26</p>
22239<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>
22240<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
22241<p><b>Discussion:</b></p>
22242<p>
22243The fifth of these engines with predefined parameters, ranlux64_base_01,
22244appears to have an unintentional error for which there is a simple correction.
22245The two pre-defined  subtract_with_carry_01 engines are given as: 
22246</p>
22247<blockquote><pre>typedef subtract_with_carry_01&lt;float,  24, 10, 24&gt; ranlux_base_01;
22248typedef subtract_with_carry_01&lt;double, 48, 10, 24&gt; ranlux64_base_01;
22249</pre></blockquote>
22250<p>
22251We demonstrate below that ranlux64_base_01 fails to meet the intent of the
22252random number generation proposal, but that the simple correction to
22253</p>
22254<blockquote><pre>typedef subtract_with_carry_01&lt;double, 48,  5, 12&gt; ranlux64_base_01;
22255</pre></blockquote>
22256<p>
22257does meet the intent of defining well-known good parameterizations.
22258</p>
22259<p>
22260The ranlux64_base_01 engine as presented fails to meet the intent for
22261predefined engines, stated in proposal N1398 (section E):
22262</p>
22263<blockquote><p>
22264In order to make good random numbers available to a large number of library
22265users, this proposal not only defines generic random-number engines, but also
22266provides a number of predefined well-known good parameterizations for those.
22267</p></blockquote>
22268<p>
22269The predefined ranlux_base_01 engine has been proven [1,2,3] to have a very
22270long period and so meets this criterion.  This property makes it suitable for
22271use in the excellent discard_block  engines defined subsequently.  The proof
22272of long period relies on the fact (proven in [1]) that 2**(w*r) - 2**(w*s)
22273+ 1 is prime (w, r, and s are template parameters to subtract_with_carry_01,
22274as defined in [tr.rand.eng.sub1]).
22275</p>
22276<p>
22277The ranlux64_base_01 engine as presented in [tr.rand.predef] uses w=48, r=24, s=10.
22278For these numbers, the combination 2**(w*r)-2**(w*s)+1 is non-prime (though
22279explicit factorization  would be a challenge).  In consequence, while it is
22280certainly possible for some seeding states that this engine would have a very
22281long period, it is not at all "well-known" that this is the case. The intent
22282in the N1398 proposal involved the base of the ranlux64 engine, which finds heavy
22283use in the physics community.  This is isomorphic to the predefined ranlux_base_01,
22284but exploits the ability of double variables to hold (at least) 48 bits of mantissa,
22285to deliver 48 random bits at a time rather than 24.
22286</p>
22287
22288
22289<p><b>Proposed resolution:</b></p>
22290<p>
22291To achieve this intended behavior, the correct template parameteriztion  would be:
22292</p>
22293<blockquote><pre>typedef subtract_with_carry_01&lt;double, 48, 5, 12&gt; ranlux64_base_01;
22294</pre></blockquote>
22295<p>
22296The sequence of mantissa bits delivered by this is isomorphic (treating each
22297double as having the  bits of two floats) to that delivered by ranlux_base_01.
22298</p>
22299<p>
22300<b>References:</b>
22301</p>
22302<ol>
22303<li>F. James, Comput. Phys. Commun. 60(1990) 329</li>
22304<li>G. Marsaglia and A. Zaman, Ann. Appl. Prob 1(1991) 462</li>
22305<li>M. Luscher, Comput. Phys. Commun. 79(1994) 100-110</li>
22306</ol>
22307
22308<p><i>[
22309Berlin: Voted to WP.  N1932 adopts the proposed resolution in 26.3.5,
22310just above paragraph 5.
22311]</i></p>
22312
22313
22314
22315
22316
22317
22318
22319<hr>
22320<h3><a name="518"></a>518. Are insert and erase stable for unordered_multiset and unordered_multimap?</h3>
22321<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>
22322 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2005-07-03  <b>Last modified:</b> 2008-09-26</p>
22323<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>
22324<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>
22325<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
22326<p><b>Discussion:</b></p>
22327<p>
22328Issue 371 deals with stability of multiset/multimap under insert and erase
22329(i.e. do they preserve the relative order in ranges of equal elements).
22330The same issue applies to unordered_multiset and unordered_multimap.
22331</p>
22332<p><i>[
22333Moved to open (from review):  There is no resolution.
22334]</i></p>
22335
22336
22337<p><i>[
22338Toronto:  We have a resolution now.  Moved to Review.  Some concern was noted
22339as to whether this conflicted with existing practice or not.  An additional
22340concern was in specifying (partial) ordering for an unordered container.
22341]</i></p>
22342
22343
22344
22345
22346<p><b>Proposed resolution:</b></p>
22347<p>
22348Wording for the proposed resolution is taken from the equivalent text for associative containers.
22349</p>
22350
22351<p>
22352Change 23.2.5 [unord.req], Unordered associative containers, paragraph 6 to:
22353</p>
22354
22355<blockquote><p>
22356An unordered associative container supports <i>unique</i> keys if it may 
22357contain at most one element for each key. Otherwise, it supports <i>equivalent 
22358keys</i>. <tt>unordered_set</tt> and <tt>unordered_map</tt> support 
22359unique keys. <tt>unordered_multiset</tt> and <tt>unordered_multimap</tt> 
22360support equivalent keys. In containers that support equivalent keys, elements 
22361with equivalent keys are adjacent to each other. <ins>For
22362<tt>unordered_multiset</tt> 
22363and <tt>unordered_multimap</tt>,<tt> insert</tt> and <tt>erase</tt> 
22364preserve the relative ordering of equivalent elements.</ins>
22365</p></blockquote>
22366
22367<p>
22368Change 23.2.5 [unord.req], Unordered associative containers, paragraph 8 to:
22369</p>
22370
22371<blockquote>
22372<p>The elements of an unordered associative container are organized into <i>
22373buckets</i>. Keys with the same hash code appear in the same bucket. The number 
22374of buckets is automatically increased as elements are added to an unordered 
22375associative container, so that the average number of elements per bucket is kept 
22376below a bound. Rehashing invalidates iterators, changes ordering between 
22377elements, and changes which buckets elements appear in, but does not invalidate 
22378pointers or references to elements. <ins>For <tt>unordered_multiset</tt> 
22379and <tt>unordered_multimap</tt>, rehashing 
22380preserves the relative ordering of equivalent elements.</ins></p>
22381</blockquote>
22382
22383
22384
22385
22386
22387
22388<hr>
22389<h3><a name="519"></a>519. Data() undocumented</h3>
22390<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>
22391 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2005-07-03  <b>Last modified:</b> 2008-09-26</p>
22392<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>
22393<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
22394<p><b>Discussion:</b></p>
22395<p>
22396<tt>array&lt;&gt;::data()</tt> is present in the class synopsis, but not documented.
22397</p>
22398
22399
22400<p><b>Proposed resolution:</b></p>
22401<p>
22402Add a new section, after 6.2.2.3:
22403</p>
22404<blockquote><pre>T*       data()
22405const T* data() const;
22406</pre></blockquote>
22407<p>
22408<b>Returns:</b> <tt>elems</tt>.
22409</p>
22410<p>
22411Change 6.2.2.4/2 to:
22412</p>
22413<blockquote><p>
22414In the case where <tt>N == 0</tt>, <tt>begin() == end()</tt>. The return value
22415of <tt>data()</tt> is unspecified.
22416</p></blockquote>
22417
22418
22419
22420
22421
22422<hr>
22423<h3><a name="520"></a>520. Result_of and pointers to data members</h3>
22424<p><b>Section:</b> 20.7.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#CD1">CD1</a>
22425 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2005-07-03  <b>Last modified:</b> 2008-09-26</p>
22426<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
22427<p><b>Discussion:</b></p>
22428<p>
22429In the original proposal for binders, the return type of bind() when
22430called with a pointer to member data as it's callable object was
22431defined to be mem_fn(ptr); when Peter Dimov and I  unified the
22432descriptions of the TR1 function objects we hoisted the descriptions
22433of return types into the INVOKE pseudo-function and into result_of.
22434Unfortunately, we left pointer to member data out of result_of, so
22435bind doesn't have any specified behavior when called with a pointer
22436to  member data.
22437</p>
22438
22439
22440<p><b>Proposed resolution:</b></p>
22441<p><i>[
22442Pete and Peter will provide wording.
22443]</i></p>
22444
22445
22446<p>
22447In 20.5.4 [lib.func.ret] ([tr.func.ret]) p3 add the following bullet after bullet 2:
22448</p>
22449<ol start="3">
22450<li>If <tt>F</tt> is a member data pointer type <tt>R T::*</tt>, <tt>type</tt>
22451shall be <tt><i>cv</i> R&amp;</tt> when <tt>T1</tt> is <tt><i>cv</i> U1&amp;</tt>,
22452<tt>R</tt> otherwise.</li>
22453</ol>
22454
22455<p><i>[
22456Peter provided wording.
22457]</i></p>
22458
22459
22460
22461
22462
22463
22464
22465<hr>
22466<h3><a name="521"></a>521. Garbled requirements for argument_type in reference_wrapper</h3>
22467<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>
22468 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2005-07-03  <b>Last modified:</b> 2008-09-26</p>
22469<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>
22470<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
22471<p><b>Discussion:</b></p>
22472<p>
224732.1.2/3, second bullet item currently says that reference_wrapper&lt;T&gt; is
22474derived from unary_function&lt;T, R&gt; if T is:
22475</p>
22476<blockquote><p>
22477a pointer to member function type with cv-qualifier cv and no arguments;
22478the type T1 is cv T* and R is the return type of the pointer to member function;
22479</p></blockquote>
22480<p>
22481The type of T1 can't be cv T*, 'cause that's a pointer to a pointer to member
22482function. It should be a pointer to the class that T is a pointer to member of.
22483Like this:
22484</p>
22485<blockquote><p>
22486a pointer to a member function R T0::f() cv (where cv represents the member
22487function's cv-qualifiers); the type T1 is cv T0*
22488</p></blockquote>
22489<p>
22490Similarly, bullet item 2 in 2.1.2/4 should be:
22491</p>
22492<blockquote><p>
22493a pointer to a member function R T0::f(T2) cv (where cv represents the member
22494function's cv-qualifiers); the type T1 is cv T0*
22495</p></blockquote>
22496
22497
22498<p><b>Proposed resolution:</b></p>
22499
22500<p>
22501Change bullet item 2 in 2.1.2/3:
22502</p>
22503
22504<blockquote>
22505<ul>
22506<li>
22507a pointer to member function <del>type with cv-qualifier <tt><i>cv</i></tt> and no arguments;
22508the type <tt>T1</tt> is <tt><i>cv</i> T*</tt> and <tt>R</tt> is the return 
22509type of the pointer to member function</del> <ins><tt>R T0::f() <i>cv</i></tt>
22510(where <tt><i>cv</i></tt> represents the member function's cv-qualifiers);
22511the type <tt>T1</tt> is <tt><i>cv</i> T0*</tt></ins>
22512</li>
22513</ul>
22514</blockquote>
22515
22516<p>
22517Change bullet item 2 in 2.1.2/4:
22518</p>
22519
22520<blockquote>
22521<ul>
22522<li>
22523a pointer to member function <del>with cv-qualifier <tt><i>cv</i></tt> and taking one argument
22524of type <tt>T2</tt>; the type <tt>T1</tt> is <tt><i>cv</i> T*</tt> and 
22525<tt>R</tt> is the return type of the pointer to member function</del>
22526<ins><tt>R T0::f(T2) <i>cv</i></tt> (where <tt><i>cv</i></tt> represents the member
22527function's cv-qualifiers); the type <tt>T1</tt> is <tt><i>cv</i> T0*</tt></ins>
22528</li>
22529</ul>
22530</blockquote>
22531
22532
22533
22534
22535
22536
22537<hr>
22538<h3><a name="522"></a>522. Tuple doesn't define swap</h3>
22539<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>
22540 <b>Submitter:</b> Andy Koenig <b>Opened:</b> 2005-07-03  <b>Last modified:</b> 2008-09-26</p>
22541<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>
22542<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
22543<p><b>Discussion:</b></p>
22544<p>
22545Tuple doesn't define swap().  It should.
22546</p>
22547<p><i>[
22548Berlin: Doug to provide wording.
22549]</i></p>
22550
22551<p><i>[
22552Batavia: Howard to provide wording.
22553]</i></p>
22554
22555<p><i>[
22556Toronto: Howard to provide wording (really this time).
22557]</i></p>
22558
22559
22560<p><i>[
22561Bellevue:  Alisdair provided wording.
22562]</i></p>
22563
22564
22565
22566
22567<p><b>Proposed resolution:</b></p>
22568
22569<p>
22570Add these signatures to 20.5 [tuple]
22571</p>
22572
22573<blockquote><pre>template &lt;class... Types&gt;
22574  void swap(tuple&lt;Types...&gt;&amp; x, tuple&lt;Types...&gt;&amp; y);
22575template &lt;class... Types&gt;
22576  void swap(tuple&lt;Types...&gt;&amp;&amp; x, tuple&lt;Types...&gt;&amp; y);
22577template &lt;class... Types&gt;
22578  void swap(tuple&lt;Types...&gt;&amp; x, tuple&lt;Types...&gt;&amp;&amp; y); 
22579</pre></blockquote>
22580
22581<p>
22582Add this signature to 20.5.2 [tuple.tuple]
22583</p>
22584
22585<blockquote><pre>void swap(tuple&amp;&amp;);
22586</pre></blockquote>
22587
22588<p>
22589Add the following two sections to the end of the tuple clauses
22590</p>
22591
22592<blockquote>
22593<p>
2259420.3.1.7 tuple swap [tuple.swap]
22595</p>
22596
22597<pre>void swap(tuple&amp;&amp; rhs); 
22598</pre>
22599
22600<blockquote>
22601<p>
22602<i>Requires:</i> Each type in <tt>Types</tt> shall be <tt>Swappable</tt>.
22603</p>
22604<p>
22605<i>Effects:</i> Calls <tt>swap</tt> for each element in <tt>*this</tt> and its corresponding element
22606in <tt>rhs</tt>.
22607</p>
22608<p>
22609<i>Throws:</i> Nothing, unless one of the element-wise <tt>swap</tt> calls throw an
22610exception. 
22611</p>
22612</blockquote>
22613
22614<p>
2261520.3.1.8 tuple specialized algorithms [tuple.special]
22616</p>
22617
22618<pre>template &lt;class... Types&gt;
22619  void swap(tuple&lt;Types...&gt;&amp; x, tuple&lt;Types...&gt;&amp; y);
22620template &lt;class... Types&gt;
22621  void swap(tuple&lt;Types...&gt;&amp;&amp; x, tuple&lt;Types...&gt;&amp; y);
22622template &lt;class... Types&gt;
22623  void swap(tuple&lt;Types...&gt;&amp; x, tuple&lt;Types...&gt;&amp;&amp; y); 
22624</pre>
22625
22626<blockquote>
22627<p>
22628<i>Effects:</i> x.swap(y)
22629</p>
22630</blockquote>
22631</blockquote>
22632
22633
22634
22635
22636
22637
22638<hr>
22639<h3><a name="524"></a>524. regex named character classes and case-insensitivity don't mix</h3>
22640<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>
22641 <b>Submitter:</b> Eric Niebler <b>Opened:</b> 2005-07-01  <b>Last modified:</b> 2008-09-26</p>
22642<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>
22643<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
22644<p><b>Discussion:</b></p>
22645<p>
22646This defect is also being discussed on the Boost developers list. The 
22647full discussion can be found here:
22648http://lists.boost.org/boost/2005/07/29546.php
22649</p>
22650<p>
22651-- Begin original message --
22652</p>
22653<p>
22654Also, I may have found another issue, closely related to the one under
22655discussion. It regards case-insensitive matching of named character
22656classes. The regex_traits&lt;&gt; provides two functions for working with
22657named char classes: lookup_classname and isctype. To match a char class
22658such as [[:alpha:]], you pass "alpha" to lookup_classname and get a
22659bitmask. Later, you pass a char and the bitmask to isctype and get a
22660bool yes/no answer.
22661</p>
22662<p>
22663But how does case-insensitivity work in this scenario? Suppose we're
22664doing a case-insensitive match on [[:lower:]]. It should behave as if it
22665were [[:lower:][:upper:]], right? But there doesn't seem to be enough
22666smarts in the regex_traits interface to do this.
22667</p>
22668<p>
22669Imagine I write a traits class which recognizes [[:fubar:]], and the
22670"fubar" char class happens to be case-sensitive. How is the regex engine
22671to know that? And how should it do a case-insensitive match of a
22672character against the [[:fubar:]] char class? John, can you confirm this
22673is a legitimate problem?
22674</p>
22675<p>
22676I see two options:
22677</p>
22678<p>
226791) Add a bool icase parameter to lookup_classname. Then,
22680lookup_classname( "upper", true ) will know to return lower|upper
22681instead of just upper.
22682</p>
22683<p>
226842) Add a isctype_nocase function
22685</p>
22686<p>
22687I prefer (1) because the extra computation happens at the time the
22688pattern is compiled rather than when it is executed.
22689</p>
22690<p>
22691-- End original message --
22692</p>
22693
22694<p>
22695For what it's worth, John has also expressed his preference for option 
22696(1) above.
22697</p>
22698
22699
22700<p><b>Proposed resolution:</b></p>
22701<p>
22702Adopt the proposed resolution in
22703<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2409.pdf">N2409</a>.
22704</p>
22705
22706
22707<p><i>[
22708Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue.
22709The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
22710]</i></p>
22711
22712
22713
22714
22715
22716<hr>
22717<h3><a name="527"></a>527. tr1::bind has lost its Throws clause</h3>
22718<p><b>Section:</b> 20.7.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#CD1">CD1</a>
22719 <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2005-10-01  <b>Last modified:</b> 2008-09-26</p>
22720<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>
22721<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>
22722<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
22723<p><b>Discussion:</b></p>
22724<p>
22725The original bind proposal gives the guarantee that tr1::bind(f, t1,
22726..., tN) does not throw when the copy constructors of f, t1, ..., tN
22727don't.
22728</p>
22729
22730<p>
22731This guarantee is not present in the final version of TR1.
22732</p>
22733
22734<p>
22735I'm pretty certain that we never removed it on purpose. Editorial omission? :-)
22736</p>
22737
22738<p><i>[
22739Berlin: not quite editorial, needs proposed wording.
22740]</i></p>
22741
22742<p><i>[
22743Batavia:  Doug to translate wording to variadic templates.
22744]</i></p>
22745
22746
22747<p><i>[
22748Toronto:  We agree but aren't quite happy with the wording.  The "t"'s no
22749longer refer to anything.  Alan to provide improved wording.
22750]</i></p>
22751
22752
22753
22754<p><i>[
22755Pre-Bellevue:  Alisdair provided wording.
22756]</i></p>
22757
22758
22759<p>
22760TR1 proposed resolution:
22761</p>
22762
22763<blockquote>
22764<p>
22765In TR1 3.6.3 [tr.func.bind.bind], add a new paragraph after p2:
22766</p>
22767<blockquote><p>
22768<i>Throws:</i> Nothing unless one of the copy constructors of <tt>f, t1, t2, ..., tN</tt>
22769throws an exception.
22770</p></blockquote>
22771
22772<p>
22773Add a new paragraph after p4:
22774</p>
22775<blockquote><p>
22776<i>Throws:</i> nothing unless one of the copy constructors of <tt>f, t1, t2, ..., tN</tt>
22777throws an exception.
22778</p></blockquote>
22779
22780</blockquote>
22781
22782
22783
22784<p><b>Proposed resolution:</b></p>
22785<p>
22786In 20.7.11.1.3 [func.bind.bind], add a new paragraph after p2:
22787</p>
22788
22789<blockquote>
22790<i>Throws:</i> Nothing unless the copy constructor of <tt>F</tt> or of one of the types
22791in the <tt>BoundArgs...</tt> pack expansion throws an exception. 
22792</blockquote>
22793
22794<p>
22795In 20.7.11.1.3 [func.bind.bind], add a new paragraph after p4:
22796</p>
22797
22798<blockquote>
22799<i>Throws:</i> Nothing unless the copy constructor of <tt>F</tt> or of one of the types
22800in the <tt>BoundArgs...</tt> pack expansion throws an exception. 
22801</blockquote>
22802
22803
22804
22805
22806
22807
22808<hr>
22809<h3><a name="530"></a>530. Must elements of a string be contiguous?</h3>
22810<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>
22811 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2005-11-15  <b>Last modified:</b> 2008-09-26</p>
22812<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>
22813<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
22814<p><b>Discussion:</b></p>
22815<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
22816   that the elements of a vector must be stored in contiguous memory.
22817   Should the same also apply to <tt>basic_string</tt>?</p>
22818
22819<p>We almost require contiguity already. Clause 23.4.4 [multiset]
22820  defines <tt>operator[]</tt> as <tt>data()[pos]</tt>. What's missing
22821  is a similar guarantee if we access the string's elements via the
22822  iterator interface.</p>
22823
22824<p>Given the existence of <tt>data()</tt>, and the definition of
22825  <tt>operator[]</tt> and <tt>at</tt> in terms of <tt>data</tt>,
22826  I don't believe it's possible to write a useful and standard-
22827  conforming <tt>basic_string</tt> that isn't contiguous. I'm not
22828  aware of any non-contiguous implementation. We should just require
22829  it.
22830</p>
22831
22832
22833<p><b>Proposed resolution:</b></p>
22834<p>Add the following text to the end of 21.4 [basic.string],
22835paragraph 2. </p>
22836
22837<blockquote>
22838  <p>The characters in a string are stored contiguously, meaning that if
22839  <tt>s</tt> is a <tt>basic_string&lt;charT, Allocator&gt;</tt>, then
22840  it obeys the identity
22841  <tt>&amp;*(s.begin() + n) == &amp;*s.begin() + n</tt>
22842  for all <tt>0 &lt;= n &lt; s.size()</tt>.
22843  </p>
22844</blockquote>
22845
22846
22847<p><b>Rationale:</b></p>
22848<p>
22849Not standardizing this existing practice does not give implementors more
22850freedom.  We thought it might a decade ago.  But the vendors have spoken
22851both with their implementations, and with their voice at the LWG
22852meetings.  The implementations are going to be contiguous no matter what
22853the standard says.  So the standard might as well give string clients
22854more design choices.
22855</p>
22856
22857
22858
22859
22860
22861<hr>
22862<h3><a name="531"></a>531. array forms of unformatted input functions</h3>
22863<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>
22864 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2005-11-23  <b>Last modified:</b> 2008-09-26</p>
22865<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>
22866<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
22867<p><b>Discussion:</b></p>
22868<p>
22869The array forms of unformatted input functions don't seem to have well-defined
22870semantics for zero-element arrays in a couple of cases. The affected ones
22871(<tt>istream::get()</tt> and <tt>istream::getline()</tt>) are supposed to
22872terminate when <tt>(n - 1)</tt> characters are stored, which obviously can
22873never be true when <tt>(n == 0)</tt> holds to start with. See
22874c++std-lib-16071.
22875</p>
22876
22877
22878<p><b>Proposed resolution:</b></p>
22879<p>
22880I suggest changing 27.6.1.3, p7 (<tt>istream::get()</tt>), bullet 1 to read:
22881</p>
22882            <ul>
22883                <li>
22884                    <tt>(n &lt; 1)</tt> is true or <tt>(n - 1)</tt> characters
22885                    are stored;
22886                </li>
22887            </ul>
22888<p>
22889Change 27.6.1.3, p9:
22890</p>
22891
22892<blockquote><p>
22893If the function stores no characters, it calls <tt>setstate(failbit)</tt> (which
22894may throw <tt>ios_base::failure</tt> (27.4.4.3)).  In any case, <ins>if <tt>(n
22895&gt; 0)</tt> is true</ins> it then stores a null character into the next
22896successive location of the array.
22897</p></blockquote>
22898
22899        <p>
22900
22901and similarly p17 (<tt>istream::getline()</tt>), bullet 3 to:
22902
22903        </p>
22904            <ul>
22905                <li>
22906                    <tt>(n &lt; 1)</tt> is true or <tt>(n - 1)</tt> characters
22907                    are stored (in which case the function calls
22908                    <tt>setstate(failbit)</tt>).
22909                </li>
22910            </ul>
22911
22912        <p>
22913
22914In addition, to clarify that <tt>istream::getline()</tt> must not store the
22915terminating NUL character unless the the array has non-zero size, Robert
22916Klarer suggests in c++std-lib-16082 to change 27.6.1.3, p20 to read:
22917
22918        </p>
22919            <blockquote><p>
22920
22921In any case, provided <tt>(n &gt; 0)</tt> is true, it then stores a null character
22922(using charT()) into the next successive location of the array.
22923
22924            </p></blockquote>
22925
22926<p><i>[
22927post-Redmond:  Pete noticed that the current resolution for <tt>get</tt> requires
22928writing to out of bounds memory when <tt>n == 0</tt>.  Martin provided fix.
22929]</i></p>
22930
22931
22932
22933
22934
22935
22936
22937<hr>
22938<h3><a name="533"></a>533. typo in 2.2.3.10/1</h3>
22939<p><b>Section:</b> 20.8.15.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>
22940 <b>Submitter:</b> Paolo Carlini <b>Opened:</b> 2005-11-09  <b>Last modified:</b> 2009-05-01</p>
22941<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>
22942<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
22943<p><b>Discussion:</b></p>
22944<p>
22945I'm seeing something that looks like a typo. The Return of <tt>get_deleter</tt>
22946says:
22947</p>
22948<blockquote><p>
22949If <tt>*this</tt> <i>owns</i> a deleter <tt>d</tt>...
22950</p></blockquote>
22951<p>
22952but <tt>get_deleter</tt> is a free function!
22953</p>
22954
22955
22956<p><b>Proposed resolution:</b></p>
22957<p>
22958Therefore, I think should be:
22959</p>
22960<blockquote><p>
22961If <tt><del>*this</del> <ins>p</ins></tt> <i>owns</i> a deleter <tt>d</tt>...
22962</p></blockquote>
22963
22964
22965
22966
22967
22968<hr>
22969<h3><a name="534"></a>534. Missing basic_string members</h3>
22970<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>
22971 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2005-11-16  <b>Last modified:</b> 2008-09-26</p>
22972<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>
22973<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
22974<p><b>Discussion:</b></p>
22975<p>
22976OK, we all know std::basic_string is bloated and already has way too
22977many members.  However, I propose it is missing 3 useful members that
22978are often expected by users believing it is a close approximation of the
22979container concept.  All 3 are listed in table 71 as 'optional'
22980</p>
22981
22982<p>
22983i/  pop_back.
22984</p>
22985
22986<p>
22987This is the one I feel most strongly about, as I only just discovered it
22988was missing as we are switching to a more conforming standard library
22989&lt;g&gt;
22990</p>
22991
22992<p>
22993I find it particularly inconsistent to support push_back, but not
22994pop_back.
22995</p>
22996
22997<p>
22998ii/ back.
22999</p>
23000
23001<p>
23002There are certainly cases where I want to examine the last character of
23003a string before deciding to append, or to trim trailing path separators
23004from directory names etc.  *rbegin() somehow feels inelegant.
23005</p>
23006
23007<p>
23008iii/ front
23009</p>
23010
23011<p>
23012This one I don't feel strongly about, but if I can get the first two,
23013this one feels that it should be added as a 'me too' for consistency.
23014</p>
23015
23016<p>
23017I believe this would be similarly useful to the data() member recently
23018added to vector, or at() member added to the maps.
23019</p>
23020
23021
23022<p><b>Proposed resolution:</b></p>
23023<p>
23024Add the following members to definition of class template basic_string, 21.3p7
23025</p>
23026<blockquote><pre>void pop_back ()
23027
23028const charT &amp; front() const
23029charT &amp; front()
23030
23031const charT &amp; back() const
23032charT &amp; back()
23033</pre></blockquote>
23034<p>
23035Add the following paragraphs to basic_string description
23036</p>
23037
23038<p>
2303921.3.4p5
23040</p>
23041<blockquote>
23042<pre>const charT &amp; front() const
23043charT &amp; front()
23044</pre>
23045<p>
23046<i>Precondition:</i> <tt>!empty()</tt>
23047</p>
23048<p>
23049<i>Effects:</i> Equivalent to <tt>operator[](0)</tt>.
23050</p>
23051</blockquote>
23052
23053<p>
2305421.3.4p6
23055</p>
23056<blockquote>
23057<pre>const charT &amp; back() const
23058charT &amp; back()
23059</pre>
23060<p>
23061<i>Precondition:</i> <tt>!empty()</tt>
23062</p>
23063<p>
23064<i>Effects:</i> Equivalent to <tt>operator[]( size() - 1)</tt>.
23065</p>
23066</blockquote>
23067
23068<p>
2306921.3.5.5p10
23070</p>
23071<blockquote>
23072<pre>void pop_back ()
23073</pre>
23074<p>
23075<i>Precondition:</i> <tt>!empty()</tt>
23076</p>
23077<p>
23078<i>Effects:</i> Equivalent to <tt>erase( size() - 1, 1 )</tt>.
23079</p>
23080</blockquote>
23081
23082<p>
23083Update Table 71: (optional sequence operations)
23084Add basic_string to the list of containers for the following operations.
23085</p>
23086<blockquote><pre>a.front()
23087a.back()
23088a.push_back()
23089a.pop_back()
23090a[n]
23091</pre></blockquote>
23092
23093<p><i>[
23094Berlin: Has support.  Alisdair provided wording.
23095]</i></p>
23096
23097
23098
23099
23100
23101
23102<hr>
23103<h3><a name="535"></a>535. std::string::swap specification poorly worded</h3>
23104<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>
23105 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2005-12-14  <b>Last modified:</b> 2008-09-26</p>
23106<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>
23107<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
23108<p><b>Discussion:</b></p>
23109<p>
23110std::string::swap currently says for effects and postcondition:
23111</p>
23112
23113<blockquote>
23114<p>
23115<i>Effects:</i> Swaps the contents of the two strings.
23116</p>
23117
23118<p>
23119<i>Postcondition:</i> <tt>*this</tt> contains the characters that were in <tt><i>s</i></tt>,
23120<tt><i>s</i></tt> contains the characters that were in <tt>*this</tt>.
23121</p>
23122</blockquote>
23123
23124<p>
23125Specifying both Effects and Postcondition seems redundant, and the postcondition
23126needs to be made stronger. Users would be unhappy if the characters were not in
23127the same order after the swap.
23128</p>
23129
23130
23131<p><b>Proposed resolution:</b></p>
23132<blockquote>
23133<p>
23134<del><i>Effects:</i> Swaps the contents of the two strings.</del>
23135</p>
23136
23137<p>
23138<i>Postcondition:</i> <tt>*this</tt> contains the <ins>same sequence of</ins>
23139characters that <del>were</del> <ins>was</ins> in <tt><i>s</i></tt>,
23140<tt><i>s</i></tt> contains the <ins>same sequence of</ins> characters that
23141<del>were</del> <ins>was</ins> in <tt>*this</tt>.
23142</p>
23143</blockquote>
23144
23145
23146
23147
23148
23149<hr>
23150<h3><a name="537"></a>537. Typos in the signatures in 27.6.1.3/42-43 and 27.6.2.4</h3>
23151<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>
23152 <b>Submitter:</b> Paolo Carlini <b>Opened:</b> 2006-02-12  <b>Last modified:</b> 2008-09-26</p>
23153<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>
23154<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
23155<p><b>Discussion:</b></p>
23156<p>
23157In the most recent working draft, I'm still seeing:
23158</p>
23159
23160<blockquote><pre>seekg(off_type&amp; off, ios_base::seekdir dir)
23161</pre></blockquote>
23162
23163<p>
23164and
23165</p>
23166
23167<blockquote><pre>seekp(pos_type&amp; pos)
23168
23169seekp(off_type&amp; off, ios_base::seekdir dir)
23170</pre></blockquote>
23171
23172<p>
23173that is, by reference off and pos arguments.
23174</p>
23175
23176
23177<p><b>Proposed resolution:</b></p>
23178<p>
23179After 27.6.1.3p42 change:
23180</p>
23181
23182<blockquote><pre>basic_istream&lt;charT,traits&gt;&amp; seekg(off_type<del>&amp;</del> <i>off</i>, ios_base::seekdir <i>dir</i>);
23183</pre></blockquote>
23184
23185<p>
23186After 27.6.2.4p1 change:
23187</p>
23188
23189<blockquote><pre>basic_ostream&lt;charT,traits&gt;&amp; seekp(pos_type<del>&amp;</del> <i>pos</i>);
23190</pre></blockquote>
23191
23192<p>
23193After 27.6.2.4p3 change:
23194</p>
23195
23196<blockquote><pre>basic_ostream&lt;charT,traits&gt;&amp; seekp(off_type<del>&amp;</del> <i>off</i>, ios_base::seekdir <i>dir</i>);
23197</pre></blockquote>
23198
23199
23200
23201
23202
23203<hr>
23204<h3><a name="538"></a>538. 241 again: Does unique_copy() require CopyConstructible and Assignable?</h3>
23205<p><b>Section:</b> 25.3.9 [alg.unique] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
23206 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2006-02-09  <b>Last modified:</b> 2008-09-26</p>
23207<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>
23208<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
23209<p><b>Discussion:</b></p>
23210<p>
23211I believe I botched the resolution of
23212<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#241">
23213241 "Does unique_copy() require CopyConstructible and Assignable?"</a> which now
23214has WP status.
23215</p>
23216
23217<p>
23218This talks about <tt>unique_copy</tt> requirements and currently reads:
23219</p>
23220
23221<blockquote><p>
23222-5- <i>Requires:</i> The ranges <tt>[<i>first</i>, <i>last</i>)</tt> and
23223<tt>[<i>result</i>, <i>result</i>+(<i>last</i>-<i>first</i>))</tt>
23224shall not overlap. The expression <tt>*<i>result</i> = *<i>first</i></tt> shall
23225be valid. If neither <tt>InputIterator</tt> nor <tt>OutputIterator</tt> meets the
23226requirements of forward iterator then the value type of <tt>InputIterator</tt>
23227must be CopyConstructible (20.1.3). Otherwise CopyConstructible is not required.
23228</p></blockquote>
23229
23230<p>
23231The problem (which Paolo discovered) is that when the iterators are at their
23232most restrictive (<tt>InputIterator</tt>, <tt>OutputIterator</tt>), then we want
23233<tt>InputIterator::value_type</tt> to be both <tt>CopyConstructible</tt> and
23234<tt>CopyAssignable</tt> (for the most efficient implementation).  However this
23235proposed resolution only makes it clear that it is <tt>CopyConstructible</tt>,
23236and that one can assign from <tt>*<i>first</i></tt> to <tt>*<i>result</i></tt>.
23237This latter requirement does not necessarily imply that you can:
23238</p>
23239
23240<blockquote><pre>*<i>first</i> = *<i>first</i>;
23241</pre></blockquote>
23242
23243
23244<p><b>Proposed resolution:</b></p>
23245<blockquote><p>
23246-5- <i>Requires:</i> The ranges <tt>[<i>first</i>, <i>last</i>)</tt> and
23247<tt>[<i>result</i>, <i>result</i>+(<i>last</i>-<i>first</i>))</tt>
23248shall not overlap. The expression <tt>*<i>result</i> = *<i>first</i></tt>
23249shall
23250be valid. If neither <tt>InputIterator</tt> nor <tt>OutputIterator</tt> meets the
23251requirements of forward iterator then the <del>value type</del> 
23252<ins><tt>value_type</tt></ins> of <tt>InputIterator</tt>
23253must be CopyConstructible (20.1.3) <ins>and Assignable</ins>.
23254Otherwise CopyConstructible is not required.
23255</p></blockquote>
23256
23257
23258
23259
23260
23261<hr>
23262<h3><a name="540"></a>540. shared_ptr&lt;void&gt;::operator*()</h3>
23263<p><b>Section:</b> 20.8.15.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>
23264 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2005-10-15  <b>Last modified:</b> 2008-09-26</p>
23265<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>
23266<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
23267<p><b>Discussion:</b></p>
23268<p>
23269I'm trying to reconcile the note in tr.util.smartptr.shared.obs, p6
23270that talks about the operator*() member function of shared_ptr:
23271</p>
23272
23273<blockquote><p>
23274  Notes: When T is void, attempting to instantiate this member function
23275  renders the program ill-formed. [Note: Instantiating shared_ptr&lt;void&gt;
23276  does not necessarily result in instantiating this member function.
23277  --end note]
23278</p></blockquote>
23279
23280<p>
23281with the requirement in temp.inst, p1:
23282</p>
23283
23284<blockquote><p>
23285  The implicit instantiation of a class template specialization causes
23286  the implicit instantiation of the declarations, but not of the
23287  definitions...
23288</p></blockquote>
23289
23290<p>
23291I assume that what the note is really trying to say is that
23292"instantiating shared_ptr&lt;void&gt; *must not* result in instantiating
23293this member function." That is, that this function must not be
23294declared a member of shared_ptr&lt;void&gt;. Is my interpretation
23295correct?
23296</p>
23297
23298
23299<p><b>Proposed resolution:</b></p>
23300<p>
23301Change 2.2.3.5p6
23302</p>
23303
23304<blockquote><p>
23305-6- <del><i>Notes:</i></del> When <tt>T</tt> is <tt>void</tt>, <del>attempting to instantiate
23306this member function renders the program ill-formed. [<i>Note:</i>
23307Instantiating <tt>shared_ptr&lt;void&gt;</tt> does not necessarily result in
23308instantiating this member function. <i>--end note</i>]</del> <ins>it is
23309unspecified whether this member function is declared or not, and if so, what its
23310return type is, except that the declaration (although not necessarily the
23311definition) of the function shall be well-formed.</ins>
23312</p></blockquote>
23313
23314
23315
23316
23317
23318
23319<hr>
23320<h3><a name="541"></a>541. shared_ptr template assignment and void</h3>
23321<p><b>Section:</b> 20.8.15.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>
23322 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2005-10-16  <b>Last modified:</b> 2008-09-26</p>
23323<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>
23324<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
23325<p><b>Discussion:</b></p>
23326<p>
23327Is the void specialization of the template assignment operator taking
23328a shared_ptr&lt;void&gt; as an argument supposed be well-formed?
23329</p>
23330<p>
23331I.e., is this snippet well-formed:
23332</p>
23333<blockquote><pre>shared_ptr&lt;void&gt; p;
23334p.operator=&lt;void&gt;(p);
23335</pre></blockquote>
23336
23337<p>
23338Gcc complains about auto_ptr&lt;void&gt;::operator*() returning a reference
23339to void. I suspect it's because shared_ptr has two template assignment
23340operators, one of which takes auto_ptr, and the auto_ptr template gets
23341implicitly instantiated in the process of overload resolution.
23342</p>
23343
23344<p>
23345The only way I see around it is to do the same trick with auto_ptr&lt;void&gt;
23346operator*() as with the same operator in shared_ptr&lt;void&gt;.
23347</p>
23348
23349<p>
23350PS Strangely enough, the EDG front end doesn't mind the code, even
23351though in a small test case (below) I can reproduce the error with
23352it as well.
23353</p>
23354
23355<blockquote><pre>template &lt;class T&gt;
23356struct A { T&amp; operator*() { return *(T*)0; } };
23357
23358template &lt;class T&gt;
23359struct B {
23360    void operator= (const B&amp;) { }
23361    template &lt;class U&gt;
23362    void operator= (const B&lt;U&gt;&amp;) { }
23363    template &lt;class U&gt;
23364    void operator= (const A&lt;U&gt;&amp;) { }
23365};
23366
23367int main ()
23368{
23369    B&lt;void&gt; b;
23370    b.operator=&lt;void&gt;(b);
23371}
23372</pre></blockquote>
23373
23374
23375<p><b>Proposed resolution:</b></p>
23376<p>
23377In [lib.memory] change:
23378</p>
23379<blockquote><pre>template&lt;class X&gt; class auto_ptr;
23380<ins>template&lt;&gt; class auto_ptr&lt;void&gt;;</ins>
23381</pre></blockquote>
23382
23383<p>
23384In [lib.auto.ptr]/2 add the following before the last closing brace:
23385</p>
23386
23387<blockquote><pre>template&lt;&gt; class auto_ptr&lt;void&gt;
23388{
23389public:
23390    typedef void element_type;
23391};
23392</pre></blockquote>
23393
23394
23395
23396
23397
23398
23399<hr>
23400<h3><a name="542"></a>542. shared_ptr observers</h3>
23401<p><b>Section:</b> 20.8.15.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>
23402 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2005-10-18  <b>Last modified:</b> 2008-09-26</p>
23403<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>
23404<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
23405<p><b>Discussion:</b></p>
23406<p>
23407Peter Dimov wrote:
23408To: C++ libraries mailing list
23409Message c++std-lib-15614
23410[...]
23411The intent is for both use_count() and unique() to work in a threaded environment.
23412They are intrinsically prone to race conditions, but they never return garbage.
23413</p>
23414
23415<p>
23416This is a crucial piece of information that I really wish were
23417captured in the text. Having this in a non-normative note would
23418have made everything crystal clear to me and probably stopped
23419me from ever starting this discussion :) Instead, the sentence
23420in p12 "use only for debugging and testing purposes, not for
23421production code" very strongly suggests that implementations
23422can and even are encouraged to return garbage (when threads
23423are involved) for performance reasons.
23424</p>
23425<p>
23426How about adding an informative note along these lines:
23427</p>
23428<blockquote><p>
23429  Note: Implementations are encouraged to provide well-defined
23430  behavior for use_count() and unique() even in the presence of
23431  multiple threads.
23432</p></blockquote>
23433<p>
23434I don't necessarily insist on the exact wording, just that we
23435capture the intent.
23436</p>
23437
23438
23439<p><b>Proposed resolution:</b></p>
23440<p>
23441Change 20.8.15.2.5 [util.smartptr.shared.obs] p12:
23442</p>
23443<blockquote><p>
23444[<i>Note:</i> <tt>use_count()</tt> is not necessarily efficient. <del>Use only for
23445debugging and testing purposes, not for production code.</del> --<i>end note</i>]
23446</p></blockquote>
23447
23448<p>
23449Change 20.8.15.3.5 [util.smartptr.weak.obs] p3:
23450</p>
23451<blockquote><p>
23452[<i>Note:</i> <tt>use_count()</tt> is not necessarily efficient. <del>Use only for
23453debugging and testing purposes, not for production code.</del> --<i>end note</i>]
23454</p></blockquote>
23455
23456
23457
23458
23459
23460<hr>
23461<h3><a name="543"></a>543. valarray slice default constructor</h3>
23462<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>
23463 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2005-11-03  <b>Last modified:</b> 2008-09-26</p>
23464<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
23465<p><b>Discussion:</b></p>
23466<p>
23467If one explicitly constructs a slice or glice with the default
23468constructor, does the standard require this slice to have any usable
23469state?  It says "creates a slice which specifies no elements", which
23470could be interpreted two ways:
23471</p>
23472<ol>
23473<li>There are no elements to which the slice refers (i.e. undefined).</li>
23474<li>The slice specifies an array with no elements in it (i.e. defined).</li>
23475</ol>
23476<p>
23477Here is a bit of code to illustrate:
23478</p>
23479<blockquote><pre>#include &lt;iostream&gt;
23480#include &lt;valarray&gt;
23481
23482int main()
23483{
23484    std::valarray&lt;int&gt; v(10);
23485    std::valarray&lt;int&gt; v2 = v[std::slice()];
23486    std::cout &lt;&lt; "v[slice()].size() = " &lt;&lt; v2.size() &lt;&lt; '\n';
23487}
23488</pre></blockquote>
23489
23490<p>
23491Is the behavior undefined?  Or should the output be:
23492</p>
23493
23494<blockquote><pre>v[slice()].size() = 0
23495</pre></blockquote>
23496
23497<p>
23498There is a similar question and wording for gslice at 26.3.6.1p1.
23499</p>
23500
23501
23502<p><b>Proposed resolution:</b></p>
23503
23504<p><i>[Martin suggests removing the second sentence in 26.6.4.1 [cons.slice] as well.]</i></p>
23505
23506
23507<p>
23508Change 26.6.4.1 [cons.slice]:
23509</p>
23510
23511<blockquote><p>
235121 - <del>The default constructor for <tt>slice</tt> creates a <tt>slice</tt>
23513which specifies no elements.</del> <ins>The default constructor is equivalent to
23514<tt>slice(0, 0, 0)</tt>.</ins> A default constructor is provided only to permit
23515the declaration of arrays of slices. The constructor with arguments for a slice
23516takes a start, length, and stride parameter.
23517</p></blockquote>
23518
23519<p>
23520Change 26.6.6.1 [gslice.cons]:
23521</p>
23522
23523<blockquote><p>
235241 - <del>The default constructor creates a <tt>gslice</tt> which specifies no
23525elements.</del> <ins>The default constructor is equivalent to <tt>gslice(0,
23526valarray&lt;size_t&gt;(), valarray&lt;size_t&gt;())</tt>.</ins> The constructor
23527with arguments builds a <tt>gslice</tt> based on a specification of start,
23528lengths, and strides, as explained in the previous section.
23529</p></blockquote>
23530
23531
23532
23533
23534
23535
23536<hr>
23537<h3><a name="545"></a>545. When is a deleter deleted?</h3>
23538<p><b>Section:</b> 20.8.15.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>
23539 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2006-01-10  <b>Last modified:</b> 2008-09-26</p>
23540<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>
23541<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
23542<p><b>Discussion:</b></p>
23543<p>
23544The description of ~shared_ptr doesn't say when the shared_ptr's deleter, if
23545any, is destroyed. In principle there are two possibilities: it is destroyed
23546unconditionally whenever ~shared_ptr is executed (which, from an implementation
23547standpoint, means that the deleter is copied whenever the shared_ptr is copied),
23548or it is destroyed immediately after the owned pointer is destroyed (which, from
23549an implementation standpoint, means that the deleter object is shared between
23550instances). We should say which it is.
23551</p>
23552
23553
23554<p><b>Proposed resolution:</b></p>
23555<p>
23556Add after the first sentence of 20.8.15.2.11 [util.smartptr.getdeleter]/1:
23557</p>
23558<blockquote>
23559<p>
23560The returned pointer remains valid as long as there exists a <tt>shared_ptr</tt> instance
23561that owns <tt><i>d</i></tt>.
23562</p>
23563<p>
23564[<i>Note:</i> it is unspecified whether the pointer remains valid longer than that.
23565This can happen if the implementation doesn't destroy the deleter until all
23566<tt>weak_ptr</tt> instances in the ownership group are destroyed. <i>-- end note</i>]
23567</p>
23568</blockquote>
23569
23570
23571
23572
23573
23574<hr>
23575<h3><a name="550"></a>550. What should the return type of pow(float,int) be?</h3>
23576<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>
23577 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2006-01-12  <b>Last modified:</b> 2008-09-26</p>
23578<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>
23579<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
23580<p><b>Discussion:</b></p>
23581<p>
23582Assuming we adopt the
23583<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf">C
23584compatibility package from C99</a>  what should be the return type of the
23585following signature be:
23586</p>
23587<blockquote><pre>?  pow(float, int);
23588</pre></blockquote>
23589<p>
23590C++03 says that the return type should be <tt>float</tt>. 
23591<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf">
23592TR1</a> and C90/99 say the return type should be <tt>double</tt>.  This can put
23593clients into a situation where C++03 provides answers that are not as high
23594quality as C90/C99/TR1.  For example:
23595</p>
23596<blockquote><pre>#include &lt;math.h&gt;
23597
23598int main()
23599{
23600    float x = 2080703.375F;
23601    double y = pow(x, 2);
23602}
23603</pre></blockquote>
23604<p>
23605Assuming an IEEE 32 bit float and IEEE 64 bit double, C90/C99/TR1 all suggest:
23606</p>
23607
23608<blockquote><pre>y = 4329326534736.390625
23609</pre></blockquote>
23610
23611<p>
23612which is exactly right.  While C++98/C++03 demands:
23613</p>
23614
23615<blockquote><pre>y = 4329326510080.
23616</pre></blockquote>
23617
23618<p>
23619which is only approximately right.
23620</p>
23621
23622<p>
23623I recommend that C++0X adopt the mixed mode arithmetic already adopted by
23624Fortran, C and TR1 and make the return type of <tt>pow(float,int)</tt> be
23625<tt>double</tt>.
23626</p>
23627
23628<p><i>[
23629Kona (2007): Other functions that are affected by this issue include
23630<tt>ldexp</tt>, <tt>scalbln</tt>, and <tt>scalbn</tt>. We also believe that there is a typo in
2363126.7/10: <tt>float nexttoward(float, long double);</tt> [sic] should be <tt>float
23632nexttoward(float, float);</tt> Proposed Disposition: Review (the proposed
23633resolution appears above, rather than below, the heading "Proposed
23634resolution")
23635]</i></p>
23636
23637
23638<p><i>[
23639<p>
23640Howard, post Kona:
23641</p>
23642<blockquote>
23643<p>
23644Unfortunately I strongly disagree with a part of the resolution
23645from Kona.  I am moving from New to Open instead of to Review because I do not believe
23646we have consensus on the intent of the resolution.
23647</p>
23648<p>
23649This issue does not include <tt>ldexp</tt>, <tt>scalbln</tt>, and <tt>scalbn</tt> because
23650the second integral parameter in each of these signatures (from C99) is <b>not</b> a
23651<i>generic parameter</i> according to C99 7.22p2.  The corresponding C++ overloads are
23652intended (as far as I know) to correspond directly to C99's definition of <i>generic parameter</i>.
23653</p>
23654<p>
23655For similar reasons, I do not believe that the second <tt>long double</tt> parameter of
23656<tt>nexttoward</tt>, nor the return type of this function, is in error.  I believe the
23657correct signature is:
23658</p>
23659<blockquote>
23660<pre>float nexttoward(float, long double);
23661</pre>
23662</blockquote>
23663<p>
23664which is what both the C++0X working paper and C99 state (as far as I currently understand).
23665</p>
23666<p>
23667This is really <b>only</b> about <tt>pow(float, int)</tt>.  And this is because C++98 took one
23668route (with <tt>pow</tt> only) and C99 took another (with many math functions in <tt>&lt;tgmath.h&gt;</tt>.
23669The proposed resolution basically says: C++98 got it wrong and C99 got it right; let's go with C99.
23670</p>
23671</blockquote>
23672]</i></p>
23673
23674
23675<p><i>[
23676Bellevue:
23677]</i></p>
23678
23679
23680<blockquote>
23681This signature was not picked up from C99. Instead, if one types
23682pow(2.0f,2), the promotion rules will invoke "double pow(double,
23683double)", which generally gives special treatment for integral
23684exponents, preserving full accuracy of the result.  New proposed
23685wording provided.
23686</blockquote>
23687
23688
23689<p><b>Proposed resolution:</b></p>
23690<p>
23691Change 26.8 [c.math] p10:
23692</p>
23693
23694<blockquote>
23695<p>
23696The added signatures are:
23697</p>
23698<blockquote><pre>...
23699<del>float pow(float, int);</del>
23700...
23701<del>double pow(double, int);</del>
23702...
23703<del>long double pow(long double, int);</del>
23704</pre></blockquote>
23705</blockquote>
23706
23707
23708
23709
23710
23711
23712<hr>
23713<h3><a name="551"></a>551. &lt;ccomplex&gt;</h3>
23714<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>
23715 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2006-01-23  <b>Last modified:</b> 2008-09-26</p>
23716<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
23717<p><b>Discussion:</b></p>
23718<p>
23719Previously xxx.h was parsable by C++.  But in the case of C99's &lt;complex.h&gt;
23720it isn't.  Otherwise we could model it just like &lt;string.h&gt;, &lt;cstring&gt;, &lt;string&gt;:
23721</p>
23722
23723<ul>
23724<li>&lt;string&gt;   : C++ API in namespace std</li>
23725<li>&lt;cstring&gt;  : C API in namespace std</li>
23726<li>&lt;string.h&gt; : C API in global namespace</li>
23727</ul>
23728
23729<p>
23730In the case of C's complex, the C API won't compile in C++.  So we have:
23731</p>
23732
23733<ul>
23734<li>&lt;complex&gt;   : C++ API in namespace std</li>
23735<li>&lt;ccomplex&gt;  : ?</li>
23736<li>&lt;complex.h&gt; : ?</li>
23737</ul>
23738
23739<p>
23740The ? can't refer to the C API.  TR1 currently says:
23741</p>
23742
23743<ul>
23744<li>&lt;complex&gt;   : C++ API in namespace std</li>
23745<li>&lt;ccomplex&gt;  : C++ API in namespace std</li>
23746<li>&lt;complex.h&gt; : C++ API in global namespace</li>
23747</ul>
23748
23749
23750
23751<p><b>Proposed resolution:</b></p>
23752<p>
23753Change 26.3.11 [cmplxh]:
23754</p>
23755
23756<blockquote>
23757<p>
23758The header behaves as if it includes the header
23759<tt>&lt;ccomplex&gt;</tt><ins>.</ins><del>, and provides sufficient using
23760declarations to declare in the global namespace all function and type names
23761declared or defined in the neader <tt>&lt;complex&gt;</tt>.</del>
23762<ins>[<i>Note:</i> <tt>&lt;complex.h&gt;</tt> does not promote any interface
23763into the global namespace as there is no C interface to promote. <i>--end
23764note</i>]</ins>
23765</p>
23766</blockquote>
23767
23768
23769
23770
23771
23772
23773<hr>
23774<h3><a name="552"></a>552. random_shuffle and its generator</h3>
23775<p><b>Section:</b> 25.3.12 [alg.random.shuffle] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
23776 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-01-25  <b>Last modified:</b> 2008-09-26</p>
23777<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>
23778<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
23779<p><b>Discussion:</b></p>
23780<p>
23781...is specified to shuffle its range by calling swap but not how
23782(or even that) it's supposed to use the RandomNumberGenerator
23783argument passed to it.
23784</p>
23785<p>
23786Shouldn't we require that the generator object actually be used
23787by the algorithm to obtain a series of random numbers and specify
23788how many times its operator() should be invoked by the algorithm?
23789</p>
23790
23791<p>
23792See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
23793<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
23794for some further discussion.
23795</p>
23796
23797
23798
23799<p><b>Proposed resolution:</b></p>
23800<p>
23801Adopt the proposed resolution in
23802<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
23803</p>
23804
23805
23806<p><i>[
23807Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
23808The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
23809]</i></p>
23810
23811
23812
23813
23814
23815<hr>
23816<h3><a name="559"></a>559. numeric_limits&lt;const T&gt;</h3>
23817<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>
23818 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-02-19  <b>Last modified:</b> 2008-09-26</p>
23819<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>
23820<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
23821<p><b>Discussion:</b></p>
23822        <p>
23823
2382418.3.1 [limits], p2 requires implementations  to provide specializations of the
23825<code>numeric_limits</code> template for  each scalar type. While this
23826could be interepreted to include cv-qualified forms of such types such
23827an  interepretation   is  not  reflected   in  the  synopsis   of  the
23828<code>&lt;limits&gt;</code> header.
23829
23830        </p>
23831        <p>
23832
23833The absence  of specializations of the template  on cv-qualified forms
23834of  fundamental types  makes <code>numeric_limits</code>  difficult to
23835use in generic  code where the constness (or volatility)  of a type is
23836not  always  immediately  apparent.  In  such  contexts,  the  primary
23837template  ends   up  being   instantiated  instead  of   the  provided
23838specialization, typically yielding unexpected behavior.
23839
23840        </p>
23841        <p>
23842
23843Require   that  specializations   of   <code>numeric_limits</code>  on
23844cv-qualified fundamental types have the same semantics as those on the
23845unqualifed forms of the same types.
23846
23847        </p>
23848
23849
23850<p><b>Proposed resolution:</b></p>
23851        <p>
23852
23853Add  to  the   synopsis  of  the  <code>&lt;limits&gt;</code>  header,
23854immediately  below  the  declaration  of  the  primary  template,  the
23855following:
23856</p>
23857
23858<pre>
23859template &lt;class T&gt; class numeric_limits&lt;const T&gt;;
23860template &lt;class T&gt; class numeric_limits&lt;volatile T&gt;;
23861template &lt;class T&gt; class numeric_limits&lt;const volatile T&gt;;
23862
23863</pre>
23864
23865        <p>
23866
23867Add  a new paragraph  to the  end of  18.3.1.1 [numeric.limits], with  the following
23868text:
23869
23870        </p>
23871        <p>
23872
23873-new-para- The  value of each member  of a <code>numeric_limits</code>
23874specialization on a  cv-qualified T is equal to the  value of the same
23875member of <code>numeric_limits&lt;T&gt;</code>.
23876
23877        </p>
23878
23879<p><i>[
23880Portland: Martin will clarify that user-defined types get cv-specializations
23881automatically.
23882]</i></p>
23883
23884
23885
23886
23887
23888
23889
23890<hr>
23891<h3><a name="561"></a>561. inserter overly generic</h3>
23892<p><b>Section:</b> 24.5.2.6.5 [inserter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
23893 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2006-02-21  <b>Last modified:</b> 2008-09-26</p>
23894<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
23895<p><b>Discussion:</b></p>
23896<p>
23897The declaration of <tt>std::inserter</tt> is:
23898</p>
23899
23900<blockquote><pre>template &lt;class Container, class Iterator&gt;
23901insert_iterator&lt;Container&gt;
23902inserter(Container&amp; x, Iterator i);
23903</pre></blockquote>
23904
23905<p>
23906The template parameter <tt>Iterator</tt> in this function is completely unrelated
23907to the template parameter <tt>Container</tt> when it doesn't need to be.  This
23908causes the code to be overly generic.  That is, any type at all can be deduced
23909as <tt>Iterator</tt>, whether or not it makes sense.  Now the same is true of
23910<tt>Container</tt>.  However, for every free (unconstrained) template parameter
23911one has in a signature, the opportunity for a mistaken binding grows geometrically.
23912</p>
23913
23914<p>
23915It would be much better if <tt>inserter</tt> had the following signature instead:
23916</p>
23917
23918<blockquote><pre>template &lt;class Container&gt;
23919insert_iterator&lt;Container&gt;
23920inserter(Container&amp; x, typename Container::iterator i);
23921</pre></blockquote>
23922
23923<p>
23924Now there is only one free template parameter.  And the second argument to
23925<tt>inserter</tt> must be implicitly convertible to the container's iterator,
23926else the call will not be a viable overload (allowing other functions in the
23927overload set to take precedence).  Furthermore, the first parameter must have a
23928nested type named <tt>iterator</tt>, or again the binding to <tt>std::inserter</tt>
23929is not viable.  Contrast this with the current situation
23930where any type can bind to <tt>Container</tt> or <tt>Iterator</tt> and those
23931types need not be anything closely related to containers or iterators.
23932</p>
23933
23934<p>
23935This can adversely impact well written code.  Consider:
23936</p>
23937
23938<blockquote><pre>#include &lt;iterator&gt;
23939#include &lt;string&gt;
23940
23941namespace my
23942{
23943
23944template &lt;class String&gt;
23945struct my_type {};
23946
23947struct my_container
23948{
23949template &lt;class String&gt;
23950void push_back(const my_type&lt;String&gt;&amp;);
23951};
23952
23953template &lt;class String&gt;
23954void inserter(const my_type&lt;String&gt;&amp; m, my_container&amp; c) {c.push_back(m);}
23955
23956}  // my
23957
23958int main()
23959{
23960    my::my_container c;
23961    my::my_type&lt;std::string&gt; m;
23962    inserter(m, c);
23963}
23964</pre></blockquote>
23965
23966<p>
23967Today this code fails because the call to <tt>inserter</tt> binds to
23968<tt>std::inserter</tt> instead of to <tt>my::inserter</tt>.  However with the
23969proposed change <tt>std::inserter</tt> will no longer be a viable function which
23970leaves only <tt>my::inserter</tt> in the overload resolution set.  Everything
23971works as the client intends.
23972</p>
23973
23974<p>
23975To make matters a little more insidious, the above example works today if you
23976simply change the first argument to an rvalue:
23977</p>
23978
23979<blockquote><pre>    inserter(my::my_type(), c);
23980</pre></blockquote>
23981
23982<p>
23983It will also work if instantiated with some string type other than
23984<tt>std::string</tt> (or any other <tt>std</tt> type).  It will also work if
23985<tt>&lt;iterator&gt;</tt> happens to not get included.
23986</p>
23987
23988<p>
23989And it will fail again for such inocuous reaons as <tt>my_type</tt> or
23990<tt>my_container</tt> privately deriving from any <tt>std</tt> type.
23991</p>
23992
23993<p>
23994It seems unfortunate that such simple changes in the client's code can result
23995in such radically differing behavior.
23996</p>
23997
23998
23999
24000<p><b>Proposed resolution:</b></p>
24001<p>
24002Change 24.2:
24003</p>
24004
24005<blockquote><p>
24006<b>24.2 Header</b> <tt>&lt;iterator&gt;</tt> <b>synopsis</b>
24007</p>
24008<blockquote><pre>...
24009template &lt;class Container<del>, class Iterator</del>&gt;
24010   insert_iterator&lt;Container&gt; inserter(Container&amp; x, <del>Iterator</del> <ins>typename Container::iterator</ins> i);
24011...
24012</pre></blockquote>
24013</blockquote>
24014
24015<p>
24016Change 24.4.2.5:
24017</p>
24018
24019<blockquote><p>
24020<b>24.4.2.5 Class template</b> <tt>insert_iterator</tt></p>
24021<blockquote><pre>...
24022template &lt;class Container<del>, class Iterator</del>&gt;
24023   insert_iterator&lt;Container&gt; inserter(Container&amp; x, <del>Iterator</del> <ins>typename Container::iterator</ins> i);
24024...
24025</pre></blockquote>
24026</blockquote>
24027
24028<p>
24029Change 24.4.2.6.5:
24030</p>
24031
24032<blockquote>
24033<p>
24034<b>24.4.2.6.5</b> <tt>inserter</tt>
24035</p>
24036<pre>template &lt;class Container<del>, class Inserter</del>&gt;
24037   insert_iterator&lt;Container&gt; inserter(Container&amp; x, <del>Inserter</del> <ins>typename Container::iterator</ins> i);
24038</pre>
24039<blockquote><p>
24040-1- <i>Returns:</i> <tt>insert_iterator&lt;Container&gt;(x,<del>typename Container::iterator(</del>i<del>)</del>)</tt>.
24041</p></blockquote>
24042</blockquote>
24043
24044
24045
24046<p><i>[
24047Kona (2007): This issue will probably be addressed as a part of the
24048concepts overhaul of the library anyway, but the proposed resolution is
24049correct in the absence of concepts. Proposed Disposition: Ready
24050]</i></p>
24051
24052
24053
24054
24055
24056<hr>
24057<h3><a name="562"></a>562. stringbuf ctor inefficient</h3>
24058<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>
24059 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-02-23  <b>Last modified:</b> 2008-09-26</p>
24060<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>
24061<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
24062<p><b>Discussion:</b></p>
24063        <p>
24064
24065For  better efficiency,  the requirement  on the  stringbuf  ctor that
24066takes  a  string  argument  should  be  loosened  up  to  let  it  set
24067<code>epptr()</code>  beyond  just   one  past  the  last  initialized
24068character  just like  <code>overflow()</code> has  been changed  to be
24069allowed  to  do   (see  issue  432).  That  way   the  first  call  to
24070<code>sputc()</code> on  an object won't  necessarily cause a  call to
24071<code>overflow</code>. The corresponding change  should be made to the
24072string overload of the <code>str()</code> member function.
24073
24074        </p>
24075
24076
24077<p><b>Proposed resolution:</b></p>
24078        <p>
24079
24080Change 27.7.1.1, p3 of the Working Draft, N1804, as follows:
24081
24082        </p>
24083
24084<blockquote><pre>explicit basic_stringbuf(const basic_string&lt;charT,traits,Allocator&gt;&amp; <i>s<del>tr</del></i>,
24085               ios_base::openmode <i>which</i> = ios_base::in | ios_base::out);
24086</pre>
24087
24088<p>
24089-3- <i>Effects:</i>  Constructs an object of class <tt>basic_stringbuf</tt>,
24090initializing the base class with <tt>basic_streambuf()</tt>
24091(27.5.2.1), and initializing <tt><i>mode</i></tt> with <tt><i>which</i></tt>.
24092Then <ins>calls <tt>str(<i>s</i>)</tt>.</ins> <del>copies the content of
24093<i>str</i> into the <tt>basic_stringbuf</tt> underlying character
24094sequence. If <tt><i>which</i> &amp; ios_base::out</tt> is true, initializes the
24095output sequence such that <tt>pbase()</tt> points to the first underlying
24096character, <tt>epptr()</tt> points one past the last underlying character, and
24097<tt>pptr()</tt> is equal to <tt>epptr()</tt> if <tt><i>which</i> &amp; ios_base::ate</tt>
24098is true, otherwise <tt>pptr()</tt> is equal to <tt>pbase()</tt>. If
24099<tt>which &amp; ios_base::in</tt> is true, initializes the input sequence such
24100that <tt>eback()</tt> and <tt>gptr()</tt> point to the first underlying 
24101character and <tt>egptr()</tt> points one past the last underlying character.</del>
24102</p>
24103</blockquote>
24104
24105        <p>
24106
24107Change the Effects clause of the <code>str()</code> in 27.7.1.2, p2 to
24108read:
24109
24110        </p>
24111<blockquote>
24112<p>
24113-2- <i>Effects:</i> Copies the content<ins>s</ins> of <tt><i>s</i></tt> into the
24114<tt>basic_stringbuf</tt> underlying character sequence <ins>and
24115initializes the input and output sequences according to <tt><i>mode</i></tt></ins>.
24116<del>If
24117<tt><i>mode</i> &amp; ios_base::out</tt> is true, initializes the output
24118sequence such that <tt>pbase()</tt> points to the first underlying character, 
24119<tt>epptr()</tt> points one past the last underlying character, and <tt>pptr()</tt>
24120is equal to <tt>epptr()</tt> if <tt><i>mode</i> &amp; ios_base::in</tt>
24121is true, otherwise <tt>pptr()</tt> is equal to <tt>pbase()</tt>. If
24122<tt>mode &amp; ios_base::in</tt> is true, initializes the input sequence 
24123such that <tt>eback()</tt> and <tt>gptr()</tt> point to the first underlying
24124character and <tt>egptr()</tt> points one past the last underlying character.</del>
24125</p>
24126
24127        <p>
24128
24129<ins>-3- <i>Postconditions:</i>  If  <code>mode  &amp; ios_base::out</code>  is  true,
24130<code>pbase()</code>  points  to the  first  underlying character  and
24131<code>(epptr() &gt;= pbase() + s.size())</code> holds; in addition, if
24132<code>mode &amp; ios_base::in</code> is true, <code>(pptr() == pbase()
24133+ s.data())</code>  holds, otherwise <code>(pptr()  == pbase())</code>
24134is   true.    If  <code>mode   &amp;   ios_base::in</code>  is   true,
24135<code>eback()</code>  points to  the first  underlying  character, and
24136<code>(gptr()  ==  eback())</code>  and  <code>(egptr() ==  eback()  +
24137s.size())</code> hold.</ins>
24138
24139        </p>
24140</blockquote>
24141
24142
24143<p><i>[
24144Kona (2007) Moved to Ready.
24145]</i></p>
24146
24147
24148
24149
24150
24151<hr>
24152<h3><a name="563"></a>563. stringbuf seeking from end</h3>
24153<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>
24154 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-02-23  <b>Last modified:</b> 2008-09-26</p>
24155<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>
24156<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
24157<p><b>Discussion:</b></p>
24158<p>
24159According to  Table 92  (unchanged by issue  432), when  <code>(way ==
24160end)</code> the  <code>newoff</code> value in out mode  is computed as
24161the difference between <code>epptr()</code> and <code>pbase()</code>.
24162</p>
24163        <p>
24164
24165This value  isn't meaningful unless the  value of <code>epptr()</code>
24166can be  precisely controlled by a  program.  That used  to be possible
24167until  we accepted the  resolution of  issue 432,  but since  then the
24168requirements on <code>overflow()</code> have  been relaxed to allow it
24169to  make  more than  1  write  position  available (i.e.,  by  setting
24170<code>epptr()</code>     to     some     unspecified    value     past
24171<code>pptr()</code>).      So    after     the    first     call    to
24172<code>overflow()</code>  positioning the  output sequence  relative to
24173end will have unspecified results.
24174
24175        </p>
24176        <p>
24177
24178In  addition,  in <code>in|out</code>  mode,  since <code>(egptr()  ==
24179epptr())</code> need not hold, there are two different possible values
24180for   <code>newoff</code>:    <code>epptr()   -   pbase()</code>   and
24181<code>egptr() - eback()</code>.
24182
24183        </p>
24184
24185
24186<p><b>Proposed resolution:</b></p>
24187        <p>
24188
24189Change the <code>newoff</code>  column in the last row  of Table 94 to
24190read:
24191
24192        </p>
24193<blockquote><p>
24194
24195the <del>end</del> <ins>high mark</ins> pointer minus the beginning 
24196pointer (<code><del>xend</del> <ins>high_mark</ins> - xbeg</code>).
24197
24198</p></blockquote>
24199
24200
24201<p><i>[
24202Kona (2007) Moved to Ready.
24203]</i></p>
24204
24205
24206
24207
24208
24209<hr>
24210<h3><a name="564"></a>564. stringbuf seekpos underspecified</h3>
24211<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#WP">WP</a>
24212 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-02-23  <b>Last modified:</b> 2009-10-26</p>
24213<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>
24214<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
24215<p><b>Discussion:</b></p>
24216<p>
24217The   effects  of  the   <code>seekpos()</code>  member   function  of
24218<code>basic_stringbuf</code>  simply say  that the  function positions
24219the  input and/or  output  sequences  but fail  to  spell out  exactly
24220how. This is in contrast  to the detail in which <code>seekoff()</code>
24221is described.
24222</p>
24223
24224<p><i>[
242252009-07 Frankfurt
24226]</i></p>
24227
24228
24229<blockquote>
24230Move to Ready.
24231</blockquote>
24232
24233
24234
24235<p><b>Proposed resolution:</b></p>
24236        <p>
24237
24238Change 27.7.1.3, p13 to read:
24239
24240        </p>
24241<blockquote>
24242<p>
24243-13- <i>Effects:</i> <ins>Equivalent to <tt>seekoff(off_type(<i>sp</i>), ios_base::beg,
24244<i>which</i>)</tt>.</ins> <del>Alters the stream position within the controlled sequences,
24245if possible, to correspond to the stream position stored in <tt><i>sp</i></tt>
24246(as described below).</del>
24247</p>
24248<ul>
24249<li><del>If <tt>(<i>which</i> &amp; ios_base::in) != 0</tt>, positions the input sequence.</del></li>
24250<li><del>If <tt>(<i>which</i> &amp; ios_base::out) != 0</tt>, positions the output sequence.</del></li>
24251<li><del>If <tt><i>sp</i></tt> is an invalid stream position, or if the function
24252positions neither sequence, the positioning operation fails. If <tt><i>sp</i></tt>
24253has not been obtained by a previous successful call to one of the positioning
24254functions (<tt>seekoff</tt>, <tt>seekpos</tt>, <tt>tellg</tt>, <tt>tellp</tt>)
24255the effect is undefined.</del></li>
24256</ul>
24257</blockquote>
24258
24259
24260<p><i>[
24261Kona (2007): A <tt>pos_type</tt> is a position in a stream by
24262definition, so there is no ambiguity as to what it means. Proposed
24263Disposition: NAD
24264]</i></p>
24265
24266
24267<p><i>[
24268Post-Kona Martin adds:
24269I'm afraid I disagree
24270with the Kona '07 rationale for marking it NAD. The only text
24271that describes precisely what it means to position the input
24272or output sequence is in <tt>seekoff()</tt>. The <tt>seekpos()</tt> Effects
24273clause is inadequate in comparison and the proposed resolution
24274plugs the hole by specifying <tt>seekpos()</tt> in terms of <tt>seekoff()</tt>.
24275]</i></p>
24276
24277
24278
24279
24280
24281<hr>
24282<h3><a name="565"></a>565. xsputn inefficient</h3>
24283<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#WP">WP</a>
24284 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-02-23  <b>Last modified:</b> 2009-10-26</p>
24285<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
24286<p><b>Discussion:</b></p>
24287        <p>
24288
24289<tt>streambuf::xsputn()</tt>  is  specified  to  have  the  effect  of
24290"writing up to  <tt>n</tt> characters to the output  sequence as if by
24291repeated calls to <tt>sputc(c)</tt>."
24292
24293        </p>
24294        <p>
24295
24296Since  <tt>sputc()</tt> is required  to call  <tt>overflow()</tt> when
24297<tt>(pptr()    ==   epptr())</tt>    is   true,    strictly   speaking
24298<tt>xsputn()</tt>  should do  the same.   However, doing  so  would be
24299suboptimal in  some interesting cases,  such as in unbuffered  mode or
24300when the buffer is <tt>basic_stringbuf</tt>.
24301
24302        </p>
24303        <p>
24304
24305Assuming  calling <tt>overflow()</tt>  is  not really  intended to  be
24306required  and the  wording is  simply  meant to  describe the  general
24307effect of appending to the end  of the sequence it would be worthwhile
24308to  mention in  <tt>xsputn()</tt> that  the function  is  not actually
24309required to cause a call to <tt>overflow()</tt>.
24310
24311        </p>
24312
24313<p><i>[
243142009-07 Frankfurt
24315]</i></p>
24316
24317
24318<blockquote>
24319Move to Ready.
24320</blockquote>
24321
24322
24323
24324<p><b>Proposed resolution:</b></p>
24325        <p>
24326
24327Add the following sentence  to the <tt>xsputn()</tt> Effects clause in
2432827.5.2.4.5, p1 (N1804):
24329
24330        </p>
24331        <blockquote>    
24332            <p>
24333-1- <i>Effects:</i> Writes up to <tt><i>n</i></tt> characters to the output
24334sequence as if by repeated calls to <tt>sputc(<i>c</i>)</tt>. The characters 
24335written are obtained from successive elements of the array whose first element
24336is designated by <tt><i>s</i></tt>. Writing stops when either <tt><i>n</i></tt>
24337characters have been written or a call to <tt>sputc(<i>c</i>)</tt> would return
24338<tt>traits::eof()</tt>. <ins>It is  uspecified whether the function  calls
24339<tt>overflow()</tt> when <tt>(pptr() ==  epptr())</tt> becomes true or whether
24340it achieves the same effects by other means.</ins>
24341            </p>
24342        </blockquote>    
24343        <p>
24344
24345In addition,  I suggest to  add a footnote  to this function  with the
24346same text as Footnote 292 to  make it extra clear that derived classes
24347are permitted to override <tt>xsputn()</tt> for efficiency.
24348
24349        </p>
24350
24351
24352<p><i>[
24353Kona (2007): We want to permit a <tt>streambuf</tt> that streams output directly
24354to a device without making calls to <tt>sputc</tt> or <tt>overflow</tt>. We believe that
24355has always been the intention of the committee. We believe that the
24356proposed wording doesn't accomplish that. Proposed Disposition: Open
24357]</i></p>
24358
24359
24360
24361
24362
24363<hr>
24364<h3><a name="566"></a>566. array forms of unformatted input function undefined for zero-element arrays</h3>
24365<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>
24366 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-02-23  <b>Last modified:</b> 2008-09-26</p>
24367<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>
24368<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
24369<p><b>Discussion:</b></p>
24370        <p>
24371
24372The array forms of unformatted input functions don't have well-defined
24373semantics for zero-element  arrays in a couple of  cases. The affected
24374ones (<tt>istream::get()</tt> and  <tt>getline()</tt>) are supposed to
24375terminate when <tt>(n - 1)</tt> characters are stored, which obviously
24376can never be true when <tt>(n == 0)</tt> to start with.
24377
24378        </p>
24379
24380
24381<p><b>Proposed resolution:</b></p>
24382        <p>
24383
24384I  propose  the following  changes  (references  are  relative to  the
24385Working Draft (document N1804).
24386
24387        </p>
24388        <p>
24389
24390Change 27.6.1.3, p8 (<tt>istream::get()</tt>), bullet 1 as follows:
24391
24392        </p>
24393        <blockquote>
24394            <p>
24395
24396<ins>if  <tt>(n  &lt; 1)</tt>  is  true  or  </ins> <tt>(n  -  1)</tt>
24397characters are stored;
24398
24399            </p>
24400        </blockquote>
24401        <p>
24402
24403Similarly, change  27.6.1.3, p18 (<tt>istream::getline()</tt>), bullet
244043 as follows:
24405
24406        </p>
24407        <blockquote>
24408            <p>
24409
24410<ins><tt>(n &lt; 1)</tt> is  true or </ins><tt>(n - 1)</tt> characters
24411are     stored     (in    which     case     the    function     calls
24412<tt>setstate(failbit)</tt>).
24413
24414            </p>
24415        </blockquote>
24416        <p>
24417
24418Finally, change p21 as follows:
24419
24420        </p>
24421        <blockquote>
24422            <p>
24423
24424In any  case, <ins>provided  <tt>(n &gt; 0)</tt>  is true,  </ins>it then
24425stores  a null  character  (using charT())  into  the next  successive
24426location of the array.
24427
24428            </p>
24429        </blockquote>
24430
24431
24432
24433
24434
24435<hr>
24436<h3><a name="567"></a>567. streambuf inserter and extractor should be unformatted</h3>
24437<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>
24438 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-02-25  <b>Last modified:</b> 2008-09-26</p>
24439<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>
24440<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
24441<p><b>Discussion:</b></p>
24442        <p>
24443
24444Issue  60 explicitly made  the extractor  and inserter  operators that
24445take a  <tt>basic_streambuf*</tt> argument formatted  input and output
24446functions,  respectively.  I  believe that's  wrong, certainly  in the
24447case of  the extractor, since formatted functions  begin by extracting
24448and  discarding  whitespace.  The  extractor  should  not discard  any
24449characters.
24450
24451        </p>
24452
24453
24454<p><b>Proposed resolution:</b></p>
24455        <p>
24456
24457I propose to  change each operator to behave  as unformatted input and
24458output function,  respectively. The changes below are  relative to the
24459working draft document number N1804.
24460
24461        </p>
24462        <p>
24463
24464Specifically, change 27.6.1.2.3, p14 as follows:
24465
24466        </p>
24467
24468            <blockquote>
24469        <p>
24470
24471<i>Effects</i>:  Behaves as  a<ins>n un</ins>formatted  input function
24472(as   described   in   <del>27.6.1.2.1</del><ins>27.6.1.3,   paragraph
244731</ins>).
24474
24475        </p>
24476            </blockquote>
24477        <p>
24478
24479And change 27.6.2.5.3, p7 as follows:
24480
24481        </p>
24482
24483            <blockquote>
24484        <p>
24485
24486<i>Effects</i>: Behaves  as a<ins>n un</ins>formatted  output function
24487(as   described   in   <del>27.6.2.5.1</del><ins>27.6.2.6,   paragraph
244881</ins>).
24489
24490        </p>
24491            </blockquote>
24492
24493
24494<p><i>[
24495Kona (2007): Proposed Disposition: Ready
24496]</i></p>
24497
24498
24499
24500
24501
24502<hr>
24503<h3><a name="574"></a>574. DR 369 Contradicts Text</h3>
24504<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>
24505 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2006-04-18  <b>Last modified:</b> 2008-09-26</p>
24506<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>
24507<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
24508<p><b>Discussion:</b></p>
24509<p>
24510lib.iostream.objects requires that the standard stream objects are never
24511destroyed, and it requires that they be destroyed.
24512</p>
24513<p>
24514DR 369 adds words to say that we really mean for ios_base::Init objects to force
24515construction of standard stream objects. It ends, though, with the phrase "these
24516stream objects shall be destroyed after the destruction of dynamically ...".
24517However, the rule for destruction is stated in the standard: "The objects are
24518not destroyed during program execution."
24519</p>
24520
24521
24522<p><b>Proposed resolution:</b></p>
24523<p>
24524Change 27.4 [iostream.objects]/1:
24525</p>
24526
24527<blockquote>
24528<p>
24529-2- The objects are constructed and the associations are established at
24530some time prior to or during the first time an object of class
24531<tt>ios_base::Init</tt> is constructed, and in any case before the body of main
24532begins execution.<sup>290)</sup> The objects are not destroyed during program
24533execution.<sup>291)</sup> If a translation unit includes <tt>&lt;iostream&amp;t;</tt> or explicitly
24534constructs an <tt>ios_base::Init</tt> object, these stream objects shall be
24535constructed before dynamic initialization of non-local objects defined
24536later in that translation unit<del>, and these stream objects shall be
24537destroyed after the destruction of dynamically initialized non-local
24538objects defined later in that translation unit</del>.
24539</p>
24540</blockquote>
24541
24542
24543<p><i>[
24544Kona (2007): From 27.4 [iostream.objects]/2, strike the words "...and these stream objects
24545shall be destroyed after the destruction of dynamically initialized
24546non-local objects defined later in that translation unit." Proposed
24547Disposition: Review
24548]</i></p>
24549
24550
24551
24552
24553
24554<hr>
24555<h3><a name="575"></a>575. the specification of ~shared_ptr is MT-unfriendly, makes implementation assumptions</h3>
24556<p><b>Section:</b> 20.8.15.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>
24557 <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2006-04-23  <b>Last modified:</b> 2008-09-26</p>
24558<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>
24559<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
24560<p><b>Discussion:</b></p>
24561<p>
24562[tr.util.smartptr.shared.dest] says in its second bullet:
24563</p>
24564
24565<p>
24566"If *this shares ownership with another shared_ptr instance (use_count() &gt; 1),
24567decrements that instance's use count."
24568</p>
24569
24570<p>
24571The problem with this formulation is that it presupposes the existence of an
24572"use count" variable that can be decremented and that is part of the state of a
24573shared_ptr instance (because of the "that instance's use count".)
24574</p>
24575
24576<p>
24577This is contrary to the spirit of the rest of the specification that carefully
24578avoids to require an use count variable. Instead, use_count() is specified to
24579return a value, a number of instances.
24580</p>
24581
24582<p>
24583In multithreaded code, the usual implicit assumption is that a shared variable
24584should not be accessed by more than one thread without explicit synchronization,
24585and by introducing the concept of an "use count" variable, the current wording
24586implies that two shared_ptr instances that share ownership cannot be destroyed
24587simultaneously.
24588</p>
24589
24590<p>
24591In addition, if we allow the interpretation that an use count variable is part
24592of shared_ptr's state, this would lead to other undesirable consequences WRT
24593multiple threads. For example,
24594</p>
24595
24596<blockquote><pre>p1 = p2;
24597</pre></blockquote>
24598
24599<p>
24600would now visibly modify the state of p2, a "write" operation, requiring a lock.
24601</p>
24602
24603
24604<p><b>Proposed resolution:</b></p>
24605<p>
24606Change the first two bullets of [lib.util.smartptr.shared.dest]/1 to:
24607</p>
24608
24609<blockquote>
24610<ul>
24611<li>If <tt>*this</tt> is <i>empty</i> <ins>or shares ownership with another
24612<tt>shared_ptr</tt> instance (<tt>use_count() &gt; 1</tt>)</ins>, there are no side effects.</li>
24613<li><del>If <tt>*this</tt> <i>shares ownership</i> with another <tt>shared_ptr</tt> instance
24614(<tt>use_count() &gt; 1</tt>), decrements that instance's use count.</del></li>
24615</ul>
24616</blockquote>
24617
24618<p>
24619Add the following paragraph after [lib.util.smartptr.shared.dest]/1:
24620</p>
24621
24622<blockquote><p>
24623[<i>Note:</i> since the destruction of <tt>*this</tt> decreases the number of instances in
24624<tt>*this</tt>'s ownership group by one, all <tt>shared_ptr</tt> instances that share ownership
24625with <tt>*this</tt> will report an <tt>use_count()</tt> that is one lower than its previous value
24626after <tt>*this</tt> is destroyed. <i>--end note</i>]
24627</p></blockquote>
24628
24629
24630
24631
24632
24633<hr>
24634<h3><a name="576"></a>576. find_first_of is overconstrained</h3>
24635<p><b>Section:</b> 25.2.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>
24636 <b>Submitter:</b> Doug Gregor <b>Opened:</b> 2006-04-25  <b>Last modified:</b> 2008-09-26</p>
24637<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>
24638<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
24639<p><b>Discussion:</b></p>
24640<p>
24641In 25.1.4 Find First [lib.alg.find.first], the two iterator type parameters to
24642find_first_of are specified to require Forward Iterators, as follows:
24643</p>
24644
24645<blockquote><pre>template&lt;class ForwardIterator1, class ForwardIterator2&gt;
24646  ForwardIterator1
24647  find_first_of(ForwardIterator1 first1, ForwardIterator1 last1,
24648                        ForwardIterator2 first2, ForwardIterator2 last2);
24649template&lt;class ForwardIterator1, class ForwardIterator2,
24650                  class BinaryPredicate&gt;
24651ForwardIterator1
24652  find_first_of(ForwardIterator1 first1, ForwardIterator1 last1,
24653                         ForwardIterator2 first2, ForwardIterator2 last2,
24654                        BinaryPredicate pred);
24655</pre></blockquote>
24656
24657<p>
24658However, ForwardIterator1 need not actually be a Forward Iterator; an Input
24659Iterator suffices, because we do not need the multi-pass property of the Forward
24660Iterator or a true reference.
24661</p>
24662
24663
24664<p><b>Proposed resolution:</b></p>
24665<p>
24666Change the declarations of <tt>find_first_of</tt> to:
24667</p>
24668
24669<blockquote><pre>template&lt;class <del>ForwardIterator1</del><ins>InputIterator1</ins>, class ForwardIterator2&gt;
24670  <del>ForwardIterator1</del><ins>InputIterator1</ins>
24671  find_first_of(<del>ForwardIterator1</del><ins>InputIterator1</ins> first1, <del>ForwardIterator1</del><ins>InputIterator1</ins> last1,
24672                        ForwardIterator2 first2, ForwardIterator2 last2);
24673template&lt;class <del>ForwardIterator1</del><ins>InputIterator1</ins>, class ForwardIterator2,
24674                  class BinaryPredicate&gt;
24675<del>ForwardIterator1</del><ins>InputIterator1</ins>
24676  find_first_of(<del>ForwardIterator1</del><ins>InputIterator1</ins> first1, <del>ForwardIterator1</del><ins>InputIterator1</ins> last1,
24677                         ForwardIterator2 first2, ForwardIterator2 last2,
24678                        BinaryPredicate pred);
24679</pre></blockquote>
24680
24681
24682
24683
24684
24685
24686<hr>
24687<h3><a name="577"></a>577. upper_bound(first, last, ...) cannot return last</h3>
24688<p><b>Section:</b> 25.4.3.2 [upper.bound] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
24689 <b>Submitter:</b> Seungbeom Kim <b>Opened:</b> 2006-05-03  <b>Last modified:</b> 2008-09-26</p>
24690<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
24691<p><b>Discussion:</b></p>
24692<p>
24693ISO/IEC 14882:2003 says:
24694</p>
24695
24696<blockquote>
24697<p>
2469825.3.3.2 upper_bound
24699</p>
24700<p>
24701<i>Returns:</i> The furthermost iterator <tt>i</tt> in the range
24702<tt>[<i>first</i>, <i>last</i>)</tt> such that
24703for any iterator <tt>j</tt> in the range <tt>[<i>first</i>, i)</tt> the following corresponding
24704conditions hold: <tt>!(value &lt; *j)</tt> or <tt><i>comp</i>(<i>value</i>, *j) == false</tt>.
24705</p>
24706</blockquote>
24707
24708<p>
24709From the description above, upper_bound cannot return last, since it's
24710not in the interval [first, last). This seems to be a typo, because if
24711value is greater than or equal to any other values in the range, or if
24712the range is empty, returning last seems to be the intended behaviour.
24713The corresponding interval for lower_bound is also [first, last].
24714</p>
24715
24716
24717<p><b>Proposed resolution:</b></p>
24718<p>
24719Change [lib.upper.bound]:
24720</p>
24721
24722<blockquote>
24723<p>
24724<i>Returns:</i> The furthermost iterator <tt>i</tt> in the range
24725<tt>[<i>first</i>, <i>last</i><del>)</del><ins>]</ins></tt> such that
24726for any iterator <tt>j</tt> in the range <tt>[<i>first</i>, i)</tt> the following corresponding
24727conditions hold: <tt>!(value &lt; *j)</tt> or <tt><i>comp</i>(<i>value</i>, *j) == false</tt>.
24728</p>
24729</blockquote>
24730
24731
24732
24733
24734
24735
24736<hr>
24737<h3><a name="578"></a>578. purpose of hint to allocator::allocate()</h3>
24738<p><b>Section:</b> 20.8.8.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
24739 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-05-17  <b>Last modified:</b> 2008-09-26</p>
24740<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>
24741<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
24742<p><b>Discussion:</b></p>
24743        <p>
24744
24745The     description    of     the     allocator    member     function
24746<code>allocate()</code>  requires  that  the <i>hint</i>  argument  be
24747either 0 or a  value previously returned from <code>allocate()</code>.
24748Footnote 227 further suggests that  containers may pass the address of
24749an adjacent element as this argument.
24750
24751        </p>
24752        <p>
24753
24754I  believe  that  either  the  footnote  is  wrong  or  the  normative
24755requirement that  the argument be  a value previously returned  from a
24756call to  <code>allocate()</code> is wrong. The latter  is supported by
24757the resolution  to issue 20-004 proposed in  c++std-lib-3736 by Nathan
24758Myers. In addition,  the <i>hint</i> is an ordinary  void* and not the
24759<code>pointer</code>  type returned  by  <code>allocate()</code>, with
24760the  two  types potentially  being  incompatible  and the  requirement
24761impossible to satisfy.
24762
24763        </p>
24764        <p>
24765
24766See also c++std-lib-14323 for some  more context on where this came up
24767(again).
24768
24769        </p>
24770    
24771
24772    <p><b>Proposed resolution:</b></p>
24773        <p>
24774
24775Remove  the requirement  in  20.6.1.1, p4  that  the hint  be a  value
24776previously returned from <code>allocate()</code>. Specifically, change
24777the paragraph as follows:
24778
24779        </p>
24780<p>
24781<del><i>Requires</i>: <i>hint</i> either 0 or previously obtained  from  member
24782<code>allocate</code>  and  not  yet passed  to member  <code>deallocate</code>.
24783The value hint may be used by an implementation to help improve performance
24784<sup>223)</sup>.</del> <ins>[<i>Note:</i> The value <i>hint</i> may be used by an
24785implementation to help improve performance. -- <i>end note</i>]</ins>
24786</p>
24787<blockquote><p>
24788<del>[Footnote: <sup>223)</sup>In a container member function, the address of an
24789adjacent element is often a good choice to pass for this argument.</del>
24790</p></blockquote>
24791    
24792
24793
24794
24795<hr>
24796<h3><a name="581"></a>581. <code>flush()</code> not unformatted function</h3>
24797<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>
24798 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-06-14  <b>Last modified:</b> 2008-09-26</p>
24799<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>
24800<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
24801<p><b>Discussion:</b></p>
24802        <p>
24803
24804The resolution of issue 60 changed <code>basic_ostream::flush()</code>
24805so as not  to require it to behave as  an unformatted output function.
24806That has at least two in my opinion problematic consequences:
24807
24808        </p>
24809        <p>
24810
24811First, <code>flush()</code>  now calls <code>rdbuf()-&gt;pubsync()</code>
24812unconditionally, without  regard to the  state of the stream.  I can't
24813think of any reason why <code>flush()</code> should behave differently
24814from the vast majority of stream functions in this respect.
24815
24816        </p>
24817        <p>
24818
24819Second, <code>flush()</code> is not  required to catch exceptions from
24820<code>pubsync()</code> or set  <code>badbit</code> in response to such
24821events. That doesn't seem right either, as most other stream functions
24822do so.
24823
24824        </p>
24825    
24826
24827    <p><b>Proposed resolution:</b></p>
24828        <p>
24829
24830I  propose  to revert  the  resolution of  issue  60  with respect  to
24831<code>flush()</code>. Specifically,  I propose to  change 27.6.2.6, p7
24832as follows:
24833
24834        </p>
24835
24836<p>
24837Effects: <ins>Behaves as an  unformatted output function (as described
24838in 27.6.2.6, paragraph 1). </ins>If <code>rdbuf()</code> is not a null
24839pointer,  <ins>constructs a  sentry  object.  If  this object  returns
24840<code>true</code> when converted to a  value of type bool the function
24841</ins>calls <code>rdbuf()-&gt;pubsync()</code>.  If that function returns
24842-1    calls    <code>setstate(badbit)</code>    (which    may    throw
24843<code>ios_base::failure</code>  (27.4.4.3)).   <ins>Otherwise, if  the
24844sentry object returns <code>false</code>, does nothing.</ins><del>Does
24845not  behave  as  an  unformatted  output  function  (as  described  in
2484627.6.2.6, paragraph 1).</del>
24847</p>
24848
24849    
24850
24851<p><i>[
24852Kona (2007): Proposed Disposition: Ready
24853]</i></p>
24854
24855
24856
24857
24858
24859<hr>
24860<h3><a name="586"></a>586. string inserter not a formatted function</h3>
24861<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>
24862 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-06-22  <b>Last modified:</b> 2008-09-26</p>
24863<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>
24864<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
24865<p><b>Discussion:</b></p>
24866        <p>
24867
24868Section  and paragraph  numbers  in  this paper  are  relative to  the
24869working draft document number N2009 from 4/21/2006.
24870
24871        </p>
24872
24873        <p>
24874
24875The  <code>basic_string</code> extractor  in 21.3.7.9,  p1  is clearly
24876required  to  behave  as  a   formatted  input  function,  as  is  the
24877<code>std::getline()</code> overload for string described in p7.
24878
24879        </p>
24880        <p>
24881
24882However, the <code>basic_string</code> inserter described in p5 of the
24883same section has no such requirement. This has implications on how the
24884operator  responds  to  exceptions thrown  from  <code>xsputn()</code>
24885(formatted  output functions are  required to  set <code>badbit</code>
24886and swallow  the exception unless  <code>badbit</code> is also  set in
24887<code>exceptions()</code>; the  string inserter doesn't  have any such
24888requirement).
24889
24890        </p>
24891        <p>
24892
24893I don't  see anything in the  spec for the string  inserter that would
24894justify requiring  it to treat  exceptions differently from  all other
24895similar operators. (If it did, I think it should be made this explicit
24896by saying  that the  operator "does not  behave as a  formatted output
24897function" as has been made customary by the adoption of the resolution
24898of issue 60).
24899
24900        </p>
24901    
24902
24903    <p><b>Proposed resolution:</b></p>
24904        <p>
24905
24906I propose to change the Effects clause in 21.3.7.9, p5, as follows:
24907
24908        </p>
24909            <blockquote>
24910        <p>
24911
24912<i>Effects</i>: <del>Begins by constructing a  sentry object k as if k
24913were    constructed    by    typename    <code>basic_ostream&lt;charT,
24914traits&gt;::sentry   k   (os)</code>.    If  <code>bool(k)</code>   is
24915<code>true</code>, </del><ins>Behaves  as a formatted  output function
24916(27.6.2.5.1).   After constructing  a  <code>sentry</code> object,  if
24917this  object returns <code>true</code>  when converted  to a  value of
24918type   <code>bool</code>,   determines   padding   as   described   in
2491922.2.2.2.2</ins>,  then inserts the  resulting sequence  of characters
24920<code><i>seq</i></code> as if by calling <code>os.rdbuf()-&gt;sputn(seq ,
24921n)</code>,    where   <code><i>n</i></code>    is   the    larger   of
24922<code>os.width()</code>   and   <code>str.size()</code>;  then   calls
24923<code>os.width(0)</code>.  <del>If  the  call  to sputn  fails,  calls
24924<code>os.setstate(ios_base::failbit)</code>.</del>
24925
24926        </p>
24927            </blockquote>
24928        <p>
24929
24930This proposed  resilution assumes the  resolution of issue  394 (i.e.,
24931that   all   formatted   output   functions  are   required   to   set
24932<code>ios_base::badbit</code>  in response  to any  kind  of streambuf
24933failure),   and   implicitly   assumes   that  a   return   value   of
24934<code>sputn(seq,  <i>n</i>)</code>  other  than  <code><i>n</i></code>
24935indicates a failure.
24936
24937        </p>
24938    
24939
24940
24941
24942<hr>
24943<h3><a name="589"></a>589. Requirements on iterators of member template functions of containers</h3>
24944<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>
24945 <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2006-08-02  <b>Last modified:</b> 2008-09-26</p>
24946<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>
24947<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>
24948<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
24949<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a></p>
24950<p><b>Discussion:</b></p>
24951<p>
24952There appears to be no requirements on the InputIterators used in sequences in 23.1.1 in
24953terms of their value_type, and the requirements in 23.1.2 appear to be overly strict
24954(requires InputIterator::value_type be the same type as the container's value_type).
24955</p>
24956
24957
24958<p><b>Proposed resolution:</b></p>
24959<p>
24960Change 23.1.1 p3:
24961</p>
24962
24963<blockquote><p>
24964In Tables 82 and 83, <tt>X</tt> denotes a sequence class, <tt>a</tt> denotes a
24965value of <tt>X</tt>, <tt>i</tt> and <tt>j</tt> denote iterators satisfying input
24966iterator requirements <ins>and refer to elements <ins>implicitly
24967convertible to</ins> <tt>value_type</tt></ins>, <tt>[i, j)</tt> denotes a valid
24968range, <tt>n</tt> denotes a value of <tt>X::size_type</tt>, <tt>p</tt> denotes a
24969valid iterator to <tt>a</tt>, <tt>q</tt> denotes a valid dereferenceable
24970iterator to <tt>a</tt>, <tt>[q1, q2)</tt> denotes a valid range in <tt>a</tt>,
24971and <tt>t</tt> denotes a value of <tt>X::value_type</tt>.
24972</p></blockquote>
24973
24974<p>
24975Change 23.1.2 p7:
24976</p>
24977
24978<blockquote><p>
24979In Table 84, <tt>X</tt> is an associative container class, <tt>a</tt> is a value
24980of <tt>X</tt>, <tt>a_uniq</tt> is a value of <tt>X</tt> when <tt>X</tt> supports
24981unique keys, and <tt>a_eq</tt> is a value of <tt>X</tt> when <tt>X</tt> supports
24982multiple keys, <tt>i</tt> and <tt>j</tt> satisfy input iterator requirements and
24983refer to elements <del>of</del> <ins>implicitly convertible to</ins>
24984<tt>value_type</tt>, <tt>[i, j)</tt> is a valid range, <tt>p</tt> is a valid
24985iterator to <tt>a</tt>, <tt>q</tt> is a valid dereferenceable iterator to
24986<tt>a</tt>, <tt>[q1, q2)</tt> is a valid range in <tt>a</tt>, <tt>t</tt> is a
24987value of <tt>X::value_type</tt>, <tt>k</tt> is a value of <tt>X::key_type</tt>
24988and <tt>c</tt> is a value of type <tt>X::key_compare</tt>.
24989</p></blockquote>
24990
24991
24992
24993<p><b>Rationale:</b></p>
24994<p>
24995Concepts will probably come in and rewrite this section anyway.  But just in case it is
24996easy to fix this up as a safety net and as a clear statement of intent.
24997</p>
24998
24999
25000
25001
25002
25003<hr>
25004<h3><a name="593"></a>593. __STDC_CONSTANT_MACROS</h3>
25005<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>
25006 <b>Submitter:</b> Walter Brown <b>Opened:</b> 2006-08-28  <b>Last modified:</b> 2008-09-26</p>
25007<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>
25008<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
25009<p><b>Discussion:</b></p>
25010<p>
25011Clause 18.3 of the current Working Paper (N2009) deals with the new C++ headers
25012&lt;cstdint&gt; and &lt;stdint.h&gt;.  These are of course based on the C99 header
25013&lt;stdint.h&gt;, and were part of TR1.
25014</p>
25015
25016<p>
25017Per 18.3.1/1, these headers define a number of macros and function macros. 
25018While the WP does not mention __STDC_CONSTANT_MACROS in this context, C99
25019footnotes do mention __STDC_CONSTANT_MACROS.  Further, 18.3.1/2 states that "The
25020header defines all ... macros the same as C99 subclause 7.18."
25021</p>
25022
25023<p>
25024Therefore, if I wish to have the above-referenced macros and function macros
25025defined, must I #define __STDC_CONSTANT_MACROS before I #include &lt;cstdint&gt;, or
25026does the C++ header define these macros/function macros unconditionally?
25027</p>
25028
25029
25030<p><b>Proposed resolution:</b></p>
25031<p>
25032To put this issue to rest for C++0X, I propose the following addition to 
2503318.3.1/2 of the Working Paper N2009:
25034</p>
25035
25036<blockquote><p>
25037[Note: The macros defined by &lt;cstdint&gt; are provided unconditionally: in
25038particular, the symbols __STDC_LIMIT_MACROS and __STDC_CONSTANT_MACROS
25039(mentioned in C99 footnotes 219, 220, and 222) play no role in C++. --end note]
25040</p></blockquote>
25041
25042
25043
25044
25045
25046<hr>
25047<h3><a name="595"></a>595. TR1/C++0x: fabs(complex&lt;T&gt;) redundant / wrongly specified</h3>
25048<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>
25049 <b>Submitter:</b> Stefan Gro�e Pawig <b>Opened:</b> 2006-09-24  <b>Last modified:</b> 2009-03-21</p>
25050<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>
25051<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
25052<p><b>Discussion:</b></p>
25053<p>
25054TR1 introduced, in the C compatibility chapter, the function
25055fabs(complex&lt;T&gt;):
25056</p>
25057<blockquote><pre>----- SNIP -----
250588.1.1 Synopsis                                [tr.c99.cmplx.syn]
25059
25060  namespace std {
25061  namespace tr1 {
25062[...]
25063  template&lt;class T&gt; complex&lt;T&gt; fabs(const complex&lt;T&gt;&amp; x);
25064  } // namespace tr1
25065  } // namespace std
25066
25067[...]
25068
250698.1.8 Function fabs                          [tr.c99.cmplx.fabs]
25070
250711 Effects: Behaves the same as C99 function cabs, defined in
25072  subclause 7.3.8.1.
25073----- SNIP -----
25074</pre></blockquote>
25075
25076<p>
25077The current C++0X draft document (n2009.pdf) adopted this
25078definition in chapter 26.3.1 (under the comment // 26.3.7 values)
25079and 26.3.7/7.
25080</p>
25081<p>
25082But in C99 (ISO/IEC 9899:1999 as well as the 9899:TC2 draft document
25083n1124), the referenced subclause reads
25084</p>
25085
25086<blockquote><pre>----- SNIP -----
250877.3.8.1 The cabs functions
25088
25089  Synopsis
25090
250911 #include &lt;complex.h&gt;
25092  double cabs(double complex z);
25093  float cabsf(float complex z);
25094  long double cabsl(long double z);
25095
25096  Description
25097
250982 The cabs functions compute the complex absolute value (also called
25099  norm, modulus, or magnitude) of z.
25100
25101  Returns
25102
251033 The cabs functions return the complex absolute value.
25104----- SNIP -----
25105</pre></blockquote>
25106
25107<p>
25108Note that the return type of the cabs*() functions is not a complex
25109type.  Thus, they are equivalent to the already well established
25110  template&lt;class T&gt; T abs(const complex&lt;T&gt;&amp; x);
25111(26.2.7/2 in ISO/IEC 14882:1998, 26.3.7/2 in the current draft
25112document n2009.pdf).
25113</p>
25114<p>
25115So either the return value of fabs() is specified wrongly, or fabs()
25116does not behave the same as C99's cabs*().
25117</p>
25118
25119<b>Possible Resolutions</b>
25120
25121<p>
25122This depends on the intention behind the introduction of fabs().
25123</p>
25124<p>
25125If the intention was to provide a /complex/ valued function that
25126calculates the magnitude of its argument, this should be
25127explicitly specified.  In TR1, the categorization under "C
25128compatibility" is definitely wrong, since C99 does not provide
25129such a complex valued function.
25130</p>
25131<p>
25132Also, it remains questionable if such a complex valued function
25133is really needed, since complex&lt;T&gt; supports construction and
25134assignment from real valued arguments.  There is no difference
25135in observable behaviour between
25136</p>
25137<blockquote><pre>  complex&lt;double&gt; x, y;
25138  y = fabs(x);
25139  complex&lt;double&gt; z(fabs(x));
25140</pre></blockquote>
25141<p>
25142and
25143</p>
25144<blockquote><pre>  complex&lt;double&gt; x, y;
25145  y = abs(x);
25146  complex&lt;double&gt; z(abs(x));
25147</pre></blockquote>
25148<p>
25149If on the other hand the intention was to provide the intended
25150functionality of C99, fabs() should be either declared deprecated
25151or (for C++0X) removed from the standard, since the functionality
25152is already provided by the corresponding overloads of abs().
25153</p>
25154
25155<p><i>[
25156Bellevue:
25157]</i></p>
25158
25159
25160<blockquote>
25161Bill believes that abs() is a suitable overload. We should remove fabs().
25162</blockquote>
25163
25164
25165<p><b>Proposed resolution:</b></p>
25166
25167<p>
25168Change the synopsis in 26.4.1 [complex.syn]:
25169</p>
25170
25171<blockquote><pre><del>template&lt;class T&gt; complex&lt;T&gt; fabs(const complex&lt;T&gt;&amp;);</del>
25172</pre></blockquote>
25173
25174<p>
25175Remove 26.4.7 [complex.value.ops], p7:
25176</p>
25177
25178<blockquote>
25179<pre><del>template&lt;class T&gt; complex&lt;T&gt; fabs(const complex&lt;T&gt;&amp; <i>x</i>);</del>
25180</pre>
25181<blockquote>
25182<p>
25183<del>-7- <i>Effects:</i> Behaves the same as C99 function <tt>cabs</tt>, defined in subclause 7.3.8.1.</del>
25184</p>
25185</blockquote>
25186</blockquote>
25187
25188
25189
25190<p><i>[
25191Kona (2007): Change the return type of <tt>fabs(complex)</tt> to <tt>T</tt>. 
25192Proposed Disposition: Ready
25193]</i></p>
25194
25195
25196
25197
25198
25199<hr>
25200<h3><a name="596"></a>596. 27.8.1.3 Table 112 omits "a+" and "a+b" modes</h3>
25201<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>
25202 <b>Submitter:</b> Thomas Plum <b>Opened:</b> 2006-09-26  <b>Last modified:</b> 2008-09-26</p>
25203<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>
25204<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
25205<p><b>Discussion:</b></p>
25206<p>
25207In testing 27.9.1.4 [filebuf.members], Table 112 (in the latest N2009 draft), we invoke  
25208</p>
25209<blockquote><pre>   ostr.open("somename", ios_base::out | ios_base::in | ios_base::app)
25210</pre></blockquote>
25211<p>
25212and we expect the open to fail, because out|in|app is not listed in
25213Table 92, and just before the table we see very specific words:
25214</p>
25215<blockquote><p>
25216  If mode is not some combination of flags shown in the table 
25217  then the open fails.
25218</p></blockquote>
25219<p>
25220But the corresponding table in the C standard, 7.19.5.3, provides two
25221modes "a+" and "a+b", to which the C++ modes out|in|app and
25222out|in|app|binary would presumably apply.
25223</p>
25224<p>
25225We would like to argue that the intent of Table 112 was to match the
25226semantics of 7.19.5.3 and that the omission of "a+" and "a+b" was
25227unintentional.  (Otherwise there would be valid and useful behaviors
25228available in C file I/O which are unavailable using C++, for no
25229valid functional reason.)
25230</p>
25231<p>
25232We further request that the missing modes be explicitly restored to
25233the WP, for inclusion in C++0x.
25234</p>
25235
25236<p><i>[
25237Martin adds:
25238]</i></p>
25239
25240
25241<p>
25242...besides "a+" and "a+b" the C++ table is also missing a row
25243for a lone app bit which in at least two current implementation
25244as well as in Classic Iostreams corresponds to the C stdio "a"
25245mode and has been traditionally documented as implying ios::out.
25246Which means the table should also have a row for in|app meaning
25247the same thing as "a+" already proposed in the issue.
25248</p>
25249
25250
25251<p><b>Proposed resolution:</b></p>
25252<p>
25253Add to the table "File open modes" in 27.9.1.4 [filebuf.members]:
25254</p>
25255
25256<blockquote>
25257<table border="1">
25258<caption> File open modes</caption>
25259<tbody><tr>
25260<th colspan="5"><tt>ios_base</tt> Flag combination</th>
25261<th><tt>stdio</tt> equivalent</th>
25262</tr>
25263<tr>
25264<th><tt>binary</tt></th><th><tt>in</tt></th><th><tt>out</tt></th><th><tt>trunc</tt></th><th><tt>app</tt></th><th><tt>&nbsp;</tt></th>
25265</tr>
25266
25267<tr>
25268<td>&nbsp;</td> <td>&nbsp;</td> <td><tt>+</tt></td> <td>&nbsp;</td> <td>&nbsp;</td> <td><tt>"w"</tt></td>
25269</tr>
25270<tr>
25271<td>&nbsp;</td> <td>&nbsp;</td> <td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>+</tt></td> <td><tt>"a"</tt></td>
25272</tr>
25273<tr>
25274<td>&nbsp;</td> <td>&nbsp;</td> <td>&nbsp;</td> <td>&nbsp;</td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>"a"</tt></ins></td>
25275</tr>
25276<tr>
25277<td>&nbsp;</td> <td>&nbsp;</td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>"w"</tt></td>
25278</tr>
25279<tr>
25280<td>&nbsp;</td> <td><tt>+</tt></td> <td>&nbsp;</td> <td>&nbsp;</td> <td>&nbsp;</td> <td><tt>"r"</tt></td>
25281</tr>
25282<tr>
25283<td>&nbsp;</td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td>&nbsp;</td> <td>&nbsp;</td> <td><tt>"r+"</tt></td>
25284</tr>
25285<tr>
25286<td>&nbsp;</td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>"w+"</tt></td>
25287</tr>
25288<tr>
25289<td>&nbsp;</td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>+</tt></ins></td> <td>&nbsp;</td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>"a+"</tt></ins></td>
25290</tr>
25291<tr>
25292<td>&nbsp;</td> <td><ins><tt>+</tt></ins></td> <td>&nbsp;</td> <td>&nbsp;</td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>"a+"</tt></ins></td>
25293</tr>
25294
25295<tr>
25296<td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>+</tt></td> <td>&nbsp;</td> <td>&nbsp;</td> <td><tt>"wb"</tt></td>
25297</tr>
25298<tr>
25299<td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>+</tt></td> <td><tt>"ab"</tt></td>
25300</tr>
25301<tr>
25302<td><ins><tt>+</tt></ins></td> <td>&nbsp;</td> <td>&nbsp;</td> <td>&nbsp;</td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>"ab"</tt></ins></td>
25303</tr>
25304<tr>
25305<td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>"wb"</tt></td>
25306</tr>
25307<tr>
25308<td><tt>+</tt></td> <td><tt>+</tt></td> <td>&nbsp;</td> <td>&nbsp;</td> <td>&nbsp;</td> <td><tt>"rb"</tt></td>
25309</tr>
25310<tr>
25311<td><tt>+</tt></td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td>&nbsp;</td> <td>&nbsp;</td> <td><tt>"r+b"</tt></td>
25312</tr>
25313<tr>
25314<td><tt>+</tt></td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>"w+b"</tt></td>
25315</tr><tr>
25316<td><ins><tt>+</tt></ins></td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>+</tt></ins></td> <td>&nbsp;</td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>"a+b"</tt></ins></td>
25317</tr>
25318<tr>
25319<td><ins><tt>+</tt></ins></td> <td><ins><tt>+</tt></ins></td> <td>&nbsp;</td> <td>&nbsp;</td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>"a+b"</tt></ins></td>
25320</tr>
25321
25322
25323</tbody></table>
25324</blockquote>
25325
25326
25327
25328<p><i>[
25329Kona (2007) Added proposed wording and moved to Review.
25330]</i></p>
25331
25332
25333
25334
25335
25336<hr>
25337<h3><a name="598"></a>598. Decimal: Conversion to integral should truncate, not round.</h3>
25338<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>
25339 <b>Submitter:</b> Daniel Krugler <b>Opened:</b> 2006-05-28  <b>Last modified:</b> 2007-04-21</p>
25340<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>
25341<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>
25342<p><b>Discussion:</b></p>
25343
25344<p>
25345In a private email, Daniel writes:
25346</p>
25347<blockquote>
25348<p>
25349I would like to 
25350ask, what where the reason for the decision to 
25351define the semantics of the integral conversion of the decimal types, namely
25352</p>
25353<pre>"operator long long() const;
25354
25355     Returns: Returns the result of the 
25356conversion of *this to the type long long, as if 
25357performed by the expression llrounddXX(*this)."
25358</pre>
25359<p>
25360where XX stands for either 32, 64, or 128, 
25361corresponding to the proper decimal type. The 
25362exact meaning of llrounddXX is not given in that 
25363paper, so I compared it to the corresponding 
25364definition given in C99, 2nd edition (ISO 9899), which says in 7.12.9.7 p. 2:
25365</p>
25366<p>
25367"The lround and llround functions round their 
25368argument to the nearest integer value,
25369rounding halfway cases away from zero, regardless 
25370of the current rounding direction. [..]"
25371</p>
25372<p>
25373Now considering the fact that integral conversion 
25374of the usual floating-point types ("4.9 
25375Floating-integral conversions") has truncation 
25376semantic I wonder why this conversion behaviour 
25377has not been transferred for the decimal types. 
25378</p>
25379</blockquote>
25380<p>
25381Robert comments:
25382</p>
25383<p>
25384Also, there is a further error in the <b>Returns:</b> clause for converting <code>decimal::decimal128</code> to <code>long long</code>.  It currently calls <code>llroundd64</code>, not <code>llroundd128</code>.
25385</p>
25386
25387
25388
25389<p><b>Proposed resolution:</b></p>
25390<p>
25391Change the <b>Returns:</b> clause in 3.2.2.4 to:
25392</p>
25393<blockquote><p>
25394<b>Returns:</b> Returns the result of the conversion of <code>*this</code> to the type <code>long long</code>, as if performed by the expression <code>llroundd32(*this)</code> <ins>while the decimal rounding direction mode [3.5.2] <code>FE_DEC_TOWARD_ZERO</code> is in effect</ins>.
25395</p></blockquote>
25396<p>
25397Change the <b>Returns:</b> clause in 3.2.3.4 to:
25398</p>
25399<blockquote><p>
25400<b>Returns:</b> Returns the result of the conversion of <code>*this</code> to the type <code>long long</code>, as if performed by the expression <code>llroundd64(*this)</code> <ins>while the decimal rounding direction mode [3.5.2] <code>FE_DEC_TOWARD_ZERO</code> is in effect</ins>.
25401</p></blockquote>
25402<p>
25403Change the <b>Returns:</b> clause in 3.2.4.4 to:
25404</p>
25405<blockquote><p>
25406<b>Returns:</b> Returns the result of the conversion of <code>*this</code> to the type <code>long long</code>, as if performed by the expression <del><code>llroundd64(*this)</code></del> <ins><code>llroundd128(*this)</code> while the decimal rounding direction mode [3.5.2] <code>FE_DEC_TOWARD_ZERO</code> is in effect</ins>.
25407</p></blockquote>
25408
25409
25410
25411
25412
25413
25414<hr>
25415<h3><a name="599"></a>599. Decimal: Say "octets" instead of "bytes."</h3>
25416<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>
25417 <b>Submitter:</b> Daniel Krugler <b>Opened:</b> 2006-05-28  <b>Last modified:</b> 2007-04-21</p>
25418<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>
25419<p><b>Discussion:</b></p>
25420<p>
25421Daniel writes in a private email:
25422</p>
25423
25424<blockquote>
25425<p>
25426- 3.1 'Decimal type encodings' says in its note:
25427</p>
25428<pre>"this implies that 
25429sizeof(std::decimal::decimal32) == 4, 
25430sizeof(std::decimal::decimal64) == 8, and 
25431sizeof(std::decimal::decimal128) == 16."
25432</pre>
25433<p>
25434This is a wrong assertion, because the definition 
25435of 'byte' in 1.7 'The C+ + memory model' of ISO 
2543614882 (2nd edition) does not specify that a byte 
25437must be necessarily 8 bits large, which would be 
25438necessary to compare with the specified bit sizes 
25439of the types decimal32, decimal64, and decimal128.
25440</p>
25441</blockquote>
25442
25443
25444<p><b>Proposed resolution:</b></p>
25445<p>
25446Change 3.1 as follows:
25447</p>
25448<blockquote>
25449<p>
25450The three decimal encoding formats defined in IEEE-754R correspond to the three decimal floating types as follows:
25451</p>
25452<ul>
25453<li>
25454decimal32 is a <em>decimal32</em> number, which is encoded in four consecutive <del>bytes</del> <ins>octets</ins> (32 bits)
25455</li>
25456<li>
25457decimal64 is a <em>decimal64</em> number, which is encoded in eight consecutive <del>bytes</del> <ins>octets</ins> (64 bits)
25458
25459</li>
25460<li>
25461decimal128 is a <em>decimal128</em> number, which is encoded in 16 consecutive <del>bytes</del> <ins>octets</ins> (128 bits)
25462</li>
25463</ul>
25464<p>
25465<del>[<i>Note:</i> this implies that <code>sizeof(std::decimal::decimal32) == 4</code>, <code>sizeof(std::decimal::decimal64) == 8</code>, and <code>sizeof(std::decimal::decimal128) == 16</code>.  <i>--end note</i>]</del>
25466</p>
25467</blockquote>
25468
25469
25470
25471
25472<hr>
25473<h3><a name="600"></a>600. Decimal: Wrong parameters for wcstod* functions</h3>
25474<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>
25475 <b>Submitter:</b> Daniel Krugler <b>Opened:</b> 2006-05-28  <b>Last modified:</b> 2007-04-21</p>
25476<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>
25477<p><b>Discussion:</b></p>
25478<p>
25479Daniel writes:
25480</p>
25481<blockquote><p>
25482- 3.9.1 'Additions to &lt;cwchar&gt;' provides wrong 
25483signatures to the wcstod32, wcstod64, and 
25484wcstod128 functions ([the parameters have type pointer-to-] char instead of wchar_t).
25485</p></blockquote>
25486
25487
25488<p><b>Proposed resolution:</b></p>
25489<p>
25490Change "3.9.1 Additions to <code>&lt;cwchar&gt;</code> synopsis" to:
25491</p>
25492<pre>       namespace std {
25493       namespace decimal {
25494         // 3.9.2 wcstod functions:
25495         decimal32  wcstod32  (const <del>char</del> <ins>wchar_t</ins> * nptr, <del>char</del> <ins>wchar_t</ins> ** endptr);
25496         decimal64  wcstod64  (const <del>char</del> <ins>wchar_t</ins> * nptr, <del>char</del> <ins>wchar_t</ins> ** endptr);
25497         decimal128 wcstod128 (const <del>char</del> <ins>wchar_t</ins> * nptr, <del>char</del> <ins>wchar_t</ins> ** endptr);
25498       }
25499       }
25500</pre>
25501
25502
25503
25504
25505<hr>
25506<h3><a name="601"></a>601. Decimal: numeric_limits typos</h3>
25507<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>
25508 <b>Submitter:</b> Daniel Krugler <b>Opened:</b> 2006-05-28  <b>Last modified:</b> 2007-04-21</p>
25509<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>
25510<p><b>Discussion:</b></p>
25511<p>
25512Daniel writes in a private email:
25513</p>
25514
25515<blockquote>
25516<p>
25517- 3.3 'Additions to header &lt;limits&gt;' contains two 
25518errors in the specialisation of numeric_limits&lt;decimal::decimal128&gt;:
25519</p>
25520<ol>
25521<li>The static member max() returns DEC128_MIN, this should be DEC128_MAX.</li>
25522<li>The static member digits is assigned to 384,
25523this should be 34 (Probably mixed up with the
25524max. exponent for decimal::decimal64).</li>
25525</ol>
25526</blockquote>
25527
25528
25529<p><b>Proposed resolution:</b></p>
25530<p>
25531In "3.3 Additions to header <code>&lt;limits&gt;</code>" change numeric_limits&lt;decimal::decimal128&gt; as follows:
25532</p>
25533<pre>        template&lt;&gt; class numeric_limits&lt;decimal::decimal128&gt; {
25534          public:
25535            static const bool is_specialized = true;
25536
25537            static decimal::decimal128 min() throw() { return DEC128_MIN; }
25538            static decimal::decimal128 max() throw() { return <del>DEC128_MIN;</del> <ins>DEC128_MAX;</ins> }
25539
25540            static const int digits       = <del>384</del> <ins>34</ins>;
25541            /* ... */
25542</pre>
25543
25544
25545
25546
25547<hr>
25548<h3><a name="602"></a>602. Decimal: "generic floating type" not defined.</h3>
25549<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>
25550 <b>Submitter:</b> Daniel Krugler <b>Opened:</b> 2006-05-28  <b>Last modified:</b> 2007-04-21</p>
25551<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>
25552<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>
25553<p><b>Discussion:</b></p>
25554<p>
25555The document uses the term "generic floating types," but defines it nowhere.
25556</p>
25557
25558
25559<p><b>Proposed resolution:</b></p>
25560<p>
25561Change the first paragraph of "3 Decimal floating-point types" as follows:
25562</p>
25563<blockquote><p>
25564This Technical Report introduces three decimal floating-point types, named
25565decimal32, decimal64, and decimal128. The set of values of type decimal32 is a
25566subset of the set of values of type decimal64; the set of values of the type
25567decimal64 is a subset of the set of values of the type decimal128. Support for
25568decimal128 is optional.  <ins>These types supplement the Standard C++ types
25569<code>float</code>, <code>double</code>, and <code>long double</code>, which are
25570collectively described as the <i>basic floating types</i></ins>.
25571</p></blockquote>
25572
25573
25574
25575
25576<hr>
25577<h3><a name="603"></a>603. Decimal: Trivially simplifying decimal classes.</h3>
25578<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>
25579 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-05-28  <b>Last modified:</b> 2007-04-21</p>
25580<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>
25581<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>
25582<p><b>Discussion:</b></p>
25583<p>In c++std-lib-17198, Martin writes:</p>
25584
25585<blockquote><p>
25586Each of the three classes proposed in the paper (decimal32, decimal64,
25587and decimal128) explicitly declares and specifies the semantics of its
25588copy constructor, copy assignment operator, and destructor. Since the
25589semantics of all three functions are identical to the trivial versions
25590implicitly generated by the compiler in the absence of any declarations
25591it is safe to drop them from the spec. This change would make the
25592proposed classes consistent with other similar classes already in the
25593standard (e.g., std::complex).
25594</p></blockquote>
25595
25596
25597<p><b>Proposed resolution:</b></p>
25598<p>
25599Change "3.2.2 Class <code>decimal32</code>" as follows:
25600</p>
25601<pre>      namespace std {
25602      namespace decimal {
25603        class decimal32 {
25604          public:
25605            // 3.2.2.1 construct/copy/destroy:
25606            decimal32();
25607            <del>decimal32(const decimal32 &amp; d32);</del>
25608            <del>decimal32 &amp; operator=(const decimal32 &amp; d32);</del>
25609            <del>~decimal32();</del>
25610            /* ... */
25611</pre>
25612<p>
25613Change "3.2.2.1 construct/copy/destroy" as follows:
25614</p>
25615<pre>        decimal32();
25616
25617    Effects: Constructs an object of type decimal32 with the value 0;
25618
25619        <del>decimal32(const decimal32 &amp; d32);</del>
25620        <del>decimal32 &amp; operator=(const decimal32 &amp; d32);</del>
25621
25622    <del>Effects: Copies an object of type decimal32.</del>
25623
25624        <del>~decimal32();</del>
25625
25626    <del>Effects: Destroys an object of type decimal32.</del>
25627
25628</pre>
25629<p>
25630Change "3.2.3 Class <code>decimal64</code>" as follows:
25631</p>
25632<pre>      namespace std {
25633      namespace decimal {
25634        class decimal64 {
25635          public:
25636            // 3.2.3.1 construct/copy/destroy:
25637            decimal64();
25638            <del>decimal64(const decimal64 &amp; d64);</del>
25639            <del>decimal64 &amp; operator=(const decimal64 &amp; d64);</del>
25640            <del>~decimal64();</del>
25641            /* ... */
25642</pre>
25643<p>
25644Change "3.2.3.1 construct/copy/destroy" as follows:
25645</p>
25646<pre>        decimal64();
25647
25648    Effects: Constructs an object of type decimal64 with the value 0;
25649
25650        <del>decimal64(const decimal64 &amp; d64);</del>
25651        <del>decimal64 &amp; operator=(const decimal64 &amp; d64);</del>
25652
25653    <del>Effects: Copies an object of type decimal64.</del>
25654
25655        <del>~decimal64();</del>
25656
25657    <del>Effects: Destroys an object of type decimal64.</del>
25658
25659</pre>
25660<p>
25661Change "3.2.4 Class <code>decimal128</code>" as follows:
25662</p>
25663<pre>      namespace std {
25664      namespace decimal {
25665        class decimal128 {
25666          public:
25667            // 3.2.4.1 construct/copy/destroy:
25668            decimal128();
25669            <del>decimal128(const decimal128 &amp; d128);</del>
25670            <del>decimal128 &amp; operator=(const decimal128 &amp; d128);</del>
25671            <del>~decimal128();</del>
25672            /* ... */
25673</pre>
25674<p>
25675Change "3.2.4.1 construct/copy/destroy" as follows:
25676</p>
25677<pre>        decimal128();
25678
25679    Effects: Constructs an object of type decimal128 with the value 0;
25680
25681        <del>decimal128(const decimal128 &amp; d128);</del>
25682        <del>decimal128 &amp; operator=(const decimal128 &amp; d128);</del>
25683
25684    <del>Effects: Copies an object of type decimal128.</del>
25685
25686        <del>~decimal128();</del>
25687
25688    <del>Effects: Destroys an object of type decimal128.</del>
25689
25690</pre>
25691
25692
25693
25694
25695<hr>
25696<h3><a name="604"></a>604. Decimal: Storing a reference to a facet unsafe.</h3>
25697<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>
25698 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-05-28  <b>Last modified:</b> 2007-07-25</p>
25699<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>
25700<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>
25701<p><b>Discussion:</b></p>
25702<p>
25703In c++std-lib-17197, Martin writes:
25704</p>
25705<blockquote><p>
25706The extended_num_get and extended_num_put facets are designed
25707to store a reference to a num_get or num_put facet which the
25708extended facets delegate the parsing and formatting of types
25709other than decimal. One form of the extended facet's ctor (the
25710default ctor and the size_t overload) obtains the reference
25711from the global C++ locale while the other form takes this
25712reference as an argument.
25713</p></blockquote>
25714<blockquote><p>
25715The problem with storing a reference to a facet in another
25716object (as opposed to storing the locale object in which the
25717facet is installed) is that doing so bypasses the reference
25718counting mechanism designed to prevent a facet that is still
25719being referenced (i.e., one that is still installed in some
25720locale) from being destroyed when another locale that contains
25721it is destroyed. Separating a facet reference from the locale
25722it comes from van make it cumbersome (and in some cases might
25723even make it impossible) for programs to prevent invalidating
25724the reference. (The danger of this design is highlighted in
25725the paper.)
25726</p></blockquote>
25727<blockquote><p>
25728This problem could be easily avoided by having the extended
25729facets store a copy of the locale from which they would extract
25730the base facet either at construction time or when needed. To
25731make it possible, the forms of ctors of the extended facets that
25732take a reference to the base facet would need to be changed to
25733take a locale argument instead.
25734</p></blockquote>
25735
25736
25737<p><b>Proposed resolution:</b></p>
25738<p>
257391. Change the <code>extended_num_get</code> synopsis in 3.10.2 as follows:
25740</p>
25741<pre>            extended_num_get(const <del>std::num_get&lt;charT, InputIterator&gt;</del> <ins>std::locale</ins> &amp; <i>b</i>, size_t <i>refs</i> = 0);
25742
25743            /* ... */
25744
25745            <del>// <i>const std::num_get&lt;charT, InputIterator&gt; &amp; <b>base</b></i>;        <i><b>exposition only</b></i></del>
25746            <ins>// <i>std::locale <b>baseloc</b></i>;                                    <i><b>exposition only</b></i></ins>
25747</pre>
25748<p>
257492. Change the description of the above constructor in 3.10.2.1:
25750</p>
25751<pre>            extended_num_get(const <del>std::num_get&lt;charT, InputIterator&gt;</del> <ins>std::locale</ins> &amp; <i>b</i>, size_t <i>refs</i> = 0);
25752
25753</pre>
25754<blockquote>
25755<p>
25756<b>Effects:</b> Constructs an <code>extended_num_get</code> facet as if by:
25757</p>
25758<pre>       extended_num_get(const <del>std::num_get&lt;charT, InputIterator&gt;</del> <ins>std::locale</ins> &amp; <i>b</i>, size_t <i>refs</i> = 0)
25759                : facet(<i>refs</i>), <i>base<ins>loc</ins></i>(<i>b</i>)
25760                { /* ... */ }
25761
25762</pre>
25763<p>
25764<del><b>Notes:</b> Care must be taken by the implementation to ensure that the lifetime of the facet referenced by <i>base</i> exceeds that of the resulting <code>extended_num_get</code> facet.</del>
25765</p>
25766</blockquote>
25767<p>
257683. Change the <b>Returns:</b> clause for <code>do_get(iter_type, iter_type, ios_base &amp;, ios_base::iostate &amp;, bool &amp;) const</code>, <i>et al</i> to
25769</p>
25770<blockquote><p>
25771<b>Returns:</b> <code><del><i>base</i></del> <ins>std::use_facet&lt;std::num_get&lt;charT, InputIterator&gt; &gt;(<i>baseloc</i>)</ins>.get(<i>in</i>, <i>end</i>, <i>str</i>, <i>err</i>, <i>val</i>)</code>. 
25772</p></blockquote>
25773<p>
257744. Change the <code>extended_num_put</code> synopsis in 3.10.3 as follows:
25775</p>
25776<pre>            extended_num_put(const <del>std::num_put&lt;charT, OutputIterator&gt;</del> <ins>std::locale</ins> &amp; <i>b</i>, size_t <i>refs</i> = 0);
25777
25778            /* ... */
25779
25780            <del>// <i>const std::num_put&lt;charT, OutputIterator&gt; &amp; <b>base</b></i>;       <i><b>exposition only</b></i></del>
25781            <ins>// <i>std::locale <b>baseloc</b></i>;                                    <i><b>exposition only</b></i></ins>
25782</pre>
25783<p>
257845. Change the description of the above constructor in 3.10.3.1:
25785</p>
25786<pre>            extended_num_put(const <del>std::num_put&lt;charT, OutputIterator&gt;</del> <ins>std::locale</ins> &amp; <i>b</i>, size_t <i>refs</i> = 0);
25787</pre>
25788<blockquote>
25789<p>
25790<b>Effects:</b> Constructs an <code>extended_num_put</code> facet as if by:
25791</p>
25792<pre>       extended_num_put(const <del>std::num_put&lt;charT, OutputIterator&gt;</del> <ins>std::locale</ins> &amp; <i>b</i>, size_t <i>refs</i> = 0)
25793                : facet(<i>refs</i>), <i>base<ins>loc</ins></i>(<i>b</i>)
25794                { /* ... */ }
25795
25796</pre>
25797<p>
25798<del><b>Notes:</b> Care must be taken by the implementation to ensure that the lifetime of the facet referenced by <i>base</i> exceeds that of the resulting <code>extended_num_put</code> facet.</del>
25799</p>
25800</blockquote>
25801<p>
258026. Change the <b>Returns:</b> clause for <code>do_put(iter_type, ios_base &amp;, char_type, bool &amp;) const</code>, <i>et al</i> to
25803</p>
25804<blockquote><p>
25805<b>Returns:</b> <code><del><i>base</i></del> <ins>std::use_facet&lt;std::num_put&lt;charT, OutputIterator&gt; &gt;(<i>baseloc</i>)</ins>.put(<i>s</i>, <i>f</i>, <i>fill</i>, <i>val</i>)</code>. 
25806</p></blockquote>
25807
25808<p><i>[
25809Redmond:  We would prefer to rename "extended" to "decimal".
25810]</i></p>
25811
25812
25813
25814
25815
25816
25817<hr>
25818<h3><a name="605"></a>605. Decimal: &lt;decfloat.h&gt; doesn't live here anymore.</h3>
25819<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>
25820 <b>Submitter:</b> Robert Klarer <b>Opened:</b> 2006-10-17  <b>Last modified:</b> 2007-04-21</p>
25821<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>
25822<p><b>Discussion:</b></p>
25823<p>
25824In Berlin, WG14 decided to drop the &lt;decfloat.h&gt; header. The
25825contents of that header have been moved into &lt;float.h&gt;. For the
25826sake of C compatibility, we should make corresponding changes.
25827</p>
25828
25829
25830<p><b>Proposed resolution:</b></p>
25831<p>
258321. Change the heading of subclause 3.4, "Headers <code>&lt;cdecfloat&gt;</code> and <code>&lt;decfloat.h&gt;</code>" to "Additions to headers <code>&lt;cfloat&gt;</code> and <code>&lt;float.h&gt;</code>."
25833</p>
25834<p>
258352. Change the text of subclause 3.4 as follows:
25836</p>
25837<blockquote>
25838<p>
25839<del>The standard C++ headers <code>&lt;cfloat&gt;</code> and <code>&lt;float.h&gt;</code> define characteristics of the floating-point types <code>float</code>, <code>double</code>, and <code>long double</code>.  Their contents remain unchanged by this Technical Report.</del>
25840</p>
25841<p>
25842<del>Headers <code>&lt;cdecfloat&gt;</code> and <code>&lt;decfloat.h&gt;</code> define characteristics of the decimal floating-point types <code>decimal32</code>, <code>decimal64</code>, and <code>decimal128</code>.  As well, <code>&lt;decfloat.h&gt;</code> defines the convenience typedefs <code>_Decimal32</code>, <code>_Decimal64</code>, and <code>_Decimal128</code>, for compatibilty with the C programming language.</del>
25843</p>
25844<p>
25845<ins>The header <code>&lt;cfloat&gt;</code> is described in [tr.c99.cfloat].  The header <code>&lt;float.h&gt;</code>
25846is described in [tr.c99.floath]. These headers are extended by this
25847Technical Report to define characteristics of the decimal
25848floating-point types <code>decimal32</code>, <code>decimal64</code>, and <code>decimal128</code>.  As well, <code>&lt;float.h&gt;</code> is extended to define the convenience typedefs <code>_Decimal32</code>, <code>_Decimal64</code>, and <code>_Decimal128</code> for compatibility with the C programming language.</ins>
25849</p>
25850</blockquote>
25851<p>
258523. Change the heading of subclause 3.4.1, "Header <code>&lt;cdecfloat&gt;</code> synopsis"  to "Additions to header <code>&lt;cfloat&gt;</code> synopsis."
25853</p>
25854<p>
258554. Change the heading of subclause 3.4.2, "Header <code>&lt;decfloat.h&gt;</code> synopsis" to "Additions to header <code>&lt;float.h&gt;</code> synopsis."
25856</p>
25857<p>
258585. Change the contents of 3.4.2 as follows:
25859</p>
25860<pre>      <del>#include &lt;cdecfloat&gt;</del>
25861
25862      // <i>C-compatibility convenience typedefs:</i>
25863
25864      typedef std::decimal::decimal32  _Decimal32;
25865      typedef std::decimal::decimal64  _Decimal64;
25866      typedef std::decimal::decimal128 _Decimal128;
25867</pre>
25868
25869
25870
25871
25872
25873<hr>
25874<h3><a name="607"></a>607. Concern about short seed vectors</h3>
25875<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>
25876 <b>Submitter:</b> Charles Karney <b>Opened:</b> 2006-10-26  <b>Last modified:</b> 2008-09-26</p>
25877<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>
25878<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
25879<p><b>Discussion:</b></p>
25880<p>
25881Short seed vectors of 32-bit quantities all result in different states. However
25882this is not true of seed vectors of 16-bit (or smaller) quantities.  For example
25883these two seeds
25884</p>
25885
25886<blockquote><pre>unsigned short seed = {1, 2, 3};
25887unsigned short seed = {1, 2, 3, 0};
25888</pre></blockquote>
25889
25890<p>
25891both pack to
25892</p>
25893
25894<blockquote><pre>unsigned seed = {0x20001, 0x3};
25895</pre></blockquote>
25896
25897<p>
25898yielding the same state.
25899</p>
25900
25901<p>
25902See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
25903<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
25904for some further discussion.
25905</p>
25906
25907
25908<p><b>Proposed resolution:</b></p>
25909<p>
25910Adopt the proposed resolution in
25911<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
25912</p>
25913
25914
25915<p><i>[
25916Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
25917The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
25918]</i></p>
25919
25920
25921
25922
25923
25924<hr>
25925<h3><a name="608"></a>608. Unclear seed_seq construction details</h3>
25926<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>
25927 <b>Submitter:</b> Charles Karney <b>Opened:</b> 2006-10-26  <b>Last modified:</b> 2008-09-26</p>
25928<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>
25929<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
25930<p><b>Discussion:</b></p>
25931<p>
25932In 26.4.7.1 [rand.util.seedseq] /6, the order of packing the inputs into b and the
25933treatment of signed quantities is unclear. Better to spell it out.
25934</p>
25935
25936<p>
25937See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
25938<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
25939for some further discussion.
25940</p>
25941
25942
25943<p><b>Proposed resolution:</b></p>
25944<p>
25945Adopt the proposed resolution in
25946<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
25947</p>
25948
25949
25950<p><i>[
25951Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
25952The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
25953]</i></p>
25954
25955
25956
25957
25958
25959<hr>
25960<h3><a name="609"></a>609. missing static const</h3>
25961<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>
25962 <b>Submitter:</b> Walter E. Brown <b>Opened:</b> 2006-11-02  <b>Last modified:</b> 2008-09-26</p>
25963<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
25964<p><b>Discussion:</b></p>
25965<p>
25966In preparing N2111, an error on my part resulted in the omission of the
25967following line from the template synopsis in the cited section:
25968</p>
25969
25970<blockquote><pre>static const size_t word_size = w;
25971</pre></blockquote>
25972
25973<p>
25974(This same constant is found, for example, in 26.4.3.3 [rand.eng.sub].)
25975</p>
25976
25977
25978<p><b>Proposed resolution:</b></p>
25979<p>
25980Add the above declaration as the first line after the comment in [rand.adapt.ibits] p4:
25981</p>
25982
25983<blockquote><pre>// engine characteristics
25984<ins>static const size_t word_size = w;</ins>
25985</pre></blockquote>
25986
25987<p>
25988and accept my apologies for the oversight.
25989</p>
25990
25991
25992
25993
25994
25995<hr>
25996<h3><a name="610"></a>610. Suggested non-normative note for C++0x</h3>
25997<p><b>Section:</b> 20.7.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#CD1">CD1</a>
25998 <b>Submitter:</b> Scott Meyers <b>Opened:</b> 2006-11-02  <b>Last modified:</b> 2008-09-26</p>
25999<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
26000<p><b>Discussion:</b></p>
26001<p>
26002My suggestion is that implementers of both tr1::function and its 
26003official C++0x successor be explicitly encouraged (but not required) to 
26004optimize for the cases mentioned above, i.e., function pointers and 
26005small function objects.  They could do this by using a small internal 
26006buffer akin to the buffer used by implementations of the small string 
26007optimization.  (That would make this the small functor optimization -- 
26008SFO :-})  The form of this encouragement could be a note in the standard 
26009akin to footnote 214 of the current standard.
26010</p>
26011
26012<p>
26013Dave Abrahams notes:
26014</p>
26015
26016<p>
26017"shall not throw exceptions" should really be "nothing," both to be more
26018grammatical and to be consistent with existing wording in the standard.
26019</p>
26020
26021<p>
26022Doug Gregor comments: I think this is a good idea. Currently, implementations of
26023tr1::function are required to have non-throwing constructors and assignment
26024operators when the target function object is a function pointer or a
26025reference_wrapper. The common case, however, is for a tr1::function to store
26026either an empty function object or a member pointer + an object pointer.
26027</p>
26028<p>
26029The function implementation in the upcoming Boost 1.34.0 uses the
26030"SFO", so that the function objects for typical bind expressions like
26031</p>
26032<blockquote><pre>bind(&amp;X::f, this, _1, _2, _3)
26033</pre></blockquote>
26034
26035<p>
26036do not require heap allocation when stored in a boost::function. I
26037believe Dinkumware's implementation also performs this optimization.
26038</p>
26039
26040
26041
26042<p><b>Proposed resolution:</b></p>
26043<p>
26044Revise 20.5.14.2.1 p6 [func.wrap.func.con] to add a note as follows:
26045</p>
26046
26047<blockquote>
26048<p>
26049<i>Throws:</i> shall not throw exceptions if <tt>f</tt>'s target is a function
26050pointer or a function object passed via <tt>reference_wrapper</tt>. Otherwise,
26051may throw <tt>bad_alloc</tt> or any exception thrown by the copy constructor of
26052the stored function object.
26053</p>
26054<p>
26055<ins><i>Note:</i> Implementations are encouraged to avoid the use of dynamically
26056allocated memory for "small" function objects, e.g., where <tt>f</tt>'s target
26057is an object holding only a pointer or reference to an object and a member
26058function pointer (a "bound member function").</ins>
26059</p>
26060</blockquote>
26061
26062
26063
26064
26065
26066<hr>
26067<h3><a name="611"></a>611. Standard library templates and incomplete types</h3>
26068<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>
26069 <b>Submitter:</b> Nicola Musatti <b>Opened:</b> 2006-11-13  <b>Last modified:</b> 2008-09-26</p>
26070<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>
26071<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
26072<p><b>Discussion:</b></p>
26073<p>
26074In the latest available draft standard 
26075(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2134.pdf">N2134</a>)
26076� 17.4.3.6 [res.on.functions] states:
26077</p>
26078
26079<blockquote>
26080<p>
26081-1- In certain cases (replacement functions, handler functions, operations on
26082types used to instantiate standard library template components), the C++
26083Standard Library depends on components supplied by a C++ program. If these
26084components do not meet their requirements, the Standard places no requirements
26085on the implementation.
26086</p>
26087
26088<p>
26089-2- In particular, the effects are undefined in the following cases:
26090</p>
26091<p>
26092[...]
26093</p>
26094<ul>
26095<li>if an incomplete type (3.9) is used as a template argument when
26096instantiating a template component. </li>
26097</ul>
26098</blockquote>
26099
26100<p>
26101This is contradicted by � 20.6.6.2/2 [util.smartptr.shared] which
26102states:
26103</p>
26104
26105<blockquote>
26106<p>
26107[...]
26108</p>
26109
26110<p>
26111The template parameter <tt>T</tt> of <tt>shared_ptr</tt> may be an incomplete type.
26112</p>
26113</blockquote>
26114
26115
26116<p><b>Proposed resolution:</b></p>
26117<p>
26118Modify the last bullet of � 17.4.3.6/2 [res.on.functions] to allow for
26119exceptions:
26120</p>
26121
26122<blockquote>
26123<ul>
26124<li>if an incomplete type (3.9) is used as a template argument when
26125instantiating a template component<ins>, unless specifically allowed for the
26126component</ins>. </li>
26127</ul>
26128</blockquote>
26129
26130
26131
26132
26133
26134
26135<hr>
26136<h3><a name="612"></a>612. numeric_limits::is_modulo insufficiently defined</h3>
26137<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>
26138 <b>Submitter:</b> Chris Jefferson <b>Opened:</b> 2006-11-10  <b>Last modified:</b> 2008-09-26</p>
26139<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>
26140<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
26141<p><b>Discussion:</b></p>
26142<p>
2614318.2.1.2 55 states that "A type is modulo if it is possible to add two
26144positive numbers together and have a result that wraps around to a
26145third number that is less".
26146This seems insufficient for the following reasons:
26147</p>
26148
26149<ol>
26150<li>Doesn't define what that value received is.</li>
26151<li>Doesn't state the result is repeatable</li>
26152<li> Doesn't require that doing addition, subtraction and other
26153operations on all values is defined behaviour.</li>
26154</ol>
26155
26156<p><i>[
26157Batavia: Related to
26158<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2144.pdf">N2144</a>.
26159Pete: is there an ISO definition of modulo?  Underflow on signed behavior is undefined.
26160]</i></p>
26161
26162
26163<p><i>[
26164Bellevue:  accept resolution, move to ready status.
26165Does this mandate that is_modulo be true on platforms for which int
26166happens to b modulo? A: the standard already seems to require that.
26167]</i></p>
26168
26169
26170
26171<p><b>Proposed resolution:</b></p>
26172<p>
26173Suggest 18.3.1.2 [numeric.limits.members], paragraph 57 is amended to:
26174</p>
26175
26176<blockquote><p>
26177A type is modulo if<ins>,</ins> <del>it is possible to add two positive numbers
26178and have a result that wraps around to a third number that is less.</del>
26179<ins>given any operation involving +,- or * on values of that type whose value
26180would fall outside the range <tt>[min(), max()]</tt>, then the value returned
26181differs from the true value by an integer multiple of <tt>(max() - min() +
261821)</tt>.</ins>
26183</p></blockquote>
26184
26185
26186
26187
26188
26189
26190<hr>
26191<h3><a name="613"></a>613. max_digits10 missing from numeric_limits</h3>
26192<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>
26193 <b>Submitter:</b> Bo Persson <b>Opened:</b> 2006-11-20  <b>Last modified:</b> 2008-09-26</p>
26194<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>
26195<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
26196<p><b>Discussion:</b></p>
26197<p>
26198Section 18.3.1.5 [numeric.special] starts out by saying that "All members shall be provided 
26199for all specializations."
26200</p>
26201<p>
26202Then it goes on to show specializations for float and bool, where one member 
26203is missing (max_digits10).
26204</p>
26205
26206<p>
26207Maarten Kronenburg adds:
26208</p>
26209
26210<p>
26211I agree, just adding the comment that the exact number of decimal digits
26212is digits * ln(radix) / ln(10), where probably this real number is
26213rounded downward for digits10, and rounded upward for max_digits10
26214(when radix=10, then digits10=max_digits10).
26215Why not add this exact definition also to the standard, so the user
26216knows what these numbers exactly mean.
26217</p>
26218
26219<p>
26220Howard adds:
26221</p>
26222
26223<p>
26224For reference, here are the correct formulas from
26225<a href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1822.pdf">N1822</a>:
26226</p>
26227
26228<blockquote><pre>digits10 = floor((digits-1) * log10(2))
26229max_digits10 = ceil((1 + digits) * log10(2))
26230</pre></blockquote>
26231
26232<p>
26233We are also missing a statement regarding for what specializations this member has meaning.
26234</p>
26235
26236
26237
26238<p><b>Proposed resolution:</b></p>
26239<p>
26240Change and add after 18.3.1.2 [numeric.limits.members], p11:
26241</p>
26242
26243<blockquote>
26244<pre>static const int max_digits10;</pre>
26245<blockquote>
26246<p>
26247-11- Number of base 10 digits required to ensure that values which
26248differ <del>by only one epsilon</del> are always differentiated.
26249</p>
26250<p><ins>
26251-12- Meaningful for all floating point types.
26252</ins></p>
26253</blockquote>
26254</blockquote>
26255
26256<p>
26257Change 18.3.1.5 [numeric.special], p2:
26258</p>
26259
26260<blockquote><pre>template&lt;&gt; class numeric_limits&lt;float&gt; { 
26261public: 
26262  static const bool is_specialized = true; 
26263  ...
26264  static const int digits10 = 6;
26265  <ins>static const int max_digits10 = 9</ins>;
26266  ...
26267</pre></blockquote>
26268
26269<p>
26270Change 18.3.1.5 [numeric.special], p3:
26271</p>
26272
26273<blockquote><pre>template&lt;&gt; class numeric_limits&lt;bool&gt; { 
26274public: 
26275  static const bool is_specialized = true; 
26276  ...
26277  static const int digits10 = 0;
26278  <ins>static const int max_digits10 = 0</ins>;
26279  ...
26280</pre></blockquote>
26281
26282
26283
26284
26285
26286
26287
26288<hr>
26289<h3><a name="616"></a>616. missing 'typename' in ctype_byname</h3>
26290<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>
26291 <b>Submitter:</b> Bo Persson <b>Opened:</b> 2006-12-16  <b>Last modified:</b> 2008-09-26</p>
26292<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>
26293<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
26294<p><b>Discussion:</b></p>
26295<p>
26296Section 22.2.1.2 defines the ctype_byname class template. It contains the 
26297line
26298</p>
26299
26300<blockquote><pre>typedef ctype&lt;charT&gt;::mask   mask;
26301</pre></blockquote>
26302
26303
26304
26305<p><b>Proposed resolution:</b></p>
26306<p>
26307as this is a dependent type, it should obviously be
26308</p>
26309
26310<blockquote><pre>typedef <ins>typename</ins> ctype&lt;charT&gt;::mask   mask;
26311</pre></blockquote>
26312
26313
26314
26315
26316
26317<hr>
26318<h3><a name="618"></a>618. valarray::cshift() effects on empty array</h3>
26319<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>
26320 <b>Submitter:</b> Gabriel Dos Reis <b>Opened:</b> 2007-01-10  <b>Last modified:</b> 2008-09-26</p>
26321<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
26322<p><b>Discussion:</b></p>
26323<p>
26324I would respectfully request an issue be opened with the intention to
26325clarify the wording for <tt>size() == 0</tt> for <tt>cshift</tt>.
26326</p>
26327
26328
26329<p><b>Proposed resolution:</b></p>
26330<p>
26331Change 26.6.2.7 [valarray.members], paragraph 10:
26332</p>
26333
26334<blockquote>
26335
26336<pre>valarray&lt;T&gt; cshift(int <i>n</i>) const;
26337</pre>
26338
26339<blockquote>
26340<p>
26341This function returns an object of class <tt>valarray&lt;T&gt;</tt>, of
26342length <tt>size()</tt>, <del>each of whose elements <tt>I</tt> is
26343<tt>(*this)[(I + n ) % size()]</tt>. Thus, if element zero is taken as
26344the leftmost element, a positive value of <i>n</i> shifts the elements
26345circularly left <i>n</i> places.</del> <ins>that is a circular shift of <tt>*this</tt>. If
26346element zero is taken as the leftmost element, a non-negative value of
26347<i>n</i> shifts the elements circularly left <i>n</i> places and a
26348negative value of <i>n</i> shifts the elements circularly right
26349-<i>n</i> places.</ins>
26350</p>
26351</blockquote>
26352</blockquote>
26353
26354
26355
26356<p><b>Rationale:</b></p>
26357<p>
26358We do not believe that there is any real ambiguity about what happens
26359when <tt>size() == 0</tt>, but we do believe that spelling this out as a C++
26360expression causes more trouble that it solves. The expression is
26361certainly wrong when <tt>n &lt; 0</tt>, since the sign of % with negative arguments
26362is implementation defined.
26363</p>
26364
26365
26366<p><i>[
26367Kona (2007) Changed proposed wording, added rationale and set to Review.
26368]</i></p>
26369
26370
26371
26372
26373
26374<hr>
26375<h3><a name="619"></a>619. Longjmp wording problem</h3>
26376<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>
26377 <b>Submitter:</b> Lawrence Crowl <b>Opened:</b> 2007-01-12  <b>Last modified:</b> 2008-09-26</p>
26378<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>
26379<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
26380<p><b>Discussion:</b></p>
26381<p>
26382The wording for <tt>longjmp</tt> is confusing.
26383</p>
26384<p>
2638518.10 [support.runtime] -4- Other runtime support
26386</p>
26387<blockquote><p>
26388The function signature <tt>longjmp(jmp_buf jbuf, int val)</tt> has more restricted
26389behavior in this International Standard.  If any automatic objects would
26390be destroyed by a thrown exception transferring control to another
26391(destination) point in the program, then a call to <tt>longjmp(jbuf, val)</tt> that
26392the throw point that transfers control to the same (destination) point has
26393undefined behavior.
26394</p></blockquote>
26395<p>
26396Someone at Google thinks that should say "then a call to <tt>longjmp(jbuf, val)</tt>
26397*at* the throw point that transfers control".
26398</p>
26399<p>
26400Bill Gibbons thinks it should say something like "If any automatic objects
26401would be destroyed by an exception thrown at the point of the longjmp and
26402caught only at the point of the setjmp, the behavior is undefined."
26403</p>
26404
26405
26406<p><b>Proposed resolution:</b></p>
26407<p>
26408In general, accept Bill Gibbons' recommendation,
26409but add "call" to indicate that the undefined behavior
26410comes from the dynamic call, not from its presence in the code.
26411In 18.10 [support.runtime] paragraph 4, change
26412</p>
26413
26414<blockquote><p>
26415The function signature <tt>longjmp(jmp_buf jbuf, int val)</tt> has more
26416restricted behavior in this International Standard.  <del>If any automatic
26417objects would be destroyed by a thrown exception transferring control to another
26418(destination) point in the program, then a call to <tt>longjmp(jbuf, val)</tt>
26419that the throw point that transfers control to the same (destination) point has
26420undefined behavior.</del> <ins>A <tt>setjmp</tt>/<tt>longjmp</tt> call pair has
26421undefined behavior if replacing the <tt>setjmp</tt> and <tt>longjmp</tt> by
26422<tt>catch</tt> and <tt>throw</tt> would destroy any automatic objects.</ins>
26423</p></blockquote>
26424
26425
26426
26427
26428
26429<hr>
26430<h3><a name="620"></a>620. valid uses of empty valarrays</h3>
26431<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>
26432 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-01-20  <b>Last modified:</b> 2008-09-26</p>
26433<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>
26434<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
26435<p><b>Discussion:</b></p>
26436        <p>
26437
26438The <i>Effects</i>  clause for the  default <code>valarray</code> ctor
26439suggests  that  it  is possible  to  increase  the  size of  an  empty
26440<code>valarray</code>  object   by  calling  other   non-const  member
26441functions of the class besides <code>resize()</code>. However, such an
26442interpretation would  be contradicted by  the requirement on  the copy
26443assignment  operator  (and  apparently   also  that  on  the  computed
26444assignments)  that the  assigned arrays  be  the same  size.  See  the
26445reflector discussion starting with c++std-lib-17871.
26446
26447        </p>
26448        <p>
26449
26450In  addition,  <i>Footnote</i> 280  uses  some questionable  normative
26451language.
26452
26453        </p>
26454
26455
26456<p><b>Proposed resolution:</b></p>
26457        <p>
26458
26459Reword the <i>Effects</i> clause and <i>Footnote 280</i> as follows (26.6.2.1 [valarray.cons]):
26460
26461        </p>
26462        <blockquote>
26463            <p>
26464
26465<code>valarray();</code>
26466
26467            </p>
26468            <p>
26469
26470<i>Effects</i>:      Constructs      an      object      of      class
26471<code>valarray&lt;T&gt;</code>,<sup>279)</sup>    which    has    zero
26472length<del> until it is passed into a library function as a modifiable
26473lvalue or through a non-constant this pointer</del>.<sup>280)</sup>
26474
26475            </p>
26476            <p>
26477
26478<ins><i>Postcondition</i>: <code>size() == 0</code>.</ins>
26479
26480            </p>
26481            <p>
26482
26483<i>Footnote  280</i>:  This default  constructor  is essential,  since
26484arrays  of  <code>valarray</code>  <del>are  likely to  prove  useful.
26485There  shall also  be  a way  to change  the  size of  an array  after
26486initialization;  this  is  supplied  by the  semantics</del>  <ins>may be
26487useful.   The  length  of  an  empty  array  can  be  increased  after
26488initialization  by  means</ins>  of the  <code>resize()</code>  member
26489function.
26490
26491            </p>
26492        </blockquote>
26493
26494
26495
26496
26497
26498<hr>
26499<h3><a name="621"></a>621. non-const copy assignment operators of helper arrays</h3>
26500<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>
26501 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-01-20  <b>Last modified:</b> 2008-09-26</p>
26502<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>
26503<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
26504<p><b>Discussion:</b></p>
26505        <p>
26506
26507The computed and  "fill" assignment operators of <code>valarray</code>
26508helper     array     class    templates     (<code>slice_array</code>,
26509<code>gslice_array</code>,         <code>mask_array</code>,        and
26510<code>indirect_array</code>) are const  member functions of each class
26511template     (the     latter    by     the     resolution    of  <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#123">123</a>
26512since  they have reference  semantics and thus do  not affect
26513the state of  the object on which they are  called.  However, the copy
26514assignment  operators  of  these  class  templates,  which  also  have
26515reference semantics,  are non-const.   The absence of  constness opens
26516the door to speculation about whether they really are intended to have
26517reference semantics (existing implementations vary widely).
26518
26519        </p>
26520
26521<p>
26522Pre-Kona, Martin adds:
26523</p>
26524
26525<p>
26526I realized that adding the const qualifier to the
26527functions as I suggested would break the const correctness of the
26528classes. A few possible solutions come to mind:
26529</p>
26530
26531<ol>
26532<li>Add the const qualifier to the return types of these functions.</li>
26533<li>Change the return type of all the functions to void to match
26534the signatures of all the other assignment operators these classes
26535define.</li>
26536<li>Prohibit the copy assignment of these classes by declaring the
26537copy assignment operators private (as is done and documented by
26538some implementations).</li>
26539</ol>
26540
26541
26542
26543<p><b>Proposed resolution:</b></p>
26544        <p>
26545
26546Declare  the  copy  assignment  operators  of all  four  helper  array
26547class templates const.
26548
26549        </p>
26550        <p>
26551
26552Specifically,  make the following edits:
26553
26554        </p>
26555        <p>
26556
26557Change     the    signature     in     26.6.5 [template.slice.array]    and
2655826.6.5.1 [slice.arr.assign] as follows:
26559
26560        </p>
26561        <blockquote><pre>
26562<code><ins>const</ins> slice_array&amp; operator= (const slice_array&amp;)<ins> const</ins>;</code>
26563
26564        </pre></blockquote>
26565        <p>
26566
26567Change     the     signature     in    26.6.7 [template.gslice.array]     and
2656826.6.7.1 [gslice.array.assign] as follows:
26569
26570        </p>
26571        <blockquote><pre>
26572<code><ins>const</ins> gslice_array&amp; operator= (const gslice_array&amp;)<ins> const</ins>;</code>
26573
26574        </pre></blockquote>
26575        <p>
26576
26577Change the  signature in 26.6.8 [template.mask.array]  and 26.6.8.1 [mask.array.assign] as
26578follows:
26579
26580        </p>
26581        <blockquote><pre>
26582<code><ins>const</ins> mask_array&amp; operator= (const mask_array&amp;)<ins> const</ins>;</code>
26583
26584        </pre></blockquote>
26585        <p>
26586
26587Change     the     signature     in    26.6.9 [template.indirect.array] and
2658826.6.9.1 [indirect.array.assign] as follows:
26589
26590        </p>
26591        <blockquote><pre>
26592<code><ins>const</ins> indirect_array&amp; operator= (const indirect_array&amp;)<ins> const</ins>;</code>
26593
26594        </pre></blockquote>
26595
26596
26597<p><i>[
26598Kona (2007) Added const qualification to the return types and set to Ready.
26599]</i></p>
26600
26601
26602
26603
26604
26605<hr>
26606<h3><a name="622"></a>622. behavior of <code>filebuf</code> dtor and <code>close</code> on error</h3>
26607<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>
26608 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-01-20  <b>Last modified:</b> 2008-09-26</p>
26609<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
26610<p><b>Discussion:</b></p>
26611        <p>
26612
26613<code>basic_filebuf</code>  dtor is  specified to  have  the following
26614straightforward effects:
26615
26616        </p>
26617        <blockquote><p>
26618
26619<i>Effects</i>:       Destroys      an      object       of      class
26620<code>basic_filebuf</code>. Calls <code>close()</code>.
26621
26622        </p></blockquote>
26623        <p>
26624
26625<code>close()</code> does a lot of potentially complicated processing,
26626including calling <code>overflow()</code> to write out the termination
26627sequence  (to   bring  the  output  sequence  to   its  initial  shift
26628state). Since  any of the  functions called during the  processing can
26629throw an exception, what should the  effects of an exception be on the
26630dtor? Should the  dtor catch and swallow it or  should it propagate it
26631to the caller?  The text doesn't  seem to provide any guidance in this
26632regard  other  than  the  general  restriction on  throwing  (but  not
26633propagating)  exceptions  from   destructors  of  library  classes  in
2663417.6.4.11 [res.on.exception.handling].
26635
26636        </p>
26637        <p>
26638
26639Further,  the last thing  <code>close()</code> is  specified to  do is
26640call <code>fclose()</code> to close the <code>FILE</code> pointer. The
26641last sentence of the <i>Effects</i> clause reads:
26642
26643        </p>
26644        <blockquote><p>
26645
26646...   If    any   of    the   calls   to    <code>overflow</code>   or
26647<code>std::fclose</code> fails then <code>close</code> fails.
26648
26649        </p></blockquote>
26650        <p>
26651
26652This  suggests that  <code>close()</code>  might be  required to  call
26653<code>fclose()</code>   if  and  only   if  none   of  the   calls  to
26654<code>overflow()</code> fails, and avoid closing the <code>FILE</code>
26655otherwise. This  way, if  <code>overflow()</code> failed to  flush out
26656the data, the caller  would have  the opportunity to  try to  flush it
26657again (perhaps  after trying  to deal with  whatever problem  may have
26658caused the failure), rather than losing it outright.
26659
26660        </p>
26661        <p>
26662
26663On the other hand,  the function's <i>Postcondition</i> specifies that
26664<code>is_open() ==  false</code>, which  suggests that it  should call
26665<code>fclose()</code>       unconditionally.       However,      since
26666<i>Postcondition</i> clauses  are specified for many  functions in the
26667standard,  including constructors  where they  obviously  cannot apply
26668after an  exception, it's not clear  whether this <i>Postcondition</i>
26669clause is intended to apply even after an exception.
26670
26671        </p>
26672        <p>
26673
26674It  might  be worth  noting  that  the  traditional behavior  (Classic
26675Iostreams  <code>fstream::close()</code> and  C <code>fclose()</code>)
26676is  to  close  the  <code>FILE</code> unconditionally,  regardless  of
26677errors.
26678
26679        </p>
26680
26681<p><i>[
26682See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#397">397</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#418">418</a> for related issues.
26683]</i></p>
26684
26685
26686
26687
26688<p><b>Proposed resolution:</b></p>
26689        <p>
26690
26691After discussing this  on the reflector (see the  thread starting with
26692c++std-lib-17650) we propose that <code>close()</code> be clarified to
26693match the traditional behavior, that is to close the <code>FILE</code>
26694unconditionally,  even after  errors or  exceptions.  In  addition, we
26695propose the dtor description be amended so as to explicitly require it
26696to catch and swallow any exceptions thrown by <code>close()</code>.
26697
26698        </p>
26699        <p>
26700
26701Specifically,   we   propose   to   make  the   following   edits   in
2670227.9.1.4 [filebuf.members]:
26703
26704        </p>
26705        <blockquote>
26706            <pre>
26707<code>basic_filebuf&lt;charT,traits&gt;* close();</code>
26708
26709            </pre>
26710            <p>
26711
26712<i>Effects</i>:  If <code>is_open()  == false</code>,  returns  a null
26713pointer.        If      a       put      area       exists,      calls
26714<code>overflow(traits::eof())</code> to flush  characters. If the last
26715virtual   member  function   called  on   <code>*this</code>  (between
26716<code>underflow</code>,  <code>overflow</code>,  <code>seekoff</code>,
26717and   <code>seekpos</code>)  was   <code>overflow</code>   then  calls
26718<code>a_codecvt.unshift</code> (possibly several times) to determine a
26719termination   sequence,    inserts   those   characters    and   calls
26720<code>overflow(traits::eof())</code>  again.  Finally<ins>, regardless
26721of whether  any of the preceding  calls fails or  throws an exception,
26722the  function</ins> <del>it</del>  closes   the  file   ("as   if"  by   calling
26723<code>std::fclose(file)</code>).<sup>334)</sup>  If any  of  the calls
26724<ins>made    by   the    function</ins><del>to   <code>overflow</code>
26725or</del><ins>,  including  </ins><code>std::fclose</code><ins>, </ins>
26726fails then <code>close</code> fails<ins>  by returning a null pointer.
26727If one of these calls throws an exception, the exception is caught and
26728rethrown after closing the file.</ins>
26729
26730            </p>
26731        </blockquote>
26732        <p>
26733
26734And to make the following edits in 27.9.1.2 [filebuf.cons].
26735
26736        </p>
26737        <blockquote>
26738            <pre>
26739<code>virtual ~basic_filebuf();</code>
26740
26741            </pre>
26742            <p>
26743
26744<i>Effects</i>:       Destroys      an      object       of      class
26745<code>basic_filebuf&lt;charT,traits&gt;</code>.                   Calls
26746<code>close()</code>.    <ins>If  an   exception  occurs   during  the
26747destruction of the object, including the call to <code>close()</code>,
26748the     exception    is     caught    but     not     rethrown    (see
2674917.6.4.11 [res.on.exception.handling]).</ins>
26750
26751            </p>
26752        </blockquote>
26753
26754
26755
26756
26757
26758<hr>
26759<h3><a name="623"></a>623. <code>pubimbue</code> forbidden to call <code>imbue</code></h3>
26760<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>
26761 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-01-20  <b>Last modified:</b> 2008-09-26</p>
26762<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
26763<p><b>Discussion:</b></p>
26764        <p>
26765
2676627.2.1 [iostream.limits.imbue]  specifies  that  "no  function  described  in
26767clause 27 except  for <code>ios_base::imbue</code> causes any instance
26768of                   <code>basic_ios::imbue</code>                  or
26769<code>basic_streambuf::imbue</code> to be called."
26770
26771        </p>
26772        <p>
26773
26774That      contradicts      the      <i>Effects</i>     clause      for
26775<code>basic_streambuf::pubimbue()</code>  which requires  the function
26776to do just that: call <code>basic_streambuf::imbue()</code>.
26777
26778        </p>
26779
26780
26781<p><b>Proposed resolution:</b></p>
26782        <p>
26783
26784To    fix   this,    rephrase    the   sentence    above   to    allow
26785<code>pubimbue</code> to do what  it was designed to do. Specifically.
26786change 27.2.1 [iostream.limits.imbue], p1 to read:
26787
26788        </p>
26789        <blockquote><p>
26790
26791No     function    described     in    clause     27     except    for
26792<code>ios_base::imbue</code>  <ins>and <code>basic_filebuf::pubimbue</code></ins>
26793causes    any    instance    of    <code>basic_ios::imbue</code>    or
26794<code>basic_streambuf::imbue</code> to be called. ...
26795
26796        </p></blockquote>
26797
26798
26799
26800
26801
26802<hr>
26803<h3><a name="624"></a>624. <code>valarray</code> assignment and arrays of unequal length</h3>
26804<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>
26805 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-01-20  <b>Last modified:</b> 2008-09-26</p>
26806<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
26807<p><b>Discussion:</b></p>
26808        <p>
26809
26810The behavior of the  <code>valarray</code> copy assignment operator is
26811defined only when both sides have  the same number of elements and the
26812spec is explicit about assignments of arrays of unequal lengths having
26813undefined behavior.
26814
26815        </p>
26816        <p>
26817
26818However, the generalized  subscripting assignment operators overloaded
26819on <code>slice_array</code>  et al (26.6.2.2 [valarray.assign])  don't have any
26820such restriction, leading  the reader to believe that  the behavior of
26821these  overloads is  well defined  regardless  of the  lengths of  the
26822arguments.
26823
26824        </p>
26825        <p>
26826
26827For example,  based on  the reading  of the spec  the behavior  of the
26828snippet below can be expected to be well-defined:
26829
26830        </p>
26831        <pre>    const std::slice from_0_to_3 (0, 3, 1);   // refers to elements 0, 1, 2
26832    const std::valarray&lt;int&gt; a (1, 3);        // a = { 1, 1, 1 }
26833    std::valarray&lt;int&gt;       b (2, 4);        // b = { 2, 2, 2, 2 }
26834
26835    b = a [from_0_to_3];
26836        </pre>
26837        <p>
26838
26839In practice, <code>b</code> may end up being <code>{ 1, 1, 1 }</code>,
26840<code>{  1,  1, 1,  2  }</code>,  or  anything else,  indicating  that
26841existing implementations vary.
26842
26843        </p>
26844
26845<p>
26846Quoting from Section 3.4, Assignment operators, of Al Vermeulen's
26847Proposal for Standard C++ Array Classes (see c++std-lib-704;
26848<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1993/N0308.asc">N0308</a>):
26849</p>
26850<blockquote><p>
26851  ...if the size of the array on the right hand side of the equal
26852  sign differs from the size of the array on the left, a run time
26853  error occurs. How this error is handled is implementation
26854  dependent; for compilers which support it, throwing an exception
26855  would be reasonable.
26856</p></blockquote>
26857
26858<p>
26859And see more history in
26860<a href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/1993/N0280.pdf">N0280</a>.
26861</p>
26862
26863        <p>
26864
26865It has  been argued in  discussions on the committee's  reflector that
26866the semantics of all <code>valarray</code> assignment operators should
26867be permitted to be undefined unless  the  length  of the arrays  being
26868assigned is the same as the length of the one being assigned from. See
26869the thread starting at c++std-lib-17786.
26870
26871        </p>
26872        <p>
26873
26874In order  to reflect  such views, the  standard must specify  that the
26875size of the  array referred to by the argument  of the assignment must
26876match the size of the array  under assignment, for example by adding a
26877<i>Requires</i> clause to 26.6.2.2 [valarray.assign] as follows:
26878
26879        </p>
26880        <blockquote><p>
26881
26882<i>Requires</i>: The length of the  array to which the argument refers
26883equals <code>size()</code>.
26884
26885        </p></blockquote>
26886
26887        <p>
26888
26889Note that it's  far from clear that such leeway  is necessary in order
26890to implement <code>valarray</code> efficiently.
26891
26892        </p>
26893
26894
26895<p><b>Proposed resolution:</b></p>
26896<p>
26897Insert new paragraph into 26.6.2.2 [valarray.assign]:
26898</p>
26899
26900<blockquote>
26901<pre>valarray&lt;T&gt;&amp; operator=(const slice_array&lt;T&gt;&amp;); 
26902valarray&lt;T&gt;&amp; operator=(const gslice_array&lt;T&gt;&amp;); 
26903valarray&lt;T&gt;&amp; operator=(const mask_array&lt;T&gt;&amp;); 
26904valarray&lt;T&gt;&amp; operator=(const indirect_array&lt;T&gt;&amp;);
26905</pre>
26906<blockquote>
26907<p><ins>
26908<i>Requires</i>: The length of the  array to which the argument refers
26909equals <code>size()</code>.
26910</ins></p>
26911<p>
26912These operators allow the results of a generalized subscripting operation to be assigned directly to a <tt>valarray</tt>.
26913</p>
26914</blockquote>
26915</blockquote>
26916
26917
26918
26919
26920
26921<hr>
26922<h3><a name="628"></a>628. Inconsistent definition of basic_regex constructor</h3>
26923<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#CD1">CD1</a>
26924 <b>Submitter:</b> Bo Persson <b>Opened:</b> 2007-01-23  <b>Last modified:</b> 2008-09-26</p>
26925<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>
26926<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
26927<p><b>Discussion:</b></p>
26928<p>
26929Section 28.8 [re.regex] lists a constructor
26930</p>
26931
26932<blockquote><pre>template&lt;class InputIterator&gt;
26933basic_regex(InputIterator first, InputIterator last,
26934                       flag_type f = regex_constants::ECMAScript);
26935</pre></blockquote>
26936
26937<p>
26938However, in section 28.8.2 [re.regex.construct], this constructor takes a 
26939pair of <tt>ForwardIterator</tt>.
26940</p>
26941
26942
26943<p><b>Proposed resolution:</b></p>
26944<p>
26945Change 28.8.2 [re.regex.construct]:
26946</p>
26947
26948<blockquote><pre>template &lt;class <del>ForwardIterator</del> <ins>InputIterator</ins>&gt;
26949  basic_regex(<del>ForwardIterator</del> <ins>InputIterator</ins> first, <del>ForwardIterator</del> <ins>InputIterator</ins> last, 
26950              flag_type f = regex_constants::ECMAScript);
26951</pre></blockquote>
26952
26953
26954
26955
26956
26957
26958<hr>
26959<h3><a name="629"></a>629. complex<t> insertion and locale dependence</t></h3>
26960<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>
26961 <b>Submitter:</b> Gabriel Dos Reis <b>Opened:</b> 2007-01-28  <b>Last modified:</b> 2008-09-26</p>
26962<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>
26963<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
26964<p><b>Discussion:</b></p>
26965<p>
26966is there an issue opened for (0,3) as complex number with
26967the French local?  With the English local, the above parses as an
26968imaginery complex number.  With the French locale it parses as a
26969real complex number.
26970</p>
26971
26972<p>
26973Further notes/ideas from the lib-reflector, messages 17982-17984:
26974</p>
26975
26976<blockquote>
26977<p>
26978Add additional entries in num_punct to cover the complex separator (French would be ';').
26979</p>
26980<p>
26981Insert a space before the comma, which should eliminate the ambiguity.
26982</p>
26983<p>
26984Solve the problem for ordered sequences in general, perhaps with a
26985dedicated facet.  Then complex should use that solution.
26986</p>
26987</blockquote>
26988
26989<p><i>[
26990Bellevue:
26991]</i></p>
26992
26993
26994<blockquote>
26995<p>
26996After much discussion, we agreed on the following: Add a footnote:
26997</p>
26998<p>
26999[In a locale in which comma is being used as a decimal point character,
27000inserting "showbase" into the output stream forces all outputs to show
27001an explicit decimal point character; then all inserted complex sequences
27002will extract unambiguously.]
27003</p>
27004<p>
27005And move this to READY status.
27006</p>
27007</blockquote>
27008
27009<p><i>[
27010Pre-Sophia Antipolis, Howard adds:
27011]</i></p>
27012
27013
27014<blockquote>
27015Changed "showbase" to "showpoint" and changed from Ready to Review.
27016</blockquote>
27017
27018<p><i>[
27019Post-Sophia Antipolis:
27020]</i></p>
27021
27022
27023<blockquote>
27024<p>
27025I neglected to pull this issue from the formal motions page after the "showbase" to "showpoint" change.
27026In Sophia Antipolis this change was reviewed by the LWG and the issue was set to Ready.  We subsequently
27027voted the footnote into the WP with "showbase".
27028</p>
27029<p>
27030I'm changing from WP back to Ready to pick up the "showbase" to "showpoint" change.
27031</p>
27032</blockquote>
27033
27034
27035
27036<p><b>Proposed resolution:</b></p>
27037<p>
27038Add a footnote to 26.4.6 [complex.ops] p16:
27039</p>
27040
27041<blockquote>
27042[In a locale in which comma is being used as a decimal point character,
27043inserting <tt>showpoint</tt> into the output stream forces all outputs to show
27044an explicit decimal point character; then all inserted complex sequences
27045will extract unambiguously.]
27046</blockquote>
27047
27048
27049
27050
27051
27052<hr>
27053<h3><a name="630"></a>630. arrays of valarray</h3>
27054<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#WP">WP</a>
27055 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-01-28  <b>Last modified:</b> 2009-10-26</p>
27056<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>
27057<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
27058<p><b>Discussion:</b></p>
27059        <p>
27060
27061Section 26.2 [numeric.requirements], p1     suggests     that     a
27062<code>valarray</code>  specialization on  a  type <code>T</code>  that
27063satisfies  the requirements enumerated  in the  paragraph is  itself a
27064valid  type   on  which  <code>valarray</code>   may  be  instantiated
27065(Footnote       269        makes       this       clear).        I.e.,
27066<code>valarray&lt;valarray&lt;T&gt;  &gt;</code> is  valid as  long as
27067<code>T</code>   is   valid.    However,  since   implementations   of
27068<code>valarray</code> are permitted to initialize storage allocated by
27069the class by  invoking the default ctor of  <code>T</code> followed by
27070the    copy    assignment    operator,   such    implementations    of
27071<code>valarray</code>   wouldn't  work  with   (perhaps  user-defined)
27072specializations of <code>valarray</code> whose assignment operator had
27073undefined behavior when the size of its argument didn't match the size
27074of <code>*this</code>.  By <i>"wouldn't work"</i> I mean that it would
27075be  impossible  to resize  such  an array  of  arrays  by calling  the
27076<code>resize()</code> member  function on it if the  function used the
27077copy  assignment operator  after constructing  all elements  using the
27078default  ctor (e.g.,  by invoking  <code>new  value_type[N]</code>) to
27079obtain default-initialized storage) as it's permitted to do.
27080
27081        </p>
27082        <p>
27083
27084Stated      more     generally,      the      problem     is      that
27085<code>valarray&lt;valarray&lt;T&gt;  &gt;::resize(size_t)</code> isn't
27086required or  guaranteed to have well-defined semantics  for every type
27087<code>T</code>     that      satisfies     all     requirements     in
2708826.2 [numeric.requirements].
27089
27090        </p>
27091        <p>
27092
27093I  believe  this  problem  was  introduced  by  the  adoption  of  the
27094resolution                outlined                in                <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1996/N0857.asc">N0857</a>,
27095<i>Assignment  of  valarrays</i>,  from  1996.   The  copy  assignment
27096operator  of  the original  numerical  array  classes  proposed in  <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1993/N0280.pdf">N0280</a>,
27097as      well       as      the      one       proposed      in      <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1993/N0308.asc">N0308</a>
27098(both  from 1993), had  well-defined semantics  for arrays  of unequal
27099size (the  latter explicitly  only when <code>*this</code>  was empty;
27100assignment of non empty arrays of unequal size was a runtime error).
27101
27102        </p>
27103        <p>
27104
27105The  justification for  the  change given  in  N0857 was the "loss  of
27106performance [deemed]  only significant  for very simple  operations on
27107small arrays or for architectures with very few registers."
27108
27109        </p>
27110        <p>
27111
27112Since tiny  arrays on a  limited subset of hardware  architectures are
27113likely  to  be  an   exceedingly  rare  case  (despite  the  continued
27114popularity of  x86) I  propose to revert  the resolution and  make the
27115behavior    of   all   <code>valarray</code>    assignment   operators
27116well-defined even  for non-conformal  arrays (i.e., arrays  of unequal
27117size).   I have implemented  this change  and measured  no significant
27118degradation  in performance in  the common  case (non-empty  arrays of
27119equal size).  I  have measured a 50% (and in  some cases even greater)
27120speedup  in the  case of  assignments to  empty arrays  versus calling
27121<code>resize()</code>  first followed  by  an invocation  of the  copy
27122assignment operator.
27123
27124        </p>
27125
27126<p><i>[
27127Bellevue:
27128]</i></p>
27129
27130
27131<blockquote>
27132If no proposed wording by June meeting, this issue should be closed NAD.
27133</blockquote>
27134
27135<p><i>[
271362009-07 Frankfurt
27137]</i></p>
27138
27139
27140<blockquote>
27141<p>
27142Move resolution 1 to Ready.
27143</p>
27144<p>
27145Howard: second resolution has been commented out (made invisible).
27146Can be brought back on demand.
27147</p>
27148</blockquote>
27149
27150
27151
27152<p><b>Proposed resolution:</b></p>
27153        <p>
27154
27155Change 26.6.2.2 [valarray.assign], p1 as follows:
27156
27157        </p>
27158        <blockquote>
27159            <p>
27160                <code>
27161
27162valarray&lt;T&gt;&amp; operator=(const valarray&lt;T&gt;&amp;<ins> x</ins>);
27163
27164                </code>
27165            </p>
27166            <p>
27167
27168-1- Each element of the <code>*this</code> array is assigned the value
27169of  the  corresponding  element   of  the  argument  array.   <del>The
27170resulting behavior is undefined if </del><ins>When </ins>the length of
27171the  argument  array  is  not   equal  to  the  length  of  the  *this
27172array<del>.</del><ins>  resizes  <code>*this</code>  to make  the  two
27173arrays     the      same     length,     as      if     by     calling
27174<code>resize(x.size())</code>, before performing the assignment.</ins>
27175
27176            </p>
27177        </blockquote>
27178        <p>
27179
27180And  add a new  paragraph just  below paragraph  1 with  the following
27181text:
27182
27183        </p>
27184        <blockquote>
27185            <p>
27186
27187<ins>-2- <i>Postcondition</i>: <code>size() == x.size()</code>.</ins>
27188
27189            </p>
27190        </blockquote>
27191        <p>
27192
27193Also add the following paragraph to 26.6.2.2 [valarray.assign], immediately after p4:
27194
27195        </p>
27196        <blockquote>
27197            <p>
27198
27199<ins>-?- When the length,  <i><code>N</code></i> of the array referred
27200to by the  argument is not equal to  the length of <code>*this</code>,
27201the  operator resizes <code>*this</code>  to make  the two  arrays the
27202same  length, as if  by calling  <code>resize(<i>N</i>)</code>, before
27203performing the assignment.</ins>
27204
27205            </p>
27206        </blockquote>
27207
27208<p><i>[
27209pre-Sophia Antipolis, Martin adds the following compromise wording, but
27210prefers the original proposed resolution:
27211]</i></p>
27212
27213
27214
27215
27216
27217
27218<p><i>[
27219Kona (2007): Gaby to propose wording for an alternative resolution in
27220which you can assign to a <tt>valarray</tt> of size 0, but not to any other
27221<tt>valarray</tt> whose size is unequal to the right hand side of the assignment.
27222]</i></p>
27223
27224
27225
27226
27227
27228<hr>
27229<h3><a name="634"></a>634. <tt>allocator.address()</tt> doesn't work for types overloading <tt>operator&amp;</tt></h3>
27230<p><b>Section:</b> 20.8.8.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
27231 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2007-02-07  <b>Last modified:</b> 2008-09-26</p>
27232<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>
27233<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
27234<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a></p>
27235<p><b>Discussion:</b></p>
27236
27237<p>
2723820.8.8.1 [allocator.members] says:
27239</p>
27240<blockquote>
27241<pre>pointer address(reference <i>x</i>) const;</pre>
27242<blockquote>
27243<p>
27244-1- <i>Returns:</i> <tt>&amp;<i>x</i></tt>.
27245</p>
27246</blockquote>
27247</blockquote>
27248
27249<p>
2725020.8.8.1 [allocator.members] defines <tt>CopyConstructible</tt> which currently not
27251only defines the semantics of copy construction, but also restricts what an overloaded
27252<tt>operator&amp;</tt> may do.  I believe proposals are in the works (such as concepts
27253and rvalue reference) to decouple these two requirements.  Indeed it is not evident
27254that we should disallow overloading <tt>operator&amp;</tt> to return something other
27255than the address of <tt>*this</tt>.
27256</p>
27257
27258<p>
27259An example of when you want to overload <tt>operator&amp;</tt> to return something
27260other than the object's address is proxy references such as <tt>vector&lt;bool&gt;</tt>
27261(or its replacement, currently code-named <tt>bit_vector</tt>).  Taking the address of
27262such a proxy reference should logically yield a proxy pointer, which when dereferenced,
27263yields a copy of the original proxy reference again.
27264</p>
27265
27266<p>
27267On the other hand, some code truly needs the address of an object, and not a proxy
27268(typically for determining the identity of an object compared to a reference object).
27269<a href="http://www.boost.org/">boost</a> has long recognized this dilemma and solved it with 
27270<a href="http://www.boost.org/libs/utility/utility.htm#addressof"><tt>boost::addressof</tt></a>.
27271It appears to me that this would be useful functionality for the default allocator.  Adopting
27272this definition for <tt>allocator::address</tt> would free the standard of requiring
27273anything special from types which overload <tt>operator&amp;</tt>.  Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#580">580</a>
27274is expected to make use of <tt>allocator::address</tt> mandatory for containers.
27275</p>
27276
27277
27278
27279<p><b>Proposed resolution:</b></p>
27280<p>
27281Change 20.8.8.1 [allocator.members]:
27282</p>
27283
27284<blockquote>
27285<pre>pointer address(reference <i>x</i>) const;</pre>
27286<blockquote>
27287<p>
27288-1- <i>Returns:</i> <del><tt>&amp;<i>x</i></tt>.</del> <ins>The actual address of object referenced by <i>x</i>,
27289even in the presence of an overloaded <tt>operator&amp;</tt>.</ins>
27290</p>
27291</blockquote>
27292
27293<pre>const_pointer address(address(const_reference <i>x</i>) const;</pre>
27294<blockquote>
27295<p>
27296-2- <i>Returns:</i> <del><tt>&amp;<i>x</i></tt>.</del> <ins>The actual address of object referenced by <i>x</i>,
27297even in the presence of an overloaded <tt>operator&amp;</tt>.</ins>
27298</p>
27299</blockquote>
27300</blockquote>
27301
27302<p><i>[
27303post Oxford:  This would be rendered NAD Editorial by acceptance of
27304<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2257.html">N2257</a>.
27305]</i></p>
27306
27307
27308<p><i>[
27309Kona (2007): The LWG adopted the proposed resolution of N2387 for this issue which
27310was subsequently split out into a separate paper N2436 for the purposes of voting.
27311The resolution in N2436 addresses this issue.  The LWG voted to accelerate this
27312issue to Ready status to be voted into the WP at Kona.
27313]</i></p>
27314
27315
27316
27317
27318
27319
27320
27321<hr>
27322<h3><a name="638"></a>638. deque end invalidation during erase</h3>
27323<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>
27324 <b>Submitter:</b> Steve LoBasso <b>Opened:</b> 2007-02-17  <b>Last modified:</b> 2008-09-26</p>
27325<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
27326<p><b>Discussion:</b></p>
27327<p>
27328The standard states at 23.3.2.3 [deque.modifiers]/4:
27329</p>
27330<blockquote><pre>deque erase(...)
27331</pre>
27332 <p>
27333<i>Effects:</i> ... An erase at either end of the deque invalidates only
27334the iterators and the references to the erased elements.
27335</p>
27336</blockquote>
27337<p>
27338This does not state that iterators to end will be invalidated.
27339It needs to be amended in such a way as to account for end invalidation.
27340</p>
27341<p>
27342Something like:
27343</p>
27344<blockquote><p>
27345Any time the last element is erased, iterators to end are invalidated.
27346</p></blockquote>
27347
27348<p>
27349This would handle situations like:
27350</p>
27351<blockquote><pre>erase(begin(), end())
27352erase(end() - 1)
27353pop_back()
27354resize(n, ...) where n &lt; size()
27355pop_front() with size() == 1
27356
27357</pre></blockquote>
27358
27359<p><i>[
27360Post Kona, Steve LoBasso notes:
27361]</i></p>
27362
27363
27364<blockquote>
27365My only issue with the proposed resolution is that it might not be clear
27366that <tt>pop_front()</tt> [where <tt>size() == 1</tt>] can invalidate past-the-end
27367iterators.
27368</blockquote>
27369
27370
27371
27372<p><b>Proposed resolution:</b></p>
27373<p>
27374Change 23.3.2.3 [deque.modifiers], p4:
27375</p>
27376
27377<blockquote>
27378<pre>iterator erase(const_iterator position); 
27379iterator erase(const_iterator first, const_iterator last);
27380</pre>
27381
27382<blockquote>
27383<p>
27384-4- <i>Effects:</i> An erase in the middle of the <tt>deque</tt>
27385invalidates all the iterators and references to elements of the
27386<tt>deque</tt> <ins>and the past-the-end iterator</ins>. An erase at
27387either end of the <tt>deque</tt> invalidates only the iterators and the
27388references to the erased elements<ins>, except that erasing at the end
27389also invalidates the past-the-end iterator</ins>.
27390</p>
27391</blockquote>
27392</blockquote>
27393
27394
27395
27396<p><i>[
27397Kona (2007): Proposed wording added and moved to Review.
27398]</i></p>
27399
27400
27401<p><i>[
27402Bellevue:
27403]</i></p>
27404
27405
27406<blockquote>
27407Note that there is existing code that relies on iterators not being
27408invalidated, but there are also existing implementations that do
27409invalidate iterators. Thus, such code is not portable in any case. There
27410is a pop_front() note, which should possibly be a separate issue. Mike
27411Spertus to evaluate and, if need be, file an issue.
27412</blockquote>
27413
27414
27415
27416
27417<hr>
27418<h3><a name="640"></a>640. 27.6.2.5.2 does not handle (unsigned) long long</h3>
27419<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>
27420 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2007-02-17  <b>Last modified:</b> 2008-09-26</p>
27421<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>
27422<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
27423<p><b>Discussion:</b></p>
27424<p>
27425The arithmetic inserters are described in 27.7.2.6.2 [ostream.inserters.arithmetic].
27426Although the section starts with a listing of the inserters including
27427the new ones:
27428</p>
27429
27430<blockquote><pre>operator&lt;&lt;(long long val );
27431operator&lt;&lt;(unsigned long long val );
27432</pre></blockquote>
27433
27434<p>
27435the text in paragraph 1, which describes the corresponding effects
27436of the inserters, depending on the actual type of val, does not
27437handle the types <tt>long long</tt> and <tt>unsigned long long</tt>.
27438</p>
27439
27440<p><i>[
27441Alisdair: In addition to the (unsigned) long long problem, that whole paragraph
27442misses any reference to extended integral types supplied by the
27443implementation - one of the additions by core a couple of working papers
27444back.
27445]</i></p>
27446
27447
27448
27449
27450<p><b>Proposed resolution:</b></p>
27451<p>
27452In 27.7.2.6.2 [ostream.inserters.arithmetic]/1 change the third sentence
27453</p>
27454
27455<blockquote>
27456When val is of type <tt>bool</tt>, <tt>long</tt>, <tt>unsigned
27457long</tt>, <ins>long long, unsigned long long,</ins> <tt>double</tt>,
27458<tt>long double</tt>, or <tt>const void*</tt>, the formatting conversion
27459occurs as if it performed the following code fragment:
27460</blockquote>
27461
27462
27463
27464
27465
27466<hr>
27467<h3><a name="643"></a>643. Impossible "as if" clauses</h3>
27468<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>
27469 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2007-02-20  <b>Last modified:</b> 2008-09-26</p>
27470<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
27471<p><b>Discussion:</b></p>
27472<p>
27473The current standard 14882:2003(E) as well as N2134 have the
27474following
27475defects:
27476</p>
27477
27478<p>
2747927.9.1.1 [filebuf]/5 says:
27480</p>
27481
27482<blockquote>
27483<p>
27484In order to support file I/O and multibyte/wide character conversion, conversions are performed using members of a 
27485facet, referred to as <tt><i>a_codecvt</i></tt> in following sections, obtained "as if" by
27486</p>
27487<blockquote><pre>codecvt&lt;charT,char,typename traits::state_type&gt; <i>a_codecvt</i> =
27488  use_facet&lt;codecvt&lt;charT,char,typename traits::state_type&gt; &gt;(getloc());
27489</pre></blockquote>
27490</blockquote>
27491
27492<p>
27493<tt>use_facet</tt> returns a <tt>const facet</tt> reference and no facet is
27494copyconstructible, so the codecvt construction should fail to compile.
27495</p>
27496
27497<p>
27498A similar issue arises in 22.4.2.2.2 [facet.num.put.virtuals]/15 for <tt>num_punct</tt>.
27499</p>
27500
27501
27502<p><b>Proposed resolution:</b></p>
27503<p>
27504In 27.9.1.1 [filebuf]/5 change the "as if" code
27505</p>
27506
27507<blockquote><pre><ins>const </ins>codecvt&lt;charT,char,typename traits::state_type&gt;<ins>&amp;</ins> <i>a_codecvt</i> =
27508  use_facet&lt;codecvt&lt;charT,char,typename traits::state_type&gt; &gt;(getloc());
27509</pre></blockquote>
27510
27511<p>
27512In 22.4.2.2.2 [facet.num.put.virtuals]/15 (This is para 5 in N2134) change
27513</p>
27514
27515<blockquote>
27516<p>
27517A local variable <tt><i>punct</i></tt> is initialized via
27518</p>
27519<blockquote><pre><ins>const </ins>numpunct&lt;charT&gt;<ins>&amp;</ins> <i>punct</i> = use_facet&lt; numpunct&lt;charT&gt; &gt;(<i>str</i>.getloc() )<ins>;</ins>
27520</pre></blockquote>
27521</blockquote>
27522
27523<p>
27524(Please note also the additional provided trailing semicolon)
27525</p>
27526
27527
27528
27529
27530
27531
27532<hr>
27533<h3><a name="646"></a>646. const incorrect match_result members</h3>
27534<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#CD1">CD1</a>
27535 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2007-02-26  <b>Last modified:</b> 2008-09-26</p>
27536<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
27537<p><b>Discussion:</b></p>
27538<p>
2753928.10.4 [re.results.form] (root and para 3) in N2134 defines the two function template
27540members format as non-const functions, although they are declared
27541as const in 28.10 [re.results]/3.
27542</p>
27543
27544
27545<p><b>Proposed resolution:</b></p>
27546<p>
27547Add the missing <tt>const</tt> specifier to both <tt>format</tt> overloads described
27548in section 28.10.4 [re.results.form].
27549</p>
27550
27551
27552
27553
27554
27555<hr>
27556<h3><a name="650"></a>650. regex_token_iterator and const correctness</h3>
27557<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#CD1">CD1</a>
27558 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2007-03-05  <b>Last modified:</b> 2008-09-26</p>
27559<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>
27560<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
27561<p><b>Discussion:</b></p>
27562<p>
27563Both the class definition of regex_token_iterator (28.12.2
27564[re.tokiter]/6) and the latter member specifications (28.12.2.2
27565[re.tokiter.comp]/1+2) declare both comparison operators as
27566non-const functions. Furtheron, both dereference operators are
27567unexpectedly also declared as non-const in 28.12.2 [re.tokiter]/6
27568as well as in (28.12.2.3 [re.tokiter.deref]/1+2).
27569</p>
27570
27571
27572<p><b>Proposed resolution:</b></p>
27573<p>
275741) In (28.12.2 [re.tokiter]/6) change the current declarations
27575</p>
27576
27577<blockquote><pre>bool operator==(const regex_token_iterator&amp;) <ins>const</ins>;
27578bool operator!=(const regex_token_iterator&amp;) <ins>const</ins>;
27579const value_type&amp; operator*() <ins>const</ins>;
27580const value_type* operator-&gt;() <ins>const</ins>;
27581</pre></blockquote>
27582
27583<p>
275842) In 28.12.2.2 [re.tokiter.comp] change the following declarations
27585</p>
27586
27587<blockquote><pre>bool operator==(const regex_token_iterator&amp; right) <ins>const</ins>;
27588bool operator!=(const regex_token_iterator&amp; right) <ins>const</ins>;
27589</pre></blockquote>
27590
27591<p>
275923) In 28.12.2.3 [re.tokiter.deref] change the following declarations
27593</p>
27594
27595<blockquote><pre>const value_type&amp; operator*() <ins>const</ins>;
27596const value_type* operator-&gt;() <ins>const</ins>;
27597</pre></blockquote>
27598
27599
27600<p><i>[
27601Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue (which
27602is to adopt the proposed wording in this issue).
27603The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
27604]</i></p>
27605
27606
27607
27608
27609
27610<hr>
27611<h3><a name="651"></a>651. Missing preconditions for regex_token_iterator c'tors</h3>
27612<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#CD1">CD1</a>
27613 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2007-03-05  <b>Last modified:</b> 2008-09-26</p>
27614<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>
27615<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
27616<p><b>Discussion:</b></p>
27617<p>
27618The text provided in 28.12.2.1 [re.tokiter.cnstr]/2+3 describes
27619the effects of the three non-default constructors of class
27620template regex_token_iterator but is does not clarify which values
27621are legal values for submatch/submatches. This becomes
27622an issue, if one takes 28.12.2 [re.tokiter]/9 into account, which explains
27623the notion of a "current match" by saying:
27624</p>
27625
27626<blockquote><p>
27627The <i>current match</i> is <tt>(*position).prefix()</tt> if <tt>subs[N]
27628== -1</tt>, or <tt>(*position)[subs[N]]</tt> for any other value of
27629<tt>subs[N]</tt>.
27630</p></blockquote>
27631
27632<p>
27633It's not clear to me, whether other negative values except -1
27634are legal arguments or not - it seems they are not.
27635</p>
27636
27637
27638<p><b>Proposed resolution:</b></p>
27639<p>
27640Add the following precondition paragraph just before the current
2764128.12.2.1 [re.tokiter.cnstr]/2:
27642</p>
27643
27644<blockquote><p>
27645<i>Requires:</i> Each of the initialization values of <tt>subs</tt> must be <tt>&gt;= -1</tt>.
27646</p></blockquote>
27647
27648
27649<p><i>[
27650Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue (which
27651is to adopt the proposed wording in this issue).
27652The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
27653]</i></p>
27654
27655
27656
27657
27658
27659<hr>
27660<h3><a name="652"></a>652. regex_iterator and const correctness</h3>
27661<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#CD1">CD1</a>
27662 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2007-03-05  <b>Last modified:</b> 2008-09-26</p>
27663<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
27664<p><b>Discussion:</b></p>
27665<p>Both the class definition of regex_iterator (28.12.1 [re.regiter]/1)
27666and the latter member specification (28.12.1.2 [re.regiter.comp]/1+2)
27667declare both comparison operators as
27668non-const functions. Furtheron, both dereference operators are
27669unexpectedly also declared as non-const in 28.12.1 [re.regiter]/1
27670as well as in (28.12.1.3 [re.regiter.deref]/1+2).
27671</p>
27672
27673
27674<p><b>Proposed resolution:</b></p>
27675<p>
276761) In (28.12.1 [re.regiter]/1) change the current declarations
27677</p>
27678
27679<blockquote><pre>bool operator==(const regex_iterator&amp;) <ins>const</ins>;
27680bool operator!=(const regex_iterator&amp;) <ins>const</ins>;
27681const value_type&amp; operator*() <ins>const</ins>;
27682const value_type* operator-&gt;() <ins>const</ins>;
27683</pre></blockquote>
27684
27685<p>
276862) In 28.12.1.3 [re.regiter.deref] change the following declarations
27687</p>
27688
27689<blockquote><pre>const value_type&amp; operator*() <ins>const</ins>;
27690const value_type* operator-&gt;() <ins>const</ins>;
27691</pre></blockquote>
27692
27693<p>
276943) In 28.12.1.2 [re.regiter.comp] change the following declarations
27695</p>
27696
27697<blockquote><pre>bool operator==(const regex_iterator&amp; right) <ins>const</ins>;
27698bool operator!=(const regex_iterator&amp; right) <ins>const</ins>;
27699</pre></blockquote>
27700
27701
27702<p><i>[
27703Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue (which
27704is to adopt the proposed wording in this issue).
27705The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
27706]</i></p>
27707
27708
27709
27710
27711
27712<hr>
27713<h3><a name="654"></a>654. Missing IO roundtrip for random number engines</h3>
27714<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>
27715 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2007-03-08  <b>Last modified:</b> 2009-05-01</p>
27716<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>
27717<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
27718<p><b>Discussion:</b></p>
27719<p>
27720Table 98 and para 5 in X [rand.req.eng] specify
27721the IO insertion and extraction semantic of random
27722number engines. It can be shown, v.i., that the specification
27723of the extractor cannot guarantee to fulfill the requirement
27724from para 5:
27725</p>
27726
27727<blockquote><p>
27728If a textual representation written via os &lt;&lt; x was
27729subsequently read via is &gt;&gt; v, then x == v provided that
27730there have been no intervening invocations of x or of v.
27731</p></blockquote>
27732
27733<p>
27734The problem is, that the extraction process described in
27735table 98 misses to specify that it will initially set the
27736if.fmtflags to ios_base::dec, see table 104:
27737</p>
27738
27739<blockquote><p>
27740dec: converts integer input or generates integer output
27741in decimal base
27742</p></blockquote>
27743
27744<p>
27745Proof: The following small program demonstrates the violation
27746of requirements (exception safety not fulfilled):
27747</p>
27748
27749<blockquote><pre>#include &lt;cassert&gt;
27750#include &lt;ostream&gt;
27751#include &lt;iostream&gt;
27752#include &lt;iomanip&gt;
27753#include &lt;sstream&gt;
27754
27755class RanNumEngine {
27756  int state;
27757public:
27758  RanNumEngine() : state(42) {}
27759
27760  bool operator==(RanNumEngine other) const {
27761      return state == other.state;
27762  }
27763
27764  template &lt;typename Ch, typename Tr&gt;
27765  friend std::basic_ostream&lt;Ch, Tr&gt;&amp; operator&lt;&lt;(std::basic_ostream&lt;Ch, Tr&gt;&amp; os, RanNumEngine engine) {
27766    Ch old = os.fill(os.widen(' ')); // Sets space character
27767    std::ios_base::fmtflags f = os.flags();
27768    os &lt;&lt; std::dec &lt;&lt; std::left &lt;&lt; engine.state; // Adds ios_base::dec|ios_base::left
27769    os.fill(old); // Undo
27770    os.flags(f);
27771    return os;
27772  }
27773
27774  template &lt;typename Ch, typename Tr&gt;
27775  friend std::basic_istream&lt;Ch, Tr&gt;&amp; operator&gt;&gt;(std::basic_istream&lt;Ch, Tr&gt;&amp; is, RanNumEngine&amp; engine) {
27776       // Uncomment only for the fix.
27777
27778    //std::ios_base::fmtflags f = is.flags();
27779    //is &gt;&gt; std::dec;
27780    is &gt;&gt; engine.state;
27781    //is.flags(f);
27782    return is;
27783  }
27784};
27785
27786int main() {
27787    std::stringstream s;
27788    s &lt;&lt; std::setfill('#'); // No problem
27789        s &lt;&lt; std::oct; // Yikes!
27790        // Here starts para 5 requirements:
27791    RanNumEngine x;
27792    s &lt;&lt; x;
27793    RanNumEngine v;
27794    s &gt;&gt; v;
27795    assert(x == v); // Fails: 42 == 34
27796}
27797</pre></blockquote>
27798
27799<p>
27800A second, minor issue seems to be, that the insertion
27801description from table 98 unnecessarily requires the
27802addition of ios_base::fixed (which only influences floating-point
27803numbers). Its not entirely clear to me whether the proposed
27804standard does require that the state of random number engines
27805is stored in integral types or not, but I have the impression
27806that this is the indent, see e.g. p. 3
27807</p>
27808
27809<blockquote><p>
27810The specification of each random number engine defines the
27811size of its state in multiples of the size of its result_type.
27812</p></blockquote>
27813
27814<p>
27815If other types than integrals are supported, then I wonder why
27816no requirements are specified for the precision of the stream.
27817</p>
27818
27819<p>
27820See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
27821<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
27822for some further discussion.
27823</p>
27824
27825
27826<p><b>Proposed resolution:</b></p>
27827<p>
27828Adopt the proposed resolution in
27829<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
27830</p>
27831
27832
27833<p><i>[
27834Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
27835The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
27836]</i></p>
27837
27838
27839
27840
27841
27842<hr>
27843<h3><a name="655"></a>655. Signature of generate_canonical not useful</h3>
27844<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>
27845 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2007-03-08  <b>Last modified:</b> 2008-09-26</p>
27846<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>
27847<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
27848<p><b>Discussion:</b></p>
27849<p>
27850In 26.5.1 [rand.synopsis] we have the declaration
27851</p>
27852
27853<blockquote><pre>template&lt;class RealType, class UniformRandomNumberGenerator,
27854  size_t bits&gt;
27855result_type generate_canonical(UniformRandomNumberGenerator&amp; g);
27856</pre></blockquote>
27857
27858<p>
27859Besides the "result_type" issue (already recognized by Bo Persson
27860at Sun, 11 Feb 2007 05:26:47 GMT in this group) it's clear, that
27861the template parameter order is not reasonably choosen: Obviously
27862one always needs to specify all three parameters, although usually
27863only two are required, namely the result type RealType and the
27864wanted bits, because UniformRandomNumberGenerator can usually
27865be deduced.
27866</p>
27867
27868<p>
27869See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
27870<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
27871for some further discussion.
27872</p>
27873
27874
27875<p><b>Proposed resolution:</b></p>
27876<p>
27877Adopt the proposed resolution in
27878<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
27879</p>
27880
27881
27882<p><i>[
27883Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
27884The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
27885]</i></p>
27886
27887
27888
27889
27890
27891<hr>
27892<h3><a name="659"></a>659. istreambuf_iterator should have an operator-&gt;()</h3>
27893<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#WP">WP</a>
27894 <b>Submitter:</b> Niels Dekker <b>Opened:</b> 2007-03-25  <b>Last modified:</b> 2009-10-26</p>
27895<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>
27896<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
27897<p><b>Discussion:</b></p>
27898<p>
27899Greg Herlihy has clearly demonstrated that a user defined input
27900iterator should have an operator-&gt;(), even if its
27901value type is a built-in type (comp.std.c++, "Re: Should any iterator
27902have an operator-&gt;() in C++0x?", March 2007).  And as Howard
27903Hinnant remarked in the same thread that the input iterator
27904<tt>istreambuf_iterator</tt> doesn't have one, this must be a
27905defect!
27906</p>
27907<p>
27908Based on Greg's example, the following code demonstrates the issue:
27909</p><pre> #include &lt;iostream&gt; 
27910 #include &lt;fstream&gt;
27911 #include &lt;streambuf&gt; 
27912
27913 typedef char C;
27914 int main ()
27915 {
27916   std::ifstream s("filename", std::ios::in);
27917   std::istreambuf_iterator&lt;char&gt; i(s);
27918
27919   (*i).~C();  // This is well-formed...
27920   i-&gt;~C();  // ... so this should be supported!
27921 }
27922</pre>
27923
27924<p>
27925Of course, operator-&gt; is also needed when the value_type of
27926istreambuf_iterator is a class.
27927</p>
27928<p>
27929The operator-&gt; could be implemented in various ways.  For instance,
27930by storing the current value inside the iterator, and returning its
27931address.  Or by returning a proxy, like operator_arrow_proxy, from
27932<a href="http://www.boost.org/boost/iterator/iterator_facade.hpp">http://www.boost.org/boost/iterator/iterator_facade.hpp</a>
27933</p>
27934<p>
27935I hope that the resolution of this issue will contribute to getting a
27936clear and consistent definition of iterator concepts.
27937</p>
27938
27939<p><i>[
27940Kona (2007): The proposed resolution is inconsistent because the return
27941type of <tt>istreambuf_iterator::operator-&gt;()</tt> is specified to be <tt>pointer</tt>,
27942but the proposed text also states that "<tt>operator-&gt;</tt> may return a proxy."
27943]</i></p>
27944
27945
27946<p><i>[
27947Niels Dekker (mailed to Howard Hinnant):
27948]</i></p>
27949
27950<blockquote>
27951<p>
27952The proposed resolution does
27953not seem inconsistent to me. <tt>istreambuf_iterator::operator-&gt;()</tt> should
27954have <tt>istreambuf_iterator::pointer</tt> as return type, and this return type
27955may in fact be a proxy.
27956</p>
27957<p>
27958AFAIK, the resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#445">445</a> ("<tt>iterator_traits::reference</tt>
27959unspecified for some iterator categories") implies that for any iterator
27960class <tt>Iter</tt>, the return type of <tt>operator-&gt;()</tt> is <tt>Iter::pointer</tt>, by
27961definition.  I don't think <tt>Iter::pointer</tt> needs to be a raw pointer.
27962</p>
27963<p>
27964Still I wouldn't mind if the text "<tt>operator-&gt;</tt> may return a proxy" would
27965be removed from the resolution. I think it's up to the library
27966implementation, how to implement <tt>istreambuf_iterator::operator-&gt;()</tt>.  As
27967longs as it behaves as expected: <tt>i-&gt;m</tt> should have the same effect as
27968<tt>(*i).m</tt>. Even for an explicit destructor call, <tt>i-&gt;~C()</tt>.  The main issue
27969is just: <tt>istreambuf_iterator</tt> should have an <tt>operator-&gt;()</tt>!
27970</p>
27971</blockquote>
27972
27973<p><i>[
279742009-04-30 Alisdair adds:
27975]</i></p>
27976
27977
27978<blockquote>
27979Note that operator-&gt; is now a requirement in the <tt>InputIterator</tt> concept, so
27980this issue cannot be ignored or existing valid programs will break when
27981compiled with an 0x library.
27982</blockquote>
27983
27984<p><i>[
279852009-05-29 Alisdair adds:
27986]</i></p>
27987
27988
27989<blockquote>
27990<p>
27991I agree with the observation that in principle the type 'pointer' may be a
27992proxy, and the words highlighting this are redundant.
27993</p>
27994<p>
27995However, in the current draught <tt>pointer</tt> is required to be exactly '<tt>charT *</tt>'
27996by the derivation from <tt>std::iterator</tt>.  At a minimum, the 4th parameter of
27997this base class template should become unspecified.  That permits the
27998introduction of a proxy as a nested class in some further undocumented (not
27999even exposition-only) base.
28000</p>
28001<p>
28002It also permits the <tt>istream_iterator</tt> approach where the cached value is
28003stored in the iterator itself, and the iterator serves as its own proxy for
28004post-increment <tt>operator++</tt> - removing the need for the existing
28005exposition-only nested class <tt>proxy</tt>.
28006</p>
28007<p>
28008Note that the current <tt>proxy</tt> class also has exactly the right properties to
28009serve as the pointer <tt>proxy</tt> too.  This is likely to be a common case where an
28010<tt>InputIterator</tt> does not hold internal state but delegates to another class.
28011</p>
28012<p>
28013Proposed Resolution:
28014</p>
28015<p>
28016In addition to the current proposal:
28017</p>
28018<p>
2801924.6.3 [istreambuf.iterator]
28020</p>
28021<blockquote><pre>template&lt;class charT, class traits = char_traits&lt;charT&gt; &gt;
28022class istreambuf_iterator
28023  : public iterator&lt;input_iterator_tag, charT,
28024                    typename traits::off_type, <del>charT*</del> <ins><i>unspecified</i></ins>, charT&gt; {
28025</pre></blockquote>
28026</blockquote>
28027
28028<p><i>[
280292009-07 Frankfurt
28030]</i></p>
28031
28032
28033<blockquote>
28034<p>
28035Move the additional part into the proposed resolution, and wrap the
28036descriptive text in a Note.
28037</p>
28038<p><i>[Howard: done.]</i></p>
28039
28040<p>
28041Move to Ready.
28042</p>
28043</blockquote>
28044
28045
28046
28047<p><b>Proposed resolution:</b></p>
28048<p>
28049Add to the synopsis in 24.6.3 [istreambuf.iterator]:
28050</p>
28051
28052<blockquote><pre>charT operator*() const;
28053<ins>pointer operator-&gt;() const;</ins>
28054istreambuf_iterator&lt;charT,traits&gt;&amp; operator++();
28055</pre></blockquote>
28056
28057<p>
2805824.6.3 [istreambuf.iterator]
28059</p>
28060
28061<blockquote><pre>template&lt;class charT, class traits = char_traits&lt;charT&gt; &gt;
28062class istreambuf_iterator
28063  : public iterator&lt;input_iterator_tag, charT,
28064                    typename traits::off_type, <del>charT*</del> <ins><i>unspecified</i></ins>, charT&gt; {
28065</pre></blockquote>
28066
28067<p>
28068Change 24.6.3 [istreambuf.iterator], p1:
28069</p>
28070
28071<blockquote><p>
28072The class template <tt>istreambuf_iterator</tt> reads successive
28073characters from the <tt>streambuf</tt> for which it was constructed.
28074<tt>operator*</tt> provides access to the current input character, if
28075any. <ins>[<i>Note:</i> <tt>operator-&gt;</tt> may return a proxy. &#8212;
28076<i>end note</i>]</ins> Each time
28077<tt>operator++</tt> is evaluated, the iterator advances to the next
28078input character. If the end of stream is reached
28079(<tt>streambuf_type::sgetc()</tt> returns <tt>traits::eof()</tt>), the
28080iterator becomes equal to the end of stream iterator value. The default
28081constructor <tt>istreambuf_iterator()</tt> and the constructor
28082<tt>istreambuf_iterator(0)</tt> both construct an end of stream iterator
28083object suitable for use as an end-of-range.
28084</p></blockquote>
28085
28086
28087
28088
28089
28090
28091
28092<hr>
28093<h3><a name="660"></a>660. Missing Bitwise Operations</h3>
28094<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>
28095 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2007-04-02  <b>Last modified:</b> 2008-09-26</p>
28096<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>
28097<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
28098<p><b>Discussion:</b></p>
28099<p>Section 20.7 [function.objects] provides <span id="st" name="st" class="st">function</span>
28100<span id="st" name="st" class="st">objects</span> for some unary and binary 
28101operations, but others are missing. In a LWG reflector discussion, beginning 
28102with c++std-lib-18078, pros and cons of adding some of the missing operations 
28103were discussed. Bjarne Stroustrup commented "Why standardize what isn't used? 
28104Yes, I see the chicken and egg problems here, but it would be nice to see a 
28105couple of genuine uses before making additions."</p>
28106<p>A number of libraries, including Rogue Wave, GNU, Adobe ASL, and Boost, have 
28107already added these functions, either publicly or for internal use. For example, 
28108Doug Gregor commented: "Boost will also add ... (|, &amp;, ^) in 1.35.0, because we 
28109need those <span id="st" name="st" class="st">function</span>
28110<span id="st" name="st" class="st">objects</span> to represent various parallel 
28111collective operations (reductions, prefix reductions, etc.) in the new Message 
28112Passing Interface (MPI) library."</p>
28113<p>Because the bitwise operators have the strongest use cases, the proposed 
28114resolution is limited to them.</p>
28115
28116
28117<p><b>Proposed resolution:</b></p>
28118<p>To 20.7 [function.objects], Function objects, paragraph 2, add to the header 
28119&lt;functional&gt; synopsis:</p>
28120<blockquote>
28121  <pre>template &lt;class T&gt; struct bit_and;
28122template &lt;class T&gt; struct bit_or;
28123template &lt;class T&gt; struct bit_xor;</pre>
28124</blockquote>
28125<p>At a location in clause 20 to be determined by the Project Editor, add:</p>
28126<blockquote>
28127  <p>The library provides basic function object classes for all of the bitwise 
28128  operators in the language ([expr.bit.and], [expr.or], [exp.xor]).</p>
28129  <pre>template &lt;class T&gt; struct bit_and : binary_function&lt;T,T,T&gt; {
28130  T operator()(const T&amp; x , const T&amp; y ) const;
28131};</pre>
28132  <blockquote>
28133    <p><code>operator()</code> returns<code> x &amp; y</code> .</p>
28134  </blockquote>
28135  <pre>template &lt;class T&gt; struct bit_or : binary_function&lt;T,T,T&gt; {
28136  T operator()(const T&amp; x , const T&amp; y ) const;
28137};</pre>
28138  <blockquote>
28139    <p><code>operator()</code> returns <code>x | y</code> .</p>
28140  </blockquote>
28141  <pre>template &lt;class T&gt; struct bit_xor : binary_function&lt;T,T,T&gt; {
28142  T operator()(const T&amp; x , const T&amp; y ) const;
28143};</pre>
28144  <blockquote>
28145    <p><code>operator()</code> returns <code>x ^ y</code> .</p>
28146  </blockquote>
28147</blockquote>
28148
28149
28150
28151
28152
28153<hr>
28154<h3><a name="661"></a>661. New 27.6.1.2.2 changes make special extractions useless</h3>
28155<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>
28156 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2007-04-01  <b>Last modified:</b> 2008-09-26</p>
28157<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>
28158<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
28159<p><b>Discussion:</b></p>
28160<p>
28161To the more drastic changes of 27.7.1.2.2 [istream.formatted.arithmetic] in the current draft N2134 belong
28162the explicit description of the extraction of the types short and int in
28163terms of as-if code fragments.
28164</p>
28165
28166<ol>
28167<li>
28168The corresponding as-if extractions in paragraph 2 and 3 will never
28169result in a change of the operator&gt;&gt; argument val, because the
28170contents of the local variable lval is in no case written into val.
28171Furtheron both fragments need a currently missing parentheses in the
28172beginning of the if-statement to be valid C++.
28173</li>
28174<li>I would like to ask whether the omission of a similar explicit
28175extraction of unsigned short and unsigned int in terms of long -
28176compared to their corresponding new insertions, as described in
2817727.7.2.6.2 [ostream.inserters.arithmetic], is a deliberate decision or
28178an
28179oversight.
28180</li>
28181</ol>
28182
28183
28184<p><b>Proposed resolution:</b></p>
28185<ol>
28186<li>
28187<p>
28188In 27.7.1.2.2 [istream.formatted.arithmetic]/2 change the current as-if code fragment
28189</p>
28190<blockquote><pre>typedef num_get&lt;charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget;
28191iostate err = 0;
28192long lval;
28193use_facet&lt;numget&gt;(loc).get(*this, 0, *this, err, lval );
28194if (err == 0) <ins>{</ins>
28195  <del>&amp;&amp;</del> <ins>if</ins> (lval &lt; numeric_limits&lt;short&gt;::min() || numeric_limits&lt;short&gt;::max() &lt; lval)<del>)</del>
28196      err = ios_base::failbit;
28197  <ins>else
28198    val = static_cast&lt;short&gt;(lval);
28199}</ins>
28200setstate(err);
28201</pre></blockquote>
28202
28203<p>
28204Similarily in 27.7.1.2.2 [istream.formatted.arithmetic]/3 change the current as-if fragment
28205</p>
28206
28207<blockquote><pre>typedef num_get&lt;charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget;
28208iostate err = 0;
28209long lval;
28210use_facet&lt;numget&gt;(loc).get(*this, 0, *this, err, lval );
28211if (err == 0) <ins>{</ins>
28212  <del>&amp;&amp;</del> <ins>if</ins> (lval &lt; numeric_limits&lt;int&gt;::min() || numeric_limits&lt;int&gt;::max() &lt; lval)<del>)</del>
28213      err = ios_base::failbit;
28214  <ins>else
28215    val = static_cast&lt;int&gt;(lval);
28216}</ins>
28217setstate(err);
28218</pre></blockquote>
28219</li>
28220<li>
28221---
28222</li>
28223</ol>
28224
28225
28226<p><i>[
28227Kona (2007): Note to the editor: the name lval in the call to <tt>use_facet</tt>
28228is incorrectly italicized in the code fragments corresponding to
28229<tt>operator&gt;&gt;(short &amp;)</tt> and <tt>operator &gt;&gt;(int &amp;)</tt>. Also, val -- which appears
28230twice on the line with the <tt>static_cast</tt> in the proposed resolution --
28231should be italicized. Also, in response to part two of the issue: this
28232is deliberate.
28233]</i></p>
28234
28235
28236
28237
28238
28239<hr>
28240<h3><a name="664"></a>664. <tt>do_unshift</tt> for <tt>codecvt&lt;char, char, mbstate_t&gt;</tt></h3>
28241<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>
28242 <b>Submitter:</b> Thomas Plum <b>Opened:</b> 2007-04-16  <b>Last modified:</b> 2008-09-26</p>
28243<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>
28244<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
28245<p><b>Discussion:</b></p>
28246<p>
2824722.4.1.4.2 [locale.codecvt.virtuals], para 7 says (regarding <tt>do_unshift</tt>):
28248</p>
28249
28250<blockquote><p>
28251<i>Effects:</i> Places characters starting at to that should be appended to
28252terminate a sequence when the current <tt>stateT</tt> is given by
28253<tt><i>state</i></tt>.<sup>237)</sup> Stores no more than <tt>(<i>to_limit</i> -
28254<i>to</i>)</tt> destination elements, and leaves the <tt><i>to_next</i></tt>
28255pointer pointing one beyond the last element successfully stored.
28256<em><tt>codecvt&lt;char, char, mbstate_t&gt;</tt> stores no characters.</em>
28257</p></blockquote>
28258
28259<p>
28260The following objection has been raised:
28261</p>
28262
28263<blockquote><p>
28264Since the C++ Standard permits a nontrivial conversion for the required
28265instantiations of <tt>codecvt</tt>, it is overly restrictive to say that
28266<tt>do_unshift</tt> must store no characters and return <tt>noconv</tt>.
28267</p></blockquote>
28268
28269<p>
28270[Plum ref _222152Y50]
28271</p>
28272
28273
28274<p><b>Proposed resolution:</b></p>
28275<p>
28276Change 22.4.1.4.2 [locale.codecvt.virtuals], p7:
28277</p>
28278
28279<blockquote>
28280<p>
28281<i>Effects:</i> Places characters starting at <i>to</i> that should be
28282appended to terminate a sequence when the current <tt>stateT</tt> is
28283given by state.<sup>237)</sup> Stores no more than (<i>to_limit -to</i>)
28284destination elements, and leaves the <i>to_next</i> pointer pointing one
28285beyond the last element successfully stored. <del><tt>codecvt&lt;char, char,
28286mbstate_t&gt;</tt> stores no characters.</del>
28287</p>
28288</blockquote>
28289
28290
28291
28292
28293
28294<hr>
28295<h3><a name="665"></a>665. <tt>do_unshift</tt> return value</h3>
28296<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>
28297 <b>Submitter:</b> Thomas Plum <b>Opened:</b> 2007-04-16  <b>Last modified:</b> 2008-09-26</p>
28298<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>
28299<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
28300<p><b>Discussion:</b></p>
28301<p>
2830222.4.1.4.2 [locale.codecvt.virtuals], para 8 says:
28303</p>
28304
28305<blockquote><p>
28306<tt>codecvt&lt;char,char,mbstate_t&gt;</tt>, returns <tt>noconv</tt>.
28307</p></blockquote>
28308
28309<p>
28310The following objection has been raised:
28311</p>
28312
28313<blockquote><p>
28314Despite what the C++ Standard 
28315says, <tt>unshift</tt> can't always return <tt>noconv</tt> for the default facets, since 
28316they can be nontrivial. At least one implementation does whatever the 
28317C functions do.
28318</p></blockquote>
28319
28320<p>
28321[Plum ref _222152Y62]
28322</p>
28323
28324
28325<p><b>Proposed resolution:</b></p>
28326<p>
28327Change 22.4.1.4.2 [locale.codecvt.virtuals], p8:
28328</p>
28329
28330<blockquote>
28331<p><i>Returns:</i> An enumeration value, as summarized in Table 76:</p>
28332<p>...</p>
28333<p>
28334<del><tt>codecvt&lt;char,char,mbstate_t&gt;</tt>, returns <tt>noconv</tt>.</del>
28335</p>
28336</blockquote>
28337
28338
28339
28340
28341
28342
28343<hr>
28344<h3><a name="666"></a>666. <tt>moneypunct::do_curr_symbol()</tt></h3>
28345<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>
28346 <b>Submitter:</b> Thomas Plum <b>Opened:</b> 2007-04-16  <b>Last modified:</b> 2008-09-26</p>
28347<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>
28348<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
28349<p><b>Discussion:</b></p>
28350<p>
2835122.4.6.3.2 [locale.moneypunct.virtuals], para 4 footnote 257 says
28352</p>
28353
28354<blockquote><p>
28355<sup>257)</sup> For international 
28356specializations (second template parameter <tt>true</tt>) this is always four 
28357characters long, usually three letters and a space.
28358</p></blockquote>
28359
28360<p>
28361The following objection has been raised:
28362</p>
28363
28364<blockquote><p>
28365The international currency 
28366symbol is whatever the underlying locale says it is, not necessarily 
28367four characters long.
28368</p></blockquote>
28369
28370<p>
28371[Plum ref _222632Y41]
28372</p>
28373
28374
28375<p><b>Proposed resolution:</b></p>
28376<p>
28377Change footnote 253 in 22.4.6.3.2 [locale.moneypunct.virtuals]:
28378</p>
28379
28380<blockquote>
28381<p>
28382<sup>253)</sup> For international specializations (second template
28383parameter <tt>true</tt>) this is <del>always</del> <ins>typically</ins>
28384four characters long, usually three letters and a space.
28385</p>
28386</blockquote>
28387
28388
28389
28390
28391
28392<hr>
28393<h3><a name="672"></a>672. Swappable requirements need updating</h3>
28394<p><b>Section:</b> 20.2.1 [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
28395 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2007-05-04  <b>Last modified:</b> 2008-09-26</p>
28396<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>
28397<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>
28398<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
28399<p><b>Discussion:</b></p>
28400<p>
28401The current <tt>Swappable</tt> is:
28402</p>
28403
28404<blockquote>
28405<table border="1">
28406<caption>Table 37: <tt>Swappable</tt> requirements <b>[swappable]</b></caption>
28407<tbody><tr><th>expression</th><th>return type</th><th>post-condition</th></tr>
28408<tr><td><tt>swap(s,t)</tt></td><td><tt>void</tt></td><td><tt>t</tt> has the value originally held by <tt>u</tt>, and <tt>u</tt> has the value originally 
28409held by <tt>t</tt></td></tr>
28410<tr><td colspan="3">
28411<p>
28412The Swappable requirement is met by satisfying one or more of the following conditions:
28413</p>
28414<ul>
28415<li>
28416<tt>T</tt> is Swappable if <tt>T</tt> satisfies the <tt>CopyConstructible</tt> requirements (Table 34) 
28417and the <tt>CopyAssignable</tt> requirements (Table 36);
28418</li>
28419<li>
28420<tt>T</tt> is Swappable if a namespace scope function named <tt>swap</tt> exists in the same 
28421namespace as the definition of <tt>T</tt>, such that the expression <tt>swap(t,u)</tt> is valid 
28422and has the semantics described in this table.
28423</li>
28424</ul>
28425</td></tr>
28426</tbody></table>
28427</blockquote>
28428
28429<p>
28430With the passage of rvalue reference into the language, <tt>Swappable</tt> needs to be updated to
28431require only <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt>.  This is a minimum.
28432</p>
28433
28434<p>
28435Additionally we may want to support proxy references such that the following code is acceptable:
28436</p>
28437
28438<blockquote><pre>namespace Mine {
28439
28440template &lt;class T&gt;
28441struct proxy {...};
28442
28443template &lt;class T&gt;
28444struct proxied_iterator
28445{
28446   typedef T value_type;
28447   typedef proxy&lt;T&gt; reference;
28448   reference operator*() const;
28449   ...
28450};
28451
28452struct A
28453{
28454   // heavy type, has an optimized swap, maybe isn't even copyable or movable, just swappable
28455   void swap(A&amp;);
28456   ...
28457};
28458
28459void swap(A&amp;, A&amp;);
28460void swap(proxy&lt;A&gt;, A&amp;);
28461void swap(A&amp;, proxy&lt;A&gt;);
28462void swap(proxy&lt;A&gt;, proxy&lt;A&gt;);
28463
28464}  // Mine
28465
28466...
28467
28468Mine::proxied_iterator&lt;Mine::A&gt; i(...)
28469Mine::A a;
28470swap(*i1, a);
28471</pre></blockquote>
28472
28473<p>
28474I.e. here is a call to <tt>swap</tt> which the user enables swapping between a proxy to a class and the class
28475itself.  We do not need to anything in terms of implementation except not block their way with overly
28476constrained concepts.  That is, the <tt>Swappable</tt> concept should be expanded to allow swapping
28477between two different types for the case that one is binding to a user-defined <tt>swap</tt>.
28478</p>
28479
28480
28481
28482<p><b>Proposed resolution:</b></p>
28483
28484<p>
28485Change 20.2.1 [utility.arg.requirements]:
28486</p>
28487
28488<blockquote>
28489
28490<p>
28491-1- The template definitions in the C++ Standard Library refer to various
28492named requirements whose details are set out in tables 31-38. In these
28493tables, <tt>T</tt> is a type to be supplied by a C++ program
28494instantiating a template; <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> are
28495values of type <tt>const T</tt>; <tt>s</tt> and <tt>t</tt> are modifiable
28496lvalues of type <tt>T</tt>; <tt>u</tt> is a value of type (possibly
28497<tt>const</tt>) <tt>T</tt>; and <tt>rv</tt> is a non-<tt>const</tt>
28498rvalue of type <tt>T</tt>.
28499</p>
28500
28501<table border="1">
28502<caption>Table 37: <tt>Swappable</tt> requirements <b>[swappable]</b></caption>
28503<tbody><tr><th>expression</th><th>return type</th><th>post-condition</th></tr>
28504<tr><td><tt>swap(s,t)</tt></td><td><tt>void</tt></td>
28505<td><tt>t</tt> has the value originally
28506held by <tt>u</tt>, and
28507<tt>u</tt> has the value originally held
28508by <tt>t</tt></td></tr>
28509<tr><td colspan="3">
28510<p>
28511The <tt>Swappable</tt> requirement is met by satisfying one or more of the following conditions:
28512</p>
28513<ul>
28514<li>
28515<tt>T</tt> is <tt>Swappable</tt> if <tt>T</tt> satisfies the
28516<del><tt>CopyConstructible</tt></del> <ins>MoveConstructible</ins>
28517requirements (Table <del>34</del> <ins>33</ins>) and the <del><tt>CopyAssignable</tt></del> <ins>MoveAssignable</ins>
28518requirements (Table <del>36</del> <ins>35</ins>);
28519</li>
28520<li>
28521<tt>T</tt> is <tt>Swappable</tt> if a namespace scope function named
28522<tt>swap</tt> exists in the same namespace as the definition of
28523<tt>T</tt>, such that the expression
28524<tt>swap(t,u)</tt> is valid and has the
28525semantics described in this table.
28526</li>
28527</ul>
28528</td></tr>
28529</tbody></table>
28530</blockquote>
28531
28532
28533
28534<p><i>[
28535Kona (2007): We like the change to the <tt>Swappable</tt> requirements to use
28536move semantics. The issue relating to the support of proxies is
28537separable from the one relating to move semantics, and it's bigger than
28538just swap. We'd like to address only the move semantics changes under
28539this 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
28540may be a third issue, in that the current definition of <tt>Swappable</tt> does
28541not permit rvalues to be operands to a swap operation, and Howard's
28542proposed resolution would allow the right-most operand to be an rvalue,
28543but it would not allow the left-most operand to be an rvalue (some swap
28544functions in the library have been overloaded to permit left operands to
28545swap to be rvalues).
28546]</i></p>
28547
28548
28549
28550
28551
28552<hr>
28553<h3><a name="673"></a>673. <tt>unique_ptr</tt> update</h3>
28554<p><b>Section:</b> 20.8.14 [unique.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
28555 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2007-05-04  <b>Last modified:</b> 2008-09-26</p>
28556<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>
28557<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
28558<p><b>Discussion:</b></p>
28559<p>
28560Since the publication of
28561<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html">N1856</a>
28562there have been a few small but significant advances which should be included into
28563<tt>unique_ptr</tt>.  There exists a
28564<a href="http://home.twcny.rr.com/hinnant/cpp_extensions/unique_ptr.html">example implmenation</a>
28565for all of these changes.
28566</p>
28567
28568<ul>
28569
28570<li>
28571<p>
28572Even though <tt>unique_ptr&lt;void&gt;</tt> is not a valid use case (unlike for <tt>shared_ptr&lt;void&gt;</tt>),
28573unexpected cases to crop up which require the instantiation of the interface of <tt>unique_ptr&lt;void&gt;</tt>
28574even if it is never used.  For example see
28575<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#541">LWG 541</a> for how this accidently
28576happened to <tt>auto_ptr</tt>.  I believe the most robust way to protect <tt>unique_ptr</tt> against this
28577type of failure is to augment the return type of <tt>unique_ptr&lt;T&gt;:operator*()</tt> with
28578<tt>add_lvalue_reference&lt;T&gt;::type</tt>.  This means that given an instantiated <tt>unique_ptr&lt;void&gt;</tt>
28579the act of dereferencing it will simply return <tt>void</tt> instead of causing a compile time failure.
28580This is simpler than creating a <tt>unique_ptr&lt;void&gt;</tt> specialization which isn't robust in the
28581face of <tt><i>cv-</i></tt>qualified <tt>void</tt> types.
28582</p>
28583
28584<p>
28585This resolution also supports instantiations such as <tt>unique_ptr&lt;void, free_deleter&gt;</tt>
28586which could be very useful to the client.
28587</p>
28588
28589</li>
28590
28591<li>
28592<p>
28593Efforts have been made to better support containers and smart pointers in shared
28594memory contexts.  One of the key hurdles in such support is not assuming that a
28595pointer type is actually a <tt>T*</tt>.  This can easily be accomplished
28596for <tt>unique_ptr</tt> by having the deleter define the pointer type:
28597<tt>D::pointer</tt>.  Furthermore this type can easily be defaulted to
28598<tt>T*</tt> should the deleter <tt>D</tt> choose not to define a pointer
28599type (example implementation
28600<a href="http://home.twcny.rr.com/hinnant/cpp_extensions/unique_ptr.html">here</a>).
28601This change has no run time overhead.  It has no interface overhead on
28602authors of custom delter types.  It simply allows (but not requires)
28603authors of custom deleter types to define a smart pointer for the
28604storage type of <tt>unique_ptr</tt> if they find such functionality
28605useful.  <tt>std::default_delete</tt> is an example of a deleter which
28606defaults <tt>pointer</tt> to <tt>T*</tt> by simply ignoring this issue
28607and not including a <tt>pointer typedef</tt>.
28608</p>
28609</li>
28610
28611<li>
28612<p>
28613When the deleter type is a function pointer then it is unsafe to construct
28614a <tt>unique_ptr</tt> without specifying the function pointer in the constructor.
28615This case is easy to check for with a <tt>static_assert</tt> assuring that the
28616deleter is not a pointer type in those constructors which do not accept deleters.
28617</p>
28618
28619<blockquote><pre>unique_ptr&lt;A, void(*)(void*)&gt; p(new A);  // error, no function given to delete the pointer!
28620</pre></blockquote>
28621
28622</li>
28623
28624</ul>
28625
28626<p><i>[
28627Kona (2007): We don't like the solution given to the first bullet in
28628light of concepts. The second bullet solves the problem of supporting
28629fancy pointers for one library component only. The full LWG needs to
28630decide whether to solve the problem of supporting fancy pointers
28631piecemeal, or whether a paper addressing the whole library is needed. We
28632think that the third bullet is correct.
28633]</i></p>
28634
28635
28636<p><i>[
28637Post Kona: Howard adds example user code related to the first bullet:
28638]</i></p>
28639
28640
28641<blockquote>
28642<pre>void legacy_code(void*, std::size_t);
28643
28644void foo(std::size_t N)
28645{
28646    std::unique_ptr&lt;void, void(*)(void*)&gt; ptr(std::malloc(N), std::free);
28647    legacy_code(ptr.get(), N);
28648}   // unique_ptr used for exception safety purposes
28649</pre>
28650</blockquote>
28651
28652<p>
28653I.e. <tt>unique_ptr&lt;void&gt;</tt> <i>is</i> a useful tool that we don't want
28654to disable with concepts.  The only part of <tt>unique_ptr&lt;void&gt;</tt> we
28655want to disable (with concepts or by other means) are the two member functions:
28656</p>
28657
28658<blockquote><pre>T&amp; operator*() const;
28659T* operator-&gt;() const;
28660</pre></blockquote>
28661
28662
28663
28664<p><b>Proposed resolution:</b></p>
28665
28666<p><i>[
28667I am grateful for the generous aid of Peter Dimov and Ion Gazta�aga in helping formulate and review
28668the proposed resolutions below.
28669]</i></p>
28670
28671
28672<ul>
28673<li>
28674
28675<p>
28676Change 20.8.14.2 [unique.ptr.single]:
28677</p>
28678
28679<blockquote><pre>template &lt;class T, class D = default_delete&lt;T&gt;&gt; class unique_ptr {
28680   ...
28681   <del>T&amp;</del> <ins>typename add_lvalue_reference&lt;T&gt;::type</ins> operator*() const;
28682   ...
28683};
28684</pre></blockquote>
28685
28686<p>
28687Change 20.8.14.2.4 [unique.ptr.single.observers]:
28688</p>
28689
28690<blockquote><pre><del>T&amp;</del> <ins>typename add_lvalue_reference&lt;T&gt;::type</ins> operator*() const;
28691</pre></blockquote>
28692
28693</li>
28694
28695<li>
28696<p>
28697Change 20.8.14.2 [unique.ptr.single]:
28698</p>
28699
28700<blockquote><pre>template &lt;class T, class D = default_delete&lt;T&gt;&gt; class unique_ptr {
28701public:
28702  <ins>typedef <i>implementation (see description below)</i> pointer;</ins>
28703   ...
28704   explicit unique_ptr(<del>T*</del> <ins>pointer</ins> p);
28705   ...
28706   unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined (see description below)</i> d);
28707   unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined (see description below)</i> d);
28708   ...
28709   <del>T*</del> <ins>pointer</ins> operator-&gt;() const;
28710   <del>T*</del> <ins>pointer</ins> get() const;
28711   ...
28712   <del>T*</del> <ins>pointer</ins> release();
28713   void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);
28714};
28715</pre></blockquote>
28716
28717<p>
28718<ins>
28719-3- If the type <tt>remove_reference&lt;D&gt;::type::pointer</tt>
28720exists, then <tt>unique_ptr&lt;T, D&gt;::pointer</tt> is a typedef to
28721<tt>remove_reference&lt;D&gt;::type::pointer</tt>.  Otherwise
28722<tt>unique_ptr&lt;T, D&gt;::pointer</tt> is a typedef to <tt>T*</tt>.
28723The type <tt>unique_ptr&lt;T, D&gt;::pointer</tt> shall be <tt>CopyConstructible</tt>
28724and <tt>CopyAssignable</tt>.
28725</ins>
28726</p>
28727
28728<p>
28729Change 20.8.14.2.1 [unique.ptr.single.ctor]:
28730</p>
28731
28732<blockquote><pre>unique_ptr(<del>T*</del> <ins>pointer</ins> p);
28733...
28734unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d); 
28735unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d); 
28736...
28737unique_ptr(<del>T*</del> <ins>pointer</ins> p, const A&amp; d);
28738unique_ptr(<del>T*</del> <ins>pointer</ins> p, A&amp;&amp; d);
28739...
28740unique_ptr(<del>T*</del> <ins>pointer</ins> p, A&amp; d); 
28741unique_ptr(<del>T*</del> <ins>pointer</ins> p, A&amp;&amp; d);
28742...
28743unique_ptr(<del>T*</del> <ins>pointer</ins> p, const A&amp; d); 
28744unique_ptr(<del>T*</del> <ins>pointer</ins> p, const A&amp;&amp; d);
28745...
28746</pre></blockquote>
28747
28748<p>
28749-23- <i>Requires:</i> If <tt>D</tt> is not a reference type,
28750construction of the deleter <tt>D</tt> from an rvalue of type <tt>E</tt>
28751<del>must</del> <ins>shall</ins> be well formed and not throw an exception. If <tt>D</tt> is a
28752reference type, then <tt>E</tt> <del>must</del> <ins>shall</ins> be the same type as <tt>D</tt>
28753(diagnostic required). <del><tt>U*</tt></del> <ins><tt>unique_ptr&lt;U,E&gt;::pointer</tt></ins>
28754<del>must</del> <ins>shall</ins> be implicitly convertible to <del><tt>T*</tt></del>
28755<ins>pointer</ins>.
28756</p>
28757
28758<p>
28759-25- <i>Postconditions:</i> <tt>get() == value u.get()</tt> had before
28760the construction, modulo any required offset adjustments resulting from
28761the cast from <del><tt>U*</tt></del>
28762<ins><tt>unique_ptr&lt;U,E&gt;::pointer</tt></ins> to <del><tt>T*</tt></del>
28763<ins>pointer</ins>. <tt>get_deleter()</tt> returns a reference to the
28764internally stored deleter which was constructed from
28765<tt>u.get_deleter()</tt>.
28766</p>
28767
28768<p>
28769Change 20.8.14.2.3 [unique.ptr.single.asgn]:
28770</p>
28771
28772<blockquote>
28773<p>
28774-8- <i>Requires:</i> Assignment of the deleter <tt>D</tt> from an rvalue
28775<tt>D</tt> <del>must</del> <ins>shall</ins> not throw an exception. <del><tt>U*</tt></del>
28776<ins><tt>unique_ptr&lt;U,E&gt;::pointer</tt></ins> <del>must</del> <ins>shall</ins> be implicitly
28777convertible to <del><tt>T*</tt></del> <ins>pointer</ins>.
28778</p>
28779</blockquote>
28780
28781<p>
28782Change 20.8.14.2.4 [unique.ptr.single.observers]:
28783</p>
28784
28785<blockquote>
28786<pre><del>T*</del> <ins>pointer</ins> operator-&gt;() const;</pre>
28787...
28788<pre><del>T*</del> <ins>pointer</ins> get() const;</pre>
28789</blockquote>
28790
28791<p>
28792Change 20.8.14.2.5 [unique.ptr.single.modifiers]:
28793</p>
28794
28795<blockquote>
28796<pre><del>T*</del> <ins>pointer</ins> release();</pre>
28797...
28798<pre>void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);</pre>
28799</blockquote>
28800
28801<p>
28802Change 20.8.14.3 [unique.ptr.runtime]:
28803</p>
28804
28805<blockquote><pre>template &lt;class T, class D&gt; class unique_ptr&lt;T[], D&gt; {
28806public:
28807  <ins>typedef <i>implementation</i> pointer;</ins>
28808   ...
28809   explicit unique_ptr(<del>T*</del> <ins>pointer</ins> p);
28810   ...
28811   unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
28812   unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
28813   ...
28814   <del>T*</del> <ins>pointer</ins> get() const;
28815   ...
28816   <del>T*</del> <ins>pointer</ins> release();
28817   void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);
28818};
28819</pre></blockquote>
28820
28821<p>
28822Change 20.8.14.3.1 [unique.ptr.runtime.ctor]:
28823</p>
28824
28825<blockquote>
28826<pre>unique_ptr(<del>T*</del> <ins>pointer</ins> p);
28827unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
28828unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
28829</pre>
28830
28831<p>
28832These constructors behave the same as in the primary template except
28833that they do not accept pointer types which are convertible to
28834<del><tt>T*</tt></del> <ins><tt>pointer</tt></ins>. [<i>Note:</i> One
28835implementation technique is to create private templated overloads of
28836these members. <i>-- end note</i>]
28837</p>
28838</blockquote>
28839
28840<p>
28841Change 20.8.14.3.3 [unique.ptr.runtime.modifiers]:
28842</p>
28843
28844<blockquote>
28845<pre>void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);
28846</pre>
28847
28848<p>
28849-1- <i>Requires:</i> Does not accept pointer types which are convertible
28850to <del><tt>T*</tt></del> <ins><tt>pointer</tt></ins> (diagnostic
28851required). [<i>Note:</i> One implementation technique is to create a private
28852templated overload. <i>-- end note</i>]
28853</p>
28854</blockquote>
28855
28856</li>
28857
28858<li>
28859
28860<p>
28861Change 20.8.14.2.1 [unique.ptr.single.ctor]:
28862</p>
28863
28864<blockquote>
28865<pre>unique_ptr();</pre>
28866<blockquote>
28867<p>
28868<i>Requires:</i> <tt>D</tt> <del>must</del> <ins>shall</ins> be default constructible, and that
28869construction <del>must</del> <ins>shall</ins> not throw an exception. <tt>D</tt> <del>must</del> <ins>shall</ins> not be a
28870reference type <ins>or pointer type (diagnostic required)</ins>.
28871</p>
28872</blockquote>
28873<pre>unique_ptr(<del>T*</del> <ins>pointer</ins> p);</pre>
28874<blockquote>
28875<p>
28876<i>Requires:</i>  The expression <tt>D()(p)</tt> <del>must</del> <ins>shall</ins> be well formed.
28877The default constructor of <tt>D</tt> <del>must</del> <ins>shall</ins> not throw an exception.
28878<tt>D</tt> <del>must</del> <ins>shall</ins> not be a reference type <ins>or pointer type (diagnostic
28879required)</ins>.
28880</p>
28881</blockquote>
28882</blockquote>
28883
28884</li>
28885
28886</ul>
28887
28888
28889
28890
28891
28892
28893<hr>
28894<h3><a name="674"></a>674. <tt>shared_ptr</tt> interface changes for consistency with N1856</h3>
28895<p><b>Section:</b> 20.8.15.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
28896 <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2007-05-05  <b>Last modified:</b> 2008-09-26</p>
28897<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>
28898<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
28899<p><b>Discussion:</b></p>
28900<p>
28901<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html">N1856</a> does not propose
28902any changes to <tt>shared_ptr</tt>. It needs to be updated to use a rvalue reference where appropriate
28903and to interoperate with <tt>unique_ptr</tt> as it does with <tt>auto_ptr</tt>.
28904</p>
28905
28906
28907<p><b>Proposed resolution:</b></p>
28908
28909<p>
28910Change 20.8.15.2 [util.smartptr.shared] as follows:
28911</p>
28912
28913<blockquote>
28914<pre>template&lt;class Y&gt; explicit shared_ptr(auto_ptr&lt;Y&gt;<del>&amp;</del><ins>&amp;&amp;</ins> r);
28915<ins>template&lt;class Y, class D&gt; explicit shared_ptr(const unique_ptr&lt;Y,D&gt;&amp; r) = delete;
28916template&lt;class Y, class D&gt; explicit shared_ptr(unique_ptr&lt;Y,D&gt;&amp;&amp; r);</ins>
28917...
28918template&lt;class Y&gt; shared_ptr&amp; operator=(auto_ptr&lt;Y&gt;<del>&amp;</del><ins>&amp;&amp;</ins> r);
28919<ins>template&lt;class Y, class D&gt; shared_ptr&amp; operator=(const unique_ptr&lt;Y,D&gt;&amp; r) = delete;
28920template&lt;class Y, class D&gt; shared_ptr&amp; operator=(unique_ptr&lt;Y,D&gt;&amp;&amp; r);</ins></pre>
28921</blockquote>
28922
28923<p>
28924Change 20.8.15.2.1 [util.smartptr.shared.const] as follows:
28925</p>
28926
28927<blockquote>
28928<pre><ins>template&lt;class Y&gt; shared_ptr(auto_ptr&lt;Y&gt;<del>&amp;</del><ins>&amp;&amp;</ins> r);</ins></pre>
28929</blockquote>
28930
28931<p>
28932Add to 20.8.15.2.1 [util.smartptr.shared.const]:
28933</p>
28934
28935<blockquote>
28936<pre><ins>template&lt;class Y, class D&gt; shared_ptr(unique_ptr&lt;Y, D&gt;&amp;&amp; r);</ins></pre>
28937<blockquote>
28938
28939<p><ins>
28940<i>Effects:</i> Equivalent to <tt>shared_ptr( r.release(), r.get_deleter() )</tt> when <tt>D</tt> is
28941          not a reference type, <tt>shared_ptr( r.release(), ref( r.get_deleter() ) )</tt>
28942          otherwise.
28943</ins></p>
28944
28945<p><ins>
28946<i>Exception safety:</i> If an exception is thrown, the constructor has no effect.
28947</ins></p>
28948</blockquote>
28949
28950</blockquote>
28951
28952<p>
28953Change 20.8.15.2.3 [util.smartptr.shared.assign] as follows:
28954</p>
28955
28956<blockquote>
28957<pre>template&lt;class Y&gt; shared_ptr&amp; operator=(auto_ptr&lt;Y&gt;<del>&amp;</del><ins>&amp;&amp;</ins> r);</pre>
28958</blockquote>
28959
28960<p>
28961Add to 20.8.15.2.3 [util.smartptr.shared.assign]:
28962</p>
28963
28964<blockquote>
28965<pre><ins>template&lt;class Y, class D&gt; shared_ptr&amp; operator=(unique_ptr&lt;Y,D&gt;&amp;&amp; r);</ins></pre>
28966
28967<blockquote>
28968<p><ins>
28969-4- <i>Effects:</i> Equivalent to <tt>shared_ptr(std::move(r)).swap(*this)</tt>.
28970</ins></p>
28971<p><ins>
28972-5- <i>Returns:</i> <tt>*this</tt>.
28973</ins></p>
28974</blockquote>
28975
28976</blockquote>
28977
28978
28979
28980<p><i>[
28981Kona (2007): We may need to open an issue (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#743">743</a>) to deal with the question of
28982whether <tt>shared_ptr</tt> needs an rvalue <tt>swap</tt>.
28983]</i></p>
28984
28985
28986
28987
28988
28989<hr>
28990<h3><a name="675"></a>675. Move assignment of containers</h3>
28991<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>
28992 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2007-05-05  <b>Last modified:</b> 2008-09-26</p>
28993<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>
28994<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>
28995<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
28996<p><b>Discussion:</b></p>
28997<p>
28998James Hopkin pointed out to me that if <tt>vector&lt;T&gt;</tt> move assignment is O(1)
28999(just a <tt>swap</tt>) then containers such as <tt>vector&lt;shared_ptr&lt;ostream&gt;&gt;</tt> might have
29000the wrong semantics under move assignment when the source is not truly an rvalue, but a
29001moved-from lvalue (destructors could run late).
29002</p>
29003
29004<blockquote><pre><tt>vector&lt;shared_ptr&lt;ostream&gt;&gt;</tt> v1;
29005<tt>vector&lt;shared_ptr&lt;ostream&gt;&gt;</tt> v2;
29006...
29007v1 = v2;               // #1
29008v1 = std::move(v2);    // #2
29009</pre></blockquote>
29010
29011<p>
29012Move semantics means not caring what happens to the source (<tt>v2</tt> in this example).
29013It doesn't mean not caring what happens to the target (<tt>v1</tt>).  In the above example
29014both assignments should have the same effect on <tt>v1</tt>.  Any non-shared <tt>ostream</tt>'s
29015<tt>v1</tt> owns before the assignment should be closed, whether <tt>v1</tt> is undergoing
29016copy assignment or move assignment.
29017</p>
29018
29019<p>
29020This implies that the semantics of move assignment of a generic container should be
29021<tt>clear, swap</tt> instead of just swap.  An alternative which could achieve the same
29022effect would be to move assign each element.  In either case, the complexity of move
29023assignment needs to be relaxed to <tt>O(v1.size())</tt>.
29024</p>
29025
29026<p>
29027The performance hit of this change is not nearly as drastic as it sounds. 
29028In practice, the target of a move assignment has always just been move constructed
29029or move assigned <i>from</i>.  Therefore under <tt>clear, swap</tt> semantics (in
29030this common use case) we are still achieving O(1) complexity.
29031</p>
29032
29033
29034
29035<p><b>Proposed resolution:</b></p>
29036<p>
29037Change 23.2 [container.requirements]:
29038</p>
29039
29040<blockquote>
29041<table border="1">
29042<caption>Table 89: Container requirements</caption>
29043<tbody><tr>
29044<th>expression</th><th>return type</th><th>operational semantics</th>
29045<th>assertion/note pre/post-condition</th><th>complexity</th>
29046</tr>
29047<tr>
29048<td><tt>a = rv;</tt></td><td><tt>X&amp;</tt></td>
29049<td>All existing elements of <tt>a</tt> are either move assigned or destructed</td>
29050<td><tt>a</tt> shall be equal to the 
29051value that <tt>rv</tt> had 
29052before this construction
29053</td>
29054<td><del>(Note C)</del> <ins>linear</ins></td>
29055</tr>
29056</tbody></table>
29057
29058<p>
29059Notes: the algorithms <tt>swap()</tt>, <tt>equal()</tt> and
29060<tt>lexicographical_compare()</tt> are defined in clause 25. Those
29061entries marked "(Note A)" should have constant complexity. Those entries
29062marked "(Note B)" have constant complexity unless
29063<tt>allocator_propagate_never&lt;X::allocator_type&gt;::value</tt> is
29064<tt>true</tt>, in which case they have linear complexity.
29065<del>Those entries
29066marked "(Note C)" have constant complexity if <tt>a.get_allocator() ==
29067rv.get_allocator()</tt> or if either
29068<tt>allocator_propagate_on_move_assignment&lt;X::allocator_type&gt;::value</tt>
29069is <tt>true</tt> or
29070<tt>allocator_propagate_on_copy_assignment&lt;X::allocator_type&gt;::value</tt>
29071is <tt>true</tt> and linear complexity otherwise.</del>
29072</p>
29073</blockquote>
29074
29075
29076
29077<p><i>[
29078post Bellevue Howard adds:
29079]</i></p>
29080
29081
29082<blockquote>
29083<p>
29084This issue was voted to WP in Bellevue, but accidently got stepped on by
29085<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2525.pdf">N2525</a>
29086which was voted to WP simulataneously.  Moving back to Open for the purpose of getting
29087the wording right.  The intent of this issue and N2525 are not in conflict.
29088</p>
29089</blockquote>
29090
29091<p><i>[
29092post Sophia Antipolis Howard updated proposed wording:
29093]</i></p>
29094
29095
29096
29097
29098
29099<hr>
29100<h3><a name="677"></a>677. Weaknesses in seed_seq::randomize [rand.util.seedseq]</h3>
29101<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>
29102 <b>Submitter:</b> Charles Karney <b>Opened:</b> 2007-05-15  <b>Last modified:</b> 2008-09-26</p>
29103<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>
29104<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
29105<p><b>Discussion:</b></p>
29106<p>
29107<tt>seed_seq::randomize</tt> provides a mechanism for initializing random number
29108engines which ideally would yield "distant" states when given "close"
29109seeds.  The algorithm for <tt>seed_seq::randomize</tt> given in the current
29110Working Draft for C++,
29111<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2284.pdf">N2284</a>
29112(2007-05-08), has 3 weaknesses
29113</p>
29114
29115<ol>
29116<li>
29117<p> Collisions in state.  Because of the way the state is initialized,
29118    seeds of different lengths may result in the same state.  The
29119    current version of seed_seq has the following properties:</p>
29120<ul>
29121<li>  For a given <tt>s &lt;= n</tt>, each of the 2^(32s) seed vectors results in a
29122      distinct state.</li>
29123</ul>
29124<p>
29125    The proposed algorithm (below) has the considerably stronger
29126    properties:</p>
29127<ul>
29128<li>   All of the <tt>(2^(32n)-1)/(2^32-1)</tt> seed vectors of lengths <tt>s &lt; n</tt>
29129      result in distinct states.
29130</li>
29131<li>  All of the <tt>2^(32n)</tt> seed vectors of length <tt>s == n</tt> result in
29132      distinct states.
29133</li>
29134</ul>
29135</li>
29136<li>
29137<p> Poor mixing of <tt>v'</tt>s entropy into the state.  Consider <tt>v.size() == n</tt>
29138    and hold <tt>v[n/2]</tt> thru <tt>v[n-1]</tt> fixed while varying <tt>v[0]</tt> thru <tt>v[n/2-1]</tt>,
29139    a total of <tt>2^(16n)</tt> possibilities.  Because of the simple recursion
29140    used in <tt>seed_seq</tt>, <tt>begin[n/2]</tt> thru <tt>begin[n-1]</tt> can take on only 2^64
29141    possible states.</p>
29142
29143<p> The proposed algorithm uses a more complex recursion which results
29144    in much better mixing.</p>
29145</li>
29146<li> <tt>seed_seq::randomize</tt> is undefined for <tt>v.size() == 0</tt>.  The proposed
29147    algorithm remedies this.
29148</li>
29149</ol>
29150<p>
29151The current algorithm for <tt>seed_seq::randomize</tt> is adapted by me from the
29152initialization procedure for the Mersenne Twister by Makoto Matsumoto
29153and Takuji Nishimura.  The weakness (2) given above was communicated to
29154me by Matsumoto last year.
29155</p>
29156<p>
29157The proposed replacement for <tt>seed_seq::randomize</tt> is due to Mutsuo Saito,
29158a student of Matsumoto, and is given in the implementation of the
29159SIMD-oriented Fast Mersenne Twister random number generator SFMT.
29160<a href="http://www.math.sci.hiroshima-u.ac.jp/%7Em-mat/MT/SFMT/index.html">http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/index.html</a>
29161<a href="http://www.math.sci.hiroshima-u.ac.jp/%7Em-mat/MT/SFMT/SFMT-src-1.2.tar.gz">http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/SFMT-src-1.2.tar.gz</a>
29162</p>
29163<p>
29164See
29165Mutsuo Saito,
29166An Application of Finite Field: Design and Implementation of 128-bit
29167Instruction-Based Fast Pseudorandom Number Generator,
29168Master's Thesis, Dept. of Math., Hiroshima University (Feb. 2007)
29169<a href="http://www.math.sci.hiroshima-u.ac.jp/%7Em-mat/MT/SFMT/M062821.pdf">http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/M062821.pdf</a>
29170</p>
29171<p>
29172One change has been made here, namely to treat the case of small <tt>n</tt>
29173(setting <tt>t = (n-1)/2</tt> for <tt>n &lt; 7</tt>).
29174</p>
29175<p>
29176Since <tt>seed_seq</tt> was introduced relatively recently there is little cost
29177in making this incompatible improvement to it.
29178</p>
29179
29180<p>
29181See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
29182<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
29183for some further discussion.
29184</p>
29185
29186
29187<p><b>Proposed resolution:</b></p>
29188<p>
29189Adopt the proposed resolution in
29190<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
29191</p>
29192
29193
29194<p><i>[
29195Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
29196The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
29197]</i></p>
29198
29199
29200
29201
29202
29203<hr>
29204<h3><a name="678"></a>678. Changes for [rand.req.eng]</h3>
29205<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>
29206 <b>Submitter:</b> Charles Karney <b>Opened:</b> 2007-05-15  <b>Last modified:</b> 2008-09-26</p>
29207<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>
29208<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
29209<p><b>Discussion:</b></p>
29210<p>
29211Section X [rand.req.eng] Random number engine requirements:
29212</p>
29213
29214<p>
29215This change follows naturally from the proposed change to
29216<tt>seed_seq::randomize</tt> in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>.
29217</p>
29218
29219<p>
29220In table 104 the description of <tt>X(q)</tt> contains a special treatment of
29221the case <tt>q.size() == 0</tt>.  This is undesirable for 4 reasons:
29222</p>
29223
29224<ol>
29225<li>It replicates the functionality provided by <tt>X()</tt>.</li>
29226<li>It leads to the possibility of a collision in the state provided
29227    by some other <tt>X(q)</tt> with <tt>q.size() &gt; 0</tt>.</li>
29228<li>It is inconsistent with the description of the <tt>X(q)</tt> in
29229paragraphs 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
29230there is no special treatment of <tt>q.size() == 0</tt>.</li>
29231<li>The proposed replacement for <tt>seed_seq::randomize</tt> given above
29232    allows for the case <tt>q.size() == 0</tt>.</li>
29233</ol>
29234
29235<p>
29236See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
29237<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
29238for some further discussion.
29239</p>
29240
29241
29242<p><b>Proposed resolution:</b></p>
29243<p>
29244Adopt the proposed resolution in
29245<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
29246</p>
29247
29248
29249<p><i>[
29250Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
29251The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
29252]</i></p>
29253
29254
29255
29256
29257
29258<hr>
29259<h3><a name="679"></a>679. resize parameter by value</h3>
29260<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>
29261 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2007-06-11  <b>Last modified:</b> 2008-09-26</p>
29262<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>
29263<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
29264<p><b>Discussion:</b></p>
29265<p>
29266The C++98 standard specifies that one member function alone of the containers
29267passes its parameter (<tt>T</tt>) by value instead of by const reference:
29268</p>
29269
29270<blockquote><pre>void resize(size_type sz, T c = T());
29271</pre></blockquote>
29272
29273<p>
29274This fact has been discussed / debated repeatedly over the years, the first time
29275being even before C++98 was ratified.  The rationale for passing this parameter by
29276value has been:
29277</p>
29278
29279<blockquote>
29280<p>
29281So that self referencing statements are guaranteed to work, for example:
29282</p>
29283<blockquote><pre>v.resize(v.size() + 1, v[0]);
29284</pre></blockquote>
29285</blockquote>
29286
29287<p>
29288However this rationale is not convincing as the signature for <tt>push_back</tt> is:
29289</p>
29290
29291<blockquote><pre>void push_back(const T&amp; x);
29292</pre></blockquote>
29293
29294<p>
29295And <tt>push_back</tt> has similar semantics to <tt>resize</tt> (append).
29296And <tt>push_back</tt> must also work in the self referencing case:
29297</p>
29298
29299<blockquote><pre>v.push_back(v[0]);  // must work
29300</pre></blockquote>
29301
29302<p>
29303The problem with passing <tt>T</tt> by value is that it can be significantly more
29304expensive than passing by reference.  The converse is also true, however when it is
29305true it is usually far less dramatic (e.g. for scalar types).
29306</p>
29307
29308<p>
29309Even with move semantics available, passing this parameter by value can be expensive.
29310Consider for example <tt>vector&lt;vector&lt;int&gt;&gt;</tt>:
29311</p>
29312
29313<blockquote><pre>std::vector&lt;int&gt; x(1000);
29314std::vector&lt;std::vector&lt;int&gt;&gt; v;
29315...
29316v.resize(v.size()+1, x);
29317</pre></blockquote>
29318
29319<p>
29320In the pass-by-value case, <tt>x</tt> is copied once to the parameter of
29321<tt>resize</tt>.  And then internally, since the code can not know at compile
29322time by how much <tt>resize</tt> is growing the <tt>vector</tt>, <tt>x</tt> is
29323usually copied (not moved) a second time from <tt>resize</tt>'s parameter into its proper place
29324within the <tt>vector</tt>.
29325</p>
29326
29327<p>
29328With pass-by-const-reference, the <tt>x</tt> in the above example need be copied
29329only once.  In this case, <tt>x</tt> has an expensive copy constructor and so any
29330copies that can be saved represents a significant savings.
29331</p>
29332
29333<p>
29334If we can be efficient for <tt>push_back</tt>, we should be efficient for <tt>resize</tt>
29335as well.  The resize taking a reference parameter has been coded and shipped in the
29336CodeWarrior library with no reports of problems which I am aware of.
29337</p>
29338
29339
29340
29341<p><b>Proposed resolution:</b></p>
29342<p>
29343Change 23.3.2 [deque], p2:
29344</p>
29345
29346<blockquote><pre>class deque {
29347   ...
29348   void resize(size_type sz, <ins>const </ins>T<ins>&amp;</ins> c);
29349</pre></blockquote>
29350
29351<p>
29352Change 23.3.2.2 [deque.capacity], p3:
29353</p>
29354
29355<blockquote><pre>void resize(size_type sz, <ins>const </ins>T<ins>&amp;</ins> c);
29356</pre></blockquote>
29357
29358<p>
29359Change 23.3.4 [list], p2:
29360</p>
29361
29362<blockquote><pre>class list {
29363   ...
29364   void resize(size_type sz, <ins>const </ins>T<ins>&amp;</ins> c);
29365</pre></blockquote>
29366
29367<p>
29368Change 23.3.4.2 [list.capacity], p3:
29369</p>
29370
29371<blockquote><pre>void resize(size_type sz, <ins>const </ins>T<ins>&amp;</ins> c);
29372</pre></blockquote>
29373
29374<p>
29375Change 23.3.6 [vector], p2:
29376</p>
29377
29378<blockquote><pre>class vector {
29379   ...
29380   void resize(size_type sz, <ins>const </ins>T<ins>&amp;</ins> c);
29381</pre></blockquote>
29382
29383<p>
29384Change 23.3.6.2 [vector.capacity], p11:
29385</p>
29386
29387<blockquote><pre>void resize(size_type sz, <ins>const </ins>T<ins>&amp;</ins> c);
29388</pre></blockquote>
29389
29390
29391
29392
29393
29394
29395<hr>
29396<h3><a name="680"></a>680. move_iterator operator-&gt; return</h3>
29397<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>
29398 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2007-06-11  <b>Last modified:</b> 2008-09-26</p>
29399<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#move.iterator">issues</a> in [move.iterator].</p>
29400<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
29401<p><b>Discussion:</b></p>
29402<p>
29403<tt>move_iterator</tt>'s <tt>operator-&gt;</tt> return type <tt>pointer</tt>
29404does not consistently match the type which is returned in the description
29405in 24.5.3.3.5 [move.iter.op.ref].
29406</p>
29407
29408<blockquote><pre>template &lt;class Iterator&gt;
29409class move_iterator {
29410public:
29411    ...
29412    typedef typename iterator_traits&lt;Iterator&gt;::pointer pointer;
29413    ...
29414    pointer operator-&gt;() const {return current;}
29415    ...
29416private: 
29417    Iterator current; // exposition only
29418};
29419</pre></blockquote>
29420
29421
29422<p>
29423There are two possible fixes.
29424</p>
29425
29426<ol>
29427<li><tt>pointer operator-&gt;() const {return &amp;*current;}</tt></li>
29428<li><tt>typedef Iterator pointer;</tt></li>
29429</ol>
29430
29431<p>
29432The first solution is the one chosen by <tt>reverse_iterator</tt>.  A potential
29433disadvantage of this is it may not work well with iterators which return a
29434proxy on dereference and that proxy has overloaded <tt>operator&amp;()</tt>.  Proxy
29435references often need to overloaad <tt>operator&amp;()</tt> to return a proxy
29436pointer.  That proxy pointer may or may not be the same type as the iterator's
29437<tt>pointer</tt> type.
29438</p>
29439
29440<p>
29441By simply returning the <tt>Iterator</tt> and taking advantage of the fact that
29442the language forwards calls to <tt>operator-&gt;</tt> automatically until it
29443finds a non-class type, the second solution avoids the issue of an overloaded
29444<tt>operator&amp;()</tt> entirely.
29445</p>
29446
29447<p><b>Proposed resolution:</b></p>
29448<p>
29449Change the synopsis in 24.5.3.1 [move.iterator]:
29450</p>
29451
29452<blockquote><pre>typedef <del>typename iterator_traits&lt;</del>Iterator<del>&gt;::pointer</del> pointer;
29453</pre></blockquote>
29454
29455
29456
29457
29458
29459
29460<hr>
29461<h3><a name="681"></a>681. Operator functions impossible to compare are defined in [re.submatch.op]</h3>
29462<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#CD1">CD1</a>
29463 <b>Submitter:</b> Nozomu Katoo <b>Opened:</b> 2007-05-27  <b>Last modified:</b> 2009-05-01</p>
29464<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.submatch.op">issues</a> in [re.submatch.op].</p>
29465<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
29466<p><b>Discussion:</b></p>
29467<p>
29468In 28.9.2 [re.submatch.op] of N2284, 
29469operator functions numbered 31-42 seem impossible to compare. E.g.: 
29470</p>
29471
29472<blockquote>
29473<pre>template &lt;class BiIter&gt;
29474   bool operator==(typename iterator_traits&lt;BiIter&gt;::value_type const&amp; lhs,
29475                    const sub_match&lt;BiIter&gt;&amp; rhs);
29476</pre>
29477<blockquote>
29478<p>
29479-31- <i>Returns:</i> <tt>lhs == rhs.str()</tt>.
29480</p>
29481</blockquote>
29482</blockquote>
29483
29484<p>
29485When <tt>char*</tt> is used as <tt>BiIter</tt>, <tt>iterator_traits&lt;BiIter&gt;::value_type</tt> would be 
29486<tt>char</tt>, so that <tt>lhs == rhs.str()</tt> ends up comparing a <tt>char</tt> value and an object 
29487of <tt>std::basic_string&lt;char&gt;</tt>.  However, the behaviour of comparison between 
29488these two types is not defined in 21.4.8 [string.nonmembers] of N2284.
29489 This applies when <tt>wchar_t*</tt> is used as <tt>BiIter</tt>. 
29490</p>
29491
29492
29493<p><b>Proposed resolution:</b></p>
29494<p>
29495Adopt the proposed resolution in
29496<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2409.pdf">N2409</a>.
29497</p>
29498
29499
29500<p><i>[
29501Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue.
29502The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
29503]</i></p>
29504
29505
29506
29507
29508
29509<hr>
29510<h3><a name="682"></a>682. basic_regex ctor takes InputIterator or ForwardIterator?</h3>
29511<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#CD1">CD1</a>
29512 <b>Submitter:</b> Eric Niebler <b>Opened:</b> 2007-06-03  <b>Last modified:</b> 2009-05-01</p>
29513<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>
29514<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
29515<p><b>Discussion:</b></p>
29516<p>
29517Looking at N2284, 28.8 [re.regex], p3 <tt>basic_regex</tt> class template synopsis shows this 
29518constructor: 
29519</p>
29520<blockquote><pre>template &lt;class InputIterator&gt;
29521     basic_regex(InputIterator first, InputIterator last, 
29522                 flag_type f = regex_constants::ECMAScript);
29523</pre></blockquote>
29524
29525<p>
29526In 28.8.2 [re.regex.construct], p15, the constructor appears with this signature: 
29527</p>
29528
29529<blockquote><pre>template &lt;class ForwardIterator&gt;
29530     basic_regex(ForwardIterator first, ForwardIterator last, 
29531                 flag_type f = regex_constants::ECMAScript);
29532</pre></blockquote>
29533
29534<p>
29535<tt>ForwardIterator</tt> is probably correct, so the synopsis is wrong.
29536</p>
29537
29538<p><i>[
29539John adds:
29540]</i></p>
29541
29542
29543<blockquote>
29544<p>
29545I think either could be implemented?  Although an input iterator would 
29546probably require an internal copy of the string being made.
29547</p>
29548<p>
29549I have no strong feelings either way, although I think my original intent 
29550was <tt>InputIterator</tt>. 
29551</p>
29552</blockquote>
29553
29554
29555<p><b>Proposed resolution:</b></p>
29556<p>
29557Adopt the proposed resolution in
29558<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2409.pdf">N2409</a>.
29559</p>
29560
29561
29562<p><i>[
29563Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue.
29564The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
29565]</i></p>
29566
29567
29568
29569
29570
29571<hr>
29572<h3><a name="685"></a>685. reverse_iterator/move_iterator difference has invalid signatures</h3>
29573<p><b>Section:</b> 24.5.1.3.19 [reverse.iter.opdiff], 24.5.3.3.14 [move.iter.nonmember] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
29574 <b>Submitter:</b> Bo Persson <b>Opened:</b> 2007-06-10  <b>Last modified:</b> 2008-09-26</p>
29575<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
29576<p><b>Discussion:</b></p>
29577<p>
29578In C++03 the difference between two <tt>reverse_iterators</tt>
29579</p>
29580<blockquote><pre>ri1 - ri2
29581</pre></blockquote>
29582<p>
29583is possible to compute only if both iterators have the same base 
29584iterator. The result type is the <tt>difference_type</tt> of the base iterator. 
29585</p>
29586<p>
29587In the current draft, the operator is defined as 24.5.1.3.19 [reverse.iter.opdiff] 
29588</p>
29589<blockquote><pre>template&lt;class Iterator1, class Iterator2&gt; 
29590typename reverse_iterator&lt;Iterator&gt;::difference_type 
29591   operator-(const reverse_iterator&lt;Iterator1&gt;&amp; x, 
29592                    const reverse_iterator&lt;Iterator2&gt;&amp; y);
29593</pre></blockquote>
29594<p>
29595The return type is the same as the C++03 one, based on the no longer 
29596present <tt>Iterator</tt> template parameter. 
29597</p>
29598<p>
29599Besides being slightly invalid, should this operator work only when 
29600<tt>Iterator1</tt> and <tt>Iterator2</tt> has the same <tt>difference_type</tt>? Or should the 
29601implementation choose one of them? Which one? 
29602</p>
29603<p>
29604The same problem now also appears in <tt>operator-()</tt> for <tt>move_iterator</tt>
2960524.5.3.3.14 [move.iter.nonmember]. 
29606</p>
29607
29608
29609<p><b>Proposed resolution:</b></p>
29610<p>
29611Change the synopsis in 24.5.1.1 [reverse.iterator]:
29612</p>
29613
29614<blockquote>
29615<pre>template &lt;class Iterator1, class Iterator2&gt; 
29616  <del>typename reverse_iterator&lt;Iterator&gt;::difference_type</del> <ins>auto</ins> operator-( 
29617    const reverse_iterator&lt;Iterator1&gt;&amp; x, 
29618    const reverse_iterator&lt;Iterator2&gt;&amp; y)<ins> -&gt; decltype(y.current - x.current)</ins>;
29619</pre>
29620</blockquote>
29621
29622<p>
29623Change 24.5.1.3.19 [reverse.iter.opdiff]:
29624</p>
29625
29626<blockquote>
29627<pre>template &lt;class Iterator1, class Iterator2&gt; 
29628  <del>typename reverse_iterator&lt;Iterator&gt;::difference_type</del> <ins>auto</ins> operator-( 
29629    const reverse_iterator&lt;Iterator1&gt;&amp; x, 
29630    const reverse_iterator&lt;Iterator2&gt;&amp; y)<ins> -&gt; decltype(y.current - x.current)</ins>;
29631</pre>
29632<blockquote>
29633<p>
29634<i>Returns:</i> <tt>y.current - x.current</tt>.
29635</p>
29636</blockquote>
29637</blockquote>
29638
29639
29640<p>
29641Change the synopsis in 24.5.3.1 [move.iterator]:
29642</p>
29643
29644<blockquote>
29645<pre>template &lt;class Iterator1, class Iterator2&gt; 
29646  <del>typename move_iterator&lt;Iterator&gt;::difference_type</del> <ins>auto</ins> operator-( 
29647    const move_iterator&lt;Iterator1&gt;&amp; x, 
29648    const move_iterator&lt;Iterator2&gt;&amp; y)<ins> -&gt; decltype(x.base() - y.base())</ins>;
29649</pre>
29650</blockquote>
29651
29652<p>
29653Change 24.5.3.3.14 [move.iter.nonmember]:
29654</p>
29655
29656<blockquote>
29657<pre>template &lt;class Iterator1, class Iterator2&gt; 
29658  <del>typename move_iterator&lt;Iterator&gt;::difference_type</del> <ins>auto</ins> operator-( 
29659    const move_iterator&lt;Iterator1&gt;&amp; x, 
29660    const move_iterator&lt;Iterator2&gt;&amp; y)<ins> -&gt; decltype(x.base() - y.base())</ins>;
29661</pre>
29662<blockquote>
29663<p>
29664<i>Returns:</i> <tt>x.base() - y.base()</tt>.
29665</p>
29666</blockquote>
29667</blockquote>
29668
29669<p><i>[
29670Pre Bellevue:  This issue needs to wait until the <tt>auto -&gt; return</tt> language feature
29671goes in.
29672]</i></p>
29673
29674
29675
29676
29677
29678
29679
29680<hr>
29681<h3><a name="687"></a>687. shared_ptr conversion constructor not constrained</h3>
29682<p><b>Section:</b> 20.8.15.2.1 [util.smartptr.shared.const], 20.8.15.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>
29683 <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2007-05-10  <b>Last modified:</b> 2009-02-02</p>
29684<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>
29685<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
29686<p><b>Discussion:</b></p>
29687<p>
29688Since all conversions from <tt>shared_ptr&lt;T&gt;</tt> to <tt>shared_ptr&lt;U&gt;</tt> have the same
29689rank regardless of the relationship between <tt>T</tt> and <tt>U</tt>, reasonable user
29690code that works with raw pointers fails with <tt>shared_ptr</tt>:
29691</p>
29692
29693<blockquote><pre>void f( shared_ptr&lt;void&gt; );
29694void f( shared_ptr&lt;int&gt; );
29695
29696int main()
29697{
29698  f( shared_ptr&lt;double&gt;() ); // ambiguous
29699}
29700</pre></blockquote>
29701
29702<p>
29703Now that we officially have <tt>enable_if</tt>, we can constrain the constructor
29704and the corresponding assignment operator to only participate in the
29705overload resolution when the pointer types are compatible.
29706</p>
29707
29708
29709<p><b>Proposed resolution:</b></p>
29710<p>
29711In 20.8.15.2.1 [util.smartptr.shared.const], change:
29712</p>
29713
29714<blockquote><p>
29715-14- <i>Requires:</i> <del>For the second constructor</del> <ins>The
29716second constructor shall not participate in the overload resolution
29717unless</ins> <tt>Y*</tt> <del>shall be</del> <ins>is implicitly</ins> convertible
29718to <tt>T*</tt>.
29719</p></blockquote>
29720
29721<p>
29722In 20.8.15.3.1 [util.smartptr.weak.const], change:
29723</p>
29724
29725<blockquote>
29726<pre><del>template&lt;class Y&gt; weak_ptr(shared_ptr&lt;Y&gt; const&amp; r);</del>
29727<del>weak_ptr(weak_ptr const&amp; r);</del>
29728<del>template&lt;class Y&gt; weak_ptr(weak_ptr&lt;Y&gt; const&amp; r);</del>
29729<ins>weak_ptr(weak_ptr const&amp; r);</ins>
29730<ins>template&lt;class Y&gt; weak_ptr(weak_ptr&lt;Y&gt; const&amp; r);</ins>
29731<ins>template&lt;class Y&gt; weak_ptr(shared_ptr&lt;Y&gt; const&amp; r);</ins>
29732</pre>
29733<blockquote><p>
29734-4- <i>Requires:</i> <del>For</del> <del>t</del><ins>T</ins>he second and
29735third constructors<del>,</del> <ins>shall not participate in the
29736overload resolution unless</ins> <tt>Y*</tt> <del>shall be</del>
29737<ins>is implicitly</ins> convertible to <tt>T*</tt>.
29738</p></blockquote>
29739</blockquote>
29740
29741
29742
29743
29744
29745
29746<hr>
29747<h3><a name="688"></a>688. reference_wrapper, cref unsafe, allow binding to rvalues</h3>
29748<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#WP">WP</a>
29749 <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2007-05-10  <b>Last modified:</b> 2009-07-18</p>
29750<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>
29751<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
29752<p><b>Discussion:</b></p>
29753<p>
29754A <tt>reference_wrapper</tt> can be constructed from an rvalue, either by using
29755the constructor, or via <tt>cref</tt> (and <tt>ref</tt> in some corner cases). This leads
29756to a dangling reference being stored into the <tt>reference_wrapper</tt> object.
29757Now that we have a mechanism to detect an rvalue, we can fix them to
29758disallow this source of undefined behavior.
29759</p>
29760
29761<p>
29762Also please see the thread starting at c++std-lib-17398 for some good discussion on this subject.
29763</p>
29764
29765<p><i>[
297662009-05-09 Alisdair adds:
29767]</i></p>
29768
29769
29770<blockquote>
29771<p>
29772Now that <tt>ref/cref</tt> are constained that <tt>T</tt> must be an <tt>ObjectType</tt>, I do not
29773believe there is any risk of binding <tt>ref</tt> to a temporary (which would rely on
29774deducing <tt>T</tt> to be an rvalue reference type)
29775</p>
29776<p>
29777However, the problem for <tt>cref</tt> remains, so I recommend retaining that deleted
29778overload.
29779</p>
29780</blockquote>
29781
29782<p><i>[
297832009-05-10 Howard adds:
29784]</i></p>
29785
29786
29787<blockquote>
29788<p>
29789Without:
29790</p>
29791
29792<blockquote><pre>template &lt;class T&gt; void ref(const T&amp;&amp; t) = delete;
29793</pre></blockquote>
29794<p>
29795I believe this program will compile:
29796</p>
29797
29798<blockquote><pre>#include &lt;functional&gt;
29799
29800struct A {};
29801
29802const A source() {return A();}
29803
29804int main()
29805{
29806   std::reference_wrapper&lt;const A&gt; r = std::ref(source());
29807}
29808</pre></blockquote>
29809<p>
29810I.e. in:
29811</p>
29812<blockquote><pre>template &lt;ObjectType T&gt; reference_wrapper&lt;T&gt; ref(T&amp; t);
29813</pre></blockquote>
29814
29815<p>
29816this:
29817</p>
29818
29819<blockquote><pre>ref(source())
29820</pre></blockquote>
29821<p>
29822deduces <tt>T</tt> as <tt>const A</tt>, and so:
29823</p>
29824
29825<blockquote><pre>ref(const A&amp; t)
29826</pre></blockquote>
29827
29828<p>
29829will bind to a temporary (tested with a pre-concepts rvalue-ref enabled compiler).
29830</p>
29831<p>
29832Therefore I think we still need the ref-protection.  I respectfully disagree with Alisdair's
29833comment and am in favor of the proposed wording as it stands.  Also, CWG 606
29834(noted below) has now been "favorably" resolved.
29835</p>
29836
29837</blockquote>
29838
29839<p><i>[
29840Batavia (2009-05):
29841]</i></p>
29842
29843<blockquote>
29844We agree with the proposed resolution.
29845Move to Tentatively Ready.
29846</blockquote>
29847
29848
29849<p><b>Proposed resolution:</b></p>
29850<p>
29851In 20.7 [function.objects], add the following two signatures to the synopsis:
29852</p>
29853
29854<blockquote><pre>template &lt;class T&gt; void ref(const T&amp;&amp; t) = delete;
29855template &lt;class T&gt; void cref(const T&amp;&amp; t) = delete;
29856</pre></blockquote>
29857
29858
29859
29860<p><i>[
29861<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2292.html">N2292</a>
29862addresses the first part of the resolution but not the second.
29863]</i></p>
29864
29865
29866<p><i>[
29867Bellevue:  Doug noticed problems with the current wording.
29868]</i></p>
29869
29870
29871<p><i>[
29872post Bellevue:  Howard and Peter provided revised wording.
29873]</i></p>
29874
29875
29876<p><i>[
29877This resolution depends on a "favorable" resolution of CWG 606:  that is,
29878the "special deduction rule" is disabled with the const T&amp;&amp; pattern.
29879]</i></p>
29880
29881
29882
29883
29884
29885<hr>
29886<h3><a name="689"></a>689. reference_wrapper constructor overly constrained</h3>
29887<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>
29888 <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2007-05-10  <b>Last modified:</b> 2008-09-26</p>
29889<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>
29890<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
29891<p><b>Discussion:</b></p>
29892<p>
29893The constructor of <tt>reference_wrapper</tt> is currently <tt>explicit</tt>. The primary
29894motivation behind this is the safety problem with respect to rvalues,
29895which is addressed by the proposed resolution of the previous issue.
29896Therefore we should consider relaxing the requirements on the
29897constructor since requests for the implicit conversion keep resurfacing.
29898</p>
29899<p>
29900Also please see the thread starting at c++std-lib-17398 for some good discussion on this subject.
29901</p>
29902
29903
29904<p><b>Proposed resolution:</b></p>
29905<p>
29906Remove the <tt>explicit</tt> from the constructor of <tt>reference_wrapper</tt>. If the
29907proposed resolution of the previous issue is accepted, remove the
29908<tt>explicit</tt> from the <tt>T&amp;&amp;</tt> constructor as well to keep them in sync.
29909</p>
29910
29911
29912
29913
29914
29915<hr>
29916<h3><a name="691"></a>691. const_local_iterator cbegin, cend missing from TR1</h3>
29917<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>
29918 <b>Submitter:</b> Joaqu�n M L�pez Mu�oz <b>Opened:</b> 2007-06-14  <b>Last modified:</b> 2008-09-26</p>
29919<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>
29920<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
29921<p><b>Discussion:</b></p>
29922<p>
29923The last version of TR1 does not include the following member
29924functions
29925for unordered containers:
29926</p>
29927
29928<blockquote><pre>const_local_iterator cbegin(size_type n) const;
29929const_local_iterator cend(size_type n) const;
29930</pre></blockquote>
29931
29932<p>
29933which looks like an oversight to me. I've checked th TR1 issues lists
29934and the latest working draft of the C++0x std (N2284) and haven't
29935found any mention to these menfuns or to their absence.
29936</p>
29937<p>
29938Is this really an oversight, or am I missing something?
29939</p>
29940
29941
29942
29943<p><b>Proposed resolution:</b></p>
29944<p>
29945Add the following two rows to table 93 (unordered associative container
29946requirements) in section 23.2.5 [unord.req]:
29947</p>
29948
29949<blockquote>
29950<table border="1">
29951<caption>Unordered associative container requirements (in addition to container)</caption>
29952<tbody><tr>
29953<th>expression</th> <th>return type</th> <th>assertion/note pre/post-condition</th> <th>complexity</th>
29954</tr>
29955<tr>
29956<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> 
29957</tr>
29958<tr>
29959<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> 
29960</tr>
29961</tbody></table>
29962</blockquote>
29963
29964<p>
29965Add to the synopsis in 23.5.1 [unord.map]:
29966</p>
29967
29968<blockquote><pre><ins>const_local_iterator cbegin(size_type n) const;
29969const_local_iterator cend(size_type n) const;</ins>
29970</pre></blockquote>
29971
29972<p>
29973Add to the synopsis in 23.5.2 [unord.multimap]:
29974</p>
29975
29976<blockquote><pre><ins>const_local_iterator cbegin(size_type n) const;
29977const_local_iterator cend(size_type n) const;</ins>
29978</pre></blockquote>
29979
29980<p>
29981Add to the synopsis in 23.5.3 [unord.set]:
29982</p>
29983
29984<blockquote><pre><ins>const_local_iterator cbegin(size_type n) const;
29985const_local_iterator cend(size_type n) const;</ins>
29986</pre></blockquote>
29987
29988<p>
29989Add to the synopsis in 23.5.4 [unord.multiset]:
29990</p>
29991
29992<blockquote><pre><ins>const_local_iterator cbegin(size_type n) const;
29993const_local_iterator cend(size_type n) const;</ins>
29994</pre></blockquote>
29995
29996
29997
29998
29999
30000
30001<hr>
30002<h3><a name="692"></a>692. <code>get_money</code> and <code>put_money</code> should be formatted I/O functions</h3>
30003<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>
30004 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-06-22  <b>Last modified:</b> 2008-09-26</p>
30005<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>
30006<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
30007<p><b>Discussion:</b></p>
30008<p>
30009In a private email Bill Plauger notes:
30010</p>
30011<blockquote><p>
30012I  believe that  the function  that  implements <code>get_money</code>
30013[from <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2072.html">N2072</a>]
30014should behave  as a  formatted input function,  and the  function that
30015implements <code>put_money</code> should  behave as a formatted output
30016function. This  has implications regarding the  skipping of whitespace
30017and the handling of errors, among other things.
30018</p>
30019<p>
30020The words  don't say that  right now and  I'm far from  convinced that
30021such a change is editorial.
30022</p></blockquote>
30023<p>
30024Martin's response:
30025</p>
30026<blockquote><p>
30027I agree that the manipulators should handle exceptions the same way as
30028formatted I/O functions do. The text in N2072 assumes so but the
30029<i>Returns</i> clause explicitly omits exception handling for the sake
30030of brevity. The spec should be clarified to that effect.
30031</p>
30032<p>
30033As for dealing  with whitespace, I also agree it  would make sense for
30034the extractors  and inserters involving the new  manipulators to treat
30035it the same way as formatted I/O.
30036</p></blockquote>
30037
30038
30039<p><b>Proposed resolution:</b></p>
30040<p>
30041Add  a new  paragraph immediately  above  p4 of 27.7.4 [ext.manip] with  the
30042following text:
30043</p>
30044<blockquote><p>
30045<i>Effects</i>:  The   expression  <code><i>in</i> &gt;&gt; get_money(mon, intl)</code>
30046described below behaves as a formatted input function (as
30047described in 27.7.1.2.1 [istream.formatted.reqmts]).
30048</p></blockquote>
30049<p>
30050Also change p4 of 27.7.4 [ext.manip] as follows:
30051</p>
30052<blockquote><p>
30053<i>Returns</i>: An object <code>s</code> of unspecified type such that
30054if <code>in</code> is  an object of type <code>basic_istream&lt;charT,
30055traits&gt;</code>    then    the    expression   <code><i>in</i> &gt;&gt; get_money(mon, intl)</code> behaves as <ins>a formatted input function
30056that    calls    </ins><code>f(in, mon, intl)</code><del>    were
30057called</del>. The function <code>f</code> can be defined as...
30058</p></blockquote>
30059
30060
30061<p><i>[
30062post Bellevue:
30063]</i></p>
30064
30065
30066<blockquote>
30067We recommend moving immediately to Review. We've looked at the issue and
30068have a consensus that the proposed resolution is correct, but want an
30069iostream expert to sign off. Alisdair has taken the action item to putt
30070this up on the reflector for possible movement by Howard to Tenatively
30071Ready.
30072</blockquote>
30073
30074
30075
30076
30077<hr>
30078<h3><a name="693"></a>693. <code>std::bitset::all()</code> missing</h3>
30079<p><b>Section:</b> 20.3.7 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
30080 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-06-22  <b>Last modified:</b> 2008-09-26</p>
30081<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>
30082<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>
30083<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
30084<p><b>Discussion:</b></p>
30085<p>
30086The  <code>bitset</code> class template  provides the  member function
30087<code>any()</code> to determine whether an  object of the type has any
30088bits  set, and  the member  function <code>none()</code>  to determine
30089whether all of an object's  bits are clear. However, the template does
30090not   provide  a   corresponding  function   to  discover   whether  a
30091<code>bitset</code>  object  has  all  its  bits  set.   While  it  is
30092possible,  even easy,  to  obtain this  information  by comparing  the
30093result of <code>count()</code>  with the result of <code>size()</code>
30094for  equality  (i.e.,  via  <code>b.count()  ==  b.size()</code>)  the
30095operation  is   less  efficient   than  a  member   function  designed
30096specifically  for that purpose  could be.   (<code>count()</code> must
30097count  all non-zero bits  in a  <code>bitset</code> a  word at  a time
30098while <code>all()</code> could stop counting as soon as it encountered
30099the first word with a zero bit).
30100</p>
30101
30102
30103<p><b>Proposed resolution:</b></p>
30104<p>
30105Add  a declaration of the new  member function <code>all()</code> to the
30106defintion of the <code>bitset</code> template in 20.3.7 [template.bitset], p1,
30107right above the declaration of <code>any()</code> as shown below:
30108</p>
30109
30110<blockquote><pre>bool operator!=(const bitset&lt;N&gt;&amp; rhs) const;
30111bool test(size_t pos) const;
30112<ins>bool all() const;</ins>
30113bool any() const;
30114bool none() const;
30115</pre></blockquote>
30116
30117<p>
30118Add a description of the new member function to the end of 20.3.7.2 [bitset.members] with the following text:
30119</p>
30120<blockquote><p>
30121<code>bool all() const;</code>
30122</p>
30123<blockquote>
30124<i>Returns</i>: <code>count() == size()</code>.
30125</blockquote>
30126</blockquote>
30127
30128<p>
30129In  addition,   change  the  description   of  <code>any()</code>  and
30130<code>none()</code>   for  consistency   with   <code>all()</code>  as
30131follows:
30132</p>
30133<blockquote><p>
30134<code>bool any() const;</code>
30135</p>
30136<blockquote>
30137<p>
30138<i>Returns</i>: <del><code>true</code> if any bit in <code>*this</code>
30139is one</del><ins><code>count() != 0</code></ins>.
30140</p>
30141</blockquote>
30142<p>
30143<code>bool none() const;</code>
30144</p>
30145<blockquote>
30146<p>
30147<i>Returns</i>: <del><code>true</code> if no bit in <code>*this</code>
30148is one</del><ins><code>count() == 0</code></ins>.
30149</p>
30150</blockquote>
30151</blockquote>
30152
30153
30154
30155
30156
30157<hr>
30158<h3><a name="694"></a>694. <code>std::bitset</code> and <code>long long</code></h3>
30159<p><b>Section:</b> 20.3.7 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
30160 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-06-22  <b>Last modified:</b> 2008-09-26</p>
30161<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>
30162<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>
30163<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
30164<p><b>Discussion:</b></p>
30165<p>
30166Objects of the  <code>bitset</code> class template specializations can
30167be constructed from  and explicitly converted to values  of the widest
30168C++ integer  type, <code>unsigned long</code>.   With the introduction
30169of  <code>long long</code> into  the language  the template  should be
30170enhanced to make it possible  to interoperate with values of this type
30171as well, or  perhaps <code>uintmax_t</code>.  See c++std-lib-18274 for
30172a brief discussion in support of this change.
30173</p>
30174
30175
30176<p><b>Proposed resolution:</b></p>
30177<p>
30178For simplicity,  instead of  adding overloads for  <code>unsigned long
30179long</code> and dealing with possible ambiguities in the spec, replace
30180the <code>bitset</code> ctor  that takes an <code>unsigned long</code>
30181argument  with  one  taking  <code>unsigned long  long</code>  in  the
30182definition  of the  template as  shown below.   (The  standard permits
30183implementations  to add  overloads on  other integer  types  or employ
30184template tricks to  achieve the same effect provided  they don't cause
30185ambiguities or changes in behavior.)
30186</p>
30187<blockquote>
30188<pre>// [bitset.cons] constructors:
30189bitset();
30190bitset(unsigned <ins>long</ins> long val);
30191template&lt;class charT, class traits, class Allocator&gt;
30192explicit bitset(
30193                const basic_string&lt;charT,traits,Allocator&gt;&amp; str,
30194                typename basic_string&lt;charT,traits,Allocator&gt;::size_type pos = 0,
30195                typename basic_string&lt;charT,traits,Allocator&gt;::size_type n =
30196                    basic_string&lt;charT,traits,Allocator&gt;::npos);
30197</pre>
30198</blockquote>
30199<p>
30200Make a corresponding change in 20.3.7.1 [bitset.cons], p2:
30201</p>
30202<blockquote>
30203<p>
30204<code>bitset(unsigned <ins>long</ins> long val);</code>
30205</p>
30206<blockquote>
30207<i>Effects</i>:  Constructs   an  object  of   class  bitset&lt;N&gt;,
30208initializing  the  first <code><i>M</i></code>  bit  positions to  the
30209corresponding      bit     values      in     <code><i>val</i></code>.
30210<code><i>M</i></code> is the  smaller of <code><i>N</i></code> and the
30211number of bits in  the value representation (section [basic.types]) of
30212<code>unsigned  <ins> long</ins> long</code>.   If  <code><i>M</i> &lt;
30213<i>N</i></code>  <ins>is  <code>true</code></ins>,  the remaining  bit
30214positions are initialized to zero.
30215</blockquote>
30216</blockquote>
30217
30218<p>
30219Additionally, introduce a new member function <code>to_ullong()</code>
30220to make  it possible to  convert <code>bitset</code> to values  of the
30221new  type. Add  the following  declaration  to the  definition of  the
30222template, immediate  after the declaration  of <code>to_ulong()</code>
30223in 20.3.7 [template.bitset], p1, as shown below:
30224</p>
30225<blockquote>
30226<pre>// element access:
30227bool operator[](size_t pos) const; // for b[i];
30228reference operator[](size_t pos); // for b[i];
30229unsigned long to_ulong() const;
30230<ins>unsigned long long to_ullong() const;</ins>
30231template &lt;class charT, class traits, class Allocator&gt;
30232basic_string&lt;charT, traits, Allocator&gt; to_string() const;
30233</pre>
30234</blockquote>
30235<p>
30236And add a description of  the new member function to 20.3.7.2 [bitset.members],
30237below  the  description of  the  existing <code>to_ulong()</code>  (if
30238possible), with the following text:
30239</p>
30240<blockquote>
30241<p>
30242<code>unsigned long long to_ullong() const;</code>
30243</p>
30244<blockquote>
30245<i>Throws</i>:  <code>overflow_error</code>   if  the  integral  value
30246<code><i>x</i></code> corresponding to  the bits in <code>*this</code>
30247cannot be represented as type <code>unsigned long long</code>.
30248</blockquote>
30249<blockquote>
30250<i>Returns:</i> <code><i>x</i></code>.
30251</blockquote>
30252</blockquote>
30253
30254
30255
30256
30257
30258<hr>
30259<h3><a name="695"></a>695. ctype&lt;char&gt;::classic_table() not accessible</h3>
30260<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>
30261 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-06-22  <b>Last modified:</b> 2008-09-26</p>
30262<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
30263<p><b>Discussion:</b></p>
30264<p>
30265The   <code>ctype&lt;char&gt;::classic_table()</code>   static  member
30266function    returns    a    pointer    to   an    array    of    const
30267<code>ctype_base::mask</code>    objects    (enums)   that    contains
30268<code>ctype&lt;char&gt;::table_size</code>    elements.    The   table
30269describes the properties of the character set in the "C" locale (i.e.,
30270whether a  character at an index  given by its value  is alpha, digit,
30271punct,   etc.),   and   is    typically   used   to   initialize   the
30272<code>ctype&lt;char&gt;</code>  facet in the  classic "C"  locale (the
30273protected      <code>ctype&lt;char&gt;</code>      member     function
30274<code>table()</code>    then    returns     the    same    value    as
30275<code>classic_table()</code>).
30276</p>
30277<p>
30278However, while <code>ctype&lt;char&gt;::table_size</code> (the size of
30279the   table)    is   a   public    static   const   member    of   the
30280<code>ctype&lt;char&gt;</code>           specialization,           the
30281<code>classic_table()</code> static member function is protected. That
30282makes getting at the classic  data less than convenient (i.e., one has
30283to create  a whole derived class just  to get at the  masks array). It
30284makes  little sense  to expose  the size  of the  table in  the public
30285interface while making the table itself protected, especially when the
30286table is a constant object.
30287</p>
30288<p>
30289The  same argument  can be  made for  the non-static  protected member
30290function <code>table()</code>.
30291</p>
30292
30293
30294<p><b>Proposed resolution:</b></p>
30295<p>
30296Make     the    <code>ctype&lt;char&gt;::classic_table()</code>    and
30297<code>ctype&lt;char&gt;::table()</code>  member  functions  public  by
30298moving their declarations into the public section of the definition of
30299specialization in 22.4.1.3 [facet.ctype.special] as shown below:
30300</p>
30301<blockquote>
30302<pre>  static locale::id id;
30303  static const size_t table_size = IMPLEMENTATION_DEFINED;
30304<del>protected:</del>
30305  const mask* table() const throw();
30306  static const mask* classic_table() throw();
30307<ins>protected:</ins>
30308
30309~ctype(); // virtual
30310virtual char do_toupper(char c) const;
30311</pre>
30312</blockquote>
30313
30314
30315
30316
30317
30318<hr>
30319<h3><a name="696"></a>696. <code>istream::operator&gt;&gt;(int&amp;)</code> broken</h3>
30320<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#WP">WP</a>
30321 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-06-23  <b>Last modified:</b> 2009-10-26</p>
30322<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>
30323<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
30324<p><b>Discussion:</b></p>
30325<p>
30326From message c++std-lib-17897:
30327</p>
30328<p>
30329The code shown in 27.7.1.2.2 [istream.formatted.arithmetic] as the "as if"
30330implementation of the two arithmetic extractors that don't have a
30331corresponding <code>num_get</code> interface (i.e., the
30332<code>short</code> and <code>int</code> overloads) is subtly buggy in
30333how it deals with <code>EOF</code>, overflow, and other similar
30334conditions (in addition to containing a few typos).
30335</p>
30336<p>
30337One problem is that if <code>num_get::get()</code> reaches the EOF
30338after reading in an otherwise valid value that exceeds the limits of
30339the narrower type (but not <code>LONG_MIN</code> or
30340<code>LONG_MAX</code>), it will set <code><i>err</i></code> to
30341<code>eofbit</code>. Because of the if condition testing for
30342<code>(<i>err</i> == 0)</code>, the extractor won't set
30343<code>failbit</code> (and presumably, return a bogus value to the
30344caller).
30345</p>
30346<p>
30347Another problem with the code is that it never actually sets the
30348argument to the extracted value. It can't happen after the call to
30349<code>setstate()</code> since the function may throw, so we need to
30350show when and how it's done (we can't just punt as say: "it happens
30351afterwards"). However, it turns out that showing how it's done isn't
30352quite so easy since the argument is normally left unchanged by the
30353facet on error except when the error is due to a misplaced thousands
30354separator, which causes <code>failbit</code> to be set but doesn't
30355prevent the facet from storing the value.
30356</p>
30357
30358<p><i>[
30359Batavia (2009-05):
30360]</i></p>
30361
30362<blockquote>
30363<p>
30364We believe this part of the Standard has been recently adjusted
30365and that this issue was addressed during that rewrite.
30366</p>
30367<p>
30368Move to NAD.
30369</p>
30370</blockquote>
30371
30372<p><i>[
303732009-05-28 Howard adds:
30374]</i></p>
30375
30376
30377<blockquote>
30378<p>
30379I've moved this issue from Tentatively NAD to Open.
30380</p>
30381
30382<p>
30383The current wording of
30384<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2857.pdf">N2857</a>
30385in 22.4.2.1.2 [facet.num.get.virtuals] p3, stage 3 appears to indicate that
30386in parsing arithmetic types, the value is always set, but sometimes in addition
30387to setting <tt>failbit</tt>.
30388</p>
30389
30390<ul>
30391<li>
30392If there is a range error, the value is set to min or max, else
30393</li>
30394<li>
30395if there is a conversion error, the value is set to 0, else
30396</li>
30397<li>
30398if there is a grouping error, the value is set to whatever it would be if grouping were ignored, else
30399</li>
30400<li>
30401the value is set to its error-free result.
30402</li>
30403</ul>
30404
30405<p>
30406However there is a contradictory sentence in 22.4.2.1.2 [facet.num.get.virtuals] p1.
30407</p>
30408
30409<p>
3041027.7.1.2.2 [istream.formatted.arithmetic] should mimic the behavior of 22.4.2.1.2 [facet.num.get.virtuals]
30411(whatever we decide that behavior is) for
30412<tt>int</tt> and <tt>short</tt>, and currently does not.  I believe that the
30413correct code fragment should look like:
30414</p>
30415
30416<blockquote><pre>typedef num_get&lt;charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget;
30417iostate err = ios_base::goodbit;
30418long lval;
30419use_facet&lt;numget&gt;(loc).get(*this, 0, *this, err, lval);
30420if (lval &lt; numeric_limits&lt;int&gt;::min())
30421{
30422  err |= ios_base::failbit;
30423  val = numeric_limits&lt;int&gt;::min();
30424}
30425else if (lval &gt; numeric_limits&lt;int&gt;::max())
30426{
30427  err |= ios_base::failbit;
30428  val = numeric_limits&lt;int&gt;::max();
30429}
30430else
30431  val = static_cast&lt;int&gt;(lval);
30432setstate(err);
30433</pre></blockquote>
30434</blockquote>
30435
30436<p><i>[
304372009-07 Frankfurt
30438]</i></p>
30439
30440
30441<blockquote>
30442Move to Ready.
30443</blockquote>
30444
30445
30446
30447<p><b>Proposed resolution:</b></p>
30448<p>
30449Change 22.4.2.1.2 [facet.num.get.virtuals], p1:
30450</p>
30451
30452<blockquote>
30453-1- <i>Effects:</i> Reads characters from <tt>in</tt>, interpreting them
30454according to <tt>str.flags()</tt>, <tt>use_facet&lt;ctype&lt;charT&gt;
30455&gt;(loc)</tt>, and <tt>use_facet&lt; numpunct&lt;charT&gt;
30456&gt;(loc)</tt>, where <tt>loc</tt> is <tt>str.getloc()</tt>. <del>If an error
30457occurs, <tt>val</tt> is unchanged; otherwise it is set to the resulting value.</del>
30458</blockquote>
30459
30460<p>
30461Change 27.7.1.2.2 [istream.formatted.arithmetic], p2 and p3:
30462</p>
30463
30464<blockquote>
30465<pre>operator&gt;&gt;(short&amp; val);
30466</pre>
30467<blockquote>
30468<p>
30469-2- The conversion occurs as if performed by the following code fragment (using the same notation as for 
30470the preceding code fragment):
30471</p>
30472
30473<blockquote><pre>typedef num_get&lt;charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget;
30474iostate err = ios<del>tate</del><ins>_base</ins>::goodbit;
30475long lval;
30476use_facet&lt;numget&gt;(loc).get(*this, 0, *this, err, lval);
30477<del>if (err != 0)
30478  ;
30479else if (lval &lt; numeric_limits&lt;short&gt;::min()
30480  || numeric_limits&lt;short&gt;::max() &lt; lval)
30481     err = ios_base::failbit;</del>
30482<ins>if (lval &lt; numeric_limits&lt;short&gt;::min())
30483{
30484  err |= ios_base::failbit;
30485  val = numeric_limits&lt;short&gt;::min();
30486}
30487else if (lval &gt; numeric_limits&lt;short&gt;::max())
30488{
30489  err |= ios_base::failbit;
30490  val = numeric_limits&lt;short&gt;::max();
30491}</ins>
30492else
30493  val = static_cast&lt;short&gt;(lval);
30494setstate(err);
30495</pre></blockquote>
30496
30497</blockquote>
30498
30499<pre>operator&gt;&gt;(int&amp; val);
30500</pre>
30501<blockquote>
30502<p>
30503-3- The conversion occurs as if performed by the following code fragment (using the same notation as for 
30504the preceding code fragment):
30505</p>
30506
30507<blockquote><pre>typedef num_get&lt;charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget;
30508iostate err = ios<del>tate</del><ins>_base</ins>::goodbit;
30509long lval;
30510use_facet&lt;numget&gt;(loc).get(*this, 0, *this, err, lval);
30511<del>if (err != 0)
30512  ;
30513else if (lval &lt; numeric_limits&lt;int&gt;::min()
30514  || numeric_limits&lt;int&gt;::max() &lt; lval)
30515     err = ios_base::failbit;</del>
30516<ins>if (lval &lt; numeric_limits&lt;int&gt;::min())
30517{
30518  err |= ios_base::failbit;
30519  val = numeric_limits&lt;int&gt;::min();
30520}
30521else if (lval &gt; numeric_limits&lt;int&gt;::max())
30522{
30523  err |= ios_base::failbit;
30524  val = numeric_limits&lt;int&gt;::max();
30525}</ins>
30526else
30527  val = static_cast&lt;int&gt;(lval);
30528setstate(err);
30529</pre></blockquote>
30530
30531</blockquote>
30532
30533</blockquote>
30534
30535
30536
30537
30538
30539<hr>
30540<h3><a name="698"></a>698. <tt>system_error</tt> needs <tt>const char*</tt> constructors</h3>
30541<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>
30542 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2007-06-24  <b>Last modified:</b> 2008-09-26</p>
30543<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
30544<p><b>Discussion:</b></p>
30545<p>
30546In 19.5.5.1 [syserr.syserr.overview] we have the class definition of
30547<tt>std::system_error</tt>. In contrast to all exception classes, which
30548are constructible with a <tt>what_arg string</tt> (see 19.2 [std.exceptions],
30549or <tt>ios_base::failure</tt> in 27.5.2.1.1 [ios::failure]), only overloads with with
30550<tt>const string&amp;</tt> are possible. For consistency with the re-designed
30551remaining exception classes this class should also provide
30552c'tors which accept a const <tt>char* what_arg</tt> string.
30553</p>
30554<p>
30555Please note that this proposed addition makes sense even
30556considering the given implementation hint for <tt>what()</tt>, because
30557<tt>what_arg</tt> is required to be set as <tt>what_arg</tt> of the base class
30558<tt>runtime_error</tt>, which now has the additional c'tor overload
30559accepting a <tt>const char*</tt>.
30560</p>
30561
30562
30563<p><b>Proposed resolution:</b></p>
30564<p>
30565This 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.
30566</p>
30567
30568<p>
30569Change 19.5.5.1 [syserr.syserr.overview] Class system_error overview, as indicated:
30570</p>
30571
30572<blockquote><pre>public:
30573  system_error(error_code ec, const string&amp; what_arg);
30574  <ins>system_error(error_code ec, const char* what_arg);</ins>
30575  system_error(error_code ec);
30576  system_error(int ev, const error_category* ecat,
30577      const string&amp; what_arg);
30578  <ins>system_error(int ev, const error_category* ecat,
30579      const char* what_arg);</ins>
30580  system_error(int ev, const error_category* ecat);
30581</pre></blockquote>
30582
30583<p>
30584To 19.5.5.2 [syserr.syserr.members] Class system_error members add:
30585</p>
30586
30587<blockquote>
30588<pre>system_error(error_code ec, const char* what_arg);
30589</pre>
30590<blockquote>
30591<p>
30592<i>Effects:</i> Constructs an object of class <tt>system_error</tt>.
30593</p>
30594<p>
30595<i>Postconditions:</i> <tt>code() == ec</tt> and <tt>strcmp(runtime_error::what(), what_arg) == 0</tt>.
30596</p>
30597</blockquote>
30598
30599<pre>system_error(int ev, const error_category* ecat, const char* what_arg);
30600</pre>
30601
30602<blockquote>
30603<p>
30604<i>Effects:</i> Constructs an object of class <tt>system_error</tt>.
30605</p>
30606<p>
30607<i>Postconditions:</i> <tt>code() == error_code(ev, ecat)</tt> and <tt>strcmp(runtime_error::what(), what_arg) == 0</tt>.
30608</p>
30609</blockquote>
30610</blockquote>
30611
30612
30613
30614
30615
30616
30617<hr>
30618<h3><a name="699"></a>699. N2111 changes min/max</h3>
30619<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>
30620 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2007-07-01  <b>Last modified:</b> 2008-09-26</p>
30621<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>
30622<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
30623<p><b>Discussion:</b></p>
30624<p>
30625<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2111.pdf">N2111</a>
30626changes <tt>min/max</tt> in several places in random from member
30627functions to static data members. I believe this introduces
30628a needless backward compatibility problem between C++0X and
30629TR1. I'd like us to find new names for the static data members,
30630or perhaps change <tt>min/max</tt> to <tt>constexpr</tt>s in C++0X.
30631</p>
30632
30633<p>
30634See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
30635<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
30636for some further discussion.
30637</p>
30638
30639
30640<p><b>Proposed resolution:</b></p>
30641<p>
30642Adopt the proposed resolution in
30643<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
30644</p>
30645
30646
30647<p><i>[
30648Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
30649The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
30650]</i></p>
30651
30652
30653
30654
30655
30656<hr>
30657<h3><a name="700"></a>700. N1856 defines struct <tt>identity</tt></h3>
30658<p><b>Section:</b> 20.3.3 [forward] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
30659 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2007-07-01  <b>Last modified:</b> 2008-09-26</p>
30660<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>
30661<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
30662<p><b>Discussion:</b></p>
30663<p>
30664<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html">N1856</a>
30665defines struct <tt>identity</tt> in <tt>&lt;utility&gt;</tt> which clashes with
30666the traditional definition of struct <tt>identity</tt> in <tt>&lt;functional&gt;</tt>
30667(not standard, but a common extension from old STL). Be nice
30668if we could avoid this name clash for backward compatibility.
30669</p>
30670
30671
30672<p><b>Proposed resolution:</b></p>
30673<p>
30674Change 20.3.3 [forward]:
30675</p>
30676
30677<blockquote>
30678<pre>template &lt;class T&gt; struct identity
30679{
30680    typedef T type;
30681    <ins>const T&amp; operator()(const T&amp; x) const;</ins>
30682};
30683</pre>
30684<blockquote>
30685<pre><ins>const T&amp; operator()(const T&amp; x) const;</ins>
30686</pre>
30687<blockquote>
30688<p>
30689<ins><i>Returns:</i> <tt>x</tt>.</ins>
30690</p>
30691</blockquote>
30692</blockquote>
30693
30694</blockquote>
30695
30696
30697
30698
30699
30700
30701<hr>
30702<h3><a name="703"></a>703. <tt>map::at()</tt> need a complexity specification</h3>
30703<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>
30704 <b>Submitter:</b> Joe Gottman <b>Opened:</b> 2007-07-03  <b>Last modified:</b> 2008-09-26</p>
30705<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>
30706<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
30707<p><b>Discussion:</b></p>
30708<p>
30709<tt>map::at()</tt> need a complexity specification.
30710</p>
30711
30712
30713<p><b>Proposed resolution:</b></p>
30714<p>
30715Add the following to the specification of <tt>map::at()</tt>, 23.4.1.2 [map.access]:
30716</p>
30717<blockquote>
30718<p>
30719<i>Complexity:</i> logarithmic.
30720</p>
30721</blockquote>
30722
30723
30724
30725
30726
30727<hr>
30728<h3><a name="705"></a>705. type-trait <tt>decay</tt> incompletely specified</h3>
30729<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>
30730 <b>Submitter:</b> Thorsten Ottosen <b>Opened:</b> 2007-07-08  <b>Last modified:</b> 2008-09-26</p>
30731<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>
30732<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
30733<p><b>Discussion:</b></p>
30734<p>
30735The current working draft has a type-trait <tt>decay</tt> in 20.6.7 [meta.trans.other].
30736</p>
30737
30738<p>
30739Its use is to turn C++03 pass-by-value parameters into efficient C++0x
30740pass-by-rvalue-reference parameters. However, the current definition
30741introduces an incompatible change where the cv-qualification of the
30742parameter type is retained. The deduced type should loose such
30743cv-qualification, as pass-by-value does.
30744</p>
30745
30746
30747<p><b>Proposed resolution:</b></p>
30748<p>
30749In 20.6.7 [meta.trans.other] change the last sentence:
30750</p>
30751
30752<blockquote><p>
30753Otherwise the  member typedef <tt>type</tt> equals <tt><ins>remove_cv&lt;</ins>U<ins>&gt;::type</ins></tt>.
30754</p></blockquote>
30755
30756<p>
30757In 20.5.2.4 [tuple.creation]/1 change:
30758</p>
30759
30760<blockquote><p>
30761<del>where each <tt>Vi</tt> in <tt>VTypes</tt> is <tt>X&amp;</tt> if, for the
30762corresponding type <tt>Ti</tt> in <tt>Types</tt>,
30763<tt>remove_cv&lt;remove_reference&lt;Ti&gt;::type&gt;::type</tt> equals
30764<tt>reference_wrapper&lt;X&gt;</tt>, otherwise <tt>Vi</tt> is
30765<tt>decay&lt;Ti&gt;::type</tt>.</del>
30766<ins>Let <tt>Ui</tt> be <tt>decay&lt;Ti&gt;::type</tt> for each
30767<tt>Ti</tt> in <tt>Types</tt>. Then each <tt>Vi</tt> in <tt>VTypes</tt>
30768is <tt>X&amp;</tt> if <tt>Ui</tt> equals
30769<tt>reference_wrapper&lt;X&gt;</tt>, otherwise <tt>Vi</tt> is
30770<tt>Ui</tt>.</ins>
30771</p></blockquote>
30772
30773
30774
30775
30776
30777
30778<hr>
30779<h3><a name="706"></a>706. <tt>make_pair()</tt> should behave as <tt>make_tuple()</tt> wrt. <tt>reference_wrapper()</tt></h3>
30780<p><b>Section:</b> 20.3.4 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
30781 <b>Submitter:</b> Thorsten Ottosen <b>Opened:</b> 2007-07-08  <b>Last modified:</b> 2008-09-26</p>
30782<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>
30783<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>
30784<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
30785<p><b>Discussion:</b></p>
30786<p>
30787The current draft has <tt>make_pair()</tt> in 20.3.4 [pairs]/16
30788and <tt>make_tuple()</tt> in 20.5.2.4 [tuple.creation].
30789<tt>make_tuple()</tt> detects the presence of
30790<tt>reference_wrapper&lt;X&gt;</tt> arguments and "unwraps" the reference in
30791such cases. <tt>make_pair()</tt> would OTOH create a
30792<tt>reference_wrapper&lt;X&gt;</tt> member. I suggest that the two
30793functions are made to behave similar in this respect to minimize
30794confusion.
30795</p>
30796
30797
30798<p><b>Proposed resolution:</b></p>
30799<p>
30800In 20.3 [utility] change the synopsis for make_pair() to read
30801</p>
30802
30803<blockquote><pre>template &lt;class T1, class T2&gt;
30804  pair&lt;<del>typename decay&lt;T1&gt;::type</del> <ins>V1</ins>, <del>typename decay&lt;T2&gt;::type</del> <ins>V2</ins>&gt; make_pair(T1&amp;&amp;, T2&amp;&amp;);
30805</pre></blockquote>
30806
30807<p>
30808In 20.3.4 [pairs]/16 change the declaration to match the above synopsis.
30809Then change the 20.3.4 [pairs]/17 to:
30810</p>
30811
30812<blockquote>
30813<p>
30814<i>Returns:</i> <tt>pair&lt;<del>typename decay&lt;T1&gt;::type</del> <ins>V1</ins>,<del>typename decay&lt;T2&gt;::type</del> <ins>V2</ins>&gt;(forward&lt;T1&gt;(x),forward&lt;T2&gt;(y))</tt> <ins>where <tt>V1</tt> and
30815<tt>V2</tt> are determined as follows: Let <tt>Ui</tt> be
30816<tt>decay&lt;Ti&gt;::type</tt> for each <tt>Ti</tt>. Then each
30817<tt>Vi</tt> is <tt>X&amp;</tt> if <tt>Ui</tt> equals
30818<tt>reference_wrapper&lt;X&gt;</tt>, otherwise <tt>Vi</tt> is
30819<tt>Ui</tt>.</ins>
30820</p>
30821</blockquote>
30822
30823
30824
30825
30826
30827
30828<hr>
30829<h3><a name="709"></a>709. <tt>char_traits::not_eof</tt> has wrong signature</h3>
30830<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>
30831 <b>Submitter:</b> Bo Persson <b>Opened:</b> 2007-08-13  <b>Last modified:</b> 2008-09-26</p>
30832<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>
30833<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
30834<p><b>Discussion:</b></p>
30835<p>
30836The changes made for <tt>constexpr</tt> in 21.2.3 [char.traits.specializations] have 
30837not only changed the <tt>not_eof</tt> function from pass by const reference to 
30838pass by value, it has also changed the parameter type from <tt>int_type</tt> to 
30839<tt>char_type</tt>.
30840</p>
30841<p>
30842This doesn't work for type <tt>char</tt>, and is inconsistent with the 
30843requirements in Table 56, Traits requirements, 21.2.1 [char.traits.require].
30844</p>
30845
30846<p>
30847Pete adds:
30848</p>
30849
30850<blockquote><p>
30851For what it's worth, that may not have been an intentional change. 
30852N2349, which detailed the changes for adding constant expressions to 
30853the library, has strikeout bars through the <tt>const</tt> and the <tt>&amp;</tt> that 
30854surround the <tt>char_type</tt> argument, but none through <tt>char_type</tt> itself. 
30855So the intention may have been just to change to pass by value, with 
30856text incorrectly copied from the standard.
30857</p></blockquote>
30858
30859
30860
30861<p><b>Proposed resolution:</b></p>
30862<p>
30863Change the signature in 21.2.3.1 [char.traits.specializations.char],
3086421.2.3.2 [char.traits.specializations.char16_t], 21.2.3.3 [char.traits.specializations.char32_t],
30865and 21.2.3.4 [char.traits.specializations.wchar.t] to
30866</p>
30867
30868<blockquote><pre>static constexpr int_type not_eof(<del>char_type</del> <ins>int_type</ins> c);
30869</pre></blockquote>
30870
30871
30872
30873<p><i>[
30874Bellevue:
30875]</i></p>
30876
30877
30878<blockquote>
30879Resolution: NAD editorial - up to Pete's judgment
30880</blockquote>
30881
30882<p><i>[
30883Post Sophia Antipolis
30884]</i></p>
30885
30886
30887<blockquote>
30888Moved from Pending NAD Editorial to Review.  The proposed wording appears to be correct but non-editorial.
30889</blockquote>
30890
30891
30892
30893
30894<hr>
30895<h3><a name="710"></a>710. Missing postconditions</h3>
30896<p><b>Section:</b> 20.8.15.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
30897 <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2007-08-24  <b>Last modified:</b> 2008-09-26</p>
30898<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>
30899<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
30900<p><b>Discussion:</b></p>
30901<p>
30902A discussion on
30903<a href="http://groups.google.com/group/comp.std.c++/browse_frm/thread/8e89dceb35cd7971">comp.std.c++</a>
30904has identified a contradiction in the <tt>shared_ptr</tt> specification.
30905The <tt>shared_ptr</tt> move constructor and the cast functions are
30906missing postconditions for the <tt>get()</tt> accessor.
30907</p>
30908
30909<p><i>[
30910Bellevue:
30911]</i></p>
30912
30913
30914<blockquote>
30915<p>
30916Move to "ready", adopting the first (Peter's) proposed resolution.
30917</p>
30918<p>
30919Note to the project editor: there is an editorial issue here. The
30920wording for the postconditions of the casts is slightly awkward, and the
30921editor should consider rewording "If w is the return value...", e. g. as
30922"For a return value w...".
30923</p>
30924</blockquote>
30925
30926
30927<p><b>Proposed resolution:</b></p>
30928<p>
30929Add to 20.8.15.2.1 [util.smartptr.shared.const]:
30930</p>
30931
30932<blockquote>
30933<pre>shared_ptr(shared_ptr&amp;&amp; r);
30934template&lt;class Y&gt; shared_ptr(shared_ptr&lt;Y&gt;&amp;&amp; r);
30935</pre>
30936<blockquote>
30937<p>
30938<i>Postconditions:</i>  <tt>*this</tt> shall contain the old value of <tt>r</tt>. <tt>r</tt>
30939shall be empty. <ins><tt>r.get() == 0</tt>.</ins>
30940</p>
30941</blockquote>
30942</blockquote>
30943
30944<p>
30945Add to 20.8.15.2.10 [util.smartptr.shared.cast]:
30946</p>
30947
30948<blockquote>
30949<pre>template&lt;class T, class U&gt; shared_ptr&lt;T&gt; static_pointer_cast(shared_ptr&lt;U&gt; const&amp; r);
30950</pre>
30951<blockquote>
30952<p>
30953<ins><i>Postconditions:</i> If <tt>w</tt> is the return value,
30954<tt>w.get() == static_cast&lt;T*&gt;(r.get()) &amp;&amp; w.use_count() == r.use_count()</tt>.</ins>
30955</p>
30956</blockquote>
30957</blockquote>
30958
30959<blockquote>
30960<pre>template&lt;class T, class U&gt; shared_ptr&lt;T&gt; dynamic_pointer_cast(shared_ptr&lt;U&gt; const&amp; r);
30961</pre>
30962<blockquote>
30963<p>
30964<ins><i>Postconditions:</i> If <tt>w</tt> is the return value, <tt>w.get() == dynamic_cast&lt;T*&gt;(r.get())</tt>.</ins>
30965</p>
30966</blockquote>
30967</blockquote>
30968
30969<blockquote>
30970<pre>template&lt;class T, class U&gt; shared_ptr&lt;T&gt; const_pointer_cast(shared_ptr&lt;U&gt; const&amp; r);
30971</pre>
30972<blockquote>
30973<p>
30974<ins><i>Postconditions:</i> If <tt>w</tt> is the return value,
30975<tt>w.get() == const_cast&lt;T*&gt;(r.get()) &amp;&amp; w.use_count() == r.use_count()</tt>.</ins>
30976</p>
30977</blockquote>
30978</blockquote>
30979
30980<p>
30981Alberto Ganesh Barbati has written an
30982<a href="http://barbati.net/c++/shared_ptr.pdf">alternative proposal</a>
30983where he suggests (among other things) that the casts be respecified in terms of
30984the aliasing constructor as follows:
30985</p>
30986
30987<p>
30988Change 20.8.15.2.10 [util.smartptr.shared.cast]:
30989</p>
30990
30991<blockquote>
30992<p>
30993-2- <i>Returns:</i> <del>If <tt>r</tt> is empty, an <tt>empty
30994shared_ptr&lt;T&gt;;</tt> otherwise, a <tt>shared_ptr&lt;T&gt;</tt>
30995object that stores <tt>static_cast&lt;T*&gt;(r.get())</tt> and shares ownership with
30996<tt>r</tt>.</del> <ins><tt>shared_ptr&lt;T&gt;(r, static_cast&lt;T*&gt;(r.get())</tt>.</ins>
30997</p>
30998</blockquote>
30999
31000<blockquote>
31001<p>
31002-6- <i>Returns:</i>
31003</p>
31004<ul>
31005<li><del>When <tt>dynamic_cast&lt;T*&gt;(r.get())</tt> returns a nonzero value,
31006a <tt>shared_ptr&lt;T&gt;</tt> object that stores a copy 
31007of it and <i>shares ownership</i> with <tt>r</tt>;</del></li>
31008<li><del>Otherwise, an <i>empty</i> <tt>shared_ptr&lt;T&gt;</tt> object.</del></li>
31009<li><ins>If <tt>p = dynamic_cast&lt;T*&gt;(r.get())</tt> is a non-null pointer, <tt>shared_ptr&lt;T&gt;(r, p);</tt></ins></li>
31010<li><ins>Otherwise, <tt>shared_ptr&lt;T&gt;()</tt>.</ins></li>
31011</ul>
31012</blockquote>
31013
31014<blockquote>
31015<p>
31016-10- <i>Returns:</i> <del>If <tt>r</tt> is empty, an <tt>empty
31017shared_ptr&lt;T&gt;;</tt> otherwise, a <tt>shared_ptr&lt;T&gt;</tt>
31018object that stores <tt>const_cast&lt;T*&gt;(r.get())</tt> and shares ownership with
31019<tt>r</tt>.</del> <ins><tt>shared_ptr&lt;T&gt;(r, const_cast&lt;T*&gt;(r.get())</tt>.</ins>
31020</p>
31021</blockquote>
31022
31023<p>
31024This takes care of the missing postconditions for the casts by bringing
31025in the aliasing constructor postcondition "by reference".
31026</p>
31027
31028
31029
31030
31031
31032
31033<hr>
31034<h3><a name="711"></a>711. Contradiction in empty <tt>shared_ptr</tt></h3>
31035<p><b>Section:</b> 20.8.15.2.5 [util.smartptr.shared.obs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
31036 <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2007-08-24  <b>Last modified:</b> 2009-10-26</p>
31037<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>
31038<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
31039<p><b>Discussion:</b></p>
31040<p>
31041A discussion on
31042<a href="http://groups.google.com/group/comp.std.c++/browse_frm/thread/8e89dceb35cd7971">comp.std.c++</a>
31043has identified a contradiction in the <tt>shared_ptr</tt> specification.
31044The note:
31045</p>
31046
31047<blockquote><p>
31048[ <i>Note:</i> this constructor allows creation of an empty shared_ptr instance with a non-NULL stored pointer.
31049-end note ]
31050</p></blockquote>
31051
31052<p>
31053after the aliasing constructor
31054</p>
31055
31056<blockquote><pre>template&lt;class Y&gt; shared_ptr(shared_ptr&lt;Y&gt; const&amp; r, T *p);
31057</pre></blockquote>
31058
31059<p>
31060reflects the intent of
31061<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2351.htm">N2351</a>
31062to, well, allow the creation of an empty <tt>shared_ptr</tt>
31063with a non-NULL stored pointer.
31064</p>
31065
31066<p>
31067This is contradicted by the second sentence in the Returns clause of 20.8.15.2.5 [util.smartptr.shared.obs]:
31068</p>
31069
31070<blockquote>
31071<pre>T* get() const;
31072</pre>
31073<blockquote><p>
31074<i>Returns:</i> the stored pointer. Returns a null pointer if <tt>*this</tt> is empty.
31075</p></blockquote>
31076</blockquote>
31077
31078<p><i>[
31079Bellevue:
31080]</i></p>
31081
31082
31083<blockquote>
31084<p>
31085Adopt option 1 and move to review, not ready.
31086</p>
31087<p>
31088There was a lot of confusion about what an empty <tt>shared_ptr</tt> is (the term
31089isn't defined anywhere), and whether we have a good mental model for how
31090one behaves. We think it might be possible to deduce what the definition
31091should be, but the words just aren't there. We need to open an issue on
31092the use of this undefined term. (The resolution of that issue might
31093affect the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#711">711</a>.)
31094</p>
31095<p>
31096The LWG is getting more uncomfortable with the aliasing proposal (N2351)
31097now that we realize some of its implications, and we need to keep an eye
31098on it, but there isn't support for removing this feature at this time.
31099</p>
31100</blockquote>
31101
31102<p><i>[
31103Sophia Antipolis:
31104]</i></p>
31105
31106
31107<blockquote>
31108<p>
31109We heard from Peter Dimov, who explained his reason for preferring solution 1.
31110</p>
31111<p>
31112Because it doesn't seem to add anything. It simply makes the behavior
31113for p = 0 undefined. For programmers who don't create empty pointers
31114with p = 0, there is no difference. Those who do insist on creating them
31115presumably have a good reason, and it costs nothing for us to define the
31116behavior in this case.
31117</p>
31118<p>
31119The aliasing constructor is sharp enough as it is, so "protecting" users
31120doesn't make much sense in this particular case.
31121</p>
31122<p>
31123&gt; Do you have a use case for r being empty and r being non-null? 
31124</p>
31125<p>
31126I have received a few requests for it from "performance-conscious"
31127people (you should be familiar with this mindset) who don't like the
31128overhead of allocating and maintaining a control block when a null
31129deleter is used to approximate a raw pointer. It is obviously an "at
31130your own risk", low-level feature; essentially a raw pointer behind a
31131shared_ptr facade.
31132</p>
31133<p>
31134We could not agree upon a resolution to the issue; some of us thought
31135that Peter's description above is supporting an undesirable behavior.
31136</p>
31137</blockquote>
31138
31139<p><i>[
311402009-07 Frankfurt:
31141]</i></p>
31142
31143
31144<blockquote>
31145<p>
31146We favor option 1, move to Ready.
31147</p>
31148<p><i>[
31149Howard:  Option 2 commented out for clarity, and can be brought back.
31150]</i></p>
31151
31152</blockquote>
31153
31154
31155
31156<p><b>Proposed resolution:</b></p>
31157<p>
31158In keeping the N2351 spirit and obviously my preference, change 20.8.15.2.5 [util.smartptr.shared.obs]:
31159</p>
31160
31161<blockquote>
31162<pre>T* get() const;
31163</pre>
31164<blockquote><p>
31165<i>Returns:</i> the stored pointer. <del>Returns a null pointer if <tt>*this</tt> is empty.</del>
31166</p></blockquote>
31167</blockquote>
31168
31169
31170
31171
31172
31173
31174
31175
31176<hr>
31177<h3><a name="712"></a>712. <tt>seed_seq::size</tt> no longer useful</h3>
31178<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>
31179 <b>Submitter:</b> Marc Paterno <b>Opened:</b> 2007-08-25  <b>Last modified:</b> 2008-09-26</p>
31180<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>
31181<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
31182<p><b>Discussion:</b></p>
31183<p>
31184One of the motivations for incorporating <tt>seed_seq::size()</tt>
31185was to simplify the wording
31186in other parts of 26.5 [rand].
31187As a side effect of resolving related issues,
31188all such references
31189to <tt>seed_seq::size()</tt> will have been excised.
31190More importantly,
31191the present specification is contradictory,
31192as "The number of 32-bit units the object can deliver"
31193is not the same as "the result of <tt>v.size()</tt>."
31194</p>
31195
31196<p>
31197See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
31198<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
31199for some further discussion.
31200</p>
31201
31202
31203<p><b>Proposed resolution:</b></p>
31204<p>
31205Adopt the proposed resolution in
31206<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
31207</p>
31208
31209
31210<p><i>[
31211Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
31212The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
31213]</i></p>
31214
31215
31216
31217
31218
31219<hr>
31220<h3><a name="713"></a>713. <tt>sort()</tt> complexity is too lax</h3>
31221<p><b>Section:</b> 25.4.1.1 [sort] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
31222 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2007-08-30  <b>Last modified:</b> 2008-09-26</p>
31223<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
31224<p><b>Discussion:</b></p>
31225<p>
31226The complexity of <tt>sort()</tt> is specified as "Approximately <tt>N
31227log(N)</tt> (where <tt>N == last - first</tt> ) comparisons on the
31228average", with no worst case complicity specified. The intention was to
31229allow a median-of-three quicksort implementation, which is usually <tt>O(N
31230log N)</tt> but can be quadratic for pathological inputs. However, there is
31231no longer any reason to allow implementers the freedom to have a
31232worst-cast-quadratic sort algorithm. Implementers who want to use
31233quicksort can use a variant like David Musser's "Introsort" (Software
31234Practice and Experience 27:983-993, 1997), which is guaranteed to be <tt>O(N
31235log N)</tt> in the worst case without incurring additional overhead in the
31236average case. Most C++ library implementers already do this, and there
31237is no reason not to guarantee it in the standard.
31238</p>
31239
31240
31241<p><b>Proposed resolution:</b></p>
31242<p>
31243In 25.4.1.1 [sort], change the complexity to "O(N log N)", and remove footnote 266:
31244</p>
31245
31246<blockquote>
31247<p>
31248<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> )
31249comparisons<del> on the average</del>.<del><sup>266)</sup></del>
31250</p>
31251<p>
31252<del><sup>266)</sup>
31253If the worst case behavior is important <tt>stable_sort()</tt> (25.3.1.2) or <tt>partial_sort()</tt>
31254(25.3.1.3) should be used.</del>
31255</p>
31256</blockquote>
31257
31258
31259
31260
31261
31262
31263<hr>
31264<h3><a name="714"></a>714. <tt>search_n</tt> complexity is too lax</h3>
31265<p><b>Section:</b> 25.2.12 [alg.search] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
31266 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2007-08-30  <b>Last modified:</b> 2008-09-26</p>
31267<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>
31268<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
31269<p><b>Discussion:</b></p>
31270<p>
31271The complexity for <tt>search_n</tt> (25.2.12 [alg.search] par 7) is specified as "At most
31272(last - first ) * count applications of the corresponding predicate if
31273count is positive, or 0 otherwise." This is unnecessarily pessimistic.
31274Regardless of the value of count, there is no reason to examine any
31275element in the range more than once.
31276</p>
31277
31278
31279<p><b>Proposed resolution:</b></p>
31280<p>
31281Change the complexity to "At most (last - first) applications of the corresponding predicate".
31282</p>
31283
31284<blockquote>
31285<pre>template&lt;class ForwardIterator, class Size, class T&gt; 
31286  ForwardIterator 
31287    search_n(ForwardIterator first , ForwardIterator last , Size count , 
31288             const T&amp; value ); 
31289
31290template&lt;class ForwardIterator, class Size, class T, 
31291         class BinaryPredicate&gt; 
31292  ForwardIterator 
31293    search_n(ForwardIterator first , ForwardIterator last , Size count , 
31294             const T&amp; value , BinaryPredicate pred );
31295</pre>
31296<blockquote>
31297<p>
31298<i>Complexity:</i> At most <tt>(last - first ) <del>* count</del></tt> applications of the corresponding predicate
31299<del>if <tt>count</tt> is positive, or 0 otherwise</del>.
31300</p>
31301</blockquote>
31302</blockquote>
31303
31304
31305
31306
31307
31308
31309<hr>
31310<h3><a name="715"></a>715. <tt>minmax_element</tt> complexity is too lax</h3>
31311<p><b>Section:</b> 25.4.7 [alg.min.max] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
31312 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2007-08-30  <b>Last modified:</b> 2008-09-26</p>
31313<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>
31314<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
31315<p><b>Discussion:</b></p>
31316<p>
31317The complexity for <tt>minmax_element</tt> (25.4.7 [alg.min.max] par 16) says "At most <tt>max(2 *
31318(last - first ) - 2, 0)</tt> applications of the corresponding comparisons",
31319i.e. the worst case complexity is no better than calling <tt>min_element</tt> and
31320<tt>max_element</tt> separately. This is gratuitously inefficient. There is a
31321well known technique that does better: see section 9.1 of CLRS
31322(Introduction to Algorithms, by Cormen, Leiserson, Rivest, and Stein).
31323</p>
31324
31325
31326<p><b>Proposed resolution:</b></p>
31327<p>
31328Change 25.4.7 [alg.min.max] to:
31329</p>
31330
31331<blockquote>
31332<pre>template&lt;class ForwardIterator&gt; 
31333  pair&lt;ForwardIterator, ForwardIterator&gt; 
31334    minmax_element(ForwardIterator first , ForwardIterator last); 
31335template&lt;class ForwardIterator, class Compare&gt; 
31336  pair&lt;ForwardIterator, ForwardIterator&gt; 
31337    minmax_element(ForwardIterator first , ForwardIterator last , Compare comp);
31338</pre>
31339<blockquote>
31340<p>
31341<i>Returns:</i> <tt>make_pair(m, M)</tt>, where <tt>m</tt> is
31342<del><tt>min_element(first, last)</tt> or <tt>min_element(first, last,
31343comp)</tt></del> <ins>the first iterator in <tt>[first,
31344last)</tt> such that no iterator in the range refers to a smaller element,</ins> and
31345<ins>where</ins> <tt>M</tt> is <del><tt>max_element(first, last)</tt> or
31346<tt>max_element(first, last, comp)</tt></del> <ins>the last iterator
31347in <tt>[first, last)</tt> such that no iterator in the range refers to a larger element</ins>.
31348</p>
31349<p>
31350<i>Complexity:</i> At most <del><tt>max(2 * (last - first ) - 2, 0)</tt></del>
31351<ins><tt>max(&#8970;(3/2) (N-1)&#8971;, 0)</tt></ins> applications of the
31352corresponding <del>comparisons</del> <ins>predicate, where <tt>N</tt> is <tt>distance(first, last)</tt></ins>.
31353</p>
31354</blockquote>
31355</blockquote>
31356
31357
31358
31359
31360
31361
31362<hr>
31363<h3><a name="716"></a>716. Production in [re.grammar] not actually modified</h3>
31364<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#WP">WP</a>
31365 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2007-08-31  <b>Last modified:</b> 2009-10-26</p>
31366<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
31367<p><b>Discussion:</b></p>
31368<p>
31369TR1 7.13 [tr.re.grammar]/3 and C++0x WP 28.13 [re.grammar]/3 say:
31370</p>
31371
31372<blockquote>
31373<p>
31374The following productions within the ECMAScript grammar are modified as follows:
31375</p>
31376
31377<blockquote><pre>CharacterClass ::
31378[ [lookahead &#8713; {^}] ClassRanges ]
31379[ ^ ClassRanges ]
31380</pre></blockquote>
31381
31382</blockquote>
31383
31384<p>
31385This definition for <tt>CharacterClass</tt> appears to be exactly identical to that in ECMA-262.
31386</p>
31387
31388<p>
31389Was an actual modification intended here and accidentally omitted, or was this production accidentally included?
31390</p>
31391
31392<p><i>[
31393Batavia (2009-05):
31394]</i></p>
31395
31396<blockquote>
31397<p>
31398We agree that what is specified is identical to what ECMA-262 specifies.
31399Pete would like to take a bit of time to assess whether we had intended,
31400but failed, to make a change.
31401It would also be useful to hear from John Maddock on the issue.
31402</p>
31403<p>
31404Move to Open.
31405</p>
31406</blockquote>
31407
31408<p><i>[
314092009-07 Frankfurt:
31410]</i></p>
31411
31412
31413<blockquote>
31414Move to Ready.
31415</blockquote>
31416
31417
31418
31419<p><b>Proposed resolution:</b></p>
31420<p>
31421Remove this mention of the CharacterClass production.
31422</p>
31423
31424<blockquote><pre><del>CharacterClass ::
31425[ [lookahead &#8713; {^}] ClassRanges ]
31426[ ^ ClassRanges ]</del>
31427</pre></blockquote>
31428
31429
31430
31431
31432
31433
31434<hr>
31435<h3><a name="720"></a>720. Omissions in constexpr usages</h3>
31436<p><b>Section:</b> 23.3.1 [array], 20.3.7 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
31437 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2007-08-25  <b>Last modified:</b> 2008-09-26</p>
31438<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>
31439<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
31440<p><b>Discussion:</b></p>
31441<ol>
31442<li>
31443The member function <tt>bool array&lt;T,N&gt;::empty() const</tt> should be a
31444<tt>constexpr</tt> because this is easily to proof and to implement following it's operational
31445semantics defined by Table 87 (Container requirements) which says: <tt>a.size() == 0</tt>.
31446</li>
31447<li>
31448The member function <tt>bool bitset&lt;N&gt;::test() const</tt> must be a
31449<tt>constexpr</tt> (otherwise it would violate the specification of <tt>constexpr
31450bitset&lt;N&gt;::operator[](size_t) const</tt>, because it's return clause delegates to <tt>test()</tt>).
31451</li>
31452<li>
31453I wonder how the constructor <tt>bitset&lt;N&gt;::bitset(unsigned long)</tt> can
31454be declared as a <tt>constexpr</tt>. Current implementations usually have no such <tt>bitset</tt>
31455c'tor which would fulfill the requirements of a <tt>constexpr</tt> c'tor because they have a
31456non-empty c'tor body that typically contains for-loops or <tt>memcpy</tt> to compute the
31457initialisation. What have I overlooked here?
31458</li>
31459</ol>
31460
31461<p><i>[
31462Sophia Antipolis:
31463]</i></p>
31464
31465
31466<blockquote>
31467<p>
31468We handle this as two parts
31469</p>
31470<ol>
31471<li>
31472The proposed resolution is correct; move to ready.
31473</li>
31474<li>
31475The issue points out a real problem, but the issue is larger than just
31476this solution. We believe a paper is needed, applying the full new
31477features of C++ (including extensible literals) to update <tt>std::bitset</tt>.
31478We note that we do not consider this new work, and that is should be
31479handled by the Library Working Group.
31480</li>
31481</ol>
31482<p>
31483In order to have a consistent working paper, Alisdair and Daniel produced a new wording for the resolution.
31484</p>
31485</blockquote>
31486
31487
31488
31489<p><b>Proposed resolution:</b></p>
31490<ol>
31491<li>
31492<p>In the class template definition of 23.3.1 [array]/p. 3 change</p>
31493<blockquote><pre><ins>constexpr</ins> bool empty() const;
31494</pre></blockquote>
31495</li>
31496
31497<li>
31498<p>In the class template definition of 20.3.7 [template.bitset]/p. 1 change</p>
31499<blockquote><pre><ins>constexpr</ins> bool test(size_t pos ) const;
31500</pre></blockquote>
31501
31502<p>
31503and in 20.3.7.2 [bitset.members] change
31504</p>
31505
31506<blockquote><pre><ins>constexpr</ins> bool test(size_t pos ) const;
31507</pre></blockquote>
31508
31509</li>
31510</ol>
31511
31512
31513
31514
31515
31516<hr>
31517<h3><a name="722"></a>722. Missing [c.math] functions <tt>nanf</tt> and <tt>nanl</tt></h3>
31518<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>
31519 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2007-08-27  <b>Last modified:</b> 2008-09-26</p>
31520<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>
31521<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
31522<p><b>Discussion:</b></p>
31523<p>
31524In the listing of 26.8 [c.math], table 108: Header <tt>&lt;cmath&gt;</tt> synopsis I miss
31525the following C99 functions (from 7.12.11.2):
31526</p>
31527
31528<blockquote><pre>float nanf(const char *tagp);
31529long double nanl(const char *tagp);
31530</pre></blockquote>
31531
31532<p>
31533(Note: These functions cannot be overloaded and they are also not
31534listed anywhere else)
31535</p>
31536
31537
31538<p><b>Proposed resolution:</b></p>
31539<p>
31540In 26.8 [c.math], table 108, section "Functions", add <tt>nanf</tt> and <tt>nanl</tt>
31541just after the existing entry <tt>nan</tt>.
31542</p>
31543
31544
31545
31546
31547
31548<hr>
31549<h3><a name="723"></a>723. <tt>basic_regex</tt> should be moveable</h3>
31550<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>
31551 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2007-08-29  <b>Last modified:</b> 2009-10-26</p>
31552<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>
31553<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
31554<p><b>Discussion:</b></p>
31555
31556<p><b>Addresses UK 316</b></p>
31557
31558<p>
31559According to the current state of the standard draft, the class
31560template <tt>basic_regex</tt>, as described in 28.8 [re.regex]/3, is
31561neither <tt>MoveConstructible</tt> nor <tt>MoveAssignable</tt>.
31562IMO it should be, because typical regex state machines tend
31563to have a rather large data quantum and I have seen several
31564use cases, where a factory function returns regex values,
31565which would take advantage of moveabilities.
31566</p>
31567
31568<p><i>[
31569Sophia Antipolis:
31570]</i></p>
31571
31572
31573<blockquote>
31574Needs wording for the semantics, the idea is agreed upon.
31575</blockquote>
31576
31577<p><i>[
31578Post Summit Daniel updated wording to reflect new "swap rules".
31579]</i></p>
31580
31581
31582<p><i>[
315832009-07 Frankfurt:
31584]</i></p>
31585
31586
31587<blockquote>
31588Move to Ready.
31589</blockquote>
31590
31591
31592
31593<p><b>Proposed resolution:</b></p>
31594<p>
31595In the class definition of <tt>basic_regex</tt>, just below 28.8 [re.regex]/3,
31596perform the following changes:
31597</p>
31598
31599<ol type="a">
31600<li>
31601<p>
31602Just after <tt>basic_regex(const basic_regex&amp;);</tt> insert:
31603</p>
31604
31605<blockquote><pre>basic_regex(basic_regex&amp;&amp;);
31606</pre></blockquote>
31607</li>
31608<li>
31609<p>
31610Just after <tt>basic_regex&amp; operator=(const basic_regex&amp;);</tt> insert:
31611</p>
31612<blockquote><pre>basic_regex&amp; operator=(basic_regex&amp;&amp;);
31613</pre></blockquote>
31614</li>
31615<li>
31616<p>
31617Just after <tt>basic_regex&amp; assign(const basic_regex&amp; that);</tt> insert:
31618</p>
31619<blockquote><pre>basic_regex&amp; assign(basic_regex&amp;&amp; that);
31620</pre></blockquote>
31621</li>
31622<li>
31623<p>
31624In 28.8.2 [re.regex.construct], just after p.11 add the following
31625new member definition:
31626</p>
31627<blockquote><pre>basic_regex(basic_regex&amp;&amp; e);
31628</pre>
31629<blockquote>
31630<p>
31631<i>Effects:</i> Move-constructs a <tt>basic_regex</tt> instance from <tt>e</tt>.
31632</p>
31633<p>
31634<i>Postconditions:</i> <tt>flags()</tt> and <tt>mark_count()</tt> return <tt>e.flags()</tt> and
31635<tt>e.mark_count()</tt>, respectively,
31636that <tt>e</tt> had before construction, leaving
31637<tt>e</tt> in a valid state with an unspecified value.
31638</p>
31639<p>
31640<i>Throws:</i> nothing.
31641</p>
31642</blockquote>
31643</blockquote>
31644</li>
31645<li>
31646<p>
31647Also in 28.8.2 [re.regex.construct], just after p.18 add the
31648following new member definition:
31649</p>
31650
31651<blockquote><pre>basic_regex&amp; operator=(basic_regex&amp;&amp; e);
31652</pre>
31653<blockquote>
31654<i>Effects:</i> Returns the result of <tt>assign(std::move(e))</tt>.
31655</blockquote>
31656</blockquote>
31657</li>
31658<li>
31659<p>
31660In 28.8.3 [re.regex.assign], just after p. 2 add the following new
31661member definition:
31662</p>
31663<blockquote><pre>basic_regex&amp; assign(basic_regex&amp;&amp; rhs);
31664</pre>
31665<blockquote>
31666<p>
31667<i>Effects:</i> Move-assigns a <tt>basic_regex</tt> instance from <tt>rhs</tt> and returns <tt>*this</tt>.
31668</p>
31669<p>
31670<i>Postconditions:</i> <tt>flags()</tt> and <tt>mark_count()</tt> return <tt>rhs.flags()</tt>
31671and <tt>rhs.mark_count()</tt>, respectively, that
31672<tt>rhs</tt> had before assignment, leaving <tt>rhs</tt>
31673in a valid state with an unspecified value.
31674</p>
31675<p>
31676<i>Throws:</i> nothing.
31677</p>
31678</blockquote>
31679</blockquote>
31680</li>
31681</ol>
31682
31683
31684
31685
31686
31687<hr>
31688<h3><a name="728"></a>728. Problem in [rand.eng.mers]/6</h3>
31689<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>
31690 <b>Submitter:</b> Stephan Tolksdorf <b>Opened:</b> 2007-09-21  <b>Last modified:</b> 2008-09-26</p>
31691<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>
31692<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
31693<p><b>Discussion:</b></p>
31694<p>
31695The <tt>mersenne_twister_engine</tt> is required to use a seeding method that is given 
31696as an algorithm parameterized over the number of bits <tt>W</tt>. I doubt whether the given generalization 
31697of an algorithm that was originally developed only for unsigned 32-bit integers is appropriate 
31698for other bit widths. For instance, <tt>W</tt> could be theoretically 16 and <tt>UIntType</tt> a 16-bit integer, in 
31699which case the given multiplier would not fit into the <tt>UIntType</tt>. Moreover, T. Nishimura and M. 
31700Matsumoto have chosen a dif ferent multiplier for their 64 bit Mersenne Twister
31701[<a href="http://www.math.sci.hiroshima-u.ac.jp/%7Em-mat/MT/VERSIONS/C-LANG/mt19937-64.c">reference</a>].
31702</p>
31703
31704<p>
31705I see two possible resolutions: 
31706</p>
31707
31708<ol type="a">
31709<li>Restrict the parameter <tt>W</tt> of the <tt>mersenne_twister_template</tt> to values of 32 or 64 and use the 
31710multiplier from [the above reference] for the 64-bit case (my preference)</li>
31711<li>Interpret the state array for any <tt>W</tt> as a 32-bit array of appropriate length (and a specified byte 
31712order) and always employ the 32-bit algorithm for seeding
31713</li>
31714</ol>
31715
31716<p>
31717See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
31718for further discussion.
31719</p>
31720
31721<p><i>[
31722Bellevue:
31723]</i></p>
31724
31725
31726<blockquote>
31727<p>
31728Stephan Tolksdorf has additional comments on N2424. He comments: "there
31729is a typo in the required behaviour for mt19937_64: It should be the
3173010000th (not 100000th) invocation whose value is given, and the value
31731should be 9981545732273789042 (not 14002232017267485025)." These values
31732need checking.
31733</p>
31734<p>
31735Take the proposed recommendation in N2424 and move to REVIEW.
31736</p>
31737</blockquote>
31738
31739
31740
31741
31742<p><b>Proposed resolution:</b></p>
31743
31744<p>
31745See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
31746for the proposed resolution.
31747</p>
31748
31749<p><i>[
31750Stephan Tolksdorf adds pre-Bellevue:
31751]</i></p>
31752
31753
31754<blockquote>
31755I support the proposed resolution in
31756<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>,
31757but there is a typo in the
31758required behaviour for <tt>mt19937_64</tt>: It should be the 10000<sup>th</sup> (not
31759100000<sup>th</sup>) invocation whose value is given, and the value should be
317609981545732273789042 (not 14002232017267485025). The change to para. 8
31761proposed by Charles Karney should also be included in the proposed
31762wording.
31763</blockquote>
31764
31765<p><i>[
31766Sophia Antipolis:
31767]</i></p>
31768
31769
31770<blockquote>
31771Note the main part of the issue is resolved by
31772<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>.
31773</blockquote>
31774
31775
31776
31777
31778
31779
31780<hr>
31781<h3><a name="734"></a>734. Unnecessary restriction in [rand.dist.norm.chisq]</h3>
31782<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>
31783 <b>Submitter:</b> Stephan Tolksdorf <b>Opened:</b> 2007-09-21  <b>Last modified:</b> 2008-09-26</p>
31784<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
31785<p><b>Discussion:</b></p>
31786<p>
31787<tt>chi_squared_distribution</tt>, <tt>fisher_f_distribution</tt> and <tt>student_t_distribution</tt>
31788have parameters for the "degrees of freedom" <tt>n</tt> and <tt>m</tt> that are specified as integers. For the 
31789following two reasons this is an unnecessary restriction: First, in many applications such as 
31790Bayesian inference or Monte Carlo simulations it is more convenient to treat the respective param- 
31791eters as continuous variables. Second, the standard non-naive algorithms (i.e. 
31792O(1) algorithms) 
31793for simulating from these distributions work with floating-point parameters anyway (all three 
31794distributions could be easily implemented using the Gamma distribution, for instance).
31795</p>
31796
31797<p>
31798Similar arguments could in principle be made for the parameters <tt>t</tt> and <tt>k</tt> of the discrete 
31799<tt>binomial_distribution</tt> and <tt>negative_binomial_distribution</tt>, though in both cases continuous
31800parameters are less frequently used in practice and in case of the <tt>binomial_distribution</tt>
31801the implementation would be significantly complicated by a non-discrete parameter (in most 
31802implementations one would need an approximation of the log-gamma function instead of just the 
31803log-factorial function).
31804</p>
31805
31806<p>
31807<b>Possible resolution:</b> For these reasons, I propose to change the type of the respective parameters 
31808to double.
31809</p>
31810
31811<p><i>[
31812Bellevue:
31813]</i></p>
31814
31815
31816<blockquote>
31817In N2424. Not wildly enthusiastic, not really felt necessary. Less
31818frequently used in practice. Not terribly bad either. Move to OPEN.
31819</blockquote>
31820
31821<p><i>[
31822Sophia Antipolis:
31823]</i></p>
31824
31825
31826<blockquote>
31827<p>
31828Marc Paterno: The generalizations were explicitly left out when designing the facility. It's harder to test.
31829</p>
31830<p>
31831Marc Paterno: Ask implementers whether floating-point is a significant burden.
31832</p>
31833<p>
31834Alisdair: It's neater to do it now, do ask Bill Plauger.
31835</p>
31836<p>
31837Disposition: move to review with the option for "NAD" if it's not straightforward to implement; unanimous consent.
31838</p>
31839</blockquote>
31840
31841
31842
31843<p><b>Proposed resolution:</b></p>
31844<p>
31845See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
31846for the proposed resolution.
31847</p>
31848
31849<p><i>[
31850Stephan Tolksdorf adds pre-Bellevue:
31851]</i></p>
31852
31853
31854<blockquote>
31855<p>
31856In 26.5.8.4.3 [rand.dist.norm.chisq]:
31857</p>
31858
31859<blockquote>
31860<p>
31861Delete ", where <tt>n</tt> is a positive integer" in the first paragraph.
31862</p>
31863
31864<p>
31865Replace both occurrences of "<tt>explicit chi_squared_distribution(int n = 1);</tt>"
31866with "<tt>explicit chi_squared_distribution(RealType n = 1);</tt>".
31867</p>
31868
31869<p>
31870Replace both occurrences of "<tt>int n() const;</tt>" with "<tt>RealType n() const;</tt>".
31871</p>
31872
31873</blockquote>
31874
31875<p>
31876In 26.5.8.4.5 [rand.dist.norm.f]:
31877</p>
31878<blockquote>
31879<p>
31880Delete ", where <tt>m</tt> and <tt>n</tt> are positive integers" in the first paragraph.
31881</p>
31882
31883<p>
31884Replace both occurrences of
31885</p>
31886<blockquote><pre>explicit fisher_f_distribution(int m = 1, int n = 1);
31887</pre></blockquote>
31888<p>
31889with
31890</p>
31891<blockquote><pre>explicit fisher_f_distribution(RealType m = 1, RealType n = 1);
31892</pre></blockquote>
31893
31894<p>
31895Replace both occurrences of "<tt>int m() const;" with "RealType m() const;</tt>".
31896</p>
31897
31898<p>
31899Replace both occurrences of "<tt>int n() const;" with "RealType n() const;</tt>".
31900</p>
31901</blockquote>
31902
31903<p>
31904In 26.5.8.4.6 [rand.dist.norm.t]:
31905</p>
31906
31907<blockquote>
31908<p>
31909Delete ", where <tt>n</tt> is a positive integer" in the first paragraph.
31910</p>
31911
31912<p>
31913Replace both occurrences of "<tt>explicit student_t_distribution(int n = 1);</tt>"
31914with "<tt>explicit student_t_distribution(RealType n = 1);</tt>".
31915</p>
31916
31917<p>
31918Replace both occurrences of "<tt>int n() const;</tt>" with "<tt>RealType n() const;</tt>".
31919</p>
31920</blockquote>
31921
31922</blockquote>
31923
31924
31925
31926
31927
31928<hr>
31929<h3><a name="740"></a>740. Please remove <tt>*_ptr&lt;T[N]&gt;</tt></h3>
31930<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>
31931 <b>Submitter:</b> Herb Sutter <b>Opened:</b> 2007-10-04  <b>Last modified:</b> 2008-09-26</p>
31932<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
31933<p><b>Discussion:</b></p>
31934<p>
31935Please don't provide <tt>*_ptr&lt;T[N]&gt;</tt>. It doesn't enable any useful
31936bounds-checking (e.g., you could imagine that doing <tt>op++</tt> on a
31937<tt>shared_ptr&lt;T[N]&gt;</tt> yields a <tt>shared_ptr&lt;T[N-1]&gt;</tt>, but that promising path
31938immediately falters on <tt>op--</tt> which can't reliably dereference because we
31939don't know the lower bound). Also, most buffers you'd want to point to
31940don't have a compile-time known size.
31941</p>
31942
31943<p>
31944To enable any bounds-checking would require run-time information, with
31945the usual triplet: base (lower bound), current offset, and max offset
31946(upper  bound). And I can sympathize with the point of view that you
31947wouldn't want to require this on <tt>*_ptr</tt> itself. But please let's not
31948follow the <tt>&lt;T[N]&gt;</tt> path, especially not with additional functions to
31949query the bounds etc., because this sets wrong user expectations by
31950embarking on a path that doesn't go all the way to bounds checking as it
31951seems to imply.
31952</p>
31953
31954<p>
31955If bounds checking is desired, consider a <tt>checked_*_ptr</tt> instead (e.g.,
31956<tt>checked_shared_ptr</tt>). And make the interfaces otherwise identical so that
31957user code could easily <tt>#define/typedef</tt> between prepending <tt>checked_</tt> on
31958debug builds and not doing so on release builds (for example).
31959</p>
31960
31961<p>
31962Note that some may object that <tt>checked_*_ptr</tt> may seem to make the smart
31963pointer more like <tt>vector</tt>, and we don't want two ways to spell <tt>vector</tt>. I
31964don't agree, but if that were true that would be another reason to
31965remove <tt>*_ptr&lt;T[N]&gt;</tt> which equally makes the smart pointer more like
31966<tt>std::array.</tt> :-)
31967</p>
31968
31969<p><i>[
31970Bellevue:
31971]</i></p>
31972
31973
31974<blockquote>
31975<p>Suggestion that fixed-size array instantiations are going to fail at
31976compile time anyway (if we remove specialization) due to pointer decay,
31977at least that appears to be result from available compilers.
31978</p>
31979<p>
31980So concerns about about requiring static_assert seem unfounded.
31981</p>
31982<p>After a little more experimentation with compiler, it appears that
31983fixed size arrays would only work at all if we supply these explicit
31984specialization. So removing them appears less breaking than originally
31985thought.
31986</p>
31987<p>
31988straw poll unanimous move to Ready.
31989</p>
31990</blockquote>
31991
31992
31993
31994<p><b>Proposed resolution:</b></p>
31995<p>
31996Change the synopsis under 20.8.14 [unique.ptr] p2:
31997</p>
31998
31999<blockquote><pre>...
32000template&lt;class T&gt; struct default_delete; 
32001template&lt;class T&gt; struct default_delete&lt;T[]&gt;; 
32002<del>template&lt;class T, size_t N&gt; struct default_delete&lt;T[N]&gt;;</del>
32003
32004template&lt;class T, class D = default_delete&lt;T&gt;&gt; class unique_ptr; 
32005template&lt;class T, class D&gt; class unique_ptr&lt;T[], D&gt;; 
32006<del>template&lt;class T, class D, size_t N&gt; class unique_ptr&lt;T[N], D&gt;;</del>
32007...
32008</pre></blockquote>
32009
32010<p>
32011Remove the entire section  [unique.ptr.dltr.dflt2] <b><tt>default_delete&lt;T[N]&gt;</tt></b>.
32012</p>
32013
32014<p>
32015Remove the entire section X [unique.ptr.compiletime] <b><tt>unique_ptr</tt> for array objects with a compile time length</b>
32016and its subsections:  [unique.ptr.compiletime.dtor],  [unique.ptr.compiletime.observers],
32017 [unique.ptr.compiletime.modifiers].
32018</p>
32019
32020
32021
32022
32023
32024
32025<hr>
32026<h3><a name="743"></a>743. rvalue <tt>swap</tt> for <tt>shared_ptr</tt></h3>
32027<p><b>Section:</b> 20.8.15.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>
32028 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2007-10-10  <b>Last modified:</b> 2008-09-26</p>
32029<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
32030<p><b>Discussion:</b></p>
32031<p>
32032When 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:
32033</p>
32034
32035<blockquote><p>
32036We may need to open an issue to deal with the question of
32037whether <tt>shared_ptr</tt> needs an rvalue <tt>swap</tt>.
32038</p></blockquote>
32039
32040<p>
32041This issue was opened in response to that note.
32042</p>
32043
32044<p>
32045I believe allowing rvalue <tt>shared_ptr</tt>s to <tt>swap</tt> is both
32046appropriate, and consistent with how other library components are currently specified.
32047</p>
32048
32049<p><i>[
32050Bellevue:
32051]</i></p>
32052
32053
32054<blockquote>
32055<p>
32056Concern that the three signatures for swap is needlessly complicated,
32057but this issue merely brings shared_ptr into equal complexity with the
32058rest of the library. Will open a new issue for concern about triplicate
32059signatures.
32060</p>
32061<p>
32062Adopt issue as written.
32063</p>
32064</blockquote>
32065
32066
32067<p><b>Proposed resolution:</b></p>
32068<p>
32069Change the synopsis in 20.8.15.2 [util.smartptr.shared]:
32070</p>
32071
32072<blockquote><pre>void swap(shared_ptr&amp;<ins>&amp;</ins> r);
32073...
32074template&lt;class T&gt; void swap(shared_ptr&lt;T&gt;&amp; a, shared_ptr&lt;T&gt;&amp; b);
32075<ins>template&lt;class T&gt; void swap(shared_ptr&lt;T&gt;&amp;&amp; a, shared_ptr&lt;T&gt;&amp; b);
32076template&lt;class T&gt; void swap(shared_ptr&lt;T&gt;&amp; a, shared_ptr&lt;T&gt;&amp;&amp; b);</ins>
32077</pre></blockquote>
32078
32079<p>
32080Change 20.8.15.2.4 [util.smartptr.shared.mod]:
32081</p>
32082
32083<blockquote><pre>void swap(shared_ptr&amp;<ins>&amp;</ins> r);
32084</pre></blockquote>
32085
32086<p>
32087Change 20.8.15.2.9 [util.smartptr.shared.spec]:
32088</p>
32089
32090<blockquote><pre>template&lt;class T&gt; void swap(shared_ptr&lt;T&gt;&amp; a, shared_ptr&lt;T&gt;&amp; b);
32091<ins>template&lt;class T&gt; void swap(shared_ptr&lt;T&gt;&amp;&amp; a, shared_ptr&lt;T&gt;&amp; b);
32092template&lt;class T&gt; void swap(shared_ptr&lt;T&gt;&amp; a, shared_ptr&lt;T&gt;&amp;&amp; b);</ins>
32093</pre></blockquote>
32094
32095
32096
32097
32098
32099<hr>
32100<h3><a name="744"></a>744. What is the lifetime of an exception pointed to by an exception_ptr?</h3>
32101<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>
32102 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2007-10-10  <b>Last modified:</b> 2008-09-26</p>
32103<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>
32104<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>
32105<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
32106<p><b>Discussion:</b></p>
32107<p>
32108Without some lifetime guarantee, it is hard to know how this type can be
32109used.  Very specifically, I don't see how the current wording would
32110guarantee and exception_ptr caught at the end of one thread could be safely
32111stored and rethrown in another thread - the original motivation for this
32112API.
32113</p>
32114<p>
32115(Peter Dimov agreed it should be clearer, maybe a non-normative note to
32116explain?)
32117</p>
32118
32119<p><i>[
32120Bellevue:
32121]</i></p>
32122
32123
32124<blockquote>
32125<p>
32126Agree the issue is real.
32127</p>
32128<p>
32129Intent is lifetime is similar to a shared_ptr (and we might even want to
32130consider explicitly saying that it is a shared_ptr&lt; unspecified type &gt;).
32131</p>
32132<p>
32133We expect that most implementations will use shared_ptr, and the
32134standard should be clear that the exception_ptr type is intended to be
32135something whose semantics are smart-pointer-like so that the user does
32136not need to worry about lifetime management. We still need someone to
32137draught those words - suggest emailing Peter Dimov.
32138</p>
32139<p>
32140Move to Open.
32141</p>
32142</blockquote>
32143
32144
32145<p><b>Proposed resolution:</b></p>
32146<p>
32147Change 18.8.5 [propagation]/7:
32148</p>
32149
32150<blockquote>
32151-7- Returns: An <tt>exception_ptr</tt> object that refers to the currently
32152handled exception or a copy of the currently handled exception, or a
32153null <tt>exception_ptr</tt> object if no exception is being handled.
32154<ins>The referenced object remains valid at least as long as there is an
32155<tt>exception_ptr</tt> that refers to it.</ins>
32156If the function needs to allocate memory and the attempt
32157fails, it returns an <tt>exception_ptr</tt> object that refers to an instance of
32158<tt>bad_alloc</tt>. It is unspecified whether the return values of two successive
32159calls to <tt>current_exception</tt> refer to the same exception object. [<i>Note:</i>
32160that is, it is unspecified whether <tt>current_exception</tt> creates a new copy
32161each time it is called. <i>--end note</i>]
32162</blockquote>
32163
32164
32165
32166
32167
32168<hr>
32169<h3><a name="746"></a>746. current_exception may fail with bad_alloc</h3>
32170<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>
32171 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2007-10-10  <b>Last modified:</b> 2008-09-26</p>
32172<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>
32173<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>
32174<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
32175<p><b>Discussion:</b></p>
32176<p>
32177I understand that the attempt to copy an exception may run out of memory,
32178but I believe this is the only part of the standard that mandates failure
32179with specifically <tt>bad_alloc</tt>, as opposed to allowing an
32180implementation-defined type derived from <tt>bad_alloc</tt>.  For instance, the Core
32181language for a failed new expression is:
32182</p>
32183<blockquote>
32184<p>
32185Any other allocation function that fails to allocate storage shall indicate
32186failure only by throwing an exception of a type that would match a handler
32187(15.3) of type <tt>std::bad_alloc</tt> (18.5.2.1).
32188</p>
32189</blockquote>
32190<p>
32191I think we should allow similar freedom here (or add a blanket
32192compatible-exception freedom paragraph in 17)
32193</p>
32194<p>
32195I prefer the clause 17 approach myself, and maybe clean up any outstanding
32196wording that could also rely on it.
32197</p>
32198<p>
32199Although filed against a specific case, this issue is a problem throughout
32200the library. 
32201</p>
32202
32203<p><i>[
32204Bellevue:
32205]</i></p>
32206
32207
32208<blockquote>
32209<p>
32210Is issue bigger than library?
32211</p>
32212<p>
32213No - Core are already very clear about their wording, which is inspiration for the issue.
32214</p>
32215<p>
32216While not sold on the original 18.7.5 use case, the generalised 17.4.4.8 wording is the real issue.
32217</p>
32218<p>
32219Accept the broad view and move to ready
32220</p>
32221</blockquote>
32222
32223
32224<p><b>Proposed resolution:</b></p>
32225<p>
32226Add the following exemption clause to 17.6.4.11 [res.on.exception.handling]:
32227</p>
32228
32229<blockquote>
32230A function may throw a type not listed in its <i>Throws</i> clause so long as it is
32231derived from a class named in the <i>Throws</i> clause, and would be caught by an
32232exception handler for the base type.
32233</blockquote>
32234
32235
32236
32237
32238
32239<hr>
32240<h3><a name="749"></a>749. Currently <tt>has_nothrow_copy_constructor&lt;T&gt;::value</tt> is true if T has 'a' nothrow copy constructor.</h3>
32241<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>
32242 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2007-10-10  <b>Last modified:</b> 2008-09-26</p>
32243<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>
32244<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>
32245<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
32246<p><b>Discussion:</b></p>
32247<p>
32248Unfortunately a class can have multiple copy constructors, and I believe to
32249be useful this trait should only return true is ALL copy constructors are
32250no-throw.
32251</p>
32252<p>
32253For instance:
32254</p>
32255<blockquote>
32256<pre>struct awkward {
32257 awkward( const awkward &amp; ) throw() {}
32258 awkward( awkward &amp; ) { throw "oops"; } };
32259</pre>
32260</blockquote>
32261
32262
32263<p><b>Proposed resolution:</b></p>
32264<p>
32265Change 20.6.4.3 [meta.unary.prop]:
32266</p>
32267
32268<blockquote>
32269<pre>has_trivial_copy_constructor</pre>
32270<blockquote>
32271<tt>T</tt> is a trivial type (3.9) or a reference type or a class type <del>with a trivial copy constructor</del>
32272<ins>where all copy constructors are trivial</ins> (12.8).
32273</blockquote>
32274</blockquote>
32275
32276<blockquote>
32277<pre>has_trivial_assign</pre>
32278<blockquote>
32279<tt>T</tt> is neither <tt>const</tt> nor a reference type, and <tt>T</tt> is a trivial type (3.9)
32280or a class type <del>with a trivial copy assignment operator</del> <ins>where all copy assignment operators are trivial</ins> (12.8).
32281</blockquote>
32282</blockquote>
32283
32284<blockquote>
32285<pre>has_nothrow_copy_constructor</pre>
32286<blockquote>
32287<tt>has_trivial_copy_constructor&lt;T&gt;::value</tt> is <tt>true</tt> or <tt>T</tt> is a class type <del>with
32288a</del> <ins>where all</ins> copy constructor<ins>s</ins> <del>that is</del> <ins>are</ins> 
32289known not to throw any exceptions or <tt>T</tt> is an
32290array of such a class type
32291</blockquote>
32292</blockquote>
32293
32294<blockquote>
32295<pre>has_nothrow_assign</pre>
32296<blockquote>
32297<tt>T</tt> is neither <tt>const</tt> nor a reference type, and
32298<tt>has_trivial_assign&lt;T&gt;::value</tt> is <tt>true</tt> or <tt>T</tt> is a class type <del>with a</del>
32299<ins>where all</ins> copy
32300assignment operator<ins>s</ins> tak<ins>e</ins><del>ing</del> an lvalue of type <tt>T</tt> that is known not to
32301throw any exceptions or <tt>T</tt> is an array of such a class type.
32302</blockquote>
32303</blockquote>
32304
32305
32306
32307
32308
32309
32310<hr>
32311<h3><a name="752"></a>752. Allocator complexity requirement</h3>
32312<p><b>Section:</b> 20.2.2 [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
32313 <b>Submitter:</b> Hans Boehm <b>Opened:</b> 2007-10-11  <b>Last modified:</b> 2009-03-09</p>
32314<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>
32315<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
32316<p><b>Discussion:</b></p>
32317<p>
32318Did LWG recently discuss 20.2.2 [allocator.requirements]-2, which states that "All the operations
32319on the allocators are expected to be amortized constant time."?
32320</p>
32321<p>
32322As I think I pointed out earlier, this is currently fiction for
32323<tt>allocate()</tt> if it has to obtain memory from the OS, and it's unclear to
32324me how to interpret this for <tt>construct()</tt> and <tt>destroy()</tt> if they deal with
32325large objects.  Would it be controversial to officially let these take
32326time linear in the size of the object, as they already do in real life?
32327</p>
32328<p>
32329<tt>Allocate()</tt> more blatantly takes time proportional to the size of the
32330object if you mix in GC.  But it's not really a new problem, and I think
32331we'd be confusing things by leaving the bogus requirements there.  The
32332current requirement on <tt>allocate()</tt> is generally not important anyway,
32333since it takes O(size) to construct objects in the resulting space.
32334There are real performance issues here, but they're all concerned with
32335the constants, not the asymptotic complexity.
32336</p>
32337
32338
32339<p><b>Proposed resolution:</b></p>
32340<p>
32341Change 20.2.2 [allocator.requirements]/2:
32342</p>
32343
32344<blockquote>
32345<p>
32346-2- Table 39 describes the requirements on types manipulated through
32347allocators. <del>All the operations on the allocators are expected to be
32348amortized constant time.</del> Table 40 describes the
32349requirements on allocator types.
32350</p>
32351</blockquote>
32352
32353
32354
32355
32356
32357<hr>
32358<h3><a name="753"></a>753. Move constructor in draft</h3>
32359<p><b>Section:</b> 20.2.1 [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
32360 <b>Submitter:</b> Yechezkel Mett <b>Opened:</b> 2007-10-14  <b>Last modified:</b> 2009-03-09</p>
32361<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>
32362<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>
32363<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
32364<p><b>Discussion:</b></p>
32365<p>
32366The draft standard n2369 uses the term <i>move constructor</i> in a few
32367places, but doesn't seem to define it.
32368</p>
32369
32370<p>
32371<tt>MoveConstructible</tt> requirements are defined in Table 33 in 20.2.1 [utility.arg.requirements] as
32372follows:
32373</p>
32374
32375<blockquote>
32376<table border="1">
32377<caption><tt>MoveConstructible</tt> requirements</caption>
32378<tbody><tr>
32379<th>expression</th> <th>post-condition</th>
32380</tr>
32381<tr>
32382<td><tt>T t = rv</tt></td> <td><tt>t</tt> is equivalent to the value of <tt>rv</tt> before the construction</td>
32383</tr>
32384<tr>
32385<td colspan="2">[<i>Note:</i> There is no requirement on the value of <tt>rv</tt> after the 
32386construction. <i>-- end note</i>]</td>
32387</tr>
32388</tbody></table>
32389</blockquote>
32390
32391<p>
32392(where <tt>rv</tt> is a non-const rvalue of type <tt>T</tt>).
32393</p>
32394
32395<p>
32396So I assume the move constructor is the constructor that would be used
32397in filling the above requirement.
32398</p>
32399
32400<p>
32401For <tt>vector::reserve</tt>, <tt>vector::resize</tt> and the <tt>vector</tt> modifiers given in
3240223.3.6.4 [vector.modifiers] we have
32403</p>
32404
32405<blockquote>
32406<i>Requires:</i> If <tt>value_type</tt> has a move constructor, that constructor shall
32407not throw any exceptions.
32408</blockquote>
32409
32410<p>
32411Firstly "If <tt>value_type</tt> has a move constructor" is superfluous; every
32412type which can be put into a <tt>vector</tt> has a move constructor (a copy
32413constructor is also a move constructor). Secondly it means that for
32414any <tt>value_type</tt> which has a throwing copy constructor and no other move
32415constructor these functions cannot be used -- which I think will come
32416as a shock to people who have been using such types in <tt>vector</tt> until
32417now!
32418</p>
32419
32420<p>
32421I can see two ways to correct this. The simpler, which is presumably
32422what was intended, is to say "If <tt>value_type</tt> has a move constructor and
32423no copy constructor, the move constructor shall not throw any
32424exceptions" or "If <tt>value_type</tt> has a move constructor which changes the
32425value of its parameter,".
32426</p>
32427
32428<p>
32429The other alternative is add to <tt>MoveConstructible</tt> the requirement that
32430the expression does not throw. This would mean that not every type
32431that satisfies the <tt>CopyConstructible</tt> requirements also satisfies the
32432<tt>MoveConstructible</tt> requirements. It would mean changing requirements in
32433various places in the draft to allow either <tt>MoveConstructible</tt> or
32434<tt>CopyConstructible</tt>, but I think the result would be clearer and
32435possibly more concise too.
32436</p>
32437
32438
32439<p><b>Proposed resolution:</b></p>
32440<p>
32441Add new defintions to 17.3 [definitions]:
32442</p>
32443
32444<blockquote>
32445<p>
32446<b>move constructor</b>
32447</p>
32448<p>
32449a constructor which accepts only rvalue arguments of that type, and modifies the rvalue as a
32450side effect during the construction.
32451</p>
32452<p>
32453<b>move assignment operator</b>
32454</p>
32455<p>
32456an assignment operator which accepts only rvalue arguments of that type, and modifies the rvalue as a
32457side effect during the assignment.
32458</p>
32459<p>
32460<b>move assignment</b>
32461</p>
32462<p>
32463use of the move assignment operator.
32464</p>
32465</blockquote>
32466
32467<p><i>[
32468Howard adds post-Bellevue:
32469]</i></p>
32470
32471
32472<blockquote>
32473<p>
32474Unfortunately I believe the wording recommended by the LWG in Bellevue is incorrect.  <tt>reserve</tt> et. al. will use a move constructor
32475if one is available, else it will use a copy constructor.  A type may have both.  If the move constructor is
32476used, it must not throw.  If the copy constructor is used, it can throw.  The sentence in the proposed wording
32477is correct without the recommended insertion.  The Bellevue LWG recommended moving this issue to Ready.  I am
32478unfortunately pulling it back to Open.  But I'm drafting wording to atone for this egregious action. :-)
32479</p>
32480</blockquote>
32481
32482
32483
32484
32485
32486
32487<hr>
32488<h3><a name="755"></a>755. <tt>std::vector</tt> and <tt>std:string</tt> lack explicit shrink-to-fit operations</h3>
32489<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>
32490 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2007-10-31  <b>Last modified:</b> 2008-09-26</p>
32491<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>
32492<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
32493<p><b>Discussion:</b></p>
32494<p>
32495A <tt>std::vector</tt> can be shrunk-to-fit via the swap idiom:
32496</p>
32497
32498<blockquote><pre>vector&lt;int&gt; v;
32499...
32500v.swap(vector&lt;int&gt;(v));  // shrink to fit
32501</pre>
32502<blockquote><p>
32503or:
32504</p></blockquote>
32505<pre>vector&lt;int&gt;(v).swap(v);  // shrink to fit
32506</pre>
32507<blockquote><p>
32508or:
32509</p></blockquote>
32510<pre>swap(v, vector&lt;int&gt;(v));  // shrink to fit
32511</pre>
32512</blockquote>
32513
32514<p>
32515A non-binding request for shrink-to-fit can be made to a <tt>std::string</tt> via:
32516</p>
32517
32518<blockquote><pre>string s;
32519...
32520s.reserve(0);
32521</pre></blockquote>
32522
32523<p>
32524Neither of these is at all obvious to beginners, and even some
32525experienced C++ programmers are not aware that shrink-to-fit is
32526trivially available.
32527</p>
32528<p>
32529Lack of explicit functions to perform these commonly requested
32530operations makes vector and string less usable for non-experts. Because
32531the idioms are somewhat obscure, code readability is impaired. It is
32532also unfortunate that two similar vector-like containers use different
32533syntax for the same operation.
32534</p>
32535<p>
32536The proposed resolution addresses these concerns. The proposed function
32537takes no arguments to keep the solution simple and focused.
32538</p>
32539
32540
32541<p><b>Proposed resolution:</b></p>
32542<p>
32543To Class template basic_string 21.4 [basic.string] synopsis,
32544Class template vector 23.3.6 [vector] synopsis, and Class
32545vector&lt;bool&gt; 23.3.7 [vector.bool] synopsis, add:
32546</p>
32547
32548<blockquote><pre>    
32549void shrink_to_fit();
32550</pre></blockquote>
32551
32552<p>
32553To basic_string capacity 21.4.4 [string.capacity] and vector
32554capacity 23.3.6.2 [vector.capacity], add:
32555</p>
32556
32557<blockquote>
32558<pre>void shrink_to_fit();
32559</pre>
32560<blockquote>
32561<i>Remarks:</i> <tt>shrink_to_fit</tt> is a non-binding request to reduce
32562<tt>capacity()</tt> to <tt>size()</tt>. [<i>Note:</i> The request is non-binding to
32563allow latitude for implementation-specific optimizations.
32564<i>-- end note</i>]
32565</blockquote>
32566</blockquote>
32567
32568<p><i>[
32569<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>.
32570]</i></p>
32571
32572
32573
32574
32575
32576
32577<hr>
32578<h3><a name="758"></a>758. <tt>shared_ptr</tt> and <tt>nullptr</tt></h3>
32579<p><b>Section:</b> 20.8.15.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
32580 <b>Submitter:</b> Joe Gottman <b>Opened:</b> 2007-10-31  <b>Last modified:</b> 2009-03-09</p>
32581<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>
32582<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
32583<p><b>Discussion:</b></p>
32584<p>
32585Consider the following program:
32586</p>
32587
32588<blockquote><pre>int main() {
32589   shared_ptr&lt;int&gt; p(nullptr); 
32590   return 0;
32591}
32592</pre></blockquote>
32593
32594<p>
32595This program will fail to compile because <tt>shared_ptr</tt> uses the following 
32596template constructor to construct itself from pointers:
32597</p>
32598
32599<blockquote><pre>template &lt;class Y&gt; shared_ptr(Y *);
32600</pre></blockquote>
32601
32602<p>
32603According
32604to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2431.pdf">N2431</a>,
32605the conversion from <tt>nullptr_t</tt> to <tt>Y *</tt> is not
32606deducible, so the above constructor will not be found.  There are similar problems with the
32607constructors that take a pointer and a <tt>deleter</tt> or a
32608pointer, a <tt>deleter</tt> and an allocator, as well as the
32609corresponding forms of <tt>reset()</tt>. Note that <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2435.htm">N2435</a>
32610will solve this problem for constructing from just <tt>nullptr</tt>, but not for constructors that use
32611<tt>deleters</tt> or allocators or for <tt>reset()</tt>.
32612</p>
32613
32614<p>
32615In the case of the functions that take deleters, there is the additional
32616question of what argument should be passed to the deleter when it is
32617eventually called.  There are two reasonable possibilities: <tt>nullptr</tt> or
32618<tt>static_cast&lt;T *&gt;(0)</tt>, where <tt>T</tt> is the template argument of the
32619<tt>shared_ptr</tt>.  It is not immediately clear which of these is better.  If
32620<tt>D::operator()</tt> is a template function similar to <tt>shared_ptr</tt>'s
32621constructor, then <tt>d(static_cast&lt;T*&gt;(0))</tt> will compile and <tt>d(nullptr)</tt>
32622will not.  On the other hand, if <tt>D::operator()()</tt> takes a parameter that
32623is a pointer to some type other that <tt>T</tt> (for instance <tt>U*</tt> where <tt>U</tt> derives
32624from <tt>T</tt>) then <tt>d(nullptr)</tt> will compile and <tt>d(static_cast&lt;T *&gt;(0))</tt> may not.
32625</p>
32626
32627<p><i>[
32628Bellevue:
32629]</i></p>
32630
32631
32632<blockquote>
32633<p>
32634The general idea is right, we need to be able to pass a nullptr to a
32635shared_ptr, but there are a few borderline editorial issues here. (For
32636example, the single-argument nullptr_t constructor in the class synopsis
32637isn't marked explicit, but it is marked explicit in the proposed wording
32638for 20.6.6.2.1. There is a missing empty parenthesis in the form that
32639takes a nullptr_t, a deleter, and an allocator.)
32640</p>
32641<p>
32642More seriously: this issue says that a shared_ptr constructed from a
32643nullptr is empty. Since "empty" is undefined, it's hard to know whether
32644that's right. This issue is pending on handling that term better.
32645</p>
32646<p>
32647Peter suggests definition of empty should be "does not own anything"
32648</p>
32649<p>
32650Is there an editorial issue that post-conditions should refer to get() =
32651nullptr, rather than get() = 0?
32652</p>
32653<p>
32654No strong feeling towards accept or NAD, but prefer to make a decision than leave it open.
32655</p>
32656<p>
32657Seems there are no technical merits between NAD and Ready, comes down to
32658"Do we intentially want to allow/disallow null pointers with these
32659functions". Staw Poll - support null pointers 5 - No null pointers 0
32660</p>
32661<p>
32662Move to Ready, modulo editorial comments
32663</p>
32664</blockquote>
32665
32666<p><i>[
32667post Bellevue Peter adds:
32668]</i></p>
32669
32670
32671<blockquote>
32672<p>
32673The following wording changes are less intrusive:
32674</p>
32675
32676<p>
32677In 20.8.15.2.1 [util.smartptr.shared.const], add:
32678</p>
32679
32680<blockquote><pre>shared_ptr(nullptr_t);
32681</pre></blockquote>
32682
32683<p>
32684after:
32685</p>
32686
32687<blockquote><pre>shared_ptr();
32688</pre></blockquote>
32689
32690<p>
32691(Absence of explicit intentional.)
32692</p>
32693
32694<p>
32695<tt>px.reset( nullptr )</tt> seems a somewhat contrived way to write <tt>px.reset()</tt>, so
32696I'm not convinced of its utility.
32697</p>
32698<p>
32699It's similarly not clear to me whether the deleter constructors need to be
32700extended to take <tt>nullptr</tt>, but if they need to:
32701</p>
32702<p>
32703Add
32704</p>
32705
32706<blockquote><pre>template&lt;class D&gt; shared_ptr(nullptr_t p, D d);
32707template&lt;class D, class A&gt; shared_ptr(nullptr_t p, D d, A a);
32708</pre></blockquote>
32709
32710<p>
32711after
32712</p>
32713
32714<blockquote><pre>template&lt;class Y, class D&gt; shared_ptr(Y* p, D d);
32715template&lt;class Y, class D, class A&gt; shared_ptr(Y* p, D d, A a);
32716</pre></blockquote>
32717
32718<p>
32719Note that this changes the semantics of the new constructors such that they
32720consistently call <tt>d(p)</tt> instead of <tt>d((T*)0)</tt> when <tt>p</tt> is <tt>nullptr</tt>.
32721</p>
32722<p>
32723The ability to be able to pass <tt>0/NULL</tt> to a function that takes a <tt>shared_ptr</tt>
32724has repeatedly been requested by users, but the other additions that the
32725proposed resolution makes are not supported by real world demand or
32726motivating examples.
32727</p>
32728<p>
32729It might be useful to split the obvious and non-controversial <tt>nullptr_t</tt>
32730constructor into a separate issue. Waiting for "empty" to be clarified is
32731unnecessary; this is effectively an alias for the default constructor.
32732</p>
32733</blockquote>
32734
32735<p><i>[
32736Sophia Antipolis:
32737]</i></p>
32738
32739
32740<blockquote>
32741<p>
32742We want to remove the reset functions from the proposed resolution.
32743</p>
32744<p>
32745The remaining proposed resolution text (addressing the constructors) are wanted.
32746</p>
32747<p>
32748Disposition: move to review. The review should check the wording in the then-current working draft.
32749</p>
32750</blockquote>
32751
32752
32753
32754<p><b>Proposed resolution:</b></p>
32755<p>
32756In 20.8.15.2 [util.smartptr.shared] p4, add to the definition/synopsis
32757of <tt>shared_ptr</tt>:
32758</p>
32759
32760<blockquote><pre>template&lt;class D&gt; shared_ptr(nullptr_t p, D d);
32761template&lt;class D, class A&gt; shared_ptr(nullptr_t p, D d, A a);
32762</pre></blockquote>
32763
32764<p>
32765after
32766</p>
32767
32768<blockquote><pre>template&lt;class Y, class D&gt; shared_ptr(Y* p, D d);
32769template&lt;class Y, class D, class A&gt; shared_ptr(Y* p, D d, A a);
32770</pre></blockquote>
32771
32772<p>
32773In 20.8.15.2.1 [util.smartptr.shared.const] add:
32774</p>
32775
32776<blockquote><pre>template&lt;class D&gt; shared_ptr(nullptr_t p, D d);
32777template&lt;class D, class A&gt; shared_ptr(nullptr_t p, D d, A a);
32778</pre></blockquote>
32779
32780<p>
32781after
32782</p>
32783
32784<blockquote><pre>template&lt;class Y, class D&gt; shared_ptr(Y* p, D d);
32785template&lt;class Y, class D, class A&gt; shared_ptr(Y* p, D d, A a);
32786</pre></blockquote>
32787
32788<p>
32789(reusing the following paragraphs 20.8.15.2.1 [util.smartptr.shared.const]/9-13 that speak of p.)
32790</p>
32791
32792<p>
32793In 20.8.15.2.1 [util.smartptr.shared.const]/10,  change
32794</p>
32795
32796<blockquote>
32797<i>Effects:</i> Constructs a <tt>shared_ptr</tt> object that <i>owns</i> the
32798<del>pointer</del> <ins>object</ins> <tt>p</tt> and the deleter <tt>d</tt>. The second 
32799constructor shall use a copy of <tt>a</tt> to allocate memory for internal use.
32800</blockquote>
32801
32802
32803<p><b>Rationale:</b></p>
32804<p><i>[
32805San Francisco:
32806]</i></p>
32807
32808
32809<blockquote>
32810"pointer" is changed to "object" to handle the fact that nullptr_t isn't a pointer.
32811</blockquote>
32812
32813
32814
32815
32816
32817
32818<hr>
32819<h3><a name="759"></a>759. A reference is not an object</h3>
32820<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>
32821 <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2007-11-06  <b>Last modified:</b> 2008-09-26</p>
32822<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>
32823<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>
32824<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
32825<p><b>Discussion:</b></p>
32826<p>
3282723.2 [container.requirements] says:
32828</p>
32829
32830<blockquote>
32831-12- Objects passed to member functions of a container as rvalue references shall not be elements of that container. No 
32832diagnostic required.
32833</blockquote>
32834
32835<p>
32836A reference is not an object, but this sentence appears to claim so.
32837</p>
32838
32839<p>
32840What is probably meant here:
32841</p>
32842<blockquote>
32843An object bound to an rvalue
32844reference parameter of a member function of a container shall not be
32845an element of that container; no diagnostic required.
32846</blockquote>
32847
32848
32849
32850<p><b>Proposed resolution:</b></p>
32851<p>
32852Change 23.2 [container.requirements]:
32853</p>
32854
32855<blockquote>
32856-12- <del>Objects passed to member functions of a container as rvalue references shall not be elements</del>
32857<ins>An object bound to an rvalue
32858reference parameter of a member function of a container shall not be
32859an element</ins>
32860of that container<del>.</del><ins>;</ins> <del>N</del><ins>n</ins>o 
32861diagnostic required.
32862</blockquote>
32863
32864
32865
32866
32867
32868
32869<hr>
32870<h3><a name="761"></a>761. <tt>unordered_map</tt> needs an <tt>at()</tt> member function</h3>
32871<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>
32872 <b>Submitter:</b> Joe Gottman <b>Opened:</b> 2007-11-15  <b>Last modified:</b> 2008-09-26</p>
32873<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
32874<p><b>Discussion:</b></p>
32875<p>
32876The new member function <tt>at()</tt> was recently added to <tt>std::map()</tt>.  It acts 
32877like <tt>operator[]()</tt>, except it throws an exception when the input key is 
32878not found.  It is useful when the <tt>map</tt> is <tt>const</tt>, the <tt>value_type</tt> of the 
32879key doesn't have  a default constructor, it is an error if the key is 
32880not found, or the user wants to avoid accidentally adding an element to 
32881the map.  For exactly these same reasons, <tt>at()</tt> would be equally useful 
32882in <tt>std::unordered_map</tt>.
32883</p>
32884
32885
32886<p><b>Proposed resolution:</b></p>
32887<p>
32888Add the following functions to the definition of <tt>unordered_map</tt> under "lookup" (23.5.1 [unord.map]):
32889</p>
32890
32891<blockquote><pre>mapped_type&amp; at(const key_type&amp; k);
32892const mapped_type &amp;at(const key_type &amp;k) const;
32893</pre></blockquote>
32894
32895<p>
32896Add the following definitions to 23.5.1.2 [unord.map.elem]:
32897</p>
32898
32899<blockquote>
32900<pre>mapped_type&amp; at(const key_type&amp; k);
32901const mapped_type &amp;at(const key_type &amp;k) const;
32902</pre>
32903<blockquote>
32904<p>
32905<i>Returns:</i> A reference to <tt>x.second</tt>, where <tt>x</tt> is the (unique) element 
32906whose key is equivalent to <tt>k</tt>.
32907</p>
32908<p>
32909<i>Throws:</i> An exception object of type <tt>out_of_range</tt> if no such element 
32910is present.
32911</p>
32912</blockquote>
32913</blockquote>
32914
32915<p><i>[
32916Bellevue:  Editorial note: the "(unique)" differs from map.
32917]</i></p>
32918
32919
32920
32921
32922
32923
32924
32925<hr>
32926<h3><a name="762"></a>762. <tt>std::unique_ptr</tt> requires complete type?</h3>
32927<p><b>Section:</b> 20.8.14 [unique.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
32928 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2007-11-30  <b>Last modified:</b> 2008-09-26</p>
32929<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>
32930<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
32931<p><b>Discussion:</b></p>
32932<p>
32933In contrast to the proposed <tt>std::shared_ptr</tt>, <tt>std::unique_ptr</tt>
32934does currently not support incomplete types, because it
32935gives no explicit grant - thus instantiating <tt>unique_ptr</tt> with
32936an incomplete pointee type <tt>T</tt> automatically belongs to
32937undefined behaviour according to 17.6.3.8 [res.on.functions]/2, last
32938bullet. This is an unnecessary restriction and prevents
32939many well-established patterns - like the bridge pattern -
32940for <tt>std::unique_ptr</tt>.
32941</p>
32942
32943<p><i>[
32944Bellevue:
32945]</i></p>
32946
32947
32948<blockquote>
32949Move to open. The LWG is comfortable with the intent of allowing
32950incomplete types and making <tt>unique_ptr</tt> more like <tt>shared_ptr</tt>, but we are
32951not comfortable with the wording. The specification for <tt>unique_ptr</tt>
32952should be more like that of <tt>shared_ptr</tt>. We need to know, for individual
32953member functions, which ones require their types to be complete. The
32954<tt>shared_ptr</tt> specification is careful to say that for each function, and
32955we need the same level of care here. We also aren't comfortable with the
32956"part of the operational semantic" language; it's not used elsewhere in
32957the standard, and it's not clear what it means. We need a volunteer to
32958produce new wording.
32959</blockquote>
32960
32961
32962<p><b>Proposed resolution:</b></p>
32963<p>
32964The proposed changes in the following revision refers to the current state of
32965N2521 including the assumption that X [unique.ptr.compiletime] will be removed
32966according to the current state of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>.
32967</p>
32968<p>
32969The specialization <tt>unique_ptr&lt;T[]&gt;</tt> has some more restrictive constraints on
32970type-completeness on <tt>T</tt> than <tt>unique_ptr&lt;T&gt;</tt>. The following proposed wordings
32971try to cope with that. If the committee sees less usefulness on relaxed
32972constraints on <tt>unique_ptr&lt;T[]&gt;</tt>, the alternative would be to stop this relaxation
32973e.g. by adding one further bullet to 20.8.14.3 [unique.ptr.runtime]/1:
32974"<tt>T</tt> shall be a complete type, if used as template argument of
32975<tt>unique_ptr&lt;T[], D&gt;</tt>
32976</p>
32977<p>
32978This 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
32979problems with this one,
32980because <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
32981with the here discussed
32982ones, provided that <tt>D::pointer</tt>'s operations (including default
32983construction, copy construction/assignment,
32984and pointer conversion) are specified <em>not</em> to throw, otherwise this
32985would have impact on the
32986current specification of <tt>unique_ptr</tt>.
32987</p>
32988
32989<ol>
32990<li>
32991<p>
32992In 20.8.14 [unique.ptr]/2 add as the last sentence to the existing para:
32993</p>
32994
32995<blockquote>
32996The <tt>unique_ptr</tt> provides a semantics of strict ownership. A
32997<tt>unique_ptr</tt> owns the object it holds a pointer to. A
32998<tt>unique_ptr</tt> is not <tt>CopyConstructible</tt>, nor
32999<tt>CopyAssignable</tt>, however it is <tt>MoveConstructible</tt> and
33000<tt>MoveAssignable</tt>. <ins>The template parameter <tt>T</tt> of
33001<tt>unique_ptr</tt> may be an incomplete type.</ins> [ <i>Note:</i> The
33002uses of <tt>unique_ptr</tt> include providing exception safety for
33003dynamically allcoated memory, passing ownership of dynamically allocated
33004memory to a function, and returning dynamically allocated memory from a
33005function. -- <i>end note</i> ]
33006</blockquote>
33007</li>
33008
33009<li>
33010<p>
3301120.8.14.2.1 [unique.ptr.single.ctor]/1: No changes necessary.
33012</p>
33013
33014<blockquote>
33015<p><i>[
33016N.B.: We only need the requirement that <tt>D</tt> is <tt>DefaultConstructible</tt>.
33017The current wording says just this.
33018]</i></p>
33019
33020</blockquote>
33021</li>
33022
33023<li>
33024<p>
33025In 20.8.14.2.1 [unique.ptr.single.ctor]/5 change the requires clause to say:
33026</p>
33027
33028<blockquote>
33029<p>
33030<i>Requires:</i> <del>The expression <tt>D()(p)</tt> shall be well formed. The default constructor
33031of <tt>D</tt> shall not throw an exception.</del>
33032<del><tt>D</tt> must not be a reference type.</del>
33033<ins>
33034<tt>D</tt> shall be default constructible, and that construction
33035shall not throw an exception.
33036</ins>
33037</p>
33038<p><i>[
33039N.B.: There is no need that the expression <tt>D()(p)</tt> is well-formed at
33040this point. I assume that the current wording is based on the
33041corresponding <tt>shared_ptr</tt> wording. In case of <tt>shared_ptr</tt> this
33042requirement is necessary, because the corresponding c'tor *can* fail
33043and must invoke delete <tt>p/d(p)</tt> in this case. <tt>Unique_ptr</tt> is simpler in
33044this regard. The *only* functions that must insist on well-formedness
33045and well-definedness of the expression <tt>get_deleter()(get())</tt> are (1)
33046the destructor and (2) <tt>reset</tt>. The reasoning for the wording change to
33047explicitly require <tt>DefaultConstructible</tt> of <tt>D</tt> is to guarantee that
33048invocation of
33049<tt>D</tt>'s default c'tor is both well-formed and well-defined. Note also that
33050we do *not* need the
33051requirement that <tt>T</tt> must be complete, also in contrast to <tt>shared_ptr</tt>.
33052<tt>Shared_ptr</tt> needs this, because it's c'tor is a template c'tor which
33053potentially requires <tt>Convertible&lt;Y*, X*&gt;</tt>, which
33054again requires Completeness of <tt>Y</tt>, if <tt>!SameType&lt;X, Y&gt;</tt>
33055]</i></p>
33056
33057</blockquote>
33058</li>
33059
33060<li>
33061<p>
33062Merge 20.8.14.2.1 [unique.ptr.single.ctor]/12+13 thereby removing the sentence
33063of 12, but transferring the "requires" to 13:
33064</p>
33065
33066<blockquote>
33067<p>
33068<i>Requires:</i> If <tt>D</tt> is not an lvalue-reference type then[..]
33069</p>
33070<p><i>[
33071N.B.: For the same reasons as for (3), there is no need that <tt>d(p)</tt> is
33072well-formed/well-defined at this point. The current wording guarantees
33073all what we need, namely that the initialization of both the <tt>T*</tt>
33074pointer and the <tt>D</tt> deleter are well-formed and well-defined.
33075]</i></p>
33076
33077</blockquote>
33078</li>
33079
33080<li>
3308120.8.14.2.1 [unique.ptr.single.ctor]/17: No changes necessary.
33082</li>
33083<li>
33084<p>20.8.14.2.1 [unique.ptr.single.ctor]/21:</p>
33085
33086<blockquote>
33087<i>Requires:</i> If <tt>D</tt> is not a reference type, construction of
33088the deleter <tt>D</tt> from an rvalue of type <tt>E</tt> shall be well
33089formed and shall not throw an exception. If <tt>D</tt> is a reference
33090type, then <tt>E</tt> shall be the same type as <tt>D</tt> (diagnostic
33091required). <tt>U*</tt> shall be implicitly convertible to <tt>T*</tt>.
33092<ins>[<i>Note:</i> These requirements imply that <tt>T</tt> and <tt>U</tt>
33093be complete types. <i>-- end note</i>]</ins>
33094</blockquote>
33095
33096<p><i>[
33097N.B.: The current wording of 21 already implicitly guarantees that <tt>U</tt>
33098is completely defined, because it requires that <tt>Convertible&lt;U*, T*&gt;</tt> is
33099true. If the committee wishes this explicit requirement can be added,
33100e.g. "<tt>U</tt> shall be a complete type."
33101]</i></p>
33102
33103</li>
33104
33105<li>
33106<p>
3310720.8.14.2.2 [unique.ptr.single.dtor]: Just before p1 add a new paragraph:
33108</p>
33109<blockquote>
33110<p>
33111<i>Requires:</i> The expression <tt>get_deleter()(get())</tt> shall be well-formed,
33112shall have well-defined behavior, and shall not throw exceptions.
33113<ins>[<i>Note:</i> The use of <tt>default_delete</tt> requires <tt>T</tt> to
33114be a complete type. <i>-- end note</i>]</ins>
33115</p>
33116<p><i>[
33117N.B.: This requirement ensures that the whole responsibility on
33118type-completeness of <tt>T</tt> is delegated to this expression.
33119]</i></p>
33120
33121</blockquote>
33122</li>
33123
33124<li>
33125<p>
3312620.8.14.2.3 [unique.ptr.single.asgn]/1: No changes necessary, except the
33127current editorial issue, that "must shall" has to be changed to
33128"shall", but this change is not a special part of this resolution.
33129</p>
33130
33131<p><i>[
33132N.B. The current wording is sufficient, because we can delegate all
33133further requirements on the requirements of the effects clause
33134]</i></p>
33135
33136</li>
33137
33138<li>
33139<p>
3314020.8.14.2.3 [unique.ptr.single.asgn]/6:
33141</p>
33142
33143<blockquote>
33144<i>Requires:</i> Assignment of the deleter <tt>D</tt> from an rvalue
33145<tt>D</tt> shall not throw an exception. <tt>U*</tt> shall be implicitly
33146convertible to <tt>T*</tt>.
33147<ins>[<i>Note:</i> These requirements imply that <tt>T</tt> and <tt>U</tt>
33148be complete types. <i>-- end note</i>]</ins>
33149</blockquote>
33150
33151<p><i>[
33152N.B.: The current wording of p. 6 already implicitly guarantees that
33153<tt>U</tt> is completely defined, because it requires that <tt>Convertible&lt;U*, T*&gt;</tt>
33154is true, see (6)+(8).
33155]</i></p>
33156
33157</li>
33158
33159<li>
33160<p>
3316120.8.14.2.3 [unique.ptr.single.asgn]/11: No changes necessary.
33162</p>
33163<p><i>[
33164N.B.: Delegation to requirements of effects clause is sufficient.
33165]</i></p>
33166
33167</li>
33168
33169<li>
3317020.8.14.2.4 [unique.ptr.single.observers]/1+4+7+9+11:
33171</li>
33172
33173<blockquote>
33174<pre>T* operator-&gt;() const;</pre>
33175<blockquote>
33176<ins><i>Note:</i> Use typically requires <tt>T</tt> shall be complete. <i>-- end note</i>]</ins>
33177</blockquote>
33178</blockquote>
33179
33180<li>
3318120.8.14.2.5 [unique.ptr.single.modifiers]/1: No changes necessary.
33182</li>
33183
33184<li>
33185<p>
3318620.8.14.2.5 [unique.ptr.single.modifiers]/4: Just before p. 4 add a new paragraph:
33187</p>
33188<blockquote>
33189<i>Requires:</i> The expression <tt>get_deleter()(get())</tt> shall be well-formed,
33190shall have well-defined behavior, and shall not throw exceptions.
33191</blockquote>
33192</li>
33193
33194<li>
3319520.8.14.2.5 [unique.ptr.single.modifiers]/7: No changes necessary.
33196</li>
33197
33198<li>
33199<p>
3320020.8.14.3 [unique.ptr.runtime]: Add one additional bullet on paragraph 1:
33201</p>
33202
33203<blockquote>
33204<p>
33205A specialization for array types is provided with a slightly altered interface.
33206</p>
33207
33208<ul>
33209<li>
33210...
33211</li>
33212<li>
33213<ins><tt>T</tt> shall be a complete type.</ins>
33214</li>
33215</ul>
33216</blockquote>
33217</li>
33218</ol>
33219
33220<p><i>[
33221post Bellevue: Daniel provided revised wording.
33222]</i></p>
33223
33224
33225
33226
33227
33228
33229
33230<hr>
33231<h3><a name="765"></a>765. more on iterator validity</h3>
33232<p><b>Section:</b> X [iterator.concepts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
33233 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-12-14  <b>Last modified:</b> 2009-07-18</p>
33234<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>
33235<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
33236<p><b>Discussion:</b></p>
33237       <p>
33238
33239Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#278">278</a>
33240defines the meaning of the term "invalid iterator" as one that may be
33241singular.
33242
33243       </p>
33244       <p>
33245
33246Consider the following code:
33247
33248       </p>
33249       <pre>   std::deque&lt;int&gt; x, y;
33250   std::deque&lt;int&gt;::iterator i = x.end(), j = y.end();
33251   x.swap(y);
33252       </pre>
33253       <p>
33254
33255Given that <code>swap()</code> is required not to invalidate iterators
33256and using the definition above, what should be the expected result of
33257comparing <code>i</code> and <code>j</code> to <code>x.end()</code>
33258and <code>y.end()</code>, respectively, after the <code>swap()</code>?
33259
33260       </p>
33261       <p>
33262
33263I.e., is the expression below required to evaluate
33264to <code>true</code>?
33265
33266       </p>
33267       <pre>   i == y.end() &amp;&amp; j == x.end()
33268       </pre>
33269       <p>
33270
33271(There are at least two implementations where the expression
33272returns <code>false</code>.)
33273
33274       </p>
33275       <p>
33276
33277More 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
33278make any guarantees about whether iterators actually point to the same
33279elements or be associated with the same containers after a
33280non-invalidating operation as they did before?
33281
33282       </p>
33283       <p>
33284
33285Here's a motivating example intended to demonstrate the importance of
33286the question:
33287
33288       </p>
33289       <pre>   Container x, y ({ 1, 2});   // pseudocode to initialize y with { 1, 2 }
33290   Container::iterator i = y.begin() + 1;
33291   Container::iterator j = y.end();
33292   std::swap(x, y);
33293   std::find(i, j, 3);
33294       </pre>
33295       <p>
33296
33297<code>swap()</code> guarantees that <code>i</code> and <code>j</code>
33298continue to be valid. Unless the spec says that even though they are
33299valid they may no longer denote a valid range the code above must be
33300well-defined. Expert opinions on this differ as does the behavior of
33301popular implementations for some standard <code>Containers</code>.
33302
33303       </p>
33304<p><i>[
33305San Francisco:
33306]</i></p>
33307
33308
33309<blockquote>
33310<p>Pablo: add a note to the last bullet of paragraph 11 of 23.1.1
33311clarifying that the end() iterator doesn't refer to an element and that
33312it can therefore be invalidated.
33313</p>
33314<p>
33315Proposed wording:
33316</p>
33317<blockquote>
33318[<i>Note:</i> The <tt>end()</tt> iterator does not refer to any element and can
33319therefore be invalidated. <i>-- end note</i>]
33320</blockquote>
33321<p>
33322Howard will add this proposed wording to the issue and then move it to Review.
33323</p>
33324</blockquote>
33325
33326<p><i>[
33327Post Summit:
33328]</i></p>
33329
33330
33331<blockquote>
33332<p>
33333Lawrence: suggestion: "Note: The <tt>end()</tt> iterator does not refer to any element"
33334</p>
33335<p>
33336Walter: "Note: The <tt>end()</tt> iterator can nevertheless be invalidated,
33337because it does not refer to any element."
33338</p>
33339<p>
33340Nick: "The <tt>end()</tt> iterator does not refer to any element. It is therefore
33341subject to being invalidated."
33342</p>
33343<p>
33344Consensus: go with Nick
33345</p>
33346<p>
33347With that update, Recommend Tentatively Ready.
33348</p>
33349</blockquote>
33350
33351
33352
33353<p><b>Proposed resolution:</b></p>
33354<p>
33355Add to 23.2.1 [container.requirements.general], p11:
33356</p>
33357
33358<blockquote>
33359<p>
33360Unless otherwise specified (see 23.1.4.1, 23.1.5.1, 23.2.2.3, and
3336123.2.6.4) all container types defined in this Clause meet the following
33362additional requirements:
33363</p>
33364<ul>
33365<li>...</li>
33366<li>
33367no <tt>swap()</tt> function invalidates any references, pointers, or
33368iterators referring to the elements of the containers being swapped.
33369<ins>[<i>Note:</i> The <tt>end()</tt> iterator does not refer to any element. It is therefore
33370subject to being invalidated. <i>-- end note</i>]</ins>
33371</li>
33372</ul>
33373</blockquote>
33374
33375
33376
33377
33378
33379<hr>
33380<h3><a name="766"></a>766. Inconsistent exception guarantees between ordered and unordered associative containers</h3>
33381<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>
33382 <b>Submitter:</b> Ion Gazta�aga <b>Opened:</b> 2007-12-22  <b>Last modified:</b> 2008-09-26</p>
33383<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>
33384<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>
33385<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
33386<p><b>Discussion:</b></p>
33387<p>
3338823.2 [container.requirements]p10 states:
33389</p>
33390
33391<blockquote>
33392<p>
33393Unless otherwise specified (see 23.2.2.3 and 23.2.5.4) all container types defined in this clause meet the following
33394additional requirements:
33395</p>
33396<ul>
33397
33398<li>[...]</li>
33399
33400<li>no <tt>erase()</tt>, <tt>pop_back()</tt> or <tt>pop_front()</tt> function throws an exception.</li>
33401
33402</ul>
33403</blockquote>
33404
33405<p>
3340623.3.2.3 [deque.modifiers] and 23.3.6.4 [vector.modifiers] offer
33407additional guarantees for <tt>deque</tt>/<tt>vector insert()</tt> and
33408<tt>erase()</tt> members. However, 23.2 [container.requirements]p10
33409does not mention 23.2.5.1 [unord.req.except] that specifies exception
33410safety guarantees
33411for unordered containers. In addition, 23.2.5.1 [unord.req.except]p1
33412offers the following guaratee for
33413<tt>erase()</tt>:
33414</p>
33415
33416<blockquote>
33417No <tt>erase()</tt> function throws an exception unless that exception
33418is thrown by the container's Hash or Pred object (if any).
33419</blockquote>
33420
33421<p>
33422Summary:
33423</p>
33424
33425<p>
33426According to 23.2 [container.requirements]p10 no
33427<tt>erase()</tt> function should throw an exception unless otherwise
33428specified. Although does not explicitly mention 23.2.5.1 [unord.req.except], this section offers additional guarantees
33429for unordered containers, allowing <tt>erase()</tt> to throw if
33430predicate or hash function throws.
33431</p>
33432
33433<p>
33434In contrast, associative containers have no exception safety guarantees
33435section so no <tt>erase()</tt> function should throw, <em>including
33436<tt>erase(k)</tt></em> that needs to use the predicate function to
33437perform its work. This means that the predicate of an associative
33438container is not allowed to throw.
33439</p>
33440
33441<p>
33442So:
33443</p>
33444
33445<ol>
33446<li>
33447<tt>erase(k)</tt> for associative containers is not allowed to throw. On
33448the other hand, <tt>erase(k)</tt> for unordered associative containers
33449is allowed to throw.
33450</li>
33451<li>
33452<tt>erase(q)</tt> for associative containers is not allowed to throw. On
33453the other hand, <tt>erase(q)</tt> for unordered associative containers
33454is allowed to throw if it uses the hash or predicate.
33455</li>
33456<li>
33457To fulfill 1), predicates of associative containers are not allowed to throw.
33458Predicates of unordered associative containers are allowed to throw.
33459</li>
33460<li>
334612) breaks a widely used programming pattern (flyweight pattern) for
33462unordered containers, where objects are registered in a global map in
33463their constructors and unregistered in their destructors. If <tt>erase(q)</tt> is
33464allowed to throw, the destructor of the object would need to rethrow the
33465exception or swallow it, leaving the object registered.
33466</li>
33467</ol>
33468
33469
33470<p><b>Proposed resolution:</b></p>
33471<p>
33472Create a new sub-section of 23.2.4 [associative.reqmts] (perhaps [associative.req.except]) titled "Exception
33473safety guarantees".
33474</p>
33475
33476<blockquote>
33477<p>
334781 For associative containers, no <tt>clear()</tt> function throws an exception.
33479<tt>erase(k)</tt> does not throw an exception unless that exception is thrown by
33480the container's Pred object (if any).
33481</p>
33482
33483<p>
334842 For associative containers, if an exception is thrown by any operation
33485from within an <tt>insert()</tt> function inserting a single element, the
33486<tt>insert()</tt> function has no effect.
33487</p>
33488
33489<p>
334903 For associative containers, no <tt>swap</tt> function throws an exception
33491unless that exception is thrown by the copy constructor or copy
33492assignment operator of the container's Pred object (if any).
33493</p>
33494</blockquote>
33495
33496<p>
33497Change 23.2.5.1 [unord.req.except]p1:
33498</p>
33499
33500<blockquote>
33501For unordered associative containers, no <tt>clear()</tt> function
33502throws an exception. <del>No</del> <tt>erase(<ins>k</ins>)</tt>
33503<del>function</del> <ins>does not</ins> throw<del>s</del> an exception
33504unless that exception is thrown by the container's Hash or Pred object
33505(if any).
33506</blockquote>
33507
33508<p>
33509Change 23.2 [container.requirements]p10 to add references to new sections:
33510</p>
33511
33512<blockquote>
33513Unless otherwise specified (see [deque.modifiers]<ins>,</ins>
33514<del>and</del> [vector.modifiers]<ins>, [associative.req.except],
33515[unord.req.except]</ins>) all container types defined in this clause meet
33516the following additional requirements:
33517</blockquote>
33518
33519<p>
33520Change 23.2 [container.requirements]p10 referring to <tt>swap</tt>:
33521</p>
33522
33523<blockquote>
33524<ul>
33525<li>
33526no <tt>swap()</tt> function throws an exception<del> unless that exception is thrown
33527by the copy constructor or assignment operator of the container's
33528Compare object (if any; see [associative.reqmts])</del>.
33529</li>
33530</ul>
33531</blockquote>
33532
33533
33534
33535
33536
33537
33538<hr>
33539<h3><a name="768"></a>768. Typos in [atomics]?</h3>
33540<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>
33541 <b>Submitter:</b> Alberto Ganesh Barbati <b>Opened:</b> 2007-12-28  <b>Last modified:</b> 2008-09-26</p>
33542<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>
33543<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
33544<p><b>Discussion:</b></p>
33545<p>
33546in the latest publicly available draft, paper
33547<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">N2641</a>,
33548in section 29.5.3 [atomics.types.generic], the following specialization of the template
33549<tt>atomic&lt;&gt;</tt> is provided for pointers:
33550</p>
33551
33552<blockquote><pre>template &lt;class T&gt; struct atomic&lt;T*&gt; : atomic_address { 
33553  T* fetch_add(ptrdiff_t, memory_order = memory_order_seq_cst) volatile; 
33554  T* fetch_sub(ptrdiff_t, memory_order = memory_order_seq_cst) volatile; 
33555
33556  atomic() = default; 
33557  constexpr explicit atomic(T); 
33558  atomic(const atomic&amp;) = delete; 
33559  atomic&amp; operator=(const atomic&amp;) = delete; 
33560
33561  T* operator=(T*) volatile; 
33562  T* operator++(int) volatile; 
33563  T* operator--(int) volatile; 
33564  T* operator++() volatile; 
33565  T* operator--() volatile; 
33566  T* operator+=(ptrdiff_t) volatile;
33567  T* operator-=(ptrdiff_t) volatile; 
33568};
33569</pre></blockquote>
33570
33571<p>
33572First of all, there is a typo in the non-default constructor which
33573should take a <tt>T*</tt> rather than a <tt>T</tt>.
33574</p>
33575
33576<p>
33577As you can see, the specialization redefine and therefore hide a few
33578methods from the base class <tt>atomic_address</tt>, namely <tt>fetch_add</tt>, <tt>fetch_sub</tt>,
33579<tt>operator=</tt>, <tt>operator+=</tt> and <tt>operator-=</tt>. That's good, but... what happened
33580to the other methods, in particular these ones:
33581</p>
33582
33583<blockquote><pre>void store(T*, memory_order = memory_order_seq_cst) volatile;
33584T* load( memory_order = memory_order_seq_cst ) volatile;
33585T* swap( T*, memory_order = memory_order_seq_cst ) volatile;
33586bool compare_swap( T*&amp;, T*, memory_order, memory_order ) volatile;
33587bool compare_swap( T*&amp;, T*, memory_order = memory_order_seq_cst ) volatile;
33588</pre></blockquote>
33589
33590<p>
33591By reading paper
33592<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2427.html">N2427 "C++ Atomic Types and Operations"</a>,
33593I see that the
33594definition of the specialization <tt>atomic&lt;T*&gt;</tt> matches the one in the
33595draft, but in the example implementation the methods <tt>load()</tt>, <tt>swap()</tt>
33596and <tt>compare_swap()</tt> are indeed present.
33597</p>
33598
33599<p>
33600Strangely, the example implementation does not redefine the method
33601<tt>store()</tt>. It's true that a <tt>T*</tt> is always convertible to <tt>void*</tt>, but not
33602hiding the <tt>void*</tt> signature from the base class makes the class
33603error-prone to say the least: it lets you assign pointers of any type to
33604a <tt>T*</tt>, without any hint from the compiler.
33605</p>
33606
33607<p>
33608Is there a true intent to remove them from the specialization or are
33609they just missing from the definition because of a mistake?
33610</p>
33611
33612<p><i>[
33613Bellevue:
33614]</i></p>
33615
33616
33617<blockquote>
33618<p>
33619The proposed revisions are accepted.
33620</p>
33621<p>
33622Further discussion: why is the ctor labeled "constexpr"? Lawrence said
33623this permits the object to be statically initialized, and that's
33624important because otherwise there would be a race condition on
33625initialization.
33626</p>
33627</blockquote>
33628
33629
33630<p><b>Proposed resolution:</b></p>
33631<p>
33632Change the synopsis in 29.5.3 [atomics.types.generic]:
33633</p>
33634
33635<blockquote><pre>template &lt;class T&gt; struct atomic&lt;T*&gt; : atomic_address { 
33636  <ins>void store(T*, memory_order = memory_order_seq_cst) volatile;</ins>
33637  <ins>T* load( memory_order = memory_order_seq_cst ) volatile;</ins>
33638  <ins>T* swap( T*, memory_order = memory_order_seq_cst ) volatile;</ins>
33639  <ins>bool compare_swap( T*&amp;, T*, memory_order, memory_order ) volatile;</ins>
33640  <ins>bool compare_swap( T*&amp;, T*, memory_order = memory_order_seq_cst ) volatile;</ins>
33641
33642  T* fetch_add(ptrdiff_t, memory_order = memory_order_seq_cst) volatile; 
33643  T* fetch_sub(ptrdiff_t, memory_order = memory_order_seq_cst) volatile; 
33644
33645  atomic() = default; 
33646  constexpr explicit atomic(T<ins>*</ins>); 
33647  atomic(const atomic&amp;) = delete; 
33648  atomic&amp; operator=(const atomic&amp;) = delete; 
33649
33650  T* operator=(T*) volatile; 
33651  T* operator++(int) volatile; 
33652  T* operator--(int) volatile; 
33653  T* operator++() volatile; 
33654  T* operator--() volatile; 
33655  T* operator+=(ptrdiff_t) volatile;
33656  T* operator-=(ptrdiff_t) volatile; 
33657};
33658</pre></blockquote>
33659
33660
33661
33662
33663
33664
33665<hr>
33666<h3><a name="769"></a>769. std::function should use nullptr_t instead of "unspecified-null-pointer-type"</h3>
33667<p><b>Section:</b> 20.7.15.2 [func.wrap.func] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
33668 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2008-01-10  <b>Last modified:</b> 2008-09-26</p>
33669<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>
33670<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
33671<p><b>Discussion:</b></p>
33672<p>
33673N2461 already replaced in 20.7.15.2 [func.wrap.func] it's originally proposed
33674(implicit) conversion operator to "unspecified-bool-type" by the new
33675explicit bool conversion, but the inverse conversion should also
33676use the new <tt>std::nullptr_t</tt> type instead of "unspecified-null-pointer-
33677type".
33678</p>
33679
33680
33681<p><b>Proposed resolution:</b></p>
33682
33683<p>
33684In 20.7 [function.objects], header <tt>&lt;functional&gt;</tt> synopsis replace:
33685</p>
33686
33687<blockquote><pre>template&lt;class R, class... ArgTypes&gt;
33688  bool operator==(const function&lt;R(ArgTypes...)&gt;&amp;, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
33689template&lt;class R, class... ArgTypes&gt;
33690  bool operator==(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function&lt;R(ArgTypes...)&gt;&amp;);
33691template&lt;class R, class... ArgTypes&gt;
33692  bool operator!=(const function&lt;R(ArgTypes...)&gt;&amp;, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
33693template&lt;class R, class... ArgTypes&gt;
33694  bool operator!=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function&lt;R(ArgTypes...)&gt;&amp;);
33695</pre></blockquote>
33696
33697<p>
33698In the class function synopsis of 20.7.15.2 [func.wrap.func] replace
33699</p>
33700
33701<blockquote><pre>function(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
33702...
33703function&amp; operator=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
33704</pre></blockquote>
33705
33706<p>
33707In 20.7.15.2 [func.wrap.func], "Null pointer comparisons" replace:
33708</p>
33709
33710<blockquote><pre>template &lt;class R, class... ArgTypes&gt;
33711  bool operator==(const function&lt;R(ArgTypes...)&gt;&amp;, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
33712template &lt;class R, class... ArgTypes&gt;
33713  bool operator==(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function&lt;R(ArgTypes...)&gt;&amp;);
33714template &lt;class R, class... ArgTypes&gt;
33715  bool operator!=(const function&lt;R(ArgTypes...)&gt;&amp;, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
33716template &lt;class R, class... ArgTypes&gt;
33717  bool operator!=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function&lt;R(ArgTypes...)&gt;&amp;);
33718</pre></blockquote>
33719
33720<p>
33721In 20.7.15.2.1 [func.wrap.func.con], replace
33722</p>
33723
33724<blockquote><pre>function(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
33725...
33726function&amp; operator=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
33727</pre></blockquote>
33728
33729<p>
33730In 20.7.15.2.6 [func.wrap.func.nullptr], replace
33731</p>
33732
33733<blockquote><pre>template &lt;class R, class... ArgTypes&gt;
33734  bool operator==(const function&lt;R(ArgTypes...)&gt;&amp; f, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
33735template &lt;class R, class... ArgTypes&gt;
33736  bool operator==(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function&lt;R(ArgTypes...)&gt;&amp; f);
33737</pre></blockquote>
33738
33739<p>
33740and replace
33741</p>
33742
33743<blockquote><pre>template &lt;class R, class... ArgTypes&gt;
33744  bool operator!=(const function&lt;R(ArgTypes...)&gt;&amp; f, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
33745template &lt;class R, class... ArgTypes&gt;
33746  bool operator!=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function&lt;R(ArgTypes...)&gt;&amp; f);
33747</pre></blockquote>
33748
33749
33750
33751
33752
33753
33754<hr>
33755<h3><a name="770"></a>770. std::function should use rvalue swap</h3>
33756<p><b>Section:</b> 20.7.15 [func.wrap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
33757 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2008-01-10  <b>Last modified:</b> 2008-09-26</p>
33758<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
33759<p><b>Discussion:</b></p>
33760<p>
33761It is expected that typical implementations of <tt>std::function</tt> will
33762use dynamic memory allocations at least under given conditions,
33763so it seems appropriate to change the current lvalue swappabilty of
33764this class to rvalue swappability.
33765</p>
33766
33767
33768<p><b>Proposed resolution:</b></p>
33769<p>
33770In 20.7 [function.objects], header <tt>&lt;functional&gt;</tt> synopsis, just below of
33771</p>
33772
33773<blockquote><pre>template&lt;class R, class... ArgTypes&gt;
33774  void swap(function&lt;R(ArgTypes...)&gt;&amp;, function&lt;R(ArgTypes...)&gt;&amp;);
33775<ins>template&lt;class R, class... ArgTypes&gt;
33776  void swap(function&lt;R(ArgTypes...)&gt;&amp;&amp;, function&lt;R(ArgTypes...)&gt;&amp;);
33777template&lt;class R, class... ArgTypes&gt;
33778  void swap(function&lt;R(ArgTypes...)&gt;&amp;, function&lt;R(ArgTypes...)&gt;&amp;&amp;);</ins>
33779</pre></blockquote>
33780
33781<p>
33782In 20.7.15.2 [func.wrap.func] class <tt>function</tt> definition, change
33783</p>
33784
33785<blockquote><pre>void swap(function&amp;<ins>&amp;</ins>);
33786</pre></blockquote>
33787
33788<p>
33789In 20.7.15.2 [func.wrap.func], just below of
33790</p>
33791
33792<blockquote><pre>template &lt;class R, class... ArgTypes&gt;
33793  void swap(function&lt;R(ArgTypes...)&gt;&amp;, function&lt;R(ArgTypes...)&gt;&amp;);
33794<ins>template &lt;class R, class... ArgTypes&gt;
33795  void swap(function&lt;R(ArgTypes...)&gt;&amp;&amp;, function&lt;R(ArgTypes...)&gt;&amp;);
33796template &lt;class R, class... ArgTypes&gt;
33797  void swap(function&lt;R(ArgTypes...)&gt;&amp;, function&lt;R(ArgTypes...)&gt;&amp;&amp;);</ins>
33798</pre></blockquote>
33799
33800<p>
33801In 20.7.15.2.2 [func.wrap.func.mod] change
33802</p>
33803
33804<blockquote><pre>void swap(function&amp;<ins>&amp;</ins> other);
33805</pre></blockquote>
33806
33807<p>
33808In 20.7.15.2.7 [func.wrap.func.alg] add the two overloads
33809</p>
33810
33811<blockquote><pre><ins>template&lt;class R, class... ArgTypes&gt;
33812  void swap(function&lt;R(ArgTypes...)&gt;&amp;&amp; f1, function&lt;R(ArgTypes...)&gt;&amp; f2);
33813template&lt;class R, class... ArgTypes&gt;
33814  void swap(function&lt;R(ArgTypes...)&gt;&amp; f1, function&lt;R(ArgTypes...)&gt;&amp;&amp; f2);</ins>
33815</pre></blockquote>
33816
33817
33818
33819
33820
33821
33822<hr>
33823<h3><a name="771"></a>771. Impossible throws clause in [string.conversions]</h3>
33824<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>
33825 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2008-01-13  <b>Last modified:</b> 2008-09-26</p>
33826<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>
33827<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
33828<p><b>Discussion:</b></p>
33829<p>
33830The new <tt>to_string</tt> and <tt>to_wstring</tt> functions described in 21.5 [string.conversions]
33831have throws clauses (paragraphs 8 and 16) which say:
33832</p>
33833
33834<blockquote>
33835<i>Throws:</i> nothing
33836</blockquote>
33837
33838<p>
33839Since all overloads return either a <tt>std::string</tt> or a <tt>std::wstring</tt> by value
33840this throws clause is impossible to realize in general, since the <tt>basic_string</tt>
33841constructors can fail due to out-of-memory conditions. Either these throws
33842clauses should be removed or should be more detailled like:
33843</p>
33844
33845<blockquote>
33846<i>Throws:</i> Nothing if the string construction throws nothing
33847</blockquote>
33848
33849<p>
33850Further there is an editorial issue in p. 14: All three <tt>to_wstring</tt>
33851overloads return a <tt>string</tt>, which should be <tt>wstring</tt> instead (The
33852header <tt>&lt;string&gt;</tt> synopsis of 21.3 [string.classes] is correct in this
33853regard).
33854</p>
33855
33856
33857
33858<p><b>Proposed resolution:</b></p>
33859<p>
33860In 21.5 [string.conversions], remove the paragraphs 8 and 16.
33861</p>
33862
33863<blockquote>
33864<pre>string to_string(long long val); 
33865string to_string(unsigned long long val); 
33866string to_string(long double val); 
33867</pre>
33868<blockquote>
33869<del><i>Throws:</i> nothing</del>
33870</blockquote>
33871</blockquote>
33872
33873<blockquote>
33874<pre><ins>w</ins>string to_wstring(long long val); 
33875<ins>w</ins>string to_wstring(unsigned long long val); 
33876<ins>w</ins>string to_wstring(long double val); 
33877</pre>
33878<blockquote>
33879<del><i>Throws:</i> nothing</del>
33880</blockquote>
33881</blockquote>
33882
33883
33884
33885
33886
33887
33888<hr>
33889<h3><a name="772"></a>772.  Impossible return clause in [string.conversions]</h3>
33890<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>
33891 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2008-01-13  <b>Last modified:</b> 2008-09-26</p>
33892<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>
33893<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
33894<p><b>Discussion:</b></p>
33895<p>
33896The return clause 21.5 [string.conversions]/paragraph 15 of the new <tt>to_wstring</tt>
33897overloads says:
33898</p>
33899
33900<blockquote>
33901<i>Returns:</i> each function returns a <tt>wstring</tt> object holding the character
33902representation of the value of its argument that would be generated by
33903calling <tt>wsprintf(buf, fmt, val)</tt> with a format specifier of <tt>L"%lld"</tt>, <tt>L"%ulld"</tt>,
33904or <tt>L"%f"</tt>, respectively.
33905</blockquote>
33906
33907<p>
33908Problem is: There does not exist any <tt>wsprintf</tt> function in C99 (I checked
33909the 2nd edition of ISO 9899, and the first and the second corrigenda from
339102001-09-01 and 2004-11-15). What probably meant here is the function
33911<tt>swprintf</tt> from <tt>&lt;wchar.h&gt;/&lt;cwchar&gt;</tt>, but this has the non-equivalent
33912declaration:
33913</p>
33914
33915<blockquote><pre>int swprintf(wchar_t * restrict s, size_t n,
33916const wchar_t * restrict format, ...);
33917</pre></blockquote>
33918
33919<p>
33920therefore the paragraph needs to mention the <tt>size_t</tt> parameter <tt>n</tt>.
33921</p>
33922
33923
33924
33925<p><b>Proposed resolution:</b></p>
33926<p>
33927Change the current wording of 21.5 [string.conversions]/p. 15 to:
33928</p>
33929
33930<blockquote>
33931<i>Returns:</i> <del>e</del><ins>E</ins>ach function returns a
33932<tt>wstring</tt> object holding the character representation of the
33933value of its argument that would be generated by calling
33934<tt><del>ws</del><ins>sw</ins>printf(buf, <ins>bufsz,</ins> fmt,
33935val)</tt> with a format specifier <ins><tt>fmt</tt></ins> of <tt>L"%lld"</tt>,
33936<tt>L"%ulld"</tt>, or <tt>L"%f"</tt>, respectively<ins>, where <tt>buf</tt>
33937designates an internal character buffer of sufficient size <tt>bufsz</tt></ins>.
33938</blockquote>
33939
33940<p>
33941[Hint to the editor: The resolution also adds to mention the name of
33942the format specifier "fmt"]
33943</p>
33944
33945<p>
33946I also would like to remark that the current wording of it's equivalent
33947paragraph 7 should also mention the meaning of <tt>buf</tt> and <tt>fmt</tt>.
33948</p>
33949
33950<p>
33951Change the current wording of 21.5 [string.conversions]/p. 7 to:
33952</p>
33953
33954<blockquote>
33955<i>Returns:</i> <del>e</del><ins>E</ins>ach function returns a string object holding the
33956character representation of the value of its argument that would be
33957generated by calling <tt>sprintf(buf, fmt, val)</tt> with a format specifier <ins><tt>fmt</tt></ins> of
33958<tt>"%lld"</tt>, <tt>"%ulld"</tt>, or <tt>"%f"</tt>, respectively<ins>, where <tt>buf</tt> designates an internal
33959character buffer of sufficient size</ins>.
33960</blockquote>
33961
33962
33963
33964
33965
33966
33967<hr>
33968<h3><a name="775"></a>775. Tuple indexing should be unsigned?</h3>
33969<p><b>Section:</b> 20.5.2.5 [tuple.helper] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
33970 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-01-16  <b>Last modified:</b> 2008-09-26</p>
33971<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>
33972<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>
33973<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
33974<p><b>Discussion:</b></p>
33975<p>
33976The tuple element access API identifies the element in the sequence
33977using signed integers, and then goes on to enforce the requirement that
33978I be &gt;= 0.  There is a much easier way to do this - declare I as
33979<tt>unsigned</tt>.
33980</p>
33981<p>
33982In fact the proposal is to use <code>std::size_t</code>, matching the type used in the <tt>tuple_size</tt> API.
33983</p>
33984<p>
33985A second suggestion is that it is hard to imagine an API that deduces
33986and index at compile time and returns a reference throwing an exception.
33987Add a specific <em>Throws:</em> Nothing paragraph to each element
33988access API.
33989</p>
33990<p>
33991In addition to <code>tuple</code>, update the API applies to
33992<code>pair</code> and <code>array</code>, and should be updated
33993accordingly.
33994</p>
33995
33996<p>
33997A third observation is that the return type of the <code>get</code>
33998functions for <code>std::pair</code> is pseudo-code, but it is not
33999clearly marked as such.  There is actually no need for pseudo-code as
34000the return type can be specified precisely with a call to
34001<code>tuple_element</code>.  This is already done for
34002<code>std::tuple</code>, and <code>std::array</code> does not have a
34003problem as all elements are of type <code>T</code>.
34004</p>
34005
34006
34007<p><b>Proposed resolution:</b></p>
34008<p>
34009Update header &lt;utility&gt; synopsis in 20.3 [utility]
34010</p>
34011<pre><em>// 20.2.3, tuple-like access to pair:</em>
34012template &lt;class T&gt; class tuple_size;
34013template &lt;<del>int</del><ins>size_t</ins> I, class T&gt; class tuple_element;
34014
34015template &lt;class T1, class T2&gt; struct tuple_size&lt;std::pair&lt;T1, T2&gt; &gt;;
34016template &lt;class T1, class T2&gt; struct tuple_element&lt;0, std::pair&lt;T1, T2&gt; &gt;;
34017template &lt;class T1, class T2&gt; struct tuple_element&lt;1, std::pair&lt;T1, T2&gt; &gt;;
34018
34019template&lt;<del>int</del><ins>size_t</ins> I, class T1, class T2&gt;
34020  <del>P</del><ins>typename tuple_element&lt;I, std::pair&lt;T1, T2&gt; &gt;::type </ins>&amp; get(std::pair&lt;T1, T2&gt;&amp;);
34021template&lt;<del>int</del><ins>size_t</ins> I, class T1, class T2&gt;
34022  const <del>P</del><ins>typename tuple_element&lt;I, std::pair&lt;T1, T2&gt; &gt;::type </ins>&amp; get(const std::pair&lt;T1, T2&gt;&amp;);
34023</pre>
34024<p>
34025Update <strong>20.3.4 [pairs] Pairs</strong>
34026</p>
34027<pre>template&lt;<del>int</del><ins>size_t</ins> I, class T1, class T2&gt;
34028  <del>P</del><ins>typename tuple_element&lt;I, std::pair&lt;T1, T2&gt; &gt;::type </ins>&amp; get(pair&lt;T1, T2&gt;&amp;);
34029template&lt;<del>int</del><ins>size_t</ins> I, class T1, class T2&gt;
34030  const <del>P</del><ins>typename tuple_element&lt;I, std::pair&lt;T1, T2&gt; &gt;::type </ins>&amp; get(const pair&lt;T1, T2&gt;&amp;);
34031</pre>
34032<p>
34033<del>24 <em>Return type:</em> If <code>I == 0</code> then <code>P</code> is <code>T1</code>, if <code>I == 1</code> then <code>P</code> is <code>T2</code>, and otherwise the program is ill-formed.</del>
34034</p>
34035<p>
3403625 <em>Returns:</em> If <code>I == 0</code> returns <code>p.first</code>, <del>otherwise</del> <ins>if <code>I == 1</code></ins> returns <code>p.second</code><ins>, and otherwise the program is ill-formed</ins>.
34037</p>
34038<p>
34039<ins><em>Throws:</em> Nothing.</ins>
34040</p>
34041
34042
34043<p>
34044Update header &lt;tuple&gt; synopsis in 20.5 [tuple] with a APIs as below:
34045</p>
34046<pre>template &lt;<del>int</del><ins>size_t</ins> I, class T&gt; class tuple_element; <em>// undefined</em>
34047template &lt;<del>int</del><ins>size_t</ins> I, class... Types&gt; class tuple_element&lt;I, tuple&lt;Types...&gt; &gt;;
34048
34049<em>// 20.3.1.4, element access:</em>
34050template &lt;<del>int</del><ins>size_t</ins> I, class... Types&gt;
34051  typename tuple_element&lt;I, tuple&lt;Types...&gt; &gt;::type&amp; get(tuple&lt;Types...&gt;&amp;);
34052template &lt;<del>int</del><ins>size_t</ins> I, class ... types&gt;
34053  typename tuple_element&lt;I, tuple&lt;Types...&gt; &gt;::type const&amp; get(const tuple&lt;Types...&gt;&amp;);
34054</pre>
34055
34056<p>
34057Update <strong>20.5.2.5 [tuple.helper] Tuple helper classes</strong>
34058</p>
34059<pre>template &lt;<del>int</del><ins>size_t</ins> I, class... Types&gt;
34060class tuple_element&lt;I, tuple&lt;Types...&gt; &gt; {
34061public:
34062  typedef TI type;
34063};</pre>
34064<p>
340651 <em>Requires:</em> <code><del>0 &lt;= I and </del>I &lt; sizeof...(Types)</code>. The program is ill-formed if <code>I</code> is out of bounds.
34066</p>
34067<p>
340682 <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.
34069</p>
34070<p>
34071Update <strong>20.5.2.6 [tuple.elem] Element access</strong>
34072</p>
34073<pre>template &lt;<del>int</del><ins>size_t</ins> I, class... types &gt;
34074typename tuple_element&lt;I, tuple&lt;Types...&gt; &gt;::type&amp; get(tuple&lt;Types...&gt;&amp; t);
34075</pre>
340761 <em>Requires:</em> <code><del>0 &lt;= I and </del>I &lt; sizeof...(Types)</code>. The program is ill-formed if <code>I</code> is out of bounds.
34077<p>
340782 <em>Returns:</em> A reference to the <code>I</code>th element of <code>t</code>, where indexing is zero-based.
34079</p>
34080<ins><em>Throws:</em> Nothing.</ins>
34081<pre>template &lt;<del>int</del><ins>size_t</ins> I, class... types&gt;
34082typename tuple_element&lt;I, tuple&lt;Types...&gt; &gt;::type const&amp; get(const tuple&lt;Types...&gt;&amp; t);
34083</pre>
34084<p>
340853 <em>Requires:</em> <code><del>0 &lt;= I and </del>I &lt; sizeof...(Types)</code>. The program is ill-formed if <code>I</code> is out of bounds.
34086</p>
34087<p>
340884 <em>Returns:</em> A const reference to the <code>I</code>th element of <code>t</code>, where indexing is zero-based.
34089</p>
34090<p>
34091<ins><em>Throws:</em> Nothing.</ins>
34092</p>
34093
34094
34095<p>
34096Update header &lt;array&gt; synopsis in 20.3 [utility]
34097</p>
34098<pre>template &lt;class T&gt; class tuple_size; <em>// forward declaration</em>
34099template &lt;<del>int</del><ins>size_t</ins> I, class T&gt; class tuple_element; <em>// forward declaration</em>
34100template &lt;class T, size_t N&gt;
34101  struct tuple_size&lt;array&lt;T, N&gt; &gt;;
34102template &lt;<del>int</del><ins>size_t</ins> I, class T, size_t N&gt;
34103  struct tuple_element&lt;I, array&lt;T, N&gt; &gt;;
34104template &lt;<del>int</del><ins>size_t</ins> I, class T, size_t N&gt;
34105  T&amp; get(array&lt;T, N&gt;&amp;);
34106template &lt;<del>int</del><ins>size_t</ins> I, class T, size_t N&gt;
34107  const T&amp; get(const array&lt;T, N&gt;&amp;);
34108</pre>
34109
34110<p>
34111Update <strong>23.3.1.7 [array.tuple] Tuple interface to class template array</strong>
34112</p>
34113<pre>tuple_element&lt;<ins>size_t </ins>I, array&lt;T, N&gt; &gt;::type
34114</pre>
34115<p>
341163 <em>Requires:</em> <code><del>0 &lt;= </del>I &lt; N.</code> The program is ill-formed if <code>I</code> is out of bounds.
34117</p>
34118<p>
341194 <em>Value:</em> The type <code>T</code>.
34120</p>
34121<pre>template &lt;<del>int</del><ins>size_t</ins> I, class T, size_t N&gt; T&amp; get(array&lt;T, N&gt;&amp; a);
34122</pre>
34123<p>
341245 <em>Requires:</em> <code><del>0 &lt;= </del>I &lt; N</code>. The program is ill-formed if <code>I</code> is out of bounds.
34125</p>
34126<p>
34127<em>Returns:</em> A reference to the <code>I</code>th element of <code>a</code>, where indexing is zero-based.
34128</p>
34129<p>
34130<ins><em>Throws:</em> Nothing.</ins>
34131</p>
34132<pre>template &lt;<del>int</del><ins>size_t</ins> I, class T, size_t N&gt; const T&amp; get(const array&lt;T, N&gt;&amp; a);
34133</pre>
34134<p>
341356 <em>Requires:</em> <code><del>0 &lt;= </del>I &lt; N</code>. The program is ill-formed if <code>I</code> is out of bounds.
34136</p>
34137<p>
341387 <em>Returns:</em> A const reference to the <code>I</code>th element of <code>a</code>, where indexing is zero-based.
34139</p>
34140<p>
34141<ins><em>Throws:</em> Nothing.</ins>
34142</p>
34143
34144
34145<p><i>[
34146Bellevue: Note also that the phrase "The program is ill-formed if I is
34147out of bounds" in the requires clauses are probably unnecessary, and
34148could be removed at the editor's discretion. Also std:: qualification
34149for pair is also unnecessary.
34150]</i></p>
34151
34152
34153
34154
34155<hr>
34156<h3><a name="776"></a>776. Undescribed assign function of std::array</h3>
34157<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>
34158 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2008-01-20  <b>Last modified:</b> 2008-09-26</p>
34159<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>
34160<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
34161<p><b>Discussion:</b></p>
34162<p>
34163The class template array synopsis in 23.3.1 [array]/3 declares a member
34164function
34165</p>
34166
34167<blockquote><pre>void assign(const T&amp; u);
34168</pre></blockquote>
34169
34170<p>
34171which's semantic is no-where described. Since this signature is
34172not part of the container requirements, such a semantic cannot
34173be derived by those.
34174</p>
34175
34176<p>
34177I found only one reference to this function in the issue list,
34178<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#588">588</a> where the question is raised:
34179</p>
34180
34181<blockquote>
34182what's the effect of calling <tt>assign(T&amp;)</tt> on a zero-sized array?
34183</blockquote>
34184
34185<p>
34186which does not answer the basic question of this issue.
34187</p>
34188
34189<p>
34190If this function shall be part of the <tt>std::array</tt>, it's probable
34191semantic should correspond to that of <tt>boost::array</tt>, but of
34192course such wording must be added.
34193</p>
34194
34195
34196<p><b>Proposed resolution:</b></p>
34197<p>
34198Just after the section 23.3.1.4 [array.data] add the following new section:
34199</p>
34200
34201<p>
3420223.2.1.5 array::fill [array.fill]
34203</p>
34204
34205<blockquote>
34206<pre>void fill(const T&amp; u);
34207</pre>
34208
34209<p>
342101: <i>Effects:</i> <tt>fill_n(begin(), N, u)</tt>
34211</p>
34212</blockquote>
34213
34214<p>
34215[N.B: I wonder, why class <tt>array</tt> does not have a "modifiers"
34216section. If it had, then <tt>assign</tt> would naturally belong to it]
34217</p>
34218
34219<p>
34220Change the synopsis in 23.3.1 [array]/3:
34221</p>
34222
34223<blockquote><pre>template &lt;class T, size_t N&gt;
34224struct array { 
34225  ...
34226  void <del>assign</del> <ins>fill</ins>(const T&amp; u);
34227  ...
34228</pre></blockquote>
34229
34230
34231<p><i>[
34232Bellevue:
34233]</i></p>
34234
34235
34236<blockquote>
34237<p>
34238Suggest substituting "fill" instead of "assign".
34239</p>
34240<p>
34241Set state to Review given substitution of "fill" for "assign".
34242</p>
34243</blockquote>
34244
34245
34246
34247
34248<hr>
34249<h3><a name="777"></a>777. Atomics Library Issue</h3>
34250<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>
34251 <b>Submitter:</b> Lawrence Crowl <b>Opened:</b> 2008-01-21  <b>Last modified:</b> 2008-09-26</p>
34252<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>
34253<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
34254<p><b>Discussion:</b></p>
34255<p>
34256The load functions are defined as
34257</p>
34258
34259<blockquote><pre>C atomic_load(volatile A* object);
34260C atomic_load_explicit(volatile A* object, memory_order);
34261C A::load(memory_order order = memory_order_seq_cst) volatile;
34262</pre></blockquote>
34263
34264<p>
34265which prevents their use in <tt>const</tt> contexts.
34266</p>
34267
34268<p><i>[
34269post Bellevue Peter adds:
34270]</i></p>
34271
34272
34273<blockquote>
34274<p>
34275Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a> suggests making <tt>atomic_load</tt> operate on <tt>const</tt> objects. There is a
34276subtle point here. Atomic loads do not generally write to the object, except
34277potentially for the <tt>memory_order_seq_cst</tt> constraint. Depending on the
34278architecture, a dummy write with the same value may be required to be issued
34279by the atomic load to maintain sequential consistency. This, in turn, may
34280make the following code:
34281</p>
34282
34283<blockquote><pre>const atomic_int x{};
34284
34285int main()
34286{
34287  x.load();
34288}
34289</pre></blockquote>
34290
34291<p>
34292dump core under a straightforward implementation that puts const objects in
34293a read-only section.
34294</p>
34295<p>
34296There are ways to sidestep the problem, but it needs to be considered.
34297</p>
34298<p>
34299The tradeoff is between making the data member of the atomic types
34300mutable and requiring the user to explicitly mark atomic members as
34301mutable, as is already the case with mutexes.
34302</p>
34303</blockquote>
34304
34305
34306
34307<p><b>Proposed resolution:</b></p>
34308<p>
34309Add the <tt>const</tt> qualifier to <tt>*object</tt> and <tt>*this</tt>.
34310</p>
34311
34312<blockquote><pre>C atomic_load(<ins>const</ins> volatile A* object);
34313C atomic_load_explicit(<ins>const</ins> volatile A* object, memory_order);
34314C A::load(memory_order order = memory_order_seq_cst) <ins>const</ins> volatile;
34315</pre></blockquote>
34316
34317
34318
34319
34320
34321
34322<hr>
34323<h3><a name="778"></a>778. std::bitset does not have any constructor taking a string literal</h3>
34324<p><b>Section:</b> 20.3.7.1 [bitset.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
34325 <b>Submitter:</b> Thorsten Ottosen <b>Opened:</b> 2008-01-24  <b>Last modified:</b> 2008-09-26</p>
34326<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>
34327<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
34328<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#116">116</a></p>
34329<p><b>Discussion:</b></p>
34330<p>
34331A small issue with <tt>std::bitset</tt>: it does not have any constructor
34332taking a string literal, which is clumsy and looks like an oversigt when
34333we tried to enable uniform use of <tt>string</tt> and <tt>const char*</tt> in the library.
34334</p>
34335
34336<p>
34337Suggestion: Add
34338</p>
34339
34340<blockquote><pre>explicit bitset( const char* str );
34341</pre></blockquote>
34342
34343<p>
34344to std::bitset.
34345</p>
34346
34347
34348<p><b>Proposed resolution:</b></p>
34349<p>
34350Add to synopsis in 20.3.7 [template.bitset]
34351</p>
34352
34353<blockquote><pre>explicit bitset( const char* str );
34354</pre></blockquote>
34355
34356<p>
34357Add to synopsis in 20.3.7.1 [bitset.cons]
34358</p>
34359
34360<blockquote><pre>explicit bitset( const char* str );
34361</pre>
34362<p>
34363<i>Effects:</i> Constructs a <tt>bitset</tt> as if <tt>bitset(string(str))</tt>.
34364</p>
34365</blockquote>
34366
34367
34368
34369
34370
34371
34372<hr>
34373<h3><a name="779"></a>779. Resolution of #283 incomplete</h3>
34374<p><b>Section:</b> 25.3.8 [alg.remove] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
34375 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2008-01-25  <b>Last modified:</b> 2008-09-26</p>
34376<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>
34377<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
34378<p><b>Discussion:</b></p>
34379<p>
34380The 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
34381<tt>remove_copy[_if]</tt>,
34382which seems to be an oversight.
34383</p>
34384
34385
34386<p><b>Proposed resolution:</b></p>
34387<p>
34388In 25.3.8 [alg.remove]/p.6, replace the N2461 requires clause with:
34389</p>
34390
34391<blockquote>
34392<i>Requires:</i> <del>Type <tt>T</tt> is <tt>EqualityComparable</tt> (31).</del> The ranges <tt>[first,last)</tt>
34393and <tt>[result,result + (last - first))</tt> shall not overlap. <ins>The expression <tt>*result = *first</tt> shall be
34394valid.</ins>
34395</blockquote>
34396
34397
34398
34399
34400
34401
34402<hr>
34403<h3><a name="781"></a>781. <tt>std::complex</tt> should add missing C99 functions</h3>
34404<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>
34405 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2008-01-26  <b>Last modified:</b> 2009-03-21</p>
34406<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>
34407<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
34408<p><b>Discussion:</b></p>
34409<p>
34410A comparision of the N2461 header <tt>&lt;complex&gt;</tt> synopsis ([complex.syn])
34411with the C99 standard (ISO 9899, 2nd edition and the two corrigenda) show
34412some complex functions that are missing in C++. These are:
34413</p>
34414
34415<ol>
34416<li>
344177.3.9.4: (required elements of the C99 library)<br>
34418The <tt>cproj</tt> functions
34419</li>
34420<li>
344217.26.1: (optional elements of the C99 library)<br>
34422<pre>cerf    cerfc    cexp2
34423cexpm1  clog10   clog1p
34424clog2   clgamma  ctgamma
34425</pre>
34426</li>
34427</ol>
34428
34429<p>
34430I propose that at least the required <tt>cproj</tt> overloads are provided as equivalent
34431C++ functions. This addition is easy to do in one sentence (delegation to C99
34432function).
34433</p>
34434
34435<p>
34436Please note also that the current entry <tt>polar</tt>
34437in 26.4.9 [cmplx.over]/1
34438should be removed from the mentioned overload list. It does not make sense to require that a
34439function already expecting <em>scalar</em> arguments
34440should cast these arguments into corresponding
34441<tt>complex&lt;T&gt;</tt> arguments, which are not accepted by
34442this function.
34443</p>
34444
34445
34446<p><b>Proposed resolution:</b></p>
34447<p>
34448In 26.4.1 [complex.syn] add just between the declaration of <tt>conj</tt> and <tt>fabs</tt>:
34449</p>
34450
34451<blockquote><pre>template&lt;class T&gt; complex&lt;T&gt; conj(const complex&lt;T&gt;&amp;);
34452<ins>template&lt;class T&gt; complex&lt;T&gt; proj(const complex&lt;T&gt;&amp;);</ins>
34453template&lt;class T&gt; complex&lt;T&gt; fabs(const complex&lt;T&gt;&amp;);
34454</pre></blockquote>
34455
34456<p>
34457In 26.4.7 [complex.value.ops] just after p.6 (return clause of <tt>conj</tt>) add:
34458</p>
34459
34460<blockquote>
34461<pre>template&lt;class T&gt; complex&lt;T&gt; proj(const complex&lt;T&gt;&amp; x);
34462</pre>
34463<blockquote>
34464
34465<i>Effects:</i> Behaves the same as C99 function <tt>cproj</tt>, defined in
34466subclause 7.3.9.4."
34467</blockquote>
34468</blockquote>
34469
34470<p>
34471In 26.4.9 [cmplx.over]/1, add one further entry <tt>proj</tt> to
34472the overload list.
34473</p>
34474
34475<blockquote>
34476<p>
34477The following function templates shall have additional overloads:
34478</p>
34479<blockquote><pre>arg           norm 
34480conj          <del>polar</del> <ins>proj</ins>
34481imag          real
34482</pre></blockquote>
34483</blockquote>
34484
34485
34486
34487
34488
34489
34490<hr>
34491<h3><a name="782"></a>782. Extended <tt>seed_seq</tt> constructor is useless</h3>
34492<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>
34493 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2008-01-27  <b>Last modified:</b> 2009-05-01</p>
34494<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>
34495<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
34496<p><b>Discussion:</b></p>
34497<p>
34498Part of the resolution of n2423, issue 8 was the proposal to
34499extend the <tt>seed_seq</tt> constructor accepting an input range
34500as follows (which is now part of N2461):
34501</p>
34502
34503<blockquote><pre>template&lt;class InputIterator,
34504size_t u = numeric_limits&lt;iterator_traits&lt;InputIterator&gt;::value_type&gt;::digits&gt;
34505seed_seq(InputIterator begin, InputIterator end);
34506</pre></blockquote>
34507
34508<p>
34509First, the expression <tt>iterator_traits&lt;InputIterator&gt;::value_type</tt>
34510is invalid due to missing <tt>typename</tt> keyword, which is easy to
34511fix.
34512</p>
34513
34514<p>
34515Second (and worse), while the language now supports default
34516template arguments of function templates, this customization
34517point via the second <tt>size_t</tt> template parameter is of no advantage,
34518because <tt>u</tt> can never be deduced, and worse - because it is a
34519constructor function template - it can also never be explicitly
34520provided (14.9.1 [temp.arg.explicit]/7).
34521</p>
34522
34523<p>
34524The question arises, which advantages result from a compile-time
34525knowledge of <tt>u</tt> versus a run time knowledge? If run time knowledge
34526suffices, this parameter should be provided as normal function
34527default argument [Resolution marked (A)], if compile-time knowledge
34528is important, this could be done via a tagging template or more
34529user-friendly via a standardized helper generator function
34530(<tt>make_seed_seq</tt>), which allows this [Resolution marked (B)].
34531</p>
34532
34533<p><i>[
34534Bellevue:
34535]</i></p>
34536
34537
34538<blockquote>
34539<p>
34540Fermilab does not have a strong opinion. Would prefer to go with
34541solution A. Bill agrees that solution A is a lot simpler and does the
34542job.
34543</p>
34544<p>
34545Proposed Resolution: Accept Solution A.
34546</p>
34547</blockquote>
34548
34549<p>
34550Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#803">803</a> claims to make this issue moot.
34551</p>
34552
34553
34554
34555<p><b>Proposed resolution:</b></p>
34556<ol type="A">
34557<li>
34558<p>
34559In 26.5.7.1 [rand.util.seedseq]/2, class <tt>seed_seq</tt> synopsis replace:
34560</p>
34561
34562<blockquote><pre>class seed_seq 
34563{ 
34564public:
34565   ...
34566   template&lt;class InputIterator<del>,
34567      size_t u = numeric_limits&lt;iterator_traits&lt;InputIterator&gt;::value_type&gt;::digits</del>&gt;
34568          seed_seq(InputIterator begin, InputIterator end<ins>,
34569          size_t u = numeric_limits&lt;typename iterator_traits&lt;InputIterator&gt;::value_type&gt;::digits</ins>);
34570   ...
34571};
34572</pre></blockquote>
34573
34574<p>
34575and do a similar replacement in the member description between
34576p.3 and p.4.
34577</p>
34578</li>
34579
34580<li>
34581<p>
34582In 26.5.7.1 [rand.util.seedseq]/2, class <tt>seed_seq</tt> synopsis <em>and</em> in the
34583member description between p.3 and p.4 replace:
34584</p>
34585
34586<blockquote><pre>template&lt;class InputIterator<del>,
34587  size_t u = numeric_limits&lt;iterator_traits&lt;InputIterator&gt;::value_type&gt;::digits</del>&gt;
34588      seed_seq(InputIterator begin, InputIterator end);
34589<ins>template&lt;class InputIterator, size_t u&gt;
34590seed_seq(InputIterator begin, InputIterator end, <i>implementation-defined</i> s);</ins>
34591</pre></blockquote>
34592
34593<p>
34594In 26.5.1 [rand.synopsis], header <tt>&lt;random&gt;</tt> synopsis, immediately after the
34595class <tt>seed_seq</tt> declaration <em>and</em> in 26.5.7.1 [rand.util.seedseq]/2, immediately
34596after the class <tt>seed_seq</tt> definition add:
34597</p>
34598
34599<blockquote><pre>template&lt;size_t u, class InputIterator&gt;
34600  seed_seq make_seed_seq(InputIterator begin, InputIterator end);
34601</pre></blockquote>
34602
34603<p>
34604In 26.5.7.1 [rand.util.seedseq], just before p.5 insert two paragraphs:
34605</p>
34606
34607<blockquote>
34608<p>
34609The first constructor behaves as if it would provide an
34610integral constant expression <tt>u</tt> of type <tt>size_t</tt> of value
34611<tt>numeric_limits&lt;typename iterator_traits&lt;InputIterator&gt;::value_type&gt;::digits</tt>.
34612</p>
34613<p>
34614The second constructor uses an implementation-defined mechanism
34615to provide an integral constant expression <tt>u</tt> of type <tt>size_t</tt> and
34616is called by the function <tt>make_seed_seq</tt>.
34617</p>
34618</blockquote>
34619
34620<p>
34621In 26.5.7.1 [rand.util.seedseq], just after the last paragraph add:
34622</p>
34623
34624<blockquote>
34625<pre>template&lt;size_t u, class InputIterator&gt;
34626   seed_seq make_seed_seq(InputIterator begin, InputIterator end);
34627</pre>
34628<blockquote>
34629<p>
34630where <tt>u</tt> is used to construct an object <tt>s</tt> of implementation-defined type.
34631</p>
34632<p>
34633<i>Returns:</i> <tt>seed_seq(begin, end, s)</tt>;
34634</p>
34635</blockquote>
34636</blockquote>
34637
34638</li>
34639</ol>
34640
34641
34642
34643
34644
34645
34646<hr>
34647<h3><a name="783"></a>783. <tt>thread::id</tt> reuse</h3>
34648<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>
34649 <b>Submitter:</b> Hans Boehm <b>Opened:</b> 2008-02-01  <b>Last modified:</b> 2008-09-26</p>
34650<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>
34651<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
34652<p><b>Discussion:</b></p>
34653<p>
34654The current working paper 
34655(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2497.html">N2497</a>,
34656integrated just before Bellevue) is
34657not completely clear whether a given <tt>thread::id</tt> value may be reused once
34658a thread has exited and has been joined or detached.  Posix allows
34659thread ids (<tt>pthread_t</tt> values) to be reused in this case.  Although it is
34660not completely clear whether this originally was the right decision, it
34661is clearly the established practice, and we believe it was always the
34662intent of the C++ threads API to follow Posix and allow this.  Howard
34663Hinnant's example implementation implicitly relies on allowing reuse
34664of ids, since it uses Posix thread ids directly.
34665</p>
34666
34667<p>
34668It is important to be clear on this point, since it the reuse of thread
34669ids often requires extra care in client code, which would not be
34670necessary if thread ids were unique across all time.  For example, a
34671hash table indexed by thread id may have to be careful not to associate
34672data values from an old thread with a new one that happens to reuse the
34673id.  Simply removing the old entry after joining a thread may not be
34674sufficient, if it creates a visible window between the join and removal
34675during which a new thread with the same id could have been created and
34676added to the table.
34677</p>
34678
34679<p><i>[
34680post Bellevue Peter adds:
34681]</i></p>
34682
34683
34684<blockquote>
34685<p>
34686There is a real issue with <tt>thread::id</tt> reuse, but I urge the LWG to
34687reconsider fixing this by disallowing reuse, rather than explicitly allowing
34688it. Dealing with thread id reuse is an incredibly painful exercise that
34689would just force the world to reimplement a non-conflicting <tt>thread::id</tt> over
34690and over.
34691</p>
34692<p>
34693In addition, it would be nice if a <tt>thread::id</tt> could be manipulated
34694atomically in a lock-free manner, as motivated by the recursive lock
34695example:
34696</p>
34697
34698<p>
34699<a href="http://www.decadentplace.org.uk/pipermail/cpp-threads/2006-August/001091.html">http://www.decadentplace.org.uk/pipermail/cpp-threads/2006-August/001091.html</a>
34700</p>
34701</blockquote>
34702
34703
34704
34705<p><b>Proposed resolution:</b></p>
34706<p>
34707Add a sentence to 30.3.1.1 [thread.thread.id]/p1:
34708</p>
34709
34710<blockquote>
34711<p>
34712An object of type <code>thread::id</code> provides
34713a unique identifier for each thread of execution
34714and a single distinct value for all thread objects
34715that do not represent a thread of execution ([thread.threads.class]).
34716Each thread of execution has a <code>thread::id</code>
34717that is not equal to the <code>thread::id</code>
34718of other threads of execution
34719and that is not equal to
34720the <code>thread::id</code> of <code>std::thread</code> objects
34721that do not represent threads of execution.
34722<ins>The library may reuse the value of a <code>thread::id</code> of a
34723terminated thread that can no longer be joined.</ins>
34724</p>
34725</blockquote>
34726
34727
34728
34729
34730
34731<hr>
34732<h3><a name="787"></a>787. complexity of <tt>binary_search</tt></h3>
34733<p><b>Section:</b> 25.4.3.4 [binary.search] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
34734 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2007-09-08  <b>Last modified:</b> 2008-09-26</p>
34735<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
34736<p><b>Discussion:</b></p>
34737<p>
34738In 25.4.3.4 [binary.search]/3 the complexity of <tt>binary_search</tt> is described as
34739</p>
34740
34741<blockquote>
34742At most <tt>log(last - first) + 2</tt> comparisons.
34743</blockquote>
34744
34745<p>
34746This should be precised and brought in line with the nomenclature used for
34747<tt>lower_bound</tt>, <tt>upper_bound</tt>, and <tt>equal_range</tt>.
34748</p>
34749
34750<p>
34751All existing libraries I'm aware of, delegate to
34752<tt>lower_bound</tt> (+ one further comparison). Since
34753issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a>
34754has now WP status, the resolution of #787 should
34755be 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>
34756to <tt>+ O(1)</tt>.
34757</p>
34758
34759<p><i>[
34760Sophia Antipolis:
34761]</i></p>
34762
34763
34764<blockquote>
34765Alisdair prefers to apply an upper bound instead of O(1), but that would
34766require fixing for <tt>lower_bound</tt>, <tt>upper_bound</tt> etc. as well. If he really
34767cares about it, he'll send an issue to Howard.
34768</blockquote>
34769
34770
34771
34772<p><b>Proposed resolution:</b></p>
34773<p>
34774Change 25.4.3.4 [binary.search]/3
34775</p>
34776
34777<blockquote>
34778<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.
34779</blockquote>
34780
34781
34782
34783
34784
34785<hr>
34786<h3><a name="788"></a>788. ambiguity in [istream.iterator]</h3>
34787<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#WP">WP</a>
34788 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2008-02-06  <b>Last modified:</b> 2009-10-26</p>
34789<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>
34790<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
34791<p><b>Discussion:</b></p>
34792
34793<p><b>Addresses UK 287</b></p>
34794
34795<blockquote>
34796<p>
34797It is not clear what the initial state of an <tt>istream_iterator</tt> should be. Is
34798_value_ initialized by reading the stream, or default/value initialized? If
34799it is initialized by reading the stream, what happens if the initialization
34800is deferred until first dereference, when ideally the iterator value should
34801have been that of an end-of-stream iterator which is not safely
34802dereferencable?
34803</p>
34804
34805<p>
34806Recommendation: Specify _value_ is initialized by reading the stream, or
34807the iterator takes on the end-of-stream value if the stream is empty.
34808</p>
34809</blockquote>
34810
34811<p>
34812The description of how an istream_iterator object becomes an
34813end-of-stream iterator is a) ambiguous and b) out of date WRT
34814issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#468">468</a>:
34815</p>
34816
34817<blockquote>
34818<tt>istream_iterator</tt> reads (using <tt>operator&gt;&gt;</tt>) successive elements from the
34819input stream for which it was constructed. After it is constructed, and
34820every time <tt>++</tt> is used, the iterator reads and stores a value of <tt>T</tt>. If
34821the end of stream is reached (<tt>operator void*()</tt> on the stream returns
34822<tt>false</tt>), the iterator becomes equal to the <i>end-of-stream</i> iterator value.
34823The constructor with no arguments <tt>istream_iterator()</tt> always constructs
34824an end of stream input iterator object, which is the only legitimate
34825iterator to be used for the end condition. The result of <tt>operator*</tt> on an
34826end of stream is not defined. For any other iterator value a <tt>const T&amp;</tt> is
34827returned. The result of <tt>operator-&gt;</tt> on an end of stream is not defined.
34828For any other iterator value a <tt>const T*</tt> is returned. It is impossible to
34829store things into istream iterators. The main peculiarity of the istream
34830iterators is the fact that <tt>++</tt> operators are not equality preserving,
34831that is, <tt>i == j</tt> does not guarantee at all that <tt>++i == ++j</tt>. Every time <tt>++</tt>
34832is used a new value is read.
34833</blockquote>
34834
34835<p>
34836<tt>istream::operator void*()</tt> returns null if <tt>istream::fail()</tt> is <tt>true</tt>,
34837otherwise non-null. <tt>istream::fail()</tt> returns <tt>true</tt> if <tt>failbit</tt> or
34838<tt>badbit</tt> is set in <tt>rdstate()</tt>. Reaching the end of stream doesn't
34839necessarily imply that <tt>failbit</tt> or <tt>badbit</tt> is set (e.g., after
34840extracting an <tt>int</tt> from <tt>stringstream("123")</tt> the stream object will
34841have reached the end of stream but <tt>fail()</tt> is <tt>false</tt> and <tt>operator
34842void*()</tt> will return a non-null value).
34843</p>
34844
34845<p>
34846Also I would prefer to be explicit about calling <tt>fail()</tt> here
34847(there is no <tt>operator void*()</tt> anymore.)
34848</p>
34849
34850<p><i>[
34851Summit:
34852]</i></p>
34853
34854
34855<blockquote>
34856Moved from Ready to Open for the purposes of using this issue to address NB UK 287.
34857Martin to handle.
34858</blockquote>
34859
34860<p><i>[
348612009-07 Frankfurt:
34862]</i></p>
34863
34864
34865<blockquote>
34866<p>
34867This improves the wording.
34868</p>
34869<p>
34870Move to Ready.
34871</p>
34872</blockquote>
34873
34874
34875
34876<p><b>Proposed resolution:</b></p>
34877<p>
34878Change 24.6.1 [istream.iterator]/1:
34879</p>
34880
34881<blockquote>
34882<tt>istream_iterator</tt> reads (using <tt>operator&gt;&gt;</tt>) successive elements from the
34883input stream for which it was constructed. After it is constructed, and
34884every time <tt>++</tt> is used, the iterator reads and stores a value of <tt>T</tt>. If
34885<del>the end of stream is reached</del> <ins>the iterator fails to read and store a value of <tt>T</tt></ins>
34886(<tt><del>operator void*()</del> <ins>fail()</ins></tt> on the stream returns
34887<tt><del>false</del> <ins>true</ins></tt>), the iterator becomes equal to the <i>end-of-stream</i> iterator value.
34888The constructor with no arguments <tt>istream_iterator()</tt> always constructs
34889an end of stream input iterator object, which is the only legitimate
34890iterator to be used for the end condition. The result of <tt>operator*</tt> on an
34891end of stream is not defined. For any other iterator value a <tt>const T&amp;</tt> is
34892returned. The result of <tt>operator-&gt;</tt> on an end of stream is not defined.
34893For any other iterator value a <tt>const T*</tt> is returned. It is impossible to
34894store things into istream iterators. The main peculiarity of the istream
34895iterators is the fact that <tt>++</tt> operators are not equality preserving,
34896that is, <tt>i == j</tt> does not guarantee at all that <tt>++i == ++j</tt>. Every time <tt>++</tt>
34897is used a new value is read.
34898</blockquote>
34899
34900
34901
34902
34903
34904<hr>
34905<h3><a name="789"></a>789. <tt>xor_combine_engine(result_type)</tt> should be explicit</h3>
34906<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>
34907 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2008-02-09  <b>Last modified:</b> 2008-09-26</p>
34908<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>
34909<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
34910<p><b>Discussion:</b></p>
34911<p>
34912<tt>xor_combine_engine(result_type)</tt> should be <tt>explicit</tt>. (Obvious oversight.)
34913</p>
34914
34915<p><i>[
34916Bellevue:
34917]</i></p>
34918
34919
34920<blockquote>
34921Non-controversial. Bill is right, but Fermilab believes that this is
34922easy to use badly and hard to use right, and so it should be removed
34923entirely. Got into TR1 by well defined route, do we have permission to
34924remove stuff? Should probably check with Jens, as it is believed he is
34925the originator. Broad consensus that this is not a robust engine
34926adapter.
34927</blockquote>
34928
34929
34930<p><b>Proposed resolution:</b></p>
34931<p>
34932Remove xor_combine_engine from synopsis of 26.5.1 [rand.synopsis].
34933</p>
34934<p>
34935Remove X [rand.adapt.xor] <tt>xor_combine_engine</tt>.
34936</p>
34937
34938
34939
34940
34941
34942<hr>
34943<h3><a name="792"></a>792. <tt>piecewise_constant_distribution</tt> is undefined for a range with just one endpoint</h3>
34944<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>
34945 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2008-02-09  <b>Last modified:</b> 2008-09-26</p>
34946<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>
34947<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
34948<p><b>Discussion:</b></p>
34949<p>
34950<tt>piecewise_constant_distribution</tt> is undefined for a range with just one
34951endpoint. (Probably should be the same as an empty range.)
34952</p>
34953
34954
34955<p><b>Proposed resolution:</b></p>
34956<p>
34957Change 26.5.8.5.2 [rand.dist.samp.pconst] paragraph 3b:
34958</p>
34959
34960<blockquote>
34961b) If <tt>firstB == lastB</tt> <ins>or the sequence <tt>w</tt> has the length zero</ins>,
34962</blockquote>
34963
34964
34965
34966
34967
34968<hr>
34969<h3><a name="798"></a>798. Refactoring of binders lead to interface breakage</h3>
34970<p><b>Section:</b> D.9 [depr.lib.binders] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
34971 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2008-02-14  <b>Last modified:</b> 2008-09-26</p>
34972<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>
34973<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
34974<p><b>Discussion:</b></p>
34975<p>
34976<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2521.pdf">N2521</a>
34977and its earlier predecessors have moved the old binders from
34978[lib.binders] to D.9 [depr.lib.binders] thereby introducing some renaming
34979of the template parameter names (<tt>Operation -&gt; Fn</tt>). During this
34980renaming process the <em>protected</em> data member <tt>op</tt> was also renamed to
34981<tt>fn</tt>, which seems as an unnecessary interface breakage to me - even if
34982this user access point is probably rarely used.
34983</p>
34984
34985
34986<p><b>Proposed resolution:</b></p>
34987<p>
34988Change D.9.1 [depr.lib.binder.1st]:
34989</p>
34990
34991<blockquote>
34992<pre>template &lt;class Fn&gt; 
34993class binder1st 
34994  : public unary_function&lt;typename Fn::second_argument_type, 
34995                          typename Fn::result_type&gt; { 
34996protected: 
34997  Fn <del>fn</del> <ins>op</ins>; 
34998  typename Fn::first_argument_type value; 
34999public: 
35000  binder1st(const Fn&amp; x, 
35001            const typename Fn::first_argument_type&amp; y); 
35002  typename Fn::result_type 
35003    operator()(const typename Fn::second_argument_type&amp; x) const; 
35004  typename Fn::result_type 
35005    operator()(typename Fn::second_argument_type&amp; x) const; 
35006};
35007</pre>
35008
35009<blockquote>
35010<p>
35011-1- The constructor initializes <del><tt>fn</tt></del> <ins><tt>op</tt></ins> with <tt>x</tt> and <tt>value</tt> with <tt>y</tt>.
35012</p>
35013<p>
35014-2- <tt>operator()</tt> returns <tt><del>fn</del><ins>op</ins>(value,x)</tt>.
35015</p>
35016</blockquote>
35017</blockquote>
35018
35019<p>
35020Change D.9.3 [depr.lib.binder.2nd]:
35021</p>
35022
35023<blockquote>
35024<pre>template &lt;class Fn&gt; 
35025class binder2nd
35026  : public unary_function&lt;typename Fn::first_argument_type, 
35027                          typename Fn::result_type&gt; { 
35028protected: 
35029  Fn <del>fn</del> <ins>op</ins>; 
35030  typename Fn::second_argument_type value; 
35031public: 
35032  binder2nd(const Fn&amp; x, 
35033            const typename Fn::second_argument_type&amp; y); 
35034  typename Fn::result_type 
35035    operator()(const typename Fn::first_argument_type&amp; x) const; 
35036  typename Fn::result_type 
35037    operator()(typename Fn::first_argument_type&amp; x) const; 
35038};
35039</pre>
35040
35041<blockquote>
35042<p>
35043-1- The constructor initializes <del><tt>fn</tt></del> <ins><tt>op</tt></ins> with <tt>x</tt> and <tt>value</tt> with <tt>y</tt>.
35044</p>
35045<p>
35046-2- <tt>operator()</tt> returns <tt><del>fn</del><ins>op</ins>(value,x)</tt>.
35047</p>
35048</blockquote>
35049</blockquote>
35050
35051
35052
35053
35054
35055
35056<hr>
35057<h3><a name="804"></a>804. Some problems with classes <tt>error_code</tt>/<tt>error_condition</tt></h3>
35058<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>
35059 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2008-02-24  <b>Last modified:</b> 2008-09-26</p>
35060<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>
35061<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
35062<p><b>Discussion:</b></p>
35063<ol type="A">
35064<li>
35065<p>
3506619.5.2.1 [syserr.errcode.overview]/1, class <tt>error_code</tt> and
3506719.5.3.1 [syserr.errcondition.overview]/, class <tt>error_condition</tt> synopses
35068declare an expository data member <tt>cat_</tt>:
35069</p>
35070<blockquote><pre>const error_category&amp; cat_; // exposition only
35071</pre></blockquote>
35072<p>
35073which is used to define the semantics of several members. The decision
35074to use a member of reference type lead to several problems:
35075</p>
35076<ol>
35077<li>
35078The classes are not <tt>(Copy)Assignable</tt>, which is probably not the intent.
35079</li>
35080<li>
35081The post conditions of all modifiers from
3508219.5.2.3 [syserr.errcode.modifiers] and 19.5.3.3 [syserr.errcondition.modifiers], resp.,
35083cannot be fulfilled.
35084</li>
35085</ol>
35086<p>
35087The simple fix would be to replace the reference by a pointer member.
35088</p>
35089</li>
35090
35091<li>
35092I would like to give the editorial remark that in both classes the
35093constrained <tt>operator=</tt>
35094overload (template with <tt>ErrorCodeEnum</tt> argument) makes in invalid
35095usage of <tt>std::enable_if</tt>: By using the default value for the second <tt>enable_if</tt>
35096parameter the return type would be defined to be <tt>void&amp;</tt> even in otherwise
35097valid circumstances - this return type must be explicitly provided (In
35098<tt>error_condition</tt> the first declaration uses an explicit value, but of wrong
35099type).
35100</li>
35101
35102<li>
35103The member function <tt>message</tt> throws clauses (
3510419.5.1.2 [syserr.errcat.virtuals]/10, 19.5.2.4 [syserr.errcode.observers]/8, and
3510519.5.3.4 [syserr.errcondition.observers]/6) guarantee "throws nothing",
35106although
35107they return a <tt>std::string</tt> by value, which might throw in out-of-memory
35108conditions (see related issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#771">771</a>).
35109</li>
35110</ol>
35111
35112<p><i>[
35113Sophia Antipolis:
35114]</i></p>
35115
35116
35117<blockquote>
35118<p>
35119Part 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>.
35120</p>
35121<p>
35122Part B: Technically correct, save for typo. Rendered moot by the concept proposal 
35123(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2620.html">N2620</a>) NAD (editorial).
35124</p>
35125<p>
35126Part C: We agree; this is consistent with the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#721">721</a>.
35127</p>
35128<p>
35129Howard: please ping Beman, asking him to clear away parts A and B from
35130the wording in the proposed resolution, so it is clear to the editor
35131what needs to be applied to the working paper.
35132</p>
35133<p>
35134Beman 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
35135forward, the provided wording includes resolution of part A.
35136</p>
35137</blockquote>
35138
35139
35140
35141<p><b>Proposed resolution:</b></p>
35142
35143<p>
35144Resolution of part A:
35145</p>
35146<blockquote>
35147<p>
35148Change 19.5.2.1 [syserr.errcode.overview] Class error_code overview synopsis as indicated:
35149</p>
35150
35151<blockquote><pre>private:
35152  int val_;                    // exposition only
35153  const error_category<del>&amp;</del><ins>*</ins> cat_; // exposition only
35154</pre></blockquote>
35155
35156<p>
35157Change 19.5.2.2 [syserr.errcode.constructors] Class error_code constructors as indicated:
35158</p>
35159
35160<blockquote>
35161<pre>error_code();
35162</pre>
35163<blockquote>
35164<p>
35165<i>Effects:</i> Constructs an object of type <tt>error_code</tt>.
35166</p>
35167<p>
35168<i>Postconditions:</i> <tt>val_ == 0</tt> and <tt>cat_ == <ins>&amp;</ins>system_category</tt>.
35169</p>
35170<p>
35171<i>Throws:</i> Nothing.
35172</p>
35173</blockquote>
35174<pre>error_code(int val, const error_category&amp; cat);
35175</pre>
35176<blockquote>
35177<p>
35178<i>Effects:</i> Constructs an object of type <tt>error_code</tt>.
35179</p>
35180<p>
35181<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&amp;</ins>cat</tt>.
35182</p>
35183<p>
35184<i>Throws:</i> Nothing.
35185</p>
35186</blockquote>
35187</blockquote>
35188
35189<p>
35190Change 19.5.2.3 [syserr.errcode.modifiers] Class error_code modifiers as indicated:
35191</p>
35192
35193<blockquote>
35194<pre>void assign(int val, const error_category&amp; cat);
35195</pre>
35196<blockquote>
35197<p>
35198<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&amp;</ins>cat</tt>.
35199</p>
35200<p>
35201<i>Throws:</i> Nothing.
35202</p>
35203</blockquote>
35204</blockquote>
35205
35206<p>
35207Change 19.5.2.4 [syserr.errcode.observers] Class error_code observers as indicated:
35208</p>
35209
35210<blockquote>
35211const error_category&amp; category() const;
35212<blockquote>
35213<p>
35214<i>Returns:</i> <tt><ins>*</ins>cat_</tt>.
35215</p>
35216<p>
35217<i>Throws:</i> Nothing.
35218</p>
35219</blockquote>
35220</blockquote>
35221
35222<p>
35223Change 19.5.3.1 [syserr.errcondition.overview] Class error_condition overview synopsis as indicated:
35224</p>
35225
35226<blockquote><pre>private:
35227  int val_;                    // exposition only
35228  const error_category<del>&amp;</del><ins>*</ins> cat_; // exposition only
35229</pre></blockquote>
35230
35231<p>
35232Change 19.5.3.2 [syserr.errcondition.constructors] Class error_condition constructors as indicated:
35233</p>
35234<p><i>[
35235(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
35236name <tt>posix_category</tt> will have been changed to <tt>generic_category</tt>. That has
35237no effect on this resolution.)
35238]</i></p>
35239
35240
35241<blockquote>
35242<pre>error_condition();
35243</pre>
35244<blockquote>
35245<p>
35246<i>Effects:</i> Constructs an object of type <tt>error_condition</tt>.
35247</p>
35248<p>
35249<i>Postconditions:</i> <tt>val_ == 0</tt> and <tt>cat_ == <ins>&amp;</ins>posix_category</tt>.
35250</p>
35251<p>
35252<i>Throws:</i> Nothing.
35253</p>
35254</blockquote>
35255<pre>error_condition(int val, const error_category&amp; cat);
35256</pre>
35257<blockquote>
35258<p>
35259<i>Effects:</i> Constructs an object of type <tt>error_condition</tt>.
35260</p>
35261<p>
35262<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&amp;</ins>cat</tt>.
35263</p>
35264<p>
35265<i>Throws:</i> Nothing.
35266</p>
35267</blockquote>
35268</blockquote>
35269
35270<p>
35271Change 19.5.3.3 [syserr.errcondition.modifiers] Class error_condition modifiers as indicated:
35272</p>
35273
35274<blockquote>
35275void assign(int val, const error_category&amp; cat);
35276<blockquote>
35277<p>
35278<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&amp;</ins>cat</tt>.
35279</p>
35280<p>
35281<i>Throws:</i> Nothing.
35282</p>
35283</blockquote>
35284</blockquote>
35285
35286<p>
35287Change 19.5.3.4 [syserr.errcondition.observers] Class error_condition observers as indicated:
35288</p>
35289
35290<blockquote>
35291const error_category&amp; category() const;
35292<blockquote>
35293<p>
35294<i>Returns:</i> <tt><ins>*</ins>cat_</tt>.
35295</p>
35296<p>
35297<i>Throws:</i> Nothing.
35298</p>
35299</blockquote>
35300</blockquote>
35301</blockquote>
35302
35303<p>
35304Resolution of part C:
35305</p>
35306
35307<blockquote>
35308
35309<p>
35310In 19.5.1.2 [syserr.errcat.virtuals], remove the throws clause p. 10.
35311</p>
35312
35313<blockquote>
35314<pre>virtual string message(int ev) const = 0;
35315</pre>
35316
35317<blockquote>
35318<p>
35319<i>Returns:</i> A string that describes the error condition denoted by <tt>ev</tt>.
35320</p>
35321<p>
35322<del><i>Throws:</i> Nothing.</del>
35323</p>
35324</blockquote>
35325</blockquote>
35326
35327<p>
35328In 19.5.2.4 [syserr.errcode.observers], remove the throws clause p. 8.
35329</p>
35330
35331<blockquote>
35332<pre>string message() const;
35333</pre>
35334<blockquote>
35335<p>
35336<i>Returns:</i> <tt>category().message(value())</tt>.
35337</p>
35338<p>
35339<del><i>Throws:</i> Nothing.</del>
35340</p>
35341</blockquote>
35342</blockquote>
35343
35344<p>
35345In 19.5.3.4 [syserr.errcondition.observers], remove the throws clause p. 6.
35346</p>
35347
35348<blockquote>
35349<pre>string message() const;
35350</pre>
35351<blockquote>
35352<p>
35353<i>Returns:</i> <tt>category().message(value())</tt>.
35354</p>
35355<p>
35356<del><i>Throws:</i> Nothing.</del>
35357</p>
35358</blockquote>
35359</blockquote>
35360
35361</blockquote>
35362
35363
35364
35365
35366
35367
35368<hr>
35369<h3><a name="805"></a>805. <tt>posix_error::posix_errno</tt> concerns</h3>
35370<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>
35371 <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2008-02-24  <b>Last modified:</b> 2008-09-26</p>
35372<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>
35373<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
35374<p><b>Discussion:</b></p>
35375<p>
3537619.5 [syserr]
35377</p>
35378
35379<blockquote><pre>namespace posix_error {
35380  enum posix_errno {
35381    address_family_not_supported, // EAFNOSUPPORT
35382    ...
35383</pre></blockquote>
35384
35385<p>
35386should rather use the new scoped-enum  facility (7.2 [dcl.enum]),
35387which would avoid the necessity for a new <tt>posix_error</tt>
35388namespace, if I understand correctly.
35389</p>
35390
35391<p><i>[
35392Further discussion:
35393]</i></p>
35394
35395
35396<blockquote>
35397<p>
35398See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf">N2347</a>,
35399Strongly Typed Enums, since renamed Scoped Enums.
35400</p>
35401<p>
35402Alberto Ganesh Barbati also raised this issue in private email, and also proposed the scoped-enum solution.
35403</p>
35404<p>
35405Nick Stoughton asked in Bellevue that <tt>posix_error</tt> and <tt>posix_errno</tt> not be used as names. The LWG agreed.
35406</p>
35407<p>
35408The wording for the Proposed resolution was provided by Beman Dawes.
35409</p>
35410</blockquote>
35411
35412
35413<p><b>Proposed resolution:</b></p>
35414<p>
35415Change System error support 19.5 [syserr] as indicated:
35416</p>
35417
35418<blockquote><pre><del>namespace posix_error {</del>
35419  enum <del>posix_errno</del> <ins>class errc</ins> {
35420    address_family_not_supported, // EAFNOSUPPORT
35421    ...
35422    wrong_protocol_type, // EPROTOTYPE
35423  };
35424<del>} // namespace posix_error</del>
35425
35426template &lt;&gt; struct is_error_condition_enum&lt;<del>posix_error::posix_errno</del> <ins>errc</ins>&gt;
35427  : public true_type {}
35428
35429<del>namespace posix_error {</del>
35430  error_code make_error_code(<del>posix_errno</del> <ins>errc</ins> e);
35431  error_condition make_error_condition(<del>posix_errno</del> <ins>errc</ins> e);
35432<del>} // namespace posix_error</del>
35433</pre></blockquote>
35434
35435<p>
35436Change System error support 19.5 [syserr] :
35437</p>
35438
35439<blockquote>
35440<del>The <tt>is_error_code_enum</tt> and <tt>is_error_condition_enum</tt> templates may be
35441specialized for user-defined types to indicate that such a type is
35442eligible for class <tt>error_code</tt> and class <tt>error_condition</tt> automatic
35443conversions, respectively.</del>
35444</blockquote>
35445
35446<p>
35447Change System error support 19.5 [syserr] and its subsections:
35448</p>
35449
35450<blockquote>
35451<ul>
35452<li>
35453remove all occurrences of <tt>posix_error::</tt>
35454</li>
35455<li>
35456change all instances of <tt>posix_errno</tt> to <tt>errc</tt>
35457</li>
35458<li>
35459change all instances of <tt>posix_category</tt> to <tt>generic_category</tt>
35460</li>
35461<li>
35462change all instances of <tt>get_posix_category</tt> to <tt>get_generic_category</tt>
35463</li>
35464</ul>
35465</blockquote>
35466
35467<p>
35468Change Error category objects 19.5.1.5 [syserr.errcat.objects], paragraph 2:
35469</p>
35470
35471<blockquote>
35472<i>Remarks:</i> The object's <tt>default_error_condition</tt> and equivalent virtual
35473functions shall behave as specified for the class <tt>error_category</tt>. The
35474object's name virtual function shall return a pointer to the string
35475<del>"POSIX"</del> <ins>"generic"</ins>.
35476</blockquote>
35477
35478<p>
35479Change 19.5.2.5 [syserr.errcode.nonmembers] Class <tt>error_code</tt> non-member functions as indicated:
35480</p>
35481
35482<blockquote>
35483<pre>error_code make_error_code(<del>posix_errno</del> <ins>errc</ins> e);
35484</pre>
35485
35486<blockquote>
35487<i>Returns:</i> <tt>error_code(<ins>static_cast&lt;int&gt;(</ins>e<ins>)</ins>, <del>posix</del><ins>generic</ins>_category)</tt>.
35488</blockquote>
35489</blockquote>
35490
35491<p>
35492Change 19.5.3.5 [syserr.errcondition.nonmembers] Class <tt>error_condition</tt> non-member functions as indicated:
35493</p>
35494
35495<blockquote>
35496<pre>error_condition make_error_condition(<del>posix_errno</del> <ins>errc</ins> e);
35497</pre>
35498
35499<blockquote>
35500<i>Returns:</i> <tt>error_condition(<ins>static_cast&lt;int&gt;(</ins>e<ins>)</ins>, <del>posix</del><ins>generic</ins>_category)</tt>.
35501</blockquote>
35502</blockquote>
35503
35504
35505
35506<p><b>Rationale:</b></p>
35507<table border="1">
35508<tbody><tr>
35509<th colspan="2">Names Considered</th>
35510</tr>
35511
35512<tr>
35513<td><tt>portable</tt></td>
35514<td>
35515Too non-specific. Did not wish to reserve such a common word in
35516namespace std. Not quite the right meaning, either.
35517</td>
35518</tr>
35519
35520<tr>
35521<td><tt>portable_error</tt></td>
35522<td>
35523Too long. Explicit qualification is always required for scoped enums, so
35524a short name is desirable. Not quite the right meaning, either. May be
35525misleading because <tt>*_error</tt> in the std lib is usually an exception class
35526name.
35527</td>
35528</tr>
35529
35530<tr>
35531<td><tt>std_error</tt></td>
35532<td>
35533Fairly short, yet explicit. But in fully qualified names like
35534<tt>std::std_error::not_enough_memory</tt>, the std_ would be unfortunate. Not
35535quite the right meaning, either. May be misleading because <tt>*_error</tt> in
35536the std lib is usually an exception class name.
35537</td>
35538</tr>
35539
35540<tr>
35541<td><tt>generic</tt></td>
35542<td>
35543Short enough. The category could be <tt>generic_category</tt>. Fully qualified
35544names like <tt>std::generic::not_enough_memory</tt> read well. Reserving in
35545namespace std seems dicey.
35546</td>
35547</tr>
35548
35549<tr>
35550<td><tt>generic_error</tt></td>
35551<td>
35552Longish. The category could be <tt>generic_category</tt>. Fully qualified names
35553like <tt>std::generic_error::not_enough_memory</tt> read well. Misleading because
35554<tt>*_error</tt> in the std lib is usually an exception class name.
35555</td>
35556</tr>
35557
35558<tr>
35559<td><tt>generic_err</tt></td>
35560<td>
35561A bit less longish. The category could be <tt>generic_category</tt>. Fully
35562qualified names like <tt>std::generic_err::not_enough_memory</tt> read well.
35563</td>
35564</tr>
35565
35566<tr>
35567<td><tt>gen_err</tt></td>
35568<td>
35569Shorter still. The category could be <tt>generic_category</tt>. Fully qualified
35570names like <tt>std::gen_err::not_enough_memory</tt> read well.
35571</td>
35572</tr>
35573
35574<tr>
35575<td><tt>generr</tt></td>
35576<td>
35577Shorter still. The category could be <tt>generic_category</tt>. Fully qualified
35578names like <tt>std::generr::not_enough_memory</tt> read well.
35579</td>
35580</tr>
35581
35582<tr>
35583<td><tt>error</tt></td>
35584<td>
35585Shorter still. The category could be <tt>generic_category</tt>. Fully qualified
35586names like <tt>std::error::not_enough_memory</tt> read well. Do we want to use
35587this general a name?
35588</td>
35589</tr>
35590
35591<tr>
35592<td><tt>err</tt></td>
35593<td>
35594Shorter still. The category could be <tt>generic_category</tt>. Fully qualified
35595names like <tt>std::err::not_enough_memory</tt> read well. Although alone it
35596looks odd as a name, given the existing <tt>errno</tt> and <tt>namespace std</tt> names,
35597it seems fairly intuitive.
35598Problem: <tt>err</tt> is used throughout the standard library as an argument name
35599and in examples as a variable name; it seems too confusing to add yet
35600another use of the name.
35601</td>
35602</tr>
35603
35604<tr>
35605<td><tt>errc</tt></td>
35606<td>
35607Short enough. The "c" stands for "constant". The category could be
35608<tt>generic_category</tt>. Fully qualified names like
35609<tt>std::errc::not_enough_memory</tt> read well. Although alone it looks odd as a
35610name, given the existing <tt>errno</tt> and <tt>namespace std</tt> names, it seems fairly
35611intuitive. There are no uses of <tt>errc</tt> in the current C++ standard.
35612</td>
35613</tr>
35614</tbody></table>
35615
35616
35617
35618
35619
35620<hr>
35621<h3><a name="806"></a>806. <tt>unique_ptr::reset</tt> effects incorrect, too permissive</h3>
35622<p><b>Section:</b> 20.8.14.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>
35623 <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2008-03-13  <b>Last modified:</b> 2008-09-26</p>
35624<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>
35625<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
35626<p><b>Discussion:</b></p>
35627<p>
35628<tt>void unique_ptr::reset(T* p = 0)</tt> is currently specified as:
35629</p>
35630
35631<blockquote>
35632<i>Effects:</i> If <tt>p == get()</tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>.
35633</blockquote>
35634
35635<p>
35636There are two problems with this. One, if <tt>get() == 0</tt> and <tt>p != 0</tt>, the
35637deleter is called with a NULL pointer, and this is probably not what's
35638intended (the destructor avoids calling the deleter with 0.)
35639</p>
35640
35641<p>
35642Two, the special check for <tt>get() == p</tt> is generally not needed and such a
35643situation usually indicates an error in the client code, which is being
35644masked. As a data point, <tt>boost::shared_ptr</tt> was changed to assert on such
35645self-resets in 2001 and there were no complaints.
35646</p>
35647
35648<p>
35649One might think that self-resets are necessary for operator= to work; it's specified to perform
35650</p>
35651
35652<blockquote><pre>reset( u.release() );
35653</pre></blockquote>
35654
35655<p>
35656and the self-assignment
35657</p>
35658
35659<blockquote><pre>p = move(p);
35660</pre></blockquote>
35661
35662<p>
35663might appear to result in a self-reset. But it doesn't; the <tt>release()</tt> is
35664performed first, zeroing the stored pointer. In other words, <tt>p.reset(
35665q.release() )</tt> works even when <tt>p</tt> and <tt>q</tt> are the same <tt>unique_ptr</tt>, and there
35666is no need to special-case <tt>p.reset( q.get() )</tt> to work in a similar
35667scenario, as it definitely doesn't when <tt>p</tt> and <tt>q</tt> are separate.
35668</p>
35669
35670
35671
35672<p><b>Proposed resolution:</b></p>
35673
35674<p>
35675Change 20.8.14.2.5 [unique.ptr.single.modifiers]:
35676</p>
35677
35678<blockquote>
35679<pre>void reset(T* p = 0);
35680</pre>
35681<blockquote>
35682-4- <i>Effects:</i> If <tt><del>p ==</del> get()<ins> == 0</ins></tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>.
35683</blockquote>
35684</blockquote>
35685
35686<p>
35687Change 20.8.14.3.3 [unique.ptr.runtime.modifiers]:
35688</p>
35689
35690<blockquote>
35691<pre>void reset(T* p = 0);
35692</pre>
35693<blockquote>
35694<p>...</p>
35695<p>
35696-2- <i>Effects:</i> If <tt><del>p ==</del> get()<ins> == 0</ins></tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>.
35697</p>
35698</blockquote>
35699</blockquote>
35700
35701
35702
35703
35704
35705
35706<hr>
35707<h3><a name="807"></a>807. <tt>tuple</tt> construction should not fail unless its element's construction fails</h3>
35708<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>
35709 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2008-03-13  <b>Last modified:</b> 2008-09-26</p>
35710<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>
35711<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
35712<p><b>Discussion:</b></p>
35713<p>
35714<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
35715should be added to <tt>tuple</tt> except it ought to take into account move constructors as well.
35716</p>
35717
35718
35719<p><b>Proposed resolution:</b></p>
35720<p>
35721Add to 20.5.2.1 [tuple.cnstr]:
35722</p>
35723
35724<blockquote>
35725<p>
35726For each <tt>tuple</tt> constructor and assignment operator, an exception is thrown only if the construction
35727or assignment of one of the types in <tt>Types</tt> throws an exception.
35728</p>
35729</blockquote>
35730
35731
35732
35733
35734
35735<hr>
35736<h3><a name="808"></a>808. [forward] incorrect redundant specification</h3>
35737<p><b>Section:</b> 20.3.3 [forward] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
35738 <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2008-03-13  <b>Last modified:</b> 2008-09-26</p>
35739<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>
35740<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
35741<p><b>Discussion:</b></p>
35742<p>
35743p4 (forward) says:
35744</p>
35745<blockquote>
35746<i>Return type:</i> If <tt>T</tt> is an lvalue-reference type, an lvalue; otherwise, an rvalue.
35747</blockquote>
35748
35749<p>
35750First of all, lvalue-ness and rvalue-ness are properties of an expression,
35751not of a type (see 3.10 [basic.lval]).  Thus, the phrasing "Return type" is wrong.
35752Second, the phrase says exactly what the core language wording says for
35753folding references in 14.4.1 [temp.arg.type]/p4  and for function return values
35754in 5.2.2 [expr.call]/p10.  (If we feel the wording should be retained, it should
35755at most be a note with cross-references to those sections.)
35756</p>
35757<p>
35758The prose after the example talks about "forwarding as an <tt>int&amp;</tt> (an lvalue)" etc.
35759In my opinion, this is a category error:  "<tt>int&amp;</tt>" is a type, "lvalue" is a
35760property of an expression, orthogonal to its type.  (Btw, expressions cannot
35761have reference type, ever.)
35762</p>
35763<p>
35764Similar with move:
35765</p>
35766<blockquote>
35767Return type: an rvalue.
35768</blockquote>
35769<p>
35770is just wrong and also redundant.
35771</p>
35772
35773
35774<p><b>Proposed resolution:</b></p>
35775<p>
35776Change 20.3.3 [forward] as indicated:
35777</p>
35778
35779<blockquote>
35780<pre>template &lt;class T&gt; T&amp;&amp; forward(typename identity&lt;T&gt;::type&amp;&amp; t);
35781</pre>
35782
35783<blockquote>
35784<p>...</p>
35785<p>
35786<del><i>Return type:</i> If <tt>T</tt> is an lvalue-reference type, an lvalue; otherwise, an rvalue.</del>
35787</p>
35788<p>...</p>
35789<p>
35790-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
35791as <del>an <tt>int&amp;&amp;</tt> (</del>an rvalue<del>)</del>. In the second call to factory, <tt>A1</tt> is deduced
35792as <tt>int&amp;</tt>, so <tt>i</tt> is forwarded to <tt>A</tt>'s constructor as <del>an <tt>int&amp;</tt> (</del>an lvalue<del>)</del>.
35793In both cases, <tt>A2</tt> is deduced as double, so 1.414 is forwarded to <tt>A</tt>'s constructor as
35794<del><tt>double&amp;&amp;</tt> (</del>an rvalue<del>)</del>.
35795</p>
35796</blockquote>
35797
35798<pre>template &lt;class T&gt; typename remove_reference&lt;T&gt;::type&amp;&amp; move(T&amp;&amp; t);
35799</pre>
35800
35801<blockquote>
35802<p>...</p>
35803<p>
35804<del><i>Return type:</i>  an rvalue.</del>
35805</p>
35806</blockquote>
35807
35808</blockquote>
35809
35810
35811
35812
35813
35814
35815<hr>
35816<h3><a name="809"></a>809. std::swap should be overloaded for array types</h3>
35817<p><b>Section:</b> 25.3.3 [alg.swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
35818 <b>Submitter:</b> Niels Dekker <b>Opened:</b> 2008-02-28  <b>Last modified:</b> 2008-09-26</p>
35819<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>
35820<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
35821<p><b>Discussion:</b></p>
35822<p>
35823For the sake of generic programming, the header <code>&lt;algorithm&gt;</code> should provide an
35824overload of <code>std::swap</code> for array types:
35825</p><pre>template&lt;class T, size_t N&gt; void swap(T (&amp;a)[N], T (&amp;b)[N]);
35826</pre>
35827
35828
35829<p>
35830It became apparent to me that this overload is missing, when I considered how to write a swap
35831function for a generic wrapper class template.
35832(Actually I was thinking of Boost's <a href="http://www.boost.org/libs/utility/value_init.htm">value_initialized</a>.)
35833Please look at the following template, <code>W</code>, and suppose that is intended to be a very
35834<em>generic</em> wrapper:
35835</p><pre>template&lt;class T&gt; class W {
35836public:
35837   T data;
35838};
35839</pre>
35840Clearly <code>W&lt;T&gt;</code> is <em>CopyConstructible and CopyAssignable</em>, and therefore
35841<em>Swappable</em>, whenever <code>T</code> is <em>CopyConstructible and CopyAssignable</em>.
35842Moreover, <code>W&lt;T&gt;</code> is <em>also</em> Swappable when <code>T</code> is an array type
35843whose element type is CopyConstructible and CopyAssignable.
35844Still it is recommended to add a <em>custom</em> swap function template to such a class template,
35845for the sake of efficiency and exception safety.
35846(E.g., <em>Scott Meyers, Effective C++, Third Edition, item 25: Consider support for a non-throwing
35847swap</em>.)
35848This function template is typically written as follows:
35849<pre>template&lt;class T&gt; void swap(W&lt;T&gt;&amp; x, W&lt;T&gt;&amp; y) {
35850  using std::swap;
35851  swap(x.data, y.data);
35852}
35853</pre>
35854Unfortunately, this will introduce an undesirable inconsistency, when <code>T</code> is an array.
35855For instance, <code>W&lt;std::string[8]&gt;</code> is Swappable, but the current Standard does not
35856allow calling the custom swap function that was especially written for <code>W</code>!
35857<pre>W&lt;std::string[8]&gt; w1, w2;  // Two objects of a Swappable type.
35858std::swap(w1, w2);  // Well-defined, but inefficient.
35859using std::swap;
35860swap(w1, w2);  // Ill-formed, just because ADL finds W's swap function!!!
35861</pre>
35862
35863<code>W</code>'s <code>swap</code> function would try to call <code>std::swap</code> for an array,
35864<code>std::string[8]</code>, which is not supported by the Standard Library.
35865This issue is easily solved by providing an overload of <code>std::swap</code> for array types.
35866This swap function should be implemented in terms of swapping the elements of the arrays, so that
35867it would be non-throwing for arrays whose element types have a non-throwing swap.
35868
35869
35870<p>
35871Note that such an overload of <code>std::swap</code> should also support <em>multi-dimensional</em>
35872arrays. Fortunately that isn't really an issue, because it would do so <i>automatically</i>, by
35873means of recursion.
35874</p>
35875
35876<p>
35877For 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
35878Library] Shouldn't std::swap be overloaded for C-style arrays?</a>
35879</p>
35880
35881
35882<p><b>Proposed resolution:</b></p>
35883<p>
35884Add an extra condition to the definition of Swappable requirements [swappable] in 20.2.1 [utility.arg.requirements]:
35885</p>
35886<blockquote>
35887- <tt>T</tt> is <tt>Swappable</tt> if <tt>T</tt> is an array type whose element type is <tt>Swappable</tt>.
35888</blockquote>
35889<p>
35890Add the following to 25.3.3 [alg.swap]:
35891</p>
35892<blockquote>
35893<pre>template&lt;class T, size_t N&gt; void swap(T (&amp;a)[N], T (&amp;b)[N]);
35894</pre>
35895<blockquote>
35896<i>Requires:</i> Type <code>T</code> shall be <tt>Swappable</tt>.
35897</blockquote>
35898<blockquote>
35899<i>Effects:</i> <code>swap_ranges(a, a + N, b);</code>
35900</blockquote>
35901</blockquote>
35902
35903
35904
35905
35906
35907<hr>
35908<h3><a name="810"></a>810. Missing traits dependencies in operational semantics of extended manipulators</h3>
35909<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#WP">WP</a>
35910 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2008-03-01  <b>Last modified:</b> 2009-07-18</p>
35911<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>
35912<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
35913<p><b>Discussion:</b></p>
35914<p>
35915The recent draft (as well as the original proposal n2072) uses an
35916operational semantic
35917for <tt>get_money</tt> ([ext.manip]/4) and <tt>put_money</tt> ([ext.manip]/6), which uses
35918</p>
35919
35920<blockquote><pre>istreambuf_iterator&lt;charT&gt;
35921</pre></blockquote>
35922
35923<p>
35924and
35925</p>
35926
35927<blockquote><pre>ostreambuf_iterator&lt;charT&gt;
35928</pre></blockquote>
35929
35930<p>
35931resp, instead of the iterator instances, with explicitly provided
35932traits argument (The operational semantic defined by <tt>f</tt> is also traits
35933dependent). This is an obvious oversight because both <tt>*stream_buf</tt>
35934c'tors expect a <tt>basic_streambuf&lt;charT,traits&gt;</tt> as argument.
35935</p>
35936<p>
35937The same problem occurs within the <tt>get_time</tt> and <tt>put_time</tt> semantic 
35938where additional to the problem we
35939have an editorial issue in <tt>get_time</tt> (<tt>streambuf_iterator</tt> instead of
35940<tt>istreambuf_iterator</tt>).
35941</p>
35942
35943<p><i>[
35944Batavia (2009-05):
35945]</i></p>
35946
35947<blockquote>
35948<p>
35949This appears to be an issue of presentation.
35950</p>
35951<p>
35952We agree with the proposed resolution.
35953Move to Tentatively Ready.
35954</p>
35955</blockquote>
35956
35957
35958<p><b>Proposed resolution:</b></p>
35959<p>
35960In 27.7.4 [ext.manip]/4 within function <tt>f</tt> replace the first line
35961</p>
35962
35963<blockquote><pre>template &lt;class charT, class traits, class moneyT&gt; 
35964void f(basic_ios&lt;charT, traits&gt;&amp; str, moneyT&amp; mon, bool intl) { 
35965   typedef istreambuf_iterator&lt;charT<ins>, traits</ins>&gt; Iter;
35966   ...
35967</pre></blockquote>
35968
35969<p>
35970In 27.7.4 [ext.manip]/5 remove the first template <tt>charT</tt> parameter:
35971</p>
35972
35973<blockquote><pre>template &lt;<del>class charT, </del>class moneyT&gt; unspecified put_money(const moneyT&amp; mon, bool intl = false<ins>)</ins>;
35974</pre></blockquote>
35975
35976<p>
35977In 27.7.4 [ext.manip]/6 within function <tt>f</tt> replace the first line
35978</p>
35979
35980<blockquote><pre>template &lt;class charT, class traits, class moneyT&gt; 
35981void f(basic_ios&lt;charT, traits&gt;&amp; str, const moneyT&amp; mon, bool intl) { 
35982  typedef ostreambuf_iterator&lt;charT<ins>, traits</ins>&gt; Iter;
35983  ...
35984</pre></blockquote>
35985
35986<p>
35987In 27.7.4 [ext.manip]/8 within function <tt>f</tt> replace the first line
35988</p>
35989
35990<blockquote><pre>template &lt;class charT, class traits&gt; 
35991void f(basic_ios&lt;charT, traits&gt;&amp; str, struct tm *tmb, const charT *fmt) { 
35992  typedef <ins>i</ins>streambuf_iterator&lt;charT<ins>, traits</ins>&gt; Iter;
35993  ...
35994</pre></blockquote>
35995
35996<p>
35997In 27.7.4 [ext.manip]/10 within function <tt>f</tt> replace the first line
35998</p>
35999
36000<blockquote><pre>template &lt;class charT, class traits&gt; 
36001void f(basic_ios&lt;charT, traits&gt;&amp; str, const struct tm *tmb, const charT *fmt) { 
36002  typedef ostreambuf_iterator&lt;charT<ins>, traits</ins>&gt; Iter;
36003  ...
36004</pre></blockquote>
36005
36006<p>
36007In 27.7 [iostream.format], Header <tt>&lt;iomanip&gt;</tt> synopsis change:
36008</p>
36009
36010<blockquote><pre>template &lt;<del>class charT, </del>class moneyT&gt; T8 put_money(const moneyT&amp; mon, bool intl = false);
36011</pre></blockquote>
36012
36013
36014
36015
36016
36017<hr>
36018<h3><a name="813"></a>813. "empty" undefined for <tt>shared_ptr</tt></h3>
36019<p><b>Section:</b> 20.8.15.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
36020 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2008-02-26  <b>Last modified:</b> 2008-09-26</p>
36021<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>
36022<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
36023<p><b>Discussion:</b></p>
36024<p>
36025Several places in 20.8.15.2 [util.smartptr.shared] refer to an "empty" <tt>shared_ptr</tt>.
36026However, that term is nowhere defined. The closest thing we have to a
36027definition is that the default constructor creates an empty <tt>shared_ptr</tt>
36028and that a copy of a default-constructed <tt>shared_ptr</tt> is empty. Are any
36029other <tt>shared_ptr</tt>s empty? For example, is <tt>shared_ptr((T*) 0)</tt> empty? What
36030are the properties of an empty <tt>shared_ptr</tt>? We should either clarify this
36031term or stop using it.
36032</p><p>
36033</p>
36034One reason it's not good enough to leave this term up to the reader's
36035intuition is that, in light of
36036<a href="http://www.open-std.org/JTC1/sc22/WG21/docs/papers/2007/n2351.htm">N2351</a>
36037and issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#711">711</a>, most readers'
36038intuitive understanding is likely to be wrong. Intuitively one might
36039expect that an empty <tt>shared_ptr</tt> is one that doesn't store a pointer,
36040but, whatever the definition is, that isn't it.
36041
36042
36043<p><i>[
36044Peter adds:
36045]</i></p>
36046
36047
36048<blockquote>
36049<p>
36050Or, what is an "empty" <tt>shared_ptr</tt>?
36051</p>
36052
36053<ul>
36054<li>
36055<p>
36056Are any other <tt>shared_ptrs</tt> empty?
36057</p>
36058<p>
36059Yes. Whether a given <tt>shared_ptr</tt> instance is empty or not is (*)
36060completely specified by the last mutating operation on that instance.
36061Give me an example and I'll tell you whether the <tt>shared_ptr</tt> is empty or
36062not.
36063</p>
36064<blockquote>
36065(*) If it isn't, this is a legitimate defect.
36066</blockquote>
36067</li>
36068
36069<li>
36070<p>
36071For example, is <tt>shared_ptr((T*) 0)</tt> empty?
36072</p>
36073<p>
36074No. If it were empty, it would have a <tt>use_count()</tt> of 0, whereas it is
36075specified to have an <tt>use_count()</tt> of 1.
36076</p>
36077</li>
36078
36079<li>
36080<p>
36081What are the properties of an empty <tt>shared_ptr</tt>?
36082</p>
36083<p>
36084The properties of an empty <tt>shared_ptr</tt> can be derived from the
36085specification. One example is that its destructor is a no-op. Another is
36086that its <tt>use_count()</tt> returns 0. I can enumerate the full list if you
36087really like.
36088</p>
36089</li>
36090
36091<li>
36092<p>
36093We should either clarify this term or stop using it.
36094</p>
36095<p>
36096I don't agree with the imperative tone
36097</p>
36098<p>
36099A clarification would be either a no-op - if it doesn't contradict the
36100existing wording - or a big mistake if it does.
36101</p>
36102<p>
36103I agree that a clarification that is formally a no-op may add value.
36104</p>
36105</li>
36106
36107<li>
36108<p>
36109However, that term is nowhere defined.
36110</p>
36111<p>
36112Terms can be useful without a definition. Consider the following
36113simplistic example. We have a type <tt>X</tt> with the following operations
36114defined:
36115</p>
36116<blockquote><pre>X x;
36117X x2(x);
36118X f(X x);
36119X g(X x1, X x2);
36120</pre></blockquote>
36121<p>
36122A default-constructed value is green.<br>
36123A copy has the same color as the original.<br>
36124<tt>f(x)</tt> returns a red value if the argument is green, a green value otherwise.<br>
36125<tt>g(x1,x2)</tt> returns a green value if the arguments are of the same color, a red value otherwise.
36126</p>
36127
36128<p>
36129Given these definitions, you can determine the color of every instance
36130of type <tt>X</tt>, even if you have absolutely no idea what green and red mean.
36131</p>
36132
36133<p>
36134Green and red are "nowhere defined" and completely defined at the same time.
36135</p>
36136</li>
36137</ul>
36138
36139<p>
36140Alisdair's wording is fine.
36141</p>
36142</blockquote>
36143
36144
36145<p><b>Proposed resolution:</b></p>
36146<p>
36147Append the following sentance to 20.8.15.2 [util.smartptr.shared]
36148</p>
36149<blockquote>
36150The <code>shared_ptr</code> class template stores a pointer, usually obtained
36151via <code>new</code>. <code>shared_ptr</code> implements semantics of
36152shared ownership; the last remaining owner of the pointer is responsible for
36153destroying the object, or otherwise releasing  the resources associated with
36154the stored pointer. <ins>A <code>shared_ptr</code> object that does not own
36155a pointer is said to be <i>empty</i>.</ins>
36156</blockquote>
36157
36158
36159
36160
36161
36162<hr>
36163<h3><a name="814"></a>814. <tt>vector&lt;bool&gt;::swap(reference, reference)</tt> not defined</h3>
36164<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#WP">WP</a>
36165 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-03-17  <b>Last modified:</b> 2009-07-18</p>
36166<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>
36167<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
36168<p><b>Discussion:</b></p>
36169<p>
36170<tt>vector&lt;bool&gt;::swap(reference, reference)</tt> has no definition.
36171</p>
36172
36173<p><i>[
36174San Francisco:
36175]</i></p>
36176
36177
36178<blockquote>
36179Move to Open. Alisdair to provide a resolution.
36180</blockquote>
36181
36182<p><i>[
36183Post Summit Daniel provided wording.
36184]</i></p>
36185
36186
36187<p><i>[
36188Batavia (2009-05):
36189]</i></p>
36190
36191<blockquote>
36192We agree with the proposed resolution.
36193Move to Tentatively Ready.
36194</blockquote>
36195
36196
36197<p><b>Proposed resolution:</b></p>
36198<p>
36199Just after 23.3.7 [vector.bool]/5 add the following prototype and description:
36200</p>
36201
36202<blockquote>
36203<p>
36204<ins>static void swap(reference x, reference y);</ins>
36205</p>
36206<blockquote>
36207<p>
36208<ins>-6- <i>Effects:</i> Exchanges the contents of <tt>x</tt> and <tt>y</tt> as-if</ins> by:
36209</p>
36210<blockquote><pre><ins>
36211bool b = x;
36212x = y;
36213y = b;
36214</ins></pre></blockquote>
36215</blockquote>
36216</blockquote>
36217
36218
36219
36220
36221
36222<hr>
36223<h3><a name="818"></a>818. wording for memory ordering</h3>
36224<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>
36225 <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2008-03-22  <b>Last modified:</b> 2008-09-26</p>
36226<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>
36227<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
36228<p><b>Discussion:</b></p>
36229<p>
3623029.3 [atomics.order] p1 says in the table that
36231</p>
36232
36233<blockquote>
36234<table border="1">
36235<tbody><tr>
36236<th>Element</th><th>Meaning</th>
36237</tr>
36238<tr>
36239<td><tt>memory_order_acq_rel</tt></td>
36240<td>the operation has both acquire and release semantics</td>
36241</tr>
36242</tbody></table>
36243</blockquote>
36244
36245<p>
36246To my naked eye, that seems to imply that even an atomic read has both
36247acquire and release semantics.
36248</p>
36249
36250<p>
36251Then, p1 says in the table:
36252</p>
36253
36254<blockquote>
36255<table border="1">
36256<tbody><tr>
36257<th>Element</th><th>Meaning</th>
36258</tr>
36259<tr>
36260<td><tt>memory_order_seq_cst</tt></td>
36261<td>the operation has both acquire and release semantics,
36262    and, in addition, has sequentially-consistent operation ordering</td>
36263</tr>
36264</tbody></table>
36265</blockquote>
36266
36267<p>
36268So that seems to be "the same thing" as <tt>memory_order_acq_rel</tt>, with additional
36269constraints.
36270</p>
36271
36272<p>
36273I'm then reading p2, where it says:
36274</p>
36275
36276<blockquote>
36277The <tt>memory_order_seq_cst</tt> operations that load a value are acquire operations
36278on the affected locations. The <tt>memory_order_seq_cst</tt> operations that store a value
36279are release operations on the affected locations.
36280</blockquote>
36281
36282<p>
36283That seems to imply that atomic reads only have acquire semantics.  If that
36284is intended, does this also apply to <tt>memory_order_acq_rel</tt> and the individual
36285load/store operations as well?
36286</p>
36287
36288<p>
36289Also, the table in p1 contains phrases with "thus" that seem to indicate
36290consequences of normative wording in 1.10 [intro.multithread].  That shouldn't be in
36291normative text, for the fear of redundant or inconsistent specification with
36292the other normative text.
36293</p>
36294
36295<p>
36296Double-check 29.6 [atomics.types.operations] that each
36297operation clearly says whether it's a load or a store operation, or
36298both.  (It could be clearer, IMO.  Solution not in current proposed resolution.)
36299</p>
36300
36301<p>
3630229.3 [atomics.order] p2:  What's a "consistent execution"?  It's not defined in
363031.10 [intro.multithread], it's just used in notes there.
36304</p>
36305
36306<p>
36307And why does 29.6 [atomics.types.operations] p9 for "load" say:
36308</p>
36309
36310
36311<blockquote>
36312<i>Requires:</i> The order argument shall not be <tt>memory_order_acquire</tt>
36313nor <tt>memory_order_acq_rel</tt>.
36314</blockquote>
36315
36316<p>
36317(Since this is exactly the same restriction as for "store", it seems to be a typo.)
36318</p>
36319
36320<p>
36321And then: 29.6 [atomics.types.operations] p12:
36322</p>
36323
36324<blockquote>
36325These operations are read-modify-write operations in the sense of the
36326"synchronizes with" definition (1.10 [intro.multithread]), so both such an operation and the
36327evaluation that produced the input value synchronize with any evaluation
36328that reads the updated value.
36329</blockquote>
36330
36331<p>
36332This is redundant with 1.10 [intro.multithread], see above for the reasoning.
36333</p>
36334
36335<p><i>[
36336San Francisco:
36337]</i></p>
36338
36339
36340<blockquote>
36341<p>
36342Boehm: "I don't think that this changes anything terribly substantive,
36343but it improves the text."
36344</p>
36345<p>
36346Note that "Rephrase the table in as [sic] follows..." should read
36347"Replace the table in [atomics.order] with the following...."
36348</p>
36349<p>
36350The proposed resolution needs more work. Crowl volunteered to address
36351all of the atomics issues in one paper.
36352</p>
36353
36354<p>
36355This issue is addressed in
36356<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2783.html">N2783</a>.
36357</p>
36358</blockquote>
36359
36360
36361<p><b>Proposed resolution:</b></p>
36362<p>
36363edit 29.3 [atomics.order], paragraph 1 as follows.
36364</p>
36365
36366<blockquote>
36367<p>
36368The enumeration <code>memory_order</code>
36369specifies the detailed regular (non-atomic) memory synchronization order
36370as defined in <del>Clause 1.7</del> <ins>section 1.10</ins>
36371and may provide for operation ordering.
36372Its enumerated values and their meanings are as follows:
36373</p>
36374<blockquote>
36375<dl>
36376<dt><ins>For <code>memory_order_relaxed</code>,</ins></dt>
36377<dd><ins>no operation orders memory.</ins></dd>
36378<dt><ins>For <code>memory_order_release</code>,
36379<code>memory_order_acq_rel</code>,
36380and <code>memory_order_seq_cst</code>,</ins></dt>
36381<dd><ins>a store operation performs a release operation
36382on the affected memory location.</ins></dd>
36383<dt><ins>For <code>memory_order_consume</code>,</ins></dt>
36384<dd><ins>a load operation performs a consume operation
36385on the affected memory location.</ins></dd>
36386<dt><ins>For <code>memory_order_acquire</code>,
36387<code>memory_order_acq_rel</code>,
36388and <code>memory_order_seq_cst</code>,</ins></dt>
36389<dd><ins>a load operation performs an acquire operation
36390on the affected memory location.</ins></dd>
36391</dl>
36392</blockquote>
36393</blockquote>
36394
36395<p>
36396remove table 136 in 29.3 [atomics.order].
36397</p>
36398
36399<blockquote>
36400<table border="1">
36401<caption><del>Table 136 &#8212; memory_order effects</del></caption>
36402<tbody><tr><th><del>Element</del></th><th><del>Meaning</del></th></tr>
36403<tr><td valign="top"><del><code>memory_order_relaxed</code></del></td>
36404<td valign="top"><del>the operation does not order memory</del></td></tr>
36405<tr><td valign="top"><del><code>memory_order_release</code></del></td>
36406<td valign="top"><del>the operation
36407performs a release operation on the affected memory location,
36408thus making regular memory writes visible to other threads
36409through the atomic variable to which it is applied</del></td></tr>
36410<tr><td valign="top"><del><code>memory_order_acquire</code></del></td>
36411<td valign="top"><del>the operation
36412performs an acquire operation on the affected memory location,
36413thus making regular memory writes in other threads
36414released through the atomic variable to which it is applied
36415visible to the current thread</del></td></tr>
36416<tr><td valign="top"><del><code>memory_order_consume</code></del></td>
36417<td valign="top"><del>the operation
36418performs a consume operation on the affected memory location,
36419thus making regular memory writes in other threads
36420released through the atomic variable to which it is applied
36421visible to the regular memory reads
36422that are dependencies of this consume operation.</del></td></tr>
36423<tr><td valign="top"><del><code>memory_order_acq_rel</code></del></td>
36424<td valign="top"><del>the operation has both acquire and release semantics</del></td></tr>
36425<tr><td valign="top"><del><code>memory_order_seq_cst</code></del></td>
36426<td valign="top"><del>the operation has both acquire and release semantics,
36427and, in addition, has sequentially-consistent operation ordering</del></td></tr>
36428</tbody></table>
36429</blockquote>
36430
36431<p>
36432edit 29.3 [atomics.order], paragraph 2 as follows.
36433</p>
36434
36435<blockquote>
36436<p>
36437<del>The <code>memory_order_seq_cst</code> operations that load a value
36438are acquire operations on the affected locations.
36439The <code>memory_order_seq_cst</code> operations that store a value
36440are release operations on the affected locations.
36441In addition, in a consistent execution,
36442there</del> <ins>There</ins> <del>must be</del> <ins>is</ins>
36443a single total order <var>S</var>
36444on all <code>memory_order_seq_cst</code> operations,
36445consistent with the happens before order
36446and modification orders for all affected locations,
36447such that each <code>memory_order_seq_cst</code> operation
36448observes either the last preceding modification
36449according to this order <var>S</var>,
36450or the result of an operation that is not <code>memory_order_seq_cst</code>.
36451[<i>Note:</i>
36452Although it is not explicitly required that <var>S</var> include locks,
36453it can always be extended to an order
36454that does include lock and unlock operations,
36455since the ordering between those
36456is already included in the happens before ordering.
36457&#8212;<i>end note</i>]
36458</p>
36459</blockquote>
36460
36461
36462
36463
36464
36465
36466<hr>
36467<h3><a name="820"></a>820. <tt>current_exception()</tt>'s interaction with throwing copy ctors</h3>
36468<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>
36469 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2008-03-26  <b>Last modified:</b> 2008-09-26</p>
36470<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>
36471<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>
36472<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
36473<p><b>Discussion:</b></p>
36474<p>
36475As of N2521, the Working Paper appears to be silent about what
36476<tt>current_exception()</tt> should do if it tries to copy the currently handled
36477exception and its copy constructor throws.  18.8.5 [propagation]/7 says "If the
36478function needs to allocate memory and the attempt fails, it returns an
36479<tt>exception_ptr</tt> object that refers to an instance of <tt>bad_alloc</tt>.", but
36480doesn't say anything about what should happen if memory allocation
36481succeeds but the actual copying fails.
36482</p>
36483
36484<p>
36485I see three alternatives: (1) return an <tt>exception_ptr</tt> object that refers
36486to an instance of some fixed exception type, (2) return an <tt>exception_ptr</tt>
36487object that refers to an instance of the copy ctor's thrown exception
36488(but if that has a throwing copy ctor, an infinite loop can occur), or
36489(3) call <tt>terminate()</tt>.
36490</p>
36491
36492<p>
36493I believe that <tt>terminate()</tt> is the most reasonable course of action, but
36494before we go implement that, I wanted to raise this issue.
36495</p>
36496
36497<p><i>[
36498Peter's summary:
36499]</i></p>
36500
36501
36502<blockquote>
36503<p>
36504The current practice is to not have throwing copy constructors in
36505exception classes, because this can lead to <tt>terminate()</tt> as described in
3650615.5.1 [except.terminate]. Thus calling <tt>terminate()</tt> in this situation seems
36507consistent and does not introduce any new problems.
36508</p>
36509
36510<p>
36511However, the resolution of core issue 475 may relax this requirement:
36512</p>
36513
36514<blockquote>
36515The CWG agreed with the position that <tt>std::uncaught_exception()</tt> should
36516return <tt>false</tt> during the copy to the exception object and that <tt>std::terminate()</tt>
36517should not be called if that constructor exits with an exception.
36518</blockquote>
36519
36520<p>
36521Since throwing copy constructors will no longer call <tt>terminate()</tt>, option
36522(3) doesn't seem reasonable as it is deemed too drastic a response in a
36523recoverable situation.
36524</p>
36525
36526<p>
36527Option (2) cannot be adopted by itself, because a potential infinite
36528recursion will need to be terminated by one of the other options.
36529</p>
36530
36531</blockquote>
36532
36533
36534<p><b>Proposed resolution:</b></p>
36535<p>
36536Add the following paragraph after 18.8.5 [propagation]/7:
36537</p>
36538
36539<blockquote>
36540<p>
36541<i>Returns (continued):</i> If the attempt to copy the current exception
36542object throws an exception, the function returns an <tt>exception_ptr</tt> that
36543refers to the thrown exception or, if this is not possible, to an
36544instance of <tt>bad_exception</tt>.
36545</p>
36546<p>
36547[<i>Note:</i> The copy constructor of the thrown exception may also fail, so
36548the implementation is allowed to substitute a <tt>bad_exception</tt> to avoid
36549infinite recursion. <i>-- end note.</i>]
36550</p>
36551</blockquote>
36552
36553
36554
36555<p><b>Rationale:</b></p>
36556<p><i>[
36557San Francisco:
36558]</i></p>
36559
36560
36561<blockquote>
36562<p>
36563Pete: there may be an implied assumption in the proposed wording that
36564current_exception() copies the existing exception object; the
36565implementation may not actually do that.
36566</p>
36567<p>
36568Pete will make the required editorial tweaks to rectify this.
36569</p>
36570</blockquote>
36571
36572
36573
36574
36575
36576<hr>
36577<h3><a name="821"></a>821. Minor cleanup : <tt>unique_ptr</tt></h3>
36578<p><b>Section:</b> 20.8.14.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>
36579 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-03-30  <b>Last modified:</b> 2009-03-09</p>
36580<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
36581<p><b>Discussion:</b></p>
36582<p>
36583Reading 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:
36584</p>
36585
36586<blockquote>
36587<pre>void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);
36588</pre>
36589
36590<p>
36591-1- <i>Requires:</i> Does not accept pointer types which are convertible
36592to <del><tt>T*</tt></del> <ins><tt>pointer</tt></ins> (diagnostic
36593required). [<i>Note:</i> One implementation technique is to create a private
36594templated overload. <i>-- end note</i>]
36595</p>
36596</blockquote>
36597
36598<p>
36599This could be cleaned up by mandating the overload as a public deleted
36600function.  In addition, we should probably overload <tt>reset</tt> on <tt>nullptr_t</tt>
36601to be a stronger match than the deleted overload. Words...
36602</p>
36603
36604
36605<p><b>Proposed resolution:</b></p>
36606<p>
36607Add to class template definition in 20.8.14.3 [unique.ptr.runtime]
36608</p>
36609
36610<blockquote>
36611<pre>// modifiers 
36612pointer release(); 
36613void reset(pointer p = pointer()); 
36614<ins>void reset( nullptr_t );</ins>
36615<ins>template&lt; typename U &gt; void reset( U ) = delete;</ins>
36616void swap(unique_ptr&amp;&amp; u);
36617</pre>
36618</blockquote>
36619
36620<p>
36621Update 20.8.14.3.3 [unique.ptr.runtime.modifiers]
36622</p>
36623
36624<blockquote>
36625<pre>void reset(pointer p = pointer());
36626<ins>void reset(nullptr_t);</ins>
36627</pre>
36628
36629<p>
36630<del>-1- <i>Requires:</i> Does not accept pointer types which are convertible
36631to <tt>pointer</tt> (diagnostic
36632required). [<i>Note:</i> One implementation technique is to create a private
36633templated overload. <i>-- end note</i>]</del>
36634</p>
36635<p>
36636<i>Effects:</i> If <tt>get() == nullptr</tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>. 
36637</p>
36638<p>...</p>
36639</blockquote>
36640
36641<p><i>[
36642Note 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).
36643]</i></p>
36644
36645
36646
36647
36648
36649
36650<hr>
36651<h3><a name="822"></a>822. Object with explicit copy constructor no longer <tt>CopyConstructible</tt></h3>
36652<p><b>Section:</b> 20.2.1 [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
36653 <b>Submitter:</b> James Kanze <b>Opened:</b> 2008-04-01  <b>Last modified:</b> 2009-10-26</p>
36654<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>
36655<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>
36656<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
36657<p><b>Discussion:</b></p>
36658<p>
36659I just noticed that the following program is legal in C++03, but
36660is forbidden in the current draft:
36661</p>
36662
36663<blockquote><pre>#include &lt;vector&gt;
36664#include &lt;iostream&gt;
36665
36666class Toto
36667{
36668public:
36669    Toto() {}
36670    explicit Toto( Toto const&amp; ) {}
36671} ;
36672
36673int
36674main()
36675{
36676    std::vector&lt; Toto &gt; v( 10 ) ;
36677    return 0 ;
36678}
36679</pre></blockquote>
36680
36681<p>
36682Is this change intentional?  (And if so, what is the
36683justification?  I wouldn't call such code good, but I don't see
36684any reason to break it unless we get something else in return.)
36685</p>
36686
36687<p><i>[
36688San Francisco:
36689]</i></p>
36690
36691
36692<blockquote>
36693The subgroup that looked at this felt this was a good change, but it may
36694already be handled by incoming concepts (we're not sure).
36695</blockquote>
36696
36697<p><i>[
36698Post Summit:
36699]</i></p>
36700
36701
36702<blockquote>
36703<p>
36704Alisdair: Proposed resolution kinda funky as these tables no longer
36705exist. Move from direct init to copy init. Clarify with Doug, recommends
36706NAD.
36707</p>
36708<p>
36709Walter: Suggest NAD via introduction of concepts.
36710</p>
36711<p>
36712Recommend close as NAD.
36713</p>
36714</blockquote>
36715
36716<p><i>[
367172009-07 Frankfurt:
36718]</i></p>
36719
36720
36721<blockquote>
36722Need to look at again without concepts.
36723</blockquote>
36724
36725<p><i>[
367262009-07 Frankfurt:
36727]</i></p>
36728
36729
36730<blockquote>
36731<p>
36732Move to Ready with original proposed resolution.
36733</p>
36734<p><i>[Howard:  Original proposed resolution restored.]</i></p>
36735
36736</blockquote>
36737
36738
36739
36740<p><b>Proposed resolution:</b></p>
36741<p>
36742In 20.2.1 [utility.arg.requirements] change Table 33: <tt>MoveConstructible</tt> requirements [moveconstructible]:
36743</p>
36744
36745<blockquote>
36746<table border="1">
36747<tbody><tr>
36748<th>expression</th><th>post-condition</th>
36749</tr>
36750<tr>
36751<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>
36752</tr>
36753<tr>
36754<td colspan="2" align="center">...</td>
36755</tr>
36756</tbody></table>
36757</blockquote>
36758
36759<p>
36760In 20.2.1 [utility.arg.requirements] change Table 34: <tt>CopyConstructible</tt> requirements [copyconstructible]:
36761</p>
36762
36763<blockquote>
36764<table border="1">
36765<tbody><tr>
36766<th>expression</th><th>post-condition</th>
36767</tr>
36768<tr>
36769<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>
36770</tr>
36771<tr>
36772<td colspan="2" align="center">...</td>
36773</tr>
36774</tbody></table>
36775</blockquote>
36776
36777
36778
36779
36780
36781<hr>
36782<h3><a name="824"></a>824. rvalue ref issue with <tt>basic_string</tt> inserter</h3>
36783<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>
36784 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-04-10  <b>Last modified:</b> 2008-09-26</p>
36785<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>
36786<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
36787<p><b>Discussion:</b></p>
36788<p>
36789In the current working paper, the <tt>&lt;string&gt;</tt> header synopsis at the end of
3679021.3 [string.classes] lists a single <tt>operator&lt;&lt;</tt> overload
36791for <tt>basic_string</tt>.
36792</p>
36793
36794<blockquote><pre>template&lt;class charT, class traits, class Allocator&gt;
36795 basic_ostream&lt;charT, traits&gt;&amp;
36796   operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp;&amp; os,
36797              const basic_string&lt;charT,traits,Allocator&gt;&amp; str);
36798</pre></blockquote>
36799
36800<p>
36801The definition in 21.4.8.9 [string.io] lists two:
36802</p>
36803
36804<blockquote><pre>template&lt;class charT, class traits, class Allocator&gt;
36805 basic_ostream&lt;charT, traits&gt;&amp;
36806   operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; os,
36807              const basic_string&lt;charT,traits,Allocator&gt;&amp; str);
36808
36809template&lt;class charT, class traits, class Allocator&gt;
36810 basic_ostream&lt;charT, traits&gt;&amp;
36811   operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp;&amp; os,
36812              const basic_string&lt;charT,traits,Allocator&gt;&amp; str);
36813</pre></blockquote>
36814
36815<p>
36816I believe the synopsis in 21.3 [string.classes] is correct, and the first of the two
36817signatures in 21.4.8.9 [string.io] should be deleted.
36818</p>
36819
36820
36821<p><b>Proposed resolution:</b></p>
36822<p>
36823Delete the first of the two signatures in 21.4.8.9 [string.io]:
36824</p>
36825
36826<blockquote><pre><del>template&lt;class charT, class traits, class Allocator&gt;
36827 basic_ostream&lt;charT, traits&gt;&amp;
36828   operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; os,
36829              const basic_string&lt;charT,traits,Allocator&gt;&amp; str);</del>
36830
36831template&lt;class charT, class traits, class Allocator&gt;
36832 basic_ostream&lt;charT, traits&gt;&amp;
36833   operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp;&amp; os,
36834              const basic_string&lt;charT,traits,Allocator&gt;&amp; str);
36835</pre></blockquote>
36836
36837
36838
36839
36840
36841<hr>
36842<h3><a name="829"></a>829. current_exception wording unclear about exception type</h3>
36843<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>
36844 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2008-04-20  <b>Last modified:</b> 2008-09-26</p>
36845<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>
36846<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>
36847<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
36848<p><b>Discussion:</b></p>
36849<p>Consider this code:</p>
36850
36851<blockquote>
36852<pre>exception_ptr xp;</pre>
36853<pre>try {do_something(); }
36854
36855catch (const runtime_error&amp; ) {xp = current_exception();}
36856
36857...
36858
36859rethrow_exception(xp);</pre>
36860</blockquote>
36861
36862<p>
36863Say <code>do_something()</code> throws an exception object of type <code>
36864range_error</code>. What is the type of the exception object thrown by <code>
36865rethrow_exception(xp)</code> above? It must have a type of <code>range_error</code>; 
36866if it were of type <code>runtime_error</code> it still isn't possible to 
36867propagate an exception and the exception_ptr/current_exception/rethrow_exception 
36868machinery serves no useful purpose.
36869</p>
36870
36871<p>
36872Unfortunately, the current wording does not explicitly say that. Different 
36873people read the current wording and come to different conclusions. While it may 
36874be possible to deduce the correct type from the current wording, it would be 
36875much clearer to come right out and explicitly say what the type of the referred 
36876to exception is.
36877</p>
36878
36879<p><i>[
36880Peter adds:
36881]</i></p>
36882
36883
36884<blockquote>
36885<p>
36886I don't like the proposed resolution of 829. The normative text is
36887unambiguous that the <tt>exception_ptr</tt> refers to the <em>currently handled
36888exception</em>. This term has a standard meaning, see 15.3 [except.handle]/8; this is the
36889exception that <tt>throw;</tt> would rethrow, see 15.1 [except.throw]/7.
36890</p>
36891<p>
36892A better way to address this is to simply add the non-normative example
36893in question as a clarification. The term <i>currently handled exception</i>
36894should be italicized and cross-referenced. A [<i>Note:</i> the currently
36895handled exception is the exception that a throw expression without an
36896operand (15.1 [except.throw]/7) would rethrow. <i>--end note</i>] is also an option.
36897</p>
36898</blockquote>
36899
36900
36901
36902<p><b>Proposed resolution:</b></p>
36903
36904<p>
36905After 18.8.5 [propagation] , paragraph 7, add the indicated text:
36906</p>
36907
36908<blockquote>
36909<pre>exception_ptr current_exception();</pre>
36910
36911<blockquote>
36912<p>
36913<i>Returns:</i> <code>exception_ptr</code> object that refers 
36914to the currently handled exception <ins>(15.3 [except.handle])</ins> or a copy of the currently handled 
36915exception, or a null <code>exception_ptr</code> object if no exception is being handled. If 
36916the function needs to allocate memory and the attempt fails, it returns an
36917<code>exception_ptr</code> object that refers to an instance of <code>bad_alloc</code>. 
36918It is unspecified whether the return values of two successive calls to
36919<code>current_exception</code> refer to the same exception object. 
36920[<i>Note:</i> that is, it 
36921is unspecified whether <code>current_exception</code>
36922creates a new copy each time it is called.
36923<i>-- end note</i>]
36924</p>
36925
36926<p>
36927<i>Throws:</i> nothing.
36928</p>
36929
36930</blockquote>
36931</blockquote>
36932
36933
36934
36935
36936
36937
36938<hr>
36939<h3><a name="838"></a>838. 
36940   can an <i>end-of-stream</i> iterator become a <i>non-end-of-stream</i> one?
36941 </h3>
36942<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#WP">WP</a>
36943 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2008-05-17  <b>Last modified:</b> 2009-10-26</p>
36944<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>
36945<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
36946<p><b>Discussion:</b></p>
36947   <p>
36948
36949From message c++std-lib-20003...
36950
36951   </p>
36952   <p>
36953
36954The description of <code>istream_iterator</code> in
3695524.6.1 [istream.iterator], p1 specifies that objects of the
36956class become the <i>end-of-stream</i> (EOS) iterators under the
36957following condition (see also issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#788">788</a> another problem
36958with this paragraph):
36959
36960   </p>
36961   <blockquote>
36962
36963If the end of stream is reached (<code>operator void*()</code> on the
36964stream returns <code>false</code>), the iterator becomes equal to
36965the <i>end-of-stream</i> iterator value.
36966
36967   </blockquote>
36968   <p>
36969
36970One possible implementation approach that has been used in practice is
36971for the iterator to set its <code>in_stream</code> pointer to 0 when
36972it reaches the end of the stream, just like the default ctor does on
36973initialization. The problem with this approach is that
36974the <i>Effects</i> clause for <code>operator++()</code> says the
36975iterator unconditionally extracts the next value from the stream by
36976evaluating <code>*in_stream &gt;&gt; value</code>, without checking
36977for <code>(in_stream == 0)</code>.
36978
36979   </p>
36980   <p>
36981
36982Conformance to the requirement outlined in the <i>Effects</i> clause
36983can easily be verified in programs by setting <code>eofbit</code>
36984or <code>failbit</code> in <code>exceptions()</code> of the associated
36985stream and attempting to iterate past the end of the stream: each
36986past-the-end access should trigger an exception. This suggests that
36987some other, more elaborate technique might be intended.
36988
36989   </p>
36990   <p>
36991
36992Another approach, one that allows <code>operator++()</code> to attempt
36993to extract the value even for EOS iterators (just as long
36994as <code>in_stream</code> is non-0) is for the iterator to maintain a
36995flag indicating whether it has reached the end of the stream. This
36996technique would satisfy the presumed requirement implied by
36997the <i>Effects</i> clause mentioned above, but it isn't supported by
36998the exposition-only members of the class (no such flag is shown). This
36999approach is also found in existing practice.
37000
37001   </p>
37002   <p>
37003
37004The inconsistency between existing implementations raises the question
37005of whether the intent of the specification is that a non-EOS iterator
37006that has reached the EOS become a non-EOS one again after the
37007stream's <code>eofbit</code> flag has been cleared? That is, are the
37008assertions in the program below expected to pass?
37009
37010   </p>
37011   <blockquote>
37012     <pre>   sstream strm ("1 ");
37013   istream_iterator eos;
37014   istream_iterator it (strm);
37015   int i;
37016   i = *it++
37017   assert (it == eos);
37018   strm.clear ();
37019   strm &lt;&lt; "2 3 ";
37020   assert (it != eos);
37021   i = *++it;
37022   assert (3 == i);
37023     </pre>
37024   </blockquote>
37025   <p>
37026
37027Or is it intended that once an iterator becomes EOS it stays EOS until
37028the end of its lifetime?
37029
37030   </p>
37031 
37032 <p><i>[
37033San Francisco:
37034]</i></p>
37035
37036
37037<blockquote>
37038<p>
37039We like the direction of the proposed resolution. We're not sure about
37040the wording, and we need more time to reflect on it,
37041</p>
37042<p>
37043Move to Open. Detlef to rewrite the proposed resolution in such a way
37044that no reference is made to exposition only members of
37045<tt>istream_iterator</tt>.
37046</p>
37047</blockquote>
37048
37049<p><i>[
370502009-07 Frankfurt:
37051]</i></p>
37052
37053
37054<blockquote>
37055Move to Ready.
37056</blockquote>
37057
37058
37059
37060 <p><b>Proposed resolution:</b></p>
37061   <p>
37062
37063The discussion of this issue on the reflector suggests that the intent
37064of the standard is for an <code>istreambuf_iterator</code> that has
37065reached the EOS to remain in the EOS state until the end of its
37066lifetime. Implementations that permit EOS iterators to return to a
37067non-EOS state may only do so as an extension, and only as a result of
37068calling <code>istream_iterator</code> member functions on EOS
37069iterators whose behavior is in this case undefined.
37070
37071   </p>
37072   <p>
37073
37074To this end we propose to change 24.6.1 [istream.iterator], p1,
37075as follows:
37076
37077   </p>
37078   <blockquote>
37079
37080The result of operator-&gt; on an end<ins>-</ins>of<ins>-</ins>stream
37081is not defined. For any other iterator value a <code>const T*</code>
37082is returned.<ins> Invoking <code>operator++()</code> on
37083an <i>end-of-stream</i> iterator is undefined.</ins> It is impossible
37084to store things into istream iterators...
37085
37086   </blockquote>
37087   <p>
37088
37089Add pre/postconditions to the member function descriptions of <code>istream_iterator</code> like so:
37090
37091   </p>
37092   <blockquote>
37093
37094<pre>istream_iterator();</pre>
37095
37096<i>Effects</i>: Constructs the <i>end-of-stream</i> iterator.<br>
37097<ins><i>Postcondition</i>: <code>in_stream == 0</code>.</ins>
37098
37099<pre>istream_iterator(istream_type &amp;s);</pre>
37100
37101<i>Effects</i>: Initializes <code>in_stream</code> with &amp;s. value
37102may be initialized during construction or the first time it is
37103referenced.<br>
37104<ins><i>Postcondition</i>: <code>in_stream == &amp;s</code>.</ins>
37105
37106<pre>istream_iterator(const istream_iterator &amp;x);</pre>
37107
37108<i>Effects</i>: Constructs a copy of <code>x</code>.<br>
37109<ins><i>Postcondition</i>: <code>in_stream == x.in_stream</code>.</ins>
37110
37111<pre>istream_iterator&amp; operator++();</pre>
37112
37113<ins><i>Requires</i>: <code>in_stream != 0</code>.</ins><br>
37114<i>Effects</i>: <code>*in_stream &gt;&gt; value</code>.
37115
37116<pre>istream_iterator&amp; operator++(int);</pre>
37117
37118<ins><i>Requires</i>: <code>in_stream != 0</code>.</ins><br>
37119<i>Effects</i>:
37120   <blockquote><pre>istream_iterator tmp (*this);
37121*in_stream &gt;&gt; value;
37122return tmp;
37123     </pre>
37124     </blockquote>
37125   </blockquote>
37126 
37127
37128
37129
37130<hr>
37131<h3><a name="842"></a>842. ConstructibleAsElement and bit containers</h3>
37132<p><b>Section:</b> 23.2 [container.requirements], 23.3.7 [vector.bool], 20.3.7 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
37133 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2008-06-03  <b>Last modified:</b> 2008-09-26</p>
37134<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>
37135<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>
37136<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
37137<p><b>Discussion:</b></p>
37138<p>
3713923.2 [container.requirements]/p3 says:
37140</p>
37141
37142<blockquote>
37143Objects stored in these components shall be constructed using
37144<tt>construct_element</tt> (20.6.9). For each operation that inserts an
37145element of type <tt>T</tt> into a container (<tt>insert</tt>,
37146<tt>push_back</tt>, <tt>push_front</tt>, <tt>emplace</tt>, etc.) with
37147arguments <tt>args... T</tt> shall be <tt>ConstructibleAsElement</tt>,
37148as described in table 88. [<i>Note:</i> If the component is instantiated
37149with a scoped allocator of type <tt>A</tt> (i.e., an allocator for which
37150<tt>is_scoped_allocator&lt;A&gt;::value</tt> is <tt>true</tt>), then
37151<tt>construct_element</tt> may pass an inner allocator argument to
37152<tt>T</tt>'s constructor. <i>-- end note</i>]
37153</blockquote>
37154
37155<p>
37156However <tt>vector&lt;bool, A&gt;</tt> (23.3.7 [vector.bool]) and <tt>bitset&lt;N&gt;</tt> 
37157(20.3.7 [template.bitset]) store bits, not <tt>bool</tt>s, and <tt>bitset&lt;N&gt;</tt>
37158does not even have an allocator.  But these containers are governed by this clause.  Clearly this
37159is not implementable.
37160</p>
37161
37162
37163<p><b>Proposed resolution:</b></p>
37164<p>
37165Change 23.2 [container.requirements]/p3:
37166</p>
37167
37168<blockquote>
37169Objects stored in these components shall be constructed using
37170<tt>construct_element</tt> (20.6.9)<ins>, unless otherwise specified</ins>.
37171For each operation that inserts an
37172element of type <tt>T</tt> into a container (<tt>insert</tt>,
37173<tt>push_back</tt>, <tt>push_front</tt>, <tt>emplace</tt>, etc.) with
37174arguments <tt>args... T</tt> shall be <tt>ConstructibleAsElement</tt>,
37175as described in table 88. [<i>Note:</i> If the component is instantiated
37176with a scoped allocator of type <tt>A</tt> (i.e., an allocator for which
37177<tt>is_scoped_allocator&lt;A&gt;::value</tt> is <tt>true</tt>), then
37178<tt>construct_element</tt> may pass an inner allocator argument to
37179<tt>T</tt>'s constructor. <i>-- end note</i>]
37180</blockquote>
37181
37182<p>
37183Change 23.3.7 [vector.bool]/p2:
37184</p>
37185
37186<blockquote>
37187Unless described below, all operations have the same requirements and semantics as the primary <tt>vector</tt> template, 
37188except that operations dealing with the <tt>bool</tt> value type map to bit values in the container storage<ins>,
37189and <tt>construct_element</tt> (23.2 [container.requirements]) is not used to construct these values</ins>.
37190</blockquote>
37191
37192<p>
37193Move 20.3.7 [template.bitset] to clause 20.
37194</p>
37195
37196
37197
37198
37199
37200
37201<hr>
37202<h3><a name="843"></a>843.  Reference Closure</h3>
37203<p><b>Section:</b> X [func.referenceclosure.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
37204 <b>Submitter:</b> Lawrence Crowl <b>Opened:</b> 2008-06-02  <b>Last modified:</b> 2008-09-26</p>
37205<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
37206<p><b>Discussion:</b></p>
37207<p>
37208The <tt>std::reference_closure</tt> type has a deleted copy assignment operator
37209under the theory that references cannot be assigned, and hence the
37210assignment of its reference member must necessarily be ill-formed.
37211</p>
37212<p>
37213However, other types, notably <tt>std::reference_wrapper</tt> and <tt>std::function</tt>
37214provide for the "copying of references", and thus the current definition
37215of <tt>std::reference_closure</tt> seems unnecessarily restrictive.  In particular,
37216it should be possible to write generic functions using both <tt>std::function</tt>
37217and <tt>std::reference_closure</tt>, but this generality is much harder when
37218one such type does not support assignment.
37219</p>
37220<p>
37221The definition of <tt>reference_closure</tt> does not necessarily imply direct
37222implementation via reference types.  Indeed, the <tt>reference_closure</tt> is
37223best implemented via a frame pointer, for which there is no standard
37224type.
37225</p>
37226<p>
37227The semantics of assignment are effectively obtained by use of the
37228default destructor and default copy assignment operator via
37229</p>
37230
37231<blockquote><pre>x.~reference_closure(); new (x) reference_closure(y);
37232</pre></blockquote>
37233
37234<p>
37235So the copy assignment operator generates no significant real burden
37236to the implementation.
37237</p>
37238
37239
37240<p><b>Proposed resolution:</b></p>
37241<p>
37242In  [func.referenceclosure] Class template reference_closure,
37243replace the <tt>=delete</tt> in the copy assignment operator in the synopsis
37244with <tt>=default</tt>.
37245</p>
37246
37247<blockquote><pre>template&lt;class R , class... ArgTypes &gt; 
37248  class reference_closure&lt;R (ArgTypes...)&gt; { 
37249  public:
37250     ...
37251     reference_closure&amp; operator=(const reference_closure&amp;) = <del>delete</del> <ins>default</ins>;
37252     ...
37253</pre></blockquote>
37254
37255<p>
37256In X [func.referenceclosure.cons] Construct, copy, destroy,
37257add the member function description
37258</p>
37259
37260<blockquote>
37261<pre>reference_closure&amp; operator=(const reference_closure&amp; f)
37262</pre>
37263<blockquote>
37264<p>
37265<i>Postcondition:</i> <tt>*this</tt> is a copy of <tt>f</tt>.
37266</p>
37267<p>
37268<i>Returns:</i> <tt>*this</tt>.
37269</p>
37270</blockquote>
37271</blockquote>
37272
37273
37274
37275
37276
37277
37278
37279<hr>
37280<h3><a name="844"></a>844. <tt>complex pow</tt> return type is ambiguous</h3>
37281<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>
37282 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2008-06-03  <b>Last modified:</b> 2009-03-21</p>
37283<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>
37284<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
37285<p><b>Discussion:</b></p>
37286<p>
37287The current working draft is in an inconsistent state.
37288</p>
37289
37290<p>
3729126.4.8 [complex.transcendentals] says that:
37292</p>
37293
37294<blockquote>
37295<tt>pow(complex&lt;float&gt;(), int())</tt> returns a <tt>complex&lt;float&gt;</tt>.
37296</blockquote>
37297
37298<p>
3729926.4.9 [cmplx.over] says that:
37300</p>
37301
37302<blockquote>
37303<tt>pow(complex&lt;float&gt;(), int())</tt> returns a <tt>complex&lt;double&gt;</tt>.
37304</blockquote>
37305
37306<p><i>[
37307Sophia Antipolis:
37308]</i></p>
37309
37310
37311<blockquote>
37312<p>
37313Since <tt>int</tt> promotes to <tt>double</tt>, and C99 doesn't have an <tt>int</tt>-based
37314overload for <tt>pow</tt>, the C99 result is <tt>complex&lt;double&gt;</tt>, see also C99
373157.22, see also library issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>.
37316</p>
37317<p>
37318Special note: ask P.J. Plauger.
37319</p>
37320<blockquote>
37321Looks fine.
37322</blockquote>
37323</blockquote>
37324
37325
37326<p><b>Proposed resolution:</b></p>
37327<p>
37328Strike this <tt>pow</tt> overload in 26.4.1 [complex.syn] and in 26.4.8 [complex.transcendentals]:
37329</p>
37330
37331<blockquote><pre><del>template&lt;class T&gt; complex&lt;T&gt; pow(const complex&lt;T&gt;&amp; x, int y);</del>
37332</pre></blockquote>
37333
37334
37335
37336
37337
37338<hr>
37339<h3><a name="845"></a>845. atomics cannot support aggregate initialization</h3>
37340<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>
37341 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-06-03  <b>Last modified:</b> 2008-09-26</p>
37342<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>
37343<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
37344<p><b>Discussion:</b></p>
37345<p>
37346The atomic classes (and class templates) are required to support aggregate
37347initialization (29.5.1 [atomics.types.integral]p2 / 29.5.2 [atomics.types.address]p1)
37348yet also have user declared constructors, so cannot be aggregates.
37349</p>
37350<p>
37351This problem might be solved with the introduction of the proposed
37352initialization syntax at Antipolis, but the wording above should be altered.
37353Either strike the sentence as redundant with new syntax, or refer to 'brace
37354initialization'.
37355</p>
37356
37357<p><i>[
37358Jens adds:
37359]</i></p>
37360
37361
37362<blockquote>
37363<p>
37364Note that
37365</p>
37366<blockquote><pre>atomic_itype a1 = { 5 };
37367</pre></blockquote>
37368<p>
37369would be aggregate-initialization syntax (now coming under the disguise
37370of brace initialization), but would be ill-formed, because the corresponding
37371constructor for atomic_itype is explicit.  This works, though:
37372</p>
37373<blockquote><pre>atomic_itype a2 { 6 };
37374</pre></blockquote>
37375
37376</blockquote>
37377
37378<p><i>[
37379San Francisco:
37380]</i></p>
37381
37382
37383<blockquote>
37384<p>
37385The preferred approach to resolving this is to remove the explicit
37386specifiers from the atomic integral type constructors.
37387</p>
37388<p>
37389Lawrence will provide wording.
37390</p>
37391<p>
37392This issue is addressed in
37393<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2783.html">N2783</a>.
37394</p>
37395</blockquote>
37396
37397
37398
37399<p><b>Proposed resolution:</b></p>
37400<p>
37401within the synopsis in 29.5.1 [atomics.types.integral] edit as follows.
37402</p>
37403
37404<blockquote><pre><code>
37405....
37406typedef struct atomic_bool {
37407....
37408  constexpr <del>explicit</del> atomic_bool(bool);
37409....
37410typedef struct atomic_<var>itype</var> {
37411....
37412  constexpr <del>explicit</del> atomic_<var>itype</var>(<var>integral</var>);
37413....
37414</code></pre></blockquote>
37415
37416<p>
37417edit 29.5.1 [atomics.types.integral] paragraph 2 as follows.
37418</p>
37419
37420<blockquote>
37421The atomic integral types shall have standard layout.
37422They shall each have a trivial default constructor,
37423a constexpr <del>explicit</del> value constructor,
37424a deleted copy constructor,
37425a deleted copy assignment operator,
37426and a trivial destructor.
37427They shall each support aggregate initialization syntax.
37428</blockquote>
37429
37430<p>
37431within the synopsis of 29.5.2 [atomics.types.address] edit as follows.
37432</p>
37433
37434<blockquote><pre><code>
37435....
37436typedef struct atomic_address {
37437....
37438  constexpr <del>explicit</del> atomic_address(void*);
37439....
37440</code></pre></blockquote>
37441
37442<p>
37443edit 29.5.2 [atomics.types.address] paragraph 1 as follows.
37444</p>
37445
37446<blockquote>
37447The type <code>atomic_address</code> shall have standard layout.
37448It shall have a trivial default constructor,
37449a constexpr <del>explicit</del> value constructor,
37450a deleted copy constructor,
37451a deleted copy assignment operator,
37452and a trivial destructor.
37453It shall support aggregate initialization syntax.
37454</blockquote>
37455
37456<p>
37457within the synopsis of 29.5.3 [atomics.types.generic] edit as follows.
37458</p>
37459
37460<blockquote><pre><code>
37461....
37462template &lt;class T&gt; struct atomic {
37463....
37464  constexpr <del>explicit</del> atomic(T);
37465....
37466template &lt;&gt; struct atomic&lt;<var>integral</var>&gt; : atomic_<var>itype</var> {
37467....
37468  constexpr <del>explicit</del> atomic(<var>integral</var>);
37469....
37470template &lt;&gt; struct atomic&lt;T*&gt; : atomic_address {
37471....
37472  constexpr <del>explicit</del> atomic(T*);
37473....
37474</code></pre></blockquote>
37475
37476<p>
37477edit 29.5.3 [atomics.types.generic] paragraph 2 as follows.
37478</p>
37479
37480<blockquote>
37481Specializations of the <code>atomic</code> template
37482shall have a deleted copy constructor,
37483a deleted copy assignment operator,
37484and a constexpr <del>explicit</del> value constructor.
37485</blockquote>
37486
37487
37488
37489
37490
37491
37492<hr>
37493<h3><a name="846"></a>846. No definition for constructor</h3>
37494<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>
37495 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-06-03  <b>Last modified:</b> 2008-09-26</p>
37496<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>
37497<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
37498<p><b>Discussion:</b></p>
37499<p>
37500The atomic classes and class templates (29.5.1 [atomics.types.integral] /
3750129.5.2 [atomics.types.address]) have a constexpr
37502constructor taking a value of the appropriate type for that atomic.
37503However, neither clause provides semantics or a definition for this
37504constructor.  I'm not sure if the initialization is implied by use of
37505constexpr keyword (which restricts the form of a constructor) but even if
37506that is the case, I think it is worth spelling out explicitly as the
37507inference would be far too subtle in that case.
37508</p>
37509
37510<p><i>[
37511San Francisco:
37512]</i></p>
37513
37514
37515<blockquote>
37516<p>
37517Lawrence will provide wording.
37518</p>
37519<p>
37520This issue is addressed in
37521<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2783.html">N2783</a>.
37522</p>
37523</blockquote>
37524
37525
37526<p><b>Proposed resolution:</b></p>
37527
37528<p>
37529before the description of ...<code>is_lock_free</code>,
37530that is before 29.6 [atomics.types.operations] paragraph 4,
37531add the following description.
37532</p>
37533
37534<blockquote>
37535<pre><code>
37536constexpr <var>A</var>::<var>A</var>(<var>C</var> desired);
37537</code></pre>
37538<dl>
37539<dt><i>Effects:</i></dt>
37540<dd>
37541Initializes the object with the value <code>desired</code>.
37542[<i>Note:</i>
37543Construction is not atomic.
37544&#8212;<i>end note</i>]
37545</dd>
37546</dl>
37547</blockquote>
37548
37549
37550
37551
37552
37553<hr>
37554<h3><a name="847"></a>847. string exception safety guarantees</h3>
37555<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#WP">WP</a>
37556 <b>Submitter:</b> Herv� Br�nnimann <b>Opened:</b> 2008-06-05  <b>Last modified:</b> 2009-10-26</p>
37557<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>
37558<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
37559<p><b>Discussion:</b></p>
37560<p>
37561In March, on comp.lang.c++.moderated, I asked what were the
37562string exception safety guarantees are, because I cannot see
37563*any* in the working paper, and any implementation I know offers
37564the strong exception safety guarantee (string unchanged if a
37565member throws exception). The closest the current draft comes to
37566offering any guarantees is 21.4 [basic.string], para 3:
37567</p>
37568
37569<blockquote>
37570The class template <tt>basic_string</tt> conforms to the requirements
37571for a Sequence Container (23.1.1), for a Reversible Container (23.1),
37572and for an Allocator-aware container (91). The iterators supported by
37573<tt>basic_string</tt> are random access iterators (24.1.5).
37574</blockquote>
37575
37576<p>
37577However, the chapter 23 only says, on the topic of exceptions:  23.2 [container.requirements],
37578para 10:
37579</p>
37580
37581<blockquote>
37582<p>
37583Unless otherwise specified (see 23.2.2.3 and 23.2.6.4) all container types defined in this clause meet the following 
37584additional requirements:
37585</p>
37586
37587<ul>
37588<li>if an exception is thrown by...</li>
37589</ul>
37590</blockquote>
37591
37592<p>
37593I take it  as saying that this paragraph has *no* implication on
37594<tt>std::basic_string</tt>, as <tt>basic_string</tt> isn't defined in Clause 23 and
37595this paragraph does not define a *requirement* of Sequence
37596nor Reversible Container, just of the models defined in Clause 23.
37597In addition, LWG Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#718">718</a> proposes to remove 23.2 [container.requirements], para 3.
37598</p>
37599
37600<p>
37601Finally, the fact that no operation on Traits should throw
37602exceptions has no bearing, except to suggest (since the only
37603other throws should be allocation, <tt>out_of_range</tt>, or <tt>length_error</tt>)
37604that the strong exception guarantee can be achieved.
37605</p>
37606
37607<p>
37608The reaction in that group by Niels Dekker, Martin Sebor, and
37609Bo Persson, was all that this would be worth an LWG issue.
37610</p>
37611
37612<p>
37613A related issue is that <tt>erase()</tt> does not throw.  This should be
37614stated somewhere (and again, I don't think that the 23.2 [container.requirements], para 1
37615applies here).
37616</p>
37617
37618<p><i>[
37619San Francisco:
37620]</i></p>
37621
37622
37623<blockquote>
37624Implementors will study this to confirm that it is actually possible.
37625</blockquote>
37626
37627<p><i>[
37628Daniel adds 2009-02-14:
37629]</i></p>
37630
37631
37632<blockquote>
37633The proposed resolution of paper
37634<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2815.html">N2815</a>
37635interacts with this issue (the paper does not refer to this issue).
37636</blockquote>
37637
37638<p><i>[
376392009-07 Frankfurt:
37640]</i></p>
37641
37642
37643<blockquote>
37644Move to Ready.
37645</blockquote>
37646
37647
37648
37649<p><b>Proposed resolution:</b></p>
37650<p>
37651Add a blanket statement in 21.4.1 [string.require]:
37652</p>
37653
37654<blockquote>
37655<p>
37656- if any member function or operator of <tt>basic_string&lt;charT, traits, Allocator&gt;</tt>
37657throws, that function or operator has no effect.
37658</p>
37659<p>
37660- no <tt>erase()</tt> or <tt>pop_back()</tt> function throws.
37661</p>
37662</blockquote>
37663
37664<p>
37665As far as I can tell, this is achieved by any implementation.  If I made a
37666mistake and it is not possible to offer this guarantee, then
37667either state all the functions for which this is possible
37668(certainly at least <tt>operator+=</tt>, <tt>append</tt>, <tt>assign</tt>, and <tt>insert</tt>),
37669or add paragraphs to Effects clauses wherever appropriate.
37670</p>
37671
37672
37673
37674
37675
37676<hr>
37677<h3><a name="848"></a>848. missing <tt>std::hash</tt> specializations for <tt>std::bitset/std::vector&lt;bool&gt;</tt></h3>
37678<p><b>Section:</b> 20.7.16 [unord.hash] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
37679 <b>Submitter:</b> Thorsten Ottosen <b>Opened:</b> 2008-06-05  <b>Last modified:</b> 2008-09-26</p>
37680<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>
37681<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>
37682<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
37683<p><b>Discussion:</b></p>
37684<p>
37685In the current working draft, <tt>std::hash&lt;T&gt;</tt> is specialized for builtin
37686types and a few other types. Bitsets seems like one that is missing from
37687the list, not because it cannot not be done by the user, but because it
37688is hard or impossible to write an efficient implementation that works on
3768932bit/64bit chunks at a time. For example, <tt>std::bitset</tt> is too much
37690encapsulated in this respect.
37691</p>
37692
37693
37694<p><b>Proposed resolution:</b></p>
37695<p>
37696Add the following to the synopsis in 20.7 [function.objects]/2:
37697</p>
37698
37699<blockquote><pre>template&lt;class Allocator&gt; struct hash&lt;std::vector&lt;bool,Allocator&gt;&gt;;
37700template&lt;size_t N&gt; struct hash&lt;std::bitset&lt;N&gt;&gt;;
37701</pre></blockquote>
37702
37703<p>
37704Modify the last sentence of 20.7.16 [unord.hash]/1 to end with:
37705</p>
37706
37707<blockquote>
37708... and <tt>std::string</tt>, <tt>std::u16string</tt>, <tt>std::u32string</tt>, <tt>std::wstring</tt>,
37709<tt>std::error_code</tt>, <tt>std::thread::id</tt>, <tt>std::bitset</tt>, <tt>and std::vector&lt;bool&gt;</tt>.
37710</blockquote>
37711
37712
37713
37714
37715
37716
37717<hr>
37718<h3><a name="850"></a>850. Should <tt>shrink_to_fit</tt> apply to <tt>std::deque</tt>?</h3>
37719<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>
37720 <b>Submitter:</b> Niels Dekker <b>Opened:</b> 2008-06-05  <b>Last modified:</b> 2008-09-26</p>
37721<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>
37722<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
37723<p><b>Discussion:</b></p>
37724<p>
37725Issue <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>.
37726It did not yet deal with <tt>std::deque</tt>, because of the fundamental
37727difference between <tt>std::deque</tt> and the other two container types. The
37728need for <tt>std::deque</tt> may seem less evident, because one might think that
37729for this container, the overhead is a small map, and some number of
37730blocks that's bounded by a small constant.
37731</p>
37732<p>
37733The container overhead can in fact be arbitrarily large (i.e. is not
37734necessarily O(N) where N is the number of elements currently held by the
37735<tt>deque</tt>).  As Bill Plauger noted in a reflector message, unless the map of
37736block pointers is shrunk, it must hold at least maxN/B pointers where
37737maxN is the maximum of N over the lifetime of the <tt>deque</tt> since its
37738creation.  This is independent of how the map is implemented
37739(<tt>vector</tt>-like circular buffer and all), and maxN bears no relation to N,
37740the number of elements it currently holds.
37741</p>
37742<p>
37743Herv� Br�nnimann reports a situation where a <tt>deque</tt> of requests grew very
37744large due to some temporary backup (the front request hanging), and the
37745map of the <tt>deque</tt> grew quite large before getting back to normal.  Just
37746to put some color on it, assuming a <tt>deque</tt> with 1K pointer elements in
37747steady regime, that held, at some point in its lifetime, maxN=10M
37748pointers, with one block holding 128 elements, the spine must be at
37749least (maxN / 128), in that case 100K.   In that case, shrink-to-fit
37750would allow to reuse about 100K which would otherwise never be reclaimed
37751in the lifetime of the <tt>deque</tt>.
37752</p>
37753<p>
37754An added bonus would be that it *allows* implementations to hang on to
37755empty blocks at the end (but does not care if they do or not).  A
37756<tt>shrink_to_fit</tt> would take care of both shrinks, and guarantee that at
37757most O(B) space is used in addition to the storage to hold the N
37758elements and the N/B block pointers.
37759</p>
37760
37761
37762<p><b>Proposed resolution:</b></p>
37763<p>
37764To Class template deque 23.3.2 [deque] synopsis, add:
37765</p>
37766<blockquote><pre>void shrink_to_fit();
37767</pre></blockquote>
37768
37769<p>
37770To deque capacity 23.3.2.2 [deque.capacity], add:
37771</p>
37772<blockquote><pre>void shrink_to_fit();
37773</pre>
37774
37775<blockquote>
37776<i>Remarks:</i> <tt>shrink_to_fit</tt> is a non-binding request to reduce memory
37777use. [<i>Note:</i> The request is non-binding to allow latitude for
37778implementation-specific optimizations. -- <i>end note</i>]
37779</blockquote>
37780</blockquote>
37781
37782
37783
37784
37785
37786<hr>
37787<h3><a name="852"></a>852. unordered containers <tt>begin(n)</tt> mistakenly <tt>const</tt></h3>
37788<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>
37789 <b>Submitter:</b> Robert Klarer <b>Opened:</b> 2008-06-12  <b>Last modified:</b> 2008-09-26</p>
37790<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>
37791<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
37792<p><b>Discussion:</b></p>
37793<p>
37794In 3 of the four unordered containers the local <tt>begin</tt> member is mistakenly declared <tt>const</tt>:
37795</p>
37796
37797<blockquote><pre>local_iterator begin(size_type n) const;
37798</pre></blockquote>
37799
37800
37801<p><b>Proposed resolution:</b></p>
37802<p>
37803Change the synopsis in 23.5.1 [unord.map], 23.5.2 [unord.multimap], and 23.5.4 [unord.multiset]:
37804</p>
37805
37806<blockquote><pre>local_iterator begin(size_type n)<del> const</del>;
37807</pre></blockquote>
37808
37809
37810
37811
37812
37813<hr>
37814<h3><a name="853"></a>853. <tt>to_string</tt> needs updating with <tt>zero</tt> and <tt>one</tt></h3>
37815<p><b>Section:</b> 20.3.7 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
37816 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2008-06-18  <b>Last modified:</b> 2009-07-18</p>
37817<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>
37818<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>
37819<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
37820<p><b>Discussion:</b></p>
37821<p>
37822Issue <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
37823the three newer <tt>to_string</tt> overloads.
37824</p>
37825
37826<p><i>[
37827post San Francisco:
37828]</i></p>
37829
37830
37831<blockquote>
37832Daniel found problems with the wording and provided fixes.  Moved from Ready
37833to Review.
37834</blockquote>
37835
37836<p><i>[
37837Post Summit:
37838]</i></p>
37839
37840
37841<blockquote>
37842<p>
37843Alisdair: suggest to not repeat the default arguments in B, C, D
37844(definition of to_string members)
37845</p>
37846<p>
37847Walter: This is not really a definition.
37848</p>
37849<p>
37850Consensus: Add note to the editor: Please apply editor's judgement
37851whether default arguments should be repeated for B, C, D changes.
37852</p>
37853<p>
37854Recommend Tentatively Ready.
37855</p>
37856</blockquote>
37857
37858<p><i>[
378592009-05-09:  See alternative solution in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1113">1113</a>.
37860]</i></p>
37861
37862
37863
37864
37865<p><b>Proposed resolution:</b></p>
37866<ol type="A">
37867<li>
37868<p>replace in 20.3.7 [template.bitset]/1 (class <tt>bitset</tt>)
37869</p>
37870<blockquote><pre>template &lt;class charT, class traits&gt;
37871  basic_string&lt;charT, traits, allocator&lt;charT&gt; &gt;
37872  to_string(<ins>charT zero = charT('0'), charT one = charT('1')</ins>) const;
37873template &lt;class charT&gt;
37874  basic_string&lt;charT, char_traits&lt;charT&gt;, allocator&lt;charT&gt; &gt;
37875  to_string(<ins>charT zero = charT('0'), charT one = charT('1')</ins>) const;
37876basic_string&lt;char, char_traits&lt;char&gt;, allocator&lt;char&gt; &gt;
37877  to_string(<ins>char zero = '0', char one = '1'</ins>) const;
37878</pre></blockquote>
37879</li>
37880<li>
37881<p>
37882replace in 20.3.7.2 [bitset.members]/37
37883</p>
37884<blockquote><pre>template &lt;class charT, class traits&gt;
37885  basic_string&lt;charT, traits, allocator&lt;charT&gt; &gt;
37886  to_string(<ins>charT zero = charT('0'), charT one = charT('1')</ins>) const;
37887</pre>
37888<blockquote>
3788937 <i>Returns:</i> <tt>to_string&lt;charT, traits, allocator&lt;charT&gt; &gt;(<ins>zero, one</ins>)</tt>.
37890</blockquote>
37891</blockquote>
37892</li>
37893<li>
37894<p>
37895replace in 20.3.7.2 [bitset.members]/38
37896</p>
37897
37898<blockquote><pre>template &lt;class charT&gt;
37899  basic_string&lt;charT, char_traits&lt;charT&gt;, allocator&lt;charT&gt; &gt;
37900  to_string(<ins>charT zero = charT('0'), charT one = charT('1')</ins>) const;
37901</pre>
37902<blockquote>
3790338 <i>Returns:</i> <tt>to_string&lt;charT, char_traits&lt;charT&gt;, allocator&lt;charT&gt; &gt;(<ins>zero, one</ins>)</tt>.
37904</blockquote>
37905</blockquote>
37906</li>
37907
37908<li>
37909<p>
37910replace in 20.3.7.2 [bitset.members]/39
37911</p>
37912
37913<blockquote><pre>basic_string&lt;char, char_traits&lt;char&gt;, allocator&lt;char&gt; &gt;
37914  to_string(<ins>char zero = '0', char one = '1'</ins>) const;
37915</pre>
37916<blockquote>
3791739 <i>Returns:</i> <tt>to_string&lt;char, char_traits&lt;char&gt;, allocator&lt;char&gt; &gt;(<ins>zero, one</ins>)</tt>.
37918</blockquote>
37919</blockquote>
37920</li>
37921
37922</ol>
37923
37924
37925
37926
37927
37928
37929<hr>
37930<h3><a name="856"></a>856. Removal of <tt>aligned_union</tt></h3>
37931<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>
37932 <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2008-06-12  <b>Last modified:</b> 2008-09-26</p>
37933<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>
37934<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
37935<p><b>Discussion:</b></p>
37936<p>
37937With the arrival of extended unions 
37938(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2544.pdf">N2544</a>),
37939there is no
37940known use of <tt>aligned_union</tt> that couldn't be handled by
37941the "extended unions" core-language facility.
37942</p>
37943
37944
37945<p><b>Proposed resolution:</b></p>
37946<p>
37947Remove the following signature from 20.6.2 [meta.type.synop]:
37948</p>
37949<blockquote><pre>template &lt;std::size_t Len, class... Types&gt; struct aligned_union;
37950</pre></blockquote>
37951
37952<p>
37953Remove the second row from table 51 in 20.6.7 [meta.trans.other],
37954starting with:
37955</p>
37956
37957<blockquote><pre>template &lt;std::size_t Len,
37958class... Types&gt;
37959struct aligned_union;
37960</pre></blockquote>
37961
37962
37963
37964
37965
37966<hr>
37967<h3><a name="857"></a>857. <tt>condition_variable::time_wait</tt> return <tt>bool</tt> error prone</h3>
37968<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#WP">WP</a>
37969 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2008-06-13  <b>Last modified:</b> 2009-10-26</p>
37970<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>
37971<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>
37972<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
37973<p><b>Discussion:</b></p>
37974<p>
37975The meaning of the <tt>bool</tt> returned by <tt>condition_variable::timed_wait</tt> is so
37976obscure that even the class' designer can't deduce it correctly. Several
37977people have independently stumbled on this issue.
37978</p>
37979<p>
37980It might be simpler to change the return type to a scoped enum:
37981</p>
37982<blockquote><pre>enum class timeout { not_reached, reached };
37983</pre></blockquote>
37984
37985<p>
37986That's the same cost as returning a <tt>bool</tt>, but not subject to mistakes. Your example below would be:
37987</p>
37988
37989<blockquote><pre>if (cv.wait_until(lk, time_limit) == timeout::reached )
37990  throw time_out();
37991</pre></blockquote>
37992
37993<p><i>[
37994Beman to supply exact wording.
37995]</i></p>
37996
37997
37998<p><i>[
37999San Francisco:
38000]</i></p>
38001
38002
38003<blockquote>
38004<p>
38005There is concern that the enumeration names are just as confusing, if
38006not more so, as the bool. You might have awoken because of a signal or a
38007spurious wakeup, for example.
38008</p>
38009<p>
38010Group feels that this is a defect that needs fixing.
38011</p>
38012<p>
38013Group prefers returning an enum over a void return.
38014</p>
38015<p>
38016Howard to provide wording.
38017</p>
38018</blockquote>
38019
38020<p><i>[
380212009-06-14 Beman provided wording.
38022]</i></p>
38023
38024
38025<p><i>[
380262009-07 Frankfurt:
38027]</i></p>
38028
38029
38030<blockquote>
38031Move to Ready.
38032</blockquote>
38033
38034
38035
38036<p><b>Proposed resolution:</b></p>
38037<p>
38038Change Condition variables 30.5 [thread.condition], Header
38039condition_variable synopsis, as indicated:
38040</p>
38041
38042<blockquote><pre>namespace std {
38043  class condition_variable;
38044  class condition_variable_any;
38045
38046  <ins>enum class cv_status { no_timeout, timeout };</ins>
38047}
38048</pre></blockquote>
38049
38050<p>
38051Change Class condition_variable 30.5.1 [thread.condition.condvar] as indicated:
38052</p>
38053
38054<blockquote><pre>class condition_variable { 
38055public:
38056  ...
38057  template &lt;class Clock, class Duration&gt;
38058    <del>bool</del> <ins>cv_status</ins> wait_until(unique_lock&lt;mutex&gt;&amp; lock,
38059                    const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time);
38060  template &lt;class Clock, class Duration, class Predicate&gt;
38061    bool wait_until(unique_lock&lt;mutex&gt;&amp; lock,
38062                    const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time,
38063                    Predicate pred);
38064
38065  template &lt;class Rep, class Period&gt;
38066    <del>bool</del> <ins>cv_status</ins> wait_for(unique_lock&lt;mutex&gt;&amp; lock,
38067                  const chrono::duration&lt;Rep, Period&gt;&amp; rel_time);
38068  template &lt;class Rep, class Period, class Predicate&gt;
38069    bool wait_for(unique_lock&lt;mutex&gt;&amp; lock,
38070                  const chrono::duration&lt;Rep, Period&gt;&amp; rel_time,
38071                  Predicate pred);
38072  ...
38073};
38074
38075...
38076
38077template &lt;class Clock, class Duration&gt;
38078  <del>bool</del> <ins>cv_status</ins> wait_until(unique_lock&lt;mutex&gt;&amp; lock,
38079                  const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time);
38080</pre>
38081<blockquote>
38082<p>
38083-15- <i>Precondition:</i> <tt>lock</tt> is locked by the calling thread, and either
38084</p>
38085<ul>
38086<li>
38087no other thread is waiting on this <tt>condition_variable</tt> object or
38088</li>
38089<li>
38090<tt>lock.mutex()</tt> returns the same value for each of the <tt>lock</tt>
38091arguments supplied by all concurrently waiting threads (via <tt>wait</tt>,
38092<tt>wait_for</tt> or <tt>wait_until</tt>.).
38093</li>
38094</ul>
38095
38096<p>
38097-16- <i>Effects:</i>
38098</p>
38099
38100<ul>
38101<li>
38102Atomically calls <tt>lock.unlock()</tt> and blocks on <tt>*this</tt>.
38103</li>
38104<li>
38105When unblocked, calls <tt>lock.lock()</tt> (possibly blocking on the lock) and returns.
38106</li>
38107<li>
38108The function will unblock when signaled by a call to <tt>notify_one()</tt>,
38109a call to <tt>notify_all()</tt>, <del>by 
38110the current time exceeding <tt>abs_time</tt></del> <ins>if <tt>Clock::now() &gt;= abs_time</tt></ins>,
38111or spuriously.
38112</li>
38113<li>
38114If the function exits via an exception, <tt>lock.unlock()</tt> shall be called prior
38115to exiting the function scope.
38116</li>
38117</ul>
38118
38119<p>
38120-17- <i>Postcondition:</i> <tt>lock</tt> is locked by the calling thread.
38121</p>
38122
38123<p>
38124-18- <i>Returns:</i> <del><tt>Clock::now() &lt; abs_time</tt></del>
38125<ins><tt>cv_status::timeout</tt> if the function unblocked because <tt>abs_time</tt>
38126was reached, otherwise <tt>cv_status::no_timeout</tt></ins>.
38127</p>
38128
38129<p>
38130-19- <i>Throws:</i> <tt>std::system_error</tt> when the effects or postcondition
38131cannot be achieved.
38132</p>
38133
38134<p>
38135-20- <i>Error conditions:</i>
38136</p>
38137
38138<ul>
38139<li>
38140<tt>operation_not_permitted</tt> &#8212; if the thread does not own the lock.
38141</li>
38142<li>
38143equivalent error condition from <tt>lock.lock()</tt> or <tt>lock.unlock()</tt>.
38144</li>
38145</ul>
38146</blockquote>
38147
38148<pre>template &lt;class Rep, class Period&gt;
38149  <del>bool</del> <ins>cv_status</ins> wait_for(unique_lock&lt;mutex&gt;&amp; lock,
38150                const chrono::duration&lt;Rep, Period&gt;&amp; rel_time);
38151
38152</pre>
38153<blockquote>
38154<p>
38155-21- <i><del>Effects</del> <ins>Returns</ins>:</i>
38156</p>
38157<blockquote><pre>wait_until(lock, chrono::monotonic_clock::now() + rel_time)
38158</pre></blockquote>
38159<p>
38160<del>-22- <i>Returns:</i> <tt>false</tt> if the call is returning because the time
38161duration specified by <tt>rel_time</tt> has elapsed, 
38162otherwise <tt>true</tt>.</del>
38163</p>
38164
38165<p><i>[
38166This part of the wording may conflict with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#859">859</a> in detail, but does
38167not do so in spirit.  If both issues are accepted, there is a logical merge.
38168]</i></p>
38169
38170</blockquote>
38171
38172<pre>template &lt;class Clock, class Duration, class Predicate&gt; 
38173  bool wait_until(unique_lock&lt;mutex&gt;&amp; lock, 
38174                  const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time, 
38175                  Predicate pred);
38176</pre>
38177
38178<blockquote>
38179<p>
38180-23- <i>Effects:</i>
38181</p>
38182<blockquote><pre>while (!pred()) 
38183  if (<del>!</del>wait_until(lock, abs_time) <ins>== cv_status::timeout</ins>) 
38184    return pred(); 
38185return true;
38186</pre></blockquote>
38187
38188<p>
38189-24- <i>Returns:</i> <tt>pred()</tt>.
38190</p>
38191
38192<p>
38193-25- [<i>Note:</i>
38194The returned value indicates whether the predicate evaluates to
38195<tt>true</tt> regardless of whether the timeout was triggered.
38196&#8212; <i>end note</i>].
38197</p>
38198</blockquote>
38199</blockquote>
38200
38201<p>
38202Change Class condition_variable_any 30.5.2 [thread.condition.condvarany] as indicated:
38203</p>
38204
38205<blockquote><pre>class condition_variable_any {
38206public:
38207  ...
38208  template &lt;class Lock, class Clock, class Duration&gt;
38209    <del>bool</del> <ins>cv_status</ins> wait_until(Lock&amp; lock,
38210                    const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time);
38211  template &lt;class Lock, class Clock, class Duration, class Predicate&gt;
38212    bool wait_until(Lock&amp; lock,
38213                    const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time,
38214                    Predicate pred);
38215
38216  template &lt;class Lock, class Rep, class Period&gt;
38217    <del>bool</del> <ins>cv_status</ins> wait_for(Lock&amp; lock,
38218                  const chrono::duration&lt;Rep, Period&gt;&amp; rel_time);
38219  template &lt;class Lock, class Rep, class Period, class Predicate&gt;
38220    bool wait_for(Lock&amp; lock,
38221                  const chrono::duration&lt;Rep, Period&gt;&amp; rel_time,
38222                  Predicate pred);
38223  ...
38224};
38225
38226...
38227
38228template &lt;class Lock, class Clock, class Duration&gt;
38229  <del>bool</del> <ins>cv_status</ins> wait_until(Lock&amp; lock,
38230                  const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time);
38231</pre>
38232
38233<blockquote>
38234
38235<p>
38236-13- <i>Effects:</i>
38237</p>
38238
38239<ul>
38240<li>
38241Atomically calls <tt>lock.unlock()</tt> and blocks on <tt>*this</tt>.
38242</li>
38243<li>
38244When unblocked, calls <tt>lock.lock()</tt> (possibly blocking on the lock) and returns.
38245</li>
38246<li>
38247The function will unblock when signaled by a call to <tt>notify_one()</tt>,
38248a call to <tt>notify_all()</tt>, <del>by 
38249the current time exceeding <tt>abs_time</tt></del> <ins>if <tt>Clock::now() &gt;= abs_time</tt></ins>,
38250or spuriously.
38251</li>
38252<li>
38253If the function exits via an exception, <tt>lock.unlock()</tt> shall be called prior
38254to exiting the function scope.
38255</li>
38256</ul>
38257
38258<p>
38259-14- <i>Postcondition:</i> <tt>lock</tt> is locked by the calling thread.
38260</p>
38261
38262<p>
38263-15- <i>Returns:</i> <del><tt>Clock::now() &lt; abs_time</tt></del>
38264<ins><tt>cv_status::timeout</tt> if the function unblocked because <tt>abs_time</tt>
38265was reached, otherwise <tt>cv_status::no_timeout</tt></ins>.
38266</p>
38267
38268<p>
38269-16- <i>Throws:</i> <tt>std::system_error</tt> when the effects or postcondition
38270cannot be achieved.
38271</p>
38272
38273<p>
38274-17- <i>Error conditions:</i>
38275</p>
38276
38277<ul>
38278<li>
38279equivalent error condition from <tt>lock.lock()</tt> or <tt>lock.unlock()</tt>.
38280</li>
38281</ul>
38282</blockquote>
38283
38284<pre>template &lt;class Lock, class Rep, class Period&gt;
38285  <del>bool</del> <ins>cv_status</ins> wait_for(Lock&amp; lock,
38286                const chrono::duration&lt;Rep, Period&gt;&amp; rel_time);
38287
38288</pre>
38289
38290<blockquote>
38291<p>
38292-18- <i><del>Effects</del> <ins>Returns</ins>:</i>
38293</p>
38294<blockquote><pre>wait_until(lock, chrono::monotonic_clock::now() + rel_time)
38295</pre></blockquote>
38296
38297<p>
38298<del>-19- <i>Returns:</i> <tt>false</tt> if the call is returning because the time
38299duration specified by <tt>rel_time</tt> has elapsed, 
38300otherwise <tt>true</tt>.</del>
38301</p>
38302
38303<p><i>[
38304This part of the wording may conflict with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#859">859</a> in detail, but does
38305not do so in spirit.  If both issues are accepted, there is a logical merge.
38306]</i></p>
38307
38308
38309</blockquote>
38310
38311<pre>template &lt;class Lock, class Clock, class Duration, class Predicate&gt; 
38312  bool wait_until(Lock&amp; lock, 
38313                  const chrono::time_point&lt;Clock, Duration&gt;&amp; <del>rel_time</del> <ins>abs_time</ins>, 
38314                  Predicate pred);
38315</pre>
38316
38317<blockquote>
38318<p>
38319-20- <i>Effects:</i>
38320</p>
38321<blockquote><pre>while (!pred()) 
38322  if (<del>!</del>wait_until(lock, abs_time) <ins>== cv_status::timeout</ins>) 
38323    return pred(); 
38324return true;
38325</pre></blockquote>
38326
38327<p>
38328-21- <i>Returns:</i> <tt>pred()</tt>.
38329</p>
38330
38331<p>
38332-22- [<i>Note:</i>
38333The returned value indicates whether the predicate evaluates to
38334<tt>true</tt> regardless of whether the timeout was triggered.
38335&#8212; <i>end note</i>].
38336</p>
38337</blockquote>
38338
38339</blockquote>
38340
38341
38342
38343
38344
38345
38346<hr>
38347<h3><a name="858"></a>858. Wording for Minimal Support for Garbage Collection</h3>
38348<p><b>Section:</b> 20.8.15.6 [util.dynamic.safety] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#CD1">CD1</a>
38349 <b>Submitter:</b> Pete Becker  <b>Opened:</b> 2008-06-21  <b>Last modified:</b> 2008-09-26</p>
38350<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>
38351<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
38352<p><b>Discussion:</b></p>
38353<p>
38354The first sentence of the Effects clause for <tt>undeclare_reachable</tt> seems
38355to be missing some words. I can't parse
38356</p>
38357<blockquote>
38358... for all non-null <tt>p</tt> referencing the argument is no longer declared reachable...
38359</blockquote>
38360<p>
38361I take it the intent is that <tt>undeclare_reachable</tt> should be called only
38362when there has been a corresponding call to <tt>declare_reachable</tt>. In
38363particular, although the wording seems to allow it, I assume that code
38364shouldn't call <tt>declare_reachable</tt> once then call <tt>undeclare_reachable</tt>
38365twice.
38366</p>
38367<p>
38368I don't know what "shall be live" in the Requires clause means.
38369</p>
38370<p>
38371In the final Note for <tt>undeclare_reachable</tt>, what does "cannot be
38372deallocated" mean? Is this different from "will not be able to collect"?
38373</p>
38374
38375<p>
38376For the wording on nesting of <tt>declare_reachable</tt> and
38377<tt>undeclare_reachable</tt>, the words for locking and unlocking recursive
38378mutexes probably are a good model.
38379</p>
38380
38381<p><i>[
38382San Francisco:
38383]</i></p>
38384
38385
38386<blockquote>
38387<p>
38388Nick: what does "shall be live" mean?
38389</p>
38390<p>
38391Hans: I can provide an appropriate cross-reference to the Project Editor
38392to clarify the intent.
38393</p>
38394</blockquote>
38395
38396
38397<p><b>Proposed resolution:</b></p>
38398<p>
38399In 20.8.15.6 [util.dynamic.safety]
38400(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2670.htm">N2670</a>,
38401Minimal Support for Garbage Collection)
38402</p>
38403<p>
38404Add at the beginning, before paragraph 39
38405</p>
38406
38407<blockquote>
38408A complete object is <i>declared reachable</i> while the number of calls
38409to <tt>declare_reachable</tt> with an argument referencing the object exceeds the
38410number of <tt>undeclare_reachable</tt> calls with pointers to the same complete
38411object.
38412</blockquote>
38413
38414<p>
38415Change paragraph 42 (Requires clause for <tt>undeclare_reachable</tt>)
38416</p>
38417
38418<blockquote>
38419If <tt>p</tt> is not null, <del><tt>declare_reachable(p)</tt> was previously called</del>
38420<ins>the complete object referenced by <tt>p</tt> shall have
38421been previously declared reachable</ins>, and shall
38422be live <ins>(3.8 [basic.life])</ins> from the time of the call until the last <tt>undeclare_reachable(p)</tt>
38423call on the object.
38424</blockquote>
38425
38426<p>
38427Change the first sentence in paragraph 44 (Effects clause for
38428<tt>undeclare_reachable</tt>):
38429</p>
38430
38431<blockquote>
38432<i>Effects:</i> 
38433<del>Once the number of calls to
38434<tt>undeclare_reachable(p)</tt> equals the number of calls to
38435<tt>declare_reachable(p)</tt>
38436for all non-null <tt>p</tt> referencing
38437the argument is no longer declared reachable.  When this happens,
38438pointers to the object referenced by p may not be subsequently
38439dereferenced.</del>
38440<ins>
38441After a call to <tt>undeclare_reachable(p)</tt>, if <tt>p</tt> is not null and the object <tt>q</tt>
38442referenced by <tt>p</tt> is no longer declared reachable, then
38443dereferencing any pointer to <tt>q</tt> that is not safely derived
38444results in undefined behavior.
38445</ins> ...
38446</blockquote>
38447
38448<p>
38449Change the final note:
38450</p>
38451<p>
38452[<i>Note:</i> It is expected that calls to <tt>declare_reachable(p)</tt>
38453will consume a small amount of memory<ins>, in addition to that occupied
38454by the referenced object, </ins> until the matching call to
38455<tt>undeclare_reachable(p)</tt> is encountered. <del>In addition, the
38456referenced object cannot be deallocated during this period, and garbage
38457collecting implementations will not be able to collect the object while
38458it is declared reachable.</del> Long running programs should arrange
38459that calls <ins>for short-lived objects</ins> are matched. <i>--end
38460note</i>]
38461</p>
38462
38463
38464
38465
38466
38467
38468<hr>
38469<h3><a name="859"></a>859. Monotonic Clock is Conditionally Supported?</h3>
38470<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#WP">WP</a>
38471 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2008-06-23  <b>Last modified:</b> 2009-10-26</p>
38472<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.condition">active issues</a> in [thread.condition].</p>
38473<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.condition">issues</a> in [thread.condition].</p>
38474<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
38475<p><b>Discussion:</b></p>
38476
38477<p>Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#958">958</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#959">959</a>.</p>
38478
38479<p>
38480<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2661.html">N2661</a>
38481says that there is a class named <tt>monotonic_clock</tt>. It also says that this
38482name may be a synonym for <tt>system_clock</tt>, and that it's conditionally
38483supported. So the actual requirement is that it can be monotonic or not,
38484and you can tell by looking at <tt>is_monotonic</tt>, or it might not exist at
38485all (since it's conditionally supported). Okay, maybe too much
38486flexibility, but so be it.
38487</p>
38488<p>
38489A problem comes up in the threading specification, where several
38490variants of <tt>wait_for</tt> explicitly use <tt>monotonic_clock::now()</tt>. What is the
38491meaning of an effects clause that says
38492</p>
38493
38494<blockquote><pre>wait_until(lock, chrono::monotonic_clock::now() + rel_time)
38495</pre></blockquote>
38496
38497<p>
38498when <tt>monotonic_clock</tt> is not required to exist?
38499</p>
38500
38501<p><i>[
38502San Francisco:
38503]</i></p>
38504
38505
38506<blockquote>
38507<p>
38508Nick: maybe instead of saying that chrono::monotonic_clock is
38509conditionally supported, we could say that it's always there, but not
38510necessarily supported..
38511</p>
38512<p>
38513Beman: I'd prefer a typedef that identifies the best clock to use for
38514wait_for locks.
38515</p>
38516<p>
38517Tom: combine the two concepts; create a duration clock type, but keep
38518the is_monotonic test.
38519</p>
38520<p>
38521Howard: if we create a duration_clock type, is it a typedef or an
38522entirely true type?
38523</p>
38524<p>
38525There was broad preference for a typedef.
38526</p>
38527<p>
38528Move to Open. Howard to provide wording to add a typedef for
38529duration_clock and to replace all uses of monotonic_clock in function
38530calls and signatures with duration_clock.
38531</p>
38532</blockquote>
38533
38534<p><i>[
38535Howard notes post-San Francisco:
38536]</i></p>
38537
38538
38539<blockquote>
38540<p>
38541After further thought I do not believe that creating a <tt>duration_clock typedef</tt>
38542is the best way to proceed.  An implementation may not need to use a
38543<tt>time_point</tt> to implement the <tt>wait_for</tt> functions.
38544</p>
38545
38546<p>
38547For example, on POSIX systems <tt>sleep_for</tt> can be implemented in terms of
38548<tt>nanosleep</tt> which takes only a duration in terms of nanoseconds.  The current
38549working paper does not describe <tt>sleep_for</tt> in terms of <tt>sleep_until</tt>.
38550And paragraph 2 of 30.2.4 [thread.req.timing] has the words strongly encouraging
38551implementations to use monotonic clocks for <tt>sleep_for</tt>:
38552</p>
38553
38554<blockquote>
385552 The member functions whose names end in <tt>_for</tt> take an argument that
38556specifies a relative time. Implementations should use a monotonic clock to
38557measure time for these functions.
38558</blockquote>
38559
38560<p>
38561I believe the approach taken in describing the effects of <tt>sleep_for</tt>
38562and <tt>try_lock_for</tt> is also appropriate for <tt>wait_for</tt>.  I.e. these
38563are not described in terms of their <tt>_until</tt> variants.
38564</p>
38565
38566</blockquote>
38567
38568<p><i>[
385692009-07 Frankfurt:
38570]</i></p>
38571
38572
38573<blockquote>
38574<p>
38575Beman will send some suggested wording changes to Howard.
38576</p>
38577<p>
38578Move to Ready.
38579</p>
38580</blockquote>
38581
38582<p><i>[
385832009-07-21 Beman added the requested wording changes to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#962">962</a>.
38584]</i></p>
38585
38586
38587
38588
38589<p><b>Proposed resolution:</b></p>
38590<p>
38591Change 30.5.1 [thread.condition.condvar], p21-22:
38592</p>
38593
38594<blockquote>
38595<pre>template &lt;class Rep, class Period&gt; 
38596  bool wait_for(unique_lock&lt;mutex&gt;&amp; lock, 
38597                const chrono::duration&lt;Rep, Period&gt;&amp; rel_time);
38598</pre>
38599<blockquote>
38600<p><ins>
38601<i>Precondition:</i> <tt>lock</tt> is locked by the calling thread, and either
38602</ins></p>
38603<ul>
38604<li><ins>no other thread is waiting on this <tt>condition_variable</tt> object or</ins></li>
38605<li><ins><tt>lock.mutex()</tt> returns the same value for each of the <tt>lock</tt>
38606arguments supplied by all concurrently waiting threads (via <tt>wait</tt>,
38607<tt>wait_for</tt> or <tt>wait_until</tt>).</ins></li>
38608</ul>
38609<p>
3861021 <i>Effects:</i>
38611</p>
38612<blockquote><pre><del>wait_until(lock, chrono::monotonic_clock::now() + rel_time)</del>
38613</pre></blockquote>
38614<ul>
38615<li><ins>
38616Atomically calls <tt>lock.unlock()</tt> and blocks on <tt>*this</tt>.
38617</ins></li>
38618
38619<li><ins>
38620When unblocked, calls <tt>lock.lock()</tt> (possibly blocking on the lock) and returns.
38621</ins></li>
38622
38623<li><ins>
38624The function will unblock when signaled by a call to <tt>notify_one()</tt>, a call
38625to <tt>notify_all()</tt>, by 
38626the elapsed time <tt>rel_time</tt> passing (30.2.4 [thread.req.timing]),
38627or spuriously.
38628</ins></li>
38629
38630<li><ins>
38631If the function exits via an exception, <tt>lock.unlock()</tt> shall be called 
38632prior to exiting the function scope.
38633</ins></li>
38634</ul>
38635
38636<p><ins>
38637<i>Postcondition:</i> <tt>lock</tt> is locked by the calling thread.
38638</ins></p>
38639
38640
38641<p>
3864222 <i>Returns:</i> <tt>false</tt> if the call is returning because the time
38643duration specified by <tt>rel_time</tt> has elapsed, otherwise <tt>true</tt>.
38644</p>
38645
38646<p><i>[
38647This part of the wording may conflict with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#857">857</a> in detail, but does
38648not do so in spirit.  If both issues are accepted, there is a logical merge.
38649]</i></p>
38650
38651
38652<p><ins>
38653<i>Throws:</i> <tt>std::system_error</tt> when the effects or postcondition cannot be achieved.
38654</ins></p>
38655
38656<p><ins>
38657<i>Error conditions:</i>
38658</ins></p>
38659
38660<ul>
38661<li><ins>
38662<tt>operation_not_permitted</tt> -- if the thread does not own the lock.
38663</ins></li>
38664<li><ins>
38665equivalent error condition from <tt>lock.lock()</tt> or <tt>lock.unlock()</tt>.
38666</ins></li>
38667</ul>
38668
38669</blockquote>
38670</blockquote>
38671
38672<p>
38673Change 30.5.1 [thread.condition.condvar], p26-p29:
38674</p>
38675
38676<blockquote>
38677<pre>template &lt;class Rep, class Period, class Predicate&gt; 
38678  bool wait_for(unique_lock&lt;mutex&gt;&amp; lock, 
38679                const chrono::duration&lt;Rep, Period&gt;&amp; rel_time, 
38680                Predicate pred);
38681</pre>
38682<blockquote>
38683<p><ins>
38684<i>Precondition:</i> <tt>lock</tt> is locked by the calling thread, and either
38685</ins></p>
38686<ul>
38687<li><ins>no other thread is waiting on this <tt>condition_variable</tt> object or</ins></li>
38688<li><ins><tt>lock.mutex()</tt> returns the same value for each of the <tt>lock</tt>
38689arguments supplied by all concurrently waiting threads (via <tt>wait</tt>,
38690<tt>wait_for</tt> or <tt>wait_until</tt>).</ins></li>
38691</ul>
38692<p>
38693<i>26 Effects:</i>
38694</p>
38695<blockquote><pre><del>wait_until(lock, chrono::monotonic_clock::now() + rel_time, std::move(pred))</del>
38696</pre>
38697<ul>
38698<li><ins>
38699Executes a loop:  Within the loop the function first evaluates <tt>pred()</tt>
38700and exits the loop if the result of <tt>pred()</tt> is <tt>true</tt>.
38701</ins></li>
38702<li><ins>
38703Atomically calls <tt>lock.unlock()</tt>
38704and blocks on <tt>*this</tt>.
38705</ins></li>
38706<li><ins>
38707When unblocked, calls <tt>lock.lock()</tt> (possibly blocking on the lock).
38708</ins></li>
38709<li><ins>
38710The function will unblock when signaled by a call to <tt>notify_one()</tt>, a
38711call to <tt>notify_all()</tt>, by the elapsed time <tt>rel_time</tt> passing (30.1.4
38712[thread.req.timing]), or spuriously.
38713</ins></li>
38714<li><ins>
38715If the function exits via an exception, <tt>lock.unlock()</tt> shall be called
38716prior to exiting the function scope.
38717</ins></li>
38718<li><ins>
38719The loop terminates when <tt>pred()</tt> returns <tt>true</tt> or when the time
38720duration specified by <tt>rel_time</tt> has elapsed.
38721</ins></li>
38722</ul>
38723</blockquote>
38724
38725<p>
3872627 [<i>Note:</i> There is no blocking if <tt>pred()</tt> is initially <tt>true</tt>,
38727even if the timeout has already expired. <i>-- end note</i>]
38728</p>
38729
38730<p><ins>
38731<i>Postcondition:</i> <tt>lock</tt> is locked by the calling thread.
38732</ins></p>
38733
38734<p>
3873528 <i>Returns:</i> <tt>pred()</tt>
38736</p>
38737
38738<p>
3873929 [<i>Note:</i> The returned value indicates whether the predicate evaluates to
38740<tt>true</tt> regardless of whether the timeout was triggered. <i>-- end note</i>]
38741</p>
38742
38743<p><ins>
38744<i>Throws:</i> <tt>std::system_error</tt> when the effects or postcondition cannot be achieved.
38745</ins></p>
38746
38747<p><ins>
38748<i>Error conditions:</i>
38749</ins></p>
38750
38751<ul>
38752<li><ins>
38753<tt>operation_not_permitted</tt> -- if the thread does not own the lock.
38754</ins></li>
38755<li><ins>
38756equivalent error condition from <tt>lock.lock()</tt> or <tt>lock.unlock()</tt>.
38757</ins></li>
38758</ul>
38759
38760</blockquote>
38761</blockquote>
38762
38763<p>
38764Change 30.5.2 [thread.condition.condvarany], p18-19:
38765</p>
38766
38767<blockquote>
38768<pre>template &lt;class Lock, class Rep, class Period&gt; 
38769  bool wait_for(Lock&amp; lock, const chrono::duration&lt;Rep, Period&gt;&amp; rel_time);
38770</pre>
38771<blockquote>
38772<p>
3877318 <i>Effects:</i>
38774</p>
38775<blockquote><pre><del>wait_until(lock, chrono::monotonic_clock::now() + rel_time)</del>
38776</pre></blockquote>
38777
38778<ul>
38779<li><ins>
38780Atomically calls <tt>lock.unlock()</tt> and blocks on <tt>*this</tt>.
38781</ins></li>
38782
38783<li><ins>
38784When unblocked, calls <tt>lock.lock()</tt> (possibly blocking on the lock) and returns.
38785</ins></li>
38786
38787<li><ins>
38788The function will unblock when signaled by a call to <tt>notify_one()</tt>, a call to
38789<tt>notify_all()</tt>, by
38790the elapsed time <tt>rel_time</tt> passing (30.2.4 [thread.req.timing]),
38791or spuriously.
38792</ins></li>
38793
38794<li><ins>
38795If the function exits via an exception, <tt>lock.unlock()</tt> shall be called
38796prior to exiting the function scope.
38797</ins></li>
38798</ul>
38799
38800<p><ins>
38801<i>Postcondition:</i> <tt>lock</tt> is locked by the calling thread.
38802</ins></p>
38803
38804<p>
3880519 <i>Returns:</i> <tt>false</tt> if the call is returning because the time duration
38806specified by <tt>rel_time</tt> has elapsed, otherwise <tt>true</tt>.
38807</p>
38808
38809<p><ins>
38810<i>Throws:</i> <tt>std::system_error</tt> when the returned value, effects,
38811or postcondition cannot be achieved.
38812</ins></p>
38813
38814<p><ins>
38815<i>Error conditions:</i>
38816</ins></p>
38817
38818<ul>
38819<li><ins>
38820equivalent error condition from <tt>lock.lock()</tt> or <tt>lock.unlock()</tt>.
38821</ins></li>
38822</ul>
38823</blockquote>
38824</blockquote>
38825
38826<p>
38827Change 30.5.2 [thread.condition.condvarany], p23-p26:
38828</p>
38829
38830<blockquote>
38831<pre>template &lt;class Lock, class Rep, class Period, class Predicate&gt; 
38832  bool wait_for(Lock&amp; lock, const chrono::duration&lt;Rep, Period&gt;&amp; rel_time, Predicate pred);
38833</pre>
38834<blockquote>
38835<p><ins>
38836<i>Precondition:</i> <tt>lock</tt> is locked by the calling thread, and either
38837</ins></p>
38838<ul>
38839<li><ins>no other thread is waiting on this <tt>condition_variable</tt> object or</ins></li>
38840<li><ins><tt>lock.mutex()</tt> returns the same value for each of the <tt>lock</tt>
38841arguments supplied by all concurrently waiting threads (via <tt>wait</tt>,
38842<tt>wait_for</tt> or <tt>wait_until</tt>).</ins></li>
38843</ul>
38844<p>
38845<i>23 Effects:</i>
38846</p>
38847<blockquote><pre><del>wait_until(lock, chrono::monotonic_clock::now() + rel_time, std::move(pred))</del>
38848</pre>
38849<ul>
38850<li><ins>
38851Executes a loop:  Within the loop the function first evaluates <tt>pred()</tt>
38852and exits the loop if the result of <tt>pred()</tt> is <tt>true</tt>.
38853</ins></li>
38854<li><ins>
38855Atomically calls <tt>lock.unlock()</tt>
38856and blocks on <tt>*this</tt>.
38857</ins></li>
38858<li><ins>
38859When unblocked, calls <tt>lock.lock()</tt> (possibly blocking on the lock).
38860</ins></li>
38861<li><ins>
38862The function will unblock when signaled by a call to <tt>notify_one()</tt>, a
38863call to <tt>notify_all()</tt>, by the elapsed time <tt>rel_time</tt> passing (30.1.4
38864[thread.req.timing]), or spuriously.
38865</ins></li>
38866<li><ins>
38867If the function exits via an exception, <tt>lock.unlock()</tt> shall be called
38868prior to exiting the function scope.
38869</ins></li>
38870<li><ins>
38871The loop terminates when <tt>pred()</tt> returns <tt>true</tt> or when the time
38872duration specified by <tt>rel_time</tt> has elapsed.
38873</ins></li>
38874</ul>
38875</blockquote>
38876
38877<p>
3887824 [<i>Note:</i> There is no blocking if <tt>pred()</tt> is initially <tt>true</tt>,
38879even if the timeout has already expired. <i>-- end note</i>]
38880</p>
38881
38882<p><ins>
38883<i>Postcondition:</i> <tt>lock</tt> is locked by the calling thread.
38884</ins></p>
38885
38886<p>
3888725 <i>Returns:</i> <tt>pred()</tt>
38888</p>
38889
38890<p>
3889126 [<i>Note:</i> The returned value indicates whether the predicate evaluates to
38892<tt>true</tt> regardless of whether the timeout was triggered. <i>-- end note</i>]
38893</p>
38894
38895<p><ins>
38896<i>Throws:</i> <tt>std::system_error</tt> when the effects or postcondition cannot be achieved.
38897</ins></p>
38898
38899<p><ins>
38900<i>Error conditions:</i>
38901</ins></p>
38902
38903<ul>
38904<li><ins>
38905<tt>operation_not_permitted</tt> -- if the thread does not own the lock.
38906</ins></li>
38907<li><ins>
38908equivalent error condition from <tt>lock.lock()</tt> or <tt>lock.unlock()</tt>.
38909</ins></li>
38910</ul>
38911
38912</blockquote>
38913</blockquote>
38914
38915
38916
38917
38918
38919
38920
38921<hr>
38922<h3><a name="866"></a>866. Qualification of placement new-expressions</h3>
38923<p><b>Section:</b> 20.8.13 [specialized.algorithms], 20.8.15.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>
38924 <b>Submitter:</b> Alberto Ganesh Barbati <b>Opened:</b> 2008-07-14  <b>Last modified:</b> 2009-03-09</p>
38925<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>
38926<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
38927<p><b>Discussion:</b></p>
38928<p>
38929LWG 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
38930new-expression in 20.8.8.1 [allocator.members]. I believe the rationale
38931given 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:
38932</p>
38933<ul>
38934<li>
38935<p>
38936in 20.8.13 [specialized.algorithms], all four algorithms <tt>unitialized_copy</tt>,
38937<tt>unitialized_copy_n</tt>, <tt>unitialized_fill</tt> and <tt>unitialized_fill_n</tt> use
38938the unqualified placement new-expression in some variation of the form:
38939</p>
38940<blockquote><pre>new  (static_cast&lt;void*&gt;(&amp;*result)) typename  iterator_traits&lt;ForwardIterator&gt;::value_type(*first);
38941</pre></blockquote>
38942</li>
38943<li>
38944<p>
38945in 20.8.15.2.6 [util.smartptr.shared.create] there is a reference to the unqualified placement new-expression:
38946</p>
38947<blockquote><pre>new  (pv)  T(std::forward&lt;Args&gt;(args)...),
38948</pre></blockquote>
38949</li>
38950</ul>
38951<p>
38952I suggest to add qualification in all those places. As far as I know,
38953these are all the remaining places in the whole library that explicitly
38954use a placement new-expression. Should other uses come out, they should
38955be qualified as well.
38956</p>
38957<p>
38958As an aside, a qualified placement new-expression does not need
38959additional requirements to be compiled in a constrained context. By
38960adding qualification, the <tt>HasPlacementNew</tt> concept introduced recently in
38961<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2677.pdf">N2677 (Foundational Concepts)</a>
38962would no longer be needed by library and
38963should therefore be removed.
38964</p>
38965
38966<p><i>[
38967San Francisco:
38968]</i></p>
38969
38970
38971<blockquote>
38972Detlef: If we move this to Ready, it's likely that we'll forget about
38973the side comment about the <tt>HasPlacementNew</tt> concept.
38974</blockquote>
38975
38976<p><i>[
38977post San Francisco:
38978]</i></p>
38979
38980
38981<blockquote>
38982Daniel:  <tt>HasPlacementNew</tt> has been removed from
38983<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2774.pdf">N2774 (Foundational Concepts)</a>.
38984</blockquote>
38985
38986
38987
38988<p><b>Proposed resolution:</b></p>
38989<p>
38990Replace "<tt>new</tt>" with "<tt>::new</tt>" in:
38991</p>
38992<ul>
38993<li>
3899420.8.13.2 [uninitialized.copy], paragraphs 1 and 3
38995</li>
38996<li>
3899720.8.13.3 [uninitialized.fill]  paragraph 1
38998</li>
38999<li>
3900020.8.13.4 [uninitialized.fill.n] paragraph 1
39001</li>
39002<li>
3900320.8.15.2.6 [util.smartptr.shared.create] once in paragraph 1 and twice in paragraph 2.
39004</li>
39005</ul>
39006
39007
39008
39009
39010
39011
39012<hr>
39013<h3><a name="869"></a>869. Bucket (local) iterators and iterating past end</h3>
39014<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#WP">WP</a>
39015 <b>Submitter:</b> Sohail Somani <b>Opened:</b> 2008-07-22  <b>Last modified:</b> 2009-07-18</p>
39016<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>
39017<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>
39018<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
39019<p><b>Discussion:</b></p>
39020<p>
39021Is there any language in the current draft specifying the behaviour of the following snippet?
39022</p>
39023
39024<blockquote><pre>unordered_set&lt;int&gt; s;
39025unordered_set&lt;int&gt;::local_iterator it = s.end(0);
39026
39027// Iterate past end - the unspecified part
39028it++;
39029</pre></blockquote>
39030
39031<p>
39032I don't think there is anything about <tt>s.end(n)</tt> being considered an
39033iterator for the past-the-end value though (I think) it should be.
39034</p>
39035
39036<p><i>[
39037San Francisco:
39038]</i></p>
39039
39040
39041<blockquote>
39042We believe that this is not a substantive change, but the proposed
39043change to the wording is clearer than what we have now.
39044</blockquote>
39045
39046<p><i>[
39047Post Summit:
39048]</i></p>
39049
39050
39051<blockquote>
39052Recommend Tentatively Ready.
39053</blockquote>
39054
39055
39056
39057<p><b>Proposed resolution:</b></p>
39058<p>
39059Change Table 97 "Unordered associative container requirements" in 23.2.5 [unord.req]:
39060</p>
39061
39062<blockquote>
39063<table border="1">
39064<caption>Table 97: Unordered associative container requirements</caption>
39065<tbody><tr>
39066<th>expression</th><th>return type</th><th>assertion/note pre/post-condition</th><th>complexity</th>
39067</tr>
39068<tr>
39069<td><tt>b.begin(n)</tt></td>
39070<td><tt>local_iterator</tt><br><tt>const_local_iterator</tt> for const <tt>b</tt>.</td>
39071<td>Pre: n shall be in the range [0,b.bucket_count()). <del>Note: [b.begin(n), b.end(n)) is a
39072valid range containing all of the elements in the n<sup>th</sup> bucket.</del>
39073<ins><tt>b.begin(n)</tt> returns an iterator referring to the first element in the bucket.
39074If the bucket is empty, then <tt>b.begin(n) == b.end(n)</tt>.</ins></td>
39075<td>Constant</td>
39076</tr>
39077<tr>
39078<td><tt>b.end(n)</tt></td>
39079<td><tt>local_iterator</tt><br><tt>const_local_iterator</tt> for const <tt>b</tt>.</td>
39080<td>Pre: n shall be in the range <tt>[0, b.bucket_count())</tt>.
39081<ins><tt>b.end(n)</tt> returns an iterator which is the past-the-end value for the bucket.</ins></td>
39082<td>Constant</td>
39083</tr>
39084</tbody></table>
39085</blockquote>
39086
39087
39088
39089
39090
39091
39092<hr>
39093<h3><a name="876"></a>876. <tt>basic_string</tt> access operations should give stronger guarantees</h3>
39094<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#WP">WP</a>
39095 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2008-08-22  <b>Last modified:</b> 2009-10-26</p>
39096<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>
39097<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
39098<p><b>Discussion:</b></p>
39099<p>
39100During the Sophia Antipolis meeting it was decided to split-off some
39101parts of the
39102<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2647.html">n2647</a>
39103("Concurrency modifications for <tt>basic_string</tt>")
39104proposal into a separate issue, because these weren't actually
39105concurrency-related. The here proposed changes refer to the recent
39106update document
39107<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2668.htm">n2668</a>
39108and attempt to take advantage of the
39109stricter structural requirements.
39110</p>
39111<p>
39112Indeed there exists some leeway for more guarantees that would be
39113very useful for programmers, especially if interaction with transactionary
39114or exception-unaware C API code is important. This would also allow
39115compilers to take advantage of more performance optimizations, because
39116more functions can have throw() specifications. This proposal uses the
39117form of "Throws: Nothing" clauses to reach the same effect, because
39118there already exists a different issue in progress to clean-up the current
39119existing "schizophrenia" of the standard in this regard.
39120</p>
39121<p>
39122Due to earlier support for copy-on-write, we find the following
39123unnecessary limitations for C++0x:
39124</p>
39125
39126<ol>
39127<li>
39128Missing no-throw guarantees: <tt>data()</tt> and <tt>c_str()</tt> simply return
39129a pointer to their guts, which is a non-failure operation. This should
39130be spelled out. It is also noteworthy to mention that the same
39131guarantees should also be given by the size query functions,
39132because the combination of pointer to content and the length is
39133typically needed during interaction with low-level API.
39134</li>
39135<li>
39136Missing complexity guarantees: <tt>data()</tt> and <tt>c_str()</tt> simply return
39137a pointer to their guts, which is guaranteed O(1). This should be
39138spelled out.
39139</li>
39140<li>
39141Missing reading access to the terminating character: Only the
39142const overload of <tt>operator[]</tt> allows reading access to the terminator
39143char. For more intuitive usage of strings, reading access to this
39144position should be extended to the non-const case. In contrast
39145to C++03 this reading access should now be homogeneously
39146an lvalue access.
39147</li>
39148</ol>
39149
39150<p>
39151The proposed resolution is split into a main part (A) and a
39152secondary part (B) (earlier called "Adjunct Adjunct Proposal").
39153(B) extends (A) by also making access to index position
39154size() of the at() overloads a no-throw operation. This was
39155separated, because this part is theoretically observable in
39156specifically designed test programs.
39157</p>
39158
39159<p><i>[
39160San Francisco:
39161]</i></p>
39162
39163
39164<blockquote>
39165<p>
39166We oppose part 1 of the issue but hope to address <tt>size()</tt> in
39167issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#877">877</a>.
39168</p>
39169<p>
39170We do not support part B. 4 of the issue because of the breaking API change.
39171</p>
39172<p>
39173We support part A. 2 of the issue.
39174</p>
39175<p>
39176On support part A. 3 of the issue:
39177</p>
39178<blockquote>
39179Pete's broader comment: now that we know that basic_string will be a
39180block of contiguous memory, we should just rewrite its specification
39181with that in mind. The expression of the specification will be simpler
39182and probably more correct as a result.
39183</blockquote>
39184</blockquote>
39185
39186<p><i>[
391872009-07 Frankfurt
39188]</i></p>
39189
39190
39191<blockquote>
39192<p>
39193Move proposed resolution A to Ready.
39194</p>
39195<p><i>[
39196Howard: Commented out part B.
39197]</i></p>
39198
39199</blockquote>
39200
39201
39202
39203<p><b>Proposed resolution:</b></p>
39204<ol type="A">
39205<li>
39206<ol>
39207<li>
39208<p>In 21.4.4 [string.capacity], just after p. 1 add a new paragraph:
39209</p>
39210<blockquote>
39211<i>Throws:</i> Nothing.
39212</blockquote>
39213
39214</li>
39215<li>
39216<p>
39217In 21.4.5 [string.access] <em>replace</em> p. 1 by the following <em>4</em> paragraghs:
39218</p>
39219
39220<blockquote>
39221<p>
39222<i>Requires:</i> <tt>pos &#8804; size()</tt>.
39223</p>
39224<p>
39225<i>Returns:</i> If <tt>pos &lt; size()</tt>, returns <tt>*(begin() + pos)</tt>. Otherwise, returns
39226a reference to a <tt>charT()</tt> that shall not be modified.
39227</p>
39228<p>
39229<i>Throws:</i> Nothing.
39230</p>
39231<p>
39232<i>Complexity:</i> Constant time.
39233</p>
39234</blockquote>
39235
39236</li>
39237<li>
39238<p>
39239In 21.4.7.1 [string.accessors] replace the now <em>common</em> returns
39240clause of <tt>c_str()</tt> and <tt>data()</tt> by the following <em>three</em> paragraphs:
39241</p>
39242<blockquote>
39243<p>
39244<i>Returns:</i> A pointer <tt>p</tt> such that <tt>p+i == &amp;operator[](i)</tt> for each <tt>i</tt>
39245in <tt>[0, size()]</tt>.
39246</p>
39247<p>
39248<i>Throws:</i> Nothing.
39249</p>
39250<p>
39251<i>Complexity:</i> Constant time.
39252</p>
39253</blockquote>
39254</li>
39255</ol>
39256</li>
39257
39258</ol>
39259
39260
39261
39262
39263
39264
39265<hr>
39266<h3><a name="878"></a>878. <tt>forward_list</tt> preconditions</h3>
39267<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#WP">WP</a>
39268 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2008-08-23  <b>Last modified:</b> 2009-07-18</p>
39269<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
39270<p><b>Discussion:</b></p>
39271       <p>
39272
39273<tt>forward_list</tt> member functions that take
39274a <tt>forward_list::iterator</tt> (denoted <tt>position</tt> in the
39275function signatures) argument have the following precondition:
39276
39277       </p>
39278       <blockquote>
39279
39280<i>Requires:</i> <tt>position</tt> is dereferenceable or equal
39281to <tt>before_begin()</tt>.
39282
39283       </blockquote>
39284       <p>
39285
39286I believe what's actually intended is this:
39287
39288       </p>
39289       <blockquote>
39290
39291<i>Requires:</i> <tt>position</tt> is in the range
39292[<tt>before_begin()</tt>, <tt>end()</tt>).
39293
39294       </blockquote>
39295       <p>
39296
39297That is, when it's dereferenceable, <tt>position</tt> must point
39298into <tt>*this</tt>, not just any <tt>forward_list</tt> object.
39299
39300       </p>
39301
39302<p><i>[
39303San Francisco:
39304]</i></p>
39305
39306
39307<blockquote>
39308Robert suggested alternate proposed wording which had large support.
39309</blockquote>
39310
39311<p><i>[
39312Post Summit:
39313]</i></p>
39314
39315
39316<blockquote>
39317<p>
39318Walter: "position is before_begin() or a dereferenceable": add "is" after the "or"
39319</p>
39320<p>
39321With that minor update, Recommend Tentatively Ready.
39322</p>
39323</blockquote>
39324
39325
39326
39327<p><b>Proposed resolution:</b></p>
39328       <p>
39329
39330Change the <i>Requires</i> clauses
39331 [forwardlist] , p21, p24, p26, p29, and,
3933223.3.3.5 [forwardlist.ops], p39, p43, p47
39333as follows:
39334
39335       </p>
39336       <blockquote>
39337
39338<i>Requires:</i> <tt>position</tt> is <ins><tt>before_begin()</tt> or is a</ins>
39339dereferenceable
39340<ins>iterator in the range <tt>[begin(), end())</tt></ins>
39341<del>or equal to <tt>before_begin()</tt></del>. ...
39342
39343       </blockquote>
39344   
39345
39346
39347
39348<hr>
39349<h3><a name="881"></a>881. shared_ptr conversion issue</h3>
39350<p><b>Section:</b> 20.8.15.2.1 [util.smartptr.shared.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
39351 <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2008-08-30  <b>Last modified:</b> 2009-10-26</p>
39352<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>
39353<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
39354<p><b>Discussion:</b></p>
39355<p>
39356We've changed <tt>shared_ptr&lt;Y&gt;</tt> to not convert to <tt>shared_ptr&lt;T&gt;</tt> when <tt>Y*</tt>
39357doesn'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
39358converting copy constructor though.
39359<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2351.htm">N2351</a>
39360later added move support, and
39361the converting move constructor is not constrained.
39362</p>
39363
39364<p><i>[
39365San Francisco:
39366]</i></p>
39367
39368
39369<blockquote>
39370We might be able to move this to NAD, Editorial once shared_ptr is
39371conceptualized, but we want to revisit this issue to make sure.
39372</blockquote>
39373
39374<p><i>[
393752009-07 Frankfurt
39376]</i></p>
39377
39378
39379<blockquote>
39380<p>
39381Moved to Ready.
39382</p>
39383<p>
39384This issue now represents the favored format for specifying constrained templates.
39385</p>
39386</blockquote>
39387
39388
39389
39390<p><b>Proposed resolution:</b></p>
39391<p>
39392We need to change the Requires clause of the move constructor:
39393</p>
39394
39395<blockquote><pre>shared_ptr(shared_ptr&amp;&amp; r); 
39396template&lt;class Y&gt; shared_ptr(shared_ptr&lt;Y&gt;&amp;&amp; r); 
39397</pre>
39398<blockquote>
39399<i><del>Requires</del> <ins>Remarks</ins>:</i> <del>For the second constructor <tt>Y*</tt> shall be
39400convertible to <tt>T*</tt>.</del>
39401<ins>
39402The second constructor shall not participate in overload resolution
39403unless <tt>Y*</tt> is convertible to <tt>T*</tt>.
39404</ins>
39405</blockquote>
39406</blockquote>
39407
39408<p>
39409in 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
39410(it now resolves to the move constructor).
39411</p>
39412
39413
39414
39415
39416
39417
39418<hr>
39419<h3><a name="882"></a>882. <tt>duration</tt> non-member arithmetic requirements</h3>
39420<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>
39421 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2008-09-08  <b>Last modified:</b> 2008-09-26</p>
39422<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>
39423<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
39424<p><b>Discussion:</b></p>
39425<p>
39426<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2661.htm">N2661</a>
39427specified the following requirements for the non-member <tt>duration</tt>
39428arithmetic:
39429</p>
39430
39431<blockquote>
39432
39433<pre>template &lt;class Rep1, class Period, class Rep2&gt;
39434  duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt;
39435  operator*(const duration&lt;Rep1, Period&gt;&amp; d, const Rep2&amp; s);
39436</pre>
39437<blockquote>
39438<i>Requires:</i> Let <tt>CR</tt> represent the <tt>common_type</tt> of <tt>Rep1</tt> and
39439<tt>Rep2</tt>.  Both <tt>Rep1</tt> and <tt>Rep2</tt> shall be implicitly convertible
39440to CR, diagnostic required.
39441</blockquote>
39442
39443<pre>template &lt;class Rep1, class Period, class Rep2&gt;
39444  duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt;
39445  operator*(const Rep1&amp; s, const duration&lt;Rep2, Period&gt;&amp; d);
39446</pre>
39447
39448<blockquote>
39449<i>Requires:</i> Let <tt>CR</tt> represent the <tt>common_type</tt> of
39450<tt>Rep1</tt> and <tt>Rep2</tt>. Both <tt>Rep1</tt> and <tt>Rep2</tt>
39451shall be implicitly convertible to <tt>CR</tt>, diagnostic required.
39452</blockquote>
39453
39454<pre>template &lt;class Rep1, class Period, class Rep2&gt;
39455  duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt;
39456  operator/(const duration&lt;Rep1, Period&gt;&amp; d, const Rep2&amp; s);
39457</pre>
39458
39459<blockquote>
39460<i>Requires:</i> Let <tt>CR</tt> represent the <tt>common_type</tt> of
39461<tt>Rep1</tt> and <tt>Rep2</tt>. Both <tt>Rep1</tt> and <tt>Rep2</tt> shall be
39462implicitly convertible to <tt>CR</tt>, and <tt>Rep2</tt> shall not be an
39463instantiation of <tt>duration</tt>, diagnostic required.
39464</blockquote>
39465
39466</blockquote>
39467
39468<p>
39469During transcription into the working paper, the requirements clauses on these
39470three functions was changed to:
39471</p>
39472
39473<blockquote>
39474<i>Requires:</i> <tt>CR(Rep1, Rep2)</tt> shall exist. Diagnostic required.
39475</blockquote>
39476
39477<p>
39478This is a non editorial change with respect to
39479<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2661.htm">N2661</a>
39480as user written representations which are used in <tt>duration</tt> need not be
39481implicitly convertible to or from arithmetic types in order to interoperate with
39482<tt>duration</tt>s based on arithmetic types.  An explicit conversion will do
39483fine for most expressions as long as there exists a <tt>common_type</tt> specialization
39484relating the user written representation and the arithmetic type.  For example:
39485</p>
39486
39487<blockquote><pre>class saturate
39488{
39489public:
39490  explicit saturate(long long i);
39491  ...
39492};
39493
39494namespace std {
39495
39496template &lt;&gt;
39497struct common_type&lt;saturate, long long&gt;
39498{
39499    typedef saturate type;
39500};
39501
39502template &lt;&gt;
39503struct common_type&lt;long long, saturate&gt;
39504{
39505    typedef saturate type;
39506};
39507
39508}  // std
39509
39510millisecond ms(3);  // integral-based duration
39511duration&lt;saturate, milli&gt; my_ms = ms;  // ok, even with explicit conversions
39512my_ms = my_ms + ms;                    // ok, even with explicit conversions
39513</pre></blockquote>
39514
39515<p>
39516However, when dealing with multiplication of a duration and its representation,
39517implicit convertibility is required between the rhs and the lhs's representation
39518for the member <tt>*=</tt> operator:
39519</p>
39520
39521<blockquote><pre>template &lt;class Rep, class Period = ratio&lt;1&gt;&gt; 
39522class duration { 
39523public: 
39524   ...
39525   duration&amp; operator*=(const rep&amp; rhs);
39526   ...
39527};
39528...
39529ms *= 2;               // ok, 2 is implicitly convertible to long long
39530my_ms *= saturate(2);  // ok, rhs is lhs's representation
39531my_ms *= 2;            // error, 2 is not implicitly convertible to saturate
39532</pre></blockquote>
39533
39534<p>
39535The last line does not (and should not) compile.  And we want non-member multiplication
39536to have the same behavior as member arithmetic:
39537</p>
39538
39539<blockquote><pre>my_ms = my_ms * saturate(2);  // ok, rhs is lhs's representation
39540my_ms = my_ms * 2;            // <em>should be</em> error, 2 is not implicitly convertible to saturate
39541</pre></blockquote>
39542
39543<p>
39544The requirements clauses of
39545<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2661.htm">N2661</a>
39546make the last line an error as expected.  However the latest working draft at
39547this time
39548(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>)
39549allows the last line to compile.
39550</p>
39551
39552<p>
39553All that being said, there does appear to be an error in these requirements clauses
39554as specified by 
39555<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2661.htm">N2661</a>.
39556</p>
39557
39558<blockquote>
39559<i>Requires:</i> ... <em>Both</em> <tt>Rep1</tt> and <tt>Rep2</tt> shall be implicitly convertible
39560to CR, diagnostic required.
39561</blockquote>
39562
39563<p>
39564It is not necessary for both <tt>Rep</tt>s to be <i>implicitly</i> convertible to
39565the <tt>CR</tt>.  It is only necessary for the rhs <tt>Rep</tt> to be implicitly
39566convertible to the <tt>CR</tt>.  The <tt>Rep</tt> within the <tt>duration</tt>
39567should be allowed to only be explicitly convertible to the <tt>CR</tt>.  The
39568explicit-conversion-requirement is covered under 20.9.3.7 [time.duration.cast].
39569</p>
39570
39571
39572
39573<p><b>Proposed resolution:</b></p>
39574<p>
39575Change the requirements clauses under 20.9.3.5 [time.duration.nonmember]:
39576</p>
39577
39578<blockquote>
39579
39580<pre>template &lt;class Rep1, class Period, class Rep2&gt;
39581  duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt;
39582  operator*(const duration&lt;Rep1, Period&gt;&amp; d, const Rep2&amp; s);
39583</pre>
39584
39585<blockquote>
39586<i>Requires:</i> <del><tt>CR(Rep1, Rep2)</tt> shall exist.</del>
39587<ins><tt>Rep2</tt> shall be implicitly convertible to <tt>CR(Rep1, Rep2)</tt>.</ins>
39588Diagnostic required.
39589</blockquote>
39590
39591<pre>template &lt;class Rep1, class Period, class Rep2&gt;
39592  duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt;
39593  operator*(const Rep1&amp; s, const duration&lt;Rep2, Period&gt;&amp; d);
39594</pre>
39595
39596<blockquote>
39597<i>Require<ins>s</ins><del>d behavior</del>:</i> <del><tt>CR(Rep1, Rep2)</tt> shall exist.</del>
39598<ins><tt>Rep1</tt> shall be implicitly convertible to <tt>CR(Rep1, Rep2)</tt>.</ins>
39599Diagnostic required.
39600</blockquote>
39601
39602<pre>template &lt;class Rep1, class Period, class Rep2&gt;
39603  duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt;
39604  operator/(const duration&lt;Rep1, Period&gt;&amp; d, const Rep2&amp; s);
39605</pre>
39606
39607<blockquote>
39608<i>Requires:</i> <del><tt>CR(Rep1, Rep2)</tt> shall exist</del>
39609<ins><tt>Rep2</tt> shall be implicitly convertible to <tt>CR(Rep1, Rep2)</tt></ins>
39610and <tt>Rep2</tt> shall not
39611be an instantiation of <tt>duration</tt>. Diagnostic required.
39612</blockquote>
39613
39614</blockquote>
39615
39616
39617
39618
39619
39620<hr>
39621<h3><a name="883"></a>883. swap circular definition</h3>
39622<p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
39623 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-09-10  <b>Last modified:</b> 2009-10-26</p>
39624<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>
39625<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>
39626<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
39627<p><b>Discussion:</b></p>
39628
39629<p>
39630Note in particular that Table 90 "Container Requirements" gives
39631semantics of <tt>a.swap(b)</tt> as <tt>swap(a,b)</tt>, yet for all
39632containers we define <tt>swap(a,b)</tt> to call <tt>a.swap(b)</tt> - a
39633circular definition.
39634</p>
39635
39636<p><i>[
39637San Francisco:
39638]</i></p>
39639
39640
39641<blockquote>
39642Robert to propose a resolution along the lines of "Postcondition: "a =
39643b, b = a" This will be a little tricky for the hash containers, since
39644they don't have <tt>operator==</tt>.
39645</blockquote>
39646
39647<p><i>[
39648Post Summit Anthony Williams provided proposed wording.
39649]</i></p>
39650
39651
39652<p><i>[
396532009-07 Frankfurt
39654]</i></p>
39655
39656
39657<blockquote>
39658Moved to Ready with minor edits (which have been made).
39659</blockquote>
39660
39661
39662
39663<p><b>Proposed resolution:</b></p>
39664<p>
39665In table 80 in section 23.2.1 [container.requirements.general],
39666replace the postcondition of <tt>a.swap(b)</tt> with the following:
39667</p>
39668
39669<blockquote>
39670<table border="1">
39671<caption>Table 80 -- Container requirements</caption>
39672<tbody><tr>
39673<th>Expression</th>
39674<th>Return type</th>
39675<th>Operational semantics</th>
39676<th>Assertion/note pre-/post-conidtion</th>
39677<th>Complexity</th>
39678</tr>
39679<tr>
39680<td>...</td>
39681<td>...</td>
39682<td>...</td>
39683<td>...</td>
39684<td>...</td>
39685</tr>
39686<tr>
39687<td><tt>a.swap(b);</tt></td>
39688<td><tt>void</tt></td>
39689<td>&nbsp;</td>
39690<td><del><tt>swap(a,b)</tt></del>
39691<ins>Exchange the contents of <tt>a</tt> and <tt>b</tt>.</ins></td>
39692<td>(Note A)</td>
39693</tr>
39694</tbody></table>
39695</blockquote>
39696
39697<p>
39698Remove the reference to swap from the paragraph following the table.
39699</p>
39700
39701<blockquote>
39702Notes: the algorithms <del><tt>swap()</tt>, </del><tt>equal()</tt> and
39703<tt>lexicographical_compare()</tt> are defined in Clause 25. ...
39704</blockquote>
39705
39706
39707
39708
39709
39710<hr>
39711<h3><a name="886"></a>886. tuple construction</h3>
39712<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#WP">WP</a>
39713 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-09-15  <b>Last modified:</b> 2009-10-26</p>
39714<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>
39715<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
39716<p><b>Discussion:</b></p>
39717<p>
3971820.5.2.1 [tuple.cnstr]:
39719</p>
39720<blockquote>
39721<i>Effects:</i> Default initializes each element.
39722</blockquote>
39723
39724<p>
39725Could be clarified to state each "non-trivial" element.  Otherwise
39726we have a conflict with Core deinfition of default initialization -
39727trivial types do not get initialized (rather than initialization
39728having no effect)
39729</p>
39730
39731<p>
39732I'm going to punt on this one, because it's not an issue that's
39733related to concepts. I suggest bringing it to Howard's attention on
39734the reflector.
39735</p>
39736
39737<p><i>[
39738San Francisco:
39739]</i></p>
39740
39741
39742<blockquote>
39743<p>
39744Text in draft doesn't mean anything, changing to "non-trivial" makes it
39745meaningful.
39746</p>
39747<p>
39748We prefer "value initializes". Present implementations use
39749value-initialization. Users who don't want value initialization have
39750alternatives.
39751</p>
39752<p>
39753Request resolution text from Alisdair.
39754</p>
39755
39756<p>
39757This 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.
39758</p>
39759</blockquote>
39760
39761<p><i>[
397622009-05-04 Alisdair provided wording and adds:
39763]</i></p>
39764
39765
39766<blockquote>
39767<p>
39768Note: This <em>IS</em> a change of semantic from TR1, although one the room agreed
39769with during the discussion.  To preserve TR1 semantics, this would have been
39770worded:
39771</p>
39772<blockquote><pre>requires DefaultConstructible&lt;Types&gt;... tuple();
39773</pre>
39774<blockquote>
39775-2-   <i>Effects:</i> Default-initializes each non-trivial element.
39776</blockquote>
39777</blockquote>
39778
39779
39780</blockquote>
39781
39782<p><i>[
397832009-07 Frankfurt
39784]</i></p>
39785
39786
39787<blockquote>
39788Move to Ready.
39789</blockquote>
39790
39791
39792
39793<p><b>Proposed resolution:</b></p>
39794<p>
39795Change p2 in Construction 20.5.2.1 [tuple.cnstr]:
39796</p>
39797
39798<blockquote><pre>requires DefaultConstructible&lt;Types&gt;... tuple();
39799</pre>
39800<blockquote>
39801<p>
39802-2- <i>Effects:</i> <del>Default</del> <ins>Value-</ins>initializes each element.
39803</p>
39804</blockquote>
39805</blockquote>
39806
39807
39808
39809
39810
39811
39812<hr>
39813<h3><a name="888"></a>888. this_thread::yield too strong</h3>
39814<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#WP">WP</a>
39815 <b>Submitter:</b> Lawrence Crowl <b>Opened:</b> 2008-09-15  <b>Last modified:</b> 2009-07-18</p>
39816<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
39817<p><b>Discussion:</b></p>
39818<p>
39819I never thought I'd say this, but <tt>this_thread::yield</tt> seems to be too
39820strong in specification.  The issue is that some systems distinguish
39821between yielding to another thread in the same process and yielding
39822to another process.  Given that the C++ standard only talks about
39823a single program, one can infer that the specification allows yielding
39824only to another thread within the same program.  Posix has no
39825facility for that behavior.  Can you please file an issue to weaken
39826the wording.  Perhaps "Offers the operating system the opportunity
39827to reschedule."
39828</p>
39829
39830<p><i>[
39831Post Summit:
39832]</i></p>
39833
39834
39835<blockquote>
39836Recommend move to Tentatively Ready.
39837</blockquote>
39838
39839
39840
39841<p><b>Proposed resolution:</b></p>
39842<p>
39843Change 30.3.2 [thread.thread.this]/3:
39844</p>
39845
39846<blockquote>
39847<pre>void this_thread::yield();
39848</pre>
39849<blockquote>
39850<i>Effects:</i> Offers the <del>operating system</del> <ins>implementation</ins>
39851the opportunity to <ins>re</ins>schedule.
39852<del>another thread.</del>
39853</blockquote>
39854</blockquote>
39855
39856
39857
39858
39859
39860<hr>
39861<h3><a name="890"></a>890. Improving <tt>&lt;system_error&gt;</tt> initialization</h3>
39862<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#WP">WP</a>
39863 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2008-09-14  <b>Last modified:</b> 2009-07-18</p>
39864<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
39865<p><b>Discussion:</b></p>
39866<p>
39867The <tt>static const error_category</tt> objects <tt>generic_category</tt> and
39868<tt>system_category</tt> in header <tt>&lt;system_error&gt;</tt> are currently declared:
39869</p>
39870
39871<blockquote><pre>const error_category&amp; get_generic_category();
39872const error_category&amp; get_system_category();
39873
39874static const error_category&amp; generic_category = get_generic_category();
39875static const error_category&amp; system_category = get_system_category();
39876</pre></blockquote>
39877
39878<p>
39879This formulation has several problems:
39880</p>
39881
39882<ul>
39883<li>
39884Implementation details are exposed, since initialization is specified in
39885the interface. This over-constrains implementations without offsetting
39886user benefits. The form of initialization specified may be less than
39887maximally efficient on some platforms.
39888</li>
39889<li>
39890Use of the objects is more expensive in terms of number of machine level
39891instructions. See <i>Implementation experience</i> below.
39892</li>
39893<li>
39894Depending on the compiler, some cost may be incurred by each translation unit
39895that includes the header, even if the objects are not used. This is a
39896common scenario in user code, since the header is included by other
39897standard library headers. It should be mentioned that at least one
39898compilers is able to optimize this cost away, however.
39899</li>
39900</ul>
39901
39902<p>
39903IO streams uses a somewhat different formulation for iostream_category, but 
39904still suffer much the same problems.
39905</p>
39906
39907<p>
39908The original plan was to eliminate these problems by applying the C++0x
39909<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
39910to be unimplementable, since it would require a <tt>constexpr</tt> object of a
39911class with virtual functions, and that is not allowed by the core
39912language.
39913</p>
39914
39915<p>
39916The proposed resolution was developed as an alternative. It mitigates the above 
39917problems by removing initialization from the visible interface, allowing 
39918implementations flexibility.
39919</p>
39920
39921<p>
39922<b>Implementation experience:</b>
39923</p>
39924
39925<p>
39926Prototype implementations of the current WP interface and proposed
39927resolution interface were tested with recent Codegear, GCC, Intel, and Microsoft 
39928compilers on Windows. The code generated by the Microsoft compiler was studied 
39929at length; the WP and proposal versions generated very similar code. For both versions 
39930the compiler did make use of static
39931initialization; apparently the compiler applied an implicit <tt>constexpr</tt>
39932where useful, even in cases where <tt>constexpr</tt> would not be permitted by
39933the language!
39934</p>
39935
39936<p>
39937<b>Acknowledgements:</b>
39938</p>
39939
39940<p>
39941Martin Sebor, Chris Kohlhoff, and John Lakos provided useful ideas and comments on initialization issues.
39942</p>
39943
39944<p><i>[
39945San Francisco:
39946]</i></p>
39947
39948
39949<blockquote>
39950<p>
39951Martin: prefers not to create more file-scope static objects, and would
39952like to see <tt>get_*</tt> functions instead.
39953</p>
39954</blockquote>
39955
39956
39957<p><i>[Pre-Summit:]</i></p>
39958
39959<blockquote>
39960
39961
39962<p>
39963Beman: The proposed resolution has been reworked to remove the file-scope 
39964static objects, per Martin's suggestions. The <tt>get_</tt> prefix has been 
39965eliminated from the function names as no longer necessary and to conform with 
39966standard library naming practice.
39967</p>
39968
39969</blockquote>
39970
39971<p><i>[
39972Post Summit:
39973]</i></p>
39974
39975
39976<blockquote>
39977Agreement that this is wise and essential, text provided works and has
39978been implemented. Seems to be widespread consensus. Move to Tentative Ready.
39979</blockquote>
39980
39981
39982
39983<p><b>Proposed resolution:</b></p>
39984
39985<p>Change 17.6.4.13 [value.error.codes] Value of error codes as indicated:</p>
39986<blockquote>
39987 <p>Certain functions in the C++ standard library report errors via a 
39988 <tt>std::error_code</tt> (19.4.2.2) object. That object's <tt>category()</tt> member shall 
39989 return <del>a reference to</del> <code>std::system_category</code><tt><ins><code>()</code></ins></tt> for errors originating from the 
39990 operating system, or a reference to an implementation-defined error_category 
39991 object for errors originating elsewhere. The implementation shall define the 
39992 possible values of value() for each of these error categories. [<i>Example:</i> For 
39993 operating systems that are based on POSIX, implementations are encouraged to 
39994 define the <code>std::system_category</code><tt><ins><code>()</code></ins></tt> values as identical to the POSIX <tt>errno</tt> values, 
39995 with additional values as defined by the operating system's documentation. 
39996 Implementations for operating systems that are not based on POSIX are 
39997 encouraged to define values identical to the operating system's values. For 
39998 errors that do not originate from the operating system, the implementation may 
39999 provide enums for the associated values --<i>end example</i>]</p>
40000</blockquote>
40001
40002<p>
40003Change 19.5.1.1 [syserr.errcat.overview] Class <tt>error_category</tt> overview
40004<tt>error_category</tt> synopsis as indicated:
40005</p>
40006
40007<blockquote>
40008<pre>const error_category&amp; <del>get_</del>generic_category();
40009const error_category&amp; <del>get_</del>system_category();
40010
40011<del>static storage-class-specifier const error_category&amp; generic_category = get_generic_category();
40012static storage-class-specifier const error_category&amp; system_category = get_system_category();</del>
40013</pre>
40014</blockquote>
40015
40016<p>
40017Change 19.5.1.5 [syserr.errcat.objects] Error category objects as indicated:
40018</p>
40019
40020<blockquote>
40021<pre>const error_category&amp; <del>get_</del>generic_category();
40022</pre>
40023
40024<blockquote>
40025
40026<p>
40027<i>Returns:</i> A reference to an object of a type derived from class <tt>error_category</tt>.
40028</p>
40029
40030<p>
40031<i>Remarks:</i> The object's <tt>default_error_condition</tt> and <tt>equivalent</tt> virtual
40032functions shall behave as specified for the class <tt>error_category</tt>. The
40033object's <tt>name</tt> virtual function shall return a pointer to the string
40034<tt>"GENERIC"</tt>.
40035</p>
40036</blockquote>
40037
40038<pre>const error_category&amp; <del>get_</del>system_category();
40039</pre>
40040
40041<blockquote>
40042<p>
40043<i>Returns:</i> A reference to an object of a type derived from class <tt>error_category</tt>.
40044</p>
40045
40046<p>
40047<i>Remarks:</i> The object's <tt>equivalent</tt> virtual functions shall behave as
40048specified for class <tt>error_category</tt>. The object's <tt>name</tt> virtual function
40049shall return a pointer to the string <tt>"system"</tt>. The object's
40050<tt>default_error_condition</tt> virtual function shall behave as follows:
40051</p>
40052<blockquote>
40053If the argument <tt>ev</tt> corresponds to a POSIX <tt>errno</tt> value <tt>posv</tt>, the function
40054shall return <tt>error_condition(posv, generic_category<ins>()</ins>)</tt>. Otherwise, the
40055function shall return <tt>error_condition(ev, system_category<ins>()</ins>)</tt>. What
40056constitutes correspondence for any given operating system is
40057unspecified. [<i>Note:</i> The number of potential system error codes is large
40058and unbounded, and some may not correspond to any POSIX <tt>errno</tt> value.
40059Thus implementations are given latitude in determining correspondence.
40060<i>-- end note</i>]
40061</blockquote>
40062</blockquote>
40063
40064</blockquote>
40065
40066<p>Change 19.5.2.2 [syserr.errcode.constructors] Class error_code constructors 
40067as indicated:</p>
40068<blockquote>
40069 <pre>error_code();</pre>
40070 <blockquote>
40071 <p><i>Effects:</i> Constructs an object of type error_code.</p>
40072 <p><i>Postconditions:</i> <code>val_ == 0 </code>and <code>cat_ == &amp;system_category</code><tt><ins>()</ins></tt>.</p>
40073 </blockquote>
40074</blockquote>
40075<p>Change 19.5.2.3 [syserr.errcode.modifiers] Class error_code modifiers as 
40076indicated:</p>
40077<blockquote>
40078 <pre>void clear();</pre>
40079 <blockquote>
40080 <p>Postconditions: <code>value() == 0</code> and <code>category() == 
40081 system_category</code><tt><ins>()</ins></tt>.</p>
40082 </blockquote>
40083</blockquote>
40084<p>Change 19.5.2.5 [syserr.errcode.nonmembers] Class error_code non-member 
40085functions as indicated:</p>
40086<blockquote>
40087 <pre>error_code make_error_code(errc e);</pre>
40088 <blockquote>
40089 <p><i>Returns:</i> <code>error_code(static_cast&lt;int&gt;(e), generic_category</code><tt><ins>()</ins></tt><code>)</code>.</p>
40090 </blockquote>
40091</blockquote>
40092<p>Change 19.5.3.2 [syserr.errcondition.constructors] Class error_condition 
40093constructors as indicated:</p>
40094<blockquote>
40095 <pre>error_condition();</pre>
40096 <blockquote>
40097 <p><i>Effects:</i> Constructs an object of type <code>error_condition</code>.</p>
40098 <p><i>Postconditions:</i> <code>val_ == 0</code> and <code>cat_ == &amp;generic_category</code><tt><ins>()</ins></tt>.</p>
40099 </blockquote>
40100</blockquote>
40101<p>Change 19.5.3.3 [syserr.errcondition.modifiers] Class error_condition 
40102modifiers as indicated:</p>
40103<blockquote>
40104 <pre>void clear();</pre>
40105 <blockquote>
40106 <p><i>Postconditions:</i> <code>value() == 0</code> and <code>category() == 
40107 generic_category</code><tt><ins>()</ins></tt>.</p>
40108 </blockquote>
40109</blockquote>
40110<p>Change 19.5.3.5 [syserr.errcondition.nonmembers] Class error_condition 
40111non-member functions as indicated:</p>
40112<blockquote>
40113 <pre>error_condition make_error_condition(errc e);</pre>
40114 <blockquote>
40115 <p><i>Returns:</i> <tt>error_condition(static_cast&lt;int&gt;(e), generic_category<ins>()</ins>)</tt>.</p>
40116 </blockquote>
40117</blockquote>
40118 <p>Change 27.5 [iostreams.base] Iostreams base classes, Header &lt;ios&gt; 
40119 synopsis as indicated:</p>
40120<blockquote>
40121 <pre>concept_map ErrorCodeEnum&lt;io_errc&gt; { };
40122error_code make_error_code(io_errc e);
40123error_condition make_error_condition(io_errc e);
40124<del>storage-class-specifier</del> const error_category&amp; iostream_category<ins>()</ins>;</pre>
40125</blockquote>
40126<p>Change 27.5.2.1.1 [ios::failure] Class ios_base::failure, paragraph 2 as 
40127indicated:</p>
40128<blockquote>
40129<p>When throwing ios_base::failure exceptions, implementations should provide 
40130values of ec that identify the specific reason for the failure. [ Note: Errors 
40131arising from the operating system would typically be reported as <tt>
40132system_category</tt><tt><ins>()</ins></tt> errors with an error value of the 
40133error number reported by the operating system. Errors arising from within the 
40134stream library would typically be reported as <tt>error_code(io_errc::stream, 
40135iostream_category<ins>()</ins>)</tt>. --end note ]</p>
40136</blockquote>
40137<p>Change 27.5.5.5 [error.reporting] Error reporting as indicated:</p>
40138<blockquote>
40139 <pre>error_code make_error_code(io_errc e);</pre>
40140 <blockquote>
40141 <p><i>Returns:</i> <code>error_code(static_cast&lt;int&gt;(e), iostream_category</code><ins>()</ins><code>)</code>.</p>
40142 </blockquote>
40143 <pre>error_condition make_error_condition(io_errc e);</pre>
40144 <blockquote>
40145 <p><i>Returns:</i> <code>error_condition(static_cast&lt;int&gt;(e), 
40146 iostream_category</code><ins>()</ins><code>)</code>.</p>
40147 </blockquote>
40148 <pre><del>storage-class-specifier</del> const error_category&amp; iostream_category<ins>()</ins>;</pre>
40149 <blockquote>
40150 <del><p>The implementation shall initialize iostream_category. Its storage-class-specifier 
40151 may be static or extern. It is unspecified whether initialization is static 
40152 or dynamic (3.6.2). If initialization is dynamic, it shall occur before 
40153 completion of the dynamic initialization of the first translation unit 
40154 dynamically initialized that includes header &lt;system_error&gt;.</p></del>
40155<p>
40156<ins><i>Returns:</i> A reference to an object of a type derived from class <tt>error_category</tt>.</ins>
40157</p>
40158<p><i>Remarks:</i> The object's default_error_condition and equivalent virtual functions shall 
40159behave as specified for the class error_category. The object's name virtual 
40160function shall return a pointer to the string "iostream".</p>
40161 </blockquote>
40162</blockquote>
40163
40164
40165
40166
40167
40168
40169
40170<hr>
40171<h3><a name="894"></a>894. longjmp and destructors</h3>
40172<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>
40173 <b>Submitter:</b> Lawrence Crowl, Alisdair Meredith <b>Opened:</b> 2008-09-17  <b>Last modified:</b> 2009-03-09</p>
40174<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>
40175<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
40176<p><b>Discussion:</b></p>
40177<p>
40178The interaction between <tt>longjmp</tt> and exceptions seems unnecessarily
40179restrictive and not in keeping with existing practice.
40180</p>
40181
40182
40183<p><b>Proposed resolution:</b></p>
40184<p>
40185Edit paragraph 4 of 18.10 [support.runtime] as follows:
40186</p>
40187
40188<blockquote>
40189The function signature <tt>longjmp(jmp_buf jbuf, int val)</tt> has more
40190restricted behavior in this International Standard. A
40191<tt>setjmp/longjmp</tt> call pair has undefined behavior if replacing the
40192<tt>setjmp</tt> and <tt>longjmp</tt> by <tt>catch</tt> and
40193<tt>throw</tt> would <del>destroy</del>
40194<ins>invoke any non-trivial destructors for</ins>
40195any automatic objects.
40196</blockquote>
40197
40198
40199
40200
40201
40202<hr>
40203<h3><a name="898"></a>898. Small contradiction in n2723 to forward to committee</h3>
40204<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#WP">WP</a>
40205 <b>Submitter:</b> Arch Robison <b>Opened:</b> 2008-09-08  <b>Last modified:</b> 2009-07-18</p>
40206<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>
40207<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
40208<p><b>Discussion:</b></p>
40209<p>
40210I ran across a small contradiction in working draft n2723. 
40211</p>
40212<blockquote>
40213<p>
4021423.3.3 [forwardlist]p2: A <tt>forward_list</tt> satisfies all of the
40215requirements of a container (table 90), except that the <tt>size()</tt> member
40216function is not provided.
40217</p>
40218<p>
4021923.3.3.5 [forwardlist.ops]p57: <i>Complexity:</i> At most <tt>size() + x.size() - 1</tt>
40220comparisons.
40221</p>
40222</blockquote>
40223<p>
40224Presumably 23.3.3.5 [forwardlist.ops]p57 needs to be rephrased to not use
40225<tt>size()</tt>, or note that it is used there only for sake of notational convenience. 
40226</p>
40227
40228<p><i>[
402292009-03-29 Beman provided proposed wording.
40230]</i></p>
40231
40232
40233<p><i>[
40234Batavia (2009-05):
40235]</i></p>
40236
40237<blockquote>
40238<p>
40239We agree with the proposed resolution.
40240</p>
40241<p>
40242Move to Tentatively Ready.
40243</p>
40244</blockquote>
40245
40246
40247<p><b>Proposed resolution:</b></p>
40248<p><i>Change 23.3.3.5 [forwardlist.ops],
40249forward_list operations, paragraph 19, merge complexity as indicated:
40250</i></p>
40251<blockquote><i>Complexity:</i> At most <tt><del>size() + x.size()</del>
40252<ins>distance(begin(), end()) + distance(x.begin(), x.end())</ins> - 1</tt>
40253comparisons.
40254</blockquote>
40255
40256
40257
40258
40259
40260<hr>
40261<h3><a name="899"></a>899. Adjusting <tt>shared_ptr</tt> for <tt>nullptr_t</tt></h3>
40262<p><b>Section:</b> 20.8.15.2.2 [util.smartptr.shared.dest] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
40263 <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2008-09-18  <b>Last modified:</b> 2009-07-18</p>
40264<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>
40265<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
40266<p><b>Discussion:</b></p>
40267<p>
40268James Dennett, message c++std-lib-22442:
40269</p>
40270<blockquote>
40271The wording below addresses one case of this, but opening an
40272issue to address the need to sanity check uses of the term "pointer"
40273in 20.8.15.2 [util.smartptr.shared] would be a good thing.
40274</blockquote>
40275<p>
40276There's one more reference, in <tt>~shared_ptr;</tt> we can apply your suggested change to it, too. That is:
40277</p>
40278<p>
40279Change 20.8.15.2.2 [util.smartptr.shared.dest]/1 second bullet from:
40280</p>
40281<blockquote>
40282Otherwise, if *this owns a pointer p and a deleter d, d(p) is called.
40283</blockquote>
40284<p>
40285to:
40286</p>
40287<blockquote>
40288Otherwise, if *this owns an object p and a deleter d, d(p) is called.
40289</blockquote>
40290
40291<p><i>[
40292Post Summit:
40293]</i></p>
40294
40295
40296<blockquote>
40297Recommend Review.
40298</blockquote>
40299
40300<p><i>[
40301Batavia (2009-05):
40302]</i></p>
40303
40304<blockquote>
40305<p>
40306Peter Dimov notes the analogous change has already been made
40307to "the new nullptr_t taking constructors
40308in 20.8.15.2.1 [util.smartptr.shared.const] p9-13."
40309</p>
40310<p>
40311We agree with the proposed resolution.
40312Move to Tentatively Ready.
40313</p>
40314</blockquote>
40315
40316
40317<p><b>Proposed resolution:</b></p>
40318<p>
40319Change 20.8.15.2.2 [util.smartptr.shared.dest]/1 second bullet:
40320</p>
40321<blockquote>
40322<ul>
40323<li>...</li>
40324<li>
40325Otherwise, if <tt>*this</tt> <i>owns</i> <del>a pointer</del>
40326<ins>an object</ins> <tt>p</tt> and a
40327deleter <tt>d</tt>, <tt>d(p)</tt> is called.
40328</li>
40329</ul>
40330</blockquote>
40331
40332
40333
40334
40335
40336<hr>
40337<h3><a name="904"></a>904. result_of argument types</h3>
40338<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#WP">WP</a>
40339 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2008-09-10  <b>Last modified:</b> 2009-07-18</p>
40340<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.ret">issues</a> in [func.ret].</p>
40341<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
40342<p><b>Discussion:</b></p>
40343<p>
40344The WP and TR1 have the same text regarding the argument types of a
40345<tt>result_of</tt> expression:
40346</p>
40347<blockquote>
40348The values <tt>ti</tt> are lvalues when the corresponding type <tt>Ti</tt> is a
40349reference type, and rvalues otherwise.
40350</blockquote>
40351<p>
40352I read this to mean that this compiles:
40353</p>
40354<blockquote><pre>typedef int (*func)(int&amp;);
40355result_of&lt;func(int&amp;&amp;)&gt;::type i = 0;
40356</pre></blockquote>
40357<p>
40358even though this doesn't:
40359</p>
40360<blockquote><pre>int f(int&amp;);
40361f( std::move(0) );
40362</pre></blockquote>
40363<p>
40364Should the text be updated to say "when <tt>Ti</tt> is an lvalue-reference
40365type" or am I missing something?
40366</p>
40367<p>
40368I later came up with this self-contained example which won't compile,
40369but I think it should:
40370</p>
40371<blockquote><pre>struct X {
40372  void operator()(int&amp;);
40373  int operator()(int&amp;&amp;);
40374} x;
40375
40376std::result_of&lt; X(int&amp;&amp;) &gt;::type i = x(std::move(0));
40377</pre></blockquote>
40378
40379<p><i>[
40380Post Summit:
40381]</i></p>
40382
40383
40384<blockquote>
40385Recommend Tentatively Ready.
40386</blockquote>
40387
40388
40389
40390<p><b>Proposed resolution:</b></p>
40391<p>
40392Change 20.7.4 [func.ret], p1:
40393</p>
40394
40395<blockquote>
40396... The values <tt>ti</tt> are lvalues 
40397when the corresponding type <tt>Ti</tt> is a<ins>n</ins> <ins>lvalue-</ins>reference type,
40398and rvalues otherwise. 
40399</blockquote>
40400
40401
40402
40403
40404
40405<hr>
40406<h3><a name="907"></a>907. Bitset's immutable element retrieval is inconsistently defined</h3>
40407<p><b>Section:</b> 20.3.7.2 [bitset.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
40408 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2008-09-26  <b>Last modified:</b> 2009-07-18</p>
40409<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>
40410<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
40411<p><b>Discussion:</b></p>
40412<p>
40413The current standard 14882::2003(E) as well as the current draft
40414<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>
40415have in common a contradiction of the operational semantics
40416of member function test 20.3.7.2 [bitset.members]/56-58 and the immutable
40417member <tt>operator[]</tt> overload 20.3.7.2 [bitset.members]/64-66 (all references
40418are defined in terms of
40419<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>):
40420</p>
40421
40422<ol>
40423<li><pre>bool test(size_t pos) const;
40424</pre>
40425<blockquote>
40426<p>
40427<i>Requires:</i> <tt>pos</tt> is valid
40428</p>
40429<p>
40430<i>Throws:</i> <tt>out_of_range</tt> if <tt>pos</tt> does not correspond
40431to a valid bit position.
40432</p>
40433<p>
40434<i>Returns:</i> <tt>true</tt> if the bit at position <tt>pos</tt> in <tt>*this</tt>
40435has the value one.
40436</p>
40437</blockquote>
40438</li>
40439<li><pre>constexpr bool operator[](size_t pos) const;
40440</pre>
40441<blockquote>
40442<p>
40443<i>Requires:</i> <tt>pos</tt> shall be valid.
40444</p>
40445<p>
40446<i>Throws:</i> nothing.
40447</p>
40448<p>
40449<i>Returns:</i> <tt>test(pos)</tt>.
40450</p>
40451</blockquote>
40452</li>
40453</ol>
40454
40455<p>
40456Three interpretations:
40457</p>
40458
40459<ol type="A">
40460<li>
40461The <tt>operator[]</tt> overload is indeed allowed to throw an exception
40462(via <tt>test()</tt>, if <tt>pos</tt> corresponds to an invalid bit position) which does
40463not leave the call frame. In this case this function cannot be a
40464<tt>constexpr</tt> function, because <tt>test()</tt> is not, due to
404655.19 [expr.const]/2, last bullet.
40466</li>
40467<li>
40468The intend was not to throw an exception in <tt>test</tt> in case of an
40469invalid bit position. There is only little evidence for this interpretation.
40470</li>
40471<li>
40472The intend was that <tt>operator[]</tt> should not throw any exception,
40473but that <tt>test</tt> has the contract to do so, if the provided bit position
40474is invalid.
40475</li>
40476</ol>
40477
40478<p>
40479The problem became worse, because issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#720">720</a>
40480recently voted into WP argued that member <tt>test</tt> logically must be
40481a <tt>constexpr</tt> function, because it was used to define the semantics
40482of another <tt>constexpr</tt> function (the <tt>operator[]</tt> overload).
40483</p>
40484
40485<p>
40486Three alternatives are proposed, corresponding to the three bullets
40487(A), (B), and (C), the author suggests to follow proposal (C).
40488</p>
40489
40490<b>
40491Proposed alternatives:
40492</b>
40493
40494<ol type="A">
40495<li>
40496<p>
40497Remove the <tt>constexpr</tt> specifier in front of <tt>operator[]</tt> overload and
40498undo 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
40499class declaration 20.3.7 [template.bitset]/1 and in the member description
40500before 20.3.7.2 [bitset.members]/56 and before /64 to read:
40501</p>
40502<blockquote><pre><del>constexpr</del> bool test(size_t pos) const;
40503..
40504<del>constexpr</del> bool operator[](size_t pos) const;
40505</pre></blockquote>
40506
40507<p>
40508Change the throws clause of p. 65 to read:
40509</p>
40510
40511<blockquote>
40512<i>Throws:</i> <del>nothing</del>
40513<ins><tt>out_of_range</tt> if <tt>pos</tt> does not correspond to a valid bit
40514position</ins>.
40515</blockquote>
40516</li>
40517<li>
40518<p>
40519Replace the throws clause p. 57 to read:
40520</p>
40521
40522<blockquote>
40523<i>Throws:</i> <del><tt>out_of_range</tt> if <tt>pos</tt> does not correspond to a valid bit
40524position</del> <ins>nothing</ins>.
40525</blockquote>
40526</li>
40527<li>
40528<p>
40529Undo the addition of the <tt>constexpr</tt> specifier to the <tt>test</tt> member
40530function in both class declaration 20.3.7 [template.bitset]/1 and in the
40531member description before 20.3.7.2 [bitset.members]/56, assuming that <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#720">720</a>
40532was applied.
40533</p>
40534
40535<blockquote><pre><del>constexpr</del> bool test(size_t pos) const;
40536</pre></blockquote>
40537
40538<p>
40539Change the returns clause p. 66 to read:
40540</p>
40541
40542<blockquote>
40543<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>
40544has the value one, otherwise <tt>false</tt></ins>.
40545</blockquote>
40546</li>
40547</ol>
40548
40549<p><i>[
40550Post Summit:
40551]</i></p>
40552
40553
40554<blockquote>
40555<p>
40556Lawrence: proposed resolutions A, B, C are mutually exclusive.
40557</p>
40558<p>
40559Recommend Review with option C.
40560</p>
40561</blockquote>
40562
40563<p><i>[
40564Batavia (2009-05):
40565]</i></p>
40566
40567<blockquote>
40568We agree with the proposed resolution.
40569Move to Tentatively Ready.
40570</blockquote>
40571
40572
40573<p><b>Proposed resolution:</b></p>
40574
40575<ol ,="" start="3" type="A">
40576<li>
40577<p>
40578Undo the addition of the <tt>constexpr</tt> specifier to the <tt>test</tt> member
40579function in both class declaration 20.3.7 [template.bitset]/1 and in the
40580member description before 20.3.7.2 [bitset.members]/56, assuming that <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#720">720</a>
40581was applied.
40582</p>
40583
40584<blockquote><pre><del>constexpr</del> bool test(size_t pos) const;
40585</pre></blockquote>
40586
40587<p>
40588Change the returns clause p. 66 to read:
40589</p>
40590
40591<blockquote>
40592<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>
40593has the value one, otherwise <tt>false</tt></ins>.
40594</blockquote>
40595</li>
40596</ol>
40597
40598
40599
40600
40601
40602
40603<hr>
40604<h3><a name="909"></a>909. <tt>regex_token_iterator</tt> should use <tt>initializer_list</tt></h3>
40605<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>
40606 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2008-09-26  <b>Last modified:</b> 2009-07-18</p>
40607<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>
40608<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
40609<p><b>Discussion:</b></p>
40610
40611<p><b>Addresses UK 319</b></p>
40612<p>
40613Construction of a <tt>regex_token_iterator</tt> (28.12.2 [re.tokiter]/6+) usually
40614requires the provision of a sequence of integer values, which
40615can currently be done via a <tt>std::vector&lt;int&gt;</tt> or
40616a C array of <tt>int</tt>. Since the introduction of <tt>initializer_list</tt> in the
40617standard it seems much more reasonable to provide a
40618corresponding constructor that accepts an <tt>initializer_list&lt;int&gt;</tt>
40619instead. This could be done as a pure addition or one could
40620even consider replacement. The author suggests the
40621replacement strategy (A), but provides an alternative additive
40622proposal (B) as a fall-back, because of the handiness of this
40623range type:
40624</p>
40625
40626<p><i>[
40627Batavia (2009-05):
40628]</i></p>
40629
40630<blockquote>
40631We strongly recommend alternative B of the proposed resolution
40632in order that existing code not be broken.
40633With that understanding, move to Tentatively Ready.
40634</blockquote>
40635
40636<p><b>Original proposed wording:</b></p>
40637
40638<ol type="A">
40639<li><br>
40640<ol>
40641<li>
40642<p>
40643In 28.12.2 [re.tokiter]/6 and the list 28.12.2.1 [re.tokiter.cnstr]/10-11 change the
40644constructor declaration:
40645</p>
40646
40647<blockquote><pre><del>template &lt;std::size_t N&gt;</del>
40648regex_token_iterator(BidirectionalIterator a, BidirectionalIterator b,
40649                     const regex_type&amp; re,
40650                     <del>const int (&amp;submatches)[N]</del> <ins>initializer_list&lt;int&gt; submatches</ins>,
40651                     regex_constants::match_flag_type m =
40652                       regex_constants::match_default);
40653</pre></blockquote>
40654</li>
40655
40656<li>
40657<p>
40658In 28.12.2.1 [re.tokiter.cnstr]/12 change the last sentence
40659</p>
40660
40661<blockquote>
40662The third constructor initializes the member <tt>subs</tt> to hold
40663a copy of the sequence of integer values pointed to by the
40664iterator range <tt>[<del>&amp;</del>submatches<ins>.begin()</ins>,
40665<del>&amp;</del>submatches<ins>.end()</ins> <del>+ N</del>)</tt>.
40666</blockquote>
40667</li>
40668</ol>
40669</li>
40670
40671<li><br>
40672<ol>
40673<li>
40674<p>
40675In 28.12.2 [re.tokiter]/6 and the list 28.12.2.1 [re.tokiter.cnstr]/10-11 <em>insert</em> the
40676following constructor declaration between the already existing ones
40677accepting a <tt>std::vector</tt> and a C array of <tt>int</tt>, resp.:
40678</p>
40679
40680<blockquote><pre>regex_token_iterator(BidirectionalIterator a, BidirectionalIterator b,
40681                     const regex_type&amp; re,
40682                     initializer_list&lt;int&gt; submatches,
40683                     regex_constants::match_flag_type m =
40684                       regex_constants::match_default);
40685</pre></blockquote>
40686</li>
40687<li>
40688<p>
40689In 28.12.2.1 [re.tokiter.cnstr]/12 change the last sentence
40690</p>
40691
40692<blockquote>
40693The third <ins>and fourth</ins> constructor initialize<del>s</del> the member <tt>subs</tt>
40694to hold a copy of the sequence of integer values pointed to
40695by the iterator range <tt>[&amp;submatches,&amp;submatches + N)</tt>
40696<ins>and <tt>[submatches.begin(),submatches.end())</tt>, respectively</ins>.
40697</blockquote>
40698</li>
40699</ol>
40700</li>
40701
40702</ol>
40703
40704
40705
40706<p><b>Proposed resolution:</b></p>
40707
40708<ol start="2" type="A">
40709
40710<li><br>
40711<ol>
40712<li>
40713<p>
40714In 28.12.2 [re.tokiter]/6 and the list 28.12.2.1 [re.tokiter.cnstr]/10-11 <em>insert</em> the
40715following constructor declaration between the already existing ones
40716accepting a <tt>std::vector</tt> and a C array of <tt>int</tt>, resp.:
40717</p>
40718
40719<blockquote><pre>regex_token_iterator(BidirectionalIterator a, BidirectionalIterator b,
40720                     const regex_type&amp; re,
40721                     initializer_list&lt;int&gt; submatches,
40722                     regex_constants::match_flag_type m =
40723                       regex_constants::match_default);
40724</pre></blockquote>
40725</li>
40726<li>
40727<p>
40728In 28.12.2.1 [re.tokiter.cnstr]/12 change the last sentence
40729</p>
40730
40731<blockquote>
40732The third <ins>and fourth</ins> constructor initialize<del>s</del> the member <tt>subs</tt>
40733to hold a copy of the sequence of integer values pointed to
40734by the iterator range <tt>[&amp;submatches,&amp;submatches + N)</tt>
40735<ins>and <tt>[submatches.begin(),submatches.end())</tt>, respectively</ins>.
40736</blockquote>
40737</li>
40738</ol>
40739</li>
40740
40741</ol>
40742
40743
40744
40745
40746
40747
40748<hr>
40749<h3><a name="922"></a>922. [func.bind.place] Number of placeholders</h3>
40750<p><b>Section:</b> B [implimits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
40751 <b>Submitter:</b> Sohail Somani <b>Opened:</b> 2008-10-11  <b>Last modified:</b> 2009-07-18</p>
40752<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
40753<p><b>Discussion:</b></p>
40754<p><b>Addresses DE 24</b></p>
40755
40756<p>
40757With respect to the section 20.7.11.1.4 [func.bind.place]:
40758</p>
40759<p>
40760TR1 dropped some suggested implementation quantities for the number of
40761placeholders. The purpose of this defect is to put these back for C++0x.
40762</p>
40763
40764<p><i>[
40765Post Summit:
40766]</i></p>
40767
40768
40769<blockquote>
40770<p>
40771see DE 24
40772</p>
40773<p>
40774Recommend applying the proposed resolution from DE 24, with that
40775Tentatively Ready.
40776</p>
40777</blockquote>
40778
40779<b>Original proposed resolution:</b>
40780
40781<p>
40782Add 20.7.11.1.4 [func.bind.place]/2:
40783</p>
40784
40785<blockquote>
40786While the exact number of placeholders (<tt>_M</tt>) is implementation defined,
40787this number shall be at least 10.
40788</blockquote>
40789
40790
40791
40792<p><b>Proposed resolution:</b></p>
40793
40794<p>
40795Add to B [implimits]:
40796</p>
40797
40798<ul>
40799<li>
40800Number of placeholders (20.7.11.1.4 [func.bind.place]) [10].
40801</li>
40802</ul>
40803
40804
40805
40806
40807
40808
40809<hr>
40810<h3><a name="925"></a>925. <tt>shared_ptr</tt>'s explicit conversion from <tt>unique_ptr</tt></h3>
40811<p><b>Section:</b> 20.8.15.2.1 [util.smartptr.shared.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
40812 <b>Submitter:</b> Rodolfo Lima <b>Opened:</b> 2008-10-12  <b>Last modified:</b> 2009-07-18</p>
40813<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>
40814<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
40815<p><b>Discussion:</b></p>
40816<p>
40817The current working draft
40818(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdf">N2798</a>),
40819section 20.8.15.2.1 [util.smartptr.shared.const] declares
40820<tt>shared_ptr</tt>'s constructor that takes a rvalue reference to <tt>unique_ptr</tt> and
40821<tt>auto_ptr</tt> as being explicit, affecting several valid smart pointer use
40822cases that would take advantage of this conversion being implicit, for
40823example:
40824</p>
40825
40826<blockquote><pre>class A;
40827std::unique_ptr&lt;A&gt; create();
40828void process(std::shared_ptr&lt;A&gt; obj);
40829
40830int main()
40831{
40832   process(create());                  // use case #1
40833   std::unique_ptr&lt;A&gt; uobj = create();
40834   process(std::move(uobj));           // use case #2
40835   return 0;
40836}
40837</pre></blockquote>
40838
40839<p>
40840If <tt>unique_ptr</tt> to <tt>shared_ptr</tt> conversions are explicit, the above lines
40841should be written:
40842</p>
40843
40844<blockquote><pre>process(std::shared_ptr&lt;A&gt;(create()));        // use case #1
40845process(std::shared_ptr&lt;A&gt;(std::move(uobj))); // use case #2
40846</pre></blockquote>
40847
40848<p>
40849The extra cast required doesn't seems to give any benefits to the user,
40850nor protects him of any unintended conversions, this being the raison
40851d'etre of explicit constructors.
40852</p>
40853
40854<p>
40855It seems that this constructor was made explicit to mimic the conversion
40856from <tt>auto_ptr</tt> in pre-rvalue reference days, which accepts both lvalue and
40857rvalue references. Although this decision was valid back then, C++0x
40858allows the user to express in a clear and non verbose manner when he wants
40859move semantics to be employed, be it implicitly (use case 1) or explicitly
40860(use case 2).
40861</p>
40862
40863<p><i>[
40864Batavia (2009-05):
40865]</i></p>
40866
40867<blockquote>
40868<p>
40869Howard and Alisdair like the motivating use cases
40870and the proposed resolution.
40871</p>
40872<p>
40873Move to Tentatively Ready.
40874</p>
40875</blockquote>
40876
40877
40878<p><b>Proposed resolution:</b></p>
40879<p>
40880In both 20.8.15.2 [util.smartptr.shared] paragraph 1 and 
4088120.8.15.2.1 [util.smartptr.shared.const] change:
40882</p>
40883
40884<blockquote><pre>template &lt;class Y&gt; <del>explicit</del> shared_ptr(auto_ptr&lt;Y&gt; &amp;&amp;r);
40885template &lt;class Y, class D&gt; <del>explicit</del> shared_ptr(unique_ptr&lt;Y, D&gt; &amp;&amp;r);
40886</pre></blockquote>
40887
40888
40889
40890
40891
40892
40893<hr>
40894<h3><a name="931"></a>931. type trait <tt>extent&lt;T, I&gt;</tt></h3>
40895<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#WP">WP</a>
40896 <b>Submitter:</b> Yechezkel Mett <b>Opened:</b> 2008-11-04  <b>Last modified:</b> 2009-07-18</p>
40897<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>
40898<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>
40899<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
40900<p><b>Discussion:</b></p>
40901<p>
40902The draft (N2798) says in 20.6.4.3 [meta.unary.prop] Table 44: 
40903</p>
40904<blockquote>
40905<table border="1">
40906<caption>Table 44 -- Type property queries</caption>
40907<tbody><tr><th>Template</th><th>Value</th></tr>
40908<tr>
40909<td>
40910<tt>template &lt;class T, unsigned I = 0&gt; struct extent;</tt>
40911</td>
40912<td>
40913If <tt>T</tt> is not an array type (8.3.4), or if it has rank less than
40914<tt>I</tt>, or if <tt>I</tt> is 0
40915and <tt>T</tt> has type "array of unknown bound of <tt>U</tt>", then 0; otherwise, the
40916size of the <tt>I</tt>'th dimension of <tt>T</tt>
40917</td>
40918</tr>
40919</tbody></table>
40920</blockquote>
40921
40922<p>
40923Firstly it isn't clear from the wording if <tt>I</tt> is 0-based or 1-based 
40924("the <tt>I</tt>'th dimension" sort of implies 1-based). From the following 
40925example it is clear that the intent is 0-based, in which case it 
40926should say "or if it has rank less than or equal to <tt>I</tt>".
40927</p>
40928<p>
40929Sanity check:
40930</p>
40931<p>
40932The example says <tt>assert((extent&lt;int[2], 1&gt;::value) == 0);</tt>
40933</p>
40934<p>
40935Here the rank is 1 and <tt>I</tt> is 1, but the desired result is 0.
40936</p>
40937
40938<p><i>[
40939Post Summit:
40940]</i></p>
40941
40942
40943<blockquote>
40944<p>
40945Do not use "size" or "value", use "bound". Also, move the
40946cross-reference to 8.3.4 to just after "bound".
40947</p>
40948<p>
40949Recommend Tentatively Ready.
40950</p>
40951</blockquote>
40952
40953
40954
40955<p><b>Proposed resolution:</b></p>
40956<p>
40957In Table 44 of 20.6.4.3 [meta.unary.prop], third row, column "Value",
40958change the cell content:
40959</p>
40960
40961<blockquote>
40962<table border="1">
40963<caption>Table 44 -- Type property queries</caption>
40964<tbody><tr><th>Template</th><th>Value</th></tr>
40965<tr>
40966<td>
40967<tt>template &lt;class T, unsigned I = 0&gt; struct extent;</tt>
40968</td>
40969<td>
40970If <tt>T</tt> is not an array type <del>(8.3.4)</del>, or if it has rank less than
40971<ins> or equal to</ins> <tt>I</tt>, or if <tt>I</tt> is 0
40972and <tt>T</tt> has type "array of unknown bound of <tt>U</tt>", then 0; otherwise, the
40973<del>size</del> <ins>bound (8.3.4)</ins> of the <tt>I</tt>'th dimension of <tt>T</tt><ins>,
40974where indexing of <tt>I</tt> is zero-based.</ins>
40975</td>
40976</tr>
40977</tbody></table>
40978</blockquote>
40979
40980<p><i>[
40981Wording supplied by Daniel.
40982]</i></p>
40983
40984
40985
40986
40987
40988
40989
40990<hr>
40991<h3><a name="934"></a>934. <tt>duration</tt> is missing <tt>operator%</tt></h3>
40992<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#WP">WP</a>
40993 <b>Submitter:</b> Terry Golubiewski <b>Opened:</b> 2008-11-30  <b>Last modified:</b> 2009-10-26</p>
40994<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#time.duration">active issues</a> in [time.duration].</p>
40995<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.duration">issues</a> in [time.duration].</p>
40996<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
40997<p><b>Discussion:</b></p>
40998
40999<p><b>Addresses US 81</b></p>
41000
41001<p>
41002<tt>duration</tt> is missing <tt>operator%</tt>.  This operator is convenient
41003for computing where in a time frame a given <tt>duration</tt> lies.  A
41004motivating example is converting a <tt>duration</tt> into a "broken-down"
41005time duration such as hours::minutes::seconds:
41006</p>
41007
41008<blockquote><pre>class ClockTime
41009{
41010    typedef std::chrono::hours hours;
41011    typedef std::chrono::minutes minutes;
41012    typedef std::chrono::seconds seconds;
41013public:
41014    hours hours_;
41015    minutes minutes_;
41016    seconds seconds_;
41017
41018    template &lt;class Rep, class Period&gt;
41019      explicit ClockTime(const std::chrono::duration&lt;Rep, Period&gt;&amp; d)
41020        : hours_  (std::chrono::duration_cast&lt;hours&gt;  (d)),
41021          minutes_(std::chrono::duration_cast&lt;minutes&gt;(d % hours(1))),
41022          seconds_(std::chrono::duration_cast&lt;seconds&gt;(d % minutes(1)))
41023          {}
41024};
41025</pre></blockquote>
41026
41027<p><i>[
41028Summit:
41029]</i></p>
41030
41031
41032<blockquote>
41033Agree except that there is a typo in the proposed resolution. The member
41034operators should be operator%=.
41035</blockquote>
41036
41037<p><i>[
41038Batavia (2009-05):
41039]</i></p>
41040
41041<blockquote>
41042We agree with the proposed resolution.
41043Move to Tentatively Ready.
41044</blockquote>
41045
41046<p><i>[
410472009-07 Frankfurt
41048]</i></p>
41049
41050
41051<blockquote>
41052Moved from Tentatively Ready to Open only because the wording needs to be
41053improved for enable_if type constraining, possibly following Robert's
41054formula.
41055</blockquote>
41056
41057<p><i>[
410582009-07 Frankfurt:
41059]</i></p>
41060
41061
41062<blockquote>
41063<p>
41064Howard to open a separate issue (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1177">1177</a>) to handle the removal of member
41065functions from overload sets, provide wording, and possibly demonstrate
41066how this can be implemented using enable_if (see <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#947">947</a>).
41067</p>
41068<p>
41069Move to Ready.
41070</p>
41071</blockquote>
41072
41073
41074
41075<p><b>Proposed resolution:</b></p>
41076<p>
41077Add to the synopsis in 20.9 [time]:
41078</p>
41079
41080<blockquote><pre>template &lt;class Rep1, class Period, class Rep2&gt;
41081  duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt;
41082  operator%(const duration&lt;Rep1, Period&gt;&amp; d, const Rep2&amp; s);
41083template &lt;class Rep1, class Period1, class Rep2, class Period2&gt;
41084  typename common_type&lt;duration&lt;Rep1, Period1&gt;, duration&lt;Rep2, Period2&gt;&gt;::type
41085  operator%(const duration&lt;Rep1, Period1&gt;&amp; lhs, const duration&lt;Rep2, Period2&gt;&amp; rhs);
41086</pre></blockquote>
41087
41088<p>
41089Add to the synopsis of <tt>duration</tt> in 20.9.3 [time.duration]:
41090</p>
41091
41092<blockquote><pre>template &lt;class Rep, class Period = ratio&lt;1&gt;&gt;
41093class duration {
41094public:
41095  ...
41096  <ins>duration&amp; operator%=(const rep&amp; rhs);</ins>
41097  <ins>duration&amp; operator%=(const duration&amp; d);</ins>
41098  ...
41099};
41100</pre></blockquote>
41101
41102<p>
41103Add to 20.9.3.3 [time.duration.arithmetic]:
41104</p>
41105
41106<blockquote>
41107<pre>duration&amp; operator%=(const rep&amp; rhs);
41108</pre>
41109<blockquote>
41110<p>
41111<i>Effects:</i> <tt>rep_ %= rhs</tt>.
41112</p>
41113<p>
41114<i>Returns:</i> <tt>*this</tt>.
41115</p>
41116</blockquote>
41117
41118<pre>duration&amp; operator%=(const duration&amp; d);
41119</pre>
41120<blockquote>
41121<p>
41122<i>Effects:</i> <tt>rep_ %= d.count()</tt>.
41123</p>
41124<p>
41125<i>Returns:</i> <tt>*this</tt>.
41126</p>
41127</blockquote>
41128</blockquote>
41129
41130<p>
41131Add to 20.9.3.5 [time.duration.nonmember]:
41132</p>
41133
41134<blockquote>
41135
41136<pre>template &lt;class Rep1, class Period, class Rep2&gt;
41137  duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt;
41138  operator%(const duration&lt;Rep1, Period&gt;&amp; d, const Rep2&amp; s);
41139</pre>
41140<blockquote>
41141<p>
41142<i>Requires:</i> <tt>Rep2</tt> shall be implicitly convertible to <tt>CR(Rep1, Rep2)</tt> and
41143<tt>Rep2</tt> shall not be an instantiation of <tt>duration</tt>. Diagnostic required.
41144</p>
41145<p>
41146<i>Returns:</i> <tt>duration&lt;CR, Period&gt;(d) %= s</tt>.
41147</p>
41148</blockquote>
41149
41150<pre>template &lt;class Rep1, class Period1, class Rep2, class Period2&gt;
41151  typename common_type&lt;duration&lt;Rep1, Period1&gt;, duration&lt;Rep2, Period2&gt;&gt;::type
41152  operator%(const duration&lt;Rep1, Period1&gt;&amp; lhs, const duration&lt;Rep2, Period2&gt;&amp; rhs);
41153</pre>
41154<blockquote>
41155<p>
41156<i>Returns:</i> <tt>common_type&lt;duration&lt;Rep1, Period1&gt;, duration&lt;Rep2, Period2&gt;&gt;::type(lhs) %= rhs</tt>.
41157</p>
41158</blockquote>
41159
41160</blockquote>
41161
41162
41163
41164
41165
41166
41167<hr>
41168<h3><a name="938"></a>938. <tt>default_delete&lt;T[]&gt;::operator()</tt> should only accept <tt>T*</tt></h3>
41169<p><b>Section:</b> 20.8.14.1.2 [unique.ptr.dltr.dflt1] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
41170 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2008-12-07  <b>Last modified:</b> 2009-07-18</p>
41171<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
41172<p><b>Discussion:</b></p>
41173<p>
41174Consider:
41175</p>
41176
41177<blockquote><pre>derived* p = new derived[3];
41178std::default_delete&lt;base[]&gt; d;
41179d(p);  <font color="#c80000">// should fail</font>
41180</pre></blockquote>
41181
41182<p>
41183Currently the marked line is a run time failure.  We can make it a compile
41184time failure by "poisoning" <tt>op(U*)</tt>.
41185</p>
41186
41187<p><i>[
41188Post Summit:
41189]</i></p>
41190
41191
41192<blockquote>
41193Recommend Review.
41194</blockquote>
41195
41196<p><i>[
41197Batavia (2009-05):
41198]</i></p>
41199
41200<blockquote>
41201We agree with the proposed resolution.
41202Move to Tentatively Ready.
41203</blockquote>
41204
41205
41206<p><b>Proposed resolution:</b></p>
41207<p>
41208Add to 20.8.14.1.2 [unique.ptr.dltr.dflt1]:
41209</p>
41210
41211<blockquote><pre>namespace std {
41212  template &lt;class T&gt; struct default_delete&lt;T[]&gt; {
41213    void operator()(T*) const;
41214  <ins>template &lt;class U&gt; void operator()(U*) const = delete;</ins>
41215};
41216}
41217</pre></blockquote>
41218
41219
41220
41221
41222
41223<hr>
41224<h3><a name="943"></a>943. <tt>ssize_t</tt> undefined</h3>
41225<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#WP">WP</a>
41226 <b>Submitter:</b> Holger Grund <b>Opened:</b> 2008-12-19  <b>Last modified:</b> 2009-07-18</p>
41227<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
41228<p><b>Discussion:</b></p>
41229<p>
41230There is a row in "Table 122 - Atomics for standard typedef types"
41231in 29.5.1 [atomics.types.integral] with <tt>atomic_ssize_t</tt>
41232and <tt>ssize_t</tt>. Unless, I'm missing something <tt>ssize_t</tt>
41233is not defined by the standard.
41234</p>
41235
41236<p><i>[
41237Summit:
41238]</i></p>
41239
41240
41241<blockquote>
41242Move to review. Proposed resolution: Remove the typedef. Note: ssize_t
41243is a POSIX type.
41244</blockquote>
41245
41246<p><i>[
41247Batavia (2009-05):
41248]</i></p>
41249
41250<blockquote>
41251We agree with the proposed resolution.
41252Move to Tentatively Ready.
41253</blockquote>
41254
41255
41256<p><b>Proposed resolution:</b></p>
41257<p>
41258Remove the row containing <tt>ssize_t</tt> from Table 119
41259"Atomics for standard typedef types" in 29.5.2 [atomics.types.address].
41260</p>
41261
41262
41263
41264
41265
41266<hr>
41267<h3><a name="948"></a>948. <tt>ratio</tt> arithmetic tweak</h3>
41268<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#WP">WP</a>
41269 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2008-12-26  <b>Last modified:</b> 2009-07-18</p>
41270<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>
41271<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
41272<p><b>Discussion:</b></p>
41273<p>
41274<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2800.pdf">N2800</a>,
4127520.4.2 [ratio.arithmetic] lacks a paragraph from the proposal
41276<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2661.htm">N2661</a>:
41277</p>
41278
41279<blockquote>
41280<p><b>ratio arithmetic [ratio.arithmetic]</b></p>
41281
41282<p>
41283... If the implementation is unable to form the indicated <tt>ratio</tt> due to
41284overflow, a diagnostic shall be issued.
41285</p>
41286</blockquote>
41287
41288<p>
41289The lack of a diagnostic on compile-time overflow is a significant lack of
41290functionality.  This paragraph could be put back into the WP simply editorially.
41291However in forming this issue I realized that we can do better than that.  This
41292paragraph should also allow alternative formulations which go to extra lengths
41293to avoid overflow when possible.  I.e. we should not mandate overflow when the
41294implementation can avoid it.
41295</p>
41296
41297<p>
41298For example:
41299</p>
41300
41301<blockquote>
41302<pre>template &lt;class R1, class R2&gt; struct ratio_multiply {
41303  typedef <i>see below</i>} type; 
41304</pre>
41305
41306<blockquote>
41307The nested typedef type shall be a synonym for <tt>ratio&lt;T1, T2&gt;</tt> where
41308<tt>T1</tt> has the value <tt>R1::num * R2::num</tt> and <tt>T2</tt> has the
41309value <tt>R1::den * R2::den</tt>.
41310</blockquote>
41311
41312</blockquote>
41313
41314<p>
41315Consider the case where <tt>intmax_t</tt> is a 64 bit 2's complement signed integer,
41316and we have:
41317</p>
41318
41319<blockquote><pre>typedef std::ratio&lt;0x7FFFFFFFFFFFFFFF, 0x7FFFFFFFFFFFFFF0&gt; R1;
41320typedef std::ratio&lt;8, 7&gt; R2;
41321typedef std::ratio_multiply&lt;R1, R2&gt;::type RT;
41322</pre></blockquote>
41323
41324<p>
41325According to the present formulation the implementaiton will multiply
41326<tt>0x7FFFFFFFFFFFFFFF * 8</tt> which will result in an overflow and subsequently
41327require a diagnostic.
41328</p>
41329
41330<p>
41331However if the implementation is first allowed to divde <tt>0x7FFFFFFFFFFFFFFF</tt>
41332by <tt>7</tt> obtaining <tt>0x1249249249249249 / 1</tt> and divide
41333<tt>8</tt> by <tt>0x7FFFFFFFFFFFFFF0</tt> obtaining <tt>1 / 0x0FFFFFFFFFFFFFFE</tt>,
41334then the exact result can then be computed without overflow:
41335</p>
41336
41337<blockquote><pre>[0x7FFFFFFFFFFFFFFF/0x7FFFFFFFFFFFFFF0] * [8/7] = [0x1249249249249249/0x0FFFFFFFFFFFFFFE]
41338</pre></blockquote>
41339
41340<p>
41341Example implmentation which accomplishes this:
41342</p>
41343
41344<blockquote><pre>template &lt;class R1, class R2&gt;
41345struct ratio_multiply
41346{
41347private:
41348    typedef ratio&lt;R1::num, R2::den&gt; _R3;
41349    typedef ratio&lt;R2::num, R1::den&gt; _R4;
41350public:
41351    typedef ratio&lt;__ll_mul&lt;_R3::num, _R4::num&gt;::value,
41352                  __ll_mul&lt;_R3::den, _R4::den&gt;::value&gt; type;
41353};
41354</pre></blockquote>
41355
41356<p><i>[
41357Post Summit:
41358]</i></p>
41359
41360
41361<blockquote>
41362Recommend Tentatively Ready.
41363</blockquote>
41364
41365
41366
41367
41368<p><b>Proposed resolution:</b></p>
41369<p>
41370Add a paragraph prior to p1 in 20.4.2 [ratio.arithmetic]:
41371</p>
41372
41373<blockquote>
41374Implementations may use other algorithms to compute the indicated ratios to avoid overflow. 
41375If overflow occurs, a diagnostic shall be issued.
41376</blockquote>
41377
41378
41379
41380
41381
41382<hr>
41383<h3><a name="949"></a>949. <tt>owner_less</tt></h3>
41384<p><b>Section:</b> 20.8.15.3.7 [util.smartptr.ownerless] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
41385 <b>Submitter:</b> Thomas Plum <b>Opened:</b> 2008-12-30  <b>Last modified:</b> 2009-07-18</p>
41386<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
41387<p><b>Discussion:</b></p>
41388<p>
4138920.8.15.3.7 [util.smartptr.ownerless] (class template <tt>owner_less</tt>) says that 
41390<tt>operator()(x,y)</tt> shall return <tt>x.before(y)</tt>.
41391</p>
41392<p>
41393However, <tt>shared_ptr</tt> and <tt>weak_ptr</tt> have an <tt>owner_before()</tt> but not a
41394<tt>before()</tt>, and there's no base class to provide a missing <tt>before()</tt>.
41395</p>
41396<p>
41397Being that the class is named  <tt>owner_less</tt> , I'm guessing that
41398"<tt>before()</tt>" should be "<tt>owner_before()</tt>", right?
41399</p>
41400
41401<p><i>[
41402Herve adds:
41403]</i></p>
41404
41405
41406<blockquote>
41407Agreed with the typo, it should be "shall return <tt>x.owner_before(y)</tt>".
41408</blockquote>
41409
41410<p><i>[
41411Post Summit:
41412]</i></p>
41413
41414
41415<blockquote>
41416Recommend Tentatively Ready.
41417</blockquote>
41418
41419
41420
41421<p><b>Proposed resolution:</b></p>
41422<p>
41423Change 20.8.15.3.7 [util.smartptr.ownerless] p2:
41424</p>
41425
41426<blockquote>
41427-2- <tt>operator()(x,y)</tt> shall return
41428<tt>x.<ins>owner_</ins>before(y)</tt>. [<i>Note:</i> ...
41429</blockquote>
41430
41431
41432
41433
41434
41435<hr>
41436<h3><a name="965"></a>965. Various threading bugs #15</h3>
41437<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#WP">WP</a>
41438 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07  <b>Last modified:</b> 2009-07-18</p>
41439<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>
41440<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>
41441<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
41442<p><b>Discussion:</b></p>
41443<p>
4144430.5.1 [thread.condition.condvar]: the constructor for
41445<tt>condition_variable</tt> throws an exception with error code
41446<tt>device_or_resource_busy</tt> "if attempting to initialize a
41447previously-initialized but as of yet undestroyed <tt>condition_variable</tt>."
41448How can this occur?
41449</p>
41450
41451<p><i>[
41452Summit:
41453]</i></p>
41454
41455<blockquote>
41456<p>
41457Move to review. Proposed resolution: strike the <tt>device_or_resource_busy</tt>
41458error condition from the constructor of <tt>condition_variable</tt>.
41459</p>
41460<ul>
41461<li>
41462This is a POSIX error that cannot occur in this interface because the
41463C++ interface does not separate declaration from initialization.
41464</li>
41465</ul>
41466</blockquote>
41467
41468<p><i>[
41469Batavia (2009-05):
41470]</i></p>
41471
41472<blockquote>
41473We agree with the proposed resolution.
41474Move to Tentatively Ready.
41475</blockquote>
41476
41477
41478<p><b>Proposed resolution:</b></p>
41479<p>
41480Change 30.5.1 [thread.condition.condvar] p3:
41481</p>
41482
41483<blockquote>
41484<ul>
41485<li>...</li>
41486<li>
41487<del><tt>device_or_resource_busy</tt> -- if attempting to initialize a
41488previously-initialized but as of yet undestroyed
41489<tt>condition_variable</tt>.</del>
41490</li>
41491</ul>
41492</blockquote>
41493
41494
41495
41496
41497
41498<hr>
41499<h3><a name="970"></a>970. addressof overload unneeded</h3>
41500<p><b>Section:</b> X [object.addressof] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">Pending WP</a>
41501 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-01-16  <b>Last modified:</b> 2009-09-25</p>
41502<p><b>Discussion:</b></p>
41503<p>
41504X [object.addressof] specifies:
41505</p>
41506
41507<blockquote><pre>template &lt;ObjectType T&gt; T* addressof(T&amp; r);
41508template &lt;ObjectType T&gt; T* addressof(T&amp;&amp; r);
41509</pre></blockquote>
41510
41511<p>
41512The two signatures are ambiguous when the argument is an lvalue.  The
41513second signature seems not useful:  what does it mean to take the
41514address of an rvalue?
41515</p>
41516
41517<p><i>[
41518Post Summit:
41519]</i></p>
41520
41521
41522<blockquote>
41523Recommend Review.
41524</blockquote>
41525
41526<p><i>[
41527Batavia (2009-05):
41528]</i></p>
41529
41530<blockquote>
41531We agree with the proposed resolution.
41532Move to Tentatively Ready.
41533</blockquote>
41534
41535
41536<p><b>Proposed resolution:</b></p>
41537<p>
41538Change X [object.addressof]:
41539</p>
41540
41541<blockquote><pre>template &lt;ObjectType T&gt; T* addressof(T&amp; r);
41542<del>template &lt;ObjectType T&gt; T* addressof(T&amp;&amp; r);</del>
41543</pre></blockquote>
41544
41545
41546
41547
41548
41549
41550<hr>
41551<h3><a name="975"></a>975. <tt>is_convertible</tt> cannot be instantiated for  non-convertible types</h3>
41552<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#WP">WP</a>
41553 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2009-01-25  <b>Last modified:</b> 2009-07-18</p>
41554<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>
41555<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
41556<p><b>Discussion:</b></p>
41557
41558<b>Addresses UK 206</b>
41559
41560<p>
41561Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1114">1114</a>.
41562</p>
41563
41564<p>
41565The current specification of <tt>std::is_convertible</tt> (reference is draft
41566<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdf">N2798</a>)
41567is basically defined by 20.6.5 [meta.rel]/4:
41568</p>
41569
41570<blockquote>
41571<p>
41572In order to instantiate the template <tt>is_convertible&lt;From,
41573To&gt;</tt>, the following code shall be well formed:
41574</p>
41575
41576<blockquote><pre>template &lt;class T&gt;
41577  typename add_rvalue_reference&lt;T&gt;::type create();
41578
41579To test() {
41580  return create&lt;From&gt;();
41581}
41582</pre></blockquote>
41583
41584<p>
41585[<i>Note:</i> This requirement gives well defined results for reference
41586types, void types, array types, and function types. --<i>end note</i>]
41587</p>
41588</blockquote>
41589
41590<p>
41591The first sentence can be interpreted, that e.g. the expression
41592</p>
41593
41594<blockquote><pre>std::is_convertible&lt;double, int*&gt;::value
41595</pre></blockquote>
41596
41597<p>
41598is ill-formed because <tt>std::is_convertible&lt;double, int*&gt;</tt> could not be
41599instantiated, or in more general terms: The wording requires that
41600<tt>std::is_convertible&lt;X, Y&gt;</tt> cannot be instantiated for otherwise valid
41601argument types <tt>X</tt> and <tt>Y</tt> if <tt>X</tt> is not convertible to <tt>Y</tt>.
41602</p>
41603
41604<p>
41605This semantic is both unpractical and in contradiction to what the last type
41606traits paper
41607<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2255.html">N2255</a>
41608proposed:
41609</p>
41610
41611<blockquote>
41612<p>
41613If the following <tt>test</tt> function is well formed code <tt>b</tt>
41614is <tt>true</tt>, else it is <tt>false</tt>.
41615</p>
41616
41617<blockquote><pre>template &lt;class T&gt;
41618  typename add_rvalue_reference&lt;T&gt;::type create();
41619
41620To test() {
41621  return create&lt;From&gt;();
41622}
41623</pre></blockquote>
41624
41625<p>
41626[<i>Note:</i> This definition gives well defined results for <tt>reference</tt>
41627types, <tt>void</tt> types, array types, and function types. --<i>end note</i>]
41628</p>
41629</blockquote>
41630
41631<p><i>[
41632Post Summit:
41633]</i></p>
41634
41635
41636<blockquote>
41637<p>
41638Jens: Checking that code is well-formed and then returning true/false
41639sounds like speculative compilation. John Spicer would really dislike
41640this. Please find another wording suggesting speculative compilation.
41641</p>
41642<p>
41643Recommend Open.
41644</p>
41645</blockquote>
41646
41647<p><i>[
41648Post Summit, Howard adds:
41649]</i></p>
41650
41651
41652<blockquote>
41653<p>
41654John finds the following wording clearer:
41655</p>
41656<blockquote>
41657
41658<table border="1">
41659<tbody><tr>
41660<th>Template</th><th>Condition</th><th>Comments</th>
41661</tr>
41662<tr>
41663<td><tt>template &lt;class From, class To&gt;<br>struct is_convertible;</tt></td>
41664<td><i>see below</i></td>
41665<td><tt>From</tt> and <tt>To</tt> shall be complete types, arrays of unknown bound,
41666or (possibly cv-qualified) <tt>void</tt> types.</td>
41667</tr>
41668</tbody></table>
41669
41670<p>
41671Given the following function prototype:
41672</p>
41673
41674<blockquote><pre>template &lt;class T&gt;
41675  typename add_rvalue_reference&lt;T&gt;::type create();
41676</pre></blockquote>
41677
41678<p>
41679<tt>is_convertible&lt;From, To&gt;::value</tt> shall be <tt>true</tt> if the
41680return expression in the following code would be well-formed, including
41681any implicit conversions to the return type of the function, else
41682<tt>is_convertible&lt;From, To&gt;::value</tt> shall be <tt>false</tt>.
41683</p>
41684
41685<blockquote><pre>To test() {
41686  return create&lt;From&gt;();
41687}
41688</pre></blockquote>
41689
41690</blockquote>
41691
41692</blockquote>
41693
41694<b>Original proposed wording:</b>
41695
41696<p>
41697In 20.6.5 [meta.rel]/4 change:
41698</p>
41699
41700<blockquote>
41701<del>In order to instantiate the template <tt>is_convertible&lt;From, To&gt;</tt>, the
41702following code shall be well formed</del> <ins>If the following code
41703is well formed <tt>is_convertible&lt;From, To&gt;::value</tt> is <tt>true</tt>, otherwise
41704<tt>false</tt></ins>:[..]
41705</blockquote>
41706
41707<p><b>Revision 2</b></p>
41708
41709<blockquote>
41710
41711<p>
41712In 20.6.5 [meta.rel] change:
41713</p>
41714
41715<blockquote>
41716
41717<table border="1">
41718<tbody><tr>
41719<th>Template</th><th>Condition</th><th>Comments</th>
41720</tr>
41721<tr>
41722</tr><tr><td>...</td><td>...</td><td>...</td></tr>
41723<tr><td><tt>template &lt;class From, class To&gt;<br>struct is_convertible;</tt></td>
41724<td>
41725<del>The code set out below shall be well formed.</del>
41726<ins><i>see below</i></ins></td>
41727<td><tt>From</tt> and <tt>To</tt> shall be complete types, arrays of unknown bound,
41728or (possibly cv-qualified) <tt>void</tt> types.</td>
41729</tr>
41730</tbody></table>
41731
41732<p>
41733-4- <del>In order to instantiate the template <tt>is_convertible&lt;From, To&gt;</tt>, the
41734following code shall be well formed:</del>
41735<ins>Given the following function prototype:</ins>
41736</p>
41737
41738<blockquote><pre>template &lt;class T&gt; 
41739  typename add_rvalue_reference&lt;T&gt;::type create();
41740</pre></blockquote>
41741
41742<p>
41743<ins><tt>is_convertible&lt;From, To&gt;::value</tt> inherits either directly or
41744indirectly from <tt>true_type</tt> if the
41745return expression in the following code would be well-formed, including
41746any implicit conversions to the return type of the function, else
41747<tt>is_convertible&lt;From, To&gt;::value</tt> inherits either directly or
41748indirectly from <tt>false_type</tt>.</ins>
41749</p>
41750
41751<blockquote><pre>To test() { 
41752  return create&lt;From&gt;(); 
41753}
41754</pre></blockquote>
41755
41756<p>
41757[<i>Note:</i> This requirement gives well defined results for reference types,
41758void types, array types, and function types. <i>-- end note</i>]
41759</p>
41760
41761</blockquote>
41762</blockquote>
41763
41764<p><i>[
41765Batavia (2009-05):
41766]</i></p>
41767
41768<blockquote>
41769We agree with the proposed resolution.
41770Move to Tentatively Ready.
41771</blockquote>
41772
41773
41774<p><b>Proposed resolution:</b></p>
41775
41776<p>
41777In 20.6.5 [meta.rel] change:
41778</p>
41779
41780<blockquote>
41781
41782<table border="1">
41783<tbody><tr>
41784<th>Template</th><th>Condition</th><th>Comments</th>
41785</tr>
41786<tr>
41787</tr><tr><td>...</td><td>...</td><td>...</td></tr>
41788<tr><td><tt>template &lt;class From, class To&gt;<br>struct is_convertible;</tt></td>
41789<td>
41790<del>The code set out below shall be well formed.</del>
41791<ins><i>see below</i></ins></td>
41792<td><tt>From</tt> and <tt>To</tt> shall be complete types, arrays of unknown bound,
41793or (possibly cv-qualified) <tt>void</tt> types.</td>
41794</tr>
41795</tbody></table>
41796
41797<p>
41798-4- <del>In order to instantiate the template <tt>is_convertible&lt;From, To&gt;</tt>, the
41799following code shall be well formed:</del>
41800<ins>Given the following function prototype:</ins>
41801</p>
41802
41803<blockquote><pre>template &lt;class T&gt; 
41804  typename add_rvalue_reference&lt;T&gt;::type create();
41805</pre></blockquote>
41806
41807<p>
41808<ins>the predicate condition for a template specialization
41809<tt>is_convertible&lt;From, To&gt;</tt> shall be satisfied, if and only
41810if the return expression in the following code would be well-formed,
41811including any implicit conversions to the return type of the
41812function.</ins>
41813</p>
41814
41815<blockquote><pre>To test() { 
41816  return create&lt;From&gt;(); 
41817}
41818</pre></blockquote>
41819
41820<p>
41821[<i>Note:</i> This requirement gives well defined results for reference types,
41822void types, array types, and function types. <i>&#8212; end note</i>]
41823</p>
41824
41825</blockquote>
41826
41827
41828
41829
41830
41831<hr>
41832<h3><a name="981"></a>981. Unordered container requirements should add  <tt>initializer_list</tt> support</h3>
41833<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#WP">WP</a>
41834 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2009-02-08  <b>Last modified:</b> 2009-07-18</p>
41835<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>
41836<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>
41837<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
41838<p><b>Discussion:</b></p>
41839<p>
41840Refering to
41841<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2800.pdf">N2800</a>
41842all container requirements tables (including those for
41843associative containers) provide useful member function overloads
41844accepting <tt>std::initializer_list</tt> as argument, the only exception is
41845Table 87. There seems to be no reason for not providing them, because 23.5 [unord]
41846is already <tt>initializer_list</tt>-aware. For the sake of 
41847library interface consistency and user-expectations corresponding 
41848overloads should be added to the table requirements of unordered 
41849containers as well.
41850</p>
41851
41852<p><i>[
41853Batavia (2009-05):
41854]</i></p>
41855
41856<blockquote>
41857<p>
41858We agree with the proposed resolution.
41859</p>
41860<p>
41861Move to Tentatively Ready.
41862</p>
41863</blockquote>
41864
41865
41866<p><b>Proposed resolution:</b></p>
41867
41868<p>
41869In 23.2.5 [unord.req]/9 insert:
41870</p>
41871
41872<blockquote>
41873... <tt>[q1, q2)</tt> is a valid range in <tt>a</tt>, <ins><tt>il</tt>
41874designates an object of type <tt>initializer_list&lt;value_type&gt;</tt>, </ins><tt>t</tt> is a value of type
41875<tt>X::value_type</tt>, ...
41876</blockquote>
41877
41878<p>
41879In 23.2.5 [unord.req], Table 87 insert:
41880</p>
41881
41882<blockquote>
41883<table border="1">
41884<caption>Table 87 - Unordered associative container requirements (in addition to container)</caption>
41885<tbody><tr>
41886<th>Expression</th> <th>Return type</th> <th>Assertion/note<br>pre-/post-condition</th> <th>Complexity</th>
41887</tr>
41888<tr>
41889<td><tt>X(i, j)<br>X a(i, j)</tt></td> <td><tt>X</tt></td> <td>...</td> <td>...</td>
41890</tr>
41891<tr>
41892<td><ins><tt>X(il)</tt></ins></td> <td><ins><tt>X</tt></ins></td> 
41893<td><ins>Same as <tt>X(il.begin(), il.end())</tt>.</ins></td> 
41894<td><ins>Same as <tt>X(il.begin(), il.end())</tt>.</ins></td>
41895</tr>
41896<tr>
41897<td>...</td> <td>...</td> <td>...</td> <td>...</td>
41898</tr>
41899<tr>
41900<td><tt>a = b</tt></td> <td><tt>X</tt></td> <td>...</td> <td>...</td>
41901</tr>
41902<tr>
41903<td><ins><tt>a = il</tt></ins></td> <td><ins><tt>X&amp;</tt></ins></td> 
41904<td><ins><tt>a = X(il); return *this;</tt></ins></td> 
41905<td><ins>Same as <tt>a = X(il)</tt>.</ins></td>
41906</tr>
41907<tr>
41908<td>...</td> <td>...</td> <td>...</td> <td>...</td>
41909</tr>
41910<tr>
41911<td><tt>a.insert(i, j)</tt></td> <td><tt>void</tt></td> <td>...</td> <td>...</td>
41912</tr>
41913<tr>
41914<td><ins><tt>a.insert(il)</tt></ins></td> <td><ins><tt>void</tt></ins></td> 
41915<td><ins>Same as <tt>a.insert(il.begin(), il.end())</tt>.</ins></td> 
41916<td><ins>Same as <tt>a.insert(il.begin(), il.end())</tt>.</ins></td>
41917</tr>
41918</tbody></table>
41919</blockquote>
41920
41921
41922
41923
41924
41925
41926<hr>
41927<h3><a name="982"></a>982. Wrong complexity for initializer_list assignment in  Table 85</h3>
41928<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#WP">WP</a>
41929 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2009-02-08  <b>Last modified:</b> 2009-07-18</p>
41930<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>
41931<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>
41932<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
41933<p><b>Discussion:</b></p>
41934<p>
41935According to
41936<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2800.pdf">N2800</a>,
41937the associative container requirements table 85 says
41938    that assigning an <tt>initializer_list</tt> to such a container is of
41939    constant complexity, which is obviously wrong.
41940</p>
41941
41942<p><i>[
41943Batavia (2009-05):
41944]</i></p>
41945
41946<blockquote>
41947<p>
41948We agree with the proposed resolution.
41949</p>
41950<p>
41951Move to Tentatively Ready.
41952</p>
41953</blockquote>
41954
41955
41956<p><b>Proposed resolution:</b></p>
41957
41958<p>
41959In 23.2.4 [associative.reqmts], Table 85 change:
41960</p>
41961
41962<blockquote>
41963<table border="1">
41964<caption>Table 85 - Associative container requirements (in addition to container)</caption>
41965<tbody><tr>
41966<th>Expression</th> <th>Return type</th> <th>Assertion/note<br>pre-/post-condition</th> <th>Complexity</th>
41967</tr>
41968<tr>
41969<td><tt>a = il</tt></td> <td><tt>X&amp;</tt></td> <td><tt>a = X(il);<br>return *this;</tt></td> 
41970<td><del>constant</del><ins>Same as <tt>a = X(il)</tt>.</ins></td>
41971</tr>
41972</tbody></table>
41973</blockquote>
41974
41975
41976
41977
41978
41979
41980<hr>
41981<h3><a name="984"></a>984. Does <tt>&lt;cinttypes&gt;</tt> have macro guards?</h3>
41982<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#WP">WP</a>
41983 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-02-12  <b>Last modified:</b> 2009-07-18</p>
41984<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
41985<p><b>Discussion:</b></p>
41986<p>
41987The C standard says about <tt>&lt;inttypes.h&gt;</tt>:
41988</p>
41989
41990<blockquote>
41991C++ implementations should define these macros only when <tt>__STDC_FORMAT_MACROS</tt>is defined 
41992before <tt>&lt;inttypes.h&gt;</tt> is included.
41993</blockquote>
41994
41995<p>
41996The C standard has a similar note about <tt>&lt;stdint.h&gt;</tt>.  For <tt>&lt;cstdint&gt;</tt>
41997we adopted a "thanks but no thanks" policy and documented that fact in
4199818.4.1 [cstdint.syn]:
41999</p>
42000
42001<blockquote>
42002... [<i>Note:</i> The macros defined by <tt>&lt;stdint&gt;</tt> are
42003provided unconditionally. In particular, the symbols
42004<tt>__STDC_LIMIT_MACROS</tt> and <tt>__STDC_CONSTANT_MACROS</tt>
42005(mentioned in C99 footnotes 219, 220, and 222) play no role in C++.
42006<i>-- end note</i>]
42007</blockquote>
42008
42009<p>
42010I recommend we put a similar note in 27.9.2 [c.files] regarding <tt>&lt;cinttypes&gt;</tt>.
42011</p>
42012
42013<p><i>[
42014Batavia (2009-05):
42015]</i></p>
42016
42017<blockquote>
42018We agree with the proposed resolution.
42019Move to Tentatively Ready.
42020</blockquote>
42021
42022
42023<p><b>Proposed resolution:</b></p>
42024<p>
42025Add to 27.9.2 [c.files]:
42026</p>
42027
42028<blockquote>
42029Table 112 describes header <tt>&lt;cinttypes&gt;</tt>.
42030<ins>
42031[<i>Note:</i> The macros defined by <tt>&lt;cintypes&gt;</tt> are
42032provided unconditionally. In particular, the symbol
42033<tt>__STDC_FORMAT_MACROS</tt>
42034(mentioned in C99 footnote 182) plays no role in C++.
42035<i>-- end note</i>]
42036</ins>
42037</blockquote>
42038
42039
42040
42041
42042
42043<hr>
42044<h3><a name="986"></a>986. Generic <tt>try_lock</tt> contradiction</h3>
42045<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#WP">WP</a>
42046 <b>Submitter:</b> Chris Fairles <b>Opened:</b> 2009-02-14  <b>Last modified:</b> 2009-07-18</p>
42047<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
42048<p><b>Discussion:</b></p>
42049<p>
42050In 30.4.4 [thread.lock.algorithm], the generic <tt>try_lock</tt> effects (p2) say that a failed
42051<tt>try_lock</tt> is when it either returns <tt>false</tt> or throws an exception. In
42052the event a call to <tt>try_lock</tt> does fail, by either returning <tt>false</tt> or
42053throwing an exception, it states that <tt>unlock</tt> shall be called for all
42054prior arguments. Then the returns clause (p3) goes on to state
42055in a note that after returning, either all locks are locked or none
42056will be. So what happens if multiple locks fail on <tt>try_lock</tt>?
42057</p>
42058
42059<p>
42060Example:
42061</p>
42062
42063<blockquote><pre>#include &lt;mutex&gt;
42064
42065int main() {
42066 std::mutex m0, m1, m2;
42067 std::unique_lock&lt;std::mutex&gt; l0(m0, std::defer_lock);
42068 std::unique_lock&lt;std::mutex&gt; l1(m1); //throws on try_lock
42069 std::unique_lock&lt;std::mutex&gt; l2(m2); //throws on try_lock
42070
42071 int result = std::try_lock(l0, l1, l2);
42072
42073 assert( !l0.owns_lock() );
42074 assert( l1.owns_lock() ); //??
42075 assert( l2.owns_lock() ); //??
42076}
42077</pre></blockquote>
42078
42079<p>
42080The first lock's <tt>try_lock</tt> succeeded but, being a prior argument to a
42081lock whose <tt>try_lock</tt> failed, it gets unlocked as per the effects clause
42082of 30.4.4 [thread.lock.algorithm]. However, 2 locks remain locked in this case but the return
42083clause states that either all arguments shall be locked or none will
42084be. This seems to be a contradiction unless the intent is for
42085implementations to make an effort to unlock not only prior arguments,
42086but the one that failed and those that come after as well. Shouldn't
42087the note only apply to the arguments that were successfully locked?
42088</p>
42089
42090<p>
42091Further discussion and possible resolutions in c++std-lib-23049.
42092</p>
42093
42094<p><i>[
42095Summit:
42096]</i></p>
42097
42098<blockquote>
42099Move to review. Agree with proposed resolution.
42100</blockquote>
42101
42102<p><i>[
42103Batavia (2009-05):
42104]</i></p>
42105
42106<blockquote>
42107We agree with the proposed resolution.
42108Move to Tentatively Ready.
42109</blockquote>
42110
42111
42112<p><b>Proposed resolution:</b></p>
42113
42114<p>
42115Change 30.4.4 [thread.lock.algorithm], p2:
42116</p>
42117
42118<blockquote>
42119-2- <i>Effects:</i> Calls <tt>try_lock()</tt> for each argument in order
42120beginning with the first until all arguments have been processed or a
42121call to <tt>try_lock()</tt> fails, either by returning <tt>false</tt> or by throwing an
42122exception. If a call to <tt>try_lock()</tt> fails, <tt>unlock()</tt> shall be called for
42123all prior arguments<ins> and there shall be no further calls to <tt>try_lock()</tt></ins>.
42124</blockquote>
42125
42126<p>
42127Delete the note from 30.4.4 [thread.lock.algorithm], p3
42128</p>
42129
42130<blockquote>
42131-3- <i>Returns:</i> -1 if all calls to <tt>try_lock()</tt> returned <tt>true</tt>,
42132otherwise a 0-based index value that indicates 
42133the argument for which <tt>try_lock()</tt> returned <tt>false</tt>. <del>[<i>Note:</i>
42134On return, either all arguments will be 
42135locked or none will be locked. -- <i>end note</i>]</del>
42136</blockquote>
42137
42138
42139
42140
42141
42142<hr>
42143<h3><a name="990"></a>990. <tt>monotonic_clock::is_monotonic</tt> must be <tt>true</tt></h3>
42144<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#WP">WP</a>
42145 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-09  <b>Last modified:</b> 2009-07-18</p>
42146<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
42147<p><b>Discussion:</b></p>
42148<p>
42149There is some confusion over what the value of <tt>monotonic_clock::is_monotonic</tt>
42150when <tt>monotonic_clock</tt> is a  synonym for <tt>system_clock</tt>.  The
42151intent is that if <tt>monotonic_clock</tt> exists, then <tt>monotonic_clock::is_monotonic</tt>
42152is <tt>true</tt>.
42153</p>
42154
42155<p><i>[
42156Batavia (2009-05):
42157]</i></p>
42158
42159<blockquote>
42160<p>
42161We agree with the proposed resolution.
42162</p>
42163<p>
42164Move to Tentatively Ready.
42165</p>
42166</blockquote>
42167
42168
42169<p><b>Proposed resolution:</b></p>
42170<p>
42171Change 20.9.5.2 [time.clock.monotonic], p1:
42172</p>
42173
42174<blockquote>
42175-1- Objects of class <tt>monotonic_clock</tt> represent clocks for which
42176values of <tt>time_point</tt> never decrease as physical time advances.
42177<tt>monotonic_clock</tt> may be a synonym for <tt>system_clock</tt>
42178<ins>if and only if <tt>system_clock::is_monotonic</tt> is
42179<tt>true</tt></ins>.
42180</blockquote>
42181
42182
42183
42184
42185
42186<hr>
42187<h3><a name="991"></a>991. Response to JP 50</h3>
42188<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#WP">WP</a>
42189 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2009-03-03  <b>Last modified:</b> 2009-07-18</p>
42190<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>
42191<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
42192<p><b>Discussion:</b></p>
42193<p>
42194Add custom allocator parameter to <tt>wstring_convert</tt>, since we cannot
42195allocate memory for strings from a custom allocator.
42196</p>
42197
42198<p><i>[
42199Batavia (2009-05):
42200]</i></p>
42201
42202<blockquote>
42203We agree with the proposed resolution.
42204Move to Tentatively Ready.
42205</blockquote>
42206
42207
42208<p><b>Proposed resolution:</b></p>
42209<p>
42210Change 22.3.3.2.2 [conversions.string]:
42211</p>
42212
42213<blockquote><pre>template&lt;class Codecvt, class Elem = wchar_t<ins>,
42214         class Wide_alloc = std::allocator&lt;Elem&gt;,
42215         class Byte_alloc = std::allocator&lt;char&gt; </ins>&gt; class wstring_convert {
42216  public:
42217    typedef std::basic_string&lt;char<ins>, char_traits&lt;char&gt;, Byte_alloc</ins>&gt; byte_string;
42218    typedef std::basic_string&lt;Elem<ins>, char_traits&lt;Elem&gt;, Wide_alloc</ins>&gt; wide_string;
42219     ...
42220</pre></blockquote>
42221
42222<p>
42223Change 22.3.3.2.2 [conversions.string], p3:
42224</p>
42225
42226<blockquote>
42227-3- The class template describes an ob ject that controls conversions
42228between wide string ob jects of class
42229<tt>std::basic_string&lt;Elem<ins>, char_traits&lt;Elem&gt;, Wide_alloc</ins>&gt;</tt>
42230and byte string objects of class
42231<tt>std::basic_string&lt;char<ins>, char_traits&lt;char&gt;, Byte_alloc</ins>&gt;</tt>
42232<del>(also known as <tt>std::string</tt>)</del>.
42233</blockquote>
42234
42235
42236
42237
42238
42239
42240<hr>
42241<h3><a name="993"></a>993. Response to UK 188</h3>
42242<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#WP">WP</a>
42243 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2009-03-03  <b>Last modified:</b> 2009-07-18</p>
42244<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>
42245<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
42246<p><b>Discussion:</b></p>
42247<p>
42248The function <tt>_Exit</tt> does not appear to be defined in this standard.
42249Should it be added to the table of functions included-by-reference to
42250the C standard?
42251</p>
42252
42253<p><i>[
422542009-05-09 Alisdair fixed some minor issues in the wording.
42255]</i></p>
42256
42257
42258<p><i>[
42259Batavia (2009-05):
42260]</i></p>
42261
42262<blockquote>
42263We agree with the proposed resolution.
42264Move to Tentatively Ready.
42265</blockquote>
42266
42267
42268<p><b>Proposed resolution:</b></p>
42269<p>
42270Add to 18.5 [support.start.term] Table 20 (Header
42271<tt>&lt;cstdlib&gt;</tt> synopsis) Functions:
42272</p>
42273
42274<blockquote><pre>_Exit
42275</pre></blockquote>
42276
42277<p>
42278Add before the description of <tt>abort(void)</tt>:
42279</p>
42280
42281<blockquote><pre>void _Exit [[noreturn]] (int status)
42282</pre>
42283
42284<blockquote>
42285<p>
42286The function <tt>_Exit(int status)</tt> has additional behavior in this
42287International Standard:
42288</p>
42289<ul>
42290<li>
42291The program is terminated without executing destructors for objects of
42292automatic, thread, or static storage duration and without calling the
42293functions passed to <tt>atexit()</tt> (3.6.3 [basic.start.term]).
42294</li>
42295</ul>
42296</blockquote>
42297</blockquote>
42298
42299
42300
42301
42302
42303
42304<hr>
42305<h3><a name="994"></a>994. Response to UK 193</h3>
42306<p><b>Section:</b> 18.6.2.3 [new.handler] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
42307 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2009-03-03  <b>Last modified:</b> 2009-07-18</p>
42308<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
42309<p><b>Discussion:</b></p>
42310<p>
42311<tt>quick_exit</tt> has been added as a new valid way to terminate a program in a
42312well defined way
42313</p>
42314
42315<p><i>[
42316Batavia (2009-05):
42317]</i></p>
42318
42319<blockquote>
42320We agree with the proposed resolution.
42321Move to Tentatively Ready.
42322</blockquote>
42323
42324
42325<p><b>Proposed resolution:</b></p>
42326<p>
42327Change 18.6.2.3 [new.handler], p2:
42328</p>
42329
42330<blockquote>
42331<p>
42332-2- <i>Required behavior:</i> ...
42333</p>
42334<ul>
42335<li>...</li>
42336<li>
42337<del>call either <tt>abort()</tt> or <tt>exit();</tt></del>
42338<ins>terminate execution of the program without returning to the caller</ins>
42339</li>
42340</ul>
42341</blockquote>
42342
42343
42344
42345
42346
42347
42348
42349<hr>
42350<h3><a name="997"></a>997. Response to UK 163</h3>
42351<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#WP">WP</a>
42352 <b>Submitter:</b> Thomas Plum <b>Opened:</b> 2009-03-03  <b>Last modified:</b> 2009-07-18</p>
42353<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>
42354<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
42355<p><b>Discussion:</b></p>
42356<p>
42357Many functions are defined as "Effects: Equivalent to a...", which seems
42358to also define the preconditions, effects, etc. But this is not made
42359clear.
42360</p>
42361
42362<p>
42363After studying the occurrences of "Effects: Equivalent to", I agree with
42364the diagnosis but disagree with the solution.  In 21.4.2 [string.cons]
42365we find
42366</p>
42367
42368<blockquote>
42369<p>
4237014 <i>Effects:</i> If <tt>InputIterator</tt> is an integral type, equivalent to
42371<tt>basic_string(static_cast&lt;size_type&gt;(begin), static_cast&lt;value_type&gt;(end), a)</tt>
42372</p>
42373<p>
4237415 Otherwise constructs a string from the values in the range <tt>[begin,
42375end)</tt>, as indicated in the Sequence Requirements table (see 23.1.3).
42376</p>
42377</blockquote>
42378
42379<p>
42380This would be devishly difficult to re-write with an explicit
42381"Equivalent to:" clause.  Instead, I propose the following, which will
42382result in much less editorial re-work.
42383</p>
42384
42385<p><i>[
423862009-05-09 Alisdair adds:
42387]</i></p>
42388
42389
42390<blockquote>
42391This issue is related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#492">492</a>.
42392</blockquote>
42393
42394<p><i>[
42395Batavia (2009-05):
42396]</i></p>
42397
42398<blockquote>
42399We agree with the proposed resolution.
42400Move to Tentatively Ready.
42401</blockquote>
42402
42403
42404<p><b>Proposed resolution:</b></p>
42405<p>
42406Add a new paragraph after 17.5.1.4 [structure.specifications], p3:
42407</p>
42408
42409<blockquote>
42410<p>
42411-3- Descriptions of function semantics contain the following elements (as appropriate):<sup>154</sup>
42412</p>
42413
42414<ul>
42415<li>
42416<i>Requires:</i> the preconditions for calling the function
42417</li>
42418<li>
42419<i>Effects:</i> the actions performed by the function
42420</li>
42421<li>
42422<i>Postconditions:</i> the observable results established by the function
42423</li>
42424<li>
42425<i>Returns:</i> a description of the value(s) returned by the function
42426</li>
42427<li>
42428<i>Throws:</i> any exceptions thrown by the function, and the conditions that would cause the exception
42429</li>
42430<li>
42431<i>Complexity:</i> the time and/or space complexity of the function
42432</li>
42433<li>
42434<i>Remarks:</i> additional semantic constraints on the function
42435</li>
42436<li>
42437<i>Error conditions:</i> the error conditions for error codes reported by the function.
42438</li>
42439<li>
42440<i>Notes:</i> non-normative comments about the function
42441</li>
42442</ul>
42443
42444<p><ins>
42445Whenever the <i>Effects</i> element specifies that the semantics of some
42446function <tt>F</tt> are <i>Equivalent to</i> some <i>code-sequence</i>, then
42447the various elements are interpreted as follows.  If <tt>F</tt>'s
42448semantics specifies a <i>Requires</i> element, then that requirement is
42449logically imposed prior to the <i>equivalent-to</i> semantics.  Then,
42450the semantics of the <i>code-sequence</i> are determined by the
42451<i>Requires</i>, <i>Effects</i>, <i>Postconditions</i>, <i>Returns</i>,
42452<i>Throws</i>, <i>Complexity</i>, <i>Remarks</i>, <i>Error
42453Conditions</i> and <i>Notes</i> specified for the (one or more) function
42454invocations contained in the <i>code-sequence</i>. The value returned from
42455<tt>F</tt> is specified by <tt>F</tt>'s <i>Returns</i> element, or
42456if <tt>F</tt> has no <i>Returns</i> element, a non-<tt>void</tt> return from <tt>F</tt> is specified 
42457by the <i>Returns</i> elements in <i>code-sequence</i>.  If
42458<tt>F</tt>'s semantics contains a <i>Throws</i> (or
42459<i>Postconditions</i>, or <i>Complexity</i>) element, then that
42460supersedes any occurrences of that element in the <i>code-sequence</i>.
42461</ins></p>
42462</blockquote>
42463
42464
42465
42466
42467
42468
42469<hr>
42470<h3><a name="998"></a>998. Smart pointer referencing its owner</h3>
42471<p><b>Section:</b> 20.8.14.2.5 [unique.ptr.single.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
42472 <b>Submitter:</b> Pavel Minaev <b>Opened:</b> 2009-02-26  <b>Last modified:</b> 2009-07-18</p>
42473<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>
42474<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
42475<p><b>Discussion:</b></p>
42476<p>
42477Consider the following (simplified) implementation of 
42478<tt>std::auto_ptr&lt;T&gt;::reset()</tt>: 
42479</p>
42480
42481<blockquote><pre>void reset(T* newptr = 0) { 
42482   if (this-&gt;ptr &amp;&amp; this-&gt;ptr != newptr) { 
42483     delete this-&gt;ptr; 
42484   } 
42485   this-&gt;ptr = newptr; 
42486} 
42487</pre></blockquote>
42488
42489<p>
42490Now consider the following code which uses the above implementation: 
42491</p>
42492
42493<blockquote><pre>struct foo { 
42494   std::auto_ptr&lt;foo&gt; ap; 
42495   foo() : ap(this) {} 
42496   void reset() { ap.reset(); } 
42497}; 
42498int main() { 
42499   (new foo)-&gt;reset(); 
42500} 
42501</pre></blockquote>
42502
42503<p>
42504With the above implementation of auto_ptr, this results in U.B. at the 
42505point of auto_ptr::reset(). If this isn't obvious yet, let me explain 
42506how this goes step by step: 
42507</p>
42508
42509<ol>
42510<li>
42511<tt>foo::reset()</tt> entered 
42512</li>
42513<li>
42514<tt>auto_ptr::reset()</tt> entered 
42515</li>
42516<li>
42517<tt>auto_ptr::reset()</tt> tries to delete <tt>foo</tt>
42518</li>
42519<li>
42520<tt>foo::~foo()</tt> entered, tries to destruct its members 
42521</li>
42522<li>
42523<tt>auto_ptr::~auto_ptr()</tt> executed - <tt>auto_ptr</tt> is no longer a valid object! 
42524</li>
42525<li>
42526<tt>foo::~foo()</tt> left 
42527</li>
42528<li>
42529<tt>auto_ptr::reset()</tt> sets its "ptr" field to 0 &lt;- U.B.! <tt>auto_ptr</tt>
42530is not a valid object here already! 
42531</li>
42532</ol>
42533
42534<p><i>[
42535Thanks to Peter Dimov who recognized the connection to <tt>unique_ptr</tt> and
42536brought this to the attention of the LWG, and helped with the solution.
42537]</i></p>
42538
42539
42540<p><i>[
42541Howard adds:
42542]</i></p>
42543
42544
42545<blockquote>
42546To fix this behavior <tt>reset</tt> must be specified such that deleting the
42547pointer is the last action to be taken within <tt>reset</tt>.
42548</blockquote>
42549
42550<p><i>[
42551Alisdair adds:
42552]</i></p>
42553
42554
42555<blockquote>
42556<p>
42557The example providing the rationale for LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#998">998</a> is poor, as it relies on
42558broken semantics of having two object believing they are unique owners of a
42559single resource.  It should not be surprising that UB results from such
42560code, and I feel no need to go out of our way to support such behaviour.
42561</p>
42562<p>
42563If an example is presented that does not imply multiple ownership of a
42564unique resource, I would be much more ready to accept the proposed
42565resolution.
42566</p>
42567</blockquote>
42568
42569<p><i>[
42570Batavia (2009-05):
42571]</i></p>
42572
42573<blockquote>
42574<p>
42575Howard summarizes:
42576</p>
42577<blockquote>
42578This issue has to do with circular ownership,
42579and affects <tt>auto_ptr</tt>, too (but we don't really care about that).
42580It is intended to spell out the order in which operations must be performed
42581so as to avoid the possibility
42582of undefined behavior in the self-referential case.
42583</blockquote>
42584<p>
42585Howard points to message c++std-lib-23175 for another example,
42586requested by Alisdair.
42587</p>
42588<p>
42589We agree with the issue and with the proposed resolution.
42590Move to Tentatively Ready.
42591</p>
42592</blockquote>
42593
42594
42595
42596<p><b>Proposed resolution:</b></p>
42597<p>
42598Change 20.8.14.2.5 [unique.ptr.single.modifiers], p5 (<i>Effects</i> clause for <tt>reset</tt>), and p6:
42599</p>
42600
42601<blockquote>
42602<p>
42603-5- <i>Effects:</i> <del>If <tt>get() == nullptr</tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>.</del>
42604<ins>Assigns <tt>p</tt> to the stored <tt>pointer</tt>, and then if the old value of the <tt>pointer</tt> is not
42605equal to <tt>nullptr</tt>, calls <tt>get_deleter()(</tt>the old value of the <tt>pointer)</tt>.
42606[<i>Note:</i> The order of these operations is significant because the call to <tt>get_deleter()</tt>
42607may destroy <tt>*this</tt>. <i>-- end note</i>]</ins>
42608</p>
42609
42610<p>
42611-6- Postconditions: <tt>get() == p</tt>.
42612<ins>[<i>Note:</i> The postcondition does not hold if the call to
42613<tt>get_deleter()</tt> destroys <tt>*this</tt> since <tt>this-&gt;get()</tt> is no longer a valid
42614expression. <i>-- end note</i>]</ins>
42615</p>
42616</blockquote>
42617
42618
42619
42620
42621
42622<hr>
42623<h3><a name="1004"></a>1004. Response to UK 179</h3>
42624<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#WP">WP</a>
42625 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11  <b>Last modified:</b> 2009-10-26</p>
42626<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>
42627<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
42628<p><b>Discussion:</b></p>
42629
42630<p><b>Addresses UK 179</b></p>
42631
42632<p>
42633According to the 4th bullet there is a problem if "if any replacement
42634function or handler function or destructor operation throws an
42635exception". There should be no problem throwing exceptions so long as
42636they are caught within the function.
42637</p>
42638
42639<p><i>[
42640Batavia (2009-05):
42641]</i></p>
42642
42643<blockquote>
42644The phrasing "throws an exception" is commonly used elsewhere
42645to mean "throws or propagates an exception."
42646Move to Open pending a possible more general resolution.
42647</blockquote>
42648
42649<p><i>[
426502009-07 Frankfurt:
42651]</i></p>
42652
42653
42654<blockquote>
42655Replace "propagates" in the proposed resolution with the phrase "exits
42656via" and move to Ready.
42657</blockquote>
42658
42659
42660
42661<p><b>Proposed resolution:</b></p>
42662<p>
42663Change the 4th bullet of 17.6.3.8 [res.on.functions], p2:
42664</p>
42665
42666<blockquote>
42667<ul>
42668<li>
42669if any replacement function or handler function or destructor operation
42670<del>throws</del> <ins>exits via</ins> an exception, unless specifically
42671allowed in the applicable <i>Required behavior:</i> paragraph.
42672</li>
42673</ul>
42674</blockquote>
42675
42676
42677
42678
42679
42680
42681<hr>
42682<h3><a name="1006"></a>1006. <tt>operator delete</tt> in garbage collected implementation</h3>
42683<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#WP">WP</a>
42684 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11  <b>Last modified:</b> 2009-07-18</p>
42685<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>
42686<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
42687<p><b>Discussion:</b></p>
42688
42689<p><b>Addresses UK 190</b></p>
42690
42691<p>
42692It is not entirely clear how the current specification acts in the
42693presence of a garbage collected implementation.
42694</p>
42695
42696<p><i>[
42697Summit:
42698]</i></p>
42699
42700 
42701<blockquote>
42702Agreed.
42703</blockquote>
42704
42705<p><i>[
427062009-05-09 Alisdair adds:
42707]</i></p>
42708
42709
42710<blockquote>
42711Proposed wording is too strict for implementations that do not support
42712garbage collection.  Updated wording supplied.
42713</blockquote>
42714
42715<p><i>[
42716Batavia (2009-05):
42717]</i></p>
42718
42719<blockquote>
42720We recommend advancing this to Tentatively Ready
42721with the understanding that it will not be moved for adoption
42722unless and until the proposed resolution to Core issue #853 is adopted.
42723</blockquote>
42724
42725
42726<p><b>Proposed resolution:</b></p>
42727
42728<p>
42729(Editorial note: This wording ties into the proposed
42730resolution for Core #853)
42731</p>
42732
42733<p>
42734Add paragraphs to 18.6.1.1 [new.delete.single]:
42735</p>
42736
42737<blockquote><pre>void operator delete(void* ptr) throw();
42738<del>void operator delete(void* ptr, const std::nothrow_t&amp;) throw();</del>
42739</pre>
42740
42741<p><i>[
42742The second signature deletion above is editorial.
42743]</i></p>
42744
42745
42746<blockquote>
42747<p><ins>
42748<i>Requires:</i> If an implementation has strict pointer safety
42749(3.7.4.3 [basic.stc.dynamic.safety]) then <tt>ptr</tt> shall
42750be a safely-derived pointer.
42751</ins></p>
42752
42753<p>-10- ...</p>
42754</blockquote>
42755
42756<pre>void operator delete(void* ptr, const std::nothrow_t&amp;) throw();
42757</pre>
42758
42759<blockquote>
42760<p><ins>
42761<i>Requires:</i> If an implementation has strict pointer safety
42762(3.7.4.3 [basic.stc.dynamic.safety]) then <tt>ptr</tt> shall
42763be a safely-derived pointer.
42764</ins></p>
42765
42766<p>-15- ...</p>
42767</blockquote>
42768
42769</blockquote>
42770
42771<p>
42772Add paragraphs to 18.6.1.2 [new.delete.array]:
42773</p>
42774
42775<blockquote><pre>void operator delete[](void* ptr) throw();
42776<del>void operator delete[](void* ptr, const std::nothrow_t&amp;) throw();</del>
42777</pre>
42778
42779<p><i>[
42780The second signature deletion above is editorial.
42781]</i></p>
42782
42783
42784<blockquote>
42785<p><ins>
42786<i>Requires:</i> If an implementation has strict pointer safety
42787(3.7.4.3 [basic.stc.dynamic.safety]) then <tt>ptr</tt> shall
42788be a safely-derived pointer.
42789</ins></p>
42790
42791<p>-9- ...</p>
42792</blockquote>
42793
42794<pre>void operator delete[](void* ptr, const std::nothrow_t&amp;) throw();
42795</pre>
42796
42797<blockquote>
42798<p><ins>
42799<i>Requires:</i> If an implementation has strict pointer safety
42800(3.7.4.3 [basic.stc.dynamic.safety]) then <tt>ptr</tt> shall
42801be a safely-derived pointer.
42802</ins></p>
42803
42804<p>-13- ...</p>
42805</blockquote>
42806
42807</blockquote>
42808
42809
42810<p>
42811Add paragraphs to 18.6.1.3 [new.delete.placement]:
42812</p>
42813
42814<blockquote><pre>void operator delete(void* ptr, void*) throw();
42815</pre>
42816
42817<blockquote>
42818<p><ins>
42819<i>Requires:</i> If an implementation has strict pointer safety
42820(3.7.4.3 [basic.stc.dynamic.safety]) then <tt>ptr</tt> shall
42821be a safely-derived pointer.
42822</ins></p>
42823
42824<p>-7- ...</p>
42825</blockquote>
42826
42827<pre>void operator delete[](void* ptr, void*) throw();
42828</pre>
42829
42830<blockquote>
42831<p><ins>
42832<i>Requires:</i> If an implementation has strict pointer safety
42833(3.7.4.3 [basic.stc.dynamic.safety]) then <tt>ptr</tt> shall
42834be a safely-derived pointer.
42835</ins></p>
42836
42837<p>-9- ...</p>
42838</blockquote>
42839
42840</blockquote>
42841
42842
42843
42844
42845
42846
42847<hr>
42848<h3><a name="1012"></a>1012. <tt>reverse_iterator</tt> default ctor should value initialize</h3>
42849<p><b>Section:</b> 24.5.1.3.1 [reverse.iter.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
42850 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11  <b>Last modified:</b> 2009-10-26</p>
42851<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
42852<p><b>Discussion:</b></p>
42853
42854<p><b>Addresses UK 277</b></p>
42855
42856<p>
42857The default constructor default-initializes current, rather than
42858value-initializes. This means that when Iterator corresponds to a
42859trivial type, the current member is left un-initialized, even when the
42860user explictly requests value intialization! At this point, it is not
42861safe to perform any operations on the reverse_iterator other than assign
42862it a new value or destroy it. Note that this does correspond to the
42863basic definition of a singular iterator.
42864</p>
42865
42866<p><i>[
42867Summit:
42868]</i></p>
42869
42870
42871<blockquote>
42872Agree with option i.
42873</blockquote>
42874
42875<p>
42876Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#408">408</a>
42877</p>
42878
42879<p><i>[
42880Batavia (2009-05):
42881]</i></p>
42882
42883<blockquote>
42884We believe this should be revisited
42885in conjunction with issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#408">408</a>,
42886which nearly duplicates this issue.
42887Move to Open.
42888</blockquote>
42889
42890<p><i>[
428912009-07 post-Frankfurt:
42892]</i></p>
42893
42894
42895<blockquote>
42896<p>
42897Change "constructed" to "initialized" in two places in the proposed resolution.
42898</p>
42899<p>
42900Move to Tentatively Ready.
42901</p>
42902</blockquote>
42903
42904<p><i>[
429052009 Santa Cruz:
42906]</i></p>
42907
42908
42909<blockquote>
42910Moved to Ready for this meeting.
42911</blockquote>
42912
42913
42914
42915<p><b>Proposed resolution:</b></p>
42916<p>
42917Change  [reverse.iter.con]:
42918</p>
42919
42920<blockquote><pre>reverse_iterator();
42921</pre>
42922<blockquote>
42923-1- <i>Effects:</i> <del>Default</del> <ins>Value</ins> initializes <tt>current</tt>. Iterator
42924operations applied to the resulting iterator have defined behavior if and
42925only if the corresponding operations are defined on a <del>default constructed</del>
42926<ins>value initialized</ins>
42927iterator of type <tt>Iterator</tt>.
42928</blockquote>
42929</blockquote>
42930
42931<p>
42932Change 24.5.3.3.1 [move.iter.op.const]:
42933</p>
42934
42935<blockquote><pre>move_iterator();
42936</pre>
42937<blockquote>
42938-1- <i>Effects:</i> Constructs a <tt>move_iterator</tt>, <del>default</del> <ins>value</ins>
42939initializing <tt>current</tt>.
42940<ins>Iterator
42941operations applied to the resulting iterator have defined behavior if and
42942only if the corresponding operations are defined on a
42943value initialized
42944iterator of type <tt>Iterator</tt>.</ins>
42945</blockquote>
42946</blockquote>
42947
42948
42949
42950
42951
42952
42953<hr>
42954<h3><a name="1014"></a>1014. Response to UK 317 and JP 74</h3>
42955<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>
42956 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11  <b>Last modified:</b> 2009-07-18</p>
42957<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>
42958<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
42959<p><b>Discussion:</b></p>
42960
42961<p><b>Addresses UK 317 and JP 74</b></p>
42962
42963<p>
42964UK 317:
42965</p>
42966
42967<blockquote>
42968<tt>basic_string</tt> has both a constructor and an assignment operator that
42969accepts an initializer list, <tt>basic_regex</tt> should have the same.
42970</blockquote>
42971
42972<p>
42973JP 74:
42974</p>
42975
42976<blockquote>
42977<tt>basic_regx &amp; operator= (initializer_list&lt;T&gt;);</tt> is not defined.
42978</blockquote>
42979
42980<p><i>[
42981Batavia (2009-05):
42982]</i></p>
42983
42984<blockquote>
42985UK 317 asks for both assignment and constructor,
42986but the requested constructor is already present in the current Working Paper.
42987We agree with the proposed resolution.
42988Move to Tentatively Ready.
42989</blockquote>
42990
42991
42992<p><b>Proposed resolution:</b></p>
42993<p>
42994Change 28.8 [re.regex]:
42995</p>
42996
42997<blockquote><pre>template &lt;class charT,
42998          class traits = regex_traits&lt;charT&gt; &gt;
42999class basic_regex {
43000  ...
43001  basic_regex&amp; operator=(const charT* ptr);
43002  <ins>basic_regex&amp; operator=(initializer_list&lt;charT&gt; il);</ins>
43003  template &lt;class ST, class SA&gt;
43004    basic_regex&amp; operator=(const basic_string&lt;charT, ST, SA&gt;&amp; p);
43005  ...
43006};
43007</pre></blockquote>
43008
43009<p>
43010Add in  28.8.2 [re.regex.construct]:
43011</p>
43012
43013<blockquote>
43014<blockquote>
43015-20- ...
43016</blockquote>
43017<pre>basic_regex&amp; operator=(initializer_list&lt;charT&gt; il);
43018</pre>
43019<blockquote>
43020-21- <i>Effects:</i> returns <tt>assign(il.begin(), il.end());</tt>
43021</blockquote>
43022</blockquote>
43023
43024
43025
43026
43027
43028
43029<hr>
43030<h3><a name="1019"></a>1019. Response to UK 205</h3>
43031<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#WP">WP</a>
43032 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11  <b>Last modified:</b> 2009-10-26</p>
43033<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>
43034<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
43035<p><b>Discussion:</b></p>
43036
43037<p><b>Addresses UK 205</b></p>
43038
43039<p>
43040<tt>integral_constant</tt> objects should be usable in integral-constant-expressions.
43041The addition to the language of literal types and the enhanced rules for
43042constant expressions make this possible.
43043</p>
43044
43045<p><i>[
43046Batavia (2009-05):
43047]</i></p>
43048
43049<blockquote>
43050We agree that the <tt>static</tt> data member
43051ought be declared <tt>constexpr</tt>,
43052but do not see a need for the proposed <tt>operator value_type()</tt>.
43053(A use case would be helpful.)
43054Move to Open.
43055</blockquote>
43056
43057<p><i>[
430582009-05-23 Alisdair adds:
43059]</i></p>
43060
43061
43062<blockquote>
43063<p>
43064The motivating case in my mind is that we can then use
43065<tt>true_type</tt> and <tt>false_type</tt> as integral Boolean expressions, for example inside
43066a <tt>static_assert</tt> declaration.  In that sense it is purely a matter of style.
43067</p>
43068<p>
43069Note that Boost has applied the non-explicit conversion operator for many
43070years as it has valuable properties for extension into other metaprogramming
43071libraries, such as MPL.  If additional rationale is desired I will poll the
43072Boost lists for why this extension was originally applied.  I would argue
43073that explicit conversion is more appropriate for 0x though.
43074</p>
43075</blockquote>
43076
43077<p><i>[
430782009-07-04 Howard adds:
43079]</i></p>
43080
43081
43082<blockquote>
43083<p>
43084Here's a use case which demonstrates the syntactic niceness which Alisdair describes:
43085</p>
43086
43087<blockquote><pre>#define requires(...) class = typename std::enable_if&lt;(__VA_ARGS__)&gt;::type
43088
43089template &lt;class T, class U,
43090    requires(!is_lvalue_reference&lt;T&gt;() ||
43091              is_lvalue_reference&lt;T&gt;() &amp;&amp; is_lvalue_reference&lt;U&gt;()),
43092    requires(is_same&lt;typename base_type&lt;T&gt;::type,
43093                     typename base_type&lt;U&gt;::type&gt;)&gt;
43094inline
43095T&amp;&amp;
43096forward(U&amp;&amp; t)
43097{
43098    return static_cast&lt;T&amp;&amp;&gt;(t);
43099}
43100</pre></blockquote>
43101</blockquote>
43102
43103<p><i>[
431042009-07 post-Frankfurt:
43105]</i></p>
43106
43107
43108<blockquote>
43109Move to Tentatively Ready.
43110</blockquote>
43111
43112<p><i>[
431132009 Santa Cruz:
43114]</i></p>
43115
43116
43117<blockquote>
43118Moved to Ready for this meeting.
43119</blockquote>
43120
43121
43122
43123<p><b>Proposed resolution:</b></p>
43124<p>
43125Add to the <tt>integral_constant</tt> struct definition in 20.6.3 [meta.help]:
43126</p>
43127
43128<blockquote><pre>template &lt;class T, T v&gt;
43129struct integral_constant {
43130  static const<ins>expr</ins> T value = v;
43131  typedef T value_type;
43132  typedef integral_constant&lt;T,v&gt; type;
43133  <ins>constexpr operator value_type() { return value; }</ins>
43134};
43135</pre></blockquote>
43136
43137
43138
43139
43140
43141<hr>
43142<h3><a name="1021"></a>1021. Response to UK 211</h3>
43143<p><b>Section:</b> 20.8.14.2.3 [unique.ptr.single.asgn] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
43144 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11  <b>Last modified:</b> 2009-07-18</p>
43145<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
43146<p><b>Discussion:</b></p>
43147
43148<p><b>Addresses UK 211</b></p>
43149
43150<p>
43151The <tt>nullptr_t</tt> type was introduced to resolve the null pointer literal
43152problem. It should be used for the assignemnt operator, as with the
43153constructor and elsewhere through the library.
43154</p>
43155
43156<p><i>[
43157Batavia (2009-05):
43158]</i></p>
43159
43160<blockquote>
43161We agree with the proposed resolution.
43162Move to Tentatively Ready.
43163</blockquote>
43164
43165
43166<p><b>Proposed resolution:</b></p>
43167<p>
43168Change the synopsis in 20.8.14.2 [unique.ptr.single]:
43169</p>
43170
43171<blockquote><pre>unique_ptr&amp; operator=(<del><i>unspecified-pointer-type</i></del> <ins>nullptr_t</ins>);
43172</pre></blockquote>
43173
43174<p>
43175Change 20.8.14.2.3 [unique.ptr.single.asgn]:
43176</p>
43177
43178<blockquote><pre>unique_ptr&amp; operator=(<del><i>unspecified-pointer-type</i></del> <ins>nullptr_t</ins>);
43179</pre>
43180<blockquote>
43181<del>Assigns from the literal 0 or <tt>NULL</tt>. [<i>Note:</i> The
43182<i>unspecified-pointer-type</i> is often implemented as a pointer to a
43183private data member, avoiding many of the implicit conversion pitfalls.
43184<i>-- end note</i>]</del>
43185</blockquote>
43186</blockquote>
43187
43188
43189
43190
43191
43192<hr>
43193<h3><a name="1037"></a>1037. Response to UK 232</h3>
43194<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#WP">WP</a>
43195 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12  <b>Last modified:</b> 2009-07-18</p>
43196<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>
43197<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>
43198<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
43199<p><b>Discussion:</b></p>
43200
43201<p><b>Addresses UK 232</b></p>
43202
43203<p>
43204<tt>match_results</tt> may follow the requirements but is not listed a general
43205purpose library container.
43206</p>
43207
43208<p>
43209Remove reference to <tt>match_results</tt> against <tt>a[n]</tt> operation.
43210</p>
43211
43212<p><i>[
43213Summit:
43214]</i></p>
43215
43216
43217<blockquote>
43218Agree. <tt>operator[]</tt> is defined elsewhere.
43219</blockquote>
43220
43221<p><i>[
43222Batavia (2009-05):
43223]</i></p>
43224
43225<blockquote>
43226We agree with the proposed resolution.
43227Move to Tentatively Ready.
43228</blockquote>
43229
43230
43231<p><b>Proposed resolution:</b></p>
43232<p>
43233In 23.2.3 [sequence.reqmts] Table 84, remove reference to
43234<tt>match_results</tt> in the row describing the <tt>a[n]</tt> operation.
43235</p>
43236
43237
43238
43239
43240
43241<hr>
43242<h3><a name="1038"></a>1038. Response to UK 233</h3>
43243<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#WP">WP</a>
43244 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12  <b>Last modified:</b> 2009-07-18</p>
43245<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>
43246<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>
43247<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
43248<p><b>Discussion:</b></p>
43249
43250<p><b>Addresses UK 233</b></p>
43251
43252<p>
43253Table 84 is missing references to several new container types.
43254</p>
43255
43256<p><i>[
43257Summit:
43258]</i></p>
43259
43260
43261<blockquote>
43262Agree.
43263</blockquote>
43264
43265<p><i>[
43266Batavia (2009-05):
43267]</i></p>
43268
43269<blockquote>
43270We agree with the proposed resolution.
43271Move to Tentatively Ready.
43272</blockquote>
43273
43274
43275<p><b>Proposed resolution:</b></p>
43276<p>
43277In 23.2.3 [sequence.reqmts] Table 84, Add reference to listed
43278containers to the following rows:
43279</p>
43280
43281<blockquote>
43282<table border="1">
43283<caption>Table 84 -- Optional sequence container operations</caption>
43284<tbody><tr>
43285<th>Expression</th>
43286<th>Return type</th>
43287<th>Operational semantics</th>
43288<th>Container</th>
43289</tr>
43290<tr>
43291<td><tt>a.front()</tt></td>
43292<td>...</td>
43293<td>...</td>
43294<td><tt>vector, list, deque, basic_string<ins>, array, forward_list</ins></tt></td>
43295</tr>
43296<tr>
43297<td><tt>a.back()</tt></td>
43298<td>...</td>
43299<td>...</td>
43300<td><tt>vector, list, deque, basic_string<ins>, array</ins></tt></td>
43301</tr>
43302<tr>
43303<td><tt>a.emplace_front(args)</tt></td>
43304<td>...</td>
43305<td>...</td>
43306<td><tt>list, deque<ins>, forward_list</ins></tt></td>
43307</tr>
43308<tr>
43309<td><tt>a.push_front(t)</tt></td>
43310<td>...</td>
43311<td>...</td>
43312<td><tt>list, deque<ins>, forward_list</ins></tt></td>
43313</tr>
43314<tr>
43315<td><tt>a.push_front(rv)</tt></td>
43316<td>...</td>
43317<td>...</td>
43318<td><tt>list, deque<ins>, forward_list</ins></tt></td>
43319</tr>
43320<tr>
43321<td><tt>a.pop_front()</tt></td>
43322<td>...</td>
43323<td>...</td>
43324<td><tt>list, deque<ins>, forward_list</ins></tt></td>
43325</tr>
43326<tr>
43327<td><tt>a[n]</tt></td>
43328<td>...</td>
43329<td>...</td>
43330<td><tt>vector, deque, basic_string<ins>, array</ins></tt></td>
43331</tr>
43332<tr>
43333<td><tt>a.at(n)</tt></td>
43334<td>...</td>
43335<td>...</td>
43336<td><tt>vector, deque<ins>, basic_string, array</ins></tt></td>
43337</tr>
43338</tbody></table>
43339</blockquote>
43340
43341
43342
43343
43344
43345<hr>
43346<h3><a name="1039"></a>1039. Response to UK 234</h3>
43347<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#WP">WP</a>
43348 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12  <b>Last modified:</b> 2009-07-18</p>
43349<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>
43350<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>
43351<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
43352<p><b>Discussion:</b></p>
43353
43354<p><b>Addresses UK 234</b></p>
43355
43356<p>
43357The reference to <tt>iterator</tt> in semantics for <tt>back</tt> should
43358also allow for <tt>const_iterator</tt> when called on a const-qualified
43359container. This would be ugly to specify in the 03 standard, but is
43360quite easy with the addition of <tt>auto</tt> in this new standard.
43361</p>
43362
43363<p><i>[
43364Summit:
43365]</i></p>
43366
43367
43368<blockquote>
43369Agree.
43370</blockquote>
43371
43372<p><i>[
43373Batavia (2009-05):
43374]</i></p>
43375
43376<blockquote>
43377We agree with the proposed resolution.
43378Move to Tentatively Ready.
43379</blockquote>
43380
43381
43382<p><b>Proposed resolution:</b></p>
43383<p>
43384In 23.2.3 [sequence.reqmts] Table 84, replace iterator with auto in semantics for back:
43385</p>
43386
43387<blockquote>
43388<table border="1">
43389<caption>Table 84 -- Optional sequence container operations</caption>
43390<tbody><tr>
43391<th>Expression</th>
43392<th>Return type</th>
43393<th>Operational semantics</th>
43394<th>Container</th>
43395</tr>
43396<tr>
43397<td><tt>a.back()</tt></td>
43398<td><tt>reference; const_reference</tt> for constant <tt>a</tt></td>
43399<td><tt>{ <del>iterator</del> <ins>auto</ins> tmp = a.end();<br>--tmp;<br>return *tmp; }</tt></td>
43400<td><tt>vector, list, deque, basic_string</tt></td>
43401</tr>
43402</tbody></table>
43403</blockquote>
43404
43405
43406
43407
43408
43409<hr>
43410<h3><a name="1040"></a>1040. Response to UK 238</h3>
43411<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#WP">WP</a>
43412 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12  <b>Last modified:</b> 2009-07-18</p>
43413<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>
43414<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>
43415<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
43416<p><b>Discussion:</b></p>
43417
43418<p><b>Addresses UK 238</b></p>
43419
43420<p>
43421Leaving it unspecified whether or not <tt>iterator</tt> and <tt>const_iterator</tt> are the
43422same type is dangerous, as user code may or may not violate the One
43423Definition Rule by providing overloads for 
43424both types. It is probably too late to specify a single behaviour, but
43425implementors should document what to expect. Observing that problems can be
43426avoided by users restricting themselves to using <tt>const_iterator</tt>, add a note to that effect. 
43427</p>
43428<p>
43429Suggest Change 'unspecified' to 'implementation defined'.
43430</p>
43431
43432<p><i>[
43433Summit:
43434]</i></p>
43435
43436
43437<blockquote>
43438Agree with issue. Agree with adding the note but not with changing the
43439normative text. We believe the note provides sufficient guidance.
43440</blockquote>
43441
43442<p><i>[
43443Batavia (2009-05):
43444]</i></p>
43445
43446<blockquote>
43447We agree with the proposed resolution.
43448Move to Tentatively Ready.
43449</blockquote>
43450
43451
43452<p><b>Proposed resolution:</b></p>
43453<p>
43454In 23.2.4 [associative.reqmts] p6, add:
43455</p>
43456
43457<blockquote>
43458-6- <tt>iterator</tt> of an associative container meets the requirements
43459of the <tt>BidirectionalIterator</tt> concept. For associative
43460containers where the value type is the same as the key type, both
43461<tt>iterator</tt> and <tt>const_iterator</tt> are constant iterators. It
43462is unspecified whether or not <tt>iterator</tt> and
43463<tt>const_iterator</tt> are the same type.
43464<ins>[<i>Note:</i> <tt>iterator</tt> and <tt>const_iterator</tt> have identical semantics in
43465this case, and <tt>iterator</tt> is convertible to <tt>const_iterator</tt>. Users can avoid
43466violating the One Definition Rule by always using <tt>const_iterator</tt>
43467in their function parameter lists <i>-- end note</i>]</ins>
43468</blockquote>
43469
43470
43471
43472
43473
43474<hr>
43475<h3><a name="1044"></a>1044. Response to UK 325</h3>
43476<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#WP">WP</a>
43477 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12  <b>Last modified:</b> 2009-07-18</p>
43478<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
43479<p><b>Discussion:</b></p>
43480
43481<p><b>Addresses UK 325</b></p>
43482
43483<p>
43484We believe constexpr literal values should be a more natural expression
43485of empty tag types than extern objects as it should improve the
43486compiler's ability to optimize the empty object away completely.
43487</p>
43488
43489<p><i>[
43490Summit:
43491]</i></p>
43492
43493
43494<blockquote>
43495Move to review. The current specification is a "hack", and the proposed
43496specification is a better "hack".
43497</blockquote>
43498
43499<p><i>[
43500Batavia (2009-05):
43501]</i></p>
43502
43503<blockquote>
43504We agree with the proposed resolution.
43505Move to Tentatively Ready.
43506</blockquote>
43507
43508
43509<p><b>Proposed resolution:</b></p>
43510<p>
43511Change the synopsis in 30.4 [thread.mutex]:
43512</p>
43513
43514<blockquote><pre>struct defer_lock_t <ins>{}</ins>;
43515struct try_to_lock_t <ins>{}</ins>;
43516struct adopt_lock_t <ins>{}</ins>;
43517
43518<del>extern</del> const<ins>expr</ins> defer_lock_t defer_lock <ins>{}</ins>;
43519<del>extern</del> const<ins>expr</ins> try_to_lock_t try_to_lock <ins>{}</ins>;
43520<del>extern</del> const<ins>expr</ins> adopt_lock_t adopt_lock <ins>{}</ins>;
43521</pre></blockquote>
43522
43523
43524
43525
43526
43527
43528<hr>
43529<h3><a name="1045"></a>1045. Response to UK 326</h3>
43530<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#WP">WP</a>
43531 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12  <b>Last modified:</b> 2009-07-18</p>
43532<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
43533<p><b>Discussion:</b></p>
43534
43535<p><b>Addresses UK 326</b></p>
43536
43537<p>
43538The precondition that the mutex is not owned by this thread offers
43539introduces the risk of un-necessary undefined behaviour into the
43540program. The only time it matters whether the current thread owns the
43541mutex is in the lock operation, and that will happen subsequent to
43542construction in this case. The lock operation has the identical
43543pre-condition, so there is nothing gained by asserting that precondition
43544earlier and denying the program the right to get into a valid state
43545before calling lock.
43546</p>
43547
43548<p><i>[
43549Summit:
43550]</i></p>
43551
43552
43553<blockquote>
43554Agree, move to review.
43555</blockquote>
43556
43557<p><i>[
43558Batavia (2009-05):
43559]</i></p>
43560
43561<blockquote>
43562We agree with the proposed resolution.
43563Move to Tentatively Ready.
43564</blockquote>
43565
43566
43567<p><b>Proposed resolution:</b></p>
43568<p>
43569Strike 30.4.3.2.1 [thread.lock.unique.cons] p7:
43570</p>
43571
43572<blockquote><pre>unique_lock(mutex_type&amp; m, defer_lock_t);
43573</pre>
43574<blockquote>
43575<del>-7- <i>Precondition:</i> If <tt>mutex_type</tt> is not a recursive mutex
43576the calling thread does not own the mutex.</del>
43577</blockquote>
43578</blockquote>
43579
43580
43581
43582
43583
43584
43585<hr>
43586<h3><a name="1065"></a>1065. Response to UK 168</h3>
43587<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#WP">WP</a>
43588 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-15  <b>Last modified:</b> 2009-07-18</p>
43589<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>
43590<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
43591<p><b>Discussion:</b></p>
43592<p><b>Addresses UK 168</b></p>
43593<p>
43594We should make it clear (either by note or normatively) that namespace
43595<tt>std</tt> may contain inline namespaces, and that entities specified to be
43596defined in std may in fact be defined in one of these inline namespaces.
43597(If we're going to use them for versioning, eg when TR2 comes along,
43598we're going to need that.)
43599</p>
43600
43601<p>
43602Replace "namespace std or namespaces nested within namespace std" with
43603"namespace std or namespaces nested within namespace std or inline
43604namespaces nested directly or indirectly within namespace std"
43605</p>
43606
43607<p><i>[
43608Summit:
43609]</i></p>
43610
43611<blockquote>
43612adopt UK words (some have reservations whether it is correct)
43613</blockquote>
43614
43615<p><i>[
436162009-05-09 Alisdair improves the wording.
43617]</i></p>
43618
43619
43620<p><i>[
43621Batavia (2009-05):
43622]</i></p>
43623
43624<blockquote>
43625<p>
43626Bill believes there is strictly speaking no need to say that
43627because no portable test can detect the difference.
43628However he agrees that it doesn't hurt to say this.
43629</p>
43630<p>
43631Move to Tentatively Ready.
43632</p>
43633</blockquote>
43634
43635
43636<p><b>Proposed resolution:</b></p>
43637<p>
43638Change 17.6.1.1 [contents] p2:
43639</p>
43640
43641<blockquote>
43642All library entities except macros, <tt>operator new</tt> and
43643<tt>operator delete</tt> are defined within the namespace <tt>std</tt> or
43644namespaces nested within namespace <tt>std</tt>.
43645<ins>It is unspecified whether names declared in a specific namespace
43646are declared directly in that namespace, or in an inline namespace inside
43647that namespace. [<i>Footnote:</i> This gives implementers freedom to support
43648multiple configurations of the library.]</ins>
43649</blockquote>
43650
43651
43652
43653
43654
43655<hr>
43656<h3><a name="1066"></a>1066. Response to UK 189 and JP 27</h3>
43657<p><b>Section:</b> 18 [language.support] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
43658 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-15  <b>Last modified:</b> 2009-07-18</p>
43659<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
43660<p><b>Discussion:</b></p>
43661<p><b>Addresses UK 189 and JP 27</b></p>
43662<p>
43663The addition of the <tt>[[noreturn]]</tt> attribute to the language will be an
43664important aid for static analysis tools.
43665</p>
43666
43667<p>
43668The following functions should be declared in C++ with the
43669<tt>[[noreturn]]</tt> attribute: <tt>abort</tt> <tt>exit</tt>
43670<tt>quick_exit</tt> <tt>terminate</tt> <tt>unexpected</tt>
43671<tt>rethrow_exception</tt> <tt>throw_with_nested</tt>.
43672</p>
43673
43674<p><i>[
43675Summit:
43676]</i></p>
43677
43678<blockquote>
43679Agreed.
43680</blockquote>
43681
43682<p><i>[
43683Batavia (2009-05):
43684]</i></p>
43685
43686<blockquote>
43687We agree with the proposed resolution.
43688Move to Tentatively Ready.
43689</blockquote>
43690
43691
43692<p><b>Proposed resolution:</b></p>
43693<p>
43694Change 18.5 [support.start.term] p3:
43695</p>
43696
43697<blockquote>
43698<p>-2- ...</p>
43699<pre><ins>void</ins> abort <ins>[[noreturn]]</ins> (void)
43700</pre>
43701<p>-3- ...</p>
43702<p>-6- ...</p>
43703<pre><ins>void</ins> exit<ins> [[noreturn]] </ins>(int status)
43704</pre>
43705<p>-7- ...</p>
43706<p>-11- ...</p>
43707<pre>void quick_exit<ins> [[noreturn]] </ins>(int status)
43708</pre>
43709<p>-12- ...</p>
43710</blockquote>
43711
43712<p>
43713Change the <tt>&lt;exception&gt;</tt> synopsis in 18.8 [support.exception]:
43714</p>
43715
43716<blockquote><pre>void unexpected<ins> [[noreturn]] </ins>();
43717...
43718void terminate<ins> [[noreturn]] </ins>();
43719...
43720void rethrow_exception<ins> [[noreturn]] </ins>(exception_ptr p);
43721...
43722template &lt;class T&gt; void throw_with_nested<ins> [[noreturn]] </ins>(T&amp;&amp; t); <del>// [[noreturn]]</del>
43723</pre></blockquote>
43724
43725<p>
43726Change 18.8.2.4 [unexpected]:
43727</p>
43728
43729<blockquote><pre>void unexpected<ins> [[noreturn]] </ins>();
43730</pre></blockquote>
43731
43732<p>
43733Change 18.8.3.3 [terminate]:
43734</p>
43735
43736<blockquote><pre>void terminate<ins> [[noreturn]] </ins>();
43737</pre></blockquote>
43738
43739<p>
43740Change 18.8.5 [propagation]:
43741</p>
43742
43743<blockquote><pre>void rethrow_exception<ins> [[noreturn]] </ins>(exception_ptr p);
43744</pre></blockquote>
43745
43746<p>
43747In the synopsis of 18.8.6 [except.nested] and the definition area change:
43748</p>
43749
43750<blockquote><pre>template &lt;class T&gt; void throw_with_nested<ins> [[noreturn]] </ins>(T&amp;&amp; t); <del>// [[noreturn]]</del>
43751</pre></blockquote>
43752
43753
43754
43755
43756
43757<hr>
43758<h3><a name="1070"></a>1070. Ambiguous move overloads in function</h3>
43759<p><b>Section:</b> 20.7.15.2 [func.wrap.func] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
43760 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-19  <b>Last modified:</b> 2009-07-18</p>
43761<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>
43762<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
43763<p><b>Discussion:</b></p>
43764<p>
43765The synopsis in 20.7.15.2 [func.wrap.func] says:
43766</p>
43767
43768<blockquote><pre>template&lt;Returnable R, CopyConstructible... ArgTypes&gt; 
43769class function&lt;R(ArgTypes...)&gt;
43770{
43771    ...
43772    template&lt;class F&gt; 
43773      requires CopyConstructible&lt;F&gt; &amp;&amp; Callable&lt;F, ArgTypes...&gt; 
43774            &amp;&amp; Convertible&lt;Callable&lt;F, ArgTypes...&gt;::result_type, R&gt; 
43775      function(F); 
43776    template&lt;class F&gt; 
43777      requires CopyConstructible&lt;F&gt; &amp;&amp; Callable&lt;F, ArgTypes...&gt; 
43778            &amp;&amp; Convertible&lt;Callable&lt;F, ArgTypes...&gt;::result_type, R&gt; 
43779      function(F&amp;&amp;);
43780    ...
43781    template&lt;class F, Allocator Alloc&gt; function(allocator_arg_t, const Alloc&amp;, F); 
43782    template&lt;class F, Allocator Alloc&gt; function(allocator_arg_t, const Alloc&amp;, F&amp;&amp;);
43783    ...
43784    template&lt;class F&gt; 
43785      requires CopyConstructible&lt;F&gt; &amp;&amp; Callable&lt;F, ArgTypes..&gt; 
43786            &amp;&amp; Convertible&lt;Callable&lt;F, ArgTypes...&gt;::result_type 
43787      function&amp; operator=(F); 
43788    template&lt;class F&gt; 
43789      requires CopyConstructible&lt;F&gt; &amp;&amp; Callable&lt;F, ArgTypes...&gt; 
43790            &amp;&amp; Convertible&lt;Callable&lt;F, ArgTypes...&gt;::result_type, R&gt; 
43791      function&amp; operator=(F&amp;&amp;);
43792    ...
43793};
43794</pre></blockquote>
43795
43796<p>
43797Each of the 3 pairs above are ambiguous.  We need only one of each pair, and we
43798could do it with either one.  If we choose the <tt>F&amp;&amp;</tt> version we
43799need to bring <tt>decay</tt> into the definition to get the pass-by-value behavior.
43800In the proposed wording I've gotten lazy and just used the pass-by-value signature.
43801</p>
43802
43803<p><i>[
438042009-05-01 Daniel adds:
43805]</i></p>
43806
43807
43808<blockquote>
43809<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1024">1024</a> modifies the second removed constructor.
43810</blockquote>
43811
43812<p><i>[
43813Batavia (2009-05):
43814]</i></p>
43815
43816<blockquote>
43817<p>
43818We briefly discussed whether we ought support moveable function objects,
43819but decided that should be a separate issue if someone cares to propose it.
43820</p>
43821<p>
43822Move to Tentatively Ready.
43823</p>
43824</blockquote>
43825
43826
43827<p><b>Proposed resolution:</b></p>
43828<p>
43829Change the synopsis of 20.7.15.2 [func.wrap.func], and remove the associated definitions in
4383020.7.15.2.1 [func.wrap.func.con]:
43831</p>
43832
43833<blockquote><pre>template&lt;Returnable R, CopyConstructible... ArgTypes&gt; 
43834class function&lt;R(ArgTypes...)&gt;
43835{
43836    ...
43837    template&lt;class F&gt; 
43838      requires CopyConstructible&lt;F&gt; &amp;&amp; Callable&lt;F, ArgTypes...&gt; 
43839            &amp;&amp; Convertible&lt;Callable&lt;F, ArgTypes...&gt;::result_type, R&gt; 
43840      function(F); 
43841    <del>template&lt;class F&gt; 
43842      requires CopyConstructible&lt;F&gt; &amp;&amp; Callable&lt;F, ArgTypes...&gt; 
43843            &amp;&amp; Convertible&lt;Callable&lt;F, ArgTypes...&gt;::result_type, R&gt; 
43844      function(F&amp;&amp;);</del>
43845    ...
43846    template&lt;class F, Allocator Alloc&gt; function(allocator_arg_t, const Alloc&amp;, F); 
43847    <del>template&lt;class F, Allocator Alloc&gt; function(allocator_arg_t, const Alloc&amp;, F&amp;&amp;);</del>
43848    ...
43849    template&lt;class F&gt; 
43850      requires CopyConstructible&lt;F&gt; &amp;&amp; Callable&lt;F, ArgTypes..&gt; 
43851            &amp;&amp; Convertible&lt;Callable&lt;F, ArgTypes...&gt;::result_type 
43852      function&amp; operator=(F); 
43853    <del>template&lt;class F&gt; 
43854      requires CopyConstructible&lt;F&gt; &amp;&amp; Callable&lt;F, ArgTypes...&gt; 
43855            &amp;&amp; Convertible&lt;Callable&lt;F, ArgTypes...&gt;::result_type, R&gt; 
43856      function&amp; operator=(F&amp;&amp;);</del>
43857    ...
43858};
43859</pre></blockquote>
43860
43861
43862
43863
43864
43865
43866<hr>
43867<h3><a name="1073"></a>1073. Declaration of <tt>allocator_arg</tt> should be <tt>constexpr</tt></h3>
43868<p><b>Section:</b> 20.8 [memory] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
43869 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-19  <b>Last modified:</b> 2009-07-18</p>
43870<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>
43871<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
43872<p><b>Discussion:</b></p>
43873
43874<p>
43875Declaration of <tt>allocator_arg</tt> should be <tt>constexpr</tt> to ensure constant
43876initialization.
43877</p>
43878
43879<p><i>[
43880Batavia (2009-05):
43881]</i></p>
43882
43883<blockquote>
43884We agree with the proposed resolution.  Move to Tentatively Ready.
43885</blockquote>
43886
43887
43888<p><b>Proposed resolution:</b></p>
43889<p>
43890Change 20.8 [memory] p2:
43891</p>
43892
43893<blockquote><pre>// 20.8.1, allocator argument tag
43894struct allocator_arg_t { };
43895const<ins>expr</ins> allocator_arg_t allocator_arg = allocator_arg_t();
43896</pre></blockquote>
43897
43898
43899
43900
43901
43902
43903<hr>
43904<h3><a name="1103"></a>1103. <tt>system_error</tt> constructor postcondition overly strict</h3>
43905<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#WP">WP</a>
43906 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-04-25  <b>Last modified:</b> 2009-07-18</p>
43907<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
43908<p><b>Discussion:</b></p>
43909<p>
4391019.5.5.2 [syserr.syserr.members] says:
43911</p>
43912
43913<blockquote><pre>system_error(error_code ec, const string&amp; what_arg);
43914</pre>
43915<blockquote>
43916<p>
43917<i>Effects:</i> Constructs an object of class <tt>system_error</tt>.
43918</p>
43919<p>
43920<i>Postconditions:</i> <tt>code() == ec</tt> and <tt>strcmp(runtime_error::what(), what_arg.c_str()) == 0</tt>.
43921</p>
43922</blockquote>
43923</blockquote>
43924
43925<p>
43926However the intent is for:
43927</p>
43928
43929<blockquote><pre>std::system_error se(std::errc::not_a_directory, "In FooBar");
43930...
43931se.what();  <font color="#c80000">// returns something along the lines of:</font>
43932            <font color="#c80000">//   "In FooBar: Not a directory"</font>
43933</pre></blockquote>
43934
43935<p>
43936The way the constructor postconditions are set up now, to achieve both
43937conformance, and the desired intent in the <tt>what()</tt> string, the
43938<tt>system_error</tt> constructor must store "In FooBar" in the base class,
43939and then form the desired output each time <tt>what()</tt> is called.  Or
43940alternatively, store "In FooBar" in the base class, and store the desired
43941<tt>what()</tt> string in the derived <tt>system_error</tt>, and override
43942<tt>what()</tt> to return the string in the derived part.
43943</p>
43944
43945<p>
43946Both of the above implementations seem suboptimal to me.  In one I'm computing
43947a new string every time <tt>what()</tt> is called.  And since <tt>what()</tt>
43948can't propagate exceptions, the client may get a different string on different
43949calls.
43950</p>
43951
43952<p>
43953The second solution requires storing two strings instead of one.
43954</p>
43955
43956<p>
43957What I would like to be able to do is form the desired <tt>what()</tt> string
43958once in the <tt>system_error</tt> constructor, and store <em>that</em> in the
43959base class.  Now I'm:
43960</p>
43961
43962<ol>
43963<li>Computing the desired <tt>what()</tt> only once.</li>
43964<li>The base class <tt>what()</tt> definition is sufficient and nothrow.</li>
43965<li>I'm not storing multiple strings.</li>
43966</ol>
43967
43968<p>
43969This is smaller code, smaller data, and faster.
43970</p>
43971
43972<p>
43973<tt>ios_base::failure</tt> has the same issue.
43974</p>
43975
43976<p><i>[
43977Comments about this change received favorable comments from the <tt>system_error</tt>
43978designers.
43979]</i></p>
43980
43981
43982<p><i>[
43983Batavia (2009-05):
43984]</i></p>
43985
43986
43987<blockquote>
43988<p>
43989We agree with the proposed resolution.
43990</p>
43991<p>
43992Move to Tentatively Ready.
43993</p>
43994</blockquote>
43995
43996
43997<p><b>Proposed resolution:</b></p>
43998<p>
43999In 19.5.5.2 [syserr.syserr.members], change the following constructor postconditions:
44000</p>
44001
44002<blockquote>
44003<pre>system_error(error_code ec, const string&amp; what_arg);
44004</pre>
44005<blockquote>
44006-2- <i>Postconditions:</i> <tt>code() == ec</tt>
44007and <tt><del>strcmp(runtime_error::what(), what_arg.c_str()) == 0</del>
44008<ins>string(what()).find(what_arg) != string::npos</ins></tt>.
44009</blockquote>
44010
44011<pre>system_error(error_code ec, const char* what_arg);
44012</pre>
44013<blockquote>
44014-4- <i>Postconditions:</i> <tt>code() == ec</tt>
44015and <tt><del>strcmp(runtime_error::what(), what_arg) == 0</del>
44016<ins>string(what()).find(what_arg) != string::npos</ins></tt>.
44017</blockquote>
44018
44019<pre>system_error(error_code ec);
44020</pre>
44021<blockquote>
44022-6- <i>Postconditions:</i> <tt>code() == ec</tt>
44023<del>and <tt>strcmp(runtime_error::what(), ""</tt></del>.
44024</blockquote>
44025
44026<pre>system_error(int ev, const error_category&amp; ecat, const string&amp; what_arg);
44027</pre>
44028<blockquote>
44029-8- <i>Postconditions:</i> <tt>code() == error_code(ev, ecat)</tt>
44030and <tt><del>strcmp(runtime_error::what(), what_arg.c_str()) == 0</del>
44031<ins>string(what()).find(what_arg) != string::npos</ins></tt>.
44032</blockquote>
44033
44034<pre>system_error(int ev, const error_category&amp; ecat, const char* what_arg);
44035</pre>
44036<blockquote>
44037-10- <i>Postconditions:</i> <tt>code() == error_code(ev, ecat)</tt>
44038and <tt><del>strcmp(runtime_error::what(), what_arg) == 0</del>
44039<ins>string(what()).find(what_arg) != string::npos</ins></tt>.
44040</blockquote>
44041
44042<pre>system_error(int ev, const error_category&amp; ecat);
44043</pre>
44044<blockquote>
44045-12- <i>Postconditions:</i> <tt>code() == error_code(ev, ecat)</tt>
44046<del>and <tt>strcmp(runtime_error::what(), "") == 0</tt></del>.
44047</blockquote>
44048
44049</blockquote>
44050
44051<p>
44052In 19.5.5.2 [syserr.syserr.members], change the description of <tt>what()</tt>:
44053</p>
44054
44055<blockquote>
44056<pre>const char *what() const throw();
44057</pre>
44058<blockquote>
44059<p>
44060-14- <i>Returns:</i> An NTBS incorporating <del><tt>runtime_error::what()</tt> and
44061<tt>code().message()</tt></del> <ins>the arguments supplied in the constructor</ins>.
44062</p>
44063<p>
44064[<i>Note:</i> <del>One possible implementation would be:</del>
44065<ins>The return NTBS might take the form: <tt>what_arg + ": " + code().message()</tt></ins>
44066</p>
44067<blockquote><pre><del>
44068if (msg.empty()) { 
44069  try { 
44070    string tmp = runtime_error::what(); 
44071    if (code()) { 
44072      if (!tmp.empty()) 
44073        tmp += ": "; 
44074      tmp += code().message(); 
44075    } 
44076    swap(msg, tmp); 
44077  } catch(...) { 
44078    return runtime_error::what(); 
44079  } 
44080return msg.c_str();
44081</del></pre></blockquote>
44082<p>
44083&#8212; <i>end note</i>]
44084</p>
44085</blockquote>
44086</blockquote>
44087
44088<p>
44089In 27.5.2.1.1 [ios::failure], change the synopsis:
44090</p>
44091
44092<blockquote><pre>namespace std { 
44093  class ios_base::failure : public system_error { 
44094  public: 
44095    explicit failure(const string&amp; msg, const error_code&amp; ec = io_errc::stream); 
44096    explicit failure(const char* msg, const error_code&amp; ec = io_errc::stream); 
44097    <del>virtual const char* what() const throw();</del>
44098  }; 
44099}
44100</pre></blockquote>
44101
44102<p>
44103In 27.5.2.1.1 [ios::failure], change the description of the constructors:
44104</p>
44105
44106<blockquote>
44107
44108<pre>explicit failure(const string&amp; msg, , const error_code&amp; ec = io_errc::stream);
44109</pre>
44110<blockquote>
44111<p>
44112-3- <i>Effects:</i> Constructs an object of class <tt>failure</tt>
44113<ins>by constructing the base class with <tt>msg</tt> and <tt>ec</tt></ins>.
44114</p>
44115<p>
44116<del>-4- <i>Postcondition:</i> <tt>code() == ec</tt> and <tt>strcmp(what(), msg.c_str()) == 0</tt></del>
44117</p>
44118</blockquote>
44119
44120<pre>explicit failure(const char* msg, const error_code&amp; ec = io_errc::stream);
44121</pre>
44122<blockquote>
44123<p>
44124-5- <i>Effects:</i> Constructs an object of class <tt>failure</tt>
44125<ins>by constructing the base class with <tt>msg</tt> and <tt>ec</tt></ins>.
44126</p>
44127<p>
44128<del>-6- <i>Postcondition:</i> <tt>code() == ec and strcmp(what(), msg) == 0</tt></del>
44129</p>
44130</blockquote>
44131
44132</blockquote>
44133
44134<p>
44135In 27.5.2.1.1 [ios::failure], remove <tt>what</tt> (the base class definition
44136need not be repeated here).
44137</p>
44138
44139<blockquote>
44140<pre><del>const char* what() const;</del>
44141</pre>
44142<blockquote>
44143<del>-7- <i>Returns:</i> The message <tt>msg</tt> with which the exception was created.</del>
44144</blockquote>
44145
44146</blockquote>
44147
44148
44149
44150
44151
44152
44153<hr>
44154<h3><a name="1178"></a>1178. Header dependencies</h3>
44155<p><b>Section:</b> 17.6.4.2 [res.on.headers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
44156 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2009-07-18  <b>Last modified:</b> 2009-10-26</p>
44157<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
44158<p><b>Discussion:</b></p>
44159<p>
44160See Frankfurt notes of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1001">1001</a>.
44161</p>
44162
44163
44164<p><b>Proposed resolution:</b></p>
44165<p><i>Change 17.6.4.2 [res.on.headers], Headers, paragraph 1, as indicated:</i></p>
44166
44167<blockquote>
44168
44169<p>
44170A C++ header may include other C++
44171headers.<del><sup>[footnote]</sup></del> <ins>A C++ header shall provide
44172the declarations and definitions that appear in its synopsis
44173(3.2 [basic.def.odr]). A C++ header shown in its synopsis as including 
44174other C++ headers shall provide the declarations and definitions that appear in
44175the synopses of those other headers.</ins>
44176</p>
44177
44178  <p><del><sup>[footnote]</sup> C++ headers must include a C++ header that contains 
44179  any needed definition (3.2).</del></p>
44180</blockquote>
44181
44182
44183
44184
44185
44186
44187</body></html>