libstdc++-v3/doc/html/ext/lwg-closed.html

   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 Closed Issues List</title>
   7 <style type="text/css">
   8 p {text-align:justify}
   9 li {text-align:justify}
  10 ins {background-color:#A0FFA0}
  11 del {background-color:#FFA0A0}
  12 </style>
  13 </head><body>
  14 <table>
  15 <tbody><tr>
  16 <td align="left">Doc. no.</td>
  17 <td align="left">N2896=09-0086</td>
  18 </tr>
  19 <tr>
  20 <td align="left">Date:</td>
  21 <td align="left">2009-06-21</td>
  22 </tr>
  23 <tr>
  24 <td align="left">Project:</td>
  25 <td align="left">Programming Language C++</td>
  26 </tr>
  27 <tr>
  28 <td align="left">Reply to:</td>
  29 <td align="left">Howard Hinnant &lt;<a href="mailto:howard.hinnant@gmail.com">howard.hinnant@gmail.com</a>&gt;</td>
  30 </tr>
  31 </tbody></table>
  32 <h1>C++ Standard Library Closed Issues List (Revision R65)</h1>
  33
  34   <p>Reference ISO/IEC IS 14882:2003(E)</p>
  35   <p>Also see:</p>
  36     <ul>
  37       <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html">Table of Contents</a> for all library issues.</li>
  38       <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html">Index by Section</a> for all library issues.</li>
  39       <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html">Index by Status</a> for all library issues.</li>
  40       <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html">Library Active Issues List</a></li>
  41       <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html">Library Defect Reports List</a></li>
  42     </ul>
  43
  44   <p>This document contains only library issues which have been closed
  45   by the Library Working Group as duplicates or not defects. That is,
  46   issues which have a status of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> or
  47   <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>. See the <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html">Library Active Issues List</a> active issues and more
  48   information. See the <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html">Library Defect Reports List</a> for issues considered
  49   defects.  The introductory material in that document also applies to
  50   this document.</p>
  51
  52 <h2>Revision History</h2>
  53 <ul>
  54 <li>R65:
  55 2009-06-19 pre-Frankfurt mailing.
  56 <ul>
  57 <li><b>Summary:</b><ul>
  58 <li>378 open issues, up by 32.</li>
  59 <li>765 closed issues, up by 0.</li>
  60 <li>1143 issues total, up by 32.</li>
  61 </ul></li>
  62 <li><b>Details:</b><ul>
  63 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1115">1115</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1116">1116</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1117">1117</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1118">1118</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1119">1119</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1120">1120</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1121">1121</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1122">1122</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1123">1123</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1124">1124</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1125">1125</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1126">1126</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1127">1127</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1128">1128</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1129">1129</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1130">1130</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1131">1131</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1132">1132</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1133">1133</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1134">1134</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1135">1135</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1136">1136</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1137">1137</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1138">1138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1139">1139</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1140">1140</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1141">1141</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1142">1142</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1143">1143</a>.</li>
  64 <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>
  65 <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>
  66 <li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#696">696</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#716">716</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#727">727</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#865">865</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#900">900</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#911">911</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#916">916</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#917">917</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#920">920</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#933">933</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#935">935</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#941">941</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#947">947</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#951">951</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#953">953</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#954">954</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#955">955</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#956">956</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#977">977</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#978">978</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#985">985</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#989">989</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#996">996</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1033">1033</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1054">1054</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1056">1056</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1057">1057</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1059">1059</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1062">1062</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1068">1068</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1069">1069</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1071">1071</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1072">1072</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1076">1076</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1090">1090</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1092">1092</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1096">1096</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1098">1098</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1099">1099</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1105">1105</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1106">1106</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1108">1108</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1110">1110</a>.</li>
  67 <li>Changed the following issues from Review to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#817">817</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#971">971</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#992">992</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1004">1004</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1010">1010</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1012">1012</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1015">1015</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1019">1019</a>.</li>
  68 <li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#780">780</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#835">835</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#897">897</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#919">919</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#939">939</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#957">957</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#983">983</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1001">1001</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1080">1080</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1091">1091</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1093">1093</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1094">1094</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1095">1095</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1097">1097</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1102">1102</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1104">1104</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1111">1111</a>.</li>
  69 <li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#921">921</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#987">987</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1087">1087</a>.</li>
  70 <li>Changed the following issues from New to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#568">568</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#701">701</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#702">702</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#785">785</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#863">863</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#903">903</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#912">912</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#918">918</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#946">946</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#995">995</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1074">1074</a>.</li>
  71 <li>Changed the following issues from Open to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#458">458</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#644">644</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#669">669</a>.</li>
  72 <li>Changed the following issues from Review to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#901">901</a>.</li>
  73 <li>Changed the following issues from Tentatively Ready to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#822">822</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#988">988</a>.</li>
  74 <li>Changed the following issues from New to Tentatively NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#837">837</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#862">862</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#867">867</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#927">927</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#945">945</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#952">952</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#969">969</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#972">972</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#973">973</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#979">979</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1058">1058</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1060">1060</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1061">1061</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1077">1077</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1101">1101</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1109">1109</a>.</li>
  75 <li>Changed the following issues from Open to Tentatively NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#424">424</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#825">825</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#830">830</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#884">884</a>.</li>
  76 <li>Changed the following issues from Review to Tentatively NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1023">1023</a>.</li>
  77 <li>Changed the following issues from Open to Tentatively NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#96">96</a>.</li>
  78 <li>Changed the following issues from New to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#810">810</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#898">898</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#906">906</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#910">910</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#913">913</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#914">914</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#915">915</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#925">925</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#974">974</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#976">976</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#981">981</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#982">982</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#984">984</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#990">990</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#998">998</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#999">999</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1063">1063</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1067">1067</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1070">1070</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1073">1073</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1100">1100</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1103">1103</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1107">1107</a>.</li>
  79 <li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#814">814</a>.</li>
  80 <li>Changed the following issues from Review to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#899">899</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#907">907</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#909">909</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#934">934</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#938">938</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#940">940</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#943">943</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#950">950</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#965">965</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#970">970</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#975">975</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#986">986</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#991">991</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#993">993</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#994">994</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#997">997</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1002">1002</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1006">1006</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1011">1011</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1013">1013</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1014">1014</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1021">1021</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1024">1024</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1037">1037</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1038">1038</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1039">1039</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1040">1040</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1044">1044</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1045">1045</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1065">1065</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1066">1066</a>.</li>
  81 </ul></li>
  82 </ul>
  83 </li>
  84 <li>R64:
  85 2009-05-01 mid-term mailing.
  86 <ul>
  87 <li><b>Summary:</b><ul>
  88 <li>346 open issues, up by 19.</li>
  89 <li>765 closed issues, up by 0.</li>
  90 <li>1111 issues total, up by 19.</li>
  91 </ul></li>
  92 <li><b>Details:</b><ul>
  93 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1093">1093</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1094">1094</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1095">1095</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1096">1096</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1097">1097</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1098">1098</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1099">1099</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1100">1100</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1101">1101</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1102">1102</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1103">1103</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1104">1104</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1105">1105</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1106">1106</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1107">1107</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1108">1108</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1109">1109</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1110">1110</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1111">1111</a>.</li>
  94 <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>
  95 <li>Changed the following issues from Review to New: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1070">1070</a>.</li>
  96 </ul></li>
  97 </ul>
  98 </li>
  99 <li>R63:
 100 2009-03-20 post-Summit mailing.
 101 <ul>
 102 <li><b>Summary:</b><ul>
 103 <li>327 open issues, up by 96.</li>
 104 <li>765 closed issues, up by 14.</li>
 105 <li>1092 issues total, up by 110.</li>
 106 </ul></li>
 107 <li><b>Details:</b><ul>
 108 <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>
 109 <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>
 110 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#983">983</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#984">984</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#985">985</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#989">989</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#990">990</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#995">995</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#996">996</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#998">998</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#999">999</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1001">1001</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1033">1033</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1054">1054</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1056">1056</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1057">1057</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1058">1058</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1059">1059</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1060">1060</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1061">1061</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1062">1062</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1063">1063</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1067">1067</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1068">1068</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1069">1069</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1071">1071</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1072">1072</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1073">1073</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1074">1074</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1076">1076</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1077">1077</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1080">1080</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1090">1090</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1091">1091</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1092">1092</a>.</li>
 111 <li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#987">987</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1000">1000</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1007">1007</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1008">1008</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1016">1016</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1017">1017</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1018">1018</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1020">1020</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1026">1026</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1027">1027</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1028">1028</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1029">1029</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1030">1030</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1031">1031</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1032">1032</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1034">1034</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1035">1035</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1036">1036</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1041">1041</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1042">1042</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1046">1046</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1048">1048</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1051">1051</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1052">1052</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1053">1053</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1055">1055</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1064">1064</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1075">1075</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1078">1078</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1079">1079</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1081">1081</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1082">1082</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1083">1083</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1084">1084</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1085">1085</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1086">1086</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1087">1087</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1088">1088</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1089">1089</a>.</li>
 112 <li>Added the following Review issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#986">986</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#991">991</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#992">992</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#993">993</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#994">994</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#997">997</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1002">1002</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1003">1003</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1004">1004</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1005">1005</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1006">1006</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1009">1009</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1010">1010</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1011">1011</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1012">1012</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1013">1013</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1014">1014</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1015">1015</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1019">1019</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1021">1021</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1023">1023</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1024">1024</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1037">1037</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1038">1038</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1039">1039</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1040">1040</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1043">1043</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1044">1044</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1045">1045</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1047">1047</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1049">1049</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1050">1050</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1065">1065</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1066">1066</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1070">1070</a>.</li>
 113 <li>Added the following Tentatively Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#988">988</a>.</li>
 114 <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>
 115 <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>
 116 <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>
 117 <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>
 118 <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>
 119 <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>
 120 <li>Changed the following issues from NAD to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#466">466</a>.</li>
 121 <li>Changed the following issues from NAD Future to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#111">111</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#149">149</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#219">219</a>.</li>
 122 <li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#880">880</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#891">891</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#893">893</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#902">902</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#908">908</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#921">921</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#923">923</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#924">924</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#926">926</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#930">930</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#936">936</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#944">944</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#958">958</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#959">959</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#960">960</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#961">961</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#962">962</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#963">963</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#964">964</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#966">966</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#967">967</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#968">968</a>.</li>
 123 <li>Changed the following issues from Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#788">788</a>.</li>
 124 <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>
 125 <li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#879">879</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#899">899</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#901">901</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#907">907</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#909">909</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#929">929</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#934">934</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#938">938</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#940">940</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#943">943</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#950">950</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#965">965</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#970">970</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#971">971</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#975">975</a>.</li>
 126 <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>
 127 <li>Changed the following issues from New to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#904">904</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#922">922</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#928">928</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#931">931</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#932">932</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#948">948</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#949">949</a>.</li>
 128 <li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#890">890</a>.</li>
 129 <li>Changed the following issues from Review to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#765">765</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#822">822</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#853">853</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#869">869</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#878">878</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#888">888</a>.</li>
 130 <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>
 131 </ul></li>
 132 </ul>
 133 </li>
 134 <li>R62:
 135 2009-02-06 pre-Summit mailing.
 136 <ul>
 137 <li><b>Summary:</b><ul>
 138 <li>231 open issues, up by 44.</li>
 139 <li>751 closed issues, up by 0.</li>
 140 <li>982 issues total, up by 44.</li>
 141 </ul></li>
 142 <li><b>Details:</b><ul>
 143 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#939">939</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#940">940</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#941">941</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#942">942</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#943">943</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#944">944</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#945">945</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#946">946</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#947">947</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#948">948</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#949">949</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#950">950</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#951">951</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#952">952</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#953">953</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#954">954</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#955">955</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#956">956</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#957">957</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#958">958</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#959">959</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#960">960</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#961">961</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#962">962</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#963">963</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#964">964</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#965">965</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#966">966</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#967">967</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#968">968</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#969">969</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#970">970</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#971">971</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#972">972</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#973">973</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#974">974</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#975">975</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#976">976</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#977">977</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#978">978</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#979">979</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#980">980</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#981">981</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#982">982</a>.</li>
 144 </ul></li>
 145 </ul>
 146 </li>
 147 <li>R61:
 148 2008-12-05 mid-term mailing.
 149 <ul>
 150 <li><b>Summary:</b><ul>
 151 <li>187 open issues, up by 20.</li>
 152 <li>751 closed issues, up by 0.</li>
 153 <li>938 issues total, up by 20.</li>
 154 </ul></li>
 155 <li><b>Details:</b><ul>
 156 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#919">919</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#920">920</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#921">921</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#922">922</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#923">923</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#924">924</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#925">925</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#926">926</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#927">927</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#928">928</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#929">929</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#930">930</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#931">931</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#932">932</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#933">933</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#934">934</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#935">935</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#936">936</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#937">937</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#938">938</a>.</li>
 157 </ul></li>
 158 </ul>
 159 </li>
 160 <li>R60:
 161 2008-10-03 post-San Francisco mailing.
 162 <ul>
 163 <li><b>Summary:</b><ul>
 164 <li>167 open issues, down by 25.</li>
 165 <li>751 closed issues, up by 65.</li>
 166 <li>918 issues total, up by 40.</li>
 167 </ul></li>
 168 <li><b>Details:</b><ul>
 169 <li>Added the following CD1 issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#882">882</a>.</li>
 170 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#879">879</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#880">880</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#891">891</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#893">893</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#897">897</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#898">898</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#899">899</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#900">900</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#901">901</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#902">902</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#903">903</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#904">904</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#905">905</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#906">906</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#907">907</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#908">908</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#909">909</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#910">910</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#911">911</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#912">912</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#913">913</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#914">914</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#915">915</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#916">916</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#917">917</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#918">918</a>.</li>
 171 <li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#881">881</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#883">883</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#884">884</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#885">885</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#886">886</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#887">887</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#889">889</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#890">890</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#895">895</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#896">896</a>.</li>
 172 <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>
 173 <li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#894">894</a>.</li>
 174 <li>Added the following Review issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#888">888</a>.</li>
 175 <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>
 176 <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>
 177 <li>Changed the following issues from Review to CD1: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#23">23</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#698">698</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#709">709</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#804">804</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#823">823</a>.</li>
 178 <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>
 179 <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>
 180 <li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#849">849</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#855">855</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#871">871</a>.</li>
 181 <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>
 182 <li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#811">811</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#812">812</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#841">841</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#864">864</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#870">870</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#872">872</a>.</li>
 183 <li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#299">299</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#484">484</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#556">556</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#676">676</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#724">724</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#742">742</a>.</li>
 184 <li>Changed the following issues from Pending NAD Editorial to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#594">594</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#717">717</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#725">725</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#738">738</a>.</li>
 185 <li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#721">721</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#751">751</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#814">814</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#816">816</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#817">817</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#819">819</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#827">827</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#836">836</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#838">838</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#847">847</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#857">857</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#859">859</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#860">860</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#861">861</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#868">868</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#873">873</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#876">876</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#877">877</a>.</li>
 186 <li>Changed the following issues from Pending NAD Editorial to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#424">424</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#625">625</a>.</li>
 187 <li>Changed the following issues from Review to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#851">851</a>.</li>
 188 <li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#788">788</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#821">821</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#866">866</a>.</li>
 189 <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>
 190 <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>
 191 <li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#765">765</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#822">822</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#853">853</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#854">854</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#869">869</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#878">878</a>.</li>
 192 <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>
 193 </ul></li>
 194 </ul>
 195 </li>
 196 <li>R59:
 197 2008-08-22 pre-San Francisco mailing.
 198 <ul>
 199 <li><b>Summary:</b><ul>
 200 <li>192 open issues, up by 9.</li>
 201 <li>686 closed issues, up by 0.</li>
 202 <li>878 issues total, up by 9.</li>
 203 </ul></li>
 204 <li><b>Details:</b><ul>
 205 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#870">870</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#871">871</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#872">872</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#873">873</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#874">874</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#875">875</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#876">876</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#877">877</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#878">878</a>.</li>
 206 </ul></li>
 207 </ul>
 208 </li>
 209 <li>R58:
 210 2008-07-28 mid-term mailing.
 211 <ul>
 212 <li><b>Summary:</b><ul>
 213 <li>183 open issues, up by 12.</li>
 214 <li>686 closed issues, down by 4.</li>
 215 <li>869 issues total, up by 8.</li>
 216 </ul></li>
 217 <li><b>Details:</b><ul>
 218 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#862">862</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#863">863</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#864">864</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#865">865</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#866">866</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#867">867</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#868">868</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#869">869</a>.</li>
 219 <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>
 220 <li>Changed the following issues from Pending WP to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#644">644</a>.</li>
 221 <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>
 222 <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>
 223 </ul></li>
 224 </ul>
 225 </li>
 226 <li>R57:
 227 2008-06-27 post-Sophia Antipolis mailing.
 228 <ul>
 229 <li><b>Summary:</b><ul>
 230 <li>171 open issues, down by 20.</li>
 231 <li>690 closed issues, up by 43.</li>
 232 <li>861 issues total, up by 23.</li>
 233 </ul></li>
 234 <li><b>Details:</b><ul>
 235 <li>Added the following NAD issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#840">840</a>.</li>
 236 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#841">841</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#843">843</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#845">845</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#846">846</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#847">847</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#849">849</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#853">853</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#854">854</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#855">855</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#856">856</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#857">857</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#858">858</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#859">859</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#860">860</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#861">861</a>.</li>
 237 <li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#839">839</a>.</li>
 238 <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>
 239 <li>Added the following Review issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#851">851</a>.</li>
 240 <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>
 241 <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>
 242 <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>
 243 <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>
 244 <li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#723">723</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#726">726</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#794">794</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#815">815</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#825">825</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#830">830</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#833">833</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#834">834</a>.</li>
 245 <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>
 246 <li>Changed the following issues from Review to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>.</li>
 247 <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>
 248 <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>
 249 <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>
 250 <li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#698">698</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#804">804</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#823">823</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#828">828</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#832">832</a>.</li>
 251 <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>
 252 <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>
 253 <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>
 254 </ul></li>
 255 </ul>
 256 </li>
 257 <li>R56:
 258 2008-05-16 pre-Sophia Antipolis mailing.
 259 <ul>
 260 <li><b>Summary:</b><ul>
 261 <li>191 open issues, up by 24.</li>
 262 <li>647 closed issues, up by 1.</li>
 263 <li>838 issues total, up by 25.</li>
 264 </ul></li>
 265 <li><b>Details:</b><ul>
 266 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#814">814</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#815">815</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#816">816</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#817">817</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#818">818</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#819">819</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#820">820</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#821">821</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#822">822</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#823">823</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#824">824</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#825">825</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#826">826</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#827">827</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#828">828</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#829">829</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#830">830</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#831">831</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#832">832</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#833">833</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#834">834</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#835">835</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#836">836</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#837">837</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#838">838</a>.</li>
 267 <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>
 268 </ul></li>
 269 </ul>
 270 </li>
 271 <li>R55:
 272 2008-03-14 post-Bellevue mailing.
 273 <ul>
 274 <li><b>Summary:</b><ul>
 275 <li>167 open issues, down by 39.</li>
 276 <li>646 closed issues, up by 65.</li>
 277 <li>813 issues total, up by 26.</li>
 278 </ul></li>
 279 <li><b>Details:</b><ul>
 280 <li>Added the following Dup issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#795">795</a>.</li>
 281 <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>
 282 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#788">788</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#794">794</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#802">802</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#804">804</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#805">805</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#806">806</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#807">807</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#808">808</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#809">809</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#810">810</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#811">811</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#812">812</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#813">813</a>.</li>
 283 <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>
 284 <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>
 285 <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>
 286 <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>
 287 <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>
 288 <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>
 289 <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>
 290 <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>
 291 <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>
 292 <li>Changed the following issues from NAD Future to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#128">128</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#190">190</a>.</li>
 293 <li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#617">617</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#718">718</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#719">719</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#724">724</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#742">742</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#747">747</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#750">750</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#762">762</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#774">774</a>.</li>
 294 <li>Changed the following issues from Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#676">676</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>.</li>
 295 <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>
 296 <li>Changed the following issues from Open to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#424">424</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#625">625</a>.</li>
 297 <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>
 298 <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>
 299 <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>
 300 <li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#776">776</a>.</li>
 301 <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>
 302 <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>
 303 <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>
 304 </ul></li>
 305 </ul>
 306 </li>
 307 <li>R54:
 308 2008-02-01 pre-Bellevue mailing.
 309 <ul>
 310 <li><b>Summary:</b><ul>
 311 <li>206 open issues, up by 23.</li>
 312 <li>581 closed issues, up by 0.</li>
 313 <li>787 issues total, up by 23.</li>
 314 </ul></li>
 315 <li><b>Details:</b><ul>
 316 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#765">765</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#769">769</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#772">772</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#773">773</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#774">774</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#776">776</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#779">779</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#780">780</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#783">783</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#784">784</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#785">785</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#786">786</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#787">787</a>.</li>
 317 <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>
 318 <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>
 319 <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>
 320 <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>
 321 <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>
 322 </ul></li>
 323 </ul>
 324 </li>
 325 <li>R53:
 326 2007-12-09 mid-term mailing.
 327 <ul>
 328 <li><b>Summary:</b><ul>
 329 <li>183 open issues, up by 11.</li>
 330 <li>581 closed issues, down by 1.</li>
 331 <li>764 issues total, up by 10.</li>
 332 </ul></li>
 333 <li><b>Details:</b><ul>
 334 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#757">757</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#762">762</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#763">763</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#764">764</a>.</li>
 335 <li>Changed the following issues from NAD to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>.</li>
 336 <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>
 337 </ul></li>
 338 </ul>
 339 </li>
 340 <li>R52:
 341 2007-10-19 post-Kona mailing.
 342 <ul>
 343 <li><b>Summary:</b><ul>
 344 <li>172 open issues, up by 4.</li>
 345 <li>582 closed issues, up by 27.</li>
 346 <li>754 issues total, up by 31.</li>
 347 </ul></li>
 348 <li><b>Details:</b><ul>
 349 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#724">724</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#725">725</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#726">726</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#727">727</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#729">729</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#730">730</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#731">731</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#733">733</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#735">735</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#736">736</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#737">737</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#738">738</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#739">739</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#741">741</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#742">742</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#745">745</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#747">747</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#748">748</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#750">750</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#751">751</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#754">754</a>.</li>
 350 <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>
 351 <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>
 352 <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>
 353 <li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#546">546</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#564">564</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#565">565</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#573">573</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#585">585</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#588">588</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#632">632</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#635">635</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#659">659</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#670">670</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#707">707</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#708">708</a>.</li>
 354 <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>
 355 <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>
 356 <li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#561">561</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#562">562</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#563">563</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#567">567</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#595">595</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#676">676</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#706">706</a>.</li>
 357 <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>
 358 <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>
 359 <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>
 360 <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>
 361 <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>
 362 </ul></li>
 363 </ul>
 364 </li>
 365 <li>R51:
 366 2007-09-09 pre-Kona mailing.
 367 <ul>
 368 <li><b>Summary:</b><ul>
 369 <li>168 open issues, up by 15.</li>
 370 <li>555 closed issues, up by 0.</li>
 371 <li>723 issues total, up by 15.</li>
 372 </ul></li>
 373 <li><b>Details:</b><ul>
 374 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#709">709</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#712">712</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#714">714</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#716">716</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#717">717</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#718">718</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#719">719</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#721">721</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#723">723</a>.</li>
 375 </ul></li>
 376 </ul>
 377 </li>
 378 <li>R50:
 379 2007-08-05 post-Toronto mailing.
 380 <ul>
 381 <li><b>Summary:</b><ul>
 382 <li>153 open issues, down by 5.</li>
 383 <li>555 closed issues, up by 17.</li>
 384 <li>708 issues total, up by 12.</li>
 385 </ul></li>
 386 <li><b>Details:</b><ul>
 387 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#697">697</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#698">698</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#699">699</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#701">701</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#702">702</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#706">706</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#707">707</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#708">708</a>.</li>
 388 <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>
 389 <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>
 390 <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>
 391 <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>
 392 <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>
 393 <li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#579">579</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>.</li>
 394 <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>
 395 <li>Changed the following issues from Ready to Pending WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#644">644</a>.</li>
 396 <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>
 397 <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>
 398 <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>
 399 <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>
 400 <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>
 401 <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>
 402 </ul></li>
 403 </ul>
 404 </li>
 405 <li>R49:
 406 2007-06-23 pre-Toronto mailing.
 407 <ul>
 408 <li><b>Summary:</b><ul>
 409 <li>158 open issues, up by 13.</li>
 410 <li>538 closed issues, up by 7.</li>
 411 <li>696 issues total, up by 20.</li>
 412 </ul></li>
 413 <li><b>Details:</b><ul>
 414 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#678">678</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#681">681</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#682">682</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#684">684</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#690">690</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#696">696</a>.</li>
 415 <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>
 416 <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>
 417 <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>
 418 <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>
 419 </ul></li>
 420 </ul>
 421 </li>
 422 <li>R48:
 423 2007-05-06 post-Oxford mailing.
 424 <ul>
 425 <li><b>Summary:</b><ul>
 426 <li>145 open issues, down by 33.</li>
 427 <li>531 closed issues, up by 53.</li>
 428 <li>676 issues total, up by 20.</li>
 429 </ul></li>
 430 <li><b>Details:</b><ul>
 431 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#657">657</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#658">658</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#659">659</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#660">660</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#662">662</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#663">663</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#670">670</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#676">676</a>.</li>
 432 <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>
 433 <li>Changed the following issues from Tentatively Ready to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#385">385</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#466">466</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#470">470</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#547">547</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#560">560</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>.</li>
 434 <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>
 435 <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>
 436 <li>Changed the following issues from NAD_Future to NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#77">77</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#105">105</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#111">111</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#116">116</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#128">128</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#149">149</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#188">188</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#190">190</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#219">219</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#353">353</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#388">388</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#390">390</a>.</li>
 437 <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>
 438 <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>
 439 <li>Changed the following issues from Tentatively Ready to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#553">553</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#571">571</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#591">591</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#594">594</a>.</li>
 440 <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>
 441 <li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#566">566</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#640">640</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#643">643</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#644">644</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#646">646</a>.</li>
 442 <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>
 443 <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>
 444 <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>
 445 <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>
 446 </ul></li>
 447 </ul>
 448 </li>
 449 <li>R47:
 450 2007-03-09 pre-Oxford mailing.
 451 <ul>
 452 <li><b>Summary:</b><ul>
 453 <li>178 open issues, up by 37.</li>
 454 <li>478 closed issues, up by 0.</li>
 455 <li>656 issues total, up by 37.</li>
 456 </ul></li>
 457 <li><b>Details:</b><ul>
 458 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#632">632</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#633">633</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#634">634</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#635">635</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#636">636</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#637">637</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#639">639</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#640">640</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#641">641</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#642">642</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#643">643</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#644">644</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#646">646</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#647">647</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#648">648</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#649">649</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#650">650</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#651">651</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#652">652</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#656">656</a>.</li>
 459 <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>
 460 <li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#570">570</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#580">580</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#582">582</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#590">590</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#614">614</a>.</li>
 461 <li>Changed the following issues from New to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#547">547</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#553">553</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#560">560</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#571">571</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#575">575</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#576">576</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#578">578</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#586">586</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#589">589</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#591">591</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#593">593</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#594">594</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#609">609</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#610">610</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#611">611</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#613">613</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#615">615</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#616">616</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#619">619</a>.</li>
 462 <li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#201">201</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#206">206</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#254">254</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#258">258</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#385">385</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#416">416</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#422">422</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#456">456</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#466">466</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#470">470</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#482">482</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>.</li>
 463 <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>
 464 </ul></li>
 465 </ul>
 466 </li>
 467 <li>R46:
 468 2007-01-12 mid-term mailing.
 469 <ul>
 470 <li><b>Summary:</b><ul>
 471 <li>141 open issues, up by 11.</li>
 472 <li>478 closed issues, down by 1.</li>
 473 <li>619 issues total, up by 10.</li>
 474 </ul></li>
 475 <li><b>Details:</b><ul>
 476 <li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#610">610</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#611">611</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#613">613</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#614">614</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#615">615</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#616">616</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#617">617</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#619">619</a>.</li>
 477 </ul></li>
 478 </ul>
 479 </li>
 480 <li>R45:
 481 2006-11-03 post-Portland mailing.
 482 <ul>
 483 <li><b>Summary:</b><ul>
 484 <li>130 open issues, up by 0.</li>
 485 <li>479 closed issues, up by 17.</li>
 486 <li>609 issues total, up by 17.</li>
 487 </ul></li>
 488 <li><b>Details:</b><ul>
 489 <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>
 490 <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>
 491 <li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#569">569</a> to Dup.</li>
 492 <li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#523">523</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#524">524</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#556">556</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#597">597</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#606">606</a> to Open.</li>
 493 <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>
 494 <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>
 495 <li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#593">593</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#594">594</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#595">595</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#597">597</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#598">598</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#599">599</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#600">600</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#601">601</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#602">602</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#603">603</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#604">604</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#605">605</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#606">606</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#607">607</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#608">608</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#609">609</a>.</li>
 496 </ul></li>
 497 </ul>
 498 </li>
 499 <li>R44:
 500 2006-09-08 pre-Portland mailing.
 501 <ul>
 502 <li><b>Summary:</b><ul>
 503 <li>130 open issues, up by 6.</li>
 504 <li>462 closed issues, down by 1.</li>
 505 <li>592 issues total, up by 5.</li>
 506 </ul></li>
 507 <li><b>Details:</b><ul>
 508 <li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#583">583</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#584">584</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#585">585</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#586">586</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#587">587</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#588">588</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#589">589</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#590">590</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#591">591</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#592">592</a>.</li>
 509 </ul></li>
 510 </ul>
 511 </li>
 512 <li>R43:
 513 2006-06-23 mid-term mailing.
 514 <ul>
 515 <li><b>Summary:</b><ul>
 516 <li>124 open issues, up by 14.</li>
 517 <li>463 closed issues, down by 1.</li>
 518 <li>587 issues total, up by 13.</li>
 519 </ul></li>
 520 <li><b>Details:</b><ul>
 521 <li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#575">575</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#576">576</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#577">577</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#578">578</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#579">579</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#580">580</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#582">582</a>.</li>
 522 <li>Reopened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#255">255</a>.</li>
 523 <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>
 524 </ul></li>
 525 </ul>
 526 </li>
 527 <li>R42:
 528 2006-04-21 post-Berlin mailing.
 529 <ul>
 530 <li><b>Summary:</b><ul>
 531 <li>110 open issues, down by 16.</li>
 532 <li>464 closed issues, up by 24.</li>
 533 <li>574 issues total, up by 8.</li>
 534 </ul></li>
 535 <li><b>Details:</b><ul>
 536 <li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#567">567</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#568">568</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#569">569</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#570">570</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#571">571</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>.</li>
 537 <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>
 538 <li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#502">502</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#503">503</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#516">516</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#525">525</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#528">528</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#529">529</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#548">548</a> to Open.</li>
 539 <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>
 540 <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>
 541 <li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a> to Review.</li>
 542 </ul></li>
 543 </ul>
 544 </li>
 545 <li>R41:
 546 2006-02-24 pre-Berlin mailing.
 547 <ul>
 548 <li><b>Summary:</b><ul>
 549 <li>126 open issues, up by 31.</li>
 550 <li>440 closed issues, up by 0.</li>
 551 <li>566 issues total, up by 31.</li>
 552 </ul></li>
 553 <li><b>Details:</b><ul>
 554 <li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#537">537</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#538">538</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#540">540</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#541">541</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#543">543</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#544">544</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#545">545</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#546">546</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#547">547</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#548">548</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a> ,<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#551">551</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#552">552</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#553">553</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#554">554</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#555">555</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#556">556</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#558">558</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#560">560</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#561">561</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#562">562</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#563">563</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#564">564</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#565">565</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#566">566</a>.</li>
 555 <li>Moved <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#342">342</a> from Ready to Open.</li>
 556 <li>Reopened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#309">309</a>.</li>
 557 </ul></li>
 558 </ul>
 559 </li>
 560 <li>R40:
 561 2005-12-16 mid-term mailing.
 562 <ul>
 563 <li><b>Summary:</b><ul>
 564 <li>95 open issues.</li>
 565 <li>440 closed issues.</li>
 566 <li>535 issues total.</li>
 567 </ul></li>
 568 <li><b>Details:</b><ul>
 569 <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>
 570 </ul></li>
 571 </ul>
 572 </li>
 573 <li>R39:
 574 2005-10-14 post-Mont Tremblant mailing.
 575 Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#528">528</a>.
 576 Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#280">280</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#461">461</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#464">464</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#465">465</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#467">467</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#468">468</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#474">474</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#496">496</a> from Ready to WP as per the vote from Mont Tremblant.
 577 Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#247">247</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#294">294</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#342">342</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#362">362</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#369">369</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#371">371</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#376">376</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#475">475</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#495">495</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#497">497</a> from Review to Ready.
 578 Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#498">498</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#506">506</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#509">509</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#510">510</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#511">511</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#513">513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#514">514</a> from New to Open.
 579 Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#505">505</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#507">507</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#508">508</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#519">519</a> from New to Ready.
 580 Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#500">500</a> from New to NAD.
 581 Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a> from New to Review.
 582 </li>
 583 <li>R38:
 584 2005-07-03 pre-Mont Tremblant mailing.
 585 Merged open TR1 issues in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#522">522</a>.
 586 Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#523">523</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#523">523</a>
 587 </li>
 588 <li>R37:
 589 2005-06 mid-term mailing.
 590 Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#498">498</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#503">503</a>.
 591 </li>
 592 <li>R36:
 593 2005-04 post-Lillehammer mailing. All issues in "ready" status except
 594 for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#454">454</a> were moved to "DR" status, and all issues
 595 previously in "DR" status were moved to "WP".
 596 </li>
 597 <li>R35:
 598 2005-03 pre-Lillehammer mailing.
 599 </li>
 600 <li>R34:
 601 2005-01 mid-term mailing.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#488">488</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#494">494</a>.
 602 </li>
 603 <li>R33:
 604 2004-11 post-Redmond mailing. Reflects actions taken in Redmond.
 605 </li>
 606 <li>R32:
 607 2004-09 pre-Redmond mailing: reflects new proposed resolutions and
 608 new issues received after the 2004-07 mailing.  Added
 609 new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#481">481</a>.
 610 </li>
 611 <li>R31:
 612 2004-07 mid-term mailing: reflects new proposed resolutions and
 613 new issues received after the post-Sydney mailing.  Added
 614 new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>.
 615 </li>
 616 <li>R30:
 617 Post-Sydney mailing: reflects decisions made at the Sydney meeting.
 618 Voted all "Ready" issues from R29 into the working paper.
 619 Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#460">460</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#462">462</a>.
 620 </li>
 621 <li>R29:
 622 Pre-Sydney mailing.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#441">441</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#457">457</a>.
 623 </li>
 624 <li>R28:
 625 Post-Kona mailing: reflects decisions made at the Kona meeting.
 626 Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#432">432</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#440">440</a>.
 627 </li>
 628 <li>R27:
 629 Pre-Kona mailing.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#404">404</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#431">431</a>.
 630 </li>
 631 <li>R26:
 632 Post-Oxford mailing: reflects decisions made at the Oxford meeting.
 633 All issues in Ready status were voted into DR status.  All issues in
 634 DR status were voted into WP status.
 635 </li>
 636 <li>R25:
 637 Pre-Oxford mailing.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#390">390</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#402">402</a>.
 638 </li>
 639 <li>R24:
 640 Post-Santa Cruz mailing: reflects decisions made at the Santa Cruz
 641 meeting.  All Ready issues from R23 with the exception of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#253">253</a>, which has been given a new proposed resolution, were
 642 moved to DR status.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#383">383</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a>.  (Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#387">387</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a> were discussed
 643 at the meeting.)  Made progress on issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a>: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a> have been moved to Ready status, and the only remaining
 644 concerns with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a> involve wording.
 645 </li>
 646 <li>R23:
 647 Pre-Santa Cruz mailing.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#367">367</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#382">382</a>.
 648 Moved issues in the TC to TC status.
 649 </li>
 650 <li>R22:
 651 Post-Curaçao mailing.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#362">362</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#366">366</a>.
 652 </li>
 653 <li>R21:
 654 Pre-Curaçao mailing.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#351">351</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#361">361</a>.
 655 </li>
 656 <li>R20:
 657 Post-Redmond mailing; reflects actions taken in Redmond.  Added
 658 new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#336">336</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a>, of which issues
 659 <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
 660 not discussed at the meeting.
 661
 662 All Ready issues were moved to DR status, with the exception of issues
 663 <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>.
 664
 665 Noteworthy issues discussed at Redmond include
 666 <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>,
 667 <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>.
 668 </li>
 669 <li>R19:
 670 Pre-Redmond mailing.  Added new issues
 671 <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>.
 672 </li>
 673 <li>R18:
 674 Post-Copenhagen mailing; reflects actions taken in Copenhagen.
 675 Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#312">312</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#317">317</a>, and discussed
 676 new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#271">271</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#314">314</a>.
 677
 678 Changed status of issues
 679 <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>
 680 <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>
 681 <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>
 682 <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>
 683 <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>
 684 <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>
 685 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#268">268</a>
 686 to DR.
 687
 688 Changed status of issues
 689 <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>
 690 <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>
 691 <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>
 692 <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>
 693 <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>
 694 <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>
 695 <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>
 696 <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>
 697 <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>
 698 to Ready.
 699
 700 Closed issues
 701 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#111">111</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#277">277</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#279">279</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#287">287</a>
 702 <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>
 703 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#314">314</a>
 704 as NAD.
 705
 706 </li>
 707 <li>R17:
 708 Pre-Copenhagen mailing.  Converted issues list to XML.  Added proposed
 709 resolutions for issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#49">49</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#76">76</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#91">91</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#235">235</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#250">250</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#267">267</a>.
 710 Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#278">278</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#311">311</a>.
 711 </li>
 712 <li>R16:
 713 post-Toronto mailing; reflects actions taken in Toronto. Added new
 714 issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#265">265</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#277">277</a>.  Changed status of issues
 715 <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>,
 716 <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>,
 717 <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>,
 718 <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>,
 719 <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>,
 720 <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>,
 721 <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>,
 722 <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>,
 723 <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>,
 724 <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>,
 725 <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>,
 726 <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>,
 727 <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
 728 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#187">187</a>. Changed issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#2">2</a> and
 729 <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
 730 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#70">70</a>: signature should be changed both places it
 731 appears. Fixed issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#160">160</a>: previous version didn't fix
 732 the bug in enough places.
 733 </li>
 734 <li>R15:
 735 pre-Toronto mailing. Added issues
 736 <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
 737 changes so that we pass Weblint tests.
 738 </li>
 739 <li>R14:
 740 post-Tokyo II mailing; reflects committee actions taken in
 741 Tokyo. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#228">228</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#232">232</a>. (00-0019R1/N1242)
 742 </li>
 743 <li>R13:
 744 pre-Tokyo II updated: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#212">212</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#227">227</a>.
 745 </li>
 746 <li>R12:
 747 pre-Tokyo II mailing: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#199">199</a> to
 748 <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
 749 of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#29">29</a>.  Add further rationale to issue
 750 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#178">178</a>.
 751 </li>
 752 <li>R11:
 753 post-Kona mailing: Updated to reflect LWG and full committee actions
 754 in Kona (99-0048/N1224). Note changed resolution of issues
 755 <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>
 756 to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#198">198</a>. Closed issues list split into "defects" and
 757 "closed" documents.  Changed the proposed resolution of issue
 758 <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
 759 of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#38">38</a>.
 760 </li>
 761 <li>R10:
 762 pre-Kona updated.  Added proposed resolutions <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>,
 763 <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>,
 764 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#109">109</a>. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#190">190</a> to
 765 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a>. (99-0033/D1209, 14 Oct 99)
 766 </li>
 767 <li>R9:
 768 pre-Kona mailing.  Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a> to
 769 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#189">189</a>. Issues list split into separate "active" and
 770 "closed" documents. (99-0030/N1206, 25 Aug 99)
 771 </li>
 772 <li>R8:
 773 post-Dublin mailing. Updated to reflect LWG and full committee actions
 774 in Dublin. (99-0016/N1193, 21 Apr 99)
 775 </li>
 776 <li>R7:
 777 pre-Dublin updated: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#130">130</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#131">131</a>,
 778 <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>,
 779 <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>,
 780 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#139">139</a> (31 Mar 99)
 781 </li>
 782 <li>R6:
 783 pre-Dublin mailing. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#127">127</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#128">128</a>,
 784 and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#129">129</a>.  (99-0007/N1194, 22 Feb 99)
 785 </li>
 786 <li>R5:
 787 update issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#103">103</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#112">112</a>; added issues
 788 <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
 789 for making list public. (30 Dec 98)
 790 </li>
 791 <li>R4:
 792 post-Santa Cruz II updated: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#110">110</a>,
 793 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#111">111</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#112">112</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#113">113</a> added, several
 794 issues corrected. (22 Oct 98)
 795 </li>
 796 <li>R3:
 797 post-Santa Cruz II: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#94">94</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#109">109</a>
 798 added, many issues updated to reflect LWG consensus (12 Oct 98)
 799 </li>
 800 <li>R2:
 801 pre-Santa Cruz II: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#73">73</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#93">93</a> added,
 802 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#17">17</a> updated. (29 Sep 98)
 803 </li>
 804 <li>R1:
 805 Correction to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#55">55</a> resolution, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</a> code
 806 format, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64">64</a> title. (17 Sep 98)
 807 </li>
 808 </ul>
 809
 810 <h2>Closed Issues</h2>
 811 <hr>
 812 <h3><a name="2"></a>2. Auto_ptr conversions effects incorrect</h3>
 813 <p><b>Section:</b> D.9.1.3 [auto.ptr.conv] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
 814  <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1997-12-04  <b>Last modified:</b> 2006-12-29</p>
 815 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
 816 <p><b>Discussion:</b></p>
 817 <p>Paragraph 1 in "Effects", says "Calls
 818 p-&gt;release()" where it clearly must be "Calls
 819 p.release()". (As it is, it seems to require using
 820 auto_ptr&lt;&gt;::operator-&gt; to refer to X::release, assuming that
 821 exists.)</p>
 822
 823
 824 <p><b>Proposed resolution:</b></p>
 825 <p>Change 20.6.4.3 [meta.unary.prop] paragraph 1 Effects from
 826 "Calls p-&gt;release()" to "Calls p.release()".</p>
 827
 828
 829 <p><b>Rationale:</b></p>
 830 <p>Not a defect: the proposed change is already found in the standard.
 831 [Originally classified as a defect, later reclassified.]</p>
 832
 833
 834
 835
 836
 837 <hr>
 838 <h3><a name="4"></a>4. Basic_string size_type and difference_type should be implementation defined</h3>
 839 <p><b>Section:</b> 21.4 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
 840  <b>Submitter:</b> Beman Dawes <b>Opened:</b> 1997-11-16  <b>Last modified:</b> 2006-12-27</p>
 841 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.string">active issues</a> in [basic.string].</p>
 842 <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>
 843 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
 844 <p><b>Discussion:</b></p>
 845 <p>In Morristown we changed the size_type and difference_type typedefs
 846 for all the other containers to implementation defined with a
 847 reference to 23.2 [container.requirements].  This should probably also have been
 848 done for strings. </p>
 849
 850
 851 <p><b>Rationale:</b></p>
 852 <p>Not a defect.  [Originally classified as a defect, later
 853 reclassified.]  basic_string, unlike the other standard library
 854 template containers, is severely constrained by its use of
 855 char_traits. Those types are dictated by the traits class, and are far
 856 from implementation defined.</p>
 857
 858
 859
 860
 861
 862 <hr>
 863 <h3><a name="6"></a>6. File position not an offset unimplementable</h3>
 864 <p><b>Section:</b> 27.5.3 [fpos] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
 865  <b>Submitter:</b> Matt Austern <b>Opened:</b> 1997-12-15  <b>Last modified:</b> 2006-12-27</p>
 866 <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>
 867 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
 868 <p><b>Discussion:</b></p>
 869 <p>Table 88, in I/O, is too strict; it's unimplementable on systems
 870 where a file position isn't just an offset. It also never says just
 871 what fpos&lt;&gt; is really supposed to be.  [Here's my summary, which
 872 Jerry agrees is more or less accurate. "I think I now know what
 873 the class really is, at this point: it's a magic cookie that
 874 encapsulates an mbstate_t and a file position (possibly represented as
 875 an fpos_t), it has syntactic support for pointer-like arithmetic, and
 876 implementors are required to have real, not just syntactic, support
 877 for arithmetic." This isn't standardese, of course.] </p>
 878
 879
 880 <p><b>Rationale:</b></p>
 881 <p>Not a defect. The LWG believes that the Standard is already clear,
 882 and that the above summary is what the Standard in effect says.</p>
 883
 884
 885
 886
 887
 888 <hr>
 889 <h3><a name="10"></a>10. Codecvt&lt;&gt;::do unclear</h3>
 890 <p><b>Section:</b> 22.4.1.5 [locale.codecvt.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
 891  <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-01-14  <b>Last modified:</b> 2006-12-30</p>
 892 <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>
 893 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
 894 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#19">19</a></p>
 895 <p><b>Discussion:</b></p>
 896 <p>Section 22.2.1.5.2 says that codecvt&lt;&gt;::do_in and do_out
 897 should return the value noconv if "no conversion was
 898 needed". However, I don't see anything anywhere that defines what
 899 it means for a conversion to be needed or not needed. I can think of
 900 several circumstances where one might plausibly think that a
 901 conversion is not "needed", but I don't know which one is
 902 intended here. </p>
 903
 904
 905 <p><b>Rationale:</b></p>
 906
 907
 908
 909
 910
 911
 912 <hr>
 913 <h3><a name="12"></a>12. Way objects hold allocators unclear</h3>
 914 <p><b>Section:</b> X [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
 915  <b>Submitter:</b> Angelika Langer <b>Opened:</b> 1998-02-23  <b>Last modified:</b> 2006-12-30</p>
 916 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p>
 917 <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>
 918 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
 919 <p><b>Discussion:</b></p>
 920 <p>I couldn't find a statement in the standard saying whether the allocator object held by
 921 a container is held as a copy of the constructor argument or whether a pointer of
 922 reference is maintained internal. There is an according statement for compare objects and
 923 how they are maintained by the associative containers, but I couldn't find anything
 924 regarding allocators. </p>
 925
 926 <p>Did I overlook it? Is it an open issue or known defect? Or is it deliberately left
 927 unspecified? </p>
 928
 929
 930 <p><b>Rationale:</b></p>
 931 <p>Not a defect. The LWG believes that the Standard is already
 932 clear.&nbsp; See 23.2 [container.requirements], paragraph 8.</p>
 933
 934
 935
 936
 937
 938 <hr>
 939 <h3><a name="43"></a>43. Locale table correction</h3>
 940 <p><b>Section:</b> 22.4.1.5 [locale.codecvt.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
 941  <b>Submitter:</b> Brendan Kehoe <b>Opened:</b> 1998-06-01  <b>Last modified:</b> 2006-12-30</p>
 942 <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>
 943 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
 944 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#33">33</a></p>
 945 <p><b>Discussion:</b></p>
 946
 947
 948 <p><b>Rationale:</b></p>
 949
 950
 951
 952
 953
 954
 955 <hr>
 956 <h3><a name="45"></a>45. Stringstreams read/write pointers initial position unclear</h3>
 957 <p><b>Section:</b> 27.8.3 [ostringstream] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
 958  <b>Submitter:</b> Matthias Mueller <b>Opened:</b> 1998-05-27  <b>Last modified:</b> 2006-12-27</p>
 959 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
 960 <p><b>Discussion:</b></p>
 961 <p>In a comp.lang.c++.moderated Matthias Mueller wrote:</p>
 962
 963 <p>"We are not sure how to interpret the CD2 (see 27.3
 964 [iostream.forward], 27.8.3.1 [ostringstream.cons], 27.8.1.1
 965 [stringbuf.cons])
 966 with respect to the question as to what the correct initial positions
 967 of the write and&nbsp; read pointers of a stringstream should
 968 be."</p>
 969
 970 <p>"Is it the same to output two strings or to initialize the stringstream with the
 971 first and to output the second?"</p>
 972
 973 <p><i>[PJ Plauger, Bjarne Stroustrup, Randy Smithey, Sean Corfield, and
 974 Jerry Schwarz have all offered opinions; see reflector messages
 975 lib-6518, 6519, 6520, 6521, 6523, 6524.]</i></p>
 976
 977
 978
 979
 980 <p><b>Rationale:</b></p>
 981 <p>The LWG believes the Standard is correct as written. The behavior
 982 of stringstreams is consistent with fstreams, and there is a
 983 constructor which can be used to obtain the desired effect. This
 984 behavior is known to be different from strstreams.</p>
 985
 986
 987
 988
 989
 990 <hr>
 991 <h3><a name="58"></a>58. Extracting a char from a wide-oriented stream</h3>
 992 <p><b>Section:</b> 27.7.1.2.3 [istream::extractors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
 993  <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-07-01  <b>Last modified:</b> 2006-12-27</p>
 994 <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>
 995 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
 996 <p><b>Discussion:</b></p>
 997 <p>27.6.1.2.3 has member functions for extraction of signed char and
 998 unsigned char, both singly and as strings. However, it doesn't say
 999 what it means to extract a <tt>char</tt> from a
1000 <tt>basic_streambuf&lt;charT, Traits&gt;</tt>. </p>
1001
1002 <p>basic_streambuf, after all, has no members to extract a char, so
1003 basic_istream must somehow convert from charT to signed char or
1004 unsigned char. The standard doesn't say how it is to perform that
1005 conversion. </p>
1006
1007
1008 <p><b>Rationale:</b></p>
1009 <p>The Standard is correct as written.  There is no such extractor and
1010 this is the intent of the LWG.</p>
1011
1012
1013
1014
1015 <hr>
1016 <h3><a name="65"></a>65. Underspecification of strstreambuf::seekoff</h3>
1017 <p><b>Section:</b> D.7.1.3 [depr.strstreambuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1018  <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-08-18  <b>Last modified:</b> 2006-12-27</p>
1019 <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>
1020 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1021 <p><b>Discussion:</b></p>
1022 <p>The standard says how this member function affects the current
1023 stream position. (<tt>gptr</tt> or <tt>pptr</tt>) However, it does not
1024 say how this member function affects the beginning and end of the
1025 get/put area. </p>
1026
1027 <p>This is an issue when seekoff is used to position the get pointer
1028 beyond the end of the current read area. (Which is legal. This is
1029 implicit in the definition of <i>seekhigh</i> in D.7.1, paragraph 4.)
1030 </p>
1031
1032
1033 <p><b>Rationale:</b></p>
1034 <p>The LWG agrees that seekoff() is underspecified, but does not wish
1035 to invest effort in this deprecated feature.</p>
1036
1037
1038
1039
1040
1041 <hr>
1042 <h3><a name="67"></a>67. Setw useless for strings</h3>
1043 <p><b>Section:</b> 21.4.8.9 [string.io] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
1044  <b>Submitter:</b> Steve Clamage <b>Opened:</b> 1998-07-09  <b>Last modified:</b> 2006-12-30</p>
1045 <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>
1046 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
1047 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#25">25</a></p>
1048 <p><b>Discussion:</b></p>
1049 <p>In a comp.std.c++ posting Michel Michaud wrote: What
1050 should be output by: </p>
1051
1052 <pre>   string text("Hello");
1053    cout &lt;&lt; '[' &lt;&lt; setw(10) &lt;&lt; right &lt;&lt; text &lt;&lt; ']';
1054 </pre>
1055
1056 <p>Shouldn't it be:</p>
1057
1058 <pre>   [     Hello]</pre>
1059
1060 <p>Another person replied: Actually, according to the FDIS, the width
1061 of the field should be the minimum of width and the length of the
1062 string, so the output shouldn't have any padding. I think that this is
1063 a typo, however, and that what is wanted is the maximum of the
1064 two. (As written, setw is useless for strings. If that had been the
1065 intent, one wouldn't expect them to have mentioned using its value.)
1066 </p>
1067
1068 <p>It's worth pointing out that this is a recent correction anyway;
1069 IIRC, earlier versions of the draft forgot to mention formatting
1070 parameters whatsoever.</p>
1071
1072
1073 <p><b>Rationale:</b></p>
1074
1075
1076
1077
1078
1079
1080 <hr>
1081 <h3><a name="72"></a>72. Do_convert phantom member function</h3>
1082 <p><b>Section:</b> 22.4.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
1083  <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-24  <b>Last modified:</b> 2006-12-30</p>
1084 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.codecvt">active issues</a> in [locale.codecvt].</p>
1085 <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>
1086 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
1087 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#24">24</a></p>
1088 <p><b>Discussion:</b></p>
1089 <p>In 22.4.1.4 [locale.codecvt] par 3, and in 22.4.1.4.2 [locale.codecvt.virtuals] par 8, a nonexistent member function
1090 "do_convert" is mentioned. This member was replaced with
1091 "do_in" and "do_out", the proper referents in the
1092 contexts above.</p>
1093
1094
1095 <p><b>Rationale:</b></p>
1096
1097
1098
1099
1100
1101 <hr>
1102 <h3><a name="73"></a>73. <tt>is_open</tt> should be const</h3>
1103 <p><b>Section:</b> 27.9.1 [fstreams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1104  <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-08-27  <b>Last modified:</b> 2006-12-27</p>
1105 <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>
1106 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1107 <p><b>Discussion:</b></p>
1108 <p>Classes <tt>basic_ifstream</tt>, <tt>basic_ofstream</tt>, and
1109 <tt>basic_fstream</tt> all have a member function <tt>is_open</tt>. It
1110 should be a <tt>const</tt> member function, since it does nothing but
1111 call one of <tt>basic_filebuf</tt>'s const member functions. </p>
1112
1113
1114 <p><b>Rationale:</b></p>
1115 <p>Not a defect. This is a deliberate feature; const streams would be
1116 meaningless.</p>
1117
1118
1119
1120
1121 <hr>
1122 <h3><a name="77"></a>77. Valarray operator[] const returning value</h3>
1123 <p><b>Section:</b> 26.6.2.3 [valarray.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
1124  <b>Submitter:</b> Levente Farkas <b>Opened:</b> 1998-09-09  <b>Last modified:</b> 2007-10-11</p>
1125 <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>
1126 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
1127 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a></p>
1128 <p><b>Discussion:</b></p>
1129 <p>valarray:<br>
1130 <br>
1131 &nbsp;&nbsp;&nbsp; <tt>T operator[] (size_t) const;</tt><br>
1132 <br>
1133 why not <br>
1134 <br>
1135 &nbsp;&nbsp;&nbsp; <tt>const T&amp; operator[] (size_t) const;</tt><br>
1136 <br>
1137 as in vector ???<br>
1138 <br>
1139 One can't copy even from a const valarray eg:<br>
1140 <br>
1141 &nbsp;&nbsp;&nbsp; <tt>memcpy(ptr, &amp;v[0], v.size() * sizeof(double));<br>
1142 </tt><br>
1143 [I] find this bug in valarray is very difficult.</p>
1144
1145
1146 <p><b>Rationale:</b></p>
1147 <p>The LWG believes that the interface was deliberately designed that
1148 way. That is what valarray was designed to do; that's where the
1149 "value array" name comes from. LWG members further comment
1150 that "we don't want valarray to be a full STL container."
1151 26.6.2.3 [valarray.access] specifies properties that indicate "an
1152 absence of aliasing" for non-constant arrays; this allows
1153 optimizations, including special hardware optimizations, that are not
1154 otherwise possible. </p>
1155
1156
1157
1158
1159
1160 <hr>
1161 <h3><a name="81"></a>81. Wrong declaration of slice operations</h3>
1162 <p><b>Section:</b> 26.6.5 [template.slice.array], 26.6.7 [template.gslice.array], 26.6.8 [template.mask.array], 26.6.9 [template.indirect.array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1163  <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29  <b>Last modified:</b> 2006-12-29</p>
1164 <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>
1165 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1166 <p><b>Discussion:</b></p>
1167 <p>Isn't the definition of copy constructor and assignment operators wrong?
1168 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Instead of</p>
1169
1170 <pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; slice_array(const slice_array&amp;);
1171 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; slice_array&amp; operator=(const slice_array&amp;);</pre>
1172
1173 <p>IMHO they have to be</p>
1174
1175 <pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;slice_array(const slice_array&lt;T&gt;&amp;);
1176 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;slice_array&amp; operator=(const slice_array&lt;T&gt;&amp;);</pre>
1177
1178 <p>Same for gslice_array. </p>
1179
1180
1181 <p><b>Rationale:</b></p>
1182 <p>Not a defect. The Standard is correct as written. </p>
1183
1184
1185
1186
1187 <hr>
1188 <h3><a name="82"></a>82. Missing constant for set elements</h3>
1189 <p><b>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1190  <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29  <b>Last modified:</b> 2007-01-15</p>
1191 <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>
1192 <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>
1193 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1194 <p><b>Discussion:</b></p>
1195 <p>Paragraph 5 specifies:</p>
1196
1197 <blockquote><p>
1198 For set and multiset the value type is the same as the key type. For
1199 map and multimap it is equal to pair&lt;const Key, T&gt;.
1200 </p></blockquote>
1201
1202 <p>Strictly speaking, this is not correct because for set and multiset
1203 the value type is the same as the <b>constant</b> key type.</p>
1204
1205
1206 <p><b>Rationale:</b></p>
1207 <p>Not a defect. The Standard is correct as written; it uses a
1208 different mechanism (const &amp;) for <tt>set</tt> and
1209 <tt>multiset</tt>. See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#103">103</a> for a related
1210 issue.</p>
1211
1212
1213
1214
1215 <hr>
1216 <h3><a name="84"></a>84. Ambiguity with string::insert()</h3>
1217 <p><b>Section:</b> 21.4.5 [string.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1218  <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29  <b>Last modified:</b> 2006-12-27</p>
1219 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1220 <p><b>Discussion:</b></p>
1221 <p>If I try</p>
1222 <pre>    s.insert(0,1,' ');</pre>
1223
1224 <p>&nbsp; I get an nasty ambiguity. It might be</p>
1225 <pre>    s.insert((size_type)0,(size_type)1,(charT)' ');</pre>
1226
1227 <p>which inserts 1 space character at position 0, or</p>
1228 <pre>    s.insert((char*)0,(size_type)1,(charT)' ')</pre>
1229
1230 <p>which inserts 1 space character at iterator/address 0 (bingo!), or</p>
1231 <pre>    s.insert((char*)0, (InputIterator)1, (InputIterator)' ')</pre>
1232
1233 <p>which normally inserts characters from iterator 1 to iterator '
1234 '. But according to 23.1.1.9 (the "do the right thing" fix)
1235 it is equivalent to the second. However, it is still ambiguous,
1236 because of course I mean the first!</p>
1237
1238
1239 <p><b>Rationale:</b></p>
1240 <p>Not a defect. The LWG believes this is a "genetic
1241 misfortune" inherent in the design of string and thus not a
1242 defect in the Standard as such .</p>
1243
1244
1245
1246
1247 <hr>
1248 <h3><a name="85"></a>85. String char types</h3>
1249 <p><b>Section:</b> 21 [strings] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1250  <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29  <b>Last modified:</b> 2006-12-27</p>
1251 <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>
1252 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1253 <p><b>Discussion:</b></p>
1254 <p>The standard seems not to require that charT is equivalent to
1255 traits::char_type. So, what happens if charT is not equivalent to
1256 traits::char_type?</p>
1257
1258
1259 <p><b>Rationale:</b></p>
1260 <p>There is already wording in 21.2 [char.traits] paragraph 3 that
1261 requires them to be the same.</p>
1262
1263
1264
1265
1266 <hr>
1267 <h3><a name="87"></a>87. Error in description of string::compare()</h3>
1268 <p><b>Section:</b> 21.4.6.8 [string::swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
1269  <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29  <b>Last modified:</b> 2006-12-30</p>
1270 <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>
1271 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
1272 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#5">5</a></p>
1273 <p><b>Discussion:</b></p>
1274 <p>The following compare() description is obviously a bug:</p>
1275
1276 <pre>int compare(size_type pos, size_type n1,
1277             charT *s, size_type n2 = npos) const;
1278 </pre>
1279
1280 <p>because without passing n2 it should compare up to the end of the
1281 string instead of comparing npos characters (which throws an
1282 exception) </p>
1283
1284
1285 <p><b>Rationale:</b></p>
1286
1287
1288
1289
1290
1291 <hr>
1292 <h3><a name="88"></a>88. Inconsistency between string::insert() and string::append()</h3>
1293 <p><b>Section:</b> 21.4.6.4 [string::insert], 21.4.6.2 [string::append] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1294  <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29  <b>Last modified:</b> 2006-12-27</p>
1295 <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>
1296 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1297 <p><b>Discussion:</b></p>
1298 <p>Why does </p>
1299 <pre>  template&lt;class InputIterator&gt;
1300        basic_string&amp; append(InputIterator first, InputIterator last);</pre>
1301
1302 <p>return a string, while</p>
1303 <pre>  template&lt;class InputIterator&gt;
1304        void insert(iterator p, InputIterator first, InputIterator last);</pre>
1305
1306 <p>returns nothing ?</p>
1307
1308
1309 <p><b>Rationale:</b></p>
1310 <p>The LWG believes this stylistic inconsistency is not sufficiently
1311 serious to constitute a defect.</p>
1312
1313
1314
1315
1316 <hr>
1317 <h3><a name="89"></a>89. Missing throw specification for string::insert() and string::replace()</h3>
1318 <p><b>Section:</b> 21.4.6.4 [string::insert], 21.4.6.6 [string::replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
1319  <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29  <b>Last modified:</b> 2006-12-30</p>
1320 <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>
1321 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
1322 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a></p>
1323 <p><b>Discussion:</b></p>
1324 <p>All insert() and replace() members for strings with an iterator as
1325 first argument lack a throw specification. The throw
1326 specification should probably be: length_error if size exceeds
1327 maximum. </p>
1328
1329
1330 <p><b>Rationale:</b></p>
1331 <p>Considered a duplicate because it will be solved by the resolution
1332 of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>.</p>
1333
1334
1335
1336
1337
1338 <hr>
1339 <h3><a name="93"></a>93. Incomplete Valarray Subset Definitions</h3>
1340 <p><b>Section:</b> 26.6 [numarray] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1341  <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29  <b>Last modified:</b> 2006-12-29</p>
1342 <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>
1343 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1344 <p><b>Discussion:</b></p>
1345 <p>You can easily create subsets, but you can't easily combine them
1346 with other subsets.  Unfortunately, you almost always needs an
1347 explicit type conversion to valarray. This is because the standard
1348 does not specify that valarray subsets provide the same operations as
1349 valarrays. </p>
1350
1351 <p>For example, to multiply two subsets and assign the result to a third subset, you can't
1352 write the following:</p>
1353
1354 <pre>va[slice(0,4,3)] = va[slice(1,4,3)] * va[slice(2,4,3)];</pre>
1355
1356 <p>Instead, you have to code as follows:</p>
1357
1358 <pre>va[slice(0,4,3)] = static_cast&lt;valarray&lt;double&gt; &gt;(va[slice(1,4,3)]) *
1359                    static_cast&lt;valarray&lt;double&gt; &gt;(va[slice(2,4,3)]);</pre>
1360
1361 <p>This is tedious and error-prone. Even worse, it costs performance because each cast
1362 creates a temporary objects, which could be avoided without the cast. </p>
1363
1364
1365 <p><b>Proposed resolution:</b></p>
1366 <p>Extend all valarray subset types so that they offer all valarray operations.</p>
1367
1368
1369 <p><b>Rationale:</b></p>
1370 <p>This is not a defect in the Standard; it is a request for an extension.</p>
1371
1372
1373
1374
1375 <hr>
1376 <h3><a name="94"></a>94. May library implementors add template parameters to Standard Library classes?</h3>
1377 <p><b>Section:</b> 17.6.4 [conforming] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1378  <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-01-22  <b>Last modified:</b> 2006-12-27</p>
1379 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1380 <p><b>Discussion:</b></p>
1381 <p>Is it a permitted extension for library implementors to add template parameters to
1382 standard library classes, provided that those extra parameters have defaults? For example,
1383 instead of defining <tt>template &lt;class T, class Alloc = allocator&lt;T&gt; &gt; class
1384 vector;</tt> defining it as <tt>template &lt;class T, class Alloc = allocator&lt;T&gt;,
1385 int N = 1&gt; class vector;</tt> </p>
1386
1387 <p>The standard may well already allow this (I can't think of any way that this extension
1388 could break a conforming program, considering that users are not permitted to
1389 forward-declare standard library components), but it ought to be explicitly permitted or
1390 forbidden. </p>
1391
1392 <p>comment from Steve Cleary via comp.std.c++:</p>
1393 <blockquote>
1394 <p>I disagree [with the proposed resolution] for the following reason:
1395 consider user library code with template template parameters. For
1396 example, a user library object may be templated on the type of
1397 underlying sequence storage to use (deque/list/vector), since these
1398 classes all take the same number and type of template parameters; this
1399 would allow the user to determine the performance tradeoffs of the
1400 user library object. A similar example is a user library object
1401 templated on the type of underlying set storage (set/multiset) or map
1402 storage (map/multimap), which would allow users to change (within
1403 reason) the semantic meanings of operations on that object.</p>
1404 <p>I think that additional template parameters should be forbidden in
1405 the Standard classes. Library writers don't lose any expressive power,
1406 and can still offer extensions because additional template parameters
1407 may be provided by a non-Standard implementation class:</p>
1408 <pre>
1409    template &lt;class T, class Allocator = allocator&lt;T&gt;, int N = 1&gt;
1410    class __vector
1411    { ... };
1412    template &lt;class T, class Allocator = allocator&lt;T&gt; &gt;
1413    class vector: public __vector&lt;T, Allocator&gt;
1414    { ... };
1415 </pre>
1416
1417 </blockquote>
1418
1419
1420
1421 <p><b>Proposed resolution:</b></p>
1422 <p>Add a new subclause [presumably 17.4.4.9] following 17.6.4.10 [res.on.exception.handling]:</p>
1423
1424 <blockquote>
1425   <p>17.4.4.9 Template Parameters</p> <p>A specialization of a
1426   template class described in the C++ Standard Library behaves the
1427   same as if the implementation declares no additional template
1428   parameters.</p> <p>Footnote: Additional template parameters with
1429   default values are thus permitted.</p>
1430 </blockquote>
1431
1432 <p>Add "template parameters" to the list of subclauses at
1433 the end of 17.6.4 [conforming] paragraph 1.</p>
1434
1435 <p><i>[Kona: The LWG agreed the standard needs clarification. After
1436 discussion with John Spicer, it seems added template parameters can be
1437 detected by a program using template-template parameters. A straw vote
1438 - "should implementors be allowed to add template
1439 parameters?" found no consensus ; 5 - yes, 7 - no.]</i></p>
1440
1441
1442
1443
1444 <p><b>Rationale:</b></p>
1445 <p>
1446 There is no ambiguity; the standard is clear as written.  Library
1447 implementors are not permitted to add template parameters to standard
1448 library classes.  This does not fall under the "as if" rule,
1449 so it would be permitted only if the standard gave explicit license
1450 for implementors to do this.  This would require a change in the
1451 standard.
1452 </p>
1453
1454 <p>
1455 The LWG decided against making this change, because it would break
1456 user code involving template template parameters or specializations
1457 of standard library class templates.
1458 </p>
1459
1460
1461
1462
1463
1464 <hr>
1465 <h3><a name="95"></a>95. Members added by the implementation</h3>
1466 <p><b>Section:</b> 17.6.4.5 [member.functions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1467  <b>Submitter:</b> AFNOR <b>Opened:</b> 1998-10-07  <b>Last modified:</b> 2006-12-27</p>
1468 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1469 <p><b>Discussion:</b></p>
1470 <p>In 17.3.4.4/2 vs 17.3.4.7/0 there is a hole; an implementation could add virtual
1471 members a base class and break user derived classes.</p>
1472
1473 <p>Example: </p>
1474
1475 <blockquote>
1476   <pre>// implementation code:
1477 struct _Base { // _Base is in the implementer namespace
1478         virtual void foo ();
1479 };
1480 class vector : _Base // deriving from a class is allowed
1481 { ... };
1482
1483 // user code:
1484 class vector_checking : public vector
1485 {
1486         void foo (); // don't want to override _Base::foo () as the
1487                      // user doesn't know about _Base::foo ()
1488 };</pre>
1489 </blockquote>
1490
1491
1492 <p><b>Proposed resolution:</b></p>
1493 <p>Clarify the wording to make the example illegal.</p>
1494
1495
1496 <p><b>Rationale:</b></p>
1497 <p>This is not a defect in the Standard.&nbsp; The example is already
1498 illegal.&nbsp; See 17.6.4.5 [member.functions] paragraph 2.</p>
1499
1500
1501
1502
1503 <hr>
1504 <h3><a name="97"></a>97. Insert inconsistent definition</h3>
1505 <p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1506  <b>Submitter:</b> AFNOR <b>Opened:</b> 1998-10-07  <b>Last modified:</b> 2006-12-27</p>
1507 <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>
1508 <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>
1509 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1510 <p><b>Discussion:</b></p>
1511 <p><tt>insert(iterator, const value_type&amp;)</tt> is defined both on
1512 sequences and on set, with unrelated semantics: insert here (in
1513 sequences), and insert with hint (in associative containers). They
1514 should have different names (B.S. says: do not abuse overloading).</p>
1515
1516
1517 <p><b>Rationale:</b></p>
1518 <p>This is not a defect in the Standard. It is a genetic misfortune of
1519 the design, for better or for worse.</p>
1520
1521
1522
1523
1524 <hr>
1525 <h3><a name="99"></a>99. Reverse_iterator comparisons completely wrong</h3>
1526 <p><b>Section:</b> 24.5.1.2.13 [reverse.iter.op==] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1527  <b>Submitter:</b> AFNOR <b>Opened:</b> 1998-10-07  <b>Last modified:</b> 2006-12-27</p>
1528 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1529 <p><b>Discussion:</b></p>
1530 <p>The &lt;, &gt;, &lt;=, &gt;= comparison operator are wrong: they
1531 return the opposite of what they should.</p>
1532
1533 <p>Note: same problem in CD2, these were not even defined in CD1.  SGI
1534 STL code is correct; this problem is known since the Morristown
1535 meeting but there it was too late</p>
1536
1537
1538 <p><b>Rationale:</b></p>
1539 <p>This is not a defect in the Standard. A careful reading shows the Standard is correct
1540 as written. A review of several implementations show that they implement
1541 exactly what the Standard says.</p>
1542
1543
1544
1545
1546 <hr>
1547 <h3><a name="100"></a>100. Insert iterators/ostream_iterators overconstrained</h3>
1548 <p><b>Section:</b> 24.7 [insert.iterators], 24.6.4 [ostreambuf.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1549  <b>Submitter:</b> AFNOR <b>Opened:</b> 1998-10-07  <b>Last modified:</b> 2006-12-27</p>
1550 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#insert.iterators">active issues</a> in [insert.iterators].</p>
1551 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#insert.iterators">issues</a> in [insert.iterators].</p>
1552 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1553 <p><b>Discussion:</b></p>
1554 <p>Overspecified For an insert iterator it, the expression *it is
1555 required to return a reference to it. This is a simple possible
1556 implementation, but as the SGI STL documentation says, not the only
1557 one, and the user should not assume that this is the case.</p>
1558
1559
1560 <p><b>Rationale:</b></p>
1561 <p>The LWG believes this causes no harm and is not a defect in the
1562 standard. The only example anyone could come up with caused some
1563 incorrect code to work, rather than the other way around.</p>
1564
1565
1566
1567
1568
1569 <hr>
1570 <h3><a name="101"></a>101. No way to free storage for vector and deque</h3>
1571 <p><b>Section:</b> 23.3.6 [vector], 23.3.1 [array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1572  <b>Submitter:</b> AFNOR <b>Opened:</b> 1998-10-07  <b>Last modified:</b> 2007-02-19</p>
1573 <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>
1574 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1575 <p><b>Discussion:</b></p>
1576 <p>Reserve can not free storage, unlike string::reserve</p>
1577
1578
1579 <p><b>Rationale:</b></p>
1580 <p>This is not a defect in the Standard. The LWG has considered this
1581 issue in the past and sees no need to change the Standard. Deque has
1582 no reserve() member function. For vector, shrink-to-fit can be
1583 expressed in a single line of code (where <tt>v</tt> is
1584 <tt>vector&lt;T&gt;</tt>):
1585 </p>
1586
1587 <blockquote>
1588   <p><tt>vector&lt;T&gt;(v).swap(v);&nbsp; // shrink-to-fit v</tt></p>
1589 </blockquote>
1590
1591
1592
1593
1594
1595 <hr>
1596 <h3><a name="102"></a>102. Bug in insert range in associative containers</h3>
1597 <p><b>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
1598  <b>Submitter:</b> AFNOR <b>Opened:</b> 1998-10-07  <b>Last modified:</b> 2006-12-30</p>
1599 <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>
1600 <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>
1601 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
1602 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#264">264</a></p>
1603 <p><b>Discussion:</b></p>
1604 <p>Table 69 of Containers say that a.insert(i,j) is linear if [i, j) is ordered. It seems
1605 impossible to implement, as it means that if [i, j) = [x], insert in an associative
1606 container is O(1)!</p>
1607
1608
1609 <p><b>Proposed resolution:</b></p>
1610 <p>N+log (size()) if [i,j) is sorted according to value_comp()</p>
1611
1612
1613 <p><b>Rationale:</b></p>
1614 <p>Subsumed by issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#264">264</a>.</p>
1615
1616
1617
1618
1619
1620 <hr>
1621 <h3><a name="104"></a>104. Description of basic_string::operator[] is unclear</h3>
1622 <p><b>Section:</b> 21.4.4 [string.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1623  <b>Submitter:</b> AFNOR <b>Opened:</b> 1998-10-07  <b>Last modified:</b> 2006-12-27</p>
1624 <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>
1625 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1626 <p><b>Discussion:</b></p>
1627 <p>It is not clear that undefined behavior applies when pos == size ()
1628 for the non const version.</p>
1629
1630
1631 <p><b>Proposed resolution:</b></p>
1632 <p>Rewrite as: Otherwise, if pos &gt; size () or pos == size () and
1633 the non-const version is used, then the behavior is undefined.</p>
1634
1635
1636 <p><b>Rationale:</b></p>
1637 <p>The Standard is correct. The proposed resolution already appears in
1638 the Standard.</p>
1639
1640
1641
1642
1643 <hr>
1644 <h3><a name="105"></a>105. fstream ctors argument types desired</h3>
1645 <p><b>Section:</b> 27.9 [file.streams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
1646  <b>Submitter:</b> AFNOR <b>Opened:</b> 1998-10-07  <b>Last modified:</b> 2008-01-05</p>
1647 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
1648 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#454">454</a></p>
1649 <p><b>Discussion:</b></p>
1650
1651
1652 <p>fstream ctors take a const char* instead of string.<br>
1653 fstream ctors can't take wchar_t</p>
1654
1655 <p>An extension to add a const wchar_t* to fstream would make the
1656 implementation non conforming.</p>
1657
1658
1659 <p><b>Rationale:</b></p>
1660 <p>This is not a defect in the Standard. It might be an
1661 interesting extension for the next Standard. </p>
1662
1663
1664
1665
1666 <hr>
1667 <h3><a name="107"></a>107. Valarray constructor is strange</h3>
1668 <p><b>Section:</b> 26.6.2 [template.valarray] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1669  <b>Submitter:</b> AFNOR <b>Opened:</b> 1998-10-07  <b>Last modified:</b> 2006-12-29</p>
1670 <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>
1671 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1672 <p><b>Discussion:</b></p>
1673 <p>The order of the arguments is (elem, size) instead of the normal
1674 (size, elem) in the rest of the library. Since elem often has an
1675 integral or floating point type, both types are convertible to each
1676 other and reversing them leads to a well formed program.</p>
1677
1678
1679 <p><b>Proposed resolution:</b></p>
1680 <p>Inverting the arguments could silently break programs. Introduce
1681 the two signatures (const T&amp;, size_t) and (size_t, const T&amp;),
1682 but make the one we do not want private so errors result in a
1683 diagnosed access violation. This technique can also be applied to STL
1684 containers.</p>
1685
1686
1687 <p><b>Rationale:</b></p>
1688 <p>The LWG believes that while the order of arguments is unfortunate,
1689 it does not constitute a defect in the standard. The LWG believes that
1690 the proposed solution will not work for valarray&lt;size_t&gt; and
1691 perhaps other cases.</p>
1692
1693
1694
1695
1696 <hr>
1697 <h3><a name="113"></a>113. Missing/extra iostream sync semantics</h3>
1698 <p><b>Section:</b> 27.7.1.1 [istream], 27.7.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1699  <b>Submitter:</b> Steve Clamage <b>Opened:</b> 1998-10-13  <b>Last modified:</b> 2006-12-27</p>
1700 <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>
1701 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1702 <p><b>Discussion:</b></p>
1703 <p>In 27.6.1.1, class basic_istream has a member function sync, described in 27.6.1.3,
1704 paragraph 36. </p>
1705
1706 <p>Following the chain of definitions, I find that the various sync functions have defined
1707 semantics for output streams, but no semantics for input streams. On the other hand,
1708 basic_ostream has no sync function. </p>
1709
1710 <p>The sync function should at minimum be added to basic_ostream, for internal
1711 consistency. </p>
1712
1713 <p>A larger question is whether sync should have assigned semantics for input streams. </p>
1714
1715 <p>Classic iostreams said streambuf::sync flushes pending output and attempts to return
1716 unread input characters to the source. It is a protected member function. The filebuf
1717 version (which is public) has that behavior (it backs up the read pointer). Class
1718 strstreambuf does not override streambuf::sync, and so sync can't be called on a
1719 strstream. </p>
1720
1721 <p>If we can add corresponding semantics to the various sync functions, we should. If not,
1722 we should remove sync from basic_istream.</p>
1723
1724
1725 <p><b>Rationale:</b></p>
1726 <p>A sync function is not needed in basic_ostream because the flush function provides the
1727 desired functionality.</p>
1728
1729 <p>As for the other points, the LWG finds the standard correct as written.</p>
1730
1731
1732
1733
1734
1735 <hr>
1736 <h3><a name="116"></a>116. bitset cannot be constructed with a const char*</h3>
1737 <p><b>Section:</b> 20.3.6 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
1738  <b>Submitter:</b> Judy Ward <b>Opened:</b> 1998-11-06  <b>Last modified:</b> 2008-03-14</p>
1739 <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>
1740 <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>
1741 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
1742 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a></p>
1743 <p><b>Discussion:</b></p>
1744
1745
1746
1747 <p>The following code does not compile with the EDG compiler:</p>
1748
1749 <blockquote>
1750   <pre>#include &lt;bitset&gt;
1751 using namespace std;
1752 bitset&lt;32&gt; b("111111111");</pre>
1753 </blockquote>
1754
1755 <p>If you cast the ctor argument to a string, i.e.:</p>
1756
1757 <blockquote>
1758   <pre>bitset&lt;32&gt; b(string("111111111"));</pre>
1759 </blockquote>
1760
1761 <p>then it will compile. The reason is that bitset has the following templatized
1762 constructor:</p>
1763
1764 <blockquote>
1765   <pre>template &lt;class charT, class traits, class Allocator&gt;
1766 explicit bitset (const basic_string&lt;charT, traits, Allocator&gt;&amp; str, ...);</pre>
1767 </blockquote>
1768
1769 <p>According to the compiler vendor, Steve Adamcyk at EDG, the user
1770 cannot pass this template constructor a <tt>const char*</tt> and
1771 expect a conversion to <tt>basic_string</tt>.  The reason is
1772 "When you have a template constructor, it can get used in
1773 contexts where type deduction can be done. Type deduction basically
1774 comes up with exact matches, not ones involving conversions."
1775 </p>
1776
1777 <p>I don't think the intention when this constructor became
1778 templatized was for construction from a <tt>const char*</tt> to no
1779 longer work.</p>
1780
1781
1782 <p><b>Proposed resolution:</b></p>
1783 <p>Add to 20.3.6 [template.bitset] a bitset constructor declaration</p>
1784
1785 <blockquote>
1786   <pre>explicit bitset(const char*);</pre>
1787 </blockquote>
1788
1789 <p>and in Section 20.3.6.1 [bitset.cons] add:</p>
1790
1791 <blockquote>
1792   <pre>explicit bitset(const char* str);</pre>
1793   <p>Effects: <br>
1794   &nbsp;&nbsp;&nbsp; Calls <tt>bitset((string) str, 0, string::npos);</tt></p>
1795 </blockquote>
1796
1797
1798 <p><b>Rationale:</b></p>
1799 <p>Although the problem is real, the standard is designed that way so
1800 it is not a defect.  Education is the immediate workaround. A future
1801 standard may wish to consider the Proposed Resolution as an
1802 extension.</p>
1803
1804
1805
1806
1807
1808 <hr>
1809 <h3><a name="121"></a>121. Detailed definition for ctype&lt;wchar_t&gt; specialization</h3>
1810 <p><b>Section:</b> 22.3.1.1.1 [locale.category] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1811  <b>Submitter:</b> Judy Ward <b>Opened:</b> 1998-12-15  <b>Last modified:</b> 2006-12-27</p>
1812 <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>
1813 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1814 <p><b>Discussion:</b></p>
1815 <p>Section 22.1.1.1.1 has the following listed in Table 51: ctype&lt;char&gt; ,
1816 ctype&lt;wchar_t&gt;. </p>
1817
1818 <p>Also Section 22.4.1.1 [locale.ctype] says: </p>
1819
1820 <blockquote>
1821   <p>The instantiations required in Table 51 (22.1.1.1.1) namely ctype&lt;char&gt; and
1822   ctype&lt;wchar_t&gt; , implement character classing appropriate to the implementation's
1823   native character set. </p>
1824 </blockquote>
1825
1826 <p>However, Section 22.4.1.3 [facet.ctype.special]
1827 only has a detailed description of the ctype&lt;char&gt; specialization, not the
1828 ctype&lt;wchar_t&gt; specialization. </p>
1829
1830
1831 <p><b>Proposed resolution:</b></p>
1832 <p>Add the ctype&lt;wchar_t&gt; detailed class description to Section
1833 22.4.1.3 [facet.ctype.special]. </p>
1834
1835
1836 <p><b>Rationale:</b></p>
1837 <p>Specialization for wchar_t is not needed since the default is acceptable.</p>
1838
1839
1840
1841
1842
1843 <hr>
1844 <h3><a name="131"></a>131. list::splice throws nothing</h3>
1845 <p><b>Section:</b> 23.3.4.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1846  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 1999-03-06  <b>Last modified:</b> 2007-02-19</p>
1847 <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>
1848 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1849 <p><b>Discussion:</b></p>
1850 <p>What happens if a splice operation causes the size() of a list to grow
1851 beyond max_size()?</p>
1852
1853
1854 <p><b>Rationale:</b></p>
1855 <p>Size() cannot grow beyond max_size().&nbsp; </p>
1856
1857
1858
1859
1860
1861 <hr>
1862 <h3><a name="135"></a>135. basic_iostream doubly initialized</h3>
1863 <p><b>Section:</b> 27.7.1.5.1 [iostream.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1864  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 1999-03-06  <b>Last modified:</b> 2006-12-27</p>
1865 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1866 <p><b>Discussion:</b></p>
1867 <p>-1- Effects Constructs an object of class basic_iostream, assigning
1868 initial values to the base classes by calling
1869 basic_istream&lt;charT,traits&gt;(sb) (lib.istream) and
1870 basic_ostream&lt;charT,traits&gt;(sb) (lib.ostream)</p>
1871
1872 <p>The called for basic_istream and basic_ostream constructors call
1873 init(sb). This means that the basic_iostream's virtual base class is
1874 initialized twice.</p>
1875
1876
1877 <p><b>Proposed resolution:</b></p>
1878 <p>Change 27.6.1.5.1, paragraph 1 to:</p>
1879
1880 <p>-1- Effects Constructs an object of class basic_iostream, assigning
1881 initial values to the base classes by calling
1882 basic_istream&lt;charT,traits&gt;(sb) (lib.istream).</p>
1883
1884
1885 <p><b>Rationale:</b></p>
1886 <p>The LWG agreed that the <tt> init()</tt> function is called
1887 twice, but said that this is harmless and so not a defect in the
1888 standard.</p>
1889
1890
1891
1892
1893 <hr>
1894 <h3><a name="140"></a>140. map&lt;Key, T&gt;::value_type does not satisfy the assignable requirement</h3>
1895 <p><b>Section:</b> 23.4.1 [map] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
1896  <b>Submitter:</b> Mark Mitchell <b>Opened:</b> 1999-04-14  <b>Last modified:</b> 2008-03-14</p>
1897 <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>
1898 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
1899 <p><b>Discussion:</b></p>
1900 <blockquote>
1901   <p>23.2 [container.requirements]<br>
1902   <br>
1903   expression&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; return type
1904   &nbsp;&nbsp;&nbsp;&nbsp; pre/post-condition<br>
1905   -------------&nbsp;&nbsp;&nbsp;&nbsp; ----------- &nbsp;&nbsp;&nbsp;&nbsp;
1906   -------------------<br>
1907   X::value_type&nbsp;&nbsp;&nbsp; T
1908   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
1909   T is assignable<br>
1910   <br>
1911   23.4.1 [map]<br>
1912   <br>
1913   A map satisfies all the requirements of a container.<br>
1914   <br>
1915   For a map&lt;Key, T&gt; ... the value_type is pair&lt;const Key, T&gt;.</p>
1916 </blockquote>
1917
1918 <p>There's a contradiction here. In particular, `pair&lt;const Key,
1919 T&gt;' is not assignable; the `const Key' cannot be assigned
1920 to. So,&nbsp; map&lt;Key, T&gt;::value_type does not satisfy the
1921 assignable requirement imposed by a container.</p>
1922
1923 <p><i>[See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#103">103</a> for the slightly related issue of
1924 modification of set keys.]</i></p>
1925
1926
1927
1928 <p><b>Rationale:</b></p>
1929 <p>The LWG believes that the standard is inconsistent, but that this
1930 is a design problem rather than a strict defect. May wish to
1931 reconsider for the next standard.</p>
1932
1933
1934
1935
1936 <hr>
1937 <h3><a name="143"></a>143. C .h header wording unclear</h3>
1938 <p><b>Section:</b> D.5 [depr.c.headers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1939  <b>Submitter:</b> Christophe de Dinechin <b>Opened:</b> 1999-05-04  <b>Last modified:</b> 2006-12-27</p>
1940 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1941 <p><b>Discussion:</b></p>
1942 <p>[depr.c.headers] paragraph 2 reads:</p>
1943
1944 <blockquote>
1945
1946 <p>Each C header, whose name has the form name.h, behaves as if each
1947 name placed in the Standard library namespace by the corresponding
1948 cname header is also placed within the namespace scope of the
1949 namespace std and is followed by an explicit using-declaration
1950 (_namespace.udecl_)</p>
1951
1952 </blockquote>
1953
1954 <p>I think it should mention the global name space somewhere...&nbsp;
1955 Currently, it indicates that name placed in std is also placed in
1956 std...</p>
1957
1958 <p>I don't know what is the correct wording. For instance, if struct
1959 tm is defined in time.h, ctime declares std::tm. However, the current
1960 wording seems ambiguous regarding which of the following would occur
1961 for use of both ctime and time.h:</p>
1962
1963 <blockquote>
1964   <pre>// version 1:
1965 namespace std {
1966         struct tm { ... };
1967 }
1968 using std::tm;
1969
1970 // version 2:
1971 struct tm { ... };
1972 namespace std {
1973         using ::tm;
1974 }
1975
1976 // version 3:
1977 struct tm { ... };
1978 namespace std {
1979         struct tm { ... };
1980 }</pre>
1981 </blockquote>
1982
1983 <p>I think version 1 is intended.</p>
1984
1985 <p><i>[Kona: The LWG agreed that the wording is not clear. It also
1986 agreed that version 1 is intended, version 2 is not equivalent to
1987 version 1, and version 3 is clearly not intended. The example below
1988 was constructed by Nathan Myers to illustrate why version 2 is not
1989 equivalent to version 1.</i></p>
1990
1991 <p><i>Although not equivalent, the LWG is unsure if (2) is enough of
1992 a problem to be prohibited. Points discussed in favor of allowing
1993 (2):</i></p>
1994
1995 <blockquote>
1996   <ul>
1997     <li><i>It may be a convenience to implementors.</i></li>
1998     <li><i>The only cases that fail are structs, of which the C library
1999       contains only a few.</i></li>
2000   </ul>
2001 </blockquote>
2002
2003 <p><i>]</i></p>
2004
2005 <p><b>Example:</b></p>
2006
2007 <blockquote>
2008
2009 <pre>#include &lt;time.h&gt;
2010 #include &lt;utility&gt;
2011
2012 int main() {
2013     std::tm * t;
2014     make_pair( t, t ); // okay with version 1 due to Koenig lookup
2015                        // fails with version 2; make_pair not found
2016     return 0;
2017 }</pre>
2018
2019 </blockquote>
2020
2021
2022 <p><b>Proposed resolution:</b></p>
2023
2024 <p>Replace D.5 [depr.c.headers] paragraph 2 with:</p>
2025
2026 <blockquote>
2027
2028 <p> Each C header, whose name has the form name.h, behaves as if each
2029 name placed in the Standard library namespace by the corresponding
2030 cname header is also placed within the namespace scope of the
2031 namespace std by name.h and is followed by an explicit
2032 using-declaration (_namespace.udecl_) in global scope.</p>
2033
2034 </blockquote>
2035
2036
2037
2038 <p><b>Rationale:</b></p>
2039 <p> The current wording in the standard is the result of a difficult
2040 compromise that averted delay of the standard. Based on discussions
2041 in Tokyo it is clear that there is no still no consensus on stricter
2042 wording, so the issue has been closed. It is suggested that users not
2043 write code that depends on Koenig lookup of C library functions.</p>
2044
2045
2046
2047
2048 <hr>
2049 <h3><a name="145"></a>145. adjustfield lacks default value</h3>
2050 <p><b>Section:</b> 27.5.4.1 [basic.ios.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
2051  <b>Submitter:</b> Angelika Langer <b>Opened:</b> 1999-05-12  <b>Last modified:</b> 2006-12-27</p>
2052 <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>
2053 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2054 <p><b>Discussion:</b></p>
2055 <p>There is no initial value for the adjustfield defined, although
2056 many people believe that the default adjustment were right. This is a
2057 common misunderstanding. The standard only defines that, if no
2058 adjustment is specified, all the predefined inserters must add fill
2059 characters before the actual value, which is "as if" the
2060 right flag were set. The flag itself need not be set.</p>
2061
2062 <p>When you implement a user-defined inserter you cannot rely on right
2063 being the default setting for the adjustfield. Instead, you must be
2064 prepared to find none of the flags set and must keep in mind that in
2065 this case you should make your inserter behave "as if" the
2066 right flag were set. This is surprising to many people and complicates
2067 matters more than necessary.</p>
2068
2069 <p>Unless there is a good reason why the adjustfield should not be
2070 initialized I would suggest to give it the default value that
2071 everybody expects anyway.</p>
2072
2073
2074
2075 <p><b>Rationale:</b></p>
2076 <p>This is not a defect. It is deliberate that the default is no bits
2077 set. Consider Arabic or Hebrew, for example. See 22.4.2.2.2 [facet.num.put.virtuals] paragraph 19, Table 61 - Fill padding.</p>
2078
2079
2080
2081
2082 <hr>
2083 <h3><a name="157"></a>157. Meaningless error handling for <tt>pword()</tt> and <tt>iword()</tt></h3>
2084 <p><b>Section:</b> 27.5.2.5 [ios.base.storage] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
2085  <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 1999-07-20  <b>Last modified:</b> 2007-01-15</p>
2086 <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>
2087 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
2088 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#41">41</a></p>
2089 <p><b>Discussion:</b></p>
2090 <p>According to paragraphs 2 and 4 of 27.5.2.5 [ios.base.storage], the
2091 functions <tt>iword()</tt> and <tt>pword()</tt> "set the
2092 <tt>badbit</tt> (which might throw an exception)" on
2093 failure. ... but what does it mean for <tt>ios_base</tt> to set the
2094 <tt>badbit</tt>? The state facilities of the IOStream library are
2095 defined in <tt>basic_ios</tt>, a derived class! It would be possible
2096 to attempt a down cast but then it would be necessary to know the
2097 character type used...</p>
2098
2099
2100 <p><b>Rationale:</b></p>
2101
2102
2103
2104
2105
2106 <hr>
2107 <h3><a name="162"></a>162. Really "formatted input functions"?</h3>
2108 <p><b>Section:</b> 27.7.1.2.3 [istream::extractors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
2109  <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 1999-07-20  <b>Last modified:</b> 2007-01-15</p>
2110 <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>
2111 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
2112 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</a></p>
2113 <p><b>Discussion:</b></p>
2114 <p>It appears to be somewhat nonsensical to consider the functions
2115 defined in the paragraphs 1 to 5 to be "Formatted input
2116 function" but since these functions are defined in a section
2117 labeled "Formatted input functions" it is unclear to me
2118 whether these operators are considered formatted input functions which
2119 have to conform to the "common requirements" from 27.7.1.2.1
2120 [istream.formatted.reqmts]: If this is the case, all manipulators, not
2121 just
2122 <tt>ws</tt>, would skip whitespace unless <tt>noskipws</tt> is set
2123 (... but setting <tt>noskipws</tt> using the manipulator syntax would
2124 also skip whitespace :-)</p>
2125
2126 <p>See also issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#166">166</a> for the same problem in formatted
2127 output</p>
2128
2129
2130 <p><b>Rationale:</b></p>
2131
2132
2133
2134
2135
2136 <hr>
2137 <h3><a name="163"></a>163. Return of <tt>gcount()</tt> after a call to <tt>gcount</tt></h3>
2138 <p><b>Section:</b> 27.7.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
2139  <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 1999-07-20  <b>Last modified:</b> 2007-01-15</p>
2140 <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>
2141 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
2142 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</a></p>
2143 <p><b>Discussion:</b></p>
2144 <p>It is not clear which functions are to be considered unformatted
2145 input functions. As written, it seems that all functions in 27.7.1.3
2146 [istream.unformatted] are unformatted input functions. However, it does
2147 not
2148 really make much sense to construct a sentry object for
2149 <tt>gcount()</tt>, <tt>sync()</tt>, ... Also it is unclear what
2150 happens to the <tt>gcount()</tt> if eg. <tt>gcount()</tt>,
2151 <tt>putback()</tt>, <tt>unget()</tt>, or <tt>sync()</tt> is called:
2152 These functions don't extract characters, some of them even
2153 "unextract" a character. Should this still be reflected in
2154 <tt>gcount()</tt>? Of course, it could be read as if after a call to
2155 <tt>gcount()</tt> <tt>gcount()</tt> return <tt>0</tt> (the last
2156 unformatted input function, <tt>gcount()</tt>, didn't extract any
2157 character) and after a call to <tt>putback()</tt> <tt>gcount()</tt>
2158 returns <tt>-1</tt> (the last unformatted input function
2159 <tt>putback()</tt> did "extract" back into the
2160 stream). Correspondingly for <tt>unget()</tt>. Is this what is
2161 intended?  If so, this should be clarified. Otherwise, a corresponding
2162 clarification should be used.</p>
2163
2164
2165 <p><b>Rationale:</b></p>
2166
2167
2168
2169
2170
2171 <hr>
2172 <h3><a name="166"></a>166. Really "formatted output functions"?</h3>
2173 <p><b>Section:</b> 27.7.2.6.3 [ostream.inserters] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
2174  <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 1999-07-20  <b>Last modified:</b> 2007-01-15</p>
2175 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
2176 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</a></p>
2177 <p><b>Discussion:</b></p>
2178 <p>From 27.7.2.6.1 [ostream.formatted.reqmts] it appears that all the functions
2179 defined in 27.7.2.6.3 [ostream.inserters] have to construct a
2180 <tt>sentry</tt> object. Is this really intended?</p>
2181
2182 <p>This is basically the same problem as issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#162">162</a> but
2183 for output instead of input.</p>
2184
2185
2186 <p><b>Rationale:</b></p>
2187
2188
2189
2190
2191
2192 <hr>
2193 <h3><a name="177"></a>177. Complex operators cannot be explicitly instantiated</h3>
2194 <p><b>Section:</b> 26.4.6 [complex.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
2195  <b>Submitter:</b> Judy Ward <b>Opened:</b> 1999-07-02  <b>Last modified:</b> 2006-12-27</p>
2196 <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>
2197 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2198 <p><b>Discussion:</b></p>
2199 <p>A user who tries to explicitly instantiate a complex non-member operator will
2200 get compilation errors. Below is a simplified example of the reason why. The
2201 problem is that iterator_traits cannot be instantiated on a non-pointer type
2202 like float, yet when the compiler is trying to decide which operator+ needs to
2203 be instantiated it must instantiate the declaration to figure out the first
2204 argument type of a reverse_iterator operator.</p>
2205 <pre>namespace std {
2206 template &lt;class Iterator&gt;
2207 struct iterator_traits
2208 {
2209     typedef typename Iterator::value_type value_type;
2210 };
2211
2212 template &lt;class T&gt; class reverse_iterator;
2213
2214 // reverse_iterator operator+
2215 template &lt;class T&gt;
2216 reverse_iterator&lt;T&gt; operator+
2217 (typename iterator_traits&lt;T&gt;::difference_type, const reverse_iterator&lt;T&gt;&amp;);
2218
2219 template &lt;class T&gt; struct complex {};
2220
2221 // complex operator +
2222 template &lt;class T&gt;
2223 complex&lt;T&gt; operator+ (const T&amp; lhs, const complex&lt;T&gt;&amp; rhs)
2224 { return complex&lt;T&gt;();}
2225 }
2226
2227 // request for explicit instantiation
2228 template std::complex&lt;float&gt; std::operator+&lt;float&gt;(const float&amp;,
2229      const std::complex&lt;float&gt;&amp;);</pre>
2230 <p>See also c++-stdlib reflector messages: lib-6814, 6815, 6816.</p>
2231
2232
2233 <p><b>Rationale:</b></p>
2234 <p>Implementors can make minor changes and the example will
2235 work. Users are not affected in any case.</p> <p>According to John
2236 Spicer, It is possible to explicitly instantiate these operators using
2237 different syntax: change "std::operator+&lt;float&gt;" to
2238 "std::operator+".</p>
2239
2240 <p>The proposed resolution of issue 120 is that users will not be able
2241 to explicitly instantiate standard library templates. If that
2242 resolution is accepted then library implementors will be the only ones
2243 that will be affected by this problem, and they must use the indicated
2244 syntax.</p>
2245
2246
2247
2248
2249 <hr>
2250 <h3><a name="178"></a>178. Should clog and cerr initially be tied to cout?</h3>
2251 <p><b>Section:</b> 27.4.1 [narrow.stream.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
2252  <b>Submitter:</b> Judy Ward <b>Opened:</b> 1999-07-02  <b>Last modified:</b> 2006-12-27</p>
2253 <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>
2254 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2255 <p><b>Discussion:</b></p>
2256 <p>
2257 Section 27.3.1 says "After the object cerr is initialized,
2258 cerr.flags() &amp; unitbuf is nonzero. Its state is otherwise the same as
2259 required for ios_base::init (lib.basic.ios.cons).  It doesn't say
2260 anything about the the state of clog.  So this means that calling
2261 cerr.tie() and clog.tie() should return 0 (see Table 89 for
2262 ios_base::init effects).
2263 </p>
2264 <p>
2265 Neither of the popular standard library implementations
2266 that I tried does this, they both tie cerr and clog
2267 to &amp;cout. I would think that would be what users expect.
2268 </p>
2269
2270
2271 <p><b>Rationale:</b></p>
2272 <p>The standard is clear as written.</p>
2273 <p>27.3.1/5 says that "After the object cerr is initialized, cerr.flags()
2274 &amp; unitbuf is nonzero. Its state is otherwise the same as required for
2275 ios_base::init (27.4.4.1)." Table 89 in 27.4.4.1, which gives the
2276 postconditions of basic_ios::init(), says that tie() is 0. (Other issues correct
2277 ios_base::init to basic_ios::init().)</p>
2278
2279
2280
2281
2282 <hr>
2283 <h3><a name="188"></a>188. valarray helpers missing augmented assignment operators</h3>
2284 <p><b>Section:</b> 26.6.2.6 [valarray.cassign] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
2285  <b>Submitter:</b> Gabriel Dos Reis <b>Opened:</b> 1999-08-15  <b>Last modified:</b> 2008-03-11</p>
2286 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2287 <p><b>Discussion:</b></p>
2288 <p>26.5.2.6 defines augmented assignment operators
2289 valarray&lt;T&gt;::op=(const T&amp;), but fails to provide
2290 corresponding versions for the helper classes. Thus making the
2291 following illegal:</p>
2292 <blockquote>
2293 <pre>#include &lt;valarray&gt;
2294
2295 int main()
2296 {
2297 std::valarray&lt;double&gt; v(3.14, 1999);
2298
2299 v[99] *= 2.0; // Ok
2300
2301 std::slice s(0, 50, 2);
2302
2303 v[s] *= 2.0; // ERROR
2304 }</pre>
2305 </blockquote>
2306 <p>I can't understand the intent of that omission.  It makes the
2307 valarray library less intuitive and less useful.</p>
2308
2309
2310 <p><b>Rationale:</b></p>
2311 <p>Although perhaps an unfortunate
2312 design decision, the omission is not a defect in the current
2313 standard.&nbsp; A future standard may wish to add the missing
2314 operators.</p>
2315
2316
2317
2318
2319 <hr>
2320 <h3><a name="191"></a>191. Unclear complexity for algorithms such as binary search</h3>
2321 <p><b>Section:</b> 25.5.3 [alg.binary.search] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
2322  <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1999-10-10  <b>Last modified:</b> 2006-12-27</p>
2323 <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>
2324 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2325 <p><b>Discussion:</b></p>
2326 <p>The complexity of binary_search() is stated as "At most
2327 log(last-first) + 2 comparisons", which seems to say that the
2328 algorithm has logarithmic complexity. However, this algorithms is
2329 defined for forward iterators. And for forward iterators, the need to
2330 step element-by-element results into linear complexity. But such a
2331 statement is missing in the standard. The same applies to
2332 lower_bound(), upper_bound(), and equal_range().&nbsp;<br>
2333 <br>
2334 However, strictly speaking the standard contains no bug here. So this
2335 might considered to be a clarification or improvement.
2336 </p>
2337
2338
2339 <p><b>Rationale:</b></p>
2340 <p>The complexity is expressed in terms of comparisons, and that
2341 complexity can be met even if the number of iterators accessed is
2342 linear. Paragraph 1 already says exactly what happens to
2343 iterators.</p>
2344
2345
2346
2347
2348 <hr>
2349 <h3><a name="192"></a>192. a.insert(p,t) is inefficient and overconstrained</h3>
2350 <p><b>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
2351  <b>Submitter:</b> Ed Brey <b>Opened:</b> 1999-06-06  <b>Last modified:</b> 2006-12-30</p>
2352 <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>
2353 <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>
2354 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2355 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a></p>
2356 <p><b>Discussion:</b></p>
2357 <p>As defined in 23.1.2, paragraph 7 (table 69), a.insert(p,t) suffers from
2358 several problems:</p>
2359 <table border="1" cellpadding="5">
2360   <tbody><tr>
2361     <td><b>expression</b></td>
2362     <td><b>return type</b></td>
2363     <td><b>pre/post-condition</b></td>
2364     <td><b>complexity</b></td>
2365   </tr>
2366   <tr>
2367     <td><tt>a.insert(p,t)</tt></td>
2368     <td><tt>iterator</tt></td>
2369     <td>inserts t if and only if there is no element with key equivalent to the key of
2370        t in containers with unique keys; always inserts t in containers with equivalent
2371        keys. always returns the iterator pointing to the element with key equivalent to
2372        the key of t . iterator p is a hint pointing to where the insert should start to search.</td>
2373     <td>logarithmic in general, but amortized constant if t is inserted right after p .</td>
2374   </tr>
2375 </tbody></table>
2376 <p>1. For a container with unique keys, only logarithmic complexity is
2377 guaranteed if no element is inserted, even though constant complexity is always
2378 possible if p points to an element equivalent to t.</p>
2379 <p>2. For a container with equivalent keys, the amortized constant complexity
2380 guarantee is only useful if no key equivalent to t exists in the container.
2381 Otherwise, the insertion could occur in one of multiple locations, at least one
2382 of which would not be right after p.</p>
2383 <p>3. By guaranteeing amortized constant complexity only when t is inserted
2384 after p, it is impossible to guarantee constant complexity if t is inserted at
2385 the beginning of the container. Such a problem would not exist if amortized
2386 constant complexity was guaranteed if t is inserted before p, since there is
2387 always some p immediately before which an insert can take place.</p>
2388 <p>4. For a container with equivalent keys, p does not allow specification of
2389 where to insert the element, but rather only acts as a hint for improving
2390 performance. This negates the added functionality that p would provide if it
2391 specified where within a sequence of equivalent keys the insertion should occur.
2392 Specifying the insert location provides more control to the user, while
2393 providing no disadvantage to the container implementation.</p>
2394
2395
2396 <p><b>Proposed resolution:</b></p>
2397 <p>In 23.2.4 [associative.reqmts] paragraph 7, replace the row in table 69
2398 for a.insert(p,t) with the following two rows:</p>
2399 <table border="1" cellpadding="5">
2400   <tbody><tr>
2401     <td><b>expression</b></td>
2402     <td><b>return type</b></td>
2403     <td><b>pre/post-condition</b></td>
2404     <td><b>complexity</b></td>
2405   </tr>
2406   <tr>
2407     <td><tt>a_uniq.insert(p,t)</tt></td>
2408     <td><tt>iterator</tt></td>
2409     <td>inserts t if and only if there is no element with key equivalent to the
2410       key of t. returns the iterator pointing to the element with key equivalent
2411       to the key of t.</td>
2412     <td>logarithmic in general, but amortized constant if t is inserted right
2413       before p or p points to an element with key equivalent to t.</td>
2414   </tr>
2415   <tr>
2416     <td><tt>a_eq.insert(p,t)</tt></td>
2417     <td><tt>iterator</tt></td>
2418     <td>inserts t and returns the iterator pointing to the newly inserted
2419       element. t is inserted right before p if doing so preserves the container
2420       ordering.</td>
2421     <td>logarithmic in general, but amortized constant if t is inserted right
2422       before p.</td>
2423   </tr>
2424 </tbody></table>
2425
2426
2427
2428 <p><b>Rationale:</b></p>
2429 <p>Too big a change.&nbsp; Furthermore, implementors report checking
2430 both before p and after p, and don't want to change this behavior.</p>
2431
2432
2433
2434
2435
2436 <hr>
2437 <h3><a name="194"></a>194. rdbuf() functions poorly specified</h3>
2438 <p><b>Section:</b> 27.5.4 [ios] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
2439  <b>Submitter:</b> Steve Clamage <b>Opened:</b> 1999-09-07  <b>Last modified:</b> 2006-12-27</p>
2440 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2441 <p><b>Discussion:</b></p>
2442 <p>In classic iostreams, base class ios had an rdbuf function that returned a
2443 pointer to the associated streambuf. Each derived class had its own rdbuf
2444 function that returned a pointer of a type reflecting the actual type derived
2445 from streambuf. Because in ARM C++, virtual function overrides had to have the
2446 same return type, rdbuf could not be virtual.</p>
2447 <p>In standard iostreams, we retain the non-virtual rdbuf function design, and
2448 in addition have an overloaded rdbuf function that sets the buffer pointer.
2449 There is no need for the second function to be virtual nor to be implemented in
2450 derived classes.</p>
2451 <p>Minor question: Was there a specific reason not to make the original rdbuf
2452 function virtual?</p>
2453 <p>Major problem: Friendly compilers warn about functions in derived classes
2454 that hide base-class overloads. Any standard implementation of iostreams will
2455 result in such a warning on each of the iostream classes, because of the
2456 ill-considered decision to overload rdbuf only in a base class.</p>
2457 <p>In addition, users of the second rdbuf function must use explicit
2458 qualification or a cast to call it from derived classes. An explicit
2459 qualification or cast to basic_ios would prevent access to any later overriding
2460 version if there was one.</p>
2461 <p>What I'd like to do in an implementation is add a using- declaration for the
2462 second rdbuf function in each derived class. It would eliminate warnings about
2463 hiding functions, and would enable access without using explicit qualification.
2464 Such a change I don't think would change the behavior of any valid program, but
2465 would allow invalid programs to compile:</p>
2466 <blockquote>
2467   <pre> filebuf mybuf;
2468  fstream f;
2469  f.rdbuf(mybuf); // should be an error, no visible rdbuf</pre>
2470 </blockquote>
2471 <p>I'd like to suggest this problem as a defect, with the proposed resolution to
2472 require the equivalent of a using-declaration for the rdbuf function that is not
2473 replaced in a later derived class. We could discuss whether replacing the
2474 function should be allowed.</p>
2475
2476
2477 <p><b>Rationale:</b></p>
2478 <p>For historical reasons, the standard is correct as written. There is a subtle difference between the base
2479 class <tt> rdbuf()</tt> and derived class <tt>rdbuf()</tt>. The derived
2480 class <tt> rdbuf()</tt> always returns the original streambuf, whereas the base class
2481 <tt> rdbuf()</tt> will return the "current streambuf" if that has been changed by the variant you mention.</p>
2482
2483 <p>Permission is not required to add such an extension.  See
2484 17.6.4.5 [member.functions].</p>
2485
2486
2487
2488
2489 <hr>
2490 <h3><a name="196"></a>196. Placement new example has alignment problems</h3>
2491 <p><b>Section:</b> 18.6.1.3 [new.delete.placement] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
2492  <b>Submitter:</b> Herb Sutter <b>Opened:</b> 1998-12-15  <b>Last modified:</b> 2006-12-30</p>
2493 <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>
2494 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
2495 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#114">114</a></p>
2496 <p><b>Discussion:</b></p>
2497 <p>The example in 18.6.1.3 [new.delete.placement] paragraph 4 reads: </p>
2498
2499 <blockquote>
2500
2501 <p>[Example: This can be useful for constructing an object at a known address:<br>
2502 <br>
2503 <tt>&nbsp;&nbsp; char place[sizeof(Something)];<br>
2504 &nbsp;&nbsp; Something* p = new (place) Something();<br>
2505 <br>
2506 </tt>end example] </p>
2507
2508 </blockquote>
2509
2510 <p>This example has potential alignment problems. </p>
2511
2512
2513 <p><b>Rationale:</b></p>
2514
2515
2516
2517
2518
2519 <hr>
2520 <h3><a name="197"></a>197. max_size() underspecified</h3>
2521 <p><b>Section:</b> X [allocator.requirements], 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
2522  <b>Submitter:</b> Andy Sawyer <b>Opened:</b> 1999-10-21  <b>Last modified:</b> 2006-12-30</p>
2523 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p>
2524 <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>
2525 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2526 <p><b>Discussion:</b></p>
2527 <p>Must the value returned by max_size() be unchanged from call to call? </p>
2528
2529 <p>Must the value returned from max_size() be meaningful? </p>
2530
2531 <p>Possible meanings identified in lib-6827: </p>
2532
2533 <p>1) The largest container the implementation can support given "best
2534 case" conditions - i.e. assume the run-time platform is "configured to
2535 the max", and no overhead from the program itself. This may possibly
2536 be determined at the point the library is written, but certainly no
2537 later than compile time.<br>
2538 <br>
2539 2) The largest container the program could create, given "best case"
2540 conditions - i.e. same platform assumptions as (1), but take into
2541 account any overhead for executing the program itself. (or, roughly
2542 "storage=storage-sizeof(program)"). This does NOT include any resource
2543 allocated by the program. This may (or may not) be determinable at
2544 compile time.<br>
2545 <br>
2546 3) The largest container the current execution of the program could
2547 create, given knowledge of the actual run-time platform, but again,
2548 not taking into account any currently allocated resource. This is
2549 probably best determined at program start-up.<br>
2550 <br>
2551 4) The largest container the current execution program could create at
2552 the point max_size() is called (or more correctly at the point
2553 max_size() returns :-), given it's current environment (i.e. taking
2554 into account the actual currently available resources). This,
2555 obviously, has to be determined dynamically each time max_size() is
2556 called. </p>
2557
2558
2559 <p><b>Proposed resolution:</b></p>
2560
2561
2562 <p><b>Rationale:</b></p>
2563 <p>max_size() isn't useful for very many things, and the existing
2564   wording is sufficiently clear for the few cases that max_size() can
2565   be used for.  None of the attempts to change the existing wording
2566   were an improvement.</p>
2567
2568 <p>It is clear to the LWG that the value returned by max_size() can't
2569   change from call to call.</p>
2570
2571
2572
2573
2574
2575
2576 <hr>
2577 <h3><a name="203"></a>203. basic_istream::sentry::sentry() is uninstantiable with ctype&lt;user-defined type&gt;</h3>
2578 <p><b>Section:</b> 27.7.1.1.3 [istream::sentry] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
2579  <b>Submitter:</b> Matt McClure and Dietmar Kühl <b>Opened:</b> 2000-01-01  <b>Last modified:</b> 2007-01-15</p>
2580 <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>
2581 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2582 <p><b>Discussion:</b></p>
2583 <p>27.6.1.1.2 Paragraph 4 states:</p>
2584 <blockquote>
2585   <p>To decide if the character c is a whitespace character, the constructor
2586      performs ''as if'' it executes the following code fragment:&nbsp;</p>
2587   <pre>const ctype&lt;charT&gt;&amp; ctype = use_facet&lt;ctype&lt;charT&gt; &gt;(is.getloc());
2588 if (ctype.is(ctype.space,c)!=0)
2589 // c is a whitespace character.</pre>
2590 </blockquote>
2591
2592 <p> But Table 51 in 22.1.1.1.1 only requires an implementation to
2593 provide specializations for ctype&lt;char&gt; and
2594 ctype&lt;wchar_t&gt;.  If sentry's constructor is implemented using
2595 ctype, it will be uninstantiable for a user-defined character type
2596 charT, unless the implementation has provided non-working (since it
2597 would be impossible to define a correct ctype&lt;charT&gt; specialization
2598 for an arbitrary charT) definitions of ctype's virtual member
2599 functions.</p>
2600
2601 <p>
2602 It seems the intent the standard is that sentry should behave, in
2603 every respect, not just during execution, as if it were implemented
2604 using ctype, with the burden of providing a ctype specialization
2605 falling on the user.  But as it is written, nothing requires the
2606 translation of sentry's constructor to behave as if it used the above
2607 code, and it would seem therefore, that sentry's constructor should be
2608 instantiable for all character types.
2609 </p>
2610
2611 <p>
2612 Note: If I have misinterpreted the intent of the standard with
2613 respect to sentry's constructor's instantiability, then a note should
2614 be added to the following effect:
2615 </p>
2616
2617 <blockquote><p>
2618 An implementation is forbidden from using the above code if it renders
2619 the constructor uninstantiable for an otherwise valid character
2620 type.
2621 </p></blockquote>
2622
2623 <p>In any event, some clarification is needed.</p>
2624
2625
2626
2627 <p><b>Rationale:</b></p>
2628 <p>It is possible but not easy to instantiate on types other than char
2629 or wchar_t; many things have to be done first. That is by intention
2630 and is not a defect.</p>
2631
2632
2633
2634
2635 <hr>
2636 <h3><a name="204"></a>204. distance(first, last) when "last" is before "first"</h3>
2637 <p><b>Section:</b> 24.4 [iterator.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
2638  <b>Submitter:</b> Rintala Matti <b>Opened:</b> 2000-01-28  <b>Last modified:</b> 2008-09-30</p>
2639 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iterator.operations">active issues</a> in [iterator.operations].</p>
2640 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.operations">issues</a> in [iterator.operations].</p>
2641 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2642 <p><b>Discussion:</b></p>
2643 <p>Section 24.3.4 describes the function distance(first, last) (where first and
2644 last are iterators) which calculates "the number of increments or
2645 decrements needed to get from 'first' to 'last'".</p>
2646 <p>The function should work for forward, bidirectional and random access
2647 iterators, and there is a requirement 24.3.4.5 which states that "'last'
2648 must be reachable from 'first'".</p>
2649 <p>With random access iterators the function is easy to implement as "last
2650 - first".</p>
2651 <p>With forward iterators it's clear that 'first' must point to a place before
2652 'last', because otherwise 'last' would not be reachable from 'first'.</p>
2653 <p>But what about bidirectional iterators? There 'last' is reachable from
2654 'first' with the -- operator even if 'last' points to an earlier position than
2655 'first'. However, I cannot see how the distance() function could be implemented
2656 if the implementation does not know which of the iterators points to an earlier
2657 position (you cannot use ++ or -- on either iterator if you don't know which
2658 direction is the "safe way to travel").</p>
2659 <p>The paragraph 24.3.4.1 states that "for ... bidirectional iterators they
2660 use ++ to provide linear time implementations". However, the ++ operator is
2661 not mentioned in the reachability requirement. Furthermore 24.3.4.4 explicitly
2662 mentions that distance() returns the number of increments _or decrements_,
2663 suggesting that it could return a negative number also for bidirectional
2664 iterators when 'last' points to a position before 'first'.</p>
2665 <p>Is a further requirement is needed to state that for forward and
2666 bidirectional iterators "'last' must be reachable from 'first' using the ++
2667 operator". Maybe this requirement might also apply to random access
2668 iterators so that distance() would work the same way for every iterator
2669 category?</p>
2670
2671
2672 <p><b>Rationale:</b></p>
2673 <p>"Reachable" is defined in the standard in 24.2 [iterator.concepts] paragraph 6.
2674 The definition is only in terms of operator++(). The LWG sees no defect in
2675 the standard.</p>
2676
2677
2678
2679
2680 <hr>
2681 <h3><a name="205"></a>205.  numeric_limits unclear on how to determine floating point types</h3>
2682 <p><b>Section:</b> 18.3.1.2 [numeric.limits.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
2683  <b>Submitter:</b> Steve Cleary <b>Opened:</b> 2000-01-28  <b>Last modified:</b> 2006-12-27</p>
2684 <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>
2685 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2686 <p><b>Discussion:</b></p>
2687 <p>In several places in 18.3.1.2 [numeric.limits.members], a member is
2688 described as "Meaningful for all floating point types."
2689 However, no clear method of determining a floating point type is
2690 provided.</p>
2691
2692 <p>In 18.3.1.5 [numeric.special], paragraph 1 states ". . . (for
2693 example, epsilon() is only meaningful if is_integer is
2694 false). . ." which suggests that a type is a floating point type
2695 if is_specialized is true and is_integer is false; however, this is
2696 unclear.</p>
2697
2698 <p>When clarifying this, please keep in mind this need of users: what
2699 exactly is the definition of floating point? Would a fixed point or
2700 rational representation be considered one? I guess my statement here
2701 is that there could also be types that are neither integer or
2702 (strictly) floating point.</p>
2703
2704
2705 <p><b>Rationale:</b></p>
2706 <p>It is up to the implementor of a user define type to decide if it is a
2707 floating point type.</p>
2708
2709
2710
2711
2712 <hr>
2713 <h3><a name="207"></a>207. ctype&lt;char&gt; members return clause incomplete</h3>
2714 <p><b>Section:</b> 22.4.1.3.2 [facet.ctype.char.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
2715  <b>Submitter:</b> Robert Klarer <b>Opened:</b> 1999-11-02  <b>Last modified:</b> 2006-12-30</p>
2716 <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>
2717 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
2718 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#153">153</a></p>
2719 <p><b>Discussion:</b></p>
2720 <p>
2721 The <tt>widen</tt> and <tt>narrow</tt> member functions are described
2722 in 22.2.1.3.2, paragraphs 9-11.  In each case we have two overloaded
2723 signatures followed by a <b>Returns</b> clause.  The <b>Returns</b>
2724 clause only describes one of the overloads.
2725 </p>
2726
2727
2728 <p><b>Proposed resolution:</b></p>
2729 <p>Change the returns clause in 22.4.1.3.2 [facet.ctype.char.members]
2730 paragraph 10 from:</p>
2731 <p>&nbsp;&nbsp;&nbsp; Returns: do_widen(low, high, to).</p>
2732
2733 <p>to:</p>
2734 <p>&nbsp;&nbsp;&nbsp; Returns: do_widen(c) or do_widen(low, high, to),
2735 respectively.</p>
2736
2737 <p>Change the returns clause in 22.4.1.3.2 [facet.ctype.char.members] paragraph 11
2738 from:</p>
2739 <p>&nbsp;&nbsp;&nbsp; Returns: do_narrow(low, high, to).</p>
2740
2741 <p>to:</p>
2742 <p>&nbsp;&nbsp;&nbsp; Returns: do_narrow(c) or do_narrow(low, high, to),
2743 respectively.</p>
2744
2745
2746 <p><b>Rationale:</b></p>
2747 <p>Subsumed by issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#153">153</a>, which addresses the same
2748 paragraphs.</p>
2749
2750
2751
2752
2753
2754
2755 <hr>
2756 <h3><a name="213"></a>213. Math function overloads ambiguous</h3>
2757 <p><b>Section:</b> 26.8 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
2758  <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 2000-02-26  <b>Last modified:</b> 2006-12-29</p>
2759 <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>
2760 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2761 <p><b>Discussion:</b></p>
2762 <p>Due to the additional overloaded versions of numeric functions for
2763 float and long double according to Section 26.5, calls such as int x;
2764 std::pow (x, 4) are ambiguous now in a standard conforming
2765 implementation. Current implementations solve this problem very
2766 different (overload for all types, don't overload for float and long
2767 double, use preprocessor, follow the standard and get
2768 ambiguities).</p> <p>This behavior should be standardized or at least
2769 identified as implementation defined.</p>
2770
2771
2772 <p><b>Rationale:</b></p>
2773 <p>These math issues are an
2774 understood and accepted consequence of the design. They have
2775 been discussed several times in the past. Users must write casts
2776 or write floating point expressions as arguments.</p>
2777
2778
2779
2780
2781 <hr>
2782 <h3><a name="215"></a>215. Can a map's key_type be const?</h3>
2783 <p><b>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
2784  <b>Submitter:</b> Judy Ward <b>Opened:</b> 2000-02-29  <b>Last modified:</b> 2006-12-27</p>
2785 <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>
2786 <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>
2787 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2788 <p><b>Discussion:</b></p>
2789 <p>A user noticed that this doesn't compile with the Rogue Wave library because
2790 the rb_tree class declares a key_allocator, and allocator&lt;const int&gt; is
2791 not legal, I think:</p>
2792 <blockquote>
2793   <pre>map &lt; const int, ... &gt; // legal?</pre>
2794 </blockquote>
2795 <p>which made me wonder whether it is legal for a map's key_type to be const. In
2796 email from Matt Austern he said:</p>
2797 <blockquote>
2798 <p>I'm not sure whether it's legal to declare a map with a const key type. I
2799 hadn't thought about that question until a couple weeks ago. My intuitive
2800 feeling is that it ought not to be allowed, and that the standard ought to say
2801 so. It does turn out to work in SGI's library, though, and someone in the
2802 compiler group even used it. Perhaps this deserves to be written up as an issue
2803 too.</p>
2804 </blockquote>
2805
2806
2807 <p><b>Rationale:</b></p>
2808 <p>The "key is assignable" requirement from table 69 in
2809 23.2.4 [associative.reqmts] already implies the key cannot be const.</p>
2810
2811
2812
2813
2814 <hr>
2815 <h3><a name="216"></a>216. setbase manipulator description flawed</h3>
2816 <p><b>Section:</b> 27.7.3 [std.manip] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
2817  <b>Submitter:</b> Hyman Rosen <b>Opened:</b> 2000-02-29  <b>Last modified:</b> 2006-12-30</p>
2818 <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>
2819 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
2820 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#193">193</a></p>
2821 <p><b>Discussion:</b></p>
2822 <p>27.7.3 [std.manip] paragraph 5 says:</p>
2823 <blockquote>
2824 <pre>smanip setbase(int base);</pre>
2825 <p> Returns: An object s of unspecified type such that if out is an
2826 (instance of) basic_ostream then the expression out&lt;&lt;s behaves
2827 as if f(s) were called, in is an (instance of) basic_istream then the
2828 expression in&gt;&gt;s behaves as if f(s) were called. Where f can be
2829 defined as:</p>
2830 <pre>ios_base&amp; f(ios_base&amp; str, int base)
2831 {
2832   // set basefield
2833   str.setf(n == 8 ? ios_base::oct :
2834                 n == 10 ? ios_base::dec :
2835                 n == 16 ? ios_base::hex :
2836                   ios_base::fmtflags(0), ios_base::basefield);
2837   return str;
2838 }</pre>
2839 </blockquote>
2840 <p>There are two problems here. First, f takes two parameters, so the
2841 description needs to say that out&lt;&lt;s and in&gt;&gt;s behave as if f(s,base)
2842 had been called. Second, f is has a parameter named base, but is written as if
2843 the parameter was named n.</p>
2844 <p>Actually, there's a third problem. The paragraph has grammatical errors.
2845 There needs to be an "and" after the first comma, and the "Where
2846 f" sentence fragment needs to be merged into its preceding sentence. You
2847 may also want to format the function a little better. The formatting above is
2848 more-or-less what the Standard contains.</p>
2849
2850
2851 <p><b>Rationale:</b></p>
2852 <p>The resolution of this defect is subsumed by the proposed resolution for
2853 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#193">193</a>.</p>
2854
2855 <p><i>[Tokyo: The LWG agrees that this is a defect and notes that it
2856 occurs additional places in the section, all requiring fixes.]</i></p>
2857
2858
2859
2860
2861
2862
2863
2864
2865 <hr>
2866 <h3><a name="218"></a>218. Algorithms do not use binary predicate objects for default comparisons</h3>
2867 <p><b>Section:</b> 25.5 [alg.sorting] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
2868  <b>Submitter:</b> Pablo Halpern <b>Opened:</b> 2000-03-06  <b>Last modified:</b> 2006-12-27</p>
2869 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.sorting">issues</a> in [alg.sorting].</p>
2870 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2871 <p><b>Discussion:</b></p>
2872 <p>Many of the algorithms take an argument, pred, of template parameter type
2873 BinaryPredicate or an argument comp of template parameter type Compare. These
2874 algorithms usually have an overloaded version that does not take the predicate
2875 argument. In these cases pred is usually replaced by the use of operator== and
2876 comp is replaced by the use of operator&lt;.</p>
2877 <p>This use of hard-coded operators is inconsistent with other parts of the
2878 library, particularly the containers library, where equality is established
2879 using equal_to&lt;&gt; and ordering is established using less&lt;&gt;. Worse,
2880 the use of operator&lt;, would cause the following innocent-looking code to have
2881 undefined behavior:</p>
2882 <blockquote>
2883   <pre>vector&lt;string*&gt; vec;
2884 sort(vec.begin(), vec.end());</pre>
2885 </blockquote>
2886 <p>The use of operator&lt; is not defined for pointers to unrelated objects. If
2887 std::sort used less&lt;&gt; to compare elements, then the above code would be
2888 well-defined, since less&lt;&gt; is explicitly specialized to produce a total
2889 ordering of pointers.</p>
2890
2891
2892 <p><b>Rationale:</b></p>
2893 <p>This use of operator== and operator&lt; was a very deliberate, conscious, and
2894 explicitly made design decision; these operators are often more efficient. The
2895 predicate forms are available for users who don't want to rely on operator== and
2896 operator&lt;.</p>
2897
2898
2899
2900
2901 <hr>
2902 <h3><a name="236"></a>236. ctype&lt;char&gt;::is() member modifies facet</h3>
2903 <p><b>Section:</b> 22.4.1.3.2 [facet.ctype.char.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
2904  <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 2000-04-24  <b>Last modified:</b> 2007-01-15</p>
2905 <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>
2906 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
2907 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#28">28</a></p>
2908 <p><b>Discussion:</b></p>
2909 <p>The description of the <tt>is()</tt> member in paragraph 4 of 22.4.1.3.2 [facet.ctype.char.members] is broken: According to this description, the
2910 second form of the <tt>is()</tt> method modifies the masks in the
2911 <tt>ctype</tt> object. The correct semantics if, of course, to obtain
2912 an array of masks. The corresponding method in the general case,
2913 ie. the <tt>do_is()</tt> method as described in 22.4.1.1.2 [locale.ctype.virtuals] paragraph 1 does the right thing.</p>
2914
2915
2916 <p><b>Proposed resolution:</b></p>
2917   <p>Change paragraph 4 from</p>
2918     <blockquote><p>
2919     The second form, for all *p in the range [low, high), assigns
2920     vec[p-low] to table()[(unsigned char)*p].
2921     </p></blockquote>
2922   <p>to become</p>
2923     <blockquote><p>
2924     The second form, for all *p in the range [low, high), assigns
2925     table()[(unsigned char)*p] to vec[p-low].
2926   </p></blockquote>
2927
2928
2929 <p><b>Rationale:</b></p>
2930
2931
2932
2933
2934
2935 <hr>
2936 <h3><a name="244"></a>244. Must <tt>find</tt>'s third argument be CopyConstructible?</h3>
2937 <p><b>Section:</b> 25.3.5 [alg.find] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
2938  <b>Submitter:</b> Andrew Koenig <b>Opened:</b> 2000-05-02  <b>Last modified:</b> 2006-12-27</p>
2939 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.find">issues</a> in [alg.find].</p>
2940 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2941 <p><b>Discussion:</b></p>
2942 <p>Is the following implementation of <tt>find</tt> acceptable?</p>
2943
2944 <pre>        template&lt;class Iter, class X&gt;
2945         Iter find(Iter begin, Iter end, const X&amp; x)
2946         {
2947             X x1 = x;           // this is the crucial statement
2948             while (begin != end &amp;&amp; *begin != x1)
2949                 ++begin;
2950             return begin;
2951         }
2952 </pre>
2953
2954 <p>If the answer is yes, then it is implementation-dependent as to
2955 whether the following fragment is well formed:</p>
2956
2957 <pre>        vector&lt;string&gt; v;
2958
2959         find(v.begin(), v.end(), "foo");
2960 </pre>
2961
2962 <p>At issue is whether there is a requirement that the third argument
2963 of find be CopyConstructible.  There may be no problem here, but
2964 analysis is necessary.</p>
2965
2966
2967 <p><b>Rationale:</b></p>
2968 <p>There is no indication in the standard that find's third argument
2969 is required to be Copy Constructible.  The LWG believes that no such
2970 requirement was intended.  As noted above, there are times when a user
2971 might reasonably pass an argument that is not Copy Constructible.</p>
2972
2973
2974
2975
2976 <hr>
2977 <h3><a name="245"></a>245. Which operations on <tt>istream_iterator</tt> trigger input operations?</h3>
2978 <p><b>Section:</b> 24.6.1 [istream.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
2979  <b>Submitter:</b> Andrew Koenig <b>Opened:</b> 2000-05-02  <b>Last modified:</b> 2006-12-27</p>
2980 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#istream.iterator">active issues</a> in [istream.iterator].</p>
2981 <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>
2982 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2983 <p><b>Discussion:</b></p>
2984 <p>I do not think the standard specifies what operation(s) on istream
2985 iterators trigger input operations.  So, for example:</p>
2986
2987 <pre>        istream_iterator&lt;int&gt; i(cin);
2988
2989         int n = *i++;
2990 </pre>
2991
2992 <p>I do not think it is specified how many integers have been read
2993 from cin.  The number must be at least 1, of course, but can it be 2?
2994 More?</p>
2995
2996
2997 <p><b>Rationale:</b></p>
2998 <p>The standard is clear as written: the stream is read every time
2999 operator++ is called, and it is also read either when the iterator is
3000 constructed or when operator* is called for the first time.  In the
3001 example above, exactly two integers are read from cin.</p>
3002
3003 <p>There may be a problem with the interaction between istream_iterator
3004 and some STL algorithms, such as find.  There are no guarantees about
3005 how many times find may invoke operator++.</p>
3006
3007
3008
3009
3010 <hr>
3011 <h3><a name="246"></a>246. <tt>a.insert(p,t)</tt> is incorrectly specified</h3>
3012 <p><b>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
3013  <b>Submitter:</b> Mark Rodgers <b>Opened:</b> 2000-05-19  <b>Last modified:</b> 2007-01-15</p>
3014 <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>
3015 <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>
3016 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
3017 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a></p>
3018 <p><b>Discussion:</b></p>
3019 <p>Closed issue 192 raised several problems with the specification of
3020 this function, but was rejected as Not A Defect because it was too big
3021 a change with unacceptable impacts on existing implementations.
3022 However, issues remain that could be addressed with a smaller change
3023 and with little or no consequent impact.</p>
3024
3025 <ol>
3026    <li><p> The specification is inconsistent with the original
3027    proposal and with several implementations.</p>
3028
3029    <p>The initial implementation by Hewlett Packard only ever looked
3030    immediately <i>before</i> p, and I do not believe there was any
3031    intention to standardize anything other than this behavior.
3032    Consequently, current implementations by several leading
3033    implementors also look immediately before p, and will only insert
3034    after p in logarithmic time.  I am only aware of one implementation
3035    that does actually look after p, and it looks before p as well.  It
3036    is therefore doubtful that existing code would be relying on the
3037    behavior defined in the standard, and it would seem that fixing
3038    this defect as proposed below would standardize existing
3039    practice.</p></li>
3040
3041    <li><p>
3042    The specification is inconsistent with insertion for sequence
3043    containers.</p>
3044
3045    <p>This is difficult and confusing to teach to newcomers.  All
3046    insert operations that specify an iterator as an insertion location
3047    should have a consistent meaning for the location represented by
3048    that iterator.</p></li>
3049
3050    <li><p> As specified, there is no way to hint that the insertion
3051    should occur at the beginning of the container, and the way to hint
3052    that it should occur at the end is long winded and unnatural.</p>
3053
3054    <p>For a container containing n elements, there are n+1 possible
3055    insertion locations and n+1 valid iterators.  For there to be a
3056    one-to-one mapping between iterators and insertion locations, the
3057    iterator must represent an insertion location immediately before
3058    the iterator.</p></li>
3059
3060    <li><p> When appending sorted ranges using insert_iterators,
3061    insertions are guaranteed to be sub-optimal.</p>
3062
3063    <p>In such a situation, the optimum location for insertion is
3064    always immediately after the element previously inserted.  The
3065    mechanics of the insert iterator guarantee that it will try and
3066    insert after the element after that, which will never be correct.
3067    However, if the container first tried to insert before the hint,
3068    all insertions would be performed in amortized constant
3069    time.</p></li>
3070 </ol>
3071
3072
3073 <p><b>Proposed resolution:</b></p>
3074 <p>In 23.1.2 [lib.associative.reqmts] paragraph 7, table 69, make
3075 the following changes in the row for a.insert(p,t):</p>
3076
3077 <p><i>assertion/note pre/post condition:</i>
3078 <br>Change the last sentence from</p>
3079      <blockquote><p>
3080      "iterator p is a hint pointing to where the insert should
3081      start to search."
3082      </p></blockquote>
3083 <p>to</p>
3084      <blockquote><p>
3085      "iterator p is a hint indicating that immediately before p
3086      may be a correct location where the insertion could occur."
3087      </p></blockquote>
3088
3089 <p><i>complexity:</i><br>
3090 Change the words "right after" to "immediately before".</p>
3091
3092
3093 <p><b>Rationale:</b></p>
3094
3095
3096
3097
3098
3099 <hr>
3100 <h3><a name="249"></a>249. Return Type of <tt>auto_ptr::operator=</tt></h3>
3101 <p><b>Section:</b> D.9.1 [auto.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
3102  <b>Submitter:</b> Joseph Gottman <b>Opened:</b> 2000-06-30  <b>Last modified:</b> 2006-12-29</p>
3103 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#auto.ptr">active issues</a> in [auto.ptr].</p>
3104 <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>
3105 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3106 <p><b>Discussion:</b></p>
3107 <p>According to section 20.4.5, the function
3108 <tt>auto_ptr::operator=()</tt> returns a reference to an auto_ptr.
3109 The reason that <tt>operator=()</tt> usually returns a reference is to
3110 facilitate code like</p>
3111
3112 <pre>    int x,y,z;
3113     x = y = z = 1;
3114 </pre>
3115
3116 <p>However, given analogous code for <tt>auto_ptr</tt>s,</p>
3117 <pre>    auto_ptr&lt;int&gt; x, y, z;
3118     z.reset(new int(1));
3119     x = y = z;
3120 </pre>
3121
3122 <p>the result would be that <tt>z</tt> and <tt>y</tt> would both be set to
3123 NULL, instead of all the <tt>auto_ptr</tt>s being set to the same value.
3124 This makes such cascading assignments useless and counterintuitive for
3125 <tt>auto_ptr</tt>s.</p>
3126
3127
3128 <p><b>Proposed resolution:</b></p>
3129 <p>Change <tt>auto_ptr::operator=()</tt> to return <tt>void</tt> instead
3130 of an <tt>auto_ptr</tt> reference.</p>
3131
3132
3133 <p><b>Rationale:</b></p>
3134 <p>The return value has uses other than cascaded assignments: a user can
3135 call an auto_ptr member function, pass the auto_ptr to a
3136 function, etc.  Removing the return value could break working user
3137 code.</p>
3138
3139
3140
3141
3142 <hr>
3143 <h3><a name="257"></a>257. STL functional object and iterator inheritance.</h3>
3144 <p><b>Section:</b> 20.7.3 [base], D.10.2 [iterator.basic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
3145  <b>Submitter:</b> Robert Dick  <b>Opened:</b> 2000-08-17  <b>Last modified:</b> 2006-12-29</p>
3146 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#base">issues</a> in [base].</p>
3147 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3148 <p><b>Discussion:</b></p>
3149 <p>
3150 According to the November 1997 Draft Standard, the results of deleting an
3151 object of a derived class through a pointer to an object of its base class are
3152 undefined if the base class has a non-virtual destructor.  Therefore, it is
3153 potentially dangerous to publicly inherit from such base classes.
3154 </p>
3155
3156 <p>Defect:
3157 <br>
3158 The STL design encourages users to publicly inherit from a number of classes
3159 which do nothing but specify interfaces, and which contain non-virtual
3160 destructors.
3161 </p>
3162
3163 <p>Attribution:
3164 <br>
3165 Wil Evers and William E. Kempf suggested this modification for functional
3166 objects.
3167 </p>
3168
3169
3170 <p><b>Proposed resolution:</b></p>
3171 <p>
3172 When a base class in the standard library is useful only as an interface
3173 specifier, i.e., when an object of the class will never be directly
3174 instantiated, specify that the class contains a protected destructor.  This
3175 will prevent deletion through a pointer to the base class without performance,
3176 or space penalties (on any implementation I'm aware of).
3177 </p>
3178
3179 <p>
3180 As an example, replace...
3181 </p>
3182
3183 <pre>    template &lt;class Arg, class Result&gt;
3184     struct unary_function {
3185             typedef Arg    argument_type;
3186             typedef Result result_type;
3187     };
3188 </pre>
3189
3190 <p>
3191 ... with...
3192 </p>
3193
3194 <pre>    template &lt;class Arg, class Result&gt;
3195     struct unary_function {
3196             typedef Arg    argument_type;
3197             typedef Result result_type;
3198     protected:
3199             ~unary_function() {}
3200     };
3201 </pre>
3202
3203 <p>
3204 Affected definitions:
3205 <br>
3206   &nbsp;20.3.1 [lib.function.objects] -- unary_function, binary_function
3207   <br>
3208   &nbsp;24.3.2 [lib.iterator.basic] -- iterator
3209 </p>
3210
3211
3212 <p><b>Rationale:</b></p>
3213 <p>
3214 The standard is clear as written; this is a request for change, not a
3215 defect in the strict sense.  The LWG had several different objections
3216 to the proposed change.  One is that it would prevent users from
3217 creating objects of type <tt>unary_function</tt> and
3218 <tt>binary_function</tt>.  Doing so can sometimes be legitimate, if users
3219 want to pass temporaries as traits or tag types in generic code.
3220 </p>
3221
3222
3223
3224
3225
3226 <hr>
3227 <h3><a name="267"></a>267. interaction of strstreambuf::overflow() and seekoff()</h3>
3228 <p><b>Section:</b> D.7.1.3 [depr.strstreambuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
3229  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-10-05  <b>Last modified:</b> 2007-01-15</p>
3230 <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>
3231 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3232 <p><b>Discussion:</b></p>
3233 <p>
3234 It appears that the interaction of the strstreambuf members overflow()
3235 and seekoff() can lead to undefined behavior in cases where defined
3236 behavior could reasonably be expected. The following program
3237 demonstrates this behavior:
3238 </p>
3239
3240 <pre>    #include &lt;strstream&gt;
3241
3242     int main ()
3243     {
3244          std::strstreambuf sb;
3245          sb.sputc ('c');
3246
3247          sb.pubseekoff (-1, std::ios::end, std::ios::in);
3248          return !('c' == sb.sgetc ());
3249     }
3250 </pre>
3251
3252 <p>
3253 D.7.1.1, p1 initializes strstreambuf with a call to basic_streambuf&lt;&gt;(),
3254 which in turn sets all pointers to 0 in 27.5.2.1, p1.
3255 </p>
3256
3257 <p>
3258 27.5.2.2.5, p1 says that basic_streambuf&lt;&gt;::sputc(c) calls
3259 overflow(traits::to_int_type(c)) if a write position isn't available (it
3260 isn't due to the above).
3261 </p>
3262
3263 <p>
3264 D.7.1.3, p3 says that strstreambuf::overflow(off, ..., ios::in) makes at
3265 least one write position available (i.e., it allows the function to make
3266 any positive number of write positions available).
3267 </p>
3268
3269 <p>
3270 D.7.1.3, p13 computes newoff = seekhigh - eback(). In D.7.1, p4 we see
3271 seekhigh = epptr() ? epptr() : egptr(), or seekhigh = epptr() in this
3272 case. newoff is then epptr() - eback().
3273 </p>
3274
3275 <p>
3276 D.7.1.4, p14 sets gptr() so that gptr() == eback() + newoff + off, or
3277 gptr() == epptr() + off holds.
3278 </p>
3279
3280 <p>
3281 If strstreambuf::overflow() made exactly one write position available
3282 then gptr() will be set to just before epptr(), and the program will
3283 return 0. Buf if the function made more than one write position
3284 available, epptr() and gptr() will both point past pptr() and the
3285 behavior of the program is undefined.
3286 </p>
3287
3288
3289 <p><b>Proposed resolution:</b></p>
3290
3291
3292    <p>Change the last sentence of D.7.1 [depr.strstreambuf] paragraph 4 from</p>
3293
3294       <blockquote><p>
3295       Otherwise, seeklow equals gbeg and seekhigh is either pend, if
3296       pend is not a null pointer, or gend.
3297       </p></blockquote>
3298
3299    <p>to become</p>
3300
3301       <blockquote><p>
3302       Otherwise, seeklow equals gbeg and seekhigh is either gend if
3303       0 == pptr(), or pbase() + max where max is the maximum value of
3304       pptr() - pbase() ever reached for this stream.
3305       </p></blockquote>
3306
3307 <p><i>[
3308   pre-Copenhagen: Dietmar provided wording for proposed resolution.
3309 ]</i></p>
3310
3311
3312 <p><i>[
3313   post-Copenhagen: Fixed a typo: proposed resolution said to fix
3314   4.7.1, not D.7.1.
3315 ]</i></p>
3316
3317
3318
3319
3320 <p><b>Rationale:</b></p>
3321 <p>This is related to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#65">65</a>: it's not clear what it
3322 means to seek beyond the current area.  Without resolving issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#65">65</a> we can't resolve this.  As with issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#65">65</a>,
3323 the library working group does not wish to invest time nailing down
3324 corner cases in a deprecated feature.</p>
3325
3326
3327
3328
3329
3330 <hr>
3331 <h3><a name="269"></a>269. cstdarg and unnamed parameters</h3>
3332 <p><b>Section:</b> 18.8 [support.exception] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
3333  <b>Submitter:</b> J. Stephen Adamczyk <b>Opened:</b> 2000-10-10  <b>Last modified:</b> 2006-12-27</p>
3334 <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>
3335 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3336 <p><b>Discussion:</b></p>
3337 <p>
3338 One of our customers asks whether this is valid C++:
3339 </p>
3340
3341 <pre>   #include &lt;cstdarg&gt;
3342
3343    void bar(const char *, va_list);
3344
3345    void
3346    foo(const char *file, const char *, ...)
3347    {
3348      va_list ap;
3349      va_start(ap, file);
3350      bar(file, ap);
3351      va_end(ap);
3352    }
3353 </pre>
3354
3355 <p>
3356 The issue being whether it is valid to use cstdarg when the final
3357 parameter before the "..." is unnamed.  cstdarg is, as far
3358 as I can tell, inherited verbatim from the C standard. and the
3359 definition there (7.8.1.1 in the ISO C89 standard) refers to "the
3360 identifier of the rightmost parameter".  What happens when there
3361 is no such identifier?
3362 </p>
3363
3364 <p>
3365 My personal opinion is that this should be allowed, but some tweak
3366 might be required in the C++ standard.
3367 </p>
3368
3369
3370 <p><b>Rationale:</b></p>
3371 <p>
3372 Not a defect, the C and C++ standards are clear.  It is impossible to
3373 use varargs if the parameter immediately before "..." has no
3374 name, because that is the parameter that must be passed to va_start.
3375 The example given above is broken, because va_start is being passed
3376 the wrong parameter.
3377 </p>
3378
3379 <p>
3380 There is no support for extending varargs to provide additional
3381 functionality beyond what's currently there.  For reasons of C/C++
3382 compatibility, it is especially important not to make gratuitous
3383 changes in this part of the C++ standard.  The C committee has already
3384 been requested not to touch this part of the C standard unless
3385 necessary.
3386 </p>
3387
3388
3389
3390
3391 <hr>
3392 <h3><a name="277"></a>277. Normative encouragement in allocator requirements unclear</h3>
3393 <p><b>Section:</b> X [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
3394  <b>Submitter:</b> Matt Austern <b>Opened:</b> 2000-11-07  <b>Last modified:</b> 2006-12-30</p>
3395 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p>
3396 <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>
3397 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3398 <p><b>Discussion:</b></p>
3399 <p>
3400 In 20.1.5, paragraph 5, the standard says that "Implementors are
3401 encouraged to supply libraries that can accept allocators that
3402 encapsulate more general memory models and that support non-equal
3403 instances." This is intended as normative encouragement to
3404 standard library implementors.  However, it is possible to interpret
3405 this sentence as applying to nonstandard third-party libraries.
3406 </p>
3407
3408
3409 <p><b>Proposed resolution:</b></p>
3410 <p>
3411 In 20.1.5, paragraph 5, change "Implementors" to
3412 "Implementors of the library described in this International
3413 Standard".
3414 </p>
3415
3416
3417 <p><b>Rationale:</b></p>
3418 <p>The LWG believes the normative encouragement is already
3419 sufficiently clear, and that there are no important consequences
3420 even if it is misunderstood.</p>
3421
3422
3423
3424
3425
3426 <hr>
3427 <h3><a name="279"></a>279. const and non-const iterators should have equivalent typedefs</h3>
3428 <p><b>Section:</b> 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
3429  <b>Submitter:</b> Steve Cleary <b>Opened:</b> 2000-11-27  <b>Last modified:</b> 2006-12-27</p>
3430 <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>
3431 <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>
3432 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3433 <p><b>Discussion:</b></p>
3434
3435 <p>
3436 This came from an email from Steve Cleary to Fergus in reference to
3437 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#179">179</a>. The library working group briefly discussed
3438 this in Toronto and believes it should be a separate issue.
3439 </p>
3440
3441 <p>
3442 Steve said: "We may want to state that the const/non-const iterators must have
3443 the same difference type, size_type, and category."
3444 </p>
3445
3446 <p>
3447 (Comment from Judy)
3448 I'm not sure if the above sentence should be true for all
3449 const and non-const iterators in a particular container, or if it means
3450 the container's iterator can't be compared with the container's
3451 const_iterator unless the above it true. I suspect the former.
3452 </p>
3453
3454
3455 <p><b>Proposed resolution:</b></p>
3456 <p>
3457 In <b>Section:</b> 23.2 [container.requirements],
3458 table 65, in the assertion/note pre/post condition for X::const_iterator,
3459 add the following:
3460 </p>
3461
3462 <blockquote>
3463 <p>
3464 typeid(X::const_iterator::difference_type) == typeid(X::iterator::difference_type)
3465 </p>
3466
3467 <p>
3468 typeid(X::const_iterator::size_type) == typeid(X::iterator::size_type)
3469 </p>
3470
3471 <p>
3472 typeid(X::const_iterator::category) == typeid(X::iterator::category)
3473 </p>
3474 </blockquote>
3475
3476
3477 <p><b>Rationale:</b></p>
3478 <p>Going through the types one by one: Iterators don't have a
3479 <tt>size_type</tt>.  We already know that the difference types are
3480 identical, because the container requirements already say that the
3481 difference types of both X::iterator and X::const_iterator are both
3482 X::difference_type.  The standard does not require that X::iterator
3483 and X::const_iterator have the same iterator category, but the LWG
3484 does not see this as a defect: it's possible to imagine cases in which
3485 it would be useful for the categories to be different.</p>
3486
3487 <p>It may be desirable to require X::iterator and X::const_iterator to
3488 have the same value type, but that is a new issue. (Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#322">322</a>.)</p>
3489
3490
3491
3492
3493
3494
3495 <hr>
3496 <h3><a name="287"></a>287. conflicting ios_base fmtflags</h3>
3497 <p><b>Section:</b> 27.5.2.2 [fmtflags.state] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
3498  <b>Submitter:</b> Judy Ward <b>Opened:</b> 2000-12-30  <b>Last modified:</b> 2006-12-27</p>
3499 <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>
3500 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3501 <p><b>Discussion:</b></p>
3502 <p>
3503 The Effects clause for ios_base::setf(fmtflags fmtfl) says
3504 "Sets fmtfl in flags()".  What happens if the user first calls
3505 ios_base::scientific and then calls ios_base::fixed or vice-versa?
3506 This is an issue for all of the conflicting flags, i.e. ios_base::left
3507 and ios_base::right or ios_base::dec, ios_base::hex and ios_base::oct.
3508 </p>
3509
3510 <p>
3511 I see three possible solutions:
3512 </p>
3513
3514 <ol>
3515 <li>Set ios_base::failbit whenever the user specifies a conflicting
3516 flag with one previously explicitly set. If the constructor is
3517 supposed to set ios_base::dec (see discussion below), then
3518 the user setting hex or oct format after construction will not
3519 set failbit. </li>
3520 <li>The last call to setf "wins", i.e. it clears any conflicting
3521 previous setting.</li>
3522 <li>All the flags that the user specifies are set, but when actually
3523 interpreting them, fixed always override scientific, right always
3524 overrides left, dec overrides hex which overrides oct.</li>
3525 </ol>
3526
3527 <p>
3528 Most existing implementations that I tried seem to conform to resolution #3,
3529 except that when using the iomanip manipulator hex or oct then that always
3530 overrides dec, but calling setf(ios_base::hex) doesn't.
3531 </p>
3532
3533 <p>
3534 There is a sort of related issue, which is that although the ios_base
3535 constructor says that each ios_base member has an indeterminate value
3536 after construction, all the existing implementations I tried explicitly set
3537 ios_base::dec.
3538 </p>
3539
3540
3541 <p><b>Proposed resolution:</b></p>
3542
3543
3544 <p><b>Rationale:</b></p>
3545 <p>
3546 <tt>adjustfield</tt>, <tt>basefield</tt>, and <tt>floatfield</tt>
3547 are each multi-bit fields.  It is possible to set multiple bits within
3548 each of those fields.  (For example, <tt>dec</tt> and
3549 <tt>oct</tt>). These fields are used by locale facets. The LWG
3550 reviewed the way in which each of those three fields is used, and
3551 believes that in each case the behavior is well defined for any
3552 possible combination of bits. See for example Table 58, in 22.4.2.2.2
3553 [facet.num.put.virtuals], noting the requirement in paragraph 6 of that
3554 section.
3555 </p>
3556 <p>
3557 Users are advised to use manipulators, or else use the two-argument
3558 version of <tt>setf</tt>, to avoid unexpected behavior.
3559 </p>
3560
3561
3562
3563
3564
3565 <hr>
3566 <h3><a name="289"></a>289. &lt;cmath&gt; requirements missing C float and long double versions</h3>
3567 <p><b>Section:</b> 26.8 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
3568  <b>Submitter:</b> Judy Ward <b>Opened:</b> 2000-12-30  <b>Last modified:</b> 2007-01-15</p>
3569 <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>
3570 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3571 <p><b>Discussion:</b></p>
3572 <p>
3573     In ISO/IEC 9899:1990 Programming Languages C we find the following
3574     concerning &lt;math.h&gt;:
3575 </p>
3576
3577 <blockquote><p>
3578          7.13.4 Mathematics &lt;math.h&gt;
3579          <br>
3580          The names of all existing functions declared in the &lt;math.h&gt;
3581          header, suffixed with f or l, are reserved respectively for
3582          corresponding functions with float and long double arguments
3583          are return values.
3584 </p></blockquote>
3585
3586 <p>
3587     For example, <tt>float&nbsp;sinf(float)</tt>
3588     is reserved.
3589 </p>
3590
3591 <p>
3592     In the C99 standard, &lt;math.h&gt; must contain declarations
3593     for these functions.
3594 </p>
3595
3596 <p>
3597 So, is it acceptable for an implementor to add these prototypes to the
3598 C++ versions of the math headers? Are they required?
3599 </p>
3600
3601
3602 <p><b>Proposed resolution:</b></p>
3603 <p>
3604 Add these Functions to Table 80, section 26.5 and to Table 99,
3605 section C.2:
3606 </p>
3607
3608 <pre>    acosf asinf atanf atan2f ceilf cosf coshf
3609     expf fabsf floorf fmodf frexpf ldexpf
3610     logf log10f modff powf sinf sinhf sqrtf
3611     tanf tanhf
3612     acosl asinl atanl atan2l ceill cosl coshl
3613     expl fabsl floorl fmodl frexpl ldexpl
3614     logl log10l modfl powl sinl sinhl sqrtl
3615     tanl tanhl
3616 </pre>
3617
3618 <p>
3619 There should probably be a note saying that these functions
3620 are optional and, if supplied, should match the description in
3621 the 1999 version of the C standard. In the next round
3622 of C++ standardization they can then become mandatory.
3623 </p>
3624
3625
3626 <p><b>Rationale:</b></p>
3627 <p>The C90 standard, as amended, already permits (but does not
3628 require) these functions, and the C++ standard incorporates the
3629 C90 standard by reference.  C99 is not an issue, because it is
3630 never referred to by the C++ standard.</p>
3631
3632
3633
3634
3635
3636 <hr>
3637 <h3><a name="293"></a>293. Order of execution in transform algorithm</h3>
3638 <p><b>Section:</b> 25.4.4 [alg.transform] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
3639  <b>Submitter:</b> Angelika Langer <b>Opened:</b> 2001-01-04  <b>Last modified:</b> 2007-01-15</p>
3640 <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>
3641 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3642 <p><b>Discussion:</b></p>
3643 <p>This issue is related to issue 242.  In case that the resolution
3644 proposed for issue 242 is accepted, we have have the following
3645 situation: The 4 numeric algorithms (accumulate and consorts) as well
3646 as transform would allow a certain category of side effects.  The
3647 numeric algorithms specify that they invoke the functor "for
3648 every iterator i in the range [first, last) in order". transform,
3649 in contrast, would not give any guarantee regarding order of
3650 invocation of the functor, which means that the functor can be invoked
3651 in any arbitrary order.
3652 </p>
3653
3654 <p>Why would that be a problem?  Consider an example: say the
3655 transformator that is a simple enumerator ( or more generally
3656 speaking, "is order-sensitive" ).  Since a standard
3657 compliant implementation of transform is free to invoke the enumerator
3658 in no definite order, the result could be a garbled enumeration.
3659 Strictly speaking this is not a problem, but it is certainly at odds
3660 with the prevalent understanding of transform as an algorithms that
3661 assigns "a new _corresponding_ value" to the output
3662 elements.
3663 </p>
3664
3665 <p>All implementations that I know of invoke the transformator in
3666 definite order, namely starting from first and proceeding to last -
3667 1. Unless there is an optimization conceivable that takes advantage of
3668 the indefinite order I would suggest to specify the order, because it
3669 eliminate the uncertainty that users would otherwise have regarding
3670 the order of execution of their potentially order-sensitive function
3671 objects.
3672 </p>
3673
3674
3675 <p><b>Proposed resolution:</b></p>
3676 <p>In section 25.2.3 - Transform [lib.alg.transform] change:</p>
3677 <blockquote><p>
3678 -1- Effects: Assigns through every iterator i in the range [result,
3679 result + (last1 - first1)) a new corresponding
3680 value equal to op(*(first1 + (i - result)) or binary_op(*(first1 +
3681 (i - result), *(first2 + (i - result))).
3682 </p></blockquote>
3683 <p>to:</p>
3684 <blockquote><p>
3685 -1- Effects: Computes values by  invoking the operation op or binary_op
3686 for every iterator in the range [first1, last1) in order. Assigns through
3687 every iterator i in the range [result, result + (last1 - first1)) a new
3688 corresponding
3689 value equal to op(*(first1 + (i - result)) or binary_op(*(first1 +
3690 (i - result), *(first2 + (i - result))).
3691 </p></blockquote>
3692
3693
3694 <p><b>Rationale:</b></p>
3695 <p>For Input Iterators an order is already guaranteed, because
3696 only one order is possible.  If a user who passes a Forward
3697 Iterator to one of these algorithms really needs a specific
3698 order of execution, it's possible to achieve that effect by
3699 wrapping it in an Input Iterator adaptor.</p>
3700
3701
3702
3703
3704
3705 <hr>
3706 <h3><a name="296"></a>296. Missing descriptions and requirements of pair operators</h3>
3707 <p><b>Section:</b> 20.3.3 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
3708  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-01-14  <b>Last modified:</b> 2006-12-27</p>
3709 <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>
3710 <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>
3711 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3712 <p><b>Discussion:</b></p>
3713 <p>The synopsis of the header <tt>&lt;utility&gt;</tt> in 20.3 [utility]
3714 lists the complete set of equality and relational operators for <tt>pair</tt>
3715 but the section describing the template and the operators only describes
3716 <tt>operator==()</tt> and <tt>operator&lt;()</tt>, and it fails to mention
3717 any requirements on the template arguments. The remaining operators are
3718 not mentioned at all.
3719 </p>
3720
3721
3722 <p><b>Rationale:</b></p>
3723 <p>20.3.1 [operators] paragraph 10 already specifies the semantics.
3724 That paragraph says that, if declarations of operator!=, operator&gt;,
3725 operator&lt;=, and operator&gt;= appear without definitions, they are
3726 defined as specified in 20.3.1 [operators].  There should be no user
3727 confusion, since that paragraph happens to immediately precede the
3728 specification of <tt>pair</tt>.</p>
3729
3730
3731
3732
3733
3734 <hr>
3735 <h3><a name="299"></a>299. Incorrect return types for iterator dereference</h3>
3736 <p><b>Section:</b> 24.2.5 [bidirectional.iterators], 24.2.6 [random.access.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
3737  <b>Submitter:</b> John Potter <b>Opened:</b> 2001-01-22  <b>Last modified:</b> 2008-09-26</p>
3738 <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>
3739 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
3740 <p><b>Discussion:</b></p>
3741 <p>
3742 In section 24.2.5 [bidirectional.iterators],
3743 Table 75 gives the return type of *r-- as convertible to T.  This is
3744 not consistent with Table 74 which gives the return type of *r++ as
3745 T&amp;.  *r++ = t is valid while *r-- = t is invalid.
3746 </p>
3747
3748 <p>
3749 In section 24.2.6 [random.access.iterators],
3750 Table 76 gives the return type of a[n] as convertible to T.  This is
3751 not consistent with the semantics of *(a + n) which returns T&amp; by
3752 Table 74.  *(a + n) = t is valid while a[n] = t is invalid.
3753 </p>
3754
3755 <p>
3756 Discussion from the Copenhagen meeting: the first part is
3757 uncontroversial.  The second part, operator[] for Random Access
3758 Iterators, requires more thought.  There are reasonable arguments on
3759 both sides.  Return by value from operator[] enables some potentially
3760 useful iterators, e.g. a random access "iota iterator" (a.k.a
3761 "counting iterator" or "int iterator").  There isn't any obvious way
3762 to do this with return-by-reference, since the reference would be to a
3763 temporary.  On the other hand, <tt>reverse_iterator</tt> takes an
3764 arbitrary Random Access Iterator as template argument, and its
3765 operator[] returns by reference.  If we decided that the return type
3766 in Table 76 was correct, we would have to change
3767 <tt>reverse_iterator</tt>.  This change would probably affect user
3768 code.
3769 </p>
3770
3771 <p>
3772 History: the contradiction between <tt>reverse_iterator</tt> and the
3773 Random Access Iterator requirements has been present from an early
3774 stage.  In both the STL proposal adopted by the committee
3775 (N0527==94-0140) and the STL technical report (HPL-95-11 (R.1), by
3776 Stepanov and Lee), the Random Access Iterator requirements say that
3777 operator[]'s return value is "convertible to T".  In N0527
3778 reverse_iterator's operator[] returns by value, but in HPL-95-11
3779 (R.1), and in the STL implementation that HP released to the public,
3780 reverse_iterator's operator[] returns by reference.  In 1995, the
3781 standard was amended to reflect the contents of HPL-95-11 (R.1).  The
3782 original intent for operator[] is unclear.
3783 </p>
3784
3785 <p>
3786 In the long term it may be desirable to add more fine-grained
3787 iterator requirements, so that access method and traversal strategy
3788 can be decoupled.  (See "Improved Iterator Categories and
3789 Requirements", N1297 = 01-0011, by Jeremy Siek.)  Any decisions
3790 about issue 299 should keep this possibility in mind.
3791 </p>
3792
3793 <p>Further discussion: I propose a compromise between John Potter's
3794 resolution, which requires <tt>T&amp;</tt> as the return type of
3795 <tt>a[n]</tt>, and the current wording, which requires convertible to
3796 <tt>T</tt>. The compromise is to keep the convertible to <tt>T</tt>
3797 for the return type of the expression <tt>a[n]</tt>, but to also add
3798 <tt>a[n] = t</tt> as a valid expression. This compromise "saves" the
3799 common case uses of random access iterators, while at the same time
3800 allowing iterators such as counting iterator and caching file
3801 iterators to remain random access iterators (iterators where the
3802 lifetime of the object returned by <tt>operator*()</tt> is tied to the
3803 lifetime of the iterator).
3804 </p>
3805
3806 <p>
3807 Note that the compromise resolution necessitates a change to
3808 <tt>reverse_iterator</tt>. It would need to use a proxy to support
3809 <tt>a[n] = t</tt>.
3810 </p>
3811
3812 <p>
3813 Note also there is one kind of mutable random access iterator that
3814 will no longer meet the new requirements. Currently, iterators that
3815 return an r-value from <tt>operator[]</tt> meet the requirements for a
3816 mutable random access iterartor, even though the expression <tt>a[n] =
3817 t</tt> will only modify a temporary that goes away. With this proposed
3818 resolution, <tt>a[n] = t</tt> will be required to have the same
3819 operational semantics as <tt>*(a + n) = t</tt>.
3820 </p>
3821
3822
3823
3824 <p><b>Proposed resolution:</b></p>
3825
3826 <p>
3827 In section 24.1.4 [lib.bidirectdional.iterators], change the return
3828 type in table 75 from "convertible to <tt>T</tt>" to
3829 <tt>T&amp;</tt>.
3830 </p>
3831
3832 <p>
3833 In section 24.1.5 [lib.random.access.iterators], change the
3834 operational semantics for <tt>a[n]</tt> to " the r-value of
3835 <tt>a[n]</tt> is equivalent to the r-value of <tt>*(a +
3836 n)</tt>". Add a new row in the table for the expression <tt>a[n] = t</tt>
3837 with a return type of convertible to <tt>T</tt> and operational semantics of
3838 <tt>*(a + n) = t</tt>.
3839 </p>
3840
3841 <p><i>[Lillehammer: Real problem, but should be addressed as part of
3842   iterator redesign]</i></p>
3843
3844
3845
3846
3847 <p><b>Rationale:</b></p>
3848 <p><i>[
3849 San Francisco:
3850 ]</i></p>
3851
3852
3853 <blockquote>
3854 Solved by
3855 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2758.pdf">N2758</a>.
3856 </blockquote>
3857
3858
3859
3860
3861
3862
3863
3864 <hr>
3865 <h3><a name="302"></a>302. Need error indication from codecvt&lt;&gt;::do_length</h3>
3866 <p><b>Section:</b> 22.4.1.5 [locale.codecvt.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
3867  <b>Submitter:</b> Gregory Bumgardner <b>Opened:</b> 2001-01-25  <b>Last modified:</b> 2006-12-27</p>
3868 <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>
3869 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3870 <p><b>Discussion:</b></p>
3871 <p>
3872 The effects of <tt>codecvt&lt;&gt;::do_length()</tt> are described in
3873 22.2.1.5.2, paragraph 10.  As implied by that paragraph, and clarified
3874 in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#75">75</a>, <tt>codecvt&lt;&gt;::do_length()</tt> must
3875 process the source data and update the <tt>stateT</tt> argument just
3876 as if the data had been processed by <tt>codecvt&lt;&gt;::in()</tt>.
3877 However, the standard does not specify how <tt>do_length()</tt> would
3878 report a translation failure, should the source sequence contain
3879 untranslatable or illegal character sequences.
3880 </p>
3881
3882 <p>
3883 The other conversion methods return an "error" result value
3884 to indicate that an untranslatable character has been encountered, but
3885 <tt>do_length()</tt> already has a return value (the number of source
3886 characters that have been processed by the method).
3887 </p>
3888
3889
3890 <p><b>Proposed resolution:</b></p>
3891 <p>
3892 This issue cannot be resolved without modifying the interface. An exception
3893 cannot be used, as there would be no way to determine how many characters
3894 have been processed and the state object would be left in an indeterminate
3895 state.
3896 </p>
3897
3898 <p>
3899 A source compatible solution involves adding a fifth argument to length()
3900 and do_length() that could be used to return position of the offending
3901 character sequence. This argument would have a default value that would
3902 allow it to be ignored:
3903 </p>
3904
3905 <pre>  int length(stateT&amp; state,
3906              const externT* from,
3907              const externT* from_end,
3908              size_t max,
3909              const externT** from_next = 0);
3910
3911   virtual
3912   int do_length(stateT&amp; state,
3913                 const externT* from,
3914                 const externT* from_end,
3915                 size_t max,
3916                 const externT** from_next);
3917 </pre>
3918
3919 <p>
3920 Then an exception could be used to report any translation errors and
3921 the from_next argument, if used, could then be used to retrieve the
3922 location of the offending character sequence.
3923 </p>
3924
3925
3926 <p><b>Rationale:</b></p>
3927 <p>The standard is already clear: the return value is the number of
3928 "valid complete characters".  If it encounters an invalid sequence of
3929 external characters, it stops.</p>
3930
3931
3932
3933
3934
3935 <hr>
3936 <h3><a name="304"></a>304. Must <tt>*a</tt> return an lvalue when <tt>a</tt> is an input iterator?</h3>
3937 <p><b>Section:</b> 24.2 [iterator.concepts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
3938  <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2001-02-05  <b>Last modified:</b> 2008-09-30</p>
3939 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iterator.concepts">active issues</a> in [iterator.concepts].</p>
3940 <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>
3941 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3942 <p><b>Discussion:</b></p>
3943 <p>
3944 We all "know" that input iterators are allowed to produce
3945 values when dereferenced of which there is no other in-memory copy.
3946 </p>
3947
3948 <p>
3949 But: Table 72, with a careful reading, seems to imply that this can only be
3950 the case if the value_type has no members (e.g. is a built-in type).
3951 </p>
3952
3953 <p>The problem occurs in the following entry:</p>
3954
3955 <pre>  a-&gt;m     pre: (*a).m is well-defined
3956            Equivalent to (*a).m
3957 </pre>
3958
3959 <p>
3960 <tt>*a.m</tt> can be well-defined if <tt>*a</tt> is not a reference
3961 type, but since <tt>operator-&gt;()</tt> must return a pointer for
3962 <tt>a-&gt;m</tt> to be well-formed, it needs something to return a
3963 pointer <i>to</i>. This seems to indicate that <tt>*a</tt> must be
3964 buffered somewhere to make a legal input iterator.
3965 </p>
3966
3967 <p>I don't think this was intentional.</p>
3968
3969
3970 <p><b>Rationale:</b></p>
3971 <p>The current standard is clear and consistent.  Input iterators that
3972   return rvalues are in fact implementable.  They may in some cases
3973   require extra work, but it is still possible to define an operator-&gt;
3974   in such cases: it doesn't have to return a T*, but may return a
3975   proxy type.  No change to the standard is justified.</p>
3976
3977
3978
3979
3980
3981 <hr>
3982 <h3><a name="313"></a>313. set_terminate and set_unexpected question</h3>
3983 <p><b>Section:</b> 18.8.3.3 [terminate] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
3984  <b>Submitter:</b> Judy Ward <b>Opened:</b> 2001-04-03  <b>Last modified:</b> 2006-12-27</p>
3985 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#terminate">issues</a> in [terminate].</p>
3986 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3987 <p><b>Discussion:</b></p>
3988 <p>
3989 According to section 18.7.3.3 of the standard, std::terminate() is
3990 supposed to call the terminate_handler in effect immediately after
3991 evaluating the throw expression.
3992 </p>
3993
3994 <p>
3995 Question: what if the terminate_handler in effect is itself
3996 std::terminate?
3997 </p>
3998
3999 <p>For example:</p>
4000
4001 <pre>  #include &lt;exception&gt;
4002
4003   int main () {
4004       std::set_terminate(std::terminate);
4005       throw 5;
4006       return 0;
4007   }
4008 </pre>
4009
4010 <p>
4011 Is the implementation allowed to go into an infinite loop?
4012 </p>
4013
4014 <p>
4015 I think the same issue applies to std::set_unexpected.
4016 </p>
4017
4018
4019 <p><b>Proposed resolution:</b></p>
4020
4021
4022 <p><b>Rationale:</b></p>
4023 <p>Infinite recursion is to be expected: users who set the terminate
4024 handler to <tt>terminate</tt> are explicitly asking for <tt>terminate</tt>
4025 to call itself.</p>
4026
4027
4028
4029
4030
4031 <hr>
4032 <h3><a name="314"></a>314. Is the stack unwound when terminate() is called?</h3>
4033 <p><b>Section:</b> 18.8.3.3 [terminate] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
4034  <b>Submitter:</b> Detlef Vollmann <b>Opened:</b> 2001-04-11  <b>Last modified:</b> 2007-01-15</p>
4035 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#terminate">issues</a> in [terminate].</p>
4036 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
4037 <p><b>Discussion:</b></p>
4038
4039 <p>
4040 The standard appears to contradict itself about whether the stack is
4041 unwound when the implementation calls terminate().
4042 </p>
4043
4044 <p>From 18.7.3.3p2:</p>
4045 <blockquote><p>
4046     Calls the terminate_handler function in effect immediately
4047     after evaluating the throw-expression (lib.terminate.handler),
4048     if called by the implementation [...]
4049 </p></blockquote>
4050
4051 <p>So the stack is guaranteed not to be unwound.</p>
4052
4053 <p>But from 15.3p9:</p>
4054 <blockquote><p>
4055     [...]whether or not the stack is unwound before this call
4056     to terminate() is implementation-defined (except.terminate).
4057 </p></blockquote>
4058
4059 <p>
4060 And 15.5.1 actually defines that in most cases the stack is unwound.
4061 </p>
4062
4063
4064 <p><b>Proposed resolution:</b></p>
4065
4066
4067 <p><b>Rationale:</b></p>
4068 <p>There is definitely no contradiction between the core and library
4069 clauses; nothing in the core clauses says that stack unwinding happens
4070 after <tt>terminate</tt> is called.  18.7.3.3p2 does not say anything
4071 about when terminate() is called; it merely specifies which
4072 <tt>terminate_handler</tt> is used.</p>
4073
4074
4075
4076
4077
4078 <hr>
4079 <h3><a name="323"></a>323. abs() overloads in different headers</h3>
4080 <p><b>Section:</b> 26.8 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
4081  <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2001-06-04  <b>Last modified:</b> 2008-03-12</p>
4082 <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>
4083 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
4084 <p><b>Discussion:</b></p>
4085 <p>Currently the standard mandates the following overloads of
4086 abs():</p>
4087
4088 <pre>    abs(long), abs(int) in &lt;cstdlib&gt;
4089
4090     abs(float), abs(double), abs(long double) in &lt;cmath&gt;
4091
4092     template&lt;class T&gt; T abs(const complex&lt;T&gt;&amp;) in &lt;complex&gt;
4093
4094     template&lt;class T&gt; valarray&lt;T&gt; abs(const valarray&lt;T&gt;&amp;); in &lt;valarray&gt;
4095 </pre>
4096
4097 <p>
4098 The problem is that having only some overloads visible of a function
4099 that works on "implicitly inter-convertible" types is dangerous in
4100 practice. The headers that get included at any point in a translation
4101 unit can change unpredictably during program
4102 development/maintenance. The wrong overload might be unintentionally
4103 selected.
4104 </p>
4105
4106 <p>
4107 Currently, there is nothing that mandates the simultaneous visibility
4108 of these overloads. Indeed, some vendors have begun fastidiously
4109 reducing dependencies among their (public) headers as a QOI issue: it
4110 helps people to write portable code by refusing to compile unless all
4111 the correct headers are #included.
4112 </p>
4113
4114 <p>The same issue may exist for other functions in the library.</p>
4115
4116 <p>Redmond: PJP reports that C99 adds two new kinds of abs: complex,
4117 and int_max_abs.</p>
4118
4119 <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#343">343</a>.</p>
4120
4121 <p><i>[
4122 Bellevue:
4123 ]</i></p>
4124
4125
4126 <blockquote>
4127 The situation is not sufficiently severe to warrant a change.
4128 </blockquote>
4129
4130
4131
4132
4133 <p><b>Rationale:</b></p>
4134 <p>The programs that could potentially be broken by this situation are
4135   already fragile, and somewhat contrived: For example, a user-defined
4136   class that has conversion overloads both to <tt>long</tt> and
4137   to <tt>float</tt>.  If <tt>x</tt> is a value of such a class, then
4138   <tt>abs(x)</tt> would give the <tt>long</tt> version if the user
4139   included &lt;cstdlib&gt;, the <tt>float</tt> version if the user
4140   included &lt;cmath&gt;, and would be diagnosed as ambiguous at
4141   compile time if the user included both headers.  The LWG couldn't
4142   find an example of a program whose meaning would be changed (as
4143   opposed to changing it from well-formed to ill-formed) simply by
4144   adding another standard header.</p>
4145
4146 <p>Since the harm seems minimal, and there don't seem to be any simple
4147   and noninvasive solutions, this is being closed as NAD.  It is
4148   marked as "Future" for two reasons.  First, it might be useful to
4149   define an <tt>&lt;all&gt;</tt> header that would include all
4150   Standard Library headers.  Second, we should at least make sure that
4151   future library extensions don't make this problem worse.</p>
4152
4153
4154
4155
4156
4157 <hr>
4158 <h3><a name="326"></a>326. Missing typedef in moneypunct_byname</h3>
4159 <p><b>Section:</b> 22.4.6.4 [locale.moneypunct.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
4160  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-07-05  <b>Last modified:</b> 2006-12-27</p>
4161 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
4162 <p><b>Discussion:</b></p>
4163 <p>The definition of the moneypunct facet contains the typedefs char_type
4164 and string_type. Only one of these names, string_type, is defined in
4165 the derived facet, moneypunct_byname.</p>
4166
4167
4168 <p><b>Proposed resolution:</b></p>
4169 <p>For consistency with the numpunct facet, add a typedef for
4170 char_type to the definition of the moneypunct_byname facet in
4171 22.4.6.4 [locale.moneypunct.byname].</p>
4172
4173
4174 <p><b>Rationale:</b></p>
4175 <p>The absence of the typedef is irrelevant.  Users can still access
4176 the typedef, because it is inherited from the base class.</p>
4177
4178
4179
4180
4181
4182 <hr>
4183 <h3><a name="330"></a>330. Misleading "exposition only" value in class locale definition</h3>
4184 <p><b>Section:</b> 22.3.1 [locale] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
4185  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-07-15  <b>Last modified:</b> 2006-12-27</p>
4186 <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>
4187 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
4188 <p><b>Discussion:</b></p>
4189 <p>
4190 The "exposition only" value of the std::locale::none constant shown in
4191 the definition of class locale is misleading in that it on many
4192 systems conflicts with the value assigned to one if the LC_XXX
4193 constants (specifically, LC_COLLATE on AIX, LC_ALL on HP-UX, LC_CTYPE
4194 on Linux and SunOS). This causes incorrect behavior when such a
4195 constant is passed to one of the locale member functions that accept a
4196 locale::category argument and interpret it as either the C LC_XXX
4197 constant or a bitmap of locale::category values. At least three major
4198 implementations adopt the suggested value without a change and
4199 consequently suffer from this problem.
4200 </p>
4201
4202 <p>
4203 For instance, the following code will (presumably) incorrectly copy facets
4204 belonging to the collate category from the German locale on AIX:
4205 </p>
4206
4207 <pre>  std::locale l (std::locale ("C"), "de_DE", std::locale::none);
4208 </pre>
4209
4210
4211 <p><b>Rationale:</b></p>
4212 <p>The LWG agrees that it may be difficult to implement locale member
4213 functions in such a way that they can take either <tt>category</tt>
4214 arguments or the LC_ constants defined in &lt;cctype&gt;.  In light of
4215 this requirement (22.3.1.1.1 [locale.category], paragraph 2), and in light
4216 of the requirement in the preceding paragraph that it is possible to
4217 combine <tt>category</tt> bitmask elements with bitwise operations,
4218 defining the <tt>category</tt> elements is delicate,
4219 particularly if an implementor is constrained to work with a
4220 preexisting C library.  (Just using the existing LC_ constants would
4221 not work in general.)  There's no set of "exposition only" values that
4222 could give library implementors proper guidance in such a delicate
4223 matter.  The non-normative example we're giving is no worse than
4224 any other choice would be.</p>
4225
4226 <p>See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#347">347</a>.</p>
4227
4228
4229
4230
4231
4232 <hr>
4233 <h3><a name="332"></a>332. Consider adding increment and decrement operators to std::fpos&lt; T &gt; </h3>
4234 <p><b>Section:</b> 27.5.3 [fpos] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
4235  <b>Submitter:</b> PremAnand M. Rao <b>Opened:</b> 2001-08-27  <b>Last modified:</b> 2006-12-27</p>
4236 <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>
4237 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
4238 <p><b>Discussion:</b></p>
4239 <p>
4240 Increment and decrement operators are missing from
4241 Table 88 -- Position type requirements in 27.5.3 [fpos].
4242 </p>
4243
4244
4245 <p><b>Proposed resolution:</b></p>
4246 <p>
4247 Table 88 (section 27.4.3) -- Position type requirements
4248 be updated to include increment and decrement operators.
4249 </p>
4250
4251 <pre>expression        return type     operational    note
4252
4253 ++p               fpos&amp;           p += O(1)
4254 p++               fpos            { P tmp = p;
4255                                     ++p;
4256                                     return tmp; }
4257 --p               fpos&amp;           p -= O(1)
4258 p--               fpos            { P tmp = p;
4259                                     --p;
4260                                     return tmp; }
4261 </pre>
4262
4263
4264
4265 <p><b>Rationale:</b></p>
4266 <p>The LWG believes this is a request for extension, not a defect
4267 report.  Additionally, nobody saw a clear need for this extension;
4268 <tt>fpos</tt> is used only in very limited ways.</p>
4269
4270
4271
4272
4273
4274 <hr>
4275 <h3><a name="344"></a>344. grouping + showbase</h3>
4276 <p><b>Section:</b> 22.4.2 [category.numeric] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
4277  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2001-10-13  <b>Last modified:</b> 2007-01-15</p>
4278 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
4279 <p><b>Discussion:</b></p>
4280 <p>
4281 When both grouping and showbase are active and the basefield is octal,
4282 does the leading 0 participate in the grouping or not?  For example,
4283 should one format as: 0,123,456 or 0123,456?
4284 </p>
4285 <p>
4286 An analogy can be drawn with hexadecimal.  It appears that 0x123,456 is
4287 preferred over 0x,123,456.  However, this analogy is not universally
4288 accepted to apply to the octal base.  The standard is not clear on how
4289 to format (or parse) in this manner.
4290 </p>
4291
4292 <p><b>Proposed resolution:</b></p>
4293 <p>
4294 Insert into 22.4.3.1.2 [facet.numpunct.virtuals] paragraph 3, just before the last
4295 sentence:
4296 </p>
4297 <blockquote><p>
4298 The leading hexadecimal base specifier "0x" does not participate in
4299 grouping.  The leading '0' octal base specifier may participate in
4300 grouping.  It is unspecified if the leading '0' participates in
4301 formatting octal numbers.  In parsing octal numbers, the implementation
4302 is encouraged to accept both the leading '0' participating in the
4303 grouping, and not participating (e.g. 0123,456 or 0,123,456).
4304 </p></blockquote>
4305
4306 <p><b>Rationale:</b></p>
4307 <p>
4308 The current behavior may be unspecified, but it's not clear that it
4309 matters.  This is an obscure corner case, since grouping is usually
4310 intended for the benefit of humans and oct/hex prefixes are usually
4311 intended for the benefit of machines.  There is not a strong enough
4312 consensus in the LWG for action.
4313 </p>
4314
4315
4316
4317
4318 <hr>
4319 <h3><a name="348"></a>348. Minor issue with std::pair operator&lt;</h3>
4320 <p><b>Section:</b> 20.3.3 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
4321  <b>Submitter:</b> Andy Sawyer <b>Opened:</b> 2001-10-23  <b>Last modified:</b> 2008-01-05</p>
4322 <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>
4323 <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>
4324 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
4325 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a></p>
4326 <p><b>Discussion:</b></p>
4327
4328
4329 <p>
4330 The current wording of 20.2.2 [lib.pairs] p6 precludes the use of
4331 operator&lt; on any pair type which contains a pointer.
4332 </p>
4333
4334
4335 <p><b>Proposed resolution:</b></p>
4336 <p>In 20.3.3 [pairs] paragraph 6, replace:</p>
4337 <pre>    Returns: x.first &lt; y.first || (!(y.first &lt; x.first) &amp;&amp; x.second &lt;
4338         y.second).
4339 </pre>
4340 <p>With:</p>
4341 <pre>    Returns: std::less&lt;T1&gt;()( x.first, y.first ) ||
4342              (!std::less&lt;T1&gt;()( y.first, x.first) &amp;&amp;
4343              std::less&lt;T2&gt;()( x.second, y.second ) )
4344 </pre>
4345
4346
4347
4348 <p><b>Rationale:</b></p>
4349 <p>This is an instance of a much more general problem.  If we want
4350   operator&lt; to translate to std::less for pairs of pointers, where
4351   do we draw the line?  The same issue applies to individual
4352   pointers, smart pointer wrappers, std::vector&lt;T*&gt;, and so
4353   on.</p>
4354
4355 <p>Andy Koenig suggests that the real issue here is that we aren't
4356   distinguishing adequately between two different orderings, a
4357   "useful ordering" and a "canonical ordering" that's used just
4358   because we sometimes need <i>some</i> ordering without caring much
4359   which ordering it is.  Another example of the later is typeinfo's
4360   <tt>before</tt>.</p>
4361
4362
4363
4364
4365
4366
4367 <hr>
4368 <h3><a name="350"></a>350. allocator&lt;&gt;::address</h3>
4369 <p><b>Section:</b> 20.8.6.1 [allocator.members], X [allocator.requirements], 17.6.1.1 [contents] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
4370  <b>Submitter:</b> Nathan Myers <b>Opened:</b> 2001-10-25  <b>Last modified:</b> 2007-10-11</p>
4371 <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>
4372 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
4373 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#634">634</a></p>
4374 <p><b>Discussion:</b></p>
4375 <p>See c++std-lib-9006 and c++std-lib-9007.  This issue is taken
4376 verbatim from -9007.</p>
4377
4378 <p>
4379 The core language feature allowing definition of operator&amp;() applied
4380 to any non-builtin type makes that operator often unsafe to use in
4381 implementing libraries, including the Standard Library.  The result
4382 is that many library facilities fail for legal user code, such as
4383 the fragment</p>
4384 <pre>  class A { private: A* operator&amp;(); };
4385   std::vector&lt;A&gt; aa;
4386
4387   class B { };
4388   B* operator&amp;(B&amp;) { return 0; }
4389   std::vector&lt;B&gt; ba;
4390 </pre>
4391
4392 <p>
4393 In particular, the requirements table for Allocator (Table 32) specifies
4394 no semantics at all for member address(), and allocator&lt;&gt;::address is
4395 defined in terms of unadorned operator &amp;.
4396 </p>
4397
4398
4399
4400 <p><b>Proposed resolution:</b></p>
4401 <p>
4402 In 20.6.1.1, Change the definition of allocator&lt;&gt;::address from:</p>
4403 <blockquote><p>
4404   Returns: &amp;x
4405 </p></blockquote>
4406
4407 <p>to:</p>
4408
4409 <p>
4410   Returns: The value that the built in operator&amp;(x) would return if not
4411   overloaded.
4412 </p>
4413
4414 <p>
4415 In 20.1.6, Table 32, add to the Notes column of the a.address(r) and
4416 a.address(s) lines, respectively:
4417 </p>
4418
4419 <pre>  allocator&lt;T&gt;::address(r)
4420   allocator&lt;T&gt;::address(s)
4421 </pre>
4422
4423 <p>In addition, in clause 17.4.1.1, add a statement:</p>
4424
4425 <blockquote><p>
4426  The Standard Library does not apply operator&amp; to any type for which
4427  operator&amp; may be overloaded.
4428 </p></blockquote>
4429
4430
4431
4432 <p><b>Rationale:</b></p>
4433 <p>The LWG believes both examples are ill-formed.  The contained type
4434 is required to be CopyConstructible (X [utility.arg.requirements]), and that
4435 includes the requirement that &amp;t return the usual types and
4436 values. Since allocators are intended to be used in conjunction with
4437 containers, and since the CopyConstructible requirements appear to
4438 have been written to deal with the concerns of this issue, the LWG
4439 feels it is NAD unless someone can come up with a well-formed example
4440 exhibiting a problem.</p>
4441
4442 <p>It may well be that the CopyConstructible requirements are too
4443   restrictive and that either the container requirements or the
4444   CopyConstructive requirements should be relaxed, but that's a far
4445   larger issue.  Marking this issue as "future" as a pointer to that
4446   larger issue.</p>
4447
4448
4449
4450
4451
4452 <hr>
4453 <h3><a name="351"></a>351. unary_negate and binary_negate: struct or class?</h3>
4454 <p><b>Section:</b> 20.7 [function.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
4455  <b>Submitter:</b> Dale Riley <b>Opened:</b> 2001-11-12  <b>Last modified:</b> 2007-04-24</p>
4456 <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>
4457 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
4458 <p><b>Discussion:</b></p>
4459 <p>
4460 In 20.7 [function.objects] the header &lt;functional&gt; synopsis declares
4461 the unary_negate and binary_negate function objects as struct.
4462 However in 20.7.11 [negators] the unary_negate and binary_negate
4463 function objects are defined as class.  Given the context, they are
4464 not "basic function objects" like negate, so this is either a typo or
4465 an editorial oversight.
4466 </p>
4467
4468 <p><i>[Taken from comp.std.c++]</i></p>
4469
4470
4471
4472 <p><b>Proposed resolution:</b></p>
4473 <p>Change the synopsis to reflect the useage in 20.7.11 [negators]</p>
4474
4475 <p><i>[Curaçao: Since the language permits "struct", the LWG
4476 views this as NAD. They suggest, however, that the Project Editor
4477 might wish to make the change as editorial.]</i></p>
4478
4479
4480
4481
4482
4483
4484
4485 <hr>
4486 <h3><a name="353"></a>353. <tt>std::pair</tt> missing template assignment</h3>
4487 <p><b>Section:</b> 20.3.3 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
4488  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-12-02  <b>Last modified:</b> 2008-01-05</p>
4489 <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>
4490 <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>
4491 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
4492 <p><b>Discussion:</b></p>
4493 <p>
4494 The class template <tt>std::pair</tt> defines a template ctor (20.2.2, p4) but
4495 no template assignment operator. This may lead to inefficient code since
4496 assigning an object of <tt>pair&lt;C, D&gt;</tt> to <tt>pair&lt;A, B&gt;</tt>
4497 where the types <tt>C</tt> and <tt>D</tt> are distinct from but convertible to
4498 <tt>A</tt> and <tt>B</tt>, respectively, results in a call to the template copy
4499 ctor to construct an unnamed temporary of type <tt>pair&lt;A, B&gt;</tt>
4500 followed by an ordinary (perhaps implicitly defined) assignment operator,
4501 instead of just a straight assignment.
4502 </p>
4503
4504
4505 <p><b>Proposed resolution:</b></p>
4506 <p>
4507 Add the following declaration to the definition of <tt>std::pair</tt>:
4508 </p>
4509 <pre>    template&lt;class U, class V&gt;
4510     pair&amp; operator=(const pair&lt;U, V&gt; &amp;p);
4511 </pre>
4512 <p>
4513 And also add a paragraph describing the effects of the function template to the
4514 end of 20.2.2:
4515 </p>
4516 <pre>    template&lt;class U, class V&gt;
4517     pair&amp; operator=(const pair&lt;U, V&gt; &amp;p);
4518 </pre>
4519 <p>
4520     <b>Effects</b>: <tt>first = p.first;</tt>
4521                     <tt>second = p.second;</tt>
4522     <b>Returns</b>: <tt>*this</tt>
4523 </p>
4524
4525 <p><i>[Curaçao: There is no indication this is was anything other than
4526 a design decision, and thus NAD.&nbsp; May be appropriate for a future
4527 standard.]</i></p>
4528
4529
4530 <p><i>[
4531 Pre Bellevue:  It was recognized that this was taken care of by
4532 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html">N1856</a>,
4533 and thus moved from NAD Future to NAD Editorial.
4534 ]</i></p>
4535
4536
4537
4538
4539
4540
4541 <hr>
4542 <h3><a name="356"></a>356. Meaning of ctype_base::mask enumerators</h3>
4543 <p><b>Section:</b> 22.4.1 [category.ctype] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
4544  <b>Submitter:</b> Matt Austern <b>Opened:</b> 2002-01-23  <b>Last modified:</b> 2006-12-27</p>
4545 <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>
4546 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
4547 <p><b>Discussion:</b></p>
4548
4549 <p>What should the following program print?</p>
4550
4551 <pre>  #include &lt;locale&gt;
4552   #include &lt;iostream&gt;
4553
4554   class my_ctype : public std::ctype&lt;char&gt;
4555   {
4556     typedef std::ctype&lt;char&gt; base;
4557   public:
4558     my_ctype(std::size_t refs = 0) : base(my_table, false, refs)
4559     {
4560       std::copy(base::classic_table(), base::classic_table() + base::table_size,
4561                 my_table);
4562       my_table[(unsigned char) '_'] = (base::mask) (base::print | base::space);
4563     }
4564   private:
4565     mask my_table[base::table_size];
4566   };
4567
4568   int main()
4569   {
4570     my_ctype ct;
4571     std::cout &lt;&lt; "isspace: " &lt;&lt; ct.is(std::ctype_base::space, '_') &lt;&lt; "    "
4572               &lt;&lt; "isalpha: " &lt;&lt; ct.is(std::ctype_base::alpha, '_') &lt;&lt; std::endl;
4573   }
4574 </pre>
4575
4576 <p>The goal is to create a facet where '_' is treated as whitespace.</p>
4577
4578 <p>On gcc 3.0, this program prints "isspace: 1 isalpha: 0".  On
4579 Microsoft C++ it prints "isspace: 1 isalpha: 1".</p>
4580
4581 <p>
4582 I believe that both implementations are legal, and the standard does not
4583 give enough guidance for users to be able to use std::ctype's
4584 protected interface portably.</p>
4585
4586 <p>
4587 The above program assumes that ctype_base::mask enumerators like
4588 <tt>space</tt> and <tt>print</tt> are disjoint, and that the way to
4589 say that a character is both a space and a printing character is to or
4590 those two enumerators together.  This is suggested by the "exposition
4591 only" values in 22.4.1 [category.ctype], but it is nowhere specified in
4592 normative text.  An alternative interpretation is that the more
4593 specific categories subsume the less specific.  The above program
4594 gives the results it does on the Microsoft compiler because, on that
4595 compiler, <tt>print</tt> has all the bits set for each specific
4596 printing character class.
4597 </p>
4598
4599 <p>From the point of view of std::ctype's public interface, there's no
4600 important difference between these two techniques.  From the point of
4601 view of the protected interface, there is.  If I'm defining a facet
4602 that inherits from std::ctype&lt;char&gt;, I'm the one who defines the
4603 value that table()['a'] returns.  I need to know what combination of
4604 mask values I should use.  This isn't so very esoteric: it's exactly
4605 why std::ctype has a protected interface.  If we care about users
4606 being able to write their own ctype facets, we have to give them a
4607 portable way to do it.
4608 </p>
4609
4610 <p>
4611 Related reflector messages:
4612 lib-9224, lib-9226, lib-9229, lib-9270, lib-9272, lib-9273, lib-9274,
4613 lib-9277, lib-9279.
4614 </p>
4615
4616 <p>Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#339">339</a> is related, but not identical.  The
4617 proposed resolution if issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#339">339</a> says that
4618 ctype_base::mask must be a bitmask type. It does not say that the
4619 ctype_base::mask elements are bitmask elements, so it doesn't
4620 directly affect this issue.</p>
4621
4622 <p>More comments from Benjamin Kosnik, who believes that
4623 that C99 compatibility essentially requires what we're
4624 calling option 1 below.</p>
4625
4626 <blockquote>
4627 <pre>I think the C99 standard is clear, that isspace -&gt; !isalpha.
4628 --------
4629
4630 #include &lt;locale&gt;
4631 #include &lt;iostream&gt;
4632
4633 class my_ctype : public std::ctype&lt;char&gt;
4634 {
4635 private:
4636   typedef std::ctype&lt;char&gt; base;
4637   mask my_table[base::table_size];
4638
4639 public:
4640   my_ctype(std::size_t refs = 0) : base(my_table, false, refs)
4641   {
4642     std::copy(base::classic_table(), base::classic_table() + base::table_size,
4643               my_table);
4644     mask both = base::print | base::space;
4645     my_table[static_cast&lt;mask&gt;('_')] = both;
4646   }
4647 };
4648
4649 int main()
4650 {
4651   using namespace std;
4652   my_ctype ct;
4653   cout &lt;&lt; "isspace: " &lt;&lt; ct.is(ctype_base::space, '_') &lt;&lt; endl;
4654   cout &lt;&lt; "isprint: " &lt;&lt; ct.is(ctype_base::print, '_') &lt;&lt; endl;
4655
4656   // ISO C99, isalpha iff upper | lower set, and !space.
4657   // 7.5, p 193
4658   // -&gt; looks like g++ behavior is correct.
4659   // 356 -&gt; bitmask elements are required for ctype_base
4660   // 339 -&gt; bitmask type required for mask
4661   cout &lt;&lt; "isalpha: " &lt;&lt; ct.is(ctype_base::alpha, '_') &lt;&lt; endl;
4662 }
4663 </pre>
4664 </blockquote>
4665
4666
4667
4668 <p><b>Proposed resolution:</b></p>
4669 <p>Informally, we have three choices:</p>
4670 <ol>
4671 <li>Require that the enumerators are disjoint (except for alnum and
4672 graph)</li>
4673 <li>Require that the enumerators are not disjoint, and specify which
4674 of them subsume which others.  (e.g. mandate that lower includes alpha
4675 and print)</li>
4676 <li>Explicitly leave this unspecified, which the result that the above
4677 program is not portable.</li>
4678 </ol>
4679
4680 <p>Either of the first two options is just as good from the standpoint
4681 of portability.  Either one will require some implementations to
4682 change.</p>
4683
4684
4685 <p><b>Rationale:</b></p>
4686 <p>The LWG agrees that this is a real ambiguity, and that both
4687 interpretations are conforming under the existing standard. However,
4688 there's no evidence that it's causing problems for real users. Users
4689 who want to define ctype facets portably can test the ctype_base masks
4690 to see which interpretation is being used.</p>
4691
4692
4693
4694
4695
4696 <hr>
4697 <h3><a name="357"></a>357. &lt;cmath&gt; float functions cannot return HUGE_VAL</h3>
4698 <p><b>Section:</b> 26.8 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
4699  <b>Submitter:</b> Ray Lischner <b>Opened:</b> 2002-02-26  <b>Last modified:</b> 2007-04-24</p>
4700 <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>
4701 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
4702 <p><b>Discussion:</b></p>
4703 <p>
4704 The float versions of the math functions have no meaningful value to return
4705 for a range error. The long double versions have a value they can return,
4706 but it isn't necessarily the most reasonable value.
4707 </p>
4708
4709 <p>
4710 Section 26.5 [lib.c.math], paragraph 5, says that C++ "adds float and long
4711 double overloaded versions of these functions, with the same semantics,"
4712 referring to the math functions from the C90 standard.
4713 </p>
4714
4715 <p>
4716 The C90 standard, in section 7.5.1, paragraph 3, says that functions return
4717 "the value of the macro HUGE_VAL" when they encounter a range error.
4718 Section 7.5, paragraph 2, defines HUGE_VAL as a macro that "expands to a
4719 positive double expression, not necessarily representable as a float."
4720 </p>
4721
4722 <p>
4723 Therefore, the float versions of the math functions have no way to
4724 signal a range error. <i>[Curaçao: The LWG notes that this isn't
4725 strictly correct, since errno is set.]</i> The semantics require that they
4726 return HUGE_VAL, but they cannot because HUGE_VAL might not be
4727 representable as a float.
4728 </p>
4729
4730 <p>
4731 The problem with long double functions is less severe because HUGE_VAL is
4732 representable as a long double. On the other hand, it might not be a "huge"
4733 long double value, and might fall well within the range of normal return
4734 values for a long double function. Therefore, it does not make sense for a
4735 long double function to return a double (HUGE_VAL) for a range error.
4736 </p>
4737
4738
4739 <p><b>Proposed resolution:</b></p>
4740 <p>Curaçao: C99 was faced with a similar problem, which they fixed by
4741 adding HUGE_VALF and HUGE_VALL in addition to HUGE_VAL.</p>
4742
4743 <p>C++ must also fix, but it should be done in the context of the
4744 general C99 based changes to C++, not via DR. Thus the LWG in Curaçao
4745 felt the resolution should be NAD, FUTURE, but the issue is being held
4746 open for one more meeting to ensure LWG members not present during the
4747 discussion concur.</p>
4748
4749
4750 <p><b>Rationale:</b></p>
4751 <p>Will be fixed as part of more general work in the TR.</p>
4752
4753
4754
4755
4756
4757 <hr>
4758 <h3><a name="361"></a>361. num_get&lt;&gt;::do_get (..., void*&amp;) checks grouping</h3>
4759 <p><b>Section:</b> 22.4.2.2.2 [facet.num.put.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
4760  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2002-03-12  <b>Last modified:</b> 2007-01-15</p>
4761 <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>
4762 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
4763 <p><b>Discussion:</b></p>
4764 <p>
4765 22.2.2.2.2, p12 specifies that <tt>thousands_sep</tt> is to be inserted only
4766 for integral types (issue 282 suggests that this should be done for
4767 all arithmetic types).
4768 </p>
4769
4770 <p>
4771 22.2.2.1.2, p12 requires that grouping be checked for all extractors
4772 including that for <tt>void*</tt>.
4773 </p>
4774
4775 <p>
4776 I don't think that's right. <tt>void*</tt> values should not be checked for
4777 grouping, should they? (Although if they should, then <tt>num_put</tt> needs
4778 to write them out, otherwise their extraction will fail.)
4779 </p>
4780
4781
4782 <p><b>Proposed resolution:</b></p>
4783 <p>
4784 Change the first sentence of 22.2.2.2.2, p12 from
4785 </p>
4786 <blockquote><p>
4787     Digit grouping is checked. That is, the positions of discarded
4788     separators is examined for consistency with
4789     use_facet&lt;numpunct&lt;charT&gt; &gt;(loc).grouping().
4790     If they are not consistent then ios_base::failbit is assigned
4791     to err.
4792 </p></blockquote>
4793
4794 <p>to</p>
4795 <blockquote><p>
4796     Except for conversions to void*, digit grouping is checked...
4797 </p></blockquote>
4798
4799
4800
4801 <p><b>Rationale:</b></p>
4802 <p>This would be a change: as it stands, the standard clearly
4803   specifies that grouping applies to void*.  A survey of existing
4804   practice shows that most existing implementations do that, as they
4805   should.</p>
4806
4807
4808
4809
4810
4811 <hr>
4812 <h3><a name="366"></a>366. Excessive const-qualification</h3>
4813 <p><b>Section:</b> 27 [input.output] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
4814  <b>Submitter:</b> Walter Brown, Marc Paterno <b>Opened:</b> 2002-05-10  <b>Last modified:</b> 2006-12-27</p>
4815 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#input.output">active issues</a> in [input.output].</p>
4816 <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>
4817 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
4818 <p><b>Discussion:</b></p>
4819 <p>
4820 The following member functions are declared const, yet return non-const
4821 pointers. We believe they are should be changed, because they allow code
4822 that may surprise the user. See document N1360 for details and
4823 rationale.
4824 </p>
4825
4826 <p><i>[Santa Cruz: the real issue is that we've got const member
4827 functions that return pointers to non-const, and N1360 proposes
4828 replacing them by overloaded pairs.  There isn't a consensus about
4829 whether this is a real issue, since we've never said what our
4830 constness policy is for iostreams.  N1360 relies on a distinction
4831 between physical constness and logical constness; that distinction, or
4832 those terms, does not appear in the standard.]</i></p>
4833
4834
4835
4836
4837 <p><b>Proposed resolution:</b></p>
4838 <p>In 27.4.4 and 27.4.4.2</p>
4839 <p>Replace</p>
4840 <pre>  basic_ostream&lt;charT,traits&gt;* tie() const;
4841 </pre>
4842 <p>with</p>
4843 <pre>  basic_ostream&lt;charT,traits&gt;* tie();
4844   const basic_ostream&lt;charT,traits&gt;* tie() const;
4845 </pre>
4846
4847 <p>and replace</p>
4848 <pre>  basic_streambuf&lt;charT,traits&gt;* rdbuf() const;
4849 </pre>
4850 <p>with</p>
4851 <pre>  basic_streambuf&lt;charT,traits&gt;* rdbuf();
4852   const basic_streambuf&lt;charT,traits&gt;* rdbuf() const;
4853 </pre>
4854
4855 <p>In 27.5.2 and 27.5.2.3.1</p>
4856 <p>Replace</p>
4857 <pre>  char_type* eback() const;
4858 </pre>
4859 <p>with</p>
4860 <pre>  char_type* eback();
4861   const char_type* eback() const;
4862 </pre>
4863
4864 <p>Replace</p>
4865 <pre>  char_type gptr() const;
4866 </pre>
4867 <p>with</p>
4868 <pre>  char_type* gptr();
4869   const char_type* gptr() const;
4870 </pre>
4871
4872 <p>Replace</p>
4873 <pre>  char_type* egptr() const;
4874 </pre>
4875 <p>with</p>
4876 <pre>  char_type* egptr();
4877   const char_type* egptr() const;
4878 </pre>
4879
4880 <p>In 27.5.2 and 27.5.2.3.2</p>
4881 <p>Replace</p>
4882 <pre>  char_type* pbase() const;
4883 </pre>
4884 <p>with</p>
4885 <pre>  char_type* pbase();
4886   const char_type* pbase() const;
4887 </pre>
4888
4889 <p>Replace</p>
4890 <pre>  char_type* pptr() const;
4891 </pre>
4892 <p>with</p>
4893 <pre>  char_type* pptr();
4894   const char_type* pptr() const;
4895 </pre>
4896
4897 <p>Replace</p>
4898 <pre>  char_type* epptr() const;
4899 </pre>
4900 <p>with</p>
4901 <pre>  char_type* epptr();
4902   const char_type* epptr() const;
4903 </pre>
4904
4905 <p>In 27.7.2, 27.7.2.2, 27.7.3 27.7.3.2, 27.7.4, and 27.7.6</p>
4906 <p>Replace</p>
4907 <pre>  basic_stringbuf&lt;charT,traits,Allocator&gt;* rdbuf() const;
4908 </pre>
4909 <p>with</p>
4910 <pre>  basic_stringbuf&lt;charT,traits,Allocator&gt;* rdbuf();
4911   const basic_stringbuf&lt;charT,traits,Allocator&gt;* rdbuf() const;
4912 </pre>
4913
4914 <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>
4915 <p>Replace</p>
4916 <pre>  basic_filebuf&lt;charT,traits&gt;* rdbuf() const;
4917 </pre>
4918 <p>with</p>
4919 <pre>  basic_filebuf&lt;charT,traits&gt;* rdbuf();
4920   const basic_filebuf&lt;charT,traits&gt;* rdbuf() const;
4921 </pre>
4922
4923
4924 <p><b>Rationale:</b></p>
4925 <p>The existing specification is a bit sloppy, but there's no
4926   particular reason to change this other than tidiness, and there are
4927   a number of ways in which streams might have been designed
4928   differently if we were starting today.  There's no evidence that the
4929   existing constness policy is harming users.  We might consider
4930   a different constness policy as part of a full stream redesign.</p>
4931
4932
4933
4934
4935
4936 <hr>
4937 <h3><a name="367"></a>367. remove_copy/remove_copy_if and Input Iterators</h3>
4938 <p><b>Section:</b> 25.4.8 [alg.remove] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
4939  <b>Submitter:</b> Anthony Williams <b>Opened:</b> 2002-05-13  <b>Last modified:</b> 2006-12-27</p>
4940 <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>
4941 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
4942 <p><b>Discussion:</b></p>
4943 <p>
4944 remove_copy and remove_copy_if (25.4.8 [alg.remove]) permit their
4945 input range to be marked with Input Iterators. However, since two
4946 operations are required against the elements to copy (comparison and
4947 assigment), when the input range uses Input Iterators, a temporary
4948 copy must be taken to avoid dereferencing the iterator twice. This
4949 therefore requires the value type of the InputIterator to be
4950 CopyConstructible. If the iterators are at least Forward Iterators,
4951 then the iterator can be dereferenced twice, or a reference to the
4952 result maintained, so the temporary is not required.
4953 </p>
4954
4955
4956 <p><b>Proposed resolution:</b></p>
4957 <p>
4958 Add "If InputIterator does not meet the requirements of forward
4959 iterator, then the value type of InputIterator must be copy
4960 constructible. Otherwise copy constructible is not required." to
4961 25.4.8 [alg.remove] paragraph 6.
4962 </p>
4963
4964
4965 <p><b>Rationale:</b></p>
4966 <p>The assumption is that an input iterator can't be dereferenced
4967   twice.  There's no basis for that assumption in the Standard.</p>
4968
4969
4970
4971
4972
4973 <hr>
4974 <h3><a name="368"></a>368. basic_string::replace has two "Throws" paragraphs</h3>
4975 <p><b>Section:</b> 21.4.6.6 [string::replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
4976  <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2002-06-03  <b>Last modified:</b> 2007-04-24</p>
4977 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
4978 <p><b>Discussion:</b></p>
4979 <p>
4980 21.4.6.6 [string::replace] basic_string::replace, second
4981 signature, given in paragraph 1, has two "Throws" paragraphs (3 and
4982 5).
4983 </p>
4984
4985 <p>
4986 In addition, the second "Throws" paragraph (5) includes specification
4987 (beginning with "Otherwise, the function replaces ...") that should be
4988 part of the "Effects" paragraph.
4989 </p>
4990
4991
4992 <p><b>Proposed resolution:</b></p>
4993
4994
4995 <p><b>Rationale:</b></p>
4996 <p>This is editorial. Both "throws" statements are true. The bug is
4997   just that the second one should be a sentence, part of the "Effects"
4998   clause, not a separate "Throws".  The project editor has been
4999   notified.</p>
5000
5001
5002
5003
5004
5005 <hr>
5006 <h3><a name="372"></a>372. Inconsistent description of stdlib exceptions</h3>
5007 <p><b>Section:</b> 17.6.4.10 [res.on.exception.handling], 18.7.1 [type.info] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
5008  <b>Submitter:</b> Randy Maddox <b>Opened:</b> 2002-07-22  <b>Last modified:</b> 2006-12-27</p>
5009 <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>
5010 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
5011 <p><b>Discussion:</b></p>
5012
5013 <p>Paragraph 3 under clause 17.6.4.10 [res.on.exception.handling], Restrictions on
5014 Exception Handling, states that "Any other functions defined in the
5015 C++ Standard Library that do not have an exception-specification may
5016 throw implementation-defined exceptions unless otherwise specified."
5017 This statement is followed by a reference to footnote 178 at the
5018 bottom of that page which states, apparently in reference to the C++
5019 Standard Library, that "Library implementations are encouraged (but
5020 not required) to report errors by throwing exceptions from (or derived
5021 from) the standard exceptions."</p>
5022
5023 <p>These statements appear to be in direct contradiction to clause
5024 18.7.1 [type.info], which states "The class exception defines the
5025 base class for the types of objects thrown as exceptions by the C++
5026 Standard library components ...".</p>
5027
5028 <p>Is this inconsistent?</p>
5029
5030
5031
5032 <p><b>Proposed resolution:</b></p>
5033
5034
5035 <p><b>Rationale:</b></p>
5036 <p>Clause 17 is setting the overall library requirements, and it's
5037   clear and consistent.  This sentence from Clause 18 is descriptive,
5038   not setting a requirement on any other class.
5039 </p>
5040
5041
5042
5043
5044
5045 <hr>
5046 <h3><a name="374"></a>374. moneypunct::frac_digits returns int not unsigned</h3>
5047 <p><b>Section:</b> 22.4.6.3.1 [locale.moneypunct.members], 22.4.6.3.2 [locale.moneypunct.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
5048  <b>Submitter:</b> Ray Lischner <b>Opened:</b> 2002-08-08  <b>Last modified:</b> 2006-12-27</p>
5049 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
5050 <p><b>Discussion:</b></p>
5051 <p>
5052 In section 22.4.6.3.1 [locale.moneypunct.members], frac_digits() returns type
5053 "int". This implies that frac_digits() might return a negative value,
5054 but a negative value is nonsensical. It should return "unsigned".
5055 </p>
5056
5057 <p>
5058 Similarly, in section 22.4.6.3.2 [locale.moneypunct.virtuals], do_frac_digits()
5059 should return "unsigned".
5060 </p>
5061
5062
5063
5064 <p><b>Proposed resolution:</b></p>
5065
5066
5067 <p><b>Rationale:</b></p>
5068 <p>Regardless of whether the return value is int or unsigned, it's
5069 always conceivable that frac_digits might return a nonsensical
5070 value. (Is 4294967295 really any better than -1?)  The clients of
5071 moneypunct, the get and put facets, can and do perform range
5072 checks.</p>
5073
5074
5075
5076
5077
5078 <hr>
5079 <h3><a name="377"></a>377. basic_string::insert and length_error</h3>
5080 <p><b>Section:</b> 21.4.6.4 [string::insert] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
5081  <b>Submitter:</b> Ray Lischner <b>Opened:</b> 2002-08-16  <b>Last modified:</b> 2006-12-27</p>
5082 <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>
5083 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
5084 <p><b>Discussion:</b></p>
5085 <p>
5086 Section 21.4.6.4 [string::insert], paragraph 4, contains the following,
5087 "Then throws length_error if size() &gt;= npos - rlen."
5088 </p>
5089
5090 <p>
5091 Related to DR 83, this sentence should probably be removed.
5092 </p>
5093
5094
5095 <p><b>Proposed resolution:</b></p>
5096
5097
5098 <p><b>Rationale:</b></p><p>This requirement is redundant but correct.  No change is
5099 needed.</p>
5100
5101
5102
5103
5104 <hr>
5105 <h3><a name="378"></a>378. locale immutability and locale::operator=()</h3>
5106 <p><b>Section:</b> 22.3.1 [locale] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
5107  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2002-09-06  <b>Last modified:</b> 2006-12-30</p>
5108 <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>
5109 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
5110 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#31">31</a></p>
5111 <p><b>Discussion:</b></p>
5112 <p>
5113 I think there is a problem with 22.1.1, p6 which says that
5114 </p>
5115 <pre>    -6- An instance of locale is immutable; once a facet reference
5116         is obtained from it, that reference remains usable as long
5117         as the locale value itself exists.
5118 </pre>
5119 <p>
5120 and 22.1.1.2, p4:
5121 </p>
5122 <pre>    const locale&amp; operator=(const locale&amp; other) throw();
5123
5124     -4- Effects: Creates a copy of other, replacing the current value.
5125 </pre>
5126 <p>
5127 How can a reference to a facet obtained from a locale object remain
5128 valid after an assignment that clearly must replace all the facets
5129 in the locale object? Imagine a program such as this
5130 </p>
5131 <pre>    std::locale loc ("de_DE");
5132     const std::ctype&lt;char&gt; &amp;r0 = std::use_facet&lt;std::ctype&lt;char&gt; &gt;(loc);
5133     loc = std::locale ("en_US");
5134     const std::ctype&lt;char&gt; &amp;r1 = std::use_facet&lt;std::ctype&lt;char&gt; &gt;(loc);
5135 </pre>
5136 <p>
5137 Is r0 really supposed to be preserved and destroyed only when loc goes
5138 out of scope?
5139 </p>
5140
5141
5142 <p><b>Proposed resolution:</b></p>
5143 <p><i>[Summer '04 mid-meeting mailing: Martin and Dietmar believe this
5144   is a duplicate of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#31">31</a> and recommend that it be
5145   closed.
5146 ]</i></p>
5147
5148
5149
5150
5151
5152
5153 <hr>
5154 <h3><a name="385"></a>385. Does call by value imply the CopyConstructible requirement?</h3>
5155 <p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
5156  <b>Submitter:</b> Matt Austern <b>Opened:</b> 2002-10-23  <b>Last modified:</b> 2007-04-18</p>
5157 <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>
5158 <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>
5159 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
5160 <p><b>Discussion:</b></p>
5161 <p>
5162 Many function templates have parameters that are passed by value;
5163 a typical example is <tt>find_if</tt>'s <i>pred</i> parameter in
5164 25.3.5 [alg.find].  Are the corresponding template parameters
5165 (<tt>Predicate</tt> in this case) implicitly required to be
5166 CopyConstructible, or does that need to be spelled out explicitly?
5167 </p>
5168
5169 <p>
5170 This isn't quite as silly a question as it might seem to be at first
5171 sight.  If you call <tt>find_if</tt> in such a way that template
5172 argument deduction applies, then of course you'll get call by value
5173 and you need to provide a copy constructor.  If you explicitly provide
5174 the template arguments, however, you can force call by reference by
5175 writing something like <tt>find_if&lt;my_iterator,
5176 my_predicate&amp;&gt;</tt>.  The question is whether implementation
5177 are required to accept this, or whether this is ill-formed because
5178 my_predicate&amp; is not CopyConstructible.
5179 </p>
5180
5181 <p>
5182 The scope of this problem, if it is a problem, is unknown.  Function
5183 object arguments to generic algorithms in clauses 25 [algorithms]
5184 and 26 [numerics] are obvious examples.  A review of the whole
5185 library is necessary.
5186 </p>
5187 <p><i>[
5188 This is really two issues.  First, predicates are typically passed by
5189 value but we don't say they must be Copy Constructible.  They should
5190 be. Second: is specialization allowed to transform value arguments
5191 into references? References aren't copy constructible, so this should
5192 not be allowed.
5193 ]</i></p>
5194
5195 <p><i>[
5196 2007-01-12, Howard: First, despite the note above, references <b>are</b>
5197 copy constructible. They just aren't assignable.  Second, this is very
5198 closely related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#92">92</a> and should be consistent with that.
5199 That issue already says that implementations are allowed to copy
5200 function objects.  If one passes in a reference, it is copyable, but
5201 susceptible to slicing if one passes in a reference to a base.  Third,
5202 with rvalue reference in the language one only needs to satisfy
5203 MoveConstructible to pass an rvalue "by value".  Though the function
5204 might still copy the function object internally (requiring
5205 CopyConstructible). Finally (and fwiw), if we wanted to, it is easy to
5206 code all of the std::algorithms such that they do not copy function
5207 objects internally.  One merely passes them by reference internally if
5208 desired (this has been fully implemented and shipped for several years).
5209  If this were mandated, it would reverse <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#92">92</a>, allowing
5210 function objects to reliably maintain state.  E.g. the example in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#92">92</a> would reliably remove only the third element.
5211 ]</i></p>
5212
5213
5214
5215 <p><b>Proposed resolution:</b></p>
5216 <p>
5217 Recommend NAD.
5218 </p>
5219
5220
5221 <p><b>Rationale:</b></p>
5222 <p>
5223 Generic algorithms will be marked with concepts and these will imply a requirement
5224 of MoveConstructible (not CopyConstructible).  The signature of the function will
5225 then precisely describe and enforce the precise requirements.
5226 </p>
5227
5228
5229
5230
5231
5232 <hr>
5233 <h3><a name="388"></a>388. Use of complex as a key in associative containers</h3>
5234 <p><b>Section:</b> 26.4 [complex.numbers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
5235  <b>Submitter:</b> Gabriel Dos Reis <b>Opened:</b> 2002-11-08  <b>Last modified:</b> 2008-02-27</p>
5236 <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>
5237 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
5238 <p><b>Discussion:</b></p>
5239 <p>
5240 Practice with std::complex&lt;&gt; and the associative containers
5241 occasionally reveals artificial and distracting issues with constructs
5242 resembling: std::set&lt;std::complex&lt;double&gt; &gt; s;
5243 </p>
5244
5245 <p>
5246 The main reason for the above to fail is the absence of an approriate
5247 definition for std::less&lt;std::complex&lt;T&gt; &gt;. That in turn comes from
5248 the definition of the primary template std::less&lt;&gt; in terms of
5249 operator&lt;.
5250 </p>
5251
5252 <p>
5253 The usual argument goes as follows: Since there is no ordering over
5254 the complex field compatible with field operations it makes little
5255 sense to define a function operator&lt; operating on the datatype
5256 std::complex&lt;T&gt;.  That is fine. However, that reasoning does not carry
5257 over to std::less&lt;T&gt; which is used, among other things, by associative
5258 containers as an ordering useful to meet complexity requirements.
5259 </p>
5260
5261 <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a>.</p>
5262
5263 <p><i>[
5264 Pre Bellevue: Reopened at the request of Alisdair.
5265 ]</i></p>
5266
5267
5268 <p><i>[
5269 Bellevue:
5270 ]</i></p>
5271
5272
5273 <blockquote>
5274 This is a request for a design change, and not a defect in the standard.
5275 It is in scope to consider, but the group feels that it is not a change
5276 that we need to do. Is there a total ordering for floating point values,
5277 including NaN? There is not a clear enough solution or big enough
5278 problem for us to solve. Solving this problem would require solving the
5279 problem for floating point, which is equally unclear. The LWG noted that
5280 users who want to put objects into an associative container for which
5281 operator&lt; isn't defined can simply provide their own comparison function
5282 object. NAD
5283 </blockquote>
5284
5285
5286 <p><b>Proposed resolution:</b></p>
5287 <p>Informally: Add a specialization of std::less for std::complex.</p>
5288
5289
5290 <p><b>Rationale:</b></p>
5291 <p>Discussed in Santa Cruz.  An overwhelming majority of the LWG
5292 believes this should not be treated a DR: it's a request for a design
5293 change, not a defect in the existing standard.  Most people (10-3)
5294 believed that we probably don't want this change, period: as with
5295 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a>, it's hard to know where to draw the line.
5296 The LWG noted that users who want to put objects into an associative
5297 container for which <tt>operator&lt;</tt> isn't defined can simply
5298 provide their own comparison function object.</p>
5299
5300
5301
5302
5303
5304 <hr>
5305 <h3><a name="390"></a>390. CopyConstructible requirements too strict</h3>
5306 <p><b>Section:</b> X [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
5307  <b>Submitter:</b> Doug Gregor <b>Opened:</b> 2002-10-24  <b>Last modified:</b> 2008-03-14</p>
5308 <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>
5309 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
5310 <p><b>Discussion:</b></p>
5311 <p>
5312 The CopyConstructible requirements in Table 30 state that for an
5313 object t of type T (where T is CopyConstructible), the expression &amp;t
5314 returns the address of t (with type T*). This requirement is overly
5315 strict, in that it disallows types that overload operator&amp; to not
5316 return a value of type T*. This occurs, for instance, in the <a href="http://www.boost.org/libs/lambda">Boost.Lambda</a> library, where
5317 operator&amp; is overloaded for a Boost.Lambda function object to return
5318 another function object.
5319 </p>
5320
5321 <p>Example:</p>
5322
5323 <pre>  std::vector&lt;int&gt; u, v;
5324   int x;
5325   // ...
5326   std::transform(u.begin(), u.end(), std::back_inserter(v), _1 * x);
5327 </pre>
5328
5329 <p>
5330 _1 * x returns an unnamed function object with operator&amp; overloaded to
5331 not return T* , therefore rendering the std::transform call ill-formed.
5332 However, most standard library implementations will compile this code
5333 properly, and the viability of such binder libraries is severely hindered
5334 by the unnecessary restriction in the CopyConstructible requirements.
5335 </p>
5336
5337 <p>
5338 For reference, the address of an object can be retrieved without using
5339 the address-of operator with the following function template:
5340 </p>
5341
5342 <pre>  template &lt;typename T&gt; T* addressof(T&amp; v)
5343   {
5344     return reinterpret_cast&lt;T*&gt;(
5345          &amp;const_cast&lt;char&amp;&gt;(reinterpret_cast&lt;const volatile char &amp;&gt;(v)));
5346   }
5347 </pre>
5348
5349 <p>
5350 Note: this relates directly to library issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a>, which
5351 will need to be reexamined if the CopyConstructible requirements
5352 change.
5353 </p>
5354
5355
5356 <p><b>Proposed resolution:</b></p>
5357 <p>
5358 Remove the last two rows of Table 30, eliminating the requirements
5359 that &amp;t and &amp;u return the address of t and u, respectively.
5360 </p>
5361
5362
5363 <p><b>Rationale:</b></p>
5364 <p>This was a deliberate design decision.  Perhaps it should be
5365    reconsidered for C++0x. </p>
5366
5367
5368
5369
5370
5371 <hr>
5372 <h3><a name="392"></a>392. 'equivalence' for input iterators</h3>
5373 <p><b>Section:</b> 24.2.2 [input.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
5374  <b>Submitter:</b> Corwin Joy <b>Opened:</b> 2002-12-11  <b>Last modified:</b> 2006-12-27</p>
5375 <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>
5376 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
5377 <p><b>Discussion:</b></p>
5378
5379 <p>
5380 In section 24.2.2 [input.iterators] table 72 -
5381 'Input Iterator Requirements' we have as a postcondition of *a:
5382 "If a==b and (a, b) is in the domain of == then *a is equivalent to *b".
5383 </p>
5384
5385 <p>
5386 In section 24.6.3.5 [istreambuf.iterator::equal] it states that
5387 "istreambuf_iterator::equal returns true if and only if both iterators
5388 are at end-of-stream, or neither is at end-of-stream, <i>regardless of
5389 what streambuf object they use</i>."  (My emphasis).
5390 </p>
5391
5392 <p>
5393 The defect is that either 'equivalent' needs to be more precisely
5394 defined or the conditions for equality in 24.6.3.5 [istreambuf.iterator::equal]
5395 are incorrect. (Or both).
5396 </p>
5397
5398 <p>Consider the following example:</p>
5399 <pre>   #include &lt;iostream&gt;
5400    #include &lt;fstream&gt;
5401    #include &lt;iterator&gt;
5402    using namespace std;
5403
5404    int main() {
5405     ifstream file1("file1.txt"), file2("file2.txt");
5406     istreambuf_iterator&lt;char&gt; f1(file1), f2(file2);
5407     cout &lt;&lt; "f1 == f2 : " &lt;&lt; boolalpha &lt;&lt; (f1 == f2) &lt;&lt; endl;
5408     cout &lt;&lt; "f1 = " &lt;&lt; *f1 &lt;&lt; endl;
5409     cout &lt;&lt; "f2 = " &lt;&lt; *f2 &lt;&lt; endl;
5410     return 0;
5411    }
5412 </pre>
5413
5414 <p>Now assuming that neither f1 or f2 are at the end-of-stream then
5415 f1 == f2 by 24.6.3.5 [istreambuf.iterator::equal].</p>
5416
5417 <p>However, it is unlikely that *f1 will give the same value as *f2 except
5418 by accident.</p>
5419
5420 <p>So what does *f1 'equivalent' to *f2 mean?  I think the standard should
5421 be clearer on this point, or at least be explicit that this does not
5422 mean that *f1 and *f2 are required to have the same value in the case
5423 of input iterators.</p>
5424
5425
5426 <p><b>Proposed resolution:</b></p>
5427
5428
5429 <p><b>Rationale:</b></p><p>The two iterators aer not in the domain of ==</p>
5430
5431
5432
5433
5434
5435
5436 <hr>
5437 <h3><a name="393"></a>393. do_in/do_out operation on state unclear</h3>
5438 <p><b>Section:</b> 22.4.1.4.2 [locale.codecvt.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
5439  <b>Submitter:</b> Alberto Barbati <b>Opened:</b> 2002-12-24  <b>Last modified:</b> 2008-07-02</p>
5440 <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>
5441 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
5442 <p><b>Discussion:</b></p>
5443 <p>
5444 this DR follows the discussion on the previous thread "codecvt::do_in
5445 not consuming external characters". It's just a clarification issue
5446 and not a request for a change.
5447 </p>
5448 <p>
5449 Can do_in()/do_out() produce output characters without consuming input
5450 characters as a result of operation on state?
5451 </p>
5452
5453
5454 <p><b>Proposed resolution:</b></p>
5455 <p>
5456 Add a note at the end of 22.4.1.4.2 [locale.codecvt.virtuals],
5457 paragraph 3:
5458 </p>
5459
5460 <p>
5461 [Note: As a result of operations on state, it can return ok or partial
5462 and set from_next == from and to_next != to. --end note]
5463 </p>
5464
5465
5466 <p><b>Rationale:</b></p>
5467 <p>
5468 The submitter believes that standard already provides an affirmative
5469 answer to the question. However, the current wording has induced a few
5470 library implementors to make the incorrect assumption that
5471 do_in()/do_out() always consume at least one internal character when
5472 they succeed.
5473 </p>
5474
5475 <p>
5476 The submitter also believes that the proposed resolution is not in
5477 conflict with the related issue 76. Moreover, by explicitly allowing
5478 operations on state to produce characters, a codecvt implementation
5479 may effectively implement N-to-M translations without violating the
5480 "one character at a time" principle described in such issue. On a side
5481 note, the footnote in the proposed resolution of issue 76 that
5482 informally rules out N-to-M translations for basic_filebuf should be
5483 removed if this issue is accepted as valid.
5484 </p>
5485
5486
5487 <p><i>[
5488 Kona (2007): The proposed resolution is to add a note. Since this is
5489 non-normative, the issue is editorial, but we believe that the note is
5490 correct. Proposed Disposition: NAD, Editorial
5491 ]</i></p>
5492
5493
5494
5495
5496
5497
5498 <hr>
5499 <h3><a name="399"></a>399. volations of unformatted input function requirements</h3>
5500 <p><b>Section:</b> 27.7.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
5501  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-01-05  <b>Last modified:</b> 2006-12-27</p>
5502 <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>
5503 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
5504 <p><b>Discussion:</b></p>
5505     <p>
5506 The Effects clauses for the two functions below violate the
5507 general requirements on unformatted input functions outlined
5508 in 27.6.1.3: they do not begin by constructing a sentry object.
5509 Instead, they begin by calling widen ('\n'), which may throw
5510 an exception. The exception is then allowed to propagate from
5511 the unformatted input function irrespective of the setting of
5512 exceptions().
5513     </p>
5514     <p>
5515 Note that in light of 27.6.1.1, p3 and p4, the fact that the
5516 functions allow exceptions thrown from widen() to propagate
5517 may not strictly speaking be a defect (but the fact that the
5518 functions do not start by constructing a sentry object still
5519 is). However, since an exception thrown from ctype&lt;charT&gt;
5520 ::widen() during any other input operation (say, from within
5521 a call to num_get&lt;charT&gt;::get()) will be caught and cause
5522 badbit to be set, these two functions should not be treated
5523 differently for the sake of consistency.
5524     </p>
5525
5526
5527 <p><b>Proposed resolution:</b></p>
5528
5529
5530 <p><b>Rationale:</b></p>
5531 <p>
5532 Not a defect.  The standard is consistent, and the behavior required
5533 by the standard is unambiguous.  Yes, it's theoretically possible for
5534 widen to throw.  (Not that this will happen for the default ctype
5535 facet or for most real-world replacement ctype facets.)  Users who
5536 define ctype facets that can throw, and who care about this behavior,
5537 can use alternative signatures that don't call widen.
5538 </p>
5539
5540
5541
5542
5543
5544
5545 <hr>
5546 <h3><a name="429"></a>429. typo in basic_ios::clear(iostate)</h3>
5547 <p><b>Section:</b> 27.5.4.3 [iostate.flags] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
5548  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18  <b>Last modified:</b> 2006-12-30</p>
5549 <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>
5550 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
5551 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#412">412</a></p>
5552 <p><b>Discussion:</b></p>
5553         <p>
5554
5555 The Effects clause in 27.4.4.3, p5 describing the effects of a call to
5556 the ios_base member function clear(iostate state) says that the function
5557 only throws if the respective bits are already set prior to the function
5558 call. That's obviously not the intent. If it was, a call to clear(badbit)
5559 on an object for which (rdstate() == goodbit &amp;&amp; exceptions() == badbit)
5560 holds would not result in an exception being thrown.
5561
5562         </p>
5563
5564     <p><b>Proposed resolution:</b></p>
5565         <p>
5566
5567 The text ought to be changed from
5568 <br>
5569
5570 "If (rdstate() &amp; exceptions()) == 0, returns. ..."
5571 <br>
5572
5573 to
5574 <br>
5575
5576 "If (state &amp; exceptions()) == 0, returns. ..."
5577         </p>
5578
5579
5580 <p><b>Rationale:</b></p>
5581
5582
5583
5584
5585
5586
5587 <hr>
5588 <h3><a name="433"></a>433. Contradiction in specification of unexpected()</h3>
5589 <p><b>Section:</b> 18.8.2.4 [unexpected] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
5590  <b>Submitter:</b> Vyatcheslav Sysoltsev <b>Opened:</b> 2003-09-29  <b>Last modified:</b> 2006-12-27</p>
5591 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
5592 <p><b>Discussion:</b></p>
5593 <p>
5594 Clause 15.5.2 [except.unexpected] paragraph 1 says that "void unexpected();
5595 is called (18.7.2) immediately after completing the stack unwinding
5596 for the former function", but 18.7.2.4 (Effects) says that "void
5597 unexpected(); . . . Calls the unexpected_handler function in effect
5598 immediately after evaluating the throwexpression (18.7.2.2),".  Isn't
5599 here a contradiction: 15.5.2 requires stack have been unwound when in
5600 void unexpected() and therefore in unexpected_handler but 18.7.2.4
5601 claims that unexpected_handler is called "in effect immediately" after
5602 evaluation of throw expression is finished, so there is no space left
5603 for stack to be unwound therefore?  I think the phrase "in effect
5604 immediately" should be removed from the standard because it brings
5605 ambiguity in understanding.
5606 </p>
5607
5608
5609 <p><b>Proposed resolution:</b></p>
5610
5611
5612 <p><b>Rationale:</b></p>
5613 <p>There is no contradiction.  The phrase "in effect immediately" is
5614   just to clarify which handler is to be called.</p>
5615
5616
5617
5618
5619
5620 <hr>
5621 <h3><a name="437"></a>437. Formatted output of function pointers is confusing</h3>
5622 <p><b>Section:</b> 27.7.2.6.2 [ostream.inserters.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
5623  <b>Submitter:</b> Ivan Godard <b>Opened:</b> 2003-10-24  <b>Last modified:</b> 2006-12-27</p>
5624 <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>
5625 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
5626 <p><b>Discussion:</b></p>
5627 <p>
5628 Given:
5629 </p>
5630 <pre>void f(int) {}
5631 void(*g)(int) = f;
5632 cout &lt;&lt; g;
5633 </pre>
5634
5635 <p>
5636 (with the expected #include and usings), the value printed is a rather
5637 surprising "true". Rather useless too.
5638 </p>
5639
5640 <p>The standard defines:</p>
5641
5642 <pre>ostream&amp; operator&lt;&lt;(ostream&amp;, void*);</pre>
5643
5644 <p>which picks up all data pointers and prints their hex value, but does
5645 not pick up function pointers because there is no default conversion
5646 from function pointer to void*. Absent that, we fall back to legacy
5647 conversions from C and the function pointer is converted to bool.
5648 </p>
5649
5650 <p>There should be an analogous inserter that prints the address of a
5651   function pointer.</p>
5652
5653
5654 <p><b>Proposed resolution:</b></p>
5655
5656
5657 <p><b>Rationale:</b></p>
5658 <p>This is indeed a wart, but there is no good way to solve it.  C
5659   doesn't provide a portable way of outputting the address of a
5660   function point either.</p>
5661
5662
5663
5664
5665
5666 <hr>
5667 <h3><a name="439"></a>439. Should facets be copyable?</h3>
5668 <p><b>Section:</b> 22.4 [locale.categories] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
5669  <b>Submitter:</b> Matt Austern <b>Opened:</b> 2003-11-02  <b>Last modified:</b> 2006-12-27</p>
5670 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.categories">active issues</a> in [locale.categories].</p>
5671 <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>
5672 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
5673 <p><b>Discussion:</b></p>
5674 <p>The following facets classes have no copy constructors described in
5675   the standard, which, according to the standard, means that they are
5676   supposed to use the compiler-generated defaults.  Default copy
5677   behavior is probably inappropriate.  We should either make these
5678   classes uncopyable or else specify exactly what their constructors do.</p>
5679
5680 <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#421">421</a>.</p>
5681
5682 <pre>        ctype_base
5683         ctype
5684         ctype_byname
5685         ctype&lt;char&gt;
5686         ctype_byname&lt;char&gt;
5687         codecvt_base
5688         codecvt
5689         codecvt_byname
5690         num_get
5691         num_put
5692         numpunct
5693         numpunct_byname
5694         collate
5695         collate_byname
5696         time_base
5697         time_get
5698         time_get_byname
5699         time_put
5700         time_put_byname
5701         money_get
5702         money_put
5703         money_base
5704         moneypunct
5705         moneypunct_byname
5706         messages_base
5707         messages
5708         messages_byname
5709 </pre>
5710
5711
5712
5713 <p><b>Proposed resolution:</b></p>
5714
5715
5716 <p><b>Rationale:</b></p>
5717 <p>The copy constructor in the base class is private.</p>
5718
5719
5720
5721
5722
5723 <hr>
5724 <h3><a name="440"></a>440. Should std::complex use unqualified transcendentals?</h3>
5725 <p><b>Section:</b> 26.4.8 [complex.transcendentals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
5726  <b>Submitter:</b> Matt Austern <b>Opened:</b> 2003-11-05  <b>Last modified:</b> 2009-03-21</p>
5727 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
5728 <p><b>Discussion:</b></p>
5729 <p>
5730 Operations like <tt>pow</tt> and <tt>exp</tt> on
5731 <tt>complex&lt;T&gt;</tt> are typically implemented in terms of
5732 operations like <tt>sin</tt> and <tt>cos</tt> on <tt>T</tt>.
5733 Should implementations write this as <tt>std::sin</tt>, or as plain
5734 unqualified <tt>sin</tt>?
5735 </p>
5736
5737 <p>The issue, of course, is whether we want to use
5738 argument-dependent lookup in the case where <tt>T</tt> is a
5739 user-defined type.  This is similar to the issue of valarray
5740 transcendentals, as discussed in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a>.</p>
5741
5742 <p>This issue differs from valarray transcendentals in two important
5743 ways.  First, "the effect of instantiating the template
5744 <tt>complex</tt> for types other than float, double or long double is
5745 unspecified." (26.4.1 [complex.syn]) Second, the standard does not
5746 dictate implementation, so there is no guarantee that a particular
5747 real math function is used in the implementation of a particular
5748 complex function.</p>
5749
5750
5751
5752 <p><b>Proposed resolution:</b></p>
5753
5754
5755 <p><b>Rationale:</b></p>
5756 <p>If you instantiate std::complex for user-defined types, all bets
5757 are off.</p>
5758
5759
5760
5761
5762
5763 <hr>
5764 <h3><a name="447"></a>447. Wrong template argument for time facets</h3>
5765 <p><b>Section:</b> 22.3.1.1.1 [locale.category] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
5766  <b>Submitter:</b> Pete Becker <b>Opened:</b> 2003-12-26  <b>Last modified:</b> 2007-01-15</p>
5767 <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>
5768 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
5769 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#327">327</a></p>
5770 <p><b>Discussion:</b></p>
5771 <p>
5772 22.1.1.1.1/4, table 52, "Required Instantiations", lists, among others:
5773 </p>
5774 <pre>    time_get&lt;char,InputIterator&gt;
5775     time_get_byname&lt;char,InputIterator&gt;
5776     time_get&lt;wchar_t,OutputIterator&gt;
5777     time_get_byname&lt;wchar_t,OutputIterator&gt;
5778 </pre>
5779
5780 <p>
5781 The second argument to the last two should be InputIterator, not
5782 OutputIterator.
5783 </p>
5784
5785
5786 <p><b>Proposed resolution:</b></p>
5787 <p>
5788 Change the second template argument to InputIterator.
5789 </p>
5790
5791
5792 <p><b>Rationale:</b></p>
5793
5794
5795
5796
5797
5798
5799 <hr>
5800 <h3><a name="450"></a>450. set::find is inconsistent with associative container requirements</h3>
5801 <p><b>Section:</b> 23.4.3 [set] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
5802  <b>Submitter:</b> Bill Plauger <b>Opened:</b> 2004-01-30  <b>Last modified:</b> 2009-05-01</p>
5803 <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>
5804 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
5805 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#214">214</a></p>
5806 <p><b>Discussion:</b></p>
5807 <p>map/multimap have:</p>
5808
5809 <pre>    iterator find(const key_type&amp; x) const;
5810     const_iterator find(const key_type&amp; x) const;
5811 </pre>
5812
5813 <p>
5814 which is consistent with the table of associative container requirements.
5815 But set/multiset have:
5816 </p>
5817 <pre>    iterator find(const key_type&amp;) const;
5818 </pre>
5819
5820 <p>
5821 set/multiset should look like map/multimap, and honor the requirements
5822 table, in this regard.
5823 </p>
5824
5825
5826 <p><b>Proposed resolution:</b></p>
5827
5828
5829 <p><b>Rationale:</b></p>
5830
5831
5832
5833
5834
5835
5836 <hr>
5837 <h3><a name="451"></a>451. Associative erase should return an iterator</h3>
5838 <p><b>Section:</b> 23.2.4 [associative.reqmts], 23.4 [associative] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
5839  <b>Submitter:</b> Bill Plauger <b>Opened:</b> 2004-01-30  <b>Last modified:</b> 2009-05-01</p>
5840 <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>
5841 <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>
5842 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
5843 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#130">130</a></p>
5844 <p><b>Discussion:</b></p>
5845 <p>map/multimap/set/multiset have:</p>
5846 <pre>    void erase(iterator);
5847     void erase(iterator, iterator);
5848 </pre>
5849
5850 <p>But there's no good reason why these can't return an iterator, as for
5851 vector/deque/list:</p>
5852 <pre>    iterator erase(iterator);
5853     iterator erase(iterator, iterator);
5854 </pre>
5855
5856
5857
5858 <p><b>Proposed resolution:</b></p>
5859 <p>
5860 Informally: The table of associative container requirements, and the
5861 relevant template classes, should return an iterator designating the
5862 first element beyond the erased subrange.
5863 </p>
5864
5865
5866 <p><b>Rationale:</b></p>
5867
5868
5869
5870
5871
5872
5873 <hr>
5874 <h3><a name="452"></a>452.  locale::combine should be permitted to generate a named locale</h3>
5875 <p><b>Section:</b> 22.3.1.3 [locale.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
5876  <b>Submitter:</b> Bill Plauger <b>Opened:</b> 2004-01-30  <b>Last modified:</b> 2009-05-01</p>
5877 <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>
5878 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
5879 <p><b>Discussion:</b></p>
5880 <pre>template&lt;class Facet&gt;
5881     locale::combine(const locale&amp;) const;
5882 </pre>
5883 <p>
5884 is obliged to create a locale that has no name. This is overspecification
5885 and overkill. The resulting locale should follow the usual rules -- it
5886 has a name if the locale argument has a name and Facet is one of the
5887 standard facets.
5888 </p>
5889
5890 <p><i>[
5891  Sydney and post-Sydney (see c++std-lib-13439, c++std-lib-13440,
5892  c++std-lib-13443): agreed that it's overkill to say that the locale
5893  is obligated to be nameless.  However, we also can't require it to
5894  have a name.  At the moment, locale names are based on categories
5895  and not on individual facets.  If a locale contains two different
5896  facets of different names from the same category, then this would
5897  not fit into existing naming schemes.  We need to give
5898  implementations more freedom.  Bill will provide wording.
5899 ]</i></p>
5900
5901
5902
5903
5904 <p><b>Rationale:</b></p>
5905 <p>After further discussion the LWG decided to close this as NAD.
5906   The fundamental problem is that names right now are per-category,
5907   not per-facet.  The <tt>combine</tt> member function works at the
5908   wrong level of granularity.</p>
5909
5910
5911
5912
5913
5914 <hr>
5915 <h3><a name="454"></a>454. basic_filebuf::open should accept wchar_t names</h3>
5916 <p><b>Section:</b> 27.9.1.4 [filebuf.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
5917  <b>Submitter:</b> Bill Plauger <b>Opened:</b> 2004-01-30  <b>Last modified:</b> 2009-05-01</p>
5918 <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>
5919 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
5920 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#105">105</a></p>
5921 <p><b>Discussion:</b></p>
5922 <pre>    basic_filebuf *basic_filebuf::open(const char *, ios_base::open_mode);
5923 </pre>
5924
5925 <p>should be supplemented with the overload:</p>
5926
5927 <pre>    basic_filebuf *basic_filebuf::open(const wchar_t *, ios_base::open_mode);
5928 </pre>
5929
5930 <p>
5931 Depending on the operating system, one of these forms is fundamental and
5932 the other requires an implementation-defined mapping to determine the
5933 actual filename.
5934 </p>
5935
5936 <p><i>[Sydney: Yes, we want to allow wchar_t filenames.  Bill will
5937   provide wording.]</i></p>
5938
5939
5940 <p><i>[
5941 In Toronto we noted that this is issue 5 from
5942 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1569.htm">N1569</a>.
5943 ]</i></p>
5944
5945 <p>
5946 How does this interact with the newly-defined character types, and how
5947 do we avoid interface explosion considering <tt>std::string</tt> overloads that
5948 were added? Propose another solution that is different than the
5949 suggestion proposed by PJP.
5950 </p>
5951 <p>
5952 Suggestion is to make a member template function for <tt>basic_string</tt> (for
5953 <tt>char</tt>, <tt>wchar_t</tt>, <tt>u16char</tt>, <tt>u32char</tt> instantiations), and then just keep a
5954 <tt>const char*</tt> member.
5955 </p>
5956 <p>
5957 Goal is to do implicit conversion between character string literals to
5958 appropriate <tt>basic_string</tt> type. Not quite sure if this is possible.
5959 </p>
5960 <p>
5961 Implementors are free to add specific overloads for non-char character
5962 types.
5963 </p>
5964
5965 <p><i>[
5966 Martin adds pre-Sophia Antipolis:
5967 ]</i></p>
5968
5969
5970 <blockquote>
5971 Please see <a href="http://wiki.dinkumware.com/twiki/pub/Wg21sophiaAntipolis/LibraryWorkingGroup/issue-454.html">issue 454: problems and solutions</a>.
5972 </blockquote>
5973
5974 <p><i>[
5975 Sophia Antipolis:
5976 ]</i></p>
5977
5978
5979 <blockquote>
5980 <p>
5981 Beman is concerned that making these changes to <tt>basic_filebuf</tt> is not
5982 usefully changed unless <tt>fstream</tt> is also changed; this also only handles
5983 <tt>wchar_t</tt> and not other character types.
5984 </p>
5985 <p>
5986 The TR2 filesystem library is a more complete solution, but is not available soon.
5987 </p>
5988 </blockquote>
5989
5990 <p><i>[
5991 Martin adds:  please reference
5992 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2683.html">N2683</a> for
5993 problems and solutions.
5994 ]</i></p>
5995
5996
5997
5998
5999 <p><b>Proposed resolution:</b></p>
6000
6001 <p>Change from:</p>
6002 <blockquote>
6003 <pre>basic_filebuf&lt;charT,traits&gt;* open(
6004     const char* s,
6005     ios_base::openmode mode );
6006 </pre>
6007
6008 <p>
6009 Effects: If is_open() != false, returns a null pointer.
6010 Otherwise, initializes the filebuf as required. It then
6011 opens a file, if possible, whose name is the NTBS s ("as if"
6012 by calling std::fopen(s,modstr)).</p>
6013 </blockquote>
6014
6015 <p>to:</p>
6016
6017 <blockquote>
6018 <pre>basic_filebuf&lt;charT,traits&gt;* open(
6019     const char* s,
6020     ios_base::openmode mode );
6021
6022 basic_filebuf&lt;charT,traits&gt;* open(
6023     const wchar_t* ws,
6024     ios_base::openmode mode );
6025 </pre>
6026
6027 <p>
6028 Effects: If is_open() != false, returns a null pointer.
6029 Otherwise, initializes the filebuf as required. It then
6030 opens a file, if possible, whose name is the NTBS s ("as if"
6031 by calling std::fopen(s,modstr)).
6032 For the second signature, the NTBS s is determined from the
6033 WCBS ws in an implementation-defined manner.
6034 </p>
6035
6036 <p>
6037 (NOTE: For a system that "naturally" represents a filename
6038 as a WCBS, the NTBS s in the first signature may instead
6039 be mapped to a WCBS; if so, it follows the same mapping
6040 rules as the first argument to open.)
6041 </p>
6042 </blockquote>
6043
6044
6045
6046 <p><b>Rationale:</b></p>
6047 <p>
6048 Slightly controversial, but by a 7-1 straw poll the LWG agreed to move
6049 this to Ready.  The controversy was because the mapping between wide
6050 names and files in a filesystem is implementation defined.  The
6051 counterargument, which most but not all LWG members accepted, is that
6052 the mapping between narrow files names and files is also
6053 implemenation defined.</p>
6054
6055 <p><i>[Lillehammer: Moved back to "open" status, at Beman's urging.
6056 (1) Why just basic_filebuf, instead of also basic_fstream (and
6057 possibly other things too). (2) Why not also constructors that take
6058 std::basic_string? (3) We might want to wait until we see Beman's
6059 filesystem library; we might decide that it obviates this.]</i></p>
6060
6061
6062 <p><i>[
6063 post Bellevue:
6064 ]</i></p>
6065
6066
6067 <blockquote>
6068 <p>
6069 Move again to Ready.
6070 </p>
6071 <p>
6072 There is a timing issue here. Since the filesystem library will not be
6073 in C++0x, this should be brought forward. This solution would remain
6074 valid in the context of the proposed filesystem.
6075 </p>
6076 <p>
6077 This issue has been kicking around for a while, and the wchar_t addition
6078 alone would help many users. Thus, we suggest putting this on the
6079 reflector list with an invitation for someone to produce proposed
6080 wording that covers basic_fstream. In the meantime, we suggest that the
6081 proposed wording be adopted as-is.
6082 </p>
6083 <p>
6084 If more of the Lillehammer questions come back, they should be
6085 introduced as separate issues.
6086 </p>
6087 </blockquote>
6088
6089 <p><i>[
6090 San Francisco:
6091 ]</i></p>
6092
6093
6094 <blockquote>
6095 Some existing implementations provide overload already. Expected
6096 filesystem "path" object overloads neatly, without surprises; implying
6097 NAD.
6098 </blockquote>
6099
6100
6101
6102
6103
6104
6105
6106 <hr>
6107 <h3><a name="462"></a>462. Destroying objects with static storage duration</h3>
6108 <p><b>Section:</b> 3.6.3 [basic.start.term], 18.4 [cstdint] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
6109  <b>Submitter:</b> Bill Plauger <b>Opened:</b> 2004-03-23  <b>Last modified:</b> 2008-02-25</p>
6110 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
6111 <p><b>Discussion:</b></p>
6112 <p>
6113 3.6.3 Termination spells out in detail the interleaving of static
6114 destructor calls and calls to functions registered with atexit. To
6115 match this behavior requires intimate cooperation between the code
6116 that calls destructors and the exit/atexit machinery. The former
6117 is tied tightly to the compiler; the latter is a primitive mechanism
6118 inherited from C that traditionally has nothing to do with static
6119 construction and destruction. The benefits of intermixing destructor
6120 calls with atexit handler calls is questionable at best, and <i>very</i>
6121 difficult to get right, particularly when mixing third-party C++
6122 libraries with different third-party C++ compilers and C libraries
6123 supplied by still other parties.
6124 </p>
6125
6126 <p>
6127 I believe the right thing to do is defer all static destruction
6128 until after all atexit handlers are called. This is a change in
6129 behavior, but one that is likely visible only to perverse test
6130 suites. At the very least, we should <i>permit</i> deferred destruction
6131 even if we don't require it.
6132 </p>
6133
6134 <p><i>[If this is to be changed, it should probably be changed by CWG.
6135   At this point, however, the LWG is leaning toward NAD.  Implementing
6136   what the standard says is hard work, but it's not impossible and
6137   most vendors went through that pain years ago.  Changing this
6138   behavior would be a user-visible change, and would break at least
6139   one real application.]</i></p>
6140
6141
6142 <p><i>[
6143 Batavia:  Send to core with our recommendation that we should permit deferred
6144 destruction but not require it.
6145 ]</i></p>
6146
6147
6148 <p><i>[
6149 Howard:  The course of action recommended in Batavia would undo LWG
6150 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#3">3</a> and break current code implementing the "phoenix
6151 singleton". Search the net for "phoenix singleton atexit" to get a feel
6152 for the size of the adverse impact this change would have.  Below is
6153 sample code which implements the phoenix singleton and would break if
6154 <tt>atexit</tt> is changed in this way:
6155 ]</i></p>
6156
6157
6158 <blockquote><pre>#include &lt;cstdlib&gt;
6159 #include &lt;iostream&gt;
6160 #include &lt;type_traits&gt;
6161 #include &lt;new&gt;
6162
6163 class A
6164 {
6165     bool alive_;
6166     A(const A&amp;);
6167     A&amp; operator=(const A&amp;);
6168 public:
6169     A() : alive_(true) {std::cout &lt;&lt; "A()\n";}
6170     ~A() {alive_ = false; std::cout &lt;&lt; "~A()\n";}
6171     void use()
6172     {
6173         if (alive_)
6174             std::cout &lt;&lt; "A is alive\n";
6175         else
6176             std::cout &lt;&lt; "A is dead\n";
6177     }
6178 };
6179
6180 void deallocate_resource();
6181
6182 // This is the phoenix singleton pattern
6183 A&amp; get_resource(bool create = true)
6184 {
6185     static std::aligned_storage&lt;sizeof(A), std::alignment_of&lt;A&gt;::value&gt;::type buf;
6186     static A* a;
6187     if (create)
6188     {
6189         if (a != (A*)&amp;buf)
6190         {
6191             a = ::new (&amp;buf) A;
6192             std::atexit(deallocate_resource);
6193         }
6194     }
6195     else
6196     {
6197         a-&gt;~A();
6198         a = (A*)&amp;buf + 1;
6199     }
6200     return *a;
6201 }
6202
6203 void deallocate_resource()
6204 {
6205     get_resource(false);
6206 }
6207
6208 void use_A(const char* message)
6209 {
6210     A&amp; a = get_resource();
6211     std::cout &lt;&lt; "Using A " &lt;&lt; message &lt;&lt; "\n";
6212     a.use();
6213 }
6214
6215 struct B
6216 {
6217     ~B() {use_A("from ~B()");}
6218 };
6219
6220 B b;
6221
6222 int main()
6223 {
6224     use_A("from main()");
6225 }
6226 </pre></blockquote>
6227
6228 <p>
6229 The correct output is:
6230 </p>
6231
6232 <blockquote><pre>A()
6233 Using A from main()
6234 A is alive
6235 ~A()
6236 A()
6237 Using A from ~B()
6238 A is alive
6239 ~A()
6240 </pre></blockquote>
6241
6242 <p><i>[
6243 Bellevue: Confirmed no interaction with <tt>quick_exit</tt>.
6244 Strong feeling against mandating the change. Leaning towards NAD rather than permitting the change,
6245 as this would make common implementations of pheonix-singleton pattern implementation defined, as noted by Howard.
6246 Bill agrees issue is no longer serious, and accepts NAD.
6247 ]</i></p>
6248
6249
6250
6251
6252 <p><b>Proposed resolution:</b></p>
6253 <p>
6254 </p>
6255
6256
6257
6258
6259
6260 <hr>
6261 <h3><a name="470"></a>470. accessing containers from their elements' special functions</h3>
6262 <p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
6263  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2004-06-28  <b>Last modified:</b> 2007-04-18</p>
6264 <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>
6265 <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>
6266 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
6267 <p><b>Discussion:</b></p>
6268
6269 <p>
6270 The standard doesn't prohibit the destructors (or any other special
6271 functions) of containers' elements invoked from a member function
6272 of the container from "recursively" calling the same (or any other)
6273 member function on the same container object, potentially while the
6274 container is in an intermediate state, or even changing the state
6275 of the container object while it is being modified. This may result
6276 in some surprising (i.e., undefined) behavior.
6277 </p>
6278
6279 <p>Read email thread starting with c++std-lib-13637 for more.</p>
6280
6281
6282
6283 <p><b>Proposed resolution:</b></p>
6284
6285 <p>Add to Container Requirements the following new paragraph:</p>
6286
6287 <pre>    Unless otherwise specified, the behavior of a program that
6288     invokes a container member function f from a member function
6289     g of the container's value_type on a container object c that
6290     called g from its mutating member function h, is undefined.
6291     I.e., if v is an element of c, directly or indirectly calling
6292     c.h() from v.g() called from c.f(), is undefined.
6293 </pre>
6294
6295 <p><i>[Redmond: This is a real issue, but it's probably a clause 17
6296   issue, not clause 23.  We get the same issue, for example, if we
6297   try to destroy a stream from one of the stream's callback functions.]</i></p>
6298
6299
6300
6301
6302 <p><b>Rationale:</b></p>
6303 <p>
6304 Recommend NAD.  We agree this is an issue, but not a defect.
6305 We believe that there is no wording we can put in the standard
6306 that will cover all cases without introducing unfortunate
6307 corner cases.
6308 </p>
6309
6310
6311
6312
6313
6314 <hr>
6315 <h3><a name="472"></a>472. Missing "Returns" clause in std::equal_range</h3>
6316 <p><b>Section:</b> 25.5.3.3 [equal.range] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
6317  <b>Submitter:</b> Prateek R Karandikar <b>Opened:</b> 2004-06-30  <b>Last modified:</b> 2006-12-30</p>
6318 <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>
6319 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
6320 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#270">270</a></p>
6321 <p><b>Discussion:</b></p>
6322 <p>
6323 There is no "Returns:" clause for std::equal_range, which returns non-void.
6324 </p>
6325
6326
6327 <p><b>Proposed resolution:</b></p>
6328
6329
6330 <p><b>Rationale:</b></p>
6331 <p>Fixed as part of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#270">270</a>.</p>
6332
6333
6334
6335
6336
6337
6338 <hr>
6339 <h3><a name="476"></a>476. Forward Iterator implied mutability</h3>
6340 <p><b>Section:</b> 24.2.4 [forward.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
6341  <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2004-07-09  <b>Last modified:</b> 2007-01-15</p>
6342 <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>
6343 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
6344 <p><b>Discussion:</b></p>
6345
6346 <p>24.1/3 says:</p>
6347 <blockquote><p>
6348   Forward iterators satisfy all the requirements of the input and
6349   output iterators and can be used whenever either kind is specified
6350 </p></blockquote>
6351
6352 <p>
6353 The problem is that satisfying the requirements of output iterator
6354 means that you can always assign *something* into the result of
6355 dereferencing it.  That makes almost all non-mutable forward
6356 iterators non-conforming.  I think we need to sever the refinement
6357 relationship between forward iterator and output iterator.
6358 </p>
6359
6360 <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#200">200</a>.  But this is not a dup.</p>
6361
6362
6363
6364 <p><b>Proposed resolution:</b></p>
6365
6366
6367 <p><b>Rationale:</b></p>
6368 <p>Yes, 24.1/3 does say that. But it's introductory material. The
6369 precise specification is in 24.1.3, and the requrements table there is
6370 right.  We don't need to fine-tune introductory wording.  (Especially
6371 since this wording is likely to be changed as part of the iterator
6372 overhaul.)</p>
6373
6374
6375
6376
6377
6378 <hr>
6379 <h3><a name="477"></a>477. Operator-&gt; for const forward iterators</h3>
6380 <p><b>Section:</b> 24.2.4 [forward.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
6381  <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2004-07-11  <b>Last modified:</b> 2007-01-15</p>
6382 <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>
6383 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
6384 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a></p>
6385 <p><b>Discussion:</b></p>
6386 <p>
6387 The Forward Iterator requirements table contains the following:
6388 </p>
6389 <pre> expression  return type         operational  precondition
6390                                   semantics
6391   ==========  ==================  ===========  ==========================
6392   a-&gt;m        U&amp; if X is mutable, (*a).m       pre: (*a).m is well-defined.
6393               otherwise const U&amp;
6394
6395   r-&gt;m        U&amp;                  (*r).m       pre: (*r).m is well-defined.
6396 </pre>
6397
6398 <p>
6399 The first line is exactly right.  The second line is wrong.  Basically
6400 it implies that the const-ness of the iterator affects the const-ness
6401 of referenced members.  But Paragraph 11 of [lib.iterator.requirements] says:
6402 </p>
6403
6404 <blockquote><p>
6405    In the following sections, a and b denote values of type const X, n
6406    denotes a value of the difference type Distance, u, tmp, and m
6407    denote identifiers, r denotes a value of X&amp;, t denotes a value of
6408    value type T, o denotes a value of some type that is writable to
6409    the output iterator.
6410 </p></blockquote>
6411
6412 <p>AFAICT if we need the second line at all, it should read the same
6413 as the first line.</p>
6414
6415 <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a></p>
6416
6417
6418 <p><b>Proposed resolution:</b></p>
6419
6420
6421 <p><b>Rationale:</b></p>
6422 <p>The LWG agrees that this is a real problem.  Marked as a DUP
6423   because the LWG chose to adopt the solution proposed in
6424   <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>.
6425 </p>
6426
6427
6428
6429
6430
6431 <hr>
6432 <h3><a name="479"></a>479. Container requirements and placement new</h3>
6433 <p><b>Section:</b> 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
6434  <b>Submitter:</b> Herb Sutter <b>Opened:</b> 2004-08-01  <b>Last modified:</b> 2007-04-18</p>
6435 <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>
6436 <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>
6437 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
6438 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#580">580</a></p>
6439 <p><b>Discussion:</b></p>
6440 <p>Nothing in the standard appears to make this program ill-formed:</p>
6441
6442 <pre>  struct C {
6443     void* operator new( size_t s ) { return ::operator new( s ); }
6444     // NOTE: this hides in-place and nothrow new
6445   };
6446
6447   int main() {
6448     vector&lt;C&gt; v;
6449     v.push_back( C() );
6450   }
6451 </pre>
6452
6453 <p>Is that intentional?  We should clarify whether or not we intended
6454   to require containers to support types that define their own special
6455   versions of <tt>operator new</tt>.</p>
6456
6457 <p><i>[
6458 Lillehammer: A container will definitely never use this overridden
6459 operator new, but whether it will fail to compile is unclear from the
6460 standard.  Are containers supposed to use qualified or unqualified
6461 placement new?  20.4.1.1 is somewhat relevant, but the standard
6462 doesn't make it completely clear whether containers have to use
6463 Allocator::construct(). If containers don't use it, the details of how
6464 containers use placement new are unspecified. That is the real bug,
6465 but it needs to be fixed as part of the allocator overhaul.  Weak
6466 support that the eventual solution should make this code well formed.
6467 ]</i></p>
6468
6469
6470
6471
6472 <p><b>Proposed resolution:</b></p>
6473
6474
6475
6476
6477
6478
6479
6480 <hr>
6481 <h3><a name="480"></a>480. unary_function and binary_function should have protected nonvirtual destructors</h3>
6482 <p><b>Section:</b> 20.7.3 [base] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
6483  <b>Submitter:</b> Joe Gottman <b>Opened:</b> 2004-08-19  <b>Last modified:</b> 2006-12-29</p>
6484 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#base">issues</a> in [base].</p>
6485 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
6486 <p><b>Discussion:</b></p>
6487 <p>The classes std::unary_function and std::binary_function are both
6488 designed to be inherited from but contain no virtual functions.  This
6489 makes it too easy for a novice programmer to write code like
6490 binary_function&lt;int, int, int&gt; *p = new plus&lt;int&gt;; delete p;</p>
6491
6492 <p>There are two common ways to prevent this source of undefined
6493 behavior: give the base class a public virtual destructor, or give it
6494 a protected nonvirtual destructor.  Since unary_function and
6495 binary_function have no other virtual functions, (note in particular
6496 the absence of an operator()() ), it would cost too much to give them
6497 public virtual destructors.  Therefore, they should be given protected
6498 nonvirtual destructors.</p>
6499
6500
6501 <p><b>Proposed resolution:</b></p>
6502 <p>Change Paragraph 20.3.1 of the Standard from</p>
6503 <pre>    template &lt;class Arg, class Result&gt;
6504     struct unary_function {
6505         typedef Arg argument_type;
6506         typedef Result result_type;
6507     };
6508
6509     template &lt;class Arg1, class Arg2, class Result&gt;
6510     struct binary_function {
6511         typedef Arg1 first_argument_type;
6512         typedef Arg2 second_argument_type;
6513         typedef Result result_type;
6514     };
6515 </pre>
6516
6517 <p>to</p>
6518 <pre>    template &lt;class Arg, class Result&gt;
6519         struct unary_function {
6520         typedef Arg argument_type;
6521         typedef Result result_type;
6522     protected:
6523         ~unary_function() {}
6524     };
6525
6526     template &lt;class Arg1, class Arg2, class Result&gt;
6527     struct binary_function {
6528         typedef Arg1 first_argument_type;
6529         typedef Arg2 second_argument_type;
6530         typedef Result result_type;
6531     protected:
6532         ~binary_function() {}
6533     };
6534 </pre>
6535
6536
6537 <p><b>Rationale:</b></p>
6538 <p>The LWG doesn't believe the existing definition causes anybody any
6539   concrete harm.</p>
6540
6541
6542
6543
6544
6545 <hr>
6546 <h3><a name="481"></a>481. unique's effects on the range [result, last)</h3>
6547 <p><b>Section:</b> 25.4.9 [alg.unique] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
6548  <b>Submitter:</b> Andrew Koenig <b>Opened:</b> 2004-08-30  <b>Last modified:</b> 2006-12-27</p>
6549 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#alg.unique">active issues</a> in [alg.unique].</p>
6550 <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>
6551 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
6552 <p><b>Discussion:</b></p>
6553 <p>
6554 The standard says that unique(first, last) "eliminates all but the
6555 first element from every consecutive group of equal elements" in
6556 [first, last) and returns "the end of the resulting range".  So a
6557 postcondition is that [first, result) is the same as the old [first,
6558 last) except that duplicates have been eliminated.
6559 </p>
6560
6561 <p>What postconditions are there on the range [result, last)?  One
6562   might argue that the standard says nothing about those values, so
6563   they can be anything.  One might also argue that the standard
6564   doesn't permit those values to be changed, so they must not be.
6565   Should the standard say something explicit one way or the other?</p>
6566
6567
6568
6569 <p><b>Proposed resolution:</b></p>
6570 <p>
6571 </p>
6572
6573
6574 <p><b>Rationale:</b></p>
6575 <p>We don't want to make many guarantees about what's in [result,
6576 end). Maybe we aren't being quite explicit enough about not being
6577 explicit, but it's hard to think that's a major problem.</p>
6578
6579
6580
6581
6582
6583 <hr>
6584 <h3><a name="482"></a>482. Swapping pairs</h3>
6585 <p><b>Section:</b> 20.3.3 [pairs], 20.5 [tuple] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
6586  <b>Submitter:</b> Andrew Koenig <b>Opened:</b> 2004-09-14  <b>Last modified:</b> 2007-05-06</p>
6587 <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>
6588 <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>
6589 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
6590 <p><b>Discussion:</b></p>
6591 <p>(Based on recent comp.std.c++ discussion)</p>
6592
6593 <p>Pair (and tuple) should specialize std::swap to work in terms of
6594 std::swap on their components.  For example, there's no obvious reason
6595 why swapping two objects of type pair&lt;vector&lt;int&gt;,
6596 list&lt;double&gt; &gt; should not take O(1).</p>
6597
6598 <p><i>[Lillehammer: We agree it should be swappable.  Howard will
6599   provide wording.]</i></p>
6600
6601
6602 <p><i>[
6603 Post Oxford:  We got <tt>swap</tt> for <tt>pair</tt> but accidently
6604 missed <tt>tuple</tt>.  <tt>tuple::swap</tt> is being tracked by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#522">522</a>.
6605 ]</i></p>
6606
6607
6608
6609
6610 <p><b>Proposed resolution:</b></p>
6611 <p>
6612 Wording provided in
6613 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html#20.2.3%20-%20Pairs">N1856</a>.
6614 </p>
6615
6616 <p><b>Rationale:</b></p>
6617 <p>
6618 Recommend NAD, fixed by
6619 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html#20.2.3%20-%20Pairs">N1856</a>.
6620 </p>
6621
6622
6623
6624
6625
6626 <hr>
6627 <h3><a name="483"></a>483. Heterogeneous equality and EqualityComparable</h3>
6628 <p><b>Section:</b> 25.3 [alg.nonmodifying], 25.4 [alg.modifying.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
6629  <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2004-09-20  <b>Last modified:</b> 2007-01-15</p>
6630 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
6631 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#283">283</a></p>
6632 <p><b>Discussion:</b></p>
6633 <p>c++std-lib-14262</p>
6634
6635 <p>[lib.alg.find] requires T to be EqualityComparable:</p>
6636
6637 <pre>template &lt;class InputIterator, class T&gt;
6638    InputIterator find(InputIterator first, InputIterator last,
6639                       const T&amp; value);
6640 </pre>
6641
6642 <p>
6643 However the condition being tested, as specified in the Effects
6644 clause, is actually *i == value, where i is an InputIterator.
6645 </p>
6646
6647 <p>
6648 The two clauses are in agreement only if the type of *i is T, but this
6649 isn't necessarily the case. *i may have a heterogeneous comparison
6650 operator that takes a T, or a T may be convertible to the type of *i.
6651 </p>
6652
6653 <p>Further discussion (c++std-lib-14264): this problem affects a
6654   number of algorithsm in clause 25, not just <tt>find</tt>.  We
6655   should try to resolve this problem everywhere it appears.</p>
6656
6657
6658 <p><b>Proposed resolution:</b></p>
6659
6660 <p>[lib.alg.find]:</p>
6661 <blockquote><p>
6662    Remove [lib.alg.find]/1.
6663 </p></blockquote>
6664
6665 <p>[lib.alg.count]:</p>
6666 <blockquote><p>
6667    Remove [lib.alg.count]/1.
6668 </p></blockquote>
6669
6670 <p>[lib.alg.search]:</p>
6671 <blockquote><p>
6672    Remove "Type T is EqualityComparable (20.1.1), " from [lib.alg.search]/4.
6673 </p></blockquote>
6674
6675 <p>[lib.alg.replace]:</p>
6676
6677 <blockquote>
6678    <p>
6679    Remove [lib.alg.replace]/1.
6680    Replace [lb.alg.replace]/2 with:
6681    </p>
6682
6683        <blockquote><p>
6684        For every iterator i in the range [first, last) for which *i == value
6685        or pred(*i) holds perform *i = new_value.
6686        </p></blockquote>
6687
6688    <p>
6689    Remove the first sentence of /4.
6690    Replace the beginning of /5 with:
6691    </p>
6692
6693        <blockquote><p>
6694        For every iterator i in the range [result, result + (last -
6695        first)), assign to *i either...
6696        </p></blockquote>
6697
6698    <p>(Note the defect here, current text says assign to i, not *i).</p>
6699 </blockquote>
6700
6701 <p>[lib.alg.fill]:</p>
6702
6703 <blockquote>
6704    <p>
6705    Remove "Type T is Assignable (23.1), " from /1.
6706    Replace /2 with:
6707    </p>
6708
6709        <blockquote><p>
6710        For every iterator i in the range [first, last) or [first, first + n),
6711        perform *i = value.
6712        </p></blockquote>
6713 </blockquote>
6714
6715 <p>[lib.alg.remove]:</p>
6716 <blockquote><p>
6717    Remove /1.
6718    Remove the first sentence of /6.
6719 </p></blockquote>
6720
6721
6722
6723 <p><b>Rationale:</b></p>
6724 <p>Duplicate of (a subset of) issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#283">283</a>.</p>
6725
6726
6727
6728
6729
6730
6731 <hr>
6732 <h3><a name="484"></a>484. Convertible to T</h3>
6733 <p><b>Section:</b> 24.2.2 [input.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
6734  <b>Submitter:</b> Chris Jefferson <b>Opened:</b> 2004-09-16  <b>Last modified:</b> 2008-09-26</p>
6735 <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>
6736 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
6737 <p><b>Discussion:</b></p>
6738 <p>From comp.std.c++:</p>
6739
6740 <p>
6741 I note that given an input iterator a for type T,
6742 then *a only has to be "convertable to T", not actually of type T.
6743 </p>
6744
6745 <p>Firstly, I can't seem to find an exact definition of "convertable to T".
6746 While I assume it is the obvious definition (an implicit conversion), I
6747 can't find an exact definition. Is there one?</p>
6748
6749 <p>Slightly more worryingly, there doesn't seem to be any restriction on
6750 the this type, other than it is "convertable to T". Consider two input
6751 iterators a and b. I would personally assume that most people would
6752 expect *a==*b would perform T(*a)==T(*b), however it doesn't seem that
6753 the standard requires that, and that whatever type *a is (call it U)
6754 could have == defined on it with totally different symantics and still
6755 be a valid inputer iterator.</p>
6756
6757 <p>Is this a correct reading? When using input iterators should I write
6758 T(*a) all over the place to be sure that the object i'm using is the
6759 class I expect?</p>
6760
6761 <p>This is especially a nuisance for operations that are defined to be
6762   "convertible to bool".  (This is probably allowed so that
6763   implementations could return say an int and avoid an unnessary
6764   conversion. However all implementations I have seen simply return a
6765   bool anyway.  Typical implemtations of STL algorithms just write
6766   things like <tt>while(a!=b &amp;&amp; *a!=0)</tt>.  But strictly
6767   speaking, there are lots of types that are convertible to T but
6768   that also overload the appropriate operators so this doesn't behave
6769   as expected.</p>
6770
6771 <p>If we want to make code like this legal (which most people seem to
6772   expect), then we'll need to tighten up what we mean by "convertible
6773   to T".</p>
6774
6775 <p><i>[Lillehammer: The first part is NAD, since "convertible" is
6776  well-defined in core. The second part is basically about pathological
6777  overloads. It's a minor problem but a real one. So leave open for
6778  now, hope we solve it as part of iterator redesign.]</i></p>
6779
6780
6781
6782
6783 <p><b>Proposed resolution:</b></p>
6784
6785
6786 <p><b>Rationale:</b></p>
6787 <p><i>[
6788 San Francisco:
6789 ]</i></p>
6790
6791
6792 <blockquote>
6793 Solved by
6794 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2758.pdf">N2758</a>.
6795 </blockquote>
6796
6797
6798
6799
6800
6801
6802
6803 <hr>
6804 <h3><a name="486"></a>486. min/max CopyConstructible requirement is too strict</h3>
6805 <p><b>Section:</b> 25.5.7 [alg.min.max] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
6806  <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2004-10-13  <b>Last modified:</b> 2006-12-30</p>
6807 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#alg.min.max">active issues</a> in [alg.min.max].</p>
6808 <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>
6809 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
6810 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#281">281</a></p>
6811 <p><b>Discussion:</b></p>
6812 <p>A straightforward implementation of these algorithms does not need to
6813 copy T.</p>
6814
6815
6816 <p><b>Proposed resolution:</b></p>
6817 <p>drop the the words "and CopyConstructible" from paragraphs 1 and 4</p>
6818
6819
6820 <p><b>Rationale:</b></p>
6821
6822
6823
6824
6825
6826
6827 <hr>
6828 <h3><a name="487"></a>487. Allocator::construct is too limiting</h3>
6829 <p><b>Section:</b> X [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
6830  <b>Submitter:</b> Dhruv Matani <b>Opened:</b> 2004-10-17  <b>Last modified:</b> 2006-12-30</p>
6831 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p>
6832 <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>
6833 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
6834 <p><b>Discussion:</b></p>
6835 <p>
6836 The standard's version of allocator::construct(pointer,
6837 const_reference) severely limits what you can construct using this
6838 function.  Say you can construct a socket from a file descriptor. Now,
6839 using this syntax, I first have to manually construct a socket from
6840 the fd, and then pass the constructed socket to the construct()
6841 function so it will just to an uninitialized copy of the socket I
6842 manually constructed. Now it may not always be possible to copy
6843 construct a socket eh! So, I feel that the changes should go in the
6844 allocator::construct(), making it:
6845 </p>
6846 <pre>    template&lt;typename T&gt;
6847     struct allocator{
6848       template&lt;typename T1&gt;
6849       void construct(pointer T1 const&amp; rt1);
6850     };
6851 </pre>
6852
6853 <p>
6854 Now, the ctor of the class T which matches the one that takes a T1 can
6855 be called! Doesn't that sound great?
6856 </p>
6857
6858
6859 <p><b>Proposed resolution:</b></p>
6860
6861
6862 <p><b>Rationale:</b></p>
6863 <p>NAD. STL uses copying all the time, and making it possible for
6864   allocators to construct noncopyable objects is useless in the
6865   absence of corresponding container changes. We might consider this
6866   as part of a larger redesign of STL.</p>
6867
6868
6869
6870
6871
6872 <hr>
6873 <h3><a name="489"></a>489. std::remove / std::remove_if wrongly specified</h3>
6874 <p><b>Section:</b> 25.4.8 [alg.remove] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
6875  <b>Submitter:</b> Thomas Mang <b>Opened:</b> 2004-12-12  <b>Last modified:</b> 2006-12-27</p>
6876 <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>
6877 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
6878 <p><b>Discussion:</b></p>
6879 <p>In Section 25.2.7 [lib.alg.remove], paragraphs 1 to 5 describe the
6880 behavior of the mutating sequence operations std::remove and
6881 std::remove_if. However, the wording does not reflect the intended
6882 behavior [Note: See definition of intended behavior below] of these
6883 algorithms, as it is known to the C++ community [1].
6884 </p>
6885
6886
6887
6888 <p>1) Analysis of current wording:</p>
6889
6890
6891 <p>25.2.7 [lib.alg.remove], paragraph 2:</p>
6892
6893 <p>Current wording says:
6894 "Effects: Eliminates all the elements referred to by iterator i in the
6895 range [first, last) for which the following corresponding conditions
6896 hold: *i == value, pred(*i) != false."</p>
6897
6898 <p>
6899 This sentences expresses specifically that all elements denoted by the
6900 (original) range [first, last) for which the corresponding condition
6901 hold will be eliminated. Since there is no formal definition of the term
6902 "eliminate" provided, the meaning of "eliminate" in everyday language
6903 implies that as postcondition, no element in the range denoted by
6904 [first, last) will hold the corresponding condition on reiteration over
6905 the range [first, last).
6906 </p>
6907
6908 <p>
6909 However, this is neither the intent [Note: See definition of intended
6910 behavior below] nor a general possible approach. It can be easily proven
6911 that if all elements of the original range[first, last) will hold the
6912 condition, it is not possible to substitute them by an element for which
6913 the condition will not hold.
6914 </p>
6915
6916
6917 <p>25.2.7 [lib.alg.remove], paragraph 3:</p>
6918
6919 <p>
6920 Current wording says:
6921 "Returns: The end of the resulting range."
6922 </p>
6923
6924 <p>
6925 The resulting range is not specified. In combination with 25.2.7
6926 [lib.alg.remove], paragraph 2, the only reasonable interpretation of
6927 this so-called resulting range is the range [first,last) - thus
6928 returning always the ForwardIterator 'last' parameter.
6929 </p>
6930
6931
6932 <p>
6933 25.2.7 [lib.alg.remove], paragraph 4:
6934 </p>
6935
6936 <p>
6937 Current wording says:
6938 "Notes: Stable: the relative order of the elements that are not removed
6939 is the same as their relative order in the original range"
6940 </p>
6941
6942 <p>
6943 This sentences makes use of the term "removed", which is neither
6944 specified, nor used in a previous paragraph (which uses the term
6945 "eliminate"), nor unamgiuously separated from the name of the algorithm.
6946 </p>
6947
6948
6949 <p>2) Description of intended behavior:</p>
6950
6951 <p>
6952 For the rest of this Defect Report, it is assumed that the intended
6953 behavior was that all elements of the range [first, last) which do not
6954 hold the condition *i == value (std::remove) or  pred(*i) != false
6955 (std::remove_if)], call them s-elements [Note: s...stay], will be placed
6956 into a contiguous subrange of [first, last), denoted by the iterators
6957 [first, return value). The number of elements in the resulting range
6958 [first, return value) shall be equal to the number of s-elements in the
6959 original range [first, last). The relative order of the elements in the
6960 resulting subrange[first, return value) shall be the same as the
6961 relative order of the corresponding elements in the original range. It
6962 is undefined whether any elements in the resulting subrange [return
6963 value, last) will hold the corresponding condition, or not.
6964 </p>
6965
6966 <p>
6967 All implementations known to the author of this Defect Report comply
6968 with this intent. Since the intent  of the behavior (contrary to the
6969 current wording) is also described in various utility references serving
6970 the C++ community [1], it is not expected that fixing the paragraphs
6971 will influence current code - unless the code relies on the behavior as
6972 it is described by current wording and the implementation indeed
6973 reflects the current wording, and not the intent.
6974 </p>
6975
6976
6977
6978 <p>3) Proposed fixes:</p>
6979
6980
6981 <p>Change 25.2.7 [lib.alg.remove], paragraph 2 to:</p>
6982
6983 <p>
6984 "Effect: Places all the elements referred to by iterator i in the range
6985 [first, last) for which the following corresponding conditions hold :
6986 !(*i == value), pred(*i) == false into the subrange [first, k) of the
6987 original range, where k shall denote a value of type ForwardIterator. It
6988 is undefined whether any elements in the resulting subrange [k, last)
6989 will hold the corresponding condition, or not."
6990 </p>
6991
6992 <p>Comments to the new wording:</p>
6993
6994 <p>
6995 a) "Places" has no special meaning, and the everyday language meaning
6996 should fit.
6997 b) The corresponding conditions were negated compared to the current
6998 wording, becaue the new wording requires it.
6999 c) The wording "of the original range" might be redundant, since any
7000 subrange starting at 'first' and containing no more elements than the
7001 original range is implicitly a subrange of the original range [first,
7002 last).
7003 d) The iterator k was introduced instead of "return value" in order to
7004 avoid a cyclic dependency on 25.2.7/3. The wording ", where k shall
7005 denote a value of type ForwardIterator" might be redundant, because it
7006 follows implicitly by 25.2.7/3.
7007 e) "Places" does, in the author's opinion, explicitly forbid duplicating
7008 any element holding the corresponding condition in the original range
7009 [first, last) within the resulting range [first, k). If there is doubt
7010 this term might be not unambiguous regarding this, it is suggested that
7011 k is specified more closely by the following wording: "k shall denote a
7012 value of type ForwardIterator [Note: see d)] so that k - first is equal
7013 to the number of elements in the original range [first, last) for which
7014 the corresponding condition did hold". This could also be expressed as a
7015 separate paragraph "Postcondition:"
7016 f) The senctence "It is undefined whether any elements in the resulting
7017 subrange [k, last) will hold the corresponding condition, or not." was
7018 added consciously so the term "Places" does not imply if the original
7019 range [first, last) contains n elements holding the corresponding
7020 condition, the identical range[first, last) will also contain exactly n
7021 elements holding the corresponding condition after application of the
7022 algorithm.
7023 </p>
7024
7025 <p>
7026 Change 25.2.7 [lib.alg.remove], paragraph 3 to:
7027
7028 "Returns: The iterator k."
7029 </p>
7030
7031 <p>
7032 Change 25.2.7 [lib.alg.remove], paragraph 4 to:
7033
7034 "Notes: Stable: the relative order of the elements that are placed into
7035 the subrange [first, return value) shall be the same as their relative
7036 order was in the original range [first, last) prior to application of
7037 the algorithm."
7038 </p>
7039
7040 <p>
7041 Comments to the new wording:
7042 </p>
7043
7044 <p>
7045 a) the wording "was ...  prior to application of the algorithm" is used
7046 to explicitly distinguish the original range not only by means of
7047 iterators, but also by a 'chronological' factor from the resulting range
7048 [first, return value). It might be redundant.
7049 </p>
7050
7051 <p>
7052 [1]:
7053 The wording of these references is not always unambiguous, and provided
7054 examples partially contradict verbal description of the algorithms,
7055 because the verbal description resembles the problematic wording of
7056 ISO/IEC 14882:2003.
7057 </p>
7058
7059
7060 <p><b>Proposed resolution:</b></p>
7061
7062
7063 <p><b>Rationale:</b></p>
7064 <p>The LWG believes that the standard is sufficiently clear, and that
7065   there is no evidence of any real-world confusion about this point.</p>
7066
7067
7068
7069
7070
7071 <hr>
7072 <h3><a name="490"></a>490. std::unique wrongly specified</h3>
7073 <p><b>Section:</b> 25.4.9 [alg.unique] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
7074  <b>Submitter:</b> Thomas Mang <b>Opened:</b> 2004-12-12  <b>Last modified:</b> 2006-12-27</p>
7075 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#alg.unique">active issues</a> in [alg.unique].</p>
7076 <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>
7077 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
7078 <p><b>Discussion:</b></p>
7079 <p>In Section 25.2.8 [lib.alg.unique], paragraphs 1 to 3 describe the
7080 behavior of the mutating sequence operation std::unique. However, the
7081 wording does not reflect the intended behavior [Note: See definition of
7082 intended behavior below] of these algorithms, as it is known to the C++
7083 community [1].</p>
7084
7085
7086
7087 <p>1) Analysis of current wording:</p>
7088
7089
7090 <p>25.2.8 [lib.alg.unique], paragraph 1:</p>
7091
7092 <p>
7093 Current wording says:
7094 "Effects: Eliminates all but the first element from every consecutive
7095 group of equal elements referred to by the iterator i in the range
7096 [first, last) for which the following corresponding conditions hold: *i
7097 == *(i - 1) or pred(*i, *(i -1)) != false"
7098 </p>
7099
7100 <p>
7101 This sentences expresses specifically that all elements denoted by the
7102 (original) range [first, last) which are not but the first element from
7103 a consecutive group of equal elements (where equality is defined as *i
7104 == *(i - 1) or pred(*i, *(i - 1)) ! = false) [Note: See DR 202], call
7105 them r-elements [Note: r...remove], will be eliminated. Since there is
7106 no formal definition of the term "eliminate" provided, it is undefined
7107 how this "elimination" takes place. But the meaning of "eliminate" in
7108 everyday language seems to disallow explicitly that after application of
7109 the algorithm, any r-element will remain at any position of the range
7110 [first, last) [2].
7111 </p>
7112
7113 <p>
7114 Another defect in the current wording concerns the iterators used to
7115 compare two elements for equality: The current wording contains the
7116 expression "(i - 1)", which is not covered by 25/9 [Note: See DR
7117 submitted by Thomas Mang regarding invalid iterator arithmetic
7118 expressions].
7119 </p>
7120
7121
7122 <p>
7123 25.2.8 [lib.alg.unique], paragraph 2:
7124 </p>
7125 <p>Current wording says:
7126 "Returns: The end of the resulting range."</p>
7127
7128 <p>
7129 The resulting range is not specified. In combination with 25.2.8
7130 [lib.alg.unique], paragraph 1, one reasonable interpretation (in the
7131 author's opinion even the only possible interpretation) of this
7132 so-called resulting range is the range [first, last) - thus returning
7133 always the ForwardIterator 'last' parameter.
7134 </p>
7135
7136 <p>2) Description of intended behavior:</p>
7137
7138 <p>
7139 For the rest of this Defect Report, it is assumed that the intended
7140 behavior was that all elements denoted by the original range [first,
7141 last) which are the first element from a consecutive group of elements
7142 for which the corresponding conditions: *(i-1) == *i (for the version of
7143 unique without a predicate argument) or pred(*(i-1), *i) ! = false (for
7144 the version of unique with a predicate argument) [Note: If such a group
7145 of elements consists of only a single element, this is also considered
7146 the first element] [Note: See resolutions of DR 202], call them
7147 s-elements [Note: s...stay], will be placed into a contiguous subrange
7148 of [first, last), denoted by the iterators [first, return value). The
7149 number of elements in the resulting range [first, return value) shall be
7150 equal to the number of s-elements in the original range [first, last).
7151 Invalid iterator arithmetic expressions are expected to be resolved as
7152 proposed in DR submitted by Thomas Mang regarding invalid iterator
7153 arithmetic expressions. It is also assumed by the author that the
7154 relative order of the elements in the resulting subrange [first, return
7155 value) shall be the same as the relative order of the corresponding
7156 elements (the s-elements) in the original range [Note: If this was not
7157 intended behavior, the additional proposed paragraph about stable order
7158 will certainly become obsolete].
7159 Furthermore, the resolutions of DR 202 are partially considered.
7160 </p>
7161
7162 <p>
7163 All implementations known to the author of this Defect Report comply
7164 with this intent [Note: Except possible effects of DR 202]. Since this
7165 intent of the behavior (contrary to the current wording) is also
7166 described in various utility references serving the C++ community [1],
7167 it is not expected that fixing the paragraphs will influence current
7168 code [Note: Except possible effects of DR 202] - unless the code relies
7169 on the behavior as it is described by current wording and the
7170 implementation indeed reflects the current wording, and not the intent.
7171 </p>
7172
7173
7174
7175 <p>3) Proposed fixes:</p>
7176
7177 <p>
7178 Change 25.2.8 [lib.alg.unique], paragraph 1 to:
7179 </p>
7180
7181 <p>
7182 "Effect: Places the first element from every consecutive group of
7183 elements, referred to by the iterator i in the range [first, last), for
7184 which the following conditions hold: *(i-1) == *i (for the version of
7185 unique without a predicate argument) or pred(*(i -1), *i) != false (for
7186 the version of unique with a predicate argument), into the subrange
7187 [first, k) of the original range, where k shall denote a value of type
7188 ForwardIterator."
7189 </p>
7190
7191 <p>Comments to the new wording:</p>
7192
7193 <p>
7194 a) The new wording was influenced by the resolutions of DR 202. If DR
7195 202 is resolved in another way, the proposed wording need also
7196 additional review.
7197 b) "Places" has no special meaning, and the everyday language meaning
7198 should fit.
7199 c) The expression "(i - 1)" was left, but is expected that DR submitted
7200 by Thomas Mang regarding invalid iterator arithmetic expressions will
7201 take this into account.
7202 d) The wording "(for the version of unique without a predicate
7203 argument)" and "(for the version of unique with a predicate argument)"
7204 was added consciously for clarity and is in resemblence with current
7205 23.2.2.4 [lib.list.ops], paragraph 19. It might be considered redundant.
7206 e) The wording "of the original range" might be redundant, since any
7207 subrange starting at first and containing no more elements than the
7208 original range is implicitly a subrange of the original range [first,
7209 last).
7210 f) The iterator k was introduced instead of "return value" in order to
7211 avoid a cyclic dependency on 25.2.8 [lib.alg.unique], paragraph 2. The
7212 wording ", where k shall denote a value of type ForwardIterator" might
7213 be redundant, because it follows implicitly by 25.2.8 [lib.alg.unique],
7214 paragraph 2.
7215 g) "Places" does, in the author's opinion, explicitly forbid duplicating
7216 any s-element in the original range [first, last) within the resulting
7217 range [first, k). If there is doubt this term might be not unambiguous
7218 regarding this, it is suggested that k is specified more closely by the
7219 following wording: "k shall denote a value of type ForwardIterator
7220 [Note: See f)] so that k - first is equal to the number of elements in
7221 the original range [first, last) being the first element from every
7222 consecutive group of elements for which the corresponding condition did
7223 hold". This could also be expressed as a separate paragraph
7224 "Postcondition:".
7225 h) If it is considered that the wording is unclear whether it declares
7226 the element of a group which consists of only a single element
7227 implicitly to be the first element of this group [Note: Such an
7228 interpretation could eventually arise especially in case last - first ==
7229 1] , the following additional sentence is proposed: "If such a group of
7230 elements consists of only a single element, this element is also
7231 considered the first element."
7232 </p>
7233
7234 <p>
7235 Change 25.2.8 [lib.alg.unique], paragraph 2 to:
7236 "Returns: The iterator k."
7237 </p>
7238
7239 <p>
7240 Add a separate paragraph "Notes:" as 25.2.8 [lib.alg.unique], paragraph
7241 2a or 3a, or a separate paragraph "Postcondition:" before 25.2.8
7242 [lib.alg.unique], paragraph 2 (wording inside {} shall be eliminated if
7243 the preceding expressions are used, or the preceding expressions shall
7244 be eliminated if wording inside {} is used):
7245 </p>
7246
7247 <p>
7248 "Notes:{Postcondition:} Stable: the relative order of the elements that
7249 are placed into the subrange [first, return value {k}) shall be the same
7250 as their relative order was in the original range [first, last) prior to
7251 application of the algorithm."
7252 </p>
7253
7254 <p>Comments to the new wording:</p>
7255
7256 <p>
7257 a) It is assumed by the author that the algorithm was intended to be
7258 stable.
7259 In case this was not the intent, this paragraph becomes certainly
7260 obsolete.
7261 b) The wording "was ...  prior to application of the algorithm" is used
7262 to explicitly distinguish the original range not only by means of
7263 iterators, but also by a 'chronological' factor from the resulting range
7264 [first, return value). It might be redundant.
7265 </p>
7266
7267 <p>
7268 25.2.8 [lib.alg.unique], paragraph 3:
7269 </p>
7270 <p>See DR 239.</p>
7271
7272 <p>
7273 4) References to other DRs:
7274 </p>
7275
7276 <p>
7277 See DR 202, but which does not address any of the problems described in
7278 this Defect Report [Note: This DR is supposed to complement DR 202].
7279 See DR 239.
7280 See DR submitted by Thomas Mang regarding invalid iterator arithmetic
7281 expressions.
7282 </p>
7283
7284 <p>
7285 [1]:
7286 The wording of these references is not always unambiguous, and provided
7287 examples partially contradict verbal description of the algorithms,
7288 because the verbal description resembles the problematic wording of
7289 ISO/IEC 14882:2003.
7290 </p>
7291
7292 <p>
7293 [2]:
7294 Illustration of conforming implementations according to current wording:
7295 </p>
7296
7297 <p>
7298 One way the author of this DR considers how this "elimination" could be
7299 achieved by a conforming implementation according to current wording is
7300 by substituting each r-element by _any_ s-element [Note: s...stay; any
7301 non-r-element], since all r-elements are "eliminated".
7302 </p>
7303
7304 <p>
7305 In case of a sequence consisting of elements being all 'equal' [Note:
7306 See DR 202], substituting each r-element by the single s-element is the
7307 only possible solution according to current wording.
7308 </p>
7309
7310
7311 <p><b>Proposed resolution:</b></p>
7312
7313
7314 <p><b>Rationale:</b></p>
7315 <p>The LWG believes the standard is sufficiently clear. No
7316 implementers get it wrong, and changing it wouldn't cause any code to
7317 change, so there is no real-world harm here.</p>
7318
7319
7320
7321
7322
7323 <hr>
7324 <h3><a name="491"></a>491. std::list&lt;&gt;::unique incorrectly specified</h3>
7325 <p><b>Section:</b> 23.3.4.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
7326  <b>Submitter:</b> Thomas Mang <b>Opened:</b> 2004-12-12  <b>Last modified:</b> 2007-02-19</p>
7327 <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>
7328 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
7329 <p><b>Discussion:</b></p>
7330 <p>In Section 23.3.4.4 [list.ops], paragraphs 19 to 21 describe the
7331 behavior of the std::list&lt;T, Allocator&gt;::unique operation. However, the
7332 current wording is defective for various reasons.</p>
7333
7334
7335
7336 <p>
7337 1) Analysis of current wording:
7338 </p>
7339
7340 <p>23.3.4.4 [list.ops], paragraph 19:</p>
7341
7342 <p>
7343 Current wording says:
7344 "Effects:  Eliminates all but the first element from every consecutive
7345 group of equal elements referred to by the iterator i in the range
7346 [first + 1, last) for which *i == *(i - 1) (for the version of unique
7347 with no argument) or pred(*i, *(i -1)) (for the version of unique with a
7348 predicate argument) holds."</p>
7349
7350 <p>
7351 This sentences makes use of the undefined term "Eliminates". Although it
7352 is, to a certain degree, reasonable to consider the term "eliminate"
7353 synonymous with "erase", using "Erase" in the first place, as the
7354 wording of 23.3.4.4 [list.ops], paragraph 15 does, would be clearer.</p>
7355
7356 <p>
7357 The range of the elements referred to by iterator i is "[first + 1,
7358 last)". However, neither "first" nor "last" is defined.</p>
7359
7360 <p>
7361 The sentence makes three times use of iterator arithmetic expressions (
7362 "first + 1", "*i == *(i - 1)", "pred(*i, *(i -1))" ) which is not
7363 defined for bidirectional iterator [see DR submitted by Thomas Mang
7364 regarding invalid iterator arithmetic expressions].</p>
7365
7366 <p>
7367 The same problems as pointed out in DR 202 (equivalence relation / order
7368 of arguments for pred()) apply to this paragraph.</p>
7369
7370 <p>
7371 23.3.4.4 [list.ops], paragraph 20:
7372 </p>
7373
7374 <p>
7375 Current wording says:
7376 "Throws: Nothing unless an exception in thrown by *i == *(i-1) or
7377 pred(*i, *(i - 1))"</p>
7378
7379 <p>
7380 The sentence makes two times use of invalid iterator arithmetic
7381 expressions ( "*i == *(i - 1)", "pred(*i, *(i -1))" ).
7382 </p>
7383 <p>
7384 [Note: Minor typos: "in" / missing dot at end of sentence.]
7385 </p>
7386
7387 <p>
7388 23.3.4.4 [list.ops], paragraph 21:</p>
7389
7390 <p>
7391 Current wording says:
7392 "Complexity: If the range (last - first) is not empty, exactly (last -
7393 first) - 1 applications of the corresponding predicate, otherwise no
7394 application of the predicate.</p>
7395
7396 <p>
7397 See DR 315 regarding "(last - first)" not yielding a range.</p>
7398
7399 <p>
7400 Invalid iterator arithmetic expression "(last - first) - 1" left .</p>
7401
7402
7403 <p>2) Description of intended behavior:</p>
7404
7405 <p>
7406 For the rest of this Defect Report, it is assumed that "eliminate" is
7407 supposed to be synonymous to "erase", that "first" is equivalent to an
7408 iterator obtained by a call to begin(), "last" is equivalent to an
7409 iterator obtained by a call to end(), and that all invalid iterator
7410 arithmetic expressions are resolved as described in DR submitted by
7411 Thomas Mang regarding invalid iterator arithmetic expressions.</p>
7412
7413 <p>
7414 Furthermore, the resolutions of DR 202 are considered regarding
7415 equivalence relation and order of arguments for a call to pred.</p>
7416
7417 <p>
7418 All implementations known to the author of this Defect Report comply
7419 with these assumptions, apart from the impact of the alternative
7420 resolution of DR 202. Except for the changes implied by the resolutions
7421 of DR 202, no impact on current code is expected.</p>
7422
7423 <p>
7424 3) Proposed fixes:</p>
7425
7426 <p>
7427 Change 23.3.4.4 [list.ops], paragraph 19 to:</p>
7428
7429 <p>
7430 "Effect: Erases all but the first element from every consecutive group
7431 of elements, referred to by the iterator i in the range [begin(),
7432 end()), for which the following conditions hold: *(i-1) == *i (for the
7433 version of unique with no argument) or pred(*(i-1), *i) != false (for
7434 the version of unique with a predicate argument)."</p>
7435
7436 <p>
7437 Comments to the new wording:</p>
7438
7439 <p>
7440 a) The new wording was influenced by DR 202 and the resolutions
7441 presented there. If DR 202 is resolved in another way, the proposed
7442 wording need also additional review.
7443 b) "Erases" refers in the author's opinion unambiguously to the member
7444 function "erase". In case there is doubt this might not be unamgibuous,
7445 a direct reference to the member function "erase" is suggested [Note:
7446 This would also imply a change of 23.3.4.4 [list.ops], paragraph
7447 15.].
7448 c) The expression "(i - 1)" was left, but is expected that DR submitted
7449 by Thomas Mang regarding invalid iterator arithmetic expressions will
7450 take this into account.
7451 d) The wording "(for the version of unique with no argument)" and "(for
7452 the version of unique with a predicate argument)" was kept consciously
7453 for clarity.
7454 e) "begin()" substitutes "first", and "end()" substitutes "last". The
7455 range need adjustment from "[first + 1, last)" to "[begin(), end())" to
7456 ensure a valid range in case of an empty list.
7457 f) If it is considered that the wording is unclear whether it declares
7458 the element of a group which consists of only a single element
7459 implicitly to be the first element of this group [Note: Such an
7460 interpretation could eventually arise especially in case size() == 1] ,
7461 the following additional sentence is proposed: "If such a group of
7462 elements consists of only a single element, this element is also
7463 considered the first element."</p>
7464
7465 <p>
7466 Change 23.3.4.4 [list.ops], paragraph 20 to:</p>
7467
7468 <p>
7469 "Throws: Nothing unless an exception is thrown by *(i-1) == *i or
7470 pred(*(i-1), *i)."</p>
7471
7472 <p>
7473 Comments to the new wording:</p>
7474
7475 <p>
7476 a) The wording regarding the conditions is identical to proposed
7477 23.3.4.4 [list.ops], paragraph 19. If 23.3.4.4 [list.ops],
7478 paragraph 19 is resolved in another way, the proposed wording need also
7479 additional review.
7480 b) The expression "(i - 1)" was left, but is expected that DR submitted
7481 by Thomas Mang regarding invalid iterator arithmetic expressions will
7482 take this into account.
7483 c) Typos fixed.</p>
7484
7485 <p>
7486 Change 23.3.4.4 [list.ops], paragraph 21 to:</p>
7487
7488 <p>
7489 "Complexity: If empty() == false, exactly size() - 1 applications of the
7490 corresponding predicate, otherwise no applications of the corresponding
7491 predicate."</p>
7492
7493 <p>
7494 Comments to the new wording:</p>
7495
7496 <p>
7497 a) The new wording is supposed to also replace the proposed resolution
7498 of DR 315, which suffers from the problem of undefined "first" / "last".
7499 </p>
7500
7501 <p>
7502 5) References to other DRs:</p>
7503
7504 <p>See DR 202.
7505 See DR 239.
7506 See DR 315.
7507 See DR submitted by Thomas Mang regarding invalid iterator arithmetic
7508 expressions.</p>
7509
7510
7511
7512 <p><b>Proposed resolution:</b></p>
7513
7514
7515 <p><b>Rationale:</b></p>
7516 <p>"All implementations known to the author of this Defect Report
7517 comply with these assumption", and "no impact on current code is
7518 expected", i.e. there is no evidence of real-world confusion or
7519 harm.</p>
7520
7521
7522
7523
7524
7525 <hr>
7526 <h3><a name="493"></a>493. Undefined Expression in Input Iterator Note Title</h3>
7527 <p><b>Section:</b> 24.2.2 [input.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
7528  <b>Submitter:</b> Chris Jefferson <b>Opened:</b> 2004-12-13  <b>Last modified:</b> 2006-12-27</p>
7529 <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>
7530 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
7531 <p><b>Discussion:</b></p>
7532 <p>1) In 24.1.1/3, the following text is currently present.</p>
7533
7534 <p>"Note: For input iterators, a==b does not imply ++a=++b (Equality does
7535 not guarantee the substitution property or referential transparency)."</p>
7536
7537 <p>However, when in Table 72, part of the definition of ++r is given as:</p>
7538
7539 <p>"pre: r is dereferenceable.
7540 post: any copies of the previous value of r are no longer required
7541 either to be dereferenceable ..."</p>
7542
7543 <p>While a==b does not imply that b is a copy of a, this statement should
7544 perhaps still be made more clear.</p>
7545
7546 <p>2) There are no changes to intended behaviour</p>
7547
7548 <p>
7549 3) This Note should be altered to say "Note: For input iterators a==b,
7550 when its behaviour is defined ++a==++b may still be false (Equality does
7551 not guarantee the substitution property or referential transparency).</p>
7552
7553
7554
7555 <p><b>Proposed resolution:</b></p>
7556
7557
7558 <p><b>Rationale:</b></p>
7559 <p>This is descriptive text, not normative, and the meaning is clear.</p>
7560
7561
7562
7563
7564
7565 <hr>
7566 <h3><a name="494"></a>494. Wrong runtime complexity for associative container's insert and delete</h3>
7567 <p><b>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
7568  <b>Submitter:</b> Hans B os <b>Opened:</b> 2004-12-19  <b>Last modified:</b> 2006-12-27</p>
7569 <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>
7570 <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>
7571 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
7572 <p><b>Discussion:</b></p>
7573 <p>According to [lib.associative.reqmts] table 69, the runtime comlexity
7574 of insert(p, t) and erase(q) can be done in amortized constant time.</p>
7575
7576 <p>It was my understanding that an associative container could be
7577 implemented as a balanced binary tree.</p>
7578
7579 <p>For inser(p, t), you 'll have to iterate to p's next node to see if t
7580 can be placed next to p.  Furthermore, the insertion usually takes
7581 place at leaf nodes. An insert next to the root node will be done at
7582 the left of the root next node</p>
7583
7584 <p>So when p is the root node you 'll have to iterate from the root to
7585 its next node, which  takes O(log(size)) time in a balanced tree.</p>
7586
7587 <p>If you insert all values with insert(root, t) (where root is the
7588 root of the tree before insertion) then each insert takes O(log(size))
7589 time.  The amortized complexity per insertion will be O(log(size))
7590 also.</p>
7591
7592 <p>For erase(q), the normal algorithm for deleting a node that has no
7593 empty left or right subtree, is to iterate to the next (or previous),
7594 which is a leaf node. Then exchange the node with the next and delete
7595 the leaf node.  Furthermore according to DR 130, erase should return
7596 the next node of the node erased.  Thus erasing the root node,
7597 requires iterating to the next node.</p>
7598
7599 <p>Now if you empty a map by deleting the root node until the map is
7600 empty, each operation will take O(log(size)), and the amortized
7601 complexity is still O(log(size)).</p>
7602
7603 <p>The operations can be done in amortized constant time if iterating
7604 to the next node can be done in (non amortized) constant time.  This
7605 can be done by putting all nodes in a double linked list.  This
7606 requires two extra links per node.  To me this is a bit overkill since
7607 you can already efficiently insert or erase ranges with erase(first,
7608 last) and insert(first, last).</p>
7609
7610
7611
7612 <p><b>Proposed resolution:</b></p>
7613
7614
7615 <p><b>Rationale:</b></p>
7616 <p>Only "amortized constant" in special circumstances, and we believe
7617   that's implementable. That is: doing this N times will be O(N), not
7618   O(log N).</p>
7619
7620
7621
7622
7623
7624 <hr>
7625 <h3><a name="499"></a>499. Std. doesn't seem to require stable_sort() to be stable!</h3>
7626 <p><b>Section:</b> 25.5.1.2 [stable.sort] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
7627  <b>Submitter:</b> Prateek Karandikar <b>Opened:</b> 2005-04-12  <b>Last modified:</b> 2008-03-13</p>
7628 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
7629 <p><b>Discussion:</b></p>
7630 <blockquote><p>
7631 17.3.1.1 Summary</p>
7632
7633 <p>
7634 1 The Summary provides a synopsis of the category, and introduces the
7635 first-level subclauses. Each subclause also provides a summary, listing
7636 the headers specified in the subclause and the library entities
7637 provided in each header.
7638 </p>
7639 <p>
7640 2 Paragraphs labelled "Note(s):" or "Example(s):" are informative,
7641 other paragraphs are normative.
7642 </p></blockquote>
7643
7644 <p>So this means that a "Notes" paragraph wouldn't be normative. </p>
7645
7646 <blockquote><p>
7647 25.3.1.2 stable_sort
7648 </p>
7649 <pre>template&lt;class RandomAccessIterator&gt;
7650 void stable_sort(RandomAccessIterat or first, RandomAccessIterator last);
7651
7652 template&lt;class RandomAccessIterator, class Compare&gt;
7653 void stable_sort(RandomAccessIterat or first, RandomAccessIterator last, Compare comp);
7654 </pre>
7655 <p>
7656 1 Effects: Sorts the elements in the range [first, last).
7657 </p>
7658 <p>
7659 2 Complexity: It does at most N(log N)^2 (where N == last - first)
7660 comparisons; if enough extra memory is available, it is N log N.
7661 </p>
7662 <p>
7663 3 Notes: Stable: the relative order of the equivalent elements is
7664 preserved.
7665 </p></blockquote>
7666
7667 <p>
7668 The Notes para is informative, and nowhere else is stability mentioned above.
7669 </p>
7670
7671 <p>
7672 Also, I just searched for the word "stable" in my copy of the Standard.
7673 and the phrase "Notes: Stable: the relative order of the elements..."
7674 is repeated several times in the Standard library clauses for
7675 describing various functions. How is it that stability is talked about
7676 in the informative paragraph? Or am I missing something obvious?
7677 </p>
7678
7679
7680 <p><b>Proposed resolution:</b></p>
7681 <p>
7682 </p>
7683
7684
7685 <p><b>Rationale:</b></p>
7686 <p>
7687 This change has already been made.
7688 </p>
7689
7690
7691
7692
7693
7694 <hr>
7695 <h3><a name="500"></a>500. do_length cannot be implemented correctly</h3>
7696 <p><b>Section:</b> 22.4.1.5 [locale.codecvt.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
7697  <b>Submitter:</b> Krzysztof &#379;elechowski <b>Opened:</b> 2005-05-24  <b>Last modified:</b> 2008-03-13</p>
7698 <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>
7699 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
7700 <p><b>Discussion:</b></p>
7701 <ol>
7702 <li>codecvt::do_length is of type int;</li>
7703 <li>it is assumed to be sort-of returning from_next - from of type ptrdiff_t;</li>
7704 <li>ptrdiff_t cannot be cast to an int without data loss.</li>
7705 </ol>
7706 <p>
7707 Contradiction.
7708 </p>
7709
7710
7711 <p><b>Proposed resolution:</b></p>
7712 <p>
7713 </p>
7714
7715
7716
7717
7718
7719 <hr>
7720 <h3><a name="501"></a>501. Proposal: strengthen guarantees of lib.comparisons</h3>
7721 <p><b>Section:</b> 20.7.3 [base] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
7722  <b>Submitter:</b> Me &lt;anti_spam_email2003@yahoo.com&gt; <b>Opened:</b> 2005-06-07  <b>Last modified:</b> 2008-03-13</p>
7723 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#base">issues</a> in [base].</p>
7724 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
7725 <p><b>Discussion:</b></p>
7726 <blockquote><p>
7727 "For templates greater, less, greater_equal, and less_equal,
7728 the specializations for any pointer type yield a total order, even if
7729 the built-in operators &lt;, &gt;, &lt;=, &gt;= do not."
7730 </p></blockquote>
7731
7732 <p>
7733 The standard should do much better than guarantee that these provide a
7734 total order, it should guarantee that it can be used to test if memory
7735 overlaps, i.e. write a portable memmove. You can imagine a platform
7736 where the built-in operators use a uint32_t comparison (this tests for
7737 overlap on this platform) but the less&lt;T*&gt; functor is allowed to be
7738 defined to use a int32_t comparison. On this platform, if you use
7739 std::less with the intent of making a portable memmove, comparison on
7740 an array that straddles the 0x7FFFFFFF/0x8000000 boundary can give
7741 incorrect results.
7742 </p>
7743
7744
7745 <p><b>Proposed resolution:</b></p>
7746 <p>
7747 Add a footnote to 20.5.3/8 saying:
7748 </p>
7749
7750 <blockquote><p>
7751 Given a p1 and p2 such that p1 points to N objects of type T and p2
7752 points to M objects of type T. If [p1,p1+N) does not overlap [p2,p2+M),
7753 less returns the same value when comparing all pointers in [p1,p1+N) to
7754 all pointers in [p2,p2+M). Otherwise, there is a value Q and a value R
7755 such that less returns the same value when comparing all pointers in
7756 [p1,p1+Q) to all pointers in [p2,p2+R) and an opposite value when
7757 comparing all pointers in [p1+Q,p1+N) to all pointers in [p2+R,p2+M).
7758 For the sake of completeness, the null pointer value (4.10) for T is
7759 considered to be an array of 1 object that doesn't overlap with any
7760 non-null pointer to T. less_equal, greater, greater_equal, equal_to,
7761 and not_equal_to give the expected results based on the total ordering
7762 semantics of less. For T of void, treat it as having similar semantics
7763 as T of char i.e. less&lt;cv T*&gt;(a, b) gives the same results as less&lt;cv
7764 void*&gt;(a, b) which gives the same results as less&lt;cv char*&gt;((cv
7765 char*)(cv void*)a, (cv char*)(cv void*)b).
7766 </p></blockquote>
7767
7768 <p>
7769 I'm also thinking there should be a footnote to 20.5.3/1 saying that if
7770 A and B are similar types (4.4/4), comp&lt;A&gt;(a,b) returns the same value
7771 as comp&lt;B&gt;(a,b) (where comp is less, less_equal, etc.). But this might
7772 be problematic if there is some really funky operator overloading going
7773 on that does different things based on cv (that should be undefined
7774 behavior if somebody does that though). This at least should be
7775 guaranteed for all POD types (especially pointers) that use the
7776 built-in comparison operators.
7777 </p>
7778
7779
7780
7781 <p><b>Rationale:</b></p>
7782 <p>
7783 less is already required to provide a strict weak ordering which is good enough
7784 to detect overlapping memory situations.
7785 </p>
7786
7787
7788
7789
7790
7791 <hr>
7792 <h3><a name="504"></a>504. Integer types in pseudo-random number engine requirements</h3>
7793 <p><b>Section:</b> X [rand.req], TR1 5.1.1 [tr.rand.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
7794  <b>Submitter:</b> Walter Brown <b>Opened:</b> 2005-07-03  <b>Last modified:</b> 2008-03-13</p>
7795 <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>
7796 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
7797 <p><b>Discussion:</b></p>
7798 <p>
7799 In [tr.rand.req], Paragraph 2 states that "... s is a value of integral type,
7800 g is an ... object returning values of unsigned integral type ..."
7801 </p>
7802
7803
7804 <p><b>Proposed resolution:</b></p>
7805 <p>
7806 In 5.1.1 [tr.rand.req], Paragraph 2 replace
7807 </p>
7808
7809 <blockquote><p>
7810 ... s is a value of integral type, g is an lvalue of a type other than X that
7811 defines a zero-argument function object returning values of <del>unsigned integral</del> type
7812 <ins><tt>unsigned long int</tt></ins>,
7813 ...
7814 </p></blockquote>
7815
7816 <p>
7817 In 5.1.1 [tr.rand.seq], Table 16, replace in the line for X(s)
7818 </p>
7819
7820 <blockquote><p>
7821 creates an engine with the initial internal state
7822 determined by <ins><tt>static_cast&lt;unsigned long&gt;(</tt></ins><tt><i>s</i></tt><ins><tt>)</tt></ins>
7823 </p></blockquote>
7824
7825 <p><i>[
7826 Mont Tremblant:  Both s and g should be unsigned long.
7827 This should refer to the constructor signatures. Jens  provided wording post Mont Tremblant.
7828 ]</i></p>
7829
7830
7831 <p><i>[
7832 Berlin:  N1932 adopts the proposed resolution:  see 26.3.1.3/1e and Table 3 row 2. Moved
7833 to Ready.
7834 ]</i></p>
7835
7836
7837
7838
7839 <p><b>Rationale:</b></p>
7840 <p>
7841 Jens:  Just requiring X(unsigned long) still makes it possible
7842 for an evil library writer to also supply a X(int) that does something
7843 unexpected.  The wording above requires that X(s) always performs
7844 as if X(unsigned long) would have been called.  I believe that is
7845 sufficient and implements our intentions from Mont Tremblant.  I
7846 see no additional use in actually requiring a X(unsigned long)
7847 signature.  u.seed(s) is covered by its reference to X(s), same
7848 arguments.
7849 </p>
7850
7851
7852 <p><i>[
7853 Portland:  Subsumed by N2111.
7854 ]</i></p>
7855
7856
7857
7858
7859
7860 <hr>
7861 <h3><a name="506"></a>506. Requirements of Distribution parameter for variate_generator</h3>
7862 <p><b>Section:</b> 26.5 [rand], TR1 5.1.3 [tr.rand.var] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
7863  <b>Submitter:</b> Walter Brown <b>Opened:</b> 2005-07-03  <b>Last modified:</b> 2008-03-13</p>
7864 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand">active issues</a> in [rand].</p>
7865 <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>
7866 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
7867 <p><b>Discussion:</b></p>
7868 <p>
7869 Paragraph 3 requires that template argument U (which corresponds to template
7870 parameter Engine) satisfy all uniform random number generator requirements.
7871 However, there is no  analogous requirement regarding the template argument
7872 that corresponds to template parameter Distribution.  We believe there should
7873 be, and that it should require that this template argument satisfy all random
7874 distribution requirements.
7875 </p>
7876
7877
7878 <p><b>Proposed resolution:</b></p>
7879 <p>
7880 Consequence 1: Remove the precondition clauses [tr.rand.var]/16 and /18.
7881 </p>
7882 <p>
7883 Consequence 2: Add max() and min() functions to those distributions that
7884 do not already have them.
7885 </p>
7886
7887 <p><i>[
7888 Mont Tremblant: Jens reccommends NAD, min/max not needed everywhere.
7889 Marc supports having min and max to satisfy generic programming interface.
7890 ]</i></p>
7891
7892
7893
7894
7895 <p><b>Rationale:</b></p>
7896 <p>Berlin:  N1932 makes this moot: variate_generator has been eliminated.</p>
7897
7898
7899
7900
7901
7902 <hr>
7903 <h3><a name="509"></a>509. Uniform_int template parameters</h3>
7904 <p><b>Section:</b> 26.5.8.1 [rand.dist.uni], TR1 5.1.7.1 [tr.rand.dist.iunif] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
7905  <b>Submitter:</b> Walter Brown <b>Opened:</b> 2005-07-03  <b>Last modified:</b> 2008-03-13</p>
7906 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.uni">issues</a> in [rand.dist.uni].</p>
7907 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
7908 <p><b>Discussion:</b></p>
7909 <p>
7910 In [tr.rand.dist.iunif] the uniform_int distribution currently has a single
7911 template parameter, IntType, used as the input_type and as the result_type
7912 of the distribution.  We believe there is no reason to conflate these types
7913 in this way.
7914 </p>
7915
7916
7917 <p><b>Proposed resolution:</b></p>
7918 <p>
7919 We recommend that there be a second template  parameter to
7920 reflect the distribution's input_type, and that the existing first template
7921 parameter continue to reflect (solely) the result_type:
7922 </p>
7923 <blockquote><pre>template&lt; class IntType = int, UIntType = unsigned int &gt;
7924 class uniform_int
7925 {
7926 public:
7927   // types
7928   typedef  UIntType  input_type;
7929   typedef  IntType   result_type;
7930 </pre></blockquote>
7931
7932 <p><i>[
7933 Berlin: Moved to NAD.  N1932 makes this moot: the input_type template parameter has been
7934 eliminated.
7935 ]</i></p>
7936
7937
7938
7939
7940
7941
7942
7943 <hr>
7944 <h3><a name="510"></a>510. Input_type for bernoulli_distribution</h3>
7945 <p><b>Section:</b> 26.5.8.2 [rand.dist.bern], TR1 5.1.7.2 [tr.rand.dist.bern] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
7946  <b>Submitter:</b> Walter Brown <b>Opened:</b> 2005-07-03  <b>Last modified:</b> 2008-03-13</p>
7947 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
7948 <p><b>Discussion:</b></p>
7949 <p>
7950 In [tr.rand.dist.bern] the distribution currently requires;
7951 </p>
7952 <blockquote><pre>typedef  int  input_type;
7953 </pre></blockquote>
7954
7955
7956 <p><b>Proposed resolution:</b></p>
7957 <p>
7958 We believe this is an unfortunate choice, and recommend instead:
7959 </p>
7960 <blockquote><pre>typedef  unsigned int  input_type;
7961 </pre></blockquote>
7962
7963 <p><i>[
7964 Berlin:  Moved to NAD. N1932 makes this moot: the input_type template parameter has been
7965 eliminated.
7966 ]</i></p>
7967
7968
7969
7970
7971
7972
7973
7974 <hr>
7975 <h3><a name="511"></a>511. Input_type for binomial_distribution</h3>
7976 <p><b>Section:</b> 26.5.8 [rand.dist], TR1 5.1.7.5 [tr.rand.dist.bin] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
7977  <b>Submitter:</b> Walter Brown <b>Opened:</b> 2005-07-03  <b>Last modified:</b> 2008-03-13</p>
7978 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist">issues</a> in [rand.dist].</p>
7979 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
7980 <p><b>Discussion:</b></p>
7981 <p>
7982 Unlike all other distributions in TR1, this binomial_distribution has an
7983 implementation-defined  input_type.  We believe this is an unfortunate choice,
7984 because it hinders users from writing portable code.  It also hinders the
7985 writing of compliance tests.  We recommend instead:
7986 </p>
7987 <blockquote><pre>typedef  RealType  input_type;
7988 </pre></blockquote>
7989 <p>
7990 While this choice is somewhat arbitrary (as it was for some of the other
7991 distributions), we make  this particular choice because (unlike all other
7992 distributions) otherwise this template would not publish its RealType
7993 argument and so users could not write generic code that accessed this
7994 second template parameter.  In this respect, the choice is consistent with
7995 the other distributions in  TR1.
7996 </p>
7997 <p>
7998 We have two reasons for recommending that a real type be specified instead.
7999 One reason is  based specifically on characteristics of binomial distribution
8000 implementations, while the other is based on mathematical characteristics of
8001 probability distribution functions in general.
8002 </p>
8003 <p>
8004 Implementations of binomial distributions commonly use Stirling approximations
8005 for values in certain ranges.  It is far more natural to use real values to
8006 represent these approximations than it would be to use integral values to do
8007 so.  In other ranges, implementations reply on the Bernoulli  distribution to
8008 obtain values.  While TR1's bernoulli_distribution::input_type is specified as
8009 int, we believe this would be better specified as double.
8010 </p>
8011 <p>
8012 This brings us to our main point:  The notion of a random distribution rests
8013 on the notion of a cumulative distribution function, which in turn mathematically
8014 depends on a continuous dependent variable.  Indeed, such a distribution function
8015 would be meaningless if it depended on  discrete values such as integers - and this
8016 remains true even if the distribution function were to take discrete steps.
8017 </p>
8018 <p>
8019 Although this note is specifically about binomial_distribution::input_type,
8020 we intend to recommend that all of the random distributions input_types be
8021 specified as a real type (either a RealType template parameter, or double,
8022 as appropriate).
8023 </p>
8024 <p>
8025 Of the nine distributions in TR1, four already have this characteristic
8026 (uniform_real, exponential_distribution, normal_distribution, and
8027 gamma_distribution).  We have already argued the case for the binomial the
8028 remaining four distributions.
8029 </p>
8030 <p>
8031 In the case of uniform_int, we believe that the calculations to produce an
8032 integer result in a  specified range from an integer in a different specified
8033 range is best done using real arithmetic.  This is because it involves a
8034 product, one of whose terms is the ratio of the extents of the two ranges.
8035 Without real arithmetic, the results become less uniform: some numbers become
8036 more  (or less) probable that they should be.  This is, of course, undesireable
8037 behavior in a uniform distribution.
8038 </p>
8039 <p>
8040 Finally, we believe that in the case of the bernoulli_distribution (briefly
8041 mentioned earlier), as well as the cases of the geometric_distribution and the
8042 poisson_distribution, it would be far more natural to have a real input_type.
8043 This is because the most natural computation involves the  random number
8044 delivered and the distribution's parameter p (in the case of bernoulli_distribution,
8045 for example, the computation is a comparison against p), and p is already specified
8046 in each case as having some real type.
8047 </p>
8048
8049
8050 <p><b>Proposed resolution:</b></p>
8051 <blockquote><pre>typedef  RealType  input_type;
8052 </pre></blockquote>
8053
8054 <p><i>[
8055 Berlin:  Moved to NAD.  N1932 makes this moot: the input_type template parameter has been
8056 eliminated.
8057 ]</i></p>
8058
8059
8060
8061
8062
8063
8064 <hr>
8065 <h3><a name="512"></a>512. Seeding subtract_with_carry_01 from a single unsigned long</h3>
8066 <p><b>Section:</b> 26.5.3 [rand.eng], TR1 5.1.4.4 [tr.rand.eng.sub1] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
8067  <b>Submitter:</b> Walter Brown <b>Opened:</b> 2005-07-03  <b>Last modified:</b> 2008-03-13</p>
8068 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.eng">issues</a> in [rand.eng].</p>
8069 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
8070 <p><b>Discussion:</b></p>
8071 <p>
8072 Paragraph 8 specifies the algorithm by which a subtract_with_carry_01  engine
8073 is to be seeded given a single unsigned long.  This algorithm is seriously
8074 flawed in the case where the engine parameter w (also known as word_size)
8075 exceeds 31 [bits].  The key part of the paragraph reads:
8076 </p>
8077 <blockquote><p>
8078 sets x(-r) ... x(-1) to (lcg(1)*2**(-w)) mod 1
8079 </p></blockquote>
8080 <p>
8081 and so forth.
8082 </p>
8083 <p>
8084 Since the specified linear congruential engine, lcg, delivers numbers with
8085 a maximum of 2147483563 (just a shade under 31 bits), then when w is, for
8086 example, 48, each of the x(i) will be less than 2**-17.  The consequence
8087 is that roughly the first 400 numbers delivered will be  conspicuously
8088 close to either zero or one.
8089 </p>
8090 <p>
8091 Unfortunately, this is not an innocuous flaw:  One of the predefined engines
8092 in [tr.rand.predef],  namely ranlux64_base_01, has w = 48 and would exhibit
8093 this poor behavior, while the original N1378 proposal states that these
8094 pre-defined engines are intended to be of "known good properties."
8095 </p>
8096
8097
8098 <p><b>Proposed resolution:</b></p>
8099 <p>
8100 In 5.1.4.4 [tr.rand.eng.sub1], replace the "effects" clause for
8101 void seed(unsigned long value = 19780503) by
8102 </p>
8103
8104 <blockquote><p>
8105 <i>Effects:</i> If <tt>value == 0</tt>, sets value to <tt>19780503</tt>. In any
8106 case, <del>with a linear congruential generator <tt>lcg</tt>(i) having parameters
8107 <tt><i>m<sub>lcg</sub></i> = 2147483563</tt>, <tt><i>a<sub>lcg</sub></i> = 40014</tt>,
8108 <tt><i>c<sub>lcg</sub></i> = 0</tt>, and <tt><i>lcg</i>(0) = value</tt>,</del>
8109 sets <ins>carry<tt>(-1)</tt> and</ins> <tt>x(-r) &#8230; x(-1)</tt>
8110 <ins>as if executing</ins></p>
8111
8112 <blockquote><pre><ins>
8113 linear_congruential&lt;unsigned long, 40014, 0, 2147483563&gt; lcg(value);
8114 seed(lcg);
8115 </ins></pre></blockquote>
8116
8117 <p>
8118 <del>to <tt>(<i>lcg</i>(1) · 2<sup>-<i>w</i></sup>) mod 1
8119 &#8230; (<i>lcg</i>(<i>r</i>) · 2<sup>-<i>w</i></sup>) mod 1</tt>,
8120 respectively. If <tt><i>x</i>(-1) == 0</tt>, sets carry<tt>(-1) = 2<sup>-<i>w</i></sup></tt>,
8121 else sets carry<tt>(-1) = 0</tt>.</del></p>
8122 </blockquote>
8123
8124 <p><i>[
8125 Jens provided revised wording post Mont Tremblant.
8126 ]</i></p>
8127
8128
8129 <p><i>[
8130 Berlin: N1932 adopts the originally-proposed resolution of the issue.
8131 Jens's supplied wording is a clearer description of what is
8132 intended.  Moved to Ready.
8133 ]</i></p>
8134
8135
8136
8137
8138 <p><b>Rationale:</b></p>
8139 <p>
8140 Jens: I'm using an explicit type here, because fixing the
8141 prose would probably not qualify for the (with issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a> even
8142 stricter) requirements we have for seed(Gen&amp;).
8143 </p>
8144
8145 <p><i>[
8146 Portland:  Subsumed by N2111.
8147 ]</i></p>
8148
8149
8150
8151
8152
8153
8154 <hr>
8155 <h3><a name="513"></a>513. Size of state for subtract_with_carry_01</h3>
8156 <p><b>Section:</b> 26.5.3 [rand.eng], TR1 5.1.4.4 [tr.rand.eng.sub1] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
8157  <b>Submitter:</b> Walter Brown <b>Opened:</b> 2005-07-03  <b>Last modified:</b> 2008-03-13</p>
8158 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.eng">issues</a> in [rand.eng].</p>
8159 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
8160 <p><b>Discussion:</b></p>
8161 <p>
8162 Paragraph 3 begins:
8163 </p>
8164 <blockquote><p>
8165 The size of the state is r.
8166 </p></blockquote>
8167 <p>
8168 However, this is not quite consistent with the remainder of the paragraph
8169 which specifies a total  of nr+1 items in the textual representation of
8170 the state.  We recommend the sentence be corrected to match:
8171 </p>
8172 <blockquote><p>
8173 The size of the state is nr+1.
8174 </p></blockquote>
8175 <p>
8176 To give meaning to the coefficient n, it may be also desirable to move
8177 n's definition from later in the paragraph.  Either of the following
8178 seem reasonable formulations:
8179 </p>
8180 <blockquote><p>
8181 With n=..., the size of the state is nr+1.
8182 </p></blockquote>
8183 <blockquote><p>
8184 The size of the state is nr+1, where n=... .
8185 </p></blockquote>
8186
8187
8188
8189 <p><b>Proposed resolution:</b></p>
8190 <p><i>[
8191 Jens:  I plead for "NAD" on the grounds that "size of state" is only
8192 used as an argument for big-O complexity notation, thus
8193 constant factors and additions don't count.
8194 ]</i></p>
8195
8196
8197 <p><i>[
8198 Berlin: N1932 adopts the proposed NAD.
8199 ]</i></p>
8200
8201
8202
8203
8204
8205
8206
8207 <hr>
8208 <h3><a name="514"></a>514. Size of state for subtract_with_carry</h3>
8209 <p><b>Section:</b> 26.5.3.3 [rand.eng.sub], TR1 5.1.4.3 [tr.rand.eng.sub] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
8210  <b>Submitter:</b> Walter Brown <b>Opened:</b> 2005-07-03  <b>Last modified:</b> 2008-03-13</p>
8211 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
8212 <p><b>Discussion:</b></p>
8213 <p>
8214 Paragraph 2 begins:
8215 </p>
8216 <blockquote><p>
8217 The size of the state is r.
8218 </p></blockquote>
8219 <p>
8220 However, the next sentence specifies a total of r+1 items in the textual
8221 representation of the state,  r specific x's as well as a specific carry.
8222 This makes a total of r+1 items that constitute the size of the state,
8223 rather than r.
8224 </p>
8225
8226
8227 <p><b>Proposed resolution:</b></p>
8228 <p>
8229 We recommend the sentence be corrected to match:
8230 </p>
8231 <blockquote><p>
8232  The size of the state is r+1.
8233 </p></blockquote>
8234
8235 <p><i>[
8236 Jens:  I plead for "NAD" on the grounds that "size of state" is only
8237 used as an argument for big-O complexity notation, thus
8238 constant factors and additions don't count.
8239 ]</i></p>
8240
8241
8242 <p><i>[
8243 Berlin: N1932 adopts the proposed NAD.
8244 ]</i></p>
8245
8246
8247
8248
8249
8250
8251
8252 <hr>
8253 <h3><a name="515"></a>515. Random number engine traits</h3>
8254 <p><b>Section:</b> 26.5.1 [rand.synopsis], TR1 5.1.2 [tr.rand.synopsis] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
8255  <b>Submitter:</b> Walter Brown <b>Opened:</b> 2005-07-03  <b>Last modified:</b> 2008-03-13</p>
8256 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.synopsis">issues</a> in [rand.synopsis].</p>
8257 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
8258 <p><b>Discussion:</b></p>
8259 <p>
8260 To accompany the concept of a pseudo-random number engine as defined in Table 17,
8261 we propose and recommend an adjunct template, engine_traits, to be declared in
8262 [tr.rand.synopsis] as:
8263 </p>
8264 <blockquote><pre>template&lt; class PSRE &gt;
8265 class engine_traits;
8266 </pre></blockquote>
8267 <p>
8268 This template's primary purpose would be as an aid to generic programming involving
8269 pseudo-random number engines.  Given only the facilities described in tr1, it would
8270 be very difficult to produce any algorithms involving the notion of a generic engine.
8271 The intent of this proposal is to  provide, via engine_traits&lt;&gt;, sufficient
8272 descriptive information to allow an algorithm to employ a pseudo-random number engine
8273 without regard to its exact type, i.e., as a template parameter.
8274 </p>
8275 <p>
8276 For example, today it is not possible to write an efficient generic function that
8277 requires any specific number of random bits.  More specifically, consider a
8278 cryptographic application that internally needs 256 bits of randomness per call:
8279 </p>
8280 <blockquote><pre>template&lt; class Eng, class InIter, class OutIter &gt;
8281 void crypto( Eng&amp; e, InIter in, OutIter out );
8282 </pre></blockquote>
8283 <p>
8284 Without knowning the number of bits of randomness produced per call to a provided
8285 engine, the algorithm has no means of determining how many times to call the engine.
8286 </p>
8287 <p>
8288 In a new section [tr.rand.eng.traits], we proposed to define the engine_traits
8289 template as:
8290 </p>
8291 <blockquote><pre>template&lt; class PSRE &gt;
8292 class engine_traits
8293 {
8294   static  std::size_t  bits_of_randomness = 0u;
8295   static  std::string  name()  { return "unknown_engine"; }
8296   // TODO: other traits here
8297 };
8298 </pre></blockquote>
8299 <p>
8300 Further, each engine described in [tr.rand.engine] would be accompanied by a
8301 complete specialization of this new engine_traits template.
8302 </p>
8303
8304
8305
8306 <p><b>Proposed resolution:</b></p>
8307 <p><i>[
8308 Berlin:  Walter: While useful for implementation per TR1, N1932 has no need for this
8309 feature.  Recommend close as NAD.
8310 ]</i></p>
8311
8312
8313
8314 <p><b>Rationale:</b></p>
8315 <p>
8316 Recommend NAD,
8317 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1932.pdf">N1932</a>,
8318 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2111.pdf">N2111</a>
8319 covers this.  Already in WP.
8320 </p>
8321
8322
8323
8324
8325
8326 <hr>
8327 <h3><a name="516"></a>516. Seeding subtract_with_carry_01 using a generator</h3>
8328 <p><b>Section:</b> 26.5.3 [rand.eng], TR1 5.1.4.4 [tr.rand.eng.sub1] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
8329  <b>Submitter:</b> Walter Brown <b>Opened:</b> 2005-07-03  <b>Last modified:</b> 2008-03-13</p>
8330 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.eng">issues</a> in [rand.eng].</p>
8331 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
8332 <p><b>Discussion:</b></p>
8333 <p>
8334 Paragraph 6 says:
8335 </p>
8336 <blockquote><p>
8337 ... obtained by successive invocations of g, ...
8338 </p></blockquote>
8339 <p>
8340 We recommend instead:
8341 </p>
8342 <blockquote><p>
8343 ... obtained by taking successive invocations of g mod 2**32, ...
8344 </p></blockquote>
8345 <p>
8346 as the context seems to require only 32-bit quantities be used here.
8347 </p>
8348
8349
8350 <p><b>Proposed resolution:</b></p>
8351 <p>
8352 Berlin: N1932 adopts the proposed resultion: see 26.3.3.4/7.  Moved to Ready.
8353 </p>
8354
8355 <p><i>[
8356 Portland:  Subsumed by N2111.
8357 ]</i></p>
8358
8359
8360
8361
8362
8363
8364 <hr>
8365 <h3><a name="517"></a>517. Should include name in external representation</h3>
8366 <p><b>Section:</b> X [rand.req], TR1 5.1.1 [tr.rand.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
8367  <b>Submitter:</b> Walter Brown <b>Opened:</b> 2005-07-03  <b>Last modified:</b> 2008-03-13</p>
8368 <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>
8369 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
8370 <p><b>Discussion:</b></p>
8371 <p>
8372 The last two rows of Table 16 deal with the i/o requirements of an engine,
8373 specifying that the textual representation of an engine's state,
8374 appropriately formatted, constitute the engine's  external representation.
8375 </p>
8376 <p>
8377 This seems adequate when an engine's type is known.  However, it seems
8378 inadequate in the  context of generic code, where it becomes useful and
8379 perhaps even necessary to determine an engine's type via input.
8380 </p>
8381 <p>
8382 </p>
8383
8384
8385 <p><b>Proposed resolution:</b></p>
8386 <p>
8387 We therefore recommend that, in each of these two rows of Table 16, the
8388 text "textual representation" be expanded so as to read "engine name
8389 followed by the textual representation."
8390 </p>
8391
8392 <p><i>[
8393 Berlin: N1932 considers this NAD. This is a QOI issue.
8394 ]</i></p>
8395
8396
8397
8398
8399
8400
8401
8402 <hr>
8403 <h3><a name="525"></a>525. type traits definitions not clear</h3>
8404 <p><b>Section:</b> 20.6.4 [meta.unary], TR1 4.5 [tr.meta.unary] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
8405  <b>Submitter:</b> Robert Klarer <b>Opened:</b> 2005-07-11  <b>Last modified:</b> 2008-03-13</p>
8406 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
8407 <p><b>Discussion:</b></p>
8408 <p>
8409 It is not completely clear how the primary type traits deal with
8410 cv-qualified types.  And several of the secondary type traits
8411 seem to be lacking a definition.
8412 </p>
8413
8414 <p><i>[
8415 Berlin:  Howard to provide wording.
8416 ]</i></p>
8417
8418
8419
8420 <p><b>Proposed resolution:</b></p>
8421 <p>
8422 Wording provided in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2028.html">N2028</a>.
8423 A
8424 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2157.html">revision (N2157)</a>
8425 provides more detail for motivation.
8426 </p>
8427
8428
8429 <p><b>Rationale:</b></p>
8430 Solved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2157.html">revision (N2157)</a>
8431 in the WP.
8432
8433
8434
8435
8436
8437 <hr>
8438 <h3><a name="526"></a>526. Is it undefined if a function in the standard changes in parameters?</h3>
8439 <p><b>Section:</b> 23.2.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
8440  <b>Submitter:</b> Chris Jefferson <b>Opened:</b> 2005-09-14  <b>Last modified:</b> 2008-03-13</p>
8441 <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>
8442 <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>
8443 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
8444 <p><b>Discussion:</b></p>
8445 <p>
8446 Problem: There are a number of places in the C++ standard library where
8447 it is possible to write what appear to be sensible ways of calling
8448 functions, but which can cause problems in some (or all)
8449 implementations, as they cause the values given to the function to be
8450 changed in a way not specified in standard (and therefore not coded to
8451 correctly work). These fall into two similar categories.
8452 </p>
8453
8454 <p>
8455 1) Parameters taken by const reference can be changed during execution
8456 of the function
8457 </p>
8458
8459 <p>
8460 Examples:
8461 </p>
8462
8463 <p>
8464 Given std::vector&lt;int&gt; v:
8465 </p>
8466 <p>
8467 v.insert(v.begin(), v[2]);
8468 </p>
8469 <p>
8470 v[2] can be changed by moving elements of vector
8471 </p>
8472
8473
8474 <p>
8475 Given std::list&lt;int&gt; l:
8476 </p>
8477 <p>
8478 l.remove(*l.begin());
8479 </p>
8480 <p>
8481 Will delete the first element, and then continue trying to access it.
8482 This is particularily vicious, as it will appear to work in almost all
8483 cases.
8484 </p>
8485
8486 <p>
8487 2) A range is given which changes during the execution of the function:
8488 Similarly,
8489 </p>
8490
8491 <p>
8492 v.insert(v.begin(), v.begin()+4, v.begin()+6);
8493 </p>
8494
8495 <p>
8496 This kind of problem has been partly covered in some cases. For example
8497 std::copy(first, last, result) states that result cannot be in the range
8498 [first, last). However, does this cover the case where result is a
8499 reverse_iterator built from some iterator in the range [first, last)?
8500 Also, std::copy would still break if result was reverse_iterator(last +
8501 1), yet this is not forbidden by the standard
8502 </p>
8503
8504 <p>
8505 Solution:
8506 </p>
8507
8508 <p>
8509 One option would be to try to more carefully limit the requirements of
8510 each function. There are many functions which would have to be checked.
8511 However as has been shown in the std::copy case, this may be difficult.
8512 A simpler, more global option would be to somewhere insert text similar to:
8513 </p>
8514
8515 <p>
8516 If the execution of any function would change either any values passed
8517 by reference or any value in any range passed to a function in a way not
8518 defined in the definition of that function, the result is undefined.
8519 </p>
8520
8521 <p>
8522 Such code would have to at least cover chapters 23 and 25 (the sections
8523 I read through carefully). I can see no harm on applying it to much of
8524 the rest of the standard.
8525 </p>
8526
8527 <p>
8528 Some existing parts of the standard could be improved to fit with this,
8529 for example the requires for 25.2.1 (Copy) could be adjusted to:
8530 </p>
8531
8532 <p>
8533 Requires: For each non-negative integer n &lt; (last - first), assigning to
8534 *(result + n) must not alter any value in the range [first + n, last).
8535 </p>
8536
8537 <p>
8538 However, this may add excessive complication.
8539 </p>
8540
8541 <p>
8542 One other benefit of clearly introducing this text is that it would
8543 allow a number of small optimisations, such as caching values passed
8544 by const reference.
8545 </p>
8546
8547 <p>
8548 Matt Austern adds that this issue also exists for the <tt>insert</tt> and
8549 <tt>erase</tt> members of the ordered and unordered associative containers.
8550 </p>
8551
8552 <p><i>[
8553 Berlin: Lots of controversey over how this should be solved. Lots of confusion
8554 as to whether we're talking about self referencing iterators or references.
8555 Needs a good survey as to the cases where this matters, for which
8556 implementations, and how expensive it is to fix each case.
8557 ]</i></p>
8558
8559
8560
8561
8562 <p><b>Proposed resolution:</b></p>
8563
8564
8565 <p><b>Rationale:</b></p>
8566 <p>
8567 Recommend NAD.
8568 </p>
8569 <ul>
8570 <li><tt>vector::insert(iter, value)</tt> is required to work because the standard
8571 doesn't give permission for it not to work.</li>
8572 <li><tt>list::remove(value)</tt> is required to work because the standard
8573 doesn't give permission for it not to work.</li>
8574 <li><tt>vector::insert(iter, iter, iter)</tt> is not required to work because
8575 23.2.3 [sequence.reqmts], p4 says so.</li>
8576 <li><tt>copy</tt> has to work, except where 25.4.1 [alg.copy] says
8577 it doesn't have to work.  While a language lawyer can tear this wording apart,
8578 it is felt that the wording is not prone to accidental interpretation.</li>
8579 <li>The current working draft provide exceptions for the unordered associative
8580 containers similar to the containers requirements which exempt the member
8581 template insert functions from self referencing.</li>
8582 </ul>
8583
8584
8585
8586
8587
8588 <hr>
8589 <h3><a name="528"></a>528. <tt>const_iterator</tt> <tt>iterator</tt> issue when they are the same type</h3>
8590 <p><b>Section:</b> 23.5 [unord], TR1 6.3.4 [tr.unord.unord] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
8591  <b>Submitter:</b> Paolo Carlini <b>Opened:</b> 2005-10-12  <b>Last modified:</b> 2008-03-13</p>
8592 <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>
8593 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
8594 <p><b>Discussion:</b></p>
8595 <p>
8596 while implementing the resolution of issue 6.19 I'm noticing the
8597 following: according to 6.3.4.3/2 (and 6.3.4.5/2), for unordered_set and
8598 unordered_multiset:
8599 </p>
8600
8601 <blockquote><p>
8602     "The iterator and const_iterator types are both const types. It is
8603 unspecified whether they are the same type"
8604 </p></blockquote>
8605
8606 <p>
8607 Now, according to the resolution of 6.19, we have overloads of insert
8608 with hint and erase (single and range) both for iterator and
8609 const_iterator, which, AFAICS, can be meaningful at the same time *only*
8610 if iterator and const_iterator *are* in fact different types.
8611 </p>
8612 <p>
8613 Then, iterator and const_iterator are *required* to be different types?
8614 Or that is an unintended consequence? Maybe the overloads for plain
8615 iterators should be added only to unordered_map and unordered_multimap?
8616 Or, of course, I'm missing something?
8617 </p>
8618
8619
8620
8621 <p><b>Proposed resolution:</b></p>
8622 <p>
8623 Add to 6.3.4.3p2 (and 6.3.4.5p2):
8624 </p>
8625 <p>
8626 2  ... The iterator and const_iterator types are both <del>const</del>
8627 <ins>constant</ins> iterator types.
8628 It is unspecified whether they are the same type.
8629 </p>
8630
8631 <p>
8632 Add a new subsection to 17.4.4 [lib.conforming]:
8633 </p>
8634
8635 <blockquote>
8636 <p>
8637 An implementation shall not supply an overloaded function
8638        signature specified in any library clause if such a signature
8639        would be inherently ambiguous during overload resolution
8640        due to two library types referring to the same type.
8641 </p>
8642 <p>
8643        [Note: For example, this occurs when a container's iterator
8644        and const_iterator types are the same. -- end note]
8645 </p>
8646 </blockquote>
8647
8648 <p><i>[
8649 Post-Berlin: Beman supplied wording.
8650 ]</i></p>
8651
8652
8653
8654
8655 <p><b>Rationale:</b></p>
8656 Toronto:  The first issue has been fixed by N2350 (the insert and erase members
8657 are collapsed into one signature).  Alisdair to open a separate issue on the
8658 chapter 17 wording.
8659
8660
8661
8662
8663
8664 <hr>
8665 <h3><a name="529"></a>529. The standard encourages redundant and confusing preconditions</h3>
8666 <p><b>Section:</b> 17.6.3.11 [res.on.required] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
8667  <b>Submitter:</b> David Abrahams <b>Opened:</b> 2005-10-25  <b>Last modified:</b> 2008-03-13</p>
8668 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
8669 <p><b>Discussion:</b></p>
8670 <p>
8671 17.4.3.8/1 says:
8672 </p>
8673
8674 <blockquote><p>
8675 Violation of the preconditions specified in a function's
8676 Required behavior: paragraph results in undefined behavior unless the
8677 function's Throws: paragraph specifies throwing an exception when the
8678 precondition is violated.
8679 </p></blockquote>
8680
8681 <p>
8682 This implies that a precondition violation can lead to defined
8683 behavior.  That conflicts with the only reasonable definition of
8684 precondition: that a violation leads to undefined behavior.  Any other
8685 definition muddies the waters when it comes to analyzing program
8686 correctness, because precondition violations may be routinely done in
8687 correct code (e.g. you can use std::vector::at with the full
8688 expectation that you'll get an exception when your index is out of
8689 range, catch the exception, and continue).  Not only is it a bad
8690 example to set, but it encourages needless complication and redundancy
8691 in the standard.  For example:
8692 </p>
8693
8694 <blockquote><pre>  21 Strings library
8695   21.3.3 basic_string capacity
8696
8697   void resize(size_type n, charT c);
8698
8699   5 Requires: n &lt;= max_size()
8700   6 Throws: length_error if n &gt; max_size().
8701   7 Effects: Alters the length of the string designated by *this as follows:
8702 </pre></blockquote>
8703
8704 <p>
8705 The Requires clause is entirely redundant and can be dropped.  We
8706 could make that simplifying change (and many others like it) even
8707 without changing 17.4.3.8/1; the wording there just seems to encourage
8708 the redundant and error-prone Requires: clause.
8709 </p>
8710
8711 <p><i>[
8712 Batavia:  Alan and Pete to work.
8713 ]</i></p>
8714
8715
8716 <p><i>[
8717 Bellevue:  NAD Editorial, this group likes
8718 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2121.html">N2121</a>,
8719 Pete agrees, accepting it is Pete's business.
8720 General agreement that precondition violations are synonymous with UB.
8721 ]</i></p>
8722
8723
8724
8725 <p><b>Proposed resolution:</b></p>
8726 <p>
8727 1. Change 17.4.3.8/1 to read:
8728 </p>
8729
8730 <blockquote><p>
8731 Violation of the preconditions specified in a function's
8732 <i>Required behavior:</i> paragraph results in undefined behavior
8733 <del>unless the function's <i>Throws:</i> paragraph specifies throwing
8734 an exception when the precondition is violated</del>.
8735 </p></blockquote>
8736
8737 <p>
8738 2. Go through and remove redundant Requires: clauses.  Specifics to be
8739    provided by Dave A.
8740 </p>
8741
8742 <p><i>[
8743 Berlin: The LWG requests a detailed survey of part 2 of the proposed resolution.
8744 ]</i></p>
8745
8746
8747 <p><i>[
8748 Alan provided the survey
8749 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2121.html">N2121</a>.
8750 ]</i></p>
8751
8752
8753
8754
8755
8756
8757
8758 <hr>
8759 <h3><a name="532"></a>532. Tuple comparison</h3>
8760 <p><b>Section:</b> 20.5.2.5 [tuple.rel], TR1 6.1.3.5 [tr.tuple.rel] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
8761  <b>Submitter:</b> David Abrahams <b>Opened:</b> 2005-11-29  <b>Last modified:</b> 2008-09-23</p>
8762 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple.rel">issues</a> in [tuple.rel].</p>
8763 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
8764 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a></p>
8765 <p><b>Discussion:</b></p>
8766 <p>
8767 Where possible, tuple comparison operators &lt;,&lt;=,=&gt;, and &gt; ought to be
8768 defined in terms of std::less rather than operator&lt;, in order to
8769 support comparison of tuples of pointers.
8770 </p>
8771
8772
8773 <p><b>Proposed resolution:</b></p>
8774 <p>
8775 change 6.1.3.5/5 from:
8776 </p>
8777
8778 <blockquote><p>
8779   Returns: The result of a lexicographical comparison between t and
8780   u. The result is defined as: (bool)(get&lt;0&gt;(t) &lt; get&lt;0&gt;(u)) ||
8781   (!(bool)(get&lt;0&gt;(u) &lt; get&lt;0&gt;(t)) &amp;&amp; ttail &lt; utail), where rtail for
8782   some tuple r is a tuple containing all but the first element of
8783   r. For any two zero-length tuples e and f, e &lt; f returns false.
8784 </p></blockquote>
8785
8786 <p>
8787 to:
8788 </p>
8789
8790 <blockquote>
8791 <p>
8792   Returns: The result of a lexicographical comparison between t and
8793   u. For any two zero-length tuples e and f, e &lt; f returns false.
8794   Otherwise, the result is defined as: cmp( get&lt;0&gt;(t), get&lt;0&gt;(u)) ||
8795   (!cmp(get&lt;0&gt;(u), get&lt;0&gt;(t)) &amp;&amp; ttail &lt; utail), where rtail for some
8796   tuple r is a tuple containing all but the first element of r, and
8797   cmp(x,y) is an unspecified function template defined as follows.
8798 </p>
8799 <p>
8800   Where T is the type of x and U is the type of y:
8801 </p>
8802
8803 <p>
8804      if T and U are pointer types and T is convertible to U, returns
8805      less&lt;U&gt;()(x,y)
8806 </p>
8807
8808 <p>
8809      otherwise, if T and U are pointer types, returns less&lt;T&gt;()(x,y)
8810 </p>
8811
8812 <p>
8813      otherwise, returns (bool)(x &lt; y)
8814 </p>
8815 </blockquote>
8816
8817 <p><i>[
8818 Berlin: This issue is much bigger than just tuple (pair, containers,
8819 algorithms). Dietmar will survey and work up proposed wording.
8820 ]</i></p>
8821
8822
8823
8824
8825 <p><b>Rationale:</b></p>
8826 <p>
8827 Recommend NAD.  This will be fixed with the next revision of concepts.
8828 </p>
8829
8830 <p><i>[
8831 San Francisco:
8832 ]</i></p>
8833
8834
8835 <blockquote>
8836 Solved by
8837 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2770.pdf">N2770</a>.
8838 </blockquote>
8839
8840
8841
8842
8843
8844 <hr>
8845 <h3><a name="536"></a>536. Container iterator constructor and explicit convertibility</h3>
8846 <p><b>Section:</b> 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
8847  <b>Submitter:</b> Joaquín M López Muñoz <b>Opened:</b> 2005-12-17  <b>Last modified:</b> 2007-04-18</p>
8848 <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>
8849 <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>
8850 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
8851 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#589">589</a></p>
8852 <p><b>Discussion:</b></p>
8853 <p>
8854 The iterator constructor X(i,j) for containers as defined in 23.1.1 and
8855 23.2.2 does only require that i and j be input iterators but
8856 nothing is said about their associated value_type. There are three
8857 sensible
8858 options:
8859 </p>
8860 <ol>
8861 <li>iterator's value_type is exactly X::value_type (modulo cv).</li>
8862 <li>iterator's value_type is *implicitly* convertible to X::value_type.</li>
8863 <li>iterator's value_type is *explicitly* convertible to X::value_type.</li>
8864 </ol>
8865 <p>
8866 The issue has practical implications, and stdlib vendors have
8867 taken divergent approaches to it: Dinkumware follows 2,
8868 libstdc++ follows 3.
8869 </p>
8870 <p>
8871 The same problem applies to the definition of insert(p,i,j) for
8872 sequences and insert(i,j) for associative contianers, as well as
8873 assign.
8874 </p>
8875
8876 <p><i>[
8877 The following added by Howard and the example code was originally written by
8878 Dietmar.
8879 ]</i></p>
8880
8881 <p>
8882 Valid code below?
8883 </p>
8884
8885 <blockquote><pre>#include &lt;vector&gt;
8886 #include &lt;iterator&gt;
8887 #include &lt;iostream&gt;
8888
8889 struct foo
8890 {
8891     explicit foo(int) {}
8892 };
8893
8894 int main()
8895 {
8896     std::vector&lt;int&gt; v_int;
8897     std::vector&lt;foo&gt; v_foo1(v_int.begin(), v_int.end());
8898     std::vector&lt;foo&gt; v_foo2((std::istream_iterator&lt;int&gt;(std::cin)),
8899                              std::istream_iterator&lt;int&gt;());
8900 }
8901 </pre></blockquote>
8902 <p><i>[
8903 Berlin: Some support, not universal, for respecting the explicit qualifier.
8904 ]</i></p>
8905
8906
8907
8908
8909 <p><b>Proposed resolution:</b></p>
8910
8911
8912
8913
8914
8915
8916 <hr>
8917 <h3><a name="544"></a>544. minor NULL problems in C.2</h3>
8918 <p><b>Section:</b> C.2 [diff.library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
8919  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2005-11-25  <b>Last modified:</b> 2007-04-24</p>
8920 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#diff.library">issues</a> in [diff.library].</p>
8921 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
8922 <p><b>Discussion:</b></p>
8923 <p>
8924 According to C.2.2.3, p1, "the macro NULL, defined in any of &lt;clocale&gt;,
8925 &lt;cstddef&gt;, &lt;cstdio&gt;, &lt;cstdlib&gt;, &lt;cstring&gt;, &lt;ctime&gt;,
8926 or &lt;cwchar&gt;." This is consistent with the C standard.
8927 </p>
8928 <p>
8929 However, Table 95 in C.2 fails to mention &lt;clocale&gt; and &lt;cstdlib&gt;.
8930 </p>
8931 <p>
8932 In addition, C.2, p2 claims that "The C++ Standard library provides
8933 54 standard macros from the C library, as shown in Table 95." While
8934 table 95 does have 54 entries, since a couple of them (including the
8935 NULL macro) are listed more than once, the actual number of macros
8936 defined by the C++ Standard Library may not be 54.
8937 </p>
8938
8939
8940 <p><b>Proposed resolution:</b></p>
8941 <p>
8942 I propose we add &lt;clocale&gt; and &lt;cstdlib&gt; to Table 96 and remove the
8943 number of macros from C.2, p2 and reword the sentence as follows:
8944 </p>
8945 <blockquote><p>
8946 The C++ Standard library <del>provides 54 standard macros from</del>
8947 <ins>defines a number macros corresponding to those defined by</ins> the C
8948 <ins>Standard</ins> library, as shown in Table 96.
8949 </p></blockquote>
8950
8951 <p><i>[
8952 Portland:  Resolution is considered editorial.  It will be incorporated into the WD.
8953 ]</i></p>
8954
8955
8956
8957
8958
8959
8960
8961 <hr>
8962 <h3><a name="547"></a>547. division should be floating-point, not integer</h3>
8963 <p><b>Section:</b> 26.5 [rand], TR1 5.1 [tr.rand] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
8964  <b>Submitter:</b> Matt Austern <b>Opened:</b> 2006-01-10  <b>Last modified:</b> 2007-04-18</p>
8965 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand">active issues</a> in [rand].</p>
8966 <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>
8967 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
8968 <p><b>Discussion:</b></p>
8969 <p>
8970 Paragraph 10 describes how a variate generator uses numbers produced by an
8971 engine to pass to a generator. The sentence that concerns me is: "Otherwise, if
8972 the value for engine_value_type::result_type is true and the value for
8973 Distribution::input_type is false [i.e. if the engine produces integers and the
8974 engine wants floating-point values], then the numbers in s_eng are divided by
8975 engine().max() - engine().min() + 1 to obtain the numbers in s_e." Since the
8976 engine is producing integers, both the numerator and the denominator are
8977 integers and we'll be doing integer division, which I don't think is what we
8978 want. Shouldn't we be performing a conversion to a floating-point type first?
8979 </p>
8980
8981
8982 <p><b>Proposed resolution:</b></p>
8983
8984
8985 <p><b>Rationale:</b></p>
8986 <p>
8987 Recommend NAD as the affected section is now gone and so the issue is moot.
8988 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2111.pdf">N2111</a>.
8989 </p>
8990
8991
8992
8993
8994
8995 <hr>
8996 <h3><a name="548"></a>548. May random_device block?</h3>
8997 <p><b>Section:</b> 26.5.6 [rand.device], TR1 5.1.6 [tr.rand.device] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
8998  <b>Submitter:</b> Matt Austern <b>Opened:</b> 2006-01-10  <b>Last modified:</b> 2007-10-18</p>
8999 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.device">issues</a> in [rand.device].</p>
9000 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
9001 <p><b>Discussion:</b></p>
9002 <p>
9003 Class random_device "produces non-deterministic random numbers", using some
9004 external source of entropy. In most real-world systems, the amount of available
9005 entropy is limited. Suppose that entropy has been exhausted. What is an
9006 implementation permitted to do? In particular, is it permitted to block
9007 indefinitely until more random bits are available, or is the implementation
9008 required to detect failure immediately? This is not an academic question. On
9009 Linux a straightforward implementation would read from /dev/random, and "When
9010 the entropy pool is empty, reads to /dev/random will block until additional
9011 environmental noise is gathered." Programmers need to know whether random_device
9012 is permitted to (or possibly even required to?) behave the same way.
9013 </p>
9014
9015 <p><i>[
9016 Berlin: Walter: N1932 considers this NAD. Does the standard specify whether std::cin
9017 may block?
9018 ]</i></p>
9019
9020
9021 <p>
9022 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
9023 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
9024 for some further discussion.
9025 </p>
9026
9027
9028 <p><b>Proposed resolution:</b></p>
9029 <p>
9030 Adopt the proposed resolution in
9031 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a> (NAD).
9032 </p>
9033
9034
9035
9036
9037
9038 <hr>
9039 <h3><a name="549"></a>549. Undefined variable in binomial_distribution</h3>
9040 <p><b>Section:</b> 26.5.8 [rand.dist], TR1 5.1.7.5 [tr.rand.dist.bin] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
9041  <b>Submitter:</b> Matt Austern <b>Opened:</b> 2006-01-10  <b>Last modified:</b> 2007-04-24</p>
9042 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist">issues</a> in [rand.dist].</p>
9043 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
9044 <p><b>Discussion:</b></p>
9045 <p>
9046 Paragraph 1 says that "A binomial distributon random distribution produces
9047 integer values i&gt;0 with p(i) = (n choose i) * p*i * (1-p)^(t-i), where t and
9048 p are the parameters of the distribution. OK, that tells us what t, p, and i
9049 are. What's n?
9050 </p>
9051
9052
9053 <p><b>Proposed resolution:</b></p>
9054 <p>
9055 Berlin: Typo: "n" replaced by "t" in N1932: see 26.3.7.2.2/1.
9056 </p>
9057
9058 <p><i>[
9059 Portland:  Subsumed by N2111.
9060 ]</i></p>
9061
9062
9063
9064
9065
9066
9067 <hr>
9068 <h3><a name="553"></a>553. very minor editorial change intptr_t / uintptr_t</h3>
9069 <p><b>Section:</b> 18.4.1 [cstdint.syn], TR1 8.22.1 [tr.c99.cstdint.syn] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
9070  <b>Submitter:</b> Paolo Carlini <b>Opened:</b> 2006-01-30  <b>Last modified:</b> 2007-07-02</p>
9071 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#cstdint.syn">issues</a> in [cstdint.syn].</p>
9072 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
9073 <p><b>Discussion:</b></p>
9074 <p>
9075 In the synopsis, some types are identified as optional: int8_t, int16_t,
9076 and so on, consistently with C99, indeed.
9077 </p>
9078 <p>
9079 On the other hand, intptr_t and uintptr_t, are not marked as such and
9080 probably should, consistently with C99, 7.18.1.4.
9081 </p>
9082
9083
9084 <p><b>Proposed resolution:</b></p>
9085 <p>
9086 Change 18.4.1 [cstdint.syn]:
9087 </p>
9088
9089 <blockquote><pre>...
9090 typedef <i>signed integer type</i> intptr_t;    <ins><i>// optional</i></ins>
9091 ...
9092 typedef <i>unsigned integer type</i> uintptr_t;    <ins><i>// optional</i></ins>
9093 ...
9094 </pre></blockquote>
9095
9096
9097
9098 <p><b>Rationale:</b></p>
9099 Recommend NAD and fix as editorial with the proposed resolution.
9100
9101
9102
9103
9104
9105 <hr>
9106 <h3><a name="554"></a>554. Problem with lwg DR 184 numeric_limits&lt;bool&gt;</h3>
9107 <p><b>Section:</b> 18.3.1.5 [numeric.special] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
9108  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2006-01-29  <b>Last modified:</b> 2007-01-15</p>
9109 <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>
9110 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
9111 <p><b>Discussion:</b></p>
9112 <p>
9113 I believe we have a bug in the resolution of:
9114 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#184">lwg 184</a>
9115 (WP status).
9116 </p>
9117
9118 <p>
9119 The resolution spells out each member of <tt>numeric_limits&lt;bool&gt;</tt>.
9120 The part I'm having a little trouble with is:
9121 </p>
9122 <blockquote><pre>static const bool traps = false;
9123 </pre></blockquote>
9124
9125 <p>
9126 Should this not be implementation defined?  Given:
9127 </p>
9128
9129 <blockquote><pre>int main()
9130 {
9131      bool b1 = true;
9132      bool b2 = false;
9133      bool b3 = b1/b2;
9134 }
9135 </pre></blockquote>
9136
9137 <p>
9138 If this causes a trap, shouldn't <tt>numeric_limits&lt;bool&gt;::traps</tt> be
9139 <tt>true</tt>?
9140 </p>
9141
9142
9143 <p><b>Proposed resolution:</b></p>
9144 <p>
9145 Change 18.2.1.5p3:
9146 </p>
9147
9148 <blockquote><p>
9149 -3- The specialization for <tt>bool</tt> shall be provided as follows: </p>
9150 <blockquote><pre>namespace std {
9151    template &lt;&gt; class numeric_limits&lt;bool&gt; {
9152       ...
9153       static const bool traps = <del>false</del> <ins><i>implementation-defined</i></ins>;
9154       ...
9155    };
9156 }
9157 </pre></blockquote>
9158 </blockquote>
9159
9160 <p><i>[
9161 Redmond:  NAD because traps refers to values, not operations.  There is no bool
9162 value that will trap.
9163 ]</i></p>
9164
9165
9166
9167
9168
9169
9170
9171 <hr>
9172 <h3><a name="555"></a>555. TR1, 8.21/1: typo</h3>
9173 <p><b>Section:</b> TR1 8.21 [tr.c99.boolh] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
9174  <b>Submitter:</b> Paolo Carlini <b>Opened:</b> 2006-02-02  <b>Last modified:</b> 2007-04-24</p>
9175 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
9176 <p><b>Discussion:</b></p>
9177 <p>
9178 This one, if nobody noticed it yet, seems really editorial:
9179 s/cstbool/cstdbool/
9180 </p>
9181
9182
9183 <p><b>Proposed resolution:</b></p>
9184 <p>
9185 Change 8.21p1:
9186 </p>
9187 <blockquote><p>
9188 -1- The header behaves as if it defines the additional macro defined in
9189 <tt>&lt;cst<ins>d</ins>bool&gt;</tt> by including the header <tt>&lt;cstdbool&gt;</tt>.
9190 </p></blockquote>
9191
9192 <p><i>[
9193 Redmond:  Editorial.
9194 ]</i></p>
9195
9196
9197
9198
9199
9200
9201
9202 <hr>
9203 <h3><a name="556"></a>556. is Compare a BinaryPredicate?</h3>
9204 <p><b>Section:</b> 25.5 [alg.sorting] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
9205  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-02-05  <b>Last modified:</b> 2008-09-26</p>
9206 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.sorting">issues</a> in [alg.sorting].</p>
9207 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
9208 <p><b>Discussion:</b></p>
9209 <p>
9210 In 25, p8 we allow BinaryPredicates to return a type that's convertible
9211 to bool but need not actually be bool. That allows predicates to return
9212 things like proxies and requires that implementations be careful about
9213 what kinds of expressions they use the result of the predicate in (e.g.,
9214 the expression in if (!pred(a, b)) need not be well-formed since the
9215 negation operator may be inaccessible or return a type that's not
9216 convertible to bool).
9217 </p>
9218 <p>
9219 Here's the text for reference:
9220 </p>
9221 <blockquote><p>
9222   ...if an algorithm takes BinaryPredicate binary_pred as its argument
9223  and first1 and first2 as its iterator arguments, it should work
9224  correctly in the construct if (binary_pred(*first1, first2)){...}.
9225 </p></blockquote>
9226
9227 <p>
9228 In 25.3, p2 we require that the Compare function object return true
9229 of false, which would seem to preclude such proxies. The relevant text
9230 is here:
9231 </p>
9232 <blockquote><p>
9233   Compare is used as a function object which returns true if the first
9234   argument is less than the second, and false otherwise...
9235 </p></blockquote>
9236
9237
9238
9239 <p><b>Proposed resolution:</b></p>
9240 <p>
9241 I think we could fix this by rewording 25.3, p2 to read somthing like:
9242 </p>
9243 <blockquote><p>
9244 -2- <tt>Compare</tt> is <del>used as a function object which returns
9245 <tt>true</tt> if the first argument</del> <ins>a <tt>BinaryPredicate</tt>. The
9246 return value of the function call operator applied to an object of type
9247 <tt>Compare</tt>, when converted to type <tt>bool</tt>, yields <tt>true</tt>
9248 if the first argument of the call</ins> is less than the second, and
9249 <tt>false</tt> otherwise. <tt>Compare <i>comp</i></tt> is used throughout for
9250 algorithms assuming an ordering relation. It is assumed that <tt><i>comp</i></tt>
9251 will not apply any non-constant function through the dereferenced iterator.
9252 </p></blockquote>
9253
9254
9255 <p><i>[
9256 Portland:  Jack to define "convertible to bool" such that short circuiting isn't
9257 destroyed.
9258 ]</i></p>
9259
9260
9261 <p><b>Rationale:</b></p>
9262 <p><i>[
9263 San Francisco:
9264 ]</i></p>
9265
9266
9267 <blockquote>
9268 Solved by
9269 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2774.pdf">N2774</a>).
9270 </blockquote>
9271
9272
9273
9274
9275
9276
9277 <hr>
9278 <h3><a name="557"></a>557. TR1: div(_Longlong, _Longlong) vs div(intmax_t, intmax_t)</h3>
9279 <p><b>Section:</b> 18.4 [cstdint], TR1 8.22 [tr.c99.cstdint] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
9280  <b>Submitter:</b> Paolo Carlini <b>Opened:</b> 2006-02-06  <b>Last modified:</b> 2008-07-02</p>
9281 <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>
9282 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
9283 <p><b>Discussion:</b></p>
9284 <p>
9285 I'm seeing a problem with such overloads: when, _Longlong == intmax_t ==
9286 long long we end up, essentially, with the same arguments and different
9287 return types (lldiv_t and imaxdiv_t, respectively). Similar issue with
9288 abs(_Longlong) and abs(intmax_t), of course.
9289 </p>
9290 <p>
9291 Comparing sections 8.25 and 8.11, I see an important difference,
9292 however: 8.25.3 and 8.25.4 carefully describe div and abs for _Longlong
9293 types (rightfully, because not moved over directly from C99), whereas
9294 there is no equivalent in 8.11: the abs and div overloads for intmax_t
9295 types appear only in the synopsis and are not described anywhere, in
9296 particular no mention in 8.11.2 (at variance with 8.25.2).
9297 </p>
9298 <p>
9299 I'm wondering whether we really, really, want div and abs for intmax_t...
9300 </p>
9301
9302
9303
9304 <p><b>Proposed resolution:</b></p>
9305
9306
9307
9308 <p><i>[
9309 Portland: no consensus.
9310 ]</i></p>
9311
9312
9313 <p><b>Rationale:</b></p>
9314 <p><i>[
9315 Batavia, Bill: The <tt>&lt;cstdint&gt;</tt> synopsis in TR1 8.11.1 [tr.c99.cinttypes.syn] contains:
9316 ]</i></p>
9317
9318 <blockquote><pre>intmax_t imaxabs(intmax_t i);
9319 intmax_t abs(intmax_t i);
9320
9321 imaxdiv_t imaxdiv(intmax_t numer, intmax_t denom);
9322 imaxdiv_t div(intmax_t numer, intmax_t denom);
9323 </pre></blockquote>
9324
9325 <p><i>[
9326 and in TR1 8.11.2 [tr.c99.cinttypes.def]:
9327 ]</i></p>
9328
9329
9330 <blockquote><p>
9331 The header defines all functions, types, and macros the same as C99
9332 subclause 7.8.
9333 </p></blockquote>
9334
9335 <p><i>[
9336 This is as much definition as we give for most other C99 functions,
9337 so nothing need change. We might, however, choose to add the footnote:
9338 ]</i></p>
9339
9340
9341 <blockquote><p>
9342 [<i>Note:</i> These overloads for <tt>abs</tt> and <tt>div</tt> may well be equivalent to
9343 those that take <tt>long long</tt> arguments. If so, the implementation is
9344 responsible for avoiding conflicting declarations. -- <i>end note</i>]
9345 </p></blockquote>
9346
9347 <p><i>[
9348 Bellevue: NAD Editorial. Pete must add a footnote, as described below.
9349 ]</i></p>
9350
9351
9352 <blockquote>
9353 <p><i>[
9354 Looks like a real problem. Dietmar suggests div() return a template
9355 type. Matt: looks like imaxdiv_t is loosly defined. Can it be a typedef
9356 for lldiv_t when _Longlong == intmax_t? PJP seems to agree. We would
9357 need a non-normative note declaring that the types lldiv_t and imaxdiv_t
9358 may not be unique if intmax_t==_longlong.
9359 ]</i></p>
9360
9361 </blockquote>
9362
9363
9364
9365
9366
9367
9368 <hr>
9369 <h3><a name="558"></a>558. lib.input.iterators Defect</h3>
9370 <p><b>Section:</b> 24.2.2 [input.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
9371  <b>Submitter:</b> David Abrahams <b>Opened:</b> 2006-02-09  <b>Last modified:</b> 2007-04-24</p>
9372 <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>
9373 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
9374 <p><b>Discussion:</b></p>
9375 <blockquote>
9376 <p>
9377   24.1.1 Input iterators [lib.input.iterators]
9378 </p>
9379 <p>
9380   1 A class or a built-in type X satisfies the requirements of an
9381   input iterator for the value type T if the following expressions are
9382   valid, where U is the type of any specified member of type T, as
9383   shown in Table 73.
9384 </p>
9385 </blockquote>
9386 <p>
9387 There is no capital U used in table 73.  There is a lowercase u, but
9388 that is clearly not meant to denote a member of type T.  Also, there's
9389 no description in 24.1.1 of what lowercase a means.  IMO the above
9390 should have been...Hah, a and b are already covered in 24.1/11, so maybe it
9391 should have just been:
9392 </p>
9393
9394
9395 <p><b>Proposed resolution:</b></p>
9396 <p>
9397 Change 24.1.1p1:
9398 </p>
9399 <blockquote><p>
9400 -1- A class or a built-in type <tt>X</tt> satisfies the requirements of an
9401 input iterator for the value type <tt>T</tt> if the following expressions
9402 are valid<del>, where <tt>U</tt> is the type of any specified member of type
9403 <tt>T</tt>,</del> as shown in Table 73.
9404 </p></blockquote>
9405
9406 <p><i>[
9407 Portland: Editorial.
9408 ]</i></p>
9409
9410
9411
9412
9413
9414
9415
9416 <hr>
9417 <h3><a name="560"></a>560. User-defined allocators without default constructor</h3>
9418 <p><b>Section:</b> X [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
9419  <b>Submitter:</b> Sergey P. Derevyago <b>Opened:</b> 2006-02-17  <b>Last modified:</b> 2007-04-18</p>
9420 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p>
9421 <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>
9422 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
9423 <p><b>Discussion:</b></p>
9424 <h4>1. The essence of the problem.</h4>
9425 <p>
9426 User-defined allocators without default constructor are not explicitly
9427 supported by the standard but they can be supported just like std::vector
9428 supports elements without default constructor.
9429 </p>
9430 <p>
9431 As a result, there exist implementations that work well with such allocators
9432 and implementations that don't.
9433 </p>
9434
9435 <h4>2. The cause of the problem.</h4>
9436 <p>
9437 1) The standard doesn't explicitly state this intent but it should. In
9438 particular, 20.1.5p5 explicitly state the intent w.r.t. the allocator
9439 instances that compare non-equal. So it can similarly state the intent w.r.t.
9440 the user-defined allocators without default constructor.
9441 </p>
9442 <p>
9443 2) Some container operations are obviously underspecified. In particular,
9444 21.3.7.1p2 tells:
9445 </p>
9446 <blockquote><pre>template&lt;class charT, class traits, class Allocator&gt;
9447   basic_string&lt;charT,traits,Allocator&gt; operator+(
9448     const charT* lhs,
9449     const basic_string&lt;charT,traits,Allocator&gt;&amp; rhs
9450   );
9451 </pre>
9452 <p>
9453 Returns: <tt>basic_string&lt;charT,traits,Allocator&gt;(lhs) + rhs</tt>.
9454 </p>
9455 </blockquote>
9456 <p>
9457 That leads to the basic_string&lt;charT,traits,Allocator&gt;(lhs, Allocator()) call.
9458 Obviously, the right requirement is:
9459 </p>
9460 <blockquote><p>
9461 Returns: <tt>basic_string&lt;charT,traits,Allocator&gt;(lhs, rhs.get_allocator()) + rhs</tt>.
9462 </p></blockquote>
9463 <p>
9464 It seems like a lot of DRs can be submitted on this "Absent call to
9465 get_allocator()" topic.
9466 </p>
9467
9468 <h4>3. Proposed actions.</h4>
9469 <p>
9470 1) Explicitly state the intent to allow for user-defined allocators without
9471 default constructor in 20.1.5 Allocator requirements.
9472 </p>
9473 <p>
9474 2) Correct all the places, where a correct allocator object is available
9475 through the get_allocator() call but default Allocator() gets passed instead.
9476 </p>
9477 <h4>4. Code sample.</h4>
9478 <p>
9479 Let's suppose that the following memory pool is available:
9480 </p>
9481 <blockquote><pre>class mem_pool {
9482       // ...
9483       void* allocate(size_t size);
9484       void deallocate(void* ptr, size_t size);
9485 };
9486 </pre></blockquote>
9487 <p>
9488 So the following allocator can be implemented via this pool:
9489 </p>
9490 <blockquote><pre>class stl_allocator {
9491       mem_pool&amp; pool;
9492
9493  public:
9494       explicit stl_allocator(mem_pool&amp; mp) : pool(mp) {}
9495       stl_allocator(const stl_allocator&amp; sa) : pool(sa.pool) {}
9496       template &lt;class U&gt;
9497       stl_allocator(const stl_allocator&lt;U&gt;&amp; sa)  : pool(sa.get_pool()) {}
9498       ~stl_allocator() {}
9499
9500       pointer allocate(size_type n, std::allocator&lt;void&gt;::const_pointer = 0)
9501       {
9502        return (n!=0) ? static_cast&lt;pointer&gt;(pool.allocate(n*sizeof(T))) : 0;
9503       }
9504
9505       void deallocate(pointer p, size_type n)
9506       {
9507        if (n!=0) pool.deallocate(p, n*sizeof(T));
9508       }
9509
9510       // ...
9511 };
9512 </pre></blockquote>
9513 <p>
9514 Then the following code works well on some implementations and doesn't work on
9515 another:
9516 </p>
9517 <blockquote><pre>typedef basic_string&lt;char, char_traits&lt;char&gt;, stl_allocator&lt;char&gt; &gt;
9518   tl_string;
9519 mem_pool mp;
9520 tl_string s1("abc", stl_allocator&lt;int&gt;(mp));
9521 printf("(%s)\n", ("def"+s1).c_str());
9522 </pre></blockquote>
9523 <p>
9524 In particular, on some implementations the code can't be compiled without
9525 default stl_allocator() constructor.
9526 </p>
9527 <p>
9528 The obvious way to solve the compile-time problems is to intentionally define
9529 a NULL pointer dereferencing default constructor
9530 </p>
9531 <blockquote><pre>stl_allocator() : pool(*static_cast&lt;mem_pool*&gt;(0)) {}
9532 </pre></blockquote>
9533 <p>
9534 in a hope that it will not be called. The problem is that it really gets
9535 called by operator+(const char*, const string&amp;) under the current 21.3.7.1p2
9536 wording.
9537 </p>
9538
9539
9540 <p><b>Proposed resolution:</b></p>
9541 <p>
9542 </p>
9543
9544
9545 <p><b>Rationale:</b></p>
9546 <p>
9547 Recommend NAD.  <tt>operator+()</tt> with <tt>string</tt> already requires the desired
9548 semantics of copying the allocator from one of the strings (<i>lhs</i> when there is a choice).
9549 </p>
9550
9551
9552
9553
9554
9555 <hr>
9556 <h3><a name="569"></a>569. Postcondition for basic_ios::clear(iostate) incorrectly stated</h3>
9557 <p><b>Section:</b> 27.5.4.3 [iostate.flags] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
9558  <b>Submitter:</b> Seungbeom Kim <b>Opened:</b> 2006-03-10  <b>Last modified:</b> 2006-12-30</p>
9559 <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>
9560 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
9561 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#272">272</a></p>
9562 <p><b>Discussion:</b></p>
9563 <p>
9564 Section: 27.4.4.3 [lib.iostate.flags]
9565 </p>
9566 <p>
9567 Paragraph 4 says:
9568 </p>
9569 <blockquote>
9570 <blockquote><pre>void clear(iostate <i>state</i> = goodbit);
9571 </pre></blockquote>
9572 <p>
9573 <i>Postcondition:</i> If <tt>rdbuf()!=0</tt> then <tt><i>state</i> == rdstate();</tt>
9574 otherwise <tt>rdstate()==<i>state</i>|ios_base::badbit</tt>.
9575 </p>
9576 </blockquote>
9577
9578 <p>
9579 The postcondition "rdstate()==state|ios_base::badbit" is parsed as
9580 "(rdstate()==state)|ios_base::badbit", which is probably what the
9581 committee meant.
9582 </p>
9583
9584
9585
9586
9587 <p><b>Rationale:</b></p>
9588
9589
9590
9591
9592
9593
9594 <hr>
9595 <h3><a name="570"></a>570. Request adding additional explicit specializations of char_traits</h3>
9596 <p><b>Section:</b> 21.2 [char.traits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
9597  <b>Submitter:</b> Jack Reeves <b>Opened:</b> 2006-04-06  <b>Last modified:</b> 2008-06-18</p>
9598 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#char.traits">issues</a> in [char.traits].</p>
9599 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
9600 <p><b>Discussion:</b></p>
9601 <p>
9602 Currently, the Standard Library specifies only a declaration for template class
9603 char_traits&lt;&gt; and requires the implementation provide two explicit
9604 specializations: char_traits&lt;char&gt; and char_traits&lt;wchar_t&gt;. I feel the Standard
9605 should require explicit specializations for all built-in character types, i.e.
9606 char, wchar_t, unsigned char, and signed char.
9607 </p>
9608 <p>
9609 I have put together a paper
9610 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1985.htm">N1985</a>)
9611 that describes this in more detail and
9612 includes all the necessary wording.
9613 </p>
9614 <p><i>[
9615 Portland: Jack will rewrite
9616 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1985.htm">N1985</a>
9617 to propose a primary template that will work with other integral types.
9618 ]</i></p>
9619
9620 <p><i>[
9621 Toronto: issue has grown with addition of <tt>char16_t</tt> and <tt>char32_t</tt>.
9622 ]</i></p>
9623
9624
9625 <p><i>[
9626 post Bellevue:
9627 ]</i></p>
9628
9629
9630 <blockquote>
9631 <p>
9632 We suggest that Jack be asked about the status of his paper, and if it
9633 is not forthcoming, the work-item be assigned to someone else. If no one
9634 steps forward to do the paper before the next meeting, we propose to
9635 make this NAD without further discussion. We leave this Open for now,
9636 but our recommendation is NAD.
9637 </p>
9638 <p>
9639 Note: the issue statement should be updated, as the Toronto comment has
9640 already been resolved. E.g., char_traits specializations for char16_t
9641 and char32_t are now in the working paper.
9642 </p>
9643 </blockquote>
9644
9645 <p><i>[
9646 Sophia Antipolis:
9647 ]</i></p>
9648
9649
9650 <blockquote>
9651 Nobody has submitted the requested paper, so we move to NAD, as suggested by the decision at the last meeting.
9652 </blockquote>
9653
9654
9655 <p><b>Proposed resolution:</b></p>
9656
9657
9658
9659
9660
9661 <hr>
9662 <h3><a name="571"></a>571. Update C90 references to C99?</h3>
9663 <p><b>Section:</b> 1.2 [intro.refs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
9664  <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2006-04-08  <b>Last modified:</b> 2007-07-02</p>
9665 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#intro.refs">issues</a> in [intro.refs].</p>
9666 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
9667 <p><b>Discussion:</b></p>
9668 <p>
9669 1.2 Normative references [intro.refs] of the WP currently refers to ISO/IEC
9670 9899:1990, Programming languages - C. Should that be changed to ISO/IEC
9671 9899:1999?
9672 </p>
9673 <p>
9674 What impact does this have on the library?
9675 </p>
9676
9677
9678 <p><b>Proposed resolution:</b></p>
9679 <p>
9680 In 1.2/1 [intro.refs] of the WP, change:
9681 </p>
9682 <blockquote>
9683 <ul>
9684 <li>ISO/IEC 9899:<del>1990</del><ins>1999 + TC1 + TC2</ins>, <i>Programming languages - C</i></li>
9685 </ul>
9686 </blockquote>
9687
9688
9689
9690 <p><b>Rationale:</b></p>
9691 Recommend NAD, fixed editorially.
9692
9693
9694
9695
9696
9697 <hr>
9698 <h3><a name="572"></a>572. Oops, we gave 507 WP status</h3>
9699 <p><b>Section:</b> 26.5 [rand], TR1 5.1 [tr.rand] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
9700  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2006-04-11  <b>Last modified:</b> 2007-04-18</p>
9701 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand">active issues</a> in [rand].</p>
9702 <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>
9703 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
9704 <p><b>Discussion:</b></p>
9705 <p>
9706 In Berlin, as a working group, we voted in favor of N1932 which makes issue 507 moot:
9707 variate_generator has been eliminated.  Then in full committee we voted to give
9708 this issue WP status (mistakenly).
9709 </p>
9710
9711
9712 <p><b>Proposed resolution:</b></p>
9713 <p>
9714 Strike the proposed resolution of issue 507.
9715 </p>
9716 <p><i>[
9717 post-Portland:  Walter and Howard recommend NAD.  The proposed resolution of 507 no longer
9718 exists in the current WD.
9719 ]</i></p>
9720
9721
9722
9723 <p><b>Rationale:</b></p>
9724 <p>
9725 NAD.  Will be moot once
9726 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2135.pdf">N2135</a>
9727 is adopted.
9728 </p>
9729
9730
9731
9732
9733
9734 <hr>
9735 <h3><a name="579"></a>579. erase(iterator) for unordered containers should not return an iterator</h3>
9736 <p><b>Section:</b> 23.2.5 [unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
9737  <b>Submitter:</b> Joaquín M López Muñoz <b>Opened:</b> 2006-06-13  <b>Last modified:</b> 2008-03-12</p>
9738 <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>
9739 <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>
9740 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
9741 <p><b>Discussion:</b></p>
9742 <p>
9743 See
9744 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2023.pdf">N2023</a>
9745 for full discussion.
9746 </p>
9747
9748
9749 <p><b>Proposed resolution:</b></p>
9750 <p>
9751 Option 1:
9752 </p>
9753
9754 <p>
9755 The problem can be eliminated by omitting the requirement that <tt>a.erase(q)</tt> return an
9756 iterator. This is, however, in contrast with the equivalent requirements for other
9757 standard containers.
9758 </p>
9759
9760 <p>
9761 Option 2:
9762 </p>
9763
9764 <p>
9765 <tt>a.erase(q)</tt> can be made to compute the next iterator only when explicitly requested:
9766 the technique consists in returning a proxy object implicitly convertible to <tt>iterator</tt>, so
9767 that
9768 </p>
9769
9770 <blockquote><pre>iterator q1=a.erase(q);
9771 </pre></blockquote>
9772
9773 <p>
9774 works as expected, while
9775 </p>
9776
9777 <blockquote><pre>a.erase(q);
9778 </pre></blockquote>
9779
9780 <p>
9781 does not ever invoke the conversion-to-iterator operator, thus avoiding the associated
9782 computation. To allow this technique, some sections of TR1 along the line "return value
9783 is an iterator..." should be changed to "return value is an unspecified object implicitly
9784 convertible to an iterator..." Although this trick is expected to work transparently, it can
9785 have some collateral effects when the expression <tt>a.erase(q)</tt> is used inside generic
9786 code.
9787 </p>
9788
9789
9790
9791 <p><b>Rationale:</b></p>
9792 <p>
9793 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2023.pdf">N2023</a>
9794 was discussed in Portland and the consensus was that there appears to be
9795 no need for either change proposed in the paper.  The consensus opinion
9796 was that since the iterator could serve as its own proxy, there appears
9797 to be no need for the change. In general, "converts to" is undesirable
9798 because it interferes with template matching.
9799 </p>
9800
9801 <p>
9802 Post Toronto:  There does not at this time appear to be consensus with the Portland consensus.
9803 </p>
9804
9805 <p><i>[
9806 Bellevue:
9807 ]</i></p>
9808
9809
9810 <blockquote>
9811 The Bellevue review of this issue reached consensus with the Portland
9812 consensus, in contravention of the Toronto non-consensus. Common
9813 implementations have the iterator readily available, and most common
9814 uses depend on the iterator being returned.
9815 </blockquote>
9816
9817
9818
9819
9820
9821
9822 <hr>
9823 <h3><a name="583"></a>583. div() for unsigned integral types</h3>
9824 <p><b>Section:</b> 26.8 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
9825  <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2006-06-15  <b>Last modified:</b> 2007-07-25</p>
9826 <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>
9827 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
9828 <p><b>Discussion:</b></p>
9829 <p>
9830 There is no div() function for unsigned integer types.
9831 </p>
9832 <p>
9833 There are several possible resolutions.  The simplest one is noted below.  Other
9834 possibilities include a templated solution.
9835 </p>
9836
9837
9838 <p><b>Proposed resolution:</b></p>
9839 <p>
9840 Add to 26.7 [lib.c.math] paragraph 8:
9841 </p>
9842
9843 <blockquote><pre>struct udiv_t div(unsigned, unsigned);
9844 struct uldiv_t div(unsigned long, unsigned long);
9845 struct ulldiv_t div(unsigned long long, unsigned long long);
9846 </pre></blockquote>
9847
9848
9849
9850 <p><b>Rationale:</b></p>
9851 Toronto:  C99 does not have these unsigned versions because
9852 the signed version exist just to define the implementation-defined behavior
9853 of signed integer division.  Unsigned integer division has no implementation-defined
9854 behavior and thus does not need this treatment.
9855
9856
9857
9858
9859
9860 <hr>
9861 <h3><a name="584"></a>584. missing int pow(int,int) functionality</h3>
9862 <p><b>Section:</b> 26.8 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
9863  <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2006-06-15  <b>Last modified:</b> 2007-07-25</p>
9864 <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>
9865 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
9866 <p><b>Discussion:</b></p>
9867 <p>
9868 There is no pow() function for any integral type.
9869 </p>
9870
9871
9872 <p><b>Proposed resolution:</b></p>
9873 <p>
9874 Add something like:
9875 </p>
9876
9877 <blockquote><pre>template&lt; typename T&gt;
9878 T power( T x, int n );
9879 // requires: n &gt;=0
9880 </pre></blockquote>
9881
9882
9883 <p><b>Rationale:</b></p>
9884 Toronto:  We already have double pow(integral, integral) from 26.8 [c.math] p11.
9885
9886
9887
9888
9889
9890 <hr>
9891 <h3><a name="587"></a>587. iststream ctor missing description</h3>
9892 <p><b>Section:</b> D.7.2.1 [depr.istrstream.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
9893  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-06-22  <b>Last modified:</b> 2007-05-11</p>
9894 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
9895 <p><b>Discussion:</b></p>
9896         <p>
9897
9898 The  <code>iststream(char*, streamsize)</code>  ctor is  in  the class
9899 synopsis  in D.7.2  but its  signature is  missing in  the description
9900 below (in D.7.2.1).
9901
9902         </p>
9903
9904
9905     <p><b>Proposed resolution:</b></p>
9906         <p>
9907
9908 This seems like a simple editorial issue and the missing signature can
9909 be added to the one for <code>const char*</code> in paragraph 2.
9910
9911         </p>
9912
9913 <p><i>[
9914 post Oxford: Noted that it is already fixed in
9915 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2284.pdf">N2284</a>
9916 ]</i></p>
9917
9918
9919
9920
9921
9922
9923 <hr>
9924 <h3><a name="590"></a>590. Type traits implementation latitude should be removed for C++0x</h3>
9925 <p><b>Section:</b> 20.6 [meta], TR1 4.9 [tr.meta.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
9926  <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2006-08-10  <b>Last modified:</b> 2007-05-11</p>
9927 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta">active issues</a> in [meta].</p>
9928 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta">issues</a> in [meta].</p>
9929 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
9930 <p><b>Discussion:</b></p>
9931 <p>
9932 20.4.9 [lib.meta.req], Implementation requirements, provides latitude for type
9933 traits implementers that is not needed in C++0x. It includes the wording:
9934 </p>
9935
9936 <blockquote><p>
9937 [<i>Note:</i> the latitude granted to implementers in this clause is temporary,
9938 and is expected to be removed in future revisions of this document. -- <i>end note</i>]
9939 </p></blockquote>
9940
9941 <p>
9942 Note:
9943 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2157.html">N2157: Minor Modifications to the type traits Wording</a>
9944 also has the intent of removing this wording from the WP.
9945 </p>
9946
9947
9948
9949 <p><b>Proposed resolution:</b></p>
9950 <p>
9951 Remove 20.4.9 [lib.meta.req] in its entirety from the WP.
9952 </p>
9953
9954 <p><i>[
9955 post-Oxford: Recommend NAD Editorial.  This resolution is now in the
9956 current working draft.
9957 ]</i></p>
9958
9959
9960
9961
9962
9963
9964
9965 <hr>
9966 <h3><a name="591"></a>591. Misleading "built-in</h3>
9967 <p><b>Section:</b> 18.3.1.2 [numeric.limits.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
9968  <b>Submitter:</b> whyglinux <b>Opened:</b> 2006-08-08  <b>Last modified:</b> 2007-07-02</p>
9969 <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>
9970 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
9971 <p><b>Discussion:</b></p>
9972 <p>
9973 18.2.1.2 numeric_limits members [lib.numeric.limits.members]
9974 Paragraph 7:
9975 </p>
9976 <blockquote><p>
9977 "For built-in integer types, the number of non-sign bits in the
9978 representation."
9979 </p></blockquote>
9980
9981 <p>
9982 26.1 Numeric type requirements [lib.numeric.requirements]
9983 Footnote:
9984 </p>
9985
9986 <blockquote><p>
9987 "In other words, value types. These include built-in arithmetic types,
9988 pointers, the library class complex, and instantiations of valarray for
9989 value types."
9990 </p></blockquote>
9991
9992 <p>
9993 Integer types (which are bool, char, wchar_t, and the signed and
9994 unsigned integer types) and arithmetic types (which are integer and
9995 floating types) are all built-in types and thus there are no
9996 non-built-in (that is, user-defined) integer or arithmetic types. Since
9997 the redundant "built-in" in the above 2 sentences can mislead that
9998 there may be built-in or user-defined integer and arithmetic types
9999 (which is not correct), the "built-in" should be removed.
10000 </p>
10001
10002
10003 <p><b>Proposed resolution:</b></p>
10004 <p>
10005 18.2.1.2 numeric_limits members [lib.numeric.limits.members]
10006 Paragraph 7:
10007 </p>
10008 <blockquote><p>
10009 "For <del>built-in</del> integer types, the number of non-sign bits in the
10010 representation."
10011 </p></blockquote>
10012
10013 <p>
10014 26.1 Numeric type requirements [lib.numeric.requirements]
10015 Footnote:
10016 </p>
10017
10018 <blockquote><p>
10019 "In other words, value types. These include <del>built-in</del> arithmetic types,
10020 pointers, the library class complex, and instantiations of valarray for
10021 value types."
10022 </p></blockquote>
10023
10024
10025 <p><b>Rationale:</b></p>
10026 <p>
10027 Recommend NAD / Editorial.  The proposed resolution is accepted as editorial.
10028 </p>
10029
10030
10031
10032
10033
10034 <hr>
10035 <h3><a name="592"></a>592. Incorrect treatment of rdbuf()-&gt;close() return type</h3>
10036 <p><b>Section:</b> 27.9.1.9 [ifstream.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
10037  <b>Submitter:</b> Christopher Kohlhoff <b>Opened:</b> 2006-08-17  <b>Last modified:</b> 2008-07-02</p>
10038 <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>
10039 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
10040 <p><b>Discussion:</b></p>
10041 <p>
10042 I just spotted a minor problem in 27.8.1.7
10043 [lib.ifstream.members] para 4 and also 27.8.1.13
10044 [lib.fstream.members] para 4. In both places it says:
10045 </p>
10046 <blockquote>
10047 <pre>void close();
10048 </pre>
10049 <p>
10050 Effects: Calls rdbuf()-&gt;close() and, if that function returns false, ...
10051 </p>
10052 </blockquote>
10053 <p>
10054 However, basic_filebuf::close() (27.8.1.2) returns a pointer to the
10055 filebuf on success, null on failure, so I think it is meant to
10056 say "if that function returns a null pointer". Oddly, it is
10057 correct for basic_ofstream.
10058 </p>
10059
10060
10061 <p><b>Proposed resolution:</b></p>
10062 <p>
10063 Change 27.9.1.9 [ifstream.members], p5:
10064 </p>
10065
10066 <blockquote><p>
10067 <i>Effects:</i> Calls <tt>rdbuf()-&gt;close()</tt> and, if that function
10068 <ins>fails (</ins>returns <del><tt>false</tt></del> <ins>a null pointer)</ins>,
10069 calls <tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt>
10070 (27.4.4.3)).
10071 </p></blockquote>
10072
10073 <p>
10074 Change 27.9.1.17 [fstream.members], p5:
10075 </p>
10076
10077 <blockquote><p>
10078 <i>Effects:</i> Calls <tt>rdbuf()-&gt;close()</tt> and, if that function
10079 <ins>fails (</ins>returns <del><tt>false</tt></del> <ins>a null pointer)</ins>,
10080 calls <tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt>
10081 (27.4.4.3)).
10082 </p></blockquote>
10083
10084
10085
10086 <p><i>[
10087 Kona (2007): Proposed Disposition: NAD, Editorial
10088 ]</i></p>
10089
10090
10091
10092
10093
10094 <hr>
10095 <h3><a name="594"></a>594. Disadvantages of defining Swappable in terms of CopyConstructible and Assignable</h3>
10096 <p><b>Section:</b> X [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
10097  <b>Submitter:</b> Niels Dekker <b>Opened:</b> 2006-11-02  <b>Last modified:</b> 2008-09-23</p>
10098 <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>
10099 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
10100 <p><b>Discussion:</b></p>
10101 <p>
10102 It seems undesirable to define the Swappable requirement in terms of
10103 CopyConstructible and Assignable requirements. And likewise, once the
10104 MoveConstructible and MoveAssignable requirements (N1860) have made it
10105 into the Working Draft, it seems undesirable to define the Swappable
10106 requirement in terms of those requirements. Instead, it appears
10107 preferable to have the Swappable requirement defined exclusively in
10108 terms of the existence of an appropriate swap function.
10109 </p>
10110 <p>
10111 Section 20.1.4 [lib.swappable] of the current Working Draft (N2009)
10112 says:
10113 </p>
10114 <blockquote><p>
10115 The Swappable requirement is met by satisfying one or more of the
10116 following conditions:</p>
10117 <ul>
10118 <li>
10119 T is Swappable if T satisfies the CopyConstructible requirements
10120 (20.1.3) and the Assignable requirements (23.1);
10121 </li>
10122 <li>
10123 T is Swappable if a namespace scope function named swap exists in the
10124 same namespace as the definition of T, such that the expression
10125 swap(t,u) is valid and has the semantics described in Table 33.
10126 </li>
10127 </ul>
10128 </blockquote>
10129 I can think of three disadvantages of this definition:
10130 <ol>
10131 <li>
10132 If a client's type T satisfies the first condition (T is both
10133 CopyConstructible and Assignable), the client cannot stop T from
10134 satisfying the Swappable requirement without stopping T from
10135 satisfying the first condition.
10136 <p>
10137 A client might want to stop T from satisfying the Swappable
10138 requirement, because swapping by means of copy construction and
10139 assignment might throw an exception, and she might find a throwing
10140 swap unacceptable for her type. On the other hand, she might not feel
10141 the need to fully implement her own swap function for this type. In
10142 this case she would want to be able to simply prevent algorithms that
10143 would swap objects of type T from being used, e.g., by declaring a
10144 swap function for T, and leaving this function purposely undefined.
10145 This would trigger a link error, if an attempt would be made to use
10146 such an algorithm for this type. For most standard library
10147 implementations, this practice would indeed have the effect of
10148 stopping T from satisfying the Swappable requirement.
10149 </p>
10150 </li>
10151 <li>
10152 A client's type T that does not satisfy the first condition can not be
10153 made Swappable by providing a specialization of std::swap for T.
10154 <p>
10155 While I'm aware about the fact that people have mixed feelings about
10156 providing a specialization of std::swap, it is well-defined to do so.
10157 It sounds rather counter-intuitive to say that T is not Swappable, if
10158 it has a valid and semantically correct specialization of std::swap.
10159 Also in practice, providing such a specialization will have the same
10160 effect as satisfying the Swappable requirement.
10161 </p>
10162 </li>
10163 <li>
10164 For a client's type T that satisfies both conditions of the Swappable
10165 requirement, it is not specified which of the two conditions prevails.
10166 After reading section 20.1.4 [lib.swappable], one might wonder whether
10167 objects of T will be swapped by doing copy construction and
10168 assignments, or by calling the swap function of T.
10169 <p>
10170 I'm aware that the intention of the Draft is to prefer calling the
10171 swap function of T over doing copy construction and assignments. Still
10172 in my opinion, it would be better to make this clear in the wording of
10173 the definition of Swappable.
10174 </p>
10175 </li>
10176 </ol>
10177 <p>
10178 I would like to have the Swappable requirement defined in such a way
10179 that the following code fragment will correctly swap two objects of a
10180 type T, if and only if T is Swappable:
10181 </p>
10182 <pre>   using std::swap;
10183    swap(t, u);  // t and u are of type T.
10184 </pre>
10185 <p>
10186 This is also the way Scott Meyers recommends calling a swap function,
10187 in Effective C++, Third Edition, item 25.
10188 </p>
10189 <p>
10190 Most aspects of this issue have been dealt with in a discussion on
10191 comp.std.c++ about the Swappable requirement, from 13 September to 4
10192 October 2006, including valuable input by David Abrahams, Pete Becker,
10193 Greg Herlihy, Howard Hinnant and others.
10194 </p>
10195
10196 <p><b>Proposed resolution:</b></p>
10197 <p>
10198 Change section 20.1.4 [lib.swappable] as follows:
10199 </p>
10200 <blockquote><p>
10201 The Swappable requirement is met by satisfying
10202 <del>one or more of the following conditions:</del>
10203 <ins>the following condition:</ins></p>
10204 <ul>
10205
10206 <li>
10207 <del>T is Swappable if T satisfies the CopyConstructible requirements
10208 (20.1.3) and the Assignable requirements (23.1);</del>
10209 </li>
10210 <li>
10211 <del>
10212 T is Swappable if a namespace scope function named swap exists in the
10213 same namespace as the definition of T, such that the expression
10214 swap(t,u) is valid and has the semantics described in Table 33.
10215 </del>
10216 T is Swappable if an unqualified function call swap(t,u) is valid
10217 within the namespace std, and has the semantics described in Table 33.
10218 </li>
10219 </ul>
10220 </blockquote>
10221
10222
10223 <p><b>Rationale:</b></p>
10224 <p>
10225 Recommend NAD.  Concepts, specifically
10226 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2082.pdf">N2082</a>
10227 and
10228 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2084.pdf">N2084</a>,
10229 will essentially rewrite this section and provide the desired semantics.
10230 </p>
10231
10232 <p><i>[
10233 San Francisco:
10234 ]</i></p>
10235
10236
10237 <blockquote>
10238 Solved by
10239 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2774.pdf">N2774</a>.
10240 </blockquote>
10241
10242
10243
10244
10245
10246 <hr>
10247 <h3><a name="615"></a>615. Inconsistencies in Section 21.4</h3>
10248 <p><b>Section:</b> 21.6 [c.strings] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
10249  <b>Submitter:</b> Bo Persson <b>Opened:</b> 2006-12-11  <b>Last modified:</b> 2007-04-24</p>
10250 <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>
10251 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
10252 <p><b>Discussion:</b></p>
10253 <p>
10254 In the current draft N2134, 21.4/1 says
10255 </p>
10256 <p>
10257 "Tables 59,228) 60, 61, 62,and 63 229) 230) describe headers &lt;cctype&gt;,
10258 &lt;cwctype&gt;, &lt;cstring&gt;, &lt;cwchar&gt;, and &lt;cstdlib&gt; (character conversions),
10259 respectively."
10260 </p>
10261 <p>
10262 Here footnote 229 applies to table 62, not table 63.
10263 </p>
10264 <p>
10265 Also, footnote 230 lists the new functions in table 63, "atoll, strtoll,
10266 strtoull, strtof, and strtold added by TR1". However, strtof is not present
10267 in table 63.
10268 </p>
10269
10270
10271 <p><b>Proposed resolution:</b></p>
10272 <p>
10273 </p>
10274
10275
10276 <p><b>Rationale:</b></p>
10277 <p>
10278 Recommend NAD, editorial.  Send to Pete.
10279 </p>
10280
10281
10282
10283
10284
10285 <hr>
10286 <h3><a name="626"></a>626. new <i>Remark</i> clauses not documented</h3>
10287 <p><b>Section:</b> 17.5.1.4 [structure.specifications] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
10288  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-01-20  <b>Last modified:</b> 2008-02-25</p>
10289 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#structure.specifications">active issues</a> in [structure.specifications].</p>
10290 <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>
10291 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
10292 <p><b>Discussion:</b></p>
10293         <p>
10294
10295 The <i>Remark</i> clauses newly  introduced into the Working Paper
10296 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2134.pdf">N2134</a>)
10297 are  not mentioned  in  17.5.1.4 [structure.specifications] where  we list  the
10298 meaning  of <i>Effects</i>, <i>Requires</i>,  and other  clauses (with
10299 the exception  of <i>Notes</i> which are documented  as informative in
10300 17.5.1.2 [structure.summary], p2, and which they replace in many cases).
10301
10302         </p>
10303         <p>
10304
10305 Propose add a bullet for <i>Remarks</i> along with a brief description.
10306
10307         </p>
10308 <p><i>[
10309 Batavia:  Alan and Pete to work.
10310 ]</i></p>
10311
10312
10313 <p><i>[
10314 Bellevue: Already resolved in current working paper.
10315 ]</i></p>
10316
10317
10318
10319 <p><b>Proposed resolution:</b></p>
10320 <p>
10321 </p>
10322
10323
10324
10325
10326
10327 <hr>
10328 <h3><a name="627"></a>627. Low memory and exceptions</h3>
10329 <p><b>Section:</b> 18.6.1.1 [new.delete.single] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
10330  <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2007-01-23  <b>Last modified:</b> 2008-02-25</p>
10331 <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>
10332 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
10333 <p><b>Discussion:</b></p>
10334 <p>
10335 I recognize the need for nothrow guarantees in the exception reporting
10336 mechanism, but I strongly believe that implementors also need an escape hatch
10337 when memory gets really low. (Like, there's not enough heap to construct and
10338 copy exception objects, or not enough stack to process the throw.) I'd like to
10339 think we can put this escape hatch in 18.6.1.1 [new.delete.single],
10340 <tt>operator new</tt>, but I'm not sure how to do it. We need more than a
10341 footnote, but the wording has to be a bit vague. The idea is that if
10342 <tt>new</tt> can't allocate something sufficiently small, it has the right to
10343 <tt>abort</tt>/call <tt>terminate</tt>/call <tt>unexpected</tt>.
10344 </p>
10345
10346 <p><i>[
10347 Bellevue: NAD.  1.4p2 specifies a program must behave correctly "within
10348 its resource limits", so no further escape hatch is necessary.
10349 ]</i></p>
10350
10351
10352
10353 <p><b>Proposed resolution:</b></p>
10354 <p>
10355 </p>
10356
10357
10358
10359
10360
10361 <hr>
10362 <h3><a name="631"></a>631. conflicting requirements for <tt>BinaryPredicate</tt></h3>
10363 <p><b>Section:</b> 25 [algorithms] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
10364  <b>Submitter:</b> James Kanze <b>Opened:</b> 2007-01-31  <b>Last modified:</b> 2008-09-26</p>
10365 <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>
10366 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
10367 <p><b>Discussion:</b></p>
10368 <p>
10369 The general requirements for <tt><tt>BinaryPredicate</tt></tt> (in 25 [algorithms]/8) contradict the implied specific requirements for
10370 some functions. In particular, it says that:
10371 </p>
10372
10373 <blockquote><p>
10374 [...] if an algorithm takes <tt>BinaryPredicate <i>binary_pred</i></tt>
10375 as its argument and <tt><i>first1</i></tt> and <i>first2</i> as its
10376 iterator arguments, it should work correctly in the construct <tt>if
10377 (binary_pred (*<i>first1</i> , *<i>first2</i> )){...}</tt>.
10378 <tt>BinaryPredicate</tt> always takes the first iterator type as its
10379 first argument, that is, in those cases when <tt>T <i>value</i></tt> is
10380 part of the signature, it should work correctly in the context of <tt>if
10381 (binary_pred (*<i>first1</i> , <i>value</i>)){...}</tt>.
10382 </p></blockquote>
10383
10384 <p>
10385 In the description of <tt>upper_bound</tt> (25.5.3.2 [upper.bound]/2), however, the use is described as
10386 "<tt>!comp(<i>value</i>, <i>e</i>)</tt>", where <tt><i>e</i></tt> is an
10387 element of the sequence (a result of dereferencing
10388 <tt>*<i>first</i></tt>).
10389 </p>
10390
10391 <p>
10392 In the description of <tt>lexicographical_compare</tt>, we have both
10393 "<tt>*<i>first1</i> &lt; *<i>first2</i></tt>" and "<tt>*<i>first2</i>
10394 &lt; *<i>first1</i></tt>" (which presumably implies "<tt>comp(
10395 *<i>first1</i>, *<i>first2</i> )</tt>" and "<tt>comp( *<i>first2</i>,
10396 *<i>first1</i> )</tt>".
10397 </p>
10398
10399 <p><i>[
10400 Toronto:  Moved to Open.  ConceptGCC seems to get <tt>lower_bound</tt>
10401 and <tt>upper_bound</tt> to work withoutt these changes.
10402 ]</i></p>
10403
10404
10405
10406
10407 <p><b>Proposed resolution:</b></p>
10408 <p>
10409 Logically, the <tt>BinaryPredicate</tt> is used as an ordering
10410 relationship, with the semantics of "less than".  Depending on the
10411 function, it may be used to determine equality, or any of the inequality
10412 relationships; doing this requires being able to use it with either
10413 parameter first.  I would thus suggest that the requirement be:
10414 </p>
10415
10416 <blockquote><p>
10417 [...] <tt>BinaryPredicate</tt> always takes the first iterator
10418 <tt>value_type</tt> as one of its arguments, it is unspecified which. If
10419 an algorithm takes <tt>BinaryPredicate <i>binary_pred</i></tt> as its
10420 argument and <tt><i><i>first1</i></i></tt> and <i>first2</i> as its
10421 iterator arguments, it should work correctly both in the construct
10422 <tt>if (binary_pred (*<i>first1</i> , *<i>first2</i> )){...}</tt> and
10423 <tt>if (binary_pred (*<i>first2</i>, *<i>first1</i>)){...}</tt>.  In
10424 those cases when <tt>T <i>value</i></tt> is part of the signature, it
10425 should work correctly in the context of <tt>if (binary_pred
10426 (*<i>first1</i> , <i>value</i>)){...}</tt> and of <tt>if (binary_pred
10427 (<i>value</i>, *<i>first1</i>)){...}</tt>. [<i>Note:</i> if the two
10428 types are not identical, and neither is convertable to the other, this
10429 may require that the <tt>BinaryPredicate</tt> be a functional object
10430 with two overloaded <tt>operator()()</tt> functions. <i>--end note</i>]
10431 </p></blockquote>
10432
10433 <p>
10434 Alternatively, one could specify an order for each function. IMHO, this
10435 would be more work for the committee, more work for the implementors,
10436 and of no real advantage for the user: some functions, such as
10437 <tt>lexicographical_compare</tt> or <tt>equal_range</tt>, will still require both
10438 functions, and it seems like a much easier rule to teach that both
10439 functions are always required, rather than to have a complicated list of
10440 when you only need one, and which one.
10441 </p>
10442
10443
10444 <p><b>Rationale:</b></p>
10445 <p><i>[
10446 post San Francisco:
10447 ]</i></p>
10448
10449
10450 <blockquote>
10451 Solved by
10452 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2759.pdf">N2759</a>.
10453 </blockquote>
10454
10455
10456
10457
10458
10459
10460 <hr>
10461 <h3><a name="633"></a>633. Return clause mentions undefined "type()"</h3>
10462 <p><b>Section:</b> 20.7.16.2.5 [func.wrap.func.targ] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
10463  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-02-03  <b>Last modified:</b> 2007-07-02</p>
10464 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
10465 <p><b>Discussion:</b></p>
10466 <p>
10467 20.7.16.2.5 [func.wrap.func.targ], p4 says:
10468 </p>
10469 <blockquote><p>
10470 <i>Returns:</i> If <tt>type() == typeid(T)</tt>, a pointer to the stored
10471 function target; otherwise a null pointer.
10472 </p></blockquote>
10473
10474 <ol>
10475 <li>
10476 There exists neither a type, a typedef <tt>type</tt>, nor member
10477 function <tt>type()</tt> in class template function nor in the global or
10478 <tt>std</tt> namespace.
10479 </li>
10480 <li>
10481 Assuming that <tt>type</tt> should have been <tt>target_type()</tt>,
10482 this description would lead to false results, if <tt>T = <i>cv</i>
10483 void</tt> due to returns clause 20.7.16.2.5 [func.wrap.func.targ], p1.
10484 </li>
10485 </ol>
10486
10487
10488
10489 <p><b>Proposed resolution:</b></p>
10490 <p>
10491 Change 20.7.16.2.5 [func.wrap.func.targ], p4:
10492 </p>
10493
10494 <blockquote><p>
10495 <i>Returns:</i> If <tt><del>type()</del> <ins>target_type()</ins> == typeid(T) <ins>&amp;&amp; typeid(T) !=
10496 typeid(void)</ins></tt>, a pointer to the stored function target;
10497 otherwise a null pointer.
10498 </p></blockquote>
10499
10500 <p><i>[
10501 Pete: Agreed. It's editorial, so I'll fix it.
10502 ]</i></p>
10503
10504
10505
10506
10507
10508
10509
10510 <hr>
10511 <h3><a name="636"></a>636. 26.5.2.3 valarray::operator[]</h3>
10512 <p><b>Section:</b> 26.6.2.3 [valarray.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
10513  <b>Submitter:</b> Bo Persson <b>Opened:</b> 2007-02-11  <b>Last modified:</b> 2007-07-02</p>
10514 <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>
10515 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
10516 <p><b>Discussion:</b></p>
10517 <p>
10518 The signature of the const operator[] has been changed to return a const
10519 reference.
10520 </p>
10521 <p>
10522 The description in paragraph 1 still says that the operator returns by
10523 value.
10524 </p>
10525 <p><i>[
10526 Pete recommends editorial fix.
10527 ]</i></p>
10528
10529
10530
10531 <p><b>Proposed resolution:</b></p>
10532 <p>
10533 </p>
10534
10535
10536
10537
10538
10539 <hr>
10540 <h3><a name="637"></a>637. [c.math]/10 inconsistent return values</h3>
10541 <p><b>Section:</b> 26.8 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
10542  <b>Submitter:</b> Bo Persson <b>Opened:</b> 2007-02-13  <b>Last modified:</b> 2007-07-26</p>
10543 <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>
10544 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
10545 <p><b>Discussion:</b></p>
10546 <p>
10547 26.8 [c.math], paragraph 10 has long lists of added signatures for float and long double
10548 functions. All the signatures have float/long double return values, which is
10549 inconsistent with some of the double functions they are supposed to
10550 overload.
10551 </p>
10552
10553
10554 <p><b>Proposed resolution:</b></p>
10555 <p>
10556 Change 26.8 [c.math], paragraph 10,
10557 </p>
10558
10559 <blockquote><pre><del>float</del> <ins>int</ins> ilogb(float);
10560 <del>float</del> <ins>long</ins> lrint(float);
10561 <del>float</del> <ins>long</ins> lround(float);
10562 <del>float</del> <ins>long long</ins> llrint(float);
10563 <del>float</del> <ins>long long</ins> llround(float);
10564
10565 <del>long double</del> <ins>int</ins> ilogb(long double);
10566 <del>long double</del> <ins>long</ins> lrint(long double);
10567 <del>long double</del> <ins>long</ins> lround(long double);
10568 <del>long double</del> <ins>long long</ins> llrint(long double);
10569 <del>long double</del> <ins>long long</ins> llround(long double);
10570 </pre></blockquote>
10571
10572
10573
10574
10575
10576 <hr>
10577 <h3><a name="639"></a>639. Still problems with exceptions during streambuf IO</h3>
10578 <p><b>Section:</b> 27.7.1.2.3 [istream::extractors], 27.7.2.6.3 [ostream.inserters] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
10579  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-02-17  <b>Last modified:</b> 2007-10-10</p>
10580 <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>
10581 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
10582 <p><b>Discussion:</b></p>
10583 <p>
10584 There already exist two active DR's for the wording of 27.7.1.2.3 [istream::extractors]/13
10585 from 14882:2003(E), namely <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64">64</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#413">413</a>.
10586 </p>
10587
10588 <p>
10589 Even with these proposed corrections, already maintained in N2134,
10590 I have the feeling, that the current wording does still not properly
10591 handle the "exceptional" situation. The combination of para 14
10592 </p>
10593
10594 <blockquote><p>
10595 "[..] Characters are extracted and inserted until
10596 any of the following occurs:
10597 </p>
10598 <p>
10599 [..]
10600 </p>
10601 <p>
10602 - an exception occurs (in which case the exception is caught)."
10603 </p></blockquote>
10604
10605 <p>
10606 and 15
10607 </p>
10608
10609 <blockquote><p>
10610 "If the function inserts no characters, it calls setstate(failbit),
10611 which
10612 may throw ios_base::failure (27.4.4.3). If it inserted no characters
10613 because it caught an exception thrown while extracting characters
10614 from *this and failbit is on in exceptions() (27.4.4.3), then the
10615 caught
10616 exception is rethrown."
10617 </p></blockquote>
10618
10619 <p>
10620 both in N2134 seems to imply that any exception, which occurs
10621 *after* at least one character has been inserted is caught and lost
10622 for
10623 ever. It seems that even if failbit is on in exceptions() rethrow is
10624 not
10625 allowed due to the wording "If it inserted no characters because it
10626 caught an exception thrown while extracting".
10627 </p>
10628
10629 <p>
10630 Is this behaviour by design?
10631 </p>
10632
10633 <p>
10634 I would like to add that its output counterpart in 27.7.2.6.3 [ostream.inserters]/7-9
10635 (also
10636 N2134) does not demonstrate such an exception-loss-behaviour.
10637 On the other side, I wonder concerning several subtle differences
10638 compared to input::
10639 </p>
10640 <p>
10641 1) Paragraph 8 says at its end:
10642 </p>
10643
10644 <blockquote><p>
10645 "- an exception occurs while getting a character from sb."
10646 </p></blockquote>
10647
10648 <p>
10649 Note that there is nothing mentioned which would imply that such
10650 an exception will be caught compared to 27.7.1.2.3 [istream::extractors]/14.
10651 </p>
10652
10653 <p>
10654 2) Paragraph 9 says:
10655 </p>
10656
10657 <blockquote><p>
10658 "If the function inserts no characters, it calls setstate(failbit)
10659 (which
10660 may throw ios_base::failure (27.4.4.3)). If an exception was thrown
10661 while extracting a character, the function sets failbit in error
10662 state,
10663 and if failbit is on in exceptions() the caught exception is
10664 rethrown."
10665 </p></blockquote>
10666
10667 <p>
10668 The sentence starting with "If an exception was thrown" seems to
10669 imply that such an exception *should* be caught before.
10670 </p>
10671
10672
10673 <p><b>Proposed resolution:</b></p>
10674 <p>
10675 (a) In 27.7.1.2.3 [istream::extractors]/15 (N2134) change the sentence
10676 </p>
10677
10678 <blockquote><p>
10679 If the function inserts no characters, it calls
10680 <tt>setstate(failbit)</tt>, which may throw <tt>ios_base::failure</tt>
10681 (27.4.4.3). If <del>it inserted no characters because it caught an
10682 exception thrown while extracting characters from <tt>*this</tt></del>
10683 <ins>an exception was thrown while extracting a character from
10684 <tt>*this</tt>, the function sets <tt>failbit</tt> in error state,</ins>
10685 and <tt>failbit</tt> is on in <tt>exceptions()</tt> (27.4.4.3), then the
10686 caught exception is rethrown.
10687 </p></blockquote>
10688
10689 <p>
10690 (b) In 27.7.2.6.3 [ostream.inserters]/8 (N2134) change the sentence:
10691 </p>
10692
10693 <blockquote>
10694 <p>
10695 Gets characters from <tt>sb</tt> and inserts them in <tt>*this</tt>.
10696 Characters are read from <tt>sb</tt> and inserted until any of the
10697 following occurs:
10698 </p>
10699 <ul>
10700 <li>end-of-file occurs on the input sequence;</li>
10701 <li>inserting in the output sequence fails (in which case the character to be inserted is not extracted);</li>
10702 <li>an exception occurs while getting a character from <tt>sb</tt> <ins>(in which
10703 case the exception is caught)</ins>.</li>
10704 </ul>
10705 </blockquote>
10706
10707
10708
10709 <p><b>Rationale:</b></p>
10710 This extractor is described as a formatted input function so the
10711 exception behavior is already specified. There is additional behavior
10712 described in this section that applies to the case in which failbit is
10713 set. This doesn't contradict the usual exception behavior for formatted
10714 input functions because that applies to the case in which badbit is set.
10715
10716
10717
10718
10719
10720 <hr>
10721 <h3><a name="641"></a>641. Editorial fix for 27.6.4 (N2134)</h3>
10722 <p><b>Section:</b> 27.7.4 [ext.manip] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
10723  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-02-18  <b>Last modified:</b> 2007-07-02</p>
10724 <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>
10725 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
10726 <p><b>Discussion:</b></p>
10727 <p>
10728 The function <tt>f</tt> in para 4 (27.7.4 [ext.manip]) references an unknown <tt>strm</tt>
10729 in the following line:
10730 </p>
10731
10732 <blockquote><pre>mg.get(Iter(str.rdbuf()), Iter(), intl, strm, err, mon);
10733 </pre></blockquote>
10734
10735
10736 <p><b>Proposed resolution:</b></p>
10737 <p>
10738 Change 27.7.4 [ext.manip], p4:
10739 </p>
10740
10741 <blockquote><pre>mg.get(Iter(str.rdbuf()), Iter(), intl, str<del>m</del>, err, mon);
10742 </pre></blockquote>
10743
10744 <p><i>[
10745 Oxford:  Editorial.
10746 ]</i></p>
10747
10748
10749
10750
10751
10752
10753
10754 <hr>
10755 <h3><a name="642"></a>642. Invalidated fstream footnotes in N2134</h3>
10756 <p><b>Section:</b> 27.9.1.9 [ifstream.members], 27.9.1.13 [ofstream.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
10757  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-02-20  <b>Last modified:</b> 2007-07-02</p>
10758 <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>
10759 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
10760 <p><b>Discussion:</b></p>
10761 <p>
10762 The standard wording of N2134 has extended the 14882:2003(E)
10763 wording for the ifstream/ofstream/fstream open function to fix
10764 a long standing problem, see <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#409">409</a>.
10765 </p>
10766
10767 <p>
10768 Now it's properly written as
10769 </p>
10770
10771 <blockquote><p>
10772 "If that function does not return a null pointer calls clear(),
10773 otherwise
10774 calls setstate(failbit)[..]"
10775 </p></blockquote>
10776
10777 <p>
10778 instead of the previous
10779 </p>
10780
10781 <blockquote><p>
10782 "If that function returns a null pointer, calls setstate(failbit)[..]
10783 </p></blockquote>
10784
10785 <p>
10786 While the old footnotes saying
10787 </p>
10788
10789 <blockquote><p>
10790 "A successful open does not change the error state."
10791 </p></blockquote>
10792
10793 <p>
10794 where correct and important, they are invalid now for ifstream and
10795 ofstream (because clear *does* indeed modify the error state) and
10796 should be removed (Interestingly fstream itself never had these,
10797 although
10798 they where needed for that time).
10799 </p>
10800
10801
10802 <p><b>Proposed resolution:</b></p>
10803 <p>
10804 In 27.9.1.9 [ifstream.members], remove footnote:
10805 </p>
10806
10807 <blockquote><p>
10808 <del><sup>334)</sup> A successful open does not change the error state.</del>
10809 </p></blockquote>
10810
10811 <p>
10812 In 27.9.1.13 [ofstream.members], remove footnote:
10813 </p>
10814
10815 <blockquote><p>
10816 <del><sup>335)</sup> A successful open does not change the error state.</del>
10817 </p></blockquote>
10818
10819
10820
10821
10822
10823
10824 <hr>
10825 <h3><a name="645"></a>645. Missing members in match_results</h3>
10826 <p><b>Section:</b> 28.11 [re.results] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
10827  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-02-26  <b>Last modified:</b> 2008-03-12</p>
10828 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.results">issues</a> in [re.results].</p>
10829 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
10830 <p><b>Discussion:</b></p>
10831 <p>
10832 According to the description given in 28.11 [re.results]/2 the class template
10833 match_results "shall satisfy the requirements of a Sequence, [..],
10834 except that only operations defined for const-qualified Sequences
10835 are supported".
10836 Comparing the provided operations from 28.11 [re.results]/3 with the
10837 sequence/container tables 80 and 81 one recognizes the following
10838 missing operations:
10839 </p>
10840
10841 <p>
10842 1) The members
10843 </p>
10844
10845 <blockquote><pre>const_iterator rbegin() const;
10846 const_iterator rend() const;
10847 </pre></blockquote>
10848
10849 <p>
10850 should exists because 23.1/10 demands these for containers
10851 (all sequences are containers) which support bidirectional
10852 iterators. Aren't these supported by match_result? This is not
10853 explicitely expressed, but it's somewhat implied by two arguments:
10854 </p>
10855 <p>
10856 (a) Several typedefs delegate to
10857 <tt>iterator_traits&lt;BidirectionalIterator&gt;</tt>.
10858 </p>
10859 <p>
10860 (b) The existence of <tt>const_reference operator[](size_type n) const</tt>
10861 implies even random-access iteration.
10862 I also suggest, that <tt>match_result</tt> should explicitly mention,
10863 which minimum iterator category is supported and if this does
10864 not include random-access the existence of <tt>operator[]</tt> is
10865 somewhat questionable.
10866 </p>
10867 <p>
10868 2) The new "convenience" members
10869 </p>
10870 <blockquote><pre>const_iterator cbegin() const;
10871 const_iterator cend() const;
10872 const_iterator crbegin() const;
10873 const_iterator crend() const;
10874 </pre></blockquote>
10875 <p>
10876 should be added according to tables 80/81.
10877 </p>
10878
10879
10880 <p><b>Proposed resolution:</b></p>
10881 <p>
10882 Add the following members to the <tt>match_results</tt> synopsis after <tt>end()</tt> in 28.11 [re.results]
10883 para 3:
10884 </p>
10885
10886 <blockquote><pre>const_iterator cbegin() const;
10887 const_iterator cend() const;
10888 </pre></blockquote>
10889
10890 <p>
10891 In section 28.11.3 [re.results.acc] change:
10892 </p>
10893
10894 <blockquote>
10895 <pre>const_iterator begin() const;
10896 <ins>const_iterator cbegin() const;</ins>
10897 </pre>
10898 <blockquote>
10899 <p>
10900 -7- <i>Returns:</i> A starting iterator that enumerates over all the sub-expressions stored in <tt>*this</tt>.
10901 </p>
10902 </blockquote>
10903
10904 <pre>const_iterator end() const;
10905 <ins>const_iterator cend() const;</ins>
10906 </pre>
10907 <blockquote>
10908 <p>
10909 -8- <i>Returns:</i> A terminating iterator that enumerates over all the sub-expressions stored in <tt>*this</tt>.
10910 </p>
10911 </blockquote>
10912 </blockquote>
10913
10914
10915
10916 <p><i>[
10917 Kona (2007): Voted to adopt proposed wording in
10918 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2409.pdf">N2409</a>
10919 except removing the entry in the table container requirements.  Moved to Review.
10920 ]</i></p>
10921
10922
10923 <p><i>[
10924 Bellevue:  Proposed wording now in the WP.
10925 ]</i></p>
10926
10927
10928
10929
10930
10931 <hr>
10932 <h3><a name="647"></a>647. Inconsistent regex_search params</h3>
10933 <p><b>Section:</b> 28.12.3 [re.alg.search] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
10934  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-02-26  <b>Last modified:</b> 2007-07-26</p>
10935 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
10936 <p><b>Discussion:</b></p>
10937 <p>
10938 28.12.3 [re.alg.search]/5 declares
10939 </p>
10940
10941 <blockquote><pre>template &lt;class iterator, class charT, class traits&gt;
10942 bool regex_search(iterator first, iterator last,
10943                   const basic_regex&lt;charT, traits&gt;&amp; e,
10944                   regex_constants::match_flag_type flags =
10945                       regex_constants::match_default);
10946 </pre></blockquote>
10947
10948 <p>
10949 where it's not explained, which iterator category
10950 the parameter iterator belongs to. This is inconsistent
10951 to the preceding declaration in the synopsis section
10952 28.5 [re.syn], which says:
10953 </p>
10954
10955 <blockquote><pre>template &lt;class BidirectionalIterator, class charT, class traits&gt;
10956 bool regex_search(BidirectionalIterator first, BidirectionalIterator last,
10957                   const basic_regex&lt;charT, traits&gt;&amp; e,
10958                   regex_constants::match_flag_type flags =
10959                       regex_constants::match_default);
10960 </pre></blockquote>
10961
10962
10963 <p><b>Proposed resolution:</b></p>
10964 <p>
10965 In 28.12.3 [re.alg.search]/5 replace all three occurences of param "iterator" with
10966 "BidirectionalIterator"
10967 </p>
10968
10969 <blockquote><pre>template &lt;class <del>iterator</del> <ins>BidirectionalIterator</ins>, class charT, class traits&gt;
10970   bool regex_search(<del>iterator</del> <ins>BidirectionalIterator</ins> first, <del>iterator</del> <ins>BidirectionalIterator</ins> last,
10971                     const basic_regex&lt;charT, traits&gt;&amp; e,
10972                     regex_constants::match_flag_type flags =
10973                       regex_constants::match_default);
10974 </pre>
10975 <p>
10976 -6- <i>Effects:</i> Behaves "as if" by constructing an object what of
10977 type <tt>match_results&lt;<del>iterator</del>
10978 <ins>BidirectionalIterator</ins>&gt;</tt> and then returning the result
10979 of <tt>regex_search(first, last, what, e, flags)</tt>.
10980 </p>
10981 </blockquote>
10982
10983
10984 <p><b>Rationale:</b></p>
10985 Applied to working paper while issue was still in New status.
10986
10987
10988
10989
10990
10991 <hr>
10992 <h3><a name="648"></a>648. regex_iterator c'tor needs clarification/editorial fix</h3>
10993 <p><b>Section:</b> 28.13.1.1 [re.regiter.cnstr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
10994  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-03-03  <b>Last modified:</b> 2007-07-02</p>
10995 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
10996 <p><b>Discussion:</b></p>
10997 <p>
10998 In 28.13.1.1 [re.regiter.cnstr]/2 the effects paragraph starts with:
10999 </p>
11000
11001 <blockquote>
11002 <p>
11003 <i>Effects:</i> Initializes begin and end to point to the beginning and the
11004 end of the target sequence, sets pregex to &amp;re, sets flags to f,[..]
11005 </p></blockquote>
11006
11007 <p>
11008 There are two issues with this description:
11009 </p>
11010
11011 <ol>
11012 <li>
11013 The meaning of very first part of this quote is unclear, because
11014 there is no target sequence provided, instead there are given two
11015 parameters a and b, both of type BidirectionalIterator. The mentioned
11016 part does not explain what a and b represent.
11017 </li>
11018 <li>
11019 There does not exist any parameter f, but instead a parameter
11020 m in the constructor declaration, so this is actually an editorial
11021 fix.
11022 </li>
11023 </ol>
11024
11025
11026 <p><b>Proposed resolution:</b></p>
11027 <p>
11028 In 28.13.1.1 [re.regiter.cnstr]/2 change the above quoted part by
11029 </p>
11030
11031 <blockquote><p>
11032 <i>Effects:</i> Initializes <tt>begin</tt> and <tt>end</tt> to point to
11033 the beginning and the end of the target sequence <ins>designated by the
11034 iterator range <tt>[a, b)</tt></ins>, sets <tt>pregex</tt> to
11035 <tt>&amp;re</tt>, sets <tt>flags</tt> to <tt><del>f</del>
11036 <ins>m</ins></tt>, then calls <tt>regex_search(begin, end, match,
11037 *pregex, flags)</tt>. If this call returns <tt>false</tt> the
11038 constructor sets <tt>*this</tt> to the end-of-sequence iterator.
11039 </p></blockquote>
11040
11041
11042
11043
11044
11045 <hr>
11046 <h3><a name="649"></a>649. Several typos in regex_token_iterator constructors</h3>
11047 <p><b>Section:</b> 28.13.2.1 [re.tokiter.cnstr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
11048  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-03-03  <b>Last modified:</b> 2007-07-02</p>
11049 <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>
11050 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
11051 <p><b>Discussion:</b></p>
11052 <p>
11053 In 28.13.2.1 [re.tokiter.cnstr]/1+2 both the constructor declaration
11054 and the following text shows some obvious typos:
11055 </p>
11056 <p>
11057 1) The third constructor form is written as
11058 </p>
11059 <blockquote><pre>template &lt;std::size_t N&gt;
11060   regex_token_iterator(BidirectionalIterator a, BidirectionalIterator b,
11061                        const regex_type&amp; re,
11062                        const int (&amp;submatches)[R],
11063                        regex_constants::match_flag_type m =
11064                          regex_constants::match_default);
11065 </pre></blockquote>
11066
11067 <p>
11068 where the dimensions of submatches are specified by an
11069 unknown value R, which should be N.
11070 </p>
11071 <p>
11072 2) Paragraph 2 of the same section says in its last sentence:
11073 </p>
11074
11075 <blockquote><p>
11076 The third constructor initializes the member <tt>subs</tt> to hold a
11077 copy of the sequence of integer values pointed to by the iterator range
11078 <tt>[&amp;submatches, &amp;submatches + R)</tt>.
11079 </p></blockquote>
11080
11081 <p>
11082 where again R must be replaced by N.
11083 </p>
11084
11085 <p>
11086 3) Paragraph 3 of the same section says in its first sentence:
11087 </p>
11088
11089 <blockquote><p>
11090 Each constructor then sets <tt>N</tt> to <tt>0</tt>, and
11091 <tt>position</tt> to <tt>position_iterator(a, b, re, f)</tt>.
11092 </p></blockquote>
11093
11094 <p>
11095 where a non-existing parameter "f" is mentioned, which must be
11096 replaced
11097 by the parameter "m".
11098 </p>
11099
11100
11101 <p><b>Proposed resolution:</b></p>
11102 <p>
11103 Change 28.13.2.1 [re.tokiter.cnstr]/1:
11104 </p>
11105 <blockquote><pre>template &lt;std::size_t N&gt;
11106   regex_token_iterator(BidirectionalIterator a, BidirectionalIterator b,
11107                        const regex_type&amp; re,
11108                        const int (&amp;submatches)[<del>R</del> <ins>N</ins>],
11109                        regex_constants::match_flag_type m =
11110                          regex_constants::match_default);
11111 </pre></blockquote>
11112
11113 <p>
11114 Change 28.13.2.1 [re.tokiter.cnstr]/2:
11115 </p>
11116
11117 <blockquote><p>
11118 <i>Effects:</i> The first constructor initializes the member
11119 <tt>subs</tt> to hold the single value <tt>submatch</tt>. The second
11120 constructor initializes the member <tt>subs</tt> to hold a copy of the
11121 argument <tt>submatches</tt>. The third constructor initializes the
11122 member <tt>subs</tt> to hold a copy of the sequence of integer values
11123 pointed to by the iterator range <tt>[&amp;submatches, &amp;submatches +
11124 <del>R</del> <ins>N</ins>)</tt>.
11125 </p></blockquote>
11126
11127 <p>
11128 Change 28.13.2.1 [re.tokiter.cnstr]/3:
11129 </p>
11130
11131 <blockquote><p>
11132 Each constructor then sets <tt>N</tt> to <tt>0</tt>, and
11133 <tt>position</tt> to <tt>position_iterator(a, b, re, <del>f</del>
11134 <ins>m</ins>)</tt>. If <tt>position</tt> is not an end-of-sequence
11135 iterator the constructor sets <tt>result</tt> to the address of the
11136 current match. Otherwise if any of the values stored in <tt>subs</tt> is
11137 equal to <tt>-1</tt> the constructor sets <tt>*this</tt> to a suffix
11138 iterator that points to the range <tt>[a, b)</tt>, otherwise the
11139 constructor sets <tt>*this</tt> to an end-of-sequence iterator.
11140 </p></blockquote>
11141
11142
11143
11144
11145
11146
11147 <hr>
11148 <h3><a name="653"></a>653. Library reserved names</h3>
11149 <p><b>Section:</b> 1.2 [intro.refs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
11150  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2007-03-08  <b>Last modified:</b> 2008-02-25</p>
11151 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#intro.refs">issues</a> in [intro.refs].</p>
11152 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
11153 <p><b>Discussion:</b></p>
11154 <p>
11155 </p>
11156 <blockquote>
11157 <p>
11158 1.2 [intro.refs] Normative references
11159 </p>
11160
11161 <p>
11162 The following standards contain provisions which, through reference in
11163 this text, constitute provisions of this Interna- tional Standard. At
11164 the time of publication, the editions indicated were valid. All
11165 standards are subject to revision, and parties to agreements based on
11166 this International Standard are encouraged to investigate the
11167 possibility of applying the most recent editions of the standards
11168 indicated below. Members of IEC and ISO maintain registers of currently
11169 valid International Standards.
11170 </p>
11171
11172 <ul>
11173 <li>Ecma International, ECMAScript Language Specification, Standard
11174 Ecma-262, third edition, 1999.</li>
11175 <li>ISO/IEC 2382 (all parts), Information technology - Vocabulary</li>
11176 <li>ISO/IEC 9899:1990, Programming languages - C</li>
11177 <li>ISO/IEC 9899/Amd.1:1995, Programming languages - C, AMENDMENT 1: C
11178 Integrity</li>
11179 <li>ISO/IEC 9899:1999, Programming languages - C</li>
11180 <li>ISO/IEC 9899:1999/Cor.1:2001 Programming languages - C</li>
11181 <li>ISO/IEC 9899:1999/Cor.2:2004 Programming languages - C</li>
11182 <li>ISO/IEC 9945:2003, Information Technology-Portable Operating System
11183 Interface (POSIX)</li>
11184 <li>ISO/IEC 10646-1:1993 Information technology - Universal Multiple-Octet
11185 Coded Character Set (UCS) - Part 1: Architecture and Basic Multilingual
11186 Plane</li>
11187 </ul>
11188 </blockquote>
11189
11190 <p>
11191 I'm not sure how many of those reserve naming patterns that might affect
11192 us, but I am equally sure I don't own a copy of any of these to check!
11193 </p>
11194 <p>
11195 The point is to list the reserved naming patterns, rather than the
11196 individual names themselves - although we may want to list C keywords
11197 that are valid identifiers in C++ but likely to cause trouble in shared
11198 headers (e.g. restrict)
11199 </p>
11200
11201 <p><i>[
11202 Kona (2007): Recommend NAD.  No one has identified a specific defect, just the possibility of one.
11203 ]</i></p>
11204
11205
11206 <p><i>[
11207 Post-Kona: Alisdair request Open. A good example of the problem was a
11208 discussion of the system error proposal, where it was pointed out an all-caps
11209 identifier starting with a capital E conflicted with reserved macro names for
11210 both Posix and C.  I had absolutely no idea of this rule, and suspect I was
11211 not the only one in the room.<br>
11212 <br>
11213 Resolution will require someone with access to all the listed documents to
11214 research their respective name reservation rules, or people with access to
11215 specific documents add their rules to this issue until the list is complete.
11216 ]</i></p>
11217
11218
11219 <p><i>[
11220 Bellevue: Wording is aleady present in various standards, and no-one has come forward with wording.
11221 Suggest a formal paper rather than a defect report is the correct way to proceed.
11222 ]</i></p>
11223
11224
11225
11226
11227 <p><b>Proposed resolution:</b></p>
11228
11229
11230
11231
11232
11233 <hr>
11234 <h3><a name="656"></a>656. Typo in subtract_with_carry_engine declaration</h3>
11235 <p><b>Section:</b> 26.5.1 [rand.synopsis] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
11236  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-03-08  <b>Last modified:</b> 2007-07-02</p>
11237 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.synopsis">issues</a> in [rand.synopsis].</p>
11238 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
11239 <p><b>Discussion:</b></p>
11240 <p>
11241 26.5.1 [rand.synopsis] the header <tt>&lt;random&gt;</tt> synopsis
11242 contains an unreasonable closing curly brace inside the
11243 <tt>subtract_with_carry_engine</tt> declaration.
11244 </p>
11245
11246
11247 <p><b>Proposed resolution:</b></p>
11248 <p>
11249 Change the current declaration in 26.5.1 [rand.synopsis]
11250 </p>
11251
11252 <blockquote><pre>template &lt;class UIntType, size_t w<del>}</del>, size_t s, size_t r&gt;
11253 class subtract_with_carry_engine;
11254 </pre></blockquote>
11255
11256
11257 <p><i>[
11258 Pete: Recommends editorial.
11259 ]</i></p>
11260
11261
11262
11263
11264
11265 <hr>
11266 <h3><a name="657"></a>657. unclear requirement about header inclusion</h3>
11267 <p><b>Section:</b> 17.6.2.2 [using.headers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
11268  <b>Submitter:</b> Gennaro Prota <b>Opened:</b> 2007-03-14  <b>Last modified:</b> 2007-10-10</p>
11269 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
11270 <p><b>Discussion:</b></p>
11271 <p>
11272 17.6.2.2 [using.headers] states:
11273 </p>
11274
11275 <blockquote><p>
11276 A translation unit shall include a header only outside of any
11277 external declaration or definition, [...]
11278 </p></blockquote>
11279
11280 <p>
11281 I see three problems with this requirement:
11282 </p>
11283
11284 <ol type="a">
11285 <li><p>The C++ standard doesn't define what an "external declaration" or
11286 an "external definition" are (incidentally the C99 standard does, and
11287 has a sentence very similar to the above regarding header inclusion).
11288 </p><p>
11289 I think the intent is that the #include directive shall lexically
11290 appear outside *any* declaration; instead, when the issue was pointed
11291 out on comp.std.c++ at least one poster interpreted "external
11292 declaration" as "declaration of an identifier with external linkage".
11293 If this were the correct interpretation, then the two inclusions below
11294 would be legal:
11295 </p>
11296 <blockquote><pre>  // at global scope
11297   static void f()
11298   {
11299 # include &lt;cstddef&gt;
11300   }
11301
11302   static void g()
11303   {
11304 # include &lt;stddef.h&gt;
11305   }
11306 </pre></blockquote>
11307 <p>
11308 (note that while the first example is unlikely to compile correctly,
11309 the second one may well do)
11310 </p></li>
11311
11312 <li><p>as the sentence stands, violations will require a diagnostic; is
11313 this the intent? It was pointed out on comp.std.c++ (by several
11314 posters) that at least one way to ensure a diagnostic exists:
11315 </p>
11316 <blockquote><p>
11317    [If there is an actual file for each header,] one simple way
11318    to implement this would be to insert a reserved identifier
11319    such as __begin_header  at the start of each standard header.
11320    This reserved identifier would be ignored for all other
11321    purposes, except that, at the appropriate point in phase 7, if
11322    it is found inside an external definition, a diagnostic is
11323    generated. There's many other similar ways to achieve the same
11324    effect.
11325    </p>
11326 <p>                                 --James Kuyper, on comp.std.c++
11327 </p></blockquote></li>
11328
11329 <li><p>is the term "header" meant to be limited to standard headers?
11330 Clause 17 is all about the library, but still the general question is
11331 interesting and affects one of the points in the explicit namespaces
11332 proposal (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1691.html">n1691</a>):
11333 </p>
11334 <blockquote><p>
11335     Those seeking to conveniently enable argument-dependent
11336     lookups for all operators within an explicit namespace
11337     could easily create a header file that does so:
11338 </p><pre>    namespace mymath::
11339     {
11340         #include "using_ops.hpp"
11341     }
11342 </pre></blockquote>
11343 </li>
11344 </ol>
11345
11346
11347 <p><b>Proposed resolution:</b></p>
11348 <p>
11349 </p>
11350
11351
11352 <p><b>Rationale:</b></p>
11353 We believe that the existing language does not cause any real confusion
11354 and any new formulation of the rules that we could come up with are
11355 unlikely to be better than what's already in the standard.
11356
11357
11358
11359
11360
11361 <hr>
11362 <h3><a name="658"></a>658. Two unspecified function comparators in [function.objects]</h3>
11363 <p><b>Section:</b> 20.7 [function.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
11364  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-03-19  <b>Last modified:</b> 2007-08-05</p>
11365 <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>
11366 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
11367 <p><b>Discussion:</b></p>
11368 <p>
11369 The header <tt>&lt;functional&gt;</tt> synopsis in 20.7 [function.objects]
11370 contains the following two free comparison operator templates
11371 for the <tt>function</tt> class template
11372 </p>
11373
11374 <blockquote><pre>template&lt;class Function1, class Function2&gt;
11375 void operator==(const function&lt;Function1&gt;&amp;, const function&lt;Function2&gt;&amp;);
11376 template&lt;class Function1, class Function2&gt;
11377 void operator!=(const function&lt;Function1&gt;&amp;, const function&lt;Function2&gt;&amp;);
11378 </pre></blockquote>
11379
11380 <p>
11381 which are nowhere described. I assume that they are relicts before the
11382 corresponding two private and undefined member templates in the function
11383 template (see 20.7.16.2 [func.wrap.func] and  [func.wrap.func.undef]) have been introduced. The original free
11384 function templates should be removed, because using an undefined entity
11385 would lead to an ODR violation of the user.
11386 </p>
11387
11388
11389 <p><b>Proposed resolution:</b></p>
11390 <p>
11391 Remove the above mentioned two function templates from
11392 the header <tt>&lt;functional&gt;</tt> synopsis (20.7 [function.objects])
11393 </p>
11394
11395 <blockquote><pre><del>template&lt;class Function1, class Function2&gt;
11396 void operator==(const function&lt;Function1&gt;&amp;, const function&lt;Function2&gt;&amp;);
11397 template&lt;class Function1, class Function2&gt;
11398 void operator!=(const function&lt;Function1&gt;&amp;, const function&lt;Function2&gt;&amp;);</del>
11399 </pre></blockquote>
11400
11401
11402
11403 <p><b>Rationale:</b></p>
11404 Fixed by
11405 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2292.html">N2292</a>
11406 Standard Library Applications for Deleted Functions.
11407
11408
11409
11410
11411
11412 <hr>
11413 <h3><a name="662"></a>662. Inconsistent handling of incorrectly-placed thousands separators</h3>
11414 <p><b>Section:</b> 22.4.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
11415  <b>Submitter:</b> Cosmin Truta <b>Opened:</b> 2007-04-05  <b>Last modified:</b> 2007-07-25</p>
11416 <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>
11417 <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>
11418 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
11419 <p><b>Discussion:</b></p>
11420 <p>
11421 From Section 22.4.2.1.2 [facet.num.get.virtuals], paragraphs 11 and 12, it is implied
11422 that the value read from a stream must be stored
11423 even if the placement of thousands separators does not conform to the
11424 <code>grouping()</code> specification from the <code>numpunct</code> facet.
11425 Since incorrectly-placed thousands separators are flagged as an extraction
11426 failure (by the means of <code>failbit</code>), we believe it is better not
11427 to store the value. A consistent strategy, in which any kind of extraction
11428 failure leaves the input item intact, is conceptually cleaner, is able to avoid
11429 corner-case traps, and is also more understandable from the programmer's point
11430 of view.
11431 </p>
11432 <p>
11433 Here is a quote from <i>"The C++ Programming Language (Special Edition)"</i>
11434 by B.&nbsp;Stroustrup (Section&nbsp;D.4.2.3, pg.&nbsp;897):
11435 </p>
11436 <blockquote><p>
11437 <i>"If a value of the desired type could not be read, failbit is set in r.
11438 [...] An input operator will use r to determine how to set the state of its
11439 stream. If no error was encountered, the value read is assigned through v;
11440 otherwise, v is left unchanged."</i>
11441 </p></blockquote>
11442 <p>
11443 This statement implies that <code>rdstate()</code> alone is sufficient to
11444 determine whether an extracted value is to be assigned to the input item
11445 <i>val</i> passed to <code>do_get</code>. However, this is in disagreement
11446 with the current C++ Standard. The above-mentioned assumption is true in all
11447 cases, except when there are mismatches in digit grouping. In the latter case,
11448 the parsed value is assigned to <i>val</i>, and, at the same time, <i>err</i>
11449 is assigned to <code>ios_base::failbit</code> (essentially "lying" about the
11450 success of the operation). Is this intentional? The current behavior raises
11451 both consistency and usability concerns.
11452 </p>
11453 <p>
11454 Although digit grouping is outside the scope of <code>scanf</code> (on which
11455 the virtual methods of <code>num_get</code> are based), handling of grouping
11456 should be consistent with the overall behavior of scanf. The specification of
11457 <code>scanf</code> makes a distinction between input failures and matching
11458 failures, and yet both kinds of failures have no effect on the input items
11459 passed to <code>scanf</code>. A mismatch in digit grouping logically falls in
11460 the category of matching failures, and it would be more consistent, and less
11461 surprising to the user, to leave the input item intact whenever a failure is
11462 being signaled.
11463 </p>
11464 <p>
11465 The extraction of <code>bool</code> is another example outside the scope of
11466 <code>scanf</code>, and yet consistent, even in the event of a successful
11467 extraction of a <code>long</code> but a failed conversion from
11468 <code>long</code> to <code>bool</code>.
11469 </p>
11470 <p>
11471 Inconsistency is further aggravated by the fact that, when failbit is set,
11472 subsequent extraction operations are no-ops until <code>failbit</code> is
11473 explicitly cleared. Assuming that there is no explicit handling of
11474 <code>rdstate()</code> (as in <code>cin&gt;&gt;i&gt;&gt;j</code>) it is
11475 counter-intuitive to be able to extract an integer with mismatched digit
11476 grouping, but to be unable to extract another, properly-formatted integer
11477 that immediately follows.
11478 </p>
11479 <p>
11480 Moreover, setting <code>failbit</code>, and selectively assigning a value to
11481 the input item, raises usability problems. Either the strategy of
11482 <code>scanf</code> (when there is no extracted value in case of failure), or
11483 the strategy of the <code>strtol</code> family (when there is always an
11484 extracted value, and there are well-defined defaults in case of a failure) are
11485 easy to understand and easy to use. On the other hand, if <code>failbit</code>
11486 alone cannot consistently make a difference between a failed extraction, and a
11487 successful but not-quite-correct extraction whose output happens to be the same
11488 as the previous value, the programmer must resort to implementation tricks.
11489 Consider the following example:
11490 </p>
11491 <pre>    int i = old_i;
11492     cin &gt;&gt; i;
11493     if (cin.fail())
11494         // can the value of i be trusted?
11495         // what does it mean if i == old_i?
11496         // ...
11497 </pre>
11498 <p>
11499 Last but not least, the current behvaior is not only confusing to the casual
11500 reader, but it has also been confusing to some book authors. Besides
11501 Stroustrup's book, other books (e.g. "Standard C++ IOStreams and Locales" by
11502 Langer and Kreft) are describing the same mistaken assumption. Although books
11503 are not to be used instead of the standard reference, the readers of these
11504 books, as well as the people who are generally familiar to <code>scanf</code>,
11505 are even more likely to misinterpret the standard, and expect the input items
11506 to remain intact when a failure occurs.
11507 </p>
11508
11509
11510 <p><b>Proposed resolution:</b></p>
11511
11512 <p>
11513 Change 22.4.2.1.2 [facet.num.get.virtuals]:
11514 </p>
11515
11516 <blockquote>
11517 <p>
11518 <b>Stage 3:</b> The result of stage 2 processing can be one of
11519 </p>
11520 <ul>
11521 <li>A sequence of <code>chars</code> has been accumulated in stage 2 that is converted (according to the rules of <code>scanf</code>) to a value of the type of <code><i>val</i></code>.  <del>This value is stored in <code><i>val</i></code> and <code>ios_base::goodbit</code> is stored in <code><i>err</i></code>.</del></li>
11522
11523 <li>The sequence of <code>chars</code> accumulated in stage 2 would have caused <code>scanf</code> to report an input failure. <code>ios_base::failbit</code> is assigned to <code><i>err</i></code>.</li>
11524 </ul>
11525 <p>
11526 <ins>In the first case,</ins> <del>D</del><ins>d</ins>igit grouping is checked.  That is, the positions of discarded separators is examined for consistency with <code>use_facet&lt;numpunct&lt;charT&gt; &gt;(<i>loc</i>).grouping()</code>.  If they are not consistent then <code>ios_base::failbit</code> is assigned to <code><i>err</i></code>.  <ins>Otherwise, the value that was converted in stage 2 is stored in <code><i>val</i></code> and <code>ios_base::goodbit</code> is stored in <code><i>err</i></code>.</ins>
11527 </p>
11528 </blockquote>
11529
11530
11531 <p><b>Rationale:</b></p>
11532 post-Toronto: Changed from New to NAD at the request of the author.  The preferred solution of
11533 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2327.pdf">N2327</a>
11534 makes this resolution obsolete.
11535
11536
11537
11538
11539
11540 <hr>
11541 <h3><a name="663"></a>663. Complexity Requirements</h3>
11542 <p><b>Section:</b> 17.5.1.4 [structure.specifications] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
11543  <b>Submitter:</b> Thomas Plum <b>Opened:</b> 2007-04-16  <b>Last modified:</b> 2009-05-01</p>
11544 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#structure.specifications">active issues</a> in [structure.specifications].</p>
11545 <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>
11546 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
11547 <p><b>Discussion:</b></p>
11548 <p>
11549 17.5.1.4 [structure.specifications] para 5 says
11550 </p>
11551
11552 <blockquote><p>
11553 -5- Complexity requirements specified in the library
11554 clauses are upper bounds, and implementations that provide better
11555 complexity guarantees satisfy the requirements.
11556 </p></blockquote>
11557
11558 <p>
11559 The following
11560 objection has been raised:
11561 </p>
11562
11563 <blockquote><p>
11564 The library clauses suggest general
11565 guidelines regarding complexity, but we have been unable to discover
11566 any absolute hard-and-fast formulae for these requirements. Unless
11567 or until the Library group standardizes specific hard-and-fast
11568 formulae, we regard all the complexity requirements as subject to a
11569 "fudge factor" without any intrinsic upper bound.
11570 </p></blockquote>
11571
11572 <p>
11573 [Plum ref
11574 _23213Y31 etc]
11575 </p>
11576
11577
11578 <p><b>Proposed resolution:</b></p>
11579 <p>
11580 </p>
11581
11582
11583 <p><b>Rationale:</b></p>
11584 Kona (2007): No specific instances of underspecification have been
11585 identified, and big-O notation always involves constant factors.
11586
11587
11588
11589
11590
11591 <hr>
11592 <h3><a name="670"></a>670. <tt>money_base::pattern</tt> and <tt>space</tt></h3>
11593 <p><b>Section:</b> 22.4.6.3 [locale.moneypunct] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
11594  <b>Submitter:</b> Thomas Plum <b>Opened:</b> 2007-04-16  <b>Last modified:</b> 2008-09-22</p>
11595 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
11596 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#836">836</a></p>
11597 <p><b>Discussion:</b></p>
11598 <p>
11599 22.4.6.3 [locale.moneypunct], para 2 says:
11600 </p>
11601
11602 <blockquote><p>
11603 The value <tt>space</tt> indicates that at least one space is required at
11604 that position.
11605 </p></blockquote>
11606
11607 <p>
11608 The following objection has been raised:
11609 </p>
11610
11611 <blockquote><p>
11612 Whitespace is optional when matching space. (See 22.4.6.1.2 [locale.money.get.virtuals], para 2.)
11613 </p></blockquote>
11614
11615 <p>
11616 [Plum ref _22263Y22]
11617 </p>
11618
11619 <p><i>[
11620 Kona (2007): Bill to provide proposed wording. We agree that C++03 is
11621 ambiguous, and that we want C++0X to say "space" means 0 or more
11622 whitespace characters on input.
11623 ]</i></p>
11624
11625
11626
11627
11628 <p><b>Proposed resolution:</b></p>
11629
11630
11631
11632
11633
11634 <hr>
11635 <h3><a name="676"></a>676. Moving the unordered containers</h3>
11636 <p><b>Section:</b> 23.5 [unord] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
11637  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2007-05-05  <b>Last modified:</b> 2008-09-26</p>
11638 <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>
11639 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
11640 <p><b>Discussion:</b></p>
11641 <p>
11642 Move semantics are missing from the <tt>unordered</tt> containers.  The proposed
11643 resolution below adds move-support consistent with
11644 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1858.html">N1858</a>
11645 and the current working draft.
11646 </p>
11647
11648 <p>
11649 The current proposed resolution simply lists the requirements for each function.
11650 These might better be hoisted into the requirements table for unordered associative containers.
11651 Futhermore a mild reorganization of the container requirements could well be in order.
11652 This defect report is purposefully ignoring these larger issues and just focusing
11653 on getting the unordered containers "moved".
11654 </p>
11655
11656
11657
11658 <p><b>Proposed resolution:</b></p>
11659
11660 <p>
11661 Add to 23.5 [unord]:
11662 </p>
11663
11664 <blockquote><pre>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
11665   void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
11666             unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
11667
11668 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
11669   void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
11670             unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
11671
11672 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
11673   void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
11674             unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
11675
11676 template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
11677   void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
11678             unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
11679
11680 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
11681   void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
11682             unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
11683
11684 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
11685   void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
11686             unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
11687
11688 ...
11689
11690 template &lt;class Value, class Hash, class Pred, class Alloc&gt;
11691   void swap(unordered_set&lt;Value, Hash, Pred, Alloc&gt;&amp; x,
11692             unordered_set&lt;Value, Hash, Pred, Alloc&gt;&amp; y);
11693
11694 <ins>template &lt;class Value, class Hash, class Pred, class Alloc&gt;
11695   void swap(unordered_set&lt;Value, Hash, Pred, Alloc&gt;&amp; x,
11696             unordered_set&lt;Value, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
11697
11698 <ins>template &lt;class Value, class Hash, class Pred, class Alloc&gt;
11699   void swap(unordered_set&lt;Value, Hash, Pred, Alloc&gt;&amp;&amp; x,
11700             unordered_set&lt;Value, Hash, Pred, Alloc&gt;&amp; y);</ins>
11701
11702 template &lt;class Value, class Hash, class Pred, class Alloc&gt;
11703   void swap(unordered_multiset&lt;Value, Hash, Pred, Alloc&gt;&amp; x,
11704             unordered_multiset&lt;Value, Hash, Pred, Alloc&gt;&amp; y);
11705
11706 <ins>template &lt;class Value, class Hash, class Pred, class Alloc&gt;
11707   void swap(unordered_multiset&lt;Value, Hash, Pred, Alloc&gt;&amp; x,
11708             unordered_multiset&lt;Value, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
11709
11710 <ins>template &lt;class Value, class Hash, class Pred, class Alloc&gt;
11711   void swap(unordered_multiset&lt;Value, Hash, Pred, Alloc&gt;&amp;&amp; x,
11712             unordered_multiset&lt;Value, Hash, Pred, Alloc&gt;&amp; y);</ins>
11713 </pre></blockquote>
11714
11715 <p><b><tt>unordered_map</tt></b></p>
11716
11717 <p>
11718 Change 23.5.1 [unord.map]:
11719 </p>
11720
11721 <blockquote><pre>class unordered_map
11722 {
11723     ...
11724     unordered_map(const unordered_map&amp;);
11725     <ins>unordered_map(unordered_map&amp;&amp;);</ins>
11726     ~unordered_map();
11727     unordered_map&amp; operator=(const unordered_map&amp;);
11728     <ins>unordered_map&amp; operator=(unordered_map&amp;&amp;);</ins>
11729     ...
11730     // modifiers
11731     <del>std::</del>pair&lt;iterator, bool&gt; insert(const value_type&amp; obj);
11732     <ins>template &lt;class P&gt; pair&lt;iterator, bool&gt; insert(P&amp;&amp; obj);</ins>
11733     iterator       insert(iterator hint, const value_type&amp; obj);
11734     <ins>template &lt;class P&gt; iterator       insert(iterator hint, P&amp;&amp; obj);</ins>
11735     const_iterator insert(const_iterator hint, const value_type&amp; obj);
11736     <ins>template &lt;class P&gt; const_iterator insert(const_iterator hint, P&amp;&amp; obj);</ins>
11737     ...
11738     void swap(unordered_map&amp;<ins>&amp;</ins>);
11739     ...
11740     mapped_type&amp; operator[](const key_type&amp; k);
11741     <ins>mapped_type&amp; operator[](key_type&amp;&amp; k);</ins>
11742     ...
11743 };
11744
11745 template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
11746   void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
11747             unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
11748
11749 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
11750   void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
11751             unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
11752
11753 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
11754   void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
11755             unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
11756 </pre></blockquote>
11757
11758 <p>
11759 Add to 23.5.1.1 [unord.map.cnstr]:
11760 </p>
11761
11762 <blockquote>
11763 <pre>template &lt;class InputIterator&gt;
11764   unordered_map(InputIterator f, InputIterator l,
11765                 size_type n = <i>implementation-defined</i>,
11766                 const hasher&amp; hf = hasher(),
11767                 const key_equal&amp; eql = key_equal(),
11768                 const allocator_type&amp; a = allocator_type());
11769 </pre>
11770
11771 <blockquote><p>
11772 <ins>
11773 <i>Requires:</i> If the iterator's dereference operator returns an
11774 lvalue or a const rvalue <tt>pair&lt;key_type, mapped_type&gt;</tt>,
11775 then both <tt>key_type</tt> and <tt>mapped_type</tt> shall be
11776 <tt>CopyConstructible</tt>.
11777 </ins>
11778 </p></blockquote>
11779 </blockquote>
11780
11781 <p>
11782 Add to 23.5.1.2 [unord.map.elem]:
11783 </p>
11784
11785 <blockquote>
11786
11787 <pre>mapped_type&amp; operator[](const key_type&amp; k);</pre>
11788
11789 <blockquote>
11790 <p>...</p>
11791 <p><ins>
11792 <i>Requires:</i> <tt>key_type</tt> shall be <tt>CopyConstructible</tt>
11793 and <tt>mapped_type</tt> shall be <tt>DefaultConstructible</tt>.
11794 </ins></p>
11795 </blockquote>
11796
11797 <pre><ins>mapped_type&amp; operator[](key_type&amp;&amp; k);</ins></pre>
11798
11799 <blockquote>
11800 <p><ins>
11801 <i>Effects:</i> If the <tt>unordered_map</tt> does not already contain an
11802 element whose key is equivalent to <tt>k</tt> , inserts the value
11803 <tt>std::pair&lt;const key_type, mapped_type&gt;(std::move(k), mapped_type())</tt>.
11804 </ins></p>
11805
11806 <p><ins>
11807 <i>Requires:</i> <tt>mapped_type</tt> shall be <tt>DefaultConstructible</tt>.
11808 </ins></p>
11809
11810 <p><ins>
11811 <i>Returns:</i> A reference to <tt>x.second</tt>, where <tt>x</tt> is the
11812 (unique) element whose key is equivalent to <tt>k</tt>.
11813 </ins></p>
11814
11815 </blockquote>
11816
11817 </blockquote>
11818
11819 <p>
11820 Add new section [unord.map.modifiers]:
11821 </p>
11822
11823 <blockquote>
11824 <pre><ins>pair&lt;iterator, bool&gt; insert(const value_type&amp; x);</ins>
11825 <ins>template &lt;class P&gt; pair&lt;iterator, bool&gt; insert(P&amp;&amp; x);</ins>
11826 <ins>iterator       insert(iterator hint, const value_type&amp; x);</ins>
11827 <ins>template &lt;class P&gt; iterator       insert(iterator hint, P&amp;&amp; x);</ins>
11828 <ins>const_iterator insert(const_iterator hint, const value_type&amp; x);</ins>
11829 <ins>template &lt;class P&gt; const_iterator insert(const_iterator hint, P&amp;&amp; x);</ins>
11830 <ins>template &lt;class InputIterator&gt;
11831   void insert(InputIterator first, InputIterator last);</ins>
11832 </pre>
11833
11834 <blockquote>
11835 <p><ins>
11836 <i>Requires:</i> Those signatures taking a <tt>const value_type&amp;</tt> parameter
11837 requires both the <tt>key_type</tt> and the <tt>mapped_type</tt> to be
11838 <tt>CopyConstructible</tt>.
11839 </ins></p>
11840
11841 <p><ins>
11842 <tt>P</tt> shall be convertible to <tt>value_type</tt>.
11843  If <tt>P</tt> is instantiated as a reference
11844 type, then the argument <tt>x</tt> is copied from. Otherwise <tt>x</tt>
11845 is considered to be an rvalue as it is converted to <tt>value_type</tt>
11846 and inserted into the <tt>unordered_map</tt>. Specifically, in such
11847 cases <tt>CopyConstructible</tt> is not required of <tt>key_type</tt> or
11848 <tt>mapped_type</tt> unless the conversion from <tt>P</tt> specifically
11849 requires it (e.g. if <tt>P</tt> is a <tt>tuple&lt;const key_type,
11850 mapped_type&gt;</tt>, then <tt>key_type</tt> must be
11851 <tt>CopyConstructible</tt>).
11852 </ins></p>
11853
11854 <p><ins>
11855 The signature taking <tt>InputIterator</tt>
11856 parameters requires <tt>CopyConstructible</tt> of both
11857 <tt>key_type</tt> and <tt>mapped_type</tt> if the dereferenced
11858 <tt>InputIterator</tt> returns an lvalue or <tt>const</tt> rvalue
11859 <tt>value_type</tt>.
11860 </ins></p>
11861
11862 </blockquote>
11863
11864 </blockquote>
11865
11866 <p>
11867 Add to 23.5.1.3 [unord.map.swap]:
11868 </p>
11869
11870 <blockquote>
11871 <pre>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
11872   void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
11873             unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
11874 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
11875   void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
11876             unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
11877 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
11878   void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
11879             unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
11880 </pre>
11881 </blockquote>
11882
11883 <p><b><tt>unordered_multimap</tt></b></p>
11884
11885 <p>
11886 Change 23.5.2 [unord.multimap]:
11887 </p>
11888
11889 <blockquote><pre>class unordered_multimap
11890 {
11891     ...
11892     unordered_multimap(const unordered_multimap&amp;);
11893     <ins>unordered_multimap(unordered_multimap&amp;&amp;);</ins>
11894     ~unordered_multimap();
11895     unordered_multimap&amp; operator=(const unordered_multimap&amp;);
11896     <ins>unordered_multimap&amp; operator=(unordered_multimap&amp;&amp;);</ins>
11897     ...
11898     // modifiers
11899     iterator insert(const value_type&amp; obj);
11900     <ins>template &lt;class P&gt; iterator insert(P&amp;&amp; obj);</ins>
11901     iterator       insert(iterator hint, const value_type&amp; obj);
11902     <ins>template &lt;class P&gt; iterator       insert(iterator hint, P&amp;&amp; obj);</ins>
11903     const_iterator insert(const_iterator hint, const value_type&amp; obj);
11904     <ins>template &lt;class P&gt; const_iterator insert(const_iterator hint, P&amp;&amp; obj);</ins>
11905     ...
11906     void swap(unordered_multimap&amp;<ins>&amp;</ins>);
11907     ...
11908 };
11909
11910 template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
11911   void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
11912             unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
11913
11914 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
11915   void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
11916             unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
11917
11918 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
11919   void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
11920             unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
11921 </pre></blockquote>
11922
11923 <p>
11924 Add to 23.5.2.1 [unord.multimap.cnstr]:
11925 </p>
11926
11927 <blockquote>
11928 <pre>template &lt;class InputIterator&gt;
11929   unordered_multimap(InputIterator f, InputIterator l,
11930                 size_type n = <i>implementation-defined</i>,
11931                 const hasher&amp; hf = hasher(),
11932                 const key_equal&amp; eql = key_equal(),
11933                 const allocator_type&amp; a = allocator_type());
11934 </pre>
11935
11936 <blockquote><p>
11937 <ins>
11938 <i>Requires:</i> If the iterator's dereference operator returns an
11939 lvalue or a const rvalue <tt>pair&lt;key_type, mapped_type&gt;</tt>,
11940 then both <tt>key_type</tt> and <tt>mapped_type</tt> shall be
11941 <tt>CopyConstructible</tt>.
11942 </ins>
11943 </p></blockquote>
11944 </blockquote>
11945
11946 <p>
11947 Add new section [unord.multimap.modifiers]:
11948 </p>
11949
11950 <blockquote>
11951 <pre><ins>iterator insert(const value_type&amp; x);</ins>
11952 <ins>template &lt;class P&gt; iterator       insert(P&amp;&amp; x);</ins>
11953 <ins>iterator       insert(iterator hint, const value_type&amp; x);</ins>
11954 <ins>template &lt;class P&gt; iterator       insert(iterator hint, P&amp;&amp; x);</ins>
11955 <ins>const_iterator insert(const_iterator hint, const value_type&amp; x);</ins>
11956 <ins>template &lt;class P&gt; const_iterator insert(const_iterator hint, P&amp;&amp; x);</ins>
11957 <ins>template &lt;class InputIterator&gt;
11958   void insert(InputIterator first, InputIterator last);</ins>
11959 </pre>
11960
11961 <blockquote>
11962 <p><ins>
11963 <i>Requires:</i> Those signatures taking a <tt>const value_type&amp;</tt> parameter
11964 requires both the <tt>key_type</tt> and the <tt>mapped_type</tt> to be
11965 <tt>CopyConstructible</tt>.
11966 </ins></p>
11967
11968 <p><ins>
11969 <tt>P</tt> shall be convertible to <tt>value_type</tt>.
11970  If <tt>P</tt> is instantiated as a reference
11971 type, then the argument <tt>x</tt> is copied from. Otherwise <tt>x</tt>
11972 is considered to be an rvalue as it is converted to <tt>value_type</tt>
11973 and inserted into the <tt>unordered_multimap</tt>. Specifically, in such
11974 cases <tt>CopyConstructible</tt> is not required of <tt>key_type</tt> or
11975 <tt>mapped_type</tt> unless the conversion from <tt>P</tt> specifically
11976 requires it (e.g. if <tt>P</tt> is a <tt>tuple&lt;const key_type,
11977 mapped_type&gt;</tt>, then <tt>key_type</tt> must be
11978 <tt>CopyConstructible</tt>).
11979 </ins></p>
11980
11981 <p><ins>
11982 The signature taking <tt>InputIterator</tt>
11983 parameters requires <tt>CopyConstructible</tt> of both
11984 <tt>key_type</tt> and <tt>mapped_type</tt> if the dereferenced
11985 <tt>InputIterator</tt> returns an lvalue or <tt>const</tt> rvalue
11986 <tt>value_type</tt>.
11987 </ins></p>
11988 </blockquote>
11989
11990 </blockquote>
11991
11992 <p>
11993 Add to 23.5.2.2 [unord.multimap.swap]:
11994 </p>
11995
11996 <blockquote>
11997 <pre>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
11998   void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
11999             unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
12000 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
12001   void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
12002             unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
12003 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
12004   void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
12005             unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
12006 </pre>
12007 </blockquote>
12008
12009 <p><b><tt>unordered_set</tt></b></p>
12010
12011 <p>
12012 Change 23.5.3 [unord.set]:
12013 </p>
12014
12015 <blockquote><pre>class unordered_set
12016 {
12017     ...
12018     unordered_set(const unordered_set&amp;);
12019     <ins>unordered_set(unordered_set&amp;&amp;);</ins>
12020     ~unordered_set();
12021     unordered_set&amp; operator=(const unordered_set&amp;);
12022     <ins>unordered_set&amp; operator=(unordered_set&amp;&amp;);</ins>
12023     ...
12024     // modifiers
12025     <del>std::</del>pair&lt;iterator, bool&gt; insert(const value_type&amp; obj);
12026     <ins>pair&lt;iterator, bool&gt; insert(value_type&amp;&amp; obj);</ins>
12027     iterator       insert(iterator hint, const value_type&amp; obj);
12028     <ins>iterator       insert(iterator hint, value_type&amp;&amp; obj);</ins>
12029     const_iterator insert(const_iterator hint, const value_type&amp; obj);
12030     <ins>const_iterator insert(const_iterator hint, value_type&amp;&amp; obj);</ins>
12031     ...
12032     void swap(unordered_set&amp;<ins>&amp;</ins>);
12033     ...
12034 };
12035
12036 template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
12037   void swap(unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
12038             unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
12039
12040 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
12041   void swap(unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
12042             unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
12043
12044 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
12045   void swap(unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
12046             unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
12047 </pre></blockquote>
12048
12049 <p>
12050 Add to 23.5.3.1 [unord.set.cnstr]:
12051 </p>
12052
12053 <blockquote>
12054 <pre>template &lt;class InputIterator&gt;
12055   unordered_set(InputIterator f, InputIterator l,
12056                 size_type n = <i>implementation-defined</i>,
12057                 const hasher&amp; hf = hasher(),
12058                 const key_equal&amp; eql = key_equal(),
12059                 const allocator_type&amp; a = allocator_type());
12060 </pre>
12061
12062 <blockquote><p>
12063 <ins>
12064 <i>Requires:</i> If the iterator's dereference operator returns an
12065 lvalue or a const rvalue <tt>value_type</tt>, then the
12066 <tt>value_type</tt> shall be <tt>CopyConstructible</tt>.
12067 </ins>
12068 </p></blockquote>
12069 </blockquote>
12070
12071 <p>
12072 Add new section [unord.set.modifiers]:
12073 </p>
12074
12075 <blockquote>
12076 <pre><ins>pair&lt;iterator, bool&gt; insert(const value_type&amp; x);</ins>
12077 <ins>pair&lt;iterator, bool&gt; insert(value_type&amp;&amp; x);</ins>
12078 <ins>iterator       insert(iterator hint, const value_type&amp; x);</ins>
12079 <ins>iterator       insert(iterator hint, value_type&amp;&amp; x);</ins>
12080 <ins>const_iterator insert(const_iterator hint, const value_type&amp; x);</ins>
12081 <ins>const_iterator insert(const_iterator hint, value_type&amp;&amp; x);</ins>
12082 <ins>template &lt;class InputIterator&gt;
12083   void insert(InputIterator first, InputIterator last);</ins>
12084 </pre>
12085
12086 <blockquote>
12087
12088 <p><ins>
12089 <i>Requires:</i> Those signatures taking a <tt>const
12090 value_type&amp;</tt> parameter requires the <tt>value_type</tt> to
12091 be <tt>CopyConstructible</tt>.
12092 </ins></p>
12093
12094 <p><ins>
12095 The signature taking <tt>InputIterator</tt> parameters requires
12096 <tt>CopyConstructible</tt> of <tt>value_type</tt> if the dereferenced
12097 <tt>InputIterator</tt> returns an lvalue or <tt>const</tt> rvalue
12098 <tt>value_type</tt>.
12099 </ins></p>
12100
12101 </blockquote>
12102
12103 </blockquote>
12104
12105 <p>
12106 Add to 23.5.3.2 [unord.set.swap]:
12107 </p>
12108
12109 <blockquote>
12110 <pre>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
12111   void swap(unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
12112             unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
12113 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
12114   void swap(unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
12115             unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
12116 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
12117   void swap(unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
12118             unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
12119 </pre>
12120 </blockquote>
12121
12122 <p><b><tt>unordered_multiset</tt></b></p>
12123
12124 <p>
12125 Change 23.5.4 [unord.multiset]:
12126 </p>
12127
12128 <blockquote><pre>class unordered_multiset
12129 {
12130     ...
12131     unordered_multiset(const unordered_multiset&amp;);
12132     <ins>unordered_multiset(unordered_multiset&amp;&amp;);</ins>
12133     ~unordered_multiset();
12134     unordered_multiset&amp; operator=(const unordered_multiset&amp;);
12135     <ins>unordered_multiset&amp; operator=(unordered_multiset&amp;&amp;);</ins>
12136     ...
12137     // modifiers
12138     iterator insert(const value_type&amp; obj);
12139     <ins>iterator insert(value_type&amp;&amp; obj);</ins>
12140     iterator       insert(iterator hint, const value_type&amp; obj);
12141     <ins>iterator       insert(iterator hint, value_type&amp;&amp; obj);</ins>
12142     const_iterator insert(const_iterator hint, const value_type&amp; obj);
12143     <ins>const_iterator insert(const_iterator hint, value_type&amp;&amp; obj);</ins>
12144     ...
12145     void swap(unordered_multiset&amp;<ins>&amp;</ins>);
12146     ...
12147 };
12148
12149 template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
12150   void swap(unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
12151             unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
12152
12153 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
12154   void swap(unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
12155             unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
12156
12157 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
12158   void swap(unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
12159             unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
12160 </pre></blockquote>
12161
12162 <p>
12163 Add to 23.5.4.1 [unord.multiset.cnstr]:
12164 </p>
12165
12166 <blockquote>
12167 <pre>template &lt;class InputIterator&gt;
12168   unordered_multiset(InputIterator f, InputIterator l,
12169                 size_type n = <i>implementation-defined</i>,
12170                 const hasher&amp; hf = hasher(),
12171                 const key_equal&amp; eql = key_equal(),
12172                 const allocator_type&amp; a = allocator_type());
12173 </pre>
12174
12175 <blockquote><p>
12176 <ins>
12177 <i>Requires:</i> If the iterator's dereference operator returns an
12178 lvalue or a const rvalue <tt>value_type</tt>, then the
12179 <tt>value_type</tt> shall be <tt>CopyConstructible</tt>.
12180 </ins>
12181 </p></blockquote>
12182 </blockquote>
12183
12184 <p>
12185 Add new section [unord.multiset.modifiers]:
12186 </p>
12187
12188 <blockquote>
12189 <pre><ins>iterator insert(const value_type&amp; x);</ins>
12190 <ins>iterator insert(value_type&amp;&amp; x);</ins>
12191 <ins>iterator       insert(iterator hint, const value_type&amp; x);</ins>
12192 <ins>iterator       insert(iterator hint, value_type&amp;&amp; x);</ins>
12193 <ins>const_iterator insert(const_iterator hint, const value_type&amp; x);</ins>
12194 <ins>const_iterator insert(const_iterator hint, value_type&amp;&amp; x);</ins>
12195 <ins>template &lt;class InputIterator&gt;
12196   void insert(InputIterator first, InputIterator last);</ins>
12197 </pre>
12198
12199 <blockquote>
12200
12201 <p><ins>
12202 <i>Requires:</i> Those signatures taking a <tt>const
12203 value_type&amp;</tt> parameter requires the <tt>value_type</tt> to
12204 be <tt>CopyConstructible</tt>.
12205 </ins></p>
12206
12207 <p><ins>
12208 The signature taking <tt>InputIterator</tt> parameters requires
12209 <tt>CopyConstructible</tt> of <tt>value_type</tt> if the dereferenced
12210 <tt>InputIterator</tt> returns an lvalue or <tt>const</tt> rvalue
12211 <tt>value_type</tt>.
12212 </ins></p>
12213
12214 </blockquote>
12215
12216 </blockquote>
12217
12218 <p>
12219 Add to 23.5.4.2 [unord.multiset.swap]:
12220 </p>
12221
12222 <blockquote>
12223 <pre>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
12224   void swap(unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
12225             unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
12226 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
12227   void swap(unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
12228             unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
12229 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
12230   void swap(unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
12231             unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
12232 </pre>
12233 </blockquote>
12234
12235
12236
12237 <p><i>[
12238 Voted to WP in Bellevue.
12239 ]</i></p>
12240
12241
12242 <p><i>[
12243 post Bellevue, Pete notes:
12244 ]</i></p>
12245
12246
12247 <blockquote>
12248 <p>
12249 Please remind people who are reviewing issues to check that the text
12250 modifications match the current draft. Issue 676, for example, adds two
12251 overloads for unordered_map::insert taking a hint. One takes a
12252 const_iterator and returns a const_iterator, and the other takes an
12253 iterator and returns an iterator. This was correct at the time the issue
12254 was written, but was changed in Toronto so there is only one hint
12255 overload, taking a const_iterator and returning an iterator.
12256 </p>
12257 <p>
12258 This issue is not ready. In addition to the relatively minor signature
12259 problem I mentioned earlier, it puts requirements in the wrong places.
12260 Instead of duplicating requirements throughout the template
12261 specifications, it should put them in the front matter that talks about
12262 requirements for unordered containers in general. This presentation
12263 problem is editorial, but I'm not willing to do the extensive rewrite
12264 that it requires. Please put it back into Open status.
12265 </p>
12266 </blockquote>
12267
12268 <p><b>Rationale:</b></p>
12269 <p><i>[
12270 San Francisco:
12271 ]</i></p>
12272
12273
12274 <blockquote>
12275 Solved by
12276 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2776.pdf">N2776</a>.
12277 </blockquote>
12278
12279
12280
12281
12282
12283
12284 <hr>
12285 <h3><a name="683"></a>683. regex_token_iterator summary error</h3>
12286 <p><b>Section:</b> 28.13.2 [re.tokiter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
12287  <b>Submitter:</b> Eric Niebler <b>Opened:</b> 2007-06-02  <b>Last modified:</b> 2009-03-09</p>
12288 <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>
12289 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
12290 <p><b>Discussion:</b></p>
12291 <p>
12292 28.13.2 [re.tokiter], p3 says:
12293 </p>
12294 <blockquote>
12295 <p>
12296 After it is constructed, the iterator finds and stores a value
12297 <tt>match_results&lt;BidirectionalIterator&gt;</tt> position and sets the
12298 internal count <tt>N</tt> to zero.
12299 </p>
12300 </blockquote>
12301
12302 <p>
12303 Should read:
12304 </p>
12305
12306 <blockquote>
12307 <p>
12308 After it is constructed, the iterator finds and stores a value
12309 <tt><del>match_results</del><ins>regex_iterator</ins>&lt;BidirectionalIterator<ins>, charT, traits</ins>&gt;</tt>
12310 position and sets the internal count <tt>N</tt> to zero.
12311 </p>
12312 </blockquote>
12313
12314 <p><i>[
12315 John adds:
12316 ]</i></p>
12317
12318
12319 <blockquote><p>
12320 Yep, looks like a typo/administrative fix to me.
12321 </p></blockquote>
12322
12323
12324
12325 <p><b>Proposed resolution:</b></p>
12326 <p>
12327 </p>
12328
12329
12330
12331
12332
12333 <hr>
12334 <h3><a name="684"></a>684. Unclear which members of match_results should be used in comparison</h3>
12335 <p><b>Section:</b> 28.11 [re.results] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
12336  <b>Submitter:</b> Nozomu Katoo <b>Opened:</b> 2007-05-27  <b>Last modified:</b> 2008-03-12</p>
12337 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.results">issues</a> in [re.results].</p>
12338 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
12339 <p><b>Discussion:</b></p>
12340 <p>
12341 In 28.5 [re.syn] of N2284, two template functions
12342 are declared here:
12343 </p>
12344 <blockquote><pre>// 28.10, class template match_results:
12345   &lt;<i>snip</i>&gt;
12346 // match_results comparisons
12347   template &lt;class BidirectionalIterator, class Allocator&gt;
12348     bool operator== (const match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m1,
12349                      const match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m2);
12350   template &lt;class BidirectionalIterator, class Allocator&gt;
12351     bool operator!= (const match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m1,
12352                      const match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m2);
12353
12354 // 28.10.6, match_results swap:
12355 </pre></blockquote>
12356
12357 <p>
12358 But the details of these two bool operator functions (i.e., which members of
12359 <tt>match_results</tt> should be used in comparison) are not described in any
12360 following sections.
12361 </p>
12362
12363 <p><i>[
12364 John adds:
12365 ]</i></p>
12366
12367
12368 <blockquote><p>
12369 That looks like a bug: <tt>operator==</tt> should return <tt>true</tt> only if
12370 the two objects refer to the same match - ie if one object was constructed as a
12371 copy of the other.
12372 </p></blockquote>
12373
12374 <p><i>[
12375 Kona (2007): Bill and Pete to add minor wording to that proposed in
12376 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2409.pdf">N2409</a>.
12377 ]</i></p>
12378
12379
12380
12381 <p><b>Proposed resolution:</b></p>
12382 <p>
12383 Add a new section after 28.11.6 [re.results.swap], which reads:
12384 </p>
12385 <p>
12386 28.10.7 match_results non-member functions.
12387 </p>
12388
12389 <blockquote>
12390 <pre>template&lt;class BidirectionalIterator, class Allocator&gt;
12391   bool operator==(const match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m1,
12392                   const match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m2);
12393 </pre>
12394 <blockquote>
12395 <p>
12396 <i>Returns:</i> <tt>true</tt> only if the two objects refer to the same match.
12397 </p>
12398 </blockquote>
12399 </blockquote>
12400
12401 <blockquote>
12402 <pre>template&lt;class BidirectionalIterator, class Allocator&gt;
12403   bool operator!=(const match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m1,
12404                   const match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m2);
12405 </pre>
12406 <blockquote>
12407 <p>
12408 <i>Returns:</i> <tt>!(m1 == m2)</tt>.
12409 </p>
12410 </blockquote>
12411 </blockquote>
12412
12413 <blockquote>
12414 <pre>template&lt;class BidirectionalIterator, class Allocator&gt;
12415   void swap(match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m1,
12416             match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m2);
12417 </pre>
12418 <blockquote>
12419 <p>
12420 <i>Returns:</i> <tt>m1.swap(m2)</tt>.
12421 </p>
12422 </blockquote>
12423 </blockquote>
12424
12425
12426 <p><i>[
12427 Bellevue:  Proposed wording now in WP.
12428 ]</i></p>
12429
12430
12431
12432
12433
12434 <hr>
12435 <h3><a name="686"></a>686. Unique_ptr and shared_ptr fail to specify non-convertibility to int for unspecified-bool-type</h3>
12436 <p><b>Section:</b> 20.8.12.2.4 [unique.ptr.single.observers], 20.8.13.2.5 [util.smartptr.shared.obs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
12437  <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2007-06-14  <b>Last modified:</b> 2008-02-27</p>
12438 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
12439 <p><b>Discussion:</b></p>
12440 <p>
12441 The standard library uses the <tt>operator <i>unspecified-bool-type</i>() const</tt> idiom in
12442 five places. In three of those places (20.7.16.2.3 [func.wrap.func.cap], function capacity
12443 for example) the returned value is constrained to disallow
12444 unintended conversions to int. The standardese is
12445 </p>
12446 <blockquote><p>
12447 The return type shall not be convertible to <tt>int</tt>.
12448 </p></blockquote>
12449 <p>
12450 This constraint is omitted for <tt>unique_ptr</tt> and <tt>shared_ptr</tt>. It should be added for those.
12451 </p>
12452
12453 <p><i>[
12454 Bellevue:
12455 ]</i></p>
12456
12457
12458 <blockquote>
12459 Close as NAD. Accepting paper
12460 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2435.htm">N2435</a>
12461 makes it irrelevant.
12462 </blockquote>
12463
12464
12465
12466 <p><b>Proposed resolution:</b></p>
12467 <p>
12468 To the <i>Returns</i> paragraph for <tt>operator <i>unspecified-bool-type</i>()
12469 const</tt>
12470 of 20.8.12.2.4 [unique.ptr.single.observers] paragraph 11 and
12471 20.8.13.2.5 [util.smartptr.shared.obs] paragraph 16, add the sentence:
12472 </p>
12473 <blockquote><p>
12474 The return type shall not be convertible to <tt>int</tt>.
12475 </p></blockquote>
12476
12477
12478 <p><i>[
12479 Kona (2007): Uncertain if <tt>nullptr</tt> will address this issue.
12480 ]</i></p>
12481
12482
12483
12484
12485
12486 <hr>
12487 <h3><a name="690"></a>690. abs(long long) should return long long</h3>
12488 <p><b>Section:</b> 26.8 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
12489  <b>Submitter:</b> Niels Dekker <b>Opened:</b> 2007-06-10  <b>Last modified:</b> 2007-07-25</p>
12490 <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>
12491 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
12492 <p><b>Discussion:</b></p>
12493 <p>
12494 Quoting the latest draft (n2135), 26.8 [c.math]:
12495 </p>
12496
12497 <blockquote>
12498 <p>
12499 The added signatures are:
12500 </p>
12501 <blockquote><pre>long abs(long); // labs()
12502 long abs(long long); // llabs()
12503 </pre></blockquote>
12504 </blockquote>
12505 <p>
12506 Shouldn't <tt>abs(long long)</tt> have <tt>long long</tt> as return type?
12507 </p>
12508
12509
12510 <p><b>Proposed resolution:</b></p>
12511 <p>
12512 Change 26.8 [c.math]:
12513 </p>
12514 <blockquote><pre><ins>long </ins>long abs(long long); // llabs()
12515 </pre></blockquote>
12516
12517
12518 <p><b>Rationale:</b></p>
12519 Had already been fixed in the WP by the time the LWG reviewed this.
12520
12521
12522
12523
12524
12525 <hr>
12526 <h3><a name="697"></a>697. New <tt>&lt;system_error&gt;</tt> header leads to name clashes</h3>
12527 <p><b>Section:</b> 19.5 [syserr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
12528  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-06-24  <b>Last modified:</b> 2008-01-06</p>
12529 <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>
12530 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
12531 <p><b>Discussion:</b></p>
12532 <p>
12533 The most recent state of
12534 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2241.html">N2241</a>
12535 as well as the current draft
12536 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2284.pdf">N2284</a>
12537 (section 19.5 [syserr], p.2) proposes a
12538 new
12539 enumeration type <tt>posix_errno</tt> immediatly in the namespace <tt>std</tt>. One of
12540 the enumerators has the name <tt>invalid_argument</tt>, or fully qualified:
12541 <tt>std::invalid_argument</tt>. This name clashes with the exception type
12542 <tt>std::invalid_argument</tt>, see 19.2 [std.exceptions]/p.3. This clash makes
12543 e.g. the following snippet invalid:
12544 </p>
12545
12546 <blockquote><pre>#include &lt;system_error&gt;
12547 #include &lt;stdexcept&gt;
12548
12549 void foo() { throw std::invalid_argument("Don't call us - we call you!"); }
12550 </pre></blockquote>
12551
12552 <p>
12553 I propose that this enumeration type (and probably the remaining parts
12554 of
12555 <tt>&lt;system_error&gt;</tt> as well) should be moved into one additional inner
12556 namespace, e.g. <tt>sys</tt> or <tt>system</tt> to reduce foreseeable future clashes
12557 due
12558 to the great number of members that <tt>std::posix_errno</tt> already contains
12559 (Btw.: Why has the already proposed <tt>std::sys</tt> sub-namespace from
12560 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2066.html">N2066</a>
12561 been rejected?). A further clash <em>candidate</em> seems to be
12562 <tt>std::protocol_error</tt>
12563 (a reasonable name for an exception related to a std network library,
12564 I guess).
12565 </p>
12566
12567 <p>
12568 Another possible resolution would rely on the proposed strongly typed
12569 enums,
12570 as described in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2213.pdf">N2213</a>.
12571 But maybe the forbidden implicit conversion to integral types would
12572 make
12573 these enumerators less attractive in this special case?
12574 </p>
12575
12576
12577 <p><b>Proposed resolution:</b></p>
12578 <p>
12579 Fixed by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2422.htm#Issue7">issue 7 of N2422</a>.
12580 </p>
12581
12582
12583
12584
12585
12586
12587 <hr>
12588 <h3><a name="704"></a>704. MoveAssignable requirement for container value type overly strict</h3>
12589 <p><b>Section:</b> 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
12590  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2007-05-20  <b>Last modified:</b> 2008-09-26</p>
12591 <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>
12592 <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>
12593 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
12594 <p><b>Discussion:</b></p>
12595 <p>
12596 The move-related changes inadvertently overwrote the intent of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#276">276</a>.
12597 Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#276">276</a> removed the requirement of <tt>CopyAssignable</tt> from
12598 most of the member functions of node-based containers.  But the move-related changes
12599 unnecessarily introduced the <tt>MoveAssignable</tt> requirement for those members which used to
12600 require <tt>CopyAssignable</tt>.
12601 </p>
12602
12603 <p>
12604 We also discussed (c++std-lib-18722) the possibility of dropping <tt>MoveAssignable</tt>
12605 from some of the sequence requirements.  Additionally the <i>in-place</i> construction
12606 work may further reduce requirements.  For purposes of an easy reference, here are the
12607 minimum sequence requirements as I currently understand them.  Those items in requirements
12608 table in the working draft which do not appear below have been purposefully omitted for
12609 brevity as they do not have any requirements of this nature.  Some items which do not
12610 have any requirements of this nature are included below just to confirm that they were
12611 not omitted by mistake.
12612 </p>
12613
12614 <table border="1">
12615 <caption>Container Requirements</caption>
12616 <tbody><tr><td><tt>X u(a)</tt></td><td><tt>value_type</tt> must be <tt>CopyConstructible</tt></td></tr>
12617 <tr><td><tt>X u(rv)</tt></td><td><tt>array</tt> and containers with a <tt>propagate_never</tt> allocator require <tt>value_type</tt> to be <tt>MoveConstructible</tt></td></tr>
12618 <tr><td><tt>a = u</tt></td><td>Sequences require <tt>value_type</tt> to be <tt>CopyConstructible</tt> and <tt>CopyAssignable</tt>.
12619                                Associative containers require <tt>value_type</tt> to be <tt>CopyConstructible</tt>.</td></tr>
12620 <tr><td><tt>a = rv</tt></td><td><tt>array</tt> requires <tt>value_type</tt> to be <tt>MoveAssignable</tt>.
12621                                 Sequences and Associative containers with <tt>propagate_never</tt> and <tt>propagate_on_copy_construction</tt> allocators require <tt>value_type</tt> to be <tt>MoveConstructible</tt>.</td></tr>
12622 <tr><td><tt>swap(a,u)</tt></td><td><tt>array</tt> and containers with <tt>propagate_never</tt> and
12623                   <tt>propagate_on_copy_construction</tt> allocators require <tt>value_type</tt> to be <tt>Swappable</tt>.</td></tr>
12624 </tbody></table>
12625
12626 <p>
12627 </p>
12628
12629 <table border="1">
12630 <caption>Sequence Requirements</caption>
12631 <tbody><tr><td><tt>X(n)</tt></td><td><tt>value_type</tt> must be <tt>DefaultConstructible</tt></td></tr>
12632 <tr><td><tt>X(n, t)</tt></td><td><tt>value_type</tt> must be <tt>CopyConstructible</tt></td></tr>
12633 <tr><td><tt>X(i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
12634                                  If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
12635 <tr><td><tt>a.insert(p, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
12636                                         The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>CopyAssignable</tt>.</td></tr>
12637 <tr><td><tt>a.insert(p, rv)</tt></td><td>The <tt>value_type</tt> must be <tt>MoveConstructible</tt>.
12638                                         The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>MoveAssignable</tt>.</td></tr>
12639 <tr><td><tt>a.insert(p, n, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
12640                                         The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>CopyAssignable</tt>.</td></tr>
12641 <tr><td><tt>a.insert(p, i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
12642                                         The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>CopyAssignable</tt> when the iterators return an lvalue.
12643                                         If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt>.
12644                                         The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>MoveAssignable</tt> when the iterators return an rvalue.</td></tr>
12645 <tr><td><tt>a.erase(p)</tt></td><td>The sequences <tt>vector</tt> and <tt>deque</tt> require the <tt>value_type</tt> to be <tt>MoveAssignable</tt>.</td></tr>
12646 <tr><td><tt>a.erase(q1, q2)</tt></td><td>The sequences <tt>vector</tt> and <tt>deque</tt> require the <tt>value_type</tt> to be <tt>MoveAssignable</tt>.</td></tr>
12647 <tr><td><tt>a.clear()</tt></td><td></td></tr>
12648 <tr><td><tt>a.assign(i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt> and <tt>CopyAssignable</tt>.
12649                                         If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt>.</td></tr>
12650 <tr><td><tt>a.assign(n, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt> and <tt>CopyAssignable</tt>.</td></tr>
12651 <tr><td><tt>a.resize(n)</tt></td><td>The <tt>value_type</tt> must be <tt>DefaultConstructible</tt>.
12652                                      The sequence <tt>vector</tt> also requires the <tt>value_type</tt> to be <tt>MoveConstructible</tt>.</td></tr>
12653 <tr><td><tt>a.resize(n, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
12654 </tbody></table>
12655
12656 <p>
12657 </p>
12658
12659 <table border="1">
12660 <caption>Optional Sequence Requirements</caption>
12661 <tbody><tr><td><tt>a.front()</tt></td><td></td></tr>
12662 <tr><td><tt>a.back()</tt></td><td></td></tr>
12663 <tr><td><tt>a.push_front(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
12664 <tr><td><tt>a.push_front(rv)</tt></td><td>The <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
12665 <tr><td><tt>a.push_back(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
12666 <tr><td><tt>a.push_back(rv)</tt></td><td>The <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
12667 <tr><td><tt>a.pop_front()</tt></td><td></td></tr>
12668 <tr><td><tt>a.pop_back()</tt></td><td></td></tr>
12669 <tr><td><tt>a[n]</tt></td><td></td></tr>
12670 <tr><td><tt>a.at[n]</tt></td><td></td></tr>
12671 </tbody></table>
12672
12673 <p>
12674 </p>
12675
12676 <table border="1">
12677 <caption>Associative Container Requirements</caption>
12678 <tbody><tr><td><tt>X(i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
12679                                  If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
12680 <tr><td><tt>a_uniq.insert(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
12681 <tr><td><tt>a_uniq.insert(rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
12682 <tr><td><tt>a_eq.insert(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
12683 <tr><td><tt>a_eq.insert(rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
12684 <tr><td><tt>a.insert(p, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
12685 <tr><td><tt>a.insert(p, rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
12686 <tr><td><tt>a.insert(i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
12687                                         If the iterators return an rvalue the <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>..</td></tr>
12688 </tbody></table>
12689
12690 <p>
12691 </p>
12692
12693 <table border="1">
12694 <caption>Unordered Associative Container Requirements</caption>
12695 <tbody><tr><td><tt>X(i, j, n, hf, eq)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
12696                                  If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
12697 <tr><td><tt>a_uniq.insert(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
12698 <tr><td><tt>a_uniq.insert(rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
12699 <tr><td><tt>a_eq.insert(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
12700 <tr><td><tt>a_eq.insert(rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
12701 <tr><td><tt>a.insert(p, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
12702 <tr><td><tt>a.insert(p, rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
12703 <tr><td><tt>a.insert(i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
12704                                         If the iterators return an rvalue the <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>..</td></tr>
12705 </tbody></table>
12706
12707 <p>
12708 </p>
12709
12710 <table border="1">
12711 <caption>Miscellaneous Requirements</caption>
12712 <tbody><tr><td><tt>map[lvalue-key]</tt></td><td>The <tt>key_type</tt> must be <tt>CopyConstructible</tt>.
12713                                          The <tt>mapped_type</tt> must be <tt>DefaultConstructible</tt> and <tt>MoveConstructible</tt>.</td></tr>
12714 <tr><td><tt>map[rvalue-key]</tt></td><td>The <tt>key_type</tt> must be <tt>MoveConstructible</tt>.
12715                                          The <tt>mapped_type</tt> must be <tt>DefaultConstructible</tt> and <tt>MoveConstructible</tt>.</td></tr>
12716 </tbody></table>
12717
12718 <p><i>[
12719 Kona (2007): Howard and Alan to update requirements table in issue with emplace signatures.
12720 ]</i></p>
12721
12722
12723 <p><i>[
12724 Bellevue: This should be handled as part of the concepts work.
12725 ]</i></p>
12726
12727
12728
12729
12730 <p><b>Proposed resolution:</b></p>
12731
12732
12733
12734 <p><b>Rationale:</b></p>
12735 <p><i>[
12736 post San Francisco:
12737 ]</i></p>
12738
12739
12740 <blockquote>
12741 Solved by
12742 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2776.pdf">N2776</a>.
12743 </blockquote>
12744
12745
12746
12747
12748
12749
12750 <hr>
12751 <h3><a name="707"></a>707. null pointer constant for <tt>exception_ptr</tt></h3>
12752 <p><b>Section:</b> 18.8.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
12753  <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2007-07-20  <b>Last modified:</b> 2008-02-25</p>
12754 <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>
12755 <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>
12756 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
12757 <p><b>Discussion:</b></p>
12758
12759 <p>
12760 From the Toronto Core wiki:
12761 </p>
12762
12763 <p>
12764 What do you mean by "null pointer constant"? How do you guarantee that
12765 <tt>exception_ptr() == 1</tt> doesn't work?  Do you even want to prevent that?
12766 What's the semantics?  What about <tt>void *p = 0; exception_ptr() == p</tt>?
12767 Maybe disallow those in the interface, but how do you do that with
12768 portable C++? Could specify just "make it work".
12769 </p>
12770
12771 <p>
12772 Peter's response:
12773 </p>
12774
12775 <p>
12776 null pointer constant as defined in 4.10 [conv.ptr]. Intent is "just make it
12777 work", can be implemented as assignment operator taking a unique pointer
12778 to member, as in the unspecified bool type idiom.
12779 </p>
12780
12781 <p><i>[
12782 Bellevue:
12783 ]</i></p>
12784
12785
12786 <blockquote>
12787 <p>
12788 Original implementation was possible using the "unspecified-null-pointer" idiom, similar to unspecified-bool.
12789 </p>
12790 <p>
12791 Even simpler now with nullptr_t.
12792 </p>
12793 <p>
12794 NAD Rationale : null pointer constant is a perfectly defined term, and
12795 while API is clearly implementable there is no need to spell out
12796 implementation details.
12797 </p>
12798 </blockquote>
12799
12800
12801
12802 <p><b>Proposed resolution:</b></p>
12803 <p>
12804 </p>
12805
12806
12807
12808
12809
12810 <hr>
12811 <h3><a name="717"></a>717. Incomplete <tt>valarray::operator[]</tt> specification in [valarray.access]</h3>
12812 <p><b>Section:</b> 26.6.2.3 [valarray.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
12813  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-08-27  <b>Last modified:</b> 2008-09-22</p>
12814 <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>
12815 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
12816 <p><b>Discussion:</b></p>
12817 <p>
12818 Since the return type of <tt>valarray</tt>'s <tt>operator[] const</tt> overload has been
12819 changed to <tt>const T&amp;</tt> as described in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a> several paragraphs of
12820 the section 26.6.2.3 [valarray.access] are now
12821 incompletely
12822 specified, because many requirements and guarantees should now also
12823 apply to the const overload. Most notably, the address and reference
12824 guarantees should be extended to the const overload case.
12825 </p>
12826
12827
12828 <p><b>Proposed resolution:</b></p>
12829 <p>
12830 Change 26.6.2.3 [valarray.access]:
12831 </p>
12832
12833 <blockquote>
12834 <p>
12835 -1- <del>When applied to a constant array, the subscript operator returns a
12836 reference to the corresponding element of the array. When applied to a
12837 non-constant array, t</del><ins>T</ins>he subscript operator returns a
12838 reference to the corresponding element of the array.
12839 </p>
12840
12841 <p>
12842 -3- The expression <tt>&amp;a[i+j] == &amp;a[i] + j</tt> evaluates as <tt>true</tt> for all <tt>size_t i</tt>
12843 and <tt>size_t j</tt> such that <tt>i+j</tt> is less
12844 than the length of the <del>non-constant</del> array <tt>a</tt>.
12845 </p>
12846
12847 <p>
12848 -4- Likewise, the expression <tt>&amp;a[i] != &amp;b[j]</tt> evaluates
12849 as <tt>true</tt> for any two <del>non-constant</del> arrays <tt>a</tt> and
12850 <tt>b</tt> and for any <tt>size_t i</tt> and <tt>size_t j</tt> such that
12851 <tt>i</tt> is less than the length of <tt>a</tt> and <tt>j</tt> is less
12852 than the length of <tt>b</tt>. This property indicates an absence of
12853 aliasing and may be used to advantage by optimizing
12854 compilers.<sup>281)</sup>
12855 </p>
12856
12857 <p>
12858 -5- The reference returned by the subscript operator for a<ins>n</ins> <del>non-constant</del> array is guaranteed to be valid until
12859 the member function <tt>resize(size_t, T)</tt> (26.5.2.7) is called for that array or until the lifetime
12860 of that array ends, whichever happens first.
12861 </p>
12862
12863 </blockquote>
12864
12865
12866
12867
12868
12869
12870 <hr>
12871 <h3><a name="724"></a>724. <tt>DefaultConstructible</tt> is not defined</h3>
12872 <p><b>Section:</b> X [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
12873  <b>Submitter:</b> Pablo Halpern <b>Opened:</b> 2007-09-12  <b>Last modified:</b> 2008-09-23</p>
12874 <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>
12875 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
12876 <p><b>Discussion:</b></p>
12877 <p>
12878 The <tt>DefaultConstructible</tt> requirement is referenced in
12879 several places in the August 2007 working draft
12880 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2369.pdf">N2369</a>,
12881 but is not defined anywhere.
12882 </p>
12883
12884 <p><i>[
12885 Bellevue:
12886 ]</i></p>
12887
12888
12889 <blockquote>
12890 <p>
12891 Walking into the default/value-initialization mess...
12892 </p>
12893 <p>
12894 Why two lines? Because we need both expressions to be valid.
12895 </p>
12896 <p>
12897 AJM not sure what the phrase "default constructed" means. This is
12898 unfortunate, as the phrase is already used 24 times in the library!
12899 </p>
12900 <p>
12901 Example: const int would not accept first line, but will accept the second.
12902 </p>
12903 <p>
12904 This is an issue that must be solved by concepts, but we might need to solve it independantly first.
12905 </p>
12906 <p>
12907 It seems that the requirements are the syntax in the proposed first
12908 column is valid, but not clear what semantics we need.
12909 </p>
12910 <p>
12911 A table where there is no post-condition seems odd, but appears to sum up our position best.
12912 </p>
12913 <p>
12914 At a minimum an object is declared and is destuctible.
12915 </p>
12916 <p>
12917 Move to open, as no-one happy to produce wording on the fly.
12918 </p>
12919 </blockquote>
12920
12921
12922 <p><b>Proposed resolution:</b></p>
12923 <p>
12924 In section X [utility.arg.requirements], before table 33, add the
12925 following table:
12926 </p>
12927
12928 <p style="text-align: center;" align="center">Table 33: <tt>DefaultConstructible</tt> requirements</p>
12929
12930 <div align="center">
12931
12932 <table style="border-collapse: collapse;" border="0" cellpadding="0" cellspacing="0">
12933  <tbody><tr>
12934   <td style="border-style: solid none double solid; border-color: navy -moz-use-text-color navy navy; border-width: 1pt medium 1.5pt 1pt; padding: 0in 5.4pt; width: 85.5pt;" valign="top" width="114">
12935   <p style="margin: 0in 0in 0.0001pt; text-align: center;" align="center">expression</p>
12936   </td>
12937   <td style="border-style: solid solid double none; border-color: navy navy navy -moz-use-text-color; border-width: 1pt 1pt 1.5pt medium; padding: 0in 5.4pt; width: 243pt;" valign="top" width="324">
12938   <p style="margin: 0in 0in 0.0001pt; text-align: center;" align="center">post-condition</p>
12939   </td>
12940  </tr>
12941  <tr>
12942   <td style="border-style: none none solid solid; border-color: -moz-use-text-color -moz-use-text-color navy navy; border-width: medium medium 1pt 1pt; padding: 0in 5.4pt; width: 85.5pt;" valign="top" width="114">
12943   <p style="margin: 0in 0in 0.0001pt;"><tt>T
12944   t;</tt><br>
12945   <tt>T()</tt></p>
12946   </td>
12947   <td style="border-style: none solid solid none; border-color: -moz-use-text-color navy navy -moz-use-text-color; border-width: medium 1pt 1pt medium; padding: 0in 5.4pt; width: 243pt;" valign="top" width="324">
12948   <p style="margin: 0in 0in 0.0001pt;"><tt>T</tt>
12949   is <i>default constructed.</i></p>
12950   </td>
12951  </tr>
12952 </tbody></table>
12953
12954 </div>
12955
12956
12957
12958 <p><b>Rationale:</b></p>
12959 <p><i>[
12960 San Francisco:
12961 ]</i></p>
12962
12963 <blockquote>
12964 We believe concepts will solve this problem
12965 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2774.pdf">N2774</a>).
12966 </blockquote>
12967
12968
12969
12970
12971
12972 <hr>
12973 <h3><a name="725"></a>725. Optional sequence container requirements column label</h3>
12974 <p><b>Section:</b> 23.2.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
12975  <b>Submitter:</b> David Abrahams <b>Opened:</b> 2007-09-16  <b>Last modified:</b> 2008-09-22</p>
12976 <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>
12977 <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>
12978 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
12979 <p><b>Discussion:</b></p>
12980 <p>
12981 Table 90: (Optional sequence container operations) states the
12982 "assertion note pre/post-condition" of <tt>operator[]</tt> to be
12983 </p>
12984
12985 <blockquote><pre>*(a.begin() + n)
12986 </pre></blockquote>
12987
12988 <p>
12989 Surely that's meant to be "operational semantics?"
12990 </p>
12991
12992
12993
12994 <p><b>Proposed resolution:</b></p>
12995 <blockquote>
12996 <table border="1">
12997 <caption>Table 90: Optional sequence container operations</caption>
12998 <tbody><tr>
12999 <th>expression</th> <th>return type</th> <th><del>assertion/note<br>pre/post-condition</del><br> <ins>operational semantics</ins></th> <th>container</th>
13000 </tr>
13001 </tbody></table>
13002 </blockquote>
13003
13004
13005
13006
13007
13008
13009 <hr>
13010 <h3><a name="729"></a>729. Problem in [rand.req.eng]/3</h3>
13011 <p><b>Section:</b> X [rand.req.eng] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
13012  <b>Submitter:</b> Stephan Tolksdorf <b>Opened:</b> 2007-09-21  <b>Last modified:</b> 2008-02-27</p>
13013 <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>
13014 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
13015 <p><b>Discussion:</b></p>
13016 <p>
13017 The 3rd table row in X [rand.req.eng]/3 requires random number engines to accept any
13018 arithmetic type as a seed, which is then casted to the engine's <tt>result_type</tt> and subsequently
13019 used for seeding the state of the engine. The requirement stated as "Creates an engine with
13020 initial state determined by <tt>static_cast&lt;X::result_type&gt;(s)</tt>" forces random number engines
13021 to either use a seeding method that completely depends on the <tt>result_type</tt> (see the discussion
13022 of seeding for the <tt>mersenne_twister_engine</tt> in point T2 above) or at least to throw away "bits
13023 of randomness" in the seed value if the <tt>result_type</tt> is smaller than the seed type. This seems
13024 to be inappropriate for many modern random number generators, in particular F2-linear or
13025 cryptographic ones, which operate on an internal bit array that in principle is independent of the
13026 type of numbers returned.
13027 </p>
13028
13029 <p>
13030 <b>Posible resolution:</b> I propose to change the wording to a version similar to "Creates an
13031 engine with initial state determined by <tt>static_cast&lt;UintType&gt;(s)</tt>, where <tt>UintType</tt> is an
13032 implementation specific unsigned integer type."
13033 </p>
13034
13035 <p>
13036 Additionally, the definition of s in X [rand.req.eng]/1 c) could be restricted to unsigned integer types.
13037 </p>
13038
13039 <p>
13040 Similarly, the type of the seed in X [rand.req.adapt]/3 e) could be left unspecified.
13041 </p>
13042
13043 <p>
13044 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
13045 for further discussion.
13046 </p>
13047
13048 <p><i>[
13049 Stephan Tolksdorf adds pre-Bellevue:
13050 ]</i></p>
13051
13052
13053 <blockquote>
13054 <p>
13055 In reply to the discussion in
13056 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
13057 regarding this issue:
13058 </p>
13059 <p>
13060 The descriptions of all engines and engine adaptors given in sections
13061 26.5.3 [rand.eng] and 26.5.4 [rand.adapt] already specify the concrete
13062 types of the integer arguments for seeding. Hence, relaxing the general
13063 requirement in X [rand.req.eng] would not affect portability and
13064 reproducibility of the standard library. Furthermore, it is not clear to
13065 me what exactly the guarantee "with initial state determined by
13066 <tt>static_cast&lt;X::result_type&gt;(s)</tt>" is useful for. On the other hand,
13067 relaxing the requirement would allow developers to implement  other
13068 random number engines that do not have to cast all arithmetic seed
13069 arguments to their result_types.
13070 </p>
13071 </blockquote>
13072
13073 <p><i>[
13074 Bellevue:
13075 ]</i></p>
13076
13077
13078 <blockquote>
13079 Propose close NAD for the reasons given in N2424.
13080 </blockquote>
13081
13082
13083
13084
13085 <p><b>Proposed resolution:</b></p>
13086 <p>
13087 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
13088 for further discussion.
13089 </p>
13090
13091 <p><i>[
13092 Stephan Tolksdorf adds pre-Bellevue:
13093 ]</i></p>
13094
13095
13096 <blockquote>
13097 <p>
13098 Change row 3 of table 105 "Random number engine requirements" in X [rand.req.eng]/3
13099 </p>
13100
13101 <blockquote>
13102 Creates an engine with initial state determined by
13103 <tt><del>static_cast&lt;X::result_type&gt;(</del>s<del>)</del></tt>
13104 </blockquote>
13105
13106 <p>
13107 Similarly, change X [rand.req.adapt]/3 e)
13108 </p>
13109
13110 <blockquote>
13111 When <tt>X::X</tt> is invoked with <del>an <tt>X::result_type</tt></del> value <tt>s</tt>
13112 <ins>of arithmetic type (3.9.1)</ins>, ...
13113 </blockquote>
13114
13115 </blockquote>
13116
13117
13118
13119
13120
13121
13122 <hr>
13123 <h3><a name="730"></a>730. Comment on [rand.req.adapt]/3 e)</h3>
13124 <p><b>Section:</b> X [rand.req.adapt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
13125  <b>Submitter:</b> Stephan Tolksdorf <b>Opened:</b> 2007-09-21  <b>Last modified:</b> 2008-02-27</p>
13126 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
13127 <p><b>Discussion:</b></p>
13128 <p>
13129 If an engine adaptor is invoked with an argument of type <tt>seed_seq</tt>, then all base
13130 engines are specified to be seeded with this <tt>seed_seq</tt>. As <tt>seed_seq</tt>'s randomization method is
13131 qualified as constant, this procedure will ef fectively initialize all base engines with the same seed
13132 (though the resulting state might still dif fer to a certain degree if the engines are of different types).
13133 It is not clear whether this mode of operation is in general appropriate, hence -- as far as the
13134 stated requirements are of general nature and not just specific to the engine adaptors provided by
13135 the library -- it might be better to leave the behaviour unspecified, since the current definition of
13136 <tt>seed_seq</tt> does not allow for a generally satisfying specification.
13137 </p>
13138
13139 <p>
13140 <b>Posssible resolution:</b> [As above]
13141 </p>
13142
13143 <p>
13144 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
13145 for further discussion.
13146 </p>
13147
13148 <p><i>[
13149 Bellevue:
13150 ]</i></p>
13151
13152
13153 <blockquote>
13154 Close NAD for the reasons given in N2424.
13155 </blockquote>
13156
13157
13158
13159 <p><b>Proposed resolution:</b></p>
13160 <p>
13161 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
13162 for the proposed resolution.
13163 </p>
13164
13165
13166
13167
13168
13169 <hr>
13170 <h3><a name="731"></a>731. proposal for a customizable <tt>seed_seq</tt></h3>
13171 <p><b>Section:</b> 26.5.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
13172  <b>Submitter:</b> Stephan Tolksdorf <b>Opened:</b> 2007-09-21  <b>Last modified:</b> 2008-02-27</p>
13173 <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>
13174 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
13175 <p><b>Discussion:</b></p>
13176 <p>
13177 The proper way to seed random number engines seems to be the most frequently
13178 discussed issue of the 26.5 [rand] proposal. While the new <tt>seed_seq</tt> approach is already rather
13179 general and probably sufficient for most situations, it is unlikely to be optimal in every case (one
13180 problem was pointed out in point T5 above). In some situations it might, for instance, be better to
13181 seed the state with a cryptographic generator.
13182 </p>
13183 <p>
13184 In my opinion this is a pretty strong argument for extending the standard with a simple facility to
13185 customize the seeding procedure. This could, for example, be done with the following minimal
13186 changes:
13187 </p>
13188
13189 <p>
13190 <b>Possible resolution:</b>
13191 </p>
13192
13193 <ol type="a">
13194 <li>
13195 Turn the interface specification of 26.5.7.1 [rand.util.seedseq]/2 into a "SeedSeq" requirement, where the
13196 exact behaviour of the constructors and the randomize method are left unspecified and where the
13197 const qualification for randomize is removed. Classes implementing this interface are additionally
13198 required to specialize the traits class in c).
13199 </li>
13200 <li>
13201 Provide the class <tt>seed_seq</tt> as a default implementation of the SeedSeq interface.
13202 </li>
13203 <li>
13204 <p>
13205 Supplement the <tt>seed_seq</tt> with a traits class
13206 </p>
13207 <blockquote><pre>template &lt;typename T&gt;
13208 struct is_seed_seq { static const bool value = false; }
13209 </pre></blockquote>
13210 <p>and the specialization</p>
13211 <blockquote><pre>template &lt;&gt;
13212 struct is_seed_seq&lt;seed_seq&gt; { static const bool value = true; }
13213 </pre></blockquote>
13214 <p>which users can supplement with further specializations.</p>
13215 </li>
13216 <li>
13217 Change X [rand.req.eng]/1 d) to "q is an lvalue of a type that fulfils the SeedSeq requirements", and
13218 modify the constructors and seed methods in 26.5.3 [rand.eng] appropriately (the actual implementation
13219 could be done using the SFINAE technique).
13220 </li>
13221 </ol>
13222
13223 <p><i>[
13224 Bellevue:
13225 ]</i></p>
13226
13227
13228 <blockquote>
13229 See N2424. Close NAD but note that "conceptizing" the library may cause
13230 this problem to be solved by that route.
13231 </blockquote>
13232
13233
13234 <p><b>Proposed resolution:</b></p>
13235 <p>
13236 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
13237 for the proposed resolution.
13238 </p>
13239
13240
13241
13242
13243
13244 <hr>
13245 <h3><a name="732"></a>732. Defect in [rand.dist.samp.genpdf]</h3>
13246 <p><b>Section:</b> X [rand.dist.samp.genpdf] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
13247  <b>Submitter:</b> Stephan Tolksdorf <b>Opened:</b> 2007-09-21  <b>Last modified:</b> 2009-03-09</p>
13248 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.genpdf">issues</a> in [rand.dist.samp.genpdf].</p>
13249 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
13250 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#795">795</a></p>
13251 <p><b>Discussion:</b></p>
13252 <p>
13253 X [rand.dist.samp.genpdf] describes the interface for a distribution template that is
13254 meant to simulate random numbers from any general distribution given only the density and the
13255 support of the distribution. I'm not aware of any general purpose algorithm that would be capable
13256 of correctly and efficiently implementing the described functionality. From what I know, this is
13257 essentially an unsolved research problem. Existing algorithms either require more knowledge
13258 about the distribution and the problem domain or work only under very limited circumstances.
13259 Even the state of the art special purpose library UNU.RAN does not solve the problem in full
13260 generality, and in any case, testing and customer support for such a library feature would be a
13261 nightmare.
13262 </p>
13263
13264 <p>
13265 <b>Possible resolution:</b> For these reasons, I propose to delete section X [rand.dist.samp.genpdf].
13266 </p>
13267
13268 <p><i>[
13269 Bellevue:
13270 ]</i></p>
13271
13272
13273 <blockquote>
13274 <p>
13275 Disagreement persists.
13276 </p>
13277 <p>
13278 Objection to this issue is that this function takes a general functor.
13279 The general approach would be to normalize this function, integrate it,
13280 and take the inverse of the integral, which is not possible in general.
13281 An example function is sin(1+n*x) -- for any spatial frequency that the
13282 implementor chooses, there is a value of n that renders that choice
13283 arbitrarily erroneous.
13284 </p>
13285 <p>
13286 Correction: The formula above should instead read 1+sin(n*x).
13287 </p>
13288 <p>
13289 Objector proposes the following possible compromise positions:
13290 </p>
13291 <ul>
13292 <li>
13293 rand.dist.samp.genpdf takes an number of points so that implementor need not guess.
13294 </li>
13295 <li>replace rand.disk.samp.genpdf with an extension to either or both
13296 of the discrete functions to take arguments that take a functor and
13297 number of points in place of the list of probabilities. Reference
13298 issues 793 and 794.
13299 </li>
13300 </ul>
13301 </blockquote>
13302
13303
13304
13305 <p><b>Proposed resolution:</b></p>
13306 <p>
13307 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2813.pdf">N2813</a>
13308 for the proposed resolution.
13309 </p>
13310
13311
13312 <p><b>Rationale:</b></p>
13313 Addressed by
13314 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2836.pdf">N2836</a> "Wording Tweaks for Concept-enabled Random Number Generation in C++0X".
13315
13316
13317
13318
13319
13320 <hr>
13321 <h3><a name="733"></a>733. Comment on [rand.req.dist]/9</h3>
13322 <p><b>Section:</b> X [rand.req.dist] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
13323  <b>Submitter:</b> Stephan Tolksdorf <b>Opened:</b> 2007-09-21  <b>Last modified:</b> 2008-02-27</p>
13324 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
13325 <p><b>Discussion:</b></p>
13326 <p>
13327 The requirement "P shall have a declaration of the form <tt>typedef X distribution_-
13328 type</tt>" effectively makes the use of inheritance for implementing distributions very inconvenient,
13329 because the child of a distribution class in general will not satisfy this requirement. In my opinion
13330 the benefits of having a typedef in the parameter class pointing back to the distribution class are
13331 not worth the hassle this requirement causes. [In my code base I never made use of the nested
13332 typedef but on several occasions could have profited from being able to use simple inheritance for
13333 the implementation of a distribution class.]
13334 </p>
13335
13336 <p>
13337 <b>Proposed resolution:</b> I propose to drop this requirement.
13338 </p>
13339
13340 <p><i>[
13341 Bellevue:
13342 ]</i></p>
13343
13344
13345 <blockquote>
13346 Close NAD for the reasons given in N2424. In practice it is not inconvenient to meet these requirements.
13347 </blockquote>
13348
13349
13350
13351 <p><b>Proposed resolution:</b></p>
13352 <p>
13353 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
13354 for the proposed resolution.
13355 </p>
13356
13357
13358
13359
13360
13361 <hr>
13362 <h3><a name="735"></a>735. Unfortunate naming</h3>
13363 <p><b>Section:</b> 26.5.8.2.2 [rand.dist.bern.bin], 26.5.8.2.4 [rand.dist.bern.negbin] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
13364  <b>Submitter:</b> Stephan Tolksdorf <b>Opened:</b> 2007-09-21  <b>Last modified:</b> 2008-02-27</p>
13365 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
13366 <p><b>Discussion:</b></p>
13367 <p>
13368 In my opinion the choice of name for the <tt>t</tt> parameter of the <tt>binomial_distribution</tt>
13369 is very unfortunate. In virtually every internet reference, book and software implementation
13370 this parameter is called <tt>n</tt> instead, see for example Wikipedia, Mathworld, Evans et al. (1993)
13371 Statistical Distributions, 2nd E., Wiley, p. 38, the R statistical computing language, p. 926,
13372 Mathematica and Matlab.
13373 </p>
13374
13375 <p>
13376 Similarly, the choice of <tt>k</tt> for the parameter of the negative binomial distributions is rather unusual.
13377 The most common choice for the negative binomial distribution seems to be <tt>r</tt> instead.
13378 </p>
13379
13380 <p>
13381 Choosing unusual names for the parameters causes confusion among users and makes the
13382 interface unnecessarily inconvenient to use.
13383 </p>
13384
13385 <p>
13386 <b>Possible resolution:</b> For these reasons, I propose to change the name of the respective parameters
13387 to <tt>n</tt> and <tt>r</tt>.
13388 </p>
13389
13390 <p><i>[
13391 Bellevue:
13392 ]</i></p>
13393
13394
13395 <blockquote>
13396 In N2424. NAD It has been around for a while. It is hardly universal,
13397 there is prior art, and this would confuse people.
13398 </blockquote>
13399
13400
13401 <p><b>Proposed resolution:</b></p>
13402 <p>
13403 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
13404 for the proposed resolution.
13405 </p>
13406
13407
13408
13409
13410
13411 <hr>
13412 <h3><a name="736"></a>736. Comment on [rand.dist.samp.discrete]</h3>
13413 <p><b>Section:</b> 26.5.8.5.1 [rand.dist.samp.discrete] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
13414  <b>Submitter:</b> Stephan Tolksdorf <b>Opened:</b> 2007-09-21  <b>Last modified:</b> 2008-02-27</p>
13415 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.discrete">issues</a> in [rand.dist.samp.discrete].</p>
13416 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
13417 <p><b>Discussion:</b></p>
13418 <ol type="a">
13419 <li>
13420 The specification for <tt>discrete_distribution</tt> requires the member <tt>probabilities()</tt>
13421 to return a vector of <i>standardized</i> probabilities, which forces the implementation every time to
13422 divide each probability by the sum of all probabilities, as the sum will in practice almost never be
13423 exactly 1.0. This is unnecessarily inef ficient as the implementation would otherwise not need to
13424 compute the standardized probabilities at all and could instead work with the non-standardized
13425 probabilities and the sum. If there was no standardization the user would just get back the
13426 probabilities that were previously supplied to the distribution object, which to me seems to be the
13427 more obvious solution.
13428 </li>
13429 <li>
13430 The behaviour of <tt>discrete_distribution</tt> is not specified in case the number of given
13431 probabilities is larger than the maximum number representable by the IntType.
13432 </li>
13433 </ol>
13434
13435 <p>
13436 <b>Possible resolution:</b> I propose to change the specification such that the non-standardized
13437 probabilities need to be returned and that an additional requirement is included for the number
13438 of probabilities to be smaller than the maximum of IntType.
13439 </p>
13440
13441 <p><i>[
13442 Stephan Tolksdorf adds pre-Bellevue:
13443 ]</i></p>
13444
13445
13446 <blockquote>
13447 <p>
13448 In reply to the discussion in
13449 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
13450 of this issue:
13451 </p>
13452 <p>
13453 Rescaled floating-point parameter vectors can not be expected to compare
13454 equal because of the limited precision of floating-point numbers.
13455 My proposal would at least guarantee that a parameter
13456 vector (of type double) passed into the distribution would compare equal
13457 with the one returned by the <tt>probabilities()</tt> method. Furthermore, I do
13458 not understand why "the changed requirement would lead to a significant
13459 increase in the amount of state in the distribution object". A typical
13460 implementation's state would increase by exactly one number: the sum of
13461 all probabilities. The textual representation for serialization would
13462 not need to grow at all. Finally, the proposed replacement "<tt>0 &lt; n &lt;=
13463 numeric_limits&lt;IntType&gt;::max() + 1</tt>" makes the implementation
13464 unnecessarily complicated, "<tt>0 &lt; n &lt;= numeric_limits&lt;IntType&gt;::max()</tt>"
13465 would be better.
13466 </p>
13467 </blockquote>
13468
13469 <p><i>[
13470 Bellevue:
13471 ]</i></p>
13472
13473
13474 <blockquote>
13475 <p>
13476 In N2424. We agree with the observation and the proposed resolution to
13477 part b). We recommend the wording n &gt; 0 be replaced with 0 &lt; n
13478 numeric_limits::max() + 1. However, we disagree with part a), as it
13479 would interfere with the definition of parameters' equality. Further,
13480 the changed requirement would lead to a significant increase in the
13481 amount of state of the distribution object.
13482 </p>
13483
13484 <p>
13485 As it stands now, it is convenient, and the changes proposed make it
13486 much less so.
13487 </p>
13488
13489 <p>
13490 NAD. Part a the current behavior is desirable. Part b, any constructor
13491 can fail, but the rules under which it can fail do not need to be listed
13492 here.
13493 </p>
13494 </blockquote>
13495
13496
13497 <p><b>Proposed resolution:</b></p>
13498 <p>
13499 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
13500 for the proposed resolution.
13501 </p>
13502
13503 <p><i>[
13504 Stephan Tolksdorf adds pre-Bellevue:
13505 ]</i></p>
13506
13507
13508 <blockquote>
13509 <p>
13510 In 26.5.8.5.1 [rand.dist.samp.discrete]:
13511 </p>
13512
13513 <p>
13514 Proposed wording a):
13515 </p>
13516
13517 <blockquote>
13518 <p>
13519 Changae in para. 2
13520 </p>
13521
13522 <blockquote>
13523 Constructs a <tt>discrete_distribution</tt> object with <tt>n=1</tt> and <tt>p<sub>0</sub> <ins>= w<sub>0</sub></ins> = 1</tt>
13524 </blockquote>
13525
13526 <p>
13527 and change in para. 5
13528 </p>
13529
13530 <blockquote>
13531 <i>Returns:</i> A <tt>vector&lt;double&gt;</tt> whose <tt>size</tt> member returns <tt>n</tt> and whose
13532 <tt>operator[]</tt> member returns <del><tt>p<sub>k</sub></tt></del>
13533 <ins>the weight <tt>w<sub>k</sub></tt> as a double value</ins>
13534 when invoked with argument <tt>k</tt> for <tt>k = 0,
13535 ..., n-1</tt>
13536 </blockquote>
13537
13538 </blockquote>
13539
13540 <p>
13541 Proposed wording b):
13542 </p>
13543
13544 <blockquote>
13545 <p>
13546 Change in para. 3:
13547 </p>
13548
13549 <blockquote>
13550 If <tt>firstW == lastW</tt>, let the sequence <tt>w</tt> have length <tt>n = 1</tt> and consist
13551 of the single value <tt>w<sub>0</sub> = 1</tt>. Otherwise, <tt>[firstW,lastW)</tt> shall form a
13552 sequence <tt>w</tt> of length <tt>n <del>&gt; 0</del></tt>
13553 <ins>such that <tt>0 &lt; n &lt;= numeric_limits&lt;IntType&gt;::max()</tt>,</ins>
13554 and <tt>*firstW</tt> shall yield a value <tt>w<sub>0</sub></tt>
13555 convertible to <tt>double</tt>. [<i>Note:</i> The values <tt>w<sub>k</sub></tt> are commonly known
13556 as the weights . <i>-- end note</i>]
13557 </blockquote>
13558
13559 </blockquote>
13560
13561 </blockquote>
13562
13563
13564
13565
13566
13567 <hr>
13568 <h3><a name="737"></a>737. Comment on [rand.dist.samp.pconst]</h3>
13569 <p><b>Section:</b> 26.5.8.5.2 [rand.dist.samp.pconst] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
13570  <b>Submitter:</b> Stephan Tolksdorf <b>Opened:</b> 2007-09-21  <b>Last modified:</b> 2008-02-27</p>
13571 <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>
13572 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
13573 <p><b>Discussion:</b></p>
13574 <ol type="a">
13575 <li>
13576 The discussion in point T11 above regarding <tt>probabilities()</tt> similarly applies
13577 to the method <tt>densities()</tt> of <tt>piecewise_constant_distribution</tt>.
13578 </li>
13579 <li>
13580 <p>
13581 The design of the constructor
13582 </p>
13583 <blockquote><pre>template &lt;class InputIteratorB, class InputIteratorW&gt;
13584 piecewise_constant_distribution( InputIteratorB firstB, InputIteratorB lastB,
13585                                  InputIteratorW firstW);
13586 </pre></blockquote>
13587 <p>
13588 is unnecessarily unsafe, as there is no separate end-iterator given for the weights. I can't see
13589 any performance or convenience reasons that would justify the risks inherent in such a function
13590 interface, in particular the risk that input error might go unnoticed.
13591 </p>
13592 </li>
13593 </ol>
13594
13595 <p>
13596 <b>Possible resolution:</b> I propose to add an <tt>InputIteratorW lastW</tt> argument to the interface.
13597 </p>
13598
13599 <p><i>[
13600 Stephan Tolksdorf adds pre-Bellevue:
13601 ]</i></p>
13602
13603 <blockquote>
13604 In reply to the discussion in
13605 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
13606 I'd like to make the same comments as for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#736">736</a>.
13607 </blockquote>
13608
13609 <p><i>[
13610 Bellevue:
13611 ]</i></p>
13612
13613
13614 <blockquote>
13615 In N2424. There is already precedent elsewhere in the library. Follows existing convention. NAD.
13616 </blockquote>
13617
13618
13619 <p><b>Proposed resolution:</b></p>
13620 <p>
13621 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
13622 for the proposed resolution.
13623 </p>
13624
13625 <p><i>[
13626 Stephan Tolksdorf adds pre-Bellevue:
13627 ]</i></p>
13628
13629
13630 <blockquote>
13631 <p>
13632 In 26.5.8.5.2 [rand.dist.samp.pconst]:
13633 </p>
13634
13635 <p>
13636 Proposed wording a)
13637 </p>
13638
13639 <blockquote>
13640 <p>
13641 Change in para. 2
13642 </p>
13643 <blockquote>
13644 Constructs a <tt>piecewise_constant_distribution</tt> object with <tt>n = 1</tt>, <tt>p<sub>0</sub> <ins>= w<sub>0</sub></ins> = 1</tt>,
13645 <tt>b<sub>0</sub> = 0</tt>, and <tt>b<sub>1</sub> = 1</tt>
13646 </blockquote>
13647
13648 <p>
13649 and change in para. 5
13650 </p>
13651
13652 <blockquote>
13653 A <tt>vector&lt;result_type&gt;</tt> whose <tt>size</tt> member returns <tt>n</tt> and whose <tt>operator[]</tt>
13654 member returns <del><tt>p<sub>k</sub></tt></del>
13655 <ins>the weight <tt>w<sub>k</sub></tt> as a double value</ins>
13656 when invoked with argument <tt>k</tt> for <tt>k = 0, ..., n-1</tt>
13657 </blockquote>
13658
13659 </blockquote>
13660
13661 <p>
13662 Proposed wording b)
13663 </p>
13664
13665 <blockquote>
13666 <p>
13667 Change both occurrences of
13668 </p>
13669
13670 <blockquote>
13671 "piecewise_constant_distribution(InputIteratorB firstB, InputIteratorB lastB,
13672                                  InputIteratorW firstW<ins>, InputIteratorW lastW</ins>)
13673 </blockquote>
13674
13675 <p>
13676 and change in para. 3
13677 </p>
13678
13679 <blockquote>
13680 <del>the length of the sequence <tt>w</tt> starting from <tt>firstW</tt> shall be at least <tt>n</tt>,
13681 <tt>*firstW</tt> shall return a value <tt>w<sub>0</sub></tt> that is convertible to <tt>double</tt>, and any
13682 <tt>w<sub>k</sub></tt> for <tt>k &gt;= n</tt> shall be ignored by the distribution</del>
13683 <ins><tt>[firstW, lastW)</tt> shall form a sequence <tt>w</tt> of length <tt>n</tt> whose leading element
13684 <tt>w<sub>0</sub></tt> shall be convertible to <tt>double</tt></ins>
13685 </blockquote>
13686
13687 </blockquote>
13688
13689
13690 </blockquote>
13691
13692
13693
13694
13695
13696
13697 <hr>
13698 <h3><a name="738"></a>738. Editorial issue in [rand.adapt.disc]/3</h3>
13699 <p><b>Section:</b> 26.5.4.1 [rand.adapt.disc] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
13700  <b>Submitter:</b> Stephan Tolksdorf <b>Opened:</b> 2007-09-21  <b>Last modified:</b> 2008-09-22</p>
13701 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
13702 <p><b>Discussion:</b></p>
13703 <p>
13704 Since the template parameter <tt>p</tt> and <tt>r</tt> are of type <tt>size_t</tt>, the member <tt>n</tt> in the class
13705 exposition should have type <tt>size_t</tt>, too.
13706 </p>
13707
13708
13709 <p><b>Proposed resolution:</b></p>
13710 <p>
13711 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
13712 for the proposed resolution.
13713 </p>
13714
13715
13716
13717
13718
13719 <hr>
13720 <h3><a name="739"></a>739. Defect in [rand.util.canonical]/3</h3>
13721 <p><b>Section:</b> 26.5.7.2 [rand.util.canonical] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
13722  <b>Submitter:</b> Stephan Tolksdorf <b>Opened:</b> 2007-09-21  <b>Last modified:</b> 2008-02-27</p>
13723 <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>
13724 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
13725 <p><b>Discussion:</b></p>
13726 <p>
13727 The complexity of <tt>generate_canonical</tt> is specified to be "exactly k=max(1, ceil(b/log2
13728 R)) invocations of g". This terms involves a logarithm that is not rounded and hence can not (in
13729 general) be computed at compile time. As this function template is performance critical, I propose
13730 to replace ceil(b/log2 R) with ceil(b/floor(log2 R)).
13731 </p>
13732
13733 <p>
13734 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
13735 for further discussion.
13736 </p>
13737
13738 <p><i>[
13739 Bellevue:
13740 ]</i></p>
13741
13742
13743 <blockquote>
13744 In N2424. Close NAD as described there.
13745 </blockquote>
13746
13747
13748
13749 <p><b>Proposed resolution:</b></p>
13750 <p>
13751 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
13752 for the proposed resolution.
13753 </p>
13754
13755
13756
13757
13758
13759 <hr>
13760 <h3><a name="741"></a>741. Const-incorrect <tt>get_deleter</tt> function for <tt>shared_ptr</tt></h3>
13761 <p><b>Section:</b> 20.8.13.2.11 [util.smartptr.getdeleter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
13762  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-09-27  <b>Last modified:</b> 2008-02-27</p>
13763 <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>
13764 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
13765 <p><b>Discussion:</b></p>
13766 <p>
13767 The following issue was raised by Alf P. Steinbach in c.l.c++.mod:
13768 </p>
13769
13770 <p>
13771 According to the recent draft N2369, both the header memory synopsis
13772 of 20.8 [memory] and 20.8.13.2.11 [util.smartptr.getdeleter] declare:
13773 </p>
13774
13775 <blockquote><pre>template&lt;class D, class T&gt; D* get_deleter(shared_ptr&lt;T&gt; const&amp; p);
13776 </pre></blockquote>
13777
13778 <p>
13779 This allows to retrieve the pointer to a mutable deleter of a <tt>const
13780 shared_ptr</tt> (if that owns one) and therefore contradicts the usual
13781 philosophy that associated functors are either read-only (e.g.
13782 <tt>key_comp</tt> or <tt>value_comp</tt> of <tt>std::map</tt>) or do at least reflect
13783 the mutability of the owner (as seen for the both overloads of
13784 <tt>unique_ptr::get_deleter</tt>).
13785 Even the next similar counter-part of <tt>get_deleter</tt> - the two
13786 overloads of <tt>function::target</tt> in the class template function
13787 synopsis 20.7.16.2 [func.wrap.func] or in 20.7.16.2.5 [func.wrap.func.targ] - do
13788 properly mirror the const-state of the owner.
13789 </p>
13790
13791 <b>Possible proposed resolutions:</b>
13792
13793 <p>
13794 Replace the declarations of <tt>get_deleter</tt> in the header <tt>&lt;memory&gt;</tt>
13795 synopsis of 20.8 [memory] and in 20.8.13.2.11 [util.smartptr.getdeleter] by one of the
13796 following alternatives (A) or (B):
13797 </p>
13798
13799 <ol type="A">
13800 <li>
13801 Provide <b>only</b> the immutable variant. This would reflect the
13802 current praxis of <tt>container::get_allocator()</tt>, <tt>map::key_comp()</tt>, or
13803 <tt>map::value_comp</tt>.
13804
13805 <blockquote><pre>template&lt;class D, class T&gt; const D* get_deleter(shared_ptr&lt;T&gt; const&amp; p);
13806 </pre></blockquote>
13807 </li>
13808 <li>
13809 Just remove the function.
13810 </li>
13811 </ol>
13812
13813 <p>
13814 Alberto Ganesh Barbati adds:
13815 </p>
13816
13817 <ol start="3" type="A">
13818 <li>
13819 <p>
13820 Replace it with two functions:
13821 </p>
13822 <blockquote><pre>template &lt;class D, class T&gt; D get_deleter(shared_ptr&lt;T&gt; const&amp;);
13823 template &lt;class D, class T&gt; bool has_deleter(shared_ptr&lt;T&gt; const&amp;);
13824 </pre></blockquote>
13825
13826 <p>
13827 The first one would throw if <tt>D</tt> is the wrong type, while the latter would
13828 never throw. This approach would reflect the current praxis of
13829 <tt>use_facet/has_facet</tt>, with the twist of returning the deleter by value as
13830 <tt>container::get_allocator()</tt> do.
13831 </p>
13832 </li>
13833 </ol>
13834
13835 <p>
13836 Peter Dimov adds:
13837 </p>
13838
13839 <blockquote>
13840 <p>
13841 My favorite option is "not a defect". A, B and C break useful code.
13842 </p>
13843 </blockquote>
13844
13845 <p><i>[
13846 Bellevue:
13847 ]</i></p>
13848
13849
13850 <blockquote>
13851 Concern this is similar to confusing "pointer to const" with "a constant pointer".
13852 </blockquote>
13853
13854
13855 <p><b>Proposed resolution:</b></p>
13856 <p>
13857 </p>
13858
13859
13860
13861
13862
13863 <hr>
13864 <h3><a name="742"></a>742. Enabling <tt>swap</tt> for proxy iterators</h3>
13865 <p><b>Section:</b> X [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
13866  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2007-10-10  <b>Last modified:</b> 2008-09-26</p>
13867 <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>
13868 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
13869 <p><b>Discussion:</b></p>
13870 <p>
13871 This issue was split from <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>. <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a> now just
13872 deals with changing the requirements of <tt>T</tt> in the <tt>Swappable</tt>
13873 requirement from <tt>CopyConstructible</tt> and <tt>CopyAssignable</tt> to
13874 <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt>.
13875 </p>
13876
13877 <p>
13878 This issue seeks to widen the <tt>Swappable</tt> requirement to support proxy iterators.  Here
13879 is example code:
13880 </p>
13881
13882 <blockquote><pre>namespace Mine {
13883
13884 template &lt;class T&gt;
13885 struct proxy {...};
13886
13887 template &lt;class T&gt;
13888 struct proxied_iterator
13889 {
13890    typedef T value_type;
13891    typedef proxy&lt;T&gt; reference;
13892    reference operator*() const;
13893    ...
13894 };
13895
13896 struct A
13897 {
13898    // heavy type, has an optimized swap, maybe isn't even copyable or movable, just swappable
13899    void swap(A&amp;);
13900    ...
13901 };
13902
13903 void swap(A&amp;, A&amp;);
13904 void swap(proxy&lt;A&gt;, A&amp;);
13905 void swap(A&amp;, proxy&lt;A&gt;);
13906 void swap(proxy&lt;A&gt;, proxy&lt;A&gt;);
13907
13908 }  // Mine
13909
13910 ...
13911
13912 Mine::proxied_iterator&lt;Mine::A&gt; i(...)
13913 Mine::A a;
13914 <b>swap(*i1, a);</b>
13915 </pre></blockquote>
13916
13917 <p>
13918 The key point to note in the above code is that in the call to <tt>swap</tt>, <tt>*i1</tt>
13919 and <tt>a</tt> are different types (currently types can only be <tt>Swappable</tt> with the
13920 same type).  A secondary point is that to support proxies, one must be able to pass rvalues
13921 to <tt>swap</tt>.  But note that I am not stating that the general purpose <tt>std::swap</tt>
13922 should accept rvalues!  Only that overloaded <tt>swap</tt>s, as in the example above, be allowed
13923 to take rvalues.
13924 </p>
13925
13926 <p>
13927 That is, no standard library code needs to change.  We simply need to have a more flexible
13928 definition of <tt>Swappable</tt>.
13929 </p>
13930
13931 <p><i>[
13932 Bellevue:
13933 ]</i></p>
13934
13935
13936 <blockquote>
13937 <p>
13938 While we believe Concepts work will define a swappable concept, we
13939 should still resolve this issue if possible to give guidance to the
13940 Concepts work.
13941 </p>
13942 <p>
13943 Would an ambiguous swap function in two namespaces found by ADL break
13944 this wording? Suggest that the phrase "valid expression" means such a
13945 pair of types would still not be swappable.
13946 </p>
13947 <p>
13948 Motivation is proxy-iterators, but facility is considerably more
13949 general. Are we happy going so far?
13950 </p>
13951 <p>
13952 We think this wording is probably correct and probably an improvement on
13953 what's there in the WP. On the other hand, what's already there in the
13954 WP is awfully complicated. Why do we need the two bullet points? They're
13955 too implementation-centric. They don't add anything to the semantics of
13956 what swap() means, which is there in the post-condition. What's wrong
13957 with saying that types are swappable if you can call swap() and it
13958 satisfies the semantics of swapping?
13959 </p>
13960 </blockquote>
13961
13962
13963
13964 <p><b>Proposed resolution:</b></p>
13965 <p>
13966 Change X [utility.arg.requirements]:
13967 </p>
13968
13969 <blockquote>
13970
13971 <p>
13972 -1- The template definitions in the C++ Standard Library refer to various
13973 named requirements whose details are set out in tables 31-38. In these
13974 tables, <tt>T</tt> <ins>and <tt>V</tt> are</ins> <del>is a</del> type<ins>s</ins> to be supplied by a C++ program
13975 instantiating a template; <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> are
13976 values of type <tt>const T</tt>; <tt>s</tt> and <tt>t</tt> are modifiable
13977 lvalues of type <tt>T</tt>; <tt>u</tt> is a value of type (possibly
13978 <tt>const</tt>) <tt>T</tt>; <del>and</del> <tt>rv</tt> is a non-<tt>const</tt>
13979 rvalue of type <tt>T</tt><ins>; <tt>w</tt> is a value of type <tt>T</tt>; and <tt>v</tt> is a value of type <tt>V</tt></ins>.
13980 </p>
13981
13982 <table border="1">
13983 <caption>Table 37: <tt>Swappable</tt> requirements <b>[swappable]</b></caption>
13984 <tbody><tr><th>expression</th><th>return type</th><th>post-condition</th></tr>
13985 <tr><td><tt>swap(<del>s</del><ins>w</ins>,<del>t</del><ins>v</ins>)</tt></td><td><tt>void</tt></td>
13986 <td><del><tt>t</tt></del><ins><tt>w</tt></ins> has the value originally
13987 held by <del><tt>u</tt></del><ins><tt>v</tt></ins>, and
13988 <del><tt>u</tt></del><ins><tt>v</tt></ins> has the value originally held
13989 by <del><tt>t</tt></del><ins><tt>w</tt></ins></td></tr>
13990 <tr><td colspan="3">
13991 <p>
13992 The <tt>Swappable</tt> requirement is met by satisfying one or more of the following conditions:
13993 </p>
13994 <ul>
13995 <li>
13996 <tt>T</tt> is <tt>Swappable</tt> if <ins><tt>T</tt> and <tt>V</tt> are
13997 the same type and </ins> <tt>T</tt> satisfies the
13998 <del><tt>CopyConstructible</tt></del>
13999 <ins><tt>MoveConstructible</tt></ins> requirements (Table <del>34</del>
14000 <ins>33</ins>) and the <del><tt>CopyAssignable</tt></del>
14001 <ins><tt>MoveAssignable</tt></ins> requirements (Table <del>36</del>
14002 <ins>35</ins>);
14003 </li>
14004 <li>
14005 <tt>T</tt> is <tt>Swappable</tt> <ins>with <tt>V</tt></ins> if a namespace scope function named
14006 <tt>swap</tt> exists in the same namespace as the definition of
14007 <tt>T</tt> <ins>or <tt>V</tt></ins>, such that the expression
14008 <tt>swap(<del>t</del><ins>w</ins>,<del>u</del> <ins>v</ins>)</tt> is valid and has the
14009 semantics described in this table.
14010 </li>
14011 </ul>
14012 </td></tr>
14013 </tbody></table>
14014 </blockquote>
14015
14016
14017
14018 <p><b>Rationale:</b></p>
14019 <p><i>[
14020 post San Francisco:
14021 ]</i></p>
14022
14023
14024 <blockquote>
14025 Solved by
14026 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2758.pdf">N2758</a>.
14027 </blockquote>
14028
14029
14030
14031
14032
14033
14034 <hr>
14035 <h3><a name="745"></a>745. copy_exception API slices.</h3>
14036 <p><b>Section:</b> 18.8.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
14037  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2007-10-10  <b>Last modified:</b> 2008-02-25</p>
14038 <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>
14039 <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>
14040 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
14041 <p><b>Discussion:</b></p>
14042 <p>
14043 It could be I did not understand the design rationale, but I thought
14044 copy_exception would produce an exception_ptr to the most-derived (dynamic)
14045 type of the passed exception.  Instead it slices, which appears to be less
14046 useful, and a likely source of FAQ questions in the future.
14047 </p>
14048 <p>
14049 (Peter Dimov suggests NAD)
14050 </p>
14051
14052 <p><i>[
14053 Bellevue:
14054 ]</i></p>
14055
14056
14057 <blockquote>
14058 <p>
14059 How could this be implemented in a way that the dynamic type is cloned?
14060 </p>
14061 <p>
14062 The feature is designed to create an exception_ptr from an object whose
14063 static type is identical to the dynamic type and thus there is no
14064 slicing involved.
14065 </p>
14066 </blockquote>
14067
14068
14069 <p><b>Proposed resolution:</b></p>
14070 <p>
14071 </p>
14072
14073
14074
14075
14076
14077 <hr>
14078 <h3><a name="748"></a>748. The is_abstract type trait is defined by reference to 10.4.</h3>
14079 <p><b>Section:</b> 20.6.4.3 [meta.unary.prop] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
14080  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2007-10-10  <b>Last modified:</b> 2009-05-01</p>
14081 <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>
14082 <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>
14083 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
14084 <p><b>Discussion:</b></p>
14085 <p>
14086 I am trying to decide is a pure virtual function is a <i>necessary</i> as well as
14087 sufficient requirement to be classified as abstract?
14088 </p>
14089 <p>
14090 For instance, is the following (non-polymorphic) type considered abstract?
14091 </p>
14092 <blockquote><pre>struct abstract {
14093 protected:
14094  abstract(){}
14095  abstract( abstract const &amp; ) {}
14096  ~abstract() {}
14097 };
14098 </pre></blockquote>
14099 <p>
14100 (Suggested that this may be NAD, with an editorial fix-up from Pete on the
14101 core wording to make clear that abstract requires a pure virtual function)
14102 </p>
14103
14104
14105 <p><b>Proposed resolution:</b></p>
14106 <p>
14107 Core has clarified that the definition abstract is adequate. Issue withdrawn by submitter. NAD.
14108 </p>
14109
14110
14111
14112
14113
14114 <hr>
14115 <h3><a name="754"></a>754. Ambiguous return clause for <tt>std::uninitialized_copy</tt></h3>
14116 <p><b>Section:</b> 20.8.11.2 [uninitialized.copy] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
14117  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-10-15  <b>Last modified:</b> 2008-07-02</p>
14118 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#uninitialized.copy">issues</a> in [uninitialized.copy].</p>
14119 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
14120 <p><b>Discussion:</b></p>
14121 <p>
14122 14882-2003, [lib.uninitialized.copy] is currently written as follows:
14123 </p>
14124
14125 <blockquote>
14126 <pre>template &lt;class InputIterator, class ForwardIterator&gt;
14127   ForwardIterator uninitialized_copy(InputIterator <i>first</i>, InputIterator <i>last</i>,
14128                                      ForwardIterator <i>result</i>);
14129 </pre>
14130 <blockquote>
14131 <p>
14132 -1- <i>Effects:</i>
14133 </p>
14134 <blockquote><pre>for (; first != last; ++result, ++first)
14135   new (static_cast&lt;void*&gt;(&amp;*result))
14136     typename iterator_traits&lt;ForwardIterator&gt;::value_type(*first);
14137 </pre></blockquote>
14138 <p>
14139 -2- <i>Returns:</i> <tt><i>result</i></tt>
14140 </p>
14141 </blockquote>
14142 </blockquote>
14143
14144 <p>
14145 similarily for N2369, and its corresponding section
14146 20.8.11.2 [uninitialized.copy].
14147 </p>
14148
14149 <p>
14150 It's not clear to me what the return clause is supposed to mean, I see
14151 two
14152 possible interpretations:
14153 </p>
14154
14155 <ol type="a">
14156 <li>
14157 The notion of <tt><i>result</i></tt> is supposed to mean the value given by the
14158 function parameter <tt><i>result</i></tt> [Note to the issue editor: Please use italics for
14159 <tt><i>result</i></tt>].
14160 This seems somewhat implied by recognizing that both the function
14161 parameter
14162 and the name used in the clause do have the same italic font.
14163 </li>
14164 <li>
14165 The notion of "result" is supposed to mean the value of <tt><i>result</i></tt>
14166 after the
14167 preceding effects clause. This is in fact what all implementations I
14168 checked
14169 do (and which is probably it's intend, because it matches the
14170 specification of <tt>std::copy</tt>).
14171 </li>
14172 </ol>
14173
14174 <p>
14175 The problem is: I see nothing in the standard which grants that this
14176 interpretation
14177 is correct, specifically [lib.structure.specifications] or
14178 17.5.1.4 [structure.specifications]
14179 resp. do not clarify which "look-up" rules apply for names found in
14180 the elements
14181 of the detailed specifications - Do they relate to the corresponding
14182 synopsis or
14183 to the effects clause (or possibly other elements)? Fortunately most
14184 detailed
14185 descriptions are unambigious in this regard, e.g. this problem does
14186 not apply
14187 for <tt>std::copy</tt>.
14188 </p>
14189
14190
14191
14192 <p><b>Proposed resolution:</b></p>
14193 <p>
14194 Change the wording of the return clause to say (20.8.11.2 [uninitialized.copy]):
14195 </p>
14196
14197 <blockquote>
14198 <p>
14199 -2- <i>Returns:</i> <ins>The value of</ins> <tt><i>result</i></tt> <ins>after effects have taken place.</ins>
14200 </p>
14201 </blockquote>
14202
14203
14204 <p><i>[
14205 Bellevue:
14206 ]</i></p>
14207
14208
14209 <blockquote>
14210 Resolution: NAD editorial -- project editor to decide if change is
14211 worthwhile. Concern is that there are many other places this might
14212 occur.
14213 </blockquote>
14214
14215
14216
14217
14218 <hr>
14219 <h3><a name="756"></a>756. Container adaptors push</h3>
14220 <p><b>Section:</b> 23.3.5 [container.adaptors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
14221  <b>Submitter:</b> Paolo Carlini <b>Opened:</b> 2007-10-31  <b>Last modified:</b> 2008-06-18</p>
14222 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
14223 <p><b>Discussion:</b></p>
14224 <p>
14225 After n2369 we have a single <tt>push_back</tt> overload in the sequence containers,
14226 of the "emplace" type. At variance with that, still in n2461, we have
14227 two separate overloads, the C++03 one + one taking an rvalue reference
14228 in the container adaptors. Therefore, simply from a consistency point of
14229 view, I was wondering whether the container adaptors should be aligned
14230 with the specifications of the sequence container themselves: thus have
14231 a single <tt>push</tt> along the lines:
14232 </p>
14233
14234 <blockquote><pre>template&lt;typename... _Args&gt;
14235 void
14236 push(_Args&amp;&amp;... __args)
14237   { c.push_back(std::forward&lt;_Args&gt;(__args)...); }
14238 </pre></blockquote>
14239
14240 <p><i>[
14241 Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>
14242 ]</i></p>
14243
14244
14245
14246 <p><b>Proposed resolution:</b></p>
14247 <p>
14248 Change 23.3.5.1.1 [queue.defn]:
14249 </p>
14250
14251 <blockquote><pre><del>void push(const value_type&amp; x) { c.push_back(x); }</del>
14252 <del>void push(value_type&amp;&amp; x) { c.push_back(std::move(x)); }</del>
14253 <ins>template&lt;class... Args&gt; void push(Args&amp;&amp;... args) { c.push_back(std::forward&lt;Args&gt;(args)...); }</ins>
14254 </pre></blockquote>
14255
14256 <p>
14257 Change 23.3.5.2 [priority.queue]:
14258 </p>
14259
14260 <blockquote><pre><del>void push(const value_type&amp; x) { c.push_back(x); }</del>
14261 <del>void push(value_type&amp;&amp; x) { c.push_back(std::move(x)); }</del>
14262 <ins>template&lt;class... Args&gt; void push(Args&amp;&amp;... args) { c.push_back(std::forward&lt;Args&gt;(args)...); }</ins>
14263 </pre></blockquote>
14264
14265 <p>
14266 Change 23.3.5.2.2 [priqueue.members]:
14267 </p>
14268
14269 <blockquote>
14270 <pre><del>void push(const value_type&amp; x);</del>
14271 </pre>
14272 <blockquote>
14273 <p>
14274 <del><i>Effects:</i></del>
14275 </p>
14276 <blockquote><pre><del>c.push_back(x);</del>
14277 <del>push_heap(c.begin(), c.end(), comp);</del>
14278 </pre></blockquote>
14279 </blockquote>
14280
14281 <pre><ins>template&lt;class... Args&gt;</ins> void push(<del>value_type</del> <ins>Args</ins>&amp;&amp;<ins>...</ins> <del>x</del> <ins>args</ins>);
14282 </pre>
14283 <blockquote>
14284 <p>
14285 <i>Effects:</i>
14286 </p>
14287 <blockquote><pre>c.push_back(std::<del>move</del><ins>forward&lt;Args&gt;</ins>(<del>x</del> <ins>args</ins>)<ins>...</ins>);
14288 push_heap(c.begin(), c.end(), comp);
14289 </pre></blockquote>
14290 </blockquote>
14291 </blockquote>
14292
14293 <p>
14294 Change 23.3.5.3.1 [stack.defn]:
14295 </p>
14296
14297 <blockquote><pre><del>void push(const value_type&amp; x) { c.push_back(x); }</del>
14298 <del>void push(value_type&amp;&amp; x) { c.push_back(std::move(x)); }</del>
14299 <ins>template&lt;class... Args&gt; void push(Args&amp;&amp;... args) { c.push_back(std::forward&lt;Args&gt;(args)...); }</ins>
14300 </pre></blockquote>
14301
14302
14303
14304 <p><b>Rationale:</b></p>
14305 <p>
14306 Addressed by
14307 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2680.pdf">N2680 Proposed Wording for Placement Insert (Revision 1)</a>.
14308 </p>
14309
14310
14311
14312
14313
14314 <hr>
14315 <h3><a name="757"></a>757. Typo in the synopsis of vector</h3>
14316 <p><b>Section:</b> 23.3.6 [vector] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
14317  <b>Submitter:</b> Paolo Carlini <b>Opened:</b> 2007-11-04  <b>Last modified:</b> 2008-07-02</p>
14318 <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>
14319 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
14320 <p><b>Discussion:</b></p>
14321 <p>
14322 In the synopsis 23.3.6 [vector], there is the signature:
14323 </p>
14324
14325 <blockquote><pre>void insert(const_iterator position, size_type n, T&amp;&amp; x);
14326 </pre></blockquote>
14327
14328 <p>
14329 instead of:
14330 </p>
14331
14332 <blockquote><pre>iterator insert(const_iterator position, T&amp;&amp; x);
14333 </pre></blockquote>
14334
14335 <p>
14336 23.3.6.4 [vector.modifiers] is fine.
14337 </p>
14338
14339
14340
14341 <p><b>Proposed resolution:</b></p>
14342 <p>
14343 Change the synopsis in 23.3.6 [vector]:
14344 </p>
14345
14346 <blockquote><pre>iterator insert(const_iterator position, const T&amp; x);
14347 <ins>iterator insert(const_iterator position, T&amp;&amp; x);</ins>
14348 void     insert(const_iterator position, size_type n, const T&amp; x);
14349 <del>void     insert(const_iterator position, size_type n, T&amp;&amp; x);</del>
14350 </pre></blockquote>
14351
14352
14353
14354
14355
14356 <hr>
14357 <h3><a name="763"></a>763. Renaming <tt>emplace()</tt> overloads</h3>
14358 <p><b>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
14359  <b>Submitter:</b> Sylvain Pion <b>Opened:</b> 2007-12-04  <b>Last modified:</b> 2008-03-12</p>
14360 <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>
14361 <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>
14362 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
14363 <p><b>Discussion:</b></p>
14364 <p>
14365 The associative containers provide 2 overloads of <tt>emplace()</tt>:
14366 </p>
14367
14368 <blockquote><pre>template &lt;class... Args&gt; pair&lt;iterator, bool&gt; emplace(Args&amp;&amp;... args);
14369 template &lt;class... Args&gt; iterator emplace(const_iterator position, Args&amp;&amp;... args);
14370 </pre></blockquote>
14371
14372 <p>
14373 This is a problem if you mean the first overload while passing
14374 a <tt>const_iterator</tt> as first argument.
14375 </p>
14376
14377 <p><i>[
14378 Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>
14379 ]</i></p>
14380
14381
14382 <p><i>[
14383 Bellevue:
14384 ]</i></p>
14385
14386
14387 <blockquote>
14388 </blockquote>
14389 <p>
14390 This can be disambiguated by passing "begin" as the first argument in
14391 the case when the non-default choice is desired. We believe that desire
14392 will be rare.
14393 </p>
14394 <p>
14395 Resolution: Change state to NAD.
14396 </p>
14397
14398
14399 <p><b>Proposed resolution:</b></p>
14400 <p>
14401 Rename one of the two overloads.
14402 For example to <tt>emplace_here</tt>, <tt>hint_emplace</tt>...
14403 </p>
14404
14405
14406
14407
14408
14409 <hr>
14410 <h3><a name="764"></a>764. <tt>equal_range</tt> on unordered containers should return a <tt>pair</tt> of <tt>local_iterators</tt></h3>
14411 <p><b>Section:</b> 23.2.5 [unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
14412  <b>Submitter:</b> Joe Gottman <b>Opened:</b> 2007-11-29  <b>Last modified:</b> 2008-03-12</p>
14413 <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>
14414 <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>
14415 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
14416 <p><b>Discussion:</b></p>
14417 <p>
14418     A major attribute of the unordered containers is that iterating
14419 though them inside a bucket is very fast while iterating between buckets
14420 can be much slower.  If an unordered container has a low load factor,
14421 iterating between the last iterator in one bucket and the next iterator,
14422 which is in another bucket, is <tt>O(bucket_count())</tt> which may be much
14423 larger than <tt>O(size())</tt>.
14424 </p>
14425 <p>
14426     If <tt>b</tt> is an non-const unordered container of type <tt>B</tt> and <tt>k</tt> is an
14427 object of it's <tt>key_type</tt>, then <tt>b.equal_range(k)</tt> currently returns
14428 <tt>pair&lt;B::iterator, B::iterator&gt;</tt>. Consider the following code:
14429 </p>
14430
14431 <blockquote><pre>B::iterator lb, ub;
14432 tie(lb, ub) = b.equal_range(k);
14433 for (B::iterator it = lb; it != ub; ++it) {
14434         // Do something with *it
14435 }
14436 </pre></blockquote>
14437
14438 <p>
14439 If <tt>b.equal_range(k)</tt> returns a non-empty range (i.e. <tt>b</tt> contains at least
14440 on element whose key is equivalent to <tt>k</tt>), then every iterator in the
14441 half-open range <tt>[lb, ub)</tt> will be in the same bucket, but <tt>ub</tt> will likely
14442 either be in a different bucket or be equal to <tt>b.end()</tt>.  In either case,
14443 iterating between <tt>ub - 1</tt> and <tt>ub</tt> could take a much longer time than
14444 iterating through the rest of the range.
14445 </p>
14446 <p>
14447 If instead of returning <tt>pair&lt;iterator, iterator&gt;</tt>, <tt>equal_range</tt> were to
14448 return <tt>pair&lt;local_iterator, local_iterator&gt;</tt>, then <tt>ub</tt> (which, like <tt>lb</tt>,
14449 would now be a <tt>local_iterator</tt>) could be guaranteed to always be in the
14450 same bucket as <tt>lb</tt>. In the cases where currently <tt>ub</tt> is equal to <tt>b.end()</tt>
14451 or is in a different bucket, <tt>ub</tt> would be equal to <tt>b.end(b.bucket(key))</tt>.
14452   This would make iterating between <tt>lb</tt> and <tt>ub</tt> much faster, as every
14453 iteration would be constant time.
14454 </p>
14455
14456 <p><i>[
14457 Bellevue:
14458 ]</i></p>
14459
14460
14461 <blockquote>
14462 The proposed resolution breaks consistency with other container types
14463 for dubious benefit, and iterators are already constant time.
14464 </blockquote>
14465
14466
14467
14468 <p><b>Proposed resolution:</b></p>
14469 <p>
14470 Change the entry for <tt>equal_range</tt> in Table 93 (23.2.5 [unord.req]) as follows:
14471 </p>
14472 <table border="1">
14473 <tbody><tr>
14474 <th>expression</th> <th>return type</th> <th>assertion/note pre/post-condition</th> <th>complexity</th>
14475 </tr>
14476
14477 <tr>
14478 <td><tt>b.equal_range(k)</tt></td>
14479 <td><tt>pair&lt;<ins>local_</ins>iterator,<ins>local_</ins>iterator&gt;; pair&lt;const_<ins>local_</ins>iterator,const_<ins>local_</ins>iterator&gt;</tt> for <tt>const b</tt>.</td>
14480 <td>Returns a range containing all elements with keys equivalent to <tt>k</tt>. Returns <tt>make_pair(b.end(<ins>b.bucket(key)</ins>),b.end(<ins>b.bucket(key)</ins>))</tt> if no such elements exist.</td>
14481 <td>Average case &#920;<tt>(b.count(k))</tt>. Worst case &#920;<tt>(b.size())</tt>. </td>
14482 </tr>
14483 </tbody></table>
14484
14485
14486
14487
14488
14489 <hr>
14490 <h3><a name="767"></a>767. Forwarding and backward compatibility</h3>
14491 <p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
14492  <b>Submitter:</b> Sylvain Pion <b>Opened:</b> 2007-12-28  <b>Last modified:</b> 2008-06-18</p>
14493 <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>
14494 <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>
14495 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
14496 <p><b>Discussion:</b></p>
14497 <p>
14498 Playing with g++'s C++0X mode, I noticed that the following
14499 code, which used to compile:
14500 </p>
14501
14502 <blockquote><pre>#include &lt;vector&gt;
14503
14504 int main()
14505 {
14506     std::vector&lt;char *&gt; v;
14507     v.push_back(0);
14508 }
14509 </pre></blockquote>
14510
14511 <p>
14512 now fails with the following error message:
14513 </p>
14514
14515 <blockquote>.../include/c++/4.3.0/ext/new_allocator.h: In member
14516 function 'void __gnu_cxx::new_allocator&lt;_Tp&gt;::construct(_Tp*,
14517 _Args&amp;&amp; ...) [with _Args = int, _Tp = char*]':
14518 .../include/c++/4.3.0/bits/stl_vector.h:707: instantiated from 'void
14519 std::vector&lt;_Tp, _Alloc&gt;::push_back(_Args&amp;&amp; ...) [with
14520 _Args = int, _Tp = char*, _Alloc = std::allocator&lt;char*&gt;]'
14521 test.cpp:6: instantiated from here
14522 .../include/c++/4.3.0/ext/new_allocator.h:114: error: invalid
14523 conversion from 'int' to 'char*'
14524 </blockquote>
14525
14526 <p>
14527 As far as I know, g++ follows the current draft here.
14528 </p>
14529 <p>
14530 Does the committee really intend to break compatibility for such cases?
14531 </p>
14532
14533 <p><i>[
14534 Sylvain adds:
14535 ]</i></p>
14536
14537
14538 <blockquote>
14539 <p>
14540 I just noticed that <tt>std::pair</tt> has the same issue.
14541 The following now fails with GCC's -std=c++0x mode:
14542 </p>
14543
14544 <blockquote><pre>#include &lt;utility&gt;
14545
14546 int main()
14547 {
14548    std::pair&lt;char *, char *&gt; p (0,0);
14549 }
14550 </pre></blockquote>
14551
14552 <p>
14553 I have not made any general audit for such problems elsewhere.
14554 </p>
14555 </blockquote>
14556
14557 <p><i>[
14558 Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a>
14559 ]</i></p>
14560
14561
14562 <p><i>[
14563 Bellevue:
14564 ]</i></p>
14565
14566
14567 <blockquote>
14568 <p>
14569 Motivation is to handle the old-style int-zero-valued NULL pointers.
14570 Problem: this solution requires concepts in some cases, which some users
14571 will be slow to adopt. Some discussion of alternatives involving
14572 prohibiting variadic forms and additional library-implementation
14573 complexity.
14574 </p>
14575 <p>
14576 Discussion of "perfect world" solutions, the only such solution put
14577 forward being to retroactively prohibit use of the integer zero for a
14578 NULL pointer. This approach was deemed unacceptable given the large
14579 bodies of pre-existing code that do use integer zero for a NULL pointer.
14580 </p>
14581 <p>
14582 Another approach is to change the member names. Yet another approach is
14583 to forbid the extension in absence of concepts.
14584 </p>
14585 <p>
14586 Resolution: These issues (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#763">763</a>) will be subsumed into a
14587 paper to be produced by Alan Talbot in time for review at the 2008
14588 meeting in France. Once this paper is produced, these issues will be
14589 moved to NAD.
14590 </p>
14591 </blockquote>
14592
14593
14594
14595 <p><b>Proposed resolution:</b></p>
14596 <p>
14597 Add the following rows to Table 90 "Optional sequence container operations", 23.2.3 [sequence.reqmts]:
14598 </p>
14599
14600 <blockquote>
14601 <table border="1">
14602 <tbody><tr>
14603 <th>expression</th> <th>return type</th> <th>assertion/note<br>pre-/post-condition</th> <th>container</th>
14604 </tr>
14605
14606 <tr>
14607 <td>
14608 <tt>a.push_front(t)</tt>
14609 </td>
14610 <td>
14611 <tt>void</tt>
14612 </td>
14613 <td>
14614 <tt>a.insert(a.begin(), t)</tt><br>
14615 <i>Requires:</i> <tt>T</tt> shall be <tt>CopyConstructible</tt>.
14616 </td>
14617 <td>
14618 <tt>list, deque</tt>
14619 </td>
14620 </tr>
14621
14622 <tr>
14623 <td>
14624 <tt>a.push_front(rv)</tt>
14625 </td>
14626 <td>
14627 <tt>void</tt>
14628 </td>
14629 <td>
14630 <tt>a.insert(a.begin(), rv)</tt><br>
14631 <i>Requires:</i> <tt>T</tt> shall be <tt>MoveConstructible</tt>.
14632 </td>
14633 <td>
14634 <tt>list, deque</tt>
14635 </td>
14636 </tr>
14637
14638 <tr>
14639 <td>
14640 <tt>a.push_back(t)</tt>
14641 </td>
14642 <td>
14643 <tt>void</tt>
14644 </td>
14645 <td>
14646 <tt>a.insert(a.end(), t)</tt><br>
14647 <i>Requires:</i> <tt>T</tt> shall be <tt>CopyConstructible</tt>.
14648 </td>
14649 <td>
14650 <tt>list, deque, vector, basic_string</tt>
14651 </td>
14652 </tr>
14653
14654 <tr>
14655 <td>
14656 <tt>a.push_back(rv)</tt>
14657 </td>
14658 <td>
14659 <tt>void</tt>
14660 </td>
14661 <td>
14662 <tt>a.insert(a.end(), rv)</tt><br>
14663 <i>Requires:</i> <tt>T</tt> shall be <tt>MoveConstructible</tt>.
14664 </td>
14665 <td>
14666 <tt>list, deque, vector, basic_string</tt>
14667 </td>
14668 </tr>
14669
14670 </tbody></table>
14671 </blockquote>
14672
14673 <p>
14674 Change the synopsis in 23.3.2 [deque]:
14675 </p>
14676
14677 <blockquote><pre><ins>void push_front(const T&amp; x);</ins>
14678 <ins>void push_front(T&amp;&amp; x);</ins>
14679 <ins>void push_back(const T&amp; x);</ins>
14680 <ins>void push_back(T&amp;&amp; x);</ins>
14681 template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_front(Args&amp;&amp;... args);
14682 template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_back(Args&amp;&amp;... args);
14683 </pre></blockquote>
14684
14685 <p>
14686 Change 23.3.2.3 [deque.modifiers]:
14687 </p>
14688
14689 <blockquote><pre><ins>void push_front(const T&amp; x);</ins>
14690 <ins>void push_front(T&amp;&amp; x);</ins>
14691 <ins>void push_back(const T&amp; x);</ins>
14692 <ins>void push_back(T&amp;&amp; x);</ins>
14693 template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_front(Args&amp;&amp;... args);
14694 template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_back(Args&amp;&amp;... args);
14695 </pre></blockquote>
14696
14697 <p>
14698 Change the synopsis in 23.3.4 [list]:
14699 </p>
14700
14701 <blockquote><pre><ins>void push_front(const T&amp; x);</ins>
14702 <ins>void push_front(T&amp;&amp; x);</ins>
14703 <ins>void push_back(const T&amp; x);</ins>
14704 <ins>void push_back(T&amp;&amp; x);</ins>
14705 template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_front(Args&amp;&amp;... args);
14706 template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_back(Args&amp;&amp;... args);
14707 </pre></blockquote>
14708
14709 <p>
14710 Change 23.3.4.3 [list.modifiers]:
14711 </p>
14712
14713 <blockquote><pre><ins>void push_front(const T&amp; x);</ins>
14714 <ins>void push_front(T&amp;&amp; x);</ins>
14715 <ins>void push_back(const T&amp; x);</ins>
14716 <ins>void push_back(T&amp;&amp; x);</ins>
14717 template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_front(Args&amp;&amp;... args);
14718 template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_back(Args&amp;&amp;... args);
14719 </pre></blockquote>
14720
14721 <p>
14722 Change the synopsis in 23.3.6 [vector]:
14723 </p>
14724
14725 <blockquote><pre><ins>void push_back(const T&amp; x);</ins>
14726 <ins>void push_back(T&amp;&amp; x);</ins>
14727 template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_back(Args&amp;&amp;... args);
14728 </pre></blockquote>
14729
14730 <p>
14731 Change 23.3.6.4 [vector.modifiers]:
14732 </p>
14733
14734 <blockquote><pre><ins>void push_back(const T&amp; x);</ins>
14735 <ins>void push_back(T&amp;&amp; x);</ins>
14736 template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_back(Args&amp;&amp;... args);
14737 </pre></blockquote>
14738
14739
14740
14741
14742 <p><b>Rationale:</b></p>
14743 <p>
14744 Addressed by
14745 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2680.pdf">N2680 Proposed Wording for Placement Insert (Revision 1)</a>.
14746 </p>
14747
14748 <p>
14749 If there is still an issue with pair, Howard should submit another issue.
14750 </p>
14751
14752
14753
14754
14755
14756 <hr>
14757 <h3><a name="773"></a>773. issues with random</h3>
14758 <p><b>Section:</b> 26.5.8.1 [rand.dist.uni] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
14759  <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2008-01-14  <b>Last modified:</b> 2008-02-27</p>
14760 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.uni">issues</a> in [rand.dist.uni].</p>
14761 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
14762 <p><b>Discussion:</b></p>
14763 <ol>
14764 <li>
14765 26.5.8.1.1 [rand.dist.uni.int] <tt>uniform_int</tt> constructor has changed the default
14766 max constructor parameter from 9 (in TR1) to <tt>max()</tt>. The value
14767 is arbitrary at best and shouldn't be lightly changed because
14768 it breaks backward compatibility.
14769 </li>
14770
14771 <li>
14772 26.5.8.1.1 [rand.dist.uni.int] <tt>uniform_int</tt> has a parameter <tt>param</tt> that you can
14773 provide on construction or <tt>operator()</tt>, set, and get. But there
14774 is not even a hint of what this might be for.
14775 </li>
14776
14777 <li>
14778 26.5.8.1.2 [rand.dist.uni.real] <tt>uniform_real</tt>. Same issue as #2.
14779 </li>
14780 </ol>
14781
14782 <p><i>[
14783 Bellevue:
14784 ]</i></p>
14785
14786
14787 <blockquote>
14788 NAD. Withdrawn.
14789 </blockquote>
14790
14791
14792 <p><b>Proposed resolution:</b></p>
14793 <p>
14794 </p>
14795
14796
14797
14798
14799
14800 <hr>
14801 <h3><a name="784"></a>784. unique_lock::release</h3>
14802 <p><b>Section:</b> 30.4.3.2.3 [thread.lock.unique.mod] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
14803  <b>Submitter:</b> Constantine Sapuntzakis <b>Opened:</b> 2008-02-02  <b>Last modified:</b> 2008-02-27</p>
14804 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
14805 <p><b>Discussion:</b></p>
14806 <p>
14807 <tt>unique_lock::release</tt> will probably lead to many mistakes where people
14808 call <tt>release</tt> instead of <tt>unlock</tt>. I just coded such a mistake using the
14809 boost pre-1.35 threads library last week.
14810 </p>
14811
14812 <p>
14813 In many threading libraries, a call with <tt>release</tt> in it unlocks the
14814 lock (e.g. ReleaseMutex in Win32, java.util.concurrent.Semaphore).
14815 </p>
14816
14817 <p>
14818 I don't call <tt>unique_lock::lock</tt> much at all, so I don't get to see the
14819 symmetry between <tt>::lock</tt> and <tt>::unlock</tt>. I usually use the constructor to
14820 lock the mutex. So I'm left to remember whether to call <tt>release</tt> or
14821 <tt>unlock</tt> during the few times I need to release the mutex before the scope
14822 ends. If I get it wrong, the compiler doesn't warn me.
14823 </p>
14824
14825 <p>
14826 An alternative name for release may be <tt>disown</tt>.
14827 </p>
14828
14829 <p>
14830 This might be a rare case where usability is hurt by consistency with
14831 the rest of the C++ standard (e.g. <tt>std::auto_ptr::release</tt>).
14832 </p>
14833
14834 <p><i>[
14835 Bellevue:
14836 ]</i></p>
14837
14838
14839 <blockquote>
14840 Change a name from release to disown. However prior art uses the release
14841 name. Compatibility with prior art is more important that any possible
14842 benefit such a change might make. We do not see the benefit for
14843 changing. NAD
14844 </blockquote>
14845
14846
14847 <p><b>Proposed resolution:</b></p>
14848 <p>
14849 Change the synopsis in 30.4.3.2 [thread.lock.unique]:
14850 </p>
14851
14852 <blockquote><pre>template &lt;class Mutex&gt;
14853 class unique_lock
14854 {
14855 public:
14856    ...
14857    mutex_type* <del>release</del> <ins>disown</ins>();
14858    ...
14859 };
14860 </pre></blockquote>
14861
14862 <p>
14863 Change 30.4.3.2.3 [thread.lock.unique.mod]:
14864 </p>
14865
14866 <blockquote><pre>mutex_type *<del>release</del> <ins>disown</ins>();
14867 </pre></blockquote>
14868
14869
14870
14871
14872
14873 <hr>
14874 <h3><a name="786"></a>786. Thread library timed waits, UTC and monotonic clocks</h3>
14875 <p><b>Section:</b> 20.9 [time] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
14876  <b>Submitter:</b> Christopher Kohlhoff, Jeff Garland <b>Opened:</b> 2008-02-03  <b>Last modified:</b> 2008-09-30</p>
14877 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time">issues</a> in [time].</p>
14878 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
14879 <p><b>Discussion:</b></p>
14880 <p>
14881 The draft C++0x thread library requires that the time points of type
14882 <tt>system_time</tt> and returned by <tt>get_system_time()</tt> represent Coordinated
14883 Universal Time (UTC) (section X [datetime.system]). This can lead to
14884 surprising behavior when a library user performs a duration-based wait,
14885 such as <tt>condition_variable::timed_wait()</tt>. A complete explanation of the
14886 problem may be found in the
14887 <a href="http://www.opengroup.org/onlinepubs/009695399/xrat/xsh_chap02.html#tag_03_02_08_19">Rationale for the Monotonic Clock</a>
14888 section in POSIX, but in summary:
14889 </p>
14890
14891 <ul>
14892 <li>
14893 Operations such as <tt>condition_variable::timed_wait()</tt> (and its POSIX
14894 equivalent, <tt>pthread_cond_timedwait()</tt>) are specified using absolute times
14895 to address the problem of spurious wakeups.
14896 </li>
14897
14898 <li>
14899 The typical use of the timed wait operations is to perform a relative
14900 wait. This may be achieved by first calculating an absolute time as the
14901 sum of the current time and the desired duration. In fact, the C++0x
14902 thread library includes duration-based overloads of
14903 <tt>condition_variable::timed_wait()</tt> that behave as if by calling the
14904 corresponding absolute time overload with a time point value of
14905 <tt>get_system_time() + rel_time</tt>.
14906 </li>
14907
14908 <li>
14909 A UTC clock may be affected by changes to the system time, such as
14910 synchronization with an external source, leap seconds, or manual changes
14911 to the clock.
14912 </li>
14913
14914 <li>
14915 Should the clock change during a timed wait operation, the actual
14916 duration of the wait will not be the expected length. For example, a
14917 user may intend a timed wait of one second duration but, due to an
14918 adjustment of the system clock backwards by a minute, the wait instead
14919 takes 61 seconds.
14920 </li>
14921 </ul>
14922
14923 <p>
14924 POSIX solves the problem by introducing a new monotonic clock, which is
14925 unaffected by changes to the system time. When a condition variable is
14926 initialized, the user may specify whether the monotonic clock is to be
14927 used. (It is worth noting that on POSIX systems it is not possible to
14928 use <tt>condition_variable::native_handle()</tt> to access this facility, since
14929 the desired clock type must be specified during construction of the
14930 condition variable object.)
14931 </p>
14932
14933 <p>
14934 In the context of the C++0x thread library, there are added dimensions
14935 to the problem due to the need to support platforms other than POSIX:
14936 </p>
14937
14938 <ul>
14939 <li>
14940 Some environments (such as embedded systems) do not have a UTC clock, but do have a monotonic clock.
14941 </li>
14942
14943 <li>
14944 Some environments do not have a monotonic clock, but do have a UTC clock.
14945 </li>
14946
14947 <li>
14948 The Microsoft Windows API's synchronization functions use relative
14949 timeouts based on an implied monotonic clock. A program that switches
14950 from the Windows API to the C++0x thread library will now find itself
14951 susceptible to clock changes.
14952 </li>
14953 </ul>
14954
14955 <p>
14956 One possible minimal solution:
14957 </p>
14958
14959 <ul>
14960 <li>
14961 Strike normative references to UTC and an epoch based on 1970-01-01.
14962 </li>
14963
14964 <li>
14965 Make the semantics of <tt>system_time</tt> and <tt>get_system_time()</tt>
14966 implementation-defined (i.e standard library implementors may choose the
14967 appropriate underlying clock based on the capabilities of the target
14968 platform).
14969 </li>
14970
14971 <li>
14972 Add a non-normative note encouraging use of a monotonic clock.
14973 </li>
14974
14975 <li>
14976 Remove <tt>system_time::seconds_since_epoch()</tt>.
14977 </li>
14978
14979 <li>
14980 Change the constructor <tt>explicit system_time(time_t secs, nanoseconds ns
14981 = 0)</tt> to <tt>explicit system_time(nanoseconds ns)</tt>.
14982 </li>
14983 </ul>
14984
14985
14986
14987 <p><b>Proposed resolution:</b></p>
14988 <p>
14989 </p>
14990
14991
14992 <p><b>Rationale:</b></p>
14993 Addressed by
14994 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2661.html">N2661: A Foundation to Sleep On</a>.
14995
14996
14997
14998
14999
15000 <hr>
15001 <h3><a name="790"></a>790. <tt>xor_combine::seed</tt> not specified</h3>
15002 <p><b>Section:</b> X [rand.adapt.xor] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
15003  <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2008-02-09  <b>Last modified:</b> 2008-02-27</p>
15004 <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>
15005 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
15006 <p><b>Discussion:</b></p>
15007 <p>
15008 <tt>xor_combine::seed(result_type)</tt> and <tt>seed(seed_seq&amp;)</tt> don't say what
15009 happens to each of the sub-engine seeds. (Should probably do the same
15010 to both, unlike TR1.)
15011 </p>
15012
15013 <p><i>[
15014 Bellevue:
15015 ]</i></p>
15016
15017
15018 <blockquote>
15019 Overcome by the previous proposal. NAD mooted by resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#789">789</a>.
15020 </blockquote>
15021
15022
15023
15024 <p><b>Proposed resolution:</b></p>
15025
15026
15027
15028
15029
15030 <hr>
15031 <h3><a name="791"></a>791. <tt>piecewise_constant_distribution::densities</tt> has wrong name</h3>
15032 <p><b>Section:</b> 26.5.8.5.2 [rand.dist.samp.pconst] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
15033  <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2008-02-09  <b>Last modified:</b> 2008-03-11</p>
15034 <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>
15035 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
15036 <p><b>Discussion:</b></p>
15037 <p>
15038 <tt>piecewise_constant_distribution::densities()</tt> should be <tt>probabilities()</tt>,
15039 just like <tt>discrete_distribution</tt>. (There's no real use for weights divided
15040 by areas.)
15041 </p>
15042
15043 <p><i>[
15044 Bellevue:
15045 ]</i></p>
15046
15047
15048 <blockquote>
15049 <p>
15050 Fermilab does not agree with this summary. As defined in the equation in
15051 26.4.8.5.2/4, the quantities are indeed probability densities not
15052 probabilities. Because we view this distribution as a parameterization
15053 of a *probability density function*, we prefer to work in terms of
15054 probability densities.
15055 </p>
15056
15057 <p>
15058 We don't think this should be changed.
15059 </p>
15060
15061 <p>
15062 If there is a technical argument about why the implementation dealing
15063 with these values can't be as efficient as one dealing with
15064 probabilities, we might reconsider. We don't care about this one member
15065 function being somewhat more or less efficient; we care about the size
15066 of the distribution object and the speed of the calls to generate
15067 variates.
15068 </p>
15069 </blockquote>
15070
15071
15072
15073 <p><b>Proposed resolution:</b></p>
15074
15075 <p>
15076 Change synopsis in 26.5.8.5.2 [rand.dist.samp.pconst]:
15077 </p>
15078
15079 <blockquote><pre>template &lt;class RealType = double&gt;
15080 class piecewise_constant_distribution
15081 {
15082 public:
15083     ...
15084     vector&lt;double&gt; <del>densities</del> <ins>probabilities</ins>() const;
15085     ...
15086 };
15087 </pre></blockquote>
15088
15089 <p>
15090 Change 26.5.8.5.2 [rand.dist.samp.pconst]/6:
15091 </p>
15092
15093 <blockquote><pre>vector&lt;double&gt; <del>densities</del> <ins>probabilities</ins>() const;
15094 </pre></blockquote>
15095
15096
15097
15098
15099
15100
15101 <hr>
15102 <h3><a name="793"></a>793. <tt>discrete_distribution</tt> missing constructor</h3>
15103 <p><b>Section:</b> 26.5.8.5.1 [rand.dist.samp.discrete] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
15104  <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2008-02-09  <b>Last modified:</b> 2009-03-09</p>
15105 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.discrete">issues</a> in [rand.dist.samp.discrete].</p>
15106 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
15107 <p><b>Discussion:</b></p>
15108 <p>
15109 <tt>discrete_distribution</tt> should have a constructor like:
15110 </p>
15111
15112 <blockquote><pre>template&lt;class _Fn&gt;
15113   discrete_distribution(result_type _Count, double _Low, double _High,
15114                         _Fn&amp; _Func);
15115 </pre></blockquote>
15116
15117 <p>
15118 (Makes it easier to fill a histogram with function values over a range.)
15119 </p>
15120
15121 <p><i>[
15122 Bellevue:
15123 ]</i></p>
15124
15125
15126 <blockquote>
15127 How do you specify the function so that it does not return negative
15128 values? If you do it is a bad construction. This requirement is already
15129 there. Where in each bin does one evaluate the function? In the middle.
15130 Need to revisit tomorrow.
15131 </blockquote>
15132
15133 <p><i>[
15134 Sophia Antipolis:
15135 ]</i></p>
15136
15137
15138 <blockquote>
15139 <p>
15140 Bill is not requesting this.
15141 </p>
15142 <p>
15143 Marc Paterno: <tt>_Fn</tt> cannot return negative values at the points where the
15144 function is sampled. It is sampled in the middle of each bin. <tt>_Fn</tt> cannot
15145 return 0 everywhere it is sampled.
15146 </p>
15147 <p>
15148 Jens: lambda expressions are rvalues
15149 </p>
15150 <p>
15151 Add a library issue to provide an
15152 <tt>initializer_list&lt;double&gt;</tt> constructor for
15153 <tt>discrete_distribution</tt>.
15154 </p>
15155 <p>
15156 Marc Paterno: dislikes reference for <tt>_Fn</tt> parameter. Make it pass-by-value (to use lambda),
15157 use <tt>std::ref</tt> to wrap giant-state function objects.
15158 </p>
15159 <p>
15160 Daniel: See <tt>random_shuffle</tt>, pass-by-rvalue-reference.
15161 </p>
15162 <p>
15163 Daniel to draft wording.
15164 </p>
15165 </blockquote>
15166
15167 <p><i>[
15168 Pre San Francisco, Daniel provided wording:
15169 ]</i></p>
15170
15171
15172 <blockquote>
15173 The here proposed changes of the WP refer to the current state of
15174 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2691.pdf">N2691</a>.
15175 During the Sophia Antipolis meeting two different proposals came up
15176 regarding the functor argument type, either by value or by rvalue-reference.
15177 For consistence with existing conventions (state-free algorithms and the
15178 <tt>general_pdf_distribution</tt> c'tor signature) the author decided to propose a
15179 function argument that is provided by value. If severe concerns exists that
15180 stateful functions would be of dominant relevance, it should be possible to
15181 replace the two occurrences of <tt>Func</tt> by <tt>Func&amp;&amp;</tt> in this proposal as part
15182 of an editorial process.
15183 </blockquote>
15184
15185
15186
15187 <p><b>Proposed resolution:</b></p>
15188
15189 <p><b>Non-concept version of the proposed resolution</b></p>
15190
15191 <ol>
15192 <li>
15193 <p>
15194 In 26.5.8.5.1 [rand.dist.samp.discrete]/1, class <tt>discrete_distribution</tt>, just
15195 <em>before</em> the member declaration
15196 </p>
15197
15198 <blockquote><pre>explicit discrete_distribution(const param_type&amp; parm);
15199 </pre></blockquote>
15200
15201 <p>
15202 insert:
15203 </p>
15204
15205
15206 <blockquote><pre>template&lt;typename Func&gt;
15207 discrete_distribution(result_type nf, double xmin, double xmax, Func fw);
15208 </pre></blockquote>
15209 </li>
15210
15211 <li>
15212 <p>
15213 Between p.4 and p.5 insert a series of new paragraphs as part of the
15214 new member description::
15215 </p>
15216 <blockquote><pre>template&lt;typename Func&gt;
15217 discrete_distribution(result_type nf, double xmin, double xmax, Func fw);
15218 </pre>
15219
15220 <p>
15221 <i>Complexity:</i> Exactly nf invocations of fw.
15222 </p>
15223 <p>
15224 <i>Requires:</i>
15225 </p>
15226 <ol type="a">
15227 <li>
15228 fw shall be callable with one argument of type double, and shall
15229 return values of a type convertible to double;</li>
15230
15231 <li>If nf &gt; 0, the relation <tt><i>x</i><sub><i>min</i></sub></tt> &lt; <tt><i>x</i><sub><i>max</i></sub></tt> shall hold, and for all sample values
15232 <tt><i>x</i><sub><i>k</i></sub></tt>, fw(<tt><i>x</i><sub><i>k</i></sub></tt>) shall return a weight value <tt><i>w</i><sub><i>k</i></sub></tt> that is non-negative, non-NaN,
15233 and non-infinity;</li>
15234
15235 <li>The following relations shall hold: nf &#8805; 0, and 0 &lt; S = <tt><i>w</i><sub><i>0</i></sub></tt>+. . .+<tt><i>w<sub>n-1</sub></i></tt>.</li>
15236
15237 </ol>
15238
15239 <p>
15240 <i>Effects:</i>
15241 </p>
15242 <ol type="a">
15243 <li>If nf == 0, sets n = 1 and lets the sequence w have length n = 1 and
15244    consist of the single value <tt><i>w</i><sub><i>0</i></sub></tt> = 1.</li>
15245
15246 <li>
15247 <p>Otherwise, sets n = nf, deltax = (<tt><i>x</i><sub><i>max</i></sub></tt> - <tt><i>x</i><sub><i>min</i></sub></tt>)/n and <tt><i>x</i><sub><i>cent</i></sub></tt> = <tt><i>x</i><sub><i>min</i></sub></tt> +
15248 0.5 * deltax.</p>
15249 <blockquote><pre>For each k = 0, . . . ,n-1, calculates:
15250   <tt><i>x</i><sub><i>k</i></sub></tt> = <tt><i>x</i><sub><i>cent</i></sub></tt> + k * deltax
15251   <tt><i>w</i><sub><i>k</i></sub></tt> = fw(<tt><i>x</i><sub><i>k</i></sub></tt>)
15252 </pre></blockquote>
15253 </li>
15254 <li>
15255 <p>Constructs a discrete_distribution object with probabilities:</p>
15256 <blockquote><pre><tt><i>p</i><sub><i>k</i></sub></tt> = <tt><i>w</i><sub><i>k</i></sub></tt>/S  for k = 0, . . . , n-1.
15257 </pre></blockquote>
15258 </li>
15259 </ol>
15260 </blockquote>
15261 </li>
15262 </ol>
15263
15264 <p><b>Concept version of the proposed resolution</b></p>
15265
15266
15267 <ol>
15268 <li>
15269 <p>
15270 In 26.5.8.5.1 [rand.dist.samp.discrete]/1, class <tt>discrete_distribution</tt>, just
15271 <em>before</em> the member declaration
15272 </p>
15273
15274 <blockquote><pre>explicit discrete_distribution(const param_type&amp; parm);
15275 </pre></blockquote>
15276
15277 <p>
15278 insert:
15279 </p>
15280
15281
15282 <blockquote><pre>template&lt;Callable&lt;auto, double&gt; Func&gt;
15283  requires Convertible&lt;Func::result_type, double&gt;
15284 discrete_distribution(result_type nf, double xmin, double xmax, Func fw);
15285 </pre></blockquote>
15286 </li>
15287
15288 <li>
15289 <p>
15290 Between p.4 and p.5 insert a series of new paragraphs as part of the
15291 new member description::
15292 </p>
15293 <blockquote><pre>template&lt;Callable&lt;auto, double&gt; Func&gt;
15294  requires Convertible&lt;Func::result_type, double&gt;
15295 discrete_distribution(result_type nf, double xmin, double xmax, Func fw);
15296 </pre>
15297
15298 <p>
15299 <i>Complexity:</i> Exactly nf invocations of fw.
15300 </p>
15301 <p>
15302 <i>Requires:</i>
15303 </p>
15304 <ol type="a">
15305 <li>If nf &gt; 0, the relation <tt><i>x</i><sub><i>min</i></sub></tt> &lt; <tt><i>x</i><sub><i>max</i></sub></tt> shall hold, and for all sample values
15306 <tt><i>x</i><sub><i>k</i></sub></tt>, fw(<tt><i>x</i><sub><i>k</i></sub></tt>) shall return a weight value <tt><i>w</i><sub><i>k</i></sub></tt> that is non-negative, non-NaN,
15307 and non-infinity;</li>
15308
15309 <li>The following relations shall hold: nf &#8805; 0, and 0 &lt; S = <tt><i>w</i><sub><i>0</i></sub></tt>+. . .+<tt><i>w<sub>n-1</sub></i></tt>.</li>
15310
15311 </ol>
15312
15313 <p>
15314 <i>Effects:</i>
15315 </p>
15316 <ol type="a">
15317 <li>If nf == 0, sets n = 1 and lets the sequence w have length n = 1 and
15318    consist of the single value <tt><i>w</i><sub><i>0</i></sub></tt> = 1.</li>
15319
15320 <li>
15321 <p>Otherwise, sets n = nf, deltax = (<tt><i>x</i><sub><i>max</i></sub></tt> - <tt><i>x</i><sub><i>min</i></sub></tt>)/n and <tt><i>x</i><sub><i>cent</i></sub></tt> = <tt><i>x</i><sub><i>min</i></sub></tt> +
15322 0.5 * deltax.</p>
15323 <blockquote><pre>For each k = 0, . . . ,n-1, calculates:
15324   <tt><i>x</i><sub><i>k</i></sub></tt> = <tt><i>x</i><sub><i>cent</i></sub></tt> + k * deltax
15325   <tt><i>w</i><sub><i>k</i></sub></tt> = fw(<tt><i>x</i><sub><i>k</i></sub></tt>)
15326 </pre></blockquote>
15327 </li>
15328 <li>
15329 <p>Constructs a discrete_distribution object with probabilities:</p>
15330 <blockquote><pre><tt><i>p</i><sub><i>k</i></sub></tt> = <tt><i>w</i><sub><i>k</i></sub></tt>/S  for k = 0, . . . , n-1.
15331 </pre></blockquote>
15332 </li>
15333 </ol>
15334 </blockquote>
15335 </li>
15336 </ol>
15337
15338
15339
15340 <p><b>Rationale:</b></p>
15341 Addressed by
15342 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2836.pdf">N2836</a> "Wording Tweaks for Concept-enabled Random Number Generation in C++0X".
15343
15344
15345
15346
15347
15348 <hr>
15349 <h3><a name="794"></a>794. <tt>piecewise_constant_distribution</tt> missing constructor</h3>
15350 <p><b>Section:</b> 26.5.8.5.2 [rand.dist.samp.pconst] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
15351  <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2008-02-09  <b>Last modified:</b> 2009-03-09</p>
15352 <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>
15353 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
15354 <p><b>Discussion:</b></p>
15355 <p>
15356 <tt>piecewise_constant_distribution</tt> should have a constructor like:
15357 </p>
15358
15359 <blockquote><pre>template&lt;class _Fn&gt;
15360    piecewise_constant_distribution(size_t _Count,
15361             _Ty _Low, _Ty _High, _Fn&amp; _Func);
15362 </pre></blockquote>
15363
15364 <p>
15365 (Makes it easier to fill a histogram with function values over a range.
15366 The two (reference <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#793">793</a>) make a sensible replacement for
15367 <tt>general_pdf_distribution</tt>.)
15368 </p>
15369
15370 <p><i>[
15371 Sophia Antipolis:
15372 ]</i></p>
15373
15374
15375 <blockquote>
15376 <p>
15377 Marc: uses variable width of bins and weight for each bin. This is not
15378 giving enough flexibility to control both variables.
15379 </p>
15380 <p>
15381 Add a library issue to provide an constructor taking an
15382 <tt>initializer_list&lt;double&gt;</tt> and <tt>_Fn</tt> for <tt>piecewise_constant_distribution</tt>.
15383 </p>
15384 <p>
15385 Daniel to draft wording.
15386 </p>
15387 </blockquote>
15388
15389 <p><i>[
15390 Pre San Francisco, Daniel provided wording.
15391 ]</i></p>
15392
15393
15394 <blockquote>
15395 The here proposed changes of the WP refer to the current state of
15396 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2691.pdf">N2691</a>.
15397 For reasons explained in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#793">793</a>, the author decided to propose a function
15398 argument that is provided by value. The issue proposes a c'tor signature,
15399 that does not take advantage of the full flexibility of
15400 <tt>piecewise_constant_distribution</tt>,
15401 because it restricts on a constant bin width, but the use-case seems to
15402 be popular enough to justify it's introduction.
15403 </blockquote>
15404
15405
15406
15407 <p><b>Proposed resolution:</b></p>
15408
15409 <p><b>Non-concept version of the proposed resolution</b></p>
15410
15411 <ol>
15412 <li>
15413 <p>
15414 In 26.5.8.5.2 [rand.dist.samp.pconst]/1, class <tt>piecewise_constant_distribution</tt>,
15415 just <em>before</em> the member declaration
15416 </p>
15417
15418 <blockquote><pre>explicit piecewise_constant_distribution(const param_type&amp; parm);
15419 </pre></blockquote>
15420 <p>
15421 insert:
15422 </p>
15423 <blockquote><pre>template&lt;typename Func&gt;
15424 piecewise_constant_distribution(size_t nf, RealType xmin, RealType xmax, Func fw);
15425 </pre></blockquote>
15426 </li>
15427
15428 <li>
15429 <p>
15430 Between p.4 and p.5 insert a new sequence of paragraphs nominated
15431 below as [p5_1], [p5_2],
15432 [p5_3], and [p5_4] as part of the new member description:
15433 </p>
15434
15435 <blockquote><pre>template&lt;typename Func&gt;
15436 piecewise_constant_distribution(size_t nf, RealType xmin, RealType xmax, Func fw);
15437 </pre>
15438 <blockquote>
15439 <p>
15440 [p5_1] <i>Complexity:</i> Exactly <tt>nf</tt> invocations of <tt>fw</tt>.
15441 </p>
15442 <p>
15443 [p5_2] <i>Requires:</i>
15444 </p>
15445 <ol type="a">
15446 <li><tt>fw</tt> shall be callable with one argument of type <tt>RealType</tt>, and shall
15447 return values of a type convertible to double;
15448 </li>
15449 <li>
15450 For all sample values <tt><i>x<sub>k</sub></i></tt> defined below, fw(<tt><i>x<sub>k</sub></i></tt>) shall return a weight
15451 value <tt><i>w<sub>k</sub></i></tt> that is non-negative, non-NaN, and non-infinity;
15452 </li>
15453 <li>
15454 The following relations shall hold: <tt><i>x<sub>min</sub></i></tt> &lt; <tt><i>x<sub>max</sub></i></tt>, and
15455 0 &lt; S = <tt><i>w<sub>0</sub></i></tt>+. . .+<tt><i>w<sub>n-1</sub></i></tt>.
15456 </li>
15457 </ol>
15458 <p>
15459 [p5_3] <i>Effects:</i>
15460 </p>
15461 <ol type="a">
15462 <li>
15463 <p>If nf == 0,</p>
15464  <ol type="a">
15465  <li>
15466 sets deltax = <tt><i>x<sub>max</sub></i></tt> - <tt><i>x<sub>min</sub></i></tt>, and</li>
15467 <li> lets the sequence <tt>w</tt> have length <tt>n = 1</tt> and consist of the single
15468     value <tt><i>w<sub>0</sub></i></tt> = 1, and</li>
15469 <li> lets the sequence <tt>b</tt> have length <tt>n+1</tt> with <tt><i>b<sub>0</sub></i></tt> = <tt><i>x<sub>min</sub></i></tt> and
15470               <tt><i>b<sub>1</sub></i></tt> = <tt><i>x<sub>max</sub></i></tt>
15471 </li>
15472 </ol>
15473 </li>
15474 <li>
15475 <p>Otherwise,</p>
15476 <ol type="a">
15477 <li> sets <tt>n = nf</tt>, <tt>deltax = </tt>(<tt><i>x<sub>max</sub></i></tt> - <tt><i>x<sub>min</sub></i></tt>)/n,
15478                  <tt><i>x<sub>cent</sub></i></tt> = <tt><i>x<sub>min</sub></i></tt> + 0.5 * deltax, and
15479 </li>
15480 <li><p>lets the sequences <tt>w</tt> and <tt>b</tt> have length <tt>n</tt> and <tt>n+1</tt>, resp. and</p>
15481 <blockquote><pre>for each k = 0, . . . ,n-1, calculates:
15482   <tt><i>dx<sub>k</sub></i></tt> = k * deltax
15483   <tt><i>b<sub>k</sub></i></tt> = <tt><i>x<sub>min</sub></i></tt> + <tt><i>dx<sub>k</sub></i></tt>
15484   <tt><i>x<sub>k</sub></i></tt> = <tt><i>x<sub>cent</sub></i></tt> + <tt><i>dx<sub>k</sub></i></tt>
15485   <tt><i>w<sub>k</sub></i></tt> = fw(<tt><i>x<sub>k</sub></i></tt>),
15486 </pre></blockquote>
15487 <p> and</p>
15488 </li>
15489 <li> sets <tt><i>b<sub>n</sub></i></tt> = <tt><i>x<sub>max</sub></i></tt></li>
15490 </ol>
15491 </li>
15492 <li>
15493 <p>
15494 Constructs a <tt>piecewise_constant_distribution</tt> object with
15495 the above computed sequence <tt>b</tt> as the interval boundaries
15496 and with the probability densities:
15497 </p>
15498 <blockquote><pre><tt><i>&#961;<sub>k</sub></i></tt> = <tt><i>w<sub>k</sub></i></tt>/(S * deltax)  for k = 0, . . . , n-1.
15499 </pre></blockquote>
15500 </li>
15501 </ol>
15502 <p>
15503 [p5_4] [<i>Note:</i> In this context, the subintervals [<tt><i>b<sub>k</sub></i></tt>, <tt><i>b<sub>k+1</sub></i></tt>) are commonly
15504  known as the <i>bins</i> of a histogram. <i>-- end note</i>]
15505  </p>
15506 </blockquote>
15507 </blockquote>
15508 </li>
15509 </ol>
15510
15511 <p><b>Concept version of the proposed resolution</b></p>
15512
15513 <ol>
15514 <li>
15515 <p>
15516 In 26.5.8.5.2 [rand.dist.samp.pconst]/1, class <tt>piecewise_constant_distribution</tt>,
15517 just <em>before</em> the member declaration
15518 </p>
15519
15520 <blockquote><pre>explicit piecewise_constant_distribution(const param_type&amp; parm);
15521 </pre></blockquote>
15522 <p>
15523 insert:
15524 </p>
15525 <blockquote><pre>template&lt;Callable&lt;auto, RealType&gt; Func&gt;
15526  requires Convertible&lt;Func::result_type, double&gt;
15527 piecewise_constant_distribution(size_t nf, RealType xmin, RealType xmax, Func fw);
15528 </pre></blockquote>
15529 </li>
15530
15531 <li>
15532 <p>
15533 Between p.4 and p.5 insert a new sequence of paragraphs nominated
15534 below as [p5_1], [p5_2],
15535 [p5_3], and [p5_4] as part of the new member description:
15536 </p>
15537
15538 <blockquote><pre>template&lt;Callable&lt;auto, RealType&gt; Func&gt;
15539  requires Convertible&lt;Func::result_type, double&gt;
15540 piecewise_constant_distribution(size_t nf, RealType xmin, RealType xmax, Func fw);
15541 </pre>
15542 <blockquote>
15543 <p>
15544 [p5_1] <i>Complexity:</i> Exactly <tt>nf</tt> invocations of <tt>fw</tt>.
15545 </p>
15546 <p>
15547 [p5_2] <i>Requires:</i>
15548 </p>
15549 <ol type="a">
15550 <li>
15551 For all sample values <tt><i>x<sub>k</sub></i></tt> defined below, fw(<tt><i>x<sub>k</sub></i></tt>) shall return a weight
15552 value <tt><i>w<sub>k</sub></i></tt> that is non-negative, non-NaN, and non-infinity;
15553 </li>
15554 <li>
15555 The following relations shall hold: <tt><i>x<sub>min</sub></i></tt> &lt; <tt><i>x<sub>max</sub></i></tt>, and
15556 0 &lt; S = <tt><i>w<sub>0</sub></i></tt>+. . .+<tt><i>w<sub>n-1</sub></i></tt>.
15557 </li>
15558 </ol>
15559 <p>
15560 [p5_3] <i>Effects:</i>
15561 </p>
15562 <ol type="a">
15563 <li>
15564 <p>If nf == 0,</p>
15565  <ol type="a">
15566  <li>
15567 sets deltax = <tt><i>x<sub>max</sub></i></tt> - <tt><i>x<sub>min</sub></i></tt>, and</li>
15568 <li> lets the sequence <tt>w</tt> have length <tt>n = 1</tt> and consist of the single
15569     value <tt><i>w<sub>0</sub></i></tt> = 1, and</li>
15570 <li> lets the sequence <tt>b</tt> have length <tt>n+1</tt> with <tt><i>b<sub>0</sub></i></tt> = <tt><i>x<sub>min</sub></i></tt> and
15571               <tt><i>b<sub>1</sub></i></tt> = <tt><i>x<sub>max</sub></i></tt>
15572 </li>
15573 </ol>
15574 </li>
15575 <li>
15576 <p>Otherwise,</p>
15577 <ol type="a">
15578 <li> sets <tt>n = nf</tt>, <tt>deltax = </tt>(<tt><i>x<sub>max</sub></i></tt> - <tt><i>x<sub>min</sub></i></tt>)/n,
15579                  <tt><i>x<sub>cent</sub></i></tt> = <tt><i>x<sub>min</sub></i></tt> + 0.5 * deltax, and
15580 </li>
15581 <li><p>lets the sequences <tt>w</tt> and <tt>b</tt> have length <tt>n</tt> and <tt>n+1</tt>, resp. and</p>
15582 <blockquote><pre>for each k = 0, . . . ,n-1, calculates:
15583   <tt><i>dx<sub>k</sub></i></tt> = k * deltax
15584   <tt><i>b<sub>k</sub></i></tt> = <tt><i>x<sub>min</sub></i></tt> + <tt><i>dx<sub>k</sub></i></tt>
15585   <tt><i>x<sub>k</sub></i></tt> = <tt><i>x<sub>cent</sub></i></tt> + <tt><i>dx<sub>k</sub></i></tt>
15586   <tt><i>w<sub>k</sub></i></tt> = fw(<tt><i>x<sub>k</sub></i></tt>),
15587 </pre></blockquote>
15588 <p> and</p>
15589 </li>
15590 <li> sets <tt><i>b<sub>n</sub></i></tt> = <tt><i>x<sub>max</sub></i></tt></li>
15591 </ol>
15592 </li>
15593 <li>
15594 <p>
15595 Constructs a <tt>piecewise_constant_distribution</tt> object with
15596 the above computed sequence <tt>b</tt> as the interval boundaries
15597 and with the probability densities:
15598 </p>
15599 <blockquote><pre><tt><i>&#961;<sub>k</sub></i></tt> = <tt><i>w<sub>k</sub></i></tt>/(S * deltax)  for k = 0, . . . , n-1.
15600 </pre></blockquote>
15601 </li>
15602 </ol>
15603 <p>
15604 [p5_4] [<i>Note:</i> In this context, the subintervals [<tt><i>b<sub>k</sub></i></tt>, <tt><i>b<sub>k+1</sub></i></tt>) are commonly
15605  known as the <i>bins</i> of a histogram. <i>-- end note</i>]
15606  </p>
15607 </blockquote>
15608 </blockquote>
15609 </li>
15610 </ol>
15611
15612
15613
15614 <p><b>Rationale:</b></p>
15615 Addressed by
15616 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2836.pdf">N2836</a> "Wording Tweaks for Concept-enabled Random Number Generation in C++0X".
15617
15618
15619
15620
15621
15622 <hr>
15623 <h3><a name="795"></a>795. <tt>general_pdf_distribution</tt> should be dropped</h3>
15624 <p><b>Section:</b> X [rand.dist.samp.genpdf] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
15625  <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2008-02-09  <b>Last modified:</b> 2008-03-11</p>
15626 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.genpdf">issues</a> in [rand.dist.samp.genpdf].</p>
15627 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
15628 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#732">732</a></p>
15629 <p><b>Discussion:</b></p>
15630 <p>
15631 <tt>general_pdf_distribution</tt> should be dropped. (It's a research topic in
15632 adaptive numerical integration.)
15633 </p>
15634
15635 <p><i>[
15636 Stephan Tolksdorf notes:
15637 ]</i></p>
15638
15639
15640 <blockquote>
15641 This appears to be a duplicate of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#732">732</a>.
15642 </blockquote>
15643
15644
15645 <p><b>Proposed resolution:</b></p>
15646
15647
15648
15649
15650
15651
15652 <hr>
15653 <h3><a name="796"></a>796. <tt>ranlux48_base</tt> returns wrong value</h3>
15654 <p><b>Section:</b> 26.5.5 [rand.predef] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
15655  <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2008-02-09  <b>Last modified:</b> 2008-02-27</p>
15656 <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>
15657 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
15658 <p><b>Discussion:</b></p>
15659 <p>
15660 The 10,000<sup>th</sup> value returned by <tt>ranlux48_base</tt> is supposed to be
15661 61839128582725. We get 192113843633948. (Note that the underlying
15662 generator was changed in Kona.)
15663 </p>
15664
15665 <p><i>[
15666 Bellevue:
15667 ]</i></p>
15668
15669
15670 <blockquote>
15671 Submitter withdraws defect.
15672 </blockquote>
15673
15674
15675
15676 <p><b>Proposed resolution:</b></p>
15677 <p>
15678 Change 26.5.5 [rand.predef]/p5:
15679 </p>
15680
15681 <blockquote>
15682 <pre>typedef subtract_with_carry_engine&lt;uint_fast64_t, 48, 5, 12&gt;
15683         ranlux48_base;
15684 </pre>
15685 <blockquote>
15686 <i>Required behavior:</i> The 10000<sup>th</sup> consecutive invocation of a default-constructed
15687 object of type <tt>ranlux48_base</tt> shall produce the value
15688 <del>61839128582725</del> <ins>192113843633948</ins>.
15689 </blockquote>
15690 </blockquote>
15691
15692
15693
15694
15695
15696 <hr>
15697 <h3><a name="797"></a>797. <tt>ranlux48</tt> returns wrong value</h3>
15698 <p><b>Section:</b> 26.5.5 [rand.predef] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
15699  <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2008-02-09  <b>Last modified:</b> 2008-02-27</p>
15700 <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>
15701 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
15702 <p><b>Discussion:</b></p>
15703 <p>
15704 The 10,000<sup>th</sup> value returned by <tt>ranlux48</tt> is supposed to be
15705 249142670248501. We get 88229545517833. (Note that this depends
15706 on <tt>ranlux48_base</tt>.)
15707 </p>
15708 <p><i>[
15709 Bellevue:
15710 ]</i></p>
15711
15712
15713 <blockquote>
15714 Submitter withdraws defect.
15715 </blockquote>
15716
15717
15718
15719 <p><b>Proposed resolution:</b></p>
15720 <p>
15721 Change 26.5.5 [rand.predef]/p6:
15722 </p>
15723
15724 <blockquote>
15725 <pre>typedef discard_block_engine&lt;ranlux48_base, 389, 11&gt;
15726         ranlux48
15727 </pre>
15728 <blockquote>
15729 <i>Required behavior:</i> The 10000<sup>th</sup> consecutive invocation of a default-constructed
15730 object of type <tt>ranlux48</tt> shall produce the value
15731 <del>249142670248501</del> <ins>88229545517833</ins>.
15732 </blockquote>
15733 </blockquote>
15734
15735
15736
15737
15738
15739 <hr>
15740 <h3><a name="799"></a>799. [tr.rand.eng.mers] and [rand.eng.mers]</h3>
15741 <p><b>Section:</b> 26.5.3.2 [rand.eng.mers], TR1 5.1.4.2 [tr.rand.eng.mers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
15742  <b>Submitter:</b> Stephan Tolksdorf <b>Opened:</b> 2008-02-18  <b>Last modified:</b> 2008-03-11</p>
15743 <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>
15744 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
15745 <p><b>Discussion:</b></p>
15746 <p>
15747 TR1 5.1.4.2 [tr.rand.eng.mers](10) requires that <tt>operator==</tt> for the <tt>mersenne_twister</tt>
15748 returns <tt>true</tt> if and only if the states of two <tt>mersenne_twisters</tt>,
15749 consisting each of <tt>n</tt> integers between <tt>0</tt> and <tt>2<sup>w</sup> - 1</tt>, are completely
15750 equal. This is a contradiction with TR1 5.1.1 [tr.rand.req](3) because the given
15751 definition of the state also includes the lower <tt>r</tt> bits of <tt>x(i-n)</tt>, which
15752 will never be used to generate a random number. If two <tt>mersenne_twister</tt>s
15753 only differ in the lower bits of <tt>x(i-n)</tt> they will not compare equal,
15754 although they will produce an identical sequence of random numbers.
15755 </p>
15756
15757 <p>
15758 26.5.3.2 [rand.eng.mers] in the latest C++ draft does not specify the behaviour
15759 of <tt>operator==</tt> but uses a similar definition of the state and, just like
15760 TR1 5.1.4.2 [tr.rand.eng.mers], requires the textual representation of a
15761 <tt>mersenne_twister_engine</tt> to consist of <tt>X<sub>i-n</sub></tt> to <tt>X<sub>i-1</sub></tt>, including the
15762 lower bits of <tt>X<sub>i-n</sub></tt>. This leads to two problems: First, the
15763 unsuspecting implementer is likely to erroneously compare the lower <tt>r</tt>
15764 bits of <tt>X<sub>i-n</sub></tt> in <tt>operator==</tt>. Second, if only the lower <tt>r</tt> bits differ,
15765 two <tt>mersenne_twister_engine</tt>s will compare equal (if correctly
15766 implemented) but have different textual representations, which
15767 conceptually is a bit ugly.
15768 </p>
15769
15770 <p>
15771 I propose that a paragraph or footnote is added to 26.5.3.2 [rand.eng.mers] which
15772 clarifies that the lower <tt>r</tt> bits of <tt>X<sub>i-n</sub></tt> are not to be compared in
15773 <tt>operator==</tt> and <tt>operator!=</tt>. It would only be consequent if furthermore
15774 the specification for the textual respresentation was changed to
15775 <tt>X<sub>i-n</sub> bitand ((2<sup>w</sup> - 1) - (2<sup>r</sup> - 1)), X<sub>i-(n-1)</sub>, ...,  X<sub>i-1</sub></tt> or
15776 something similar.
15777 </p>
15778
15779 <p>
15780 These changes would likely have no practical effect, but would allow an
15781 implementation that does the right thing to be standard-conformant.
15782 </p>
15783
15784 <p><i>[
15785 Bellevue:
15786 ]</i></p>
15787
15788
15789 <blockquote>
15790 <p>
15791 Fermi Lab has no objection to the proposed change. However it feels that
15792 more time is needed to check the details, which would suggest a change
15793 to REVIEW.
15794 </p>
15795 <p>
15796 Bill feels that this is NAD, not enough practical importance to abandon
15797 the simple definition of equality, and someone would have to do a lot
15798 more study to ensure that all cases are covered for a very small
15799 payback. The submitter admits that "These changes would likely have no
15800 practical effect,", and according to Plum's razor this means that it is
15801 not worth the effort!
15802 </p>
15803 <p>
15804 Revisted: Agree that the fact that there is no practical difference means that no change can be justified.
15805 </p>
15806 </blockquote>
15807
15808
15809 <p><b>Proposed resolution:</b></p>
15810 <p>
15811 In 26.5.3.2 [rand.eng.mers]:
15812 </p>
15813
15814 <blockquote>
15815 <p>
15816 Insert at the end of para 2.:
15817 </p>
15818
15819 <blockquote>
15820 [<i>Note:</i> The lower <tt>r</tt> bits of <tt>X<sub>i-n</sub></tt> do not influence
15821 the state transition and hence should not be compared when comparing two
15822 <tt>mersenne_twister_engine</tt> objects. <i>-- end note</i>]
15823 </blockquote>
15824
15825 <p>
15826 In para 5. change:
15827 </p>
15828
15829 <blockquote>
15830 The textual representation of <tt>x<sub>i</sub></tt> consists of the values of
15831 <tt>X<sub>i-n</sub> <ins>bitand ((2<sup>w</sup> - 1) - (2<sup>r</sup> - 1)),  X<sub>i-(n-1)</sub></ins>,
15832 ..., X<sub>i-1</sub></tt>, in that order.
15833 </blockquote>
15834 </blockquote>
15835
15836
15837
15838
15839
15840 <hr>
15841 <h3><a name="800"></a>800. Issues in 26.4.7.1 [rand.util.seedseq](6)</h3>
15842 <p><b>Section:</b> 26.5.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
15843  <b>Submitter:</b> Stephan Tolksdorf <b>Opened:</b> 2008-02-18  <b>Last modified:</b> 2009-03-09</p>
15844 <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>
15845 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
15846 <p><b>Discussion:</b></p>
15847 <p>
15848 The for-loop in the algorithm specification has <tt>n</tt> iterations, where <tt>n</tt> is
15849 defined to be <tt>end - begin</tt>, i.e. the number of supplied w-bit quantities.
15850 Previous versions of this algorithm and the general logic behind it
15851 suggest that this is an oversight and that in the context of the
15852 for-loop <tt>n</tt> should be the number of full 32-bit quantities in <tt>b</tt> (rounded
15853 upwards). If <tt>w</tt> is 64, the current algorithm throws away half of all bits
15854 in <tt>b</tt>. If <tt>w</tt> is 16, the current algorithm sets half of all elements in <tt>v</tt>
15855 to 0.
15856 </p>
15857
15858 <p>
15859 There are two more minor issues:
15860 </p>
15861
15862 <ul>
15863 <li>
15864 Strictly speaking <tt>end - begin</tt> is not defined since
15865 <tt>InputIterator</tt> is not required to be a random access iterator.
15866 </li>
15867 <li>
15868 Currently all integral types are allowed as input to the <tt>seed_seq</tt>
15869 constructor, including <tt>bool</tt>. IMHO allowing <tt>bool</tt>s unnecessarily
15870 complicates the implementation without any real benefit to the user.
15871 I'd suggest to exclude <tt>bool</tt>s as input.
15872 </li>
15873 </ul>
15874
15875 <p><i>[
15876 Bellevue:
15877 ]</i></p>
15878
15879
15880 <blockquote>
15881 Move to OPEN Bill will try to propose a resolution by the next meeting.
15882 </blockquote>
15883
15884 <p><i>[
15885 post Bellevue:  Bill provided wording.
15886 ]</i></p>
15887
15888
15889 <p>
15890 This issue is made moot if <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#803">803</a> is accepted.
15891 </p>
15892
15893
15894
15895 <p><b>Proposed resolution:</b></p>
15896 <p>
15897 Replace 26.5.7.1 [rand.util.seedseq] paragraph 6 with:
15898 </p>
15899
15900 <blockquote>
15901 <p>
15902 <i>Effects:</i> Constructs a <tt>seed_seq</tt> object by effectively concatenating the
15903 low-order <tt>u</tt> bits of each of the elements of the supplied sequence <tt>[begin,
15904 end)</tt>
15905 in ascending order of significance to make a (possibly very large) unsigned
15906 binary number <tt>b</tt> having a total of <tt>n</tt> bits, and then carrying out the
15907 following
15908 algorithm:
15909 </p>
15910
15911 <blockquote><pre>for( v.clear(); n &gt; 0; n -= 32 )
15912    v.push_back(b mod 2<sup>32</sup>), b /= 2<sup>32</sup>;
15913 </pre></blockquote>
15914 </blockquote>
15915
15916
15917 <p><b>Rationale:</b></p>
15918 Addressed by
15919 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2836.pdf">N2836</a> "Wording Tweaks for Concept-enabled Random Number Generation in C++0X".
15920
15921
15922
15923
15924
15925 <hr>
15926 <h3><a name="802"></a>802. <tt>knuth_b</tt> returns wrong value</h3>
15927 <p><b>Section:</b> 26.5.5 [rand.predef] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
15928  <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2008-02-20  <b>Last modified:</b> 2008-03-17</p>
15929 <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>
15930 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
15931 <p><b>Discussion:</b></p>
15932 <p>
15933 The 10,000<sup>th</sup> value returned by <tt>knuth_b</tt> is supposed to be
15934 1112339016. We get 2126698284.
15935 </p>
15936
15937
15938 <p><b>Proposed resolution:</b></p>
15939 <p>
15940 Change 26.5.5 [rand.predef]/p8:
15941 </p>
15942
15943 <blockquote>
15944 <pre>typedef shuffle_order_engine&lt;minstd_rand0, 256&gt;
15945         knuth_b;
15946 </pre>
15947 <blockquote>
15948 <i>Required behavior:</i> The 10000<sup>th</sup> consecutive invocation of a default-constructed
15949 object of type <tt>knuth_b</tt> shall produce the value
15950 <del>1112339016</del> <ins>2126698284</ins>.
15951 </blockquote>
15952 </blockquote>
15953
15954
15955 <p><i>[
15956 Bellevue: Submitter withdraws defect. "We got the wrong value for entirely the right reasons". NAD.
15957 ]</i></p>
15958
15959
15960
15961
15962
15963 <hr>
15964 <h3><a name="803"></a>803. Simplification of <tt>seed_seq::seq_seq</tt></h3>
15965 <p><b>Section:</b> 26.5.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
15966  <b>Submitter:</b> Charles Karney <b>Opened:</b> 2008-02-22  <b>Last modified:</b> 2009-03-09</p>
15967 <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>
15968 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
15969 <p><b>Discussion:</b></p>
15970 <p>
15971 <tt>seed_seq(InputIterator begin, InputIterator end);</tt> constructs a <tt>seed_seq</tt>
15972 object repacking the bits of supplied sequence <tt>[begin, end)</tt> into a
15973 32-bit vector.
15974 </p>
15975 <p>
15976 This repacking triggers several problems:
15977 </p>
15978 <ol>
15979 <li>
15980 Distinctness of the output of <tt>seed_seq::generate</tt> required the
15981 introduction of the initial "<tt>if (w &lt; 32) v.push_back(n);</tt>"  (Otherwise
15982 the unsigned short vectors [1, 0] and [1] generate the same sequence.)
15983 </li>
15984 <li>
15985 Portability demanded the introduction of the template parameter <tt>u</tt>.
15986 (Otherwise some sequences could not be obtained on computers where no
15987 integer types are exactly 32-bits wide.)
15988 </li>
15989 <li>
15990 The description and algorithm have become unduly complicated.
15991 </li>
15992 </ol>
15993 <p>
15994 I propose simplifying this <tt>seed_seq</tt> constructor to be "32-bit only".
15995 Despite it's being simpler, there is NO loss of functionality (see
15996 below).
15997 </p>
15998 <p>
15999 Here's how the description would read
16000 </p>
16001 <blockquote>
16002 <p>
16003 26.5.7.1 [rand.util.seedseq] Class <tt>seed_seq</tt>
16004 </p>
16005
16006 <blockquote>
16007 <pre>template&lt;class InputIterator&gt;
16008   seed_seq(InputIterator begin, InputIterator end);
16009 </pre>
16010 <blockquote>
16011 <p>
16012 5 <i>Requires:</i> NO CHANGE
16013 </p>
16014 <p>
16015 6 <i>Effects:</i> Constructs a <tt>seed_seq</tt> object by
16016 </p>
16017 <blockquote>
16018 <pre>for (InputIterator s = begin; s != end; ++s)
16019    v.push_back((*s) mod 2^32);
16020 </pre>
16021 </blockquote>
16022 </blockquote>
16023 </blockquote>
16024 </blockquote>
16025
16026 <p>
16027 Discussion:
16028 </p>
16029 <p>
16030 The chief virtues here are simplicity, portability, and generality.
16031 </p>
16032 <ul>
16033 <li>
16034 Simplicity -- compare the above specification with the
16035 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a> proposal.
16036 </li>
16037 <li>
16038 Portability -- with <tt>iterator_traits&lt;InputIterator&gt;::value_type =
16039 uint_least32_t</tt> the user is guaranteed to get the same behavior across
16040 platforms.
16041 </li>
16042 <li>
16043 Generality -- any behavior that the
16044 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a>
16045 proposal can achieve can be
16046 obtained with this simpler proposal (albeit with a shuffling of bits
16047 in the input sequence).
16048 </li>
16049 </ul>
16050 <p>
16051 Arguments (and counter-arguments) against making this change (and
16052 retaining the
16053 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a>
16054 behavior) are:
16055 </p>
16056 <ul>
16057 <li>
16058 <p>
16059 The user can pass an array of <tt>unsigned char</tt> and <tt>seed_seq</tt> will nicely
16060  repack it.
16061 </p>
16062 <p>
16063  Response: So what?  Consider the seed string "ABC".  The
16064  <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a>
16065  proposal results in
16066 </p>
16067 <blockquote><pre>v = { 0x3, 0x434241 };
16068 </pre></blockquote>
16069 <p>
16070 while the simplified proposal yields
16071 </p>
16072 <blockquote><pre>v = { 0x41, 0x42, 0x43 };
16073 </pre></blockquote>
16074 <p>
16075 The results produced by <tt>seed_seq::generate</tt> with the two inputs are
16076 different but nevertheless equivalently "mixed up" and this remains
16077 true even if the seed string is long.
16078 </p>
16079 </li>
16080 <li>
16081 <p>
16082 With long strings (e.g., with bit-length comparable to the number of
16083  bits in the state), <tt>v</tt> is longer (by a factor of 4) with the simplified
16084  proposal and <tt>seed_seq::generate</tt> will be slower.
16085 </p>
16086 <p>
16087 Response: It's unlikely that the efficiency of <tt>seed_seq::generate</tt> will
16088  be a big issue.  If it is, the user is free to repack the seed vector
16089  before constructing <tt>seed_seq</tt>.
16090 </p>
16091 </li>
16092 <li>
16093 <p>
16094 A user can pass an array of 64-bit integers and all the bits will be
16095  used.
16096 </p>
16097 <p>
16098  Response: Indeed.  However, there are many instances in the
16099  <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a>
16100  where integers are silently coerced to a narrower width and this
16101  should just be a case of the user needing to read the documentation.
16102  The user can of course get equivalent behavior by repacking his seed
16103  into 32-bit pieces.  Furthermore, the unportability of the
16104  <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a>
16105  proposal with
16106 </p>
16107 <blockquote><pre>unsigned long s[] = {1, 2, 3, 4};
16108 seed_seq q(s, s+4);
16109 </pre></blockquote>
16110 <p>
16111  which typically results in <tt>v = {1, 2, 3, 4}</tt> on 32-bit machines and in
16112 <tt>v = {1, 0, 2, 0, 3, 0, 4, 0}</tt> on 64-bit machines is a major pitfall for
16113  unsuspecting users.
16114 </p>
16115 </li>
16116 </ul>
16117
16118 <p>
16119 Note: this proposal renders moot issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#800">800</a>.
16120 </p>
16121
16122 <p><i>[
16123 Bellevue:
16124 ]</i></p>
16125
16126
16127 <blockquote>
16128 Walter needs to ask Fermilab for guidance. Defer till tomorrow. Bill likes the proposed resolution.
16129 </blockquote>
16130
16131 <p><i>[
16132 Sophia Antipolis:
16133 ]</i></p>
16134
16135
16136 <blockquote>
16137 <p>
16138 Marc Paterno wants portable behavior between 32bit and 64bit machines;
16139 we've gone to significant trouble to support portability of engines and
16140 their values.
16141 </p>
16142 <p>
16143 Jens: the new algorithm looks perfectly portable
16144 </p>
16145 <p>
16146 Marc Paterno to review off-line.
16147 </p>
16148 <p>
16149 Modify the proposed resolution to read "Constructs a seed_seq object by the following algorithm ..."
16150 </p>
16151 <p>
16152 Disposition: move to review; unanimous consent.
16153 </p>
16154 <p>
16155 (moots <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#800">800</a>)
16156 </p>
16157 </blockquote>
16158
16159
16160
16161 <p><b>Proposed resolution:</b></p>
16162 <p>
16163 Change 26.5.7.1 [rand.util.seedseq]:
16164 </p>
16165
16166 <blockquote>
16167 <pre>template&lt;class InputIterator<del>,
16168   size_t u = numeric_limits&lt;iterator_traits&lt;InputIterator&gt;::value_type&gt;::digits</del>&gt;
16169   seed_seq(InputIterator begin, InputIterator end);
16170 </pre>
16171 <blockquote>
16172 <p>
16173 -5- <i>Requires:</i> <tt>InputIterator</tt> shall satisfy the requirements of an input iterator (24.1.1)
16174 such that <tt>iterator_traits&lt;InputIterator&gt;::value_type</tt> shall denote an integral type.
16175 </p>
16176 <p>
16177 -6- Constructs a <tt>seed_seq</tt> object by <ins>the following algorithm</ins> <del>rearranging some or all of the bits of the supplied sequence
16178 <tt>[begin,end)</tt> of w-bit quantities into 32-bit units, as if by the following: </del>
16179 </p>
16180 <p>
16181 <del>First extract the rightmost <tt>u</tt> bits from each of the <tt>n = end
16182 - begin</tt> elements of the supplied sequence and concatenate all the
16183 extracted bits to initialize a single (possibly very large) unsigned
16184 binary number, <tt>b = &#8721;<sup>n-1</sup><sub>i=0</sub> (begin[i]
16185 mod 2<sup>u</sup>) · 2<sup>w·i</sup></tt> (in which the bits of each <tt>begin[i]</tt>
16186 are treated as denoting an unsigned quantity). Then carry out
16187 the following algorithm:</del>
16188 </p>
16189 <blockquote><pre><del>
16190 v.clear();
16191 if ($w$ &lt; 32)
16192   v.push_back($n$);
16193 for( ; $n$ &gt; 0; --$n$)
16194   v.push_back(b mod 2<sup>32</sup>), b /= 2<sup>32</sup>;
16195 </del></pre></blockquote>
16196 <blockquote>
16197 <pre><ins>
16198 for (InputIterator s = begin; s != end; ++s)
16199    v.push_back((*s) mod 2<sup>32</sup>);
16200 </ins></pre>
16201 </blockquote>
16202 </blockquote>
16203 </blockquote>
16204
16205
16206 <p><b>Rationale:</b></p>
16207 Addressed by
16208 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2836.pdf">N2836</a> "Wording Tweaks for Concept-enabled Random Number Generation in C++0X".
16209
16210
16211
16212
16213
16214 <hr>
16215 <h3><a name="811"></a>811. <tt>pair</tt> of pointers no longer works with literal 0</h3>
16216 <p><b>Section:</b> 20.3.3 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
16217  <b>Submitter:</b> Doug Gregor <b>Opened:</b> 2008-03-14  <b>Last modified:</b> 2008-09-26</p>
16218 <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>
16219 <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>
16220 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
16221 <p><b>Discussion:</b></p>
16222 <blockquote><pre>#include &lt;utility&gt;
16223
16224 int main()
16225 {
16226    std::pair&lt;char *, char *&gt; p (0,0);
16227 }
16228 </pre></blockquote>
16229
16230 <p>
16231 I just got a bug report about that, because it's valid C++03, but not
16232 C++0x. The important realization, for me, is that the emplace
16233 proposal---which made <tt>push_back</tt> variadic, causing the <tt>push_back(0)</tt>
16234 issue---didn't cause this break in backward compatibility. The break
16235 actually happened when we added this pair constructor as part of adding
16236 rvalue references into the language, long before variadic templates or
16237 emplace came along:
16238 </p>
16239
16240 <blockquote><pre>template&lt;class U, class V&gt; pair(U&amp;&amp; x, V&amp;&amp; y);
16241 </pre></blockquote>
16242
16243 <p>
16244 Now, concepts will address this issue by constraining that <tt>pair</tt>
16245 constructor to only <tt>U</tt>'s and <tt>V</tt>'s that can properly construct "first" and
16246 "second", e.g. (from
16247 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2322.pdf">N2322</a>):
16248 </p>
16249
16250 <blockquote><pre>template&lt;class U , class V &gt;
16251 requires Constructible&lt;T1, U&amp;&amp;&gt; &amp;&amp; Constructible&lt;T2, V&amp;&amp;&gt;
16252 pair(U&amp;&amp; x , V&amp;&amp; y );
16253 </pre></blockquote>
16254
16255 <p><i>[
16256 San Francisco:
16257 ]</i></p>
16258
16259
16260 <blockquote>
16261 <p>
16262 Suggested to resolve using pass-by-value for that case.
16263 </p>
16264 <p>
16265 Side question: Should pair interoperate with tuples? Can construct a
16266 tuple of a pair, but not a pair from a two-element tuple.
16267 </p>
16268 <p>
16269 Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#885">885</a>.
16270 </p>
16271 </blockquote>
16272
16273
16274
16275 <p><b>Proposed resolution:</b></p>
16276 <p>
16277 </p>
16278
16279
16280 <p><b>Rationale:</b></p>
16281 <p><i>[
16282 San Francisco:
16283 ]</i></p>
16284
16285
16286 <blockquote>
16287 Solved by
16288 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2770.pdf">N2770</a>.
16289 </blockquote>
16290
16291
16292
16293
16294
16295
16296
16297 <hr>
16298 <h3><a name="812"></a>812. unsolicited multithreading considered harmful?</h3>
16299 <p><b>Section:</b> 25.5.1 [alg.sort] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
16300  <b>Submitter:</b> Paul McKenney <b>Opened:</b> 2008-02-27  <b>Last modified:</b> 2008-09-17</p>
16301 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
16302 <p><b>Discussion:</b></p>
16303 <p>
16304 Multi-threading is a good thing, but unsolicited multi-threading can
16305 potentially be harmful.  For example, <tt>sort()</tt> performance might be
16306 greatly increased via a multithreaded implementation.  However, such
16307 a multithreaded implementation could result in concurrent invocations
16308 of the user-supplied comparator.  This would in turn result in problems
16309 given a caching comparator that might be written for complex sort keys.
16310 Please note that this is not a theoretical issue, as multithreaded
16311 implementations of <tt>sort()</tt> already exist.
16312 </p>
16313 <p>
16314 Having a multithreaded <tt>sort()</tt> available is good, but it should not
16315 be the default for programs that are not explicitly multithreaded.
16316 Users should not be forced to deal with concurrency unless they have
16317 asked for it.
16318 </p>
16319
16320 <p><i>[
16321 This may be covered by
16322 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2410.html">N2410</a>
16323 Thread-Safety in the Standard Library (Rev 1).
16324 ]</i></p>
16325
16326
16327
16328 <p><b>Proposed resolution:</b></p>
16329 <p>
16330 </p>
16331
16332
16333 <p><b>Rationale:</b></p>
16334 This is already covered by 17.6.5.6/20 in N2723.
16335
16336
16337
16338
16339
16340 <hr>
16341 <h3><a name="826"></a>826. Equivalent of <tt>%'d</tt>, or rather, lack thereof?</h3>
16342 <p><b>Section:</b> 22.4.2.2 [locale.nm.put] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
16343  <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2008-04-07  <b>Last modified:</b> 2008-06-18</p>
16344 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
16345 <p><b>Discussion:</b></p>
16346 <p>
16347 In the spirit of <tt>printf vs iostream</tt>...
16348 </p>
16349
16350 <p>
16351 POSIX <tt>printf</tt> says that <tt>%'d</tt> should insert grouping characters (and the
16352 implication is that in the absence of <tt>'</tt> no grouping characters are
16353 inserted). The <tt>num_put</tt> facet, on the other hand, seems to always insert
16354 grouping characters. Can this be considered a defect worth fixing for
16355 C++0x? Maybe <tt>ios_base</tt> needs an additional flag?
16356 </p>
16357
16358 <p><i>[
16359 Pablo Halpern:
16360 ]</i></p>
16361
16362
16363 <blockquote>
16364 I'm not sure it constitutes a defect, but I would be in favor of adding
16365 another flag (and corresponding manipulator).
16366 </blockquote>
16367
16368 <p><i>[
16369 Martin Sebor:
16370 ]</i></p>
16371
16372
16373 <blockquote>
16374 I don't know if it qualifies as a defect but I agree that there
16375 should be an easy way to control whether the thousands separator
16376 should or shouldn't be inserted. A new flag would be in line with
16377 the current design of iostreams (like <tt>boolalpha</tt>, <tt>showpos</tt>, or
16378 <tt>showbase</tt>).
16379 </blockquote>
16380
16381 <p><i>[
16382 Sophia Antipolis:
16383 ]</i></p>
16384
16385
16386 <blockquote>
16387 This is not a part of C99. LWG suggests submitting a paper may be appropriate.
16388 </blockquote>
16389
16390
16391
16392 <p><b>Proposed resolution:</b></p>
16393 <p>
16394 </p>
16395
16396
16397
16398
16399
16400 <hr>
16401 <h3><a name="831"></a>831. wrong type for not_eof()</h3>
16402 <p><b>Section:</b> 21.2.3 [char.traits.specializations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
16403  <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 2008-04-23  <b>Last modified:</b> 2008-06-19</p>
16404 <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>
16405 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
16406 <p><b>Discussion:</b></p>
16407 <p>
16408   In Table 56 (Traits requirements) the <tt>not_eof()</tt> member function
16409   is using an argument of type <i>e</i> which denotes an object of
16410   type <code>X::int_type</code>. However, the specializations in
16411   21.2.3 [char.traits.specializations] all use <code>char_type</code>.
16412   This would effectively mean that the argument type actually can't
16413   represent EOF in the first place. I'm pretty sure that the type used
16414   to be <code>int_type</code> which is quite obviously the only sensible
16415   argument.
16416 </p>
16417 <p>
16418   This issue is close to being editorial. I suspect that the proposal
16419   changing this section to include the specializations for <code>char16_t</code>
16420   and <code>char32_t</code> accidentally used the wrong type.
16421 </p>
16422
16423
16424 <p><b>Proposed resolution:</b></p>
16425 <p>
16426   In 21.2.3.1 [char.traits.specializations.char],
16427   21.2.3.2 [char.traits.specializations.char16_t],
16428   21.2.3.3 [char.traits.specializations.char32_t], and
16429    [char.traits.specializations.wchar_t] correct the
16430   argument type from <code>char_type</code> to <code>int_type</code>.
16431 </p>
16432
16433
16434 <p><b>Rationale:</b></p>
16435 Already fixed in WP.
16436
16437
16438
16439
16440
16441 <hr>
16442 <h3><a name="832"></a>832. Applying constexpr to System error support</h3>
16443 <p><b>Section:</b> 19.5 [syserr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
16444  <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2008-05-14  <b>Last modified:</b> 2008-09-17</p>
16445 <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>
16446 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
16447 <p><b>Discussion:</b></p>
16448 <p>
16449 Initialization of objects of class <tt>error_code</tt>
16450 (19.5.2 [syserr.errcode]) and class
16451 <tt>error_condition</tt> (19.5.3 [syserr.errcondition]) can be made simpler and more reliable by use of
16452 the new <tt>constexpr</tt> feature
16453 [<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2349.pdf">N2349</a>]
16454 of C++0x. Less code will need to be
16455 generated for both library implementations and user programs when
16456 manipulating constant objects of these types.
16457 </p>
16458
16459 <p>
16460 This was not proposed originally because the constant expressions
16461 proposal was moving into the standard at about the same time as the
16462 Diagnostics Enhancements proposal
16463 [<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2241.html">N2241</a>],
16464 and it wasn't desirable to
16465 make the later depend on the former. There were also technical concerns
16466 as to how <tt>constexpr</tt> would apply to references. Those concerns are now
16467 resolved; <tt>constexpr</tt> can't be used for references, and that fact is
16468 reflected in the proposed resolution.
16469 </p>
16470
16471 <p>
16472 Thanks to Jens Maurer, Gabriel Dos Reis, and Bjarne Stroustrup for clarification of <tt>constexpr</tt> requirements.
16473 </p>
16474
16475 <p>
16476 LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#804">804</a> is related in that it raises the question of whether the
16477 exposition only member <tt>cat_</tt> of class <tt>error_code</tt> (19.5.2 [syserr.errcode]) and class
16478 <tt>error_condition</tt> (19.5.3 [syserr.errcondition]) should be presented as a reference or pointer.
16479 While in the context of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#804">804</a> that is arguably an editorial question,
16480 presenting it as a pointer becomes more or less required with this
16481 proposal, given <tt>constexpr</tt> does not play well with references. The
16482 proposed resolution thus changes the private member to a pointer, which
16483 also brings it in sync with real implementations.
16484 </p>
16485
16486 <p><i>[
16487 Sophia Antipolis:
16488 ]</i></p>
16489
16490
16491 <blockquote>
16492 On going question of extern pointer vs. inline functions for interface.
16493 </blockquote>
16494
16495 <p><i>[
16496 Pre-San Francisco:
16497 ]</i></p>
16498
16499
16500 <blockquote>
16501 <p>
16502 Beman Dawes reports that this proposal is unimplementable, and thus NAD.
16503 </p>
16504 <p>
16505 Implementation would require <tt>constexpr</tt> objects of classes derived
16506 from class <tt>error_category</tt>, which has virtual functions, and that is
16507 not allowed by the core language. This was determined when trying to
16508 implement the proposal using a constexpr enabled compiler provided
16509 by Gabriel Dos Reis, and subsequently verified in discussions with
16510 Gabriel and Jens Maurer.
16511 </p>
16512
16513 </blockquote>
16514
16515
16516 <p><b>Proposed resolution:</b></p>
16517 <p>
16518 The proposed wording assumes the LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#805">805</a> proposed wording has been
16519 applied to the WP, resulting in the former <tt>posix_category</tt> being renamed
16520 <tt>generic_category</tt>. If <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#805">805</a> has not been applied, the names in this
16521 proposal must be adjusted accordingly.
16522 </p>
16523
16524 <p>
16525 Change 19.5.1.1 [syserr.errcat.overview] Class
16526 <tt>error_category</tt> overview <tt>error_category</tt> synopsis  as
16527 indicated:
16528 </p>
16529
16530 <blockquote><pre><del>const error_category&amp; get_generic_category();</del>
16531 <del>const error_category&amp; get_system_category();</del>
16532
16533 <del>static</del> <ins>extern</ins> const error_category<del>&amp;</del><ins>* const</ins> generic_category<del> = get_generic_category()</del>;
16534 <del>static</del> <ins>extern</ins> const error_category<del>&amp;</del><ins>* const</ins> <del>native_category</del> system_category<del> = get_system_category()</del>;
16535 </pre></blockquote>
16536
16537 <p>
16538 Change 19.5.1.5 [syserr.errcat.objects] Error category objects as indicated:
16539 </p>
16540
16541 <blockquote>
16542 <pre><ins>extern</ins> const error_category<del>&amp;</del><ins>* const</ins> <del>get_</del>generic_category<del>()</del>;
16543 </pre>
16544 <p>
16545 <del><i>Returns:</i> A reference</del> <ins><tt>generic_category</tt> shall point</ins>
16546 to <del>an</del> <ins>a statically initialized</ins> object of a type derived from
16547 class <tt>error_category</tt>.
16548 </p>
16549
16550 <p>
16551 <del><i>Remarks:</i></del> The object's <tt>default_error_condition</tt> and <tt>equivalent</tt> virtual
16552 functions shall behave as specified for the class <tt>error_category</tt>. The
16553 object's <tt>name</tt> virtual function shall return a pointer to the string
16554 <tt>"GENERIC"</tt>.
16555 </p>
16556
16557 <pre><ins>extern</ins> const error_category<del>&amp;</del><ins>* const</ins> <del>get_</del>system_category<del>()</del>;
16558 </pre>
16559
16560 <p>
16561 <del><i>Returns:</i> A reference</del> <ins><tt>system_category</tt> shall point</ins>
16562 to <del>an</del> <ins>a statically
16563 initialized</ins> object of a type derived from class <tt>error_category</tt>.
16564 </p>
16565
16566 <p>
16567 <del><i>Remarks:</i></del>  The object's <tt>equivalent</tt> virtual functions shall behave as
16568 specified for class <tt>error_category</tt>. The object's <tt>name</tt> virtual function
16569 shall return a pointer to the string <tt>"system"</tt>. The object's
16570 <tt>default_error_condition</tt> virtual function shall behave as follows:
16571 </p>
16572
16573 <p>
16574 If the argument <tt>ev</tt> corresponds to a POSIX <tt>errno</tt> value <tt>posv</tt>, the function
16575 shall return <tt>error_condition(posv, generic_category)</tt>. Otherwise, the
16576 function shall return <tt>error_condition(ev, system_category)</tt>. What
16577 constitutes correspondence for any given operating system is
16578 unspecified. [<i>Note:</i> The number of potential system error codes is large
16579 and unbounded, and some may not correspond to any POSIX <tt>errno</tt> value.
16580 Thus implementations are given latitude in determining correspondence.
16581 <i>-- end note</i>]
16582 </p>
16583 </blockquote>
16584
16585 <p>
16586 Change 19.5.2.2 [syserr.errcode.overview] Class <tt>error_code</tt> overview as indicated:
16587 </p>
16588
16589 <blockquote><pre>class error_code {
16590 public:
16591   ...;
16592   <ins>constexpr</ins> error_code(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
16593   ...
16594   void assign(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
16595   ...
16596   const error_category<del>&amp;</del><ins>*</ins> category() const;
16597   ...
16598 private:
16599   int val_;                    // exposition only
16600   const error_category<del>&amp;</del><ins>*</ins> cat_; // exposition only
16601 </pre></blockquote>
16602
16603 <p>
16604 Change 19.5.2.3 [syserr.errcode.constructors] Class <tt>error_code</tt> constructors as indicated:
16605 </p>
16606
16607 <blockquote>
16608 <pre><ins>constexpr</ins> error_code(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
16609 </pre>
16610 <p>
16611 <i>Effects:</i> Constructs an object of type <tt>error_code</tt>.
16612 </p>
16613 <p>
16614 <i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == cat</tt>.
16615 </p>
16616 <p>
16617 <i>Throws:</i> Nothing.
16618 </p>
16619 </blockquote>
16620
16621 <p>
16622 Change 19.5.2.4 [syserr.errcode.modifiers] Class <tt>error_code</tt> modifiers  as indicated:
16623 </p>
16624
16625 <blockquote>
16626 <pre>void assign(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
16627 </pre>
16628 <p>
16629 <i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == cat</tt>.
16630 </p>
16631 <p>
16632 <i>Throws:</i> Nothing.
16633 </p>
16634 </blockquote>
16635
16636 <p>
16637 Change 19.5.2.5 [syserr.errcode.observers] Class <tt>error_code</tt> observers  as indicated:
16638 </p>
16639
16640 <blockquote>
16641 <pre>const error_category<del>&amp;</del><ins>*</ins> category() const;
16642 </pre>
16643
16644 <p>
16645 <i>Returns:</i> <tt>cat_</tt>.
16646 </p>
16647 <p>
16648 <i>Throws:</i> Nothing.
16649 </p>
16650 </blockquote>
16651
16652 <p>
16653 Change 19.5.3.2 [syserr.errcondition.overview] Class <tt>error_condition</tt> overview   as indicated:
16654 </p>
16655
16656 <blockquote>
16657 <pre>class error_condition {
16658 public:
16659   ...;
16660   <ins>constexpr</ins> error_condition(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
16661   ...
16662   void assign(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
16663   ...
16664   const error_category<del>&amp;</del><ins>*</ins> category() const;
16665   ...
16666 private:
16667   int val_;                    // exposition only
16668   const error_category<del>&amp;</del><ins>*</ins> cat_; // exposition only
16669 </pre>
16670 </blockquote>
16671
16672 <p>
16673 Change 19.5.3.3 [syserr.errcondition.constructors] Class <tt>error_condition</tt> constructors as indicated:
16674 </p>
16675
16676 <blockquote>
16677 <pre><ins>constexpr</ins> error_condition(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
16678 </pre>
16679 <p>
16680 <i>Effects:</i> Constructs an object of type <tt>error_condition</tt>.
16681 </p>
16682 <p>
16683 <i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == cat</tt>.
16684 </p>
16685 <p>
16686 <i>Throws:</i> Nothing.
16687 </p>
16688 </blockquote>
16689
16690 <p>
16691 Change 19.5.3.4 [syserr.errcondition.modifiers] Class <tt>error_condition</tt> modifiers as indicated:
16692 </p>
16693
16694 <blockquote>
16695 <pre>void assign(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
16696 </pre>
16697 <p>
16698 <i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == cat</tt>.
16699 </p>
16700 <p>
16701 <i>Throws:</i> Nothing.
16702 </p>
16703 </blockquote>
16704
16705 <p>
16706 Change 19.5.3.5 [syserr.errcondition.observers] Class <tt>error_condition</tt> observers as indicated:
16707 </p>
16708
16709 <blockquote>
16710 <pre>const error_category<del>&amp;</del><ins>*</ins> category() const;
16711 </pre>
16712 <p>
16713 <i>Returns:</i> <tt>cat_</tt>.
16714 </p>
16715 <p>
16716 <i>Throws:</i> Nothing.
16717 </p>
16718 </blockquote>
16719
16720 <p>
16721 Throughout 19.5 [syserr] System error support, change "<tt>category().</tt>"  to "<tt>category()-&gt;</tt>".
16722 Appears approximately six times.
16723 </p>
16724
16725 <p>
16726 <i>[Partially Editorial]</i> In 19.5.4 [syserr.compare] Comparison operators,
16727 paragraphs 2 and 4, change "<tt>category.equivalent(</tt>"  to
16728 "<tt>category()-&gt;equivalent(</tt>".
16729 </p>
16730
16731 <p>
16732 Change 19.5.5.1 [syserr.syserr.overview] Class system_error overview as indicated:
16733 </p>
16734
16735 <blockquote><pre>public:
16736   system_error(error_code ec, const string&amp; what_arg);
16737   system_error(error_code ec);
16738   system_error(int ev, const error_category<del>&amp;</del><ins>*</ins> ecat,
16739       const string&amp; what_arg);
16740   system_error(int ev, const error_category<del>&amp;</del><ins>*</ins> ecat);
16741 </pre></blockquote>
16742
16743 <p>
16744 Change 19.5.5.2 [syserr.syserr.members] Class system_error members as indicated:
16745 </p>
16746
16747 <blockquote>
16748 <pre>system_error(int ev, const error_category<del>&amp;</del><ins>*</ins> ecat, const string&amp; what_arg);
16749 </pre>
16750 <blockquote>
16751 <p>
16752 <i>Effects:</i> Constructs an object of class <tt>system_error</tt>.
16753 </p>
16754 <p>
16755 <i>Postconditions:</i> <tt>code() == error_code(ev, ecat)</tt> and
16756 <tt>strcmp(runtime_error::what(), what_arg.c_str()) == 0</tt>.
16757 </p>
16758 </blockquote>
16759
16760 <pre>system_error(int ev, const error_category<del>&amp;</del><ins>*</ins> ecat);
16761 </pre>
16762 <blockquote>
16763 <p>
16764 <i>Effects:</i> Constructs an object of class <tt>system_error</tt>.
16765 </p>
16766 <p>
16767 <i>Postconditions:</i> <tt>code() == error_code(ev, ecat)</tt> and
16768 <tt>strcmp(runtime_error::what(), "") == 0</tt>.
16769 </p>
16770 </blockquote>
16771 </blockquote>
16772
16773
16774
16775 <p><b>Rationale:</b></p>
16776 <p><i>[
16777 San Francisco:
16778 ]</i></p>
16779
16780
16781 <blockquote>
16782 NAD because Beman said so.
16783 </blockquote>
16784
16785
16786
16787
16788
16789 <hr>
16790 <h3><a name="840"></a>840. <tt>pair</tt> default template argument</h3>
16791 <p><b>Section:</b> 20.3.3 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
16792  <b>Submitter:</b> Thorsten Ottosen <b>Opened:</b> 2008-05-23  <b>Last modified:</b> 2008-06-18</p>
16793 <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>
16794 <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>
16795 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
16796 <p><b>Discussion:</b></p>
16797 <p>
16798 I have one issue with <tt>std::pair</tt>. Well, it might just be a very annoying
16799 historical accident, but why is there no default template argument for
16800 the second template argument? This is so annoying when the type in
16801 question is looong and hard to write (type deduction with <tt>auto</tt> won't
16802 help those cases where we use it as a return or argument type).
16803 </p>
16804
16805
16806 <p><b>Proposed resolution:</b></p>
16807 <p>
16808 Change the synopsis in 20.3 [utility] to read:
16809 </p>
16810
16811 <blockquote><pre>template &lt;class T1, class T2 <ins>= T1</ins>&gt; struct pair;
16812 </pre></blockquote>
16813
16814 <p>
16815 Change 20.3.3 [pairs] to read:
16816 </p>
16817
16818 <blockquote><pre>namespace std {
16819  template &lt;class T1, class T2 <ins>= T1</ins>&gt;
16820  struct pair {
16821    typedef T1 first_type;
16822    typedef T2 second_type;
16823    ...
16824 </pre></blockquote>
16825
16826
16827 <p><b>Rationale:</b></p>
16828 <tt>std::pair</tt> is a heterogeneous container.
16829
16830
16831
16832
16833
16834 <hr>
16835 <h3><a name="841"></a>841. cstdint.syn inconsistent with C99</h3>
16836 <p><b>Section:</b> 18.4.1 [cstdint.syn] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
16837  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2008-05-17  <b>Last modified:</b> 2008-09-17</p>
16838 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#cstdint.syn">issues</a> in [cstdint.syn].</p>
16839 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
16840 <p><b>Discussion:</b></p>
16841    <p>
16842
16843 In specifying the names of macros and types defined in
16844 header <code>&lt;stdint.h&gt;</code>, C99 makes use of the
16845 symbol <code><i>N</i></code> to accommodate unusual platforms with
16846 word sizes that aren't powers of two. C99
16847 permits <code><i>N</i></code> to take on any positive integer value
16848 (including, for example, 24).
16849
16850    </p>
16851    <p>
16852
16853 In  cstdint.syn Header <code>&lt;cstdint&gt;</code>
16854 synopsis, C++ on the other hand, fixes the value
16855 of <code><i>N</i></code> to 8, 16, 32, and 64, and specifies only
16856 types with these exact widths.
16857
16858    </p>
16859    <p>
16860    </p>
16861
16862 In addition, paragraph 1 of the same section makes use of a rather
16863 informal shorthand notation to specify sets of macros. When
16864 interpreted strictly, the notation specifies macros such
16865 as <code>INT_8_MIN</code> that are not intended to be specified.
16866
16867    <p>
16868
16869 Finally, the section is missing the usual table of symbols defined
16870 in that header, making it inconsistent with the rest of the
16871 specification.
16872
16873    </p>
16874
16875  <p><b>Proposed resolution:</b></p>
16876    <p>
16877
16878 I propose to use the same approach in the C++ spec as C99 uses, that
16879 is, to specify the header synopsis in terms of "exposition only" types
16880 that make use of the symbol <code><i>N</i></code> to denote one or
16881 more of a theoretically unbounded set of widths.
16882
16883    </p>
16884    <p>
16885
16886 Further, I propose to add a new table to section listing the symbols
16887 defined in the header using a more formal notation that avoids
16888 introducing inconsistencies.
16889
16890    </p>
16891    <p>
16892
16893 To this effect, in  cstdint.syn
16894 Header <code>&lt;cstdint&gt;</code> synopsis, replace both the
16895 synopsis and paragraph 1 with the following text:
16896
16897    </p>
16898    <blockquote>
16899      <p>
16900        </p><ol>
16901          <li>
16902
16903 In the names defined in the <code>&lt;cstdint&gt;</code> header, the
16904 symbol <code><i>N</i></code> represents a positive decimal integer
16905 with no leading zeros (e.g., 8 or 24, but not 0, 04, or 048). With the
16906 exception of exact-width types, macros and types for values
16907 of <code><i>N</i></code> in the set of 8, 16, 32, and 64 are
16908 required. Exact-width types, and any macros and types for values
16909 of <code><i>N</i></code> other than 8, 16, 32, and 64 are
16910 optional. However, if an implementation provides integer types with
16911 widths of 8, 16, 32, or 64 bits, the corresponding exact-width types
16912 and macros are required.
16913
16914          </li>
16915        </ol>
16916
16917      <pre>namespace std {
16918
16919    // required types
16920
16921    // Fastest minimum-width integer types
16922    typedef <i>signed integer type</i>   int_fast8_t;
16923    typedef <i>signed integer type</i>   int_fast16_t;
16924    typedef <i>signed integer type</i>   int_fast32_t;
16925    typedef <i>signed integer type</i>   int_fast64_t;
16926
16927    typedef <i>unsigned integer type</i> uint_fast8_t;
16928    typedef <i>unsigned integer type</i> uint_fast16_t;
16929    typedef <i>unsigned integer type</i> uint_fast32_t;
16930    typedef <i>unsigned integer type</i> uint_fast64_t;
16931
16932    // Minimum-width integer types
16933    typedef <i>signed integer type</i>   int_least8_t;
16934    typedef <i>signed integer type</i>   int_least16_t;
16935    typedef <i>signed integer type</i>   int_least32_t;
16936    typedef <i>signed integer type</i>   int_least64_t;
16937
16938    typedef <i>unsigned integer type</i> uint_least8_t;
16939    typedef <i>unsigned integer type</i> uint_least16_t;
16940    typedef <i>unsigned integer type</i> uint_least32_t;
16941    typedef <i>unsigned integer type</i> uint_least64_t;
16942
16943    // Greatest-width integer types
16944    typedef <i>signed integer type</i>   intmax_t;
16945    typedef <i>unsigned integer type</i> uintmax_t;
16946
16947    // optionally defined types
16948
16949    // Exact-width integer types
16950    typedef <i>signed integer type</i>   int<i>N</i>_t;
16951    typedef <i>unsigned integer type</i> uint<i>N</i>_t;
16952
16953    // Fastest minimum-width integer types for values
16954    // of <i>N</i> other than 8, 16, 32, and 64
16955    typedef <i>signed integer type</i>   uint_fast<i>N</i>_t;
16956    typedef <i>unsigned integer type</i> uint_fast<i>N</i>_t;
16957
16958    // Minimum-width integer types for values
16959    // of <i>N</i> other than 8, 16, 32, and 64
16960    typedef <i>signed integer type</i>   uint_least<i>N</i>_t;
16961    typedef <i>unsigned integer type</i> uint_least<i>N</i>_t;
16962
16963    // Integer types capable of holding object pointers
16964    typedef <i>signed integer type</i>   intptr_t;
16965    typedef <i>signed integer type</i>   intptr_t;
16966
16967 }</pre>
16968    </blockquote>
16969    <p>
16970
16971 [Note to editor: Remove all of the existing paragraph 1 from  cstdint.syn.]
16972
16973    </p>
16974    <blockquote>
16975      Table ??: Header <code>&lt;cstdint&gt;</code> synopsis
16976      <table border="1">
16977        <thead>
16978          <tr>
16979            <th>Type</th>
16980            <th colspan="3">Name(s)</th>
16981          </tr>
16982        </thead>
16983        <tbody>
16984          <tr>
16985            <td rowspan="11"><b>Macros:</b></td>
16986            <td><tt>INT<i>N</i>_MIN</tt></td>
16987            <td><tt>INT<i>N</i>_MAX</tt></td>
16988            <td><tt>UINT<i>N</i>_MAX</tt></td>
16989          </tr>
16990          <tr>
16991            <td><tt>INT_FAST<i>N</i>_MIN</tt></td>
16992            <td><tt>INT_FAST<i>N</i>_MAX</tt></td>
16993            <td><tt>UINT_FAST<i>N</i>_MAX</tt></td>
16994          </tr>
16995          <tr>
16996            <td><tt>INT_LEAST<i>N</i>_MIN</tt></td>
16997            <td><tt>INT_LEAST<i>N</i>_MAX</tt></td>
16998            <td><tt>UINT_LEAST<i>N</i>_MAX</tt></td>
16999          </tr>
17000          <tr>
17001            <td><tt>INTPTR_MIN</tt></td>
17002            <td><tt>INTPTR_MAX</tt></td>
17003            <td><tt>UINTPTR_MAX</tt></td>
17004          </tr>
17005          <tr>
17006            <td><tt>INTMAX_MIN</tt></td>
17007            <td><tt>INTMAX_MAX</tt></td>
17008            <td><tt>UINTMAX_MAX</tt></td>
17009          </tr>
17010          <tr>
17011            <td><tt>PTRDIFF_MIN</tt></td>
17012            <td><tt>PTRDIFF_MAX</tt></td>
17013            <td><tt>PTRDIFF_MAX</tt></td>
17014          </tr>
17015          <tr>
17016            <td><tt>SIG_ATOMIC_MIN</tt></td>
17017            <td><tt>SIG_ATOMIC_MAX</tt></td>
17018            <td><tt>SIZE_MAX</tt></td>
17019          </tr>
17020          <tr>
17021            <td><tt>WCHAR_MIN</tt></td>
17022            <td><tt>WCHAR_MAX</tt></td>
17023          <td></td>
17024          </tr>
17025          <tr>
17026            <td><tt>WINT_MIN</tt></td>
17027            <td><tt>WINT_MAX</tt></td>
17028            <td></td>
17029          </tr>
17030          <tr>
17031            <td><tt>INT<i>N</i>_C()</tt></td>
17032            <td><tt>UINT<i>N</i>_C()</tt></td>
17033            <td></td>
17034          </tr>
17035          <tr>
17036            <td><tt>INTMAX_C()</tt></td>
17037            <td><tt>UINTMAX_C()</tt></td>
17038            <td></td>
17039          </tr>
17040          <tr>
17041            <td rowspan="5"><b>Types:</b></td>
17042            <td><tt>int<i>N</i>_t</tt></td>
17043            <td><tt>uint<i>N</i>_t</tt></td>
17044            <td></td>
17045          </tr>
17046          <tr>
17047            <td><tt>int_fast<i>N</i>_t</tt></td>
17048            <td><tt>uint_fast<i>N</i>_t</tt></td>
17049            <td></td>
17050          </tr>
17051          <tr>
17052            <td><tt>int_least<i>N</i>_t</tt></td>
17053            <td><tt>uint_least<i>N</i>_t</tt></td>
17054            <td></td>
17055          </tr>
17056          <tr>
17057            <td><tt>intptr_t</tt></td>
17058            <td><tt>uintptr_t</tt></td>
17059            <td></td>
17060          </tr>
17061          <tr>
17062            <td><tt>intmax_t</tt></td>
17063            <td><tt>uintmax_t</tt></td>
17064            <td></td>
17065          </tr>
17066        </tbody>
17067      </table>
17068    </blockquote>
17069
17070
17071
17072
17073
17074 <hr>
17075 <h3><a name="849"></a>849. missing type traits to compute root class and derived class of types in a class hierachy</h3>
17076 <p><b>Section:</b> 20.6.7 [meta.trans.other] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
17077  <b>Submitter:</b> Thorsten Ottosen <b>Opened:</b> 2008-06-05  <b>Last modified:</b> 2008-09-16</p>
17078 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta.trans.other">active issues</a> in [meta.trans.other].</p>
17079 <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>
17080 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
17081 <p><b>Discussion:</b></p>
17082 <p>
17083 The type traits library contains various traits to dealt with
17084 polymorphic types, e.g. <tt>std::has_virtual_destructor</tt>, <tt>std::is_polymorphic</tt>
17085 and <tt>std::is_base_of</tt>. However, there is no way to compute the unique
17086 public base class of a type  if such  one exists.  Such a trait could be
17087 very useful if one needs to instantiate a specialization made for the
17088 root class whenever a derived class is passed as parameter. For example,
17089 imagine that you wanted to specialize <tt>std::hash</tt> for a class
17090 hierarchy---instead of specializing each class, you could specialize the
17091 <tt>std::hash&lt;root_class&gt;</tt> and provide a partial specialization that worked
17092 for all derived classes.
17093 </p>
17094
17095 <p>
17096 This ability---to specify operations in terms of their equivalent in the
17097 root class---can be done with e.g. normal functions, but there is,
17098 AFAIK, no way to do it for class templates. Being able to access
17099 compile-time information about the type-hierachy can be very powerful,
17100 and I therefore also suggest traits that computes the directly derived
17101 class whenever that is possible.
17102 </p>
17103
17104 <p>
17105 If the computation can not be done, the traits should fall back on an
17106 identity transformation. I expect this gives the best overall usability.
17107 </p>
17108
17109
17110 <p><b>Proposed resolution:</b></p>
17111 <p>
17112 Add the following to the synopsis in 20.6.2 [meta.type.synop] under "other transformations":
17113 </p>
17114
17115 <blockquote><pre>template&lt; class T &gt; struct direct_base_class;
17116 template&lt; class T &gt; struct direct_derived_class;
17117 template&lt; class T &gt; struct root_base_class;
17118 </pre></blockquote>
17119
17120 <p>
17121 Add three new entries to table 51 (20.6.7 [meta.trans.other]) with the following content
17122 </p>
17123
17124 <blockquote>
17125 <table border="1">
17126 <tbody><tr>
17127 <th>Template</th><th>Condition</th><th>Comments</th>
17128 </tr>
17129 <tr>
17130 <td><tt>template&lt; class T &gt; struct direct_base_class;</tt></td>
17131 <td><tt>T</tt> shall be a complete type.</td>
17132 <td>The member typedef <tt>type</tt> shall equal the accessible unambiguous direct base class of <tt>T</tt>.
17133 If no such type exists, the member typedef <tt>type</tt> shall equal <tt>T</tt>.</td>
17134 </tr>
17135 <tr>
17136 <td><tt>template&lt; class T &gt; struct direct_derived_class;</tt></td>
17137 <td><tt>T</tt> shall be a complete type.</td>
17138 <td>The member typedef <tt>type</tt> shall equal the unambiguous type which has <tt>T</tt>
17139 as an accessible unambiguous direct base class. If no such type exists, the member typedef
17140 <tt>type</tt> shall equal <tt>T</tt>.</td>
17141 </tr>
17142 <tr>
17143 <td><tt>template&lt; class T &gt; struct root_base_class;</tt></td>
17144 <td><tt>T</tt> shall be a complete type.</td>
17145 <td>The member typedef <tt>type</tt> shall equal the accessible unambiguous most indirect base class of
17146 <tt>T</tt>. If no such type exists, the member typedef type shall equal <tt>T</tt>.</td>
17147 </tr>
17148 </tbody></table>
17149 </blockquote>
17150
17151
17152
17153 <p><b>Rationale:</b></p>
17154 2008-9-16 San Francisco:  Issue pulled by author prior to being reviewed by the LWG.
17155
17156
17157
17158
17159
17160 <hr>
17161 <h3><a name="855"></a>855. capacity() and reserve() for deque?</h3>
17162 <p><b>Section:</b> 23.3.2.2 [deque.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
17163  <b>Submitter:</b> Hervé Brönnimann <b>Opened:</b> 2008-06-11  <b>Last modified:</b> 2008-09-22</p>
17164 <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>
17165 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
17166 <p><b>Discussion:</b></p>
17167 <p>
17168 The main point is that <tt>capacity</tt> can be viewed as a mechanism to
17169 guarantee the validity of <tt>iterators</tt> when only <tt>push_back/pop_back</tt>
17170 operations are used.  For <tt>vector</tt>, this goes with reallocation.  For
17171 <tt>deque</tt>, this is a bit more subtle:  <tt>capacity()</tt> of a <tt>deque</tt> may shrink,
17172 whereas that of <tt>vector</tt> doesn't.   In a circular buffer impl. of the
17173 map, as Howard did, there is very similar notion of capacity: as long
17174 as <tt>size()</tt> is less than <tt>B * (</tt>total size of the map <tt>- 2)</tt>, it is
17175 guaranteed that no <tt>iterator</tt> is invalidated after any number of
17176 <tt>push_front/back</tt> and <tt>pop_front/back</tt> operations.  But this does not
17177 hold for other implementations.
17178 </p>
17179 <p>
17180 Still, I believe, <tt>capacity()</tt> can be defined by <tt>size() +</tt>  how many
17181 <tt>push_front/back</tt> minus <tt>pop_front/back</tt> that can be performed before
17182 terators are invalidated.  In a classical impl., <tt>capacity() = size()
17183 + </tt> the min distance to either "physical" end of the deque (i.e.,
17184 counting the empty space in the last block plus all the blocks until
17185 the end of the map of block pointers).  In Howard's circular buffer
17186 impl., <tt>capacity() = B * (</tt>total size of the map <tt>- 2)</tt> still works with
17187 this definition, even though the guarantee could be made stronger.
17188 </p>
17189 <p>
17190 A simple picture of a deque:
17191 </p>
17192 <blockquote><pre>A-----|----|-----|---F+|++++|++B--|-----|-----Z
17193 </pre></blockquote>
17194 <p>
17195 (A,Z mark the beginning/end, | the block boundaries, F=front, B=back,
17196 and - are uninitialized, + are initialized)
17197 In that picture:  <tt>capacity = size() + min(dist(A,F),dist(B,Z)) = min
17198 (dist(A,B),dist(F,Z))</tt>.
17199 </p>
17200 <p>
17201 <tt>Reserve(n)</tt> can grow the map of pointers and add possibly a number of
17202 empty blocks to it, in order to guarantee that the next <tt>n-size()
17203 push_back/push_front</tt> operations will not invalidate iterators, and
17204 also will not allocate (i.e. cannot throw).  The second guarantee is
17205 not essential and can be left as a QoI.  I know well enough existing
17206 implementations of <tt>deque</tt> (sgi/stl, roguewave, stlport, and
17207 dinkumware) to know that either can be implemented with no change to
17208 the existing class layout and code, and only a few modifications if
17209 blocks are pre-allocated (instead of always allocating a new block,
17210 check if the next entry in the map of block pointers is not zero).
17211 </p>
17212 <p>
17213 Due to the difference with <tt>vector</tt>, wording is crucial.  Here's a
17214 proposed wording to make things concrete;  I tried to be reasonably
17215 careful but please double-check me:
17216 </p>
17217
17218 <p><i>[
17219 San Francisco:
17220 ]</i></p>
17221
17222
17223 <blockquote>
17224 <p>
17225 Hans: should the Returns clause for capacity read "1 Returns: A lower
17226 bound..." rather than "1 Returns: An upper bound..."
17227 </p>
17228 <p>
17229 Howard: maybe what's needed is capacity_front and capacity_back. In
17230 fact, I think I implemented a deque that had these members as
17231 implementation details.
17232 </p>
17233 </blockquote>
17234
17235
17236
17237 <p><b>Proposed resolution:</b></p>
17238
17239 <p>
17240 Add new signatures to synopsis in 23.3.2 [deque]:
17241 </p>
17242
17243 <blockquote><pre>size_type capacity() const;
17244 bool reserve(size_type n);
17245 </pre></blockquote>
17246
17247 <p>
17248 Add new signatures to 23.3.2.2 [deque.capacity]:
17249 </p>
17250
17251 <blockquote>
17252 <pre>size_type capacity() const;
17253 </pre>
17254 <blockquote>
17255 <p>
17256 1 <i>Returns:</i> An upper bound on <tt>n + max(n_f - m_f, n_b - m_b)</tt>  such
17257 that, for any sequence of <tt>n_f push_front</tt>, <tt>m_f pop_front</tt>, <tt>n_b
17258 push_back</tt>, and <tt>m_b pop_back</tt> operations, interleaved in any order,
17259 starting with the current <tt>deque</tt> of size <tt>n</tt>, the <tt>deque</tt> does not
17260 invalidate any of its iterators except to the erased elements.
17261 </p>
17262 <p>
17263 2 <i>Remarks:</i>  Unlike a <tt>vector</tt>'s capacity, the capacity of a <tt>deque</tt> can
17264 decrease after a sequence of insertions at both ends, even if none of
17265 the operations caused the <tt>deque</tt> to invalidate any of its iterators
17266 except to the erased elements.
17267 </p>
17268 </blockquote>
17269 </blockquote>
17270
17271 <blockquote>
17272 <pre>bool reserve(size_type n);
17273 </pre>
17274 <blockquote>
17275 <p>
17276 2 <i>Effects:</i> A directive that informs a <tt>deque</tt> of a planned sequence of
17277 <tt>push_front</tt>, <tt>pop_front</tt>, <tt>push_back</tt>, and <tt>pop_back</tt> operations, so that it
17278 can manage iterator invalidation accordingly. After <tt>reserve()</tt>,
17279 <tt>capacity()</tt> is greater or equal to the argument of <tt>reserve</tt> if this
17280 operation returns <tt>true</tt>; and equal to the previous value of <tt>capacity()</tt>
17281 otherwise.  If an exception is thrown, there are no effects.
17282 </p>
17283 <p>
17284 3 <i>Returns:</i> <tt>true</tt> if iterators are invalidated as a result of this
17285 operation, and false otherwise.
17286 </p>
17287 <p>
17288 4 <i>Complexity:</i> It does not change the size of the sequence and takes
17289 at most linear time in <tt>n</tt>.
17290 </p>
17291 <p>
17292 5 <i>Throws:</i> <tt>length_error</tt> if <tt>n &gt; max_size()</tt>.
17293 </p>
17294 <p>
17295 6 <i>Remarks:</i> It is guaranteed that no invalidation takes place during a
17296 sequence of <tt>insert</tt> or <tt>erase</tt> operations at either end that happens
17297 after a call to <tt>reserve()</tt> except to the erased elements, until the
17298 time when an insertion would make <tt>max(n_f-m_f, n_b-m_b)</tt> larger than
17299 <tt>capacity()</tt>, where <tt>n_f</tt> is the number of <tt>push_front</tt>, <tt>m_f</tt> of <tt>pop_front</tt>,
17300 <tt>n_b</tt> of <tt>push_back</tt>, and <tt>m_b</tt> of <tt>pop_back</tt> operations since the call to
17301 <tt>reserve()</tt>.
17302 </p>
17303 <p>
17304 7        An implementation is free to pre-allocate buffers so as to
17305 offer the additional guarantee that no exception will be thrown
17306 during such a sequence other than by the element constructors.
17307 </p>
17308 </blockquote>
17309 </blockquote>
17310
17311 <p>
17312 And 23.3.2.3 [deque.modifiers] para 1, can be enhanced:
17313 </p>
17314
17315 <blockquote>
17316 1 <i>Effects:</i> An insertion in the middle of the deque invalidates all the iterators and references to elements of the
17317 deque. An insertion at either end of the deque invalidates all the iterators to the deque,
17318 <ins>unless provisions have been made with reserve,</ins>
17319 but has no effect on the validity of references to elements of the deque.
17320 </blockquote>
17321
17322
17323 <p><b>Rationale:</b></p>
17324 Complication outweighs the benefit.
17325
17326
17327
17328
17329
17330 <hr>
17331 <h3><a name="864"></a>864. Defect in atomic wording</h3>
17332 <p><b>Section:</b> 29.6 [atomics.types.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
17333  <b>Submitter:</b> Anthony Williams <b>Opened:</b> 2008-07-10  <b>Last modified:</b> 2008-09-17</p>
17334 <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>
17335 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
17336 <p><b>Discussion:</b></p>
17337 <p>
17338 There's an error in 29.6 [atomics.types.operations]/p9:
17339 </p>
17340
17341 <blockquote>
17342 <pre>C atomic_load(const volatile A * object);
17343 C atomic_load_explicit(const volatile A * object, memory_order);
17344 C A ::load(memory_order order = memory_order_seq_cst) const volatile;
17345 </pre>
17346 <blockquote>
17347 <p>
17348 <i>Requires:</i> The <tt>order</tt> argument shall not be <tt>memory_order_acquire</tt> nor
17349 <tt>memory_order_acq_rel</tt>.
17350 </p>
17351 </blockquote>
17352 </blockquote>
17353
17354 <p>
17355 I believe that this should state
17356 </p>
17357 <blockquote>
17358 shall not be <tt>memory_order_release</tt>.
17359 </blockquote>
17360
17361 <p>
17362 There's also an error in 29.6 [atomics.types.operations]/p17:
17363 </p>
17364
17365 <blockquote>
17366 ... When only one <tt>memory_order</tt> argument is supplied, the value of success
17367 is <tt>order</tt>, and
17368 the value of failure is <tt>order</tt> except that a value of
17369 <tt>memory_order_acq_rel</tt> shall be replaced by the value
17370 <tt>memory_order_require</tt> ...
17371 </blockquote>
17372 <p>
17373 I believe this should state
17374 </p>
17375 <blockquote>
17376 shall be replaced by the value <tt>memory_order_acquire</tt> ...
17377 </blockquote>
17378
17379
17380 <p><b>Proposed resolution:</b></p>
17381 <p>
17382 Change 29.6 [atomics.types.operations]/p9:
17383 </p>
17384
17385 <blockquote>
17386 <pre>C atomic_load(const volatile A * object);
17387 C atomic_load_explicit(const volatile A * object, memory_order);
17388 C A ::load(memory_order order = memory_order_seq_cst) const volatile;
17389 </pre>
17390 <blockquote>
17391 <p>
17392 <i>Requires:</i> The <tt>order</tt> argument shall not be <del><tt>memory_order_acquire</tt></del>
17393 <ins><tt>memory_order_release</tt></ins> nor <tt>memory_order_acq_rel</tt>.
17394 </p>
17395 </blockquote>
17396 </blockquote>
17397
17398 <p>
17399 Change 29.6 [atomics.types.operations]/p17:
17400 </p>
17401
17402 <blockquote>
17403 ... When only one <tt>memory_order</tt> argument is supplied, the value of success
17404 is <tt>order</tt>, and
17405 the value of failure is <tt>order</tt> except that a value of
17406 <tt>memory_order_acq_rel</tt> shall be replaced by the value
17407 <del><tt>memory_order_require</tt></del> <ins><tt>memory_order_acquire</tt></ins> ...
17408 </blockquote>
17409
17410
17411
17412 <p><b>Rationale:</b></p>
17413 Already fixed by the time the LWG processed it.
17414
17415
17416
17417
17418
17419 <hr>
17420 <h3><a name="870"></a>870. Do unordered containers not support function pointers for predicate/hasher?</h3>
17421 <p><b>Section:</b> 23.2.5 [unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
17422  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-08-17  <b>Last modified:</b> 2008-09-22</p>
17423 <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>
17424 <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>
17425 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
17426 <p><b>Discussion:</b></p>
17427 <p>
17428 Good ol' associative containers allow both function pointers and
17429 function objects as feasible
17430 comparators, as described in 23.2.4 [associative.reqmts]/2:
17431 </p>
17432
17433 <blockquote>
17434 Each associative container is parameterized on <tt>Key</tt> and an ordering
17435 relation <tt>Compare</tt> that
17436 induces a strict weak ordering (25.3) on elements of Key. [..]. The
17437 object of type <tt>Compare</tt> is
17438 called the comparison object of a container. This comparison object
17439 may be a pointer to
17440 function or an object of a type with an appropriate function call operator.[..]
17441 </blockquote>
17442
17443 <p>
17444 The corresponding wording for unordered containers is not so clear,
17445 but I read it to disallow
17446 function pointers for the hasher and I miss a clear statement for the
17447 equality predicate, see
17448 23.2.5 [unord.req]/3+4+5:
17449 </p>
17450
17451 <blockquote>
17452 <p>
17453 Each unordered associative container is parameterized by <tt>Key</tt>, by a
17454 function object <tt>Hash</tt> that
17455 acts as a hash function for values of type <tt>Key</tt>, and by a binary
17456 predicate <tt>Pred</tt> that induces an
17457 equivalence relation on values of type <tt>Key</tt>.[..]
17458 </p>
17459 <p>
17460 A hash function is a function object that takes a single argument of
17461 type <tt>Key</tt> and returns a
17462 value of type <tt>std::size_t</tt>.
17463 </p>
17464 <p>
17465 Two values <tt>k1</tt> and <tt>k2</tt> of type <tt>Key</tt> are considered equal if the
17466 container's equality function object
17467 returns <tt>true</tt> when passed those values.[..]
17468 </p>
17469 </blockquote>
17470
17471 <p>
17472 and table 97 says in the column "assertion...post-condition" for the
17473 expression X::hasher:
17474 </p>
17475
17476 <blockquote>
17477 <tt>Hash</tt> shall be a unary function object type such that the expression
17478 <tt>hf(k)</tt> has type <tt>std::size_t</tt>.
17479 </blockquote>
17480
17481 <p>
17482 Note that 20.7 [function.objects]/1 defines as "Function objects are
17483 objects with an <tt>operator()</tt> defined.[..]"
17484 </p>
17485 <p>
17486 Does this restriction exist by design or is it an oversight? If an
17487 oversight, I suggest that to apply
17488 the following
17489 </p>
17490
17491
17492 <p><b>Proposed resolution:</b></p>
17493 <p>
17494 In 23.2.5 [unord.req]/3, just after the second sentence which is written as
17495 </p>
17496
17497 <blockquote>
17498 Additionally, <tt>unordered_map</tt> and <tt>unordered_multimap</tt> associate an
17499 arbitrary mapped type <tt>T</tt> with the <tt>Key</tt>.
17500 </blockquote>
17501
17502 <p>
17503 add one further sentence:
17504 </p>
17505
17506 <blockquote>
17507 Both <tt>Hash</tt> and <tt>Pred</tt> may be pointers to function or objects of a type
17508 with an appropriate function call operator.
17509 </blockquote>
17510
17511 <p>
17512 [Note1: Since the detailed requirements for <tt>Pred</tt> and <tt>Hash</tt> are given in
17513 p.4 and p.5, it an alternative resolution
17514 would be to insert a new paragraph just after p.5, which contains the
17515 above proposed sentence]
17516 </p>
17517 <p>
17518 [Note2: I do not propose a change of above quoted element in table 97,
17519 because the mis-usage of the
17520 notion of "function object" seems already present in the standard at
17521 several places, even if it includes
17522 function pointers, see e.g. 25 [algorithms]/7. The important point is
17523 that in those places a statement is
17524 given that the actually used symbol, like "Predicate" applies for
17525 function pointers as well]
17526 </p>
17527
17528
17529 <p><b>Rationale:</b></p>
17530 <p><i>[
17531 San Francisco:
17532 ]</i></p>
17533
17534
17535 <blockquote>
17536 This is fixed by
17537 <a href="" ref="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2776.pdf">N2776</a>.
17538 </blockquote>
17539
17540
17541
17542
17543
17544
17545 <hr>
17546 <h3><a name="871"></a>871. Iota's requirements on T are too strong</h3>
17547 <p><b>Section:</b> 26.7.5 [numeric.iota] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
17548  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-08-20  <b>Last modified:</b> 2008-09-23</p>
17549 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
17550 <p><b>Discussion:</b></p>
17551 <p>
17552 According to the recent WP
17553 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2691.pdf">N2691</a>,
17554 26.7.5 [numeric.iota]/1, the requires clause
17555 of <tt>std::iota</tt> says:
17556 </p>
17557
17558 <blockquote>
17559 <tt>T</tt> shall meet the requirements of <tt>CopyConstructible</tt> and <tt>Assignable</tt> types, and
17560 shall be convertible to <tt>ForwardIterator</tt>'s value type.[..]
17561 </blockquote>
17562
17563 <p>
17564 Neither <tt>CopyConstructible</tt> nor <tt>Assignable</tt> is needed, instead <tt>MoveConstructible</tt>
17565 seems to be the correct choice. I guess the current wording resulted as an
17566 artifact from comparing it with similar numerical algorithms like <tt>accumulate</tt>.
17567 </p>
17568
17569 <p>
17570 Note: If this function will be conceptualized, the here proposed
17571 <tt>MoveConstructible</tt>
17572 requirement can be removed, because this is an implied requirement of
17573 function arguments, see
17574 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2710.pdf">N2710</a>/[temp.req.impl]/3, last bullet.
17575 </p>
17576
17577
17578
17579 <p><b>Proposed resolution:</b></p>
17580
17581 <p>
17582 Change the first sentence of 26.7.5 [numeric.iota]/1:
17583 </p>
17584
17585 <blockquote>
17586 <i>Requires:</i> <tt>T</tt> shall <del>meet the requirements of
17587 <tt>CopyConstructible</tt> and <tt>Assignable</tt> types,</del>
17588 <ins>
17589 be <tt>MoveConstructible</tt> (Table 34)
17590 </ins>
17591 and shall be
17592 convertible to <tt>ForwardIterator</tt>'s value type. [..]
17593 </blockquote>
17594
17595
17596
17597 <p><b>Rationale:</b></p>
17598 <p><i>[
17599 post San Francisco:
17600 ]</i></p>
17601
17602
17603 <blockquote>
17604 Issue pulled by author prior to review.
17605 </blockquote>
17606
17607
17608
17609
17610
17611
17612 <hr>
17613 <h3><a name="872"></a>872. <tt>move_iterator::operator[]</tt> has wrong return type</h3>
17614 <p><b>Section:</b> 24.5.3.2.12 [move.iter.op.index] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
17615  <b>Submitter:</b> Doug Gregor <b>Opened:</b> 2008-08-21  <b>Last modified:</b> 2008-09-22</p>
17616 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
17617 <p><b>Discussion:</b></p>
17618 <p>
17619 <tt>move_iterator</tt>'s <tt>operator[]</tt> is declared as:
17620 </p>
17621
17622 <blockquote><pre>reference operator[](difference_type n) const;
17623 </pre></blockquote>
17624
17625 <p>
17626 This has the same problem that <tt>reverse_iterator</tt>'s <tt>operator[]</tt> used to
17627 have: if the underlying iterator's <tt>operator[]</tt> returns a proxy, the
17628 implicit conversion to <tt>value_type&amp;&amp;</tt> could end up referencing a temporary
17629 that has already been destroyed. This is essentially the same issue that
17630 we dealt with for <tt>reverse_iterator</tt> in DR <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#386">386</a>.
17631 </p>
17632
17633
17634 <p><b>Proposed resolution:</b></p>
17635 <p>
17636 In 24.5.3.1 [move.iterator] and 24.5.3.2.12 [move.iter.op.index], change the declaration of
17637 <tt>move_iterator</tt>'s <tt>operator[]</tt> to:
17638 </p>
17639
17640 <blockquote><pre><del>reference</del> <ins><i>unspecified</i></ins> operator[](difference_type n) const;
17641 </pre></blockquote>
17642
17643
17644
17645 <p><b>Rationale:</b></p>
17646 <p><i>[
17647 San Francisco:
17648 ]</i></p>
17649
17650
17651 <blockquote>
17652 NAD Editorial, see
17653 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2777.pdf">N2777</a>.
17654 </blockquote>
17655
17656
17657
17658
17659 <hr>
17660 <h3><a name="874"></a>874. Missing <tt>initializer_list</tt> constructor for <tt>discrete_distribution</tt></h3>
17661 <p><b>Section:</b> 26.5.8.5.1 [rand.dist.samp.discrete] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
17662  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-08-22  <b>Last modified:</b> 2009-03-09</p>
17663 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.discrete">issues</a> in [rand.dist.samp.discrete].</p>
17664 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
17665 <p><b>Discussion:</b></p>
17666 <p>
17667 During the Sophia Antipolis meeting it was decided to separate from <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#793">793</a> a
17668 subrequest that adds initializer list support to
17669 <tt>discrete_distribution</tt>, specifically,
17670 the issue proposed to add a c'tor taking a <tt>initializer_list&lt;double&gt;</tt>.
17671 </p>
17672
17673
17674
17675 <p><b>Proposed resolution:</b></p>
17676 <ol>
17677 <li>
17678 <p>
17679 In 26.5.8.5.1 [rand.dist.samp.discrete]/1, class <tt>discrete_distribution</tt>,
17680 just <em>before</em> the member declaration
17681 </p>
17682
17683 <blockquote><pre>explicit discrete_distribution(const param_type&amp; parm);
17684 </pre></blockquote>
17685
17686 <p>
17687 insert
17688 </p>
17689
17690 <blockquote><pre>discrete_distribution(initializer_list&lt;double&gt; wl);
17691 </pre></blockquote>
17692 </li>
17693
17694 <li>
17695 <p>
17696 Between p.4 and p.5 of the same section insert a new
17697 paragraph as part of the new member description:
17698 </p>
17699
17700 <blockquote><pre>discrete_distribution(initializer_list&lt;double&gt; wl);
17701 </pre>
17702
17703 <blockquote>
17704 <i>Effects:</i> Same as <tt>discrete_distribution(wl.begin(), wl.end())</tt>.
17705 </blockquote>
17706 </blockquote>
17707 </li>
17708 </ol>
17709
17710
17711 <p><b>Rationale:</b></p>
17712 Addressed by
17713 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2836.pdf">N2836</a> "Wording Tweaks for Concept-enabled Random Number Generation in C++0X".
17714
17715
17716
17717
17718
17719 <hr>
17720 <h3><a name="875"></a>875. Missing <tt>initializer_list</tt> constructor for <tt>piecewise_constant_distribution</tt></h3>
17721 <p><b>Section:</b> 26.5.8.5.2 [rand.dist.samp.pconst] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
17722  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-08-22  <b>Last modified:</b> 2009-03-09</p>
17723 <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>
17724 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
17725 <p><b>Discussion:</b></p>
17726 <p>
17727 During the Sophia Antipolis meeting it was decided to separate from
17728 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#794">794</a> a subrequest that adds initializer list support to
17729 <tt>piecewise_constant_distribution</tt>, specifically, the issue proposed
17730 to add a c'tor taking a <tt>initializer_list&lt;double&gt;</tt> and a <tt>Callable</tt> to evaluate
17731 weight values. For consistency with the remainder of this class and
17732 the remainder of the <tt>initializer_list</tt>-aware library the author decided to
17733 change the list argument type to the template parameter <tt>RealType</tt>
17734 instead. For the reasoning to use <tt>Func</tt> instead of <tt>Func&amp;&amp;</tt> as c'tor
17735 function argument see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#793">793</a>.
17736 </p>
17737
17738
17739 <p><b>Proposed resolution:</b></p>
17740 <p><b>Non-concept version of the proposed resolution</b></p>
17741
17742 <ol>
17743 <li>
17744 <p>
17745 In 26.5.8.5.2 [rand.dist.samp.pconst]/1, class <tt>piecewise_constant_distribution</tt>,
17746 just <em>before</em> the member declaration
17747 </p>
17748
17749 <blockquote><pre>explicit piecewise_constant_distribution(const param_type&amp; parm);
17750 </pre></blockquote>
17751
17752 <p>
17753 insert
17754 </p>
17755
17756 <blockquote><pre>template&lt;typename Func&gt;
17757 piecewise_constant_distribution(initializer_list&lt;RealType&gt; bl, Func fw);
17758 </pre></blockquote>
17759 </li>
17760
17761 <li>
17762 <p>
17763 Between p.4 and p.5 of the same section insert a series of
17764 new paragraphs nominated below as [p5_1], [p5_2], and [p5_3]
17765 as part of the new member description:
17766 </p>
17767
17768 <blockquote><pre>template&lt;typename Func&gt;
17769 piecewise_constant_distribution(initializer_list&lt;RealType&gt; bl, Func fw);
17770 </pre>
17771
17772 <blockquote>
17773
17774 <p>
17775 [p5_1] <i>Complexity:</i> Exactly <tt>nf = max(bl.size(), 1) - 1</tt> invocations of <tt>fw</tt>.
17776 </p>
17777
17778 <p>
17779 [p5_2] <i>Requires:</i>
17780 </p>
17781
17782 <ol type="a">
17783 <li>
17784 <tt>fw</tt> shall be callable with one argument of type <tt>RealType</tt>, and shall
17785    return values of a type convertible to <tt>double</tt>;
17786 </li>
17787 <li>
17788 The relation <tt>0 &lt; S = w<sub>0</sub>+. . .+w<sub>n-1</sub></tt> shall hold.
17789 For all sampled values <tt><i>x<sub>k</sub></i></tt> defined below, <tt>fw(<i>x<sub>k</sub></i>)</tt> shall return a weight
17790    value <tt><i>w<sub>k</sub></i></tt> that is non-negative, non-NaN, and non-infinity;
17791 </li>
17792 <li>
17793 If <tt>nf &gt; 0</tt> let <tt>b<sub><i>k</i></sub> = *(bl.begin() + k), k = 0, . . . , bl.size()-1</tt> and the
17794 following relations shall hold for <tt>k = 0, . . . , nf-1: b<sub><i>k</i></sub> &lt; b<sub><i>k+1</i></sub></tt>.
17795 </li>
17796 </ol>
17797
17798 <p>
17799 [p5_3] <i>Effects:</i>
17800 </p>
17801
17802 <ol type="a">
17803 <li>
17804 <p>If <tt>nf == 0</tt>,</p>
17805 <ol type="a">
17806 <li>
17807 lets the sequence <tt>w</tt> have length <tt>n = 1</tt> and consist of the single
17808      value <tt>w<sub>0</sub> = 1</tt>, and
17809 </li>
17810 <li>
17811 lets the sequence <tt>b</tt> have length <tt>n+1</tt> with <tt>b<sub>0</sub> = 0</tt> and <tt>b<sub>1</sub> = 1</tt>.
17812 </li>
17813 </ol>
17814 </li>
17815
17816 <li>
17817 <p>Otherwise,</p>
17818 <ol type="a">
17819 <li>
17820 sets <tt>n = nf</tt>, and <tt>[bl.begin(), bl.end())</tt> shall form the sequence <tt>b</tt> of
17821 length <tt>n+1</tt>, and
17822 </li>
17823 <li>
17824 <p>lets the sequences <tt>w</tt> have length <tt>n</tt> and for each <tt>k = 0, . . . ,n-1</tt>,
17825      calculates:</p>
17826 <blockquote><pre>x<sub><i>k</i></sub> = 0.5*(b<sub><i>k+1</i></sub> + b<sub><i>k</i></sub>)
17827 w<sub><i>k</i></sub> = fw(x<sub><i>k</i></sub>)
17828 </pre></blockquote>
17829 </li>
17830 </ol>
17831 </li>
17832
17833 <li>
17834 <p>
17835 Constructs a <tt>piecewise_constant_distribution</tt> object with
17836 the above computed sequence <tt>b</tt> as the interval boundaries
17837 and with the probability densities:
17838 </p>
17839 <blockquote><pre>&#961;<sub><i>k</i></sub> = w<sub><i>k</i></sub>/(S * (b<sub><i>k+1</i></sub> - b<sub><i>k</i></sub>)) for k = 0, . . . , n-1.
17840 </pre></blockquote>
17841
17842 </li>
17843 </ol>
17844
17845 </blockquote>
17846 </blockquote>
17847 </li>
17848 </ol>
17849
17850 <p><b>Concept version of the proposed resolution</b></p>
17851
17852 <ol>
17853 <li>
17854 <p>
17855 In 26.5.8.5.2 [rand.dist.samp.pconst]/1, class <tt>piecewise_constant_distribution</tt>,
17856 just <em>before</em> the member declaration
17857 </p>
17858
17859 <blockquote><pre>explicit piecewise_constant_distribution(const param_type&amp; parm);
17860 </pre></blockquote>
17861
17862 <p>
17863 insert
17864 </p>
17865
17866 <blockquote><pre>template&lt;Callable&lt;auto, RealType&gt; Func&gt;
17867  requires Convertible&lt;Func::result_type, double&gt;
17868 piecewise_constant_distribution(initializer_list&lt;RealType&gt; bl, Func fw);
17869 </pre></blockquote>
17870 </li>
17871
17872 <li>
17873 <p>
17874 Between p.4 and p.5 of the same section insert a series of
17875 new paragraphs nominated below as [p5_1], [p5_2], and [p5_3]
17876 as part of the new member description:
17877 </p>
17878
17879 <blockquote><pre>template&lt;Callable&lt;auto, RealType&gt; Func&gt;
17880  requires Convertible&lt;Func::result_type, double&gt;
17881 piecewise_constant_distribution(initializer_list&lt;RealType&gt; bl, Func fw);
17882 </pre>
17883
17884 <blockquote>
17885
17886 <p>
17887 [p5_1] <i>Complexity:</i> Exactly <tt>nf = max(bl.size(), 1) - 1</tt> invocations of <tt>fw</tt>.
17888 </p>
17889
17890 <p>
17891 [p5_2] <i>Requires:</i>
17892 </p>
17893
17894 <ol type="a">
17895 <li>
17896 The relation <tt>0 &lt; S = w<sub>0</sub>+. . .+w<sub>n-1</sub></tt> shall hold.
17897 For all sampled values <tt><i>x<sub>k</sub></i></tt> defined below, <tt>fw(<i>x<sub>k</sub></i>)</tt> shall return a weight
17898    value <tt><i>w<sub>k</sub></i></tt> that is non-negative, non-NaN, and non-infinity;
17899 </li>
17900 <li>
17901 If <tt>nf &gt; 0</tt> let <tt>b<sub><i>k</i></sub> = *(bl.begin() + k), k = 0, . . . , bl.size()-1</tt> and the
17902 following relations shall hold for <tt>k = 0, . . . , nf-1: b<sub><i>k</i></sub> &lt; b<sub><i>k+1</i></sub></tt>.
17903 </li>
17904 </ol>
17905
17906 <p>
17907 [p5_3] <i>Effects:</i>
17908 </p>
17909
17910 <ol type="a">
17911 <li>
17912 <p>If <tt>nf == 0</tt>,</p>
17913 <ol type="a">
17914 <li>
17915 lets the sequence <tt>w</tt> have length <tt>n = 1</tt> and consist of the single
17916      value <tt>w<sub>0</sub> = 1</tt>, and
17917 </li>
17918 <li>
17919 lets the sequence <tt>b</tt> have length <tt>n+1</tt> with <tt>b<sub>0</sub> = 0</tt> and <tt>b<sub>1</sub> = 1</tt>.
17920 </li>
17921 </ol>
17922 </li>
17923
17924 <li>
17925 <p>Otherwise,</p>
17926 <ol type="a">
17927 <li>
17928 sets <tt>n = nf</tt>, and <tt>[bl.begin(), bl.end())</tt> shall form the sequence <tt>b</tt> of
17929 length <tt>n+1</tt>, and
17930 </li>
17931 <li>
17932 <p>lets the sequences <tt>w</tt> have length <tt>n</tt> and for each <tt>k = 0, . . . ,n-1</tt>,
17933      calculates:</p>
17934 <blockquote><pre>x<sub><i>k</i></sub> = 0.5*(b<sub><i>k+1</i></sub> + b<sub><i>k</i></sub>)
17935 w<sub><i>k</i></sub> = fw(x<sub><i>k</i></sub>)
17936 </pre></blockquote>
17937 </li>
17938 </ol>
17939 </li>
17940
17941 <li>
17942 <p>
17943 Constructs a <tt>piecewise_constant_distribution</tt> object with
17944 the above computed sequence <tt>b</tt> as the interval boundaries
17945 and with the probability densities:
17946 </p>
17947 <blockquote><pre>&#961;<sub><i>k</i></sub> = w<sub><i>k</i></sub>/(S * (b<sub><i>k+1</i></sub> - b<sub><i>k</i></sub>)) for k = 0, . . . , n-1.
17948 </pre></blockquote>
17949
17950 </li>
17951 </ol>
17952
17953 </blockquote>
17954 </blockquote>
17955 </li>
17956 </ol>
17957
17958
17959
17960 <p><b>Rationale:</b></p>
17961 Addressed by
17962 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2836.pdf">N2836</a> "Wording Tweaks for Concept-enabled Random Number Generation in C++0X".
17963
17964
17965
17966
17967
17968 <hr>
17969 <h3><a name="892"></a>892. Forward_list issues...</h3>
17970 <p><b>Section:</b> 23.3.3.5 [forwardlist.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
17971  <b>Submitter:</b> Ed Smith-Rowland <b>Opened:</b> 2008-09-15  <b>Last modified:</b> 2009-03-09</p>
17972 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#forwardlist.ops">active issues</a> in [forwardlist.ops].</p>
17973 <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>
17974 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
17975 <p><b>Discussion:</b></p>
17976 <p>
17977 I was looking at the latest draft on <tt>forward_list</tt>.  Especially the splice methods.
17978 </p>
17979 <p>
17980 The first one splices a whole list after a given iterator in <tt>this</tt>.  The name is <tt>splice_after</tt>.
17981 I think in 23.3.3.5 [forwardlist.ops] paragraph 40
17982 change:
17983 </p>
17984 <blockquote>
17985 <i>Effect:</i> Insert the contents of <tt>x</tt> <del>before</del> <ins>after</ins> <tt>position</tt>, ...
17986 </blockquote>
17987
17988 <p>
17989 A deeper issue involves the complexity.  <tt>forward_list</tt> has no <tt>size</tt> and we
17990 don't know when we've reached the end except to walk up to it.  To
17991 splice we would need to hook the end of the source list to the item
17992 after <tt>position</tt> in this list.  This would involve walking length of the
17993 source list until we got to the last dereference-able element in source.
17994 There's no way we could do this in O(1) unless we stored a bogus end in
17995 <tt>forward_list</tt>.
17996 </p>
17997 <p>
17998 OTOH, the last version of <tt>splice_after</tt> with iterator ranges we could do
17999 in O(1) because we know how to hook the end of the source range to ...
18000 </p>
18001 <p>
18002 Unless I'm misconceiving the whole thing.  Which is possible.  I'll look at it again.
18003 </p>
18004 <p>
18005 I'm pretty sure about the first part though.
18006 </p>
18007
18008 <p><i>[
18009 San Francisco:
18010 ]</i></p>
18011
18012
18013 <blockquote>
18014 <p>
18015 This issue is more complicated than it looks.
18016 </p>
18017 <p>
18018 paragraph 47: replace each <tt>(first, last) with (first, last]</tt>
18019 </p>
18020 <p>
18021 add a statement after paragraph 48 that complexity is O(1)
18022 </p>
18023 <p>
18024 remove the complexity statement from the first overload of splice_after
18025 </p>
18026 <p>
18027 We may have the same problems with other modifiers, like erase_after.
18028 Should it require that all iterators in the range (position, last] be
18029 dereferenceable?
18030 </p>
18031 <p>
18032 We do, however, like the proposed changes and consider them Editorial.
18033 Move to NAD Editorial, Pending. Howard to open a new issue to handle the
18034 problems with the complexity requirements.
18035 </p>
18036 <p>
18037 Opened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#897">897</a>.
18038 </p>
18039 </blockquote>
18040
18041
18042 <p><b>Proposed resolution:</b></p>
18043 <p>
18044 In 23.3.3.5 [forwardlist.ops] paragraph 40
18045 change:
18046 </p>
18047 <blockquote>
18048 <i>Effect:</i> Insert the contents of <tt>x</tt> <del>before</del> <ins>after</ins> <tt>position</tt>, ...
18049 </blockquote>
18050
18051
18052
18053
18054
18055 <hr>
18056 <h3><a name="905"></a>905. Mutex specification questions</h3>
18057 <p><b>Section:</b> 30.4.1.1 [thread.mutex.class] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
18058  <b>Submitter:</b> Herb Sutter <b>Opened:</b> 2008-09-18  <b>Last modified:</b> 2009-03-22</p>
18059 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.mutex.class">active issues</a> in [thread.mutex.class].</p>
18060 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.mutex.class">issues</a> in [thread.mutex.class].</p>
18061 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
18062 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#893">893</a></p>
18063 <p><b>Discussion:</b></p>
18064 <p>
18065 A few questions on the current WP,
18066 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>:
18067 </p>
18068 <p>
18069 30.4.1 [thread.mutex.requirements]/24 says an expression
18070 <tt>mut.unlock()</tt> "Throws: Nothing." I'm assuming that, per 17.6.3.11 [res.on.required], errors that violate the precondition "The
18071 calling thread shall own the mutex" opens the door for throwing an
18072 exception anyway, such as to report unbalanced unlock operations and
18073 unlocking from a thread that does not have ownership. Right?
18074 </p>
18075 <p>
18076 30.4.1.1 [thread.mutex.class]/3 (actually numbered paragraph "27"
18077 in the WP; this is just a typo I think) says
18078 </p>
18079 <blockquote>
18080 <p>
18081 The behavior of a program is undefined if:
18082 </p>
18083 <ul>
18084 <li>it destroys a <tt>mutex</tt> object owned by any thread,</li>
18085 <li>a thread that owns a <tt>mutex</tt> object calls <tt>lock()</tt> or <tt>try_lock()</tt> on that object, or</li>
18086 <li>a thread terminates while owning a <tt>mutex</tt> object.</li>
18087 </ul>
18088 </blockquote>
18089
18090 <p>
18091 As already discussed, I think the second bullet should be removed, and
18092 such a <tt>lock()</tt> or <tt>try_lock()</tt> should fail with an
18093 exception or returning <tt>false</tt>, respectively.
18094 </p>
18095 <p>
18096 A potential addition to the list would be
18097 </p>
18098 <ul>
18099 <li>a thread unlocks a <tt>mutex</tt> it does not have ownership of.</li>
18100 </ul>
18101 <p>
18102 but without that the status quo text endorses the technique of the
18103 program logically transferring ownership of a mutex to another thread
18104 with correctness enforced by programming discipline. Was that intended?
18105 </p>
18106
18107 <p><i>[
18108 Summit:
18109 ]</i></p>
18110
18111
18112 <blockquote>
18113 <p>
18114 Two resolutions: "not a defect" and "duplicate", as follows:
18115 </p>
18116 <ul>
18117 <li>
18118 30.4.1 [thread.mutex.requirements]/24: NAD. If the precondition
18119 fails the program has undefined behaviour and therefore an
18120 implementation may throw an exception already.
18121 </li>
18122 <li>
18123 30.4.1.1 [thread.mutex.class]/3 bullet 2: Already addressed by issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#893">893</a>.
18124 </li>
18125 <li>
18126 30.4.1.1 [thread.mutex.class]/3 proposed addition: NAD. This is
18127 already covered by the mutex requirements, which have ownership as a
18128 Precondition.
18129 </li>
18130 </ul>
18131 </blockquote>
18132
18133
18134 <p><b>Proposed resolution:</b></p>
18135
18136
18137
18138
18139
18140
18141 <hr>
18142 <h3><a name="937"></a>937. Atomics for standard typedef types</h3>
18143 <p><b>Section:</b> 29 [atomics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
18144  <b>Submitter:</b> Clark Nelson <b>Opened:</b> 2008-12-05  <b>Last modified:</b> 2009-05-23</p>
18145 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#atomics">active issues</a> in [atomics].</p>
18146 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics">issues</a> in [atomics].</p>
18147 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
18148 <p><b>Discussion:</b></p>
18149
18150 <p><b>Addresses US 89</b></p>
18151
18152 <blockquote>
18153 <p>
18154 The types in the table "Atomics for standard typedef types" should be
18155 typedefs, not classes. These semantics are necessary for compatibility
18156 with C.
18157 </p>
18158
18159 <p>
18160 Change the classes to typedefs.
18161 </p>
18162 </blockquote>
18163
18164 <p>
18165 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2427.html">N2427</a>
18166 specified different requirements for atomic analogs of fundamental
18167 integer types (such as <tt>atomic_int</tt>) and for atomic analogs of <tt>&lt;cstdint&gt;</tt>
18168 typedefs (such as <tt>atomic_size_t</tt>). Specifically, <tt>atomic_int</tt> et al. were
18169 specified to be distinct classes, whereas <tt>atomic_size_t</tt> et al. were
18170 specified to be typedefs. Unfortunately, in applying
18171 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2427.html">N2427</a>
18172 to the WD, that distinction was erased, and the atomic analog of every <tt>&lt;cstdint&gt;</tt>
18173 typedef is required to be a distinct class.
18174 </p>
18175
18176 <p>
18177 It shouldn't be required that the atomic analog of every <tt>&lt;cstdint&gt;</tt>
18178 typedef be a typedef for some fundamental integer type. After all,
18179 <tt>&lt;cstdint&gt;</tt> is supposed to provide standard names for extended integer
18180 types. So there was a problem in
18181 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2427.html">N2427</a>,
18182 which certainly could have been
18183 interpreted to require that. But the status quo in the WD is even worse,
18184 because it's unambiguously wrong.
18185 </p>
18186
18187 <p>
18188 What is needed are words to require the existence of a bunch of type
18189 names, without specifying whether they are class names or typedef names.
18190 </p>
18191
18192 <p><i>[
18193 Summit:
18194 ]</i></p>
18195
18196
18197 <blockquote>
18198 <p>
18199 Change status to NAD, editorial. See US 89 comment notes above.
18200 </p>
18201 <p>
18202 Direct the editor to turn the types into typedefs as proposed in the
18203 comment. Paper approved by committee used typedefs, this appears to have
18204 been introduced as an editorial change. Rationale: for compatibility
18205 with C.
18206 </p>
18207 </blockquote>
18208
18209
18210 <p><b>Proposed resolution:</b></p>
18211 <p>
18212 </p>
18213
18214
18215
18216
18217
18218 <hr>
18219 <h3><a name="942"></a>942. Atomics synopsis typo</h3>
18220 <p><b>Section:</b> 29 [atomics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
18221  <b>Submitter:</b> Holger Grund <b>Opened:</b> 2008-12-19  <b>Last modified:</b> 2009-03-22</p>
18222 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#atomics">active issues</a> in [atomics].</p>
18223 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics">issues</a> in [atomics].</p>
18224 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
18225 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#880">880</a></p>
18226 <p><b>Discussion:</b></p>
18227
18228
18229
18230 <p>
18231 I'm looking at 29 [atomics] and can't really make sense of a couple of things.
18232 </p>
18233 <p>
18234 Firstly, there appears to be a typo in the <tt>&lt;cstdatomic&gt;</tt> synopsis:
18235 </p>
18236
18237 <blockquote>
18238 <p>
18239 The <tt>atomic_exchange</tt> overload taking an <tt>atomic_address</tt>
18240 is missing the second parameter:
18241 </p>
18242
18243 <blockquote><pre>void* atomic_exchange(volatile atomic_address*);
18244 </pre></blockquote>
18245
18246 <p>
18247 should be
18248 </p>
18249
18250 <blockquote><pre>void* atomic_exchange(volatile atomic_address*<ins>, void*</ins>);
18251 </pre></blockquote>
18252
18253 <p>
18254 Note, that this is <em>not</em> covered by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#880">880</a> "Missing atomic exchange parameter",
18255 which only talks about the <tt>atomic_bool</tt>.
18256 </p>
18257 </blockquote>
18258
18259
18260
18261 <p><b>Proposed resolution:</b></p>
18262 <p>
18263 Change the synopsis in 29 [atomics]/2:
18264 </p>
18265
18266 <blockquote><pre>void* atomic_exchange(volatile atomic_address*<ins>, void*</ins>);
18267 </pre></blockquote>
18268
18269
18270
18271
18272
18273
18274 <hr>
18275 <h3><a name="980"></a>980. <tt>mutex lock()</tt> missing error conditions</h3>
18276 <p><b>Section:</b> 30.4.1 [thread.mutex.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
18277  <b>Submitter:</b> Ion Gaztañaga <b>Opened:</b> 2009-02-07  <b>Last modified:</b> 2009-03-22</p>
18278 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.mutex.requirements">active issues</a> in [thread.mutex.requirements].</p>
18279 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.mutex.requirements">issues</a> in [thread.mutex.requirements].</p>
18280 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
18281 <p><b>Discussion:</b></p>
18282 <p>
18283 POSIX 2008 adds two return values for <tt>pthread_mutex_xxxlock()</tt>:
18284 <tt>EOWNERDEAD</tt> (<tt>owner_dead</tt>) and <tt>ENOTRECOVERABLE</tt>
18285 (<tt>state_not_recoverable</tt>). In the first case the mutex is locked,
18286 in the second case the mutex is not locked.
18287 </p>
18288
18289 <p>
18290 Throwing an exception in the first case can be incompatible with the use
18291 of Locks, since the <tt>Lock::owns_lock()</tt> will be <tt>false</tt> when the lock is
18292 being destroyed.
18293 </p>
18294
18295 <p>
18296 Consider:
18297 </p>
18298
18299 <blockquote><pre>//Suppose mutex.lock() throws "owner_dead"
18300 unique_lock ul(&amp;mutex);
18301 //mutex left locked if "owner_dead" is thrown
18302 </pre></blockquote>
18303
18304 <p>
18305 Throwing an exception with <tt>owner_dead</tt> might be also undesirable if
18306 robust-mutex support is added to C++ and the user has the equivalent of
18307 <tt>pthread_mutex_consistent()</tt> to notify the user has fixed the corrupted
18308 data and the mutex state should be marked consistent.
18309 </p>
18310
18311 <ol>
18312 <li>
18313 For <tt>state_not_recoverable</tt> add it to the list of Error conditions:
18314 </li>
18315 <li>
18316 For <tt>owner_dead</tt>, no proposed resolution.
18317 </li>
18318 </ol>
18319
18320 <p><i>[
18321 Summit:
18322 ]</i></p>
18323
18324
18325 <blockquote>
18326 Not a defect. Handling these error conditions is an implementation
18327 detail and must be handled below the C++ interface.
18328 </blockquote>
18329
18330
18331
18332 <p><b>Proposed resolution:</b></p>
18333
18334 <p>
18335 Add to 30.4.1 [thread.mutex.requirements], p12:
18336 </p>
18337
18338 <blockquote>
18339 <p>
18340 -12- <i>Error conditions:</i>
18341 </p>
18342
18343 <ul>
18344 <li>
18345 <tt>operation_not_permitted</tt> -- if the thread does not have the necessary permission to change
18346 the state of the mutex.
18347 </li>
18348 <li>
18349 <tt>resource_deadlock_would_occur</tt> -- if the current thread already owns the mutex and is able
18350 to detect it.
18351 </li>
18352 <li>
18353 <tt>device_or_resource_busy</tt> --  if the mutex is already locked and blocking is not possible.
18354 </li>
18355 <li>
18356 <ins><tt>state_not_recoverable</tt> -- if the state protected by the mutex is not recoverable.</ins>
18357 </li>
18358 </ul>
18359 </blockquote>
18360
18361
18362
18363
18364
18365 <hr>
18366 <h3><a name="1022"></a>1022. Response to UK 212</h3>
18367 <p><b>Section:</b> 20.8.13.7 [util.dynamic.safety] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
18368  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11  <b>Last modified:</b> 2009-03-12</p>
18369 <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>
18370 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
18371 <p><b>Discussion:</b></p>
18372
18373 <p><b>Addresses UK 212</b></p>
18374
18375 <p>
18376 The pointer-safety API is nothing to do with smart pointers, so does not
18377 belong in 20.8.13 [util.smartptr]. In fact it is a set of language
18378 support features are really belongs in clause 18 [language.support], with the contents declared in a header that
18379 deals with language-support of memory management.
18380 </p>
18381
18382 <p><i>[
18383 Summit:
18384 ]</i></p>
18385
18386
18387 <blockquote>Agree in principle, but not with the proposed resolution.
18388 We believe it
18389 belongs either a subsection of either 20 [utilities] or 20.8 [memory]
18390 as part of the general reorganization of 20 [utilities]. The
18391 declaration should stay in
18392 <tt>&lt;memory&gt;</tt>.
18393 </blockquote>
18394
18395
18396
18397 <p><b>Proposed resolution:</b></p>
18398
18399
18400
18401
18402
18403 <hr>
18404 <h3><a name="1025"></a>1025. Response to UK 208</h3>
18405 <p><b>Section:</b> 20.7.17 [unord.hash] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a>
18406  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11  <b>Last modified:</b> 2009-03-12</p>
18407 <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>
18408 <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>
18409 <p><b>Discussion:</b></p>
18410
18411 <p><b>Addresses UK 208</b></p>
18412
18413 <p>
18414 <tt>std::hash</tt> should be implemented for much more of the standard
18415 library. In particular for <tt>pair</tt>, <tt>tuple</tt> and all the
18416 standard containers.
18417 </p>
18418
18419
18420
18421 <p><b>Proposed resolution:</b></p>
18422
18423
18424
18425
18426
18427 </body></html>