1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
3 <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
6 <title>C++ Standard Library Active Issues List</title>
7 <style type="text/css">
9 li {text-align:justify}
10 ins {background-color:#A0FFA0}
11 del {background-color:#FFA0A0}
16 <td align="left">Doc. no.</td>
17 <td align="left">N2894=09-0084</td>
20 <td align="left">Date:</td>
21 <td align="left">2009-06-21</td>
24 <td align="left">Project:</td>
25 <td align="left">Programming Language C++</td>
28 <td align="left">Reply to:</td>
29 <td align="left">Howard Hinnant <<a href="mailto:howard.hinnant@gmail.com">howard.hinnant@gmail.com</a>></td>
32 <h1>C++ Standard Library Active Issues List (Revision R65)</h1>
34 <p>Reference ISO/IEC IS 14882:2003(E)</p>
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-defects.html">Library Defect Reports List</a></li>
41 <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html">Library Closed Issues List</a></li>
43 <p>The purpose of this document is to record the status of issues
44 which have come before the Library Working Group (LWG) of the ANSI
45 (J16) and ISO (WG21) C++ Standards Committee. Issues represent
46 potential defects in the ISO/IEC IS 14882:2003(E) document.
49 <p>This document contains only library issues which are actively being
50 considered by the Library Working Group. That is, issues which have a
51 status of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>,
52 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>, and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>. See
53 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html">Library Defect Reports List</a> for issues considered defects and
54 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html">Library Closed Issues List</a> for issues considered closed.</p>
56 <p>The issues in these lists are not necessarily formal ISO Defect
57 Reports (DR's). While some issues will eventually be elevated to
58 official Defect Report status, other issues will be disposed of in
59 other ways. See <a href="#Status">Issue Status</a>.</p>
61 <p>Prior to Revision 14, library issues lists existed in two slightly
62 different versions; a Committee Version and a Public
63 Version. Beginning with Revision 14 the two versions were combined
64 into a single version.</p>
66 <p>This document includes <i>[bracketed italicized notes]</i> as a
67 reminder to the LWG of current progress on issues. Such notes are
68 strictly unofficial and should be read with caution as they may be
69 incomplete or incorrect. Be aware that LWG support for a particular
70 resolution can quickly change if new viewpoints or killer examples are
71 presented in subsequent discussions.</p>
73 <p>For the most current official version of this document see
74 <a href="http://www.open-std.org/jtc1/sc22/wg21/">http://www.open-std.org/jtc1/sc22/wg21/</a>.
75 Requests for further information about this document should include
76 the document number above, reference ISO/IEC 14882:2003(E), and be
77 submitted to Information Technology Industry Council (ITI), 1250 Eye
78 Street NW, Washington, DC 20005.</p>
80 <p>Public information as to how to obtain a copy of the C++ Standard,
81 join the standards committee, submit an issue, or comment on an issue
82 can be found in the comp.std.c++ FAQ.
86 <h2>Revision History</h2>
89 2009-06-19 pre-Frankfurt mailing.
91 <li><b>Summary:</b><ul>
92 <li>378 open issues, up by 32.</li>
93 <li>765 closed issues, up by 0.</li>
94 <li>1143 issues total, up by 32.</li>
96 <li><b>Details:</b><ul>
97 <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>
98 <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>
99 <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>
100 <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>
101 <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>
102 <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>
103 <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>
104 <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>
105 <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>
106 <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>
107 <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>
108 <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>
109 <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>
110 <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>
111 <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>
112 <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>
113 <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>
114 <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>
119 2009-05-01 mid-term mailing.
121 <li><b>Summary:</b><ul>
122 <li>346 open issues, up by 19.</li>
123 <li>765 closed issues, up by 0.</li>
124 <li>1111 issues total, up by 19.</li>
126 <li><b>Details:</b><ul>
127 <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>
128 <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>
129 <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>
134 2009-03-20 post-Summit mailing.
136 <li><b>Summary:</b><ul>
137 <li>327 open issues, up by 96.</li>
138 <li>765 closed issues, up by 14.</li>
139 <li>1092 issues total, up by 110.</li>
141 <li><b>Details:</b><ul>
142 <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>
143 <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>
144 <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>
145 <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>
146 <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>
147 <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>
148 <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>
149 <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>
150 <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>
151 <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>
152 <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>
153 <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>
154 <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>
155 <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>
156 <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>
157 <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>
158 <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>
159 <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>
160 <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>
161 <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>
162 <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>
163 <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>
164 <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>
169 2009-02-06 pre-Summit mailing.
171 <li><b>Summary:</b><ul>
172 <li>231 open issues, up by 44.</li>
173 <li>751 closed issues, up by 0.</li>
174 <li>982 issues total, up by 44.</li>
176 <li><b>Details:</b><ul>
177 <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>
182 2008-12-05 mid-term mailing.
184 <li><b>Summary:</b><ul>
185 <li>187 open issues, up by 20.</li>
186 <li>751 closed issues, up by 0.</li>
187 <li>938 issues total, up by 20.</li>
189 <li><b>Details:</b><ul>
190 <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>
195 2008-10-03 post-San Francisco mailing.
197 <li><b>Summary:</b><ul>
198 <li>167 open issues, down by 25.</li>
199 <li>751 closed issues, up by 65.</li>
200 <li>918 issues total, up by 40.</li>
202 <li><b>Details:</b><ul>
203 <li>Added the following CD1 issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#882">882</a>.</li>
204 <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>
205 <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>
206 <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>
207 <li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#894">894</a>.</li>
208 <li>Added the following Review issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#888">888</a>.</li>
209 <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>
210 <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>
211 <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>
212 <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>
213 <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>
214 <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>
215 <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>
216 <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>
217 <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>
218 <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>
219 <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>
220 <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>
221 <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>
222 <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>
223 <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>
224 <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>
225 <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>
226 <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>
231 2008-08-22 pre-San Francisco mailing.
233 <li><b>Summary:</b><ul>
234 <li>192 open issues, up by 9.</li>
235 <li>686 closed issues, up by 0.</li>
236 <li>878 issues total, up by 9.</li>
238 <li><b>Details:</b><ul>
239 <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>
244 2008-07-28 mid-term mailing.
246 <li><b>Summary:</b><ul>
247 <li>183 open issues, up by 12.</li>
248 <li>686 closed issues, down by 4.</li>
249 <li>869 issues total, up by 8.</li>
251 <li><b>Details:</b><ul>
252 <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>
253 <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>
254 <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>
255 <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>
256 <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>
261 2008-06-27 post-Sophia Antipolis mailing.
263 <li><b>Summary:</b><ul>
264 <li>171 open issues, down by 20.</li>
265 <li>690 closed issues, up by 43.</li>
266 <li>861 issues total, up by 23.</li>
268 <li><b>Details:</b><ul>
269 <li>Added the following NAD issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#840">840</a>.</li>
270 <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>
271 <li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#839">839</a>.</li>
272 <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>
273 <li>Added the following Review issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#851">851</a>.</li>
274 <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>
275 <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>
276 <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>
277 <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>
278 <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>
279 <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>
280 <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>
281 <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>
282 <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>
283 <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>
284 <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>
285 <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>
286 <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>
287 <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>
292 2008-05-16 pre-Sophia Antipolis mailing.
294 <li><b>Summary:</b><ul>
295 <li>191 open issues, up by 24.</li>
296 <li>647 closed issues, up by 1.</li>
297 <li>838 issues total, up by 25.</li>
299 <li><b>Details:</b><ul>
300 <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>
301 <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>
306 2008-03-14 post-Bellevue mailing.
308 <li><b>Summary:</b><ul>
309 <li>167 open issues, down by 39.</li>
310 <li>646 closed issues, up by 65.</li>
311 <li>813 issues total, up by 26.</li>
313 <li><b>Details:</b><ul>
314 <li>Added the following Dup issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#795">795</a>.</li>
315 <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>
316 <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>
317 <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>
318 <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>
319 <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>
320 <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>
321 <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>
322 <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>
323 <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>
324 <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>
325 <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>
326 <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>
327 <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>
328 <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>
329 <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>
330 <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>
331 <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>
332 <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>
333 <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>
334 <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>
335 <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>
336 <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>
337 <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>
342 2008-02-01 pre-Bellevue mailing.
344 <li><b>Summary:</b><ul>
345 <li>206 open issues, up by 23.</li>
346 <li>581 closed issues, up by 0.</li>
347 <li>787 issues total, up by 23.</li>
349 <li><b>Details:</b><ul>
350 <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>
351 <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>
352 <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>
353 <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>
354 <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>
355 <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>
360 2007-12-09 mid-term mailing.
362 <li><b>Summary:</b><ul>
363 <li>183 open issues, up by 11.</li>
364 <li>581 closed issues, down by 1.</li>
365 <li>764 issues total, up by 10.</li>
367 <li><b>Details:</b><ul>
368 <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>
369 <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>
370 <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>
375 2007-10-19 post-Kona mailing.
377 <li><b>Summary:</b><ul>
378 <li>172 open issues, up by 4.</li>
379 <li>582 closed issues, up by 27.</li>
380 <li>754 issues total, up by 31.</li>
382 <li><b>Details:</b><ul>
383 <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>
384 <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>
385 <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>
386 <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>
387 <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>
388 <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>
389 <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>
390 <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>
391 <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>
392 <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>
393 <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>
394 <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>
395 <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>
400 2007-09-09 pre-Kona mailing.
402 <li><b>Summary:</b><ul>
403 <li>168 open issues, up by 15.</li>
404 <li>555 closed issues, up by 0.</li>
405 <li>723 issues total, up by 15.</li>
407 <li><b>Details:</b><ul>
408 <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>
413 2007-08-05 post-Toronto mailing.
415 <li><b>Summary:</b><ul>
416 <li>153 open issues, down by 5.</li>
417 <li>555 closed issues, up by 17.</li>
418 <li>708 issues total, up by 12.</li>
420 <li><b>Details:</b><ul>
421 <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>
422 <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>
423 <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>
424 <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>
425 <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>
426 <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>
427 <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>
428 <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>
429 <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>
430 <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>
431 <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>
432 <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>
433 <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>
434 <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>
435 <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>
440 2007-06-23 pre-Toronto mailing.
442 <li><b>Summary:</b><ul>
443 <li>158 open issues, up by 13.</li>
444 <li>538 closed issues, up by 7.</li>
445 <li>696 issues total, up by 20.</li>
447 <li><b>Details:</b><ul>
448 <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>
449 <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>
450 <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>
451 <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>
452 <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>
457 2007-05-06 post-Oxford mailing.
459 <li><b>Summary:</b><ul>
460 <li>145 open issues, down by 33.</li>
461 <li>531 closed issues, up by 53.</li>
462 <li>676 issues total, up by 20.</li>
464 <li><b>Details:</b><ul>
465 <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>
466 <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>
467 <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>
468 <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>
469 <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>
470 <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>
471 <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>
472 <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>
473 <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>
474 <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>
475 <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>
476 <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>
477 <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>
478 <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>
479 <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>
484 2007-03-09 pre-Oxford mailing.
486 <li><b>Summary:</b><ul>
487 <li>178 open issues, up by 37.</li>
488 <li>478 closed issues, up by 0.</li>
489 <li>656 issues total, up by 37.</li>
491 <li><b>Details:</b><ul>
492 <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>
493 <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>
494 <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>
495 <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>
496 <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>
497 <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>
502 2007-01-12 mid-term mailing.
504 <li><b>Summary:</b><ul>
505 <li>141 open issues, up by 11.</li>
506 <li>478 closed issues, down by 1.</li>
507 <li>619 issues total, up by 10.</li>
509 <li><b>Details:</b><ul>
510 <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>
515 2006-11-03 post-Portland mailing.
517 <li><b>Summary:</b><ul>
518 <li>130 open issues, up by 0.</li>
519 <li>479 closed issues, up by 17.</li>
520 <li>609 issues total, up by 17.</li>
522 <li><b>Details:</b><ul>
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#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>
524 <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>
525 <li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#569">569</a> to Dup.</li>
526 <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>
527 <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>
528 <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>
529 <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>
534 2006-09-08 pre-Portland mailing.
536 <li><b>Summary:</b><ul>
537 <li>130 open issues, up by 6.</li>
538 <li>462 closed issues, down by 1.</li>
539 <li>592 issues total, up by 5.</li>
541 <li><b>Details:</b><ul>
542 <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>
547 2006-06-23 mid-term mailing.
549 <li><b>Summary:</b><ul>
550 <li>124 open issues, up by 14.</li>
551 <li>463 closed issues, down by 1.</li>
552 <li>587 issues total, up by 13.</li>
554 <li><b>Details:</b><ul>
555 <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>
556 <li>Reopened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#255">255</a>.</li>
557 <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>
562 2006-04-21 post-Berlin mailing.
564 <li><b>Summary:</b><ul>
565 <li>110 open issues, down by 16.</li>
566 <li>464 closed issues, up by 24.</li>
567 <li>574 issues total, up by 8.</li>
569 <li><b>Details:</b><ul>
570 <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>
571 <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>
572 <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>
573 <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>
574 <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>
575 <li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a> to Review.</li>
580 2006-02-24 pre-Berlin mailing.
582 <li><b>Summary:</b><ul>
583 <li>126 open issues, up by 31.</li>
584 <li>440 closed issues, up by 0.</li>
585 <li>566 issues total, up by 31.</li>
587 <li><b>Details:</b><ul>
588 <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>
589 <li>Moved <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#342">342</a> from Ready to Open.</li>
590 <li>Reopened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#309">309</a>.</li>
595 2005-12-16 mid-term mailing.
597 <li><b>Summary:</b><ul>
598 <li>95 open issues.</li>
599 <li>440 closed issues.</li>
600 <li>535 issues total.</li>
602 <li><b>Details:</b><ul>
603 <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>
608 2005-10-14 post-Mont Tremblant mailing.
609 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>.
610 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.
611 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.
612 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.
613 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.
614 Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#500">500</a> from New to NAD.
615 Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a> from New to Review.
618 2005-07-03 pre-Mont Tremblant mailing.
619 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>.
620 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>
623 2005-06 mid-term mailing.
624 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>.
627 2005-04 post-Lillehammer mailing. All issues in "ready" status except
628 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
629 previously in "DR" status were moved to "WP".
632 2005-03 pre-Lillehammer mailing.
635 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>.
638 2004-11 post-Redmond mailing. Reflects actions taken in Redmond.
641 2004-09 pre-Redmond mailing: reflects new proposed resolutions and
642 new issues received after the 2004-07 mailing. Added
643 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>.
646 2004-07 mid-term mailing: reflects new proposed resolutions and
647 new issues received after the post-Sydney mailing. Added
648 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>.
651 Post-Sydney mailing: reflects decisions made at the Sydney meeting.
652 Voted all "Ready" issues from R29 into the working paper.
653 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>.
656 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>.
659 Post-Kona mailing: reflects decisions made at the Kona meeting.
660 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>.
663 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>.
666 Post-Oxford mailing: reflects decisions made at the Oxford meeting.
667 All issues in Ready status were voted into DR status. All issues in
668 DR status were voted into WP status.
671 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>.
674 Post-Santa Cruz mailing: reflects decisions made at the Santa Cruz
675 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
676 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
677 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
678 concerns with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a> involve wording.
681 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>.
682 Moved issues in the TC to TC status.
685 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>.
688 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>.
691 Post-Redmond mailing; reflects actions taken in Redmond. Added
692 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
693 <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
694 not discussed at the meeting.
696 All Ready issues were moved to DR status, with the exception of issues
697 <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>.
699 Noteworthy issues discussed at Redmond include
700 <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>,
701 <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>.
704 Pre-Redmond mailing. Added new issues
705 <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>.
708 Post-Copenhagen mailing; reflects actions taken in Copenhagen.
709 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
710 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>.
712 Changed status of issues
713 <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>
714 <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>
715 <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>
716 <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>
717 <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>
718 <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>
719 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#268">268</a>
722 Changed status of issues
723 <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>
724 <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>
725 <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>
726 <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>
727 <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>
728 <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>
729 <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>
730 <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>
731 <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>
735 <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>
736 <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>
737 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#314">314</a>
742 Pre-Copenhagen mailing. Converted issues list to XML. Added proposed
743 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>.
744 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>.
747 post-Toronto mailing; reflects actions taken in Toronto. Added new
748 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
749 <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>,
750 <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>,
751 <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>,
752 <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>,
753 <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>,
754 <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>,
755 <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>,
756 <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>,
757 <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>,
758 <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>,
759 <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>,
760 <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>,
761 <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
762 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
763 <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
764 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
765 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
766 the bug in enough places.
769 pre-Toronto mailing. Added issues
770 <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
771 changes so that we pass Weblint tests.
774 post-Tokyo II mailing; reflects committee actions taken in
775 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)
778 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>.
781 pre-Tokyo II mailing: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#199">199</a> to
782 <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
783 of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#29">29</a>. Add further rationale to issue
784 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#178">178</a>.
787 post-Kona mailing: Updated to reflect LWG and full committee actions
788 in Kona (99-0048/N1224). Note changed resolution of issues
789 <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>
790 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
791 "closed" documents. Changed the proposed resolution of issue
792 <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
793 of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#38">38</a>.
796 pre-Kona updated. Added proposed resolutions <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>,
797 <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>,
798 <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
799 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a>. (99-0033/D1209, 14 Oct 99)
802 pre-Kona mailing. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a> to
803 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#189">189</a>. Issues list split into separate "active" and
804 "closed" documents. (99-0030/N1206, 25 Aug 99)
807 post-Dublin mailing. Updated to reflect LWG and full committee actions
808 in Dublin. (99-0016/N1193, 21 Apr 99)
811 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>,
812 <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>,
813 <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>,
814 <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)
817 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>,
818 and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#129">129</a>. (99-0007/N1194, 22 Feb 99)
821 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
822 <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
823 for making list public. (30 Dec 98)
826 post-Santa Cruz II updated: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#110">110</a>,
827 <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
828 issues corrected. (22 Oct 98)
831 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>
832 added, many issues updated to reflect LWG consensus (12 Oct 98)
835 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,
836 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#17">17</a> updated. (29 Sep 98)
839 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
840 format, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64">64</a> title. (17 Sep 98)
844 <h2><a name="Status"></a>Issue Status</h2>
846 <p><b><a name="New">New</a></b> - The issue has not yet been
847 reviewed by the LWG. Any <b>Proposed Resolution</b> is purely a
848 suggestion from the issue submitter, and should not be construed as
851 <p><b><a name="Open">Open</a></b> - The LWG has discussed the issue
852 but is not yet ready to move the issue forward. There are several
853 possible reasons for open status:</p>
855 <li>Consensus may have not yet have been reached as to how to deal
857 <li>Informal consensus may have been reached, but the LWG awaits
858 exact <b>Proposed Resolution</b> wording for review.</li>
859 <li>The LWG wishes to consult additional technical experts before
861 <li>The issue may require further study.</li>
864 <p>A <b>Proposed Resolution</b> for an open issue is still not be
865 construed as the view of LWG. Comments on the current state of
866 discussions are often given at the end of open issues in an italic
867 font. Such comments are for information only and should not be given
868 undue importance.</p>
870 <p><b><a name="Dup">Dup</a></b> - The LWG has reached consensus that
871 the issue is a duplicate of another issue, and will not be further
872 dealt with. A <b>Rationale</b> identifies the duplicated issue's
875 <p><b><a name="NAD">NAD</a></b> - The LWG has reached consensus that
876 the issue is not a defect in the Standard.</p>
878 <p><b><a name="NAD Editorial">NAD Editorial</a></b> - The LWG has reached consensus that
879 the issue can either be handled editorially, or is handled by a paper (usually
880 linked to in the rationale).</p>
882 <p><b><a name="NAD Future">NAD Future</a></b> - In addition to the regular
883 status, the LWG believes that this issue should be revisited at the
884 next revision of the standard.</p>
886 <p><b><a name="Review">Review</a></b> - Exact wording of a
887 <b>Proposed Resolution</b> is now available for review on an issue
888 for which the LWG previously reached informal consensus.</p>
890 <p><b><a name="Ready">Ready</a></b> - The LWG has reached consensus
891 that the issue is a defect in the Standard, the <b>Proposed
892 Resolution</b> is correct, and the issue is ready to forward to the
893 full committee for further action as a Defect Report (DR).</p>
895 <p><b><a name="DR">DR</a></b> - (Defect Report) - The full J16
896 committee has voted to forward the issue to the Project Editor to be
897 processed as a Potential Defect Report. The Project Editor reviews
898 the issue, and then forwards it to the WG21 Convenor, who returns it
899 to the full committee for final disposition. This issues list
900 accords the status of DR to all these Defect Reports regardless of
901 where they are in that process.</p>
903 <p><b><a name="TC1">TC1</a></b> - (Technical Corrigenda 1) - The full
904 WG21 committee has voted to accept the Defect Report's Proposed
905 Resolution as a Technical Corrigenda. Action on this issue is thus
906 complete and no further action is possible under ISO rules.</p>
908 <p><b><a name="CD1">CD1</a></b> - (Committee Draft 2008) - The full
909 WG21 committee has voted to accept the Defect Report's Proposed
910 Resolution into the Fall 2008 Committee Draft.</p>
912 <p><b><a name="TRDec">TRDec</a></b> - (Decimal TR defect) - The
913 LWG has voted to accept the Defect Report's Proposed
914 Resolution into the Decimal TR. Action on this issue is thus
915 complete and no further action is expected.</p>
917 <p><b><a name="WP">WP</a></b> - (Working Paper) - The proposed
918 resolution has not been accepted as a Technical Corrigendum, but
919 the full WG21 committee has voted to apply the Defect Report's Proposed
920 Resolution to the working paper.</p>
922 <p><b>Tentatively</b> - This is a <i>status qualifier</i>. The issue has
923 been reviewed online, or at an unofficial meeting, but not in an official meeting, and some support has been formed
924 for the qualified status. Tentatively qualified issues may be moved to the unqualified status
925 and forwarded to full committee (if Ready) within the same meeting. Unlike Ready issues, Tentatively Ready issues
926 will be reviewed in subcommittee prior to forwarding to full committee. When a status is
927 qualified with Tentatively, the issue is still considered active.</p>
929 <p><b>Pending</b> - This is a <i>status qualifier</i>. When prepended to
930 a status this indicates the issue has been
931 processed by the committee, and a decision has been made to move the issue to
932 the associated unqualified status. However for logistical reasons the indicated
933 outcome of the issue has not yet appeared in the latest working paper.
935 </p><p>Issues are always given the status of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> when
936 they first appear on the issues list. They may progress to
937 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> or <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> while the LWG
938 is actively working on them. When the LWG has reached consensus on
939 the disposition of an issue, the status will then change to
940 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>, or
941 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> as appropriate. Once the full J16 committee votes to
942 forward Ready issues to the Project Editor, they are given the
943 status of Defect Report ( <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>). These in turn may
944 become the basis for Technical Corrigenda (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>),
945 or are closed without action other than a Record of Response
946 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#RR">RR</a> ). The intent of this LWG process is that
947 only issues which are truly defects in the Standard move to the
948 formal ISO DR status.
952 <h2>Active Issues</h2>
954 <h3><a name="96"></a>96. Vector<bool> is not a container</h3>
955 <p><b>Section:</b> 23.3.6 [vector] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">Tentatively NAD Future</a>
956 <b>Submitter:</b> AFNOR <b>Opened:</b> 1998-10-07 <b>Last modified:</b> 2009-05-25</p>
957 <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>
958 <p><b>Discussion:</b></p>
959 <p><tt>vector<bool></tt> is not a container as its reference and
960 pointer types are not references and pointers. </p>
962 <p>Also it forces everyone to have a space optimization instead of a
965 <p><b>See also:</b> 99-0008 == N1185 Vector<bool> is
966 Nonconforming, Forces Optimization Choice.</p>
968 <p><i>[In Santa Cruz the LWG felt that this was Not A Defect.]</i></p>
971 <p><i>[In Dublin many present felt that failure to meet Container
972 requirements was a defect. There was disagreement as to whether
973 or not the optimization requirements constituted a defect.]</i></p>
976 <p><i>[The LWG looked at the following resolutions in some detail:
978 * Not A Defect.<br>
979 * Add a note explaining that vector<bool> does not meet
980 Container requirements.<br>
981 * Remove vector<bool>.<br>
982 * Add a new category of container requirements which
983 vector<bool> would meet.<br>
984 * Rename vector<bool>.<br>
986 No alternative had strong, wide-spread, support and every alternative
987 had at least one "over my dead body" response.<br>
989 There was also mention of a transition scheme something like (1) add
990 vector_bool and deprecate vector<bool> in the next standard. (2)
991 Remove vector<bool> in the following standard.]</i></p>
994 <p><i>[Modifying container requirements to permit returning proxies
995 (thus allowing container requirements conforming vector<bool>)
996 was also discussed.]</i></p>
999 <p><i>[It was also noted that there is a partial but ugly workaround in
1000 that vector<bool> may be further specialized with a customer
1004 <p><i>[Kona: Herb Sutter presented his paper J16/99-0035==WG21/N1211,
1005 vector<bool>: More Problems, Better Solutions. Much discussion
1006 of a two step approach: a) deprecate, b) provide replacement under a
1007 new name. LWG straw vote on that: 1-favor, 11-could live with, 2-over
1008 my dead body. This resolution was mentioned in the LWG report to the
1009 full committee, where several additional committee members indicated
1010 over-my-dead-body positions.]</i></p>
1013 <p>Discussed at Lillehammer. General agreement that we should
1014 deprecate vector<bool> and introduce this functionality under
1015 a different name, e.g. bit_vector. This might make it possible to
1016 remove the vector<bool> specialization in the standard that comes
1017 after C++0x. There was also a suggestion that
1018 in C++0x we could additional say that it's implementation defined
1019 whether vector<bool> refers to the specialization or to the
1020 primary template, but there wasn't general agreement that this was a
1023 <p>We need a paper for the new bit_vector class.</p>
1030 The LWG feels we need something closer to SGI's <tt>bitvector</tt> to ease migration
1031 from <tt>vector<bool></tt>. Although some of the funcitonality from
1032 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2050.pdf">N2050</a>
1033 could well be used in such a template. The concern is easing the API migration for those
1034 users who want to continue using a bit-packed container. Alan and Beman to work.
1038 Post Summit Alisdair adds:
1044 <tt>vector<bool></tt> is now a conforming container under the revised terms of C++0x,
1045 which supports containers of proxies.
1054 i/ premature optimization in the specification.
1055 There is still some sentiment that deprecation is the correct way to go,
1056 although it is still not clear what it would mean to deprecate a single
1057 specialization of a template.
1060 Recommend: Create a new issue for the discussion, leave as Open.
1063 ii/ Request for a new bitvector class to guarantee the optimization, perhaps
1064 with a better tuned interface.
1067 This is a clear extension request that may be handled via a future TR.
1076 We note that most of this issue has become moot over time,
1077 and agree with Alisdair's recommendations.
1078 Move to NAD Future for reconsideration of part (ii).
1082 <p><b>Proposed resolution:</b></p>
1085 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2050.pdf">N2050</a>
1087 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2160.html">N2160</a>.
1096 <h3><a name="111"></a>111. istreambuf_iterator::equal overspecified, inefficient</h3>
1097 <p><b>Section:</b> 24.6.3.5 [istreambuf.iterator::equal] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
1098 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-10-15 <b>Last modified:</b> 2009-03-13</p>
1099 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#istreambuf.iterator::equal">active issues</a> in [istreambuf.iterator::equal].</p>
1100 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istreambuf.iterator::equal">issues</a> in [istreambuf.iterator::equal].</p>
1101 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
1102 <p><b>Discussion:</b></p>
1103 <p>The member istreambuf_iterator<>::equal is specified to be
1104 unnecessarily inefficient. While this does not affect the efficiency
1105 of conforming implementations of iostreams, because they can
1106 "reach into" the iterators and bypass this function, it does
1107 affect users who use istreambuf_iterators. </p>
1109 <p>The inefficiency results from a too-scrupulous definition, which
1110 requires a "true" result if neither iterator is at eof. In
1111 practice these iterators can only usefully be compared with the
1112 "eof" value, so the extra test implied provides no benefit,
1113 but slows down users' code. </p>
1115 <p>The solution is to weaken the requirement on the function to return
1116 true only if both iterators are at eof. </p>
1124 Reopened by Alisdair.
1128 Post Summit Daniel adds:
1134 Recommend NAD. The proposed wording would violate the axioms of
1135 concept requirement <tt>EqualityComparable</tt> axioms as part of concept <tt>InputIterator</tt>
1136 and more specifically it would violate the explicit wording of
1137 24.2.2 [input.iterators]/7:
1141 If two iterators <tt>a</tt> and <tt>b</tt> of the same type are equal, then either <tt>a</tt>
1142 and <tt>b</tt> are both
1143 dereferenceable or else neither is dereferenceable.
1150 <p><b>Proposed resolution:</b></p>
1151 <p>Replace 24.6.3.5 [istreambuf.iterator::equal],
1155 <p>-1- Returns: true if and only if both iterators are at end-of-stream, or neither is at
1156 end-of-stream, regardless of what streambuf object they use. </p>
1162 <p>-1- Returns: true if and only if both iterators are at
1163 end-of-stream, regardless of what streambuf object they use. </p>
1168 <p><b>Rationale:</b></p>
1169 <p>It is not clear that this is a genuine defect. Additionally, the
1170 LWG was reluctant to make a change that would result in
1171 operator== not being a equivalence relation. One consequence of
1172 this change is that an algorithm that's passed the range [i, i)
1173 would no longer treat it as an empty range.</p>
1180 <h3><a name="128"></a>128. Need open_mode() function for file stream, string streams, file buffers, and string buffers</h3>
1181 <p><b>Section:</b> 27.8 [string.streams], 27.9 [file.streams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
1182 <b>Submitter:</b> Angelika Langer <b>Opened:</b> 1999-02-22 <b>Last modified:</b> 2008-03-14</p>
1183 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.streams">issues</a> in [string.streams].</p>
1184 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
1185 <p><b>Discussion:</b></p>
1186 <p>The following question came from Thorsten Herlemann:</p>
1189 <p>You can set a mode when constructing or opening a file-stream or
1190 filebuf, e.g. ios::in, ios::out, ios::binary, ... But how can I get
1191 that mode later on, e.g. in my own operator << or operator
1192 >> or when I want to check whether a file-stream or
1193 file-buffer object passed as parameter is opened for input or output
1194 or binary? Is there no possibility? Is this a design-error in the
1195 standard C++ library? </p>
1198 <p>It is indeed impossible to find out what a stream's or stream
1199 buffer's open mode is, and without that knowledge you don't know
1200 how certain operations behave. Just think of the append mode. </p>
1202 <p>Both streams and stream buffers should have a <tt>mode()</tt> function that returns the
1203 current open mode setting. </p>
1206 post Bellevue: Alisdair requested to re-Open.
1212 <p><b>Proposed resolution:</b></p>
1213 <p>For stream buffers, add a function to the base class as a non-virtual function
1214 qualified as const to 27.6.2 [streambuf]:</p>
1216 <p> <tt>openmode mode() const</tt>;</p>
1218 <p><b> Returns</b> the current open mode.</p>
1220 <p>With streams, I'm not sure what to suggest. In principle, the mode
1221 could already be returned by <tt>ios_base</tt>, but the mode is only
1222 initialized for file and string stream objects, unless I'm overlooking
1223 anything. For this reason it should be added to the most derived
1224 stream classes. Alternatively, it could be added to <tt>basic_ios</tt>
1225 and would be default initialized in <tt>basic_ios<>::init()</tt>.</p>
1228 <p><b>Rationale:</b></p>
1229 <p>This might be an interesting extension for some future, but it is
1230 not a defect in the current standard. The Proposed Resolution is
1231 retained for future reference.</p>
1238 <h3><a name="138"></a>138. Class ctype_byname<char> redundant and misleading</h3>
1239 <p><b>Section:</b> 22.4.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
1240 <b>Submitter:</b> Angelika Langer <b>Opened:</b> 1999-03-18 <b>Last modified:</b> 2009-03-09</p>
1241 <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>
1242 <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>
1243 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
1244 <p><b>Discussion:</b></p>
1245 <p>Section 22.4.1.4 [locale.codecvt] specifies that
1246 ctype_byname<char> must be a specialization of the ctype_byname
1249 <p>It is common practice in the standard that specializations of class templates are only
1250 mentioned where the interface of the specialization deviates from the interface of the
1251 template that it is a specialization of. Otherwise, the fact whether or not a required
1252 instantiation is an actual instantiation or a specialization is left open as an
1253 implementation detail. </p>
1255 <p>Clause 22.2.1.4 deviates from that practice and for that reason is misleading. The
1256 fact, that ctype_byname<char> is specified as a specialization suggests that there
1257 must be something "special" about it, but it has the exact same interface as the
1258 ctype_byname template. Clause 22.2.1.4 does not have any explanatory value, is at best
1259 redundant, at worst misleading - unless I am missing anything. </p>
1261 <p>Naturally, an implementation will most likely implement ctype_byname<char> as a
1262 specialization, because the base class ctype<char> is a specialization with an
1263 interface different from the ctype template, but that's an implementation detail and need
1264 not be mentioned in the standard. </p>
1272 Reopened by Alisdair.
1277 <p><b>Rationale:</b></p>
1278 <p> The standard as written is mildly misleading, but the correct fix
1279 is to deal with the underlying problem in the ctype_byname base class,
1280 not in the specialization. See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#228">228</a>.</p>
1286 <h3><a name="149"></a>149. Insert should return iterator to first element inserted</h3>
1287 <p><b>Section:</b> 23.2.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
1288 <b>Submitter:</b> Andrew Koenig <b>Opened:</b> 1999-06-28 <b>Last modified:</b> 2009-05-01</p>
1289 <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>
1290 <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>
1291 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
1292 <p><b>Discussion:</b></p>
1293 <p>Suppose that c and c1 are sequential containers and i is an
1294 iterator that refers to an element of c. Then I can insert a copy of
1295 c1's elements into c ahead of element i by executing </p>
1299 <pre>c.insert(i, c1.begin(), c1.end());</pre>
1303 <p>If c is a vector, it is fairly easy for me to find out where the
1304 newly inserted elements are, even though i is now invalid: </p>
1308 <pre>size_t i_loc = i - c.begin();
1309 c.insert(i, c1.begin(), c1.end());</pre>
1313 <p>and now the first inserted element is at c.begin()+i_loc and one
1314 past the last is at c.begin()+i_loc+c1.size().<br>
1316 But what if c is a list? I can still find the location of one past the
1317 last inserted element, because i is still valid. To find the location
1318 of the first inserted element, though, I must execute something like </p>
1322 <pre>for (size_t n = c1.size(); n; --n)
1327 <p>because i is now no longer a random-access iterator.<br>
1329 Alternatively, I might write something like </p>
1333 <pre>bool first = i == c.begin();
1334 list<T>::iterator j = i;
1336 c.insert(i, c1.begin(), c1.end());
1344 <p>which, although wretched, requires less overhead.<br>
1346 But I think the right solution is to change the definition of insert
1347 so that instead of returning void, it returns an iterator that refers
1348 to the first element inserted, if any, and otherwise is a copy of its
1349 first argument. </p>
1357 Reopened by Alisdair.
1361 Post Summit Alisdair adds:
1367 In addition to the original rationale for C++03, this change also gives a
1368 consistent interface for all container insert operations i.e. they all
1369 return an iterator to the (first) inserted item.
1373 Proposed wording provided.
1379 <p><b>Proposed resolution:</b></p>
1381 <sef ref="[sequence.reqmts]"> Table 83
1382 change return type from <tt>void</tt> to <tt>iterator</tt> for the following rows:
1387 <caption>Table 83 -- Sequence container requirements (in addition to container)</caption>
1390 <th>Return type</th>
1391 <th>Assertion/note pre-/post-condition</th>
1395 <tt>a.insert(p,n,t)</tt>
1398 <tt><del>void</del> <ins>iterator</ins></tt>
1401 Inserts <tt>n</tt> copies of <tt>t</tt> before <tt>p</tt>.
1407 <tt>a.insert(p,i,j)</tt>
1410 <tt><del>void</del> <ins>iterator</ins></tt>
1413 Each iterator in the range <tt>[i,j)</tt> shall be
1414 dereferenced exactly once.
1415 pre: <tt>i</tt> and <tt>j</tt> are not iterators into <tt>a</tt>.
1416 Inserts copies of elements in <tt>[i, j)</tt> before <tt>p</tt>
1422 <tt>a.insert(p,il)</tt>
1425 <tt><del>void</del> <ins>iterator</ins></tt>
1428 <tt>a.insert(p, il.begin(), il.end())</tt>.
1435 Add after p6 23.2.3 [sequence.reqmts]:
1442 The iterator returned from <tt>a.insert(p,n,t)</tt> points to the copy of the
1443 first element inserted into <tt>a</tt>, or <tt>p</tt> if <tt>n == 0</tt>.
1447 The iterator returned from <tt>a.insert(p,i,j)</tt> points to the copy of the
1448 first element inserted into <tt>a</tt>, or <tt>p</tt> if <tt>i == j</tt>.
1452 The iterator returned from <tt>a.insert(p,il)</tt> points to the copy of the
1453 first element inserted into <tt>a</tt>, or <tt>p</tt> if <tt>il</tt> is empty.
1459 p9 23.2.6.1 [container.concepts.free] change return type from
1460 <tt>void</tt> to <tt>iterator</tt>:
1463 <blockquote><pre>concept RangeInsertionContainer<typename C, typename Iter> : InsertionContainer<C> {
1464 requires InputIterator<Iter>;
1465 <del>void</del> <ins>iterator</ins> insert(C&, const_iterator position, Iter first, Iter last);
1470 p9 23.2.6.2 [container.concepts.member] change return type from
1471 <tt>void</tt> to <tt>iterator</tt>:
1474 <blockquote><pre>auto concept MemberRangeInsertionContainer<typename C, typename Iter> : MemberInsertionContainer<C> {
1475 requires InputIterator<Iter>;
1476 <del>void</del> <ins>iterator</ins> C::insert(const_iterator position, Iter first, Iter last);
1481 p8 23.2.6.3 [container.concepts.maps] change return type from
1482 <tt>void</tt> to <tt>iterator</tt>, add return statement:
1485 <blockquote><pre>template <MemberRangeInsertionContainer C, InputIterator Iter>
1486 concept_map RangeInsertionContainer<C, Iter> {
1487 <del>void</del> <ins>iterator</ins> insert(C& c, Container<C>::const_iterator i, Iter first, Iter last)
1488 { <ins>return</ins> c.insert(i, first, last); }
1493 p2 23.3.2 [deque] Update class definition, change return type
1494 from <tt>void</tt> to <tt>iterator</tt>:
1497 <blockquote><pre>requires AllocatableElement<Alloc, T, const T&> && MoveAssignable<T>
1498 <del>void</del> <ins>iterator</ins> insert(const_iterator position, size_type n, const T& x);
1499 template <InputIterator Iter>
1500 requires AllocatableElement<Alloc, T, Iter::reference> && MoveAssignable<T>
1501 <del>void</del> <ins>iterator</ins> insert(const_iterator position, Iter first, Iter last);
1502 requires AllocatableElement<Alloc, T, const T&> && MoveAssignable<T>
1503 <del>void</del> <ins>iterator</ins> insert(const_iterator position, initializer_list<T>);
1507 23.3.2.3 [deque.modifiers] change return type from <tt>void</tt> to <tt>iterator</tt> on following declarations:
1510 <blockquote><pre>requires AllocatableElement<Alloc, T, const T&> && MoveAssignable<T>
1511 <del>void</del> <ins>iterator</ins> insert(const_iterator position, size_type n, const T& x);
1512 template <InputIterator Iter>
1513 requires AllocatableElement<Alloc, T, Iter::reference> && MoveAssignable<T>
1514 <del>void</del> <ins>iterator</ins> insert(const_iterator position, Iter first, Iter last);
1518 Add the following (missing) declaration
1521 <blockquote><pre><ins>requires AllocatableElement<Alloc, T, const T&> && MoveAssignable<T>
1522 iterator insert(const_iterator position, initializer_list<T>);</ins>
1526 23.3.3 [forwardlist] Update class definition, change return type
1527 from <tt>void</tt> to <tt>iterator</tt>:
1530 <blockquote><pre>requires AllocatableElement<Alloc, T, const T&>
1531 <del>void</del> <ins>iterator</ins> insert_after(const_iterator position, initializer_list<T> il);
1532 requires AllocatableElement<Alloc, T, const T&>
1533 <del>void</del> <ins>iterator</ins> insert_after(const_iterator position, size_type n, const T& x);
1534 template <InputIterator Iter>
1535 requires AllocatableElement<Alloc, T, Iter::reference>
1536 <del>void</del> <ins>iterator</ins> insert_after(const_iterator position, Iter first, Iter last);
1540 p8 23.3.3.4 [forwardlist.modifiers] change return type from <tt>void</tt> to <tt>iterator</tt>:
1543 <blockquote><pre>requires AllocatableElement<Alloc, T, const T&>
1544 <del>void</del> <ins>iterator</ins> insert_after(const_iterator position, size_type n, const T& x);
1556 p10 23.3.3.4 [forwardlist.modifiers] change return type from <tt>void</tt> to <tt>iterator</tt>:
1559 <blockquote><pre>template <InputIterator Iter>
1560 requires AllocatableElement<Alloc, T, Iter::reference>
1561 <del>void</del> <ins>iterator</ins> insert_after(const_iterator position, Iter first, Iter last);
1573 p12 23.3.3.4 [forwardlist.modifiers] change return type from <tt>void</tt> to <tt>iterator</tt> on following declarations:
1576 <blockquote><pre>requires AllocatableElement<Alloc, T, const T&>
1577 <del>void</del> <ins>iterator</ins> insert_after(const_iterator position, initializer_list<T> il);
1581 change return type from <tt>void</tt> to <tt>iterator</tt> on following declarations:
1585 p2 23.3.4 [list] Update class definition, change return type from <tt>void</tt> to <tt>iterator</tt>:
1588 <blockquote><pre>requires AllocatableElement<Alloc, T, const T&> && MoveAssignable<T>
1589 <del>void</del> <ins>iterator</ins> insert(const_iterator position, size_type n, const T& x);
1591 template <InputIterator Iter>
1592 requires AllocatableElement<Alloc, T, Iter::reference> && MoveAssignable<T>
1593 <del>void</del> <ins>iterator</ins> insert(const_iterator position, Iter first, Iter last);
1595 requires AllocatableElement<Alloc, T, const T&> && MoveAssignable<T>
1596 <del>void</del> <ins>iterator</ins> insert(const_iterator position, initializer_list<T>);
1601 23.3.4.3 [list.modifiers] change return type from <tt>void</tt> to <tt>iterator</tt> on following declarations:
1604 <blockquote><pre>requires AllocatableElement<Alloc, T, const T&> && MoveAssignable<T>
1605 <del>void</del> <ins>iterator</ins> insert(const_iterator position, size_type n, const T& x);
1607 template <InputIterator Iter>
1608 requires AllocatableElement<Alloc, T, Iter::reference> && MoveAssignable<T>
1609 <del>void</del> <ins>iterator</ins> insert(const_iterator position, Iter first, Iter last);
1613 Add the following (missing) declaration
1616 <blockquote><pre>requires AllocatableElement<Alloc, T, const T&> && MoveAssignable<T>
1617 iterator insert(const_iterator position, initializer_list<T>);
1625 Update class definition, change return type from <tt>void</tt> to <tt>iterator</tt>:
1628 <blockquote><pre>requires AllocatableElement<Alloc, T, T&&> && MoveAssignable<T>
1629 <del>void</del> <ins>iterator</ins> insert(const_iterator position, T&& x);
1631 requires AllocatableElement<Alloc, T, const T&> && MoveAssignable<T>
1632 <del>void</del> <ins>iterator</ins> insert(const_iterator position, size_type n, const T& x);
1634 template <InputIterator Iter>
1635 requires AllocatableElement<Alloc, T, Iter::reference> && MoveAssignable<T>
1636 <del>void</del> <ins>iterator</ins> insert(const_iterator position, Iter first, Iter last);
1638 requires AllocatableElement<Alloc, T, const T&> && MoveAssignable<T>
1639 <del>void</del> <ins>iterator</ins> insert(const_iterator position, initializer_list<T>);
1643 23.3.6.4 [vector.modifiers] change return type from <tt>void</tt> to <tt>iterator</tt> on following declarations:
1646 <blockquote><pre>requires AllocatableElement<Alloc, T, const T&> && MoveAssignable<T>
1647 <del>void</del> <ins>iterator</ins> insert(const_iterator position, size_type n, const T& x);
1649 template <InputIterator Iter>
1650 requires AllocatableElement<Alloc, T, Iter::reference> && MoveAssignable<T>
1651 <del>void</del> <ins>iterator</ins> insert(const_iterator position, Iter first, Iter last);
1655 Add the following (missing) declaration
1658 <blockquote><pre>requires AllocatableElement<Alloc, T, const T&> && MoveAssignable<T>
1659 iterator insert(const_iterator position, initializer_list<T>);
1664 p1 23.3.7 [vector.bool] Update class definition, change return type from <tt>void</tt> to <tt>iterator</tt>:
1667 <blockquote><pre><del>void</del> <ins>iterator</ins> insert (const_iterator position, size_type n, const bool& x);
1669 template <InputIterator Iter>
1670 requires Convertible<Iter::reference, bool>
1671 <del>void</del> <ins>iterator</ins> insert(const_iterator position, Iter first, Iter last);
1673 <del>void</del> <ins>iterator</ins> insert(const_iterator position, initializer_list<bool> il);
1677 p5 21.4 [basic.string] Update class definition, change return type from <tt>void</tt> to <tt>iterator</tt>:
1680 <blockquote><pre><del>void</del> <ins>iterator</ins> insert(const_iterator p, size_type n, charT c);
1682 template<class InputIterator>
1683 <del>void</del> <ins>iterator</ins> insert(const_iterator p, InputIterator first, InputIterator last);
1685 <del>void</del> <ins>iterator</ins> insert(const_iterator p, initializer_list<charT>);
1689 p13 21.4.6.4 [string::insert] change return type from <tt>void</tt> to <tt>iterator</tt>:
1692 <blockquote><pre><del>void</del> <ins>iterator</ins> insert(const_iterator p, size_type n, charT c);
1700 <i>Returns:</i> an iterator which refers to the copy of the first inserted
1701 character, or <tt>p</tt> if <tt>n == 0</tt>.
1705 p15 21.4.6.4 [string::insert] change return type from <tt>void</tt> to <tt>iterator</tt>:
1708 <blockquote><pre>template<class InputIterator>
1709 <del>void</del> <ins>iterator</ins> insert(const_iterator p, InputIterator first, InputIterator last);
1717 <i>Returns:</i> an iterator which refers to the copy of the first inserted
1718 character, or <tt>p</tt> if <tt>first == last</tt>.
1722 p17 21.4.6.4 [string::insert] change return type from <tt>void</tt> to <tt>iterator</tt>:
1725 <blockquote><pre><del>void</del> <ins>iterator</ins> insert(const_iterator p, initializer_list<charT> il);
1733 <i>Returns:</i> an iterator which refers to the copy of the first inserted
1734 character, or <tt>p</tt> if <tt>il</tt> is empty.
1739 <p><b>Rationale:</b></p>
1742 The following was the C++98/03 rationale and does not necessarily apply to the
1743 proposed resolution in the C++0X time frame:
1748 <p>The LWG believes this was an intentional design decision and so is
1749 not a defect. It may be worth revisiting for the next standard.</p>
1756 <h3><a name="190"></a>190. min() and max() functions should be std::binary_functions</h3>
1757 <p><b>Section:</b> 25.5.7 [alg.min.max] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
1758 <b>Submitter:</b> Mark Rintoul <b>Opened:</b> 1999-08-26 <b>Last modified:</b> 2008-03-14</p>
1759 <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>
1760 <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>
1761 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
1762 <p><b>Discussion:</b></p>
1763 <p>Both std::min and std::max are defined as template functions. This
1764 is very different than the definition of std::plus (and similar
1765 structs) which are defined as function objects which inherit
1766 std::binary_function.<br>
1768 This lack of inheritance leaves std::min and std::max somewhat useless in standard library algorithms which require
1769 a function object that inherits std::binary_function.</p>
1772 post Bellevue: Alisdair requested to re-Open.
1778 <p><b>Rationale:</b></p>
1779 <p>Although perhaps an unfortunate design decision, the omission is not a defect
1780 in the current standard. A future standard may wish to consider additional
1781 function objects.</p>
1787 <h3><a name="219"></a>219. find algorithm missing version that takes a binary predicate argument</h3>
1788 <p><b>Section:</b> 25.3.5 [alg.find] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
1789 <b>Submitter:</b> Pablo Halpern <b>Opened:</b> 2000-03-06 <b>Last modified:</b> 2009-03-09</p>
1790 <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>
1791 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
1792 <p><b>Discussion:</b></p>
1793 <p>The find function always searches for a value using operator== to compare the
1794 value argument to each element in the input iterator range. This is inconsistent
1795 with other find-related functions such as find_end and find_first_of, which
1796 allow the caller to specify a binary predicate object to be used for determining
1797 equality. The fact that this can be accomplished using a combination of find_if
1798 and bind_1st or bind_2nd does not negate the desirability of a consistent,
1799 simple, alternative interface to find.</p>
1807 Reopened by Alisdair.
1812 <p><b>Proposed resolution:</b></p>
1814 <p>In section 25.3.5 [alg.find], add a second prototype for find
1815 (between the existing prototype and the prototype for find_if), as
1817 <pre> template<class InputIterator, class T, class BinaryPredicate>
1818 InputIterator find(InputIterator first, InputIterator last,
1819 const T& value, BinaryPredicate bin_pred);</pre>
1820 <p>Change the description of the return from:</p>
1822 <p>Returns: The first iterator i in the range [first, last) for which the following corresponding
1823 conditions hold: *i == value, pred(*i) != false. Returns last if no such iterator is found.</p>
1827 <p>Returns: The first iterator i in the range [first, last) for which the following
1828 corresponding condition holds: *i == value, bin_pred(*i,value) != false, pred(*)
1829 != false. Return last if no such iterator is found.</p>
1834 <p><b>Rationale:</b></p>
1835 <p>This is request for a pure extension, so it is not a defect in the
1836 current standard. As the submitter pointed out, "this can
1837 be accomplished using a combination of find_if and bind_1st or
1844 <h3><a name="255"></a>255. Why do <tt>basic_streambuf<>::pbump()</tt> and <tt>gbump()</tt> take an int?</h3>
1845 <p><b>Section:</b> 27.6.2 [streambuf] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
1846 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-08-12 <b>Last modified:</b> 2007-01-15</p>
1847 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#streambuf">issues</a> in [streambuf].</p>
1848 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
1849 <p><b>Discussion:</b></p>
1851 The basic_streambuf members gbump() and pbump() are specified to take an
1852 int argument. This requirement prevents the functions from effectively
1853 manipulating buffers larger than std::numeric_limits<int>::max()
1854 characters. It also makes the common use case for these functions
1855 somewhat difficult as many compilers will issue a warning when an
1856 argument of type larger than int (such as ptrdiff_t on LLP64
1857 architectures) is passed to either of the function. Since it's often the
1858 result of the subtraction of two pointers that is passed to the
1859 functions, a cast is necessary to silence such warnings. Finally, the
1860 usage of a native type in the functions signatures is inconsistent with
1861 other member functions (such as sgetn() and sputn()) that manipulate the
1862 underlying character buffer. Those functions take a streamsize argument.
1866 <p><b>Proposed resolution:</b></p>
1868 Change the signatures of these functions in the synopsis of template
1869 class basic_streambuf (27.5.2) and in their descriptions (27.5.2.3.1, p4
1870 and 27.5.2.3.2, p4) to take a streamsize argument.
1874 Although this change has the potential of changing the ABI of the
1875 library, the change will affect only platforms where int is different
1876 than the definition of streamsize. However, since both functions are
1877 typically inline (they are on all known implementations), even on such
1878 platforms the change will not affect any user code unless it explicitly
1879 relies on the existing type of the functions (e.g., by taking their
1880 address). Such a possibility is IMO quite remote.
1884 Alternate Suggestion from Howard Hinnant, c++std-lib-7780:
1888 This is something of a nit, but I'm wondering if streamoff wouldn't be a
1889 better choice than streamsize. The argument to pbump and gbump MUST be
1890 signed. But the standard has this to say about streamsize
1891 (27.4.1/2/Footnote):
1895 [Footnote: streamsize is used in most places where ISO C would use
1896 size_t. Most of the uses of streamsize could use size_t, except for
1897 the strstreambuf constructors, which require negative values. It
1898 should probably be the signed type corresponding to size_t (which is
1899 what Posix.2 calls ssize_t). --- end footnote]
1903 This seems a little weak for the argument to pbump and gbump. Should we
1904 ever really get rid of strstream, this footnote might go with it, along
1905 with the reason to make streamsize signed.
1909 <p><b>Rationale:</b></p>
1910 <p>The LWG believes this change is too big for now. We may wish to
1911 reconsider this for a future revision of the standard. One
1912 possibility is overloading pbump, rather than changing the
1915 [2006-05-04: Reopened at the request of Chris (Krzysztof ?elechowski)]
1923 <h3><a name="290"></a>290. Requirements to for_each and its function object</h3>
1924 <p><b>Section:</b> 25.3.4 [alg.foreach] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
1925 <b>Submitter:</b> Angelika Langer <b>Opened:</b> 2001-01-03 <b>Last modified:</b> 2006-12-27</p>
1926 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#alg.foreach">active issues</a> in [alg.foreach].</p>
1927 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.foreach">issues</a> in [alg.foreach].</p>
1928 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
1929 <p><b>Discussion:</b></p>
1930 <p>The specification of the for_each algorithm does not have a
1931 "Requires" section, which means that there are no
1932 restrictions imposed on the function object whatsoever. In essence it
1933 means that I can provide any function object with arbitrary side
1934 effects and I can still expect a predictable result. In particular I
1935 can expect that the function object is applied exactly last - first
1936 times, which is promised in the "Complexity" section.
1939 <p>I don't see how any implementation can give such a guarantee
1940 without imposing requirements on the function object.
1943 <p>Just as an example: consider a function object that removes
1944 elements from the input sequence. In that case, what does the
1945 complexity guarantee (applies f exactly last - first times) mean?
1948 <p>One can argue that this is obviously a nonsensical application and
1949 a theoretical case, which unfortunately it isn't. I have seen
1950 programmers shooting themselves in the foot this way, and they did not
1951 understand that there are restrictions even if the description of the
1952 algorithm does not say so.
1954 <p><i>[Lillehammer: This is more general than for_each. We don't want
1955 the function object in transform invalidiating iterators
1956 either. There should be a note somewhere in clause 17 (17, not 25)
1957 saying that user code operating on a range may not invalidate
1958 iterators unless otherwise specified. Bill will provide wording.]</i></p>
1962 <p><b>Proposed resolution:</b></p>
1970 <h3><a name="309"></a>309. Does sentry catch exceptions?</h3>
1971 <p><b>Section:</b> 27.7 [iostream.format] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
1972 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-03-19 <b>Last modified:</b> 2006-12-27</p>
1973 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostream.format">issues</a> in [iostream.format].</p>
1974 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
1975 <p><b>Discussion:</b></p>
1977 The descriptions of the constructors of basic_istream<>::sentry
1978 (27.7.1.1.3 [istream::sentry]) and basic_ostream<>::sentry
1979 (27.7.2.4 [ostream::sentry]) do not explain what the functions do in
1980 case an exception is thrown while they execute. Some current
1981 implementations allow all exceptions to propagate, others catch them
1982 and set ios_base::badbit instead, still others catch some but let
1987 The text also mentions that the functions may call setstate(failbit)
1988 (without actually saying on what object, but presumably the stream
1989 argument is meant). That may have been fine for
1990 basic_istream<>::sentry prior to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a>, since
1991 the function performs an input operation which may fail. However,
1992 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a> amends 27.7.1.1.3 [istream::sentry], p2 to
1993 clarify that the function should actually call setstate(failbit |
1994 eofbit), so the sentence in p3 is redundant or even somewhat
1999 The same sentence that appears in 27.7.2.4 [ostream::sentry], p3
2000 doesn't seem to be very meaningful for basic_istream<>::sentry
2001 which performs no input. It is actually rather misleading since it
2002 would appear to guide library implementers to calling
2003 setstate(failbit) when os.tie()->flush(), the only called function,
2004 throws an exception (typically, it's badbit that's set in response to
2008 <p><b>Additional comments from Martin, who isn't comfortable with the
2009 current proposed resolution</b> (see c++std-lib-11530)</p>
2012 The istream::sentry ctor says nothing about how the function
2013 deals with exemptions (27.6.1.1.2, p1 says that the class is
2014 responsible for doing "exception safe"(*) prefix and suffix
2015 operations but it doesn't explain what level of exception
2016 safety the class promises to provide). The mockup example
2017 of a "typical implementation of the sentry ctor" given in
2018 27.6.1.1.2, p6, removed in ISO/IEC 14882:2003, doesn't show
2019 exception handling, either. Since the ctor is not classified
2020 as a formatted or unformatted input function, the text in
2021 27.6.1.1, p1 through p4 does not apply. All this would seem
2022 to suggest that the sentry ctor should not catch or in any
2023 way handle exceptions thrown from any functions it may call.
2024 Thus, the typical implementation of an istream extractor may
2025 look something like [1].
2029 The problem with [1] is that while it correctly sets ios::badbit
2030 if an exception is thrown from one of the functions called from
2031 the sentry ctor, if the sentry ctor reaches EOF while extracting
2032 whitespace from a stream that has eofbit or failbit set in
2033 exceptions(), it will cause an ios::failure to be thrown, which
2034 will in turn cause the extractor to set ios::badbit.
2038 The only straightforward way to prevent this behavior is to
2039 move the definition of the sentry object in the extractor
2040 above the try block (as suggested by the example in 22.2.8,
2041 p9 and also indirectly supported by 27.6.1.3, p1). See [2].
2042 But such an implementation will allow exceptions thrown from
2043 functions called from the ctor to freely propagate to the
2044 caller regardless of the setting of ios::badbit in the stream
2045 object's exceptions().
2049 So since neither [1] nor [2] behaves as expected, the only
2050 possible solution is to have the sentry ctor catch exceptions
2051 thrown from called functions, set badbit, and propagate those
2052 exceptions if badbit is also set in exceptions(). (Another
2053 solution exists that deals with both kinds of sentries, but
2054 the code is non-obvious and cumbersome -- see [3].)
2058 Please note that, as the issue points out, current libraries
2059 do not behave consistently, suggesting that implementors are
2060 not quite clear on the exception handling in istream::sentry,
2061 despite the fact that some LWG members might feel otherwise.
2062 (As documented by the parenthetical comment here:
2063 http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1480.html#309)
2067 Also please note that those LWG members who in Copenhagen
2068 felt that "a sentry's constructor should not catch exceptions,
2069 because sentries should only be used within (un)formatted input
2070 functions and that exception handling is the responsibility of
2071 those functions, not of the sentries," as noted here
2072 http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2001/n1310.html#309
2073 would in effect be either arguing for the behavior described
2074 in [1] or for extractors implemented along the lines of [3].
2078 The original proposed resolution (Revision 25 of the issues
2079 list) clarifies the role of the sentry ctor WRT exception
2080 handling by making it clear that extractors (both library
2081 or user-defined) should be implemented along the lines of
2082 [2] (as opposed to [1]) and that no exception thrown from
2083 the callees should propagate out of either function unless
2084 badbit is also set in exceptions().
2088 <p>[1] Extractor that catches exceptions thrown from sentry:</p>
2091 <pre>struct S { long i; };
2093 istream& operator>> (istream &strm, S &s)
2095 ios::iostate err = ios::goodbit;
2097 const istream::sentry guard (strm, false);
2099 use_facet<num_get<char> >(strm.getloc ())
2100 .get (istreambuf_iterator<char>(strm),
2101 istreambuf_iterator<char>(),
2108 strm.setstate (ios::badbit);
2118 strm.setstate (err);
2124 <p>[2] Extractor that propagates exceptions thrown from sentry:</p>
2127 <pre>istream& operator>> (istream &strm, S &s)
2129 istream::sentry guard (strm, false);
2131 ios::iostate err = ios::goodbit;
2133 use_facet<num_get<char> >(strm.getloc ())
2134 .get (istreambuf_iterator<char>(strm),
2135 istreambuf_iterator<char>(),
2141 strm.setstate (ios::badbit);
2151 strm.setstate (err);
2159 [3] Extractor that catches exceptions thrown from sentry
2160 but doesn't set badbit if the exception was thrown as a
2161 result of a call to strm.clear().
2165 <pre>istream& operator>> (istream &strm, S &s)
2167 const ios::iostate state = strm.rdstate ();
2168 const ios::iostate except = strm.exceptions ();
2169 ios::iostate err = std::ios::goodbit;
2172 const istream::sentry guard (strm, false);
2175 use_facet<num_get<char> >(strm.getloc ())
2176 .get (istreambuf_iterator<char>(strm),
2177 istreambuf_iterator<char>(),
2182 if (thrown && state & except)
2185 strm.setstate (ios::badbit);
2195 strm.setstate (err);
2203 [Pre-Berlin] Reopened at the request of Paolo Carlini and Steve Clamage.
2207 [Pre-Portland] A relevant newsgroup post:
2211 The current proposed resolution of issue #309
2212 (http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#309) is
2213 unacceptable. I write commerical software and coding around this
2214 makes my code ugly, non-intuitive, and requires comments referring
2215 people to this very issue. Following is the full explanation of my
2219 In the course of writing software for commercial use, I constructed
2220 std::ifstream's based on user-supplied pathnames on typical POSIX
2224 It was expected that some files that opened successfully might not read
2225 successfully -- such as a pathname which actually refered to a
2226 directory. Intuitively, I expected the streambuffer underflow() code
2227 to throw an exception in this situation, and recent implementations of
2228 libstdc++'s basic_filebuf do just that (as well as many of my own
2232 I also intuitively expected that the istream code would convert these
2233 exceptions to the "badbit' set on the stream object, because I had not
2234 requested exceptions. I refer to 27.6.1.1. P4.
2237 However, this was not the case on at least two implementations -- if
2238 the first thing I did with an istream was call operator>>( T& ) for T
2239 among the basic arithmetic types and std::string. Looking further I
2240 found that the sentry's constructor was invoking the exception when it
2241 pre-scanned for whitespace, and the extractor function (operator>>())
2242 was not catching exceptions in this situation.
2245 So, I was in a situation where setting 'noskipws' would change the
2246 istream's behavior even though no characters (whitespace or not) could
2247 ever be successfully read.
2250 Also, calling .peek() on the istream before calling the extractor()
2251 changed the behavior (.peek() had the effect of setting the badbit
2255 I found this all to be so inconsistent and inconvenient for me and my
2256 code design, that I filed a bugzilla entry for libstdc++. I was then
2257 told that the bug cannot be fixed until issue #309 is resolved by the
2263 <p><b>Proposed resolution:</b></p>
2266 <p><b>Rationale:</b></p>
2267 <p>The LWG agrees there is minor variation between implementations,
2268 but believes that it doesn't matter. This is a rarely used corner
2269 case. There is no evidence that this has any commercial importance
2270 or that it causes actual portability problems for customers trying
2271 to write code that runs on multiple implementations.</p>
2278 <h3><a name="342"></a>342. seek and eofbit</h3>
2279 <p><b>Section:</b> 27.7.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
2280 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2001-10-09 <b>Last modified:</b> 2007-01-15</p>
2281 <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>
2282 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
2283 <p><b>Discussion:</b></p>
2284 <p>I think we have a defect.</p>
2286 <p>According to lwg issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</a> which is now a dr, the
2287 description of seekg in 27.7.1.3 [istream.unformatted] paragraph 38 now looks
2291 Behaves as an unformatted input function (as described in 27.6.1.3,
2292 paragraph 1), except that it does not count the number of characters
2293 extracted and does not affect the value returned by subsequent calls to
2294 gcount(). After constructing a sentry object, if fail() != true,
2295 executes rdbuf()->pubseekpos( pos).
2298 <p>And according to lwg issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#243">243</a> which is also now a dr,
2299 27.6.1.3, paragraph 1 looks like:</p>
2302 Each unformatted input function begins execution by constructing an
2303 object of class sentry with the default argument noskipws (second)
2304 argument true. If the sentry object returns true, when converted to a
2305 value of type bool, the function endeavors to obtain the requested
2306 input. Otherwise, if the sentry constructor exits by throwing an
2307 exception or if the sentry object returns false, when converted to a
2308 value of type bool, the function returns without attempting to obtain
2309 any input. In either case the number of extracted characters is set to
2310 0; unformatted input functions taking a character array of non-zero
2311 size as an argument shall also store a null character (using charT())
2312 in the first location of the array. If an exception is thrown during
2313 input then ios::badbit is turned on in *this'ss error state. If
2314 (exception()&badbit)!= 0 then the exception is rethrown. It also counts
2315 the number of characters extracted. If no exception has been thrown it
2316 ends by storing the count in a member object and returning the value
2317 specified. In any event the sentry object is destroyed before leaving
2318 the unformatted input function.
2321 <p>And finally 27.6.1.1.2/5 says this about sentry:</p>
2324 If, after any preparation is completed, is.good() is true, ok_ != false
2325 otherwise, ok_ == false.
2329 So although the seekg paragraph says that the operation proceeds if
2330 !fail(), the behavior of unformatted functions says the operation
2331 proceeds only if good(). The two statements are contradictory when only
2332 eofbit is set. I don't think the current text is clear which condition
2333 should be respected.
2336 <p><b>Further discussion from Redmond:</b></p>
2338 <p>PJP: It doesn't seem quite right to say that <tt>seekg</tt> is
2339 "unformatted". That makes specific claims about sentry that
2340 aren't quite appropriate for seeking, which has less fragile failure
2341 modes than actual input. If we do really mean that it's unformatted
2342 input, it should behave the same way as other unformatted input. On
2343 the other hand, "principle of least surprise" is that seeking from EOF
2347 Pre-Berlin: Paolo points out several problems with the proposed resolution in
2352 <li>It should apply to both overloads of seekg.</li>
2353 <li>tellg has similar issues, except that it should not call clear().</li>
2354 <li>The point about clear() seems to apply to seekp().</li>
2355 <li>Depending on the outcome of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#419">419</a>
2357 sets <tt>failbit</tt> when it finds <tt>eofbit</tt> already set, then
2358 you can never seek away from the end of stream.</li>
2363 <p><b>Proposed resolution:</b></p>
2365 <p>Change 27.7.1.3 [istream.unformatted] to:</p>
2367 Behaves as an unformatted input function (as described in 27.6.1.3,
2368 paragraph 1), except that it does not count the number of characters
2369 extracted, does not affect the value returned by subsequent calls to
2370 gcount(), and does not examine the value returned by the sentry
2371 object. After constructing a sentry object, if <tt>fail() !=
2372 true</tt>, executes <tt>rdbuf()->pubseekpos(pos)</tt>. In
2373 case of success, the function calls clear().
2374 In case of failure, the function calls <tt>setstate(failbit)</tt>
2375 (which may throw <tt>ios_base::failure</tt>).
2378 <p><i>[Lillehammer: Matt provided wording.]</i></p>
2383 <p><b>Rationale:</b></p>
2384 <p>In C, fseek does clear EOF. This is probably what most users would
2385 expect. We agree that having eofbit set should not deter a seek,
2386 and that a successful seek should clear eofbit. Note
2387 that <tt>fail()</tt> is true only if <tt>failbit</tt>
2388 or <tt>badbit</tt> is set, so using <tt>!fail()</tt>, rather
2389 than <tt>good()</tt>, satisfies this goal.</p>
2396 <h3><a name="343"></a>343. Unspecified library header dependencies</h3>
2397 <p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
2398 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-10-09 <b>Last modified:</b> 2009-03-11</p>
2399 <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>
2400 <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>
2401 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
2402 <p><b>Discussion:</b></p>
2404 The synopses of the C++ library headers clearly show which names are
2405 required to be defined in each header. Since in order to implement the
2406 classes and templates defined in these headers declarations of other
2407 templates (but not necessarily their definitions) are typically
2408 necessary the standard in 17.4.4, p1 permits library implementers to
2409 include any headers needed to implement the definitions in each header.
2413 For instance, although it is not explicitly specified in the synopsis of
2414 <string>, at the point of definition of the std::basic_string template
2415 the declaration of the std::allocator template must be in scope. All
2416 current implementations simply include <memory> from within <string>,
2417 either directly or indirectly, to bring the declaration of
2418 std::allocator into scope.
2422 Additionally, however, some implementation also include <istream> and
2423 <ostream> at the top of <string> to bring the declarations of
2424 std::basic_istream and std::basic_ostream into scope (which are needed
2425 in order to implement the string inserter and extractor operators
2426 (21.3.7.9 [lib.string.io])). Other implementations only include
2427 <iosfwd>, since strictly speaking, only the declarations and not the
2428 full definitions are necessary.
2432 Obviously, it is possible to implement <string> without actually
2433 providing the full definitions of all the templates std::basic_string
2434 uses (std::allocator, std::basic_istream, and std::basic_ostream).
2435 Furthermore, not only is it possible, doing so is likely to have a
2436 positive effect on compile-time efficiency.
2440 But while it may seem perfectly reasonable to expect a program that uses
2441 the std::basic_string insertion and extraction operators to also
2442 explicitly include <istream> or <ostream>, respectively, it doesn't seem
2443 reasonable to also expect it to explicitly include <memory>. Since
2444 what's reasonable and what isn't is highly subjective one would expect
2445 the standard to specify what can and what cannot be assumed.
2446 Unfortunately, that isn't the case.
2449 <p>The examples below demonstrate the issue.</p>
2453 <p>It is not clear whether the following program is complete:</p>
2455 <pre>#include <string>
2457 extern std::basic_ostream<char> &strm;
2460 strm << std::string ("Hello, World!\n");
2464 <p>or whether one must explicitly include <memory> or
2465 <ostream> (or both) in addition to <string> in order for
2466 the program to compile.</p>
2471 <p>Similarly, it is unclear whether the following program is complete:</p>
2473 <pre>#include <istream>
2475 extern std::basic_iostream<char> &strm;
2478 strm << "Hello, World!\n";
2483 or whether one needs to explicitly include <ostream>, and
2484 perhaps even other headers containing the definitions of other
2485 required templates:</p>
2487 <pre>#include <ios>
2488 #include <istream>
2489 #include <ostream>
2490 #include <streambuf>
2492 extern std::basic_iostream<char> &strm;
2495 strm << "Hello, World!\n";
2501 <p>Likewise, it seems unclear whether the program below is complete:</p>
2502 <pre>#include <iterator>
2504 bool foo (std::istream_iterator<int> a, std::istream_iterator<int> b)
2512 <p>or whether one should be required to include <istream>.</p>
2514 <p>There are many more examples that demonstrate this lack of a
2515 requirement. I believe that in a good number of cases it would be
2516 unreasonable to require that a program explicitly include all the
2517 headers necessary for a particular template to be specialized, but I
2518 think that there are cases such as some of those above where it would
2519 be desirable to allow implementations to include only as much as
2520 necessary and not more.</p>
2528 Position taken in prior reviews is that the idea of a table of header
2529 dependencies is a good one. Our view is that a full paper is needed to
2530 do justice to this, and we've made that recommendation to the issue
2536 <p><b>Proposed resolution:</b></p>
2538 For every C++ library header, supply a minimum set of other C++ library
2539 headers that are required to be included by that header. The proposed
2540 list is below (C++ headers for C Library Facilities, table 12 in
2541 17.4.1.2, p3, are omitted):
2544 <pre>+------------+--------------------+
2545 | C++ header |required to include |
2546 +============+====================+
2547 |<algorithm> | |
2548 +------------+--------------------+
2550 +------------+--------------------+
2551 |<complex> | |
2552 +------------+--------------------+
2553 |<deque> |<memory> |
2554 +------------+--------------------+
2555 |<exception> | |
2556 +------------+--------------------+
2557 |<fstream> |<ios> |
2558 +------------+--------------------+
2559 |<functional>| |
2560 +------------+--------------------+
2561 |<iomanip> |<ios> |
2562 +------------+--------------------+
2563 |<ios> |<streambuf> |
2564 +------------+--------------------+
2566 +------------+--------------------+
2567 |<iostream> |<istream>, <ostream>|
2568 +------------+--------------------+
2569 |<istream> |<ios> |
2570 +------------+--------------------+
2571 |<iterator> | |
2572 +------------+--------------------+
2574 +------------+--------------------+
2575 |<list> |<memory> |
2576 +------------+--------------------+
2578 +------------+--------------------+
2579 |<map> |<memory> |
2580 +------------+--------------------+
2582 +------------+--------------------+
2583 |<new> |<exception> |
2584 +------------+--------------------+
2585 |<numeric> | |
2586 +------------+--------------------+
2587 |<ostream> |<ios> |
2588 +------------+--------------------+
2589 |<queue> |<deque> |
2590 +------------+--------------------+
2591 |<set> |<memory> |
2592 +------------+--------------------+
2593 |<sstream> |<ios>, <string> |
2594 +------------+--------------------+
2595 |<stack> |<deque> |
2596 +------------+--------------------+
2597 |<stdexcept> | |
2598 +------------+--------------------+
2599 |<streambuf> |<ios> |
2600 +------------+--------------------+
2601 |<string> |<memory> |
2602 +------------+--------------------+
2603 |<strstream> | |
2604 +------------+--------------------+
2605 |<typeinfo> |<exception> |
2606 +------------+--------------------+
2607 |<utility> | |
2608 +------------+--------------------+
2609 |<valarray> | |
2610 +------------+--------------------+
2611 |<vector> |<memory> |
2612 +------------+--------------------+
2616 <p><b>Rationale:</b></p>
2617 <p>The portability problem is real. A program that works correctly on
2618 one implementation might fail on another, because of different header
2619 dependencies. This problem was understood before the standard was
2620 completed, and it was a conscious design choice.</p>
2621 <p>One possible way to deal with this, as a library extension, would
2622 be an <all> header.</p>
2625 Hinnant: It's time we dealt with this issue for C++0X. Reopened.
2635 <h3><a name="382"></a>382. codecvt do_in/out result</h3>
2636 <p><b>Section:</b> 22.4.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
2637 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2002-08-30 <b>Last modified:</b> 2007-01-15</p>
2638 <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>
2639 <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>
2640 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
2641 <p><b>Discussion:</b></p>
2643 It seems that the descriptions of codecvt do_in() and do_out() leave
2644 sufficient room for interpretation so that two implementations of
2645 codecvt may not work correctly with the same filebuf. Specifically,
2646 the following seems less than adequately specified:
2651 the conditions under which the functions terminate
2654 precisely when the functions return ok
2657 precisely when the functions return partial
2660 the full set of conditions when the functions return error
2666 22.4.1.4.2 [locale.codecvt.virtuals], p2 says this about the effects of the
2667 function: ...Stops if it encounters a character it cannot
2668 convert... This assumes that there *is* a character to
2669 convert. What happens when there is a sequence that doesn't form a
2670 valid source character, such as an unassigned or invalid UNICODE
2671 character, or a sequence that cannot possibly form a character
2672 (e.g., the sequence "\xc0\xff" in UTF-8)?
2675 Table 53 says that the function returns codecvt_base::ok
2676 to indicate that the function(s) "completed the conversion."
2677 Suppose that the source sequence is "\xc0\x80" in UTF-8,
2678 with from pointing to '\xc0' and (from_end==from + 1).
2679 It is not clear whether the return value should be ok
2680 or partial (see below).
2683 Table 53 says that the function returns codecvt_base::partial
2684 if "not all source characters converted." With the from pointers
2685 set up the same way as above, it is not clear whether the return
2686 value should be partial or ok (see above).
2689 Table 53, in the row describing the meaning of error mistakenly
2690 refers to a "from_type" character, without the symbol from_type
2691 having been defined. Most likely, the word "source" character
2692 is intended, although that is not sufficient. The functions
2693 may also fail when they encounter an invalid source sequence
2694 that cannot possibly form a valid source character (e.g., as
2695 explained in bullet 1 above).
2699 Finally, the conditions described at the end of 22.4.1.4.2 [locale.codecvt.virtuals], p4 don't seem to be possible:
2702 "A return value of partial, if (from_next == from_end),
2703 indicates that either the destination sequence has not
2704 absorbed all the available destination elements, or that
2705 additional source elements are needed before another
2706 destination element can be produced."
2709 If the value is partial, it's not clear to me that (from_next
2710 ==from_end) could ever hold if there isn't enough room
2711 in the destination buffer. In order for (from_next==from_end) to
2712 hold, all characters in that range must have been successfully
2713 converted (according to 22.4.1.4.2 [locale.codecvt.virtuals], p2) and since there are no
2714 further source characters to convert, no more room in the
2715 destination buffer can be needed.
2718 It's also not clear to me that (from_next==from_end) could ever
2719 hold if additional source elements are needed to produce another
2720 destination character (not element as incorrectly stated in the
2721 text). partial is returned if "not all source characters have
2722 been converted" according to Table 53, which also implies that
2723 (from_next==from) does NOT hold.
2726 Could it be that the intended qualifying condition was actually
2727 (from_next != from_end), i.e., that the sentence was supposed
2731 "A return value of partial, if (from_next != from_end),..."
2734 which would make perfect sense, since, as far as I understand it,
2735 partial can only occur if (from_next != from_end)?
2737 <p><i>[Lillehammer: Defer for the moment, but this really needs to be
2738 fixed. Right now, the description of codecvt is too vague for it to
2739 be a useful contract between providers and clients of codecvt
2740 facets. (Note that both vendors and users can be both providers and
2741 clients of codecvt facets.) The major philosophical issue is whether
2742 the standard should only describe mappings that take a single wide
2743 character to multiple narrow characters (and vice versa), or whether
2744 it should describe fully general N-to-M conversions. When the
2745 original standard was written only the former was contemplated, but
2746 today, in light of the popularity of utf8 and utf16, that doesn't
2747 seem sufficient for C++0x. Bill supports general N-to-M conversions;
2748 we need to make sure Martin and Howard agree.]</i></p>
2752 <p><b>Proposed resolution:</b></p>
2758 <h3><a name="394"></a>394. behavior of formatted output on failure</h3>
2759 <p><b>Section:</b> 27.7.2.6.1 [ostream.formatted.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
2760 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2002-12-27 <b>Last modified:</b> 2007-01-15</p>
2761 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
2762 <p><b>Discussion:</b></p>
2764 There is a contradiction in Formatted output about what bit is
2765 supposed to be set if the formatting fails. On sentence says it's
2766 badbit and another that it's failbit.
2769 27.6.2.5.1, p1 says in the Common Requirements on Formatted output
2772 <pre> ... If the generation fails, then the formatted output function
2773 does setstate(ios::failbit), which might throw an exception.
2776 27.6.2.5.2, p1 goes on to say this about Arithmetic Inserters:
2779 ... The formatting conversion occurs as if it performed the
2780 following code fragment:
2783 use_facet<num_put<charT,ostreambuf_iterator<charT,traits>
2785 (getloc()).put(*this, *this, fill(), val). failed();
2787 ... If failed is true then does setstate(badbit) ...
2790 The original intent of the text, according to Jerry Schwarz (see
2791 c++std-lib-10500), is captured in the following paragraph:
2794 In general "badbit" should mean that the stream is unusable because
2795 of some underlying failure, such as disk full or socket closure;
2796 "failbit" should mean that the requested formatting wasn't possible
2797 because of some inconsistency such as negative widths. So typically
2798 if you clear badbit and try to output something else you'll fail
2799 again, but if you clear failbit and try to output something else
2803 In the case of the arithmetic inserters, since num_put cannot
2804 report failure by any means other than exceptions (in response
2805 to which the stream must set badbit, which prevents the kind of
2806 recoverable error reporting mentioned above), the only other
2807 detectable failure is if the iterator returned from num_put
2808 returns true from failed().
2811 Since that can only happen (at least with the required iostream
2812 specializations) under such conditions as the underlying failure
2813 referred to above (e.g., disk full), setting badbit would seem
2814 to be the appropriate response (indeed, it is required in
2815 27.6.2.5.2, p1). It follows that failbit can never be directly
2816 set by the arithmetic (it can only be set by the sentry object
2817 under some unspecified conditions).
2820 The situation is different for other formatted output functions
2821 which can fail as a result of the streambuf functions failing
2822 (they may do so by means other than exceptions), and which are
2823 then required to set failbit.
2826 The contradiction, then, is that ostream::operator<<(int) will
2827 set badbit if the disk is full, while operator<<(ostream&,
2828 char) will set failbit under the same conditions. To make the behavior
2829 consistent, the Common requirements sections for the Formatted output
2830 functions should be changed as proposed below.
2832 <p><i>[Kona: There's agreement that this is a real issue. What we
2833 decided at Kona: 1. An error from the buffer (which can be detected
2834 either directly from streambuf's member functions or by examining a
2835 streambuf_iterator) should always result in badbit getting set.
2836 2. There should never be a circumstance where failbit gets set.
2837 That represents a formatting error, and there are no circumstances
2838 under which the output facets are specified as signaling a
2839 formatting error. (Even more so for string output that for numeric
2840 because there's nothing to format.) If we ever decide to make it
2841 possible for formatting errors to exist then the facets can signal
2842 the error directly, and that should go in clause 22, not clause 27.
2843 3. The phrase "if generation fails" is unclear and should be
2844 eliminated. It's not clear whether it's intended to mean a buffer
2845 error (e.g. a full disk), a formatting error, or something else.
2846 Most people thought it was supposed to refer to buffer errors; if
2847 so, we should say so. Martin will provide wording.]</i></p>
2852 <p><b>Proposed resolution:</b></p>
2855 <p><b>Rationale:</b></p>
2863 <h3><a name="397"></a>397. ostream::sentry dtor throws exceptions</h3>
2864 <p><b>Section:</b> 27.7.2.4 [ostream::sentry] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
2865 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-01-05 <b>Last modified:</b> 2007-07-25</p>
2866 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#ostream::sentry">active issues</a> in [ostream::sentry].</p>
2867 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream::sentry">issues</a> in [ostream::sentry].</p>
2868 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
2869 <p><b>Discussion:</b></p>
2871 17.4.4.8, p3 prohibits library dtors from throwing exceptions.
2874 27.6.2.3, p4 says this about the ostream::sentry dtor:
2876 <pre> -4- If ((os.flags() & ios_base::unitbuf) && !uncaught_exception())
2877 is true, calls os.flush().
2880 27.6.2.6, p7 that describes ostream::flush() says:
2882 <pre> -7- If rdbuf() is not a null pointer, calls rdbuf()->pubsync().
2883 If that function returns ?-1 calls setstate(badbit) (which
2884 may throw ios_base::failure (27.4.4.3)).
2887 That seems like a defect, since both pubsync() and setstate() can
2891 The contradiction is real. Clause 17 says destructors may never
2892 throw exceptions, and clause 27 specifies a destructor that does
2893 throw. In principle we might change either one. We're leaning
2894 toward changing clause 17: putting in an "unless otherwise specified"
2895 clause, and then putting in a footnote saying the sentry destructor
2896 is the only one that can throw. PJP suggests specifying that
2897 sentry::~sentry() should internally catch any exceptions it might cause.
2902 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#418">418</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a> for related issues.
2908 <p><b>Proposed resolution:</b></p>
2915 <h3><a name="398"></a>398. effects of end-of-file on unformatted input functions</h3>
2916 <p><b>Section:</b> 27.7.2.4 [ostream::sentry] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
2917 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-01-05 <b>Last modified:</b> 2007-01-15</p>
2918 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#ostream::sentry">active issues</a> in [ostream::sentry].</p>
2919 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream::sentry">issues</a> in [ostream::sentry].</p>
2920 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
2921 <p><b>Discussion:</b></p>
2923 While reviewing unformatted input member functions of istream
2924 for their behavior when they encounter end-of-file during input
2925 I found that the requirements vary, sometimes unexpectedly, and
2926 in more than one case even contradict established practice (GNU
2927 libstdc++ 3.2, IBM VAC++ 6.0, STLPort 4.5, SunPro 5.3, HP aCC
2928 5.38, Rogue Wave libstd 3.1, and Classic Iostreams).
2931 The following unformatted input member functions set eofbit if they
2932 encounter an end-of-file (this is the expected behavior, and also
2933 the behavior of all major implementations):
2935 <pre> basic_istream<charT, traits>&
2936 get (char_type*, streamsize, char_type);
2939 Also sets failbit if it fails to extract any characters.
2941 <pre> basic_istream<charT, traits>&
2942 get (char_type*, streamsize);
2945 Also sets failbit if it fails to extract any characters.
2947 <pre> basic_istream<charT, traits>&
2948 getline (char_type*, streamsize, char_type);
2951 Also sets failbit if it fails to extract any characters.
2953 <pre> basic_istream<charT, traits>&
2954 getline (char_type*, streamsize);
2957 Also sets failbit if it fails to extract any characters.
2959 <pre> basic_istream<charT, traits>&
2960 ignore (int, int_type);
2962 <pre> basic_istream<charT, traits>&
2963 read (char_type*, streamsize);
2966 Also sets failbit if it encounters end-of-file.
2968 <pre> streamsize readsome (char_type*, streamsize);
2972 The following unformated input member functions set failbit but
2973 not eofbit if they encounter an end-of-file (I find this odd
2974 since the functions make it impossible to distinguish a general
2975 failure from a failure due to end-of-file; the requirement is
2976 also in conflict with all major implementation which set both
2977 eofbit and failbit):
2979 <pre> int_type get();
2981 <pre> basic_istream<charT, traits>&
2982 get (char_type&);
2985 These functions only set failbit of they extract no characters,
2986 otherwise they don't set any bits, even on failure (I find this
2987 inconsistency quite unexpected; the requirement is also in
2988 conflict with all major implementations which set eofbit
2989 whenever they encounter end-of-file):
2991 <pre> basic_istream<charT, traits>&
2992 get (basic_streambuf<charT, traits>&, char_type);
2994 <pre> basic_istream<charT, traits>&
2995 get (basic_streambuf<charT, traits>&);
2998 This function sets no bits (all implementations except for
2999 STLport and Classic Iostreams set eofbit when they encounter
3002 <pre> int_type peek ();
3004 <p>Informally, what we want is a global statement of intent saying
3005 that eofbit gets set if we trip across EOF, and then we can take
3006 away the specific wording for individual functions. A full review
3007 is necessary. The wording currently in the standard is a mishmash,
3008 and changing it on an individual basis wouldn't make things better.
3009 Dietmar will do this work.</p>
3012 <p><b>Proposed resolution:</b></p>
3018 <h3><a name="408"></a>408. Is vector<reverse_iterator<char*> > forbidden?</h3>
3019 <p><b>Section:</b> 24.2 [iterator.concepts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
3020 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 2003-06-03 <b>Last modified:</b> 2009-05-10</p>
3021 <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>
3022 <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>
3023 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
3024 <p><b>Discussion:</b></p>
3026 I've been discussing iterator semantics with Dave Abrahams, and a
3027 surprise has popped up. I don't think this has been discussed before.
3031 24.2 [iterator.concepts] says that the only operation that can be performed on "singular"
3032 iterator values is to assign a non-singular value to them. (It
3033 doesn't say they can be destroyed, and that's probably a defect.)
3034 Some implementations have taken this to imply that there is no need
3035 to initialize the data member of a reverse_iterator<> in the default
3036 constructor. As a result, code like
3038 <blockquote><pre> std::vector<std::reverse_iterator<char*> > v(7);
3042 invokes undefined behavior, because it must default-initialize the
3043 vector elements, and then copy them to other storage. Of course many
3044 other vector operations on these adapters are also left undefined,
3045 and which those are is not reliably deducible from the standard.
3049 I don't think that 24.1 was meant to make standard-library iterator
3050 types unsafe. Rather, it was meant to restrict what operations may
3051 be performed by functions which take general user- and standard
3052 iterators as arguments, so that raw pointers would qualify as
3053 iterators. However, this is not clear in the text, others have come
3054 to the opposite conclusion.
3058 One question is whether the standard iterator adaptors have defined
3059 copy semantics. Another is whether they have defined destructor
3062 <blockquote><pre> { std::vector<std::reverse_iterator<char*> > v(7); }
3069 Note this is not a question of whether algorithms are allowed to
3070 rely on copy semantics for arbitrary iterators, just whether the
3071 types we actually supply support those operations. I believe the
3072 resolution must be expressed in terms of the semantics of the
3073 adapter's argument type. It should make clear that, e.g., the
3074 reverse_iterator<T> constructor is actually required to execute
3075 T(), and so copying is defined if the result of T() is copyable.
3079 Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#235">235</a>, which defines reverse_iterator's default
3080 constructor more precisely, has some relevance to this issue.
3081 However, it is not the whole story.
3085 The issue was whether
3087 <blockquote><pre> reverse_iterator() { }
3092 <blockquote><pre> reverse_iterator() : current() { }
3096 The difference is when T is char*, where the first leaves the member
3097 uninitialized, and possibly equal to an existing pointer value, or
3098 (on some targets) may result in a hardware trap when copied.
3102 8.5 paragraph 5 seems to make clear that the second is required to
3103 satisfy DR <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#235">235</a>, at least for non-class Iterator argument
3108 But that only takes care of reverse_iterator, and doesn't establish
3109 a policy for all iterators. (The reverse iterator adapter was just
3110 an example.) In particular, does my function
3112 <blockquote><pre> template <typename Iterator>
3113 void f() { std::vector<Iterator> v(7); }
3116 evoke undefined behavior for some conforming iterator definitions?
3117 I think it does, now, because vector<> will destroy those singular
3118 iterator values, and that's explicitly disallowed.
3122 24.1 shouldn't give blanket permission to copy all singular iterators,
3123 because then pointers wouldn't qualify as iterators. However, it
3124 should allow copying of that subset of singular iterator values that
3125 are default-initialized, and it should explicitly allow destroying any
3126 iterator value, singular or not, default-initialized or not.
3129 <p>Related issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#407">407</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1012">1012</a></p>
3131 We don't want to require all singular iterators to be copyable,
3132 because that is not the case for pointers. However, default
3133 construction may be a special case. Issue: is it really default
3134 construction we want to talk about, or is it something like value
3135 initialization? We need to check with core to see whether default
3136 constructed pointers are required to be copyable; if not, it would be
3137 wrong to impose so strict a requirement for iterators.
3142 2009-05-10 Alisdair provided wording.
3147 The comments regarding destroying singular iterators have already been
3148 resolved. That just leaves copying (with moving implied).
3153 <p><b>Proposed resolution:</b></p>
3155 Add to the end of Iterator concepts 24.2 [iterator.concepts] para 6 (the one
3156 describing singular iterators)
3159 Any Iterator that satisfies the <tt>DefaultConstructible</tt> concept shall
3160 be safely copyable after value-initialization, even if it would otherwise be
3161 singular. [<i>Note:</i> This guarantee is not offered for default-initialization
3162 (8.5 [dcl.init]), although the distinction only matters for types with
3163 trivial default constructors such as pointers. — <i>end note</i>]
3172 <h3><a name="417"></a>417. what does ctype::do_widen() return on failure</h3>
3173 <p><b>Section:</b> 22.4.1.1.2 [locale.ctype.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
3174 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18 <b>Last modified:</b> 2006-12-27</p>
3175 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.ctype.virtuals">issues</a> in [locale.ctype.virtuals].</p>
3176 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
3177 <p><b>Discussion:</b></p>
3179 The Effects and Returns clauses of the do_widen() member function of
3180 the ctype facet fail to specify the behavior of the function on failure.
3181 That the function may not be able to simply cast the narrow character
3182 argument to the type of the result since doing so may yield the wrong value
3183 for some wchar_t encodings. Popular implementations of ctype<wchar_t> that
3184 use mbtowc() and UTF-8 as the native encoding (e.g., GNU glibc) will fail
3185 when the argument's MSB is set. There is no way for the the rest of locale
3186 and iostream to reliably detect this failure.
3188 <p><i>[Kona: This is a real problem. Widening can fail. It's unclear
3189 what the solution should be. Returning WEOF works for the wchar_t
3190 specialization, but not in general. One option might be to add a
3191 default, like <i>narrow</i>. But that's an incompatible change.
3192 Using <i>traits::eof</i> might seem like a good idea, but facets
3193 don't have access to traits (a recurring problem). We could
3194 have <i>widen</i> throw an exception, but that's a scary option;
3195 existing library components aren't written with the assumption
3196 that <i>widen</i> can throw.]</i></p>
3200 <p><b>Proposed resolution:</b></p>
3206 <h3><a name="418"></a>418. exceptions thrown during iostream cleanup</h3>
3207 <p><b>Section:</b> 27.5.2.1.6 [ios::Init] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
3208 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18 <b>Last modified:</b> 2007-07-25</p>
3209 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#ios::Init">active issues</a> in [ios::Init].</p>
3210 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios::Init">issues</a> in [ios::Init].</p>
3211 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
3212 <p><b>Discussion:</b></p>
3214 The dtor of the ios_base::Init object is supposed to call flush() on the
3215 6 standard iostream objects cout, cerr, clog, wcout, wcerr, and wclog.
3216 This call may cause an exception to be thrown.
3220 17.4.4.8, p3 prohibits all library destructors from throwing exceptions.
3224 The question is: What should this dtor do if one or more of these calls
3225 to flush() ends up throwing an exception? This can happen quite easily
3226 if one of the facets installed in the locale imbued in the iostream
3229 <p><i>[Kona: We probably can't do much better than what we've got, so
3230 the LWG is leaning toward NAD. At the point where the standard
3231 stream objects are being cleaned up, the usual error reporting
3232 mechanism are all unavailable. And exception from flush at this
3233 point will definitely cause problems. A quality implementation
3234 might reasonably swallow the exception, or call abort, or do
3235 something even more drastic.]</i></p>
3239 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#397">397</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a> for related issues.
3245 <p><b>Proposed resolution:</b></p>
3251 <h3><a name="419"></a>419. istream extractors not setting failbit if eofbit is already set</h3>
3252 <p><b>Section:</b> 27.7.1.1.3 [istream::sentry] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
3253 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18 <b>Last modified:</b> 2007-01-30</p>
3254 <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>
3255 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
3256 <p><b>Discussion:</b></p>
3259 27.7.1.1.3 [istream::sentry], p2 says that istream::sentry ctor prepares for input if is.good()
3260 is true. p4 then goes on to say that the ctor sets the sentry::ok_ member to
3261 true if the stream state is good after any preparation. 27.7.1.2.1 [istream.formatted.reqmts], p1 then
3262 says that a formatted input function endeavors to obtain the requested input
3263 if the sentry's operator bool() returns true.
3265 Given these requirements, no formatted extractor should ever set failbit if
3266 the initial stream rdstate() == eofbit. That is contrary to the behavior of
3267 all implementations I tested. The program below prints out
3275 #include <sstream>
3276 #include <cstdio>
3280 std::istringstream strm ("1");
3286 std::printf ("eof = %d, fail = %d\n",
3287 !!strm.eof (), !!strm.fail ());
3291 std::printf ("eof = %d, fail = %d\n",
3292 !!strm.eof (), !!strm.fail ());
3299 Comments from Jerry Schwarz (c++std-lib-11373):
3302 Jerry Schwarz wrote:
3305 I don't know where (if anywhere) it says it in the standard, but the
3306 formatted extractors are supposed to set failbit if they don't extract
3307 any characters. If they didn't then simple loops like
3310 while (cin >> x);
3316 Further comments from Martin Sebor:
3319 The question is which part of the extraction should prevent this from happening
3320 by setting failbit when eofbit is already set. It could either be the sentry
3321 object or the extractor. It seems that most implementations have chosen to
3322 set failbit in the sentry [...] so that's the text that will need to be
3327 Pre Berlin: This issue is related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#342">342</a>. If the sentry
3328 sets <tt>failbit</tt> when it finds <tt>eofbit</tt> already set, then
3329 you can never seek away from the end of stream.
3331 <p>Kona: Possibly NAD. If eofbit is set then good() will return false. We
3332 then set <i>ok</i> to false. We believe that the sentry's
3333 constructor should always set failbit when <i>ok</i> is false, and
3334 we also think the standard already says that. Possibly it could be
3339 <p><b>Proposed resolution:</b></p>
3341 Change 27.7.1.1.3 [istream::sentry], p2 to:
3345 <pre>explicit sentry(basic_istream<charT,traits>& <i>is</i> , bool <i>noskipws</i> = false);</pre>
3347 -2- <i>Effects:</i> If <tt>is.good()</tt> is <del><tt>true</tt></del>
3348 <ins><tt>false</tt></ins>, <ins>calls <tt>is.setstate(failbit)</tt>.
3349 Otherwise</ins> prepares for formatted or unformatted input. ...
3359 <h3><a name="421"></a>421. is basic_streambuf copy-constructible?</h3>
3360 <p><b>Section:</b> 27.6.2.1 [streambuf.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
3361 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18 <b>Last modified:</b> 2007-01-15</p>
3362 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#streambuf.cons">issues</a> in [streambuf.cons].</p>
3363 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
3364 <p><b>Discussion:</b></p>
3366 The reflector thread starting with c++std-lib-11346 notes that the class
3367 template basic_streambuf, along with basic_stringbuf and basic_filebuf,
3368 is copy-constructible but that the semantics of the copy constructors
3369 are not defined anywhere. Further, different implementations behave
3370 differently in this respect: some prevent copy construction of objects
3371 of these types by declaring their copy ctors and assignment operators
3372 private, others exhibit undefined behavior, while others still give
3373 these operations well-defined semantics.
3377 Note that this problem doesn't seem to be isolated to just the three
3378 types mentioned above. A number of other types in the library section
3379 of the standard provide a compiler-generated copy ctor and assignment
3380 operator yet fail to specify their semantics. It's believed that the
3381 only types for which this is actually a problem (i.e. types where the
3382 compiler-generated default may be inappropriate and may not have been
3383 intended) are locale facets. See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#439">439</a>.
3387 <p><b>Proposed resolution:</b></p>
3389 27.5.2 [lib.streambuf]: Add into the synopsis, public section, just above the destructor declaration:
3393 <pre>basic_streambuf(const basic_streambuf& sb);
3394 basic_streambuf& operator=(const basic_streambuf& sb);
3398 <p>Insert after 27.5.2.1, paragraph 2:</p>
3400 <pre>basic_streambuf(const basic_streambuf& sb);
3403 <p>Constructs a copy of sb.</p>
3404 <p>Postcondtions:</p>
3405 <pre> eback() == sb.eback()
3407 egptr() == sb.egptr()
3408 pbase() == sb.pbase()
3410 epptr() == sb.epptr()
3411 getloc() == sb.getloc()
3414 <pre>basic_streambuf& operator=(const basic_streambuf& sb);
3417 <p>Assigns the data members of sb to this.</p>
3419 <p>Postcondtions:</p>
3420 <pre> eback() == sb.eback()
3422 egptr() == sb.egptr()
3423 pbase() == sb.pbase()
3425 epptr() == sb.epptr()
3426 getloc() == sb.getloc()
3429 <p>Returns: *this.</p>
3432 <p>27.7.1 [lib.stringbuf]:</p>
3434 <p><b>Option A:</b></p>
3437 <p>Insert into the basic_stringbuf synopsis in the private section:</p>
3439 <pre>basic_stringbuf(const basic_stringbuf&); // not defined
3440 basic_stringbuf& operator=(const basic_stringbuf&); // not defined
3444 <p><b>Option B:</b></p>
3447 <p>Insert into the basic_stringbuf synopsis in the public section:</p>
3449 <pre>basic_stringbuf(const basic_stringbuf& sb);
3450 basic_stringbuf& operator=(const basic_stringbuf& sb);
3453 <p>27.7.1.1, insert after paragraph 4:</p>
3455 <pre>basic_stringbuf(const basic_stringbuf& sb);</pre>
3458 Constructs an independent copy of sb as if with sb.str(), and with the openmode that sb was constructed with.
3461 <p>Postcondtions: </p>
3462 <pre> str() == sb.str()
3463 gptr() - eback() == sb.gptr() - sb.eback()
3464 egptr() - eback() == sb.egptr() - sb.eback()
3465 pptr() - pbase() == sb.pptr() - sb.pbase()
3466 getloc() == sb.getloc()
3470 Note: The only requirement on epptr() is that it point beyond the
3471 initialized range if an output sequence exists. There is no requirement
3472 that epptr() - pbase() == sb.epptr() - sb.pbase().
3475 <pre>basic_stringbuf& operator=(const basic_stringbuf& sb);</pre>
3476 <p>After assignment the basic_stringbuf has the same state as if it
3477 were initially copy constructed from sb, except that the
3478 basic_stringbuf is allowed to retain any excess capacity it might have,
3479 which may in turn effect the value of epptr().
3483 <p>27.8.1.1 [lib.filebuf]</p>
3485 <p>Insert at the bottom of the basic_filebuf synopsis:</p>
3489 basic_filebuf(const basic_filebuf&); // not defined
3490 basic_filebuf& operator=(const basic_filebuf&); // not defined
3493 <p><i>[Kona: this is an issue for basic_streambuf itself and for its
3494 derived classes. We are leaning toward allowing basic_streambuf to
3495 be copyable, and specifying its precise semantics. (Probably the
3496 obvious: copying the buffer pointers.) We are less sure whether
3497 the streambuf derived classes should be copyable. Howard will
3498 write up a proposal.]</i></p>
3501 <p><i>[Sydney: Dietmar presented a new argument against basic_streambuf
3502 being copyable: it can lead to an encapsulation violation. Filebuf
3503 inherits from streambuf. Now suppose you inhert a my_hijacking_buf
3504 from streambuf. You can copy the streambuf portion of a filebuf to a
3505 my_hijacking_buf, giving you access to the pointers into the
3506 filebuf's internal buffer. Perhaps not a very strong argument, but
3507 it was strong enough to make people nervous. There was weak
3508 preference for having streambuf not be copyable. There was weak
3509 preference for having stringbuf not be copyable even if streambuf
3510 is. Move this issue to open for now.
3516 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1862.html#27.5.2%20-%20Class%20template%20basic_streambuf%3CcharT,traits%3E">Rvalue Reference Recommendations for Chapter 27</a>
3517 recommends protected copy constructor and assignment for <tt>basic_streambuf</tt> with the same semantics
3518 as would be generated by the compiler. These members aid in derived classes implementing move semantics.
3519 A protected copy constructor and copy assignment operator do not expose encapsulation more so than it is
3520 today as each data member of a <tt>basic_streambuf</tt> is already both readable and writable by derived
3521 classes via various get/set protected member functions (<tt>eback()</tt>, <tt>setp()</tt>, etc.). Rather
3522 a protected copy constructor and copy assignment operator simply make the job of derived classes implementing
3523 move semantics less tedious and error prone.
3529 <p><b>Rationale:</b></p>
3531 27.5.2 [lib.streambuf]: The proposed basic_streambuf copy constructor
3532 and assignment operator are the same as currently implied by the lack
3533 of declarations: public and simply copies the data members. This
3534 resolution is not a change but a clarification of the current
3539 27.7.1 [lib.stringbuf]: There are two reasonable options: A) Make
3540 basic_stringbuf not copyable. This is likely the status-quo of
3541 current implementations. B) Reasonable copy semantics of
3542 basic_stringbuf can be defined and implemented. A copyable
3543 basic_streambuf is arguably more useful than a non-copyable one. This
3544 should be considered as new functionality and not the fixing of a
3545 defect. If option B is chosen, ramifications from issue 432 are taken
3550 27.8.1.1 [lib.filebuf]: There are no reasonable copy semantics for
3560 <h3><a name="423"></a>423. effects of negative streamsize in iostreams</h3>
3561 <p><b>Section:</b> 27 [input.output] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
3562 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18 <b>Last modified:</b> 2006-12-27</p>
3563 <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>
3564 <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>
3565 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
3566 <p><b>Discussion:</b></p>
3569 A third party test suite tries to exercise istream::ignore(N) with
3570 a negative value of N and expects that the implementation will treat
3571 N as if it were 0. Our implementation asserts that (N >= 0) holds and
3576 I can't find anything in section 27 that prohibits such values but I don't
3577 see what the effects of such calls should be, either (this applies to
3578 a number of unformatted input functions as well as some member functions
3579 of the basic_streambuf template).
3583 <p><b>Proposed resolution:</b></p>
3585 I propose that we add to each function in clause 27 that takes an argument,
3586 say N, of type streamsize a Requires clause saying that "N >= 0." The intent
3587 is to allow negative streamsize values in calls to precision() and width()
3588 but disallow it in calls to streambuf::sgetn(), istream::ignore(), or
3592 <p><i>[Kona: The LWG agreed that this is probably what we want. However, we
3593 need a review to find all places where functions in clause 27 take
3594 arguments of type streamsize that shouldn't be allowed to go
3595 negative. Martin will do that review.]</i></p>
3603 <h3><a name="424"></a>424. normative notes</h3>
3604 <p><b>Section:</b> 17.5.1.2 [structure.summary] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Tentatively NAD Editorial</a>
3605 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18 <b>Last modified:</b> 2009-05-23</p>
3606 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD%20Editorial">Tentatively NAD Editorial</a> status.</p>
3607 <p><b>Discussion:</b></p>
3610 The text in 17.3.1.1, p1 says:
3613 "Paragraphs labelled "Note(s):" or "Example(s):" are informative, other
3614 paragraphs are normative."
3617 The library section makes heavy use of paragraphs labeled "Notes(s),"
3618 some of which are clearly intended to be normative (see list 1), while
3619 some others are not (see list 2). There are also those where the intent
3620 is not so clear (see list 3).
3623 List 1 -- Examples of (presumably) normative Notes:
3626 20.8.6.1 [allocator.members], p3,<br>
3627 20.8.6.1 [allocator.members], p10,<br>
3628 21.4.2 [string.cons], p11,<br>
3629 22.3.1.2 [locale.cons], p11,<br>
3630 23.3.2.3 [deque.modifiers], p2,<br>
3631 25.5.7 [alg.min.max], p3,<br>
3632 26.4.6 [complex.ops], p15,<br>
3633 27.6.2.4.3 [streambuf.virt.get], p7.<br>
3636 List 2 -- Examples of (presumably) informative Notes:
3639 18.6.1.3 [new.delete.placement], p3,<br>
3640 21.4.6.6 [string::replace], p14,<br>
3641 22.4.1.4.2 [locale.codecvt.virtuals], p3,<br>
3642 25.3.4 [alg.foreach], p4,<br>
3643 26.4.5 [complex.member.ops], p1,<br>
3644 27.5.2.5 [ios.base.storage], p6.<br>
3647 List 3 -- Examples of Notes that are not clearly either normative
3651 22.3.1.2 [locale.cons], p8,<br>
3652 22.3.1.5 [locale.statics], p6,<br>
3653 27.6.2.4.5 [streambuf.virt.put], p4.<br>
3656 None of these lists is meant to be exhaustive.
3659 <p><i>[Definitely a real problem. The big problem is there's material
3660 that doesn't quite fit any of the named paragraph categories
3661 (e.g. <b>Effects</b>). Either we need a new kind of named
3662 paragraph, or we need to put more material in unnamed paragraphs
3663 jsut after the signature. We need to talk to the Project Editor
3664 about how to do this.
3669 Bellevue: Specifics of list 3: First 2 items correct in std (22.1.1.2,
3670 22.1.1.5) Third item should be non-normative (27.5.2.4.5), which Pete
3671 will handle editorially.
3676 post San Francisco: Howard: reopened, needs attention.
3680 <p><i>[Pete: I changed the paragraphs marked "Note" and "Notes" to use "Remark" and "Remarks".
3681 Fixed as editorial. This change has been in the WD since the post-Redmond mailing, in 2004.
3682 Recommend NAD.]</i></p>
3686 Batavia: We feel that the references in List 2 above should be changed from <i>Remarks</i>
3687 to <i>Notes</i>. We also feel that those items in List 3 need to be double checked for
3688 the same change. Alan and Pete to review.
3698 A spot-check of List 2 suggests the issue is still relevant,
3699 and a review of List 3 still seems called-for.
3702 Move to NAD Editorial.
3708 <p><b>Proposed resolution:</b></p>
3714 <h3><a name="427"></a>427. stage 2 and rationale of DR 221</h3>
3715 <p><b>Section:</b> 22.4.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
3716 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18 <b>Last modified:</b> 2007-01-15</p>
3717 <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>
3718 <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>
3719 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
3720 <p><b>Discussion:</b></p>
3722 The requirements specified in Stage 2 and reiterated in the rationale
3723 of DR 221 (and echoed again in DR 303) specify that num_get<charT>::
3724 do_get() compares characters on the stream against the widened elements
3725 of "012...abc...ABCX+-"
3729 An implementation is required to allow programs to instantiate the num_get
3730 template on any charT that satisfies the requirements on a user-defined
3731 character type. These requirements do not include the ability of the
3732 character type to be equality comparable (the char_traits template must
3733 be used to perform tests for equality). Hence, the num_get template cannot
3734 be implemented to support any arbitrary character type. The num_get template
3735 must either make the assumption that the character type is equality-comparable
3736 (as some popular implementations do), or it may use char_traits<charT> to do
3737 the comparisons (some other popular implementations do that). This diversity
3738 of approaches makes it difficult to write portable programs that attempt to
3739 instantiate the num_get template on user-defined types.
3742 <p><i>[Kona: the heart of the problem is that we're theoretically
3743 supposed to use traits classes for all fundamental character
3744 operations like assignment and comparison, but facets don't have
3745 traits parameters. This is a fundamental design flaw and it
3746 appears all over the place, not just in this one place. It's not
3747 clear what the correct solution is, but a thorough review of facets
3748 and traits is in order. The LWG considered and rejected the
3749 possibility of changing numeric facets to use narrowing instead of
3750 widening. This may be a good idea for other reasons (see issue
3751 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#459">459</a>), but it doesn't solve the problem raised by this
3752 issue. Whether we use widen or narrow the <tt>num_get</tt> facet
3753 still has no idea which traits class the user wants to use for
3754 the comparison, because only streams, not facets, are passed traits
3755 classes. The standard does not require that two different
3756 traits classes with the same <tt>char_type</tt> must necessarily
3757 have the same behavior.]</i></p>
3760 <p>Informally, one possibility: require that some of the basic
3761 character operations, such as <tt>eq</tt>, <tt>lt</tt>,
3762 and <tt>assign</tt>, must behave the same way for all traits classes
3763 with the same <tt>char_type</tt>. If we accept that limitation on
3764 traits classes, then the facet could reasonably be required to
3765 use <tt>char_traits<charT></tt>.</p>
3768 <p><b>Proposed resolution:</b></p>
3774 <h3><a name="430"></a>430. valarray subset operations</h3>
3775 <p><b>Section:</b> 26.6.2.4 [valarray.sub] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
3776 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18 <b>Last modified:</b> 2009-05-01</p>
3777 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
3778 <p><b>Discussion:</b></p>
3780 The standard fails to specify the behavior of valarray::operator[](slice)
3781 and other valarray subset operations when they are passed an "invalid"
3782 slice object, i.e., either a slice that doesn't make sense at all (e.g.,
3783 slice (0, 1, 0) or one that doesn't specify a valid subset of the valarray
3784 object (e.g., slice (2, 1, 1) for a valarray of size 1).
3786 <p><i>[Kona: the LWG believes that invalid slices should invoke
3787 undefined behavior. Valarrays are supposed to be designed for high
3788 performance, so we don't want to require specific checking. We
3789 need wording to express this decision.]</i></p>
3798 Please note that the standard also fails to specify the behavior of
3799 slice_array and gslice_array in the valid case. Bill Plauger will
3800 endeavor to provide revised wording for slice_array and gslice_array.
3804 post-Bellevue: Bill provided wording.
3809 <p><b>Proposed resolution:</b></p>
3811 Insert after 26.6.2.4 [valarray.sub], paragraph 1:
3816 The member operator is overloaded to provide several ways to select
3818 of elements from among those controlled by <tt>*this</tt>. The first group of five
3819 member operators work in conjunction with various overloads of <tt>operator=</tt>
3820 (and other assigning operators) to allow selective replacement (slicing) of
3821 the controlled sequence. The selected elements must exist.
3824 The first member operator selects element off. For example:
3827 <blockquote><pre>valarray<char> v0("abcdefghijklmnop", 16);
3829 // v0 == valarray<char>("abcAefghijklmnop", 16)
3833 The second member operator selects those elements of the controlled sequence
3834 designated by <tt>slicearr</tt>. For example:
3837 <blockquote><pre>valarray<char> v0("abcdefghijklmnop", 16);
3838 valarray<char> v1("ABCDE", 5);
3839 v0[slice(2, 5, 3)] = v1;
3840 // v0 == valarray<char>("abAdeBghCjkDmnEp", 16)
3844 The third member operator selects those elements of the controlled sequence
3845 designated by <tt>gslicearr</tt>. For example:
3848 <blockquote><pre>valarray<char> v0("abcdefghijklmnop", 16);
3849 valarray<char> v1("ABCDEF", 6);
3850 const size_t lv[] = {2, 3};
3851 const size_t dv[] = {7, 2};
3852 const valarray<size_t> len(lv, 2), str(dv, 2);
3853 v0[gslice(3, len, str)] = v1;
3854 // v0 == valarray<char>("abcAeBgCijDlEnFp", 16)
3858 The fourth member operator selects those elements of the controlled sequence
3859 designated by <tt>boolarr</tt>. For example:
3862 <blockquote><pre>valarray<char> v0("abcdefghijklmnop", 16);
3863 valarray<char> v1("ABC", 3);
3864 const bool vb[] = {false, false, true, true, false, true};
3865 v0[valarray<bool>(vb, 6)] = v1;
3866 // v0 == valarray<char>("abABeCghijklmnop", 16)
3870 The fifth member operator selects those elements of the controlled sequence
3871 designated by indarr. For example:
3874 <blockquote><pre>valarray<char> v0("abcdefghijklmnop", 16);
3875 valarray<char> v1("ABCDE", 5);
3876 const size_t vi[] = {7, 5, 2, 3, 8};
3877 v0[valarray<size_t>(vi, 5)] = v1;
3878 // v0 == valarray<char>("abCDeBgAEjklmnop", 16)
3882 The second group of five member operators each construct an object that
3883 represents the value(s) selected. The selected elements must exist.
3887 The sixth member operator returns the value of element off. For example:
3890 <blockquote><pre>valarray<char> v0("abcdefghijklmnop", 16);
3891 // v0[3] returns 'd'
3895 The seventh member operator returns an object of class <tt>valarray<Ty></tt>
3896 containing those elements of the controlled sequence designated by <tt>slicearr</tt>.
3900 <blockquote><pre>valarray<char> v0("abcdefghijklmnop", 16);
3901 // v0[slice(2, 5, 3)] returns valarray<char>("cfilo", 5)
3905 The eighth member operator selects those elements of the controlled sequence
3906 designated by <tt>gslicearr</tt>. For example:
3909 <blockquote><pre>valarray<char> v0("abcdefghijklmnop", 16);
3910 const size_t lv[] = {2, 3};
3911 const size_t dv[] = {7, 2};
3912 const valarray<size_t> len(lv, 2), str(dv, 2);
3913 // v0[gslice(3, len, str)] returns
3914 // valarray<char>("dfhkmo", 6)
3918 The ninth member operator selects those elements of the controlled sequence
3919 designated by <tt>boolarr</tt>. For example:
3922 <blockquote><pre>valarray<char> v0("abcdefghijklmnop", 16);
3923 const bool vb[] = {false, false, true, true, false, true};
3924 // v0[valarray<bool>(vb, 6)] returns
3925 // valarray<char>("cdf", 3)
3929 The last member operator selects those elements of the controlled sequence
3930 designated by <tt>indarr</tt>. For example:
3933 <blockquote><pre>valarray<char> v0("abcdefghijklmnop", 16);
3934 const size_t vi[] = {7, 5, 2, 3, 8};
3935 // v0[valarray<size_t>(vi, 5)] returns
3936 // valarray<char>("hfcdi", 5)
3946 <h3><a name="431"></a>431. Swapping containers with unequal allocators</h3>
3947 <p><b>Section:</b> X [allocator.requirements], 25 [algorithms] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
3948 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2003-09-20 <b>Last modified:</b> 2009-05-01</p>
3949 <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>
3950 <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>
3951 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
3952 <p><b>Discussion:</b></p>
3953 <p>Clause X [allocator.requirements] paragraph 4 says that implementations
3954 are permitted to supply containers that are unable to cope with
3955 allocator instances and that container implementations may assume
3956 that all instances of an allocator type compare equal. We gave
3957 implementers this latitude as a temporary hack, and eventually we
3958 want to get rid of it. What happens when we're dealing with
3959 allocators that <i>don't</i> compare equal?
3962 <p>In particular: suppose that <tt>v1</tt> and <tt>v2</tt> are both
3963 objects of type <tt>vector<int, my_alloc></tt> and that
3964 <tt>v1.get_allocator() != v2.get_allocator()</tt>. What happens if
3965 we write <tt>v1.swap(v2)</tt>? Informally, three possibilities:</p>
3967 <p>1. This operation is illegal. Perhaps we could say that an
3968 implementation is required to check and to throw an exception, or
3969 perhaps we could say it's undefined behavior.</p>
3970 <p>2. The operation performs a slow swap (i.e. using three
3971 invocations of <tt>operator=</tt>, leaving each allocator with its
3972 original container. This would be an O(N) operation.</p>
3973 <p>3. The operation swaps both the vectors' contents and their
3974 allocators. This would be an O(1) operation. That is:</p>
3976 <pre> my_alloc a1(...);
3980 vector<int, my_alloc> v1(a1);
3981 vector<int, my_alloc> v2(a2);
3982 assert(a1 == v1.get_allocator());
3983 assert(a2 == v2.get_allocator());
3986 assert(a1 == v2.get_allocator());
3987 assert(a2 == v1.get_allocator());
3991 <p><i>[Kona: This is part of a general problem. We need a paper
3992 saying how to deal with unequal allocators in general.]</i></p>
3995 <p><i>[pre-Sydney: Howard argues for option 3 in
3996 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1599.html">N1599</a>.
4001 2007-01-12, Howard: This issue will now tend to come up more often with move constructors
4002 and move assignment operators. For containers, these members transfer resources (i.e.
4003 the allocated memory) just like swap.
4008 Batavia: There is agreement to overload the container <tt>swap</tt> on the allocator's Swappable
4009 requirement using concepts. If the allocator supports Swappable, then container's swap will
4010 swap allocators, else it will perform a "slow swap" using copy construction and copy assignment.
4015 2009-04-28 Pablo adds:
4020 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2525.pdf">N2525</a>.
4021 I argued for marking this Tentatively-Ready right after Bellevue,
4022 but there was a concern that
4023 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2525.pdf">N2525</a>
4024 would break in the presence of the RVO. (That breakage had nothing to do with
4025 swap, but never-the-less). I addressed that breakage in in
4026 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2840.pdf">N2840</a>
4027 (Summit) my means of a non-normative reference:
4030 [<i>Note:</i> in situations where the copy constructor for a container is elided,
4031 this function is not called. The behavior in these cases is as if
4032 <tt>select_on_container_copy_construction</tt> returned <tt>x</tt> — <i>end note</i>]
4039 <p><b>Proposed resolution:</b></p>
4046 <h3><a name="446"></a>446. Iterator equality between different containers</h3>
4047 <p><b>Section:</b> 24.2 [iterator.concepts], 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
4048 <b>Submitter:</b> Andy Koenig <b>Opened:</b> 2003-12-16 <b>Last modified:</b> 2008-09-30</p>
4049 <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>
4050 <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>
4051 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
4052 <p><b>Discussion:</b></p>
4054 What requirements does the standard place on equality comparisons between
4055 iterators that refer to elements of different containers. For example, if
4056 v1 and v2 are empty vectors, is v1.end() == v2.end() allowed to yield true?
4057 Is it allowed to throw an exception?
4061 The standard appears to be silent on both questions.
4063 <p><i>[Sydney: The intention is that comparing two iterators from
4064 different containers is undefined, but it's not clear if we say that,
4065 or even whether it's something we should be saying in clause 23 or in
4066 clause 24. Intuitively we might want to say that equality is defined
4067 only if one iterator is reachable from another, but figuring out how
4068 to say it in any sensible way is a bit tricky: reachability is defined
4069 in terms of equality, so we can't also define equality in terms of
4076 <p><b>Proposed resolution:</b></p>
4084 <h3><a name="458"></a>458. 24.1.5 contains unintented limitation for operator-</h3>
4085 <p><b>Section:</b> 24.2.6 [random.access.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">Tentatively NAD</a>
4086 <b>Submitter:</b> Daniel Frey <b>Opened:</b> 2004-02-27 <b>Last modified:</b> 2009-05-23</p>
4087 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#random.access.iterators">active issues</a> in [random.access.iterators].</p>
4088 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#random.access.iterators">issues</a> in [random.access.iterators].</p>
4089 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD">Tentatively NAD</a> status.</p>
4090 <p><b>Discussion:</b></p>
4092 In 24.1.5 [lib.random.access.iterators], table 76 the operational
4093 semantics for the expression "r -= n" are defined as "return r += -n".
4094 This means, that the expression -n must be valid, which is not the case
4099 Sydney: Possibly not a real problem, since difference type is required
4100 to be a signed integer type. However, the wording in the standard may
4101 be less clear than we would like.
4106 Post Summit Alisdair adds:
4112 This issue refers to a requirements table we have removed.
4115 The issue might now relate to 24.2.6 [random.access.iterators] p5.
4116 However, the rationale in the issue already recognises that the
4117 <tt>difference_type</tt> must be signed, so this really looks NAD.
4127 We agree with Alisdair's observations.
4135 <p><b>Proposed resolution:</b></p>
4137 To remove this limitation, I suggest to change the
4138 operational semantics for this column to:
4140 <blockquote><pre> { Distance m = n;
4154 <h3><a name="459"></a>459. Requirement for widening in stage 2 is overspecification</h3>
4155 <p><b>Section:</b> 22.4.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
4156 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2004-03-16 <b>Last modified:</b> 2006-12-27</p>
4157 <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>
4158 <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>
4159 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
4160 <p><b>Discussion:</b></p>
4161 <p>When parsing strings of wide-character digits, the standard
4162 requires the library to widen narrow-character "atoms" and compare
4163 the widened atoms against the characters that are being parsed.
4164 Simply narrowing the wide characters would be far simpler, and
4165 probably more efficient. The two choices are equivalent except in
4166 convoluted test cases, and many implementations already ignore the
4167 standard and use narrow instead of widen.</p>
4170 First, I disagree that using narrow() instead of widen() would
4171 necessarily have unfortunate performance implications. A possible
4172 implementation of narrow() that allows num_get to be implemented
4173 in a much simpler and arguably comparably efficient way as calling
4174 widen() allows, i.e. without making a virtual call to do_narrow every
4175 time, is as follows:
4178 <pre> inline char ctype<wchar_t>::narrow (wchar_t wc, char dflt) const
4180 const unsigned wi = unsigned (wc);
4182 if (wi > UCHAR_MAX)
4183 return typeid (*this) == typeid (ctype<wchar_t>) ?
4184 dflt : do_narrow (wc, dflt);
4186 if (narrow_ [wi] < 0) {
4187 const char nc = do_narrow (wc, dflt);
4193 return char (narrow_ [wi]);
4198 Second, I don't think the change proposed in the issue (i.e., to use
4199 narrow() instead of widen() during Stage 2) would be at all
4200 drastic. Existing implementations with the exception of libstdc++
4201 currently already use narrow() so the impact of the change on programs
4202 would presumably be isolated to just a single implementation. Further,
4203 since narrow() is not required to translate alternate wide digit
4204 representations such as those mentioned in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#303">303</a>
4206 their narrow equivalents (i.e., the portable source characters '0'
4207 through '9'), the change does not necessarily imply that these
4208 alternate digits would be treated as ordinary digits and accepted as
4209 part of numbers during parsing. In fact, the requirement in 22.4.1.1.2
4210 [locale.ctype.virtuals], p13 forbids narrow() to translate an alternate
4211 digit character, wc, to an ordinary digit in the basic source
4212 character set unless the expression
4213 (ctype<charT>::is(ctype_base::digit, wc) == true) holds. This in
4214 turn is prohibited by the C standard (7.25.2.1.5, 7.25.2.1.5, and
4215 5.2.1, respectively) for charT of either char or wchar_t.
4218 <p><i>[Sydney: To a large extent this is a nonproblem. As long as
4219 you're only trafficking in char and wchar_t we're only dealing with a
4220 stable character set, so you don't really need either 'widen' or
4221 'narrow': can just use literals. Finally, it's not even clear whether
4222 widen-vs-narrow is the right question; arguably we should be using
4223 codecvt instead.]</i></p>
4228 <p><b>Proposed resolution:</b></p>
4229 <p>Change stage 2 so that implementations are permitted to use either
4230 technique to perform the comparison:</p>
4232 <li> call widen on the atoms and compare (either by using
4233 operator== or char_traits<charT>::eq) the input with
4234 the widened atoms, or</li>
4235 <li> call narrow on the input and compare the narrow input
4237 <li> do (1) or (2) only if charT is not char or wchar_t,
4238 respectively; i.e., avoid calling widen or narrow
4239 if it the source and destination types are the same</li>
4247 <h3><a name="463"></a>463. auto_ptr usability issues</h3>
4248 <p><b>Section:</b> D.9.1 [auto.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
4249 <b>Submitter:</b> Rani Sharoni <b>Opened:</b> 2003-12-07 <b>Last modified:</b> 2007-11-15</p>
4250 <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>
4251 <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>
4252 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
4253 <p><b>Discussion:</b></p>
4256 TC1 CWG DR #84 effectively made the template<class Y> operator auto_ptr<Y>()
4257 member of auto_ptr (20.4.5.3/4) obsolete.
4261 The sole purpose of this obsolete conversion member is to enable copy
4262 initialization base from r-value derived (or any convertible types like
4265 <pre>#include <memory>
4266 using std::auto_ptr;
4271 auto_ptr<D> source();
4272 int sink(auto_ptr<B>);
4273 int x1 = sink( source() ); // #1 EDG - no suitable copy constructor
4277 The excellent analysis of conversion operations that was given in the final
4279 (http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/1997/N1128.pdf)
4280 explicitly specifies this case analysis (case 4). DR #84 makes the analysis
4281 wrong and actually comes to forbid the loophole that was exploited by the
4286 I didn't encounter any compliant compiler (e.g. EDG, GCC, BCC and VC) that
4287 ever allowed this case. This is probably because it requires 3 user defined
4288 conversions and in fact current compilers conform to DR #84.
4292 I was surprised to discover that the obsolete conversion member actually has
4293 negative impact of the copy initialization base from l-value derived
4295 <pre>auto_ptr<D> dp;
4296 int x2 = sink(dp); // #2 EDG - more than one user-defined conversion applies
4300 I'm sure that the original intention was allowing this initialization using
4301 the template<class Y> auto_ptr(auto_ptr<Y>& a) constructor (20.4.5.1/4) but
4302 since in this copy initialization it's merely user defined conversion (UDC)
4303 and the obsolete conversion member is UDC with the same rank (for the early
4304 overloading stage) there is an ambiguity between them.
4308 Removing the obsolete member will have impact on code that explicitly
4311 <pre>int y = sink(source().operator auto_ptr<B>());
4315 IMHO no one ever wrote such awkward code and the reasonable workaround for
4318 <pre>int y = sink( auto_ptr<B>(source()) );
4322 I was even more surprised to find out that after removing the obsolete
4323 conversion member the initialization was still ill-formed:
4324 int x3 = sink(dp); // #3 EDG - no suitable copy constructor
4328 This copy initialization semantically requires copy constructor which means
4329 that both template conversion constructor and the auto_ptr_ref conversion
4330 member (20.4.5.3/3) are required which is what was explicitly forbidden in
4331 DR #84. This is a bit amusing case in which removing ambiguity results with
4336 I also found exception safety issue with auto_ptr related to auto_ptr_ref:
4338 <pre>int f(auto_ptr<B>, std::string);
4339 auto_ptr<B> source2();
4341 // string constructor throws while auto_ptr_ref
4342 // "holds" the pointer
4343 int x4 = f(source2(), "xyz"); // #4
4347 The theoretic execution sequence that will cause a leak:
4350 <li>call auto_ptr<B>::operator auto_ptr_ref<B>()</li>
4351 <li>call string::string(char const*) and throw</li>
4355 According to 20.4.5.3/3 and 20.4.5/2 the auto_ptr_ref conversion member
4356 returns auto_ptr_ref<Y> that holds *this and this is another defect since
4357 the type of *this is auto_ptr<X> where X might be different from Y. Several
4358 library vendors (e.g. SGI) implement auto_ptr_ref<Y> with Y* as member which
4359 is much more reasonable. Other vendor implemented auto_ptr_ref as
4360 defectively required and it results with awkward and catastrophic code:
4361 int oops = sink(auto_ptr<B>(source())); // warning recursive on all control
4366 Dave Abrahams noticed that there is no specification saying that
4367 auto_ptr_ref copy constructor can't throw.
4371 My proposal comes to solve all the above issues and significantly simplify
4372 auto_ptr implementation. One of the fundamental requirements from auto_ptr
4373 is that it can be constructed in an intuitive manner (i.e. like ordinary
4374 pointers) but with strict ownership semantics which yield that source
4375 auto_ptr in initialization must be non-const. My idea is to add additional
4376 constructor template with sole propose to generate ill-formed, diagnostic
4377 required, instance for const auto_ptr arguments during instantiation of
4378 declaration. This special constructor will not be instantiated for other
4379 types which is achievable using 14.8.2/2 (SFINAE). Having this constructor
4380 in hand makes the constructor template<class Y> auto_ptr(auto_ptr<Y> const&)
4381 legitimate since the actual argument can't be const yet non const r-value
4386 This implementation technique makes the "private auxiliary class"
4387 auto_ptr_ref obsolete and I found out that modern C++ compilers (e.g. EDG,
4388 GCC and VC) consume the new implementation as expected and allow all
4389 intuitive initialization and assignment cases while rejecting illegal cases
4390 that involve const auto_ptr arguments.
4393 <p>The proposed auto_ptr interface:</p>
4395 <pre>namespace std {
4396 template<class X> class auto_ptr {
4398 typedef X element_type;
4400 // 20.4.5.1 construct/copy/destroy:
4401 explicit auto_ptr(X* p=0) throw();
4402 auto_ptr(auto_ptr&) throw();
4403 template<class Y> auto_ptr(auto_ptr<Y> const&) throw();
4404 auto_ptr& operator=(auto_ptr&) throw();
4405 template<class Y> auto_ptr& operator=(auto_ptr<Y>) throw();
4406 ~auto_ptr() throw();
4408 // 20.4.5.2 members:
4409 X& operator*() const throw();
4410 X* operator->() const throw();
4411 X* get() const throw();
4412 X* release() throw();
4413 void reset(X* p=0) throw();
4416 template<class U>
4417 auto_ptr(U& rhs, typename
4418 unspecified_error_on_const_auto_ptr<U>::type = 0);
4424 One compliant technique to implement the unspecified_error_on_const_auto_ptr
4425 helper class is using additional private auto_ptr member class template like
4428 <pre>template<typename T> struct unspecified_error_on_const_auto_ptr;
4430 template<typename T>
4431 struct unspecified_error_on_const_auto_ptr<auto_ptr<T> const>
4432 { typedef typename auto_ptr<T>::const_auto_ptr_is_not_allowed type; };
4436 There are other techniques to implement this helper class that might work
4437 better for different compliers (i.e. better diagnostics) and therefore I
4438 suggest defining its semantic behavior without mandating any specific
4439 implementation. IMO, and I didn't found any compiler that thinks otherwise,
4440 14.7.1/5 doesn't theoretically defeat the suggested technique but I suggest
4441 verifying this with core language experts.
4444 <p><b>Further changes in standard text:</b></p>
4445 <p>Remove section 20.4.5.3</p>
4447 <p>Change 20.4.5/2 to read something like:
4448 Initializing auto_ptr<X> from const auto_ptr<Y> will result with unspecified
4449 ill-formed declaration that will require unspecified diagnostic.</p>
4451 <p>Change 20.4.5.1/4,5,6 to read:</p>
4453 <pre>template<class Y> auto_ptr(auto_ptr<Y> const& a) throw();</pre>
4454 <p> 4 Requires: Y* can be implicitly converted to X*.</p>
4455 <p> 5 Effects: Calls const_cast<auto_ptr<Y>&>(a).release().</p>
4456 <p> 6 Postconditions: *this holds the pointer returned from a.release().</p>
4458 <p>Change 20.4.5.1/10</p>
4459 <pre>template<class Y> auto_ptr& operator=(auto_ptr<Y> a) throw();
4462 10 Requires: Y* can be implicitly converted to X*. The expression delete
4463 get() is well formed.
4466 <p>LWG TC DR #127 is obsolete.</p>
4469 Notice that the copy constructor and copy assignment operator should remain
4470 as before and accept non-const auto_ptr& since they have effect on the form
4471 of the implicitly declared copy constructor and copy assignment operator of
4472 class that contains auto_ptr as member per 12.8/5,10:
4475 // implicit X(X&)
4476 // implicit X& operator=(X&)
4477 auto_ptr<D> aptr_;
4482 In most cases this indicates about sloppy programming but preserves the
4483 current auto_ptr behavior.
4487 Dave Abrahams encouraged me to suggest fallback implementation in case that
4488 my suggestion that involves removing of auto_ptr_ref will not be accepted.
4489 In this case removing the obsolete conversion member to auto_ptr<Y> and
4490 20.4.5.3/4,5 is still required in order to eliminate ambiguity in legal
4491 cases. The two constructors that I suggested will co exist with the current
4492 members but will make auto_ptr_ref obsolete in initialization contexts.
4493 auto_ptr_ref will be effective in assignment contexts as suggested in DR
4494 #127 and I can't see any serious exception safety issues in those cases
4495 (although it's possible to synthesize such). auto_ptr_ref<X> semantics will
4496 have to be revised to say that it strictly holds pointer of type X and not
4497 reference to an auto_ptr for the favor of cases in which auto_ptr_ref<Y> is
4498 constructed from auto_ptr<X> in which X is different from Y (i.e. assignment
4499 from r-value derived to base).
4502 <p><i>[Redmond: punt for the moment. We haven't decided yet whether we
4503 want to fix auto_ptr for C++-0x, or remove it and replace it with
4504 move_ptr and unique_ptr.]</i></p>
4508 Oxford 2007: Recommend NAD. We're just going to deprecate it. It still works for simple use cases
4509 and people know how to deal with it. Going forward <tt>unique_ptr</tt> is the recommended
4515 2007-11-09: Reopened at the request of David Abrahams, Alisdair Meredith and Gabriel Dos Reis.
4521 <p><b>Proposed resolution:</b></p>
4523 Change the synopsis in D.9.1 [auto.ptr]:
4526 <blockquote><pre>namespace std {
4527 <del>template <class Y> struct auto_ptr_ref {};</del>
4529 <ins>// exposition only</ins>
4530 <ins>template <class T> struct constant_object;</ins>
4532 <ins>// exposition only</ins>
4533 <ins>template <class T></ins>
4534 <ins>struct cannot_transfer_ownership_from</ins>
4535 <ins>: constant_object<T> {};</ins>
4537 template <class X> class auto_ptr {
4539 typedef X element_type;
4541 // D.9.1.1 construct/copy/destroy:
4542 explicit auto_ptr(X* p =0) throw();
4543 auto_ptr(auto_ptr&) throw();
4544 template<class Y> auto_ptr(auto_ptr<Y><ins> const</ins>&) throw();
4545 auto_ptr& operator=(auto_ptr&) throw();
4546 template<class Y> auto_ptr& operator=(auto_ptr<Y><del>&</del>) throw();
4547 <del>auto_ptr& operator=(auto_ptr_ref<X> r) throw();</del>
4548 ~auto_ptr() throw();
4551 X& operator*() const throw();
4552 X* operator->() const throw();
4553 X* get() const throw();
4554 X* release() throw();
4555 void reset(X* p =0) throw();
4557 <del>// D.9.1.3 conversions:</del>
4558 <del>auto_ptr(auto_ptr_ref<X>) throw();</del>
4559 <del>template<class Y> operator auto_ptr_ref<Y>() throw();</del>
4560 <del>template<class Y> operator auto_ptr<Y>() throw();</del>
4562 <ins>// exposition only</ins>
4563 <ins>template<class U></ins>
4564 <ins>auto_ptr(U& rhs, typename cannot_transfer_ownership_from<U>::error = 0);</ins>
4567 template <> class auto_ptr<void>
4570 typedef void element_type;
4577 Remove D.9.1.3 [auto.ptr.conv].
4581 Change D.9.1 [auto.ptr], p3:
4585 The <tt>auto_ptr</tt> provides a semantics of strict ownership. An
4586 <tt>auto_ptr</tt> owns the object it holds a pointer to. Copying an
4587 <tt>auto_ptr</tt> copies the pointer and transfers ownership to the
4588 destination. If more than one <tt>auto_ptr</tt> owns the same object at
4589 the same time the behavior of the program is undefined. <ins>Templates
4590 <tt>constant_object</tt> and <tt>cannot_transfer_ownership_from</tt>,
4591 and the final constructor of <tt>auto_ptr</tt> are for exposition only.
4592 For any types <tt>X</tt> and <tt>Y</tt>, initializing
4593 <tt>auto_ptr<X></tt> from <tt>const auto_ptr<Y></tt> is
4594 ill-formed, diagnostic required.</ins> [<i>Note:</i> The uses of
4595 <tt>auto_ptr</tt> include providing temporary exception-safety for
4596 dynamically allocated memory, passing ownership of dynamically allocated
4597 memory to a function, and returning dynamically allocated memory from a
4598 function. <tt>auto_ptr</tt> does not meet the <tt>CopyConstructible</tt>
4599 and <tt>Assignable</tt> requirements for Standard Library container
4600 elements and thus instantiating a Standard Library container with an
4601 <tt>auto_ptr</tt> results in undefined behavior. <i>-- end note</i>]
4605 Change D.9.1.1 [auto.ptr.cons], p5:
4609 <pre>template<class Y> auto_ptr(auto_ptr<Y><ins> const</ins>& a) throw();
4613 <i>Requires:</i> <tt>Y*</tt> can be implicitly converted to <tt>X*</tt>.
4616 <i>Effects:</i> Calls <ins><tt>const_cast<auto_ptr<Y>&>(</tt></ins><tt>a</tt><ins><tt>)</tt></ins><tt>.release()</tt>.
4619 <i>Postconditions:</i> <tt>*this</tt> holds the pointer returned from <tt>a.release()</tt>.
4625 Change D.9.1.1 [auto.ptr.cons], p10:
4629 <pre>template<class Y> auto_ptr& operator=(auto_ptr<Y><del>&</del> a) throw();
4633 <i>Requires:</i> <tt>Y*</tt> can be implicitly converted to <tt>X*</tt>.
4634 The expression <tt>delete get()</tt> is well formed.
4637 <i>Effects:</i> Calls <tt>reset(a.release())</tt>.
4640 <i>Returns:</i> <tt>*this</tt>.
4651 <h3><a name="466"></a>466. basic_string ctor should prevent null pointer error</h3>
4652 <p><b>Section:</b> 21.4.1 [string.require] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
4653 <b>Submitter:</b> Daniel Frey <b>Opened:</b> 2004-06-10 <b>Last modified:</b> 2009-05-23</p>
4654 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#string.require">active issues</a> in [string.require].</p>
4655 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.require">issues</a> in [string.require].</p>
4656 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
4657 <p><b>Discussion:</b></p>
4659 Today, my colleagues and me wasted a lot of time. After some time, I
4660 found the problem. It could be reduced to the following short example:
4663 <pre> #include <string>
4664 int main() { std::string( 0 ); }
4667 <p>The problem is that the tested compilers (GCC 2.95.2, GCC 3.3.1 and
4668 Comeau online) compile the above without errors or warnings! The
4669 programs (at least for the GCC) resulted in a SEGV.</p>
4671 <p>I know that the standard explicitly states that the ctor of string
4672 requires a char* which is not zero. STLs could easily detect the above
4673 case with a private ctor for basic_string which takes a single 'int'
4674 argument. This would catch the above code at compile time and would not
4675 ambiguate any other legal ctors.</p>
4677 <p><i>[Redmond: No great enthusiasm for doing this. If we do,
4678 however, we want to do it for all places that take <tt>charT*</tt>
4679 pointers, not just the single-argument constructor. The other
4680 question is whether we want to catch this at compile time (in which
4681 case we catch the error of a literal 0, but not an expression whose
4682 value is a null pointer), at run time, or both.
4683 Recommend NAD. Relegate this functionality to debugging implementations.]</i></p>
4687 Post Summit: Alisdair requests this be re-opened as several new language facilities are
4688 designed to solve exactly this kind of problem.
4697 We are unable to achieve consensus on an approach to a resolution.
4698 There is some sentiment for treating this as a QOI matter.
4700 that when <tt>string</tt> is brought into the concepts world,
4701 this issue might be addressed in that context.
4705 <p><b>Proposed resolution:</b></p>
4707 Add to the synopsis in 21.4 [basic.string]
4710 <blockquote><pre><ins>basic_string( nullptr_t ) = delete;</ins>
4718 <h3><a name="471"></a>471. result of what() implementation-defined</h3>
4719 <p><b>Section:</b> 18.7.1 [type.info] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
4720 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2004-06-28 <b>Last modified:</b> 2009-05-23</p>
4721 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#type.info">issues</a> in [type.info].</p>
4722 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
4723 <p><b>Discussion:</b></p>
4725 <p>[lib.exception] specifies the following:</p>
4726 <pre> exception (const exception&) throw();
4727 exception& operator= (const exception&) throw();
4729 -4- Effects: Copies an exception object.
4730 -5- Notes: The effects of calling what() after assignment
4731 are implementation-defined.
4735 First, does the Note only apply to the assignment operator? If so,
4736 what are the effects of calling what() on a copy of an object? Is
4737 the returned pointer supposed to point to an identical copy of
4738 the NTBS returned by what() called on the original object or not?
4742 Second, is this Note intended to extend to all the derived classes
4743 in section 19? I.e., does the standard provide any guarantee for
4744 the effects of what() called on a copy of any of the derived class
4745 described in section 19?
4749 Finally, if the answer to the first question is no, I believe it
4750 constitutes a defect since throwing an exception object typically
4751 implies invoking the copy ctor on the object. If the answer is yes,
4752 then I believe the standard ought to be clarified to spell out
4753 exactly what the effects are on the copy (i.e., after the copy
4757 <p><i>[Redmond: Yes, this is fuzzy. The issue of derived classes is
4762 Batavia: Howard provided wording.
4773 Eric concerned this is unimplementable, due to nothrow guarantees.
4774 Suggested implementation would involve reference counting.
4777 Is the implied reference counting subtle enough to call out a note on
4778 implementation? Probably not.
4781 If reference counting required, could we tighten specification further
4782 to require same pointer value? Probably an overspecification, especially
4783 if exception classes defer evalutation of final string to calls to
4787 Remember issue moved open and not resolved at Batavia, but cannot
4788 remember who objected to canvas a disenting opinion - please speak up if
4789 you disagree while reading these minutes!
4792 Move to Ready as we are accepting words unmodified.
4802 The issue was pulled from Ready. It needs to make clear that only homogenous copying
4803 is intended to be supported, not coping from a derived to a base.
4812 Howard supplied the following replacement wording
4813 for paragraph 7 of the proposed resolution:
4816 <ins>-7- <i>Postcondition:</i> <tt>what()</tt> shall return the same NTBS
4817 as would be obtained by using <tt>static_cast</tt>
4818 to cast the rhs to the same types as the lhs
4819 and then calling <tt>what()</tt> on that possibly sliced object.</ins>
4822 Pete asks what "the same NTBS" means.
4827 <p><b>Proposed resolution:</b></p>
4830 Change 18.8.1 [exception] to:
4834 <pre>exception(const exception& <ins><i>e</i></ins>) throw();
4835 exception& operator=(const exception& <ins><i>e</i></ins>) throw();</pre>
4838 -4- <i>Effects:</i> Copies an exception object.
4841 <del> -5- <i>Remarks:</i> The effects of calling what() after assignment are implementation-defined.</del>
4844 <ins>-5- <i>Throws:</i> Nothing. This also applies
4845 to all standard library-defined classes that derive from <tt>exception</tt>.</ins>
4848 <ins>-7- <i>Postcondition:</i> <tt>strcmp(what(), <i>e</i>.what()) == 0</tt>. This also applies
4849 to all standard library-defined classes that derive from <tt>exception</tt>.</ins>
4859 <h3><a name="473"></a>473. underspecified ctype calls</h3>
4860 <p><b>Section:</b> 22.4.1.1 [locale.ctype] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
4861 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2004-07-01 <b>Last modified:</b> 2006-12-27</p>
4862 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
4863 <p><b>Discussion:</b></p>
4865 Most ctype member functions come in two forms: one that operates
4866 on a single character at a time and another form that operates
4867 on a range of characters. Both forms are typically described by
4868 a single Effects and/or Returns clause.
4871 The Returns clause of each of the single-character non-virtual forms
4872 suggests that the function calls the corresponding single character
4873 virtual function, and that the array form calls the corresponding
4874 virtual array form. Neither of the two forms of each virtual member
4875 function is required to be implemented in terms of the other.
4878 There are three problems:
4881 1. One is that while the standard does suggest that each non-virtual
4882 member function calls the corresponding form of the virtual function,
4883 it doesn't actually explicitly require it.
4886 Implementations that cache results from some of the virtual member
4887 functions for some or all values of their arguments might want to
4888 call the array form from the non-array form the first time to fill
4889 the cache and avoid any or most subsequent virtual calls. Programs
4890 that rely on each form of the virtual function being called from
4891 the corresponding non-virtual function will see unexpected behavior
4892 when using such implementations.
4895 2. The second problem is that either form of each of the virtual
4896 functions can be overridden by a user-defined function in a derived
4897 class to return a value that is different from the one produced by
4898 the virtual function of the alternate form that has not been
4902 Thus, it might be possible for, say, ctype::widen(c) to return one
4903 value, while for ctype::widen(&c, &c + 1, &wc) to set
4904 wc to another value. This is almost certainly not intended. Both
4905 forms of every function should be required to return the same result
4906 for the same character, otherwise the same program using an
4907 implementation that calls one form of the functions will behave
4908 differently than when using another implementation that calls the
4909 other form of the function "under the hood."
4912 3. The last problem is that the standard text fails to specify whether
4913 one form of any of the virtual functions is permitted to be implemented
4914 in terms of the other form or not, and if so, whether it is required
4915 or permitted to call the overridden virtual function or not.
4918 Thus, a program that overrides one of the virtual functions so that
4919 it calls the other form which then calls the base member might end
4920 up in an infinite loop if the called form of the base implementation
4921 of the function in turn calls the other form.
4924 Lillehammer: Part of this isn't a real problem. We already talk about
4925 caching. 22.1.1/6 But part is a real problem. ctype virtuals may call
4926 each other, so users don't know which ones to override to avoid avoid
4929 <p>This is a problem for all facet virtuals, not just ctype virtuals,
4930 so we probably want a blanket statement in clause 22 for all
4931 facets. The LWG is leaning toward a blanket prohibition, that a
4932 facet's virtuals may never call each other. We might want to do that
4933 in clause 27 too, for that matter. A review is necessary. Bill will
4934 provide wording.</p>
4937 <p><b>Proposed resolution:</b></p>
4943 <h3><a name="485"></a>485. output iterator insufficently constrained</h3>
4944 <p><b>Section:</b> 24.2.3 [output.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
4945 <b>Submitter:</b> Chris Jefferson <b>Opened:</b> 2004-10-13 <b>Last modified:</b> 2006-12-27</p>
4946 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#output.iterators">issues</a> in [output.iterators].</p>
4947 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
4948 <p><b>Discussion:</b></p>
4950 The note on 24.1.2 Output iterators insufficently limits what can be
4951 performed on output iterators. While it requires that each iterator is
4952 progressed through only once and that each iterator is written to only
4953 once, it does not require the following things:</p>
4955 <p>Note: Here it is assumed that x is an output iterator of type X which
4956 has not yet been assigned to.</p>
4958 <p>a) That each value of the output iterator is written to:
4959 The standard allows:
4964 b) That assignments to the output iterator are made in order
4965 X a(x); ++a; *a=1; *x=2; is allowed
4969 c) Chains of output iterators cannot be constructed:
4970 X a(x); ++a; X b(a); ++b; X c(b); ++c; is allowed, and under the current
4971 wording (I believe) x,a,b,c could be written to in any order.
4974 <p>I do not believe this was the intension of the standard?</p>
4975 <p><i>[Lillehammer: Real issue. There are lots of constraints we
4976 intended but didn't specify. Should be solved as part of iterator
4981 <p><b>Proposed resolution:</b></p>
4988 <h3><a name="492"></a>492. Invalid iterator arithmetic expressions</h3>
4989 <p><b>Section:</b> 17.5.1.4 [structure.specifications] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
4990 <b>Submitter:</b> Thomas Mang <b>Opened:</b> 2004-12-12 <b>Last modified:</b> 2009-05-10</p>
4991 <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>
4992 <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>
4993 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
4994 <p><b>Discussion:</b></p>
4995 <p>Various clauses other than clause 25 make use of iterator arithmetic not
4996 supported by the iterator category in question.
4997 Algorithms in clause 25 are exceptional because of 25 [lib.algorithms],
4998 paragraph 9, but this paragraph does not provide semantics to the
4999 expression "iterator - n", where n denotes a value of a distance type
5000 between iterators.</p>
5002 <p>1) Examples of current wording:</p>
5004 <p>Current wording outside clause 25:</p>
5007 23.2.2.4 [lib.list.ops], paragraphs 19-21: "first + 1", "(i - 1)",
5009 23.3.1.1 [lib.map.cons], paragraph 4: "last - first"
5010 23.3.2.1 [lib.multimap.cons], paragraph 4: "last - first"
5011 23.3.3.1 [lib.set.cons], paragraph 4: "last - first"
5012 23.3.4.1 [lib.multiset.cons], paragraph 4: "last - first"
5013 24.4.1 [lib.reverse.iterators], paragraph 1: "(i - 1)"
5017 [Important note: The list is not complete, just an illustration. The
5018 same issue might well apply to other paragraphs not listed here.]</p>
5020 <p>None of these expressions is valid for the corresponding iterator
5023 <p>Current wording in clause 25:</p>
5026 25.1.1 [lib.alg.foreach], paragraph 1: "last - 1"
5027 25.1.3 [lib.alg.find.end], paragraph 2: "[first1, last1 -
5029 25.2.8 [lib.alg.unique], paragraph 1: "(i - 1)"
5030 25.2.8 [lib.alg.unique], paragraph 5: "(i - 1)"
5034 However, current wording of 25 [lib.algorithms], paragraph 9 covers
5035 neither of these four cases:</p>
5037 <p>Current wording of 25 [lib.algorithms], paragraph 9:</p>
5040 "In the description of the algorithms operator + and - are used for some
5041 of the iterator categories for which they do not have to be defined. In
5042 these cases the semantics of a+n is the same as that of</p>
5048 <p>and that of b-a is the same as of return distance(a, b)"</p>
5051 This paragrpah does not take the expression "iterator - n" into account,
5052 where n denotes a value of a distance type between two iterators [Note:
5053 According to current wording, the expression "iterator - n" would be
5054 resolved as equivalent to "return distance(n, iterator)"]. Even if the
5055 expression "iterator - n" were to be reinterpreted as equivalent to
5056 "iterator + -n" [Note: This would imply that "a" and "b" were
5057 interpreted implicitly as values of iterator types, and "n" as value of
5058 a distance type], then 24.3.4/2 interfers because it says: "Requires: n
5059 may be negative only for random access and bidirectional iterators.",
5060 and none of the paragraphs quoted above requires the iterators on which
5061 the algorithms operate to be of random access or bidirectional category.
5064 <p>2) Description of intended behavior:</p>
5067 For the rest of this Defect Report, it is assumed that the expression
5068 "iterator1 + n" and "iterator1 - iterator2" has the semantics as
5069 described in current 25 [lib.algorithms], paragraph 9, but applying to
5070 all clauses. The expression "iterator1 - n" is equivalent to an
5071 result-iterator for which the expression "result-iterator + n" yields an
5072 iterator denoting the same position as iterator1 does. The terms
5073 "iterator1", "iterator2" and "result-iterator" shall denote the value of
5074 an iterator type, and the term "n" shall denote a value of a distance
5075 type between two iterators.</p>
5078 All implementations known to the author of this Defect Report comply
5079 with these assumptions.
5080 No impact on current code is expected.</p>
5082 <p>3) Proposed fixes:</p>
5085 <p>Change 25 [lib.algorithms], paragraph 9 to:</p>
5088 "In the description of the algorithms operator + and - are used for some
5089 of the iterator categories for which they do not have to be defined. In
5090 this paragraph, a and b denote values of an iterator type, and n denotes
5091 a value of a distance type between two iterators. In these cases the
5092 semantics of a+n is the same as that of</p>
5098 <p>,the semantics of a-n denotes the value of an iterator i for which the
5099 following condition holds:
5101 and that of b-a is the same as of
5102 return distance(a, b)".
5105 <p>Comments to the new wording:</p>
5108 a) The wording " In this paragraph, a and b denote values of an iterator
5109 type, and n denotes a value of a distance type between two iterators."
5110 was added so the expressions "b-a" and "a-n" are distinguished regarding
5111 the types of the values on which they operate.
5112 b) The wording ",the semantics of a-n denotes the value of an iterator i
5113 for which the following condition holds: advance(i, n) == a" was added
5114 to cover the expression 'iterator - n'. The wording "advance(i, n) == a"
5115 was used to avoid a dependency on the semantics of a+n, as the wording
5116 "i + n == a" would have implied. However, such a dependency might well
5118 c) DR 225 is not considered in the new wording.
5122 Proposed fixes regarding invalid iterator arithmetic expressions outside
5127 a) Move modified 25 [lib.algorithms], paragraph 9 (as proposed above)
5128 before any current invalid iterator arithmetic expression. In that case,
5129 the first sentence of 25 [lib.algorithms], paragraph 9, need also to be
5130 modified and could read: "For the rest of this International Standard,
5131 ...." / "In the description of the following clauses including this
5132 ...." / "In the description of the text below ..." etc. - anyways
5133 substituting the wording "algorithms", which is a straight reference to
5135 In that case, 25 [lib.algorithms] paragraph 9 will certainly become
5138 b) Add an appropiate paragraph similar to resolved 25 [lib.algorithms],
5139 paragraph 9, to the beginning of each clause containing invalid iterator
5140 arithmetic expressions.
5142 c) Fix each paragraph (both current wording and possible resolutions of
5143 DRs) containing invalid iterator arithmetic expressions separately.
5146 <p>5) References to other DRs:</p>
5150 See DR 237. The resolution could then also read "Linear in last -
5160 Keep open and ask Bill to provide wording.
5164 2009-05-09 Alisdair adds:
5169 This issue is related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#997">997</a>.
5174 <p><b>Proposed resolution:</b></p>
5176 <p><i>[Lillehammer: Minor issue, but real. We have a blanket statement
5177 about this in 25/11. But (a) it should be in 17, not 25; and (b) it's
5178 not quite broad enough, because there are some arithmetic expressions
5179 it doesn't cover. Bill will provide wording.]</i></p>
5188 <h3><a name="498"></a>498. Requirements for partition() and stable_partition() too strong</h3>
5189 <p><b>Section:</b> 25.4.13 [alg.partitions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
5190 <b>Submitter:</b> Sean Parent, Joe Gottman <b>Opened:</b> 2005-05-04 <b>Last modified:</b> 2009-05-01</p>
5191 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
5192 <p><b>Discussion:</b></p>
5195 The iterator requirements for partition() and stable_partition() [25.2.12]
5196 are listed as BidirectionalIterator, however, there are efficient algorithms
5197 for these functions that only require ForwardIterator that have been known
5198 since before the standard existed. The SGI implementation includes these (see
5199 <a href="http://www.sgi.com/tech/stl/partition.html">http://www.sgi.com/tech/stl/partition.html</a>
5201 <a href="http://www.sgi.com/tech/stl/stable_partition.html">http://www.sgi.com/tech/stl/stable_partition.html</a>).
5205 2009-04-30 Alisdair adds:
5211 Now we have concepts this is easier to express!
5214 Proposed resolution:
5217 Add the following signature to:
5220 Header <tt><algorithm></tt> synopsis 25.2 [algorithms.syn]<br>
5221 p3 Partitions 25.4.13 [alg.partitions]
5223 <blockquote><pre> template<ForwardIterator Iter, Predicate<auto, Iter::value_type> Pred>
5224 requires ShuffleIterator<Iter>
5225 && CopyConstructible<Pred>
5226 Iter partition(Iter first, Iter last, Pred pred);
5230 Update p3 Partitions 25.4.13 [alg.partitions]:
5235 <i>Complexity:</i> <del>At most <tt>(last - first)/2</tt> swaps. Exactly <tt>last - first</tt>
5236 applications of the predicate
5239 If <tt>Iter</tt> satisfies <tt>BidirectionalIterator</tt>, at most <tt>(last -
5240 first)/2</tt> swaps. Exactly <tt>last - first</tt> applications of the predicate
5245 If <tt>Iter</tt> merely satisfied <tt>ForwardIterator</tt> at most <tt>(last - first)</tt> swaps
5246 are done. Exactly <tt>(last - first)</tt> applications of the predicate are done.
5251 [Editorial note: I looked for existing precedent in how we might call out
5252 distinct overloads overloads from a set of constrained templates, but there
5253 is not much existing practice to lean on. advance/distance were the only
5254 algorithms I could find, and that wording is no clearer.]
5261 <p><b>Proposed resolution:</b></p>
5263 Change 25.2.12 from </p>
5264 <blockquote><pre>template<class BidirectionalIterator, class Predicate>
5265 BidirectionalIterator partition(BidirectionalIterato r first,
5266 BidirectionalIterator last,
5270 <blockquote><pre>template<class ForwardIterator, class Predicate>
5271 ForwardIterator partition(ForwardIterator first,
5272 ForwardIterator last,
5275 <p>Change the complexity from </p>
5278 At most (last - first)/2 swaps are done. Exactly (last - first)
5279 applications of the predicate are done.
5285 If ForwardIterator is a bidirectional_iterator, at most (last - first)/2
5286 swaps are done; otherwise at most (last - first) swaps are done. Exactly
5287 (last - first) applications of the predicate are done.
5292 <p><b>Rationale:</b></p>
5294 Partition is a "foundation" algorithm useful in many contexts (like sorting
5295 as just one example) - my motivation for extending it to include forward
5296 iterators is foward_list - without this extension you can't partition an foward_list
5297 (without writing your own partition). Holes like this in the standard
5298 library weaken the argument for generic programming (ideally I'd be able
5299 to provide a library that would refine std::partition() to other concepts
5300 without fear of conflicting with other libraries doing the same - but
5301 that is a digression). I consider the fact that partition isn't defined
5302 to work for ForwardIterator a minor embarrassment.
5305 <p><i>[Mont Tremblant: Moved to Open, request motivation and use cases
5306 by next meeting. Sean provided further rationale by post-meeting
5316 <h3><a name="502"></a>502. Proposition: Clarification of the interaction between a facet and an iterator</h3>
5317 <p><b>Section:</b> 22.3.1.1.1 [locale.category] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
5318 <b>Submitter:</b> Christopher Conrade Zseleghovski <b>Opened:</b> 2005-06-07 <b>Last modified:</b> 2008-03-13</p>
5319 <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>
5320 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
5321 <p><b>Discussion:</b></p>
5327 This requirement seems obvious to me, it is the essence of code modularity.
5328 I have complained to Mr. Plauger that the Dinkumware library does not
5329 observe this principle but he objected that this behaviour is not covered in
5334 <p><b>Proposed resolution:</b></p>
5336 Append the following point to 22.1.1.1.1:
5340 6. The implementation of a facet of Table 52 parametrized with an
5341 InputIterator/OutputIterator should use that iterator only as character
5342 source/sink respectively.
5343 For a *_get facet, it means that the value received depends only on the
5344 sequence of input characters and not on how they are accessed.
5345 For a *_put facet, it means that the sequence of characters output depends
5346 only on the value to be formatted and not of how the characters are stored.
5350 Berlin: Moved to Open, Need to clean up this area to make it clear
5351 locales don't have to contain open ended sets of facets. Jack, Howard,
5362 <h3><a name="503"></a>503. more on locales</h3>
5363 <p><b>Section:</b> 22.4 [locale.categories] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
5364 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2005-06-20 <b>Last modified:</b> 2008-03-13</p>
5365 <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>
5366 <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>
5367 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
5368 <p><b>Discussion:</b></p>
5370 a) In 22.2.1.1 para. 2 we refer to "the instantiations required in Table
5371 51" to refer to the facet *objects* associated with a locale. And we
5372 almost certainly mean just those associated with the default or "C"
5373 locale. Otherwise, you can't switch to a locale that enforces a different
5374 mapping between narrow and wide characters, or that defines additional
5375 uppercase characters.
5379 b) 22.2.1.5 para. 3 (codecvt) has the same issues.
5383 c) 22.2.1.5.2 (do_unshift) is even worse. It *forbids* the generation of
5384 a homing sequence for the basic character set, which might very well need
5389 d) 22.2.1.5.2 (do_length) likewise dictates that the default mapping
5390 between wide and narrow characters be taken as one-for-one.
5394 e) 22.2.2 para. 2 (num_get/put) is both muddled and vacuous, as far as
5395 I can tell. The muddle is, as before, calling Table 51 a list of
5396 instantiations. But the constraint it applies seems to me to cover
5397 *all* defined uses of num_get/put, so why bother to say so?
5401 f) 22.2.3.1.2 para. 1(do_decimal_point) says "The required instantiations
5402 return '.' or L'.'.) Presumably this means "as appropriate for the
5403 character type. But given the vague definition of "required" earlier,
5404 this overrules *any* change of decimal point for non "C" locales.
5405 Surely we don't want to do that.
5409 g) 22.2.3.1.2 para. 2 (do_thousands_sep) says "The required instantiations
5410 return ',' or L','.) As above, this probably means "as appropriate for the
5411 character type. But this overrules the "C" locale, which requires *no*
5412 character ('\0') for the thousands separator. Even if we agree that we
5413 don't mean to block changes in decimal point or thousands separator,
5414 we should also eliminate this clear incompatibility with C.
5418 h) 22.2.3.1.2 para. 2 (do_grouping) says "The required instantiations
5419 return the empty string, indicating no grouping." Same considerations
5420 as for do_decimal_point.
5424 i) 22.2.4.1 para. 1 (collate) refers to "instantiations required in Table
5425 51". Same bad jargon.
5429 j) 22.2.4.1.2 para. 1 (do_compare) refers to "instantiations required
5430 in Table 51". Same bad jargon.
5434 k) 22.2.5 para. 1 (time_get/put) uses the same muddled and vacuous
5439 l) 22.2.6 para. 2 (money_get/put) uses the same muddled and vacuous
5444 m) 22.2.6.3.2 (do_pos/neg_format) says "The instantiations required
5445 in Table 51 ... return an object of type pattern initialized to
5446 {symbol, sign, none, value}." This once again *overrides* the "C"
5447 locale, as well as any other locale."
5451 3) We constrain the use_facet calls that can be made by num_get/put,
5452 so why don't we do the same for money_get/put? Or for any of the
5453 other facets, for that matter?
5457 4) As an almost aside, we spell out when a facet needs to use the ctype
5458 facet, but several also need to use a codecvt facet and we don't say so.
5461 Berlin: Bill to provide wording.
5466 <p><b>Proposed resolution:</b></p>
5475 <h3><a name="523"></a>523. regex case-insensitive character ranges are unimplementable as specified</h3>
5476 <p><b>Section:</b> 28 [re] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
5477 <b>Submitter:</b> Eric Niebler <b>Opened:</b> 2005-07-01 <b>Last modified:</b> 2008-03-13</p>
5478 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#re">active issues</a> in [re].</p>
5479 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re">issues</a> in [re].</p>
5480 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
5481 <p><b>Discussion:</b></p>
5483 A problem with TR1 regex is currently being discussed on the Boost
5484 developers list. It involves the handling of case-insensitive matching
5485 of character ranges such as [Z-a]. The proper behavior (according to the
5486 ECMAScript standard) is unimplementable given the current specification
5487 of the TR1 regex_traits<> class template. John Maddock, the author of
5488 the TR1 regex proposal, agrees there is a problem. The full discussion
5489 can be found at http://lists.boost.org/boost/2005/06/28850.php (first
5490 message copied below). We don't have any recommendations as yet.
5493 -- Begin original message --
5496 The situation of interest is described in the ECMAScript specification
5497 (ECMA-262), section 15.10.2.15:
5500 "Even if the pattern ignores case, the case of the two ends of a range
5501 is significant in determining which characters belong to the range.
5502 Thus, for example, the pattern /[E-F]/i matches only the letters E, F,
5503 e, and f, while the pattern /[E-f]/i matches all upper and lower-case
5504 ASCII letters as well as the symbols [, \, ], ^, _, and `."
5507 A more interesting case is what should happen when doing a
5508 case-insentitive match on a range such as [Z-a]. It should match z, Z,
5509 a, A and the symbols [, \, ], ^, _, and `. This is not what happens with
5510 Boost.Regex (it throws an exception from the regex constructor).
5513 The tough pill to swallow is that, given the specification in TR1, I
5514 don't think there is any effective way to handle this situation.
5515 According to the spec, case-insensitivity is handled with
5516 regex_traits<>::translate_nocase(CharT) -- two characters are equivalent
5517 if they compare equal after both are sent through the translate_nocase
5518 function. But I don't see any way of using this translation function to
5519 make character ranges case-insensitive. Consider the difficulty of
5520 detecting whether "z" is in the range [Z-a]. Applying the transformation
5521 to "z" has no effect (it is essentially std::tolower). And we're not
5522 allowed to apply the transformation to the ends of the range, because as
5523 ECMA-262 says, "the case of the two ends of a range is significant."
5526 So AFAICT, TR1 regex is just broken, as is Boost.Regex. One possible fix
5527 is to redefine translate_nocase to return a string_type containing all
5528 the characters that should compare equal to the specified character. But
5529 this function is hard to implement for Unicode, and it doesn't play nice
5530 with the existing ctype facet. What a mess!
5533 -- End original message --
5542 One small correction, I have since found that ICU's regex package does
5543 implement this correctly, using a similar mechanism to the current
5547 Given an expression [c1-c2] that is compiled as case insensitive it:
5550 Enumerates every character in the range c1 to c2 and converts it to it's
5551 case folded equivalent. That case folded character is then used a key to a
5552 table of equivalence classes, and each member of the class is added to the
5553 list of possible matches supported by the character-class. This second step
5554 isn't possible with our current traits class design, but isn't necessary if
5555 the input text is also converted to a case-folded equivalent on the fly.
5558 ICU applies similar brute force mechanisms to character classes such as
5559 [[:lower:]] and [[:word:]], however these are at least cached, so the impact
5560 is less noticeable in this case.
5563 Quick and dirty performance comparisons show that expressions such as
5564 "[X-\\x{fff0}]+" are indeed very slow to compile with ICU (about 200 times
5565 slower than a "normal" expression). For an application that uses a lot of
5566 regexes this could have a noticeable performance impact. ICU also has an
5567 advantage in that it knows the range of valid characters codes: code points
5568 outside that range are assumed not to require enumeration, as they can not
5569 be part of any equivalence class. I presume that if we want the TR1.Regex
5570 to work with arbitrarily large character sets enumeration really does become
5574 Finally note that Unicode has:
5577 Three cases (upper, lower and title).
5578 One to many, and many to one case transformations.
5579 Character that have context sensitive case translations - for example an
5580 uppercase sigma has two different lowercase forms - the form chosen depends
5581 on context(is it end of a word or not), a caseless match for an upper case
5582 sigma should match either of the lower case forms, which is why case folding
5583 is often approximated by tolower(toupper(c)).
5586 Probably we need some way to enumerate character equivalence classes,
5587 including digraphs (either as a result or an input), and some way to tell
5588 whether the next character pair is a valid digraph in the current locale.
5591 Hoping this doesn't make this even more complex that it was already,
5595 Portland: Alisdair: Detect as invalid, throw an exception.
5596 Pete: Possible general problem with case insensitive ranges.
5602 <p><b>Proposed resolution:</b></p>
5609 <h3><a name="539"></a>539. partial_sum and adjacent_difference should mention requirements</h3>
5610 <p><b>Section:</b> 26.7.3 [partial.sum] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
5611 <b>Submitter:</b> Marc Schoolderman <b>Opened:</b> 2006-02-06 <b>Last modified:</b> 2009-05-10</p>
5612 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
5613 <p><b>Discussion:</b></p>
5615 There are some problems in the definition of partial_sum and
5616 adjacent_difference in 26.4 [lib.numeric.ops]
5620 Unlike <tt>accumulate</tt> and <tt>inner_product</tt>, these functions are not
5621 parametrized on a "type T", instead, 26.4.3 [lib.partial.sum] simply
5622 specifies the effects clause as;
5626 Assigns to every element referred to by iterator <tt>i</tt> in the range
5627 <tt>[result,result + (last - first))</tt> a value correspondingly equal to
5629 <blockquote><pre>((...(* first + *( first + 1)) + ...) + *( first + ( i - result )))
5634 And similarly for BinaryOperation. Using just this definition, it seems
5635 logical to expect that:
5639 <blockquote><pre>char i_array[4] = { 100, 100, 100, 100 };
5642 std::partial_sum(i_array, i_array+4, o_array);
5649 <blockquote><pre>int o_array[4] = { 100, 100+100, 100+100+100, 100+100+100+100 };
5653 i.e. 100, 200, 300, 400, with addition happening in the <tt>result type</tt>,
5658 Yet all implementations I have tested produce 100, -56, 44, -112,
5659 because they are using an accumulator of the <tt>InputIterator</tt>'s
5660 <tt>value_type</tt>, which in this case is <tt>char</tt>, not <tt>int</tt>.
5664 The issue becomes more noticeable when the result of the expression <tt>*i +
5665 *(i+1)</tt> or <tt>binary_op(*i, *i-1)</tt> can't be converted to the
5666 <tt>value_type</tt>. In a contrived example:
5669 <blockquote><pre>enum not_int { x = 1, y = 2 };
5671 not_int e_array[4] = { x, x, y, y };
5672 std::partial_sum(e_array, e_array+4, o_array);
5676 Is it the intent that the operations happen in the <tt>input type</tt>, or in
5677 the <tt>result type</tt>?
5681 If the intent is that operations happen in the <tt>result type</tt>, something
5682 like this should be added to the "Requires" clause of 26.4.3/4
5687 The type of <tt>*i + *(i+1)</tt> or <tt>binary_op(*i, *(i+1))</tt> shall meet the
5688 requirements of <tt>CopyConstructible</tt> (20.1.3) and <tt>Assignable</tt>
5693 (As also required for <tt>T</tt> in 26.4.1 [lib.accumulate] and 26.4.2
5694 [lib.inner.product].)
5698 The "auto initializer" feature proposed in
5699 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1894.pdf">N1894</a>
5701 implement <tt>partial_sum</tt> this way. The 'narrowing' behaviour can still be
5702 obtained by using the <tt>std::plus<></tt> function object.
5706 If the intent is that operations happen in the <tt>input type</tt>, then
5707 something like this should be added instead;
5711 The type of *first shall meet the requirements of
5712 <tt>CopyConstructible</tt> (20.1.3) and <tt>Assignable</tt> (23.1) types.
5713 The result of <tt>*i + *(i+1)</tt> or <tt>binary_op(*i, *(i+1))</tt> shall be
5714 convertible to this type.
5718 The 'widening' behaviour can then be obtained by writing a custom proxy
5719 iterator, which is somewhat involved.
5723 In both cases, the semantics should probably be clarified.
5727 26.4.4 [lib.adjacent.difference] is similarly underspecified, although
5728 all implementations seem to perform operations in the 'result' type:
5731 <blockquote><pre>unsigned char i_array[4] = { 4, 3, 2, 1 };
5734 std::adjacent_difference(i_array, i_array+4, o_array);
5738 o_array is 4, -1, -1, -1 as expected, not 4, 255, 255, 255.
5742 In any case, <tt>adjacent_difference</tt> doesn't mention the requirements on the
5743 <tt>value_type</tt>; it can be brought in line with the rest of 26.4
5744 [lib.numeric.ops] by adding the following to 26.4.4/2
5745 [lib.adjacent.difference]:
5749 The type of <tt>*first</tt> shall meet the requirements of
5750 <tt>CopyConstructible</tt> (20.1.3) and <tt>Assignable</tt> (23.1) types."
5753 Berlin: Giving output iterator's value_types very controversial. Suggestion of
5754 adding signatures to allow user to specify "accumulator".
5764 The intent of the algorithms is to perform their calculations using the type of the input iterator.
5765 Proposed wording provided.
5774 We did not agree that the proposed resolution was correct. For example,
5775 when the arguments are types <tt>(float*, float*, double*)</tt>, the
5776 highest-quality solution would use double as the type of the
5777 accumulator. If the intent of the wording is to require that the type of
5778 the accumulator must be the <tt>input_iterator</tt>'s <tt>value_type</tt>, the wording
5783 2009-05-09 Alisdair adds:
5789 Now that we have the facility, the 'best' accumulator type could probably be
5792 <blockquote><pre>std::common_type<InIter::value_type, OutIter::reference>::type
5795 This type would then have additional requirements of constructability and
5796 incrementability/assignability.
5799 If this extracting an accumulator type from a pair/set of iterators (with
5800 additional requirements on that type) is a problem for multiple functions,
5801 it might be worth extracting into a SharedAccumulator concept or similar.
5804 I'll go no further in writing up wording now, until the group gives a
5805 clearer indication of preferred direction.
5811 <p><b>Proposed resolution:</b></p>
5813 Add to section 26.7.3 [partial.sum] paragraph 4 the following two sentences:
5817 The type of <tt>*first</tt> shall meet the requirements of <tt>CopyConstructible</tt>?
5818 (20.1.3?) and <tt>Assignable</tt> (23.1?) types. The result of <tt>*i + *(i+1)</tt> or
5819 <tt>binary_op(*i, *(i+1))</tt> shall be convertible to this type.
5823 Add to section 26.7.4 [adjacent.difference] paragraph 2 the following sentence:
5827 The type of <tt>*first</tt> shall meet the requirements of <tt>CopyConstructible</tt>?
5828 (20.1.3) and <tt>Assignable</tt> (23.1) types.
5837 <h3><a name="546"></a>546. _Longlong and _ULonglong are integer types</h3>
5838 <p><b>Section:</b> TR1 5.1.1 [tr.rand.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
5839 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2006-01-10 <b>Last modified:</b> 2007-10-09</p>
5840 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
5841 <p><b>Discussion:</b></p>
5843 The TR sneaks in two new integer types, _Longlong and _Ulonglong, in [tr.c99].
5844 The rest of the TR should use that type. I believe this affects two places.
5845 First, the random number requirements, 5.1.1/10-11, lists all of the types with
5846 which template parameters named IntType and UIntType may be instantiated.
5847 _Longlong (or "long long", assuming it is added to C++0x) should be added to the
5848 IntType list, and UIntType (again, or "unsigned long long") should be added to
5849 the UIntType list. Second, 6.3.2 lists the types for which hash<> is
5850 required to be instantiable. _Longlong and _Ulonglong should be added to that
5851 list, so that people may use long long as a hash key.
5855 <p><b>Proposed resolution:</b></p>
5864 <h3><a name="564"></a>564. stringbuf seekpos underspecified</h3>
5865 <p><b>Section:</b> 27.8.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
5866 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-02-23 <b>Last modified:</b> 2007-10-10</p>
5867 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#stringbuf.virtuals">issues</a> in [stringbuf.virtuals].</p>
5868 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
5869 <p><b>Discussion:</b></p>
5871 The effects of the <code>seekpos()</code> member function of
5872 <code>basic_stringbuf</code> simply say that the function positions
5873 the input and/or output sequences but fail to spell out exactly
5874 how. This is in contrast to the detail in which <code>seekoff()</code>
5879 <p><b>Proposed resolution:</b></p>
5882 Change 27.7.1.3, p13 to read:
5887 -13- <i>Effects:</i> <ins>Same as <tt>seekoff(off_type(<i>sp</i>), ios_base::beg,
5888 <i>which</i>)</tt>.</ins> <del>Alters the stream position within the controlled sequences,
5889 if possible, to correspond to the stream position stored in <tt><i>sp</i></tt>
5890 (as described below).</del>
5893 <li><del>If <tt>(<i>which</i> & ios_base::in) != 0</tt>, positions the input sequence.</del></li>
5894 <li><del>If <tt>(<i>which</i> & ios_base::out) != 0</tt>, positions the output sequence.</del></li>
5895 <li><del>If <tt><i>sp</i></tt> is an invalid stream position, or if the function
5896 positions neither sequence, the positioning operation fails. If <tt><i>sp</i></tt>
5897 has not been obtained by a previous successful call to one of the positioning
5898 functions (<tt>seekoff</tt>, <tt>seekpos</tt>, <tt>tellg</tt>, <tt>tellp</tt>)
5899 the effect is undefined.</del></li>
5905 Kona (2007): A <tt>pos_type</tt> is a position in a stream by
5906 definition, so there is no ambiguity as to what it means. Proposed
5912 Post-Kona Martin adds:
5913 I'm afraid I disagree
5914 with the Kona '07 rationale for marking it NAD. The only text
5915 that describes precisely what it means to position the input
5916 or output sequence is in <tt>seekoff()</tt>. The <tt>seekpos()</tt> Effects
5917 clause is inadequate in comparison and the proposed resolution
5918 plugs the hole by specifying <tt>seekpos()</tt> in terms of <tt>seekoff()</tt>.
5926 <h3><a name="565"></a>565. xsputn inefficient</h3>
5927 <p><b>Section:</b> 27.6.2.4.5 [streambuf.virt.put] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
5928 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-02-23 <b>Last modified:</b> 2007-10-09</p>
5929 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
5930 <p><b>Discussion:</b></p>
5933 <tt>streambuf::xsputn()</tt> is specified to have the effect of
5934 "writing up to <tt>n</tt> characters to the output sequence as if by
5935 repeated calls to <tt>sputc(c)</tt>."
5940 Since <tt>sputc()</tt> is required to call <tt>overflow()</tt> when
5941 <tt>(pptr() == epptr())</tt> is true, strictly speaking
5942 <tt>xsputn()</tt> should do the same. However, doing so would be
5943 suboptimal in some interesting cases, such as in unbuffered mode or
5944 when the buffer is <tt>basic_stringbuf</tt>.
5949 Assuming calling <tt>overflow()</tt> is not really intended to be
5950 required and the wording is simply meant to describe the general
5951 effect of appending to the end of the sequence it would be worthwhile
5952 to mention in <tt>xsputn()</tt> that the function is not actually
5953 required to cause a call to <tt>overflow()</tt>.
5958 <p><b>Proposed resolution:</b></p>
5961 Add the following sentence to the <tt>xsputn()</tt> Effects clause in
5962 27.5.2.4.5, p1 (N1804):
5967 -1- <i>Effects:</i> Writes up to <tt><i>n</i></tt> characters to the output
5968 sequence as if by repeated calls to <tt>sputc(<i>c</i>)</tt>. The characters
5969 written are obtained from successive elements of the array whose first element
5970 is designated by <tt><i>s</i></tt>. Writing stops when either <tt><i>n</i></tt>
5971 characters have been written or a call to <tt>sputc(<i>c</i>)</tt> would return
5972 <tt>traits::eof()</tt>. <ins>It is uspecified whether the function calls
5973 <tt>overflow()</tt> when <tt>(pptr() == epptr())</tt> becomes true or whether
5974 it achieves the same effects by other means.</ins>
5979 In addition, I suggest to add a footnote to this function with the
5980 same text as Footnote 292 to make it extra clear that derived classes
5981 are permitted to override <tt>xsputn()</tt> for efficiency.
5987 Kona (2007): We want to permit a <tt>streambuf</tt> that streams output directly
5988 to a device without making calls to <tt>sputc</tt> or <tt>overflow</tt>. We believe that
5989 has always been the intention of the committee. We believe that the
5990 proposed wording doesn't accomplish that. Proposed Disposition: Open
5998 <h3><a name="568"></a>568. log2 overloads missing</h3>
5999 <p><b>Section:</b> TR1 8.16.4 [tr.c99.cmath.over] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">Tentatively NAD</a>
6000 <b>Submitter:</b> Paolo Carlini <b>Opened:</b> 2006-03-07 <b>Last modified:</b> 2009-05-23</p>
6001 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD">Tentatively NAD</a> status.</p>
6002 <p><b>Discussion:</b></p>
6004 <tt>log2</tt> is missing from the list of "additional overloads" in TR1 8.16.4 [tr.c99.cmath.over] p1.
6008 Hinnant: This is a TR1 issue only. It is fixed in the current (N2135) WD.
6016 We agree this has been fixed in the Working Draft.
6021 <p><b>Proposed resolution:</b></p>
6023 Add <tt>log2</tt> to the list of functions in TR1 8.16.4 [tr.c99.cmath.over] p1.
6031 <h3><a name="573"></a>573. C++0x file positioning should handle modern file sizes</h3>
6032 <p><b>Section:</b> 27.5.3 [fpos] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
6033 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2006-04-12 <b>Last modified:</b> 2007-10-09</p>
6034 <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>
6035 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
6036 <p><b>Discussion:</b></p>
6038 There are two deficiencies related to file sizes:
6041 <li>It doesn't appear that the Standard Library is specified in
6042 a way that handles modern file sizes, which are often too
6043 large to be represented by an unsigned long.</li>
6045 <li>The std::fpos class does not currently have the ability to
6046 set/get file positions.</li>
6049 The Dinkumware implementation of the Standard Library as shipped with the Microsoft compiler copes with these issues by:
6052 <li>Defining fpos_t be long long, which is large enough to
6053 represent any file position likely in the foreseeable future.</li>
6055 <li>Adding member functions to class fpos. For example,
6056 <blockquote><pre>fpos_t seekpos() const;
6061 Because there are so many types relating to file positions and offsets (fpos_t,
6062 fpos, pos_type, off_type, streamoff, streamsize, streampos, wstreampos, and
6063 perhaps more), it is difficult to know if the Dinkumware extensions are
6064 sufficient. But they seem a useful starting place for discussions, and they do
6065 represent existing practice.
6069 Kona (2007): We need a paper. It would be nice if someone proposed
6070 clarifications to the definitions of <tt>pos_type</tt> and <tt>off_type</tt>. Currently
6071 these definitions are horrible. Proposed Disposition: Open
6076 <p><b>Proposed resolution:</b></p>
6085 <h3><a name="580"></a>580. unused allocator members</h3>
6086 <p><b>Section:</b> 23.2.1 [container.requirements.general] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
6087 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-06-14 <b>Last modified:</b> 2009-05-01</p>
6088 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements.general">active issues</a> in [container.requirements.general].</p>
6089 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements.general">issues</a> in [container.requirements.general].</p>
6090 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
6091 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a></p>
6092 <p><b>Discussion:</b></p>
6095 C++ Standard Library templates that take an allocator as an argument
6096 are required to call the <code>allocate()</code> and
6097 <code>deallocate()</code> members of the allocator object to obtain
6098 storage. However, they do not appear to be required to call any other
6099 allocator members such as <code>construct()</code>,
6100 <code>destroy()</code>, <code>address()</code>, and
6101 <code>max_size()</code>. This makes these allocator members less than
6102 useful in portable programs.
6107 It's unclear to me whether the absence of the requirement to use these
6108 allocator members is an unintentional omission or a deliberate
6109 choice. However, since the functions exist in the standard allocator
6110 and since they are required to be provided by any user-defined
6111 allocator I believe the standard ought to be clarified to explictly
6112 specify whether programs should or should not be able to rely on
6113 standard containers calling the functions.
6118 I propose that all containers be required to make use of these
6123 Batavia: We support this resolution. Martin to provide wording.
6127 pre-Oxford: Martin provided wording.
6132 2009-04-28 Pablo adds:
6137 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2554.pdf">N2554</a>
6138 (scoped allocators),
6139 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2768.pdf">N2768</a>
6140 (allocator concepts), and
6141 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2810.pdf">N2810</a>
6142 (allocator defects), address all of these points EXCEPT <tt>max_size()</tt>.
6143 So, I would add a note to that affect and re-class the defect as belonging
6144 to section 23.2.1 [container.requirements.general].
6149 <p><b>Proposed resolution:</b></p>
6152 Specifically, I propose to change 23.2 [container.requirements],
6158 -9- Copy constructors for all container types defined in this clause
6159 <ins>that are parametrized on <code>Allocator</code></ins> copy
6160 <del>an</del><ins>the</ins> allocator argument from their respective
6163 All other constructors for these container types take a<del>n</del>
6164 <ins>const</ins> <code>Allocator&</code> argument (20.1.6), an
6165 allocator whose <code>value_type</code> is the same as the container's
6166 <code>value_type</code>.
6168 A copy of this argument <del>is</del><ins>shall be</ins> used for any
6169 memory allocation <ins> and deallocation</ins> performed<del>,</del>
6170 by these constructors and by all member functions<del>,</del> during
6171 the lifetime of each container object. <ins>Allocation shall be
6172 performed "as if" by calling the <code>allocate()</code> member
6173 function on a copy of the allocator object of the appropriate type
6174 <sup>New Footnote)</sup>, and deallocation "as if" by calling
6175 <code>deallocate()</code> on a copy of the same allocator object of
6176 the corresponding type.</ins>
6178 <ins>A copy of this argument shall also be used to construct and
6179 destroy objects whose lifetime is managed by the container, including
6180 but not limited to those of the container's <code>value_type</code>,
6181 and to obtain their address. All objects residing in storage
6182 allocated by a container's allocator shall be constructed "as if" by
6183 calling the <code>construct()</code> member function on a copy of the
6184 allocator object of the appropriate type. The same objects shall be
6185 destroyed "as if" by calling <code>destroy()</code> on a copy of the
6186 same allocator object of the same type. The address of such objects
6187 shall be obtained "as if" by calling the <code>address()</code> member
6188 function on a copy of the allocator object of the appropriate
6191 <ins>Finally, a copy of this argument shall be used by its container
6192 object to determine the maximum number of objects of the container's
6193 <code>value_type</code> the container may store at the same time. The
6194 container member function <code>max_size()</code> obtains this number
6195 from the value returned by a call to
6196 <code>get_allocator().max_size()</code>.</ins>
6198 In all container types defined in this clause <ins>that are
6199 parametrized on <code>Allocator</code></ins>, the member
6200 <code>get_allocator()</code> returns a copy of the
6201 <code>Allocator</code> object used to construct the
6202 container.<sup>258)</sup>
6205 New Footnote: This type may be different from <code>Allocator</code>:
6206 it may be derived from <code>Allocator</code> via
6207 <code>Allocator::rebind<U>::other</code> for the appropriate
6208 type <code>U</code>.
6213 The proposed wording seems cumbersome but I couldn't think of a better
6214 way to describe the requirement that containers use their
6215 <code>Allocator</code> to manage only objects (regardless of their
6216 type) that persist over their lifetimes and not, for example,
6217 temporaries created on the stack. That is, containers shouldn't be
6218 required to call <code>Allocator::construct(Allocator::allocate(1),
6219 elem)</code> just to construct a temporary copy of an element, or
6220 <code>Allocator::destroy(Allocator::address(temp), 1)</code> to
6221 destroy temporaries.
6227 Howard: This same paragraph will need some work to accommodate <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#431">431</a>.
6232 post Oxford: This would be rendered NAD Editorial by acceptance of
6233 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2257.html">N2257</a>.
6241 <h3><a name="582"></a>582. specialized algorithms and volatile storage</h3>
6242 <p><b>Section:</b> 20.8.11.2 [uninitialized.copy] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
6243 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-06-14 <b>Last modified:</b> 2009-03-14</p>
6244 <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>
6245 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
6246 <p><b>Discussion:</b></p>
6248 <p>Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1029">1029</a></p>
6251 The specialized algorithms [lib.specialized.algorithms] are specified
6252 as having the general effect of invoking the following expression:
6256 new (static_cast<void*>(&*i))
6257 typename iterator_traits<ForwardIterator>::value_type (x)
6262 This expression is ill-formed when the type of the subexpression
6263 <code>&*i</code> is some volatile-qualified <code>T</code>.
6268 Batavia: Lack of support for proposed resolution but agree there is a
6269 defect. Howard to look at wording. Concern that move semantics
6270 properly expressed if iterator returns rvalue.
6276 <p><b>Proposed resolution:</b></p>
6279 In order to allow these algorithms to operate on volatile storage I
6280 propose to change the expression so as to make it well-formed even for
6281 pointers to volatile types. Specifically, I propose the following
6282 changes to clauses 20 and 24. Change 20.6.4.1, p1 to read:
6288 typedef typename iterator_traits<ForwardIterator>::pointer pointer;
6289 typedef typename iterator_traits<ForwardIterator>::value_type value_type;
6291 for (; first != last; ++result, ++first)
6292 new (static_cast<void*>(const_cast<pointer>(&*result))
6293 value_type (*first);
6298 change 20.6.4.2, p1 to read
6304 typedef typename iterator_traits<ForwardIterator>::pointer pointer;
6305 typedef typename iterator_traits<ForwardIterator>::value_type value_type;
6307 for (; first != last; ++result, ++first)
6308 new (static_cast<void*>(const_cast<pointer>(&*first))
6314 and change 20.6.4.3, p1 to read
6320 typedef typename iterator_traits<ForwardIterator>::pointer pointer;
6321 typedef typename iterator_traits<ForwardIterator>::value_type value_type;
6323 for (; n--; ++first)
6324 new (static_cast<void*>(const_cast<pointer>(&*first))
6330 In addition, since there is no partial specialization for
6331 <code>iterator_traits<volatile T*></code> I propose to add one
6332 to parallel such specialization for <const T*>. Specifically, I
6333 propose to add the following text to the end of 24.3.1, p3:
6338 and for pointers to volatile as
6343 template<class T> struct iterator_traits<volatile T*> {
6344 typedef ptrdiff_t difference_type;
6345 typedef T value_type;
6346 typedef volatile T* pointer;
6347 typedef volatile T& reference;
6348 typedef random_access_iterator_tag iterator_category;
6355 Note that the change to <code>iterator_traits</code> isn't necessary
6356 in order to implement the specialized algorithms in a way that allows
6357 them to operate on volatile strorage. It is only necesassary in order
6358 to specify their effects in terms of <code>iterator_traits</code> as
6359 is done here. Implementations can (and some do) achieve the same
6360 effect by means of function template overloading.
6368 <h3><a name="585"></a>585. facet error reporting</h3>
6369 <p><b>Section:</b> 22.4 [locale.categories] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
6370 <b>Submitter:</b> Martin Sebor, Paolo Carlini <b>Opened:</b> 2006-06-22 <b>Last modified:</b> 2007-10-09</p>
6371 <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>
6372 <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>
6373 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
6374 <p><b>Discussion:</b></p>
6377 Section 22.2, paragraph 2 requires facet <code>get()</code> members
6378 that take an <code>ios_base::iostate&</code> argument,
6379 <code><i>err</i></code>, to ignore the (initial) value of the
6380 argument, but to set it to <code>ios_base::failbit</code> in case of a
6386 We believe there are a few minor problems with this blanket
6387 requirement in conjunction with the wording specific to each
6388 <code>get()</code> member function.
6393 First, besides <code>get()</code> there are other member functions
6394 with a slightly different name (for example,
6395 <code>get_date()</code>). It's not completely clear that the intent of
6396 the paragraph is to include those as well, and at least one
6397 implementation has interpreted the requirement literally.
6402 Second, the requirement to "set the argument to
6403 <code>ios_base::failbit</code> suggests that the functions are not
6404 permitted to set it to any other value (such as
6405 <code>ios_base::eofbit</code>, or even <code>ios_base::eofbit |
6406 ios_base::failbit</code>).
6411 However, 22.2.2.1.2, p5 (Stage 3 of <code>num_get</code> parsing) and
6412 p6 (<code>bool</code> parsing) specifies that the <code>do_get</code>
6413 functions perform <code><i>err</i> |= ios_base::eofbit</code>, which
6414 contradicts the earlier requirement to ignore <i>err</i>'s initial
6420 22.2.6.1.2, p1 (the Effects clause of the <code>money_get</code>
6421 facet's <code>do_get</code> member functions) also specifies that
6422 <code><i>err</i></code>'s initial value be used to compute the final
6423 value by ORing it with either <code>ios_base::failbit</code> or
6424 with<code>ios_base::eofbit | ios_base::failbit</code>.
6429 <p><b>Proposed resolution:</b></p>
6432 We believe the intent is for all facet member functions that take an
6433 <code>ios_base::iostate&</code> argument to:
6439 ignore the initial value of the <code><i>err</i></code> argument,
6444 reset <code><i>err</i></code> to <code>ios_base::goodbit</code> prior
6445 to any further processing,
6450 and set either <code>ios_base::eofbit</code>, or
6451 <code>ios_base::failbit</code>, or both in <code><i>err</i></code>, as
6452 appropriate, in response to reaching the end-of-file or on parse
6459 To that effect we propose to change 22.2, p2 as follows:
6464 The <i>put</i><del>()</del> members make no provision for error
6465 reporting. (Any failures of the OutputIterator argument must be
6466 extracted from the returned iterator.) <ins>Unless otherwise
6467 specified, </ins>the <i>get</i><del>()</del> members <ins>that</ins>
6468 take an <code>ios_base::iostate&</code> argument <del>whose value
6469 they ignore, but set to ios_base::failbit in case of a parse
6470 error.</del><ins>, <code><i>err</i></code>, start by evaluating
6471 <code>err = ios_base::goodbit</code>, and may subsequently set
6472 <i>err</i> to either <code>ios_base::eofbit</code>, or
6473 <code>ios_base::failbit</code>, or <code>ios_base::eofbit |
6474 ios_base::failbit</code> in response to reaching the end-of-file or in
6475 case of a parse error, or both, respectively.</ins>
6481 Kona (2007): We need to change the proposed wording to clarify that the
6482 phrase "the get members" actually denotes <tt>get()</tt>, <tt>get_date()</tt>, etc.
6483 Proposed Disposition: Open
6490 <h3><a name="588"></a>588. requirements on zero sized tr1::arrays and other details</h3>
6491 <p><b>Section:</b> 23.3.1 [array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
6492 <b>Submitter:</b> Gennaro Prota <b>Opened:</b> 2006-07-18 <b>Last modified:</b> 2009-05-30</p>
6493 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#array">active issues</a> in [array].</p>
6494 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#array">issues</a> in [array].</p>
6495 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
6496 <p><b>Discussion:</b></p>
6498 The wording used for section 23.2.1 [lib.array] seems to be subtly
6499 ambiguous about zero sized arrays (N==0). Specifically:
6502 * "An instance of array<T, N> stores N elements of type T, so that
6506 Does this imply that a zero sized array object stores 0 elements, i.e.
6507 that it cannot store any element of type T? The next point clarifies
6508 the rationale behind this question, basically how to implement begin()
6512 * 23.2.1.5 [lib.array.zero], p2: "In the case that N == 0, begin() ==
6513 end() == unique value."
6516 What does "unique" mean in this context? Let's consider the following
6517 possible implementations, all relying on a partial specialization:
6520 template< typename T >
6521 class array< T, 0 > {
6526 { return iterator( reinterpret_cast< T * >( this ) ); }
6532 This has been used in boost, probably intending that the return value
6533 had to be unique to the specific array object and that array couldn't
6534 store any T. Note that, besides relying on a reinterpret_cast, has
6535 (more than potential) alignment problems.
6538 template< typename T >
6539 class array< T, 0 > {
6544 { return iterator( &t ); }
6550 This provides a value which is unique to the object and to the type of
6551 the array, but requires storing a T. Also, it would allow the user to
6552 mistakenly provide an initializer list with one element.
6555 A slight variant could be returning *the* null pointer of type T
6557 <blockquote><pre> return static_cast<T*>(0);
6560 In this case the value would be unique to the type array<T, 0> but not
6561 to the objects (all objects of type array<T, 0> with the same value
6562 for T would yield the same pointer value).
6565 Furthermore this is inconsistent with what the standard requires from
6566 allocation functions (see library issue 9).
6569 c) same as above but with t being a static data member; again, the
6570 value would be unique to the type, not to the object.
6573 d) to avoid storing a T *directly* while disallowing the possibility
6574 to use a one-element initializer list a non-aggregate nested class
6577 <blockquote><pre> struct holder { holder() {} T t; } h;
6580 and then begin be defined as
6582 <blockquote><pre> iterator begin() { return &h.t; }
6585 But then, it's arguable whether the array stores a T or not.
6589 -----------------------------------------------------
6592 Now, on different issues:
6595 * what's the effect of calling assign(T&) on a zero-sized array? There
6596 seems to be only mention of front() and back(), in 23.2.1 [lib.array]
6597 p4 (I would also suggest to move that bullet to section 23.2.1.5
6598 [lib.array.zero], for locality of reference)
6601 * (minor) the opening paragraph of 23.2.1 [lib.array] wording is a bit
6602 inconsistent with that of other sequences: that's not a problem in
6603 itself, but compare it for instance with "A vector is a kind of
6604 sequence that supports random access iterators"; though the intent is
6605 obvious one might argue that the wording used for arrays doesn't tell
6606 what an array is, and relies on the reader to infer that it is what
6607 the <array> header defines.
6610 * it would be desiderable to have a static const data member of type
6611 std::size_t, with value N, for usage as integral constant expression
6614 * section 23.1 [lib.container.requirements] seem not to consider
6615 fixed-size containers at all, as it says: "[containers] control
6616 allocation and deallocation of these objects [the contained objects]
6617 through constructors, destructors, *insert and erase* operations"
6620 * max_size() isn't specified: the result is obvious but, technically,
6621 it relies on table 80: "size() of the largest possible container"
6622 which, again, doesn't seem to consider fixed size containers
6626 2009-05-29 Daniel adds:
6634 star bullet 1 ("what's the effect of calling <tt>assign(T&)</tt> on a
6635 zero-sized array?[..]");
6638 <tt>assign</tt> has been renamed to <tt>fill</tt> and the semantic of <tt>fill</tt> is now
6640 the free algorithm <tt>fill_n</tt>, which is well-defined for this situation.
6645 star bullet 3 ("it would be desiderable to have a static const data
6649 It seems that <tt>tuple_size<array<T, N> >::value</tt> as of 23.3.1.7 [array.tuple] does
6650 provide this functionality now.
6657 <p><b>Proposed resolution:</b></p>
6663 Kona (2007): requirements on zero sized <tt>tr1::array</tt>s and other details
6664 Issue 617: <tt>std::array</tt> is a sequence that doesn't satisfy the sequence
6665 requirements? Alisdair will prepare a paper. Proposed Disposition: Open
6673 <h3><a name="597"></a>597. Decimal: The notion of 'promotion' cannot be emulated by user-defined types.</h3>
6674 <p><b>Section:</b> TRDecimal 3.2 [trdec.types.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
6675 <b>Submitter:</b> Daveed Vandevoorde <b>Opened:</b> 2006-04-05 <b>Last modified:</b> 2009-05-01</p>
6676 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#trdec.types.types">active issues</a> in [trdec.types.types].</p>
6677 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#trdec.types.types">issues</a> in [trdec.types.types].</p>
6678 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
6679 <p><b>Discussion:</b></p>
6681 In a private email, Daveed writes:
6685 I am not familiar with the C TR, but my guess is that the
6686 class type approach still won't match a built-in type
6687 approach because the notion of "promotion" cannot be
6688 emulated by user-defined types.
6696 S(_Decimal32 const&); // Converting constructor
6702 void g(_Decimal32 d) {
6709 If _Decimal32 is a built-in type, the call f(d) will likely
6710 resolve to f(_Decimal64) because that requires only a
6711 promotion, whereas f(S) requires a user-defined conversion.
6714 If _Decimal32 is a class type, I think the call f(d) will be
6715 ambiguous because both the conversion to _Decimal64 and the
6716 conversion to S will be user-defined conversions with neither
6717 better than the other.
6724 In general, a library of arithmetic types cannot exactly emulate the
6725 behavior of the intrinsic numeric types. There are several ways to tell
6726 whether an implementation of the decimal types uses compiler
6727 intrinisics or a library. For example:
6729 <pre> _Decimal32 d1;
6730 d1.operator+=(5); // If d1 is a builtin type, this won't compile.
6733 In preparing the decimal TR, we have three options:
6736 <li>require that the decimal types be class types</li>
6737 <li>require that the decimal types be builtin types, like float and double</li>
6738 <li>specify a library of class types, but allow enough implementor
6739 latitude that a conforming implementation could instead provide builtin
6743 We decided as a group to pursue option #3, but that approach implies
6744 that implementations may not agree on the semantics of certain use
6745 cases (first example, above), or on whether certain other cases are
6746 well-formed (second example). Another potentially important problem is
6747 that, under the present definition of POD, the decimal classes are not
6748 POD types, but builtins will be.
6750 <p>Note that neither example above implies any problems with respect to
6751 C-to-C++ compatibility, since neither example can be expressed in C.
6755 <p><b>Proposed resolution:</b></p>
6762 <h3><a name="606"></a>606. Decimal: allow narrowing conversions</h3>
6763 <p><b>Section:</b> TRDecimal 3.2 [trdec.types.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
6764 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-06-15 <b>Last modified:</b> 2007-01-15</p>
6765 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#trdec.types.types">active issues</a> in [trdec.types.types].</p>
6766 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#trdec.types.types">issues</a> in [trdec.types.types].</p>
6767 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
6768 <p><b>Discussion:</b></p>
6770 In c++std-lib-17205, Martin writes:
6772 <blockquote><p>...was it a deliberate design choice to make narrowing
6773 assignments ill-formed while permitting narrowing compound assignments?
6776 <pre> decimal32 d32;
6783 In c++std-lib-17229, Robert responds:
6785 <blockquote><p>It is a vestige of an old idea that I forgot to remove
6786 from the paper. Narrowing assignments should be permitted. The bug is
6787 that the converting constructors that cause narrowing should not be
6788 explicit. Thanks for pointing this out.
6791 <p><b>Proposed resolution:</b></p>
6793 1. In "3.2.2 Class <code>decimal32</code>" synopsis, remove the <code>explicit</code> specifier from the narrowing conversions:
6795 <pre> // <i>3.2.2.2 conversion from floating-point type:</i>
6796 <del>explicit</del> decimal32(decimal64 <i>d64</i>);
6797 <del>explicit</del> decimal32(decimal128 <i>d128</i>);
6800 2. Do the same thing in "3.2.2.2. Conversion from floating-point type."
6803 3. In "3.2.3 Class <code>decimal64</code>" synopsis, remove the <code>explicit</code> specifier from the narrowing conversion:
6805 <pre> // <i>3.2.3.2 conversion from floating-point type:</i>
6806 <del>explicit</del> decimal64(decimal128 <i>d128</i>);
6809 4. Do the same thing in "3.2.3.2. Conversion from floating-point type."
6813 Redmond: We prefer explicit conversions for narrowing and implicit for widening.
6822 <h3><a name="614"></a>614. std::string allocator requirements still inconsistent</h3>
6823 <p><b>Section:</b> 21.4 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
6824 <b>Submitter:</b> Bo Persson <b>Opened:</b> 2006-12-05 <b>Last modified:</b> 2008-03-12</p>
6825 <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>
6826 <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>
6827 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
6828 <p><b>Discussion:</b></p>
6830 This is based on N2134, where 21.3.1/2 states:
6831 "... The Allocator object used shall be a copy of the Allocator object
6832 passed to the basic_string object's constructor or, if the constructor does
6833 not take an Allocator argument, a copy of a default-constructed Allocator
6837 Section 21.3.2/1 lists two constructors:
6839 <blockquote><pre>basic_string(const basic_string<charT,traits,Allocator>& str );
6841 basic_string(const basic_string<charT,traits,Allocator>& str ,
6842 size_type pos , size_type n = npos,
6843 const Allocator& a = Allocator());
6846 and then says "In the first form, the Allocator value used is copied from
6847 str.get_allocator().", which isn't an option according to 21.3.1.
6850 Batavia: We need blanket statement to the effect of:
6855 <li>If an allocator is passed in, use it, or,</li>
6856 <li>If a string is passed in, use its allocator.</li>
6859 Review constructors and functions that return a string; make sure we follow these
6860 rules (substr, operator+, etc.). Howard to supply wording.
6865 Bo adds: The new container constructor which takes only a <tt>size_type</tt> is not
6866 consistent with 23.2 [container.requirements], p9 which says in part:
6869 All other constructors for these container types take an
6870 <tt>Allocator&</tt> argument (20.1.2), an allocator whose value type
6871 is the same as the container's value type. A copy of this argument is
6872 used for any memory allocation performed, by these constructors and by
6873 all member functions, during the lifetime of each container object.
6879 post Bellevue: We re-confirm that the issue is real. Pablo will provide wording.
6885 <p><b>Proposed resolution:</b></p>
6894 <h3><a name="617"></a>617. std::array is a sequence that doesn't satisfy the sequence requirements?</h3>
6895 <p><b>Section:</b> 23.3.1 [array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
6896 <b>Submitter:</b> Bo Persson <b>Opened:</b> 2006-12-30 <b>Last modified:</b> 2008-03-14</p>
6897 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#array">active issues</a> in [array].</p>
6898 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#array">issues</a> in [array].</p>
6899 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
6900 <p><b>Discussion:</b></p>
6902 The <tt><array></tt> header is given under 23.3 [sequences].
6903 23.3.1 [array]/paragraph 3 says:
6906 "Unless otherwise specified, all array operations are as described in
6907 23.2 [container.requirements]".
6910 However, array isn't mentioned at all in section 23.2 [container.requirements].
6911 In particular, Table 82 "Sequence requirements" lists several operations (insert, erase, clear)
6912 that std::array does not have in 23.3.1 [array].
6915 Also, Table 83 "Optional sequence operations" lists several operations that
6916 std::array does have, but array isn't mentioned.
6920 <p><b>Proposed resolution:</b></p>
6929 <h3><a name="625"></a>625. mixed up <i>Effects</i> and <i>Returns</i> clauses</h3>
6930 <p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
6931 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-01-20 <b>Last modified:</b> 2009-05-23</p>
6932 <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>
6933 <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>
6934 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
6935 <p><b>Discussion:</b></p>
6938 Many member functions of <code>basic_string</code> are overloaded,
6939 with some of the overloads taking a <code>string</code> argument,
6940 others <code>value_type*</code>, others <code>size_type</code>, and
6941 others still <code>iterators</code>. Often, the requirements on one of
6942 the overloads are expressed in the form of <i>Effects</i>,
6943 <i>Throws</i>, and in the Working Paper
6944 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2134.pdf">N2134</a>)
6945 also <i>Remark</i> clauses, while those on the rest of the overloads
6946 via a reference to this overload and using a <i>Returns</i> clause.
6950 The difference between the two forms of specification is that per
6951 17.5.1.4 [structure.specifications], p3, an <i>Effects</i> clause specifies
6952 <i>"actions performed by the functions,"</i> i.e., its observable
6953 effects, while a <i>Returns</i> clause is <i>"a description of the
6954 return value(s) of a function"</i> that does not impose any
6955 requirements on the function's observable effects.
6959 Since only <i>Notes</i> are explicitly defined to be informative and
6960 all other paragraphs are explicitly defined to be normative, like
6961 <i>Effects</i> and <i>Returns</i>, the new <i>Remark</i> clauses also
6962 impose normative requirements.
6966 So by this strict reading of the standard there are some member
6967 functions of <code>basic_string</code> that are required to throw an
6968 exception under some conditions or use specific traits members while
6969 many other otherwise equivalent overloads, while obliged to return the
6970 same values, aren't required to follow the exact same requirements
6971 with regards to the observable effects.
6975 Here's an example of this problem that was precipitated by the change
6976 from informative Notes to normative <i>Remark</i>s (presumably made to
6977 address <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#424">424</a>):
6981 In the Working Paper, <code>find(string, size_type)</code> contains a
6982 <i>Remark</i> clause (which is just a <i>Note</i> in the current
6983 standard) requiring it to use <code>traits::eq()</code>.
6987 <code>find(const charT *s, size_type pos)</code> is specified to
6988 return <code>find(string(s), pos)</code> by a <i>Returns</i> clause
6989 and so it is not required to use <code>traits::eq()</code>. However,
6990 the Working Paper has replaced the original informative <i>Note</i>
6991 about the function using <code>traits::length()</code> with a
6992 normative requirement in the form of a <i>Remark</i>. Calling
6993 <code>traits::length()</code> may be suboptimal, for example when the
6994 argument is a very long array whose initial substring doesn't appear
6995 anywhere in <code>*this</code>.
6999 Here's another similar example, one that existed even prior to the
7000 introduction of <i>Remark</i>s:
7004 <code> insert(size_type pos, string, size_type, size_type)</code> is
7005 required to throw <code>out_of_range</code> if <code>pos >
7010 <code>insert(size_type pos, string str)</code> is specified to return
7011 <code>insert(pos, str, 0, npos)</code> by a <i>Returns</i> clause and
7012 so its effects when <code>pos > size()</code> are strictly speaking
7017 I believe a careful review of the current <i>Effects</i> and
7018 <i>Returns</i> clauses is needed in order to identify all such
7019 problematic cases. In addition, a review of the Working Paper should
7020 be done to make sure that the newly introduced normative <i>Remark</i>
7021 clauses do not impose any undesirable normative requirements in place
7022 of the original informative <i>Notes</i>.
7026 Batavia: Alan and Pete to work.
7031 Bellevue: Marked as NAD Editorial.
7036 Post-Sophia Antipolis:
7037 Martin indicates there is still work to be done on this issue.
7047 Tom proposes we say that, unless specified otherwise,
7048 it is always the caller's responsibility to verify that supplied arguments
7049 meet the called function's requirements.
7050 If further semantics are specified
7051 (e.g., that the function throws under certain conditions),
7052 then it is up to the implementer to check those conditions.
7053 Alan feels strongly that our current use of Requires in this context
7054 is confusing, especially now that <tt>requires</tt> is a new keyword.
7058 <p><b>Proposed resolution:</b></p>
7067 <h3><a name="630"></a>630. arrays of valarray</h3>
7068 <p><b>Section:</b> 26.6.2.1 [valarray.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
7069 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-01-28 <b>Last modified:</b> 2008-06-02</p>
7070 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#valarray.cons">active issues</a> in [valarray.cons].</p>
7071 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#valarray.cons">issues</a> in [valarray.cons].</p>
7072 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
7073 <p><b>Discussion:</b></p>
7076 Section 26.2 [numeric.requirements], p1 suggests that a
7077 <code>valarray</code> specialization on a type <code>T</code> that
7078 satisfies the requirements enumerated in the paragraph is itself a
7079 valid type on which <code>valarray</code> may be instantiated
7080 (Footnote 269 makes this clear). I.e.,
7081 <code>valarray<valarray<T> ></code> is valid as long as
7082 <code>T</code> is valid. However, since implementations of
7083 <code>valarray</code> are permitted to initialize storage allocated by
7084 the class by invoking the default ctor of <code>T</code> followed by
7085 the copy assignment operator, such implementations of
7086 <code>valarray</code> wouldn't work with (perhaps user-defined)
7087 specializations of <code>valarray</code> whose assignment operator had
7088 undefined behavior when the size of its argument didn't match the size
7089 of <code>*this</code>. By <i>"wouldn't work"</i> I mean that it would
7090 be impossible to resize such an array of arrays by calling the
7091 <code>resize()</code> member function on it if the function used the
7092 copy assignment operator after constructing all elements using the
7093 default ctor (e.g., by invoking <code>new value_type[N]</code>) to
7094 obtain default-initialized storage) as it's permitted to do.
7099 Stated more generally, the problem is that
7100 <code>valarray<valarray<T> >::resize(size_t)</code> isn't
7101 required or guaranteed to have well-defined semantics for every type
7102 <code>T</code> that satisfies all requirements in
7103 26.2 [numeric.requirements].
7108 I believe this problem was introduced by the adoption of the
7109 resolution outlined in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1996/N0857.asc">N0857</a>,
7110 <i>Assignment of valarrays</i>, from 1996. The copy assignment
7111 operator of the original numerical array classes proposed in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1993/N0280.pdf">N0280</a>,
7112 as well as the one proposed in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1993/N0308.asc">N0308</a>
7113 (both from 1993), had well-defined semantics for arrays of unequal
7114 size (the latter explicitly only when <code>*this</code> was empty;
7115 assignment of non empty arrays of unequal size was a runtime error).
7120 The justification for the change given in N0857 was the "loss of
7121 performance [deemed] only significant for very simple operations on
7122 small arrays or for architectures with very few registers."
7127 Since tiny arrays on a limited subset of hardware architectures are
7128 likely to be an exceedingly rare case (despite the continued
7129 popularity of x86) I propose to revert the resolution and make the
7130 behavior of all <code>valarray</code> assignment operators
7131 well-defined even for non-conformal arrays (i.e., arrays of unequal
7132 size). I have implemented this change and measured no significant
7133 degradation in performance in the common case (non-empty arrays of
7134 equal size). I have measured a 50% (and in some cases even greater)
7135 speedup in the case of assignments to empty arrays versus calling
7136 <code>resize()</code> first followed by an invocation of the copy
7137 assignment operator.
7147 If no proposed wording by June meeting, this issue should be closed NAD.
7152 <p><b>Proposed resolution:</b></p>
7155 Change 26.6.2.2 [valarray.assign], p1 as follows:
7162 valarray<T>& operator=(const valarray<T>&<ins> x</ins>);
7168 -1- Each element of the <code>*this</code> array is assigned the value
7169 of the corresponding element of the argument array. <del>The
7170 resulting behavior is undefined if </del><ins>When </ins>the length of
7171 the argument array is not equal to the length of the *this
7172 array<del>.</del><ins> resizes <code>*this</code> to make the two
7173 arrays the same length, as if by calling
7174 <code>resize(x.size())</code>, before performing the assignment.</ins>
7180 And add a new paragraph just below paragraph 1 with the following
7187 <ins>-2- <i>Postcondition</i>: <code>size() == x.size()</code>.</ins>
7193 Also add the following paragraph to 26.6.2.2 [valarray.assign], immediately after p4:
7199 <ins>-?- When the length, <i><code>N</code></i> of the array referred
7200 to by the argument is not equal to the length of <code>*this</code>,
7201 the operator resizes <code>*this</code> to make the two arrays the
7202 same length, as if by calling <code>resize(<i>N</i>)</code>, before
7203 performing the assignment.</ins>
7209 pre-Sophia Antipolis, Martin adds the following compromise wording, but
7210 prefers the original proposed resolution:
7215 Change 26.6.2.2 [valarray.assign], p1 as follows:
7220 -1- <i>Requires:</i> <tt>size() == 0 || size() == x.size()</tt>.
7223 -2- <i>Effects:</i> If <tt>size() == 0</tt> calls <tt>x.resize(x.size())</tt> first.
7224 Each element of the <tt>*this</tt> array is assigned the value of the
7225 corresponding element of the argument array.
7228 -3- <i>Postcondition:</i> <tt>size() == x.size()</tt>.
7233 Add the following paragraph to 26.6.2.2 [valarray.assign], immediately after
7239 -?- When <tt>size() == 0</tt> and the length, <tt>N</tt> of the array referred to by
7240 the argument is not equal to the length of <tt>*this</tt>, the operator
7241 resizes <tt>*this</tt> to make the two arrays the same length, as if by
7242 calling <tt>resize(N)</tt>, before performing the assignment. Otherwise,
7243 when <tt>size() > 0</tt> and <tt>size() != N</tt>, the behavior is undefined.
7250 Kona (2007): Gaby to propose wording for an alternative resolution in
7251 which you can assign to a <tt>valarray</tt> of size 0, but not to any other
7252 <tt>valarray</tt> whose size is unequal to the right hand side of the assignment.
7260 <h3><a name="632"></a>632. Time complexity of size() for std::set</h3>
7261 <p><b>Section:</b> 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
7262 <b>Submitter:</b> Lionel B <b>Opened:</b> 2007-02-01 <b>Last modified:</b> 2009-05-23</p>
7263 <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>
7264 <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>
7265 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
7266 <p><b>Discussion:</b></p>
7268 A recent news group discussion:
7272 Anyone know if the Standard has anything to say about the time complexity
7273 of size() for std::set? I need to access a set's size (/not/ to know if it is empty!) heavily
7274 during an algorithm and was thus wondering whether I'd be better off
7275 tracking the size "manually" or whether that'd be pointless.
7278 That would be pointless. size() is O(1).
7281 Nit: the standard says "should" have constant time. Implementations may take
7282 license to do worse. I know that some do this for <tt>std::list<></tt> as a part of
7283 some trade-off with other operation.
7287 I was aware of that, hence my reluctance to use size() for std::set.
7290 However, this reason would not apply to <tt>std::set<></tt> as far as I can see.
7293 Ok, I guess the only option is to try it and see...
7298 If I have any recommendation to the C++ Standards Committee it is that
7299 implementations must (not "should"!) document clearly[1], where known, the
7300 time complexity of *all* container access operations.
7303 [1] In my case (gcc 4.1.1) I can't swear that the time complexity of size()
7304 for std::set is not documented... but if it is it's certainly well hidden
7309 Kona (2007): This issue affects all the containers. We'd love to see a
7310 paper dealing with the broad issue. We think that the complexity of the
7311 <tt>size()</tt> member of every container -- except possibly <tt>list</tt> -- should be
7312 O(1). Alan has volunteered to provide wording.
7322 Mandating O(1) size will not fly, too many implementations would be
7323 invalidated. Alan to provide wording that toughens wording, but that
7324 does not absolutely mandate O(1).
7332 We observed that the wording "should" (in note a) has no effect.
7333 Howard prefers that O(1) size be mandated.
7334 It is not clear that this issue can be resolved to everyone's satisfaction,
7335 but Alan will provide wording nonetheless.
7339 <p><b>Proposed resolution:</b></p>
7348 <h3><a name="635"></a>635. domain of <tt>allocator::address</tt></h3>
7349 <p><b>Section:</b> X [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
7350 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2007-02-08 <b>Last modified:</b> 2009-05-01</p>
7351 <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>
7352 <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>
7353 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
7354 <p><b>Discussion:</b></p>
7356 The table of allocator requirements in X [allocator.requirements] describes
7357 <tt>allocator::address</tt> as:
7359 <blockquote><pre>a.address(r)
7363 where <tt>r</tt> and <tt>s</tt> are described as:
7366 a value of type <tt>X::reference</tt> obtained by the expression <tt>*p</tt>.
7374 a value of type <tt>X::pointer</tt>, obtained by calling <tt>a1.allocate</tt>,
7375 where <tt>a1 == a</tt>
7379 This all implies that to get the address of some value of type <tt>T</tt> that
7380 value must have been allocated by this allocator or a copy of it.
7384 However sometimes container code needs to compare the address of an external value of
7385 type <tt>T</tt> with an internal value. For example <tt>list::remove(const T& t)</tt>
7386 may want to compare the address of the external value <tt>t</tt> with that of a value
7387 stored within the list. Similarly <tt>vector</tt> or <tt>deque insert</tt> may
7388 want to make similar comparisons (to check for self-referencing calls).
7392 Mandating that <tt>allocator::address</tt> can only be called for values which the
7393 allocator allocated seems overly restrictive.
7402 Pablo recommends NAD Editorial, solved by
7403 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2768.pdf">N2768</a>.
7407 2009-04-28 Pablo adds:
7412 Tentatively-ready NAD Editorial as fixed by
7413 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2768.pdf">N2768</a>.
7418 <p><b>Proposed resolution:</b></p>
7420 Change X [allocator.requirements]:
7425 <tt>r</tt> : a value of type <tt>X::reference</tt> <del>obtained by the expression *p</del>.
7428 <tt>s</tt> : a value of type <tt>X::const_reference</tt> <del>obtained by the
7429 expression <tt>*q</tt> or by conversion from a value <tt>r</tt></del>.
7434 post Oxford: This would be rendered NAD Editorial by acceptance of
7435 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2257.html">N2257</a>.
7440 Kona (2007): This issue is section 8 of N2387. There was some discussion of it but
7441 no resolution to this issue was recorded. Moved to Open.
7451 <h3><a name="644"></a>644. Possible typos in 'function' description</h3>
7452 <p><b>Section:</b> 20.7.16.2 [func.wrap.func] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">Tentatively NAD</a>
7453 <b>Submitter:</b> Bo Persson <b>Opened:</b> 2007-02-25 <b>Last modified:</b> 2009-05-23</p>
7454 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#func.wrap.func">active issues</a> in [func.wrap.func].</p>
7455 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.wrap.func">issues</a> in [func.wrap.func].</p>
7456 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD">Tentatively NAD</a> status.</p>
7457 <p><b>Discussion:</b></p>
7459 20.7.16.2 [func.wrap.func]
7462 The note in paragraph 2 refers to 'undefined void operators', while the
7463 section declares a pair of operators returning bool.
7467 Post-Sophia Antipolis:
7472 Changed from Pending WP to Open. This issue was voted to WP at the same time the operators were
7473 changed from private to deleted. The two issues stepped on each other. What do we want the return
7474 type of these deleted functions to be?
7478 2009-05-02 Daniel adds:
7484 I suggest harmonizing this issue with similar classes. E.g. in
7485 20.8.13.3 [util.smartptr.weak] <tt>bool</tt> return values for
7487 <blockquote><pre>template <class Y> bool operator<(weak_ptr<Y> const&) const = delete;
7488 template <class Y> bool operator<=(weak_ptr<Y> const&) const = delete;
7489 template <class Y> bool operator>(weak_ptr<Y> const&) const = delete;
7490 template <class Y> bool operator>=(weak_ptr<Y> const&) const = delete;
7494 are used and basically all <em>newer</em> provided deleted copy assignment operators
7495 of type <tt>X</tt> use the canonical return type <tt>X&</tt> instead of <tt>void</tt>. Since the note
7496 mentioned in the issue description has now already been changed to
7499 deleted overloads close possible hole in the type system
7502 it seems to be of even lesser need to perform the change. Therefore
7503 I recommend declaring the issue as NAD.
7513 We agree with Daniel's recommendation.
7521 <p><b>Proposed resolution:</b></p>
7523 Change 20.7.16.2 [func.wrap.func]
7526 <blockquote><pre>...
7528 // 20.7.16.2 [func.wrap.func], undefined operators:
7529 template<class Function2> <del>bool</del> <ins>void</ins> operator==(const function<Function2>&);
7530 template<class Function2> <del>bool</del> <ins>void</ins> operator!=(const function<Function2>&);
7535 Change 20.7.16.2 [func.wrap.func]
7538 <blockquote><pre>template<class Function2> <del>bool</del> <ins>void</ins> operator==(const function<Function2>&);
7539 template<class Function2> <del>bool</del> <ins>void</ins> operator!=(const function<Function2>&);
7547 <h3><a name="659"></a>659. istreambuf_iterator should have an operator->()</h3>
7548 <p><b>Section:</b> 24.6.3 [istreambuf.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
7549 <b>Submitter:</b> Niels Dekker <b>Opened:</b> 2007-03-25 <b>Last modified:</b> 2009-05-30</p>
7550 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istreambuf.iterator">issues</a> in [istreambuf.iterator].</p>
7551 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
7552 <p><b>Discussion:</b></p>
7554 Greg Herlihy has clearly demonstrated that a user defined input
7555 iterator should have an operator->(), even if its
7556 value type is a built-in type (comp.std.c++, "Re: Should any iterator
7557 have an operator->() in C++0x?", March 2007). And as Howard
7558 Hinnant remarked in the same thread that the input iterator
7559 <tt>istreambuf_iterator</tt> doesn't have one, this must be a
7563 Based on Greg's example, the following code demonstrates the issue:
7564 </p><pre> #include <iostream>
7565 #include <fstream>
7566 #include <streambuf>
7571 std::ifstream s("filename", std::ios::in);
7572 std::istreambuf_iterator<char> i(s);
7574 (*i).~C(); // This is well-formed...
7575 i->~C(); // ... so this should be supported!
7580 Of course, operator-> is also needed when the value_type of
7581 istreambuf_iterator is a class.
7584 The operator-> could be implemented in various ways. For instance,
7585 by storing the current value inside the iterator, and returning its
7586 address. Or by returning a proxy, like operator_arrow_proxy, from
7587 <a href="http://www.boost.org/boost/iterator/iterator_facade.hpp">http://www.boost.org/boost/iterator/iterator_facade.hpp</a>
7590 I hope that the resolution of this issue will contribute to getting a
7591 clear and consistent definition of iterator concepts.
7595 Kona (2007): The proposed resolution is inconsistent because the return
7596 type of <tt>istreambuf_iterator::operator->()</tt> is specified to be <tt>pointer</tt>,
7597 but the proposed text also states that "<tt>operator-></tt> may return a proxy."
7602 Niels Dekker (mailed to Howard Hinnant):
7607 The proposed resolution does
7608 not seem inconsistent to me. <tt>istreambuf_iterator::operator->()</tt> should
7609 have <tt>istreambuf_iterator::pointer</tt> as return type, and this return type
7610 may in fact be a proxy.
7613 AFAIK, the resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#445">445</a> ("<tt>iterator_traits::reference</tt>
7614 unspecified for some iterator categories") implies that for any iterator
7615 class <tt>Iter</tt>, the return type of <tt>operator->()</tt> is <tt>Iter::pointer</tt>, by
7616 definition. I don't think <tt>Iter::pointer</tt> needs to be a raw pointer.
7619 Still I wouldn't mind if the text "<tt>operator-></tt> may return a proxy" would
7620 be removed from the resolution. I think it's up to the library
7621 implementation, how to implement <tt>istreambuf_iterator::operator->()</tt>. As
7622 longs as it behaves as expected: <tt>i->m</tt> should have the same effect as
7623 <tt>(*i).m</tt>. Even for an explicit destructor call, <tt>i->~C()</tt>. The main issue
7624 is just: <tt>istreambuf_iterator</tt> should have an <tt>operator->()</tt>!
7629 2009-04-30 Alisdair adds:
7634 Note that operator-> is now a requirement in the <tt>InputIterator</tt> concept, so
7635 this issue cannot be ignored or existing valid programs will break when
7636 compiled with an 0x library.
7640 2009-05-29 Alisdair adds:
7646 I agree with the observation that in principle the type 'pointer' may be a
7647 proxy, and the words highlighting this are redundant.
7650 However, in the current draught <tt>pointer</tt> is required to be exactly '<tt>charT *</tt>'
7651 by the derivation from <tt>std::iterator</tt>. At a minimum, the 4th parameter of
7652 this base class template should become unspecified. That permits the
7653 introduction of a proxy as a nested class in some further undocumented (not
7654 even exposition-only) base.
7657 It also permits the <tt>istream_iterator</tt> approach where the cached value is
7658 stored in the iterator itself, and the iterator serves as its own proxy for
7659 post-increment <tt>operator++</tt> - removing the need for the existing
7660 exposition-only nested class <tt>proxy</tt>.
7663 Note that the current <tt>proxy</tt> class also has exactly the right properties to
7664 serve as the pointer <tt>proxy</tt> too. This is likely to be a common case where an
7665 <tt>InputIterator</tt> does not hold internal state but delegates to another class.
7668 Proposed Resolution:
7671 In addition to the current proposal:
7674 24.6.3 [istreambuf.iterator]
7676 <blockquote><pre>template<class charT, class traits = char_traits<charT> >
7677 class istreambuf_iterator
7678 : public iterator<input_iterator_tag, charT,
7679 typename traits::off_type, <del>charT*</del> <ins><i>unspecified</i></ins>, charT> {
7684 <p><b>Proposed resolution:</b></p>
7686 Add to the synopsis in 24.6.3 [istreambuf.iterator]:
7689 <blockquote><pre>charT operator*() const;
7690 <ins>pointer operator->() const;</ins>
7691 istreambuf_iterator<charT,traits>& operator++();
7695 Change 24.6.3 [istreambuf.iterator], p1:
7699 The class template <tt>istreambuf_iterator</tt> reads successive
7700 characters from the <tt>streambuf</tt> for which it was constructed.
7701 <tt>operator*</tt> provides access to the current input character, if
7702 any. <ins><tt>operator-></tt> may return a proxy.</ins> Each time
7703 <tt>operator++</tt> is evaluated, the iterator advances to the next
7704 input character. If the end of stream is reached
7705 (<tt>streambuf_type::sgetc()</tt> returns <tt>traits::eof()</tt>), the
7706 iterator becomes equal to the end of stream iterator value. The default
7707 constructor <tt>istreambuf_iterator()</tt> and the constructor
7708 <tt>istreambuf_iterator(0)</tt> both construct an end of stream iterator
7709 object suitable for use as an end-of-range.
7719 <h3><a name="667"></a>667. <tt>money_get</tt>'s widened minus sign</h3>
7720 <p><b>Section:</b> 22.4.6.1.2 [locale.money.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">Tentatively NAD</a>
7721 <b>Submitter:</b> Thomas Plum <b>Opened:</b> 2007-04-16 <b>Last modified:</b> 2009-05-23</p>
7722 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.money.get.virtuals">active issues</a> in [locale.money.get.virtuals].</p>
7723 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.money.get.virtuals">issues</a> in [locale.money.get.virtuals].</p>
7724 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD">Tentatively NAD</a> status.</p>
7725 <p><b>Discussion:</b></p>
7727 22.4.6.1.2 [locale.money.get.virtuals], para 1 says:
7731 The result is returned as an integral value
7732 stored in <tt>units</tt> or as a sequence of digits possibly preceded by a
7733 minus sign (as produced by <tt>ct.widen(c)</tt> where <tt>c</tt> is '-' or in the range
7734 from '0' through '9', inclusive) stored in <tt>digits</tt>.
7739 objection has been raised:
7743 Some implementations interpret this to mean that a facet derived from
7744 <tt>ctype<wchar_t></tt> can provide its own member <tt>do_widen(char)</tt>
7745 which produces e.g. <tt>L'@'</tt> for the "widened" minus sign, and that the
7746 <tt>'@'</tt> symbol will appear in the resulting sequence of digits. Other
7747 implementations have assumed that one or more places in the standard permit the
7748 implementation to "hard-wire" <tt>L'-'</tt> as the "widened" minus sign. Are
7749 both interpretations permissible, or only one?
7753 [Plum ref _222612Y14]
7757 Furthermore: if <tt>ct.widen('9')</tt> produces <tt>L'X'</tt> (a non-digit), does a
7758 parse fail if a <tt>'9'</tt> appears in the subject string? [Plum ref _22263Y33]
7762 Kona (2007): Bill and Dietmar to provide proposed wording.
7767 post Bellevue: Bill adds:
7772 The Standard is clear that the minus sign stored in <tt>digits</tt> is <tt>ct.widen('-')</tt>.
7773 The subject string must contain characters <tt>c</tt> in the set <tt>[-0123456789]</tt>
7774 which are translated by <tt>ct.widen(c)</tt> calls before being stored in <tt>digits</tt>;
7775 the widened characters are not relevant to the parsing of the subject string.
7783 We agree with Bill's comment above,
7784 in line with the first of the interpretations offered in the issue.
7789 <p><b>Proposed resolution:</b></p>
7798 <h3><a name="668"></a>668. <tt>money_get</tt>'s empty minus sign</h3>
7799 <p><b>Section:</b> 22.4.6.1.2 [locale.money.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">Tentatively NAD</a>
7800 <b>Submitter:</b> Thomas Plum <b>Opened:</b> 2007-04-16 <b>Last modified:</b> 2009-05-23</p>
7801 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.money.get.virtuals">active issues</a> in [locale.money.get.virtuals].</p>
7802 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.money.get.virtuals">issues</a> in [locale.money.get.virtuals].</p>
7803 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD">Tentatively NAD</a> status.</p>
7804 <p><b>Discussion:</b></p>
7806 22.4.6.1.2 [locale.money.get.virtuals], para 3 says:
7810 If <tt>pos</tt> or <tt>neg</tt> is empty, the sign component is
7811 optional, and if no sign is detected, the result is given the sign
7812 that corresponds to the source of the empty string.
7816 The following objection has been raised:
7820 A <tt>negative_sign</tt> of "" means "there is no
7821 way to write a negative sign" not "any null sequence is a negative
7822 sign, so it's always there when you look for it".
7826 [Plum ref _222612Y32]
7830 Kona (2007): Bill to provide proposed wording and interpretation of existing wording.
7835 Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#669">669</a>.
7839 2009-05-17 Howard adds:
7845 I disagree that a <tt>negative_sign</tt> of "" means "there is no
7847 write a negative sign". The meaning requires the sentences of
7848 22.4.6.1.2 [locale.money.get.virtuals] p3 following that quoted above
7854 -3- ... If <tt>pos</tt> or <tt>neg</tt> is empty, the sign component is
7855 optional, and if no sign is detected, the result is given the sign that
7856 corresponds to the source of the empty string. Otherwise, the character
7857 in the indicated position must match the first character of <tt>pos</tt>
7858 or <tt>neg</tt>, and the result is given the corresponding sign. If the
7859 first character of <tt>pos</tt> is equal to the first character of
7860 <tt>neg</tt>, or if both strings are empty, the result is given a
7865 So a <tt>negative_sign</tt> of "" means "there is no way to write a
7866 negative sign" only when <tt>positive_sign</tt> is also "". However
7867 when <tt>negative_sign</tt> is "" and <tt>postive_sign.size() >
7868 0</tt>, then one writes a negative value by not writing the
7869 <tt>postive_sign</tt> in the position indicated by
7870 <tt>money_base::sign</tt>.
7874 <blockquote><pre>pattern = {symbol, sign, value, none}
7877 $123 // a negative value, using optional sign
7878 $+123 // a positive value
7879 $-123 // a parse error
7886 <blockquote><pre>pattern = {symbol, sign, value, none}
7889 $123 // a positive value, no sign possible
7890 $+123 // a parse error
7891 $-123 // a parse error
7896 And (regarding <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#669">669</a>):
7899 <blockquote><pre>pattern = {symbol, sign, value, none}
7902 $123 // a parse error, sign is mandatory
7903 $+123 // a parse error
7904 $-123 // a positive value
7909 The text seems both unambiguous and clear to me. I recommend NAD for
7910 both this issue and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#669">669</a>. However I would have no
7911 objection to adding examples such as those above.
7921 This discussion applies equally to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#669">669</a> (q.v.).
7922 Howard has added examples above,
7923 and recommends either NAD or a resolution that adds his (or similar) examples
7924 to the Working Paper.
7927 Alan would like to rewrite paragraph 3.
7930 We recommend moving to NAD.
7931 Anyone who feels strongly about adding the examples
7932 is invited to submit corresponding wording.
7933 We further recommend issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#669">669</a> be handled identically.
7939 <p><b>Proposed resolution:</b></p>
7948 <h3><a name="669"></a>669. Equivalent postive and negative signs in <tt>money_get</tt></h3>
7949 <p><b>Section:</b> 22.4.6.1.2 [locale.money.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">Tentatively NAD</a>
7950 <b>Submitter:</b> Thomas Plum <b>Opened:</b> 2007-04-16 <b>Last modified:</b> 2009-05-23</p>
7951 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.money.get.virtuals">active issues</a> in [locale.money.get.virtuals].</p>
7952 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.money.get.virtuals">issues</a> in [locale.money.get.virtuals].</p>
7953 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD">Tentatively NAD</a> status.</p>
7954 <p><b>Discussion:</b></p>
7956 22.4.6.1.2 [locale.money.get.virtuals], para 3 sentence 4 says:
7960 If the first character of <tt>pos</tt> is equal to the first character of <tt>neg</tt>,
7961 or if both strings are empty, the result is given a positive sign.
7965 One interpretation is that an input sequence must match either the
7966 positive pattern or the negative pattern, and then in either event it
7967 is interpreted as positive. The following objections has been raised:
7971 The input can successfully match only a positive sign, so the negative
7972 pattern is an unsuccessful match.
7976 [Plum ref _222612Y34, 222612Y51b]
7980 Bill to provide proposed wording and interpretation of existing wording.
7985 2009-05-17 See Howard's comments in related issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#668">668</a>.
7995 This discussion applies equally to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#668">668</a> (q.v.).
7996 Howard has added examples there,
7997 and recommends either NAD or a resolution that adds his (or similar) examples
7998 to the Working Paper.
8001 We recommend moving to NAD.
8002 Anyone who feels strongly about adding the examples
8003 is invited to submit corresponding wording.
8004 We further recommend issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#668">668</a> be handled identically.
8009 <p><b>Proposed resolution:</b></p>
8018 <h3><a name="671"></a>671. precision of hexfloat</h3>
8019 <p><b>Section:</b> 22.4.2.2.2 [facet.num.put.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
8020 <b>Submitter:</b> John Salmon <b>Opened:</b> 2007-04-20 <b>Last modified:</b> 2009-03-12</p>
8021 <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>
8022 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
8023 <p><b>Discussion:</b></p>
8025 I am trying to understand how TR1 supports hex float (%a) output.
8028 As far as I can tell, it does so via the following:
8031 8.15 Additions to header <locale> [tr.c99.locale]
8034 In subclause 22.4.2.2.2 [facet.num.put.virtuals], Table 58 Floating-point conversions, after
8036 floatfield == ios_base::scientific %E
8041 <blockquote><pre>floatfield == ios_base::fixed | ios_base::scientific && !uppercase %a
8042 floatfield == ios_base::fixed | ios_base::scientific %A 2
8045 [Note: The additional requirements on print and scan functions, later
8046 in this clause, ensure that the print functions generate hexadecimal
8047 floating-point fields with a %a or %A conversion specifier, and that
8048 the scan functions match hexadecimal floating-point fields with a %g
8049 conversion specifier. end note]
8052 Following the thread, in 22.4.2.2.2 [facet.num.put.virtuals], we find:
8055 For conversion from a floating-point type, if (flags & fixed) != 0 or
8056 if str.precision() > 0, then str.precision() is specified in the
8057 conversion specification.
8060 This would seem to imply that when floatfield == fixed|scientific, the
8061 precision of the conversion specifier is to be taken from
8062 str.precision(). Is this really what's intended? I sincerely hope
8063 that I'm either missing something or this is an oversight. Please
8064 tell me that the committee did not intend to mandate that hex floats
8065 (and doubles) should by default be printed as if by %.6a.
8069 Howard: I think the fundamental issue we overlooked was that with %f,
8070 %e, %g, the default precision was always 6. With %a the default
8071 precision is not 6, it is infinity. So for the first time, we need to
8072 distinguish between the default value of precision, and the precision
8079 <p><b>Proposed resolution:</b></p>
8085 Kona (2007): Robert volunteers to propose wording.
8093 <h3><a name="688"></a>688. reference_wrapper, cref unsafe, allow binding to rvalues</h3>
8094 <p><b>Section:</b> 20.7.5.1 [refwrap.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
8095 <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2007-05-10 <b>Last modified:</b> 2009-05-23</p>
8096 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#refwrap.const">issues</a> in [refwrap.const].</p>
8097 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
8098 <p><b>Discussion:</b></p>
8100 A <tt>reference_wrapper</tt> can be constructed from an rvalue, either by using
8101 the constructor, or via <tt>cref</tt> (and <tt>ref</tt> in some corner cases). This leads
8102 to a dangling reference being stored into the <tt>reference_wrapper</tt> object.
8103 Now that we have a mechanism to detect an rvalue, we can fix them to
8104 disallow this source of undefined behavior.
8108 Also please see the thread starting at c++std-lib-17398 for some good discussion on this subject.
8112 2009-05-09 Alisdair adds:
8118 Now that <tt>ref/cref</tt> are constained that <tt>T</tt> must be an <tt>ObjectType</tt>, I do not
8119 believe there is any risk of binding <tt>ref</tt> to a temporary (which would rely on
8120 deducing <tt>T</tt> to be an rvalue reference type)
8123 However, the problem for <tt>cref</tt> remains, so I recommend retaining that deleted
8129 2009-05-10 Howard adds:
8138 <blockquote><pre>template <class T> void ref(const T&& t) = delete;
8141 I believe this program will compile:
8144 <blockquote><pre>#include <functional>
8148 const A source() {return A();}
8152 std::reference_wrapper<const A> r = std::ref(source());
8158 <blockquote><pre>template <ObjectType T> reference_wrapper<T> ref(T& t);
8165 <blockquote><pre>ref(source())
8168 deduces <tt>T</tt> as <tt>const A</tt>, and so:
8171 <blockquote><pre>ref(const A& t)
8175 will bind to a temporary (tested with a pre-concepts rvalue-ref enabled compiler).
8178 Therefore I think we still need the ref-protection. I respectfully disagree with Alisdair's
8179 comment and am in favor of the proposed wording as it stands. Also, CWG 606
8180 (noted below) has now been "favorably" resolved.
8190 We agree with the proposed resolution.
8191 Move to Tentatively Ready.
8195 <p><b>Proposed resolution:</b></p>
8197 In 20.7 [function.objects], add the following two signatures to the synopsis:
8200 <blockquote><pre>template <class T> void ref(const T&& t) = delete;
8201 template <class T> void cref(const T&& t) = delete;
8207 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2292.html">N2292</a>
8208 addresses the first part of the resolution but not the second.
8213 Bellevue: Doug noticed problems with the current wording.
8218 post Bellevue: Howard and Peter provided revised wording.
8223 This resolution depends on a "favorable" resolution of CWG 606: that is,
8224 the "special deduction rule" is disabled with the const T&& pattern.
8232 <h3><a name="696"></a>696. <code>istream::operator>>(int&)</code> broken</h3>
8233 <p><b>Section:</b> 27.7.1.2.2 [istream.formatted.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
8234 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-06-23 <b>Last modified:</b> 2009-05-28</p>
8235 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.formatted.arithmetic">issues</a> in [istream.formatted.arithmetic].</p>
8236 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
8237 <p><b>Discussion:</b></p>
8239 From message c++std-lib-17897:
8242 The code shown in 27.7.1.2.2 [istream.formatted.arithmetic] as the "as if"
8243 implementation of the two arithmetic extractors that don't have a
8244 corresponding <code>num_get</code> interface (i.e., the
8245 <code>short</code> and <code>int</code> overloads) is subtly buggy in
8246 how it deals with <code>EOF</code>, overflow, and other similar
8247 conditions (in addition to containing a few typos).
8250 One problem is that if <code>num_get::get()</code> reaches the EOF
8251 after reading in an otherwise valid value that exceeds the limits of
8252 the narrower type (but not <code>LONG_MIN</code> or
8253 <code>LONG_MAX</code>), it will set <code><i>err</i></code> to
8254 <code>eofbit</code>. Because of the if condition testing for
8255 <code>(<i>err</i> == 0)</code>, the extractor won't set
8256 <code>failbit</code> (and presumably, return a bogus value to the
8260 Another problem with the code is that it never actually sets the
8261 argument to the extracted value. It can't happen after the call to
8262 <code>setstate()</code> since the function may throw, so we need to
8263 show when and how it's done (we can't just punt as say: "it happens
8264 afterwards"). However, it turns out that showing how it's done isn't
8265 quite so easy since the argument is normally left unchanged by the
8266 facet on error except when the error is due to a misplaced thousands
8267 separator, which causes <code>failbit</code> to be set but doesn't
8268 prevent the facet from storing the value.
8277 We believe this part of the Standard has been recently adjusted
8278 and that this issue was addressed during that rewrite.
8286 2009-05-28 Howard adds:
8292 I've moved this issue from Tentatively NAD to Open.
8296 The current wording of
8297 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2857.pdf">N2857</a>
8298 in 22.4.2.1.2 [facet.num.get.virtuals] p3, stage 3 appears to indicate that
8299 in parsing arithmetic types, the value is always set, but sometimes in addition
8300 to setting <tt>failbit</tt>.
8305 If there is a range error, the value is set to min or max, else
8308 if there is a conversion error, the value is set to 0, else
8311 if there is a grouping error, the value is set to whatever it would be if grouping were ignored, else
8314 the value is set to its error-free result.
8319 However there is a contradictory sentence in 22.4.2.1.2 [facet.num.get.virtuals] p1.
8323 27.7.1.2.2 [istream.formatted.arithmetic] should mimic the behavior of 22.4.2.1.2 [facet.num.get.virtuals]
8324 (whatever we decide that behavior is) for
8325 <tt>int</tt> and <tt>short</tt>, and currently does not. I believe that the
8326 correct code fragment should look like:
8329 <blockquote><pre>typedef num_get<charT,istreambuf_iterator<charT,traits> > numget;
8330 iostate err = ios_base::goodbit;
8332 use_facet<numget>(loc).get(*this, 0, *this, err, lval);
8333 if (lval < numeric_limits<int>::min())
8335 err |= ios_base::failbit;
8336 val = numeric_limits<int>::min();
8338 else if (lval > numeric_limits<int>::max())
8340 err |= ios_base::failbit;
8341 val = numeric_limits<int>::max();
8344 val = static_cast<int>(lval);
8350 <p><b>Proposed resolution:</b></p>
8352 Change 22.4.2.1.2 [facet.num.get.virtuals], p1:
8356 -1- <i>Effects:</i> Reads characters from <tt>in</tt>, interpreting them
8357 according to <tt>str.flags()</tt>, <tt>use_facet<ctype<charT>
8358 >(loc)</tt>, and <tt>use_facet< numpunct<charT>
8359 >(loc)</tt>, where <tt>loc</tt> is <tt>str.getloc()</tt>. <del>If an error
8360 occurs, <tt>val</tt> is unchanged; otherwise it is set to the resulting value.</del>
8364 Change 27.7.1.2.2 [istream.formatted.arithmetic], p2 and p3:
8368 <pre>operator>>(short& val);
8372 -2- The conversion occurs as if performed by the following code fragment (using the same notation as for
8373 the preceding code fragment):
8376 <blockquote><pre>typedef num_get<charT,istreambuf_iterator<charT,traits> > numget;
8377 iostate err = ios<del>tate</del><ins>_base</ins>::goodbit;
8379 use_facet<numget>(loc).get(*this, 0, *this, err, lval);
8382 else if (lval < numeric_limits<short>::min()
8383 || numeric_limits<short>::max() < lval)
8384 err = ios_base::failbit;</del>
8385 <ins>if (lval < numeric_limits<short>::min())
8387 err |= ios_base::failbit;
8388 val = numeric_limits<short>::min();
8390 else if (lval > numeric_limits<short>::max())
8392 err |= ios_base::failbit;
8393 val = numeric_limits<short>::max();
8396 val = static_cast<short>(lval);
8402 <pre>operator>>(int& val);
8406 -3- The conversion occurs as if performed by the following code fragment (using the same notation as for
8407 the preceding code fragment):
8410 <blockquote><pre>typedef num_get<charT,istreambuf_iterator<charT,traits> > numget;
8411 iostate err = ios<del>tate</del><ins>_base</ins>::goodbit;
8413 use_facet<numget>(loc).get(*this, 0, *this, err, lval);
8416 else if (lval < numeric_limits<int>::min()
8417 || numeric_limits<int>::max() < lval)
8418 err = ios_base::failbit;</del>
8419 <ins>if (lval < numeric_limits<int>::min())
8421 err |= ios_base::failbit;
8422 val = numeric_limits<int>::min();
8424 else if (lval > numeric_limits<int>::max())
8426 err |= ios_base::failbit;
8427 val = numeric_limits<int>::max();
8430 val = static_cast<int>(lval);
8443 <h3><a name="701"></a>701. assoc laguerre poly's</h3>
8444 <p><b>Section:</b> TR1 5.2.1.1 [tr.num.sf.Lnm] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">Tentatively NAD</a>
8445 <b>Submitter:</b> Christopher Crawford <b>Opened:</b> 2007-06-30 <b>Last modified:</b> 2009-05-23</p>
8446 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD">Tentatively NAD</a> status.</p>
8447 <p><b>Discussion:</b></p>
8449 I see that the definition the associated Laguerre
8450 polynomials TR1 5.2.1.1 [tr.num.sf.Lnm] has been corrected since
8451 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1687.pdf">N1687</a>.
8452 However, the draft standard only specifies ranks of integer value <tt>m</tt>,
8453 while the associated Laguerre polynomials are actually valid for real
8454 values of <tt>m > -1</tt>. In the case of non-integer values of <tt>m</tt>, the
8455 definition <tt><i>L</i><sub>n</sub><sup>(m)</sup> = (1/n!)e<sup>x</sup>x<sup>-m</sup> (d/dx)<sup>n</sup> (e<sup>-x</sup>x<sup>m+n</sup>)</tt>
8456 must be used, which also holds for integer values of <tt>m</tt>. See
8457 Abramowitz & Stegun, 22.11.6 for the general case, and 22.5.16-17 for
8458 the integer case. In fact fractional values are most commonly used in
8459 physics, for example to <tt>m = +/- 1/2</tt> to describe the harmonic
8460 oscillator in 1 dimension, and <tt>1/2, 3/2, 5/2, ...</tt> in 3
8464 If I am correct, the calculation of the more general case is no
8465 more difficult, and is in fact the function implemented in the GNU
8466 Scientific Library. I would urge you to consider upgrading the
8467 standard, either adding extra functions for real <tt>m</tt> or switching the
8468 current ones to <tt>double</tt>.
8477 We understand the issue, and have opted not to extend as recommended.
8485 <p><b>Proposed resolution:</b></p>
8494 <h3><a name="702"></a>702. Restriction in associated Legendre functions</h3>
8495 <p><b>Section:</b> TR1 5.2.1.2 [tr.num.sf.Plm] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">Tentatively NAD</a>
8496 <b>Submitter:</b> Christopher Crawford <b>Opened:</b> 2007-06-30 <b>Last modified:</b> 2009-05-23</p>
8497 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD">Tentatively NAD</a> status.</p>
8498 <p><b>Discussion:</b></p>
8500 One other small thing, in TR1 5.2.1.2 [tr.num.sf.Plm], the restriction should be
8501 <tt>|x| <= 1</tt>, not <tt>x >= 0</tt>.</p>
8509 The error has been corrected in the pending IS.
8517 <p><b>Proposed resolution:</b></p>
8526 <h3><a name="708"></a>708. Locales need to be per thread and updated for POSIX changes</h3>
8527 <p><b>Section:</b> 22 [localization] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
8528 <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2007-07-28 <b>Last modified:</b> 2008-09-17</p>
8529 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#localization">active issues</a> in [localization].</p>
8530 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#localization">issues</a> in [localization].</p>
8531 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
8532 <p><b>Discussion:</b></p>
8534 The POSIX "Extended API Set Part 4,"
8537 <a href="http://www.opengroup.org/sib/details.tpl?id=C065">http://www.opengroup.org/sib/details.tpl?id=C065</a>
8540 introduces extensions to the C locale mechanism that
8541 allow multiple concurrent locales to be used in the same application
8542 by introducing a type <tt>locale_t</tt> that is very similar to
8543 <tt>std::locale</tt>, and a number of <tt>_l</tt> functions that make use of it.
8546 The global locale (set by setlocale) is now specified to be per-
8547 process. If a thread does not call <tt>uselocale</tt>, the global locale is
8548 in effect for that thread. It can install a per-thread locale by
8549 using <tt>uselocale</tt>.
8552 There is also a nice <tt>querylocale</tt> mechanism by which one can obtain
8553 the name (such as "de_DE") for a specific <tt>facet</tt>, even for combined
8554 locales, with no <tt>std::locale</tt> equivalent.
8557 <tt>std::locale</tt> should be harmonized with the new POSIX <tt>locale_t</tt>
8558 mechanism and provide equivalents for <tt>uselocale</tt> and <tt>querylocale</tt>.
8562 Kona (2007): Bill and Nick to provide wording.
8567 San Francisco: Bill and Nick still intend to provide wording, but this
8568 is a part of the task to be addressed by the group that will look into
8569 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#860">860</a>.
8575 <p><b>Proposed resolution:</b></p>
8584 <h3><a name="711"></a>711. Contradiction in empty <tt>shared_ptr</tt></h3>
8585 <p><b>Section:</b> 20.8.13.2.5 [util.smartptr.shared.obs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
8586 <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2007-08-24 <b>Last modified:</b> 2008-06-18</p>
8587 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared.obs">issues</a> in [util.smartptr.shared.obs].</p>
8588 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
8589 <p><b>Discussion:</b></p>
8592 <a href="http://groups.google.com/group/comp.std.c++/browse_frm/thread/8e89dceb35cd7971">comp.std.c++</a>
8593 has identified a contradiction in the <tt>shared_ptr</tt> specification.
8598 [ <i>Note:</i> this constructor allows creation of an empty shared_ptr instance with a non-NULL stored pointer.
8603 after the aliasing constructor
8606 <blockquote><pre>template<class Y> shared_ptr(shared_ptr<Y> const& r, T *p);
8610 reflects the intent of
8611 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2351.htm">N2351</a>
8612 to, well, allow the creation of an empty <tt>shared_ptr</tt>
8613 with a non-NULL stored pointer.
8617 This is contradicted by the second sentence in the Returns clause of 20.8.13.2.5 [util.smartptr.shared.obs]:
8621 <pre>T* get() const;
8624 <i>Returns:</i> the stored pointer. Returns a null pointer if <tt>*this</tt> is empty.
8635 Adopt option 1 and move to review, not ready.
8638 There was a lot of confusion about what an empty <tt>shared_ptr</tt> is (the term
8639 isn't defined anywhere), and whether we have a good mental model for how
8640 one behaves. We think it might be possible to deduce what the definition
8641 should be, but the words just aren't there. We need to open an issue on
8642 the use of this undefined term. (The resolution of that issue might
8643 affect the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>.)
8646 The LWG is getting more uncomfortable with the aliasing proposal (N2351)
8647 now that we realize some of its implications, and we need to keep an eye
8648 on it, but there isn't support for removing this feature at this time.
8659 We heard from Peter Dimov, who explained his reason for preferring solution 1.
8662 Because it doesn't seem to add anything. It simply makes the behavior
8663 for p = 0 undefined. For programmers who don't create empty pointers
8664 with p = 0, there is no difference. Those who do insist on creating them
8665 presumably have a good reason, and it costs nothing for us to define the
8666 behavior in this case.
8669 The aliasing constructor is sharp enough as it is, so "protecting" users
8670 doesn't make much sense in this particular case.
8673 > Do you have a use case for r being empty and r being non-null?
8676 I have received a few requests for it from "performance-conscious"
8677 people (you should be familiar with this mindset) who don't like the
8678 overhead of allocating and maintaining a control block when a null
8679 deleter is used to approximate a raw pointer. It is obviously an "at
8680 your own risk", low-level feature; essentially a raw pointer behind a
8684 We could not agree upon a resolution to the issue; some of us thought
8685 that Peter's description above is supporting an undesirable behavior.
8691 <p><b>Proposed resolution:</b></p>
8693 In keeping the N2351 spirit and obviously my preference, change 20.8.13.2.5 [util.smartptr.shared.obs]:
8697 <pre>T* get() const;
8700 <i>Returns:</i> the stored pointer. <del>Returns a null pointer if <tt>*this</tt> is empty.</del>
8705 Alternative proposed resolution: (I won't be happy if we do this, but it's possible):
8709 Change 20.8.13.2.1 [util.smartptr.shared.const]:
8713 <pre>template<class Y> shared_ptr(shared_ptr<Y> const& r, T *p);
8717 <ins><i>Requires:</i> If <tt>r</tt> is empty, <tt>p</tt> shall be <tt>0</tt>.</ins>
8720 <del>[ <i>Note:</i> this constructor allows creation of an empty <tt>shared_ptr</tt>
8721 instance with a non-NULL stored pointer.
8722 -- <i>end note</i> ]</del>
8733 <h3><a name="716"></a>716. Production in [re.grammar] not actually modified</h3>
8734 <p><b>Section:</b> 28.14 [re.grammar] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
8735 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2007-08-31 <b>Last modified:</b> 2009-05-23</p>
8736 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
8737 <p><b>Discussion:</b></p>
8739 TR1 7.13 [tr.re.grammar]/3 and C++0x WP 28.14 [re.grammar]/3 say:
8744 The following productions within the ECMAScript grammar are modified as follows:
8747 <blockquote><pre>CharacterClass ::
8748 [ [lookahead ∉ {^}] ClassRanges ]
8755 This definition for <tt>CharacterClass</tt> appears to be exactly identical to that in ECMA-262.
8759 Was an actual modification intended here and accidentally omitted, or was this production accidentally included?
8768 We agree that what is specified is identical to what ECMA-262 specifies.
8769 Pete would like to take a bit of time to assess whether we had intended,
8770 but failed, to make a change.
8771 It would also be useful to hear from John Maddock on the issue.
8779 <p><b>Proposed resolution:</b></p>
8781 Remove this mention of the CharacterClass production.
8784 <blockquote><pre><del>CharacterClass ::
8785 [ [lookahead ∉ {^}] ClassRanges ]
8786 [ ^ ClassRanges ]</del>
8795 <h3><a name="718"></a>718. <tt>basic_string</tt> is not a sequence</h3>
8796 <p><b>Section:</b> 21.4 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
8797 <b>Submitter:</b> Bo Persson <b>Opened:</b> 2007-08-18 <b>Last modified:</b> 2008-03-12</p>
8798 <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>
8799 <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>
8800 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
8801 <p><b>Discussion:</b></p>
8803 Paragraph 21.4 [basic.string]/3 states:
8808 The class template <tt>basic_string</tt> conforms to the requirements for a
8809 Sequence (23.1.1) and for a Reversible Container (23.1).
8814 First of all, 23.2.3 [sequence.reqmts] is no longer "Sequence" but "Sequence container".
8815 Secondly, after the resent changes to containers (<tt>emplace</tt>, <tt>push_back</tt>,
8816 <tt>const_iterator</tt> parameters to <tt>insert</tt> and <tt>erase</tt>), <tt>basic_string</tt> is not
8817 even close to conform to the current requirements.
8827 <li>emplace, for example, may not make sense for strings. Is also likely suboptimal</li>
8828 <li>with concepts do we need to maintain string as sequence container?</li>
8829 <li>One approach might be to say something like: string is a sequence except it doesn't have these functions</li>
8832 <li>basic_string already has push_back</li>
8833 <li>const_iterator parameters to insert and erase should be added to basic_string</li>
8834 <li>this leaves emplace to handle -- we have the following options:
8836 <li>option 1: add it to string even though it's optional</li>
8837 <li>option 2: make emplace optional to sequences (move from table 89 to 90)</li>
8838 <li>option 3: say string not sequence (the proposal),</li>
8839 <li>option 4: add an exception to basic string wording.</li>
8843 General consensus is to suggest option 2.
8848 <p><b>Proposed resolution:</b></p>
8850 Remove this sentence, in recognition of the fact that <tt>basic_string</tt> is
8851 not just a <tt>vector</tt>-light for literal types, but something quite
8852 different, a string abstraction in its own right.
8860 <h3><a name="719"></a>719. <tt>std::is_literal</tt> type traits should be provided</h3>
8861 <p><b>Section:</b> 20.6 [meta] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
8862 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-08-25 <b>Last modified:</b> 2009-03-14</p>
8863 <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>
8864 <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>
8865 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
8866 <p><b>Discussion:</b></p>
8868 Since the inclusion of <tt>constexpr</tt> in the standard draft N2369 we have
8869 a new type category "literal", which is defined in 3.9 [basic.types]/p.11:
8874 -11- A type is a <i>literal</i> type if it is:
8877 <li>a scalar type; or</li>
8878 <li><p>a class type (clause 9) with</p>
8880 <li>a trivial copy constructor,</li>
8881 <li>a trivial destructor,</li>
8882 <li>at least one constexpr constructor other than the copy constructor,</li>
8883 <li>no virtual base classes, and</li>
8884 <li>all non-static data members and base classes of literal types; or</li>
8887 <li>an array of literal type.</li>
8892 I strongly suggest that the standard provides a type traits for
8893 literal types in 20.6.4.3 [meta.unary.prop] for several reasons:
8897 <li>To keep the traits in sync with existing types.</li>
8898 <li>I see many reasons for programmers to use this trait in template
8899 code to provide optimized template definitions for these types,
8901 <li>A user-provided definition of this trait is practically impossible
8902 to write portably.</li>
8906 The special problem of reason (c) is that I don't see currently a
8907 way to portably test the condition for literal class types:
8912 <li>at least one constexpr constructor other than the copy constructor,</li>
8919 Alisdair is considering preparing a paper listing a number of missing
8920 type traits, and feels that it might be useful to handle them all
8921 together rather than piecemeal. This would affect issue 719 and 750.
8922 These two issues should move to OPEN pending AM paper on type traits.
8928 <p><b>Proposed resolution:</b></p>
8930 In 20.6.2 [meta.type.synop] in the group "type properties",
8934 <blockquote><pre>template <class T> struct is_pod;
8941 <blockquote><pre>template <class T> struct is_literal;
8945 In 20.6.4.3 [meta.unary.prop], table Type Property Predicates, just
8946 below the line for the <tt>is_pod</tt> property add a new line:
8951 <th>Template</th><th>Condition</th><th>Preconditions</th>
8954 <td><tt>template <class T> struct is_literal;</tt></td>
8955 <td><tt>T</tt> is a literal type (3.9)</td>
8956 <td><tt>T</tt> shall be a complete type, an
8957 array of unknown bound, or
8958 (possibly cv-qualified) <tt>void</tt>.</td>
8968 <h3><a name="721"></a>721. <tt>wstring_convert</tt> inconsistensies</h3>
8969 <p><b>Section:</b> 22.3.3.2.2 [conversions.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
8970 <b>Submitter:</b> Bo Persson <b>Opened:</b> 2007-08-27 <b>Last modified:</b> 2008-09-18</p>
8971 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#conversions.string">active issues</a> in [conversions.string].</p>
8972 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#conversions.string">issues</a> in [conversions.string].</p>
8973 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
8974 <p><b>Discussion:</b></p>
8976 Paragraph 3 says that the <tt>Codecvt</tt> template parameter shall meet the
8977 requirements of <tt>std::codecvt</tt>, even though <tt>std::codecvt</tt> itself cannot
8978 be used (because of a protected destructor).
8982 How are we going to explain this code to beginning programmers?
8985 <blockquote><pre>template<class I, class E, class S>
8986 struct codecvt : std::codecvt<I, E, S>
8994 std::wstring_convert<codecvt<wchar_t, char, std::mbstate_t> > compiles_ok;
8996 std::wstring_convert<std::codecvt<wchar_t, char, std::mbstate_t> > not_ok;
9006 Bill will propose a resolution.
9010 <p><b>Proposed resolution:</b></p>
9019 <h3><a name="723"></a>723. <tt>basic_regex</tt> should be moveable</h3>
9020 <p><b>Section:</b> 28.9 [re.regex] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
9021 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-08-29 <b>Last modified:</b> 2009-03-13</p>
9022 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.regex">issues</a> in [re.regex].</p>
9023 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
9024 <p><b>Discussion:</b></p>
9026 <p><b>Addresses UK 316</b></p>
9029 According to the current state of the standard draft, the class
9030 template <tt>basic_regex</tt>, as described in 28.9 [re.regex]/3, is
9031 neither <tt>MoveConstructible</tt> nor <tt>MoveAssignable</tt>.
9032 IMO it should be, because typical regex state machines tend
9033 to have a rather large data quantum and I have seen several
9034 use cases, where a factory function returns regex values,
9035 which would take advantage of moveabilities.
9044 Needs wording for the semantics, the idea is agreed upon.
9048 Post Summit Daniel updated wording to reflect new "swap rules".
9053 <p><b>Proposed resolution:</b></p>
9055 In the class definition of <tt>basic_regex</tt>, just below 28.9 [re.regex]/3,
9056 perform the following changes:
9062 Just after <tt>basic_regex(const basic_regex&);</tt> insert:
9065 <blockquote><pre>basic_regex(basic_regex&&);
9070 Just after <tt>basic_regex& operator=(const basic_regex&);</tt> insert:
9072 <blockquote><pre>basic_regex& operator=(basic_regex&&);
9077 Just after <tt>basic_regex& assign(const basic_regex& that);</tt> insert:
9079 <blockquote><pre>basic_regex& assign(basic_regex&& that);
9084 In 28.9.2 [re.regex.construct], just after p.11 add the following
9085 new member definition:
9087 <blockquote><pre>basic_regex(basic_regex&& e);
9091 <i>Effects:</i> Move-constructs a <tt>basic_regex</tt> instance from <tt>e</tt>.
9094 <i>Postconditions:</i> <tt>flags()</tt> and <tt>mark_count()</tt> return <tt>e.flags()</tt> and
9095 <tt>e.mark_count()</tt>, respectively,
9096 that <tt>e</tt> had before construction, leaving
9097 <tt>e</tt> in a valid state with an unspecified value.
9100 <i>Throws:</i> nothing.
9107 Also in 28.9.2 [re.regex.construct], just after p.18 add the
9108 following new member definition:
9111 <blockquote><pre>basic_regex& operator=(basic_regex&& e);
9114 <i>Effects:</i> Returns the result of <tt>assign(std::move(e))</tt>.
9120 In 28.9.3 [re.regex.assign], just after p. 2 add the following new
9123 <blockquote><pre>basic_regex& assign(basic_regex&& rhs);
9127 <i>Effects:</i> Move-assigns a <tt>basic_regex</tt> instance from <tt>rhs</tt> and returns <tt>*this</tt>.
9130 <i>Postconditions:</i> <tt>flags()</tt> and <tt>mark_count()</tt> return <tt>rhs.flags()</tt>
9131 and <tt>rhs.mark_count()</tt>, respectively, that
9132 <tt>rhs</tt> had before assignment, leaving <tt>rhs</tt>
9133 in a valid state with an unspecified value.
9136 <i>Throws:</i> nothing.
9148 <h3><a name="726"></a>726. Missing <tt>regex_replace()</tt> overloads</h3>
9149 <p><b>Section:</b> 28.12.4 [re.alg.replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
9150 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2007-09-22 <b>Last modified:</b> 2008-06-18</p>
9151 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#re.alg.replace">active issues</a> in [re.alg.replace].</p>
9152 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.alg.replace">issues</a> in [re.alg.replace].</p>
9153 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
9154 <p><b>Discussion:</b></p>
9156 Two overloads of <tt>regex_replace()</tt> are currently provided:
9159 <blockquote><pre>template <class OutputIterator, class BidirectionalIterator,
9160 class traits, class charT>
9162 regex_replace(OutputIterator out,
9163 BidirectionalIterator first, BidirectionalIterator last,
9164 const basic_regex<charT, traits>& e,
9165 const basic_string<charT>& fmt,
9166 regex_constants::match_flag_type flags =
9167 regex_constants::match_default);
9169 template <class traits, class charT>
9170 basic_string<charT>
9171 regex_replace(const basic_string<charT>& s,
9172 const basic_regex<charT, traits>& e,
9173 const basic_string<charT>& fmt,
9174 regex_constants::match_flag_type flags =
9175 regex_constants::match_default);
9179 <li>Overloads taking <tt>const charT *</tt> are provided for <tt>regex_match()</tt> and
9180 <tt>regex_search()</tt>, but not <tt>regex_replace()</tt>. This is inconsistent.</li>
9182 <p>The absence of <tt>const charT *</tt> overloads prevents ordinary-looking code from compiling, such as:</p>
9184 <blockquote><pre>const string s("kitten");
9185 const regex r("en");
9186 cout << regex_replace(s, r, "y") << endl;
9190 The compiler error message will be something like "could not deduce
9191 template argument for 'const std::basic_string<_Elem> &' from 'const
9196 Users expect that anything taking a <tt>basic_string<charT></tt> can also take a
9197 <tt>const charT *</tt>. In their own code, when they write a function taking
9198 <tt>std::string</tt> (or <tt>std::wstring</tt>), they can pass a <tt>const char *</tt> (or <tt>const
9199 wchar_t *</tt>), thanks to <tt>basic_string</tt>'s implicit constructor. Because the
9200 regex algorithms are templated on <tt>charT</tt>, they can't rely on
9201 <tt>basic_string</tt>'s implicit constructor (as the compiler error message
9202 indicates, template argument deduction fails first).
9206 If a user figures out what the compiler error message means, workarounds
9207 are available - but they are all verbose. Explicit template arguments
9208 could be given to <tt>regex_replace()</tt>, allowing <tt>basic_string</tt>'s implicit
9209 constructor to be invoked - but <tt>charT</tt> is the last template argument, not
9210 the first, so this would be extremely verbose. Therefore, constructing
9211 a <tt>basic_string</tt> from each C string is the simplest workaround.
9216 There is an efficiency consideration: constructing <tt>basic_string</tt>s can
9217 impose performance costs that could be avoided by a library
9218 implementation taking C strings and dealing with them directly.
9219 (Currently, for replacement sources, C strings can be converted into
9220 iterator pairs at the cost of verbosity, but for format strings, there
9221 is no way to avoid constructing a <tt>basic_string</tt>.)
9231 We note that Boost already has these overloads. However, the proposed
9232 wording is provided only for 28.12.4 [re.alg.replace]; wording is needed for the synopsis
9233 as well. We also note that this has impact on <tt>match_results::format</tt>,
9234 which may require further overloads.
9239 <p><b>Proposed resolution:</b></p>
9241 Provide additional overloads for <tt>regex_replace()</tt>: one additional
9242 overload of the iterator-based form (taking <tt>const charT* fmt</tt>), and three
9243 additional overloads of the convenience form (one taking <tt>const charT*
9244 str</tt>, another taking <tt>const charT* fmt</tt>, and the third taking both <tt>const
9245 charT* str</tt> and <tt>const charT* fmt</tt>). 28.12.4 [re.alg.replace]:
9249 <pre>template <class OutputIterator, class BidirectionalIterator,
9250 class traits, class charT>
9252 regex_replace(OutputIterator out,
9253 BidirectionalIterator first, BidirectionalIterator last,
9254 const basic_regex<charT, traits>& e,
9255 const basic_string<charT>& fmt,
9256 regex_constants::match_flag_type flags =
9257 regex_constants::match_default);
9259 <ins>template <class OutputIterator, class BidirectionalIterator,
9260 class traits, class charT>
9262 regex_replace(OutputIterator out,
9263 BidirectionalIterator first, BidirectionalIterator last,
9264 const basic_regex<charT, traits>& e,
9266 regex_constants::match_flag_type flags =
9267 regex_constants::match_default);</ins>
9270 <pre>template <class traits, class charT>
9271 basic_string<charT>
9272 regex_replace(const basic_string<charT>& s,
9273 const basic_regex<charT, traits>& e,
9274 const basic_string<charT>& fmt,
9275 regex_constants::match_flag_type flags =
9276 regex_constants::match_default);
9278 <ins>template <class traits, class charT>
9279 basic_string<charT>
9280 regex_replace(const basic_string<charT>& s,
9281 const basic_regex<charT, traits>& e,
9283 regex_constants::match_flag_type flags =
9284 regex_constants::match_default);</ins>
9286 <ins>template <class traits, class charT>
9287 basic_string<charT>
9288 regex_replace(const charT* s,
9289 const basic_regex<charT, traits>& e,
9290 const basic_string<charT>& fmt,
9291 regex_constants::match_flag_type flags =
9292 regex_constants::match_default);</ins>
9294 <ins>template <class traits, class charT>
9295 basic_string<charT>
9296 regex_replace(const charT* s,
9297 const basic_regex<charT, traits>& e,
9299 regex_constants::match_flag_type flags =
9300 regex_constants::match_default);</ins>
9310 <h3><a name="727"></a>727. <tt>regex_replace()</tt> doesn't accept <tt>basic_string</tt>s with custom traits and allocators</h3>
9311 <p><b>Section:</b> 28.12.4 [re.alg.replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
9312 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2007-09-22 <b>Last modified:</b> 2009-05-23</p>
9313 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#re.alg.replace">active issues</a> in [re.alg.replace].</p>
9314 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.alg.replace">issues</a> in [re.alg.replace].</p>
9315 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
9316 <p><b>Discussion:</b></p>
9318 <tt>regex_match()</tt> and <tt>regex_search()</tt> take <tt>const basic_string<charT, ST,
9319 SA>&</tt>. <tt>regex_replace()</tt> takes <tt>const basic_string<charT>&</tt>. This prevents
9320 <tt>regex_replace()</tt> from accepting <tt>basic_string</tt>s with custom traits and
9330 Bill comments, "We need to look at the depth of this change."
9333 Pete remarks that we are here dealing with a convenience function
9334 that saves a user from calling the iterato-based overload.
9342 <p><b>Proposed resolution:</b></p>
9344 Overloads of <tt>regex_replace()</tt> taking <tt>basic_string</tt> should be additionally
9345 templated on <tt>class ST, class SA</tt> and take <tt>const basic_string<charT, ST,
9346 SA>&</tt>. Consistency with <tt>regex_match()</tt> and <tt>regex_search()</tt> would place
9347 <tt>class ST, class SA</tt> as the first template arguments; compatibility with
9348 existing code using TR1 and giving explicit template arguments to
9349 <tt>regex_replace()</tt> would place <tt>class ST, class SA</tt> as the last template
9358 <h3><a name="747"></a>747. We have 3 separate type traits to identify classes supporting no-throw operations</h3>
9359 <p><b>Section:</b> 20.6.4.3 [meta.unary.prop] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
9360 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2007-10-10 <b>Last modified:</b> 2008-03-11</p>
9361 <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>
9362 <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>
9363 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
9364 <p><b>Discussion:</b></p>
9366 We have 3 separate type traits to identify classes supporting no-throw
9367 operations, which are very useful when trying to provide exception safety
9368 guarantees. However, I'm not entirely clear on what the current wording
9369 requires of a conforming implementation. To quote from
9370 <tt>has_nothrow_default_constructor</tt>:
9373 or <tt>T</tt> is a class type with a default constructor that is known not to throw
9377 What level of magic do we expect to deduce if this is known?
9383 <blockquote><pre>struct test{
9389 Should I expect a conforming compiler to
9390 <tt>assert( has_nothrow_constructor<test>::value )</tt>
9393 Is this a QoI issue?
9396 Should I expect to 'know' only if-and-only-if there is an inline definition
9400 Should I never expect that to be true, and insist that the user supplies an
9401 empty throw spec if they want to assert the no-throw guarantee?
9404 It would be helpful to maybe have a footnote explaining what is required,
9405 but right now I don't know what to suggest putting in the footnote.
9408 (agreement since is that trivial ops and explicit no-throws are required.
9409 Open if QoI should be allowed to detect further)
9418 This looks like a QoI issue.
9419 In the case of trivial and nothrow it is known. Static analysis of the program is definitely into QoI.
9420 Move to OPEN. Need to talk to Core about this.
9424 <p><b>Proposed resolution:</b></p>
9433 <h3><a name="750"></a>750. The current definition for <tt>is_convertible</tt> requires that the type be
9434 implicitly convertible, so explicit constructors are ignored.</h3>
9435 <p><b>Section:</b> 20.6.5 [meta.rel] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
9436 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2007-10-10 <b>Last modified:</b> 2008-03-11</p>
9437 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta.rel">active issues</a> in [meta.rel].</p>
9438 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.rel">issues</a> in [meta.rel].</p>
9439 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
9440 <p><b>Discussion:</b></p>
9442 With the pending arrival of explicit conversion functions though, I'm
9443 wondering if we want an additional trait, <tt>is_explictly_convertible</tt>?
9452 Alisdair is considering preparing a paper listing a number of missing
9453 type traits, and feels that it might be useful to handle them all
9454 together rather than piecemeal. This would affect issue 719 and 750.
9455 These two issues should move to OPEN pending AM paper on type traits.
9459 <p><b>Proposed resolution:</b></p>
9468 <h3><a name="751"></a>751. change pass-by-reference members of <tt>vector<bool></tt> to pass-by-value?</h3>
9469 <p><b>Section:</b> 23.3.7 [vector.bool] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
9470 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2007-10-10 <b>Last modified:</b> 2008-09-22</p>
9471 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#vector.bool">active issues</a> in [vector.bool].</p>
9472 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector.bool">issues</a> in [vector.bool].</p>
9473 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
9474 <p><b>Discussion:</b></p>
9476 A number of vector<bool> members take const bool& as arguments.
9477 Is there any chance we could change them to pass-by-value or would I
9478 be wasting everyone's time if wrote up an issue?
9488 As we understand it, the original requester (Martin Sebor) would like
9489 for implementations to be permitted to pass-by-value. Alisdair suggests
9490 that if this is to be resolved, it should be resolved more generally,
9491 e.g. in other containers as well.
9494 We note that this would break ABI. However, we also suspect that this
9495 might be covered under the "as-if" rule in section 1.9.
9498 Many in the group feel that for vector<bool>, this is a "don't care",
9499 and that at this point in the process it's not worth the bandwidth.
9502 Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a> -- which was in ready status pre-Bellevue and is
9503 now in the working paper -- is related to this, though not a duplicate.
9506 Moving to Open with a task for Alisdair to craft a informative note to
9507 be put whereever appropriate in the WP. This note would clarify places
9508 where pass-by-const-ref can be transformed to pass-by-value under the
9520 This is really a clause 17 issue, rather than something specific to vector<bool>.
9523 Move to Open. Alisdair to provide a resolution. Alternately, Howard can
9524 close this as NAD and then open a new issue to handle the general issue
9525 (rather than the vector<bool> one).
9528 Howard: Haven't yet opened new issue. Lacking wording for it.
9533 <p><b>Proposed resolution:</b></p>
9542 <h3><a name="760"></a>760. The emplace issue</h3>
9543 <p><b>Section:</b> 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
9544 <b>Submitter:</b> Paolo Carlini <b>Opened:</b> 2007-11-11 <b>Last modified:</b> 2008-06-02</p>
9545 <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>
9546 <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>
9547 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
9548 <p><b>Discussion:</b></p>
9550 In an emplace member function the function parameter pack may be bound
9551 to a priori unlimited number of objects: some or all of them can be
9552 elements of the container itself. Apparently, in order to conform to the
9553 blanket statement 23.2 [container.requirements]/11, the implementation must check all of them for
9554 that possibility. A possible solution can involve extending the
9555 exception in 23.2 [container.requirements]/12 also to the emplace member. As a side note, the
9556 <tt>push_back</tt> and <tt>push_front</tt> member functions are luckily not affected by
9557 this problem, can be efficiently implemented anyway
9561 Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>
9572 The proposed addition (13) is partially redundant with the existing
9573 paragraph 12. Why was the qualifier "rvalues" added to paragraph 12? Why
9574 does it not cover subelements and pointers?
9577 Resolution: Alan Talbot to rework language, then set state to Review.
9583 <p><b>Proposed resolution:</b></p>
9585 Add after 23.2 [container.requirements]/12:
9590 -12- Objects passed to member functions of a container as rvalue references shall not be elements of that container. No
9591 diagnostic required.
9595 -13- Objects bound to the function parameter pack of the <tt>emplace</tt> member function shall not be elements or
9596 sub-objects of elements of the container. No diagnostic required.
9608 <h3><a name="765"></a>765. more on iterator validity</h3>
9609 <p><b>Section:</b> 24.2 [iterator.concepts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
9610 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-12-14 <b>Last modified:</b> 2009-03-09</p>
9611 <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>
9612 <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>
9613 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
9614 <p><b>Discussion:</b></p>
9617 Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#278">278</a>
9618 defines the meaning of the term "invalid iterator" as one that may be
9624 Consider the following code:
9627 <pre> std::deque<int> x, y;
9628 std::deque<int>::iterator i = x.end(), j = y.end();
9633 Given that <code>swap()</code> is required not to invalidate iterators
9634 and using the definition above, what should be the expected result of
9635 comparing <code>i</code> and <code>j</code> to <code>x.end()</code>
9636 and <code>y.end()</code>, respectively, after the <code>swap()</code>?
9641 I.e., is the expression below required to evaluate
9642 to <code>true</code>?
9645 <pre> i == y.end() && j == x.end()
9649 (There are at least two implementations where the expression
9650 returns <code>false</code>.)
9655 More generally, is the definition introduced in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#278">278</a> meant to
9656 make any guarantees about whether iterators actually point to the same
9657 elements or be associated with the same containers after a
9658 non-invalidating operation as they did before?
9663 Here's a motivating example intended to demonstrate the importance of
9667 <pre> Container x, y ({ 1, 2}); // pseudocode to initialize y with { 1, 2 }
9668 Container::iterator i = y.begin() + 1;
9669 Container::iterator j = y.end();
9675 <code>swap()</code> guarantees that <code>i</code> and <code>j</code>
9676 continue to be valid. Unless the spec says that even though they are
9677 valid they may no longer denote a valid range the code above must be
9678 well-defined. Expert opinions on this differ as does the behavior of
9679 popular implementations for some standard <code>Containers</code>.
9688 <p>Pablo: add a note to the last bullet of paragraph 11 of 23.1.1
9689 clarifying that the end() iterator doesn't refer to an element and that
9690 it can therefore be invalidated.
9696 [<i>Note:</i> The <tt>end()</tt> iterator does not refer to any element and can
9697 therefore be invalidated. <i>-- end note</i>]
9700 Howard will add this proposed wording to the issue and then move it to Review.
9711 Lawrence: suggestion: "Note: The <tt>end()</tt> iterator does not refer to any element"
9714 Walter: "Note: The <tt>end()</tt> iterator can nevertheless be invalidated,
9715 because it does not refer to any element."
9718 Nick: "The <tt>end()</tt> iterator does not refer to any element. It is therefore
9719 subject to being invalidated."
9722 Consensus: go with Nick
9725 With that update, Recommend Tentatively Ready.
9731 <p><b>Proposed resolution:</b></p>
9733 Add to 23.2.1 [container.requirements.general], p11:
9738 Unless otherwise specified (see 23.1.4.1, 23.1.5.1, 23.2.2.3, and
9739 23.2.6.4) all container types defined in this Clause meet the following
9740 additional requirements:
9745 no <tt>swap()</tt> function invalidates any references, pointers, or
9746 iterators referring to the elements of the containers being swapped.
9747 <ins>[<i>Note:</i> The <tt>end()</tt> iterator does not refer to any element. It is therefore
9748 subject to being invalidated. <i>-- end note</i>]</ins>
9758 <h3><a name="774"></a>774. Member swap undefined for most containers</h3>
9759 <p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
9760 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-01-14 <b>Last modified:</b> 2008-05-11</p>
9761 <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>
9762 <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>
9763 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
9764 <p><b>Discussion:</b></p>
9766 It appears most containers declare but do not define a member-swap
9771 This is unfortunate, as all overload the <tt>swap</tt> algorithm to call the
9772 member-swap function!
9773 (required for <tt>swappable</tt> guarantees [Table 37] and Container Requirements
9778 Note in particular that Table 87 gives semantics of <tt>a.swap(b)</tt> as <tt>swap(a,b)</tt>,
9779 yet for all containers we define <tt>swap(a,b)</tt> to call <tt>a.swap(b)</tt> - a circular
9784 A quick survey of clause 23 shows that the following containers provide a
9785 definition for member-swap:
9788 <blockquote><pre>array
9795 Whereas the following declare it, but do not define the semantics:
9798 <blockquote><pre>deque
9812 Suggested resolution:
9815 Provide a definition for each of the affected containers...
9824 Move to Open and ask Alisdair to provide wording.
9828 <p><b>Proposed resolution:</b></p>
9831 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2590.pdf">N2590</a>.
9839 <h3><a name="780"></a>780. <tt>std::merge()</tt> specification incorrect/insufficient</h3>
9840 <p><b>Section:</b> 25.5.4 [alg.merge] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
9841 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-01-25 <b>Last modified:</b> 2009-05-23</p>
9842 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
9843 <p><b>Discussion:</b></p>
9845 Though issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#283">283</a> has fixed many open issues, it seems that some are still open:
9849 Both 25.3.4 [lib.alg.merge] in 14882:2003 and 25.5.4 [alg.merge] in N2461
9850 have no Requires element and the Effects element contains some requirements,
9851 which is probably editorial. Worse is that:
9856 no assignment requirements are specified (neither implicit nor explicit).
9860 the effects clause just speaks of "merges", which is badly worded
9861 near to a circular definition.
9865 p. 2 mentions a range <tt>[first, last)</tt>, which is not defined by the
9866 function arguments or otherwise.
9870 p. 2 says "according to the ordering defined by comp" which is both
9872 this excludes the first variant with <) and redundant (because the
9873 following subordinate
9874 clause mentions comp again)
9879 Post Summit Alisdair adds:
9888 (where <tt>last</tt> is equal to <tt>next(result, distance(first1, last1) +
9889 distance(first2, last2))</tt>, such that resulting range will be sorted in
9890 non-decreasing order; that is, for every iterator <tt>i</tt> in <tt>[result,last)</tt> other
9891 than <tt>result</tt>, the condition <tt>*i < *prev(i)</tt> or, respectively, <tt>comp(*i,
9892 *prev(i))</tt> will be <tt>false</tt>.
9896 Note that this might still not be technically accurate in the case of
9897 <tt>InputIterators</tt>, depending on other resolutions working their way through the
9898 system (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1011">1011</a>).
9903 Post Summit Daniel adds:
9908 If we want to use <tt>prev</tt> and <tt>next</tt> here (Note: <tt>merge</tt>
9909 is sufficiently satisfied with <tt>InputIterator</tt>) we should instead *add* more to
9910 25 [algorithms]/6, but I can currently not propose any good wording for this.
9919 Pete points out the existing wording in [algorithms]/4
9920 that permits the use of + in algorithm specifications.
9923 Alisdair points out that that wording may not apply to input iterators.
9931 <p><b>Proposed resolution:</b></p>
9933 In 25.5.4 [alg.merge] replace p.1+ 2:
9938 <i>Effects:</i> <del>Merges</del> <ins>Copies all the elements of the</ins> two sorted ranges <tt>[first1,last1)</tt> and
9939 <tt>[first2,last2)</tt> into the range
9940 <del><tt>[result,result + (last1 - first1) + (last2 - first2))</tt></del>
9941 <ins><tt>[result, last)</tt> (where <tt>last</tt> is equal to <tt>result + (last1
9942 - first1) + (last2 - first2))</tt>, such that resulting range will be
9943 sorted in non-decreasing order; that is, for every iterator <tt>i</tt> in
9944 <tt>[result,last)</tt> other than <tt>result</tt>, the condition <tt>*i < *(i - 1)</tt> or,
9945 respectively, <tt>comp(*i, *(i - 1))</tt> will be false</ins>.
9949 <ins><i>Requires:</i></ins> The resulting range shall not overlap with either of the original ranges. <del>The list will be sorted in non-decreasing
9950 order according to the ordering defined by <tt>comp</tt>; that is, for every iterator <tt>i</tt> in
9951 <tt>[first,last)</tt> other than <tt>first</tt>, the condition <tt>*i < *(i - 1)</tt> or
9952 <tt>comp(*i, *(i - 1))</tt> will be false.</del>
9957 [N.B.: I attempted to reuse the wording style of <tt>inplace_merge</tt>,
9958 therefore proposing to
9959 insert ", respectively," between both predicate tests. This is no
9960 strictly necessary as
9961 other parts of <tt><algorithm></tt> show, just a matter of consistency]
9970 <h3><a name="785"></a>785. Random Number Requirements in TR1</h3>
9971 <p><b>Section:</b> TR1 5.1.4.5 [tr.rand.eng.disc], TR1 5.1.4.6 [tr.rand.eng.xor] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">Tentatively NAD</a>
9972 <b>Submitter:</b> John Maddock <b>Opened:</b> 2008-01-15 <b>Last modified:</b> 2009-05-23</p>
9973 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD">Tentatively NAD</a> status.</p>
9974 <p><b>Discussion:</b></p>
9976 Table 16 of TR1 requires that all Pseudo Random Number generators have a
9979 <blockquote><pre>seed(integer-type s)
9983 member function that is equivalent to:
9986 <blockquote><pre>mygen = Generator(s)
9990 But the generators <tt>xor_combine</tt> and <tt>discard_block</tt> have no such seed member, only the
9993 <blockquote><pre>template <class Gen>
9998 member, which will not accept an integer literal as an argument: something that appears to violate the intent of Table 16.
10002 So... is this a bug in TR1?
10005 <p>This is a real issue BTW, since the Boost implementation does adhere
10006 to the requirements of Table 16, while at least one commercial
10007 implementation does not and follows a strict adherence to sections
10008 5.1.4.5 and 5.1.4.6 instead.
10017 Both engines do have the necessary
10018 constructor, therefore the omission of the <tt>seed()</tt> member
10019 functions appears to be an oversight.
10023 Post Summit Daniel adds:
10028 Recommend NAD: <tt>xor_combine</tt> does no longer exist and <tt>discard_block[_engine]</tt>
10029 has now the required seed overload accepting a <tt>result_type</tt>, which shall be an
10030 unsigned integral type.
10038 Move to NAD as recommended.
10042 <p><b>Proposed resolution:</b></p>
10052 <h3><a name="788"></a>788. ambiguity in [istream.iterator]</h3>
10053 <p><b>Section:</b> 24.6.1 [istream.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
10054 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2008-02-06 <b>Last modified:</b> 2009-03-14</p>
10055 <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>
10056 <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>
10057 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
10058 <p><b>Discussion:</b></p>
10060 <p><b>Addresses UK 287</b></p>
10064 It is not clear what the initial state of an <tt>istream_iterator</tt> should be. Is
10065 _value_ initialized by reading the stream, or default/value initialized? If
10066 it is initialized by reading the stream, what happens if the initialization
10067 is deferred until first dereference, when ideally the iterator value should
10068 have been that of an end-of-stream iterator which is not safely
10073 Recommendation: Specify _value_ is initialized by reading the stream, or
10074 the iterator takes on the end-of-stream value if the stream is empty.
10079 The description of how an istream_iterator object becomes an
10080 end-of-stream iterator is a) ambiguous and b) out of date WRT
10081 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#468">468</a>:
10085 <tt>istream_iterator</tt> reads (using <tt>operator>></tt>) successive elements from the
10086 input stream for which it was constructed. After it is constructed, and
10087 every time <tt>++</tt> is used, the iterator reads and stores a value of <tt>T</tt>. If
10088 the end of stream is reached (<tt>operator void*()</tt> on the stream returns
10089 <tt>false</tt>), the iterator becomes equal to the <i>end-of-stream</i> iterator value.
10090 The constructor with no arguments <tt>istream_iterator()</tt> always constructs
10091 an end of stream input iterator object, which is the only legitimate
10092 iterator to be used for the end condition. The result of <tt>operator*</tt> on an
10093 end of stream is not defined. For any other iterator value a <tt>const T&</tt> is
10094 returned. The result of <tt>operator-></tt> on an end of stream is not defined.
10095 For any other iterator value a <tt>const T*</tt> is returned. It is impossible to
10096 store things into istream iterators. The main peculiarity of the istream
10097 iterators is the fact that <tt>++</tt> operators are not equality preserving,
10098 that is, <tt>i == j</tt> does not guarantee at all that <tt>++i == ++j</tt>. Every time <tt>++</tt>
10099 is used a new value is read.
10103 <tt>istream::operator void*()</tt> returns null if <tt>istream::fail()</tt> is <tt>true</tt>,
10104 otherwise non-null. <tt>istream::fail()</tt> returns <tt>true</tt> if <tt>failbit</tt> or
10105 <tt>badbit</tt> is set in <tt>rdstate()</tt>. Reaching the end of stream doesn't
10106 necessarily imply that <tt>failbit</tt> or <tt>badbit</tt> is set (e.g., after
10107 extracting an <tt>int</tt> from <tt>stringstream("123")</tt> the stream object will
10108 have reached the end of stream but <tt>fail()</tt> is <tt>false</tt> and <tt>operator
10109 void*()</tt> will return a non-null value).
10113 Also I would prefer to be explicit about calling <tt>fail()</tt> here
10114 (there is no <tt>operator void*()</tt> anymore.)
10123 Moved from Ready to Open for the purposes of using this issue to address NB UK 287.
10128 <p><b>Proposed resolution:</b></p>
10130 Change 24.6.1 [istream.iterator]/1:
10134 <tt>istream_iterator</tt> reads (using <tt>operator>></tt>) successive elements from the
10135 input stream for which it was constructed. After it is constructed, and
10136 every time <tt>++</tt> is used, the iterator reads and stores a value of <tt>T</tt>. If
10137 <del>the end of stream is reached</del> <ins>the iterator fails to read and store a value of <tt>T</tt></ins>
10138 (<tt><del>operator void*()</del> <ins>fail()</ins></tt> on the stream returns
10139 <tt><del>false</del> <ins>true</ins></tt>), the iterator becomes equal to the <i>end-of-stream</i> iterator value.
10140 The constructor with no arguments <tt>istream_iterator()</tt> always constructs
10141 an end of stream input iterator object, which is the only legitimate
10142 iterator to be used for the end condition. The result of <tt>operator*</tt> on an
10143 end of stream is not defined. For any other iterator value a <tt>const T&</tt> is
10144 returned. The result of <tt>operator-></tt> on an end of stream is not defined.
10145 For any other iterator value a <tt>const T*</tt> is returned. It is impossible to
10146 store things into istream iterators. The main peculiarity of the istream
10147 iterators is the fact that <tt>++</tt> operators are not equality preserving,
10148 that is, <tt>i == j</tt> does not guarantee at all that <tt>++i == ++j</tt>. Every time <tt>++</tt>
10149 is used a new value is read.
10157 <h3><a name="801"></a>801. <tt>tuple</tt> and <tt>pair</tt> trivial members</h3>
10158 <p><b>Section:</b> 20.5 [tuple] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
10159 <b>Submitter:</b> Lawrence Crowl <b>Opened:</b> 2008-02-18 <b>Last modified:</b> 2009-05-30</p>
10160 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple">issues</a> in [tuple].</p>
10161 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
10162 <p><b>Discussion:</b></p>
10164 Classes with trivial special member functions are inherently more
10165 efficient than classes without such functions. This efficiency is
10166 particularly pronounced on modern ABIs that can pass small classes
10167 in registers. Examples include value classes such as complex numbers
10168 and floating-point intervals. Perhaps more important, though, are
10169 classes that are simple collections, like <tt>pair</tt> and <tt>tuple</tt>. When the
10170 parameter types of these classes are trivial, the <tt>pair</tt>s and <tt>tuple</tt>s
10171 themselves can be trivial, leading to substantial performance wins.
10174 The current working draft make specification of trivial functions
10175 (where possible) much easer through <tt>default</tt>ed and <tt>delete</tt>d functions.
10176 As long as the semantics of defaulted and deleted functions match
10177 the intended semantics, specification of defaulted and deleted
10178 functions will yield more efficient programs.
10181 There are at least two cases where specification of an explicitly
10182 defaulted function may be desirable.
10185 First, the <tt>std::pair</tt> template has a non-trivial default constructor,
10186 which prevents static initialization of the pair even when the
10187 types are statically initializable. Changing the definition to
10190 <blockquote><pre>pair() = default;
10191 </pre></blockquote>
10194 would enable such initialization. Unfortunately, the change is
10195 not semantically neutral in that the current definition effectively
10196 forces value initialization whereas the change would not value
10197 initialize in some contexts.
10201 ** Does the committee confirm that forced value initialization
10202 was the intent? If not, does the committee wish to change the
10203 behavior of <tt>std::pair</tt> in C++0x?
10206 Second, the same default constructor issue applies to <tt>std::tuple</tt>.
10207 Furthermore, the <tt>tuple</tt> copy constructor is current non-trivial,
10208 which effectively prevents passing it in registers. To enable
10209 passing <tt>tuples</tt> in registers, the copy constructor should be
10210 make explicitly <tt>default</tt>ed. The new declarations are:
10213 <blockquote><pre>tuple() = default;
10214 tuple(const tuple&) = default;
10215 </pre></blockquote>
10218 This changes is not implementation neutral. In particular, it
10219 prevents implementations based on pointers to the parameter
10220 types. It does however, permit implementations using the
10221 parameter types as bases.
10224 ** How does the committee wish to trade implementation
10225 efficiency versus implementation flexibility?
10235 General agreement; the first half of the issue is NAD.
10238 Before voting on the second half, it was agreed that a "Strongly Favor"
10239 vote meant support for trivial tuples (assuming usual requirements met),
10240 even at the expense of other desired qualities. A "Weakly Favor" vote
10241 meant support only if not at the expense of other desired qualities.
10244 Concensus: Go forward, but not at expense of other desired qualities.
10247 It was agreed to Alisdair should fold this work in with his other
10248 pair/tuple action items, above, and that issue 801 should be "open", but
10249 tabled until Alisdair's proposals are disposed of.
10254 2009-05-27 Daniel adds:
10259 This is partly solved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1117">1117</a>.
10263 <p><b>Proposed resolution:</b></p>
10272 <h3><a name="810"></a>810. Missing traits dependencies in operational semantics of extended manipulators</h3>
10273 <p><b>Section:</b> 27.7.4 [ext.manip] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
10274 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-03-01 <b>Last modified:</b> 2009-05-23</p>
10275 <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>
10276 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
10277 <p><b>Discussion:</b></p>
10279 The recent draft (as well as the original proposal n2072) uses an
10280 operational semantic
10281 for <tt>get_money</tt> ([ext.manip]/4) and <tt>put_money</tt> ([ext.manip]/6), which uses
10284 <blockquote><pre>istreambuf_iterator<charT>
10285 </pre></blockquote>
10291 <blockquote><pre>ostreambuf_iterator<charT>
10292 </pre></blockquote>
10295 resp, instead of the iterator instances, with explicitly provided
10296 traits argument (The operational semantic defined by <tt>f</tt> is also traits
10297 dependent). This is an obvious oversight because both <tt>*stream_buf</tt>
10298 c'tors expect a <tt>basic_streambuf<charT,traits></tt> as argument.
10301 The same problem occurs within the <tt>get_time</tt> and <tt>put_time</tt> semantic
10302 where additional to the problem we
10303 have an editorial issue in <tt>get_time</tt> (<tt>streambuf_iterator</tt> instead of
10304 <tt>istreambuf_iterator</tt>).
10313 This appears to be an issue of presentation.
10316 We agree with the proposed resolution.
10317 Move to Tentatively Ready.
10322 <p><b>Proposed resolution:</b></p>
10324 In 27.7.4 [ext.manip]/4 within function <tt>f</tt> replace the first line
10327 <blockquote><pre>template <class charT, class traits, class moneyT>
10328 void f(basic_ios<charT, traits>& str, moneyT& mon, bool intl) {
10329 typedef istreambuf_iterator<charT<ins>, traits</ins>> Iter;
10331 </pre></blockquote>
10334 In 27.7.4 [ext.manip]/5 remove the first template <tt>charT</tt> parameter:
10337 <blockquote><pre>template <<del>class charT, </del>class moneyT> unspecified put_money(const moneyT& mon, bool intl = false<ins>)</ins>;
10338 </pre></blockquote>
10341 In 27.7.4 [ext.manip]/6 within function <tt>f</tt> replace the first line
10344 <blockquote><pre>template <class charT, class traits, class moneyT>
10345 void f(basic_ios<charT, traits>& str, const moneyT& mon, bool intl) {
10346 typedef ostreambuf_iterator<charT<ins>, traits</ins>> Iter;
10348 </pre></blockquote>
10351 In 27.7.4 [ext.manip]/8 within function <tt>f</tt> replace the first line
10354 <blockquote><pre>template <class charT, class traits>
10355 void f(basic_ios<charT, traits>& str, struct tm *tmb, const charT *fmt) {
10356 typedef <ins>i</ins>streambuf_iterator<charT<ins>, traits</ins>> Iter;
10358 </pre></blockquote>
10361 In 27.7.4 [ext.manip]/10 within function <tt>f</tt> replace the first line
10364 <blockquote><pre>template <class charT, class traits>
10365 void f(basic_ios<charT, traits>& str, const struct tm *tmb, const charT *fmt) {
10366 typedef ostreambuf_iterator<charT<ins>, traits</ins>> Iter;
10368 </pre></blockquote>
10371 In 27.7 [iostream.format], Header <tt><iomanip></tt> synopsis change:
10374 <blockquote><pre>template <<del>class charT, </del>class moneyT> T8 put_money(const moneyT& mon, bool intl = false);
10375 </pre></blockquote>
10382 <h3><a name="814"></a>814. <tt>vector<bool>::swap(reference, reference)</tt> not defined</h3>
10383 <p><b>Section:</b> 23.3.7 [vector.bool] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
10384 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-03-17 <b>Last modified:</b> 2009-05-23</p>
10385 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#vector.bool">active issues</a> in [vector.bool].</p>
10386 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector.bool">issues</a> in [vector.bool].</p>
10387 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
10388 <p><b>Discussion:</b></p>
10390 <tt>vector<bool>::swap(reference, reference)</tt> has no definition.
10399 Move to Open. Alisdair to provide a resolution.
10403 Post Summit Daniel provided wording.
10412 We agree with the proposed resolution.
10413 Move to Tentatively Ready.
10417 <p><b>Proposed resolution:</b></p>
10419 Just after 23.3.7 [vector.bool]/5 add the following prototype and description:
10424 <ins>static void swap(reference x, reference y);</ins>
10428 <ins>-6- <i>Effects:</i> Exchanges the contents of <tt>x</tt> and <tt>y</tt> as-if</ins> by:
10430 <blockquote><pre><ins>
10434 </ins></pre></blockquote>
10443 <h3><a name="815"></a>815. <tt>std::function</tt> and <tt>reference_closure</tt> do not use perfect forwarding</h3>
10444 <p><b>Section:</b> 20.7.16.2.4 [func.wrap.func.inv] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
10445 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-03-16 <b>Last modified:</b> 2009-06-01</p>
10446 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
10447 <p><b>Discussion:</b></p>
10449 <tt>std::function</tt> and <tt>reference_closure</tt> should use "perfect forwarding" as
10450 described in the rvalue core proposal.
10459 According to Doug Gregor, as far as <tt>std::function</tt> is concerned, perfect
10460 forwarding can not be obtained because of type erasure. Not everyone
10461 agreed with this diagnosis of forwarding.
10465 2009-05-01 Howard adds:
10471 Sebastian Gesemann brought to my attention that the <tt>CopyConstructible</tt>
10472 requirement on <tt>function</tt>'s <tt>ArgTypes...</tt> is an unnecessary
10476 <blockquote><pre>template<Returnable R, <b>CopyConstructible</b>... ArgTypes>
10477 class function<R(ArgTypes...)>
10479 </pre></blockquote>
10482 On further investigation, this complaint seemed to be the same
10483 issue as this one. I believe the reason <tt>CopyConstructible</tt> was put
10484 on <tt>ArgTypes</tt> in the first place was because of the nature of the
10485 <i>invoke</i> member:
10488 <blockquote><pre>template<class R, class ...ArgTypes>
10490 function<R(ArgTypes...)>::operator()(ArgTypes... arg) const
10493 throw bad_function_call();
10494 return (*f_)(arg...);
10496 </pre></blockquote>
10499 However now with rvalue-refs, "by value" no longer implies <tt>CopyConstructible</tt>
10500 (as Sebastian correctly points out). If rvalue arguments are supplied, <tt>MoveConstructible</tt>
10501 is sufficient. Furthermore, the constraint need not be applied in <tt>function</tt>
10502 if I understand correctly. Rather the client must apply the proper constraints
10503 at the call site. Therefore, at the very least, I recommend that <tt>CopyConstructible</tt>
10504 be removed from the template class <tt>function</tt>.
10508 Furthermore we need to mandate that the <i>invoker</i> is coded as:
10511 <blockquote><pre>template<class R, class ...ArgTypes>
10513 function<R(ArgTypes...)>::operator()(ArgTypes... arg) const
10516 throw bad_function_call();
10517 return (*f_)(<b>std::forward<ArgTypes>(</b>arg<b>)</b>...);
10519 </pre></blockquote>
10522 Note that <tt>ArgTypes&&</tt> (the "perfect forwarding signature") is not
10523 appropriate here as this is not a deduced context for <tt>ArgTypes</tt>. Instead
10524 the client's arguments must implicitly convert to the non-deduced <tt>ArgType</tt>
10525 type. Catching these arguments by value makes sense to enable decay.
10529 Next <tt>forward</tt> is used to move the <tt>ArgTypes</tt> as efficiently as
10530 possible, and also with minimum requirements (not <tt>CopyConstructible</tt>)
10531 to the type-erased functor. For object types, this will be a <tt>move</tt>. For
10532 reference type <tt>ArgTypes</tt>, this will be a copy. The end result <em>must</em> be
10533 that the following is a valid program:
10536 <blockquote><pre>#include <functional>
10537 #include <memory>
10538 #include <cassert>
10540 std::unique_ptr<int>
10541 f(std::unique_ptr<int> p, int& i)
10544 return std::move(p);
10550 std::function<std::unique_ptr<int>(std::unique_ptr<int>,
10552 std::unique_ptr<int> p = g(std::unique_ptr<int>(new int(1)), i);
10556 </pre></blockquote>
10559 Tested in pre-concepts rvalue-ref-enabled compiler.
10564 In the example above, the first <tt>ArgType</tt> is <tt>unique_ptr<int></tt>
10565 and the second <tt>ArgType</tt> is <tt>int&</tt>. Both <em>must</em> work!
10571 2009-05-27 Daniel adds:
10577 in the 2009-05-01 comment of above mentioned issue Howard
10582 Recommends to replace the <tt>CopyConstructible</tt> requirement by a
10583 <tt>MoveConstructible</tt> requirement
10586 Says: "Furthermore, the constraint need not be applied in <tt>function</tt> if I
10587 understand correctly. Rather the client must apply the proper constraints
10592 I'm fine with (a), but I think comment (b) is incorrect, at least in the
10593 sense I read these sentences. Let's look at Howard's example code:
10596 <blockquote><pre>function<R(ArgTypes...)>::operator()(ArgTypes... arg) const
10599 throw bad_function_call();
10600 return (*f_)(std::forward<ArgTypes>(arg)...);
10602 </pre></blockquote>
10605 In the constrained scope of this <tt>operator()</tt> overload the expression
10606 "<tt>(*f_)(std::forward<ArgTypes>(arg)...)</tt>" must be valid. How can it
10607 do so, if <tt>ArgTypes</tt> aren't at least <tt>MoveConstructible</tt>?
10613 <p><b>Proposed resolution:</b></p>
10622 <h3><a name="816"></a>816. Should <tt>bind()</tt>'s returned functor have a nofail copy ctor when <tt>bind()</tt> is nofail?</h3>
10623 <p><b>Section:</b> 20.7.12.1.3 [func.bind.bind] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
10624 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2008-02-08 <b>Last modified:</b> 2009-05-23</p>
10625 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#func.bind.bind">active issues</a> in [func.bind.bind].</p>
10626 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.bind.bind">issues</a> in [func.bind.bind].</p>
10627 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
10628 <p><b>Discussion:</b></p>
10630 Library Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a> notes that <tt>bind(f, t1, ..., tN)</tt>
10631 should be nofail when <tt>f, t1, ..., tN</tt> have nofail copy ctors.
10634 However, no guarantees are provided for the copy ctor of the functor
10635 returned by <tt>bind()</tt>. (It's guaranteed to have a copy ctor, which can
10636 throw implementation-defined exceptions: <tt>bind()</tt> returns a forwarding
10637 call wrapper, TR1 3.6.3/2. A forwarding call wrapper is a call wrapper,
10638 TR1 3.3/4. Every call wrapper shall be CopyConstructible, TR1 3.3/4.
10639 Everything without an exception-specification may throw
10640 implementation-defined exceptions unless otherwise specified, C++03
10644 Should the nofail guarantee requested by Library Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a> be extended
10645 to cover both calling <tt>bind()</tt> and copying the returned functor?
10654 <tt>tuple</tt> construction should probably have a similar guarantee.
10663 Howard to provide wording.
10667 Post Summit, Anthony provided wording.
10676 Part of all of this issue appears to be rendered moot
10677 by the proposed resolution to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#817">817</a> (q.v.).
10678 We recommend the issues be considered simultaneously
10679 (or possibly even merged)
10680 to ensure there is no overlap.
10681 Move to Open, and likewise for issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#817">817</a>.
10685 <p><b>Proposed resolution:</b></p>
10687 Add a new sentence to the end of paragraphs 2 and 4 of 20.7.12.1.3 [func.bind.bind]:
10692 -2- <i>Returns:</i> A forwarding call wrapper <tt>g</tt> with a weak result type (20.6.2). The effect of <tt>g(u1, u2,
10693 ..., uM)</tt> shall be <tt><i>INVOKE</i>(f, v1, v2, ..., vN, Callable<F cv,V1, V2, ..., VN>::result_type)</tt>, where <i>cv</i>
10694 represents the <i>cv</i>-qualifiers of <tt>g</tt> and the values and types of the bound arguments
10695 <tt>v1, v2, ..., vN</tt> are determined as specified below.
10696 <ins>The copy constructor and move constructor of the forwarding call wrapper shall throw an
10697 exception if and only if the corresponding constructor of <tt>F</tt> or any of the types
10698 in <tt>BoundArgs...</tt> throw an exception.</ins>
10702 -4- <i>Returns:</i> A forwarding call wrapper <tt>g</tt> with a nested type <tt>result_type</tt> defined as a synonym
10703 for <tt>R</tt>. The effect of <tt>g(u1, u2, ..., uM)</tt> shall be <tt><i>INVOKE</i>(f, v1, v2, ..., vN, R)</tt>, where the
10704 values and types of the bound arguments <tt>v1, v2, ..., vN</tt> are determined as specified below.
10705 <ins>The copy constructor and move constructor of the forwarding call wrapper shall throw an
10706 exception if and only if the corresponding constructor of <tt>F</tt> or any of the types
10707 in <tt>BoundArgs...</tt> throw an exception.</ins>
10717 <h3><a name="817"></a>817. <tt>bind</tt> needs to be moved</h3>
10718 <p><b>Section:</b> 20.7.12.1.3 [func.bind.bind] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
10719 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2008-03-17 <b>Last modified:</b> 2009-05-23</p>
10720 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#func.bind.bind">active issues</a> in [func.bind.bind].</p>
10721 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.bind.bind">issues</a> in [func.bind.bind].</p>
10722 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
10723 <p><b>Discussion:</b></p>
10724 <p><b>Addresses US 72, JP 38 and DE 21</b></p>
10727 The functor returned by <tt>bind()</tt> should have a move constructor that
10728 requires only move construction of its contained functor and bound arguments.
10729 That way move-only functors can be passed to objects such as <tt>thread</tt>.
10732 This issue is related to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#816">816</a>.
10740 <tt>bind</tt> should support move-only functors and bound arguments.
10749 add the move requirement for bind's return type.
10752 For example, assume following <tt>th1</tt> and <tt>th2</tt>,
10755 <blockquote><pre>void f(vector<int> v) { }
10757 vector<int> v{ ... };
10758 thread th1([v]{ f(v); });
10759 thread th2(bind(f, v));
10760 </pre></blockquote>
10763 When function object are set to thread, <tt>v</tt> is moved to <tt>th1</tt>'s lambda
10764 expression in a Move Constructor of lambda expression because <tt>th1</tt>'s lambda
10765 expression has a Move Constructor. But <tt>bind</tt> of <tt>th2</tt>'s
10766 return type doesn't have the requirement of Move, so it may not
10770 Add the requirement of move to get rid of this useless copy.
10773 And also, add the <tt>MoveConstructible</tt> as well as <tt>CopyConstructible</tt>.
10782 The specification for bind claims twice that "the values and types for
10783 the bound arguments v1, v2, ..., vN are determined as specified below".
10784 No such specification appears to exist.
10793 Howard to provide wording.
10797 Post Summit Alisdair and Howard provided wording.
10803 Several issues are being combined in this resolution. They are all touching the
10804 same words so this is an attempt to keep one issue from stepping on another, and
10805 a place to see the complete solution in one place.
10810 <tt>bind</tt> needs to be "moved".
10813 20.7.12.1.3 [func.bind.bind]/p3, p6 and p7 were accidently removed from N2798.
10816 Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#929">929</a> argues for a way to pass by && for
10817 efficiency but retain the decaying behavior of pass by value for the
10818 <tt>thread</tt> constructor. That same solution is applicable here.
10829 We were going to recommend moving this issue to Tentatively Ready
10830 until we noticed potential overlap with issue 816 (q.v.).
10834 and recommend both issues be considered together
10835 (and possibly merged).
10840 <p><b>Proposed resolution:</b></p>
10842 Change 20.7 [function.objects] p2:
10845 <blockquote><pre>template<<del>CopyConstructible</del> <ins>MoveConstructible</ins> Fn, <del>CopyConstructible</del> <ins>MoveConstructible</ins>... Types>
10846 <i>unspecified</i> bind(Fn<ins>&&</ins>, Types<ins>&&</ins>...);
10847 template<Returnable R, <del>CopyConstructible</del> <ins>MoveConstructible</ins> Fn, <del>CopyConstructible</del> <ins>MoveConstructible</ins>... Types>
10848 <i>unspecified</i> bind(Fn<ins>&&</ins>, Types<ins>&&</ins>...);
10849 </pre></blockquote>
10852 Change 20.7.12.1.3 [func.bind.bind]:
10855 <blockquote><pre>template<<del>CopyConstructible</del> <ins>MoveConstructible</ins> F, <del>CopyConstructible</del> <ins>MoveConstructible</ins>... BoundArgs>
10856 <i>unspecified</i> bind(F<ins>&&</ins> f, BoundArgs<ins>&&</ins>... bound_args);
10861 <ins><i>Requires:</i> <i>unspecified</i> return type shall be <tt>MoveConstructible</tt>.</ins>
10864 -1- <i>Requires:</i> <tt><i>INVOKE</i>(f, w1, w2, ..., wN)</tt> (20.6.2) shall be a valid expression for some values
10865 <i>w1, w2, ..., wN</i>, where <tt>N == sizeof...(bound_args)</tt>.
10868 -2- <i>Returns:</i> A forwarding call wrapper <tt>g</tt> with a weak result type (20.6.2). The effect of <tt>g(u1, u2,
10869 ..., uM)</tt> shall be <tt><i>INVOKE</i>(f, v1, v2, ..., vN, Callable<F cv,V1, V2, ..., VN>::result_type)</tt>, where <i>cv</i>
10870 represents the <i>cv</i>-qualifiers of <tt>g</tt> and the values and types of the bound arguments
10871 <tt>v1, v2, ..., vN</tt> are determined as specified below.
10874 <i>Throws:</i> Nothing unless the constructor of <tt>F</tt> or of one of the types in the <tt>BoundArgs...</tt> pack expansion
10875 throws an exception.
10879 <pre>template<Returnable R, <del>CopyConstructible</del> <ins>MoveConstructible</ins> F, <del>CopyConstructible</del> <ins>MoveConstructible</ins>... BoundArgs>
10880 <i>unspecified</i> bind(F<ins>&&</ins> f, BoundArgs<ins>&&</ins>... bound_args);
10885 <ins><i>Requires:</i> <i>unspecified</i> return type shall be <tt>MoveConstructible</tt>.</ins>
10888 -3- <i>Requires:</i> <tt><i>INVOKE</i>(f, w1, w2, ..., wN)</tt> shall be a valid expression for some values <i>w1, w2, ...,
10889 wN</i>, where <tt>N == sizeof...(bound_args)</tt>.
10892 -4- <i>Returns:</i> A forwarding call wrapper <tt>g</tt> with a nested type <tt>result_type</tt> defined as a synonym
10893 for <tt>R</tt>. The effect of <tt>g(u1, u2, ..., uM)</tt> shall be <tt><i>INVOKE</i>(f, v1, v2, ..., vN, R)</tt>, where the
10894 values and types of the bound arguments <tt>v1, v2, ..., vN</tt> are determined as specified below.
10898 <i>Throws:</i> Nothing unless the constructor of <tt>F</tt> or of one of the types in the <tt>BoundArgs...</tt> pack expansion
10899 throws an exception.
10905 Let the values of <i>bound arguments</i> <tt>v1, v2, ..., vN</tt> and
10906 their corresponding types <tt>V1, V2, ..., VN</tt> depend on the type of
10907 the corresponding argument <tt>ti</tt> in <tt>bound_args</tt> in the
10908 call to <tt>bind</tt> and the <i>cv</i>-qualifiers <i>cv</i> of the call
10909 wrapper <tt>g</tt> as follows. Let <tt>Ti</tt> be an alias for the ith
10910 element of the pack expansion <tt>decay<BoundArgs>::type...</tt>,
10911 and let <tt>ti</tt> be an alias for the ith element in the function
10912 parameter pack expansion <tt>bound_args...</tt>:
10917 if <tt>ti</tt> is of type <tt>reference_wrapper<T></tt> the argument is
10918 <tt>ti.get()</tt> and its type <tt>Vi</tt> is <tt>T&</tt>;
10921 if the value of <tt>std::is_bind_expression<Ti>::value</tt> is <tt>true</tt> the argument is <tt>ti(u1, u2, ..., uM)</tt> and
10922 its type <tt>Vi</tt> is <tt>result_of<Ti cv (U1&, U2&, ..., UM&)>::type</tt>;
10925 if the value <tt>j</tt> of <tt>std::is_placeholder<Ti>::value</tt> is not zero the argument is <tt>std::forward<Uj>(uj)</tt> and
10926 its type <tt>Vi</tt> is <tt>Uj&&</tt>;
10929 otherwise the value is <tt>ti</tt> and its type <tt>Vi</tt> is <tt>Ti cv &</tt>.
10941 <h3><a name="819"></a>819. rethrow_if_nested</h3>
10942 <p><b>Section:</b> 18.8.6 [except.nested] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
10943 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-03-25 <b>Last modified:</b> 2008-09-17</p>
10944 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#except.nested">active issues</a> in [except.nested].</p>
10945 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#except.nested">issues</a> in [except.nested].</p>
10946 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
10947 <p><b>Discussion:</b></p>
10949 Looking at the wording I submitted for <tt>rethrow_if_nested</tt>, I don't think I
10950 got it quite right.
10954 The current wording says:
10958 <pre>template <class E> void rethrow_if_nested(const E& e);
10962 <i>Effects:</i> Calls <tt>e.rethrow_nested()</tt> only if <tt>e</tt>
10963 is publicly derived from <tt>nested_exception</tt>.
10969 This is trying to be a bit subtle, by requiring <tt>e</tt> (not <tt>E</tt>) to be publicly
10970 derived from <tt>nested_exception</tt> the idea is that a <tt>dynamic_cast</tt> would be
10971 required to be sure. Unfortunately, if <tt>e</tt> is dynamically but not statically
10972 derived from <tt>nested_exception</tt>, <tt>e.rethrow_nested()</tt> is ill-formed.
10981 Alisdair was volunteered to provide wording.
10985 <p><b>Proposed resolution:</b></p>
10992 <h3><a name="822"></a>822. Object with explicit copy constructor no longer <tt>CopyConstructible</tt></h3>
10993 <p><b>Section:</b> X [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">Tentatively NAD</a>
10994 <b>Submitter:</b> James Kanze <b>Opened:</b> 2008-04-01 <b>Last modified:</b> 2009-05-23</p>
10995 <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>
10996 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD">Tentatively NAD</a> status.</p>
10997 <p><b>Discussion:</b></p>
10999 I just noticed that the following program is legal in C++03, but
11000 is forbidden in the current draft:
11003 <blockquote><pre>#include <vector>
11004 #include <iostream>
11010 explicit Toto( Toto const& ) {}
11016 std::vector< Toto > v( 10 ) ;
11019 </pre></blockquote>
11022 Is this change intentional? (And if so, what is the
11023 justification? I wouldn't call such code good, but I don't see
11024 any reason to break it unless we get something else in return.)
11033 The subgroup that looked at this felt this was a good change, but it may
11034 already be handled by incoming concepts (we're not sure).
11038 Original Proposed resolution:
11042 In X [utility.arg.requirements] change Table 33: <tt>MoveConstructible</tt> requirements [moveconstructible]:
11048 <th>expression</th><th>post-condition</th>
11051 <td><tt>T t<ins>(rv)</ins><del> = rv</del></tt></td><td><tt>t</tt> is equivalent to the value of <tt>rv</tt> before the construction</td>
11054 <td colspan="2" align="center">...</td>
11060 In X [utility.arg.requirements] change Table 34: <tt>CopyConstructible</tt> requirements [copyconstructible]:
11066 <th>expression</th><th>post-condition</th>
11069 <td><tt>T t<ins>(u)</ins><del> = u</del></tt></td><td>the value of <tt>u</tt> is unchanged and is equivalent to <tt>t</tt></td>
11072 <td colspan="2" align="center">...</td>
11084 Alisdair: Proposed resolution kinda funky as these tables no longer
11085 exist. Move from direct init to copy init. Clarify with Doug, recommends
11089 Walter: Suggest NAD via introduction of concepts.
11092 Recommend close as NAD.
11098 <p><b>Proposed resolution:</b></p>
11100 Recommend close as NAD.
11108 <h3><a name="825"></a>825. Missing rvalues reference stream insert/extract operators?</h3>
11109 <p><b>Section:</b> 19.5.2.2 [syserr.errcode.overview], 20.8.13.2.8
11110 [util.smartptr.shared.io], 22.4.8 [facets.examples], 20.3.6.3
11111 [bitset.operators], 26.4.6 [complex.ops], 27.6 [stream.buffers], 28.10
11112 [re.submatch] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Tentatively NAD Editorial</a>
11113 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-04-10 <b>Last modified:</b> 2009-05-23</p>
11114 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD%20Editorial">Tentatively NAD Editorial</a> status.</p>
11115 <p><b>Discussion:</b></p>
11117 Should the following use rvalues references to stream in insert/extract
11122 <li>19.5.2.2 [syserr.errcode.overview]</li>
11123 <li>20.8.13.2.8 [util.smartptr.shared.io]</li>
11124 <li>22.4.8 [facets.examples]</li>
11125 <li>20.3.6.3 [bitset.operators]</li>
11126 <li>26.4.6 [complex.ops]</li>
11127 <li>Doubled signatures in 27.6 [stream.buffers] for character inserters
11128 (ref 27.7.2.6.4 [ostream.inserters.character])
11129 + definition 27.7.2.6.4 [ostream.inserters.character]</li>
11130 <li>28.10 [re.submatch]</li>
11139 Agree with the idea in the issue, Alisdair to provide wording.
11143 Daniel adds 2009-02-14:
11148 The proposal given in the paper
11149 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2831.html">N2831</a>
11150 apparently resolves this issue.
11159 The cited paper is an earlier version of
11160 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2844.html">N2844</a>,
11161 which changed the rvalue reference binding rules.
11162 That paper includes generic templates
11163 <tt>operator<<</tt> and <tt>operator>></tt>
11164 that adapt rvalue streams.
11167 We therefore agree with Daniel's observation.
11168 Move to NAD Editorial.
11173 <p><b>Proposed resolution:</b></p>
11182 <h3><a name="827"></a>827. <tt>constexpr shared_ptr::shared_ptr()?</tt></h3>
11183 <p><b>Section:</b> 20.8.13.2.1 [util.smartptr.shared.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
11184 <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2008-04-11 <b>Last modified:</b> 2009-05-30</p>
11185 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#util.smartptr.shared.const">active issues</a> in [util.smartptr.shared.const].</p>
11186 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared.const">issues</a> in [util.smartptr.shared.const].</p>
11187 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
11188 <p><b>Discussion:</b></p>
11190 Would anyone object to making the default constructor of <tt>shared_ptr</tt> (and
11191 <tt>weak_ptr</tt> and <tt>enable_shared_from_this) constexpr</tt>? This would enable
11192 static initialization for <tt>shared_ptr</tt> variables, eliminating another
11193 unfair advantage of raw pointers.
11203 It's not clear to us that you can initialize a pointer with the literal
11204 0 in a constant expression. We need to ask CWG to make sure this works.
11205 Bjarne has been appointed to do this.
11208 Core got back to us and assured as that <tt>nullptr</tt> would do the job
11214 2009-05-01 Alisdair adds:
11220 I don't believe that constexpr will buy anything in this case.
11221 <tt>shared_ptr/weak_ptr/enable_shared_from_this</tt> cannot be literal types as they
11222 have a non-trivial copy constructor. As they do not produce literal types,
11223 then the constexpr default constructor will <em>not</em> guarantee constant
11224 initialization, and so not buy the hoped for optimization.
11227 I recommend referring this back to Core to see if we can get static
11228 initialization for types with constexpr constructors, even if they are not
11229 literal types. Otherwise this should be closed as NAD.
11234 2009-05-26 Daniel adds:
11239 If Alisdair's 2009-05-01 comment is correct, wouldn't that also make
11240 <tt>constexpr mutex()</tt> useless, because this class has a non-trivial
11241 destructor? (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#828">828</a>)
11246 <p><b>Proposed resolution:</b></p>
11255 <h3><a name="828"></a>828. Static initialization for <tt>std::mutex</tt>?</h3>
11256 <p><b>Section:</b> 30.4.1.1 [thread.mutex.class] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
11257 <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2008-04-18 <b>Last modified:</b> 2009-05-30</p>
11258 <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>
11259 <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>
11260 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
11261 <p><b>Discussion:</b></p>
11263 [Note: I'm assuming here that 3.6.2 [basic.start.init]/1 will be fixed.]
11266 Currently <tt>std::mutex</tt> doesn't support static initialization. This is a
11267 regression with respect to <tt>pthread_mutex_t</tt>, which does. I believe that
11268 we should strive to eliminate such regressions in expressive power where
11269 possible, both to ease migration and to not provide incentives to (or
11270 force) people to forego the C++ primitives in favor of pthreads.
11280 We believe this is implementable on POSIX, because the initializer-list
11281 feature and the constexpr feature make this work. Double-check core
11282 language about static initialization for this case. Ask core for a core
11283 issue about order of destruction of statically-initialized objects wrt.
11284 dynamically-initialized objects (should come afterwards). Check
11285 non-POSIX systems for implementability.
11288 If ubiquitous implementability cannot be assured, plan B is to introduce
11289 another constructor, make this constexpr, which is
11290 conditionally-supported. To avoid ambiguities, this new constructor needs
11291 to have an additional parameter.
11302 Jens: constant initialization seems to be ok core-language wise
11305 Consensus: Defer to threading experts, in particular a Microsoft platform expert.
11308 Lawrence to send e-mail to Herb Sutter, Jonathan Caves, Anthony Wiliams,
11309 Paul McKenney, Martin Tasker, Hans Boehm, Bill Plauger, Pete Becker,
11310 Peter Dimov to alert them of this issue.
11313 Lawrence: What about header file shared with C? The initialization
11314 syntax is different in C and C++.
11317 Recommend Keep in Review
11326 Keep in Review status pending feedback from members of the Concurrency subgroup.
11330 See related comments from Alisdiar and Daniel in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#827">827</a>.
11336 <p><b>Proposed resolution:</b></p>
11338 Change 30.4.1.1 [thread.mutex.class]:
11341 <blockquote><pre>class mutex {
11343 <ins>constexpr</ins> mutex();
11345 </pre></blockquote>
11352 <h3><a name="830"></a>830. Incomplete list of char_traits specializations</h3>
11353 <p><b>Section:</b> 21.2 [char.traits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Tentatively NAD Editorial</a>
11354 <b>Submitter:</b> Dietmar Kühl <b>Opened:</b> 2008-04-23 <b>Last modified:</b> 2009-05-23</p>
11355 <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>
11356 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD%20Editorial">Tentatively NAD Editorial</a> status.</p>
11357 <p><b>Discussion:</b></p>
11359 Paragraph 4 of 21.2 [char.traits] mentions that this
11360 section specifies two specializations (<code>char_traits<char></code>
11361 and (<code>char_traits<wchar_t></code>). However, there are actually
11362 four specializations provided, i.e. in addition to the two above also
11363 <code>char_traits<char16_t></code> and <code>char_traits<char32_t></code>).
11364 I guess this was just an oversight and there is nothing wrong with just
11373 <tt>char_traits< char16/32_t ></tt>
11374 should also be added to <tt><ios_fwd></tt> in 27.3 [iostream.forward], and all the specializations
11375 taking a <tt>char_traits</tt> parameter in that header.
11385 Idea of the issue is ok.
11388 Alisdair to provide wording, once that wording arrives, move to review.
11394 2009-05-04 Alisdair adds:
11400 The main point of the issue was resolved editorially in
11401 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>,
11403 close to NAD Editorial.
11404 However, exploring the issue we found a second tweak was necessary for
11405 <tt><iosfwd></tt> and that is still outstanding, so here are the words I am long
11406 overdue delivering:
11410 Howard: I've put Alisdair's words into the proposed wording section and
11411 moved the issue to Review.
11418 Original proposed wording.
11425 Replace paragraph 4 of 21.2 [char.traits] by:
11429 This subclause specifies a struct template, <code>char_traits<charT></code>,
11430 and four explicit specializations of it, <code>char_traits<char></code>,
11431 <code>char_traits<char16_t></code>, <code>char_traits<char32_t></code>, and
11432 <code>char_traits<wchar_t></code>, all of which appear in the header
11433 <string> and satisfy the requirements below.
11443 We agree. Move to NAD Editorial.
11447 <p><b>Proposed resolution:</b></p>
11449 Change Forward declarations 27.3 [iostream.forward]:
11454 <b>Header <tt><iosfwd></tt> synopsis</b>
11456 <pre>namespace std {
11457 template<class charT> class char_traits;
11458 template<> class char_traits<char>;
11459 <ins>template<> class char_traits<char16_t>;</ins>
11460 <ins>template<> class char_traits<char32_t>;</ins>
11461 template<> class char_traits<wchar_t>;
11472 <h3><a name="833"></a>833. Freestanding implementations header list needs review for C++0x</h3>
11473 <p><b>Section:</b> 17.6.1.3 [compliance] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
11474 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2008-05-14 <b>Last modified:</b> 2009-03-11</p>
11475 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#compliance">active issues</a> in [compliance].</p>
11476 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#compliance">issues</a> in [compliance].</p>
11477 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
11478 <p><b>Discussion:</b></p>
11480 Once the C++0x standard library is feature complete, the LWG needs to
11481 review 17.6.1.3 [compliance] Freestanding implementations header list to
11482 ensure it reflects LWG consensus.
11492 This is a placeholder defect to remind us to review the table once we've
11493 stopped adding headers to the library.
11496 Three new headers that need to be added to the list:
11498 <blockquote><pre><initializer_list> <concept> <iterator_concepts>
11499 </pre></blockquote>
11501 <tt><iterator_concepts></tt>, in particular, has lots of stuff
11502 that isn't needed, so maybe the stuff that is needed should be broken
11503 out into a separate header.
11506 Robert: What about <tt>reference_closure</tt>? It's currently in
11507 <tt><functional></tt>.
11512 Post Summit Daniel adds:
11519 The comment regarding <tt>reference_closure</tt> seems moot since it was just
11520 recently decided to remove that.
11523 A reference to proposal
11524 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2814.pdf">N2814</a>
11525 ("Fixing freestanding") should be added. This
11526 paper e.g. proposes to add only <tt><initializer_list></tt> to the include list
11534 <p><b>Proposed resolution:</b></p>
11541 <h3><a name="834"></a>834. Unique_ptr::pointer requirements underspecified</h3>
11542 <p><b>Section:</b> 20.8.12.2 [unique.ptr.single] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
11543 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-05-14 <b>Last modified:</b> 2008-06-19</p>
11544 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unique.ptr.single">active issues</a> in [unique.ptr.single].</p>
11545 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr.single">issues</a> in [unique.ptr.single].</p>
11546 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
11547 <p><b>Discussion:</b></p>
11549 Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a> (including recent updates by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#821">821</a>) proposes a useful
11550 extension point for <tt>unique_ptr</tt> by granting support for an optional
11551 <tt>deleter_type::pointer</tt> to act as pointer-like replacement for <tt>element_type*</tt>
11552 (In the following: <tt>pointer</tt>).
11555 Unfortunately no requirements are specified for the type <tt>pointer</tt> which has
11556 impact on at least two key features of <tt>unique_ptr</tt>:
11560 <li>Operational fail-safety.</li>
11561 <li>(Well-)Definedness of expressions.</li>
11565 <tt>Unique_ptr</tt> specification makes great efforts to require that essentially *all*
11566 operations cannot throw and therefore adds proper wording to the affected
11567 operations of the deleter as well. If user-provided <tt>pointer</tt>-emulating types
11568 ("smart pointers") will be allowed, either *all* throw-nothing clauses have to
11569 be replaced by weaker "An exception is thrown only if <tt>pointer</tt>'s {op} throws
11570 an exception"-clauses or it has to be said explicitly that all used
11572 <tt>pointer</tt> are required *not* to throw. I understand the main focus of <tt>unique_ptr</tt>
11573 to be as near as possible to the advantages of native pointers which cannot
11574 fail and thus strongly favor the second choice. Also, the alternative position
11575 would make it much harder to write safe and simple template code for
11576 <tt>unique_ptr</tt>. Additionally, I assume that a general statement need to be given
11577 that all of the expressions of <tt>pointer</tt> used to define semantics are required to
11578 be well-formed and well-defined (also as back-end for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#762">762</a>).
11588 Howard: We maybe need a core concept <tt>PointerLike</tt>, but we don't need the
11589 arithmetic (see <tt>shared_ptr</tt> vs. <tt>vector<T>::iterator</tt>.
11592 Howard will go through and enumerate the individual requirements wrt. <tt>pointer</tt> for each member function.
11598 <p><b>Proposed resolution:</b></p>
11600 Add the following sentence just at the end of the newly proposed
11601 20.8.12.2 [unique.ptr.single]/p. 3:
11605 <tt>unique_ptr<T, D>::pointer</tt>'s operations shall be well-formed, shall have well
11606 defined behavior, and shall not throw exceptions.
11614 <h3><a name="835"></a>835. tying two streams together (correction to DR 581)</h3>
11615 <p><b>Section:</b> 27.5.4.2 [basic.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
11616 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2008-05-17 <b>Last modified:</b> 2009-05-30</p>
11617 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.ios.members">active issues</a> in [basic.ios.members].</p>
11618 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.ios.members">issues</a> in [basic.ios.members].</p>
11619 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
11620 <p><b>Discussion:</b></p>
11624 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>,
11625 now integrated into the working paper, overlooks a couple of minor
11631 First, being an unformatted function once again, <code>flush()</code>
11632 is required to create a sentry object whose constructor must, among
11633 other things, flush the tied stream. When two streams are tied
11634 together, either directly or through another intermediate stream
11635 object, flushing one will also cause a call to <code>flush()</code> on
11636 the other tied stream(s) and vice versa, ad infinitum. The program
11637 below demonstrates the problem.
11642 Second, as Bo Persson notes in his
11643 comp.lang.c++.moderated <a href="http://groups.google.com/group/comp.lang.c++.moderated/tree/browse_frm/thread/f2187794e9cc036d/305df31dc583054a">post</a>,
11644 for streams with the <code>unitbuf</code> flag set such
11645 as <code>std::stderr</code>, the destructor of the sentry object will
11646 again call <code>flush()</code>. This seems to create an infinite
11647 recursion for <code>std::cerr << std::flush;</code>
11651 <pre>#include <iostream>
11655 std::cout.tie (&std::cerr);
11656 std::cerr.tie (&std::cout);
11657 std::cout << "cout\n";
11658 std::cerr << "cerr\n";
11668 We agree with the proposed resolution.
11673 2009-05-26 Daniel adds:
11679 I think that the most recently suggested change in
11680 27.7.2.4 [ostream::sentry] need some further word-smithing. As
11681 written, it would make the behavior undefined, if under
11682 conditions when <tt>pubsync()</tt> should be called, but when
11683 in this scenario <tt>os.rdbuf()</tt> returns 0.
11686 This case is explicitly handled in <tt>flush()</tt> and needs to be
11687 taken care of. My suggested fix is:
11691 If <tt>((os.flags() & ios_base::unitbuf) && !uncaught_exception()</tt>
11692 <ins><tt>&& os.rdbuf() != 0</tt></ins>) is true, calls <del><tt>os.flush()</tt></del>
11693 <ins><tt>os.rdbuf()->pubsync()</tt></ins>.
11697 Two secondary questions are:
11702 Should <tt>pubsync()</tt> be invoked in any case or shouldn't a
11703 base requirement for this trial be that <tt>os.good() == true</tt>
11704 as required in the original <tt>flush()</tt> case?
11707 Since <tt>uncaught_exception()</tt> is explicitly tested, shouldn't
11708 a return value of -1 of <tt>pubsync()</tt> produce <tt>setstate(badbit)</tt>
11709 (which may throw <tt>ios_base::failure</tt>)?
11716 <p><b>Proposed resolution:</b></p>
11719 I think an easy way to plug the first hole is to add a requires clause
11720 to <code>ostream::tie(ostream *tiestr)</code> requiring the this
11721 pointer not be equal to any pointer on the list starting
11722 with <code>tiestr->tie()</code>
11723 through <code>tiestr()->tie()->tie()</code> and so on. I am not
11724 proposing that we require implementations to traverse this list,
11725 although I think we could since the list is unlikely to be very long.
11730 Add a <i>Requires</i> clause to 27.5.4.2 [basic.ios.members] withethe following
11736 <i>Requires:</i> If <code>(tiestr != 0)</code> is
11737 true, <code>tiestr</code> must not be reachable by traversing the
11738 linked list of tied stream objects starting
11739 from <code>tiestr->tie()</code>.
11744 In addition, to prevent the infinite recursion that Bo writes about in
11745 his comp.lang.c++.moderated post, I propose to change
11746 27.7.2.4 [ostream::sentry], p2 like so:
11751 If <code>((os.flags() & ios_base::unitbuf) &&
11752 !uncaught_exception())</code> is true,
11753 calls <del>os.flush()</del> <ins><code>os.rdbuf()->pubsync()</code></ins>.
11761 <h3><a name="836"></a>836.
11762 effects of <code>money_base::space</code> and
11763 <code>money_base::none</code> on <code>money_get</code>
11765 <p><b>Section:</b> 22.4.6.1.2 [locale.money.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
11766 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2008-05-17 <b>Last modified:</b> 2008-09-22</p>
11767 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.money.get.virtuals">active issues</a> in [locale.money.get.virtuals].</p>
11768 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.money.get.virtuals">issues</a> in [locale.money.get.virtuals].</p>
11769 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
11770 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#670">670</a></p>
11771 <p><b>Discussion:</b></p>
11775 In paragraph 2, 22.4.6.1.2 [locale.money.get.virtuals] specifies the following:
11780 Where <code>space</code> or <code>none</code> appears in the format
11781 pattern, except at the end, optional white space (as recognized
11782 by <code>ct.is</code>) is consumed after any required space.
11787 This requirement can be (and has been) interpreted two mutually
11788 exclusive ways by different readers. One possible interpretation
11796 where <code>money_base::space</code> appears in the format, at least
11797 one space is required, and
11802 where <code>money_base::none</code> appears in the format, space is
11803 allowed but not required.
11815 where either <code>money_base::space</code> or <code>money_base::none</code> appears in the format, white space is optional.
11825 Martin will revise the proposed resolution.
11829 <p><b>Proposed resolution:</b></p>
11832 I propose to change the text to make it clear that the first
11833 interpretation is intended, that is, to make following change to
11834 22.4.6.1.2 [locale.money.get.virtuals], p2:
11840 When <code><ins>money_base::</ins>space</code>
11841 or <code><ins>money_base::</ins>none</code> appears <ins>as the last
11842 element </ins>in the format pattern, <del>except at the end, optional
11843 white space (as recognized by <code>ct.is</code>) is consumed after
11844 any required space.</del> <ins>no white space is consumed. Otherwise,
11845 where <code>money_base::space</code> appears in any of the initial
11846 elements of the format pattern, at least one white space character is
11847 required. Where <code>money_base::none</code> appears in any of the
11848 initial elements of the format pattern, white space is allowed but not
11849 required. In either case, any required followed by all optional white
11850 space (as recognized by <code>ct.is()</code>) is consumed.</ins>
11851 If <code>(str.flags() & str.showbase)</code> is <code>false</code>, ...
11859 <h3><a name="837"></a>837.
11860 <code>basic_ios::copyfmt()</code> overly loosely specified
11862 <p><b>Section:</b> 27.5.4.2 [basic.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Tentatively NAD Editorial</a>
11863 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2008-05-17 <b>Last modified:</b> 2009-05-23</p>
11864 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.ios.members">active issues</a> in [basic.ios.members].</p>
11865 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.ios.members">issues</a> in [basic.ios.members].</p>
11866 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD%20Editorial">Tentatively NAD Editorial</a> status.</p>
11867 <p><b>Discussion:</b></p>
11870 The <code>basic_ios::copyfmt()</code> member function is specified in 27.5.4.2 [basic.ios.members] to have the following effects:
11875 <i>Effects</i>: If <code>(this == &rhs)</code> does
11876 nothing. Otherwise assigns to the member objects of <code>*this</code>
11877 the corresponding member objects of <code>rhs</code>, except that
11882 <code>rdstate()</code> and <code>rdbuf()</code> are left unchanged;
11887 <code>exceptions()</code> is altered last by
11888 calling <code>exceptions(rhs.except)</code>
11893 the contents of arrays pointed at by <code>pword</code>
11894 and <code>iword</code> are copied not the pointers themselves
11901 Since the rest of the text doesn't specify what the member objects
11902 of <code>basic_ios</code> are this seems a little too loose.
11911 We agree with the proposed resolution.
11912 Move to NAD Editorial.
11916 <p><b>Proposed resolution:</b></p>
11919 I propose to tighten things up by adding a <i>Postcondition</i> clause
11920 to the function like so:
11924 <i>Postconditions:</i>
11929 <th colspan="2"><code>copyfmt()</code> postconditions</th>
11938 <td><code>rdbuf()</code></td>
11939 <td><i>unchanged</i></td>
11942 <td><code>tie()</code></td>
11943 <td><code>rhs.tie()</code></td>
11946 <td><code>rdstate()</code></td>
11947 <td><i>unchanged</i></td>
11950 <td><code>exceptions()</code></td>
11951 <td><code>rhs.exceptions()</code></td>
11954 <td><code>flags()</code></td>
11955 <td><code>rhs.flags()</code></td>
11958 <td><code>width()</code></td>
11959 <td><code>rhs.width()</code></td>
11962 <td><code>precision()</code></td>
11963 <td><code>rhs.precision()</code></td>
11966 <td><code>fill()</code></td>
11967 <td><code>rhs.fill()</code></td>
11970 <td><code>getloc()</code></td>
11971 <td><code>rhs.getloc()</code></td>
11978 The format of the table follows Table 117 (as
11979 of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2588.pdf">N2588</a>): <code>basic_ios::init()</code>
11985 The intent of the new table is not to impose any new requirements or
11986 change existing ones, just to be more explicit about what I believe is
11995 <h3><a name="838"></a>838.
11996 can an <i>end-of-stream</i> iterator become a <i>non-end-of-stream</i> one?
11998 <p><b>Section:</b> 24.6.1 [istream.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
11999 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2008-05-17 <b>Last modified:</b> 2008-10-27</p>
12000 <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>
12001 <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>
12002 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
12003 <p><b>Discussion:</b></p>
12006 From message c++std-lib-20003...
12011 The description of <code>istream_iterator</code> in
12012 24.6.1 [istream.iterator], p1 specifies that objects of the
12013 class become the <i>end-of-stream</i> (EOS) iterators under the
12014 following condition (see also issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#788">788</a> another problem
12015 with this paragraph):
12020 If the end of stream is reached (<code>operator void*()</code> on the
12021 stream returns <code>false</code>), the iterator becomes equal to
12022 the <i>end-of-stream</i> iterator value.
12027 One possible implementation approach that has been used in practice is
12028 for the iterator to set its <code>in_stream</code> pointer to 0 when
12029 it reaches the end of the stream, just like the default ctor does on
12030 initialization. The problem with this approach is that
12031 the <i>Effects</i> clause for <code>operator++()</code> says the
12032 iterator unconditionally extracts the next value from the stream by
12033 evaluating <code>*in_stream >> value</code>, without checking
12034 for <code>(in_stream == 0)</code>.
12039 Conformance to the requirement outlined in the <i>Effects</i> clause
12040 can easily be verified in programs by setting <code>eofbit</code>
12041 or <code>failbit</code> in <code>exceptions()</code> of the associated
12042 stream and attempting to iterate past the end of the stream: each
12043 past-the-end access should trigger an exception. This suggests that
12044 some other, more elaborate technique might be intended.
12049 Another approach, one that allows <code>operator++()</code> to attempt
12050 to extract the value even for EOS iterators (just as long
12051 as <code>in_stream</code> is non-0) is for the iterator to maintain a
12052 flag indicating whether it has reached the end of the stream. This
12053 technique would satisfy the presumed requirement implied by
12054 the <i>Effects</i> clause mentioned above, but it isn't supported by
12055 the exposition-only members of the class (no such flag is shown). This
12056 approach is also found in existing practice.
12061 The inconsistency between existing implementations raises the question
12062 of whether the intent of the specification is that a non-EOS iterator
12063 that has reached the EOS become a non-EOS one again after the
12064 stream's <code>eofbit</code> flag has been cleared? That is, are the
12065 assertions in the program below expected to pass?
12069 <pre> sstream strm ("1 ");
12070 istream_iterator eos;
12071 istream_iterator it (strm);
12074 assert (it == eos);
12076 strm << "2 3 ";
12077 assert (it != eos);
12084 Or is it intended that once an iterator becomes EOS it stays EOS until
12085 the end of its lifetime?
12096 We like the direction of the proposed resolution. We're not sure about
12097 the wording, and we need more time to reflect on it,
12100 Move to Open. Detlef to rewrite the proposed resolution in such a way
12101 that no reference is made to exposition only members of
12102 <tt>istream_iterator</tt>.
12107 <p><b>Proposed resolution:</b></p>
12110 The discussion of this issue on the reflector suggests that the intent
12111 of the standard is for an <code>istreambuf_iterator</code> that has
12112 reached the EOS to remain in the EOS state until the end of its
12113 lifetime. Implementations that permit EOS iterators to return to a
12114 non-EOS state may only do so as an extension, and only as a result of
12115 calling <code>istream_iterator</code> member functions on EOS
12116 iterators whose behavior is in this case undefined.
12121 To this end we propose to change 24.6.1 [istream.iterator], p1,
12127 The result of operator-> on an end<ins>-</ins>of<ins>-</ins>stream
12128 is not defined. For any other iterator value a <code>const T*</code>
12129 is returned.<ins> Invoking <code>operator++()</code> on
12130 an <i>end-of-stream</i> iterator is undefined.</ins> It is impossible
12131 to store things into istream iterators...
12136 Add pre/postconditions to the member function descriptions of <code>istream_iterator</code> like so:
12141 <pre>istream_iterator();</pre>
12143 <i>Effects</i>: Constructs the <i>end-of-stream</i> iterator.<br>
12144 <ins><i>Postcondition</i>: <code>in_stream == 0</code>.</ins>
12146 <pre>istream_iterator(istream_type &s);</pre>
12148 <i>Effects</i>: Initializes <code>in_stream</code> with &s. value
12149 may be initialized during construction or the first time it is
12151 <ins><i>Postcondition</i>: <code>in_stream == &s</code>.</ins>
12153 <pre>istream_iterator(const istream_iterator &x);</pre>
12155 <i>Effects</i>: Constructs a copy of <code>x</code>.<br>
12156 <ins><i>Postcondition</i>: <code>in_stream == x.in_stream</code>.</ins>
12158 <pre>istream_iterator& operator++();</pre>
12160 <ins><i>Requires</i>: <code>in_stream != 0</code>.</ins><br>
12161 <i>Effects</i>: <code>*in_stream >> value</code>.
12163 <pre>istream_iterator& operator++(int);</pre>
12165 <ins><i>Requires</i>: <code>in_stream != 0</code>.</ins><br>
12167 <blockquote><pre>istream_iterator tmp (*this);
12168 *in_stream >> value;
12178 <h3><a name="839"></a>839. Maps and sets missing splice operation</h3>
12179 <p><b>Section:</b> 23.4 [associative], 23.5 [unord] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
12180 <b>Submitter:</b> Alan Talbot <b>Opened:</b> 2008-05-18 <b>Last modified:</b> 2008-09-22</p>
12181 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative">active issues</a> in [associative].</p>
12182 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative">issues</a> in [associative].</p>
12183 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
12184 <p><b>Discussion:</b></p>
12186 Splice is a very useful feature of <tt>list</tt>. This functionality is also very
12187 useful for any other node based container, and I frequently wish it were
12188 available for maps and sets. It seems like an omission that these
12189 containers lack this capability. Although the complexity for a splice is
12190 the same as for an insert, the actual time can be much less since the
12191 objects need not be reallocated and copied. When the element objects are
12192 heavy and the compare operations are fast (say a <tt>map<int, huge_thingy></tt>)
12193 this can be a big win.
12197 <b>Suggested resolution:</b>
12201 Add the following signatures to map, set, multimap, multiset, and the unordered associative containers:
12204 void splice(list<T,Allocator>&& x);
12205 void splice(list<T,Allocator>&& x, const_iterator i);
12206 void splice(list<T,Allocator>&& x, const_iterator first, const_iterator last);
12207 </pre></blockquote>
12210 Hint versions of these are also useful to the extent hint is useful.
12211 (I'm looking for guidance about whether hints are in fact useful.)
12215 void splice(const_iterator position, list<T,Allocator>&& x);
12216 void splice(const_iterator position, list<T,Allocator>&& x, const_iterator i);
12217 void splice(const_iterator position, list<T,Allocator>&& x, const_iterator first, const_iterator last);
12218 </pre></blockquote>
12227 Don't try to <tt>splice "list"</tt> into the other containers, it should be container-type.
12230 <tt>forward_list</tt> already has <tt>splice_after</tt>.
12233 Would "<tt>splice</tt>" make sense for an <tt>unordered_map</tt>?
12236 Jens, Robert: "<tt>splice</tt>" is not the right term, it implies maintaining ordering in <tt>list</tt>s.
12239 Howard: <tt>adopt</tt>?
12242 Jens: <tt>absorb</tt>?
12245 Alan: <tt>subsume</tt>?
12248 Robert: <tt>recycle</tt>?
12251 Howard: <tt>transfer</tt>? (but no direction)
12254 Jens: <tt>transfer_from</tt>. No.
12257 Alisdair: Can we give a nothrow guarantee? If your <tt>compare()</tt> and <tt>hash()</tt> doesn't throw, yes.
12260 Daniel: For <tt>unordered_map</tt>, we can't guarantee nothrow.
12271 Martin: this would possibly outlaw an implementation technique that is
12272 currently in use; caching nodes in containers.
12275 Alan: if you cache in the allocator, rather than the individual
12276 container, this proposal doesn't interfere with that.
12279 Martin: I'm not opposed to this, but I'd like to see an implementation
12280 that demonstrates that it works.
12286 <p><b>Proposed resolution:</b></p>
12293 <h3><a name="847"></a>847. string exception safety guarantees</h3>
12294 <p><b>Section:</b> 21.4.1 [string.require] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
12295 <b>Submitter:</b> Hervé Brönnimann <b>Opened:</b> 2008-06-05 <b>Last modified:</b> 2009-02-14</p>
12296 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#string.require">active issues</a> in [string.require].</p>
12297 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.require">issues</a> in [string.require].</p>
12298 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
12299 <p><b>Discussion:</b></p>
12301 In March, on comp.lang.c++.moderated, I asked what were the
12302 string exception safety guarantees are, because I cannot see
12303 *any* in the working paper, and any implementation I know offers
12304 the strong exception safety guarantee (string unchanged if a
12305 member throws exception). The closest the current draft comes to
12306 offering any guarantees is 21.4 [basic.string], para 3:
12310 The class template <tt>basic_string</tt> conforms to the requirements
12311 for a Sequence Container (23.1.1), for a Reversible Container (23.1),
12312 and for an Allocator-aware container (91). The iterators supported by
12313 <tt>basic_string</tt> are random access iterators (24.1.5).
12317 However, the chapter 23 only says, on the topic of exceptions: 23.2 [container.requirements],
12323 Unless otherwise specified (see 23.2.2.3 and 23.2.6.4) all container types defined in this clause meet the following
12324 additional requirements:
12328 <li>if an exception is thrown by...</li>
12333 I take it as saying that this paragraph has *no* implication on
12334 <tt>std::basic_string</tt>, as <tt>basic_string</tt> isn't defined in Clause 23 and
12335 this paragraph does not define a *requirement* of Sequence
12336 nor Reversible Container, just of the models defined in Clause 23.
12337 In addition, LWG Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#718">718</a> proposes to remove 23.2 [container.requirements], para 3.
12341 Finally, the fact that no operation on Traits should throw
12342 exceptions has no bearing, except to suggest (since the only
12343 other throws should be allocation, <tt>out_of_range</tt>, or <tt>length_error</tt>)
12344 that the strong exception guarantee can be achieved.
12348 The reaction in that group by Niels Dekker, Martin Sebor, and
12349 Bo Persson, was all that this would be worth an LWG issue.
12353 A related issue is that <tt>erase()</tt> does not throw. This should be
12354 stated somewhere (and again, I don't think that the 23.2 [container.requirements], para 1
12364 Implementors will study this to confirm that it is actually possible.
12368 Daniel adds 2009-02-14:
12373 The proposed resolution of paper
12374 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2815.html">N2815</a>
12375 interacts with this issue (the paper does not refer to this issue).
12380 <p><b>Proposed resolution:</b></p>
12382 Add a blanket statement in 21.4.1 [string.require]:
12387 - if any member function or operator of <tt>basic_string<charT, traits, Allocator></tt>
12388 throws, that function or operator has no effect.
12391 - no <tt>erase()</tt> or <tt>pop_back()</tt> function throws.
12396 As far as I can tell, this is achieved by any implementation. If I made a
12397 mistake and it is not possible to offer this guarantee, then
12398 either state all the functions for which this is possible
12399 (certainly at least <tt>operator+=</tt>, <tt>append</tt>, <tt>assign</tt>, and <tt>insert</tt>),
12400 or add paragraphs to Effects clauses wherever appropriate.
12408 <h3><a name="851"></a>851. simplified array construction</h3>
12409 <p><b>Section:</b> 23.3.1 [array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
12410 <b>Submitter:</b> Benjamin Kosnik <b>Opened:</b> 2008-06-05 <b>Last modified:</b> 2009-06-10</p>
12411 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#array">active issues</a> in [array].</p>
12412 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#array">issues</a> in [array].</p>
12413 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
12414 <p><b>Discussion:</b></p>
12416 This is an issue that came up on the libstdc++ list, where a
12417 discrepancy between "C" arrays and C++0x's <tt>std::array</tt> was pointed
12422 In "C," this array usage is possible:
12425 <blockquote><pre>int ar[] = {1, 4, 6};
12426 </pre></blockquote>
12432 <blockquote><pre>std::array<int> a = { 1, 4, 6 }; // error
12433 </pre></blockquote>
12436 Instead, the second parameter of the <tt>array</tt> template must be
12440 <blockquote><pre>std::array<int, 3> a = { 1, 4, 6 };
12441 </pre></blockquote>
12444 Doug Gregor proposes the following solution, that assumes
12445 generalized initializer lists.
12448 <blockquote><pre>template<typename T, typename... Args>
12449 inline array<T, sizeof...(Args)>
12450 make_array(Args&&... args)
12451 { return { std::forward<Args>(args)... }; }
12452 </pre></blockquote>
12455 Then, the way to build an <tt>array</tt> from a list of unknown size is:
12458 <blockquote><pre>auto a = make_array<T>(1, 4, 6);
12459 </pre></blockquote>
12468 Benjamin: Move to Ready?
12471 Bjarne: I'm not convinced this is useful enough to add, so I'd like us
12472 to have time to reflect on it.
12475 Alisdair: the constraints are wrong, they should be
12477 <blockquote><pre>template<ValueType T, ValueType... Args>
12478 requires Convertible<Args, T>...
12479 array<T, sizeof...(Args)> make_array(Args&&... args);
12480 </pre></blockquote>
12482 Alidair: this would be useful if we had a constexpr version.
12485 Bjarne: this is probably useful for arrays with a small number of
12486 elements, but it's not clearly useful otherwise.
12489 Consensus is to move to Open.
12494 2009-06-07 Daniel adds:
12500 I suggest a fix and a simplification of the current proposal: Recent
12502 Howard showed, that a fix is required because narrowing conversion
12503 8.5.4 [dcl.init.list]/6 b.3
12504 would severely limit the possible distribution of argument types, e.g.
12506 <tt>make_array<double>(1, 2.0)</tt> is ill-formed, because the narrowing
12507 happens <em>inside</em> the
12508 function body where no constant expressions exist anymore. Furthermore
12511 <blockquote><pre>int f();
12513 </pre></blockquote>
12515 we probably want to support
12517 <blockquote><pre>make_array<double>(f(), g());
12518 </pre></blockquote>
12521 as well. To make this feasible, the currently suggested expansion
12524 <blockquote><pre>{ std::forward<Args>(args)... }
12525 </pre></blockquote>
12528 needs to be replaced by
12531 <blockquote><pre>{ static_cast<T>(std::forward<Args>(args))... }
12532 </pre></blockquote>
12535 which is safe, because we already ensure convertibility via the
12536 element-wise <tt>Convertible<Args, T></tt> requirement. Some other fixes are
12537 necessary: The <tt>ValueType</tt> requirement for the function <em>parameters</em>
12538 is invalid, because all lvalue arguments will deduce to an lvalue-reference,
12539 thereby no longer satisfying this requirement.
12543 The suggested simplification is to provide a default-computed effective
12544 type for the result array based on common_type and decay, in
12545 unconstrained form:
12548 <blockquote><pre>template<typename... Args>
12549 array<typename decay<typename common_type<Args...>::type>::type,
12550 sizeof...(Args)>
12551 make_array(Args&&... args);
12552 </pre></blockquote>
12555 The approach used below is similar to that of <tt>make_pair</tt> and <tt>make_tuple</tt>
12556 using a symbol <tt>C</tt> to represent the decayed common type [Note: Special
12557 handling of <tt>reference_wrapper</tt> types is intentionally <em>not</em> provided, because
12558 our target has so satisfy <tt>ValueType</tt>, thus under the revised proposal only
12559 an all-<tt>reference_wrapper</tt>-arguments would be well-formed and an array of
12560 <tt>reference_wrapper</tt> will be constructed]. I do currently not suggest to
12561 add new concepts reflecting <tt>decay</tt> and <tt>common_type</tt>, but an implementor will
12562 need something like this to succeed. Note that we use a similar fuzziness for
12563 <tt>make_pair</tt> and <tt>make_tuple</tt> currently. This fuzziness is not related to
12565 missing <tt>Constructible<Vi, Ti&&></tt> requirement for those functions. The following
12566 proposal fixes that miss for <tt>make_array</tt>. If the corresponding <tt>C</tt> type
12568 explicitly wanted for standardization, here the implementation
12571 <blockquote><pre>auto concept DC<typename... T> {
12572 typename type = typename decay<typename common_type<T...>::type>::type;
12574 </pre></blockquote>
12577 where <tt>C</tt> is identical to <tt>DC<Args...>::type</tt> in the proposed resolution below.
12580 I intentionally added no further type relation between type and the concept
12581 template parameters, but instead added this requirement below to make
12582 the specification as transparent as possible. As written this concept is
12583 satisfied, if the corresponding associated type exists.
12586 <p><b>Suggested Resolution:</b></p>
12591 Add to the array synopsis in 23.3 [sequences]:
12593 <blockquote><pre><ins>
12594 template<ReferentType... Args>
12595 requires ValueType<C> && Constructible<C, Args&&>...
12596 array<C, sizeof...(Args)>
12597 make_array(Args&&... args);
12599 </pre></blockquote>
12604 Append after 23.3.1.7 [array.tuple] Tuple interface to class template array
12605 the following new section:
12609 23.4.1.7 Array creation functions [array.creation]
12613 template<ReferentType... Args>
12614 requires ValueType<C> && Constructible<C, Args&&>...
12615 array<C, sizeof...(Args)>
12616 make_array(Args&&... args);</ins>
12621 Let <tt>C</tt> be <tt>decay<common_type<Args...>::type>::type</tt>.
12624 <ins><i>Returns:</i> an <tt>array<C, sizeof...(Args)></tt> initialized with
12625 <tt>{ static_cast<C>(std::forward<Args>(args))... }</tt>.
12638 <p><b>Proposed resolution:</b></p>
12640 Add to the <tt>array</tt> synopsis in 23.3 [sequences]:
12643 <blockquote><pre>template<ValueType T, ValueType... Args>
12644 requires Convertible<Args, T>...
12645 array<T, sizeof...(Args)>
12646 make_array(Args&&... args);
12647 </pre></blockquote>
12650 Append after 23.3.1.7 [array.tuple] Tuple interface to class template <tt>array</tt> the
12651 following new section.
12656 23.2.1.7 Convenience interface to class template <tt>array</tt> [array.tuple]
12659 <pre>template<ValueType T, ValueType... Args>
12660 requires Convertible<Args, T>...
12661 array<T, sizeof...(Args)>
12662 make_array(Args&&... args);
12667 <i>Returns:</i> an <tt>array<T, sizeof...(Args)></tt> initialized with <tt>{std::forward<T>(args)...}</tt>.
12677 <h3><a name="853"></a>853. <tt>to_string</tt> needs updating with <tt>zero</tt> and <tt>one</tt></h3>
12678 <p><b>Section:</b> 20.3.6 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
12679 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2008-06-18 <b>Last modified:</b> 2009-05-10</p>
12680 <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>
12681 <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>
12682 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
12683 <p><b>Discussion:</b></p>
12685 Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#396">396</a> adds defaulted arguments to the <tt>to_string</tt> member, but neglects to update
12686 the three newer <tt>to_string</tt> overloads.
12690 post San Francisco:
12695 Daniel found problems with the wording and provided fixes. Moved from Ready
12706 Alisdair: suggest to not repeat the default arguments in B, C, D
12707 (definition of to_string members)
12710 Walter: This is not really a definition.
12713 Consensus: Add note to the editor: Please apply editor's judgement
12714 whether default arguments should be repeated for B, C, D changes.
12717 Recommend Tentatively Ready.
12722 2009-05-09: See alternative solution in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1113">1113</a>.
12728 <p><b>Proposed resolution:</b></p>
12731 <p>replace in 20.3.6 [template.bitset]/1 (class <tt>bitset</tt>)
12733 <blockquote><pre>template <class charT, class traits>
12734 basic_string<charT, traits, allocator<charT> >
12735 to_string(<ins>charT zero = charT('0'), charT one = charT('1')</ins>) const;
12736 template <class charT>
12737 basic_string<charT, char_traits<charT>, allocator<charT> >
12738 to_string(<ins>charT zero = charT('0'), charT one = charT('1')</ins>) const;
12739 basic_string<char, char_traits<char>, allocator<char> >
12740 to_string(<ins>char zero = '0', char one = '1'</ins>) const;
12741 </pre></blockquote>
12745 replace in 20.3.6.2 [bitset.members]/37
12747 <blockquote><pre>template <class charT, class traits>
12748 basic_string<charT, traits, allocator<charT> >
12749 to_string(<ins>charT zero = charT('0'), charT one = charT('1')</ins>) const;
12752 37 <i>Returns:</i> <tt>to_string<charT, traits, allocator<charT> >(<ins>zero, one</ins>)</tt>.
12758 replace in 20.3.6.2 [bitset.members]/38
12761 <blockquote><pre>template <class charT>
12762 basic_string<charT, char_traits<charT>, allocator<charT> >
12763 to_string(<ins>charT zero = charT('0'), charT one = charT('1')</ins>) const;
12766 38 <i>Returns:</i> <tt>to_string<charT, char_traits<charT>, allocator<charT> >(<ins>zero, one</ins>)</tt>.
12773 replace in 20.3.6.2 [bitset.members]/39
12776 <blockquote><pre>basic_string<char, char_traits<char>, allocator<char> >
12777 to_string(<ins>char zero = '0', char one = '1'</ins>) const;
12780 39 <i>Returns:</i> <tt>to_string<char, char_traits<char>, allocator<char> >(<ins>zero, one</ins>)</tt>.
12793 <h3><a name="854"></a>854. <tt>default_delete</tt> converting constructor underspecified</h3>
12794 <p><b>Section:</b> 20.8.12.1.1 [unique.ptr.dltr.dflt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
12795 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2008-06-18 <b>Last modified:</b> 2009-05-23</p>
12796 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
12797 <p><b>Discussion:</b></p>
12799 No relationship between <tt>U</tt> and <tt>T</tt> in the converting constructor for <tt>default_delete</tt> template.
12802 Requirements: <tt>U*</tt> is convertible to <tt>T*</tt> and <tt>has_virtual_destructor<T></tt>;
12803 the latter should also become a concept.
12806 Rules out cross-casting.
12809 The requirements for <tt>unique_ptr</tt> conversions should be the same as those on the deleter.
12813 Howard adds 2008-11-26:
12819 I believe we need to be careful to not outlaw the following use case, and
12820 I believe the current proposed wording
12821 (<tt>requires Convertible<U*, T*> && HasVirtualDestructor<T></tt>) does so:
12824 <blockquote><pre>#include <memory>
12828 std::unique_ptr<int> p1(new int(1));
12829 std::unique_ptr<const int> p2(move(p1));
12831 <font color="#c80000">// *p2 = i; // should not compile</font>
12833 </pre></blockquote>
12836 I've removed "<tt>&& HasVirtualDestructor<T></tt>" from the
12837 <tt>requires</tt> clause in the proposed wording.
12849 Alisdair: This issue has to stay in review pending a paper constraining
12850 <tt>unique_ptr</tt>.
12853 Consensus: We agree with the resolution, but <tt>unique_ptr</tt> needs
12854 to be constrained, too.
12857 Recommend Keep in Review.
12866 Keep in Review status for the reasons cited.
12870 <p><b>Proposed resolution:</b></p>
12872 Change 20.8.12.1.1 [unique.ptr.dltr.dflt]:
12875 <blockquote><pre>namespace std {
12876 template <class T> struct default_delete {
12878 template <class U>
12879 <ins>requires Convertible<U*, T*></ins>
12880 default_delete(const default_delete<U>&);
12881 void operator()(T*) const;
12884 </pre></blockquote>
12890 <blockquote><pre>template <class U>
12891 <ins>requires Convertible<U*, T*></ins>
12892 default_delete(const default_delete<U>& other);
12893 </pre></blockquote>
12901 <h3><a name="857"></a>857. <tt>condition_variable::time_wait</tt> return <tt>bool</tt> error prone</h3>
12902 <p><b>Section:</b> 30.5.1 [thread.condition.condvar] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
12903 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2008-06-13 <b>Last modified:</b> 2009-06-14</p>
12904 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.condition.condvar">active issues</a> in [thread.condition.condvar].</p>
12905 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.condition.condvar">issues</a> in [thread.condition.condvar].</p>
12906 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
12907 <p><b>Discussion:</b></p>
12909 The meaning of the <tt>bool</tt> returned by <tt>condition_variable::timed_wait</tt> is so
12910 obscure that even the class' designer can't deduce it correctly. Several
12911 people have independently stumbled on this issue.
12914 It might be simpler to change the return type to a scoped enum:
12916 <blockquote><pre>enum class timeout { not_reached, reached };
12917 </pre></blockquote>
12920 That's the same cost as returning a <tt>bool</tt>, but not subject to mistakes. Your example below would be:
12923 <blockquote><pre>if (cv.wait_until(lk, time_limit) == timeout::reached )
12925 </pre></blockquote>
12928 Beman to supply exact wording.
12939 There is concern that the enumeration names are just as confusing, if
12940 not more so, as the bool. You might have awoken because of a signal or a
12941 spurious wakeup, for example.
12944 Group feels that this is a defect that needs fixing.
12947 Group prefers returning an enum over a void return.
12950 Howard to provide wording.
12955 2009-06-14 Beman provided wording.
12960 <p><b>Proposed resolution:</b></p>
12962 Change Condition variables 30.5 [thread.condition], Header
12963 condition_variable synopsis, as indicated:
12966 <blockquote><pre>namespace std {
12967 class condition_variable;
12968 class condition_variable_any;
12970 <ins>enum class cv_status { no_timeout, timeout };</ins>
12972 </pre></blockquote>
12975 Change Class condition_variable 30.5.1 [thread.condition.condvar] as indicated:
12978 <blockquote><pre>class condition_variable {
12981 template <class Clock, class Duration>
12982 <del>bool</del> <ins>cv_status</ins> wait_until(unique_lock<mutex>& lock,
12983 const chrono::time_point<Clock, Duration>& abs_time);
12984 template <class Clock, class Duration, class Predicate>
12985 bool wait_until(unique_lock<mutex>& lock,
12986 const chrono::time_point<Clock, Duration>& abs_time,
12989 template <class Rep, class Period>
12990 <del>bool</del> <ins>cv_status</ins> wait_for(unique_lock<mutex>& lock,
12991 const chrono::duration<Rep, Period>& rel_time);
12992 template <class Rep, class Period, class Predicate>
12993 bool wait_for(unique_lock<mutex>& lock,
12994 const chrono::duration<Rep, Period>& rel_time,
13001 template <class Clock, class Duration>
13002 <del>bool</del> <ins>cv_status</ins> wait_until(unique_lock<mutex>& lock,
13003 const chrono::time_point<Clock, Duration>& abs_time);
13007 -15- <i>Precondition:</i> <tt>lock</tt> is locked by the calling thread, and either
13011 no other thread is waiting on this <tt>condition_variable</tt> object or
13014 <tt>lock.mutex()</tt> returns the same value for each of the <tt>lock</tt>
13015 arguments supplied by all concurrently waiting threads (via <tt>wait</tt>,
13016 <tt>wait_for</tt> or <tt>wait_until</tt>.).
13021 -16- <i>Effects:</i>
13026 Atomically calls <tt>lock.unlock()</tt> and blocks on <tt>*this</tt>.
13029 When unblocked, calls <tt>lock.lock()</tt> (possibly blocking on the lock) and returns.
13032 The function will unblock when signaled by a call to <tt>notify_one()</tt>,
13033 a call to <tt>notify_all()</tt>, <del>by
13034 the current time exceeding <tt>abs_time</tt></del> <ins>if <tt>Clock::now() >= abs_time</tt></ins>,
13038 If the function exits via an exception, <tt>lock.unlock()</tt> shall be called prior
13039 to exiting the function scope.
13044 -17- <i>Postcondition:</i> <tt>lock</tt> is locked by the calling thread.
13048 -18- <i>Returns:</i> <del><tt>Clock::now() < abs_time</tt></del>
13049 <ins><tt>cv_status::timeout</tt> if the function unblocked because <tt>abs_time</tt>
13050 was reached, otherwise <tt>cv_status::no_timeout</tt></ins>.
13054 -19- <i>Throws:</i> <tt>std::system_error</tt> when the effects or postcondition
13055 cannot be achieved.
13059 -20- <i>Error conditions:</i>
13064 <tt>operation_not_permitted</tt> — if the thread does not own the lock.
13067 equivalent error condition from <tt>lock.lock()</tt> or <tt>lock.unlock()</tt>.
13072 <pre>template <class Rep, class Period>
13073 <del>bool</del> <ins>cv_status</ins> wait_for(unique_lock<mutex>& lock,
13074 const chrono::duration<Rep, Period>& rel_time);
13079 -21- <i><del>Effects</del> <ins>Returns</ins>:</i>
13081 <blockquote><pre>wait_until(lock, chrono::monotonic_clock::now() + rel_time)
13082 </pre></blockquote>
13084 <del>-22- <i>Returns:</i> <tt>false</tt> if the call is returning because the time
13085 duration specified by <tt>rel_time</tt> has elapsed,
13086 otherwise <tt>true</tt>.</del>
13090 This part of the wording may conflict with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#859">859</a> in detail, but does
13091 not do so in spirit. If both issues are accepted, there is a logical merge.
13096 <pre>template <class Clock, class Duration, class Predicate>
13097 bool wait_until(unique_lock<mutex>& lock,
13098 const chrono::time_point<Clock, Duration>& abs_time,
13104 -23- <i>Effects:</i>
13106 <blockquote><pre>while (!pred())
13107 if (<del>!</del>wait_until(lock, abs_time) <ins>== cv_status::timeout</ins>)
13110 </pre></blockquote>
13113 -24- <i>Returns:</i> <tt>pred()</tt>.
13118 The returned value indicates whether the predicate evaluates to
13119 <tt>true</tt> regardless of whether the timeout was triggered.
13120 — <i>end note</i>].
13126 Change Class condition_variable_any 30.5.2 [thread.condition.condvarany] as indicated:
13129 <blockquote><pre>class condition_variable_any {
13132 template <class Lock, class Clock, class Duration>
13133 <del>bool</del> <ins>cv_status</ins> wait_until(Lock& lock,
13134 const chrono::time_point<Clock, Duration>& abs_time);
13135 template <class Lock, class Clock, class Duration, class Predicate>
13136 bool wait_until(Lock& lock,
13137 const chrono::time_point<Clock, Duration>& abs_time,
13140 template <class Lock, class Rep, class Period>
13141 <del>bool</del> <ins>cv_status</ins> wait_for(Lock& lock,
13142 const chrono::duration<Rep, Period>& rel_time);
13143 template <class Lock, class Rep, class Period, class Predicate>
13144 bool wait_for(Lock& lock,
13145 const chrono::duration<Rep, Period>& rel_time,
13152 template <class Lock, class Clock, class Duration>
13153 <del>bool</del> <ins>cv_status</ins> wait_until(Lock& lock,
13154 const chrono::time_point<Clock, Duration>& abs_time);
13160 -13- <i>Effects:</i>
13165 Atomically calls <tt>lock.unlock()</tt> and blocks on <tt>*this</tt>.
13168 When unblocked, calls <tt>lock.lock()</tt> (possibly blocking on the lock) and returns.
13171 The function will unblock when signaled by a call to <tt>notify_one()</tt>,
13172 a call to <tt>notify_all()</tt>, <del>by
13173 the current time exceeding <tt>abs_time</tt></del> <ins>if <tt>Clock::now() >= abs_time</tt></ins>,
13177 If the function exits via an exception, <tt>lock.unlock()</tt> shall be called prior
13178 to exiting the function scope.
13183 -14- <i>Postcondition:</i> <tt>lock</tt> is locked by the calling thread.
13187 -15- <i>Returns:</i> <del><tt>Clock::now() < abs_time</tt></del>
13188 <ins><tt>cv_status::timeout</tt> if the function unblocked because <tt>abs_time</tt>
13189 was reached, otherwise <tt>cv_status::no_timeout</tt></ins>.
13193 -16- <i>Throws:</i> <tt>std::system_error</tt> when the effects or postcondition
13194 cannot be achieved.
13198 -17- <i>Error conditions:</i>
13203 equivalent error condition from <tt>lock.lock()</tt> or <tt>lock.unlock()</tt>.
13208 <pre>template <class Lock, class Rep, class Period>
13209 <del>bool</del> <ins>cv_status</ins> wait_for(Lock& lock,
13210 const chrono::duration<Rep, Period>& rel_time);
13216 -18- <i><del>Effects</del> <ins>Returns</ins>:</i>
13218 <blockquote><pre>wait_until(lock, chrono::monotonic_clock::now() + rel_time)
13219 </pre></blockquote>
13222 <del>-19- <i>Returns:</i> <tt>false</tt> if the call is returning because the time
13223 duration specified by <tt>rel_time</tt> has elapsed,
13224 otherwise <tt>true</tt>.</del>
13228 This part of the wording may conflict with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#859">859</a> in detail, but does
13229 not do so in spirit. If both issues are accepted, there is a logical merge.
13235 <pre>template <class Lock, class Clock, class Duration, class Predicate>
13236 bool wait_until(Lock& lock,
13237 const chrono::time_point<Clock, Duration>& <del>rel_time</del> <ins>abs_time</ins>,
13243 -20- <i>Effects:</i>
13245 <blockquote><pre>while (!pred())
13246 if (<del>!</del>wait_until(lock, abs_time) <ins>== cv_status::timeout</ins>)
13249 </pre></blockquote>
13252 -21- <i>Returns:</i> <tt>pred()</tt>.
13257 The returned value indicates whether the predicate evaluates to
13258 <tt>true</tt> regardless of whether the timeout was triggered.
13259 — <i>end note</i>].
13271 <h3><a name="859"></a>859. Monotonic Clock is Conditionally Supported?</h3>
13272 <p><b>Section:</b> 30.5 [thread.condition] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
13273 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2008-06-23 <b>Last modified:</b> 2009-06-14</p>
13274 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
13275 <p><b>Discussion:</b></p>
13277 <p>Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#958">958</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#959">959</a>.</p>
13280 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2661.html">N2661</a>
13281 says that there is a class named <tt>monotonic_clock</tt>. It also says that this
13282 name may be a synonym for <tt>system_clock</tt>, and that it's conditionally
13283 supported. So the actual requirement is that it can be monotonic or not,
13284 and you can tell by looking at <tt>is_monotonic</tt>, or it might not exist at
13285 all (since it's conditionally supported). Okay, maybe too much
13286 flexibility, but so be it.
13289 A problem comes up in the threading specification, where several
13290 variants of <tt>wait_for</tt> explicitly use <tt>monotonic_clock::now()</tt>. What is the
13291 meaning of an effects clause that says
13294 <blockquote><pre>wait_until(lock, chrono::monotonic_clock::now() + rel_time)
13295 </pre></blockquote>
13298 when <tt>monotonic_clock</tt> is not required to exist?
13308 Nick: maybe instead of saying that chrono::monotonic_clock is
13309 conditionally supported, we could say that it's always there, but not
13310 necessarily supported..
13313 Beman: I'd prefer a typedef that identifies the best clock to use for
13317 Tom: combine the two concepts; create a duration clock type, but keep
13318 the is_monotonic test.
13321 Howard: if we create a duration_clock type, is it a typedef or an
13322 entirely true type?
13325 There was broad preference for a typedef.
13328 Move to Open. Howard to provide wording to add a typedef for
13329 duration_clock and to replace all uses of monotonic_clock in function
13330 calls and signatures with duration_clock.
13335 Howard notes post-San Francisco:
13341 After further thought I do not believe that creating a <tt>duration_clock typedef</tt>
13342 is the best way to proceed. An implementation may not need to use a
13343 <tt>time_point</tt> to implement the <tt>wait_for</tt> functions.
13347 For example, on POSIX systems <tt>sleep_for</tt> can be implemented in terms of
13348 <tt>nanosleep</tt> which takes only a duration in terms of nanoseconds. The current
13349 working paper does not describe <tt>sleep_for</tt> in terms of <tt>sleep_until</tt>.
13350 And paragraph 2 of 30.2.4 [thread.req.timing] has the words strongly encouraging
13351 implementations to use monotonic clocks for <tt>sleep_for</tt>:
13355 2 The member functions whose names end in <tt>_for</tt> take an argument that
13356 specifies a relative time. Implementations should use a monotonic clock to
13357 measure time for these functions.
13361 I believe the approach taken in describing the effects of <tt>sleep_for</tt>
13362 and <tt>try_lock_for</tt> is also appropriate for <tt>wait_for</tt>. I.e. these
13363 are not described in terms of their <tt>_until</tt> variants.
13370 <p><b>Proposed resolution:</b></p>
13372 Change 30.5.1 [thread.condition.condvar], p21-22:
13376 <pre>template <class Rep, class Period>
13377 bool wait_for(unique_lock<mutex>& lock,
13378 const chrono::duration<Rep, Period>& rel_time);
13382 <i>Precondition:</i> <tt>lock</tt> is locked by the calling thread, and either
13385 <li><ins>no other thread is waiting on this <tt>condition_variable</tt> object or</ins></li>
13386 <li><ins><tt>lock.mutex()</tt> returns the same value for each of the <tt>lock</tt>
13387 arguments supplied by all concurrently waiting threads (via <tt>wait</tt>,
13388 <tt>wait_for</tt> or <tt>wait_until</tt>).</ins></li>
13393 <blockquote><pre><del>wait_until(lock, chrono::monotonic_clock::now() + rel_time)</del>
13394 </pre></blockquote>
13397 Atomically calls <tt>lock.unlock()</tt> and blocks on <tt>*this</tt>.
13401 When unblocked, calls <tt>lock.lock()</tt> (possibly blocking on the lock) and returns.
13405 The function will unblock when signaled by a call to <tt>notify_one()</tt>, a call
13406 to <tt>notify_all()</tt>, by
13407 the elapsed time <tt>rel_time</tt> passing (30.2.4 [thread.req.timing]),
13412 If the function exits via an exception, <tt>lock.unlock()</tt> shall be called
13413 prior to exiting the function scope.
13418 <i>Postcondition:</i> <tt>lock</tt> is locked by the calling thread.
13423 22 <i>Returns:</i> <tt>false</tt> if the call is returning because the time
13424 duration specified by <tt>rel_time</tt> has elapsed, otherwise <tt>true</tt>.
13428 This part of the wording may conflict with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#857">857</a> in detail, but does
13429 not do so in spirit. If both issues are accepted, there is a logical merge.
13434 <i>Throws:</i> <tt>std::system_error</tt> when the effects or postcondition cannot be achieved.
13438 <i>Error conditions:</i>
13443 <tt>operation_not_permitted</tt> -- if the thread does not own the lock.
13446 equivalent error condition from <tt>lock.lock()</tt> or <tt>lock.unlock()</tt>.
13454 Change 30.5.1 [thread.condition.condvar], p26-p29:
13458 <pre>template <class Rep, class Period, class Predicate>
13459 bool wait_for(unique_lock<mutex>& lock,
13460 const chrono::duration<Rep, Period>& rel_time,
13465 <i>Precondition:</i> <tt>lock</tt> is locked by the calling thread, and either
13468 <li><ins>no other thread is waiting on this <tt>condition_variable</tt> object or</ins></li>
13469 <li><ins><tt>lock.mutex()</tt> returns the same value for each of the <tt>lock</tt>
13470 arguments supplied by all concurrently waiting threads (via <tt>wait</tt>,
13471 <tt>wait_for</tt> or <tt>wait_until</tt>).</ins></li>
13476 <blockquote><pre><del>wait_until(lock, chrono::monotonic_clock::now() + rel_time, std::move(pred))</del>
13480 Executes a loop: Within the loop the function first evaluates <tt>pred()</tt>
13481 and exits the loop if the result of <tt>pred()</tt> is <tt>true</tt>.
13484 Atomically calls <tt>lock.unlock()</tt>
13485 and blocks on <tt>*this</tt>.
13488 When unblocked, calls <tt>lock.lock()</tt> (possibly blocking on the lock).
13491 The function will unblock when signaled by a call to <tt>notify_one()</tt>, a
13492 call to <tt>notify_all()</tt>, by the elapsed time <tt>rel_time</tt> passing (30.1.4
13493 [thread.req.timing]), or spuriously.
13496 If the function exits via an exception, <tt>lock.unlock()</tt> shall be called
13497 prior to exiting the function scope.
13500 The loop terminates when <tt>pred()</tt> returns <tt>true</tt> or when the time
13501 duration specified by <tt>rel_time</tt> has elapsed.
13507 27 [<i>Note:</i> There is no blocking if <tt>pred()</tt> is initially <tt>true</tt>,
13508 even if the timeout has already expired. <i>-- end note</i>]
13512 <i>Postcondition:</i> <tt>lock</tt> is locked by the calling thread.
13516 28 <i>Returns:</i> <tt>pred()</tt>
13520 29 [<i>Note:</i> The returned value indicates whether the predicate evaluates to
13521 <tt>true</tt> regardless of whether the timeout was triggered. <i>-- end note</i>]
13525 <i>Throws:</i> <tt>std::system_error</tt> when the effects or postcondition cannot be achieved.
13529 <i>Error conditions:</i>
13534 <tt>operation_not_permitted</tt> -- if the thread does not own the lock.
13537 equivalent error condition from <tt>lock.lock()</tt> or <tt>lock.unlock()</tt>.
13545 Change 30.5.2 [thread.condition.condvarany], p18-19:
13549 <pre>template <class Lock, class Rep, class Period>
13550 bool wait_for(Lock& lock, const chrono::duration<Rep, Period>& rel_time);
13556 <blockquote><pre><del>wait_until(lock, chrono::monotonic_clock::now() + rel_time)</del>
13557 </pre></blockquote>
13561 Atomically calls <tt>lock.unlock()</tt> and blocks on <tt>*this</tt>.
13565 When unblocked, calls <tt>lock.lock()</tt> (possibly blocking on the lock) and returns.
13569 The function will unblock when signaled by a call to <tt>notify_one()</tt>, a call to
13570 <tt>notify_all()</tt>, by
13571 the elapsed time <tt>rel_time</tt> passing (30.2.4 [thread.req.timing]),
13576 If the function exits via an exception, <tt>lock.unlock()</tt> shall be called
13577 prior to exiting the function scope.
13582 <i>Postcondition:</i> <tt>lock</tt> is locked by the calling thread.
13586 19 <i>Returns:</i> <tt>false</tt> if the call is returning because the time duration
13587 specified by <tt>rel_time</tt> has elapsed, otherwise <tt>true</tt>.
13591 <i>Throws:</i> <tt>std::system_error</tt> when the returned value, effects,
13592 or postcondition cannot be achieved.
13596 <i>Error conditions:</i>
13601 equivalent error condition from <tt>lock.lock()</tt> or <tt>lock.unlock()</tt>.
13608 Change 30.5.2 [thread.condition.condvarany], p23-p26:
13612 <pre>template <class Lock, class Rep, class Period, class Predicate>
13613 bool wait_for(Lock& lock, const chrono::duration<Rep, Period>& rel_time, Predicate pred);
13617 <i>Precondition:</i> <tt>lock</tt> is locked by the calling thread, and either
13620 <li><ins>no other thread is waiting on this <tt>condition_variable</tt> object or</ins></li>
13621 <li><ins><tt>lock.mutex()</tt> returns the same value for each of the <tt>lock</tt>
13622 arguments supplied by all concurrently waiting threads (via <tt>wait</tt>,
13623 <tt>wait_for</tt> or <tt>wait_until</tt>).</ins></li>
13628 <blockquote><pre><del>wait_until(lock, chrono::monotonic_clock::now() + rel_time, std::move(pred))</del>
13632 Executes a loop: Within the loop the function first evaluates <tt>pred()</tt>
13633 and exits the loop if the result of <tt>pred()</tt> is <tt>true</tt>.
13636 Atomically calls <tt>lock.unlock()</tt>
13637 and blocks on <tt>*this</tt>.
13640 When unblocked, calls <tt>lock.lock()</tt> (possibly blocking on the lock).
13643 The function will unblock when signaled by a call to <tt>notify_one()</tt>, a
13644 call to <tt>notify_all()</tt>, by the elapsed time <tt>rel_time</tt> passing (30.1.4
13645 [thread.req.timing]), or spuriously.
13648 If the function exits via an exception, <tt>lock.unlock()</tt> shall be called
13649 prior to exiting the function scope.
13652 The loop terminates when <tt>pred()</tt> returns <tt>true</tt> or when the time
13653 duration specified by <tt>rel_time</tt> has elapsed.
13659 24 [<i>Note:</i> There is no blocking if <tt>pred()</tt> is initially <tt>true</tt>,
13660 even if the timeout has already expired. <i>-- end note</i>]
13664 <i>Postcondition:</i> <tt>lock</tt> is locked by the calling thread.
13668 25 <i>Returns:</i> <tt>pred()</tt>
13672 26 [<i>Note:</i> The returned value indicates whether the predicate evaluates to
13673 <tt>true</tt> regardless of whether the timeout was triggered. <i>-- end note</i>]
13677 <i>Throws:</i> <tt>std::system_error</tt> when the effects or postcondition cannot be achieved.
13681 <i>Error conditions:</i>
13686 <tt>operation_not_permitted</tt> -- if the thread does not own the lock.
13689 equivalent error condition from <tt>lock.lock()</tt> or <tt>lock.unlock()</tt>.
13703 <h3><a name="860"></a>860. Floating-Point State</h3>
13704 <p><b>Section:</b> 26 [numerics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
13705 <b>Submitter:</b> Lawrence Crowl <b>Opened:</b> 2008-06-23 <b>Last modified:</b> 2009-03-09</p>
13706 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#numerics">active issues</a> in [numerics].</p>
13707 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#numerics">issues</a> in [numerics].</p>
13708 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
13709 <p><b>Discussion:</b></p>
13711 There are a number of functions that affect the floating point state.
13712 These function need to be thread-safe, but I'm unsure of the right
13713 approach in the standard, as we inherit them from C.
13723 Nick: I think we already say that these functions do not introduce data
13724 races; see 17.6.5.6/20
13727 Pete: there's more to it than not introducing data races; are these
13728 states maintained per thread?
13731 Howard: 21.5/14 says that strtok and strerror are not required to avoid
13732 data races, and 20.9/2 says the same about asctime, gmtime, ctime, and
13736 Nick: POSIX has a list of not-safe functions. All other functions are
13737 implicitly thread safe.
13740 Lawrence is to form a group between meetings to attack this issue. Nick
13741 and Tom volunteered to work with Lawrence.
13755 Hans: Sane oses seem ok. Sensible thing is implementable and makes sense.
13758 Nick: Default wording seems to cover this? Hole in POSIX, these
13759 functions need to be added to list of thread-unsafe functions.
13762 Lawrence: Not sufficient, not "thread-safe" per our definition, but
13763 think of state as a thread-local variable. Need something like "these
13764 functions only affect state in the current thread."
13767 Hans: Suggest the following wording: "The floating point environment is
13768 maintained per-thread."
13771 Walter: Any other examples of state being thread safe that are not
13772 already covered elsewhere?
13775 Have thread unsafe functions paper which needs to be updated. Should
13776 just fold in 26.3 [cfenv] functions.
13779 Recommend Open. Lawrence instead suggests leaving it open until we have
13780 suitable wording that may or may not include the thread local
13786 <p><b>Proposed resolution:</b></p>
13795 <h3><a name="861"></a>861. Incomplete specification of EqualityComparable for std::forward_list</h3>
13796 <p><b>Section:</b> 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
13797 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-06-24 <b>Last modified:</b> 2008-11-11</p>
13798 <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>
13799 <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>
13800 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
13801 <p><b>Discussion:</b></p>
13803 Table 89, Container requirements, defines <tt>operator==</tt> in terms of the container
13804 member function <tt>size()</tt> and the algorithm <tt>std::equal</tt>:
13808 <tt>==</tt> is an equivalence relation. <tt>a.size() == b.size() &&
13809 equal(a.begin(), a.end(), b.begin()</tt>
13813 The new container <tt>forward_list</tt> does not provide a <tt>size</tt> member function
13814 by design but does provide <tt>operator==</tt> and <tt>operator!=</tt> without specifying it's semantic.
13817 Other parts of the (sequence) container requirements do also depend on
13818 <tt>size()</tt>, e.g. <tt>empty()</tt>
13819 or <tt>clear()</tt>, but this issue explicitly attempts to solve the missing
13820 <tt>EqualityComparable</tt> specification,
13821 because of the special design choices of <tt>forward_list</tt>.
13824 I propose to apply one of the following resolutions, which are described as:
13829 Provide a definition, which is optimal for this special container without
13830 previous size test. This choice prevents two <tt>O(N)</tt> calls of <tt>std::distance()</tt>
13831 with the corresponding container ranges and instead uses a special
13832 <tt>equals</tt> implementation which takes two container ranges instead of 1 1/2.
13835 The simple fix where the usual test is adapted such that <tt>size()</tt> is replaced
13836 by <tt>distance</tt> with corresponding performance disadvantages.
13840 Both proposal choices are discussed, the preferred choice of the author is
13851 There's an Option C: change the requirements table to use distance().
13854 LWG found Option C acceptable.
13857 Martin will draft the wording for Option C.
13862 post San Francisco:
13867 Martin provided wording for Option C.
13872 <p><b>Proposed resolution:</b></p>
13879 Just betwen 23.3.3.5 [forwardlist.ops] and 23.3.3.6 [forwardlist.spec]
13881 section "forwardlist comparison operators" [forwardlist.compare] (and
13883 new section number to 23.3.3 [forwardlist]/2 in front of "Comparison operators"):
13886 forwardlist comparison operators [forwardlist.compare]
13898 Add to the new section [forwardlist.compare] the following paragraphs:
13902 <pre>template <class T, class Allocator>
13903 bool operator==(const forward_list<T,Allocator>& x, const forward_list<T,Allocator>& y);
13907 <i>Requires:</i> Type <tt>T</tt> is <tt>EqualityComparable</tt> ([equalitycomparable]).
13910 <i>Returns:</i> <tt>true</tt> if
13915 for every iterator <tt>i</tt> in the range <tt>[x.begin(), E)</tt>, where <tt>E ==
13916 x.begin() + M</tt> and <tt>M ==
13917 min(distance(x.begin(), x.end()), distance(y.begin(), y.end()))</tt>,
13918 the following condition holds:
13920 <blockquote><pre>*i == *(y.begin() + (i - x.begin())).
13921 </pre></blockquote>
13924 if <tt>i == E</tt> then <tt>i == x.end() && (y.begin() + (i - x.begin())) == y.end()</tt>.
13927 Otherwise, returns <tt>false</tt>.
13931 <i>Throws:</i> Nothing unless an exception is thrown by the equality comparison.
13934 <i>Complexity:</i> At most <tt>M</tt> comparisons.
13937 <pre>template <class T, class Allocator>
13938 bool operator!=(const forward_list<T,Allocator>& x, const forward_list<T,Allocator>& y);
13941 <i>Returns:</i> <tt>!(x == y)</tt>.
13955 Add to the new section [forwardlist.compare] the following paragraphs:
13958 <pre>template <class T, class Allocator>
13959 bool operator==(const forward_list<T,Allocator>& x, const forward_list<T,Allocator>& y);
13963 <i>Requires:</i> Type <tt>T</tt> is <tt>EqualityComparable</tt> ([equalitycomparable]).
13966 <i>Returns:</i> <tt>distance(x.begin(), x.end()) == distance(y.begin(), y.end())
13967 && equal(x.begin(), x.end(), y.begin())</tt>.
13970 <pre>template <class T, class Allocator>
13971 bool operator!=(const forward_list<T,Allocator>& x, const forward_list<T,Allocator>& y);
13974 <i>Returns:</i> <tt>!(x == y)</tt>.
13989 Change Table 91 - Container Requirements in 23.2.1 [container.requirements.general]
13990 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdf">N2798</a>) like so:
13996 Change the text in the <b>Operational Semantics</b> column in
13997 the row for <tt>a == b</tt> as follows:
14000 <tt>==</tt> is an equivalence relation.
14001 <tt><ins>distance(a.begin(), a.end())</ins>
14002 <del>a.size()</del> ==
14003 <ins>distance(b.begin(), b.end())</ins> <del>b.size()</del> &&
14004 equal(a.begin(), a.end(), b.begin())</tt>
14010 Change the text in the <b>Operational Semantics</b> column in
14011 the row for <tt>a.max_size()</tt> as follows:
14014 <tt><ins>distance(a.begin(), a.end())</ins>
14015 <del>a.size()</del></tt> of the largest possible container
14021 Change the text in the <b>Operational Semantics</b> column in
14022 the row for <tt>a.empty()</tt> as follows:
14025 <tt><ins>a.begin() == a.end()</ins>
14026 <del>a.size() == 0</del></tt>
14032 In addition, for consistency, change the text in the
14033 <b>Operational Semantics</b> column in the row for <tt>a.size()</tt>
14037 <tt><ins>distance(a.begin(), a.end())</ins>
14038 <del>a.end() - a.begin()</del></tt>
14051 <h3><a name="862"></a>862. Impossible complexity for 'includes'</h3>
14052 <p><b>Section:</b> 25.5.5.1 [includes] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Tentatively NAD Editorial</a>
14053 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-07-02 <b>Last modified:</b> 2009-05-23</p>
14054 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#includes">active issues</a> in [includes].</p>
14055 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#includes">issues</a> in [includes].</p>
14056 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD%20Editorial">Tentatively NAD Editorial</a> status.</p>
14057 <p><b>Discussion:</b></p>
14059 In 25.5.5.1 [includes] the complexity is "at most -1 comparisons" if passed
14060 two empty ranges. I don't know how to perform a negative number of
14065 This same issue also applies to:
14069 <li><tt>set_union</tt></li>
14070 <li><tt>set_intersection</tt></li>
14071 <li><tt>set_difference</tt></li>
14072 <li><tt>set_symmetric_difference</tt></li>
14073 <li><tt>merge</tt></li>
14077 2009-03-30 Beman adds:
14082 Suggest NAD. The complexity of empty ranges is -1 in other places in the
14083 standard. See 25.5.4 [alg.merge] <tt>merge</tt> and
14084 <tt>inplace_merge</tt>, and <tt>forward_list</tt> merge, for example.
14085 The time and effort to find and fix all places in the standard where
14086 empty range[s] result in negative complexity isn't worth the very
14091 2009-05-09 Alisdair adds:
14097 I'm not happy with NAD if we can find a simple solution.
14100 How about adding a rider somewhere in clause 17 suggesting that complexities
14101 that specify a negative number of operations are treated as specifying zero
14102 operations? That should generically solve the issue without looking for
14112 Pete to provide "straightforward" wording.
14113 Move to NAD Editorial.
14117 <p><b>Proposed resolution:</b></p>
14127 <h3><a name="863"></a>863. What is the state of a stream after close() succeeds</h3>
14128 <p><b>Section:</b> 27.9.1 [fstreams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">Tentatively NAD</a>
14129 <b>Submitter:</b> Steve Clamage <b>Opened:</b> 2008-07-08 <b>Last modified:</b> 2009-05-23</p>
14130 <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>
14131 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD">Tentatively NAD</a> status.</p>
14132 <p><b>Discussion:</b></p>
14134 Suppose writing to an <tt>[o]fstream</tt> fails and you later close the <tt>stream</tt>.
14135 The <tt>overflow()</tt> function is called to flush the buffer (if it exists).
14136 Then the file is unconditionally closed, as if by calling <tt>flcose</tt>.
14139 If either <tt>overflow</tt> or <tt>fclose</tt> fails, <tt>close()</tt> reports failure, and clearly
14140 the <tt>stream</tt> should be in a failed or bad state.
14143 Suppose the buffer is empty or non-existent (so that <tt>overflow()</tt> does not
14144 fail), and <tt>fclose</tt> succeeds. The <tt>close()</tt> function reports success, but
14145 what is the state of the <tt>stream</tt>?
14154 Tom's impression is that the issue is about the <tt>failbit</tt>, etc.
14157 Bill responds that the stream is now closed,
14158 and any status bits remain unchanged.
14161 See the description of <tt>close()</tt> in 27.9.1.17 [fstream.members].
14164 We prefer not to add wording to say that nothing changes.
14170 <p><b>Proposed resolution:</b></p>
14179 <h3><a name="865"></a>865. More algorithms that throw away information</h3>
14180 <p><b>Section:</b> 25.4.6 [alg.fill], 25.4.7 [alg.generate] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
14181 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-07-13 <b>Last modified:</b> 2009-05-23</p>
14182 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
14183 <p><b>Discussion:</b></p>
14185 In regard to library defect <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#488">488</a> I found some more algorithms which
14186 unnecessarily throw away information. These are typically algorithms,
14187 which sequentially write into an <tt>OutputIterator</tt>, but do not return the
14188 final value of this output iterator. These cases are:
14193 <pre>template<class OutputIterator, class Size, class T>
14194 void fill_n(OutputIterator first, Size n, const T& value);</pre></li>
14197 <pre>template<class OutputIterator, class Size, class Generator>
14198 void generate_n(OutputIterator first, Size n, Generator gen);</pre></li>
14201 In both cases the minimum requirements on the iterator are
14202 <tt>OutputIterator</tt>, which means according to the requirements of
14203 24.2.3 [output.iterators]/2 that only single-pass iterations are guaranteed.
14204 So, if users of <tt>fill_n</tt> and <tt>generate_n</tt> have *only* an <tt>OutputIterator</tt>
14205 available, they have no chance to continue pushing further values
14206 into it, which seems to be a severe limitation to me.
14210 Post Summit Daniel "conceptualized" the wording.
14220 Alisdair likes the idea, but has concerns about the specific wording
14221 about the returns clauses.
14224 Alan notes this is a feature request.
14227 Bill notes we have made similar changes to other algorithms.
14235 <p><b>Proposed resolution:</b></p>
14239 Replace the current declaration of <tt>fill_n</tt> in 25 [algorithms]/2, header
14240 <tt><algorithm></tt> synopsis and in 25.4.6 [alg.fill] by
14243 <blockquote><pre>template<class Iter, IntegralLike Size, class T>
14244 requires OutputIterator<Iter, const T&>
14245 <del>void</del><ins>Iter</ins> fill_n(Iter first, Size n, const T& value);
14246 </pre></blockquote>
14249 Just after the effects clause p.1 add a new returns clause saying:
14252 <i>Returns:</i> For <tt>fill_n</tt> and <tt>n > Size(0)</tt>, returns <tt>first + n</tt>. Otherwise
14253 returns <tt>first</tt> for <tt>fill_n</tt>.
14258 Replace the current declaration of <tt>generate_n</tt> in 25 [algorithms]/2, header
14259 <tt><algorithm></tt> synopsis and in 25.4.7 [alg.generate] by
14261 <blockquote><pre>template<class Iter, IntegralLike Size, Callable Generator>
14262 requires OutputIterator<Iter, Generator::result_type>
14263 && CopyConstructible<Generator>
14264 <del>void</del><ins>Iter</ins> generate_n(Iter first, Size n, Generator gen);
14265 </pre></blockquote>
14267 Just after the effects clause p.1 add a new returns clause saying:
14270 <i>Returns:</i> For <tt>generate_n</tt> and <tt>n > Size(0)</tt>, returns <tt>first + n</tt>.
14271 Otherwise returns <tt>first</tt> for <tt>generate_n</tt>.
14281 <h3><a name="867"></a>867. Valarray and value-initialization</h3>
14282 <p><b>Section:</b> 26.6.2.1 [valarray.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Tentatively NAD Editorial</a>
14283 <b>Submitter:</b> Alberto Ganesh Barbati <b>Opened:</b> 2008-07-20 <b>Last modified:</b> 2009-05-23</p>
14284 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#valarray.cons">active issues</a> in [valarray.cons].</p>
14285 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#valarray.cons">issues</a> in [valarray.cons].</p>
14286 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD%20Editorial">Tentatively NAD Editorial</a> status.</p>
14287 <p><b>Discussion:</b></p>
14289 From 26.6.2.1 [valarray.cons], paragraph 2:
14292 <blockquote><pre>explicit valarray(size_t);
14295 The array created by this constructor has a length equal to the value of the argument. The elements
14296 of the array are constructed using the default constructor for the instantiating type <tt>T</tt>.
14301 The problem is that the most obvious <tt>T</tt>s for <tt>valarray</tt> are <tt>float</tt>
14302 and <tt>double</tt>, they don't have a default constructor. I guess the intent is to value-initialize
14303 the elements, so I suggest replacing:
14307 The elements of the array are constructed using the default constructor for the instantiating type <tt>T</tt>.
14313 The elements of the array are value-initialized.
14317 There is another reference to the default constructor of <tt>T</tt> in the non-normative note in paragraph 9.
14318 That reference should also be replaced. (The normative wording in paragraph 8 refers to <tt>T()</tt>
14319 and so it doesn't need changes).
14327 We agree with the proposed resolution.
14328 Move to NAD Editorial.
14332 <p><b>Proposed resolution:</b></p>
14334 Change 26.6.2.1 [valarray.cons], paragraph 2:
14338 <pre>explicit valarray(size_t);
14341 The array created by this constructor has a length equal to the value of the argument. The elements
14342 of the array are <del>constructed using the default constructor for the instantiating type <tt>T</tt></del>
14343 <ins>value-initialized (8.5 [dcl.init])</ins>.
14348 Change 26.6.2.7 [valarray.members], paragraph 9:
14352 [<i>Example:</i> If the argument has the value -2, the first two elements of the result will be <del>constructed using the
14353 default constructor</del>
14354 <ins>value-initialized (8.5 [dcl.init])</ins>;
14355 the third element of the result will be assigned the value of the first element of the argument; etc. <i>-- end example</i>]
14364 <h3><a name="868"></a>868. default construction and value-initialization</h3>
14365 <p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
14366 <b>Submitter:</b> Alberto Ganesh Barbati <b>Opened:</b> 2008-07-22 <b>Last modified:</b> 2008-09-22</p>
14367 <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>
14368 <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>
14369 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
14370 <p><b>Discussion:</b></p>
14372 The term "default constructed" is often used in wording that predates
14373 the introduction of the concept of value-initialization. In a few such
14374 places the concept of value-initialization is more correct than the
14375 current wording (for example when the type involved can be a built-in)
14376 so a replacement is in order. Two of such places are already covered by
14377 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#867">867</a>. This issue deliberately addresses the hopefully
14378 non-controversial changes in the attempt of being approved more quickly.
14379 A few other occurrences (for example in <tt>std::tuple</tt>,
14380 <tt>std::reverse_iterator</tt> and <tt>std::move_iterator</tt>) are left to separate
14381 issues. For <tt>std::reverse_iterator</tt>, see also issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#408">408</a>. This issue is
14382 related with issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#724">724</a>.
14392 The list provided in the proposed resolution is not complete. James
14393 Dennett will review the library and provide a complete list and will
14394 double-check the vocabulary.
14397 This issue relates to Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#886">886</a> tuple construction
14402 <p><b>Proposed resolution:</b></p>
14404 Change X [utility.arg.requirements], paragraph 2:
14408 In general, a default constructor is not required. Certain container class member function signatures specify
14409 <del>the default constructor</del>
14410 <ins><tt>T()</tt></ins>
14411 as a default argument. <tt>T()</tt> shall be a well-defined expression (8.5 [dcl.init]) if one of
14412 those signatures is called using the default argument (8.3.6 [dcl.fct.default]).
14416 In all the following paragraphs in clause 23 [containers], replace "default constructed" with "value-initialized
14421 <li>23.3.2.1 [deque.cons] para 2</li>
14422 <li>23.3.2.2 [deque.capacity] para 1</li>
14423 <li>23.3.3.1 [forwardlist.cons] para 3</li>
14424 <li>23.3.3.4 [forwardlist.modifiers] para 21</li>
14425 <li>23.3.4.1 [list.cons] para 3</li>
14426 <li>23.3.4.2 [list.capacity] para 1</li>
14427 <li>23.3.6.1 [vector.cons] para 3</li>
14428 <li>23.3.6.2 [vector.capacity] para 10</li>
14436 <h3><a name="869"></a>869. Bucket (local) iterators and iterating past end</h3>
14437 <p><b>Section:</b> 23.2.5 [unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
14438 <b>Submitter:</b> Sohail Somani <b>Opened:</b> 2008-07-22 <b>Last modified:</b> 2009-03-09</p>
14439 <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>
14440 <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>
14441 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
14442 <p><b>Discussion:</b></p>
14444 Is there any language in the current draft specifying the behaviour of the following snippet?
14447 <blockquote><pre>unordered_set<int> s;
14448 unordered_set<int>::local_iterator it = s.end(0);
14450 // Iterate past end - the unspecified part
14452 </pre></blockquote>
14455 I don't think there is anything about <tt>s.end(n)</tt> being considered an
14456 iterator for the past-the-end value though (I think) it should be.
14465 We believe that this is not a substantive change, but the proposed
14466 change to the wording is clearer than what we have now.
14475 Recommend Tentatively Ready.
14480 <p><b>Proposed resolution:</b></p>
14482 Change Table 97 "Unordered associative container requirements" in 23.2.5 [unord.req]:
14487 <caption>Table 97: Unordered associative container requirements</caption>
14489 <th>expression</th><th>return type</th><th>assertion/note pre/post-condition</th><th>complexity</th>
14492 <td><tt>b.begin(n)</tt></td>
14493 <td><tt>local_iterator</tt><br><tt>const_local_iterator</tt> for const <tt>b</tt>.</td>
14494 <td>Pre: n shall be in the range [0,b.bucket_count()). <del>Note: [b.begin(n), b.end(n)) is a
14495 valid range containing all of the elements in the n<sup>th</sup> bucket.</del>
14496 <ins><tt>b.begin(n)</tt> returns an iterator referring to the first element in the bucket.
14497 If the bucket is empty, then <tt>b.begin(n) == b.end(n)</tt>.</ins></td>
14501 <td><tt>b.end(n)</tt></td>
14502 <td><tt>local_iterator</tt><br><tt>const_local_iterator</tt> for const <tt>b</tt>.</td>
14503 <td>Pre: n shall be in the range <tt>[0, b.bucket_count())</tt>.
14504 <ins><tt>b.end(n)</tt> returns an iterator which is the past-the-end value for the bucket.</ins></td>
14516 <h3><a name="873"></a>873. signed integral type and unsigned integral type are not clearly defined</h3>
14517 <p><b>Section:</b> 3.9.1 [basic.fundamental] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
14518 <b>Submitter:</b> Travis Vitek <b>Opened:</b> 2008-06-30 <b>Last modified:</b> 2009-03-21</p>
14519 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
14520 <p><b>Discussion:</b></p>
14522 Neither the term "signed integral type" nor the term "unsigned
14523 integral type" is defined in the core language section of the
14524 standard, therefore the library section should avoid its use. The
14525 terms <i>signed integer type</i> and <i>unsigned integer type</i> are
14526 indeed defined (in 3.9.1 [basic.fundamental]), thus the usages should be
14527 replaced accordingly.
14531 Note that the key issue here is that "signed" + "integral type" !=
14532 "signed integral type".
14534 The types <code>bool</code>, <code>char</code>, <code>char16_t</code>,
14535 <code>char32_t</code> and <code>wchar_t</code> are all listed as
14536 integral types, but are neither of <i>signed integer type</i> or
14537 <i>unsigned integer type</i>. According to 3.9 [basic.types] p7, a synonym for
14538 integral type is <i>integer type</i>.
14540 Given this, one may choose to assume that an <i>integral type</i> that
14541 can represent values less than zero is a <i>signed integral type</i>.
14542 Unfortunately this can cause ambiguities.
14544 As an example, if <code>T</code> is <code>unsigned char</code>, the
14545 expression <code>make_signed<T>::type</code>, is supposed to
14546 name a signed integral type. There are potentially two types that
14547 satisfy this requirement, namely <code>signed char</code> and
14548 <code>char</code> (assuming <code>CHAR_MIN < 0</code>).
14557 Plum, Sebor to review.
14561 Post Summit Daniel adds:
14566 The proposed resolution needs to be "conceptualized". Currently we have
14567 in 14.10.4 [concept.support] only concept <tt>IntegralType</tt>
14568 for all "integral types", thus indeed the current <tt>Container</tt>
14569 concept and Iterator concepts are sufficiently satisfied with "integral
14570 types". If the changes are applied, we might ask core for concept
14571 <tt>BilateralIntegerType</tt> and add proper restrictions to the library
14577 <p><b>Proposed resolution:</b></p>
14579 I propose to use the terms "signed integer type" and "unsigned integer
14580 type" in place of "signed integral type" and "unsigned integral type"
14581 to eliminate such ambiguities.
14585 The proposed change makes it absolutely clear that the difference
14586 between two pointers cannot be <tt>char</tt> or <tt>wchar_t</tt>,
14587 but could be any of the signed integer types.
14588 5.7 [expr.add] paragraph 6...
14594 When two pointers to elements of the same array object are
14595 subtracted, the result is the difference of the subscripts of
14596 the two array elements. The type of the result is an
14597 implementation-defined <del>signed integral
14598 type</del><ins>signed integer type</ins>; this type shall be the
14599 same type that is defined as <code>std::ptrdiff_t</code> in the
14600 <code><cstdint></code> header (18.1)...
14607 The proposed change makes it clear that <tt>X::size_type</tt> and
14608 <tt>X::difference_type</tt> cannot be <tt>char</tt> or
14609 <tt>wchar_t</tt>, but could be one of the signed or unsigned integer
14610 types as appropriate.
14611 X [allocator.requirements] table 40...
14614 Table 40: Allocator requirements
14618 <th>expression</th>
14619 <th>return type</th>
14620 <th>assertion/note/pre/post-condition</th>
14625 <td><tt>X::size_type</tt></td>
14627 <del>unsigned integral type</del>
14628 <ins>unsigned integer type</ins>
14630 <td>a type that can represent the size of the largest object in
14631 the allocation model.</td>
14634 <td><tt>X::difference_type</tt></td>
14636 <del>signed integral type</del>
14637 <ins>signed integer type</ins>
14639 <td>a type that can represent the difference between any two
14640 pointers in the allocation model.</td>
14647 The proposed change makes it clear that <tt>make_signed<T>::type</tt>
14648 must be one of the signed integer types as defined in 3.9.1. Ditto for
14649 <tt>make_unsigned<T>type</tt> and unsigned integer types.
14650 20.6.6.3 [meta.trans.sign] table 48...
14653 Table 48: Sign modifications
14664 <tt>template <class T> struct make_signed;</tt>
14667 If <code>T</code> names a (possibly cv-qualified) <del>signed
14668 integral type</del><ins>signed integer type</ins> (3.9.1) then
14669 the member typedef <code>type</code> shall name the type
14670 <code>T</code>; otherwise, if <code>T</code> names a (possibly
14671 cv-qualified) <del>unsigned integral type</del><ins>unsigned
14672 integer type</ins> then <code>type</code> shall name the
14673 corresponding <del>signed integral type</del><ins>signed
14674 integer type</ins>, with the same cv-qualifiers as
14675 <code>T</code>; otherwise, <code>type</code> shall name the
14676 <del>signed integral type</del><ins>signed integer type</ins>
14677 with the smallest rank (4.13) for which <code>sizeof(T) ==
14678 sizeof(type)</code>, with the same cv-qualifiers as
14681 <i>Requires:</i> <code>T</code> shall be a (possibly
14682 cv-qualified) integral type or enumeration but not a
14683 <code>bool</code> type.
14688 <tt>template <class T> struct make_unsigned;</tt>
14691 If <code>T</code> names a (possibly cv-qualified)
14692 <del>unsigned integral type</del><ins>unsigned integer
14693 type</ins> (3.9.1) then the member typedef <code>type</code>
14694 shall name the type <code>T</code>; otherwise, if
14695 <code>T</code> names a (possibly cv-qualified) <del>signed
14696 integral type</del><ins>signed integer type</ins> then
14697 <code>type</code> shall name the corresponding <del>unsigned
14698 integral type</del><ins>unsigned integer type</ins>, with the
14699 same cv-qualifiers as <code>T</code>; otherwise,
14700 <code>type</code> shall name the <del>unsigned integral
14701 type</del><ins>unsigned integer type</ins> with the smallest
14702 rank (4.13) for which <code>sizeof(T) == sizeof(type)</code>,
14703 with the same cv-qualifiers as <code>T</code>.
14705 <i>Requires:</i> <code>T</code> shall be a (possibly
14706 cv-qualified) integral type or enumeration but not a
14707 <code>bool</code> type.
14716 Note: I believe that the basefield values should probably be
14717 prefixed with <tt>ios_base::</tt> as they are in 22.4.2.2.2 [facet.num.put.virtuals]
14719 The listed virtuals are all overloaded on signed and unsigned integer
14720 types, the new wording just maintains consistency.
14722 22.4.2.1.2 [facet.num.get.virtuals] table 78...
14725 Table 78: Integer Conversions
14730 <th><tt>stdio</tt> equivalent</th>
14735 <td><tt>basefield == oct</tt></td>
14736 <td><tt>%o</tt></td>
14739 <td><tt>basefield == hex</tt></td>
14740 <td><tt>%X</tt></td>
14743 <td><tt>basefield == 0</tt></td>
14744 <td><tt>%i</tt></td>
14747 <td><del>signed integral type</del><ins>signed integer
14749 <td><tt>%d</tt></td>
14752 <td><del>unsigned integral type</del><ins>unsigned integer
14754 <td><tt>%u</tt></td>
14763 Rationale is same as above.
14764 22.4.2.2.2 [facet.num.put.virtuals] table 80...
14767 Table 80: Integer Conversions
14772 <th><tt>stdio</tt> equivalent</th>
14777 <td><tt>basefield == ios_base::oct</tt></td>
14778 <td><tt>%o</tt></td>
14781 <td><tt>(basefield == ios_base::hex) &&
14782 !uppercase</tt></td>
14783 <td><tt>%x</tt></td>
14786 <td><tt>(basefield == ios_base::hex)</tt></td>
14787 <td><tt>%X</tt></td>
14790 <td><tt>basefield == 0</tt></td>
14791 <td><tt>%i</tt></td>
14794 <td>for a <del>signed integral type</del><ins>signed integer
14796 <td><tt>%d</tt></td>
14799 <td>for a <del>unsigned integral type</del><ins>unsigned integer
14801 <td><tt>%u</tt></td>
14809 23.2 [container.requirements] table 80...
14812 Table 89: Container requirements
14816 <th>expression</th>
14817 <th>return type</th>
14818 <th>operational semantics</th>
14819 <th>assertion/note/pre/post-condition</th>
14820 <th>complexity</th>
14825 <td><tt>X::difference_type</tt></td>
14826 <td><del>signed integral type</del><ins>signed integer type</ins></td>
14828 <td>is identical to the difference type of <tt>X::iterator</tt>
14829 and <tt>X::const_iterator</tt></td>
14830 <td>compile time</td>
14833 <td><tt>X::size_type</tt></td>
14834 <td><del>unsigned integral type</del><ins>unsigned integer type</ins></td>
14836 <td><tt>size_type</tt> can represent any non-negative value of
14837 <tt>difference_type</tt></td>
14838 <td>compile time</td>
14845 24.2 [iterator.concepts] paragraph 1...
14848 Iterators are a generalization of pointers that allow a C++ program to
14849 work with different data structures (containers) in a uniform manner.
14850 To be able to construct template algorithms that work correctly and
14851 efficiently on different types of data structures, the library
14852 formalizes not just the interfaces but also the semantics and
14853 complexity assumptions of iterators. All input iterators
14854 <code>i</code> support the expression <code>*i</code>, resulting in a
14855 value of some class, enumeration, or built-in type <code>T</code>,
14856 called the <i>value type</i> of the iterator. All output iterators
14857 support the expression <code>*i = o</code> where <code>o</code> is a
14858 value of some type that is in the set of types that are
14859 <i>writable</i> to the particular iterator type of <code>i</code>. All
14860 iterators <code>i</code> for which the expression <code>(*i).m</code>
14861 is well-defined, support the expression <code>i->m</code> with the
14862 same semantics as <code>(*i).m</code>. For every iterator type
14863 <code>X</code> for which equality is defined, there is a corresponding
14864 <del>signed integral type</del> <ins>signed integer type</ins> called
14865 the <i>difference type</i> of the iterator.
14869 I'm a little unsure of this change. Previously this paragraph would
14870 allow instantiations of <tt>linear_congruential_engine</tt> on
14871 <tt>char</tt>, <tt>wchar_t</tt>, <tt>bool</tt>, and other types. The
14872 new wording prohibits this.
14873 26.5.3.1 [rand.eng.lcong] paragraph 2...
14876 The template parameter <code>UIntType</code> shall denote an
14877 <del>unsigned integral type</del><ins>unsigned integer type</ins>
14878 large enough to store values as large as <code>m - 1</code>. If the
14879 template parameter <code>m</code> is 0, the modulus <code>m</code>
14880 used throughout this section 26.4.3.1 is
14881 <code>numeric_limits<result_type>::max()</code> plus 1. [Note:
14882 The result need not be representable as a value of type
14883 <code>result_type</code>. --end note] Otherwise, the following
14884 relations shall hold: <code>a < m</code> and <code>c <
14889 Same rationale as the previous change.
14890 X [rand.adapt.xor] paragraph 6...
14893 Both <code>Engine1::result_type</code> and
14894 <code>Engine2::result_type</code> shall denote (possibly different)
14895 <del>unsigned integral types</del><ins>unsigned integer types</ins>.
14896 The member <i>result_type</i> shall denote either the type
14897 <i>Engine1::result_type</i> or the type <i>Engine2::result_type</i>,
14898 whichever provides the most storage according to clause 3.9.1.
14902 26.5.7.1 [rand.util.seedseq] paragraph 7...
14905 <i>Requires:</i><code>RandomAccessIterator</code> shall meet the
14906 requirements of a random access iterator (24.1.5) such that
14907 <code>iterator_traits<RandomAccessIterator>::value_type</code>
14908 shall denote an <del>unsigned integral type</del><ins>unsigned integer
14909 type</ins> capable of accomodating 32-bit quantities.
14913 By making this change, integral types that happen to have a signed
14914 representation, but are not signed integer types, would no longer be
14915 required to use a two's complement representation. This may go against
14916 the original intent, and should be reviewed.
14917 29.6 [atomics.types.operations] paragraph 24...
14920 <i>Remark:</i> For <del>signed integral types</del><ins>signed integer
14921 types</ins>, arithmetic is defined using two's complement
14922 representation. There are no undefined results. For address types, the
14923 result may be an undefined address, but the operations otherwise have
14924 no undefined behavior.
14933 <h3><a name="876"></a>876. <tt>basic_string</tt> access operations should give stronger guarantees</h3>
14934 <p><b>Section:</b> 21.4 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
14935 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-08-22 <b>Last modified:</b> 2008-09-18</p>
14936 <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>
14937 <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>
14938 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
14939 <p><b>Discussion:</b></p>
14941 During the Sophia Antipolis meeting it was decided to split-off some
14943 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2647.html">n2647</a>
14944 ("Concurrency modifications for <tt>basic_string</tt>")
14945 proposal into a separate issue, because these weren't actually
14946 concurrency-related. The here proposed changes refer to the recent
14948 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2668.htm">n2668</a>
14949 and attempt to take advantage of the
14950 stricter structural requirements.
14953 Indeed there exists some leeway for more guarantees that would be
14954 very useful for programmers, especially if interaction with transactionary
14955 or exception-unaware C API code is important. This would also allow
14956 compilers to take advantage of more performance optimizations, because
14957 more functions can have throw() specifications. This proposal uses the
14958 form of "Throws: Nothing" clauses to reach the same effect, because
14959 there already exists a different issue in progress to clean-up the current
14960 existing "schizophrenia" of the standard in this regard.
14963 Due to earlier support for copy-on-write, we find the following
14964 unnecessary limitations for C++0x:
14969 Missing no-throw guarantees: <tt>data()</tt> and <tt>c_str()</tt> simply return
14970 a pointer to their guts, which is a non-failure operation. This should
14971 be spelled out. It is also noteworthy to mention that the same
14972 guarantees should also be given by the size query functions,
14973 because the combination of pointer to content and the length is
14974 typically needed during interaction with low-level API.
14977 Missing complexity guarantees: <tt>data()</tt> and <tt>c_str()</tt> simply return
14978 a pointer to their guts, which is guaranteed O(1). This should be
14982 Missing reading access to the terminating character: Only the
14983 const overload of <tt>operator[]</tt> allows reading access to the terminator
14984 char. For more intuitive usage of strings, reading access to this
14985 position should be extended to the non-const case. In contrast
14986 to C++03 this reading access should now be homogeneously
14992 The proposed resolution is split into a main part (A) and a
14993 secondary part (B) (earlier called "Adjunct Adjunct Proposal").
14994 (B) extends (A) by also making access to index position
14995 size() of the at() overloads a no-throw operation. This was
14996 separated, because this part is theoretically observable in
14997 specifically designed test programs.
15007 We oppose part 1 of the issue but hope to address <tt>size()</tt> in
15008 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#877">877</a>.
15011 We do not support part B. 4 of the issue because of the breaking API change.
15014 We support part A. 2 of the issue.
15017 On support part A. 3 of the issue:
15020 Pete's broader comment: now that we know that basic_string will be a
15021 block of contiguous memory, we should just rewrite its specification
15022 with that in mind. The expression of the specification will be simpler
15023 and probably more correct as a result.
15028 <p><b>Proposed resolution:</b></p>
15033 <p>In 21.4.4 [string.capacity], just after p. 1 add a new paragraph:
15036 <i>Throws:</i> Nothing.
15042 In 21.4.5 [string.access] <em>replace</em> p. 1 by the following <em>4</em> paragraghs:
15047 <i>Requires:</i> <tt>pos ≤ size()</tt>.
15050 <i>Returns:</i> If <tt>pos < size()</tt>, returns <tt>*(begin() + pos)</tt>. Otherwise, returns
15051 a reference to a <tt>charT()</tt> that shall not be modified.
15054 <i>Throws:</i> Nothing.
15057 <i>Complexity:</i> Constant time.
15064 In 21.4.7.1 [string.accessors] replace the now <em>common</em> returns
15065 clause of <tt>c_str()</tt> and <tt>data()</tt> by the following <em>three</em> paragraphs:
15069 <i>Returns:</i> A pointer <tt>p</tt> such that <tt>p+i == &operator[](i)</tt> for each <tt>i</tt>
15070 in <tt>[0, size()]</tt>.
15073 <i>Throws:</i> Nothing.
15076 <i>Complexity:</i> Constant time.
15086 In 21.4.5 [string.access] <em>replace</em> p.2 and p.3 by:
15090 <i>Requires:</i> <tt>pos ≤ size()</tt>
15093 <i>Throws:</i> <tt>out_of_range</tt> if <tt>pos > size()</tt>.
15107 <h3><a name="877"></a>877. to <tt>throw()</tt> or to <i>Throw:</i> Nothing.</h3>
15108 <p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
15109 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2008-08-23 <b>Last modified:</b> 2008-09-18</p>
15110 <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>
15111 <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>
15112 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
15113 <p><b>Discussion:</b></p>
15117 the <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2691.pdf">working
15118 draft</a> have introduced a gratuitous inconsistency with the C++ 2003
15119 version of the specification with respect to exception guarantees
15120 provided by standard functions. While the C++ 2003 standard
15121 consistenly uses the empty exception specification, <tt>throw()</tt>,
15122 to declare functions that are guaranteed not to throw exceptions, the
15123 current working draft contains a number of "<i>Throws:</i> Nothing."
15124 clause to specify essentially the same requirement. The difference
15125 between the two approaches is that the former specifies the behavior
15126 of programs that violate the requirement (<tt>std::unexpected()</tt>
15127 is called) while the latter leaves the behavior undefined.
15132 A survey of the working draft reveals that there are a total of 209
15133 occurrences of <tt>throw()</tt> in the library portion of the spec,
15134 the majority in clause 18, a couple (literally) in 19, a handful in
15135 20, a bunch in 22, four in 24, one in 27, and about a dozen in D.9.
15140 There are also 203 occurrences of "<i>Throws:</i> Nothing." scattered
15141 throughout the spec.
15146 While sometimes there are good reasons to use the "<i>Throws:</i>
15147 Nothing." approach rather than making use of <tt>throw()</tt>, these
15148 reasons do not apply in most of the cases where this new clause has
15149 been introduced and the empty exception specification would be a
15155 First, functions declared with the empty exception specification
15156 permit compilers to generate better code for calls to such
15157 functions. In some cases, the compiler might even be able to eliminate
15158 whole chunks of user-written code when instantiating a generic
15159 template on a type whose operations invoked from the template
15160 specialization are known not to throw. The prototypical example are
15161 the <tt>std::uninitialized_copy()</tt>
15162 and <tt>std::uninitialized_fill()</tt> algorithms where the
15163 entire <tt>catch(...)</tt> block can be optimized away.
15168 For example, given the following definition of
15169 the <tt>std::uninitialized_copy</tt> function template and a
15170 user-defined type <tt>SomeType</tt>:
15174 <pre>template <class InputIterator, class ForwardIterator>
15176 uninitialized_copy (InputIterator first, InputIterator last, ForwardIterator res)
15178 typedef iterator_traits<ForwardIterator>::value_type ValueType;
15180 ForwardIterator start = res;
15183 for (; first != last; ++first, ++res)
15184 ::new (&*res) ValueType (*first);
15187 for (; start != res; --start)
15188 (&*start)->~ValueType ();
15195 SomeType (const SomeType&) <ins>throw ()</ins>;
15200 compilers are able to emit the following efficient specialization
15201 of <tt>std::uninitialized_copy<const SomeType*, SomeType*></tt>
15202 (note that the <tt>catch</tt> block has been optimized away):
15206 <pre>template <> SomeType*
15207 uninitialized_copy (const SomeType *first, const SomeType *last, SomeType *res)
15209 for (; first != last; ++first, ++res)
15210 ::new (res) SomeType (*first);
15217 Another general example is default constructors which, when decorated
15218 with <tt>throw()</tt>, allow the compiler to eliminate the
15219 implicit <tt>try</tt> and <tt>catch</tt> blocks that it otherwise must
15220 emit around each the invocation of the constructor
15221 in <i>new-expressions</i>.
15226 For example, given the following definitions of
15227 class <tt>MayThrow</tt> and <tt>WontThrow</tt> and the two
15232 <pre>struct MayThrow {
15237 WontThrow () <ins>throw ()</ins>;
15240 MayThrow *a = new MayThrow [N];
15241 WontThrow *b = new WontThrow [N];</pre>
15246 the compiler generates the following code for the first statement:
15252 MayThrow *first = operator new[] (N * sizeof (*a));
15253 MayThrow *last = first + N;
15254 MayThrow *next = first;
15256 for ( ; next != last; ++next)
15257 new (next) MayThrow;
15260 for ( ; first != first; --next)
15261 next->~MayThrow ();
15262 operator delete[] (first);
15270 but it is can generate much more compact code for the second statement:
15274 <pre>WontThrow *b = operator new[] (N * sizeof (*b));
15275 WontThrow *last = b + N;
15276 for (WontThrow *next = b; next != last; ++next)
15277 new (next) WontThrow;
15282 Second, in order for users to get the maximum benefit out of the new
15283 <tt>std::has_nothrow_xxx</tt> traits when using standard library types
15284 it will be important for implementations to decorate all non throwing
15285 copy constructors and assignment operators with <tt>throw()</tt>. Note
15286 that while an optimizer may be able to tell whether a function without
15287 an explicit exception specification can throw or not based on its
15288 definition, it can only do so when it can see the source code of the
15289 definition. When it can't it must assume that the function may
15290 throw. To prevent violating the One Definition Rule,
15291 the <tt>std::has_nothrow_xxx</tt> trait must return the most
15292 pessimistic guess across all translation units in the program, meaning
15293 that <tt>std::has_nothrow_xxx<T>::value</tt> must evaluate to
15294 <tt>false</tt> for any <tt>T</tt> whose <tt>xxx</tt>
15295 (where <tt>xxx</tt> is default or copy ctor, or assignment operator)
15296 is defined out-of-line.
15301 <b>Counterarguments:</b>
15306 During the discussion of this issue
15307 on <a href="mailto:c++std-lib@accu.org">c++std-lib@accu.org</a>
15308 (starting with post <tt>c++std-lib-21950</tt>) the following arguments
15309 in favor of the "<i>Throws:</i> Nothing." style have been made.
15316 Decorating functions that cannot throw with the empty exception
15317 specification can cause the compiler to generate suboptimal code for
15318 the implementation of the function when it calls other functions that
15319 aren't known to the compiler not to throw (i.e., that aren't decorated
15320 with <tt>throw()</tt> even if they don't actually throw). This is a
15321 common situation when the called function is a C or POSIX function.
15326 Alternate, proprietary mechanisms exist (such as
15327 GCC <a href="http://gcc.gnu.org/onlinedocs/gcc-4.3.0/gcc/Function-Attributes.html#index-g_t_0040code_007bnothrow_007d-function-attribute-2160"><tt>__attribute__((nothrow))</tt></a>
15329 C++ <a href="http://msdn.microsoft.com/en-us/library/49147z04%28VS.80%29.aspx"><tt>__declspec(nothrow)</tt></a>)
15330 that let implementers mark up non-throwing functions, often without
15331 the penalty mentioned in (1) above. The C++ standard shouldn't
15332 preclude the use of these potentially more efficient mechanisms.
15337 There are functions, especially function templates, that invoke
15338 user-defined functions that may or may not be
15339 declared <tt>throw()</tt>. Declaring such functions with the empty
15340 exception specification will cause compilers to generate suboptimal
15341 code when the user-defined function isn't also declared not to throw.
15348 The answer to point (1) above is that implementers can (and some have)
15349 declare functions with <tt>throw()</tt> to indicate to the compiler
15350 that calls to the function can safely be assumed not to throw in order
15351 to allow it to generate efficient code at the call site without also
15352 having to define the functions the same way and causing the compiler
15353 to generate suboptimal code for the function definition. That is, the
15354 function is declared with <tt>throw()</tt> in a header but it's
15355 defined without it in the source file. The <tt>throw()</tt>
15356 declaration is suppressed when compiling the definition to avoid
15357 compiler errors. This technique, while strictly speaking no permitted
15358 by the language, is safe and has been employed in practice. For
15359 example, the GNU C library takes this approach. Microsoft Visual C++
15360 takes a similar approach by simply assuming that no function with C
15361 language linkage can throw an exception unless it's explicitly
15362 declared to do so using the language extension <tt>throw(...)</tt>.
15367 Our answer to point (2) above is that there is no existing practice
15368 where C++ Standard Library implementers have opted to make use of the
15369 proprietary mechanisms to declare functions that don't throw. The
15370 language provides a mechanism specifically designed for this
15371 purpose. Avoiding its use in the specification itself in favor of
15372 proprietary mechanisms defeats the purpose of the feature. In
15373 addition, making use of the empty exception specification
15374 inconsistently, in some areas of the standard, while conspicuously
15375 avoiding it and making use of the "<i>Throws:</i> Nothing." form in
15376 others is confusing to users.
15381 The answer to point (3) is simply to exercise caution when declaring
15382 functions and especially function templates with the empty exception
15383 specification. Functions that required not to throw but that may call
15384 back into user code are poor candidates for the empty exception
15385 specification and should instead be specified using "<i>Throws:</i>
15390 <p><b>Proposed resolution:</b></p>
15393 We propose two possible solutions. Our recommendation is to adopt
15404 Except for functions or function templates that make calls back to
15405 user-defined functions that may not be declared <tt>throw()</tt>
15406 replace all occurrences of the "<i>Throws:</i> Nothing." clause with
15407 the empty exception specification. Functions that are required not to
15408 throw but that make calls back to user code should be specified to
15409 "<i>Throw:</i> Nothing."
15419 For consistency, replace all occurrences of the empty exception
15420 specification with a "<i>Throws:</i> Nothing." clause.
15428 <h3><a name="878"></a>878. <tt>forward_list</tt> preconditions</h3>
15429 <p><b>Section:</b> 23.3.3 [forwardlist] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
15430 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2008-08-23 <b>Last modified:</b> 2009-05-10</p>
15431 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
15432 <p><b>Discussion:</b></p>
15435 <tt>forward_list</tt> member functions that take
15436 a <tt>forward_list::iterator</tt> (denoted <tt>position</tt> in the
15437 function signatures) argument have the following precondition:
15442 <i>Requires:</i> <tt>position</tt> is dereferenceable or equal
15443 to <tt>before_begin()</tt>.
15448 I believe what's actually intended is this:
15453 <i>Requires:</i> <tt>position</tt> is in the range
15454 [<tt>before_begin()</tt>, <tt>end()</tt>).
15459 That is, when it's dereferenceable, <tt>position</tt> must point
15460 into <tt>*this</tt>, not just any <tt>forward_list</tt> object.
15470 Robert suggested alternate proposed wording which had large support.
15480 Walter: "position is before_begin() or a dereferenceable": add "is" after the "or"
15483 With that minor update, Recommend Tentatively Ready.
15489 <p><b>Proposed resolution:</b></p>
15492 Change the <i>Requires</i> clauses
15493 [forwardlist] , p21, p24, p26, p29, and,
15494 23.3.3.5 [forwardlist.ops], p39, p43, p47
15500 <i>Requires:</i> <tt>position</tt> is <ins><tt>before_begin()</tt> or is a</ins>
15502 <ins>iterator in the range <tt>[begin(), end())</tt></ins>
15503 <del>or equal to <tt>before_begin()</tt></del>. ...
15511 <h3><a name="879"></a>879. Atomic load const qualification</h3>
15512 <p><b>Section:</b> 29 [atomics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
15513 <b>Submitter:</b> Alexander Chemeris <b>Opened:</b> 2008-08-24 <b>Last modified:</b> 2009-03-22</p>
15514 <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>
15515 <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>
15516 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
15517 <p><b>Discussion:</b></p>
15519 The <tt>atomic_address</tt> type and <tt>atomic<T*></tt> specialization provide atomic
15520 updates to pointers. However, the current specification requires
15521 that the types pointer be to non-const objects. This restriction
15522 is unnecessary and unintended.
15530 Move to review. Lawrence will first check with Peter whether the
15531 current examples are sufficient, or whether they need to be expanded to
15536 <p><b>Proposed resolution:</b></p>
15538 Add const qualification to the pointer values of the <tt>atomic_address</tt>
15539 and <tt>atomic<T*></tt> specializations. E.g.
15542 <blockquote><pre>typedef struct atomic_address {
15543 void store(<ins>const</ins> void*, memory_order = memory_order_seq_cst) volatile;
15544 void* exchange( <ins>const</ins> void*, memory_order = memory_order_seq_cst) volatile;
15545 bool compare_exchange( <ins>const</ins> void*&, <ins>const</ins> void*,
15546 memory_order, memory_order) volatile;
15547 bool compare_exchange( <ins>const</ins> void*&, <ins>const</ins> void*,
15548 memory_order = memory_order_seq_cst ) volatile;
15549 void* operator=(<ins>const</ins> void*) volatile;
15552 void atomic_store(volatile atomic_address*, <ins>const</ins> void*);
15553 void atomic_store_explicit(volatile atomic_address*, <ins>const</ins> void*,
15555 void* atomic_exchange(volatile atomic_address*<ins>, const void*</ins>);
15556 void* atomic_exchange_explicit(volatile atomic_address*, <ins>const</ins> void*,
15558 bool atomic_compare_exchange(volatile atomic_address*,
15559 <ins>const</ins> void**, <ins>const</ins> void*);
15560 bool atomic_compare_exchange_explicit(volatile atomic_address*,
15561 <ins>const</ins> void**, <ins>const</ins> void*,
15562 memory_order, memory_order);
15563 </pre></blockquote>
15570 <h3><a name="880"></a>880. Missing atomic exchange parameter</h3>
15571 <p><b>Section:</b> 29 [atomics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
15572 <b>Submitter:</b> Lawrence Crowl <b>Opened:</b> 2008-08-24 <b>Last modified:</b> 2009-03-22</p>
15573 <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>
15574 <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>
15575 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
15576 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#942">942</a></p>
15577 <p><b>Discussion:</b></p>
15579 The <tt>atomic_exchange</tt> and <tt>atomic_exchange_explicit</tt> functions seem to
15580 be inconsistently missing parameters.
15590 Lawrence: Need to write up a list for Pete with details.
15593 Detlef: Should not be New, we already talked about in Concurrency group.
15601 <p><b>Proposed resolution:</b></p>
15603 Add the appropriate parameters. For example,
15606 <blockquote><pre>bool atomic_exchange(volatile atomic_bool*<ins>, bool</ins>);
15607 bool atomic_exchange_explicit(volatile atomic_bool*, bool<ins>, memory_order</ins>);
15608 </pre></blockquote>
15615 <h3><a name="881"></a>881. shared_ptr conversion issue</h3>
15616 <p><b>Section:</b> 20.8.13.2.1 [util.smartptr.shared.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
15617 <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2008-08-30 <b>Last modified:</b> 2008-09-18</p>
15618 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#util.smartptr.shared.const">active issues</a> in [util.smartptr.shared.const].</p>
15619 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared.const">issues</a> in [util.smartptr.shared.const].</p>
15620 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
15621 <p><b>Discussion:</b></p>
15623 We've changed <tt>shared_ptr<Y></tt> to not convert to <tt>shared_ptr<T></tt> when <tt>Y*</tt>
15624 doesn't convert to <tt>T*</tt> by resolving issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>. This only fixed the
15625 converting copy constructor though.
15626 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2351.htm">N2351</a>
15627 later added move support, and
15628 the converting move constructor is not constrained.
15637 We might be able to move this to NAD, Editorial once shared_ptr is
15638 conceptualized, but we want to revisit this issue to make sure.
15642 <p><b>Proposed resolution:</b></p>
15644 We need to change the Requires clause of the move constructor:
15647 <blockquote><pre>shared_ptr(shared_ptr&& r);
15648 template<class Y> shared_ptr(shared_ptr<Y>&& r);
15651 <i>Requires:</i> <del>For the second constructor <tt>Y*</tt> shall be
15652 convertible to <tt>T*</tt>.</del>
15654 The second constructor shall not participate in overload resolution
15655 unless <tt>Y*</tt> is convertible to <tt>T*</tt>.
15661 in order to actually make the example in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a> compile
15662 (it now resolves to the move constructor).
15671 <h3><a name="883"></a>883. swap circular definition</h3>
15672 <p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
15673 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-09-10 <b>Last modified:</b> 2009-03-11</p>
15674 <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>
15675 <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>
15676 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
15677 <p><b>Discussion:</b></p>
15680 Note in particular that Table 90 "Container Requirements" gives
15681 semantics of <tt>a.swap(b)</tt> as <tt>swap(a,b)</tt>, yet for all
15682 containers we define <tt>swap(a,b)</tt> to call <tt>a.swap(b)</tt> - a
15683 circular definition.
15692 Robert to propose a resolution along the lines of "Postcondition: "a =
15693 b, b = a" This will be a little tricky for the hash containers, since
15694 they don't have <tt>operator==</tt>.
15698 Post Summit Anthony Williams provided proposed wording.
15704 <p><b>Proposed resolution:</b></p>
15706 In table 80 in section 23.2.1 [container.requirements.general],
15707 replace the postcondition of <tt>a.swap(b)</tt> with the following:
15712 <caption>Table 80 -- Container requirements</caption>
15714 <th>Expression</th>
15715 <th>Return type</th>
15716 <th>Operational semantics</th>
15717 <th>Assertion/note pre-/post-conidtion</th>
15718 <th>Complexity</th>
15728 <td><tt>a.swap(b);</tt></td>
15729 <td><tt>void</tt></td>
15731 <td><del><tt>swap(a,b)</tt></del>
15732 <ins>Exchange the contents of <tt>a</tt> and <tt>b</tt> as-if<br>
15733 <tt>X u=std::move(a);<br>
15734 a=std::move(b);<br>
15735 b=std::move(u);</tt></ins></td>
15742 Remove the reference to swap from the paragraph following the table.
15746 Notes: the algorithms <del><tt>swap()</tt>, </del><tt>equal()</tt> and
15747 <tt>lexicographical_compare()</tt> are defined in Clause 25. ...
15755 <h3><a name="884"></a>884. shared_ptr swap</h3>
15756 <p><b>Section:</b> 20.8.13.2.4 [util.smartptr.shared.mod] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Tentatively NAD Editorial</a>
15757 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2008-09-15 <b>Last modified:</b> 2009-05-23</p>
15758 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD%20Editorial">Tentatively NAD Editorial</a> status.</p>
15759 <p><b>Discussion:</b></p>
15760 <blockquote><pre>#include <memory>
15761 #include <cassert>
15768 std::shared_ptr<A> pa(new A);
15769 std::shared_ptr<B> pb(new B);
15770 std::swap<A>(pa, pb); // N.B. no argument deduction
15771 assert( pa.get() == pb.get() );
15774 </pre></blockquote>
15777 Is this behaviour correct (I believe it is) and if so, is it
15778 unavoidable, or not worth worrying about?
15782 This calls the lvalue/rvalue swap overload for <tt>shared_ptr</tt>:
15785 <blockquote><pre>template<class T> void swap( shared_ptr<T> & a, shared_ptr<T> && b );
15786 </pre></blockquote>
15789 silently converting the second argument from <tt>shared_ptr<B></tt> to
15790 <tt>shared_ptr<A></tt> and binding the rvalue ref to the produced temporary.
15794 This is not, in my opinion, a <tt>shared_ptr</tt> problem; it is a general issue
15795 with the rvalue swap overloads. Do we want to prevent this code from
15796 compiling? If so, how?
15800 Perhaps we should limit rvalue args to swap to those types that would
15801 benefit from the "swap trick". Or, since we now have <tt>shrink_to_fit()</tt>, just
15802 eliminate the rvalue swap overloads altogether. The original motivation
15806 <blockquote><pre>vector<A> v = ...;
15808 swap(v, vector<A>(v));
15809 </pre></blockquote>
15811 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1690.html#Improved%20swap%20Interface">N1690</a>.
15818 We agree with the proposed resolution.
15819 Move to NAD Editorial.
15823 <p><b>Proposed resolution:</b></p>
15825 Recommend NAD Editorial, fixed by
15826 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2844.html">N2844</a>.
15834 <h3><a name="885"></a>885. pair assignment</h3>
15835 <p><b>Section:</b> 20.3.3 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
15836 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-09-15 <b>Last modified:</b> 2009-05-25</p>
15837 <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>
15838 <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>
15839 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
15840 <p><b>Discussion:</b></p>
15841 <blockquote><pre>20.2.3 pairs
15842 Missing assignemnt operator:
15843 template<class U , class V>
15844 requires CopyAssignable<T1, U> && CopyAssignable<T2, V>
15845 pair& operator=(pair<U , V> const & p );
15846 </pre></blockquote>
15849 Well, that's interesting. This assignment operator isn't in the
15850 current working paper, either. Perhaps we deemed it acceptable to
15851 build a temporary of type <tt>pair</tt> from <tt>pair<U, V></tt>, then move-assign
15852 from that temporary?
15855 It sounds more like an issue waiting to be opened, unless you want to plug
15856 it now. As written we risk moving from lvalues.
15866 Would be NAD if better ctors fixed it.
15869 Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#811">811</a>.
15874 post San Francisco:
15879 Possibly NAD Editorial, solved by
15880 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2770.pdf">N2770</a>.
15884 2009-05-25 Alisdair adds:
15889 Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#885">885</a> was something I reported while reviewing the library concepts
15890 documents ahead of San Francisco. The missing operator was added as part of
15891 the paper adopted at that meeting
15892 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2770.pdf">N2770</a>)
15893 and I can confirm this operator is
15894 present in the current working paper. I recommend NAD.
15899 <p><b>Proposed resolution:</b></p>
15908 <h3><a name="886"></a>886. tuple construction</h3>
15909 <p><b>Section:</b> 20.5.2.1 [tuple.cnstr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
15910 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-09-15 <b>Last modified:</b> 2009-05-05</p>
15911 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#tuple.cnstr">active issues</a> in [tuple.cnstr].</p>
15912 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple.cnstr">issues</a> in [tuple.cnstr].</p>
15913 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
15914 <p><b>Discussion:</b></p>
15916 20.5.2.1 [tuple.cnstr]:
15919 <i>Effects:</i> Default initializes each element.
15923 Could be clarified to state each "non-trivial" element. Otherwise
15924 we have a conflict with Core deinfition of default initialization -
15925 trivial types do not get initialized (rather than initialization
15930 I'm going to punt on this one, because it's not an issue that's
15931 related to concepts. I suggest bringing it to Howard's attention on
15942 Text in draft doesn't mean anything, changing to "non-trivial" makes it
15946 We prefer "value initializes". Present implementations use
15947 value-initialization. Users who don't want value initialization have
15951 Request resolution text from Alisdair.
15955 This issue relates to Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#868">868</a> default construction and value-initialization.
15960 2009-05-04 Alisdair provided wording and adds:
15966 Note: This <em>IS</em> a change of semantic from TR1, although one the room agreed
15967 with during the discussion. To preserve TR1 semantics, this would have been
15970 <blockquote><pre>requires DefaultConstructible<Types>... tuple();
15973 -2- <i>Effects:</i> Default-initializes each non-trivial element.
15981 <p><b>Proposed resolution:</b></p>
15983 Change p2 in Construction 20.5.2.1 [tuple.cnstr]:
15986 <blockquote><pre>requires DefaultConstructible<Types>... tuple();
15990 -2- <i>Effects:</i> <del>Default</del> <ins>Value-</ins>initializes each element.
16001 <h3><a name="887"></a>887. issue with condition::wait_...</h3>
16002 <p><b>Section:</b> 30.5.1 [thread.condition.condvar] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
16003 <b>Submitter:</b> Lawrence Crowl <b>Opened:</b> 2008-09-15 <b>Last modified:</b> 2009-03-09</p>
16004 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.condition.condvar">active issues</a> in [thread.condition.condvar].</p>
16005 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.condition.condvar">issues</a> in [thread.condition.condvar].</p>
16006 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
16007 <p><b>Discussion:</b></p>
16009 The Posix/C++ working group has identified an inconsistency between
16010 Posix and the C++ working draft in that Posix requires the clock to be
16011 identified at creation, whereas C++ permits identifying the clock at the
16012 call to wait. The latter cannot be implemented with the former.
16022 Howard recommends NAD with the following explanation:
16026 The intent of the current wording is for the <tt>condtion_variable::wait_until</tt>
16027 be able to handle user-defined clocks as well as clocks the system knows about.
16028 This can be done by providing overloads for the known clocks, and another
16029 overload for unknown clocks which synchs to a known clock before waiting.
16033 <blockquote><pre>template <class Duration>
16035 condition_variable::wait_until(unique_lock<mutex>& lock,
16036 const chrono::time_point<chrono::system_clock, Duration>& abs_time)
16038 using namespace chrono;
16039 nanoseconds d = __round_up<nanoseconds>(abs_time.time_since_epoch());
16040 __do_timed_wait(lock.mutex()->native_handle(), time_point<system_clock, nanoseconds>(d));
16041 return system_clock::now() < abs_time;
16044 template <class Clock, class Duration>
16046 condition_variable::wait_until(unique_lock<mutex>& lock,
16047 const chrono::time_point<Clock, Duration>& abs_time)
16049 using namespace chrono;
16050 typename Clock::time_point c_entry = Clock::now();
16051 system_clock::time_point s_entry = system_clock::now();
16052 nanoseconds dn = __round_up<nanoseconds>(abs_time.time_since_epoch() -
16053 c_entry.time_since_epoch());
16054 __do_timed_wait(lock.mutex()->native_handle(), s_entry + dn);
16055 return Clock::now() < abs_time;
16057 </pre></blockquote>
16060 In the above example, <tt>system_clock</tt> is the only clock which the underlying
16061 condition variable knows how to deal with. One overload just passes that clock
16062 through. The second overload (approximately) converts the unknown clock into
16063 a <tt>system_clock time_point</tt> prior to passing it down to the native
16064 condition variable.
16068 On Posix systems vendors are free to add implementation defined constructors which
16069 take a clock. That clock can be stored in the condition_variable, and converted
16070 to (or not as necessary) as shown above.
16074 If an implementation defined constructor takes a clock (for example), then part
16075 of the semantics for that implementation defined ctor might include that a
16076 <tt>wait_until</tt> using a clock other than the one constructed with results
16077 in an error (exceptional condition) instead of a conversion to the stored clock.
16078 Such a design is up to the vendor as once an implementation defined ctor is used,
16079 the vendor is free to specifiy the behavior of waits and/or notifies however
16080 he pleases (when the cv is constructed in an implementation defined manner).
16091 "POSIX people will review the proposed NAD resolution at their upcoming NY
16096 See the minutes at: <a href="http://wiki.dinkumware.com/twiki/bin/view/Posix/POSIX-CppBindingWorkingGroupNewYork2009">http://wiki.dinkumware.com/twiki/bin/view/Posix/POSIX-CppBindingWorkingGroupNewYork2009</a>.
16101 <p><b>Proposed resolution:</b></p>
16110 <h3><a name="888"></a>888. this_thread::yield too strong</h3>
16111 <p><b>Section:</b> 30.3.2 [thread.thread.this] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
16112 <b>Submitter:</b> Lawrence Crowl <b>Opened:</b> 2008-09-15 <b>Last modified:</b> 2009-03-09</p>
16113 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
16114 <p><b>Discussion:</b></p>
16116 I never thought I'd say this, but <tt>this_thread::yield</tt> seems to be too
16117 strong in specification. The issue is that some systems distinguish
16118 between yielding to another thread in the same process and yielding
16119 to another process. Given that the C++ standard only talks about
16120 a single program, one can infer that the specification allows yielding
16121 only to another thread within the same program. Posix has no
16122 facility for that behavior. Can you please file an issue to weaken
16123 the wording. Perhaps "Offers the operating system the opportunity
16133 Recommend move to Tentatively Ready.
16138 <p><b>Proposed resolution:</b></p>
16140 Change 30.3.2 [thread.thread.this]/3:
16144 <pre>void this_thread::yield();
16147 <i>Effects:</i> Offers the <del>operating system</del> <ins>implementation</ins>
16148 the opportunity to <ins>re</ins>schedule.
16149 <del>another thread.</del>
16158 <h3><a name="889"></a>889. thread::id comparisons</h3>
16159 <p><b>Section:</b> 30.3.1.1 [thread.thread.id] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
16160 <b>Submitter:</b> Lawrence Crowl <b>Opened:</b> 2008-09-15 <b>Last modified:</b> 2009-05-24</p>
16161 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.thread.id">issues</a> in [thread.thread.id].</p>
16162 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
16163 <p><b>Discussion:</b></p>
16165 <p><b>Addresses UK 324</b></p>
16168 The <tt>thread::id</tt> type supports the full set of comparison operators. This
16169 is substantially more than is required for the associative containers that
16170 justified them. Please place an issue against the threads library.
16180 Would depend on proposed extension to POSIX, or non-standard extension.
16181 What about hash? POSIX discussing op. POSIX not known to be considering
16182 support needed for hash, op.
16185 Group expresses support for putting ids in both unordered and ordered containers.
16190 post San Francisco:
16196 Howard: It turns out the current working paper
16197 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>
16198 <i>already has</i> <tt>hash<thread::id></tt>
16199 (20.7 [function.objects], 20.7.17 [unord.hash]). We simply
16200 overlooked it in the meeting. It is a good thing we voted in favor of it
16215 Recommend to close as NAD. For POSIX, see if we need to add a function to
16216 convert <tt>pthread_t</tt> to integer.
16220 Post Summit, Alisdair adds:
16226 The recommendation for LWG-889/UK-324 is NAD, already specified.
16229 It is not clear to me that the specification is complete.
16232 In particular, the synopsis of <tt><functional></tt> in 20.7 [function.objects] does not mention <tt>hash< thread::id
16233 ></tt> nor <tt>hash< error_code ></tt>, although their
16234 existence is implied by 20.7.17 [unord.hash], p1.
16237 I am fairly uncomfortable putting the declaration for the
16238 <tt>thread_id</tt> specialization into <tt><functional></tt> as
16239 <tt>id</tt> is a nested class inside <tt>std::thread</tt>, so it implies
16240 that <tt><functional></tt> would require the definition of the
16241 <tt>thread</tt> class template in order to forward declared
16242 <tt>thread::id</tt> and form this specialization.
16245 It seems better to me that the dependency goes the other way around
16246 (<tt><thread></tt> will more typically make use of
16247 <tt><functional></tt> than vice-versa) and the
16248 <tt>hash<thread::id></tt> specialization be declared in the
16249 <tt><thread></tt> header.
16252 I think <tt>hash<error_code></tt> could go into either
16253 <tt><system_error></tt> or <tt><functional></tt> and have no
16254 immediate preference either way. However, it should clearly appear in
16255 the synopsis of one of these two.
16258 Recommend moving 889 back to open, and tying in a reference to UK-324.
16267 Howard observes that <tt>thread::id</tt> need not be a nested class;
16268 it could be a <tt>typedef</tt> for a more visible type.
16272 2009-05-24 Alisdair adds:
16276 I do not believe this is correct. <tt>thread::id</tt> is explicitly documents as a
16277 nested class, rather than as an unspecified typedef analogous to an
16278 iterator. If the intent is that this is not implemented as a nested class
16279 (under the as-if freedoms) then this is a novel form of standardese.
16283 <p><b>Proposed resolution:</b></p>
16293 <h3><a name="890"></a>890. Improving <tt><system_error></tt> initialization</h3>
16294 <p><b>Section:</b> 19.5.1 [syserr.errcat] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
16295 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2008-09-14 <b>Last modified:</b> 2009-03-09</p>
16296 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
16297 <p><b>Discussion:</b></p>
16299 The <tt>static const error_category</tt> objects <tt>generic_category</tt> and
16300 <tt>system_category</tt> in header <tt><system_error></tt> are currently declared:
16303 <blockquote><pre>const error_category& get_generic_category();
16304 const error_category& get_system_category();
16306 static const error_category& generic_category = get_generic_category();
16307 static const error_category& system_category = get_system_category();
16308 </pre></blockquote>
16311 This formulation has several problems:
16316 Implementation details are exposed, since initialization is specified in
16317 the interface. This over-constrains implementations without offsetting
16318 user benefits. The form of initialization specified may be less than
16319 maximally efficient on some platforms.
16322 Use of the objects is more expensive in terms of number of machine level
16323 instructions. See <i>Implementation experience</i> below.
16326 Depending on the compiler, some cost may be incurred by each translation unit
16327 that includes the header, even if the objects are not used. This is a
16328 common scenario in user code, since the header is included by other
16329 standard library headers. It should be mentioned that at least one
16330 compilers is able to optimize this cost away, however.
16335 IO streams uses a somewhat different formulation for iostream_category, but
16336 still suffer much the same problems.
16340 The original plan was to eliminate these problems by applying the C++0x
16341 <tt>constexpr</tt> feature. See LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#832">832</a>. However, that approach turned out
16342 to be unimplementable, since it would require a <tt>constexpr</tt> object of a
16343 class with virtual functions, and that is not allowed by the core
16348 The proposed resolution was developed as an alternative. It mitigates the above
16349 problems by removing initialization from the visible interface, allowing
16350 implementations flexibility.
16354 <b>Implementation experience:</b>
16358 Prototype implementations of the current WP interface and proposed
16359 resolution interface were tested with recent Codegear, GCC, Intel, and Microsoft
16360 compilers on Windows. The code generated by the Microsoft compiler was studied
16361 at length; the WP and proposal versions generated very similar code. For both versions
16362 the compiler did make use of static
16363 initialization; apparently the compiler applied an implicit <tt>constexpr</tt>
16364 where useful, even in cases where <tt>constexpr</tt> would not be permitted by
16369 <b>Acknowledgements:</b>
16373 Martin Sebor, Chris Kohlhoff, and John Lakos provided useful ideas and comments on initialization issues.
16383 Martin: prefers not to create more file-scope static objects, and would
16384 like to see <tt>get_*</tt> functions instead.
16389 <p><i>[Pre-Summit:]</i></p>
16395 Beman: The proposed resolution has been reworked to remove the file-scope
16396 static objects, per Martin's suggestions. The <tt>get_</tt> prefix has been
16397 eliminated from the function names as no longer necessary and to conform with
16398 standard library naming practice.
16409 Agreement that this is wise and essential, text provided works and has
16410 been implemented. Seems to be widespread consensus. Move to Tentative Ready.
16415 <p><b>Proposed resolution:</b></p>
16417 <p>Change 17.6.4.12 [value.error.codes] Value of error codes as indicated:</p>
16419 <p>Certain functions in the C++ standard library report errors via a
16420 <tt>std::error_code</tt> (19.4.2.2) object. That object's <tt>category()</tt> member shall
16421 return <del>a reference to</del> <code>std::system_category</code><tt><ins><code>()</code></ins></tt> for errors originating from the
16422 operating system, or a reference to an implementation-defined error_category
16423 object for errors originating elsewhere. The implementation shall define the
16424 possible values of value() for each of these error categories. [<i>Example:</i> For
16425 operating systems that are based on POSIX, implementations are encouraged to
16426 define the <code>std::system_category</code><tt><ins><code>()</code></ins></tt> values as identical to the POSIX <tt>errno</tt> values,
16427 with additional values as defined by the operating system's documentation.
16428 Implementations for operating systems that are not based on POSIX are
16429 encouraged to define values identical to the operating system's values. For
16430 errors that do not originate from the operating system, the implementation may
16431 provide enums for the associated values --<i>end example</i>]</p>
16435 Change 19.5.1.1 [syserr.errcat.overview] Class <tt>error_category</tt> overview
16436 <tt>error_category</tt> synopsis as indicated:
16440 <pre>const error_category& <del>get_</del>generic_category();
16441 const error_category& <del>get_</del>system_category();
16443 <del>static storage-class-specifier const error_category& generic_category = get_generic_category();
16444 static storage-class-specifier const error_category& system_category = get_system_category();</del>
16449 Change 19.5.1.5 [syserr.errcat.objects] Error category objects as indicated:
16453 <pre>const error_category& <del>get_</del>generic_category();
16459 <i>Returns:</i> A reference to an object of a type derived from class <tt>error_category</tt>.
16463 <i>Remarks:</i> The object's <tt>default_error_condition</tt> and <tt>equivalent</tt> virtual
16464 functions shall behave as specified for the class <tt>error_category</tt>. The
16465 object's <tt>name</tt> virtual function shall return a pointer to the string
16466 <tt>"GENERIC"</tt>.
16470 <pre>const error_category& <del>get_</del>system_category();
16475 <i>Returns:</i> A reference to an object of a type derived from class <tt>error_category</tt>.
16479 <i>Remarks:</i> The object's <tt>equivalent</tt> virtual functions shall behave as
16480 specified for class <tt>error_category</tt>. The object's <tt>name</tt> virtual function
16481 shall return a pointer to the string <tt>"system"</tt>. The object's
16482 <tt>default_error_condition</tt> virtual function shall behave as follows:
16485 If the argument <tt>ev</tt> corresponds to a POSIX <tt>errno</tt> value <tt>posv</tt>, the function
16486 shall return <tt>error_condition(posv, generic_category<ins>()</ins>)</tt>. Otherwise, the
16487 function shall return <tt>error_condition(ev, system_category<ins>()</ins>)</tt>. What
16488 constitutes correspondence for any given operating system is
16489 unspecified. [<i>Note:</i> The number of potential system error codes is large
16490 and unbounded, and some may not correspond to any POSIX <tt>errno</tt> value.
16491 Thus implementations are given latitude in determining correspondence.
16492 <i>-- end note</i>]
16498 <p>Change 19.5.2.3 [syserr.errcode.constructors] Class error_code constructors
16501 <pre>error_code();</pre>
16503 <p><i>Effects:</i> Constructs an object of type error_code.</p>
16504 <p><i>Postconditions:</i> <code>val_ == 0 </code>and <code>cat_ == &system_category</code><tt><ins>()</ins></tt>.</p>
16507 <p>Change 19.5.2.4 [syserr.errcode.modifiers] Class error_code modifiers as
16510 <pre>void clear();</pre>
16512 <p>Postconditions: <code>value() == 0</code> and <code>category() ==
16513 system_category</code><tt><ins>()</ins></tt>.</p>
16516 <p>Change 19.5.2.6 [syserr.errcode.nonmembers] Class error_code non-member
16517 functions as indicated:</p>
16519 <pre>error_code make_error_code(errc e);</pre>
16521 <p><i>Returns:</i> <code>error_code(static_cast<int>(e), generic_category</code><tt><ins>()</ins></tt><code>)</code>.</p>
16524 <p>Change 19.5.3.3 [syserr.errcondition.constructors] Class error_condition
16525 constructors as indicated:</p>
16527 <pre>error_condition();</pre>
16529 <p><i>Effects:</i> Constructs an object of type <code>error_condition</code>.</p>
16530 <p><i>Postconditions:</i> <code>val_ == 0</code> and <code>cat_ == &generic_category</code><tt><ins>()</ins></tt>.</p>
16533 <p>Change 19.5.3.4 [syserr.errcondition.modifiers] Class error_condition
16534 modifiers as indicated:</p>
16536 <pre>void clear();</pre>
16538 <p><i>Postconditions:</i> <code>value() == 0</code> and <code>category() ==
16539 generic_category</code><tt><ins>()</ins></tt>.</p>
16542 <p>Change 19.5.3.6 [syserr.errcondition.nonmembers] Class error_condition
16543 non-member functions as indicated:</p>
16545 <pre>error_condition make_error_condition(errc e);</pre>
16547 <p><i>Returns:</i> <tt>error_condition(static_cast<int>(e), generic_category<ins>()</ins>)</tt>.</p>
16550 <p>Change 27.5 [iostreams.base] Iostreams base classes, Header <ios>
16551 synopsis as indicated:</p>
16553 <pre>concept_map ErrorCodeEnum<io_errc> { };
16554 error_code make_error_code(io_errc e);
16555 error_condition make_error_condition(io_errc e);
16556 <del>storage-class-specifier</del> const error_category& iostream_category<ins>()</ins>;</pre>
16558 <p>Change 27.5.2.1.1 [ios::failure] Class ios_base::failure, paragraph 2 as
16561 <p>When throwing ios_base::failure exceptions, implementations should provide
16562 values of ec that identify the specific reason for the failure. [ Note: Errors
16563 arising from the operating system would typically be reported as <tt>
16564 system_category</tt><tt><ins>()</ins></tt> errors with an error value of the
16565 error number reported by the operating system. Errors arising from within the
16566 stream library would typically be reported as <tt>error_code(io_errc::stream,
16567 iostream_category<ins>()</ins>)</tt>. --end note ]</p>
16569 <p>Change 27.5.5.5 [error.reporting] Error reporting as indicated:</p>
16571 <pre>error_code make_error_code(io_errc e);</pre>
16573 <p><i>Returns:</i> <code>error_code(static_cast<int>(e), iostream_category</code><ins>()</ins><code>)</code>.</p>
16575 <pre>error_condition make_error_condition(io_errc e);</pre>
16577 <p><i>Returns:</i> <code>error_condition(static_cast<int>(e),
16578 iostream_category</code><ins>()</ins><code>)</code>.</p>
16580 <pre><del>storage-class-specifier</del> const error_category& iostream_category<ins>()</ins>;</pre>
16582 <del><p>The implementation shall initialize iostream_category. Its storage-class-specifier
16583 may be static or extern. It is unspecified whether initialization is static
16584 or dynamic (3.6.2). If initialization is dynamic, it shall occur before
16585 completion of the dynamic initialization of the first translation unit
16586 dynamically initialized that includes header <system_error>.</p></del>
16588 <ins><i>Returns:</i> A reference to an object of a type derived from class <tt>error_category</tt>.</ins>
16590 <p><i>Remarks:</i> The object's default_error_condition and equivalent virtual functions shall
16591 behave as specified for the class error_category. The object's name virtual
16592 function shall return a pointer to the string "iostream".</p>
16603 <h3><a name="891"></a>891. std::thread, std::call_once issue</h3>
16604 <p><b>Section:</b> 30.3.1.2 [thread.thread.constr], 30.4.5.2 [thread.once.callonce] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
16605 <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2008-09-15 <b>Last modified:</b> 2009-03-22</p>
16606 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.thread.constr">active issues</a> in [thread.thread.constr].</p>
16607 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.thread.constr">issues</a> in [thread.thread.constr].</p>
16608 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
16609 <p><b>Discussion:</b></p>
16611 I notice that the vararg overloads of <tt>std::thread</tt> and <tt>std::call_once</tt>
16612 (N2723 30.3.1.2 [thread.thread.constr] and 30.4.5.2 [thread.once.callonce]) are no longer specified in terms of
16613 <tt>std::bind</tt>; instead, some of the <tt>std::bind</tt> wording has been inlined into
16617 There are two problems with this.
16620 First, the specification (and implementation) in terms of <tt>std::bind</tt> allows, for example:
16623 <blockquote><pre>std::thread th( f, 1, std::bind( g ) );
16624 </pre></blockquote>
16627 which executes <tt>f( 1, g() )</tt> in a thread. This can be useful. The
16628 "inlined" formulation changes it to execute <tt>f( 1, bind(g) )</tt> in a thread.
16631 Second, assuming that we don't want the above, the specification has copied the wording
16635 <tt>INVOKE(func, w1, w2, ..., wN)</tt> (20.6.2) shall be a valid
16636 expression for some values <tt>w1, w2, ..., wN</tt>
16640 but this is not needed since we know that our argument list is args; it should simply be
16644 <tt>INVOKE(func, args...)</tt> (20.6.2) shall be a valid expression
16657 Post Summit Anthony provided proposed wording.
16662 <p><b>Proposed resolution:</b></p>
16664 Change paragraph 4 of 30.3.1.2 [thread.thread.constr] to:
16668 <pre>template <class F> explicit thread(F f);
16669 template <class F, class ...Args> thread(F&& f, Args&&... args);
16672 -4- <i>Requires:</i> <tt>F</tt> and each <tt>Ti</tt> in <tt>Args</tt>
16673 shall be <tt>CopyConstructible</tt> if an lvalue and otherwise
16674 <tt>MoveConstructible</tt>. <tt><i>INVOKE</i>(f, <del>w1, w2, ..., wN</del> <ins>args...</ins>)</tt>
16675 (20.6.2) shall be a valid expression<del> for some values <i>w1, w2, ...,
16676 wN</i>, where <tt>N == sizeof...(Args)</tt></del>.
16681 Change paragraph 1 of 30.4.5.2 [thread.once.callonce] to:
16684 <blockquote><pre>template<class Callable, class ...Args>
16685 void call_once(once_flag& flag, Callable func, Args&&... args);
16688 -1- <i>Requires:</i> The template parameters <tt>Callable></tt> and each
16689 <tt>Ti</tt> in <tt>Args</tt> shall be <tt>CopyConstructible</tt> if an
16690 lvalue and otherwise <tt>MoveConstructible</tt>. <tt><i>INVOKE</i>(func,
16691 <del>w1, w2, ..., wN</del> <ins>args...</ins>)</tt> (20.6.2) shall be a
16692 valid expression<del> for some values <i>w1, w2, ..., wN</i>, where
16693 <tt>N == sizeof...(Args)</tt></del>.
16702 <h3><a name="893"></a>893. std::mutex issue</h3>
16703 <p><b>Section:</b> 30.4.1.1 [thread.mutex.class] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
16704 <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2008-09-15 <b>Last modified:</b> 2009-03-22</p>
16705 <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>
16706 <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>
16707 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
16708 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#905">905</a></p>
16709 <p><b>Discussion:</b></p>
16711 30.4.1.1 [thread.mutex.class]/27 (in
16712 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>)
16713 says that the behavior is undefined if:
16716 <li>a thread that owns a <tt>mutex</tt> object calls <tt>lock()</tt> or
16717 <tt>try_lock()</tt> on that object</li>
16720 I don't believe that this is right. Calling <tt>lock()</tt> or <tt>try_lock()</tt> on a
16721 locked <tt>mutex</tt> is well defined in the general case. <tt>try_lock()</tt> is required
16722 to fail and return <tt>false</tt>. <tt>lock()</tt> is required to either throw an
16723 exception (and is allowed to do so if it detects deadlock) or to block
16724 until the <tt>mutex</tt> is free. These general requirements apply regardless of
16725 the current owner of the <tt>mutex</tt>; they should apply even if it's owned by
16726 the current thread.
16729 Making double <tt>lock()</tt> undefined behavior probably can be justified (even
16730 though I'd still disagree with the justification), but <tt>try_lock()</tt> on a
16731 locked <tt>mutex</tt> must fail.
16740 Move to open. Proposed resolution:
16744 In 30.4.1 [thread.mutex.requirements] paragraph 12, change the error
16745 condition for <tt>resource_deadlock_would_occur</tt> to: "if the implementation
16746 detects that a deadlock would occur"
16749 Strike 30.4.1.1 [thread.mutex.class] paragraph 3 bullet 2 "a thread that owns a mutex object
16750 calls <tt>lock()</tt> or <tt>try_lock()</tt> on that object, or"
16756 <p><b>Proposed resolution:</b></p>
16758 In 30.4.1 [thread.mutex.requirements] paragraph 12 change:
16765 <tt>resource_deadlock_would_occur</tt> -- if the <del>current thread already owns the mutex and is able
16766 to detect it</del> <ins>implementation detects that a deadlock would occur</ins>.
16773 Strike 30.4.1.1 [thread.mutex.class] paragraph 3 bullet 2:
16777 -3- The behavior of a program is undefined if:
16782 <del>a thread that owns a <tt>mutex</tt> object calls <tt>lock()</tt> or <tt>try_lock()</tt> on that object, or</del>
16795 <h3><a name="895"></a>895. "Requires:" on std::string::at et al</h3>
16796 <p><b>Section:</b> 17.5.1.4 [structure.specifications] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
16797 <b>Submitter:</b> James Dennett <b>Opened:</b> 2008-09-16 <b>Last modified:</b> 2009-03-11</p>
16798 <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>
16799 <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>
16800 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
16801 <p><b>Discussion:</b></p>
16803 Per discussion, we need an issue open to cover looking at "Requires"
16804 clauses which are not constraints on user code, such as that on
16805 <tt>std::basic_string::at</tt>.
16809 <p><b>Proposed resolution:</b></p>
16818 <h3><a name="896"></a>896. Library thread safety issue</h3>
16819 <p><b>Section:</b> 20.8.13.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
16820 <b>Submitter:</b> Hans Boehm <b>Opened:</b> 2008-09-16 <b>Last modified:</b> 2008-09-25</p>
16821 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#util.smartptr.shared">active issues</a> in [util.smartptr.shared].</p>
16822 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared">issues</a> in [util.smartptr.shared].</p>
16823 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
16824 <p><b>Discussion:</b></p>
16826 It is unclear whether <tt>shared_ptr</tt> is thread-safe in the sense that
16827 multiple threads may simultaneously copy a <tt>shared_ptr</tt>. However this
16828 is a critical piece of information for the client, and it has significant
16829 impact on usability for many applications. (Detlef Vollman thinks it
16830 is currently clear that it is not thread-safe. Hans Boehm thinks
16831 it currently requires thread safety, since the <tt>use_count</tt> is not an
16832 explicit field, and constructors and assignment take a const reference
16833 to an existing <tt>shared_ptr</tt>.)
16840 Many multi-threaded usages are impossible. A thread-safe version can
16841 be used to destroy an object when the last thread drops it, something
16842 that is often required, and for which we have no other easy mechanism.
16845 Against thread-safety:
16848 The thread-safe version is well-known to be far more expensive, even
16849 if used by a single thread. Many applications, including all single-threaded
16860 Beman: this is a complicated issue, and would like to move this to Open
16861 and await comment from Peter Dimov; we need very careful and complete
16862 rationale for any decision we make; let's go slow
16865 Detlef: I think that <tt>shared_ptr</tt> should not be thread-safe.
16868 Hans: When you create a thread with a lambda, it in some cases makes it
16869 very difficult for the lambda to reference anything in the heap. It's
16870 currently ambiguous as to whether you can use a <tt>shared_ptr</tt> to get at an
16874 Leave in Open. Detlef will submit an alternative proposed resolution
16875 that makes <tt>shared_ptr</tt> explicitly unsafe.
16878 A third option is to support both threadsafe and non-safe share_ptrs,
16879 and to let the programmer decide which behavior they want.
16883 Beman: Peter, do you support the PR?
16891 Yes, I support the proposed resolution, and I certainly oppose any
16892 attempts to <tt>make shared_ptr</tt> thread-unsafe.
16895 I'd mildly prefer if
16898 [<i>Note:</i> This is true in spite of that fact that such functions often
16899 modify <tt>use_count()</tt> <i>--end note</i>]
16905 [<i>Note:</i> This is true in spite of that fact that such functions often
16906 cause a change in <tt>use_count()</tt> <i>--end note</i>]
16909 (or something along these lines) to emphasise that <tt>use_count()</tt> is not,
16910 conceptually, a variable, but a return value.
16918 <p><b>Proposed resolution:</b></p>
16920 Make it explicitly thread-safe, in this weak sense, as I believe was intended:
16923 Insert in 20.8.13.2 [util.smartptr.shared], before p5:
16927 For purposes of determining the presence of a data race,
16928 member functions do not modify <tt>const shared_ptr</tt> and
16929 const <tt>weak_ptr</tt> arguments, nor any objects they
16930 refer to. [<i>Note:</i> This is true in spite of that fact that such functions often
16931 cause a change in <tt>use_count()</tt> <i>--end note</i>]
16935 On looking at the text, I'm not sure we need a similar disclaimer
16936 anywhere else, since nothing else has the problem with the modified
16937 <tt>use_count()</tt>. I think Howard arrived at a similar conclusion.
16945 <h3><a name="897"></a>897. Forward_list issues... Part 2</h3>
16946 <p><b>Section:</b> 23.3.3.4 [forwardlist.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
16947 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2008-09-22 <b>Last modified:</b> 2009-05-23</p>
16948 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
16949 <p><b>Discussion:</b></p>
16951 This issue was split off from <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#892">892</a> at the request of the LWG.
16961 This issue is more complicated than it looks.
16964 paragraph 47: replace each <tt>(first, last) with (first, last]</tt>
16967 add a statement after paragraph 48 that complexity is O(1)
16970 remove the complexity statement from the first overload of splice_after
16973 We may have the same problems with other modifiers, like erase_after.
16974 Should it require that all iterators in the range (position, last] be
16980 There are actually 3 issues here:
16986 What value should <tt>erase_after</tt> return? With <tt>list</tt>, code often
16989 <blockquote><pre>for (auto i = l.begin(); i != l.end();)
16991 // inspect *i and decide if you want to erase it
16993 if (I want to erase *i)
16998 </pre></blockquote>
17000 I.e. the iterator returned from <tt>erase</tt> is useful for setting up the
17001 logic for operating on the next element. For <tt>forward_list</tt> this might
17002 look something like:
17004 <blockquote><pre>auto i = fl.before_begin();
17006 for (++ip1; ip1 != fl.end(); ++ip1)
17008 // inspect *(i+1) and decide if you want to erase it
17010 if (I want to erase *(i+1))
17011 i = fl.erase_after(i);
17016 </pre></blockquote>
17018 In the above example code, it is convenient if <tt>erase_after</tt> returns
17019 the element <i>prior</i> to the erased element (range) instead of the element
17020 <i>after</i> the erase element (range).
17026 <li>SGI slist returns an iterator referencing the element <i>after</i> the erased range.</li>
17027 <li>CodeWarrior slist returns an iterator referencing the element <i>before</i> the erased range.</li>
17030 There is not a strong technical argument for either solution over the other.
17036 With all other containers, operations always work on the range
17037 <tt>[first, last)</tt> and/or <i>prior to</i> the given <tt>position</tt>.
17040 With <tt>forward_list</tt>, operations sometimes work on the range
17041 <tt>(first, last]</tt> and/or <i>after</i> the given <tt>position</tt>.
17044 This is simply due to the fact that in order to operate on
17045 <tt>*first</tt> (with <tt>forward_list</tt>) one needs access to
17046 <tt>*(first-1)</tt>. And that's not practical with
17047 <tt>forward_list</tt>. So the operating range needs to start with <tt>(first</tt>,
17048 not <tt>[first</tt> (as the current working paper says).
17051 Additionally, if one is interested in splicing the range <tt>(first, last)</tt>,
17052 then (with <tt>forward_list</tt>), one needs practical (constant time) access to
17053 <tt>*(last-1)</tt> so that one can set the <i>next</i> field in this node to
17054 the proper value. As this is not possible with <tt>forward_list</tt>, one must
17055 specify the last element of interest instead of one past the last element of
17056 interest. The syntax for doing this is to pass <tt>(first, last]</tt> instead
17057 of <tt>(first, last)</tt>.
17060 With <tt>erase_after</tt> we have a choice of either erasing the range
17061 <tt>(first, last]</tt> <em>or</em> <tt>(first, last)</tt>. Choosing the latter
17064 <blockquote><pre>x.erase_after(pos, x.end());
17065 </pre></blockquote>
17068 With the former, the above statement is inconvenient or expensive due to the lack
17069 of constant time access to <tt>x.end()-1</tt>. However we could introduce:
17072 <blockquote><pre>iterator erase_to_end(const_iterator position);
17073 </pre></blockquote>
17080 The advantage of the former (<tt>(first, last]</tt>) for <tt>erase_after</tt>
17081 is a consistency with <tt>splice_after</tt> which uses <tt>(first, last]</tt>
17082 as the specified range. But this either requires the addition of <tt>erase_to_end</tt>
17083 or giving up such functionality.
17089 As stated in the discussion of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#892">892</a>, and reienforced by point 2 above,
17090 a <tt>splice_after</tt> should work on the source range <tt>(first, last]</tt>
17091 if the operation is to be <i>Ο</i>(1). When splicing an entire list <tt>x</tt> the
17092 algorithm needs <tt>(x.before_begin(), x.end()-1]</tt>. Unfortunately <tt>x.end()-1</tt>
17093 is not available in constant time unless we specify that it must be. In order to
17094 make <tt>x.end()-1</tt> available in constant time, the implementation would have
17095 to dedicate a pointer to it. I believe the design of
17096 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2543.htm">N2543</a>
17097 intended a nominal overhead of <tt>foward_list</tt> of 1 pointer. Thus splicing
17098 one <i>entire</i> <tt>forward_list</tt> into another can not be <i>Ο</i>(1).
17108 We agree with the proposed resolution.
17116 <p><b>Proposed resolution:</b></p>
17118 Wording below assumes issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#878">878</a> is accepted, but this issue is
17119 independent of that issue.
17123 Change 23.3.3.4 [forwardlist.modifiers]:
17127 <pre>iterator erase_after(const_iterator position);
17131 <i>Requires:</i> The iterator following <tt>position</tt> is dereferenceable.
17134 <i>Effects:</i> Erases the element pointed to by the iterator following <tt>position</tt>.
17137 <i>Returns:</i> <del>An iterator pointing to the element following the one that was erased, or <tt>end()</tt> if no such
17138 element exists</del>
17139 <ins>An iterator equal to <tt>position</tt></ins>.
17144 <pre>iterator erase_after(const_iterator position, <ins>const_</ins>iterator last);
17148 <i>Requires:</i> All iterators in the range
17149 <tt><del>[</del><ins>(</ins>position,last)</tt>
17150 are dereferenceable.
17153 <i>Effects:</i> Erases the elements in the range
17154 <tt><del>[</del><ins>(</ins>position,last)</tt>.
17157 <i>Returns:</i> <ins>An iterator equal to <tt>position</tt></ins> <del><tt>last</tt></del>
17163 Change 23.3.3.5 [forwardlist.ops]:
17167 <pre>void splice_after(const_iterator position, forward_list<T,Allocator>&& x);
17171 <i>Requires:</i> <tt>position</tt> is <tt>before_begin()</tt> or a
17172 dereferenceable iterator in the range <tt>[begin(), end))</tt>. <tt>&x != this</tt>.
17175 <i>Effects:</i> Inserts the contents of <tt>x</tt> after <tt>position</tt>, and
17176 <tt>x</tt> becomes empty. Pointers and references to
17177 the moved elements of <tt>x</tt> now refer to those same elements but as members of <tt>*this</tt>.
17178 Iterators referring to the moved elements will continue to refer to their elements,
17179 but they now behave as iterators into <tt>*this</tt>, not into <tt>x</tt>.
17182 <i>Throws:</i> Nothing.
17185 <i>Complexity:</i> <del><i>Ο</i>(1)</del> <ins><i>Ο</i>(<tt>distance(x.begin(), x.end())</tt>)</ins>
17191 <pre>void splice_after(const_iterator position, forward_list<T,Allocator>&& x,
17192 const_iterator first, const_iterator last);
17196 <i>Requires:</i> <tt>position</tt> is <tt>before_begin()</tt> or a
17197 dereferenceable iterator in the range <tt>[begin(), end))</tt>.
17198 <tt>(first,last<ins>]</ins><del>)</del></tt> is a valid range in
17199 <tt>x</tt>, and all iterators in the range
17200 <tt>(first,last<ins>]</ins><del>)</del></tt> are dereferenceable.
17201 <tt>position</tt> is not an iterator in the range <tt>(first,last<ins>]</ins><del>)</del></tt>.
17204 <i>Effects:</i> Inserts elements in the range <tt>(first,last<ins>]</ins><del>)</del></tt>
17205 after <tt>position</tt> and removes the elements from <tt>x</tt>.
17206 Pointers and references to the moved elements of <tt>x</tt> now refer to
17207 those same elements but as members of <tt>*this</tt>. Iterators
17208 referring to the moved elements will continue to refer to their
17209 elements, but they now behave as iterators into <tt>*this</tt>, not into
17213 <ins><i>Complexity:</i> <i>Ο</i>(1).</ins>
17225 <h3><a name="898"></a>898. Small contradiction in n2723 to forward to committee</h3>
17226 <p><b>Section:</b> 23.3.3.5 [forwardlist.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
17227 <b>Submitter:</b> Arch Robison <b>Opened:</b> 2008-09-08 <b>Last modified:</b> 2009-05-23</p>
17228 <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>
17229 <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>
17230 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
17231 <p><b>Discussion:</b></p>
17233 I ran across a small contradiction in working draft n2723.
17237 23.3.3 [forwardlist]p2: A <tt>forward_list</tt> satisfies all of the
17238 requirements of a container (table 90), except that the <tt>size()</tt> member
17239 function is not provided.
17242 23.3.3.5 [forwardlist.ops]p57: <i>Complexity:</i> At most <tt>size() + x.size() - 1</tt>
17247 Presumably 23.3.3.5 [forwardlist.ops]p57 needs to be rephrased to not use
17248 <tt>size()</tt>, or note that it is used there only for sake of notational convenience.
17252 2009-03-29 Beman provided proposed wording.
17262 We agree with the proposed resolution.
17265 Move to Tentatively Ready.
17270 <p><b>Proposed resolution:</b></p>
17271 <p><i>Change 23.3.3.5 [forwardlist.ops],
17272 forward_list operations, paragraph 19, merge complexity as indicated:
17274 <blockquote><i>Complexity:</i> At most <tt><del>size() + x.size()</del>
17275 <ins>distance(begin(), end()) + distance(x.begin(), x.end())</ins> - 1</tt>
17284 <h3><a name="899"></a>899. Adjusting <tt>shared_ptr</tt> for <tt>nullptr_t</tt></h3>
17285 <p><b>Section:</b> 20.8.13.2.2 [util.smartptr.shared.dest] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
17286 <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2008-09-18 <b>Last modified:</b> 2009-05-23</p>
17287 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared.dest">issues</a> in [util.smartptr.shared.dest].</p>
17288 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
17289 <p><b>Discussion:</b></p>
17291 James Dennett, message c++std-lib-22442:
17294 The wording below addresses one case of this, but opening an
17295 issue to address the need to sanity check uses of the term "pointer"
17296 in 20.8.13.2 [util.smartptr.shared] would be a good thing.
17299 There's one more reference, in <tt>~shared_ptr;</tt> we can apply your suggested change to it, too. That is:
17302 Change 20.8.13.2.2 [util.smartptr.shared.dest]/1 second bullet from:
17305 Otherwise, if *this owns a pointer p and a deleter d, d(p) is called.
17311 Otherwise, if *this owns an object p and a deleter d, d(p) is called.
17329 Peter Dimov notes the analogous change has already been made
17330 to "the new nullptr_t taking constructors
17331 in 20.8.13.2.1 [util.smartptr.shared.const] p9-13."
17334 We agree with the proposed resolution.
17335 Move to Tentatively Ready.
17340 <p><b>Proposed resolution:</b></p>
17342 Change 20.8.13.2.2 [util.smartptr.shared.dest]/1 second bullet:
17348 Otherwise, if <tt>*this</tt> <i>owns</i> <del>a pointer</del>
17349 <ins>an object</ins> <tt>p</tt> and a
17350 deleter <tt>d</tt>, <tt>d(p)</tt> is called.
17360 <h3><a name="900"></a>900. stream move-assignment</h3>
17361 <p><b>Section:</b> 27.9.1.8 [ifstream.assign] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
17362 <b>Submitter:</b> Niels Dekker <b>Opened:</b> 2008-09-20 <b>Last modified:</b> 2009-05-23</p>
17363 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
17364 <p><b>Discussion:</b></p>
17367 appears that we have an issue similar to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#675">675</a> regarding the move-assignment of
17368 stream types. For example, when assigning to an <tt>std::ifstream</tt>,
17369 <tt>ifstream1</tt>, it seems preferable to close the file originally held by
17370 <tt>ifstream1</tt>:
17373 <blockquote><pre>ifstream1 = std::move(ifstream2);
17374 </pre></blockquote>
17378 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>)
17379 specifies that the move-assignment of
17380 stream types like <tt>ifstream</tt> has the same effect as a swap:
17385 Assign and swap 27.9.1.8 [ifstream.assign]
17387 <pre>basic_ifstream& operator=(basic_ifstream&& rhs);
17390 <i>Effects:</i> <tt>swap(rhs)</tt>.
17400 Howard agrees with the analysis and the direction proposed.
17403 Move to Open pending specific wording to be supplied by Howard.
17408 <p><b>Proposed resolution:</b></p>
17417 <h3><a name="901"></a>901. insert iterators can move from lvalues</h3>
17418 <p><b>Section:</b> 24.7.5 [insert.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">Tentatively NAD</a>
17419 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-09-24 <b>Last modified:</b> 2009-05-23</p>
17420 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD">Tentatively NAD</a> status.</p>
17421 <p><b>Discussion:</b></p>
17422 <p><b>Addresses UK 282</b></p>
17425 The requires clause on the <tt>const T &</tt> overloads in
17426 <tt>back_insert_iterator/front_insert_iterator/insert_iterator</tt> mean that the
17427 assignment operator will implicitly move from lvalues of a move-only type.
17430 Suggested resolutions are:
17434 Add another overload with a negative constraint on copy-constructible
17435 and flag it "= delete".
17438 Drop the copy-constructible overload entirely and rely on perfect
17439 forwarding to catch move issues one level deeper.
17442 This is a fundamental problem in move-syntax that relies on the
17443 presence of two overloads, and we need to look more deeply into this
17444 area as a whole - do not solve this issue in isolation.
17449 Post Summit, Alisdair adds:
17455 Both comment and issue have been resolved by the adoption of
17456 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2844.html">N2844</a>
17457 (rvalue references safety fix) at the last meeting.
17461 Suggest resolve as NAD Editorial with a reference to the paper.
17470 We agree that this has been resolved in the latest Working Draft.
17475 <p><b>Proposed resolution:</b></p>
17477 Recommend NAD, addressed by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2844.html">N2844</a>.
17485 <h3><a name="902"></a>902. Regular is the wrong concept to constrain numeric_limits</h3>
17486 <p><b>Section:</b> 18.3.1 [limits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
17487 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-09-24 <b>Last modified:</b> 2009-03-11</p>
17488 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#limits">issues</a> in [limits].</p>
17489 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
17490 <p><b>Discussion:</b></p>
17492 <p><b>Addresses FR 32 and DE 16</b></p>
17495 <tt>numeric_limits</tt> has functions specifically designed to return NaNs, which
17496 break the model of <tt>Regular</tt> (via its axioms.) While floating point types
17497 will be acceptible in many algorithms taking <tt>Regular</tt> values, it is not
17498 appopriate for this specific API and we need a less refined constraint.
17504 The definition of <tt>numeric_limits<></tt> as requiring a regular
17505 type is both conceptually wrong and operationally illogical. As we
17506 pointed before, this mistake needs to be corrected. For example, the
17507 template can be left unconstrained. In fact this reflects a much more
17508 general problem with concept_maps/axioms and their interpretations. It
17509 appears that the current text heavily leans toward experimental academic
17516 The class template <tt>numeric_limits</tt> should not specify the Regular concept
17517 requirement for its template parameter, because it contains functions
17518 returning NaN values for floating-point types; these values violate the
17519 semantics of EqualityComparable.
17528 Move to Open. Alisdair and Gaby will work on a solution, along with the new
17529 treatment of axioms in clause 14.
17534 <p><b>Proposed resolution:</b></p>
17543 <h3><a name="903"></a>903. <tt>back_insert_iterator</tt> issue</h3>
17544 <p><b>Section:</b> 24.7.1 [back.insert.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">Tentatively NAD</a>
17545 <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2008-09-19 <b>Last modified:</b> 2009-05-30</p>
17546 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD">Tentatively NAD</a> status.</p>
17547 <p><b>Discussion:</b></p>
17549 I just noticed this; don't know how far the problem(?) extends or
17550 whether it's new or existing: <tt>back_insert_iterator</tt>'s <tt>operator*</tt> is not
17551 <tt>const</tt>, so you can't dereference a <tt>const</tt> one.
17555 Post Summit Daniel adds:
17561 If done, this change should be applied for <tt>front_insert_iterator</tt>,
17562 <tt>insert_iterator</tt>, <tt>ostream_iterator</tt>, and <tt>ostreambuf_iterator</tt> as well.
17572 Alisdair notes that these all are output iterators.
17573 Howard points out that <tt>++*i</tt>
17574 would no longer work if we made this change.
17582 2009-05-25 Daniel adds:
17588 If <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1009">1009</a> is accepted, <tt>OutputIterator</tt> does no longer support post increment.
17591 To support backward compatibility a second overload of <tt>operator*</tt>
17593 Note that the <tt>HasDereference</tt> concept (and the <tt>HasDereference</tt> part of concept
17594 <tt>Iterator</tt>) was specifically refactored to cope with optional const
17596 to properly reflect the dual nature of built-in <tt>operator*</tt> as of
17597 13.5.8 [over.literal]/6.
17602 <p><b>Proposed resolution:</b></p>
17609 <h3><a name="904"></a>904. result_of argument types</h3>
17610 <p><b>Section:</b> 20.7.4 [func.ret] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
17611 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2008-09-10 <b>Last modified:</b> 2009-03-09</p>
17612 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
17613 <p><b>Discussion:</b></p>
17615 The WP and TR1 have the same text regarding the argument types of a
17616 <tt>result_of</tt> expression:
17619 The values <tt>ti</tt> are lvalues when the corresponding type <tt>Ti</tt> is a
17620 reference type, and rvalues otherwise.
17623 I read this to mean that this compiles:
17625 <blockquote><pre>typedef int (*func)(int&);
17626 result_of<func(int&&)>::type i = 0;
17627 </pre></blockquote>
17629 even though this doesn't:
17631 <blockquote><pre>int f(int&);
17633 </pre></blockquote>
17635 Should the text be updated to say "when <tt>Ti</tt> is an lvalue-reference
17636 type" or am I missing something?
17639 I later came up with this self-contained example which won't compile,
17640 but I think it should:
17642 <blockquote><pre>struct X {
17643 void operator()(int&);
17644 int operator()(int&&);
17647 std::result_of< X(int&&) >::type i = x(std::move(0));
17648 </pre></blockquote>
17656 Recommend Tentatively Ready.
17661 <p><b>Proposed resolution:</b></p>
17663 Change 20.7.4 [func.ret], p1:
17667 ... The values <tt>ti</tt> are lvalues
17668 when the corresponding type <tt>Ti</tt> is a<ins>n</ins> <ins>lvalue-</ins>reference type,
17669 and rvalues otherwise.
17677 <h3><a name="906"></a>906. <tt>ObjectType</tt> is the wrong concept to constrain <tt>initializer_list</tt></h3>
17678 <p><b>Section:</b> 18.9 [support.initlist] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
17679 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-09-26 <b>Last modified:</b> 2009-05-23</p>
17680 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
17681 <p><b>Discussion:</b></p>
17683 The currently proposed constraint on <tt>initializer_list</tt>'s element type
17684 <tt>E</tt> is that is has to meet <tt>ObjectType</tt>. This is an underspecification,
17685 because both core language and library part of <tt>initializer_list</tt>
17686 make clear, that it references an implicitly allocated array:
17689 8.5.4 [dcl.init.list]/4:
17692 When an initializer list is implicitly converted to a
17693 <tt>std::initializer_list<E></tt>, the object passed is constructed as if the
17694 implementation allocated an array of N elements of type <tt>E</tt>, where
17695 N is the number of elements in the initializer list.[..]
17699 18.9 [support.initlist]/2.
17703 An object of type <tt>initializer_list<E></tt> provides access to an array of
17704 objects of type <tt>const E</tt>.[..]
17708 Therefore, <tt>E</tt> needs to fulfill concept <tt>ValueType</tt> (thus excluding
17709 abstract class types). This stricter requirement should be added
17710 to prevent deep instantiation errors known from the bad old times,
17711 as shown in the following example:
17714 <blockquote><pre>// Header A: (Should concept-check even in stand-alone modus)
17716 template <DefaultConstructible T>
17717 requires MoveConstructible<T>
17718 void generate_and_do_3(T a) {
17719 std::initializer_list<T> list{T(), std::move(a), T()};
17724 void do_more_or_less();
17726 template <DefaultConstructible T>
17727 requires MoveConstructible<T>
17728 void more_generate_3() {
17730 generate_and_do_3(T());
17733 template <DefaultConstructible T>
17734 requires MoveConstructible<T>
17735 void something_and_generate_3() {
17746 virtual ~Abstract();
17747 virtual void foo() = 0; // abstract type
17748 Abstract(Abstract&&){} // MoveConstructible
17749 Abstract(){} // DefaultConstructible
17753 // The restricted template *accepts* the argument, but
17754 // causes a deep instantiation error in the internal function
17755 // generate_and_do_3:
17756 something_and_generate_3<Abstract>();
17758 </pre></blockquote>
17761 The proposed stricter constraint does not minimize the aim to
17762 support more general containers for which <tt>ObjectType</tt> would be
17763 sufficient. If such an extended container (lets assume it's still a
17764 class template) provides a constructor that accepts an <tt>initializer_list</tt>
17765 only <em>this</em> constructor would need to be restricted on <tt>ValueType</tt>:
17768 <blockquote><pre>template<ObjectType T>
17769 class ExtContainer {
17771 requires ValueType<T>
17772 ExtContainer(std::initializer_list<T>);
17775 </pre></blockquote>
17782 Move to Tentatively Ready.
17787 <p><b>Proposed resolution:</b></p>
17790 In 18.9 [support.initlist]/p.1 replace in "header <tt><initializer_list></tt> synopsis"
17791 the constraint "<tt>ObjectType</tt>" in the template parameter list by the
17792 constraint "<tt>ValueType</tt>".
17802 <h3><a name="907"></a>907. Bitset's immutable element retrieval is inconsistently defined</h3>
17803 <p><b>Section:</b> 20.3.6.2 [bitset.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
17804 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-09-26 <b>Last modified:</b> 2009-05-23</p>
17805 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#bitset.members">issues</a> in [bitset.members].</p>
17806 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
17807 <p><b>Discussion:</b></p>
17809 The current standard 14882::2003(E) as well as the current draft
17810 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>
17811 have in common a contradiction of the operational semantics
17812 of member function test 20.3.6.2 [bitset.members]/56-58 and the immutable
17813 member <tt>operator[]</tt> overload 20.3.6.2 [bitset.members]/64-66 (all references
17814 are defined in terms of
17815 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>):
17819 <li><pre>bool test(size_t pos) const;
17823 <i>Requires:</i> <tt>pos</tt> is valid
17826 <i>Throws:</i> <tt>out_of_range</tt> if <tt>pos</tt> does not correspond
17827 to a valid bit position.
17830 <i>Returns:</i> <tt>true</tt> if the bit at position <tt>pos</tt> in <tt>*this</tt>
17835 <li><pre>constexpr bool operator[](size_t pos) const;
17839 <i>Requires:</i> <tt>pos</tt> shall be valid.
17842 <i>Throws:</i> nothing.
17845 <i>Returns:</i> <tt>test(pos)</tt>.
17852 Three interpretations:
17857 The <tt>operator[]</tt> overload is indeed allowed to throw an exception
17858 (via <tt>test()</tt>, if <tt>pos</tt> corresponds to an invalid bit position) which does
17859 not leave the call frame. In this case this function cannot be a
17860 <tt>constexpr</tt> function, because <tt>test()</tt> is not, due to
17861 5.19 [expr.const]/2, last bullet.
17864 The intend was not to throw an exception in <tt>test</tt> in case of an
17865 invalid bit position. There is only little evidence for this interpretation.
17868 The intend was that <tt>operator[]</tt> should not throw any exception,
17869 but that <tt>test</tt> has the contract to do so, if the provided bit position
17875 The problem became worse, because issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#720">720</a>
17876 recently voted into WP argued that member <tt>test</tt> logically must be
17877 a <tt>constexpr</tt> function, because it was used to define the semantics
17878 of another <tt>constexpr</tt> function (the <tt>operator[]</tt> overload).
17882 Three alternatives are proposed, corresponding to the three bullets
17883 (A), (B), and (C), the author suggests to follow proposal (C).
17887 Proposed alternatives:
17893 Remove the <tt>constexpr</tt> specifier in front of <tt>operator[]</tt> overload and
17894 undo that of member <tt>test</tt> (assuming <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#720">720</a> is accepted) in both the
17895 class declaration 20.3.6 [template.bitset]/1 and in the member description
17896 before 20.3.6.2 [bitset.members]/56 and before /64 to read:
17898 <blockquote><pre><del>constexpr</del> bool test(size_t pos) const;
17900 <del>constexpr</del> bool operator[](size_t pos) const;
17901 </pre></blockquote>
17904 Change the throws clause of p. 65 to read:
17908 <i>Throws:</i> <del>nothing</del>
17909 <ins><tt>out_of_range</tt> if <tt>pos</tt> does not correspond to a valid bit
17915 Replace the throws clause p. 57 to read:
17919 <i>Throws:</i> <del><tt>out_of_range</tt> if <tt>pos</tt> does not correspond to a valid bit
17920 position</del> <ins>nothing</ins>.
17925 Undo the addition of the <tt>constexpr</tt> specifier to the <tt>test</tt> member
17926 function in both class declaration 20.3.6 [template.bitset]/1 and in the
17927 member description before 20.3.6.2 [bitset.members]/56, assuming that <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#720">720</a>
17931 <blockquote><pre><del>constexpr</del> bool test(size_t pos) const;
17932 </pre></blockquote>
17935 Change the returns clause p. 66 to read:
17939 <i>Returns:</i> <del><tt>test(pos)</tt></del> <ins><tt>true</tt> if the bit at position <tt>pos</tt> in <tt>*this</tt>
17940 has the value one, otherwise <tt>false</tt></ins>.
17952 Lawrence: proposed resolutions A, B, C are mutually exclusive.
17955 Recommend Review with option C.
17964 We agree with the proposed resolution.
17965 Move to Tentatively Ready.
17969 <p><b>Proposed resolution:</b></p>
17971 <ol ,="" start="3" type="A">
17974 Undo the addition of the <tt>constexpr</tt> specifier to the <tt>test</tt> member
17975 function in both class declaration 20.3.6 [template.bitset]/1 and in the
17976 member description before 20.3.6.2 [bitset.members]/56, assuming that <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#720">720</a>
17980 <blockquote><pre><del>constexpr</del> bool test(size_t pos) const;
17981 </pre></blockquote>
17984 Change the returns clause p. 66 to read:
17988 <i>Returns:</i> <del><tt>test(pos)</tt></del> <ins><tt>true</tt> if the bit at position <tt>pos</tt> in <tt>*this</tt>
17989 has the value one, otherwise <tt>false</tt></ins>.
18000 <h3><a name="908"></a>908. Deleted assignment operators for atomic types must be volatile</h3>
18001 <p><b>Section:</b> 29.5 [atomics.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
18002 <b>Submitter:</b> Anthony Williams <b>Opened:</b> 2008-09-26 <b>Last modified:</b> 2009-03-22</p>
18003 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types">issues</a> in [atomics.types].</p>
18004 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
18005 <p><b>Discussion:</b></p>
18007 <p><b>Addresses US 90</b></p>
18010 The deleted copy-assignment operators for the atomic types are not
18011 marked as volatile in N2723, whereas the assignment operators from the
18012 associated non-atomic types are. e.g.
18014 <blockquote><pre>atomic_bool& operator=(atomic_bool const&) = delete;
18015 atomic_bool& operator=(bool) volatile;
18016 </pre></blockquote>
18019 This leads to ambiguity when assigning a non-atomic value to a
18020 non-volatile instance of an atomic type:
18022 <blockquote><pre>atomic_bool b;
18024 </pre></blockquote>
18027 Both assignment operators require a standard conversions: the
18028 copy-assignment operator can use the implicit <tt>atomic_bool(bool)</tt>
18029 conversion constructor to convert <tt>false</tt> to an instance of
18030 <tt>atomic_bool</tt>, or <tt>b</tt> can undergo a qualification conversion in order to
18031 use the assignment from a plain <tt>bool</tt>.
18035 This is only a problem once issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#845">845</a> is applied.
18043 Move to open. Assign to Lawrence. Related to US 90 comment.
18047 <p><b>Proposed resolution:</b></p>
18049 Add volatile qualification to the deleted copy-assignment operator of
18050 all the atomic types:
18053 <blockquote><pre>atomic_bool& operator=(atomic_bool const&) <ins>volatile</ins> = delete;
18054 atomic_itype& operator=(atomic_itype const&) <ins>volatile</ins> = delete;
18055 </pre></blockquote>
18061 This will mean that the deleted copy-assignment operator will require
18062 <i>two</i> conversions in the above example, and thus be a worse match than
18063 the assignment from plain <tt>bool</tt>.
18071 <h3><a name="909"></a>909. <tt>regex_token_iterator</tt> should use <tt>initializer_list</tt></h3>
18072 <p><b>Section:</b> 28.13.2 [re.tokiter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
18073 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-09-26 <b>Last modified:</b> 2009-05-23</p>
18074 <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>
18075 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
18076 <p><b>Discussion:</b></p>
18078 <p><b>Addresses UK 319</b></p>
18080 Construction of a <tt>regex_token_iterator</tt> (28.13.2 [re.tokiter]/6+) usually
18081 requires the provision of a sequence of integer values, which
18082 can currently be done via a <tt>std::vector<int></tt> or
18083 a C array of <tt>int</tt>. Since the introduction of <tt>initializer_list</tt> in the
18084 standard it seems much more reasonable to provide a
18085 corresponding constructor that accepts an <tt>initializer_list<int></tt>
18086 instead. This could be done as a pure addition or one could
18087 even consider replacement. The author suggests the
18088 replacement strategy (A), but provides an alternative additive
18089 proposal (B) as a fall-back, because of the handiness of this
18098 We strongly recommend alternative B of the proposed resolution
18099 in order that existing code not be broken.
18100 With that understanding, move to Tentatively Ready.
18103 <p><b>Original proposed wording:</b></p>
18110 In 28.13.2 [re.tokiter]/6 and the list 28.13.2.1 [re.tokiter.cnstr]/10-11 change the
18111 constructor declaration:
18114 <blockquote><pre><del>template <std::size_t N></del>
18115 regex_token_iterator(BidirectionalIterator a, BidirectionalIterator b,
18116 const regex_type& re,
18117 <del>const int (&submatches)[N]</del> <ins>initializer_list<int> submatches</ins>,
18118 regex_constants::match_flag_type m =
18119 regex_constants::match_default);
18120 </pre></blockquote>
18125 In 28.13.2.1 [re.tokiter.cnstr]/12 change the last sentence
18129 The third constructor initializes the member <tt>subs</tt> to hold
18130 a copy of the sequence of integer values pointed to by the
18131 iterator range <tt>[<del>&</del>submatches<ins>.begin()</ins>,
18132 <del>&</del>submatches<ins>.end()</ins> <del>+ N</del>)</tt>.
18142 In 28.13.2 [re.tokiter]/6 and the list 28.13.2.1 [re.tokiter.cnstr]/10-11 <em>insert</em> the
18143 following constructor declaration between the already existing ones
18144 accepting a <tt>std::vector</tt> and a C array of <tt>int</tt>, resp.:
18147 <blockquote><pre>regex_token_iterator(BidirectionalIterator a, BidirectionalIterator b,
18148 const regex_type& re,
18149 initializer_list<int> submatches,
18150 regex_constants::match_flag_type m =
18151 regex_constants::match_default);
18152 </pre></blockquote>
18156 In 28.13.2.1 [re.tokiter.cnstr]/12 change the last sentence
18160 The third <ins>and fourth</ins> constructor initialize<del>s</del> the member <tt>subs</tt>
18161 to hold a copy of the sequence of integer values pointed to
18162 by the iterator range <tt>[&submatches,&submatches + N)</tt>
18163 <ins>and <tt>[submatches.begin(),submatches.end())</tt>, respectively</ins>.
18173 <p><b>Proposed resolution:</b></p>
18175 <ol start="2" type="A">
18181 In 28.13.2 [re.tokiter]/6 and the list 28.13.2.1 [re.tokiter.cnstr]/10-11 <em>insert</em> the
18182 following constructor declaration between the already existing ones
18183 accepting a <tt>std::vector</tt> and a C array of <tt>int</tt>, resp.:
18186 <blockquote><pre>regex_token_iterator(BidirectionalIterator a, BidirectionalIterator b,
18187 const regex_type& re,
18188 initializer_list<int> submatches,
18189 regex_constants::match_flag_type m =
18190 regex_constants::match_default);
18191 </pre></blockquote>
18195 In 28.13.2.1 [re.tokiter.cnstr]/12 change the last sentence
18199 The third <ins>and fourth</ins> constructor initialize<del>s</del> the member <tt>subs</tt>
18200 to hold a copy of the sequence of integer values pointed to
18201 by the iterator range <tt>[&submatches,&submatches + N)</tt>
18202 <ins>and <tt>[submatches.begin(),submatches.end())</tt>, respectively</ins>.
18216 <h3><a name="910"></a>910. Effects of MoveAssignable</h3>
18217 <p><b>Section:</b> 20.2.9 [concept.copymove] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
18218 <b>Submitter:</b> Alberto Ganesh Barbati <b>Opened:</b> 2008-09-29 <b>Last modified:</b> 2009-05-23</p>
18219 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
18220 <p><b>Discussion:</b></p>
18221 <p><b>Addresses UK 150</b></p>
18224 The description of the effect of <tt>operator=</tt> in the <tt>MoveAssignable</tt>
18225 concept, given in paragraph 7 is:
18228 <blockquote><pre>result_type T::operator=(T&& rv); // inherited from HasAssign<T, T&&>
18232 <i>Postconditions:</i> the constructed <tt>T</tt> object is equivalent to the value of
18233 <tt>rv</tt> before the assignment. [<i>Note:</i> there is no
18234 requirement on the value of <tt>rv</tt> after the assignment. <i>--end note</i>]
18239 The sentence contains a typo (what is the "constructed <tt>T</tt> object"?)
18240 probably due to a cut&paste from <tt>MoveConstructible</tt>. Moreover, the
18241 discussion of LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#675">675</a> shows that the postcondition is too generic
18242 and might not reflect the user expectations. An implementation of the
18243 move assignment that just calls <tt>swap()</tt> would always fulfill the
18244 postcondition as stated, but might have surprising side-effects in case
18245 the source rvalue refers to an object that is not going to be
18246 immediately destroyed. See LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#900">900</a> for another example. Due to
18247 the sometimes intangible nature of the "user expectation", it seems
18248 difficult to have precise normative wording that could cover all cases
18249 without introducing unnecessary restrictions. However a non-normative
18250 clarification could be a very helpful warning sign that swapping is not
18251 always the correct thing to do.
18255 2009-05-09 Alisdair adds:
18261 Issue 910 is exactly the reason BSI advanced the Editorial comment UK-150.
18264 The post-conditions after assignment are at a minimum that the object
18265 referenced by rv must be safely destructible, and the transaction should not
18266 leak resources. Ideally it should be possible to simply assign rv a new
18267 valid state after the call without invoking undefined behaviour, but any
18268 other use of the referenced object would depend upon additional guarantees
18274 2009-05-09 Howard adds:
18280 The intent of the rvalue reference work is that the moved from <tt>rv</tt> is
18281 a valid object. Not one in a singular state. If, for example, the moved from
18282 object is a <tt>vector</tt>, one should be able to do anything on that moved-from
18283 <tt>vector</tt> that you can do with any other <tt>vector</tt>. However you would
18284 first have to query it to find out what its current state is. E.g. it might have <tt>capacity</tt>,
18285 it might not. It might have a non-zero <tt>size</tt>, it might not. But regardless,
18286 you can <tt>push_back</tt> on to it if you want.
18290 That being said, most standard code is now conceptized. That is, the concepts
18291 list the only operations that can be done with templated types - whether or not
18292 the values have been moved from.
18296 Here is user-written code which must be allowed to be legal:
18298 <blockquote><pre>#include <vector>
18299 #include <cstdio>
18301 template <class Allocator>
18303 inspect(std::vector<double, Allocator>&& v)
18305 std::vector<double, Allocator> result(move(v));
18306 std::printf("moved from vector has %u size and %u capacity\n", v.size(), v.capacity());
18307 std::printf("The contents of the vector are:\n");
18308 typedef typename std::vector<double, Allocator>::iterator I;
18309 for (I i = v.begin(), e = v.end(); i != e; ++i)
18310 printf("%f\n", *i);
18315 std::vector<double> v1(100, 5.5);
18318 </pre></blockquote>
18321 The above program does not treat the moved-from <tt>vector</tt> as singular. It
18322 only treats it as a <tt>vector</tt> with an unknown value.
18325 I believe the current proposed wording is consistent with my view on this.
18334 We agree that the proposed resolution
18335 is an improvement over the current wording.
18340 <p><b>Proposed resolution:</b></p>
18342 In 20.2.9 [concept.copymove], replace the postcondition in paragraph 7 with:
18346 <i>Postconditions:</i> <tt>*this</tt> is equivalent to the value of <tt>rv</tt> before the
18347 assignment. [<i>Note:</i> there is no requirement on the value of <tt>rv</tt> after the
18348 assignment, but the
18349 effect should be unsurprising to the user even in case <tt>rv</tt> is not
18350 immediately destroyed. This may require that resources previously owned
18351 by <tt>*this</tt> are released instead of transferred to <tt>rv</tt>. <i>-- end note</i>]
18359 <h3><a name="911"></a>911. I/O streams and <tt>move/swap</tt> semantic</h3>
18360 <p><b>Section:</b> 27.7.1 [input.streams], 27.7.2 [output.streams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
18361 <b>Submitter:</b> Alberto Ganesh Barbati <b>Opened:</b> 2008-09-29 <b>Last modified:</b> 2009-05-23</p>
18362 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
18363 <p><b>Discussion:</b></p>
18365 Class template <tt>basic_istream</tt>, <tt>basic_ostream</tt> and <tt>basic_iostream</tt>
18366 implements public move constructors, move assignment operators and <tt>swap</tt>
18367 method and free functions. This might induce both the user and the
18368 compiler to think that those types are <tt>MoveConstructible</tt>, <tt>MoveAssignable</tt>
18369 and <tt>Swappable</tt>. However, those class templates fail to fulfill the user
18370 expectations. For example:
18373 <blockquote><pre>std::ostream os(std::ofstream("file.txt"));
18374 assert(os.rdbuf() == 0); // buffer object is not moved to os, file.txt has been closed
18376 std::vector<std::ostream> v;
18377 v.push_back(std::ofstream("file.txt"));
18378 v.reserve(100); // causes reallocation
18379 assert(v[0].rdbuf() == 0); // file.txt has been closed!
18381 std::ostream&& os1 = std::ofstream("file1.txt");
18382 os1 = std::ofstream("file2.txt");
18383 os1 << "hello, world"; // still writes to file1.txt, not to file2.txt!
18385 std::ostream&& os1 = std::ofstream("file1.txt");
18386 std::ostream&& os2 = std::ofstream("file2.txt");
18387 std::swap(os1, os2);
18388 os1 << "hello, world"; // writes to file1.txt, not to file2.txt!
18389 </pre></blockquote>
18392 This is because the move constructor, the move assignment operator and
18393 <tt>swap</tt> are all implemented through calls to <tt>std::basic_ios</tt> member
18394 functions <tt>move()</tt> and <tt>swap()</tt> that do not move nor swap the controlled
18395 stream buffers. That can't happen because the stream buffers may have
18400 Notice that for <tt>basic_streambuf</tt>, the member function <tt>swap()</tt> is
18401 protected. I believe that is correct and all of <tt>basic_istream</tt>,
18402 <tt>basic_ostream</tt>, <tt>basic_iostream</tt> should do the same as the move ctor, move
18403 assignment operator and swap member function are needed by the derived
18404 <tt>fstream</tt>s and <tt>stringstream</tt>s template. The free swap functions for
18405 <tt>basic_(i|o|io)stream</tt> templates should be removed for the same reason.
18414 We note that the rvalue swap functions have already been removed.
18417 Bill is unsure about making the affected functions protected;
18418 he believes they may need to be public.
18421 We are also unsure about removing the lvalue swap functions as proposed.
18429 <p><b>Proposed resolution:</b></p>
18431 27.7.1.1 [istream]: make the following member functions protected:
18434 <blockquote><pre>basic_istream(basic_istream&& rhs);
18435 basic_istream& operator=(basic_istream&& rhs);
18436 void swap(basic_istream&& rhs);
18437 </pre></blockquote>
18440 Ditto: remove the three swap free functions signatures
18443 <blockquote><pre><del>// swap:
18444 template <class charT, class traits>
18445 void swap(basic_istream<charT, traits>& x, basic_istream<charT, traits>& y);
18446 template <class charT, class traits>
18447 void swap(basic_istream<charT, traits>&& x, basic_istream<charT, traits>& y);
18448 template <class charT, class traits>
18449 void swap(basic_istream<charT, traits>& x, basic_istream<charT, traits>&& y);</del>
18450 </pre></blockquote>
18453 27.7.1.1.2 [istream.assign]: remove paragraph 4
18456 <blockquote><pre><del>template <class charT, class traits>
18457 void swap(basic_istream<charT, traits>& x, basic_istream<charT, traits>& y);
18458 template <class charT, class traits>
18459 void swap(basic_istream<charT, traits>&& x, basic_istream<charT, traits>& y);
18460 template <class charT, class traits>
18461 void swap(basic_istream<charT, traits>& x, basic_istream<charT, traits>&& y);</del>
18464 <del><i>Effects:</i> <tt>x.swap(y)</tt>.</del>
18469 27.7.1.5 [iostreamclass]: make the following member function protected:
18472 <blockquote><pre>basic_iostream(basic_iostream&& rhs);
18473 basic_iostream& operator=(basic_iostream&& rhs);
18474 void swap(basic_iostream&& rhs);
18475 </pre></blockquote>
18478 Ditto: remove the three swap free functions signatures
18481 <blockquote><pre><del>template <class charT, class traits>
18482 void swap(basic_iostream<charT, traits>& x, basic_iostream<charT, traits>& y);
18483 template <class charT, class traits>
18484 void swap(basic_iostream<charT, traits>&& x, basic_iostream<charT, traits>& y);
18485 template <class charT, class traits>
18486 void swap(basic_iostream<charT, traits>& x, basic_iostream<charT, traits>&& y);</del>
18487 </pre></blockquote>
18490 27.7.1.5.3 [iostream.assign]: remove paragraph 3
18493 <blockquote><pre><del>template <class charT, class traits>
18494 void swap(basic_iostream<charT, traits>& x, basic_iostream<charT, traits>& y);
18495 template <class charT, class traits>
18496 void swap(basic_iostream<charT, traits>&& x, basic_iostream<charT, traits>& y);
18497 template <class charT, class traits>
18498 void swap(basic_iostream<charT, traits>& x, basic_iostream<charT, traits>&& y);</del>
18501 <del><i>Effects:</i> <tt>x.swap(y)</tt>.</del>
18506 27.7.2.1 [ostream]: make the following member function protected:
18509 <blockquote><pre>basic_ostream(basic_ostream&& rhs);
18510 basic_ostream& operator=(basic_ostream&& rhs);
18511 void swap(basic_ostream&& rhs);
18512 </pre></blockquote>
18515 Ditto: remove the three swap free functions signatures
18518 <blockquote><pre><del>// swap:
18519 template <class charT, class traits>
18520 void swap(basic_ostream<charT, traits>& x, basic_ostream<charT, traits>& y);
18521 template <class charT, class traits>
18522 void swap(basic_ostream<charT, traits>&& x, basic_ostream<charT, traits>& y);
18523 template <class charT, class traits>
18524 void swap(basic_ostream<charT, traits>& x, basic_ostream<charT, traits>&& y);</del>
18525 </pre></blockquote>
18528 27.7.2.3 [ostream.assign]: remove paragraph 13 (The paragraphs seems to
18529 be misnumbered in the whole section 27.7.2 [output.streams] in
18530 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>.
18532 remove is the one that describes the three <tt>swap</tt> free functions).
18535 <blockquote><pre><del>template <class charT, class traits>
18536 void swap(basic_ostream<charT, traits>& x, basic_ostream<charT, traits>& y);
18537 template <class charT, class traits>
18538 void swap(basic_ostream<charT, traits>&& x, basic_ostream<charT, traits>& y);
18539 template <class charT, class traits>
18540 void swap(basic_ostream<charT, traits>& x, basic_ostream<charT, traits>&& y);</del>
18543 <del><i>Effects:</i> <tt>x.swap(y)</tt>.</del>
18553 <h3><a name="912"></a>912. Array swap needs to be conceptualized</h3>
18554 <p><b>Section:</b> 25.4.3 [alg.swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">Tentatively NAD</a>
18555 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-10-01 <b>Last modified:</b> 2009-05-23</p>
18556 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.swap">issues</a> in [alg.swap].</p>
18557 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD">Tentatively NAD</a> status.</p>
18558 <p><b>Discussion:</b></p>
18560 With the adaption of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#809">809</a>
18561 we have a new algorithm <tt>swap</tt> for C-arrays, which needs to be conceptualized.
18565 Post Summit Daniel adds:
18570 Recommend as NAD Editorial: The changes have already been applied to the WP
18571 <a href="" ref="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2800.pdf">N2800</a>.
18579 Move to NAD; the changes have already been made.
18583 <p><b>Proposed resolution:</b></p>
18585 Replace in 25.4.3 [alg.swap] before p. 3 until p. 4 by
18588 <blockquote><pre>template <<del>class</del> <ins>ValueType</ins> T, size_t N>
18589 <ins>requires Swappable<T></ins>
18590 void swap(T (&a)[N], T (&b)[N]);
18594 <del><i>Requires:</i> <tt>T</tt> shall be <tt>Swappable</tt>.</del>
18597 <i>Effects:</i> <tt>swap_ranges(a, a + N, b);</tt>
18608 <h3><a name="913"></a>913. Superfluous requirements for replace algorithms</h3>
18609 <p><b>Section:</b> 25.4.5 [alg.replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
18610 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-10-03 <b>Last modified:</b> 2009-05-23</p>
18611 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#alg.replace">active issues</a> in [alg.replace].</p>
18612 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.replace">issues</a> in [alg.replace].</p>
18613 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
18614 <p><b>Discussion:</b></p>
18616 (A) 25.4.5 [alg.replace]/1:
18620 <i>Requires:</i> The expression <tt>*first = new_value</tt> shall be valid.
18624 (B) 25.4.5 [alg.replace]/4:
18628 <i>Requires:</i> The results of the expressions <tt>*first</tt> and <tt>new_value</tt> shall
18629 be writable to the result output iterator.[..]
18633 Since conceptualization, the quoted content of these clauses is covered
18634 by the existing requirements
18638 (A) <tt>OutputIterator<Iter, const T&></tt>
18646 (B) <tt>OutputIterator<OutIter, InIter::reference> && OutputIterator<OutIter, const T&></tt>
18650 resp, and thus should be removed.
18659 We agree with the proposed resolution.
18662 Move to Tentatively Ready.
18667 <p><b>Proposed resolution:</b></p>
18671 Remove 25.4.5 [alg.replace]/1.
18673 <blockquote><pre>template<ForwardIterator Iter, class T>
18674 requires OutputIterator<Iter, Iter::reference>
18675 && OutputIterator<Iter, const T&>
18676 && HasEqualTo<Iter::value_type, T>
18677 void replace(Iter first, Iter last,
18678 const T& old_value, const T& new_value);
18680 template<ForwardIterator Iter, Predicate<auto, Iter::value_type> Pred, class T>
18681 requires OutputIterator<Iter, Iter::reference>
18682 && OutputIterator<Iter, const T&>
18683 && CopyConstructible<Pred>
18684 void replace_if(Iter first, Iter last,
18685 Pred pred, const T& new_value);
18688 <del>1 <i>Requires:</i> The expression <tt>*first = new_value</tt> shall be valid.</del>
18694 25.4.5 [alg.replace]/4: Remove the sentence "The results of the
18695 expressions <tt>*first</tt> and
18696 <tt>new_value</tt> shall be writable to the result output iterator.".
18698 <blockquote><pre>template<InputIterator InIter, typename OutIter, class T>
18699 requires OutputIterator<OutIter, InIter::reference>
18700 && OutputIterator<OutIter, const T&>
18701 && HasEqualTo<InIter::value_type, T>
18702 OutIter replace_copy(InIter first, InIter last,
18704 const T& old_value, const T& new_value);
18706 template<InputIterator InIter, typename OutIter,
18707 Predicate<auto, InIter::value_type> Pred, class T>
18708 requires OutputIterator<OutIter, InIter::reference>
18709 && OutputIterator<OutIter, const T&>
18710 && CopyConstructible<Pred>
18711 OutIter replace_copy_if(InIter first, InIter last,
18713 Pred pred, const T& new_value);
18716 4 <i>Requires:</i> <del>The results of the expressions <tt>*first</tt> and
18717 <tt>new_value</tt> shall be writable to the <tt>result</tt> output
18718 iterator.</del> The ranges <tt>[first,last)</tt> and <tt>[result,result +
18719 (last - first))</tt> shall not overlap.
18730 <h3><a name="914"></a>914. Superfluous requirement for unique</h3>
18731 <p><b>Section:</b> 25.4.9 [alg.unique] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
18732 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-10-03 <b>Last modified:</b> 2009-05-23</p>
18733 <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>
18734 <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>
18735 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
18736 <p><b>Discussion:</b></p>
18738 25.4.9 [alg.unique]/2: "Requires: The comparison function shall be an
18739 equivalence relation."
18743 The essence of this is already covered by the given requirement
18746 <blockquote><pre>EquivalenceRelation<auto, Iter::value_type> Pred
18747 </pre></blockquote>
18750 and should thus be removed.
18758 We agree with the proposed resolution.
18759 Move to Tentatively Ready.
18763 <p><b>Proposed resolution:</b></p>
18765 Remove 25.4.9 [alg.unique]/2
18768 <blockquote><pre>template<ForwardIterator Iter>
18769 requires OutputIterator<Iter, Iter::reference>
18770 && EqualityComparable<Iter::value_type>
18771 Iter unique(Iter first, Iter last);
18773 template<ForwardIterator Iter, EquivalenceRelation<auto, Iter::value_type> Pred>
18774 requires OutputIterator<Iter, RvalueOf<Iter::reference>::type>
18775 && CopyConstructible<Pred>
18776 Iter unique(Iter first, Iter last,
18781 1 <i>Effects:</i> ...
18784 <del>2 <i>Requires:</i> The comparison function shall be an equivalence relation.</del>
18794 <h3><a name="915"></a>915. <tt>minmax</tt> with <tt>initializer_list</tt> should return
18795 <tt>pair</tt> of <tt>T</tt>, not <tt>pair</tt> of <tt>const T&</tt></h3>
18796 <p><b>Section:</b> 25.5.7 [alg.min.max] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
18797 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-10-04 <b>Last modified:</b> 2009-05-23</p>
18798 <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>
18799 <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>
18800 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
18801 <p><b>Discussion:</b></p>
18803 It seems that the proposed changes for
18804 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2772.pdf">N2772</a>
18805 were not clear enough in
18810 25.5.7 [alg.min.max], before p.23 + p.24 + before p. 27 + p. 28 say that the return
18811 type of the <tt>minmax</tt> overloads with an <tt>initializer_list</tt> is
18812 <tt>pair<const T&, const T&></tt>,
18813 which is inconsistent with the decision for the other <tt>min/max</tt> overloads which take
18814 a <tt>initializer_list</tt> as argument and return a <tt>T</tt>, not a <tt>const T&</tt>.
18815 Doing otherwise for <tt>minmax</tt> would easily lead to unexpected life-time
18816 problems by using <tt>minmax</tt> instead of <tt>min</tt> and <tt>max</tt> separately.
18824 We agree with the proposed resolution.
18825 Move to Tentatively Ready.
18829 <p><b>Proposed resolution:</b></p>
18833 In 25 [algorithms]/2, header <tt><algorithm></tt> synopsis change as indicated:
18836 <blockquote><pre>template<<del>class</del><ins>LessThanComparable</ins> T>
18837 <ins>requires CopyConstructible<T></ins>
18838 pair<<del>const </del>T<del>&</del>, <del>const </del>T<del>&</del>>
18839 minmax(initializer_list<T> t);
18841 template<class T, <del>class</del><ins>StrictWeakOrder<auto, T></ins> Compare>
18842 <ins>requires CopyConstructible<T></ins>
18843 pair<<del>const </del>T<del>&</del>, <del>const </del>T<del>&</del>>
18844 minmax(initializer_list<T> t, Compare comp);
18845 </pre></blockquote>
18849 In 25.5.7 [alg.min.max] change as indicated (Begin: Just before p.20):
18851 <blockquote><pre>template<<del>class</del><ins>LessThanComparable</ins> T>
18852 <ins>requires CopyConstructible<T></ins>
18853 pair<<del>const </del>T<del>&</del>, <del>const </del>T<del>&</del>>
18854 minmax(initializer_list<T> t);
18858 <del>-20- <i>Requires:</i> <tt>T</tt> is <tt>LessThanComparable</tt> and
18859 <tt>CopyConstructible</tt>.</del>
18862 -21- <i>Returns:</i> <tt>pair<<del>const </del>T<del>&</del>, <del>const
18863 </del>T<del>&</del>>(x, y)</tt> where <tt>x</tt> is the
18864 smallest value and <tt>y</tt> the largest value in the <tt>initializer_list</tt>.
18869 <pre>template<class T, <del>class</del><ins>StrictWeakOrder<auto, T></ins> Compare>
18870 <ins>requires CopyConstructible<T></ins>
18871 pair<<del>const </del>T<del>&</del>, <del>const </del>T<del>&</del>>
18872 minmax(initializer_list<T> t, Compare comp);
18877 <del>-24- <i>Requires:</i> type <tt>T</tt> is <tt>LessThanComparable</tt> and <tt>CopyConstructible</tt>.</del>
18880 -25- <i>Returns:</i> <tt>pair<<del>const </del>T<del>&</del>, <del>const
18881 </del>T<del>&</del>>(x, y)</tt> where <tt>x</tt> is the
18882 smallest value and <tt>y</tt> largest value in the <tt>initializer_list</tt>.
18895 <h3><a name="916"></a>916. Redundant move-assignment operator of <tt>pair</tt> should be removed</h3>
18896 <p><b>Section:</b> 20.3.3 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
18897 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-10-04 <b>Last modified:</b> 2009-05-23</p>
18898 <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>
18899 <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>
18900 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
18901 <p><b>Discussion:</b></p>
18902 <p><b>see also <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#917">917</a>.</b></p>
18905 The current WP provides the following assignment operators for <tt>pair</tt>
18906 in 20.3.3 [pairs]/1:
18911 <pre>template<class U , class V>
18912 requires HasAssign<T1, const U&> && HasAssign<T2, const V&>
18913 pair& operator=(const pair<U , V>& p);
18917 <pre>requires MoveAssignable<T1> && MoveAssignable<T2> pair& operator=(pair&& p );
18921 <pre>template<class U , class V>
18922 requires HasAssign<T1, RvalueOf<U>::type> && HasAssign<T2, RvalueOf<V>::type>
18923 pair& operator=(pair<U , V>&& p);
18929 It seems that the functionality of (2) is completely covered by (3), therefore
18930 (2) should be removed.
18939 Bill believes the extra assignment operators are necessary for resolving
18940 ambiguities, but that does not mean it needs to be part of the specification.
18944 We recommend this be looked at in the context of the ongoing work
18945 related to the pair templates.
18950 <p><b>Proposed resolution:</b></p>
18954 In 20.3.3 [pairs] p. 1, class <tt>pair</tt> and just before p. 13 remove the declaration:
18957 <blockquote><pre>requires MoveAssignable<T1> && MoveAssignable<T2> pair& operator=(pair&& p );
18958 </pre></blockquote>
18972 <h3><a name="917"></a>917. Redundant move-assignment operator of <tt>tuple</tt> should be removed</h3>
18973 <p><b>Section:</b> 20.5.2.1 [tuple.cnstr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
18974 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-10-04 <b>Last modified:</b> 2009-05-23</p>
18975 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#tuple.cnstr">active issues</a> in [tuple.cnstr].</p>
18976 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple.cnstr">issues</a> in [tuple.cnstr].</p>
18977 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
18978 <p><b>Discussion:</b></p>
18979 <p><b>see also <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#916">916</a>.</b></p>
18981 N2770 (and thus now the WP) removed the
18982 non-template move-assignment operator from tuple's class definition,
18983 but the latter individual member description does still provide this
18984 operator. Is this (a) an oversight and can it (b) be solved as part of an
18989 Post Summit Daniel provided wording.
18999 We believe that the proposed resolution's part 1 is editorial.
19002 Regarding part 2, we either remove the specification as proposed,
19003 or else add back the declaration to which the specification refers.
19004 Alisdair and Bill prefer the latter.
19005 It is not immediately obvious whether the function is intended to be present.
19008 We recommend that the Project Editor restore the missing declaration
19009 and that we keep part 2 of the issue alive.
19018 <p><b>Proposed resolution:</b></p>
19022 In 20.5.2 [tuple.tuple], class <tt>tuple</tt> just before member <tt>swap</tt> please
19023 change as indicated:
19026 This fixes an editorial loss between N2798 to N2800
19029 <blockquote><pre>template <class... UTypes>
19030 requires HasAssign<Types, const UTypes&>...
19031 <ins>tuple& operator=(const pair<UTypes...>&);</ins>
19033 template <class... UTypes>
19034 requires HasAssign<Types, RvalueOf<UTypes>::type>...
19035 <ins>tuple& operator=(pair<UTypes...>&&);</ins>
19036 </pre></blockquote>
19040 In 20.5.2.1 [tuple.cnstr], starting just before p. 11 please remove
19044 <blockquote><pre><del>requires MoveAssignable<Types>... tuple& operator=(tuple&& u);</del>
19048 <del>-11- <i>Effects:</i> Move-assigns each element of <tt>u</tt> to the corresponding
19049 element of <tt>*this</tt>.</del>
19052 <del>-12- <i>Returns:</i> <tt>*this</tt>.</del>
19064 <h3><a name="918"></a>918. Swap for tuple needs to be conceptualized</h3>
19065 <p><b>Section:</b> 20.5.2.6 [tuple.swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">Tentatively NAD</a>
19066 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-10-04 <b>Last modified:</b> 2009-05-23</p>
19067 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD">Tentatively NAD</a> status.</p>
19068 <p><b>Discussion:</b></p>
19070 Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#522">522</a> was accepted after <tt>tuple</tt> had been conceptualized,
19071 therefore this step needs to be completed.
19075 Post Summit Daniel adds
19080 This is now NAD Editorial (addressed by
19081 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2844.html">N2844</a>)
19082 except for item 3 in the proposed wording.
19086 2009-05-01 Daniel adds:
19091 As of the recent WP
19092 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2857.pdf">N2857</a>),
19093 this issue is now completely covered by editorial
19094 changes (including the third bullet), therefore I unconditionally recommend
19104 We observed that all the proposed changes have already been applied to the
19105 Working Draft, rendering this issue moot.
19114 <p><b>Proposed resolution:</b></p>
19118 In both 20.5.1 [tuple.general]/2 and 20.5.2.7 [tuple.special] change
19121 <blockquote><pre>template <<del>class</del> <ins>Swappable</ins>... Types>
19122 void swap(tuple<Types...>& x, tuple<Types...>& y);
19123 </pre></blockquote>
19129 In 20.5.2 [tuple.tuple], class <tt>tuple</tt> definition and in
19130 20.5.2.6 [tuple.swap], change
19133 <blockquote><pre><ins>requires Swappable<Types>...</ins>void swap(tuple&);
19134 </pre></blockquote>
19140 In 20.5.2.6 [tuple.swap] remove the current requires-clause, which says:
19144 <del><i>Requires:</i> Each type in <tt>Types</tt> shall be <tt>Swappable</tt></del>
19156 <h3><a name="919"></a>919. (forward_)list specialized remove algorithms are over constrained</h3>
19157 <p><b>Section:</b> 23.3.3.5 [forwardlist.ops], 23.3.4.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
19158 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-10-06 <b>Last modified:</b> 2009-05-23</p>
19159 <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>
19160 <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>
19161 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
19162 <p><b>Discussion:</b></p>
19164 The signatures of <tt>forwardlist::remove</tt> and <tt>list::remove</tt>
19165 defined in 23.3.3.5 [forwardlist.ops] before 11 + 23.3.4.4 [list.ops] before 15:
19168 <blockquote><pre>requires EqualityComparable<T> void remove(const T& value);
19169 </pre></blockquote>
19172 are asymmetric to their predicate variants (which only require
19173 <tt>Predicate</tt>, <em>not</em> <tt>EquivalenceRelation</tt>) and with the free algorithm
19174 remove (which only require <tt>HasEqualTo</tt>). Also, nothing in the
19176 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>
19177 implies that <tt>EqualityComparable</tt> should
19178 be the intended requirement.
19187 We agree with the proposed resolution,
19188 but would like additional input from concepts experts.
19196 <p><b>Proposed resolution:</b></p>
19200 Replace in 23.3.3.5 [forwardlist.ops] before 11 and in 23.3.4.4 [list.ops] before 15
19203 <blockquote><pre>requires <del>EqualityComparable<T></del> <ins>HasEqualTo<T, T></ins> void remove(const T& value);
19204 </pre></blockquote>
19214 <h3><a name="920"></a>920. Ref-qualification support in the library</h3>
19215 <p><b>Section:</b> 20.7.15 [func.memfn] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
19216 <b>Submitter:</b> Bronek Kozicki <b>Opened:</b> 2008-10-06 <b>Last modified:</b> 2009-05-23</p>
19217 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
19218 <p><b>Discussion:</b></p>
19220 Daniel Krügler wrote:
19225 Shouldn't above list be completed for &- and &&-qualified
19226 member functions This would cause to add:
19228 <blockquote><pre>template<Returnable R, class T, CopyConstructible... Args>
19229 unspecified mem_fn(R (T::* pm)(Args...) &);
19230 template<Returnable R, class T, CopyConstructible... Args>
19231 unspecified mem_fn(R (T::* pm)(Args...) const &);
19232 template<Returnable R, class T, CopyConstructible... Args>
19233 unspecified mem_fn(R (T::* pm)(Args...) volatile &);
19234 template<Returnable R, class T, CopyConstructible... Args>
19235 unspecified mem_fn(R (T::* pm)(Args...) const volatile &);
19236 template<Returnable R, class T, CopyConstructible... Args>
19237 unspecified mem_fn(R (T::* pm)(Args...) &&);
19238 template<Returnable R, class T, CopyConstructible... Args>
19239 unspecified mem_fn(R (T::* pm)(Args...) const &&);
19240 template<Returnable R, class T, CopyConstructible... Args>
19241 unspecified mem_fn(R (T::* pm)(Args...) volatile &&);
19242 template<Returnable R, class T, CopyConstructible... Args>
19243 unspecified mem_fn(R (T::* pm)(Args...) const volatile &&);
19244 </pre></blockquote>
19249 yes, absolutely. Thanks for spotting this. Without this change <tt>mem_fn</tt>
19250 cannot be initialized from pointer to ref-qualified member function. I
19251 believe semantics of such function pointer is well defined.
19255 Post Summit Daniel provided wording.
19265 We need to think about whether we really want to go down the proposed path
19266 of combinatorial explosion.
19267 Perhaps a Note would suffice.
19270 We would really like to have an implementation before proceeding.
19273 Move to Open, and recommend this be deferred until after the next
19274 Committee Draft has been issued.
19279 <p><b>Proposed resolution:</b></p>
19283 In 20.7 [function.objects]/2, header <tt><functional></tt> synopsis, just after
19284 the section "// 20.6.15, member function adaptors::" add the following
19285 declarations to the existing list:
19287 <blockquote><pre>template<Returnable R, class T, CopyConstructible... Args>
19288 <i>unspecified</i> mem_fn(R (T::* pm)(Args...) &);
19289 template<Returnable R, class T, CopyConstructible... Args>
19290 <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const &);
19291 template<Returnable R, class T, CopyConstructible... Args>
19292 <i>unspecified</i> mem_fn(R (T::* pm)(Args...) volatile &);
19293 template<Returnable R, class T, CopyConstructible... Args>
19294 <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const volatile &);
19295 template<Returnable R, class T, CopyConstructible... Args>
19296 <i>unspecified</i> mem_fn(R (T::* pm)(Args...) &&);
19297 template<Returnable R, class T, CopyConstructible... Args>
19298 <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const &&);
19299 template<Returnable R, class T, CopyConstructible... Args>
19300 <i>unspecified</i> mem_fn(R (T::* pm)(Args...) volatile &&);
19301 template<Returnable R, class T, CopyConstructible... Args>
19302 <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const volatile &&);
19303 </pre></blockquote>
19307 In 20.7.15 [func.memfn] add the following declarations to the existing
19310 <blockquote><pre>template<Returnable R, class T, CopyConstructible... Args>
19311 <i>unspecified</i> mem_fn(R (T::* pm)(Args...) &);
19312 template<Returnable R, class T, CopyConstructible... Args>
19313 <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const &);
19314 template<Returnable R, class T, CopyConstructible... Args>
19315 <i>unspecified</i> mem_fn(R (T::* pm)(Args...) volatile &);
19316 template<Returnable R, class T, CopyConstructible... Args>
19317 <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const volatile &);
19318 template<Returnable R, class T, CopyConstructible... Args>
19319 <i>unspecified</i> mem_fn(R (T::* pm)(Args...) &&);
19320 template<Returnable R, class T, CopyConstructible... Args>
19321 <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const &&);
19322 template<Returnable R, class T, CopyConstructible... Args>
19323 <i>unspecified</i> mem_fn(R (T::* pm)(Args...) volatile &&);
19324 template<Returnable R, class T, CopyConstructible... Args>
19325 <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const volatile &&);
19326 </pre></blockquote>
19330 The following text, most notably p.2 and p.3 which discuss influence
19331 of the cv-qualification on the definition of the base class's first template
19332 parameter remains unchanged.
19340 <h3><a name="921"></a>921. Rational Arithmetic should use template aliases</h3>
19341 <p><b>Section:</b> 20.4.1 [ratio.ratio] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
19342 <b>Submitter:</b> Pablo Halpern <b>Opened:</b> 2008-10-07 <b>Last modified:</b> 2009-05-23</p>
19343 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#ratio.ratio">active issues</a> in [ratio.ratio].</p>
19344 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ratio.ratio">issues</a> in [ratio.ratio].</p>
19345 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
19346 <p><b>Discussion:</b></p>
19348 The compile-time functions that operate on <tt>ratio<N,D></tt> require the
19349 cumbersome and error-prone "evaluation" of a <tt>type</tt> member using a
19350 meta-programming style that predates the invention of template aliases.
19351 Thus, multiplying three ratios <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> requires the expression:
19354 <blockquote><pre>ratio_multiply<a, ratio_multiply<b, c>::type>::type
19355 </pre></blockquote>
19358 The simpler expression:
19361 <blockquote><pre>ratio_multiply<a, ratio_multiply<b, c>>
19362 </pre></blockquote>
19365 Could be used by if template aliases were employed in the definitions.
19375 Jens: not a complete proposed resolution: "would need to make similar change"
19378 Consensus: We agree with the direction of the issue.
19386 2009-05-11 Daniel adds:
19392 Personally I'm <em>not</em> in favor for the addition of:
19394 <blockquote><pre>typedef ratio type;
19395 </pre></blockquote>
19397 For a reader of the
19398 standard it's usage or purpose is unclear. I haven't seen similar examples
19399 of attempts to satisfy non-feature complete compilers.
19404 2009-05-11 Pablo adds:
19410 The addition of type to the <tt>ratio</tt> template allows the previous style
19411 (i.e., in the prototype implementations) to remain valid and permits the
19412 use of transitional library implementations for C++03 compilers. I do
19413 not feel strongly about its inclusion, however, and leave it up to the
19414 reviewers to decide.
19423 Bill asks for additional discussion in the issue
19424 that spells out more details of the implementation.
19425 Howard points us to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#948">948</a>
19426 which has at least most of the requested details.
19427 Tom is strongly in favor of overflow-checking at compile time.
19428 Pete points out that there is no change of functionality implied.
19429 We agree with the proposed resolution,
19430 but recommend moving the issue to Review
19431 to allow time to improve the discussion if needed.
19435 <p><b>Proposed resolution:</b></p>
19441 In 20.4 [ratio]/3 change as indicated:
19444 <blockquote><pre>// ratio arithmetic
19445 template <class R1, class R2> <del>struct</del><ins>using</ins> ratio_add<ins> = <em>see below</em></ins>;
19446 template <class R1, class R2> <del>struct</del><ins>using</ins> ratio_subtract<ins> = <em>see below</em></ins>;
19447 template <class R1, class R2> <del>struct</del><ins>using</ins> ratio_multiply<ins> = <em>see below</em></ins>;
19448 template <class R1, class R2> <del>struct</del><ins>using</ins> ratio_divide<ins> = <em>see below</em></ins>;
19449 </pre></blockquote>
19453 In 20.4.1 [ratio.ratio], change as indicated:
19455 <blockquote><pre>namespace std {
19456 template <intmax_t N, intmax_t D = 1>
19459 <ins>typedef ratio type;</ins>
19460 static const intmax_t num;
19461 static const intmax_t den;
19464 </pre></blockquote>
19468 In 20.4.2 [ratio.arithmetic] change as indicated:
19471 <blockquote><pre>template <class R1, class R2> <del>struct</del><ins>using</ins> ratio_add<ins> = <em>see below</em></ins><del>{
19472 typedef <em>see below</em> type;
19478 1 The <del>nested typedef</del> type <tt><ins>ratio_add<R1, R2></ins></tt>
19479 shall be a synonym for <tt>ratio<T1, T2></tt>
19480 where <tt>T1</tt> has the value <tt>R1::num * R2::den + R2::num * R1::den</tt> and <tt>T2</tt>
19481 has the value <tt>R1::den * R2::den</tt>.
19485 <blockquote><pre>template <class R1, class R2> <del>struct</del><ins>using</ins> ratio_subtract<ins> = <em>see below</em></ins><del>{
19486 typedef <em>see below</em> type;
19491 2 The <del>nested typedef</del> type <tt><ins>ratio_subtract<R1, R2></ins></tt>
19492 shall be a synonym for <tt>ratio<T1, T2></tt>
19493 where <tt>T1</tt> has the value <tt>R1::num * R2::den - R2::num * R1::den</tt> and <tt>T2</tt>
19494 has the value <tt>R1::den * R2::den</tt>.
19498 <blockquote><pre>template <class R1, class R2> <del>struct</del><ins>using</ins> ratio_multiply<ins> = <em>see below</em></ins><del>{
19499 typedef <em>see below</em> type;
19504 3 The <del>nested typedef</del> type <tt><ins>ratio_multiply<R1, R2></ins></tt>
19505 shall be a synonym for <tt>ratio<T1, T2></tt>
19506 where <tt>T1</tt> has the value <tt>R1::num * R2::num</tt> and <tt>T2</tt> has the value <tt>R1::den * R2::den</tt>.
19510 <blockquote><pre>template <class R1, class R2> <del>struct</del><ins>using</ins> ratio_divide<ins> = <em>see below</em></ins><del>{
19511 typedef <em>see below</em> type;
19516 4 The <del>nested typedef</del> type <tt><ins>ratio_divide<R1, R2></ins></tt>
19517 shall be a synonym for <tt>ratio<T1, T2></tt>
19518 where <tt>T1</tt> has the value <tt>R1::num * R2::den</tt> and <tt>T2</tt> has the value <tt>R1::den * R2::num</tt>.
19525 In 20.9.3.1 [time.duration.cons]/4 change as indicated:
19529 <i>Requires:</i> <tt>treat_as_floating_point<rep>::value</tt> shall be true or
19530 <tt>ratio_divide<Period2, period>::<del>type::</del>den</tt> shall be 1.[..]
19536 In 20.9.3.7 [time.duration.cast]/2 change as indicated:
19540 <i>Returns:</i> Let CF be <tt>ratio_divide<Period, typename
19541 ToDuration::period><del>::type</del></tt>, and [..]
19552 <h3><a name="922"></a>922. [func.bind.place] Number of placeholders</h3>
19553 <p><b>Section:</b> B [implimits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
19554 <b>Submitter:</b> Sohail Somani <b>Opened:</b> 2008-10-11 <b>Last modified:</b> 2009-03-13</p>
19555 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
19556 <p><b>Discussion:</b></p>
19557 <p><b>Addresses DE 24</b></p>
19560 With respect to the section 20.7.12.1.4 [func.bind.place]:
19563 TR1 dropped some suggested implementation quantities for the number of
19564 placeholders. The purpose of this defect is to put these back for C++0x.
19577 Recommend applying the proposed resolution from DE 24, with that
19582 <b>Original proposed resolution:</b>
19585 Add 20.7.12.1.4 [func.bind.place]/2:
19589 While the exact number of placeholders (<tt>_M</tt>) is implementation defined,
19590 this number shall be at least 10.
19595 <p><b>Proposed resolution:</b></p>
19598 Add to B [implimits]:
19603 Number of placeholders (20.7.12.1.4 [func.bind.place]) [10].
19613 <h3><a name="923"></a>923. atomics with floating-point </h3>
19614 <p><b>Section:</b> 29 [atomics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
19615 <b>Submitter:</b> Herb Sutter <b>Opened:</b> 2008-10-17 <b>Last modified:</b> 2009-05-01</p>
19616 <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>
19617 <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>
19618 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
19619 <p><b>Discussion:</b></p>
19621 Right now, C++0x doesn't have <tt>atomic<float></tt>. We're thinking of adding
19622 the words to support it for TR2 (note: that would be slightly
19623 post-C++0x). If we need it, we could probably add the words.
19626 <b>Proposed resolutions:</b> Using <tt>atomic<FP>::compare_exchange</tt> (weak or
19627 strong) should be either:
19640 I propose Option 1 for C++0x for expediency. If someone wants to argue
19641 for Option 2, they need to say what exactly they want <tt>compare_exchange</tt>
19642 to mean in this case (IIRC, C++0x doesn't even assume IEEE 754).
19651 Move to open. Blocked until concepts for atomics are addressed.
19655 Post Summit Anthony adds:
19661 Recommend NAD. C++0x does have <tt>std::atomic<float></tt>, and both
19662 <tt>compare_exchange_weak</tt> and <tt>compare_exchange_strong</tt> are well-defined in
19663 this case. Maybe change the note in 29.6 [atomics.types.operations] paragraph 20 to:
19668 [<i>Note:</i> The effect of the compare-and-exchange operations is
19670 <blockquote><pre>if (!memcmp(object,expected,sizeof(*object)))
19673 *expected = *object;
19674 </pre></blockquote>
19677 This may result in failed comparisons for values that compare equal if
19678 the underlying type has padding bits or alternate representations of
19679 the same value. <i>-- end note</i>]
19687 <p><b>Proposed resolution:</b></p>
19689 Change the note in 29.6 [atomics.types.operations] paragraph 20 to:
19694 [<i>Note:</i> The effect of the compare-and-exchange operations is
19696 <blockquote><pre>if (<del>*object == *expected</del> <ins>!memcmp(object,expected,sizeof(*object))</ins>)
19699 *expected = *object;
19700 </pre></blockquote>
19703 This may result in failed comparisons for values that compare equal if
19704 the underlying type has padding bits or alternate representations of
19705 the same value.</ins> <i>-- end note</i>]
19715 <h3><a name="924"></a>924. structs with internal padding</h3>
19716 <p><b>Section:</b> 29 [atomics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
19717 <b>Submitter:</b> Herb Sutter <b>Opened:</b> 2008-10-17 <b>Last modified:</b> 2009-03-22</p>
19718 <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>
19719 <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>
19720 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
19721 <p><b>Discussion:</b></p>
19723 Right now, the <tt>compare_exchange_weak</tt> loop should rapidly converge on the
19724 padding contents. But <tt>compare_exchange_strong</tt> will require a bit more
19725 compiler work to ignore padding for comparison purposes.
19728 Note that this isn't a problem for structs with no padding, and we do
19729 already have one portable way to ensure that there is no padding that
19730 covers the key use cases: Have elements be the same type. I suspect that
19731 the greatest need is for a structure of two pointers, which has no
19732 padding problem. I suspect the second need is a structure of a pointer
19733 and some form of an integer. If that integer is <tt>intptr_t</tt>, there will be
19737 Related but separable issue: For unused bitfields, or other unused
19738 fields for that matter, we should probably say it's the programmer's
19739 responsibility to set them to zero or otherwise ensure they'll be
19740 ignored by <tt>memcmp</tt>.
19744 <b>Proposed resolutions:</b> Using
19745 <tt>atomic<struct-with-padding>::compare_exchange_strong</tt> should be either:
19758 I propose Option 1 for C++0x for expediency, though I'm not sure how to
19759 say it. I would be happy with Option 2, which I believe would mean that
19760 <tt>compare_exchange_strong</tt> would be implemented to avoid comparing padding
19761 bytes, or something equivalent such as always zeroing out padding when
19762 loading/storing/comparing. (Either implementation might require compiler
19772 Move to open. Blocked until concepts for atomics are addressed.
19776 Post Summit Anthony adds:
19781 The resoultion of LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#923">923</a> should resolve this issue as well.
19786 <p><b>Proposed resolution:</b></p>
19795 <h3><a name="925"></a>925. <tt>shared_ptr</tt>'s explicit conversion from <tt>unique_ptr</tt></h3>
19796 <p><b>Section:</b> 20.8.13.2.1 [util.smartptr.shared.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
19797 <b>Submitter:</b> Rodolfo Lima <b>Opened:</b> 2008-10-12 <b>Last modified:</b> 2009-05-23</p>
19798 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#util.smartptr.shared.const">active issues</a> in [util.smartptr.shared.const].</p>
19799 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared.const">issues</a> in [util.smartptr.shared.const].</p>
19800 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
19801 <p><b>Discussion:</b></p>
19803 The current working draft
19804 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdf">N2798</a>),
19805 section 20.8.13.2.1 [util.smartptr.shared.const] declares
19806 <tt>shared_ptr</tt>'s constructor that takes a rvalue reference to <tt>unique_ptr</tt> and
19807 <tt>auto_ptr</tt> as being explicit, affecting several valid smart pointer use
19808 cases that would take advantage of this conversion being implicit, for
19812 <blockquote><pre>class A;
19813 std::unique_ptr<A> create();
19814 void process(std::shared_ptr<A> obj);
19818 process(create()); // use case #1
19819 std::unique_ptr<A> uobj = create();
19820 process(std::move(uobj)); // use case #2
19823 </pre></blockquote>
19826 If <tt>unique_ptr</tt> to <tt>shared_ptr</tt> conversions are explicit, the above lines
19830 <blockquote><pre>process(std::shared_ptr<A>(create())); // use case #1
19831 process(std::shared_ptr<A>(std::move(uobj))); // use case #2
19832 </pre></blockquote>
19835 The extra cast required doesn't seems to give any benefits to the user,
19836 nor protects him of any unintended conversions, this being the raison
19837 d'etre of explicit constructors.
19841 It seems that this constructor was made explicit to mimic the conversion
19842 from <tt>auto_ptr</tt> in pre-rvalue reference days, which accepts both lvalue and
19843 rvalue references. Although this decision was valid back then, C++0x
19844 allows the user to express in a clear and non verbose manner when he wants
19845 move semantics to be employed, be it implicitly (use case 1) or explicitly
19855 Howard and Alisdair like the motivating use cases
19856 and the proposed resolution.
19859 Move to Tentatively Ready.
19864 <p><b>Proposed resolution:</b></p>
19866 In both 20.8.13.2 [util.smartptr.shared] paragraph 1 and
19867 20.8.13.2.1 [util.smartptr.shared.const] change:
19870 <blockquote><pre>template <class Y> <del>explicit</del> shared_ptr(auto_ptr<Y> &&r);
19871 template <class Y, class D> <del>explicit</del> shared_ptr(unique_ptr<Y, D> &&r);
19872 </pre></blockquote>
19880 <h3><a name="926"></a>926. Sequentially consistent fences, relaxed operations and modification order</h3>
19881 <p><b>Section:</b> 29.3 [atomics.order] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
19882 <b>Submitter:</b> Anthony Williams <b>Opened:</b> 2008-10-19 <b>Last modified:</b> 2009-03-22</p>
19883 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.order">issues</a> in [atomics.order].</p>
19884 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
19885 <p><b>Discussion:</b></p>
19886 <p><b>Addresses UK 313</b></p>
19889 There was an interesting issue raised over on comp.programming.threads
19890 today regarding the following example
19893 <blockquote><pre>// Thread 1:
19894 x.store(1, memory_order_relaxed); // SX
19895 atomic_thread_fence(memory_order_seq_cst); // F1
19896 y.store(1, memory_order_relaxed); // SY1
19897 atomic_thread_fence(memory_order_seq_cst); // F2
19898 r1 = y.load(memory_order_relaxed); // RY
19901 y.store(0, memory_order_relaxed); // SY2
19902 atomic_thread_fence(memory_order_seq_cst); // F3
19903 r2 = x.load(memory_order_relaxed); // RX
19904 </pre></blockquote>
19907 is the outcome <tt>r1 == 0</tt> and <tt>r2 == 0</tt> possible?
19910 I think the intent is that this is not possible, but I am not sure the
19911 wording guarantees that. Here is my analysis:
19914 Since all the fences are SC, there must be a total order between them.
19915 <tt>F1</tt> must be before <tt>F2</tt> in that order since they are in
19916 the same thread. Therefore <tt>F3</tt> is either before <tt>F1</tt>,
19917 between <tt>F1</tt> and <tt>F2</tt> or after <tt>F2</tt>.
19920 If <tt>F3</tt> is <em>after</em> <tt>F2</tt>, then we can apply 29.3 [atomics.order]p5 from
19921 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdf">N2798</a>:
19925 For atomic operations <tt>A</tt> and <tt>B</tt> on an atomic object
19926 <tt>M</tt>, where <tt>A</tt> modifies <tt>M</tt> and <tt>B</tt> takes
19927 its value, if there are <tt>memory_order_seq_cst</tt> fences <tt>X</tt>
19928 and <tt>Y</tt> such that <tt>A</tt> is sequenced before <tt>X</tt>,
19929 <tt>Y</tt> is sequenced before <tt>B</tt>, and <tt>X</tt> precedes
19930 <tt>Y</tt> in <tt>S</tt>, then <tt>B</tt> observes either the effects of
19931 <tt>A</tt> or a later modification of <tt>M</tt> in its modification
19936 In this case, <tt>A</tt> is <tt>SX</tt>, <tt>B</tt> is <tt>RX</tt>, the
19937 fence <tt>X</tt> is <tt>F2</tt> and the fence <tt>Y</tt> is <tt>F3</tt>,
19938 so <tt>RX</tt> must see 1.
19941 If <tt>F3</tt> is <em>before</em> <tt>F2</tt>, this doesn't apply, but
19942 <tt>F3</tt> can therefore be before or after <tt>F1</tt>.
19945 If <tt>F3</tt> is <em>after</em> <tt>F1</tt>, the same logic applies, but this
19946 time the fence <tt>X</tt> is <tt>F1</tt>. Therefore again, <tt>RX</tt>
19950 Finally we have the case that <tt>F3</tt> is <em>before</em> <tt>F1</tt>
19951 in the SC ordering. There are now no guarantees about <tt>RX</tt>, and
19952 <tt>RX</tt> can see <tt>r2==0</tt>.
19955 We can apply 29.3 [atomics.order]p5 again. This time,
19956 <tt>A</tt> is <tt>SY2</tt>, <tt>B</tt> is <tt>RY</tt>, <tt>X</tt> is
19957 <tt>F3</tt> and <tt>Y</tt> is <tt>F1</tt>. Thus <tt>RY</tt> must observe
19958 the effects of <tt>SY2</tt> or a later modification of <tt>y</tt> in its
19959 modification order.
19962 Since <tt>SY1</tt> is sequenced before <tt>RY</tt>, <tt>RY</tt> must
19963 observe the effects of <tt>SY1</tt> or a later modification of
19964 <tt>y</tt> in its modification order.
19967 In order to ensure that <tt>RY</tt> sees <tt>(r1==1)</tt>, we must see
19968 that <tt>SY1</tt> is later in the modification order of <tt>y</tt> than
19972 We're now skating on thin ice. Conceptually, <tt>SY2</tt> happens-before
19973 <tt>F3</tt>, <tt>F3</tt> is SC-ordered before <tt>F1</tt>, <tt>F1</tt>
19974 happens-before <tt>SY1</tt>, so <tt>SY1</tt> is later in the
19975 modification order <tt>M</tt> of <tt>y</tt>, and <tt>RY</tt> must see
19976 the result of <tt>SY1</tt> (<tt>r1==1</tt>). However, I don't think the
19977 words are clear on that.
19981 Post Summit Hans adds:
19987 In my (Hans') view, our definition of fences will always be weaker than
19988 what particular hardware will guarantee. <tt>Memory_order_seq_cst</tt> fences
19989 inherently don't guarantee sequential consistency anyway, for good
19990 reasons (e.g. because they can't enforce a total order on stores).
19991 Hence I don't think the issue demonstrates a gross failure to achieve
19992 what we intended to achieve. The example in question is a bit esoteric.
19993 Hence, in my view, living with the status quo certainly wouldn't be a
19997 In any case, we should probably add text along the lines of the
19998 following between p5 and p6 in 29.3 [atomics.order]:
20001 [Note: <tt>Memory_order_seq_cst</tt> only ensures sequential consistency for a
20002 data-race-free program that uses exclusively <tt>memory_order_seq_cst</tt>
20003 operations. Any use of weaker ordering will invalidate this guarantee
20004 unless extreme care is used. In particular, <tt>memory_order_seq_cst</tt> fences
20005 only ensure a total order for the fences themselves. They cannot, in
20006 general, be used to restore sequential consistency for atomic operations
20007 with weaker ordering specifications.]
20011 Also see thread beginning at c++std-lib-23271.
20017 Herve's correction:
20022 Minor point, and sorry for the knee jerk reaction: I admit to having
20023 no knowledge of Memory_order_seq_cst, but my former boss (John Lakos)
20024 has ingrained an automatic introspection on the use of "only". I
20029 [Note: <tt>Memory_order_seq_cst</tt> ensures sequential consistency only
20030 for . . . . In particular, <tt>memory_order_seq_cst</tt> fences ensure a
20031 total order only for . . .
20034 Unless, of course, <tt>Memory_order_seq_cst</tt> really do nothing but ensure
20035 sequential consistency for a data-race-free program that uses
20036 exclusively <tt>memory_order_seq_cst</tt> operations.
20042 <p><b>Proposed resolution:</b></p>
20044 Add a new paragraph after 29.3 [atomics.order]p5 that says
20048 For atomic operations <tt>A</tt> and <tt>B</tt> on an atomic object
20049 <tt>M</tt>, where <tt>A</tt> and <tt>B</tt> modify <tt>M</tt>, if there
20050 are <tt>memory_order_seq_cst</tt> fences <tt>X</tt> and <tt>Y</tt> such
20051 that <tt>A</tt> is sequenced before <tt>X</tt>, <tt>Y</tt> is sequenced
20052 before <tt>B</tt>, and <tt>X</tt> precedes <tt>Y</tt> in <tt>S</tt>,
20053 then <tt>B</tt> occurs later than <tt>A</tt> in the modifiction order of
20062 <h3><a name="927"></a>927. <tt>Dereferenceable</tt> should be <tt>HasDereference</tt></h3>
20063 <p><b>Section:</b> 20.8.2.2 [allocator.concepts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Tentatively NAD Editorial</a>
20064 <b>Submitter:</b> Pablo Halpern <b>Opened:</b> 2008-10-23 <b>Last modified:</b> 2009-05-23</p>
20065 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD%20Editorial">Tentatively NAD Editorial</a> status.</p>
20066 <p><b>Discussion:</b></p>
20068 20.8.2.2 [allocator.concepts] contains a reference to a concept named
20069 <tt>Dereferenceable</tt>. No such concept exists.
20073 Daniel adds 2009-02-14:
20078 The proposal given in the paper
20079 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2829.pdf">N2829</a>
20080 would automatically resolve this issue.
20090 This particular set of changes has already been made.
20091 There are two related changes later on (and possibly also an earlier Example);
20092 these can be handled editorially.
20095 Move to NAD Editorial.
20100 <p><b>Proposed resolution:</b></p>
20102 Change all uses of the concept <tt>Dereferenceable</tt> to
20103 <tt>HasDereference</tt> in 20.8.2.2 [allocator.concepts].
20111 <h3><a name="928"></a>928. Wrong concepts used for <tt>tuple</tt>'s comparison operators</h3>
20112 <p><b>Section:</b> 20.5.2.5 [tuple.rel] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
20113 <b>Submitter:</b> Joe Gottman <b>Opened:</b> 2008-10-28 <b>Last modified:</b> 2009-03-09</p>
20114 <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>
20115 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
20116 <p><b>Discussion:</b></p>
20118 In the latest working draft for C++0x, <tt>tuple</tt>'s <tt>operator==</tt> and <tt>operator<</tt>
20122 <blockquote><pre>template<class... TTypes, class... UTypes>
20123 requires EqualityComparable<TTypes, UTypes>...
20124 bool operator==(const tuple<TTypes...>& t, const tuple<UTypes...>& u);
20125 </pre></blockquote>
20131 <blockquote><pre>template<class... TTypes, class... UTypes>
20132 requires LessThanComparable<TTypes, UTypes>...
20133 bool operator<(const tuple<TTypes...>& t, const tuple<UTypes...>& u);
20134 </pre></blockquote>
20137 But the concepts <tt>EqualityComparable</tt> and <tt>LessThanComparable</tt> only take one
20138 parameter, not two. Also, even if <tt>LessThanComparable</tt> could take two
20139 parameters, the definition of <tt>tuple::operator<()</tt> should also require
20142 <blockquote><pre>LessThanComparable<UTypes, TTypes>... // (note the order)
20143 </pre></blockquote>
20146 since the algorithm for <tt>tuple::operator<</tt> is the following (pseudo-code)
20149 <blockquote><pre>for (size_t N = 0; N < sizeof...(TTypes); ++N) {
20150 if (get<N>(t) < get<N>(u) return true;
20151 else if ((get<N>(u) < get<N>(t)) return false;
20155 </pre></blockquote>
20158 Similar problems hold for <tt>tuples</tt>'s other comparison operators.
20167 Recommend Tentatively Ready.
20172 <p><b>Proposed resolution:</b></p>
20174 In 20.5.1 [tuple.general] and 20.5.2.5 [tuple.rel] change:
20177 <blockquote><pre>template<class... TTypes, class... UTypes>
20178 requires <del>EqualityComparable</del><ins>HasEqualTo</ins><TTypes, UTypes>...
20179 bool operator==(const tuple<TTypes...>&, const tuple<UTypes...>&);
20181 template<class... TTypes, class... UTypes>
20182 requires <del>LessThanComparable</del><ins>HasLess</ins><TTypes, UTypes>... <ins>&& HasLess<UTypes, TTypes>...</ins>
20183 bool operator<(const tuple<TTypes...>&, const tuple<UTypes...>&);
20185 template<class... TTypes, class... UTypes>
20186 requires <del>EqualityComparable</del><ins>HasEqualTo</ins><TTypes, UTypes>...
20187 bool operator!=(const tuple<TTypes...>&, const tuple<UTypes...>&);
20189 template<class... TTypes, class... UTypes>
20190 requires <del>LessThanComparable</del><ins>HasLess</ins><<del>U</del><ins>T</ins>Types, <del>T</del><ins>U</ins>Types>... <ins>&& HasLess<UTypes, TTypes>...</ins>
20191 bool operator>(const tuple<TTypes...>&, const tuple<UTypes...>&);
20193 template<class... TTypes, class... UTypes>
20194 requires <del>LessThanComparable</del><ins>HasLess</ins><<del>U</del><ins>T</ins>Types, <del>T</del><ins>U</ins>Types>... <ins>&& HasLess<UTypes, TTypes>...</ins>
20195 bool operator<=(const tuple<TTypes...>&, const tuple<UTypes...>&);
20197 template<class... TTypes, class... UTypes>
20198 requires <del>LessThanComparable</del><ins>HasLess</ins><TTypes, UTypes>... <ins>&& HasLess<UTypes, TTypes>...</ins>
20199 bool operator>=(const tuple<TTypes...>&, const tuple<UTypes...>&);
20200 </pre></blockquote>
20207 <h3><a name="929"></a>929. Thread constructor</h3>
20208 <p><b>Section:</b> 30.3.1.2 [thread.thread.constr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
20209 <b>Submitter:</b> Anthony Williams <b>Opened:</b> 2008-10-23 <b>Last modified:</b> 2009-05-23</p>
20210 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.thread.constr">active issues</a> in [thread.thread.constr].</p>
20211 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.thread.constr">issues</a> in [thread.thread.constr].</p>
20212 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
20213 <p><b>Discussion:</b></p>
20215 <p><b>Addresses UK 323</b></p>
20218 The <tt>thread</tt> constructor for starting a new thread with a function and
20219 arguments is overly constrained by the signature requiring rvalue
20220 references for <tt>func</tt> and <tt>args</tt> and the <tt>CopyConstructible</tt> requirements
20221 for the elements of <tt>args</tt>. The use of an rvalue reference for the
20222 function restricts the potential use of a plain function name, since
20223 the type of the bound parameter will be deduced to be a function
20224 reference and decay to pointer-to-function will not happen. This
20225 therefore complicates the implementation in order to handle a simple
20226 case. Furthermore, the use of rvalue references for args prevents the
20227 array to pointer decay. Since arrays are not <tt>CopyConstructible</tt> or even
20228 <tt>MoveConstructible</tt>, this essentially prevents the passing of arrays as
20229 parameters. In particular it prevents the passing of string literals.
20230 Consequently a simple case such as
20233 <blockquote><pre>void f(const char*);
20234 std::thread t(f,"hello");
20235 </pre></blockquote>
20238 is ill-formed since the type of the string literal is <tt>const char[6]</tt>.
20242 By changing the signature to take all parameters by value we can
20243 eliminate the <tt>CopyConstructible</tt> requirement and permit the use of
20244 arrays, as the parameter passing semantics will cause the necessary
20245 array-to-pointer decay. They will also cause the function name to
20246 decay to a pointer to function and allow the implementation to handle
20247 functions and function objects identically.
20251 The new signature of the <tt>thread</tt> constructor for a function and
20255 <blockquote><pre>template<typename F,typename... Args>
20256 thread(F,Args... args);
20257 </pre></blockquote>
20260 Since the parameter pack <tt>Args</tt> can be empty, the single-parameter
20261 constructor that takes just a function by value is now redundant.
20271 I agree with everything Anthony says in this issue. However I believe we
20272 can optimize in such a way as to get the pass-by-value behavior with the
20273 pass-by-rvalue-ref performance. The performance difference is that the latter
20274 removes a <tt>move</tt> when passing in an lvalue.
20278 This circumstance is very analogous to <tt>make_pair</tt> (20.3.3 [pairs])
20279 where we started with passing by const reference, changed to pass by value to
20280 get pointer decay, and then changed to pass by rvalue reference, but modified with
20281 <tt>decay<T></tt> to retain the pass-by-value behavior. If we were to
20282 apply the same solution here it would look like:
20285 <blockquote><pre><del>template <class F> explicit thread(F f);</del>
20286 template <class F, class ...Args> thread(F&& f, Args&&... args);
20290 -4- <i>Requires:</i> <tt>F</tt> and each <tt>Ti</tt> in <tt>Args</tt> shall be <del><tt>CopyConstructible</tt>
20291 if an lvalue and otherwise</del> <tt>MoveConstructible</tt>.
20292 <tt><i>INVOKE</i>(f, w1, w2, ..., wN)</tt> (20.7.2 [func.require]) shall be a valid expression for
20293 some values <tt>w1, w2, ... , wN,</tt> where <tt>N == sizeof...(Args)</tt>.
20296 -5- <i>Effects:</i> Constructs an object of type <tt>thread</tt>
20297 <del>and executes <tt><i>INVOKE</i>(f, t1, t2, ..., tN)</tt> in a new
20298 thread of execution, where <tt>t1, t2, ..., tN</tt> are the values in <tt>args...</tt></del>.
20300 the following objects in memory which is accessible to a new thread of execution
20303 <blockquote><pre><ins>typename decay<F>::type g(std::forward<F>(f));</ins>
20304 <ins>tuple<typename decay<Args>::type...> w(std::forward<Args>(args)...);</ins>
20305 </pre></blockquote>
20307 <ins>The new thread of
20308 execution executes <tt><i>INVOKE</i>(g, wi...)</tt> where the <tt>wi...</tt> refers
20309 to the elements stored in the <tt>tuple w</tt>.</ins>
20310 Any return value from <tt>g</tt> is ignored.
20311 <del>If <tt>f</tt> terminates with an uncaught exception, <tt>std::terminate()</tt> shall be called.</del>
20312 <ins>If the evaluation of <tt><i>INVOKE</i>(g, wi...)</tt> terminates
20313 with an uncaught exception, <tt>std::terminate()</tt> shall be called [<i>Note:</i>
20314 <tt>std::terminate()</tt> could be called before entering <tt>g</tt>. -- <i>end note</i>]. Any
20315 exception thrown before the evaluation of <tt><i>INVOKE</i></tt> has started shall be
20316 catchable in the calling thread.</ins>
20322 Text referring to when <tt>terminate()</tt> is called was contributed by Ganesh.
20332 We agree with the proposed resolution,
20333 but would like the final sentence to be reworded
20334 since "catchable" is not a term of art (and is used nowhere else).
20338 <p><b>Proposed resolution:</b></p>
20340 Modify the class definition of <tt>std::thread</tt> in 30.3.1 [thread.thread.class] to remove the
20341 following signature:
20344 <blockquote><pre><del>template<class F> explicit thread(F f);</del>
20345 template<class F, class ... Args> <ins>explicit</ins> thread(F&& f, Args&& ... args);
20346 </pre></blockquote>
20349 Modify 30.3.1.2 [thread.thread.constr] to replace the constructors prior to paragraph 4 with
20350 the single constructor as above. Replace paragraph 4 - 6 with the
20356 -4- <i>Requires:</i> <tt>F</tt> and each <tt>Ti</tt> in <tt>Args</tt> shall be <del><tt>CopyConstructible</tt>
20357 if an lvalue and otherwise</del> <tt>MoveConstructible</tt>.
20358 <tt><i>INVOKE</i>(f, w1, w2, ..., wN)</tt> (20.7.2 [func.require]) shall be a valid expression for
20359 some values <tt>w1, w2, ... , wN,</tt> where <tt>N == sizeof...(Args)</tt>.
20362 -5- <i>Effects:</i> Constructs an object of type <tt>thread</tt>
20363 <del>and executes <tt><i>INVOKE</i>(f, t1, t2, ..., tN)</tt> in a new
20364 thread of execution, where <tt>t1, t2, ..., tN</tt> are the values in <tt>args...</tt></del>.
20366 the following objects:</ins>
20368 <blockquote><pre><ins>typename decay<F>::type g(std::forward<F>(f));</ins>
20369 <ins>tuple<typename decay<Args>::type...> w(std::forward<Args>(args)...);</ins>
20370 </pre></blockquote>
20372 <ins>and executes <tt><i>INVOKE</i>(g, wi...)</tt> in a new thread of execution.
20373 These objects shall be destroyed when the new thread of execution completes.</ins>
20374 Any return value from <tt>g</tt> is ignored.
20375 <del>If <tt>f</tt> terminates with an uncaught exception, <tt>std::terminate()</tt> shall be called.</del>
20376 <ins>If the evaluation of <tt><i>INVOKE</i>(g, wi...)</tt> terminates
20377 with an uncaught exception, <tt>std::terminate()</tt> shall be called [<i>Note:</i>
20378 <tt>std::terminate()</tt> could be called before entering <tt>g</tt>. -- <i>end note</i>]. Any
20379 exception thrown before the evaluation of <tt><i>INVOKE</i></tt> has started shall be
20380 catchable in the calling thread.</ins>
20383 -6- <i>Synchronization:</i> The invocation of the constructor <i>happens before</i> the
20384 invocation of <del><tt>f</tt></del> <ins><tt>g</tt></ins>.
20394 <h3><a name="930"></a>930. Access to std::array data as built-in array type</h3>
20395 <p><b>Section:</b> 23.3.1 [array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
20396 <b>Submitter:</b> Niels Dekker <b>Opened:</b> 2008-11-17 <b>Last modified:</b> 2009-06-01</p>
20397 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#array">active issues</a> in [array].</p>
20398 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#array">issues</a> in [array].</p>
20399 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
20400 <p><b>Discussion:</b></p>
20403 The Working Draft (N2798) allows access to the elements of
20404 <tt>std::array</tt> by its <tt>data()</tt> member function:
20409 <h5>23.2.1.4 array::data [array.data]</h5>
20411 const T *data() const;
20419 Unfortunately, the result of <tt>std::array::data()</tt> cannot be bound
20420 to a reference to a built-in array of the type of <tt>array::elems</tt>.
20421 And <tt>std::array</tt> provides no other way to get a reference to
20422 <tt>array::elems</tt>.
20423 This hampers the use of <tt>std::array</tt>, for example when trying to
20424 pass its data to a C style API function:
20427 <pre> // Some C style API function.
20428 void set_path( char (*)[MAX_PATH] );
20430 std::array<char,MAX_PATH> path;
20431 set_path( path.data() ); // error
20432 set_path( &(path.data()) ); // error
20436 Another example, trying to pass the array data to an instance of another
20440 <pre> // Represents a 3-D point in space.
20441 class three_d_point {
20443 explicit three_d_point(const double (&)[3]);
20446 const std::array<double,3> coordinates = { 0, 1, 2 };
20447 three_d_point point1( coordinates.data() ); // error.
20448 three_d_point point2( *(coordinates.data()) ); // error.
20452 A user might be tempted to use <tt>std::array::elems</tt> instead, but
20453 doing so isn't recommended, because <tt>std::array::elems</tt> is "for
20454 exposition only". Note that Boost.Array users might already use
20455 <tt>boost::array::elems</tt>, as its documentation doesn't explicitly
20456 state that <tt>boost::array::elems</tt> is for exposition only:
20457 http://www.boost.org/doc/libs/1_36_0/doc/html/boost/array.html
20460 I can think of three options to solve this issue:
20463 Remove the words "exposition only" from the definition of
20464 <tt>std::array::elems</tt>, as well as the note saying that "elems is
20465 shown for exposition only."
20467 Change the signature of <tt>std::array::data()</tt>, so that it would
20468 return a reference to the built-in array, instead of a pointer to its
20471 Add extra member functions, returning a reference to the built-in array.
20474 Lawrence Crowl wrote me that it might be better to leave
20475 <tt>std::array::elems</tt> "for exposition only", to allow alternate
20476 representations to allocate the array data dynamically. This might be
20477 of interest to the embedded community, having to deal with very limited
20481 The second option, changing the return type of
20482 <tt>std::array::data()</tt>, would break backward compatible to current
20483 Boost and TR1 implementations, as well as to the other contiguous
20484 container (<tt>vector</tt> and <tt>string</tt>) in a very subtle way.
20485 For example, the following call to <tt>std::swap</tt> currently swap two
20486 locally declared pointers <tt>(data1, data2)</tt>, for any container
20487 type <tt>T</tt> that has a <tt>data()</tt> member function. When
20488 <tt>std::array::data()</tt> is changed to return a reference, the
20489 <tt>std::swap</tt> call may swap the container elements instead.
20492 <pre> template <typename T>
20493 void func(T& container1, T& container2)
20495 // Are data1 and data2 pointers or references?
20496 auto data1 = container1.data();
20497 auto data2 = container2.data();
20499 // Will this swap two local pointers, or all container elements?
20500 std::swap(data1, data2);
20505 The following concept is currently satisfied by all contiguous
20506 containers, but it no longer is for <tt>std::array</tt>, when
20507 <tt>array::data()</tt>
20508 is changed to return a reference (tested on ConceptGCC Alpha 7):
20511 <pre> auto concept ContiguousContainerConcept<typename T>
20513 typename value_type = typename T::value_type;
20514 const value_type * T::data() const;
20519 Still it's worth considering having <tt>std::array::data()</tt> return a
20520 reference, because it might be the most intuitive option, from a user's
20521 point of view. Nicolai Josuttis (who wrote <tt>boost::array</tt>)
20522 mailed me that he very much prefers this option.
20525 Note that for this option, the definition of <tt>data()</tt> would also
20526 need to be revised for zero-sized arrays, as its return type cannot be a
20527 reference to a zero-sized built-in array. Regarding zero-sized array,
20528 <tt>data()</tt> could throw an exception. Or there could be a partial
20529 specialization of <tt>std::array</tt> where <tt>data()</tt> returns
20530 <tt>T*</tt> or gets removed.
20533 Personally I prefer the third option, adding a new member function to
20534 <tt>std::array</tt>, overloaded for const and non-const access,
20535 returning a reference to the built-in array, to avoid those compatible
20536 issues. I'd propose naming the function <tt>std::array::c_array()</tt>,
20537 which sounds intuitive to me. Note that <tt>boost::array</tt> already
20538 has a <tt>c_array()</tt> member, returning a pointer, but Nicolai told
20539 me that this one is only there for historical reasons. (Otherwise a name
20540 like <tt>std::array::native_array()</tt> or
20541 <tt>std::array::builtin_array()</tt> would also be fine with me.)
20542 According to my proposed resolution, a zero-sized <tt>std::array</tt> does not need
20543 to have <tt>c_array()</tt>, while it is still required to have
20544 <tt>data()</tt> functions.
20555 Alisdair: Don't like p4 suggesting implementation-defined behaviour.
20558 Walter: What about an explicit conversion operator, instead of adding
20559 the new member function?
20562 Alisdair: Noodling about:
20564 <blockquote><pre>template<size_t N, ValueType T>
20569 // fantasy code starts here
20571 // crazy decltype version for grins only
20572 //requires True<(N>0)>
20573 //explict operator decltype(elems) & () { return elems; }
20575 // conversion to lvalue ref
20576 requires True<(N>0)>
20577 explict operator T(&)[N] () & { return elems; }
20579 // conversion to const lvalue ref
20580 requires True<(N>0)>
20581 explict operator const T(&)[N] () const & { return elems; }
20583 // conversion to rvalue ref using ref qualifiers
20584 requires True<(N>0)>
20585 explict operator T(&&)[N] () && { return elems; }
20587 // fantasy code ends here
20589 explicit operator bool() { return true; }
20591 </pre></blockquote>
20594 This seems legal but odd. Jason Merrill says currently a CWG issue 613
20595 on the non-static data member that fixes the error that current G++
20596 gives for the non-explicit, non-conceptualized version of this. Verdict
20597 from human compiler: seems legal.
20600 Some grumbling about zero-sized arrays being allowed and supported.
20603 Walter: Would this address the issue? Are we inclined to go this route?
20606 Alan: What would usage look like?
20608 <blockquote><pre>// 3-d point in space
20609 struct three_d_point
20611 explicit three_d_point(const double (&)[3]);
20614 void sink(double*);
20616 const std::array<double, 3> coordinates = { 0, 1, 2 };
20617 three_d_point point1( coordinates.data() ); //error
20618 three_d_point point2( *(coordinates.data()) ); // error
20619 three_d_point point3( coordinates ); // yay!
20621 sink(cooridinates); // error, no conversion
20622 </pre></blockquote>
20625 Recommended Open with new wording. Take the required clause and add the
20626 explicit conversion operators, not have a <tt>typedef</tt>. At issue still is use
20627 <tt>decltype</tt> or use <tt>T[N]</tt>. In favour of using <tt>T[N]</tt>, even though use of
20628 <tt>decltype</tt> is specially clever.
20634 Post Summit, further discussion in the thread starting with c++std-lib-23215.
20640 <p><b>Proposed resolution:</b></p>
20642 Add to the template definition of array, 23.3.1 [array]/3:
20647 typedef T c_array_type[N];
20648 c_array_type & c_array() &;
20649 c_array_type && c_array() &&;
20650 const c_array_type & c_array() const &;
20656 Add the following subsection to 23.3.1 [array], after 23.3.1.4 [array.data]:
20660 <h5><ins>23.2.1.5 array::c_array [array.c_array]</ins></h5>
20662 c_array_type & c_array() &;
20663 c_array_type && c_array() &&;
20664 const c_array_type & c_array() const &;
20668 <ins><i>Returns:</i> <tt>elems</tt>.</ins>
20675 Add to Zero sized arrays 23.3.1.6 [array.zero]:
20679 4. The presence of <tt>c_array_type</tt> and <tt>c_array()</tt> and
20680 their semantics are implementation defined, for a zero-sized array.
20688 <h3><a name="931"></a>931. type trait <tt>extent<T, I></tt></h3>
20689 <p><b>Section:</b> 20.6.4.3 [meta.unary.prop] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
20690 <b>Submitter:</b> Yechezkel Mett <b>Opened:</b> 2008-11-04 <b>Last modified:</b> 2009-03-09</p>
20691 <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>
20692 <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>
20693 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
20694 <p><b>Discussion:</b></p>
20696 The draft (N2798) says in 20.6.4.3 [meta.unary.prop] Table 44:
20700 <caption>Table 44 -- Type property queries</caption>
20701 <tbody><tr><th>Template</th><th>Value</th></tr>
20704 <tt>template <class T, unsigned I = 0> struct extent;</tt>
20707 If <tt>T</tt> is not an array type (8.3.4), or if it has rank less than
20708 <tt>I</tt>, or if <tt>I</tt> is 0
20709 and <tt>T</tt> has type "array of unknown bound of <tt>U</tt>", then 0; otherwise, the
20710 size of the <tt>I</tt>'th dimension of <tt>T</tt>
20717 Firstly it isn't clear from the wording if <tt>I</tt> is 0-based or 1-based
20718 ("the <tt>I</tt>'th dimension" sort of implies 1-based). From the following
20719 example it is clear that the intent is 0-based, in which case it
20720 should say "or if it has rank less than or equal to <tt>I</tt>".
20726 The example says <tt>assert((extent<int[2], 1>::value) == 0);</tt>
20729 Here the rank is 1 and <tt>I</tt> is 1, but the desired result is 0.
20739 Do not use "size" or "value", use "bound". Also, move the
20740 cross-reference to 8.3.4 to just after "bound".
20743 Recommend Tentatively Ready.
20749 <p><b>Proposed resolution:</b></p>
20751 In Table 44 of 20.6.4.3 [meta.unary.prop], third row, column "Value",
20752 change the cell content:
20757 <caption>Table 44 -- Type property queries</caption>
20758 <tbody><tr><th>Template</th><th>Value</th></tr>
20761 <tt>template <class T, unsigned I = 0> struct extent;</tt>
20764 If <tt>T</tt> is not an array type <del>(8.3.4)</del>, or if it has rank less than
20765 <ins> or equal to</ins> <tt>I</tt>, or if <tt>I</tt> is 0
20766 and <tt>T</tt> has type "array of unknown bound of <tt>U</tt>", then 0; otherwise, the
20767 <del>size</del> <ins>bound (8.3.4)</ins> of the <tt>I</tt>'th dimension of <tt>T</tt><ins>,
20768 where indexing of <tt>I</tt> is zero-based.</ins>
20775 Wording supplied by Daniel.
20785 <h3><a name="932"></a>932. <tt>unique_ptr(pointer p)</tt> for pointer deleter types</h3>
20786 <p><b>Section:</b> 20.8.12.2.1 [unique.ptr.single.ctor] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
20787 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2008-11-26 <b>Last modified:</b> 2009-03-12</p>
20788 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unique.ptr.single.ctor">active issues</a> in [unique.ptr.single.ctor].</p>
20789 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr.single.ctor">issues</a> in [unique.ptr.single.ctor].</p>
20790 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
20791 <p><b>Discussion:</b></p>
20793 <p><b>Addresses US 79</b></p>
20796 20.8.12.2.1 [unique.ptr.single.ctor]/5 no longer requires for <tt>D</tt>
20797 not to be a pointer type. I believe this restriction was accidently removed
20798 when we relaxed the completeness reuqirements on <tt>T</tt>. The restriction
20799 needs to be put back in. Otherwise we have a run time failure that could
20800 have been caught at compile time:
20804 unique_ptr<int, void(*)(void*)> p1(malloc(sizeof(int))); <font color="#c80000">// should not compile</font>
20805 } <font color="#c80000">// p1.~unique_ptr() dereferences a null function pointer</font>
20806 unique_ptr<int, void(*)(void*)> p2(malloc(sizeof(int)), free); <font color="#c80000">// ok</font>
20807 </pre></blockquote>
20815 Recommend Tentatively Ready.
20820 <p><b>Proposed resolution:</b></p>
20822 Change 20.8.12.2.1 [unique.ptr.single.ctor]/5:
20825 <blockquote><pre>unique_ptr(pointer p);
20828 <i>Requires:</i> <ins><tt>D</tt> shall not be a pointer type (diagnostic required).</ins>
20829 <tt>D</tt> shall be default constructible, and that construction shall not throw an exception.
20838 <h3><a name="933"></a>933. Unique_ptr defect</h3>
20839 <p><b>Section:</b> 20.8.12.2.5 [unique.ptr.single.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
20840 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-11-27 <b>Last modified:</b> 2009-05-23</p>
20841 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unique.ptr.single.modifiers">active issues</a> in [unique.ptr.single.modifiers].</p>
20842 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr.single.modifiers">issues</a> in [unique.ptr.single.modifiers].</p>
20843 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
20844 <p><b>Discussion:</b></p>
20846 If we are supporting stateful deleters, we need an overload for
20847 <tt>reset</tt> that
20848 takes a deleter as well.
20851 <blockquote><pre>void reset( pointer p, deleter_type d);
20852 </pre></blockquote>
20855 We probably need two overloads to support move-only deleters, and
20857 sounds uncomfortably like the two constructors I have been ignoring
20868 Howard comments that we have the functionality via move-assigment.
20876 <p><b>Proposed resolution:</b></p>
20885 <h3><a name="934"></a>934. <tt>duration</tt> is missing <tt>operator%</tt></h3>
20886 <p><b>Section:</b> 20.9.3 [time.duration] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
20887 <b>Submitter:</b> Terry Golubiewski <b>Opened:</b> 2008-11-30 <b>Last modified:</b> 2009-05-23</p>
20888 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
20889 <p><b>Discussion:</b></p>
20891 <p><b>Addresses US 81</b></p>
20894 <tt>duration</tt> is missing <tt>operator%</tt>. This operator is convenient
20895 for computing where in a time frame a given <tt>duration</tt> lies. A
20896 motivating example is converting a <tt>duration</tt> into a "broken-down"
20897 time duration such as hours::minutes::seconds:
20900 <blockquote><pre>class ClockTime
20902 typedef std::chrono::hours hours;
20903 typedef std::chrono::minutes minutes;
20904 typedef std::chrono::seconds seconds;
20910 template <class Rep, class Period>
20911 explicit ClockTime(const std::chrono::duration<Rep, Period>& d)
20912 : hours_ (std::chrono::duration_cast<hours> (d)),
20913 minutes_(std::chrono::duration_cast<minutes>(d % hours(1))),
20914 seconds_(std::chrono::duration_cast<seconds>(d % minutes(1)))
20917 </pre></blockquote>
20925 Agree except that there is a typo in the proposed resolution. The member
20926 operators should be operator%=.
20934 We agree with the proposed resolution.
20935 Move to Tentatively Ready.
20939 <p><b>Proposed resolution:</b></p>
20941 Add to the synopsis in 20.9 [time]:
20944 <blockquote><pre>template <class Rep1, class Period, class Rep2>
20945 duration<typename common_type<Rep1, Rep2>::type, Period>
20946 operator%(const duration<Rep1, Period>& d, const Rep2& s);
20947 template <class Rep1, class Period1, class Rep2, class Period2>
20948 typename common_type<duration<Rep1, Period1>, duration<Rep2, Period2>>::type
20949 operator%(const duration<Rep1, Period1>& lhs, const duration<Rep2, Period2>& rhs);
20950 </pre></blockquote>
20953 Add to the synopsis of <tt>duration</tt> in 20.9.3 [time.duration]:
20956 <blockquote><pre>template <class Rep, class Period = ratio<1>>
20960 <ins>duration& operator%=(const rep& rhs);</ins>
20961 <ins>duration& operator%=(const duration& d);</ins>
20964 </pre></blockquote>
20967 Add to 20.9.3.3 [time.duration.arithmetic]:
20971 <pre>duration& operator%=(const rep& rhs);
20975 <i>Effects:</i> <tt>rep_ %= rhs</tt>.
20978 <i>Returns:</i> <tt>*this</tt>.
20982 <pre>duration& operator%=(const duration& d);
20986 <i>Effects:</i> <tt>rep_ %= d.count()</tt>.
20989 <i>Returns:</i> <tt>*this</tt>.
20995 Add to 20.9.3.5 [time.duration.nonmember]:
21000 <pre>template <class Rep1, class Period, class Rep2>
21001 duration<typename common_type<Rep1, Rep2>::type, Period>
21002 operator%(const duration<Rep1, Period>& d, const Rep2& s);
21006 <i>Requires:</i> <tt>Rep2</tt> shall be implicitly convertible to <tt>CR(Rep1, Rep2)</tt> and
21007 <tt>Rep2</tt> shall not be an instantiation of <tt>duration</tt>. Diagnostic required.
21010 <i>Returns:</i> <tt>duration<CR, Period>(d) %= s</tt>.
21014 <pre>template <class Rep1, class Period1, class Rep2, class Period2>
21015 typename common_type<duration<Rep1, Period1>, duration<Rep2, Period2>>::type
21016 operator%(const duration<Rep1, Period1>& lhs, const duration<Rep2, Period2>& rhs);
21020 <i>Returns:</i> <tt>common_type<duration<Rep1, Period1>, duration<Rep2, Period2>>::type(lhs) %= rhs</tt>.
21032 <h3><a name="935"></a>935. clock error handling needs to be specified</h3>
21033 <p><b>Section:</b> 20.9.5 [time.clock] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
21034 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2008-11-24 <b>Last modified:</b> 2009-05-23</p>
21035 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
21036 <p><b>Discussion:</b></p>
21038 Each of the three clocks specified in Clocks 20.9.5 [time.clock]
21039 provides the member function:
21042 <blockquote><pre>static time_point now();
21043 </pre></blockquote>
21046 The semantics specified by Clock requirements 20.9.1 [time.clock.req]
21047 make no mention of error handling. Thus the function may throw <tt>bad_alloc</tt>
21048 or an implementation-defined exception (17.6.4.10 [res.on.exception.handling]
21053 Some implementations of these functions on POSIX, Windows, and
21054 presumably on other operating systems, may fail in ways only detectable
21055 at runtime. Some failures on Windows are due to supporting chipset
21056 errata and can even occur after successful calls to a clock's <tt>now()</tt>
21061 These functions are used in cases where exceptions are not appropriate
21062 or where the specifics of the exception or cause of error need to be
21063 available to the user. See
21064 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2828.html">N2828</a>,
21065 <i>Library Support for hybrid error
21066 handling (Rev 1)</i>, for more specific discussion of use cases. Thus some change in
21067 the interface of now is required.
21071 The proposed resolution has been implemented in the Boost version of the
21072 chrono library. No problems were encountered.
21081 We recommend this issue be deferred until the next Committee Draft
21082 has been issued and the prerequisite paper has been accepted.
21090 <p><b>Proposed resolution:</b></p>
21092 Accept the proposed wording of
21093 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2828.html">N2828</a>,
21094 <i>Library Support for hybrid error handling (Rev 1)</i>.
21098 Change Clock requirements 20.9.1 [time.clock.req] as indicated:
21103 -2- In Table 55 <tt>C1</tt> and <tt>C2</tt> denote clock types. <tt>t1</tt> and
21104 <tt>t2</tt> are values returned by <tt>C1::now()</tt> where the call
21105 returning <tt>t1</tt> happens before (1.10) the call returning <tt>t2</tt> and
21106 both of these calls happen before <tt>C1::time_point::max()</tt>.
21107 <ins><tt>ec</tt> denotes an object of type <tt>error_code</tt>
21108 (19.5.2.2 [syserr.errcode.overview]).</ins>
21112 <caption>Table 55 -- Clock requirements</caption>
21114 <th>Expression</th><th>Return type</th><th>Operational semantics</th>
21124 <td><tt>C1::now()</tt></td>
21125 <td><tt>C1::time_point</tt></td>
21126 <td>Returns a <tt>time_point</tt> object representing the current point in time.
21131 <td><tt><ins>C1::now(ec)</ins></tt></td>
21132 <td><tt><ins>C1::time_point</ins></tt></td>
21133 <td><ins>Returns a <tt>time_point</tt> object representing the current point in time.</ins>
21140 Change Class system_clock 20.9.5.1 [time.clock.system] as indicated:
21143 <blockquote><pre>static time_point now(<ins>error_code& ec=throws()</ins>);
21144 </pre></blockquote>
21147 Change Class monotonic_clock 20.9.5.2 [time.clock.monotonic] as indicated:
21150 <blockquote><pre>static time_point now(<ins>error_code& ec=throws()</ins>);
21151 </pre></blockquote>
21154 Change Class high_resolution_clock 20.9.5.3 [time.clock.hires] as indicated:
21157 <blockquote><pre>static time_point now(<ins>error_code& ec=throws()</ins>);
21158 </pre></blockquote>
21166 <h3><a name="936"></a>936. Mutex type overspecified</h3>
21167 <p><b>Section:</b> 30.4.1 [thread.mutex.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
21168 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2008-12-05 <b>Last modified:</b> 2009-03-22</p>
21169 <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>
21170 <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>
21171 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
21172 <p><b>Discussion:</b></p>
21174 30.4.1 [thread.mutex.requirements] describes the requirements for a type to be
21175 a "Mutex type". A Mutex type can be used as the template argument for
21176 the <tt>Lock</tt> type that's passed to <tt>condition_variable_any::wait</tt> (although
21177 <tt>Lock</tt> seems like the wrong name here, since <tt>Lock</tt> is given a different
21178 formal meaning in 30.4.3 [thread.lock]) and, although the WD doesn't quite say
21179 so, as the template argument for <tt>lock_guard</tt> and <tt>unique_lock</tt>.
21183 The requirements for a Mutex type include:
21188 <tt>m.lock()</tt> shall be well-formed and have [described] semantics, including a return type of <tt>void</tt>.
21191 <tt>m.try_lock()</tt> shall be well-formed and have [described] semantics, including a return type of <tt>bool</tt>.
21194 <tt>m.unlock()</tt> shall be well-formed and have [described] semantics, including a return type of <tt>void</tt>.
21199 Also, a Mutex type "shall not be copyable nor movable".
21203 The latter requirement seems completely irrelevant, and the three
21204 requirements on return types are tighter than they need to be. For
21205 example, there's no reason that <tt>lock_guard</tt> can't be instantiated with a
21206 type that's copyable. The rule is, in fact, that <tt>lock_guard</tt>, etc. won't
21207 try to copy objects of that type. That's a constraint on locks, not on
21208 mutexes. Similarly, the requirements for <tt>void</tt> return types are
21209 unnecessary; the rule is, in fact, that <tt>lock_guard</tt>, etc. won't use any
21210 returned value. And with the return type of <tt>bool</tt>, the requirement should
21211 be that the return type is convertible to <tt>bool</tt>.
21221 Move to open. Related to conceptualization and should probably be tackled as part of that.
21225 The intention is not only to place a constraint on what types such as
21226 <tt>lock_guard</tt> may do with mutex types, but on what any code, including user
21227 code, may do with mutex types. Thus the constraints as they are apply to
21228 the mutex types themselves, not the current users of mutex types in the
21232 This is a low priority issue; the wording as it is may be overly
21233 restrictive but this may not be a real issue.
21239 Post Summit Anthony adds:
21245 Section 30.4.1 [thread.mutex.requirements] conflates the
21246 requirements on a generic Mutex type (including user-supplied mutexes)
21247 with the requirements placed on the standard-supplied mutex types in an
21248 attempt to group everything together and save space.
21251 When applying concepts to chapter 30, I suggest that the concepts
21252 <tt>Lockable</tt> and <tt>TimedLockable</tt> embody the requirements for
21253 *use* of a mutex type as required by
21254 <tt>unique_lock/lock_guard/condition_variable_any</tt>. These should be
21255 relaxed as Pete describes in the issue. The existing words in 30.4.1 [thread.mutex.requirements] are requirements on all of
21256 <tt>std::mutex</tt>, <tt>std::timed_mutex</tt>,
21257 <tt>std::recursive_mutex</tt> and <tt>std::recursive_timed_mutex</tt>,
21258 and should be rephrased as such.
21264 <p><b>Proposed resolution:</b></p>
21273 <h3><a name="938"></a>938. <tt>default_delete<T[]>::operator()</tt> should only accept <tt>T*</tt></h3>
21274 <p><b>Section:</b> 20.8.12.1.2 [unique.ptr.dltr.dflt1] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
21275 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2008-12-07 <b>Last modified:</b> 2009-05-23</p>
21276 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
21277 <p><b>Discussion:</b></p>
21282 <blockquote><pre>derived* p = new derived[3];
21283 std::default_delete<base[]> d;
21284 d(p); <font color="#c80000">// should fail</font>
21285 </pre></blockquote>
21288 Currently the marked line is a run time failure. We can make it a compile
21289 time failure by "poisoning" <tt>op(U*)</tt>.
21306 We agree with the proposed resolution.
21307 Move to Tentatively Ready.
21311 <p><b>Proposed resolution:</b></p>
21313 Add to 20.8.12.1.2 [unique.ptr.dltr.dflt1]:
21316 <blockquote><pre>namespace std {
21317 template <class T> struct default_delete<T[]> {
21318 void operator()(T*) const;
21319 <ins>template <class U> void operator()(U*) const = delete;</ins>
21322 </pre></blockquote>
21329 <h3><a name="939"></a>939. Problem with <tt>std::identity</tt> and reference-to-temporaries</h3>
21330 <p><b>Section:</b> 20.7.6 [identity.operation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
21331 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-12-11 <b>Last modified:</b> 2009-06-02</p>
21332 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
21333 <p><b>Discussion:</b></p>
21335 <tt>std::identity</tt> takes an argument of type <tt>T const &</tt>
21336 and returns a result of <tt>T const &</tt>.
21339 Unfortunately, this signature will accept a value of type other than <tt>T</tt> that
21340 is convertible-to-<tt>T</tt>, and then return a reference to the dead temporary. The
21341 constraint in the concepts version simply protects against returning
21342 reference-to-<tt>void</tt>.
21349 i/ Return-by-value, potentially slicing bases and rejecting non-copyable
21353 ii/ Provide an additional overload:
21355 <blockquote><pre>template< typename T >
21356 template operator( U & ) = delete;
21357 </pre></blockquote>
21359 This seems closer on intent, but moves beyond the original motivation for
21360 the operator, which is compatibility with existing (non-standard)
21364 iii/ Remove the <tt>operator()</tt> overload. This restores the original definition
21365 of the <tt>identity</tt>, although now effectively a type_trait rather than part of
21366 the perfect forwarding protocol.
21369 iv/ Remove <tt>std::identity</tt> completely; its original reason to exist is
21370 replaced with the <tt>IdentityOf</tt> concept.
21374 My own preference is somewhere between (ii) and (iii) - although I stumbled
21375 over the issue with a specific application hoping for resolution (i)!
21384 We dislike options i and iii, and option ii seems like overkill.
21385 If we remove it (option iv), implementers can still provide it under a
21389 Move to Open pending wording (from Alisdair) for option iv.
21394 2009-05-23 Alisdair provided wording for option iv.
21400 <p><b>Proposed resolution:</b></p>
21402 Strike 20.2.1 [concept.transform] p3:
21406 <del>-4- <i>Note:</i> concept form of the identity type metafunction (20.7.6).</del>
21410 Strike from 20.7 [function.objects] p2:
21413 <blockquote><pre><del>// 20.7.6, identity operation:</del>
21414 <del>template <IdentityOf T> struct identity;</del>
21415 </pre></blockquote>
21418 Remove 20.7.6 [identity.operation] (whole subclause):
21422 <pre><del>template <IdentityOf T> struct identity {
21425 requires ReferentType<T>
21426 const T& operator()(const T& x) const;
21429 <del>requires ReferentType<T>
21430 const T& operator()(const T& x) const;</del>
21433 <del>-1- <i>Returns:</i> <tt>x</tt></del>
21443 <h3><a name="940"></a>940. <tt>std::distance</tt></h3>
21444 <p><b>Section:</b> 24.4 [iterator.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
21445 <b>Submitter:</b> Thomas <b>Opened:</b> 2008-12-14 <b>Last modified:</b> 2009-05-23</p>
21446 <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>
21447 <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>
21448 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
21449 <p><b>Discussion:</b></p>
21451 <p><b>Addresses UK 270</b></p>
21454 Regarding the <tt>std::distance</tt> - function, 24.4 [iterator.operations]
21459 number of increments or decrements needed to get from first to last.
21462 This sentence is completely silent about the sign of the return value.
21463 24.4 [iterator.operations] / 1 gives more information about the
21464 underlying operations, but
21465 again no inferences about the sign can be made.
21466 Strictly speaking, that is taking that sentence literally, I think this
21467 sentence even implies a positive return value in all cases, as the
21468 number of increments or decrements is clearly a ratio scale variable,
21469 with a natural zero bound.
21472 Practically speaking, my implementations did what common sense and
21473 knowledge based on pointer arithmetic forecasts, namely a positive sign
21474 for increments (that is, going from <tt>first</tt> to <tt>last</tt> by <tt>operator++</tt>), and a
21475 negative sign for decrements (going from <tt>first</tt> to <tt>last</tt> by <tt>operator--</tt>).
21478 Here are my two questions:
21481 First, is that paragraph supposed to be interpreted in the way what I
21482 called 'common sense', that is negative sign for decrements ? I am
21483 fairly sure that's the supposed behavior, but a double-check here in
21484 this group can't hurt.
21487 Second, is the present wording (2003 standard version - no idea about
21488 the draft for the upcoming standard) worth an edit to make it a bit more
21489 sensible, to mention the sign of the return value explicitly ?
21499 My first thought was that resolution <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#204">204</a> would already cover the
21500 issue report, but it seems that current normative wording is in
21501 contradiction to that resolution:
21506 <a href="" ref="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdf">N2798</a>,
21507 24.4 [iterator.operations]/ p.4 says:
21511 <i>Effects:</i> Returns the number of increments or decrements needed to get
21512 from <tt>first</tt> to <tt>last</tt>.
21516 IMO the part " or decrements" is in contradiction to p. 5 which says
21520 <i>Requires:</i> <tt>last</tt> shall be reachable from <tt>first</tt>.
21524 because "reachable" is defined in 24.2 [iterator.concepts]/7 as
21528 An iterator <tt>j</tt> is called reachable from an iterator <tt>i</tt> if and only if
21530 sequence of applications of the expression <tt>++i</tt> that makes <tt>i == j</tt>.[..]
21534 Here is wording that would be consistent with this definition of "reachable":
21538 Change 24.4 [iterator.operations] p4 as follows:
21542 <i>Effects:</i> Returns the number of increments <del>or decrements</del>
21543 needed to get from <tt>first</tt> to <tt>last</tt>.
21549 Thomas adds more discussion and an alternative view point
21550 <a href="http://groups.google.com/group/comp.std.c++/browse_thread/thread/e8e46dcda0a5d797#">here</a>.
21559 The proposed wording below was verbally agreed to. Howard provided.
21568 Pete reports that a recent similar change has been made
21569 for the <tt>advance()</tt> function.
21572 We agree with the proposed resolution.
21573 Move to Tentatively Ready.
21578 <p><b>Proposed resolution:</b></p>
21580 Change 24.4 [iterator.operations]:
21584 <pre>template <InputIterator Iter>
21585 Iter::difference_type
21586 distance(Iter first, Iter last);
21587 <del>template <RandomAccessIterator Iter>
21588 Iter::difference_type distance(Iter first, Iter last);</del>
21593 -4- <i>Effects:</i> Returns the number of increments <del>or decrements</del>
21594 needed to get from <tt>first</tt> to <tt>last</tt>.
21597 -5- <i>Requires:</i> <tt>last</tt> shall be reachable from <tt>first</tt>.
21601 <pre><ins>template <RandomAccessIterator Iter>
21602 Iter::difference_type distance(Iter first, Iter last);</ins>
21607 <ins>-6- <i>Effects:</i> Returns the number of increments or decrements
21608 needed to get from <tt>first</tt> to <tt>last</tt>.</ins>
21611 <ins>-7- <i>Requires:</i> <tt>last</tt> shall be reachable from <tt>first</tt>
21612 or <tt>first</tt> shall be reachable from <tt>last</tt>.</ins>
21625 <h3><a name="941"></a>941. Ref-qualifiers for assignment operators</h3>
21626 <p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
21627 <b>Submitter:</b> Niels Dekker <b>Opened:</b> 2008-12-18 <b>Last modified:</b> 2009-05-23</p>
21628 <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>
21629 <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>
21630 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
21631 <p><b>Discussion:</b></p>
21633 The assignment and equality operators <tt>=</tt> and <tt>==</tt> are easily confused, just
21634 because of their visual similarity, and in this case a simple typo can cause
21635 a serious bug. When the left side of an <tt>operator=</tt> is an rvalue, it's
21636 highly unlikely that the assignment was intended by the programmer:
21638 <blockquote><pre>if ( func() = value ) // Typical typo: == intended!
21639 </pre></blockquote>
21641 Built-in types don't support assignment to an rvalue, but unfortunately,
21642 a lot of types provided by the Standard Library do.
21645 Fortunately the language now offers a syntax to prevent a certain member
21646 function from having an rvalue as <tt>*this</tt>: by adding a ref-qualifier (<tt>&</tt>)
21647 to the member function declaration. Assignment operators are explicitly
21648 mentioned as a use case of ref-qualifiers, in "Extending Move Semantics
21649 To <tt>*this</tt> (Revision 1)",
21650 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1821.htm">N1821</a> by Daveed
21651 Vandevoorde and Bronek Kozicki
21654 Hereby I would like to propose adding ref-qualifiers to all appropriate
21655 assignment operators in the library.
21664 We recommend this be deferred until after the next Committee Draft.
21668 <p><b>Proposed resolution:</b></p>
21670 A proposed resolution is provided by the paper on this subject,
21671 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2819.html">N2819</a>,
21672 <i>Ref-qualifiers for assignment operators of the Standard Library</i>
21680 <h3><a name="943"></a>943. <tt>ssize_t</tt> undefined</h3>
21681 <p><b>Section:</b> 29.5.2 [atomics.types.address] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
21682 <b>Submitter:</b> Holger Grund <b>Opened:</b> 2008-12-19 <b>Last modified:</b> 2009-05-23</p>
21683 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
21684 <p><b>Discussion:</b></p>
21686 There is a row in "Table 122 - Atomics for standard typedef types"
21687 in 29.5.1 [atomics.types.integral] with <tt>atomic_ssize_t</tt>
21688 and <tt>ssize_t</tt>. Unless, I'm missing something <tt>ssize_t</tt>
21689 is not defined by the standard.
21698 Move to review. Proposed resolution: Remove the typedef. Note: ssize_t
21707 We agree with the proposed resolution.
21708 Move to Tentatively Ready.
21712 <p><b>Proposed resolution:</b></p>
21714 Remove the row containing <tt>ssize_t</tt> from Table 119
21715 "Atomics for standard typedef types" in 29.5.2 [atomics.types.address].
21723 <h3><a name="944"></a>944. <tt>atomic<bool></tt> derive from <tt>atomic_bool</tt>?</h3>
21724 <p><b>Section:</b> 29.5.3 [atomics.types.generic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
21725 <b>Submitter:</b> Holger Grund <b>Opened:</b> 2008-12-19 <b>Last modified:</b> 2009-03-22</p>
21726 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types.generic">issues</a> in [atomics.types.generic].</p>
21727 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
21728 <p><b>Discussion:</b></p>
21730 I think it's fairly obvious that <tt>atomic<bool></tt> is supposed to be derived
21731 from <tt>atomic_bool</tt> (and otherwise follow the <tt>atomic<integral></tt> interface),
21732 though I think the current wording doesn't support this. I raised this
21733 point along with <tt>atomic<floating-point></tt> privately with Herb and I seem
21734 to recall it came up in the resulting discussion on this list. However,
21735 I don't see anything on the current libs issue list mentioning this
21740 29.5.3 [atomics.types.generic]/3 reads
21744 There are full specializations over the integral types on the atomic
21745 class template. For each integral type integral in the second column of
21746 table 121 or table 122, the specialization <tt>atomic<integral></tt> shall be
21747 publicly derived from the corresponding atomic integral type in the
21748 first column of the table. These specializations shall have trivial
21749 default constructors and trivial destructors.
21753 Table 121 does not include (<tt>atomic_bool</tt>, <tt>bool</tt>),
21754 so that this should probably be mentioned explicitly in the quoted paragraph.
21763 Move to open. Lawrence will draft a proposed resolution. Also, ask
21764 Howard to fix the title.
21768 Post Summit Anthony provided proposed wording.
21773 <p><b>Proposed resolution:</b></p>
21775 Replace paragraph 3 in 29.5.3 [atomics.types.generic] with
21779 -3- There are full specializations over the integral types on the <tt>atomic</tt>
21780 class template. For each integral type <tt>integral</tt> in the second column of
21781 table 121 or table 122, the specialization <tt>atomic<integral></tt> shall be
21782 publicly derived from the corresponding atomic integral type in the first
21783 column of the table.
21784 <ins>In addition, the specialization <tt>atomic<bool></tt>
21785 shall be publicly derived from <tt>atomic_bool</tt>.</ins>
21786 These specializations shall have trivial default
21787 constructors and trivial destructors.
21795 <h3><a name="945"></a>945. <tt>system_clock::rep</tt> not specified</h3>
21796 <p><b>Section:</b> 20.9.5.1 [time.clock.system] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Tentatively NAD Editorial</a>
21797 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2008-12-19 <b>Last modified:</b> 2009-05-23</p>
21798 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#time.clock.system">active issues</a> in [time.clock.system].</p>
21799 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.clock.system">issues</a> in [time.clock.system].</p>
21800 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD%20Editorial">Tentatively NAD Editorial</a> status.</p>
21801 <p><b>Discussion:</b></p>
21803 In 20.9.5.1 [time.clock.system], the declaration of <tt>system_clock::rep</tt> says "see
21804 below", but there is nothing below that describes it.
21814 This note refers to:
21818 -2- <tt>system_clock::duration::min() < system_clock::duration::zero()</tt> shall be <tt>true</tt>.
21822 I.e. this is standardeze for "<tt>system_clock::rep</tt> is signed".
21823 Perhaps an editorial note along the lines of:
21827 -2- <tt>system_clock::duration::min() < system_clock::duration::zero()</tt>
21828 shall be <tt>true</tt>. <ins>[<i>Note:</i> <tt>system_clock::rep</tt> shall be signed. <i>-- end note</i>].</ins>
21842 We agree with the direction of the proposed resolution.
21843 Move to NAD Editorial.
21848 <p><b>Proposed resolution:</b></p>
21850 Add a note to 20.9.5.1 [time.clock.system], p2:
21853 -2- <tt>system_clock::duration::min() < system_clock::duration::zero()</tt>
21854 shall be <tt>true</tt>. <ins>[<i>Note:</i> <tt>system_clock::rep</tt> shall be signed. <i>-- end note</i>].</ins>
21862 <h3><a name="946"></a>946. <tt>duration_cast</tt> improperly specified</h3>
21863 <p><b>Section:</b> 20.9.3.7 [time.duration.cast] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">Tentatively NAD</a>
21864 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2008-12-20 <b>Last modified:</b> 2009-05-23</p>
21865 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#time.duration.cast">active issues</a> in [time.duration.cast].</p>
21866 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.duration.cast">issues</a> in [time.duration.cast].</p>
21867 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD">Tentatively NAD</a> status.</p>
21868 <p><b>Discussion:</b></p>
21869 20.9.3.7 [time.duration.cast]/3:
21872 .... All intermediate computations shall be
21873 carried out in the widest possible representation... .
21878 floating-point types for the moment, all this arithmetic has to be done
21879 using the implementation's largest integral type, even if both arguments
21880 use int for their representation. This seems excessive. And it's not at
21881 all clear what this means if we don't ignore floating-point types.
21885 This issue is related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#952">952</a>.
21895 The intent of this remark is that intermediate computations are carried out
21899 <blockquote><pre>common_type<typename ToDuration::rep, Rep, intmax_t>::type
21900 </pre></blockquote>
21903 The Remark was intended to be clarifying prose supporting the rather algorithmic description
21904 of the previous paragraph. I'm open to suggestions. Perhaps the entire paragraph
21905 3 (Remarks) would be better dropped?
21915 We view this as a specific case of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#952">952</a>,
21916 and should be resolved when that issue is resolved.
21925 <p><b>Proposed resolution:</b></p>
21934 <h3><a name="947"></a>947. duration arithmetic: contradictory requirements</h3>
21935 <p><b>Section:</b> 20.9.3.5 [time.duration.nonmember] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
21936 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2008-12-20 <b>Last modified:</b> 2009-05-23</p>
21937 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.duration.nonmember">issues</a> in [time.duration.nonmember].</p>
21938 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
21939 <p><b>Discussion:</b></p>
21941 In 20.9.3.5 [time.duration.nonmember], paragraph 8 says that calling
21943 when <tt>rep</tt> is an instantiation of <tt>duration</tt> requires a diagnostic.
21944 That's followed by an <tt>operator/</tt> that takes two durations.
21945 So <tt>dur1 / dur2</tt> is legal under the second version,
21946 but requires a diagnostic under the first.
21955 Please see the thread starting with c++std-lib-22980 for more information.
21963 Move to Open, pending proposed wording (and preferably an implementation).
21967 <p><b>Proposed resolution:</b></p>
21976 <h3><a name="948"></a>948. <tt>ratio</tt> arithmetic tweak</h3>
21977 <p><b>Section:</b> 20.4.2 [ratio.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
21978 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2008-12-26 <b>Last modified:</b> 2009-03-09</p>
21979 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#ratio.arithmetic">active issues</a> in [ratio.arithmetic].</p>
21980 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ratio.arithmetic">issues</a> in [ratio.arithmetic].</p>
21981 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
21982 <p><b>Discussion:</b></p>
21984 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2800.pdf">N2800</a>,
21985 20.4.2 [ratio.arithmetic] lacks a paragraph from the proposal
21986 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2661.htm">N2661</a>:
21990 <p><b>ratio arithmetic [ratio.arithmetic]</b></p>
21993 ... If the implementation is unable to form the indicated <tt>ratio</tt> due to
21994 overflow, a diagnostic shall be issued.
21999 The lack of a diagnostic on compile-time overflow is a significant lack of
22000 functionality. This paragraph could be put back into the WP simply editorially.
22001 However in forming this issue I realized that we can do better than that. This
22002 paragraph should also allow alternative formulations which go to extra lengths
22003 to avoid overflow when possible. I.e. we should not mandate overflow when the
22004 implementation can avoid it.
22012 <pre>template <class R1, class R2> struct ratio_multiply {
22013 typedef <i>see below</i>} type;
22017 The nested typedef type shall be a synonym for <tt>ratio<T1, T2></tt> where
22018 <tt>T1</tt> has the value <tt>R1::num * R2::num</tt> and <tt>T2</tt> has the
22019 value <tt>R1::den * R2::den</tt>.
22025 Consider the case where <tt>intmax_t</tt> is a 64 bit 2's complement signed integer,
22029 <blockquote><pre>typedef std::ratio<0x7FFFFFFFFFFFFFFF, 0x7FFFFFFFFFFFFFF0> R1;
22030 typedef std::ratio<8, 7> R2;
22031 typedef std::ratio_multiply<R1, R2>::type RT;
22032 </pre></blockquote>
22035 According to the present formulation the implementaiton will multiply
22036 <tt>0x7FFFFFFFFFFFFFFF * 8</tt> which will result in an overflow and subsequently
22037 require a diagnostic.
22041 However if the implementation is first allowed to divde <tt>0x7FFFFFFFFFFFFFFF</tt>
22042 by <tt>7</tt> obtaining <tt>0x1249249249249249 / 1</tt> and divide
22043 <tt>8</tt> by <tt>0x7FFFFFFFFFFFFFF0</tt> obtaining <tt>1 / 0x0FFFFFFFFFFFFFFE</tt>,
22044 then the exact result can then be computed without overflow:
22047 <blockquote><pre>[0x7FFFFFFFFFFFFFFF/0x7FFFFFFFFFFFFFF0] * [8/7] = [0x1249249249249249/0x0FFFFFFFFFFFFFFE]
22048 </pre></blockquote>
22051 Example implmentation which accomplishes this:
22054 <blockquote><pre>template <class R1, class R2>
22055 struct ratio_multiply
22058 typedef ratio<R1::num, R2::den> _R3;
22059 typedef ratio<R2::num, R1::den> _R4;
22061 typedef ratio<__ll_mul<_R3::num, _R4::num>::value,
22062 __ll_mul<_R3::den, _R4::den>::value> type;
22064 </pre></blockquote>
22072 Recommend Tentatively Ready.
22078 <p><b>Proposed resolution:</b></p>
22080 Add a paragraph prior to p1 in 20.4.2 [ratio.arithmetic]:
22084 Implementations may use other algorithms to compute the indicated ratios to avoid overflow.
22085 If overflow occurs, a diagnostic shall be issued.
22093 <h3><a name="949"></a>949. <tt>owner_less</tt></h3>
22094 <p><b>Section:</b> 20.8.13.4 [util.smartptr.ownerless] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
22095 <b>Submitter:</b> Thomas Plum <b>Opened:</b> 2008-12-30 <b>Last modified:</b> 2009-03-10</p>
22096 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
22097 <p><b>Discussion:</b></p>
22099 20.8.13.4 [util.smartptr.ownerless] (class template <tt>owner_less</tt>) says that
22100 <tt>operator()(x,y)</tt> shall return <tt>x.before(y)</tt>.
22103 However, <tt>shared_ptr</tt> and <tt>weak_ptr</tt> have an <tt>owner_before()</tt> but not a
22104 <tt>before()</tt>, and there's no base class to provide a missing <tt>before()</tt>.
22107 Being that the class is named <tt>owner_less</tt> , I'm guessing that
22108 "<tt>before()</tt>" should be "<tt>owner_before()</tt>", right?
22117 Agreed with the typo, it should be "shall return <tt>x.owner_before(y)</tt>".
22126 Recommend Tentatively Ready.
22131 <p><b>Proposed resolution:</b></p>
22133 Change 20.8.13.4 [util.smartptr.ownerless] p2:
22137 -2- <tt>operator()(x,y)</tt> shall return
22138 <tt>x.<ins>owner_</ins>before(y)</tt>. [<i>Note:</i> ...
22146 <h3><a name="950"></a>950. unique_ptr converting ctor shouldn't accept array form</h3>
22147 <p><b>Section:</b> 20.8.12.2.1 [unique.ptr.single.ctor] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
22148 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2009-05-23</p>
22149 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unique.ptr.single.ctor">active issues</a> in [unique.ptr.single.ctor].</p>
22150 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr.single.ctor">issues</a> in [unique.ptr.single.ctor].</p>
22151 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
22152 <p><b>Discussion:</b></p>
22154 <tt>unique_ptr</tt>'s of array type should not convert to
22155 <tt>unique_ptr</tt>'s which do not have an array type.
22158 <blockquote><pre>struct Deleter
22160 void operator()(void*) {}
22165 unique_ptr<int[], Deleter> s;
22166 unique_ptr<int, Deleter> s2(std::move(s)); <font color="#c80000">// should not compile</font>
22168 </pre></blockquote>
22177 Walter: Does the "diagnostic required" apply to both arms of the "and"?
22180 Tom Plum: suggest to break into several sentences
22183 Walter: suggest "comma" before the "and" in both places
22195 The post-Summit comments have been applied to the proposed resolution.
22196 We now agree with the proposed resolution.
22197 Move to Tentatively Ready.
22201 <p><b>Proposed resolution:</b></p>
22203 Change 20.8.12.2.1 [unique.ptr.single.ctor]:
22207 <pre>template <class U, class E> unique_ptr(unique_ptr<U, E>&& u);
22211 -20- <i>Requires:</i> If <tt>D</tt> is not a reference type,
22212 construction of the deleter <tt>D</tt> from an rvalue of type <tt>E</tt>
22213 shall be well formed and shall not throw an exception. If <tt>D</tt> is
22214 a reference type, then <tt>E</tt> shall be the same type as <tt>D</tt>
22215 (diagnostic required). <tt>unique_ptr<U, E>::pointer</tt> shall be
22216 implicitly convertible to <tt>pointer</tt> <ins>(diagnostic required). <tt>U</tt> shall not be
22217 an array type (diagnostic required)</ins>. [<i>Note:</i> These requirements
22218 imply that <tt>T</tt> and <tt>U</tt> are complete types. -- <i>end note</i>]
22224 Change 20.8.12.2.3 [unique.ptr.single.asgn]:
22228 <pre>template <class U, class E> unique_ptr& operator=(unique_ptr<U, E>&& u);
22232 -6- <i>Requires:</i> Assignment of the deleter <tt>D</tt> from an rvalue
22233 <tt>D</tt> shall not throw an exception. <tt>unique_ptr<U,
22234 E>::pointer</tt> shall be implicitly convertible to <tt>pointer</tt>
22235 <ins>(diagnostic required). <tt>U</tt> shall not be an array type (diagnostic required)</ins>.
22236 [<i>Note:</i> These requirements imply that <tt>T</tt> and <tt>U</tt>
22237 are complete types. -- <i>end note</i>]
22248 <h3><a name="951"></a>951. Various threading bugs #1</h3>
22249 <p><b>Section:</b> 20.9.2.1 [time.traits.is_fp] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
22250 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2009-05-23</p>
22251 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
22252 <p><b>Discussion:</b></p>
22255 Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#953">953</a>.
22259 20.9.2.1 [time.traits.is_fp] says that the type <tt>Rep</tt> "is
22260 assumed to be ... a class emulating an integral type." What are the
22261 requirements for such a type?
22264 2009-05-10 Howard adds:
22269 <tt>IntegralLike</tt>.
22278 As with issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#953">953</a>,
22279 we recommend this issue be addressed in the context of providing concepts for the entire <tt>thread</tt> header.
22282 We look forward to proposed wording.
22290 <p><b>Proposed resolution:</b></p>
22299 <h3><a name="952"></a>952. Various threading bugs #2</h3>
22300 <p><b>Section:</b> 20.9.3.7 [time.duration.cast] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Tentatively NAD Editorial</a>
22301 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2009-05-23</p>
22302 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#time.duration.cast">active issues</a> in [time.duration.cast].</p>
22303 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.duration.cast">issues</a> in [time.duration.cast].</p>
22304 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD%20Editorial">Tentatively NAD Editorial</a> status.</p>
22305 <p><b>Discussion:</b></p>
22307 20.9.3.7 [time.duration.cast] specifies an implementation and imposes
22308 requirements in text (and the implementation doesn't satisfy all of the
22309 text requirements). Pick one.
22313 This issue is related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#946">946</a>.
22317 2009-05-10 Howard adds:
22323 The <i>Remarks</i> paragraph is an English re-statement of the preceeding
22324 <i>Returns</i> clause. It was meant to be clarifying and motivating, not
22325 confusing. I'm not aware with how the <i>Remarks</i> contradicts the <i>Returns</i> clause
22326 but I'm ok with simply removing the <i>Remarks</i>.
22336 Pete suggests that this could be resolved
22337 by rephrasing the Remarks to Notes.
22340 Move to NAD Editorial.
22345 <p><b>Proposed resolution:</b></p>
22354 <h3><a name="953"></a>953. Various threading bugs #3</h3>
22355 <p><b>Section:</b> 20.9.1 [time.clock.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
22356 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2009-05-23</p>
22357 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#time.clock.req">active issues</a> in [time.clock.req].</p>
22358 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.clock.req">issues</a> in [time.clock.req].</p>
22359 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
22360 <p><b>Discussion:</b></p>
22363 Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#951">951</a>.
22367 20.9.1 [time.clock.req] says that a clock's <tt>rep</tt> member is "an
22368 arithmetic type or a class emulating an arithmetic type." What are the
22369 requirements for such a type?
22373 2009-05-10 Howard adds:
22378 This wording was aimed directly at the <tt>ArithmeticLike</tt> concept.
22387 We recommend this issue be addressed in the context of providing concepts
22388 for the entire <tt>thread</tt> header.
22391 May resolve for now by specifying arithmetic types,
22392 and in future change to <tt>ArithmeticLike</tt>.
22393 However, Alisdair believes this is not feasible.
22399 We look forward to proposed wording. Move to Open.
22404 <p><b>Proposed resolution:</b></p>
22413 <h3><a name="954"></a>954. Various threading bugs #4</h3>
22414 <p><b>Section:</b> 20.9.1 [time.clock.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
22415 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2009-05-30</p>
22416 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#time.clock.req">active issues</a> in [time.clock.req].</p>
22417 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.clock.req">issues</a> in [time.clock.req].</p>
22418 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
22419 <p><b>Discussion:</b></p>
22421 Table 55 -- Clock Requirements (in 20.9.1 [time.clock.req])
22426 the requirements for <tt>C1::time_point</tt> require <tt>C1</tt> and <tt>C2</tt>
22427 to "refer to the same epoch", but "epoch" is not defined.
22430 "Different clocks may share a <tt>time_point</tt> definition if it is
22431 valid to compare their <tt>time_point</tt>s by comparing their
22432 respective <tt>duration</tt>s." What does "valid" mean here? And, since
22433 <tt>C1::rep</tt> is "**THE** representation type of the native
22434 <tt>duration</tt> and <tt>time_point</tt>" (emphasis added), there
22435 doesn't seem to be much room for some other representation.
22438 <tt>C1::is_monotonic</tt> has type "<tt>const bool</tt>". The
22439 "<tt>const</tt>" should be removed.
22442 <tt>C1::period</tt> has type <tt>ratio</tt>. <tt>ratio</tt> isn't a type,
22443 it's a template. What is the required type?
22448 2009-05-10 Howard adds:
22455 "epoch" is purposefully not defined beyond the common English
22456 <a href="http://www.dictionary.net/epoch">definition</a>. The C standard
22457 also chose not to define epoch, though POSIX did. I believe it is a strength
22458 of the C standard that epoch is not defined. When it is known that two <tt>time_point</tt>s
22459 refer to the same epoch, then a definition of the epoch is not needed to compare
22460 the two <tt>time_point</tt>s, or subtract them.
22463 A <tt>time_point</tt> and a <tt>Clock</tt> implicitly refer to an (unspecified) epoch.
22464 The <tt>time_point</tt> represents an offset (<tt>duration</tt>) from an epoch.
22473 may share a <tt>time_point</tt>
22474 definition if it is valid to
22475 compare their <tt>time_point</tt>s by
22476 comparing their respective
22477 <tt>duration</tt>s.
22481 is redundant and could be removed. I believe the sentence which follows the above:
22485 <tt>C1</tt> and <tt>C2</tt> shall refer to the same epoch.
22489 is sufficient. If two clocks share the same epoch, then by definition, comparing
22490 their <tt>time_point</tt>s is valid.
22494 <tt>is_monotonic</tt> is meant to never change (be <tt>const</tt>). It is also
22495 desired that this value be usable in compile-time computation and branching.
22499 This should probably instead be worded:
22502 An instantiation of <tt>ratio</tt>.
22513 Re (a): It is not clear to us whether "epoch" is a term of art.
22516 Re (b), (c), and (d): We agree with Howard's comments,
22517 and would consider adding to (c) a <tt>static constexpr</tt> requirement.
22520 Move to Open pending proposed wording.
22525 2009-05-25 Daniel adds:
22530 In regards to (d) I suggest to say "a specialization of ratio" instead of
22531 "An instantiation of ratio". This seems to be the better matching standard
22532 core language term for this kind of entity.
22536 2009-05-25 Ganesh adds:
22542 Regarding (a), I found this paper on the ISO website using the term "epoch" consistently with the current wording:
22546 <a href="http://standards.iso.org/ittf/PubliclyAvailableStandards/C030811e_FILES/MAIN_C030811e/text/ISOIEC_18026E_TEMPORAL_CS.HTM">http://standards.iso.org/ittf/PubliclyAvailableStandards/C030811e_FILES/MAIN_C030811e/text/ISOIEC_18026E_TEMPORAL_CS.HTM</a>
22549 which is part of ISO/IEC 18026 "Information technology -- Spatial Reference Model (SRM)".
22556 <p><b>Proposed resolution:</b></p>
22560 Change 20.9.1 [time.clock.req] p1:
22563 -1- A clock is a bundle consisting of a native <tt>duration</tt>, a native <tt>time_point</tt>, and a function <tt>now()</tt> to get the
22564 current <tt>time_point</tt>. <ins>The origin of the clock's <tt>time_point</tt> is referred to as the clock's <i>epoch</i> as defined in
22565 section 6.3 of ISO/IEC 18026.</ins>
22566 A clock shall meet the requirements in Table 45.
22571 Remove the sentence from the <tt>time_point</tt> row of the table "Clock Requirements":
22574 <caption>Clock requirements</caption>
22577 <tt>C1::time_point</tt>
22580 <tt>chrono::time_point<C1></tt> or <tt>chrono::time_point<C2, C1::duration></tt>
22583 The native <tt>time_point</tt> type of the clock.
22584 <del>Different clocks may share a <tt>time_point</tt> definition if it is valid to compare their <tt>time_point</tt>s by comparing their respective <tt>duration</tt>s.</del>
22585 <tt>C1</tt> and <tt>C2</tt> shall refer to the same epoch.
22591 <ol start="4" type="a">
22594 Change the row starting with <tt>C1::period</tt> of the table "Clock Requirements":
22597 <caption>Clock requirements</caption>
22600 <tt>C1::period</tt>
22603 <ins>a specialization of</ins> <tt>ratio</tt>
22606 The tick period of the clock in seconds.
22619 <h3><a name="955"></a>955. Various threading bugs #5</h3>
22620 <p><b>Section:</b> 20.9.1 [time.clock.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
22621 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2009-06-07</p>
22622 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#time.clock.req">active issues</a> in [time.clock.req].</p>
22623 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.clock.req">issues</a> in [time.clock.req].</p>
22624 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
22625 <p><b>Discussion:</b></p>
22627 20.9.1 [time.clock.req] requires that a clock type have a member
22628 typedef named <tt>time_point</tt> that names an instantiation of the
22629 template <tt>time_point</tt>, and a member named <tt>duration</tt> that
22630 names an instantiation of the template <tt>duration</tt>. This mixing of
22631 levels is confusing. The typedef names should be different from the
22636 Post Summit, Anthony provided proposed wording.
22641 2009-05-04 Howard adds:
22647 The reason that the typedef names were given the same name as the class templates
22648 was so that clients would not have to stop and think about whether they were
22649 using the clock's native <tt>time_point</tt> / <tt>duration</tt> or the class
22650 template directly. In this case, one person's confusion is another person's
22651 encapsulation. The detail that sometimes one is referring to the clock's
22652 native types, and sometimes one is referring to an independent type is
22653 <em>purposefully</em> "hidden" because it is supposed to be an unimportant
22654 detail. It can be confusing to have to remember when to type <tt>duration</tt>
22655 and when to type <tt>duration_type</tt>, and there is no need to require the
22656 client to remember something like that.
22660 For example, here is code that I once wrote in testing out the usability of
22664 <blockquote><pre>template <class Clock, class Duration>
22665 void do_until(const std::chrono::<b>time_point</b><Clock, Duration>& t)
22667 typename Clock::<b>time_point now</b> = Clock::now();
22670 typedef typename std::common_type
22673 typename std::chrono::system_clock::<b>duration</b>
22675 typedef std::chrono::<b>duration</b><double, std::nano> ID;
22678 ID us = duration_cast<ID>(d);
22684 </pre></blockquote>
22687 I see no rationale to require the client to append <tt>_type</tt> to <em>some</em>
22688 of those declarations. It seems overly burdensome on the author of <tt>do_until</tt>:
22691 <blockquote><pre>template <class Clock, class Duration>
22692 void do_until(const std::chrono::<b>time_point</b><Clock, Duration>& t)
22694 typename Clock::<b>time_point<font color="#c80000">_type</font></b> now = Clock::now();
22697 typedef typename std::common_type
22700 typename std::chrono::system_clock::<b>duration<font color="#c80000">_type</font></b>
22702 typedef std::chrono::<b>duration</b><double, std::nano> ID;
22705 ID us = duration_cast<ID>(d);
22711 </pre></blockquote>
22714 Additionally I'm fairly certain that this suggestion hasn't been implemented.
22715 If it had, it would have been discovered that it is incomplete. <tt>time_point</tt>
22716 also has a nested type (purposefully) named <tt>duration</tt>.
22719 That is, the current proposed wording would put the WP into an inconsistent state.
22723 the current WP has been implemented and I've received very favorable feedback
22724 from people using this interface in real-world code.
22735 Bill agrees that distinct names should be used for distinct kinds of entities.
22738 Walter would prefer not to suffix type names,
22739 especially for such well-understood terms as "duration".
22742 Howard reminds us that the proposed resolution is incomplete, per his comment
22751 2009-06-07 Howard adds:
22757 Not meaning to be argumentative, but we have a decade of positive experience
22758 with the precedent of using the same name for the nested type as an external
22759 class representing an identical concept.
22762 <blockquote><pre>template<class Category, class T, class Distance = ptrdiff_t,
22763 class Pointer = T*, class Reference = T&>
22764 struct <b>iterator</b>
22769 template <BidirectionalIterator Iter>
22770 class <b>reverse_iterator</b>
22775 template <ValueType T, Allocator Alloc = allocator<T> >
22776 requires NothrowDestructible<T>
22780 typedef <i>implementation-defined</i> <b>iterator</b>;
22782 typedef reverse_iterator<iterator> <b>reverse_iterator</b>;
22785 </pre></blockquote>
22788 I am aware of <em>zero</em> complaints regarding the use of <tt>iterator</tt>
22789 and <tt>reverse_iterator</tt> as nested types of the containers despite these
22790 names also having related meaning at namespace std scope.
22794 Would we really be doing programmers a favor by renaming these nested types?
22797 <blockquote><pre>template <ValueType T, Allocator Alloc = allocator<T> >
22798 requires NothrowDestructible<T>
22802 typedef <i>implementation-defined</i> <b>iterator_type</b>;
22804 typedef reverse_iterator<iterator> <b>reverse_iterator_type</b>;
22807 </pre></blockquote>
22810 I submit that such design contributes to needless verbosity which ends up
22811 reducing readability.
22817 <p><b>Proposed resolution:</b></p>
22819 Change 20.9 [time]:
22822 <blockquote><pre>...
22823 template <class Clock, class Duration = typename Clock::duration<ins>_type</ins>> class time_point;
22825 </pre></blockquote>
22828 Change 20.9.1 [time.clock.req]:
22833 <caption>Table 45 -- Clock requirements</caption>
22835 <th>Expression</th>
22836 <th>Return type</th>
22837 <th>Operational semantics</th>
22845 <td><tt>C1::duration<ins>_type</ins></tt></td>
22846 <td><tt>chrono::duration<C1::rep, C1::period></tt></td>
22847 <td>The native <tt>duration</tt> type of the clock.</td>
22850 <td><tt>C1::time_point<ins>_type</ins></tt></td>
22851 <td><tt>chrono::time_point<C1></tt> or <tt>chrono::time_point<C2, C1::duration<ins>_type</ins><</tt></td>
22852 <td>The native <tt>time_point</tt> type of the clock. Different clocks may share a <tt>time_point<ins>_type</ins></tt>
22853 definition if it is valid to
22854 compare their <tt>time_point<ins>_type</ins></tt>s by
22855 comparing their respective
22856 <tt>duration<ins>_type</ins></tt>s. <tt>C1</tt> and <tt>C2</tt> shall
22857 refer to the same epoch.</td>
22865 <td><tt>C1::now()</tt></td>
22866 <td><tt>C1::time_point<ins>_type</ins></tt></td>
22867 <td>Returns a <tt>time_point<ins>_type</ins></tt> object
22868 representing the current point
22876 Change 20.9.5.1 [time.clock.system]:
22881 -1- Objects of class <tt>system_clock</tt> represent wall clock time from the system-wide realtime clock.
22884 <blockquote><pre>class system_clock {
22886 typedef <i>see below</i> rep;
22887 typedef ratio<<i>unspecified</i>, <i>unspecified</i>> period;
22888 typedef chrono::duration<rep, period> duration<ins>_type</ins>;
22889 typedef chrono::time_point<system_clock> time_point<ins>_type</ins>;
22890 static const bool is_monotonic = <i>unspecified</i> ;
22892 static time_point<ins>_type</ins> now();
22895 static time_t to_time_t (const time_point<ins>_type</ins>& t);
22896 static time_point<ins>_type</ins> from_time_t(time_t t);
22898 </pre></blockquote>
22901 -2- <tt>system_clock::duration<ins>_type</ins>::min() < system_clock::duration<ins>_type</ins>::zero()</tt> shall be <tt>true</tt>.
22904 <pre>time_t to_time_t(const time_point<ins>_type</ins>& t);
22908 -3- <i>Returns:</i> A <tt>time_t</tt> object that represents the same
22909 point in time as <tt>t</tt> when both values are truncated to the
22910 coarser of the precisions of <tt>time_t</tt> and <tt>time_point<ins>_type</ins></tt>.
22913 <pre><tt>time_point<ins>_type</ins></tt> from_time_t(time_t t);
22917 -4- <i>Returns:</i> A <tt>time_point<ins>_type</ins></tt> object that represents the same point
22918 in time as <tt>t</tt> when both values are truncated to the coarser of the
22919 precisions of <tt>time_t</tt> and <tt>time_point<ins>_type</ins></tt>.
22924 Change 20.9.5.2 [time.clock.monotonic]:
22927 <blockquote><pre>class monotonic_clock {
22929 typedef <i>unspecified</i> rep;
22930 typedef ratio<<i>unspecified</i> , <i>unspecified</i>> period;
22931 typedef chrono::duration<rep, period> duration<ins>_type</ins>;
22932 typedef chrono::time_point<<i>unspecified</i> , duration<ins>_type</ins>> time_point<ins>_type</ins>;
22933 static const bool is_monotonic = true;
22935 static time_point<ins>_type</ins> now();
22937 </pre></blockquote>
22940 Change 20.9.5.3 [time.clock.hires]:
22943 <blockquote><pre>class high_resolution_clock {
22945 typedef <i>unspecified</i> rep;
22946 typedef ratio<<i>unspecified</i> , <i>unspecified</i>> period;
22947 typedef chrono::duration<rep, period> duration<ins>_type</ins>;
22948 typedef chrono::time_point<<i>unspecified</i> , duration<ins>_type</ins>> time_point<ins>_type</ins>;
22949 static const bool is_monotonic = true;
22951 static time_point<ins>_type</ins> now();
22953 </pre></blockquote>
22961 <h3><a name="956"></a>956. Various threading bugs #6</h3>
22962 <p><b>Section:</b> 20.9.1 [time.clock.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
22963 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2009-05-23</p>
22964 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#time.clock.req">active issues</a> in [time.clock.req].</p>
22965 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.clock.req">issues</a> in [time.clock.req].</p>
22966 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
22967 <p><b>Discussion:</b></p>
22969 20.9.1 [time.clock.req] uses the word "native" in several places,
22970 but doesn't define it. What is a "native <tt>duration</tt>"?
22974 2009-05-10 Howard adds:
22979 The standard uses "native" in several places without defining it (e.g.
22980 2.14.3 [lex.ccon]). It is meant to mean "that which is defined
22981 by the facility", or something along those lines. In this case it refers
22982 to the nested <tt>time_point</tt> and <tt>duration</tt> types of the clock.
22983 Better wording is welcome.
22991 Move to Open pending proposed wording from Pete.
22995 <p><b>Proposed resolution:</b></p>
23004 <h3><a name="957"></a>957. Various threading bugs #7</h3>
23005 <p><b>Section:</b> 20.9.5.1 [time.clock.system] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
23006 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2009-05-23</p>
23007 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#time.clock.system">active issues</a> in [time.clock.system].</p>
23008 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.clock.system">issues</a> in [time.clock.system].</p>
23009 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
23010 <p><b>Discussion:</b></p>
23012 20.9.5.1 [time.clock.system]: <tt>to_time_t</tt> is overspecified. It
23013 requires truncation, but should allow rounding. For example, suppose a
23014 system has a clock that gives times in milliseconds, but <tt>time()</tt> rounds
23015 those times to the nearest second. Then <tt>system_clock</tt> can't use any
23016 resolution finer than one second, because if it did, truncating times
23017 between half a second and a full second would produce the wrong <tt>time_t</tt>
23022 Post Summit Anthony Williams provided proposed wording.
23031 Move to Review pending input from Howard. and other stakeholders.
23035 2009-05-23 Howard adds:
23040 I am in favor of the wording provided by Anthony.
23044 <p><b>Proposed resolution:</b></p>
23046 In 20.9.5.1 [time.clock.system] replace paragraphs 3 and 4 with:
23050 <pre>time_t to_time_t(const time_point& t);
23053 -3- <i>Returns:</i> A <tt>time_t</tt> object that represents the same
23054 point in time as <tt>t</tt> when both values are <del>truncated</del>
23055 <ins>restricted</ins> to the coarser of the precisions of
23056 <tt>time_t</tt> and <tt>time_point</tt>. <ins> It is implementation
23057 defined whether values are rounded or truncated to the required
23061 <pre>time_point from_time_t(time_t t);
23064 -4- <i>Returns:</i> A <tt>time_point</tt> object that represents the
23065 same point in time as <tt>t</tt> when both values are <del>truncated</del>
23066 <ins>restricted</ins> to the
23067 coarser of the precisions of <tt>time_t</tt> and <tt>time_point</tt>.
23068 <ins>It is implementation defined whether values are
23069 rounded or truncated to the required precision.</ins>
23078 <h3><a name="958"></a>958. Various threading bugs #8</h3>
23079 <p><b>Section:</b> 30.5.1 [thread.condition.condvar] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
23080 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2009-03-22</p>
23081 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.condition.condvar">active issues</a> in [thread.condition.condvar].</p>
23082 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.condition.condvar">issues</a> in [thread.condition.condvar].</p>
23083 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
23084 <p><b>Discussion:</b></p>
23086 30.5.1 [thread.condition.condvar]: the specification for <tt>wait_for</tt>
23087 with no predicate has an effects clause that says it calls <tt>wait_until</tt>,
23088 and a returns clause that sets out in words how to determine the return
23089 value. Is this description of the return value subtly different from the
23090 description of the value returned by <tt>wait_until</tt>? Or should the effects
23091 clause and the returns clause be merged?
23100 Move to open. Associate with LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#859">859</a> and any other monotonic-clock
23105 <p><b>Proposed resolution:</b></p>
23114 <h3><a name="959"></a>959. Various threading bugs #9</h3>
23115 <p><b>Section:</b> 30.5.1 [thread.condition.condvar] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
23116 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2009-03-22</p>
23117 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.condition.condvar">active issues</a> in [thread.condition.condvar].</p>
23118 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.condition.condvar">issues</a> in [thread.condition.condvar].</p>
23119 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
23120 <p><b>Discussion:</b></p>
23122 30.5.1 [thread.condition.condvar]: <tt>condition_variable::wait_for</tt>
23123 is required to compute the absolute time by adding the duration value to
23124 <tt>chrono::monotonic_clock::now()</tt>, but <tt>monotonic_clock</tt> is not required to
23134 Move to open. Associate with LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#859">859</a> and any other monotonic-clock
23139 <p><b>Proposed resolution:</b></p>
23148 <h3><a name="960"></a>960. Various threading bugs #10</h3>
23149 <p><b>Section:</b> 30.4.1 [thread.mutex.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
23150 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2009-03-27</p>
23151 <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>
23152 <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>
23153 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
23154 <p><b>Discussion:</b></p>
23156 30.4.1 [thread.mutex.requirements]: paragraph 4 is entitled
23157 "Error conditions", but according to 17.5.1.4 [structure.specifications], "Error
23158 conditions:" specifies "the error conditions for error codes reported by
23159 the function." It's not clear what this should mean when there is no
23173 Beman provided proposed wording.
23178 <p><b>Proposed resolution:</b></p>
23180 Change 30.4.1 [thread.mutex.requirements] Mutex requirements,
23181 paragraph 4 as indicated:
23186 -4- <del><i>Error conditions:</i></del>
23187 <ins>The error conditions for error codes, if any, reported by member
23188 functions of type Mutex shall be:</ins>
23192 <tt>not_enough_memory</tt> -- if there is not enough memory to construct
23196 <tt>resource_unavailable_try_again</tt> -- if any native handle type
23197 manipulated is not available.
23200 <tt>operation_not_permitted</tt> -- if the thread does not have the
23201 necessary permission to change the state of the mutex object.
23204 <tt>device_or_resource_busy</tt> -- if any native handle type
23205 manipulated is already locked.
23208 <tt>invalid_argument</tt> -- if any native handle type manipulated as
23209 part of mutex construction is incorrect.
23219 <h3><a name="961"></a>961. Various threading bugs #11</h3>
23220 <p><b>Section:</b> 30.4.1 [thread.mutex.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
23221 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2009-03-22</p>
23222 <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>
23223 <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>
23224 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
23225 <p><b>Discussion:</b></p>
23227 30.4.1 [thread.mutex.requirements] describes required member
23228 functions of mutex types, and requires that they throw exceptions under
23229 certain circumstances. This is overspecified. User-defined types can
23230 abort on such errors without affecting the operation of templates
23231 supplied by standard-library.
23239 Move to open. Related to conceptualization and should probably be
23240 tackled as part of that.
23244 <p><b>Proposed resolution:</b></p>
23253 <h3><a name="962"></a>962. Various threading bugs #12</h3>
23254 <p><b>Section:</b> 30.4.3.2.2 [thread.lock.unique.locking] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
23255 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2009-03-22</p>
23256 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
23257 <p><b>Discussion:</b></p>
23259 30.4.3.2.2 [thread.lock.unique.locking]: <tt>unique_lock::lock</tt> is
23260 required to throw an object of type <tt>std::system_error</tt> "when the
23261 postcondition cannot be achieved." The postcondition is <tt>owns == true</tt>,
23262 and this is trivial to achieve. Presumably, the requirement is intended
23263 to mean something more than that.
23275 Beman has volunteered to provide proposed wording.
23281 <p><b>Proposed resolution:</b></p>
23290 <h3><a name="963"></a>963. Various threading bugs #13</h3>
23291 <p><b>Section:</b> 30.3.1.5 [thread.thread.member] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
23292 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2009-03-22</p>
23293 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.thread.member">active issues</a> in [thread.thread.member].</p>
23294 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.thread.member">issues</a> in [thread.thread.member].</p>
23295 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
23296 <p><b>Discussion:</b></p>
23298 30.3.1.5 [thread.thread.member]: <tt>thread::detach</tt> is required to
23299 throw an exception if the thread is "not a detachable thread".
23300 "Detachable" is never defined.
23309 Due to a mistake on my part, 3 proposed resolutions appeared at approximately
23310 the same time. They are all three noted below in the discussion.
23314 Summit, proposed resolution:
23320 In 30.3.1.5 [thread.thread.member] change:
23323 <blockquote><pre>void detach();
23327 <p>-14- <i>Error conditions:</i></p>
23329 <li><tt>no_such_process</tt> -- <ins>if the thread is</ins> not <del>a</del> valid<del> thread</del>.</li>
23330 <li><tt>invalid_argument</tt> -- <ins>if the thread is</ins> not <del>a detachable</del> <ins>joinable</ins><del> thread</del>.</li>
23339 Post Summit, Jonathan Wakely adds:
23345 A <tt>thread</tt> is detachable if it is joinable. As we've defined joinable,
23346 we can just use that.
23349 This corresponds to the pthreads specification, where pthread_detach
23350 fails if the thread is not joinable:
23353 EINVAL: The implementation has detected that the value specified by
23354 thread does not refer to a joinable thread.
23357 Jonathan recommends this proposed wording:
23361 In 30.3.1.5 [thread.thread.member] change:
23364 <blockquote><pre>void detach();
23368 <p>-14- <i>Error conditions:</i></p>
23371 <li><tt>invalid_argument</tt> -- not a <del>detachable</del> <ins>joinable</ins> thread.</li>
23380 Post Summit, Anthony Williams adds:
23386 This is covered by the precondition that <tt>joinable()</tt> be <tt>true</tt>.
23389 Anthony recommends this proposed wording:
23394 In 30.3.1.5 [thread.thread.member] change:
23397 <blockquote><pre>void detach();
23401 <p>-14- <i>Error conditions:</i></p>
23404 <li><del><tt>invalid_argument</tt> -- not a detachable thread.</del></li>
23416 <p><b>Proposed resolution:</b></p>
23423 <h3><a name="964"></a>964. Various threading bugs #14</h3>
23424 <p><b>Section:</b> 30.5.2 [thread.condition.condvarany] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
23425 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2009-03-22</p>
23426 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
23427 <p><b>Discussion:</b></p>
23429 The requirements for the constructor for <tt>condition_variable</tt> has several
23430 error conditions, but the requirements for the constructor for
23431 <tt>condition_variable_any</tt> has none. Is this difference intentional?
23440 Move to open, pass to Howard. If this is intentional, a note may be
23441 helpful. If the error conditions are to be copied from
23442 <tt>condition_variable</tt>, this depends on LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#965">965</a>.
23446 Post Summit Howard adds:
23451 The original intention
23452 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2447.htm#ConditionVariablesWording">N2447</a>)
23453 was to let the OS return whatever errors it was going to return, and for
23454 those to be translated into exceptions, for both
23455 <tt>condition_variable</tt> and <tt>condition_variable_any</tt>. I have not
23456 received any complaints about specific error conditions from vendors on
23457 non-POSIX platforms, but such complaints would not surprise me if they surfaced.
23461 <p><b>Proposed resolution:</b></p>
23468 <h3><a name="965"></a>965. Various threading bugs #15</h3>
23469 <p><b>Section:</b> 30.5.1 [thread.condition.condvar] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
23470 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2009-05-23</p>
23471 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.condition.condvar">active issues</a> in [thread.condition.condvar].</p>
23472 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.condition.condvar">issues</a> in [thread.condition.condvar].</p>
23473 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
23474 <p><b>Discussion:</b></p>
23476 30.5.1 [thread.condition.condvar]: the constructor for
23477 <tt>condition_variable</tt> throws an exception with error code
23478 <tt>device_or_resource_busy</tt> "if attempting to initialize a
23479 previously-initialized but as of yet undestroyed <tt>condition_variable</tt>."
23480 How can this occur?
23489 Move to review. Proposed resolution: strike the <tt>device_or_resource_busy</tt>
23490 error condition from the constructor of <tt>condition_variable</tt>.
23494 This is a POSIX error that cannot occur in this interface because the
23495 C++ interface does not separate declaration from initialization.
23505 We agree with the proposed resolution.
23506 Move to Tentatively Ready.
23510 <p><b>Proposed resolution:</b></p>
23512 Change 30.5.1 [thread.condition.condvar] p3:
23519 <del><tt>device_or_resource_busy</tt> -- if attempting to initialize a
23520 previously-initialized but as of yet undestroyed
23521 <tt>condition_variable</tt>.</del>
23531 <h3><a name="966"></a>966. Various threading bugs #16</h3>
23532 <p><b>Section:</b> 30.5.1 [thread.condition.condvar] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
23533 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2009-03-22</p>
23534 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.condition.condvar">active issues</a> in [thread.condition.condvar].</p>
23535 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.condition.condvar">issues</a> in [thread.condition.condvar].</p>
23536 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
23537 <p><b>Discussion:</b></p>
23539 30.5.1 [thread.condition.condvar]: <tt>condition_variable::wait</tt> and
23540 <tt>condition_variable::wait_until</tt> both have a postcondition that <tt>lock</tt> is
23541 locked by the calling thread, and a throws clause that requires throwing
23542 an exception if this postcondition cannot be achieved. How can the
23543 implementation detect that this <tt>lock</tt> can never be obtained?
23552 Move to open. Requires wording. Agreed this is an issue, and the
23553 specification should not require detecting deadlocks.
23557 <p><b>Proposed resolution:</b></p>
23564 <h3><a name="967"></a>967. Various threading bugs #17</h3>
23565 <p><b>Section:</b> 30.3.1.2 [thread.thread.constr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
23566 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2009-03-22</p>
23567 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.thread.constr">active issues</a> in [thread.thread.constr].</p>
23568 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.thread.constr">issues</a> in [thread.thread.constr].</p>
23569 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
23570 <p><b>Discussion:</b></p>
23572 the error handling for the constructor for <tt>condition_variable</tt>
23573 distinguishes lack of memory from lack of other resources, but the error
23574 handling for the thread constructor does not. Is this difference
23579 Beman has volunteered to provide proposed wording.
23584 <p><b>Proposed resolution:</b></p>
23593 <h3><a name="968"></a>968. Various threading bugs #18</h3>
23594 <p><b>Section:</b> 30.4.1 [thread.mutex.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
23595 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2009-03-22</p>
23596 <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>
23597 <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>
23598 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
23599 <p><b>Discussion:</b></p>
23601 30.4.1 [thread.mutex.requirements]: several functions are
23602 required to throw exceptions "if the thread does not have the necessary
23603 permission ...". "The necessary permission" is not defined.
23616 Beman has volunteered to provide proposed wording.
23621 <p><b>Proposed resolution:</b></p>
23630 <h3><a name="969"></a>969. What happened to Library Issue 475?</h3>
23631 <p><b>Section:</b> 25.3.4 [alg.foreach] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Tentatively NAD Editorial</a>
23632 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2009-01-12 <b>Last modified:</b> 2009-05-23</p>
23633 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#alg.foreach">active issues</a> in [alg.foreach].</p>
23634 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.foreach">issues</a> in [alg.foreach].</p>
23635 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD%20Editorial">Tentatively NAD Editorial</a> status.</p>
23636 <p><b>Discussion:</b></p>
23638 Library Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#475">475</a> has CD1 status, but the non-normative note in
23639 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>
23641 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdf">N2798</a>
23642 (25.3.4 [alg.foreach] in both drafts).
23650 Move to NAD Editorial.
23654 <p><b>Proposed resolution:</b></p>
23656 Restore the non-normative note. It might need to be expressed in terms of concepts.
23664 <h3><a name="970"></a>970. addressof overload unneeded</h3>
23665 <p><b>Section:</b> 20.8.11.1 [object.addressof] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
23666 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-01-16 <b>Last modified:</b> 2009-05-23</p>
23667 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#object.addressof">active issues</a> in [object.addressof].</p>
23668 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#object.addressof">issues</a> in [object.addressof].</p>
23669 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
23670 <p><b>Discussion:</b></p>
23672 20.8.11.1 [object.addressof] specifies:
23675 <blockquote><pre>template <ObjectType T> T* addressof(T& r);
23676 template <ObjectType T> T* addressof(T&& r);
23677 </pre></blockquote>
23680 The two signatures are ambiguous when the argument is an lvalue. The
23681 second signature seems not useful: what does it mean to take the
23682 address of an rvalue?
23699 We agree with the proposed resolution.
23700 Move to Tentatively Ready.
23704 <p><b>Proposed resolution:</b></p>
23706 Change 20.8.11.1 [object.addressof]:
23709 <blockquote><pre>template <ObjectType T> T* addressof(T& r);
23710 <del>template <ObjectType T> T* addressof(T&& r);</del>
23711 </pre></blockquote>
23719 <h3><a name="971"></a>971. Spurious diagnostic conversion function</h3>
23720 <p><b>Section:</b> 19.5.2.6 [syserr.errcode.nonmembers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
23721 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2009-01-19 <b>Last modified:</b> 2009-05-23</p>
23722 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
23723 <p><b>Discussion:</b></p>
23725 Anthony Williams raised the question in c++std-lib-22987 "why is there
23726 <tt>std::make_error_code(std::errc)</tt>? What purpose does this serve?"
23729 The function <tt>make_error_code(errc e)</tt> is not required, since
23730 <tt>make_error_condition(errc e)</tt> is the function that is needed for <tt>errc</tt>
23731 conversions. <tt>make_error_code(errc e)</tt> appears to be a holdover from my
23732 initial confusion over the distinction between POSIX and operating
23733 systems that conform to the POSIX spec.
23750 The designer of the facility (Christopher Kohlhoff)
23751 strongly disagrees that there is an issue here,
23752 and especially disagrees with the proposed resolution.
23753 Bill would prefer to be conservative and not apply this proposed resolution.
23754 Move to Open, and recommend strong consideration for NAD status.
23758 2009-05-21 Beman adds:
23763 My mistake. Christopher and Bill are correct and the issue should be
23764 NAD. The function is needed by users.
23768 <p><b>Proposed resolution:</b></p>
23770 Change System error support 19.5 [syserr], Header <tt><system_error></tt>
23771 synopsis, as indicated:
23774 <blockquote><pre><del>error_code make_error_code(errc e);</del>
23775 error_condition make_error_condition(errc e);
23776 </pre></blockquote>
23779 Delete from Class error_code non-member functions
23780 19.5.2.6 [syserr.errcode.nonmembers]:
23783 <blockquote><pre><del>error_code make_error_code(errc e);</del>
23786 <del><i>Returns:</i> <tt>error_code(static_cast<int>(e),
23787 generic_category)</tt>.</del>
23797 <h3><a name="972"></a>972. The term "Assignable" undefined but still in use</h3>
23798 <p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Tentatively NAD Editorial</a>
23799 <b>Submitter:</b> Niels Dekker <b>Opened:</b> 2009-01-07 <b>Last modified:</b> 2009-05-23</p>
23800 <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>
23801 <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>
23802 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD%20Editorial">Tentatively NAD Editorial</a> status.</p>
23803 <p><b>Discussion:</b></p>
23805 Previous versions of the Draft had a table, defining the Assignable
23806 requirement. For example
23807 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2134.pdf">N2134</a>
23808 Table 79, "Assignable requirements". But I guess the term "Assignable"
23809 is outdated by now, because the current Committee Draft provides
23810 <tt>MoveAssignable</tt>, <tt>CopyAssignable</tt>, and <tt>TriviallyCopyAssignable</tt> concepts
23811 instead. And as far as I can see, it no longer has a definition of
23812 <tt>Assignable</tt>. (Please correct me if I'm wrong.) Still the word
23813 "Assignable" is used in eight places in the Draft,
23814 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2800.pdf">N2800</a>.
23818 Are all of those instances of "<tt>Assignable</tt>" to be replaced by "<tt>CopyAssignable</tt>"?
23826 Move to NAD Editorial.
23830 <p><b>Proposed resolution:</b></p>
23833 Change Exception Propagation 18.8.5 [propagation]:
23836 <tt>exception_ptr</tt> shall be <tt>DefaultConstructible</tt>, <tt>CopyConstructible</tt>,
23837 <tt><ins>Copy</ins>Assignable</tt> and <tt>EqualityComparable</tt>.
23841 Change Class template reference_wrapper 20.7.5 [refwrap]:
23844 <tt>reference_wrapper<T></tt> is a <tt>CopyConstructible</tt> and <tt><ins>Copy</ins>Assignable</tt> wrapper around a reference to an object of type <tt>T</tt>.
23847 Change Placeholders 20.7.12.1.4 [func.bind.place]:
23850 It is implementation defined whether placeholder types are <tt><ins>Copy</ins>Assignable</tt>. <tt><ins>Copy</ins>Assignable</tt> placeholders' copy assignment operators shall not throw exceptions.
23853 Change Class template shared_ptr 20.8.13.2 [util.smartptr.shared]:
23856 Specializations of <tt>shared_ptr</tt> shall be <tt>CopyConstructible</tt>, <tt><ins>Copy</ins>Assignable</tt>, and <tt>LessThanComparable</tt>...
23859 Change Class template weak_ptr 20.8.13.3 [util.smartptr.weak]:
23862 Specializations of <tt>weak_ptr</tt> shall be <tt>CopyConstructible</tt>, <tt><ins>Copy</ins>Assignable</tt>, and <tt>LessThanComparable</tt>...
23865 Change traits typedefs 21.2.2 [char.traits.typedefs] (note: including deletion of reference to 23.1!):
23868 <i>Requires:</i> <tt>state_type</tt> shall meet the requirements of <tt><ins>Copy</ins>Assignable</tt><del> (23.1)</del>, <tt>CopyConstructible</tt> (20.1.8), and <tt>DefaultConstructible</tt> types.
23871 Change Class seed_seq 26.5.7.1 [rand.util.seedseq] (note again: including deletion of reference to 23.1!):
23874 In addition to the requirements set forth below, instances of
23875 <tt>seed_seq</tt> shall meet the requirements of <tt>CopyConstructible</tt> (20.1.8) and of <tt><ins>Copy</ins>Assignable</tt><del> (23.1)</del>.
23879 Note: The proposed resolution of this issue does not deal with the
23880 instance of the term "Assignable" in D.9.1 [auto.ptr], as this is dealt
23881 with more specifically by LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#973">973</a>, "<tt>auto_ptr</tt> characteristics", submitted
23882 by Maarten Hilferink.
23891 <h3><a name="973"></a>973. auto_ptr characteristics</h3>
23892 <p><b>Section:</b> D.9.1 [auto.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Tentatively NAD Editorial</a>
23893 <b>Submitter:</b> Maarten Hilferink <b>Opened:</b> 2009-01-21 <b>Last modified:</b> 2009-05-23</p>
23894 <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>
23895 <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>
23896 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD%20Editorial">Tentatively NAD Editorial</a> status.</p>
23897 <p><b>Discussion:</b></p>
23899 I think that the Note of D.9.1 [auto.ptr], paragraph 3 needs a rewrite
23900 since "Assignable" is no longer defined as a concept.
23901 The relationship of <tt>auto_ptr</tt> with the new <tt>CopyAssignable</tt>, <tt>MoveAssignable</tt>,
23902 and <tt>MoveConstructible</tt> concepts should be clarified.
23903 Furthermore, since the use of <tt>auto_ptr</tt> is depreciated anyway,
23904 we can also omit a description of its intended use.
23912 We agree with the intent of the proposed resolution.
23913 Move to NAD Editorial.
23917 <p><b>Proposed resolution:</b></p>
23919 Change D.9.1 [auto.ptr], paragraph 3:
23923 The <tt>auto_ptr</tt> provides a semantics of strict ownership. An
23924 <tt>auto_ptr</tt> owns the ob ject it holds a pointer to. Copying an
23925 <tt>auto_ptr</tt> copies the pointer and transfers ownership to the
23926 destination. If more than one <tt>auto_ptr</tt> owns the same ob ject at
23927 the same time the behavior of the program is undefined. [<i>Note:</i>
23928 The uses of <tt>auto_ptr</tt> include providing temporary
23929 exception-safety for dynamically allocated memory, passing ownership of
23930 dynamically allocated memory to a function, and returning dynamically
23931 allocated memory from a function.
23932 <del><tt>auto_ptr</tt> does not meet the
23933 <tt>CopyConstructible</tt> and <tt>Assignable</tt> requirements for
23934 standard library container elements and thus instantiating a standard
23935 library container with an <tt>auto_ptr</tt> results in undefined
23938 <ins>Instances of <tt>auto_ptr</tt> shall
23939 meet the <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt>
23940 requirements, but do not meet the <tt>CopyConstructible</tt> and
23941 <tt>CopyAssignable</tt> requirements.</ins>
23942 -- <i>end note</i>]
23950 <h3><a name="974"></a>974. <tt>duration<double></tt> should not implicitly convert to <tt>duration<int></tt></h3>
23951 <p><b>Section:</b> 20.9.3.1 [time.duration.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
23952 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-01-21 <b>Last modified:</b> 2009-05-23</p>
23953 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
23954 <p><b>Discussion:</b></p>
23956 The following code should not compile because it involves implicit truncation
23957 errors (against the design philosophy of the <tt>duration</tt> library).
23960 <blockquote><pre>duration<double> d(3.5);
23961 duration<int> i = d; <font color="#c80000">// implicit truncation, should not compile</font>
23962 </pre></blockquote>
23965 This intent was codified in the example implementation which drove this proposal
23966 but I failed to accurately translate the code into the specification in this
23976 We agree with the proposed resolution.
23979 Move to Tentatively Ready.
23984 <p><b>Proposed resolution:</b></p>
23986 Change 20.9.3.1 [time.duration.cons], p4:
23990 <pre>template <class Rep2, class Period2>
23991 duration(const duration<Rep2, Period2>& d);
23994 -4- <i>Requires:</i> <tt>treat_as_floating_point<rep>::value</tt>
23995 shall be <tt>true</tt> or <ins>both</ins> <tt>ratio_divide<Period2,
23996 period>::type::den</tt> shall be 1
23997 <ins>and <tt>treat_as_floating_point<Rep2>::value</tt>
23998 shall be <tt>false</tt></ins>.
23999 Diagnostic required.
24000 [<i>Note:</i> This requirement prevents implicit truncation error when
24001 converting between integral-based <tt>duration</tt> types. Such a
24002 construction could easily lead to confusion about the value of the
24003 <tt>duration</tt>. -- <i>end note</i>]
24012 <h3><a name="975"></a>975. <tt>is_convertible</tt> cannot be instantiated for non-convertible types</h3>
24013 <p><b>Section:</b> 20.6.5 [meta.rel] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
24014 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-01-25 <b>Last modified:</b> 2009-05-23</p>
24015 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta.rel">active issues</a> in [meta.rel].</p>
24016 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.rel">issues</a> in [meta.rel].</p>
24017 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
24018 <p><b>Discussion:</b></p>
24020 <b>Addresses UK 206</b>
24023 Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1114">1114</a>.
24027 The current specification of <tt>std::is_convertible</tt> (reference is draft
24028 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdf">N2798</a>)
24029 is basically defined by 20.6.5 [meta.rel]/4:
24034 In order to instantiate the template <tt>is_convertible<From,
24035 To></tt>, the following code shall be well formed:
24038 <blockquote><pre>template <class T>
24039 typename add_rvalue_reference<T>::type create();
24042 return create<From>();
24044 </pre></blockquote>
24047 [<i>Note:</i> This requirement gives well defined results for reference
24048 types, void types, array types, and function types. --<i>end note</i>]
24053 The first sentence can be interpreted, that e.g. the expression
24056 <blockquote><pre>std::is_convertible<double, int*>::value
24057 </pre></blockquote>
24060 is ill-formed because <tt>std::is_convertible<double, int*></tt> could not be
24061 instantiated, or in more general terms: The wording requires that
24062 <tt>std::is_convertible<X, Y></tt> cannot be instantiated for otherwise valid
24063 argument types <tt>X</tt> and <tt>Y</tt> if <tt>X</tt> is not convertible to <tt>Y</tt>.
24067 This semantic is both unpractical and in contradiction to what the last type
24069 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2255.html">N2255</a>
24075 If the following <tt>test</tt> function is well formed code <tt>b</tt>
24076 is <tt>true</tt>, else it is <tt>false</tt>.
24079 <blockquote><pre>template <class T>
24080 typename add_rvalue_reference<T>::type create();
24083 return create<From>();
24085 </pre></blockquote>
24088 [<i>Note:</i> This definition gives well defined results for <tt>reference</tt>
24089 types, <tt>void</tt> types, array types, and function types. --<i>end note</i>]
24100 Jens: Checking that code is well-formed and then returning true/false
24101 sounds like speculative compilation. John Spicer would really dislike
24102 this. Please find another wording suggesting speculative compilation.
24110 Post Summit, Howard adds:
24116 John finds the following wording clearer:
24122 <th>Template</th><th>Condition</th><th>Comments</th>
24125 <td><tt>template <class From, class To><br>struct is_convertible;</tt></td>
24126 <td><i>see below</i></td>
24127 <td><tt>From</tt> and <tt>To</tt> shall be complete types, arrays of unknown bound,
24128 or (possibly cv-qualified) <tt>void</tt> types.</td>
24133 Given the following function prototype:
24136 <blockquote><pre>template <class T>
24137 typename add_rvalue_reference<T>::type create();
24138 </pre></blockquote>
24141 <tt>is_convertible<From, To>::value</tt> shall be <tt>true</tt> if the
24142 return expression in the following code would be well-formed, including
24143 any implicit conversions to the return type of the function, else
24144 <tt>is_convertible<From, To>::value</tt> shall be <tt>false</tt>.
24147 <blockquote><pre>To test() {
24148 return create<From>();
24150 </pre></blockquote>
24156 <b>Original proposed wording:</b>
24159 In 20.6.5 [meta.rel]/4 change:
24163 <del>In order to instantiate the template <tt>is_convertible<From, To></tt>, the
24164 following code shall be well formed</del> <ins>If the following code
24165 is well formed <tt>is_convertible<From, To>::value</tt> is <tt>true</tt>, otherwise
24166 <tt>false</tt></ins>:[..]
24169 <p><b>Revision 2</b></p>
24174 In 20.6.5 [meta.rel] change:
24181 <th>Template</th><th>Condition</th><th>Comments</th>
24184 </tr><tr><td>...</td><td>...</td><td>...</td></tr>
24185 <tr><td><tt>template <class From, class To><br>struct is_convertible;</tt></td>
24187 <del>The code set out below shall be well formed.</del>
24188 <ins><i>see below</i></ins></td>
24189 <td><tt>From</tt> and <tt>To</tt> shall be complete types, arrays of unknown bound,
24190 or (possibly cv-qualified) <tt>void</tt> types.</td>
24195 -4- <del>In order to instantiate the template <tt>is_convertible<From, To></tt>, the
24196 following code shall be well formed:</del>
24197 <ins>Given the following function prototype:</ins>
24200 <blockquote><pre>template <class T>
24201 typename add_rvalue_reference<T>::type create();
24202 </pre></blockquote>
24205 <ins><tt>is_convertible<From, To>::value</tt> inherits either directly or
24206 indirectly from <tt>true_type</tt> if the
24207 return expression in the following code would be well-formed, including
24208 any implicit conversions to the return type of the function, else
24209 <tt>is_convertible<From, To>::value</tt> inherits either directly or
24210 indirectly from <tt>false_type</tt>.</ins>
24213 <blockquote><pre>To test() {
24214 return create<From>();
24216 </pre></blockquote>
24219 [<i>Note:</i> This requirement gives well defined results for reference types,
24220 void types, array types, and function types. <i>-- end note</i>]
24231 We agree with the proposed resolution.
24232 Move to Tentatively Ready.
24236 <p><b>Proposed resolution:</b></p>
24239 In 20.6.5 [meta.rel] change:
24246 <th>Template</th><th>Condition</th><th>Comments</th>
24249 </tr><tr><td>...</td><td>...</td><td>...</td></tr>
24250 <tr><td><tt>template <class From, class To><br>struct is_convertible;</tt></td>
24252 <del>The code set out below shall be well formed.</del>
24253 <ins><i>see below</i></ins></td>
24254 <td><tt>From</tt> and <tt>To</tt> shall be complete types, arrays of unknown bound,
24255 or (possibly cv-qualified) <tt>void</tt> types.</td>
24260 -4- <del>In order to instantiate the template <tt>is_convertible<From, To></tt>, the
24261 following code shall be well formed:</del>
24262 <ins>Given the following function prototype:</ins>
24265 <blockquote><pre>template <class T>
24266 typename add_rvalue_reference<T>::type create();
24267 </pre></blockquote>
24270 <ins>the predicate condition for a template specialization
24271 <tt>is_convertible<From, To></tt> shall be satisfied, if and only
24272 if the return expression in the following code would be well-formed,
24273 including any implicit conversions to the return type of the
24277 <blockquote><pre>To test() {
24278 return create<From>();
24280 </pre></blockquote>
24283 [<i>Note:</i> This requirement gives well defined results for reference types,
24284 void types, array types, and function types. <i>— end note</i>]
24294 <h3><a name="976"></a>976. Class template std::stack should be movable</h3>
24295 <p><b>Section:</b> 23.3.5.3.1 [stack.defn] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
24296 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-02-01 <b>Last modified:</b> 2009-05-23</p>
24297 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
24298 <p><b>Discussion:</b></p>
24300 The synopsis given in 23.3.5.3.1 [stack.defn] does not show up
24303 <blockquote><pre>requires MoveConstructible<Cont> stack(stack&&);
24304 requires MoveAssignable<Cont> stack& operator=(stack&&);
24305 </pre></blockquote>
24308 although the other container adaptors do provide corresponding
24318 We agree with the proposed resolution.
24321 Move to Tentatively Ready.
24326 <p><b>Proposed resolution:</b></p>
24328 In the class stack synopsis of 23.3.5.3.1 [stack.defn] insert:
24331 <blockquote><pre>template <ObjectType T, StackLikeContainer Cont = deque<T> >
24332 requires SameType<Cont::value_type, T>
24333 && NothrowDestructible<Cont>
24337 requires CopyConstructible<Cont> explicit stack(const Cont&);
24338 requires MoveConstructible<Cont> explicit stack(Cont&& = Cont());
24339 <ins>requires MoveConstructible<Cont> stack(stack&&);</ins>
24340 <ins>requires MoveAssignable<Cont> stack& operator=(stack&&);</ins>
24341 template <class Alloc>
24342 requires Constructible<Cont, const Alloc&>
24343 explicit stack(const Alloc&);
24346 </pre></blockquote>
24349 [Remark: This change should be done in sync with the resolution of
24351 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2819.html">N2819</a>]
24360 <h3><a name="977"></a>977. insert iterators inefficient for expensive to move types</h3>
24361 <p><b>Section:</b> 24.7 [insert.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
24362 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-02-02 <b>Last modified:</b> 2009-05-23</p>
24363 <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>
24364 <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>
24365 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
24366 <p><b>Discussion:</b></p>
24368 The new concepts for the insert iterators mandate an extra copy when
24369 inserting an lvalue:
24372 <blockquote><pre>requires CopyConstructible<Cont::value_type>
24373 back_insert_iterator<Cont>&
24374 operator=(const Cont::value_type& value);
24377 -1- <i>Effects:</i> <tt>push_back(*container, <b>Cont::value_type(</b>value<b>)</b>);</tt>
24382 The reason is to convert <tt>value</tt> into an rvalue because the current
24383 <tt>BackInsertionContainer</tt> concept only handles <tt>push_back</tt>-ing
24387 <blockquote><pre>concept BackInsertionContainer<typename C> : Container<C> {
24388 void push_back(C&, value_type&&);
24390 </pre></blockquote>
24393 Without the conversion of <tt>value</tt> to an rvalue, the assignment operator
24394 fails to concept check.
24398 A solution is to modify the <tt>BackInsertionContainer</tt> concept so that
24399 the client can pass in the parameter type for <tt>push_back</tt> similar to
24400 what is already done for the <tt>OutputIterator</tt> concept:
24403 <blockquote><pre>concept BackInsertionContainer<typename C, typename Value = C::value_type&&>
24404 : Container<C> {
24405 void push_back(C&, Value);
24407 </pre></blockquote>
24410 This allows the assignment operator to be adjusted appropriately:
24413 <blockquote><pre>requires BackInsertionContainer<Cont, Cont::value_type const&> &&
24414 CopyConstructible<Cont::value_type>
24415 back_insert_iterator<Cont>&
24416 operator=(const Cont::value_type& value);
24419 -1- <i>Effects:</i> <tt>push_back(*container, value);</tt>
24424 We may want to propagate this fix to other concepts such as <tt>StackLikeContainer</tt>.
24429 Solution and wording collaborated on by Doug and Howard.
24439 Howard notes that "these operations behaved efficiently until concepts were added."
24442 Alisdair is uncertain that the proposed resolution is syntactically correct.
24445 Move to Open, and recommend the issue be deferred until after the next
24446 Committee Draft is issued.
24451 <p><b>Proposed resolution:</b></p>
24453 Change 23.2.6.1 [container.concepts.free]:
24457 <pre>concept FrontInsertionContainer<typename C<ins>, typename Value = C::value_type&&</ins>>
24458 : Container<C> {
24459 void push_front(C&, <del>value_type&&</del> <ins>Value</ins>);
24461 axiom FrontInsertion(C c, <del>value_type</del> <ins>Value</ins> x) {
24462 x == (push_front(c, x), front(c));
24469 <pre>concept BackInsertionContainer<typename C<ins>, typename Value = C::value_type&&</ins>>
24470 : Container<C> {
24471 void push_back(C&, <del>value_type&&</del> <ins>Value</ins>);
24477 <pre>concept InsertionContainer<typename C<ins>, typename Value = C::value_type&&</ins>>
24478 : Container<C> {
24479 iterator insert(C&, const_iterator, <del>value_type&&</del> <ins>Value</ins>);
24481 axiom Insertion(C c, const_iterator position, <del>value_type</del> <ins>Value</ins> v) {
24482 v == *insert(c, position, v);
24490 Change 23.2.6.2 [container.concepts.member]:
24494 <pre>auto concept MemberFrontInsertionContainer<typename C<ins>, typename Value = C::value_type&&</ins>>
24495 : MemberContainer<C> {
24496 void C::push_front(<del>value_type&&</del> <ins>Value</ins>);
24498 axiom MemberFrontInsertion(C c, <del>value_type</del> <ins>Value</ins> x) {
24499 x == (c.push_front(x), c.front());
24506 <pre>auto concept MemberBackInsertionContainer<typename C<ins>, typename Value = C::value_type&&</ins>>
24507 : MemberContainer<C> {
24508 void C::push_back(<del>value_type&&</del> <ins>Value</ins>);
24514 <pre>auto concept MemberInsertionContainer<typename C<ins>, typename Value = C::value_type&&</ins>>
24515 : MemberContainer<C> {
24516 iterator C::insert(const_iterator, <del>value_type&&</del> <ins>Value</ins>);
24518 axiom MemberInsertion(C c, const_iterator position, <del>value_type</del> <ins>Value</ins> v) {
24519 v == *c.insert(position, v);
24526 Change 23.2.6.3 [container.concepts.maps]:
24530 <pre>template <MemberFrontInsertionContainer C<ins>, typename Value = C::value_type&&</ins>>
24531 concept_map FrontInsertionContainer<C<ins>, Value</ins>> {
24532 typedef Container<C>::value_type value_type;
24534 void push_front(C& c, <del>value_type&&</del> <ins>Value</ins> v) { c.push_front(static_cast<<del>value_type&&</del> <ins>Value</ins>>(v)); }
24540 <pre>template <MemberBackInsertionContainer C<ins>, typename Value = C::value_type&&</ins>>
24541 concept_map BackInsertionContainer<C<ins>, Value</ins>> {
24542 typedef Container<C>::value_type value_type;
24544 void push_back(C& c, <del>value_type&&</del> <ins>Value</ins> v) { c.push_back(static_cast<<del>value_type&&</del> <ins>Value</ins>>(v)); }
24550 <pre>template <MemberInsertionContainer C<ins>, typename Value = C::value_type&&</ins>>
24551 concept_map InsertionContainer<C<ins>, Value</ins>> {
24552 typedef Container<C>::value_type value_type;
24553 Container<C>::iterator insert(C& c, Container<C>::const_iterator i, <del>value_type&&</del> <ins>Value</ins> v)
24554 { return c.insert(i, static_cast<<del>value_type&&</del> <ins>Value</ins>>(v)); }
24561 Change 24.7.1 [back.insert.iterator]:
24564 <blockquote><pre>template <BackInsertionContainer Cont>
24565 class back_insert_iterator {
24567 requires <ins>BackInsertionContainer<Cont, const Cont::value_type&></ins>
24568 <del>CopyConstructible<Cont::value_type></del>
24569 back_insert_iterator<Cont>&
24570 operator=(const Cont::value_type& value);
24572 </pre></blockquote>
24575 Change 24.7.2.2 [back.insert.iter.op=]:
24579 <pre>requires <ins>BackInsertionContainer<Cont, const Cont::value_type&></ins>
24580 <del>CopyConstructible<Cont::value_type></del>
24581 back_insert_iterator<Cont>&
24582 operator=(const Cont::value_type& value);
24585 -1- <i>Effects:</i> <tt>push_back(*container, <del>Cont::value_type(</del>value<del>)</del>);</tt>
24590 Change 24.7.3 [front.insert.iterator]:
24593 <blockquote><pre>template <FrontInsertionContainer Cont>
24594 class front_insert_iterator {
24596 requires <ins>FrontInsertionContainer<Cont, const Cont::value_type&></ins>
24597 <del>CopyConstructible<Cont::value_type></del>
24598 front_insert_iterator<Cont>&
24599 operator=(const Cont::value_type& value);
24601 </pre></blockquote>
24604 Change 24.7.4.2 [front.insert.iter.op=]:
24608 <pre>requires <ins>FrontInsertionContainer<Cont, const Cont::value_type&></ins>
24609 <del>CopyConstructible<Cont::value_type></del>
24610 front_insert_iterator<Cont>&
24611 operator=(const Cont::value_type& value);
24614 -1- <i>Effects:</i> <tt>push_front(*container, <del>Cont::value_type(</del>value<del>)</del>);</tt>
24619 Change 24.7.5 [insert.iterator]:
24622 <blockquote><pre>template <InsertionContainer Cont>
24623 class insert_iterator {
24625 requires <ins>InsertionContainer<Cont, const Cont::value_type&></ins>
24626 <del>CopyConstructible<Cont::value_type></del>
24627 insert_iterator<Cont>&
24628 operator=(const Cont::value_type& value);
24630 </pre></blockquote>
24633 Change 24.7.6.2 [insert.iter.op=]:
24637 <pre>requires <ins>InsertionContainer<Cont, const Cont::value_type&></ins>
24638 <del>CopyConstructible<Cont::value_type></del>
24639 insert_iterator<Cont>&
24640 operator=(const Cont::value_type& value);
24644 -1- <i>Effects:</i>
24646 <blockquote><pre>iter = insert(*container, iter, <del>Cont::value_type(</del>value<del>)</del>);
24648 </pre></blockquote>
24658 <h3><a name="978"></a>978. Hashing smart pointers</h3>
24659 <p><b>Section:</b> 20.7.17 [unord.hash] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
24660 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-02-02 <b>Last modified:</b> 2009-05-31</p>
24661 <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>
24662 <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>
24663 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
24664 <p><b>Discussion:</b></p>
24666 I don't see an open issue on supporting <tt>std::hash</tt> for smart pointers
24667 (<tt>unique_ptr</tt> and <tt>shared_ptr</tt> at least).
24670 It seems reasonable to at least expect support for the smart
24671 pointers, especially as they support comparison for use in ordered
24672 associative containers.
24681 Howard points out that the client can always supply a custom hash function.
24684 Alisdair replies that the smart pointer classes are highly likely
24685 to be frequently used as hash keys.
24688 Bill would prefer to be conservative.
24691 Alisdair mentions that this issue may also be viewed as a subissue or
24692 duplicate of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1025">1025</a>.
24695 Move to Open, and recommend the issue be deferred until after the next
24696 Committee Draft is issued.
24701 2009-05-31 Peter adds:
24707 Howard points out that the client can always supply a custom hash function.
24710 Not entirely true. The client cannot supply the function that hashes the
24711 address of the control block (the equivalent of the old <tt>operator<</tt>, now
24712 proudly carrying the awkward name of '<tt>owner_before</tt>'). Only the
24713 implementation can do that, not necessarily via specializing <tt>hash<></tt>, of
24717 This hash function makes sense in certain situations for <tt>shared_ptr</tt>
24718 (when one needs to switch from <tt>set/map</tt> using ownership ordering to
24719 <tt>unordered_set/map</tt>) and is the only hash function that makes sense for
24726 <p><b>Proposed resolution:</b></p>
24735 <h3><a name="979"></a>979. Bad example</h3>
24736 <p><b>Section:</b> 24.5.3 [move.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Tentatively NAD Editorial</a>
24737 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-02-03 <b>Last modified:</b> 2009-05-23</p>
24738 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD%20Editorial">Tentatively NAD Editorial</a> status.</p>
24739 <p><b>Discussion:</b></p>
24741 24.5.3 [move.iterators] has an incorrect example:
24746 -2- [<i>Example:</i>
24749 <blockquote><pre>set<string> s;
24750 // populate the set s
24751 vector<string> v1(s.begin(), s.end()); // copies strings into v1
24752 vector<string> v2(make_move_iterator(s.begin()),
24753 make_move_iterator(s.end())); // moves strings into v2
24754 </pre></blockquote>
24757 <i>-- end example</i>]
24762 One can not move from a <tt>set</tt> because the iterators return <tt>const</tt>
24771 We agree with the proposed resolution. Move to NAD Editorial.
24776 <p><b>Proposed resolution:</b></p>
24778 Change 24.5.3 [move.iterators]/2:
24783 -2- [<i>Example:</i>
24786 <blockquote><pre><del>set</del><ins>list</ins><string> s;
24787 // populate the <del>set</del><ins>list</ins> s
24788 vector<string> v1(s.begin(), s.end()); // copies strings into v1
24789 vector<string> v2(make_move_iterator(s.begin()),
24790 make_move_iterator(s.end())); // moves strings into v2
24791 </pre></blockquote>
24794 <i>-- end example</i>]
24803 <h3><a name="981"></a>981. Unordered container requirements should add <tt>initializer_list</tt> support</h3>
24804 <p><b>Section:</b> 23.2.5 [unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
24805 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-02-08 <b>Last modified:</b> 2009-05-23</p>
24806 <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>
24807 <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>
24808 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
24809 <p><b>Discussion:</b></p>
24812 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2800.pdf">N2800</a>
24813 all container requirements tables (including those for
24814 associative containers) provide useful member function overloads
24815 accepting <tt>std::initializer_list</tt> as argument, the only exception is
24816 Table 87. There seems to be no reason for not providing them, because 23.5 [unord]
24817 is already <tt>initializer_list</tt>-aware. For the sake of
24818 library interface consistency and user-expectations corresponding
24819 overloads should be added to the table requirements of unordered
24820 containers as well.
24829 We agree with the proposed resolution.
24832 Move to Tentatively Ready.
24837 <p><b>Proposed resolution:</b></p>
24840 In 23.2.5 [unord.req]/9 insert:
24844 ... <tt>[q1, q2)</tt> is a valid range in <tt>a</tt>, <ins><tt>il</tt>
24845 designates an object of type <tt>initializer_list<value_type></tt>, </ins><tt>t</tt> is a value of type
24846 <tt>X::value_type</tt>, ...
24850 In 23.2.5 [unord.req], Table 87 insert:
24855 <caption>Table 87 - Unordered associative container requirements (in addition to container)</caption>
24857 <th>Expression</th> <th>Return type</th> <th>Assertion/note<br>pre-/post-condition</th> <th>Complexity</th>
24860 <td><tt>X(i, j)<br>X a(i, j)</tt></td> <td><tt>X</tt></td> <td>...</td> <td>...</td>
24863 <td><ins><tt>X(il)</tt></ins></td> <td><ins><tt>X</tt></ins></td>
24864 <td><ins>Same as <tt>X(il.begin(), il.end())</tt>.</ins></td>
24865 <td><ins>Same as <tt>X(il.begin(), il.end())</tt>.</ins></td>
24868 <td>...</td> <td>...</td> <td>...</td> <td>...</td>
24871 <td><tt>a = b</tt></td> <td><tt>X</tt></td> <td>...</td> <td>...</td>
24874 <td><ins><tt>a = il</tt></ins></td> <td><ins><tt>X&</tt></ins></td>
24875 <td><ins><tt>a = X(il); return *this;</tt></ins></td>
24876 <td><ins>Same as <tt>a = X(il)</tt>.</ins></td>
24879 <td>...</td> <td>...</td> <td>...</td> <td>...</td>
24882 <td><tt>a.insert(i, j)</tt></td> <td><tt>void</tt></td> <td>...</td> <td>...</td>
24885 <td><ins><tt>a.insert(il)</tt></ins></td> <td><ins><tt>void</tt></ins></td>
24886 <td><ins>Same as <tt>a.insert(il.begin(), il.end())</tt>.</ins></td>
24887 <td><ins>Same as <tt>a.insert(il.begin(), il.end())</tt>.</ins></td>
24898 <h3><a name="982"></a>982. Wrong complexity for initializer_list assignment in Table 85</h3>
24899 <p><b>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
24900 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-02-08 <b>Last modified:</b> 2009-05-23</p>
24901 <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>
24902 <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>
24903 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
24904 <p><b>Discussion:</b></p>
24907 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2800.pdf">N2800</a>,
24908 the associative container requirements table 85 says
24909 that assigning an <tt>initializer_list</tt> to such a container is of
24910 constant complexity, which is obviously wrong.
24919 We agree with the proposed resolution.
24922 Move to Tentatively Ready.
24927 <p><b>Proposed resolution:</b></p>
24930 In 23.2.4 [associative.reqmts], Table 85 change:
24935 <caption>Table 85 - Associative container requirements (in addition to container)</caption>
24937 <th>Expression</th> <th>Return type</th> <th>Assertion/note<br>pre-/post-condition</th> <th>Complexity</th>
24940 <td><tt>a = il</tt></td> <td><tt>X&</tt></td> <td><tt>a = X(il);<br>return *this;</tt></td>
24941 <td><del>constant</del><ins>Same as <tt>a = X(il)</tt>.</ins></td>
24952 <h3><a name="983"></a>983. <tt>unique_ptr</tt> reference deleters should not be moved from</h3>
24953 <p><b>Section:</b> 20.8.12.2 [unique.ptr.single] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
24954 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-02-10 <b>Last modified:</b> 2009-05-23</p>
24955 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unique.ptr.single">active issues</a> in [unique.ptr.single].</p>
24956 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr.single">issues</a> in [unique.ptr.single].</p>
24957 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
24958 <p><b>Discussion:</b></p>
24960 Dave brought to my attention that when a <tt>unique_ptr</tt> has a non-const reference
24961 type deleter, move constructing from it, even when the <tt>unique_ptr</tt> containing
24962 the reference is an rvalue, could have surprising results:
24965 <blockquote><pre>D d(some-state);
24966 unique_ptr<A, D&> p(new A, d);
24967 unique_ptr<A, D> p2 = std::move(p);
24968 <font color="#c80000">// has d's state changed here?</font>
24969 </pre></blockquote>
24972 I agree with him. It is the <tt>unique_ptr</tt> that is the rvalue, not the
24973 deleter. When the deleter is a reference type, the <tt>unique_ptr</tt> should
24974 respect the "lvalueness" of the deleter.
24986 Seems correct, but complicated enough that we recommend moving to Review.
24990 <p><b>Proposed resolution:</b></p>
24992 Change 20.8.12.2.1 [unique.ptr.single.ctor], p20-21
24996 <pre>template <class U, class E> unique_ptr(unique_ptr<U, E>&& u);
25002 -20- <i>Requires:</i> If <tt><del>D</del> <ins>E</ins></tt> is not a reference type,
25003 construction of the deleter <tt>D</tt> from an rvalue of type <tt>E</tt>
25004 shall be well formed and shall not throw an exception.
25006 Otherwise <tt>E</tt> is a reference type and construction of the deleter
25007 <tt>D</tt> from an lvalue of type <tt>E</tt> shall be well formed and
25008 shall not throw an exception.
25011 a reference type, then <tt>E</tt> shall be the same type as <tt>D</tt>
25012 (diagnostic required). <tt>unique_ptr<U, E>::pointer</tt> shall be
25013 implicitly convertible to <tt>pointer</tt>. [<tt>Note:</tt> These
25014 requirements imply that <tt>T</tt> and <tt>U</tt> are complete types.
25015 <i>-- end note</i>]
25019 -21- <i>Effects:</i> Constructs a <tt>unique_ptr</tt> which owns the
25020 pointer which <tt>u</tt> owns (if any). If the deleter
25021 <ins><tt>E</tt></ins> is not a reference type, <del>it</del> <ins>this
25022 deleter</ins> is move constructed from <tt>u</tt>'s deleter, otherwise
25023 <del>the reference</del> <ins>this deleter</ins> is copy constructed
25024 from <tt>u</tt>.'s deleter. After the construction, <tt>u</tt> no longer
25025 owns a pointer. [<i>Note:</i> The deleter constructor can be implemented
25026 with <tt>std::forward<<del>D</del><ins>E</ins>></tt>. <i>-- end
25034 Change 20.8.12.2.3 [unique.ptr.single.asgn], p1-3
25038 <pre>unique_ptr& operator=(unique_ptr&& u);
25043 -1- <i>Requires:</i> <ins>If the deleter <tt>D</tt> is not a reference type,</ins>
25044 <del>A</del><ins>a</ins>ssignment of the deleter <tt>D</tt> from an rvalue <tt>D</tt> shall not throw an exception.
25046 Otherwise the deleter <tt>D</tt> is a reference type,
25047 and assignment of the deleter <tt>D</tt> from an lvalue <tt>D</tt> shall not throw an exception.</ins>
25051 -2- <i>Effects:</i> reset(u.release()) followed by
25052 a<ins>n</ins> <del>move</del> assignment from <del><tt>u</tt>'s deleter to this deleter</del>
25053 <ins><tt>std::forward<D>(u.get_deleter())</tt></ins>.
25057 -3- <i>Postconditions:</i> This <tt>unique_ptr</tt> now owns the pointer
25058 which <tt>u</tt> owned, and <tt>u</tt> no longer owns it. <del>[<i>Note:</i> If
25059 <tt>D</tt> is a reference type, then the referenced lvalue deleters are
25060 move assigned. <i>-- end note</i>]</del>
25066 Change 20.8.12.2.3 [unique.ptr.single.asgn], p6-7
25070 <pre>template <class U, class E> unique_ptr& operator=(unique_ptr<U, E>&& u);
25075 <i>Requires:</i> <ins>If the deleter <tt>E</tt> is not a reference type,</ins>
25076 <del>A</del><ins>a</ins>ssignment of the deleter <tt>D</tt> from an rvalue
25077 <tt><del>D</del><ins>E</ins></tt> shall not throw an exception.
25079 Otherwise the deleter <tt>E</tt> is a reference type,
25080 and assignment of the deleter <tt>D</tt> from an lvalue <tt>E</tt> shall not throw an exception.</ins>
25081 <tt>unique_ptr<U, E>::pointer</tt> shall be implicitly convertible to <tt>pointer</tt>.
25082 [<i>Note:</i> These requirements imply that <tt>T</tt> and <tt>U></tt>
25083 are complete types. <i>-- end note</i>]
25087 <i>Effects:</i> <tt>reset(u.release())</tt> followed by
25088 a<ins>n</ins> <del>move</del> assignment from <del><tt>u</tt>'s deleter to this deleter</del>
25089 <ins><tt>std::forward<E>(u.get_deleter())</tt></ins>.
25091 <tt>D</tt> or <tt>E</tt> is a reference type, then the referenced lvalue
25092 deleter participates in the move assignment.</del>
25104 <h3><a name="984"></a>984. Does <tt><cinttypes></tt> have macro guards?</h3>
25105 <p><b>Section:</b> 27.9.2 [c.files] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
25106 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-02-12 <b>Last modified:</b> 2009-05-23</p>
25107 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
25108 <p><b>Discussion:</b></p>
25110 The C standard says about <tt><inttypes.h></tt>:
25114 C++ implementations should define these macros only when <tt>__STDC_FORMAT_MACROS</tt>is defined
25115 before <tt><inttypes.h></tt> is included.
25119 The C standard has a similar note about <tt><stdint.h></tt>. For <tt><cstdint></tt>
25120 we adopted a "thanks but no thanks" policy and documented that fact in
25121 18.4.1 [cstdint.syn]:
25125 ... [<i>Note:</i> The macros defined by <tt><stdint></tt> are
25126 provided unconditionally. In particular, the symbols
25127 <tt>__STDC_LIMIT_MACROS</tt> and <tt>__STDC_CONSTANT_MACROS</tt>
25128 (mentioned in C99 footnotes 219, 220, and 222) play no role in C++.
25129 <i>-- end note</i>]
25133 I recommend we put a similar note in 27.9.2 [c.files] regarding <tt><cinttypes></tt>.
25141 We agree with the proposed resolution.
25142 Move to Tentatively Ready.
25146 <p><b>Proposed resolution:</b></p>
25148 Add to 27.9.2 [c.files]:
25152 Table 112 describes header <tt><cinttypes></tt>.
25154 [<i>Note:</i> The macros defined by <tt><cintypes></tt> are
25155 provided unconditionally. In particular, the symbol
25156 <tt>__STDC_FORMAT_MACROS</tt>
25157 (mentioned in C99 footnote 182) plays no role in C++.
25158 <i>-- end note</i>]
25167 <h3><a name="985"></a>985. Allowing throwing move</h3>
25168 <p><b>Section:</b> 23.2.1 [container.requirements.general] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
25169 <b>Submitter:</b> Rani Sharoni <b>Opened:</b> 2009-02-12 <b>Last modified:</b> 2009-05-23</p>
25170 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements.general">active issues</a> in [container.requirements.general].</p>
25171 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements.general">issues</a> in [container.requirements.general].</p>
25172 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
25173 <p><b>Discussion:</b></p>
25175 <b>Introduction</b>
25178 <p>This proposal is meant to resolve potential regression of the
25179 <a href="" ref="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2800.pdf">N2800</a>
25181 next section, and to relax the requirements for containers of types with
25182 throwing move constructors.</p>
25184 <p>The basic problem is that some containers operations, like <tt>push_back</tt>,
25185 have a strong exception safety
25186 guarantee (i.e. no side effects upon exception) that are not achievable when
25187 throwing move constructors are used since there is no way to guarantee revert
25188 after partial move. For such operations the implementation can at most provide
25189 the basic guarantee (i.e. valid but unpredictable) as it does with multi
25190 copying operations (e.g. range insert).</p>
25192 <p>For example, <tt>vector<T>::push_back()</tt> (where <tt>T</tt> has a move
25193 constructor) might resize the <tt>vector</tt> and move the objects to the new underlying
25194 buffer. If move constructor throws it might
25195 not be possible to recover the throwing object or to move the old objects back to
25196 the original buffer.</p>
25198 <p>The current draft is explicit by disallowing throwing move
25199 for some operations (e.g. <tt>vector<>::reserve</tt>) and not clear about other
25200 operations mentioned in 23.2.1 [container.requirements.general]/10
25201 (e.g. single element <tt>insert</tt>): it guarantees strong exception
25202 safety without explicitly disallowing a throwing move constructor.
25209 <p>This section only refers to cases in which the contained object
25210 is by itself a standard container.</p>
25212 <p>Move constructors of standard containers are allowed to throw and therefore
25213 existing operations are broken, compared with C++03, due to move optimization.
25214 (In fact existing implementations like Dinkumware are actually throwing).</p>
25216 <p>For example, <tt>vector< list<int> >::reserve</tt> yields
25217 undefined behavior since <tt>list<int></tt>'s move constructor is allowed to throw.
25218 On the other hand, the same operation has strong exception safety guarantee in
25221 <p>There are few options to solve this regression:</p>
25225 Disallow throwing move and throwing default constructor
25229 Disallow throwing move but disallowing usage after move
25237 Disallow throwing move and making it optional
25242 <p>Option 1 is suggested by proposal
25243 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2815.html">N2815</a>
25244 but it might not be applicable for existing implementations for which
25245 containers default constructors are throwing.</p>
25247 <p>Option 2 limits the usage significantly and it's error prone
25248 by allowing zombie objects that are nothing but destructible (e.g. no <tt>clear()</tt>
25249 is allowed after move). It also potentially complicates the implementation by
25250 introducing special state.</p>
25252 <p>Option 3 is possible, for example, using default
25253 construction and <tt>swap</tt> instead of move for standard containers case. The
25254 implementation is also free to provide special hidden operation for non
25255 throwing move without forcing the user the cope with the limitation of option-2
25256 when using the public move.</p>
25258 <p>Option 4 impact the efficiency in all use cases due to rare throwing move.</p>
25260 <p>The proposed wording will imply option 1 or 3 though option 2 is also
25261 achievable using more wording. I personally oppose to option 2 that has impact
25265 <b>Relaxation for user types</b>
25268 <p>Disallowing throwing move constructors in general seems very restrictive
25269 since, for example, common implementation of move will be default construction
25270 + <tt>swap</tt> so move will throw if the
25271 default constructor will throw. This is currently the case with the Dinkumware
25272 implementation of node based containers (e.g. <tt>std::list</tt>)
25273 though this section doesn't refer to standard types.</p>
25275 <p>For throwing move constructors it seem that the implementation should have
25276 no problems to provide the basic guarantee instead of the strong one. It's
25277 better to allow throwing move constructors with basic guarantee than to
25278 disallow it silently (compile and run), via undefined behavior.</p>
25280 <p>There might still be cases in which the relaxation will break existing generic
25281 code that assumes the strong guarantee but it's broken either way given a
25282 throwing move constructor since this is not a preserving optimization. </p>
25290 Bjarne comments (referring to his draft paper):
25291 "I believe that my suggestion simply solves that.
25292 Thus, we don't need a throwing move."
25295 Move to Open and recommend it be deferred until after the next
25296 Committee Draft is issued.
25301 <p><b>Proposed resolution:</b></p>
25304 23.2.1 [container.requirements.general] paragraph 10 add footnote:
25309 -10- Unless otherwise specified (see 23.1.4.1, 23.1.5.1, 23.2.2.3, and
25310 23.2.6.4) all container types defined in this Clause meet the following
25311 additional requirements:
25318 <ins>[<i>Note</i>: for compatibility with C++
25319 2003, when "no effect" is required, standard containers should not use the
25320 value_type's throwing move constructor when the contained object is by itself a
25321 standard container. -- <i>end note</i>]</ins>
25326 <p>23.2.5.1 [unord.req.except] change paragraph 2 to say: </p>
25330 -2- For unordered associative containers, if an exception is
25331 thrown by any operation other than the container's hash function from within an
25332 <tt>insert()</tt> function inserting a single element, the <tt>insert()</tt>
25333 function has no effect<ins> unless the exception is thrown by the contained
25334 object move constructor</ins>.
25338 -4- For unordered associative containers, if an exception is
25339 thrown from within a <tt>rehash()</tt> function other than by the container's hash
25340 function or comparison function, the <tt>rehash()</tt> function has no effect
25341 <ins>unless the exception is thrown by the contained
25342 object move constructor</ins>.</p>
25347 23.3.2.3 [deque.modifiers] change paragraph 2 to say:
25351 -2- <i>Remarks:</i> If an exception is thrown other than by
25352 the copy constructor<ins>, move constructor</ins>
25353 or assignment operator of <tt>T</tt>
25354 there are no effects.
25355 <ins>If an exception is thrown by <tt>push_back()</tt> or <tt>emplace_back()</tt>
25356 function, that function has no effects unless the exception is thrown by
25357 the move constructor of <tt>T</tt>.</ins>
25361 23.3.2.3 [deque.modifiers] change paragraph 6 to say:
25365 -6- <i>Throws:</i> Nothing unless an exception is thrown by the copy
25366 constructor<ins>, move constructor</ins> or assignment operator of <tt>T</tt>.
25370 23.3.6.2 [vector.capacity] remove paragraph 2
25374 <del>-2- <i>Requires:</i> If <tt>value_type</tt> has a move constructor,
25375 that constructor shall not throw any exceptions.</del>
25379 23.3.6.2 [vector.capacity] paragraph 3 change to say:
25383 -3- <i>Effects:</i> A directive that informs a <tt>vector</tt>
25384 of a planned change in size, so
25385 that it can manage the storage allocation accordingly. After <tt>reserve()</tt>,
25386 <tt>capacity()</tt> is greater or equal to the argument of <tt>reserve</tt>
25387 if reallocation happens; and equal
25388 to the previous value of <tt>capacity()</tt>
25389 otherwise. Reallocation happens at this point if and only if the current
25390 capacity is less than the argument of <tt>reserve()</tt>.
25391 If an exception is thrown, there are no effects<ins>
25392 unless the exception is thrown by the contained object move constructor</ins>.
25396 23.3.6.2 [vector.capacity] paragraph 12 change to say:
25400 -12- <i>Requires:</i> <del>If <tt>value_type</tt> has a move constructor,
25401 that constructor shall not throw any exceptions.</del>
25402 <ins>If an exception is thrown, there are no effects unless the exception is thrown by
25403 the contained object move constructor.</ins>
25407 23.3.6.4 [vector.modifiers] change paragraph 1 to say:
25411 -1- <del><i>Requires:</i> If <tt>value_type</tt> has a move constructor,
25412 that constructor shall not throw any exceptions.</del>
25413 <ins><i>Remarks:</i> If an exception is thrown by <tt>push_back()</tt>
25414 or <tt>emplace_back()</tt> function, that function has no effect unless the
25415 exception is thrown by the move constructor of <tt>T</tt>.</ins>
25419 23.3.6.4 [vector.modifiers] change paragraph 2 to say:
25423 -2- <i>Remarks:</i> Causes reallocation if the new size is greater than
25424 the old capacity. If no reallocation happens, all the iterators and
25425 references before the insertion point remain valid. If an exception is
25426 thrown other than by the copy constructor<ins>, move constructor</ins>
25427 or assignment operator of <tt>T</tt> or by any <tt>InputIterator</tt>
25428 operation there are no effects.
25432 23.3.6.4 [vector.modifiers] change paragraph 6 to say:
25436 -6- <i>Throws:</i> Nothing unless an exception is thrown by the copy
25437 constructor<ins>, move constructor</ins> or assignment operator of <tt>T</tt>.
25446 <h3><a name="986"></a>986. Generic <tt>try_lock</tt> contradiction</h3>
25447 <p><b>Section:</b> 30.4.4 [thread.lock.algorithm] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
25448 <b>Submitter:</b> Chris Fairles <b>Opened:</b> 2009-02-14 <b>Last modified:</b> 2009-05-23</p>
25449 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
25450 <p><b>Discussion:</b></p>
25452 In 30.4.4 [thread.lock.algorithm], the generic <tt>try_lock</tt> effects (p2) say that a failed
25453 <tt>try_lock</tt> is when it either returns <tt>false</tt> or throws an exception. In
25454 the event a call to <tt>try_lock</tt> does fail, by either returning <tt>false</tt> or
25455 throwing an exception, it states that <tt>unlock</tt> shall be called for all
25456 prior arguments. Then the returns clause (p3) goes on to state
25457 in a note that after returning, either all locks are locked or none
25458 will be. So what happens if multiple locks fail on <tt>try_lock</tt>?
25465 <blockquote><pre>#include <mutex>
25468 std::mutex m0, m1, m2;
25469 std::unique_lock<std::mutex> l0(m0, std::defer_lock);
25470 std::unique_lock<std::mutex> l1(m1); //throws on try_lock
25471 std::unique_lock<std::mutex> l2(m2); //throws on try_lock
25473 int result = std::try_lock(l0, l1, l2);
25475 assert( !l0.owns_lock() );
25476 assert( l1.owns_lock() ); //??
25477 assert( l2.owns_lock() ); //??
25479 </pre></blockquote>
25482 The first lock's <tt>try_lock</tt> succeeded but, being a prior argument to a
25483 lock whose <tt>try_lock</tt> failed, it gets unlocked as per the effects clause
25484 of 30.4.4 [thread.lock.algorithm]. However, 2 locks remain locked in this case but the return
25485 clause states that either all arguments shall be locked or none will
25486 be. This seems to be a contradiction unless the intent is for
25487 implementations to make an effort to unlock not only prior arguments,
25488 but the one that failed and those that come after as well. Shouldn't
25489 the note only apply to the arguments that were successfully locked?
25493 Further discussion and possible resolutions in c++std-lib-23049.
25501 Move to review. Agree with proposed resolution.
25509 We agree with the proposed resolution.
25510 Move to Tentatively Ready.
25514 <p><b>Proposed resolution:</b></p>
25517 Change 30.4.4 [thread.lock.algorithm], p2:
25521 -2- <i>Effects:</i> Calls <tt>try_lock()</tt> for each argument in order
25522 beginning with the first until all arguments have been processed or a
25523 call to <tt>try_lock()</tt> fails, either by returning <tt>false</tt> or by throwing an
25524 exception. If a call to <tt>try_lock()</tt> fails, <tt>unlock()</tt> shall be called for
25525 all prior arguments<ins> and there shall be no further calls to <tt>try_lock()</tt></ins>.
25529 Delete the note from 30.4.4 [thread.lock.algorithm], p3
25533 -3- <i>Returns:</i> -1 if all calls to <tt>try_lock()</tt> returned <tt>true</tt>,
25534 otherwise a 0-based index value that indicates
25535 the argument for which <tt>try_lock()</tt> returned <tt>false</tt>. <del>[<i>Note:</i>
25536 On return, either all arguments will be
25537 locked or none will be locked. -- <i>end note</i>]</del>
25545 <h3><a name="987"></a>987. <tt>reference_wrapper</tt> and function types</h3>
25546 <p><b>Section:</b> 20.7.5 [refwrap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
25547 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-02-18 <b>Last modified:</b> 2009-05-23</p>
25548 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#refwrap">issues</a> in [refwrap].</p>
25549 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
25550 <p><b>Discussion:</b></p>
25552 The synopsis in 20.7.5 [refwrap] says:
25555 <blockquote><pre>template <<b>ObjectType</b> T> class reference_wrapper
25557 </pre></blockquote>
25560 And then paragraph 3 says:
25565 The template instantiation <tt>reference_wrapper<T></tt> shall be
25566 derived from <tt>std::unary_function<T1, R></tt> only if the type
25567 <tt>T</tt> is any of the following:
25572 a <b>function type</b> or a pointer to function type taking one argument of
25573 type <tt>T1</tt> and returning <tt>R</tt>
25579 But function types are not <tt>ObjectType</tt>s.
25583 Paragraph 4 contains the same contradiction.
25593 Jens: restricted reference to ObjectType
25601 Post Summit, Peter adds:
25607 In <a href="https://svn.boost.org/trac/boost/ticket/1846">https://svn.boost.org/trac/boost/ticket/1846</a>
25608 however Eric Niebler makes the very reasonable point that <tt>reference_wrapper<F></tt>,
25609 where <tt>F</tt> is a function type, represents a reference to a function,
25610 a legitimate entity. So <tt>boost::ref</tt> was changed to allow it.
25613 <a href="https://svn.boost.org/trac/boost/browser/trunk/libs/bind/test/ref_fn_test.cpp">https://svn.boost.org/trac/boost/browser/trunk/libs/bind/test/ref_fn_test.cpp</a>
25616 Therefore, I believe an alternative proposed resolution for issue 987 could simply
25617 allow <tt>reference_wrapper</tt> to be used with function types.
25622 Post Summit, Howard adds:
25628 I agree with Peter (and Eric). I got this one wrong on my first try. Here
25629 is code that demonstrates how easy (and useful) it is to instantiate
25630 <tt>reference_wrapper</tt> with a function type:
25633 <blockquote><pre>#include <functional>
25635 template <class F>
25644 </pre></blockquote>
25647 Output (link time error shows type of <tt>reference_wrapper</tt> instantiated
25648 with function type):
25651 <blockquote><pre>Undefined symbols:
25652 "void test<std::reference_wrapper<void ()()> >(std::reference_wrapper<void ()()>)",...
25653 </pre></blockquote>
25656 I've taken the liberty of changing the proposed wording to allow function types
25657 and set to Open. I'll also freely admit that I'm not positive <tt>ReferentType</tt>
25658 is the correct concept.
25671 Howard observed that <tt>FunctionType</tt>,
25672 a concept not (yet?) in the Working Paper,
25673 is likely the correct constraint to be applied.
25674 However, the proposed resolution provides an adequate approximation.
25682 2009-05-23 Alisdair adds:
25688 By constraining to <tt>PointeeType</tt> we rule out the ability for <tt>T</tt> to be a
25689 reference, and call in reference-collapsing. I'm not sure if this is
25690 correct and intended, but would like to be sure the case was considered.
25693 Is dis-allowing reference types and the
25694 implied reference collapsing the intended result?
25700 <p><b>Proposed resolution:</b></p>
25702 Change the synopsis in 20.7 [function.objects]:
25705 <blockquote><pre>// 20.6.5, reference_wrapper:
25706 template <<del>ObjectType</del> <ins>ReferentType</ins> T>
25707 <ins>requires PointeeType<T></ins>
25708 class reference_wrapper;
25710 template <<del>ObjectType</del> <ins>PointeeType</ins> T>
25711 reference_wrapper<T> ref(T&);
25713 template <<del>ObjectType</del> <ins>PointeeType</ins> T>
25714 reference_wrapper<const T> cref(const T&);
25716 template <<del>ObjectType</del> <ins>PointeeType</ins> T>
25717 reference_wrapper<T> ref(reference_wrapper<T>);
25718 template <<del>ObjectType</del> <ins>PointeeType</ins> T>
25719 reference_wrapper<const T> cref(reference_wrapper<T>);
25720 </pre></blockquote>
25723 Change the synopsis in 20.7.5 [refwrap]:
25726 <blockquote><pre>template <<del>ObjectType</del> <ins>ReferentType</ins> T>
25727 <ins>requires PointeeType<T></ins>
25728 class reference_wrapper
25730 </pre></blockquote>
25733 Change the prototypes in 20.7.5.5 [refwrap.helpers]:
25736 <blockquote><pre>template <<del>ObjectType</del> <ins>PointeeType</ins> T>
25737 reference_wrapper<T> ref(T&);
25739 template <<del>ObjectType</del> <ins>PointeeType</ins> T>
25740 reference_wrapper<const T> cref(const T&);
25742 template <<del>ObjectType</del> <ins>PointeeType</ins> T>
25743 reference_wrapper<T> ref(reference_wrapper<T>);
25745 template <<del>ObjectType</del> <ins>PointeeType</ins> T>
25746 reference_wrapper<const T> cref(reference_wrapper<T>);
25747 </pre></blockquote>
25751 <p><b>Rationale:</b></p>
25753 a) The occurrence of <tt>T&</tt> in the function signature auto-implies
25754 <tt>std::ReferentType</tt>,
25755 this is due to 14.11.1.2 [temp.req.impl]/4 bullet 4
25758 b) The occurrence of the constrained template <tt>reference_wrapper<T></tt> in
25760 signatures lets kick in 14.11.1.2 [temp.req.impl]/4 bullet 1 and adds *all* requirements of
25761 this template. But we need to add at least *one* requirement (and it
25763 but natural decision to require <tt>std::PointeeType</tt> here) to *activate*
25764 this. If we hadn't done
25765 this, we were in unconstrained mode!
25773 <h3><a name="988"></a>988. <tt>Reflexivity</tt> meaningless?</h3>
25774 <p><b>Section:</b> 20.2.6 [concept.comparison] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">Tentatively NAD</a>
25775 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-02-24 <b>Last modified:</b> 2009-05-23</p>
25776 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#concept.comparison">active issues</a> in [concept.comparison].</p>
25777 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#concept.comparison">issues</a> in [concept.comparison].</p>
25778 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD">Tentatively NAD</a> status.</p>
25779 <p><b>Discussion:</b></p>
25781 20.2.6 [concept.comparison] p2:
25784 Due to the subtle meaning of <tt>==</tt> inside axioms, the <tt>Reflexivity</tt> axiom does
25785 not do anything as written. It merely states that a value is substitutable
25786 with itself, rather than asserting a property of the <tt>==</tt> operator.
25790 Original proposed resolution:
25794 Change the definition of <tt>Reflexivity</tt> in 20.2.6 [concept.comparison]:
25797 <blockquote><pre>axiom Reflexivity(T a) { <ins>(</ins>a == a<ins>) == true</ins>; }
25798 </pre></blockquote>
25807 Alisdair: I was wrong.
25816 <p><b>Proposed resolution:</b></p>
25826 <h3><a name="989"></a>989. late_check and library</h3>
25827 <p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
25828 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-02-24 <b>Last modified:</b> 2009-05-23</p>
25829 <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>
25830 <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>
25831 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
25832 <p><b>Discussion:</b></p>
25834 The example in 6.9p2 shows how late_check blocks inhibit concept_map lookup
25835 inside a constrained context, and so inhibit concept map adaption by users
25836 to meet template requirements.
25839 Do we need some text in clause 17 prohibitting use of late_check in library
25840 template definitions unless otherwise documented?
25849 We need something like this, but it should be a more general statement
25850 about implementations respecting the concept maps provided by the
25851 user. Use of late_check is one way in which implementations can
25852 subvert the concept maps provided by the user, but there are other
25853 ways as well ("pattern-based" overloading, tricks with "auto" concept
25854 maps and defaulted associated type arguments).
25862 Move to Open, pending proposed wording from Alisdair and/or Doug for further review.
25866 <p><b>Proposed resolution:</b></p>
25873 <h3><a name="990"></a>990. <tt>monotonic_clock::is_monotonic</tt> must be <tt>true</tt></h3>
25874 <p><b>Section:</b> 20.9.5.2 [time.clock.monotonic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
25875 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-09 <b>Last modified:</b> 2009-05-23</p>
25876 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
25877 <p><b>Discussion:</b></p>
25879 There is some confusion over what the value of <tt>monotonic_clock::is_monotonic</tt>
25880 when <tt>monotonic_clock</tt> is a synonym for <tt>system_clock</tt>. The
25881 intent is that if <tt>monotonic_clock</tt> exists, then <tt>monotonic_clock::is_monotonic</tt>
25891 We agree with the proposed resolution.
25894 Move to Tentatively Ready.
25899 <p><b>Proposed resolution:</b></p>
25901 Change 20.9.5.2 [time.clock.monotonic], p1:
25905 -1- Objects of class <tt>monotonic_clock</tt> represent clocks for which
25906 values of <tt>time_point</tt> never decrease as physical time advances.
25907 <tt>monotonic_clock</tt> may be a synonym for <tt>system_clock</tt>
25908 <ins>if and only if <tt>system_clock::is_monotonic</tt> is
25909 <tt>true</tt></ins>.
25917 <h3><a name="991"></a>991. Response to JP 50</h3>
25918 <p><b>Section:</b> 22.3.3.2.2 [conversions.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
25919 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2009-03-03 <b>Last modified:</b> 2009-05-23</p>
25920 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#conversions.string">active issues</a> in [conversions.string].</p>
25921 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#conversions.string">issues</a> in [conversions.string].</p>
25922 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
25923 <p><b>Discussion:</b></p>
25925 Add custom allocator parameter to <tt>wstring_convert</tt>, since we cannot
25926 allocate memory for strings from a custom allocator.
25934 We agree with the proposed resolution.
25935 Move to Tentatively Ready.
25939 <p><b>Proposed resolution:</b></p>
25941 Change 22.3.3.2.2 [conversions.string]:
25944 <blockquote><pre>template<class Codecvt, class Elem = wchar_t<ins>,
25945 class Wide_alloc = std::allocator<Elem>,
25946 class Byte_alloc = std::allocator<char> </ins>> class wstring_convert {
25948 typedef std::basic_string<char<ins>, char_traits<char>, Byte_alloc</ins>> byte_string;
25949 typedef std::basic_string<Elem<ins>, char_traits<Elem>, Wide_alloc</ins>> wide_string;
25951 </pre></blockquote>
25954 Change 22.3.3.2.2 [conversions.string], p3:
25958 -3- The class template describes an ob ject that controls conversions
25959 between wide string ob jects of class
25960 <tt>std::basic_string<Elem<ins>, char_traits<Elem>, Wide_alloc</ins>></tt>
25961 and byte string objects of class
25962 <tt>std::basic_string<char<ins>, char_traits<char>, Byte_alloc</ins>></tt>
25963 <del>(also known as <tt>std::string</tt>)</del>.
25972 <h3><a name="992"></a>992. Response to UK 169</h3>
25973 <p><b>Section:</b> 17.6.1.1 [contents] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
25974 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2009-03-03 <b>Last modified:</b> 2009-05-23</p>
25975 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#contents">active issues</a> in [contents].</p>
25976 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#contents">issues</a> in [contents].</p>
25977 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
25978 <p><b>Discussion:</b></p>
25980 This phrasing contradicts later freedom to implement the C standard
25981 library portions in the global namespace as well as std. (17.6.2.3p4)
25989 The proposed wording seems to go too far.
25994 <p><b>Proposed resolution:</b></p>
25996 Change 17.6.1.1 [contents], p2:
26000 -2- All library entities except <ins>those from the Standard C
26001 library,</ins> macros, <tt>operator new</tt> and <tt>operator
26002 delete</tt> are defined within the namespace <tt>std</tt> or namespaces
26003 nested within namespace <tt>std</tt>.
26012 <h3><a name="993"></a>993. Response to UK 188</h3>
26013 <p><b>Section:</b> 18.5 [support.start.term] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
26014 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2009-03-03 <b>Last modified:</b> 2009-05-23</p>
26015 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#support.start.term">issues</a> in [support.start.term].</p>
26016 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
26017 <p><b>Discussion:</b></p>
26019 The function <tt>_Exit</tt> does not appear to be defined in this standard.
26020 Should it be added to the table of functions included-by-reference to
26025 2009-05-09 Alisdair fixed some minor issues in the wording.
26034 We agree with the proposed resolution.
26035 Move to Tentatively Ready.
26039 <p><b>Proposed resolution:</b></p>
26041 Add to 18.5 [support.start.term] Table 20 (Header
26042 <tt><cstdlib></tt> synopsis) Functions:
26045 <blockquote><pre>_Exit
26046 </pre></blockquote>
26049 Add before the description of <tt>abort(void)</tt>:
26052 <blockquote><pre>void _Exit [[noreturn]] (int status)
26057 The function <tt>_Exit(int status)</tt> has additional behavior in this
26058 International Standard:
26062 The program is terminated without executing destructors for objects of
26063 automatic, thread, or static storage duration and without calling the
26064 functions passed to <tt>atexit()</tt> (3.6.3 [basic.start.term]).
26076 <h3><a name="994"></a>994. Response to UK 193</h3>
26077 <p><b>Section:</b> 18.6.2.2 [new.handler] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
26078 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2009-03-03 <b>Last modified:</b> 2009-05-23</p>
26079 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
26080 <p><b>Discussion:</b></p>
26082 <tt>quick_exit</tt> has been added as a new valid way to terminate a program in a
26091 We agree with the proposed resolution.
26092 Move to Tentatively Ready.
26096 <p><b>Proposed resolution:</b></p>
26098 Change 18.6.2.2 [new.handler], p2:
26103 -2- <i>Required behavior:</i> ...
26108 <del>call either <tt>abort()</tt> or <tt>exit();</tt></del>
26109 <ins>terminate execution of the program without returning to the caller</ins>
26121 <h3><a name="995"></a>995. Operational Semantics Unclear</h3>
26122 <p><b>Section:</b> 17.5.1.3 [structure.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">Tentatively NAD</a>
26123 <b>Submitter:</b> David Abrahams <b>Opened:</b> 2009-03-06 <b>Last modified:</b> 2009-05-23</p>
26124 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD">Tentatively NAD</a> status.</p>
26125 <p><b>Discussion:</b></p>
26127 As a practical matter there's disagreement on the meaning of <i>operational
26128 semantics</i>. If the text in 17.5.1.3 [structure.requirements]p4 isn't
26129 clear, it should be clarified. However, it's not clear whether the
26130 disagreement is merely due to people not being aware of the text.
26138 Agree with the recommended NAD resolution.
26142 <p><b>Proposed resolution:</b></p>
26144 Recommend NAD. The text in 17.5.1.3 [structure.requirements] is
26153 <h3><a name="996"></a>996. Move operation not well specified</h3>
26154 <p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
26155 <b>Submitter:</b> David Abrahams <b>Opened:</b> 2009-03-06 <b>Last modified:</b> 2009-05-23</p>
26156 <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>
26157 <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>
26158 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
26159 <p><b>Discussion:</b></p>
26161 There are lots of places in the standard where we talk about "the move
26162 constructor" but where we mean "the move operation," i.e. <tt>T( move( x ) )</tt>.
26165 We also don't account for whether that operation modifies <tt>x</tt> or not, and
26174 Move to Open, pending proposed wording from Dave for further
26179 <p><b>Proposed resolution:</b></p>
26188 <h3><a name="997"></a>997. Response to UK 163</h3>
26189 <p><b>Section:</b> 17.5.1.4 [structure.specifications] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
26190 <b>Submitter:</b> Thomas Plum <b>Opened:</b> 2009-03-03 <b>Last modified:</b> 2009-05-23</p>
26191 <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>
26192 <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>
26193 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
26194 <p><b>Discussion:</b></p>
26196 Many functions are defined as "Effects: Equivalent to a...", which seems
26197 to also define the preconditions, effects, etc. But this is not made
26202 After studying the occurrences of "Effects: Equivalent to", I agree with
26203 the diagnosis but disagree with the solution. In 21.4.2 [string.cons]
26209 14 <i>Effects:</i> If <tt>InputIterator</tt> is an integral type, equivalent to
26210 <tt>basic_string(static_cast<size_type>(begin), static_cast<value_type>(end), a)</tt>
26213 15 Otherwise constructs a string from the values in the range <tt>[begin,
26214 end)</tt>, as indicated in the Sequence Requirements table (see 23.1.3).
26219 This would be devishly difficult to re-write with an explicit
26220 "Equivalent to:" clause. Instead, I propose the following, which will
26221 result in much less editorial re-work.
26225 2009-05-09 Alisdair adds:
26230 This issue is related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#492">492</a>.
26238 We agree with the proposed resolution.
26239 Move to Tentatively Ready.
26243 <p><b>Proposed resolution:</b></p>
26245 Add a new paragraph after 17.5.1.4 [structure.specifications], p3:
26250 -3- Descriptions of function semantics contain the following elements (as appropriate):<sup>154</sup>
26255 <i>Requires:</i> the preconditions for calling the function
26258 <i>Effects:</i> the actions performed by the function
26261 <i>Postconditions:</i> the observable results established by the function
26264 <i>Returns:</i> a description of the value(s) returned by the function
26267 <i>Throws:</i> any exceptions thrown by the function, and the conditions that would cause the exception
26270 <i>Complexity:</i> the time and/or space complexity of the function
26273 <i>Remarks:</i> additional semantic constraints on the function
26276 <i>Error conditions:</i> the error conditions for error codes reported by the function.
26279 <i>Notes:</i> non-normative comments about the function
26284 Whenever the <i>Effects</i> element specifies that the semantics of some
26285 function <tt>F</tt> are <i>Equivalent to</i> some <i>code-sequence</i>, then
26286 the various elements are interpreted as follows. If <tt>F</tt>'s
26287 semantics specifies a <i>Requires</i> element, then that requirement is
26288 logically imposed prior to the <i>equivalent-to</i> semantics. Then,
26289 the semantics of the <i>code-sequence</i> are determined by the
26290 <i>Requires</i>, <i>Effects</i>, <i>Postconditions</i>, <i>Returns</i>,
26291 <i>Throws</i>, <i>Complexity</i>, <i>Remarks</i>, <i>Error
26292 Conditions</i> and <i>Notes</i> specified for the (one or more) function
26293 invocations contained in the <i>code-sequence</i>. The value returned from
26294 <tt>F</tt> is specified by <tt>F</tt>'s <i>Returns</i> element, or
26295 if <tt>F</tt> has no <i>Returns</i> element, a non-<tt>void</tt> return from <tt>F</tt> is specified
26296 by the <i>Returns</i> elements in <i>code-sequence</i>. If
26297 <tt>F</tt>'s semantics contains a <i>Throws</i> (or
26298 <i>Postconditions</i>, or <i>Complexity</i>) element, then that
26299 supersedes any occurrences of that element in the <i>code-sequence</i>.
26309 <h3><a name="998"></a>998. Smart pointer referencing its owner</h3>
26310 <p><b>Section:</b> 20.8.12.2.5 [unique.ptr.single.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
26311 <b>Submitter:</b> Pavel Minaev <b>Opened:</b> 2009-02-26 <b>Last modified:</b> 2009-05-23</p>
26312 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unique.ptr.single.modifiers">active issues</a> in [unique.ptr.single.modifiers].</p>
26313 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr.single.modifiers">issues</a> in [unique.ptr.single.modifiers].</p>
26314 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
26315 <p><b>Discussion:</b></p>
26317 Consider the following (simplified) implementation of
26318 <tt>std::auto_ptr<T>::reset()</tt>:
26321 <blockquote><pre>void reset(T* newptr = 0) {
26322 if (this->ptr && this->ptr != newptr) {
26323 delete this->ptr;
26325 this->ptr = newptr;
26327 </pre></blockquote>
26330 Now consider the following code which uses the above implementation:
26333 <blockquote><pre>struct foo {
26334 std::auto_ptr<foo> ap;
26335 foo() : ap(this) {}
26336 void reset() { ap.reset(); }
26339 (new foo)->reset();
26341 </pre></blockquote>
26344 With the above implementation of auto_ptr, this results in U.B. at the
26345 point of auto_ptr::reset(). If this isn't obvious yet, let me explain
26346 how this goes step by step:
26351 <tt>foo::reset()</tt> entered
26354 <tt>auto_ptr::reset()</tt> entered
26357 <tt>auto_ptr::reset()</tt> tries to delete <tt>foo</tt>
26360 <tt>foo::~foo()</tt> entered, tries to destruct its members
26363 <tt>auto_ptr::~auto_ptr()</tt> executed - <tt>auto_ptr</tt> is no longer a valid object!
26366 <tt>foo::~foo()</tt> left
26369 <tt>auto_ptr::reset()</tt> sets its "ptr" field to 0 <- U.B.! <tt>auto_ptr</tt>
26370 is not a valid object here already!
26375 Thanks to Peter Dimov who recognized the connection to <tt>unique_ptr</tt> and
26376 brought this to the attention of the LWG, and helped with the solution.
26386 To fix this behavior <tt>reset</tt> must be specified such that deleting the
26387 pointer is the last action to be taken within <tt>reset</tt>.
26397 The example providing the rationale for LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#998">998</a> is poor, as it relies on
26398 broken semantics of having two object believing they are unique owners of a
26399 single resource. It should not be surprising that UB results from such
26400 code, and I feel no need to go out of our way to support such behaviour.
26403 If an example is presented that does not imply multiple ownership of a
26404 unique resource, I would be much more ready to accept the proposed
26418 This issue has to do with circular ownership,
26419 and affects <tt>auto_ptr</tt>, too (but we don't really care about that).
26420 It is intended to spell out the order in which operations must be performed
26421 so as to avoid the possibility
26422 of undefined behavior in the self-referential case.
26425 Howard points to message c++std-lib-23175 for another example,
26426 requested by Alisdair.
26429 We agree with the issue and with the proposed resolution.
26430 Move to Tentatively Ready.
26436 <p><b>Proposed resolution:</b></p>
26438 Change 20.8.12.2.5 [unique.ptr.single.modifiers], p5 (<i>Effects</i> clause for <tt>reset</tt>), and p6:
26443 -5- <i>Effects:</i> <del>If <tt>get() == nullptr</tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>.</del>
26444 <ins>Assigns <tt>p</tt> to the stored <tt>pointer</tt>, and then if the old value of the <tt>pointer</tt> is not
26445 equal to <tt>nullptr</tt>, calls <tt>get_deleter()(</tt>the old value of the <tt>pointer)</tt>.
26446 [<i>Note:</i> The order of these operations is significant because the call to <tt>get_deleter()</tt>
26447 may destroy <tt>*this</tt>. <i>-- end note</i>]</ins>
26451 -6- Postconditions: <tt>get() == p</tt>.
26452 <ins>[<i>Note:</i> The postcondition does not hold if the call to
26453 <tt>get_deleter()</tt> destroys <tt>*this</tt> since <tt>this->get()</tt> is no longer a valid
26454 expression. <i>-- end note</i>]</ins>
26463 <h3><a name="999"></a>999. Taking the address of a function</h3>
26464 <p><b>Section:</b> 20.8.11.1 [object.addressof] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
26465 <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2009-03-09 <b>Last modified:</b> 2009-05-23</p>
26466 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#object.addressof">active issues</a> in [object.addressof].</p>
26467 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#object.addressof">issues</a> in [object.addressof].</p>
26468 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
26469 <p><b>Discussion:</b></p>
26471 The same fix (reference <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#987">987</a>) may be applied to <tt>addressof</tt>, which is also constrained to
26472 <tt>ObjectType</tt>. (That was why <tt>boost::ref</tt> didn't work with functions - it
26473 tried to apply <tt>boost::addressof</tt> and the <tt>reinterpret_cast<char&></tt>
26474 implementation of <tt>addressof</tt> failed.)
26488 Move to Tentatively Ready.
26494 <p><b>Proposed resolution:</b></p>
26496 Change the synopsis in 20.8 [memory]:
26499 <blockquote><pre>template <<del>ObjectType</del> <ins>PointeeType</ins> T>
26500 T* addressof(T& r);
26501 </pre></blockquote>
26504 Change 20.8.11.1 [object.addressof]:
26507 <blockquote><pre>template <<del>ObjectType</del> <ins>PointeeType</ins> T>
26508 T* addressof(T& r);
26509 </pre></blockquote>
26512 <p><b>Rationale:</b></p>
26514 a) The occurrence of <tt>T&</tt> in the function signature auto-implies
26515 <tt>std::ReferentType</tt>,
26516 this is due to 14.11.1.2 [temp.req.impl]/4 bullet 4
26524 <h3><a name="1000"></a>1000. adjacent_find is over-constrained</h3>
26525 <p><b>Section:</b> 25.3.8 [alg.adjacent.find] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
26526 <b>Submitter:</b> Chris Jefferson <b>Opened:</b> 2009-03-09 <b>Last modified:</b> 2009-03-13</p>
26527 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.adjacent.find">issues</a> in [alg.adjacent.find].</p>
26528 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
26529 <p><b>Discussion:</b></p>
26531 <b>Addresses UK 296</b>
26535 <tt>adjacent_find</tt> in C++03 allows an arbitrary predicate, but in C++0x
26536 <tt>EqualityComparable/EquivalenceRelation</tt> is required. This forbids a
26537 number of use cases, including:
26543 <tt>adjacent_find(begin, end, less<double>)</tt>
26547 place where a range is not ordered in decreasing order - in use to check
26553 <tt>adjacent_find(begin, end, DistanceBiggerThan(6) ) )</tt>
26557 place in a range where values differ by more than a given value - in use
26558 to check an algorithm which produces points in space does not generate
26559 points too far apart.
26566 A number of books use predicate which are not equivalence relations in
26567 examples, including "Thinking in C++" and "C++ Primer".
26571 Adding the requirement that the predicate is an <tt>EquivalenceRelation</tt>
26572 does not appear to open up any possibility for a more optimised algorithm.
26577 <p><b>Proposed resolution:</b></p>
26579 Change the definition of adjacent_find in the synopsis of 25 [algorithms]
26580 and 25.3.8 [alg.adjacent.find] to:
26583 <blockquote><pre>template<ForwardIterator Iter>
26584 requires <del>EqualityComparable</del><ins>HasEqualTo</ins><Iter::value_type<ins>, Iter::value_type</ins>>
26585 Iter adjacent_find(Iter first, Iter last);
26587 template<ForwardIterator Iter, <del>EquivalenceRelation</del><ins>Predicate</ins><auto, Iter::value_type<ins>, Iter::value_type</ins>> Pred>
26588 requires CopyConstructible<Pred>
26589 Iter adjacent_find(Iter first, Iter last, Pred pred);
26590 </pre></blockquote>
26597 <h3><a name="1001"></a>1001. Pointers, concepts and headers</h3>
26598 <p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
26599 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-10 <b>Last modified:</b> 2009-06-16</p>
26600 <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>
26601 <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>
26602 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
26603 <p><b>Discussion:</b></p>
26605 <p><b>Addresses UK 78</b></p>
26608 Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1063">1063</a>.
26612 This is effectively an extension of LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#343">343</a>.
26615 We know there is an increasing trend (encouraged by conformance testers and
26616 some users) that each library header should supply no more than required to
26617 satisfy the synopsis in the standard. This is typically achieved by
26618 breaking larger headers into smaller subsets, and judicious use of forward
26622 If we apply this policy to C++0x (per
26623 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2800.pdf">N2800</a>)
26624 it will be very surprising for
26625 people using library algorithms over ranges defined by pointers that they
26626 must <tt>#include <iterator_concepts></tt> for their code to compile again. That is
26627 because pointers do not satisfy any of the iterator concepts without the
26628 <tt>concept_map</tt> supplied in this header.
26631 Therefore, I suggest we should require all library headers that make use of
26632 iterator concepts are specifically required to <tt>#include <iterator_concepts></tt>.
26635 At a minimum, the list of headers would be: (assuming all are constrained by
26638 <blockquote><pre>algorithm
26647 memory // if <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1029">1029</a> is adopted
26659 </pre></blockquote>
26668 The same problems exists for <tt><memory_concepts></tt> and
26669 <tt><container_concepts></tt>.
26672 In order to compile <tt><vector></tt> you just need the
26673 definitions of the concepts in <tt><memory_concepts></tt>, the
26674 concept maps defined there are not necessary. Yet, from the user point
26675 of view, if the concept map template for <tt>AllocatableElement</tt> are
26676 not in scope, <tt><vector></tt> is pretty useless. Same for
26677 <tt><tuple></tt> and <tt>ConstructibleWithAllocator</tt>.
26680 Similarly, <tt><queue></tt> is not very useful if the concept map
26681 template for <tt>QueueLikeContainer</tt> is not in scope, although the
26682 definition of concept alone is theoretically sufficient.
26685 There's a pattern here: if a concept has concept maps "attached", they
26686 should never be separated.
26691 Beman provided the proposed resolution for the May 2009 mailing. He
26698 <p>Initially I tried to specify exactly what header should include what other
26699 headers. This was verbose, error prone, hard to maintain, and appeared to add
26700 little value compared to just stating the general rule.</p>
26710 Pete believes the proposed wording overconstrains implementers.
26711 Instead of specifying the mechanism,
26712 he prefers a solution that spells out what needs to be declared,
26713 rather than how those declarations are to be provided,
26717 A C++ header shall provide the names
26718 that are required to be defined in that header.
26721 Bill suggests approaching the wording from a programmer's perspective.
26722 We may want to consider promising that certain widely-used headers
26723 (e.g., the concept headers) are included when needed by other headers.
26724 He feels, however, there is nothing broken now,
26725 although we may want to consider "something nicer."
26728 Move to Open status.
26734 2009-06-16 Beman updated the proposed resolution:
26740 <li>The mechanism is no longer specified, as requested in Batavia.</li>
26741 <li>The footnote has been removed since it specified mechanism and also did
26742 not reflect existing practice.</li>
26743 <li>A sentence was added that makes it clear that the existing practice is
26750 <p><b>Proposed resolution:</b></p>
26751 <p><i>Change 17.6.4.2 [res.on.headers], Headers, paragraph 1, as indicated:</i></p>
26754 header shall provide definitions for any names that appear in its synopsis (3.2 [basic.def.odr]).</ins>
26755 A C++ header may include other C++ headers.<del><sup>[footnote]</sup></del> <ins>A C++
26756 header shown in its synopsis as including other C++ headers shall provide
26757 definitions for the same names as if those other headers were included. A C++ header that uses a
26758 concept (14.10 [concept]) shall provide the definition for that concept as if it included the C++ header
26759 that defines that concept in its synopsis. The mechanism and ordering of such
26760 definitions is unspecified.</ins></p>
26762 <p><ins>[<i>Example:</i> If C++ header <code><a></code> contains a concept
26763 defined in C++ header <code><b></code>, and header <code><b></code> contains a
26764 concept defined in C++ header <code><c></code>, then inclusion of <code><a></code>
26765 is equivalent to inclusion of <code><a></code>, <code><b></code>, and <code>
26766 <c></code>. <i>— end example</i>]</ins></p>
26768 <p><del><sup>[footnote]</sup> C++ headers must include a C++ header that contains
26769 any needed definition (3.2).</del></p>
26778 <h3><a name="1002"></a>1002. Response to UK 170</h3>
26779 <p><b>Section:</b> 17.6.1.2 [headers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
26780 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-05-23</p>
26781 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#headers">issues</a> in [headers].</p>
26782 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
26783 <p><b>Discussion:</b></p>
26785 <p><b>Addresses UK 170</b></p>
26788 One of goals of C++0x is to make language easier to teach and for
26789 'incidental' programmers. The fine-grained headers of the C++ library
26790 are valuable in large scale systems for managing dependencies and
26791 optimising build times, but overcomplicated for simple development and
26792 tutorials. Add additional headers to support the whole library through a
26793 single include statement.
26801 We do not all agree that this is an issue,
26802 but we agree that if it needs solving this is the right way to do it.
26803 Move to Tentatively Ready.
26807 <p><b>Proposed resolution:</b></p>
26809 Insert a new paragraph in 17.6.1.2 [headers] between p4 and p5
26812 An additional header <tt><std></tt> shall have the effect of
26813 supplying the entire standard library. [<i>Note:</i> for example, it
26814 might be implemented as a file with an <tt>#include</tt> statement for each of the
26815 headers listed in tables 13 and 14. <i>-- end note</i>]
26823 <h3><a name="1003"></a>1003. Response to JP 23</h3>
26824 <p><b>Section:</b> 17.6.1.3 [compliance] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
26825 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-05-23</p>
26826 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#compliance">active issues</a> in [compliance].</p>
26827 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#compliance">issues</a> in [compliance].</p>
26828 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
26829 <p><b>Discussion:</b></p>
26831 <p><b>Addresses JP 23</b></p>
26834 There is a freestanding implementation including
26835 <tt><type_traits></tt>, <tt><array></tt>,
26836 <tt><ratio></tt>, lately added to Table 13, C++ library headers.
26837 Programmers think them useful and hope that these headers are also added
26838 to Table 15, C++ headers for freestanding implementations, that shows
26839 the set of headers which a freestanding implementation shall include at
26843 <p><b>Original proposed resolution</b></p>
26846 Add <tt><type_traits></tt>, <tt><array></tt>,
26847 <tt><ratio></tt> to Table 15.
26857 The <tt><array></tt> header has far too many dependencies to require for a
26858 free-standing implementation.
26861 The <tt><ratio></tt> header would be useful, has no dependencies, but is not
26862 strictly necessary.
26865 The <tt><type_traits></tt> header is fundamentally a core language facility with a
26866 library interface, so should be supported.
26870 (it is anticipated the resolution will come via an update to paper
26871 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2814.pdf">N2814</a>)
26872 (see also LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#833">833</a>)
26881 Leave in Review status pending a paper on freestanding implementations
26886 <p><b>Proposed resolution:</b></p>
26888 Add <tt><type_traits></tt> to Table 15.
26897 <h3><a name="1004"></a>1004. Response to UK 179</h3>
26898 <p><b>Section:</b> 17.6.3.8 [res.on.functions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
26899 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-05-23</p>
26900 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#res.on.functions">issues</a> in [res.on.functions].</p>
26901 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
26902 <p><b>Discussion:</b></p>
26904 <p><b>Addresses UK 179</b></p>
26907 According to the 4th bullet there is a problem if "if any replacement
26908 function or handler function or destructor operation throws an
26909 exception". There should be no problem throwing exceptions so long as
26910 they are caught within the function.
26918 The phrasing "throws an exception" is commonly used elsewhere
26919 to mean "throws or propagates an exception."
26920 Move to Open pending a possible more general resolution.
26924 <p><b>Proposed resolution:</b></p>
26926 Change the 4th bullet of 17.6.3.8 [res.on.functions], p2:
26932 if any replacement function or handler function or destructor operation
26933 <del>throws</del> <ins>propagates</ins> an exception, unless specifically
26934 allowed in the applicable <i>Required behavior:</i> paragraph.
26945 <h3><a name="1005"></a>1005. Response to JP 26</h3>
26946 <p><b>Section:</b> 18.3.1.1 [numeric.limits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
26947 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-05-25</p>
26948 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
26949 <p><b>Discussion:</b></p>
26951 <p><b>Addresses JP 26</b></p>
26954 <tt>numeric_limits</tt> [partial specializations] does not use concept.
26963 Alisdair will provide a soltion as part of treatment of axioms and LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#902">902</a>.
26972 Alisdair recommends NAD as the partial specializations are already
26973 constrained by requirements on the primary template.
26981 The Working Draft does not in general repeat a primary template's constraints
26982 in any specializations.
26987 2009-05-25 Howard adds:
26992 A c++std-lib thread starting at c++std-lib-23880 has cast doubt that NAD is the
26993 correct resolution of this issue. Indeed the discussion also casts doubt that
26994 the current proposed wording is the correct resolution as well. Personally I'm
26995 inclined to reset the status to Open. However I'm reverting the status to
26996 that which it had prior to the Batavia recommendation. I'm setting back to Review.
27000 <p><b>Proposed resolution:</b></p>
27002 Change 18.3.1.1 [numeric.limits]:
27005 <blockquote><pre>template<<del>class</del> <ins>Regular</ins> T> class numeric_limits<const T>;
27006 template<<del>class</del> <ins>Regular</ins> T> class numeric_limits<volatile T>;
27007 template<<del>class</del> <ins>Regular</ins> T> class numeric_limits<const volatile T>;
27008 </pre></blockquote>
27016 <h3><a name="1006"></a>1006. Response to UK 190</h3>
27017 <p><b>Section:</b> 18.6.1 [new.delete] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
27018 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-05-23</p>
27019 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#new.delete">issues</a> in [new.delete].</p>
27020 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
27021 <p><b>Discussion:</b></p>
27023 <p><b>Addresses UK 190</b></p>
27026 It is not entirely clear how the current specification acts in the
27027 presence of a garbage collected implementation.
27040 2009-05-09 Alisdair adds:
27045 Proposed wording is too strict for implementations that do not support
27046 garbage collection. Updated wording supplied.
27054 We recommend advancing this to Tentatively Ready
27055 with the understanding that it will not be moved for adoption
27056 unless and until the proposed resolution to Core issue #853 is adopted.
27060 <p><b>Proposed resolution:</b></p>
27063 (Editorial note: This wording ties into the proposed
27064 resolution for Core #853)
27068 Add paragraphs to 18.6.1.1 [new.delete.single]:
27071 <blockquote><pre>void operator delete(void* ptr) throw();
27072 <del>void operator delete(void* ptr, const std::nothrow_t&) throw();</del>
27076 The second signature deletion above is editorial.
27082 <i>Requires:</i> If an implementation has strict pointer safety
27083 (3.7.4.3 [basic.stc.dynamic.safety]) then <tt>ptr</tt> shall
27084 be a safely-derived pointer.
27090 <pre>void operator delete(void* ptr, const std::nothrow_t&) throw();
27095 <i>Requires:</i> If an implementation has strict pointer safety
27096 (3.7.4.3 [basic.stc.dynamic.safety]) then <tt>ptr</tt> shall
27097 be a safely-derived pointer.
27106 Add paragraphs to 18.6.1.2 [new.delete.array]:
27109 <blockquote><pre>void operator delete[](void* ptr) throw();
27110 <del>void operator delete[](void* ptr, const std::nothrow_t&) throw();</del>
27114 The second signature deletion above is editorial.
27120 <i>Requires:</i> If an implementation has strict pointer safety
27121 (3.7.4.3 [basic.stc.dynamic.safety]) then <tt>ptr</tt> shall
27122 be a safely-derived pointer.
27128 <pre>void operator delete[](void* ptr, const std::nothrow_t&) throw();
27133 <i>Requires:</i> If an implementation has strict pointer safety
27134 (3.7.4.3 [basic.stc.dynamic.safety]) then <tt>ptr</tt> shall
27135 be a safely-derived pointer.
27145 Add paragraphs to 18.6.1.3 [new.delete.placement]:
27148 <blockquote><pre>void operator delete(void* ptr, void*) throw();
27153 <i>Requires:</i> If an implementation has strict pointer safety
27154 (3.7.4.3 [basic.stc.dynamic.safety]) then <tt>ptr</tt> shall
27155 be a safely-derived pointer.
27161 <pre>void operator delete[](void* ptr, void*) throw();
27166 <i>Requires:</i> If an implementation has strict pointer safety
27167 (3.7.4.3 [basic.stc.dynamic.safety]) then <tt>ptr</tt> shall
27168 be a safely-derived pointer.
27182 <h3><a name="1007"></a>1007. Response to JP 29</h3>
27183 <p><b>Section:</b> 18.8.6 [except.nested] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
27184 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-03-13</p>
27185 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#except.nested">active issues</a> in [except.nested].</p>
27186 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#except.nested">issues</a> in [except.nested].</p>
27187 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
27188 <p><b>Discussion:</b></p>
27190 <p><b>Addresses JP 29</b></p>
27193 <tt>throw_with_nested</tt> does not use concept.
27207 <p><b>Proposed resolution:</b></p>
27210 Alisdair initially proposed wording in
27211 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2619.pdf">N2619</a>.
27214 We are awaiting an updated paper based on feedback from the San Francisco
27223 <h3><a name="1008"></a>1008. Response to JP 31</h3>
27224 <p><b>Section:</b> 18.8.6 [except.nested] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
27225 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-03-13</p>
27226 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#except.nested">active issues</a> in [except.nested].</p>
27227 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#except.nested">issues</a> in [except.nested].</p>
27228 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
27229 <p><b>Discussion:</b></p>
27231 <p><b>Addresses JP 31</b></p>
27234 It is difficult to understand in which case <tt>nested_exception</tt> is applied.
27243 Alisdair will add an example in an update to
27244 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2619.pdf">N2619</a>.
27249 <p><b>Proposed resolution:</b></p>
27256 <h3><a name="1009"></a>1009. Response to UK 251</h3>
27257 <p><b>Section:</b> 24.2.1 [iterator.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
27258 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-03-22</p>
27259 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
27260 <p><b>Discussion:</b></p>
27262 <p><b>Addresses UK 251</b></p>
27265 The post-increment operator is dangerous for a general InputIterator.
27266 The multi-pass guarantees that make it meaningful are defined as part of
27267 the ForwardIterator refinement. Any change will affect only constrained
27268 templates that have not yet been written, so should not break existing
27269 user iterators which remain free to add these operations. This change
27270 will also affect the generalised OutputIterator, although there is no
27271 percieved need for the post-increment operator in this case either.
27276 <p><b>Proposed resolution:</b></p>
27278 Change 24.2.1 [iterator.iterators]:
27281 <blockquote><pre>concept Iterator<typename X> : Semiregular<X> {
27282 MoveConstructible reference = typename X::reference;
27283 <del>MoveConstructible postincrement_result;</del>
27285 <del>requires HasDereference<postincrement_result>;</del>
27287 reference operator*(X&&);
27288 X& operator++(X&);
27289 <del>postincrement_result operator++(X&, int);</del>
27294 <pre><del>postincrement_result operator++(X& r, int);</del>
27298 <del>-3- <i>Effects:</i> equivalent to <tt>{ X tmp = r; ++r; return tmp; }</tt>.</del>
27304 Change 24.2.2 [input.iterators]:
27308 <pre>concept InputIterator<typename X> : Iterator<X>, EqualityComparable<X> {
27309 ObjectType value_type = typename X::value_type;
27310 MoveConstructible pointer = typename X::pointer;
27312 SignedIntegralLike difference_type = typename X::difference_type;
27314 requires IntegralType<difference_type>
27315 && Convertible<reference, const value_type &>;
27316 && Convertible<pointer, const value_type*>;
27318 <del>requires Convertible<HasDereference<postincrement_result>::result_type, const value_type&>;</del>
27320 pointer operator->(const X&);
27326 Change 24.2.3 [output.iterators]:
27330 <pre>auto concept OutputIterator<typename X, typename Value> {
27331 requires Iterator<X>;
27333 typename reference = Iterator<X>::reference;
27334 <del>typename postincrement_result = Iterator<X>::postincrement_result;</del>
27335 requires SameType<reference, Iterator<X>::reference>
27336 <del>&& SameType<postincrement_result, Iterator<X>::postincrement_result></del>
27337 <del>&& Convertible<postincrement_result, const X&></del>
27338 && HasAssign<reference, Value>
27339 <del>&& HasAssign<HasDereference<postincrement_result>::result_type, Value></del>;
27345 Change 24.2.4 [forward.iterators]:
27349 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1084">1084</a> which is attempting to change this same area in a compatible
27355 <pre>concept ForwardIterator<typename X> : InputIterator<X>, Regular<X> {
27356 <del>requires Convertible<postincrement_result, const X&>;</del>
27358 <ins>MoveConstructible postincrement_result;</ins>
27359 <ins>requires HasDereference<postincrement_result>
27360 && Convertible<HasDereference<postincrement_result>::result_type, const value_type&>;</ins>
27362 <ins>postincrement_result operator++(X&, int);</ins>
27364 axiom MultiPass(X a, X b) {
27365 if (a == b) *a == *b;
27366 if (a == b) ++a == ++b;
27375 <pre><ins>postincrement_result operator++(X& r, int);</ins>
27380 <ins>-5- <i>Effects:</i> equivalent to <tt>{ X tmp = r; ++r; return tmp; }</tt>.</ins>
27392 <h3><a name="1010"></a>1010. Response to UK 263</h3>
27393 <p><b>Section:</b> 24.2.6 [random.access.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
27394 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-05-23</p>
27395 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#random.access.iterators">active issues</a> in [random.access.iterators].</p>
27396 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#random.access.iterators">issues</a> in [random.access.iterators].</p>
27397 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
27398 <p><b>Discussion:</b></p>
27400 <p><b>Addresses UK 263</b></p>
27403 This requirement on <tt>operator-=</tt> would be better expressed as a default
27404 implementation in the concept, with a matching axiom.
27412 The proposed resolution should also remove
27413 paragraph 5 and the declaration that precedes it.
27414 Further, we should provide an axiom
27415 that captures the desired semantics.
27416 This may be a broader policy to be applied.
27421 <p><b>Proposed resolution:</b></p>
27423 Change 24.2.6 [random.access.iterators]:
27426 <blockquote><pre>concept RandomAccessIterator<typename X> : BidirectionalIterator<X>, LessThanComparable<X> {
27428 X& operator-=(X& <ins>x</ins>, difference_type <ins>n</ins>)<ins> { return x += -n</ins>;<ins> }</ins>
27431 </pre></blockquote>
27439 <h3><a name="1011"></a>1011. Response to UK 271</h3>
27440 <p><b>Section:</b> 24.4 [iterator.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
27441 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-05-23</p>
27442 <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>
27443 <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>
27444 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
27445 <p><b>Discussion:</b></p>
27447 <p><b>Addresses UK 271</b></p>
27450 <tt>next/prev</tt> return an incremented iterator without changing the value of
27451 the original iterator. However, even this may invalidate an
27452 <tt>InputIterator</tt>. A <tt>ForwardIterator</tt> is required to guarantee the
27453 'multipass' property.
27461 We agree with the proposed resolution.
27462 Move to Tentatively Ready.
27466 <p><b>Proposed resolution:</b></p>
27468 Change [iterator.synopsis]:
27471 <blockquote><pre>template <<del>InputIterator</del> <ins>ForwardIterator</ins> Iter>
27473 Iter::difference_type n = 1);
27474 </pre></blockquote>
27477 Change 24.4 [iterator.operations], p6:
27480 <blockquote><pre>template <<del>InputIterator</del> <ins>ForwardIterator</ins> Iter>
27482 Iter::difference_type n = 1);
27483 </pre></blockquote>
27491 <h3><a name="1012"></a>1012. Response to UK 277</h3>
27492 <p><b>Section:</b> 24.5.1.2.1 [reverse.iter.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
27493 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-05-23</p>
27494 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
27495 <p><b>Discussion:</b></p>
27497 <p><b>Addresses UK 277</b></p>
27500 The default constructor default-initializes current, rather than
27501 value-initializes. This means that when Iterator corresponds to a
27502 trivial type, the current member is left un-initialized, even when the
27503 user explictly requests value intialization! At this point, it is not
27504 safe to perform any operations on the reverse_iterator other than assign
27505 it a new value or destroy it. Note that this does correspond to the
27506 basic definition of a singular iterator.
27515 Agree with option i.
27519 Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#408">408</a>
27527 We believe this should be revisited
27528 in conjunction with issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#408">408</a>,
27529 which nearly duplicates this issue.
27534 <p><b>Proposed resolution:</b></p>
27536 Change [reverse.iter.con]:
27539 <blockquote><pre>reverse_iterator();
27542 -1- <i>Effects:</i> <del>Default</del> <ins>Value</ins> initializes <tt>current</tt>. Iterator
27543 operations applied to the resulting iterator have defined behavior if and
27544 only if the corresponding operations are defined on a default constructed
27545 iterator of type <tt>Iterator</tt>.
27550 Change 24.5.3.2.1 [move.iter.op.const]:
27553 <blockquote><pre>move_iterator();
27556 -1- <i>Effects:</i> Constructs a <tt>move_iterator</tt>, <del>default</del> <ins>value</ins>
27557 initializing <tt>current</tt>.
27567 <h3><a name="1013"></a>1013. Response to UK 305</h3>
27568 <p><b>Section:</b> 25.5.7 [alg.min.max] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
27569 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-05-23</p>
27570 <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>
27571 <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>
27572 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
27573 <p><b>Discussion:</b></p>
27575 <p><b>Addresses UK 305</b></p>
27578 The negative requirement on <tt>IsSameType</tt> is a hold-over from an earlier
27579 draught with a variadic template form of <tt>min/max</tt> algorith. It is no
27588 We agree with the proposed resolution.
27589 Move to Tentatively Ready.
27593 <p><b>Proposed resolution:</b></p>
27595 Change 25 [algorithms]:
27598 <blockquote><pre>template<class T, StrictWeakOrder<auto, T> Compare>
27599 <del>requires !SameType<T, Compare> && CopyConstructible<Compare></del>
27600 const T& min(const T& a, const T& b, Compare comp);
27602 template<class T, StrictWeakOrder<auto, T> Compare>
27603 <del>requires !SameType<T, Compare> && CopyConstructible<Compare></del>
27604 const T& max(const T& a, const T& b, Compare comp);
27606 template<class T, StrictWeakOrder<auto, T> Compare>
27607 <del>requires !SameType<T, Compare> && CopyConstructible<Compare></del>
27608 pair<const T&, const T&> minmax(const T& a, const T& b, Compare comp);
27609 </pre></blockquote>
27612 Change 25.5.7 [alg.min.max], p1, p9 and p17:
27615 <blockquote><pre>template<class T, StrictWeakOrder<auto, T> Compare>
27616 <del>requires !SameType<T, Compare> && CopyConstructible<Compare></del>
27617 const T& min(const T& a, const T& b, Compare comp);
27619 template<class T, StrictWeakOrder<auto, T> Compare>
27620 <del>requires !SameType<T, Compare> && CopyConstructible<Compare></del>
27621 const T& max(const T& a, const T& b, Compare comp);
27623 template<class T, StrictWeakOrder<auto, T> Compare>
27624 <del>requires !SameType<T, Compare> && CopyConstructible<Compare></del>
27625 pair<const T&, const T&> minmax(const T& a, const T& b, Compare comp);
27626 </pre></blockquote>
27634 <h3><a name="1014"></a>1014. Response to UK 317 and JP 74</h3>
27635 <p><b>Section:</b> 28.9.2 [re.regex.construct] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
27636 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-05-23</p>
27637 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.regex.construct">issues</a> in [re.regex.construct].</p>
27638 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
27639 <p><b>Discussion:</b></p>
27641 <p><b>Addresses UK 317 and JP 74</b></p>
27648 <tt>basic_string</tt> has both a constructor and an assignment operator that
27649 accepts an initializer list, <tt>basic_regex</tt> should have the same.
27657 <tt>basic_regx & operator= (initializer_list<T>);</tt> is not defined.
27665 UK 317 asks for both assignment and constructor,
27666 but the requested constructor is already present in the current Working Paper.
27667 We agree with the proposed resolution.
27668 Move to Tentatively Ready.
27672 <p><b>Proposed resolution:</b></p>
27674 Change 28.9 [re.regex]:
27677 <blockquote><pre>template <class charT,
27678 class traits = regex_traits<charT> >
27679 class basic_regex {
27681 basic_regex& operator=(const charT* ptr);
27682 <ins>basic_regex& operator=(initializer_list<charT> il);</ins>
27683 template <class ST, class SA>
27684 basic_regex& operator=(const basic_string<charT, ST, SA>& p);
27687 </pre></blockquote>
27690 Add in 28.9.2 [re.regex.construct]:
27697 <pre>basic_regex& operator=(initializer_list<charT> il);
27700 -21- <i>Effects:</i> returns <tt>assign(il.begin(), il.end());</tt>
27710 <h3><a name="1015"></a>1015. Response to UK 199</h3>
27711 <p><b>Section:</b> 20.2.1 [concept.transform] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
27712 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-05-23</p>
27713 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#concept.transform">active issues</a> in [concept.transform].</p>
27714 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#concept.transform">issues</a> in [concept.transform].</p>
27715 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
27716 <p><b>Discussion:</b></p>
27718 <p><b>Addresses UK 199</b></p>
27721 The requirement that programs do not supply <tt>concept_maps</tt> should
27722 probably be users do not supply their own <tt>concept_map</tt>
27723 specializations. The program will almost certainly supply
27724 <tt>concept_maps</tt> - the standard itself supplies a specialization
27725 for <tt>RvalueOf</tt> references. Note that the term <i>program</i> is
27726 defined in 3.5 [basic.link]p1 and makes no account of the
27727 standard library being treated differently to user written code.
27731 2009-05-09 Alisdair adds:
27737 The same problem is present in the words added for the
27738 <tt>LvalueReference/RvalueReference</tt> concepts last meeting.
27741 With three subsections requiring the same constraint, I'm wondering if there
27742 is a better way to organise this section.
27743 Possible 20.2.1 -> 20.2.3 belong in the fundamental concepts clause in
27744 14.10.4 [concept.support]? While they can be implemented purely as a
27745 library feature without additional compiler support, they are pretty
27746 fundamental and we want the same restriction on user-concept maps as is
27756 We agree with the issue,
27757 but believe the wording needs further improvement.
27758 We want to investigate current definitions for nomenclature such as
27759 "user" and "program."
27760 Move to Open pending the recommended investigation.
27764 <p><b>Proposed resolution:</b></p>
27766 Change 20.2.1 [concept.transform] p2:
27770 -2- A <del>program</del> <ins>user</ins> shall not provide concept maps for
27771 any concept in 20.1.1.
27775 Change 20.2.2 [concept.true] p2:
27779 -2- <i>Requires:</i> a <del>program</del> <ins>user</ins> shall not
27780 provide a concept map for the <tt>True</tt> concept.
27784 Change 20.2.3 [concept.classify] p2:
27788 -2- <i>Requires:</i> a <del>program</del><ins>user</ins> shall not provide concept
27789 maps for any concept in this section.
27798 <h3><a name="1016"></a>1016. Response to JP 33</h3>
27799 <p><b>Section:</b> 20.2.6 [concept.comparison] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
27800 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-03-12</p>
27801 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#concept.comparison">active issues</a> in [concept.comparison].</p>
27802 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#concept.comparison">issues</a> in [concept.comparison].</p>
27803 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
27804 <p><b>Discussion:</b></p>
27806 <p><b>Addresses JP 33</b></p>
27809 <tt>LessThanComparable</tt> and <tt>EqualityComparable</tt> don't correspond to NaN.
27812 <p><b>Original proposed resolution:</b></p>
27815 Apply <tt>concept_map</tt> to these concepts at <tt>FloatingPointType</tt>.
27819 Post Summit, Alisdair adds:
27825 I don't understand the proposed resolution - there is no such thing as a
27826 'negative' concept_map, and these concepts are auto concepts that match
27827 float/double etc. Also not clear how we are supposed to match values to
27831 Recommend NAD and treat as a subset of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#902">902</a>.
27837 <p><b>Proposed resolution:</b></p>
27847 <h3><a name="1017"></a>1017. Response to US 66</h3>
27848 <p><b>Section:</b> 20.2.11 [concept.regular] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
27849 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-03-12</p>
27850 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
27851 <p><b>Discussion:</b></p>
27853 <p><b>Addresses US 66</b></p>
27856 Application of the <tt>Regular</tt> concept to floating-point types appears to be
27857 controversial (see long discussion on std-lib reflector).
27860 <p><b>Original proposed resolution:</b></p>
27863 State that the <tt>Regular</tt> concept does not apply to floating-point types.
27873 Recommend that we handle the same as JP 33 / <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1016">1016</a>.
27878 Post Summit, Alisdair adds:
27884 Recommend Open, and review after resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#902">902</a> and revised axiom
27891 <p><b>Proposed resolution:</b></p>
27898 <h3><a name="1018"></a>1018. Response to US 70</h3>
27899 <p><b>Section:</b> 20.6 [meta] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
27900 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-03-12</p>
27901 <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>
27902 <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>
27903 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
27904 <p><b>Discussion:</b></p>
27906 <p><b>Addresses US 70</b></p>
27909 Specifications now expressed via narrative text are more accurately and
27910 clearly expressed via executable code.
27913 Wherever concepts are available that directly match this section's type
27914 traits, express the traits in terms of the concepts instead of via
27915 narrative text. Where the type traits do not quite match the
27916 corresponding concepts, bring the two into alignment so as to avoid two
27917 nearly-identical notions.
27927 We think that this is a good idea, but it requires a lot of work. If someone
27928 submits a paper proposing specific changes, we would be happy to review it
27929 at the next meeting.
27935 <p><b>Proposed resolution:</b></p>
27942 <h3><a name="1019"></a>1019. Response to UK 205</h3>
27943 <p><b>Section:</b> 20.6.3 [meta.help] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
27944 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-05-23</p>
27945 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta.help">active issues</a> in [meta.help].</p>
27946 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.help">issues</a> in [meta.help].</p>
27947 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
27948 <p><b>Discussion:</b></p>
27950 <p><b>Addresses UK 205</b></p>
27953 <tt>integral_constant</tt> objects should be usable in integral-constant-expressions.
27954 The addition to the language of literal types and the enhanced rules for
27955 constant expressions make this possible.
27963 We agree that the <tt>static</tt> data member
27964 ought be declared <tt>constexpr</tt>,
27965 but do not see a need for the proposed <tt>operator value_type()</tt>.
27966 (A use case would be helpful.)
27971 2009-05-23 Alisdair adds:
27977 The motivating case in my mind is that we can then use
27978 <tt>true_type</tt> and <tt>false_type</tt> as integral Boolean expressions, for example inside
27979 a <tt>static_assert</tt> declaration. In that sense it is purely a matter of style.
27982 Note that Boost has applied the non-explicit conversion operator for many
27983 years as it has valuable properties for extension into other metaprogramming
27984 libraries, such as MPL. If additional rationale is desired I will poll the
27985 Boost lists for why this extension was originally applied. I would argue
27986 that explicit conversion is more appropriate for 0x though.
27991 <p><b>Proposed resolution:</b></p>
27993 Add to the <tt>integral_constant</tt> struct definition in 20.6.3 [meta.help]:
27996 <blockquote><pre>template <class T, T v>
27997 struct integral_constant {
27998 static const<ins>expr</ins> T value = v;
27999 typedef T value_type;
28000 typedef integral_constant<T,v> type;
28001 <ins>constexpr operator value_type() { return value; }</ins>
28003 </pre></blockquote>
28010 <h3><a name="1020"></a>1020. Response to UK 204</h3>
28011 <p><b>Section:</b> 20.6.7 [meta.trans.other] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
28012 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-03-12</p>
28013 <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>
28014 <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>
28015 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
28016 <p><b>Discussion:</b></p>
28018 <p><b>Addresses UK 204</b></p>
28021 It is not possible to create a variant union based on a parameter pack
28022 expansion, e.g. to implement a classic discriminated union template.
28025 <p><b>Original proposed resolutuion:</b></p>
28028 Restore <tt>aligned_union</tt> template that was removed by LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#856">856</a>.
28037 Agree. The need for <tt>aligned_union</tt> is compelling enough to reinstate.
28041 Post Summit, Alisdair adds:
28047 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2843.html">N2843</a>
28048 proposes an extension to the <tt>[[align]]</tt> attribute
28049 that further diminishes the need for this template. Recommend NAD.
28054 <p><b>Proposed resolution:</b></p>
28061 <h3><a name="1021"></a>1021. Response to UK 211</h3>
28062 <p><b>Section:</b> 20.8.12.2.3 [unique.ptr.single.asgn] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
28063 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-05-23</p>
28064 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
28065 <p><b>Discussion:</b></p>
28067 <p><b>Addresses UK 211</b></p>
28070 The <tt>nullptr_t</tt> type was introduced to resolve the null pointer literal
28071 problem. It should be used for the assignemnt operator, as with the
28072 constructor and elsewhere through the library.
28080 We agree with the proposed resolution.
28081 Move to Tentatively Ready.
28085 <p><b>Proposed resolution:</b></p>
28087 Change the synopsis in 20.8.12.2 [unique.ptr.single]:
28090 <blockquote><pre>unique_ptr& operator=(<del><i>unspecified-pointer-type</i></del> <ins>nullptr_t</ins>);
28091 </pre></blockquote>
28094 Change 20.8.12.2.3 [unique.ptr.single.asgn]:
28097 <blockquote><pre>unique_ptr& operator=(<del><i>unspecified-pointer-type</i></del> <ins>nullptr_t</ins>);
28100 <del>Assigns from the literal 0 or <tt>NULL</tt>. [<i>Note:</i> The
28101 <i>unspecified-pointer-type</i> is often implemented as a pointer to a
28102 private data member, avoiding many of the implicit conversion pitfalls.
28103 <i>-- end note</i>]</del>
28112 <h3><a name="1023"></a>1023. Response to DE 22</h3>
28113 <p><b>Section:</b> 20.7.16.2 [func.wrap.func] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Tentatively NAD Editorial</a>
28114 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-05-23</p>
28115 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#func.wrap.func">active issues</a> in [func.wrap.func].</p>
28116 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.wrap.func">issues</a> in [func.wrap.func].</p>
28117 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD%20Editorial">Tentatively NAD Editorial</a> status.</p>
28118 <p><b>Discussion:</b></p>
28120 <p><b>Addresses DE 22</b></p>
28122 <p>Related to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1114">1114</a>.</p>
28125 The conditions for deriving from <tt>std::unary_function</tt> and
28126 <tt>std::binary_function</tt> are unclear: The condition would also be satisfied if
28127 <tt>ArgTypes</tt> were <tt>std::vector<T1></tt>, because it (arguably)
28128 "contains" <tt>T1</tt>.
28137 Agree. <tt>std::reference_wrapper</tt> has the same structure, and we
28138 suggest that <tt>std::function</tt> be presented in the same way as
28139 <tt>std::reference_wrapper</tt>.
28143 2009-05-09 Alisdair adds:
28148 Phrasing should be "publicly and
28149 unambiguously derived from" and probably back in reference_wrapper too. Updated
28158 We agree with the proposed wording.
28159 Move to NAD Editorial.
28163 <p><b>Proposed resolution:</b></p>
28165 (no changes to <tt><functional></tt> synopsis required)
28169 Change synopsis in Class template function 20.7.16.2 [func.wrap.func]:
28172 <blockquote><pre>template<Returnable R, CopyConstructible... ArgTypes>
28173 class function<R(ArgTypes...)>
28174 : public unary_function<T1, R> // <del><i>iff</i> sizeof...(ArgTypes) == 1 <i>and</i></del> <ins><i>see below</i></ins>
28175 <del>// ArgTypes <i>contains</i> T1</del>
28176 : public binary_function<T1, T2, R> // <del><i>iff</i> sizeof...(ArgTypes) == 2 <i>and</i></del> <ins><i>see below</i></ins>
28177 <del>// ArgTypes <i>contains</i> T1 <i>and</i> T2</del>
28180 </pre></blockquote>
28183 Add new p1/p2 before 20.7.16.2.1 [func.wrap.func.con]:
28188 The template instantiation <tt>function<R(T1)></tt> shall be publicly and
28189 unambiguously derived from
28190 <tt>std::unary_function<T1,R></tt> if and only if the template type parameter
28191 is a function type taking one argument of type <tt>T1</tt> and returning <tt>R</tt>.
28195 The template instantiation <tt>function<R(T1,T2)></tt> shall be publicly and
28196 unambiguously derived from
28197 <tt>std::binary_function<T1,T2,R></tt> if and only if the template type
28198 parameter is a function type taking two arguments of type <tt>T1</tt> and <tt>T2</tt> and
28199 returning <tt>R</tt>.
28202 <pre>explicit function();
28212 <h3><a name="1024"></a>1024. Response to JP 39</h3>
28213 <p><b>Section:</b> 20.7.16.2 [func.wrap.func] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
28214 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-05-23</p>
28215 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#func.wrap.func">active issues</a> in [func.wrap.func].</p>
28216 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.wrap.func">issues</a> in [func.wrap.func].</p>
28217 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
28218 <p><b>Discussion:</b></p>
28220 <p><b>Addresses JP 39</b></p>
28223 There are no requires corresponding to <tt>F</tt> of <tt>std::function</tt>.
28227 2009-05-01 Daniel adds:
28232 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1070">1070</a> removes the second constructor.
28240 We agree with the proposed resolution.
28241 Move to Tentatively Ready.
28242 If issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1070">1070</a> is accepted,
28243 the changes to the second constructor
28244 in this issue are moot.
28248 <p><b>Proposed resolution:</b></p>
28250 Correct as follows in 20.7.16.2 [func.wrap.func] (class definition)
28253 <blockquote><pre> template<class F, Allocator Alloc>
28254 <ins>requires ConstructibleWithAllocator<F, Alloc>
28255 && call=Callable<F, ArgTypes...>
28256 && Convertible<call::result_type, R></ins>
28257 function(allocator_arg_t, const Alloc&, F);
28258 template<class F, Allocator Alloc>
28259 <ins>requires ConstructibleWithAllocator<F,Alloc>
28260 && call=Callable<F, ArgTypes...>
28261 && Convertible<call::result_type, R></ins>
28262 function(allocator_arg_t, const Alloc&, F&&);
28263 </pre></blockquote>
28271 <h3><a name="1026"></a>1026. Response to UK 209</h3>
28272 <p><b>Section:</b> 20.8 [memory] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
28273 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-03-12</p>
28274 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#memory">active issues</a> in [memory].</p>
28275 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#memory">issues</a> in [memory].</p>
28276 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
28277 <p><b>Discussion:</b></p>
28279 <p><b>Addresses UK 209</b></p>
28282 Smart pointers cannot be used in constrained templates.
28291 We look forward to a paper on this topic. We recommend no action until a
28292 paper is available. We understand that a paper is forthcoming.
28301 <tt>shared_ptr<T></tt> and <tt>weak_ptr<T></tt> support all
28302 types <tt>T</tt> for which <tt>T*</tt> is valid. In other words, a
28303 possible (partial) resolution is to change class <tt>T</tt> to
28304 <tt>PointeeType T</tt> for <tt>shared_ptr</tt>, <tt>weak_ptr</tt> and
28305 possibly <tt>enable_shared_from_this</tt>.
28310 <p><b>Proposed resolution:</b></p>
28317 <h3><a name="1027"></a>1027. Response to UK 213</h3>
28318 <p><b>Section:</b> 20.8.6 [default.allocator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
28319 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-03-13</p>
28320 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
28321 <p><b>Discussion:</b></p>
28323 <p><b>Addresses UK 213</b></p>
28326 <tt>std::allocator</tt> should be constrained to simplify its use on constrained
28327 contexts. This library component models allocation from free store via the
28328 new operator so choose constraints to
28329 match. The Allocator concept allows for a wider variety of allocators that
28330 users may choose to supply if their allocation model does not require
28331 operator new, without impacting the
28332 requirements of this template.
28336 Suggested direction:
28339 The primary allocator template should be constrained to require
28340 <tt>ObjectType<T></tt> and <tt>FreeStoreAllocatable<T></tt>.
28341 Further operations to be constrained as required.
28350 Agree as stated. A future paper will address additional related issues.
28355 <p><b>Proposed resolution:</b></p>
28362 <h3><a name="1028"></a>1028. Response to UK 214</h3>
28363 <p><b>Section:</b> 20.8.8 [storage.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
28364 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-03-15</p>
28365 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
28366 <p><b>Discussion:</b></p>
28368 <p><b>Addresses UK 214</b></p>
28371 <tt>raw_storage_iterator</tt> needs constraining as an iterator adaptor to be safely
28372 used in constrained templates
28381 We look forward to a paper on this topic. We recommend no action until a
28382 paper is available.
28386 Post Summit Alisdair provided wording and rationale.
28392 <p><b>Proposed resolution:</b></p>
28397 Update the synopsis for <tt><memory></tt>
28399 <blockquote><pre>// 20.7.8, raw storage iterator:
28400 template <<del>class</del> <ins>ForwardIterator</ins> Out<del>put</del>Iter<del>ator</del>, <del>class</del> <ins>ObjectType</ins> T>
28401 <ins>requires OutputIterator< OutIter, T ></ins>
28402 class raw_storage_iterator;
28404 <ins>template <ForwardIterator OutIter, ObjectType T>
28405 requires OutputIterator< OutIter, T >
28406 concept_map Iterator<raw_storage_iterator< OutIter, T > > { }</ins>
28407 </pre></blockquote>
28411 20.8.8 [storage.iterator] p1
28414 Replace class template definition with:
28416 <blockquote><pre>namespace std {
28417 template <<del>class</del> <ins>ForwardIterator</ins> Out<del>put</del>Iter<del>ator</del>, <del>class</del> <ins>ObjectType</ins> T>
28418 <ins>requires OutputIterator< OutIter, T ></ins>
28419 class raw_storage_iterator
28420 : public iterator<output_iterator_tag,void,void,void,void> {
28422 explicit raw_storage_iterator(Out<del>put</del>Iter<del>ator</del> x);
28424 raw_storage_iterator<del><OutputIterator,T></del>& operator*();
28425 raw_storage_iterator<del><OutputIterator,T></del>& operator=(const T& element);
28426 raw_storage_iterator<del><OutputIterator,T></del>& operator++();
28427 raw_storage_iterator<del><OutputIterator,T></del> operator++(int);
28430 <ins>template <ForwardIterator OutIter, ObjectType T>
28431 requires OutputIterator< OutIter, T >
28432 concept_map Iterator<raw_storage_iterator< OutIter, T > > { }</ins>
28434 </pre></blockquote>
28437 <p><b>Rationale:</b></p>
28439 <tt>raw_storage_iterator</tt> has to adapt a <tt>ForwardIterator</tt>,
28440 rather than just an <tt>InputIterator</tt> for two reasons:
28445 The initial iterator passed by value is expected to remain valid,
28446 pointing to the initialized region of memory.
28449 to avoid breaking the declaration of post-increment operator which would
28450 require some kind of proxy formulation to support generalised InputIterators.
28460 <h3><a name="1029"></a>1029. Response to UK 210</h3>
28461 <p><b>Section:</b> 20.8.11 [specialized.algorithms] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
28462 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-03-15</p>
28463 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#specialized.algorithms">issues</a> in [specialized.algorithms].</p>
28464 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
28465 <p><b>Discussion:</b></p>
28467 <p><b>Addresses UK 210</b></p>
28469 <p>Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#582">582</a></p>
28472 Specialized algorithms for memory managenment need requirements to be
28473 easily usable in constrained templates.
28482 We look forward to a paper on this topic. We recommend no action until a
28483 paper is available.
28487 Post Summit Alisdair provided wording.
28504 I suggest <tt>Size</tt> should require <tt>IntegralLike</tt> and not <tt>UnsignedIntegralLike</tt>,
28505 because otherwise simple int-literals could not be provided as arguments
28506 and it would conflict with other algorithms that only require <tt>IntegralLike</tt>.
28510 The current for-loop-test relies on evaluation in boolean context which is
28511 not provided by <tt>ArithmeticLike</tt> and it's refinements. I propose to change the
28512 corresponding for-loop-headers to:
28516 for <tt>uninitialized_copy_n</tt>: <tt>for ( ; n > Size(0); ++result, ++first, --n) {</tt>
28519 for <tt>uninitialized_fill_n</tt>: <tt>for (; n > Size(0); ++first, --n) {</tt>
28530 For the record I agree with Daniel's suggestion.
28537 <p><b>Proposed resolution:</b></p>
28542 Update the synopsis for <tt><memory></tt>
28544 <blockquote><pre>template <<del>class</del> InputIterator <ins>InIter</ins>,
28545 <del>class ForwardIterator</del> <ins>OutputIterator<auto, InIter::reference> OutIter</ins>>
28546 <ins>requires ForwardIterator<OutIter></ins>
28547 <del>ForwardIterator</del> <ins>OutIter</ins>
28548 uninitialized_copy(<del>InputIterator</del> <ins>InIter</ins> first, <del>InputIterator</del> <ins>InIter</ins> last,
28549 <del>ForwardIterator</del> <ins>OutIter</ins> result);
28551 template <<del>class</del> InputIterator <ins>InIter</ins>,
28552 <del>class</del> <ins>IntegralLike</ins> Size,
28553 <del>class ForwardIterator</del> <ins>OutputIterator<auto, InIter::reference> OutIter</ins>>
28554 <ins>requires ForwardIterator<OutIter></ins>
28555 <del>ForwardIterator</del> <ins>OutIter</ins>
28556 uninitialized_copy_n(<del>InputIterator</del> <ins>InIter</ins> first, Size n,
28557 <del>ForwardIterator</del> <ins>OutIter</ins> result);
28559 template <<del>class</del> ForwardIterator <ins>Iter</ins>, <del>class</del> <ins>ObjectType</ins> T>
28560 <ins>requires Constructible< Iter::value_type, const T& ></ins>
28561 void uninitialized_fill(<del>ForwardIterator</del> <ins>Iter</ins> first, <del>ForwardIterator</del> <ins>Iter</ins> last,
28564 template <<del>class</del> ForwardIterator <ins>Iter</ins>, <del>class</del> <ins>IntegralLike</ins> Size, <del>class</del> <ins>ObjectType</ins> T>
28565 <ins>requires Constructible< Iter::value_type, const T& ></ins>
28567 uninitialized_fill_n(<del>ForwardIterator</del> <ins>Iter</ins> first, Size n, const T& x);
28568 </pre></blockquote>
28575 uninitialized_copy 20.8.11.2 [uninitialized.copy]
28578 <blockquote><pre>template <<del>class</del> InputIterator <ins>InIter</ins>,
28579 <del>class ForwardIterator</del> <ins>OutputIterator<auto, InIter::reference> OutIter</ins>>
28580 <ins>requires ForwardIterator<OutIter></ins>
28581 <del>ForwardIterator</del> <ins>OutIter</ins>
28582 uninitialized_copy(<del>InputIterator</del> <ins>InIter</ins> first, <del>InputIterator</del> <ins>InIter</ins> last,
28583 <del>ForwardIterator</del> <ins>OutIter</ins> result);
28588 -1- <i>Effects:</i>
28590 <blockquote><pre>for (; first != last; ++result, ++first) {
28591 new (static_cast<void*>(&*result))
28592 <del>typename iterator_traits<ForwardIterator></del> <ins>OutIter</ins>::value_type(*first);
28594 </pre></blockquote>
28597 -2- <i>Returns:</i> <tt>result</tt>
28602 <pre>template <<del>class</del> InputIterator <ins>InIter</ins>,
28603 <del>class</del> <ins>IntegralLike</ins> Size,
28604 <del>class ForwardIterator</del> <ins>OutputIterator<auto, InIter::reference> OutIter</ins>>
28605 <ins>requires ForwardIterator<OutIter></ins>
28606 <del>ForwardIterator</del> <ins>OutIter</ins>
28607 uninitialized_copy_n(<del>InputIterator</del> <ins>InIter</ins> first, Size n,
28608 <del>ForwardIterator</del> <ins>OutIter</ins> result);
28615 <blockquote><pre>for ( ; n > <ins>Size(</ins>0<ins>)</ins>; ++result, ++first, --n) {
28616 new (static_cast<void*>(&*result))
28617 <del>typename iterator_traits<ForwardIterator></del> <ins>OutIter</ins>::value_type(*first);
28619 </pre></blockquote>
28621 -4- <i>Returns:</i> result
28629 uninitialized_fill 20.8.11.3 [uninitialized.fill]
28632 <blockquote><pre>template <<del>class</del> ForwardIterator <ins>Iter</ins>, <del>class</del> <ins>ObjectType</ins> T>
28633 <ins>requires Constructible< Iter::value_type, const T& ></ins>
28634 void uninitialized_fill(<del>ForwardIterator</del> <ins>Iter</ins> first, <del>ForwardIterator</del> <ins>Iter</ins> last,
28640 -1- <i>Effects:</i>
28642 <blockquote><pre>for (; first != last; ++first) {
28643 new ( static_cast<void*>( &*first) )
28644 <del>typename iterator_traits<ForwardIterator></del> <ins>Iter</ins>::value_type(x);
28646 </pre></blockquote>
28652 uninitialized_fill_n 20.8.11.4 [uninitialized.fill.n]
28655 <blockquote><pre>template <<del>class</del> ForwardIterator <ins>Iter</ins>, <del>class</del> <ins>IntegralLike</ins> Size, <del>class</del> <ins>ObjectType</ins> T>
28656 <ins>requires Constructible< Iter::value_type, const T& ></ins>
28658 uninitialized_fill_n(<del>ForwardIterator</del> <ins>Iter</ins> first, Size n, const T& x);
28663 -1- <i>Effects:</i>
28665 <blockquote><pre>for (; n<del>--</del> <ins>> Size(0)</ins>; ++first<ins>, --n</ins>) {
28666 new ( static_cast<void*>( &*first) )
28667 <del>typename iterator_traits<ForwardIterator></del> <ins>Iter</ins>::value_type(x);
28669 </pre></blockquote>
28679 <h3><a name="1030"></a>1030. Response to JP 44</h3>
28680 <p><b>Section:</b> 20.8.13.6 [util.smartptr.shared.atomic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
28681 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-03-12</p>
28682 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
28683 <p><b>Discussion:</b></p>
28685 <p><b>Addresses JP 44</b></p>
28688 The 1st parameter <tt>p</tt> and 2nd parameter <tt>v</tt> is now
28689 <tt>shared_ptr<T>*</tt>.
28692 It should be <tt>shared_ptr<T>&</tt>, or if these are
28693 <tt>shared_ptr<T>*</tt> then add the "<tt>p</tt> shall not be a
28694 null pointer" at the requires.
28703 Agree. All of the functions need a requirement that <tt>p</tt> (or
28704 <tt>v</tt>) is a pointer to a valid object.
28709 <p><b>Proposed resolution:</b></p>
28716 <h3><a name="1031"></a>1031. Response to US 78</h3>
28717 <p><b>Section:</b> 20.8.13.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
28718 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-03-12</p>
28719 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#util.smartptr.shared">active issues</a> in [util.smartptr.shared].</p>
28720 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared">issues</a> in [util.smartptr.shared].</p>
28721 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
28722 <p><b>Discussion:</b></p>
28724 <p><b>Addresses US 78</b></p>
28727 There is presently no way to convert directly from a <tt>shared_ptr</tt> to a
28728 <tt>unique_ptr</tt>. Add an interface that performs the conversion.
28737 We look forward to a paper on this topic. We recommend no action until a
28738 paper is available. We believe that the shared pointer must use the default
28739 deleter for the conversion to succeed.
28748 This is basically a request for <tt>shared_ptr<>::release</tt> in
28749 disguise, with all the associated problems. Not a good idea.
28754 <p><b>Proposed resolution:</b></p>
28761 <h3><a name="1032"></a>1032. Response to JP 45</h3>
28762 <p><b>Section:</b> 20.9 [time] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
28763 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11 <b>Last modified:</b> 2009-03-12</p>
28764 <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>
28765 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
28766 <p><b>Discussion:</b></p>
28768 <p><b>Addresses JP 45</b></p>
28771 <tt>Rep</tt>, <tt>Period</tt>, <tt>Clock</tt> and <tt>Duration</tt>
28772 don't correspond to concept.
28774 <blockquote><pre>template <class Rep, class Period = ratio<1>> class duration;
28775 template <class Clock, class Duration = typename Clock::duration> class time_point;
28776 </pre></blockquote>
28778 Make concept for <tt>Rep</tt>, <tt>Period</tt>, <tt>Clock</tt> and <tt>Duration</tt>.
28779 Fix 20.9 [time] and <tt>wait_until</tt>
28780 and <tt>wait_for</tt>'s template parameter at 30 [thread].
28789 We agree that this section needs concepts. We look forward to a paper on
28790 this topic. We recommend no action until a paper is available.
28795 <p><b>Proposed resolution:</b></p>
28802 <h3><a name="1033"></a>1033. <tt>thread::join()</tt> effects?</h3>
28803 <p><b>Section:</b> 30.3.1.5 [thread.thread.member] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
28804 <b>Submitter:</b> Alberto Ganesh Barbati <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-05-23</p>
28805 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.thread.member">active issues</a> in [thread.thread.member].</p>
28806 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.thread.member">issues</a> in [thread.thread.member].</p>
28807 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
28808 <p><b>Discussion:</b></p>
28811 While looking at <tt>thread::join()</tt> I think I spotted a couple of
28812 possible defects in the specifications. I could not find a previous
28813 issue or NB comment about that, but I might have missed it.
28817 The postconditions clause for <tt>thread::join()</tt> is:
28821 <i>Postconditions:</i> If <tt>join()</tt> throws an exception, the value
28822 returned by <tt>get_id()</tt> is unchanged. Otherwise, <tt>get_id() == id()</tt>.
28826 and the throws clause is:
28830 <i>Throws:</i> <tt>std::system_error</tt> when the postconditions cannot be achieved.
28834 Now... how could the postconditions <em>not</em> be achieved?
28835 It's just a matter of resetting the value of <tt>get_id()</tt> or leave it
28836 unchanged! I bet we can always do that. Moreover, it's a chicken-and-egg
28837 problem: in order to decide whether to throw or not I depend on the
28838 postconditions, but the postconditions are different in the two cases.
28842 I believe the throws clause should be:
28846 <i>Throws:</i> <tt>std::system_error</tt> when the effects or postconditions
28847 cannot be achieved.
28851 as it is in <tt>detach()</tt>, or, even better, as the postcondition is
28852 trivially satisfiable and to remove the circular dependency:
28857 <i>Throws:</i> <tt>std::system_error</tt> if the effects cannot be achieved.
28861 Problem is that... ehm... <tt>join()</tt> has no "Effects" clause. Is that intentional?
28865 See the thread starting at c++std-lib-23204 for more discussion.
28875 Pete believes there may be some more general language (in frontmatter)
28876 that can address this and related issues such as <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#962">962</a>.
28884 <p><b>Proposed resolution:</b></p>
28891 <h3><a name="1034"></a>1034. Response to UK 222</h3>
28892 <p><b>Section:</b> 23.2.1 [container.requirements.general] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
28893 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-03-12</p>
28894 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements.general">active issues</a> in [container.requirements.general].</p>
28895 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements.general">issues</a> in [container.requirements.general].</p>
28896 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
28897 <p><b>Discussion:</b></p>
28899 <p><b>Addresses UK 222</b></p>
28902 It is not clear what purpose the Requirement tables serve in the
28903 Containers clause. Are they the definition of a library Container? Or
28904 simply a conventient shorthand to factor common semantics into a single
28905 place, simplifying the description of each subsequent container? This
28906 becomes an issue for 'containers' like <tt>array</tt>, which does not meet the
28907 default-construct-to-empty requirement, or <tt>forward_list</tt> which does not
28908 support the size operation. Are these components no longer containers?
28909 Does that mean the remaining requirements don't apply? Or are these
28910 contradictions that need fixing, despite being a clear design decision?
28918 Clarify all the tables in 23.2 [container.requirements] are
28919 there as a convenience for documentation, rather than a strict set of
28920 requirements. Containers should be allowed to relax specific
28921 requirements if they call attention to them in their documentation. The
28922 introductory text for <tt>array</tt> should be expanded to mention a
28923 default constructed <tt>array</tt> is not empty, and
28924 <tt>forward_list</tt> introduction should mention it does not provide
28925 the required <tt>size</tt> operation as it cannot be implemented
28935 Agree in principle.
28940 <p><b>Proposed resolution:</b></p>
28947 <h3><a name="1035"></a>1035. Response to UK 226</h3>
28948 <p><b>Section:</b> 23.2.1 [container.requirements.general] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
28949 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-05-02</p>
28950 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements.general">active issues</a> in [container.requirements.general].</p>
28951 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements.general">issues</a> in [container.requirements.general].</p>
28952 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
28953 <p><b>Discussion:</b></p>
28955 <p><b>Addresses UK 226</b></p>
28958 <tt><array></tt> must be added to this list. In particular it
28959 doesn't satisfy: - no <tt>swap()</tt> function invalidates any
28960 references, pointers, or iterators referring to the elements of the
28961 containers being swapped. and probably doesn't satisfy: - no
28962 <tt>swap()</tt> function throws an exception.
28965 If <tt><array></tt> remains a container, this will have to also
28966 reference <tt>array</tt>, which will then have to say which of these
28967 points it satisfies.
28976 Agree. The proposed resolution is incomplete. Further work required.
28980 2009-05-01 Daniel adds:
28985 Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1099">1099</a> also suggests
28986 adding move constructor to this.
28991 <p><b>Proposed resolution:</b></p>
28998 <h3><a name="1036"></a>1036. Response to UK 231</h3>
28999 <p><b>Section:</b> 23.2.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
29000 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-03-12</p>
29001 <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>
29002 <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>
29003 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
29004 <p><b>Discussion:</b></p>
29006 <p><b>Addresses UK 231</b></p>
29009 p9-p11 are redundant now that Concepts define what it means to be an
29010 Iterator and guide overload resolution accordingly.
29019 Agree with issue and change to 23.2.3 [sequence.reqmts]. The
29020 changes required to 21 [strings] will be part of the general
29021 concept support for that clause.
29026 <p><b>Proposed resolution:</b></p>
29028 Strike 23.2.3 [sequence.reqmts]p9-11. Make sure <tt>std::basic_string</tt>
29029 has constraints similar to
29030 <tt>std::vector</tt> to meet this old guarantee.
29038 <h3><a name="1037"></a>1037. Response to UK 232</h3>
29039 <p><b>Section:</b> 23.2.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
29040 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-05-23</p>
29041 <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>
29042 <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>
29043 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
29044 <p><b>Discussion:</b></p>
29046 <p><b>Addresses UK 232</b></p>
29049 <tt>match_results</tt> may follow the requirements but is not listed a general
29050 purpose library container.
29054 Remove reference to <tt>match_results</tt> against <tt>a[n]</tt> operation.
29063 Agree. <tt>operator[]</tt> is defined elsewhere.
29071 We agree with the proposed resolution.
29072 Move to Tentatively Ready.
29076 <p><b>Proposed resolution:</b></p>
29078 In 23.2.3 [sequence.reqmts] Table 84, remove reference to
29079 <tt>match_results</tt> in the row describing the <tt>a[n]</tt> operation.
29087 <h3><a name="1038"></a>1038. Response to UK 233</h3>
29088 <p><b>Section:</b> 23.2.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
29089 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-05-23</p>
29090 <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>
29091 <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>
29092 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
29093 <p><b>Discussion:</b></p>
29095 <p><b>Addresses UK 233</b></p>
29098 Table 84 is missing references to several new container types.
29115 We agree with the proposed resolution.
29116 Move to Tentatively Ready.
29120 <p><b>Proposed resolution:</b></p>
29122 In 23.2.3 [sequence.reqmts] Table 84, Add reference to listed
29123 containers to the following rows:
29128 <caption>Table 84 -- Optional sequence container operations</caption>
29130 <th>Expression</th>
29131 <th>Return type</th>
29132 <th>Operational semantics</th>
29136 <td><tt>a.front()</tt></td>
29139 <td><tt>vector, list, deque, basic_string<ins>, array, forward_list</ins></tt></td>
29142 <td><tt>a.back()</tt></td>
29145 <td><tt>vector, list, deque, basic_string<ins>, array</ins></tt></td>
29148 <td><tt>a.emplace_front(args)</tt></td>
29151 <td><tt>list, deque<ins>, forward_list</ins></tt></td>
29154 <td><tt>a.push_front(t)</tt></td>
29157 <td><tt>list, deque<ins>, forward_list</ins></tt></td>
29160 <td><tt>a.push_front(rv)</tt></td>
29163 <td><tt>list, deque<ins>, forward_list</ins></tt></td>
29166 <td><tt>a.pop_front()</tt></td>
29169 <td><tt>list, deque<ins>, forward_list</ins></tt></td>
29172 <td><tt>a[n]</tt></td>
29175 <td><tt>vector, deque, basic_string<ins>, array</ins></tt></td>
29178 <td><tt>a.at(n)</tt></td>
29181 <td><tt>vector, deque<ins>, basic_string, array</ins></tt></td>
29191 <h3><a name="1039"></a>1039. Response to UK 234</h3>
29192 <p><b>Section:</b> 23.2.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
29193 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-05-23</p>
29194 <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>
29195 <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>
29196 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
29197 <p><b>Discussion:</b></p>
29199 <p><b>Addresses UK 234</b></p>
29202 The reference to <tt>iterator</tt> in semantics for <tt>back</tt> should
29203 also allow for <tt>const_iterator</tt> when called on a const-qualified
29204 container. This would be ugly to specify in the 03 standard, but is
29205 quite easy with the addition of <tt>auto</tt> in this new standard.
29222 We agree with the proposed resolution.
29223 Move to Tentatively Ready.
29227 <p><b>Proposed resolution:</b></p>
29229 In 23.2.3 [sequence.reqmts] Table 84, replace iterator with auto in semantics for back:
29234 <caption>Table 84 -- Optional sequence container operations</caption>
29236 <th>Expression</th>
29237 <th>Return type</th>
29238 <th>Operational semantics</th>
29242 <td><tt>a.back()</tt></td>
29243 <td><tt>reference; const_reference</tt> for constant <tt>a</tt></td>
29244 <td><tt>{ <del>iterator</del> <ins>auto</ins> tmp = a.end();<br>--tmp;<br>return *tmp; }</tt></td>
29245 <td><tt>vector, list, deque, basic_string</tt></td>
29255 <h3><a name="1040"></a>1040. Response to UK 238</h3>
29256 <p><b>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
29257 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-05-23</p>
29258 <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>
29259 <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>
29260 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
29261 <p><b>Discussion:</b></p>
29263 <p><b>Addresses UK 238</b></p>
29266 Leaving it unspecified whether or not <tt>iterator</tt> and <tt>const_iterator</tt> are the
29267 same type is dangerous, as user code may or may not violate the One
29268 Definition Rule by providing overloads for
29269 both types. It is probably too late to specify a single behaviour, but
29270 implementors should document what to expect. Observing that problems can be
29271 avoided by users restricting themselves to using <tt>const_iterator</tt>, add a note to that effect.
29274 Suggest Change 'unspecified' to 'implementation defined'.
29283 Agree with issue. Agree with adding the note but not with changing the
29284 normative text. We believe the note provides sufficient guidance.
29292 We agree with the proposed resolution.
29293 Move to Tentatively Ready.
29297 <p><b>Proposed resolution:</b></p>
29299 In 23.2.4 [associative.reqmts] p6, add:
29303 -6- <tt>iterator</tt> of an associative container meets the requirements
29304 of the <tt>BidirectionalIterator</tt> concept. For associative
29305 containers where the value type is the same as the key type, both
29306 <tt>iterator</tt> and <tt>const_iterator</tt> are constant iterators. It
29307 is unspecified whether or not <tt>iterator</tt> and
29308 <tt>const_iterator</tt> are the same type.
29309 <ins>[<i>Note:</i> <tt>iterator</tt> and <tt>const_iterator</tt> have identical semantics in
29310 this case, and <tt>iterator</tt> is convertible to <tt>const_iterator</tt>. Users can avoid
29311 violating the One Definition Rule by always using <tt>const_iterator</tt>
29312 in their function parameter lists <i>-- end note</i>]</ins>
29320 <h3><a name="1041"></a>1041. Response to UK 239</h3>
29321 <p><b>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
29322 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-03-15</p>
29323 <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>
29324 <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>
29325 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
29326 <p><b>Discussion:</b></p>
29328 <p><b>Addresses UK 239</b></p>
29331 It is not possible to take a move-only key out of an unordered
29332 container, such as (<tt>multi</tt>)<tt>set</tt> or
29333 (<tt>multi</tt>)<tt>map</tt>, or the new unordered containers.
29337 Add below <tt>a.erase(q)</tt>, <tt>a.extract(q)</tt>, with the following notation:
29340 <tt>a.extract(q)></tt>, Return type <tt>pair<key, iterator></tt>
29341 Extracts the element pointed to by <tt>q</tt> and erases it from the
29342 <tt>set</tt>. Returns a <tt>pair</tt> containing the value pointed to by
29343 <tt>q</tt> and an <tt>iterator</tt> pointing to the element immediately
29344 following <tt>q</tt> prior to the element being erased. If no such
29345 element exists,returns <tt>a.end()</tt>.
29354 We look forward to a paper on this topic. We recommend no action until a
29355 paper is available. The paper would need to address exception safety.
29359 Post Summit Alisdair adds:
29364 Would <tt>value_type</tt> be a better return type than <tt>key_type</tt>?
29369 <p><b>Proposed resolution:</b></p>
29371 In 23.2.4 [associative.reqmts] Table 85, add:
29376 <caption>Table 85 -- Associative container requirements (in addition to container)</caption>
29378 <th>Expression</th>
29379 <th>Return type</th>
29380 <th>Assertion/note<br>pre-/post-condition</th>
29381 <th>Complexity</th>
29383 <tr><td><tt>a.erase(q)</tt></td>
29388 <td><ins><tt>a.extract(q)</tt></ins></td>
29389 <td><ins><tt>pair<key_type, iterator></tt></ins></td>
29390 <td><ins>Extracts the element pointed to by <tt>q</tt> and erases it from the <tt>set</tt>.
29391 Returns a <tt>pair</tt> containing the value pointed to by <tt>q</tt> and an <tt>iterator</tt>
29392 pointing to the element immediately following <tt>q</tt> prior to the element being
29393 erased. If no such element
29394 exists, returns <tt>a.end()</tt>.</ins></td>
29395 <td><ins>amortized constant</ins></td>
29401 In 23.2.5 [unord.req] Table 87, add:
29406 <caption>Table 87 -- Unordered associative container requirements (in addition to container)</caption>
29408 <th>Expression</th>
29409 <th>Return type</th>
29410 <th>Assertion/note<br>pre-/post-condition</th>
29411 <th>Complexity</th>
29413 <tr><td><tt>a.erase(q)</tt></td>
29418 <td><ins><tt>a.extract(q)</tt></ins></td>
29419 <td><ins><tt>pair<key_type, iterator></tt></ins></td>
29420 <td><ins>Extracts the element pointed to by <tt>q</tt> and erases it from the <tt>set</tt>.
29421 Returns a <tt>pair</tt> containing the value pointed to by <tt>q</tt> and an <tt>iterator</tt>
29422 pointing to the element immediately following <tt>q</tt> prior to the element being
29423 erased. If no such element
29424 exists, returns <tt>a.end()</tt>.</ins></td>
29425 <td><ins>amortized constant</ins></td>
29435 <h3><a name="1042"></a>1042. Response to UK 244</h3>
29436 <p><b>Section:</b> 23.3 [sequences] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
29437 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-03-14</p>
29438 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequences">issues</a> in [sequences].</p>
29439 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
29440 <p><b>Discussion:</b></p>
29442 <p><b>Addresses UK 244</b></p>
29445 The validity of the expression <tt>&a[n] == &a[0] + n</tt> is contingent on
29446 <tt>operator&</tt> doing the "right thing" (as captured by the <tt>CopyConstructible</tt>
29447 requirements in table 30 in C++2003). However this constraint has been
29448 lost in the Concepts of C++0x. This applies to <tt>vector</tt> and <tt>array</tt> (it
29449 actually applies to <tt>string</tt> also, but that's a different chapter, so I'll
29450 file a separate comment there and cross-reference).
29454 Suggested solution:
29458 Define a <tt>ContiguousStrorage</tt> and apply it to
29459 <tt>vector</tt>, <tt>array</tt> and <tt>string</tt>.
29468 Agree with the issue but not the details of the proposed solution. Walter to
29469 provide wording for the new concept.
29473 Post Summit Alisdair adds:
29478 Another LWG subgroup wondered if this concept
29479 should extend to <tt>complex<T></tt>, and so not be built on the container concept at
29485 <p><b>Proposed resolution:</b></p>
29487 Add to <tt><container_concepts></tt> synopsis in 23.2.6 [container.concepts]
29490 <blockquote><pre><ins>concept< typename C > ContiguousStorageContainer <i>see below</i>;</ins>
29491 </pre></blockquote>
29494 Add a new section to the end of 23.2.6 [container.concepts]
29499 23.1.6.x ContiguousStorageContainer concept [container.concepts.contiguous]
29502 <pre>concept ContiguousStorageContainer< typename C >
29503 : Container<C>
29505 value_type* data(C&);
29507 axiom Contiguity(C& c, size_type i) {
29508 if( i < size(c) ) {
29509 addressof( * (data(c) + i) )
29510 == addressof( * advance(data(c), i) );
29517 The <tt>ContiguousStorageContainer</tt> concept describes a container whose elements
29518 are allocated in a single region of memory, and are stored sequentially
29519 without intervening padding other than to meet alignment requirements.
29520 For example, the elements may be stored in a
29521 single array of suitable length.
29524 <pre>value_type * data( C& );
29528 <i>Returns:</i> a pointer to the first element in the region of storage.
29529 Result is unspecified for an empty container.
29535 Change 23.3.1 [array] p1:
29539 -1- The header <tt><array></tt> defines a class template for
29540 storing fixed-size sequences of objects. An <tt>array</tt> supports
29541 random access iterators. An instance of <tt>array<T, N></tt>
29542 stores <tt>N</tt> elements of type <tt>T</tt>, so that <tt>size() ==
29543 N</tt> is an invariant. The elements of an <tt>array</tt> are stored
29544 contiguously, meaning that <del>if <tt>a</tt> is</del> an
29545 <tt>array<T, N></tt> <del>then it obeys the identity <tt>&a[n]
29546 == &a[0] + n</tt> for all <tt>0 <= n < N</tt></del>
29547 <ins>satisfies the concept <tt>ContiguousStorageContainer< array<T,
29548 N>></tt></ins>.
29552 Add to the synopsis in 23.3.1 [array]:
29555 <blockquote><pre> ...
29557 const T * data() const;
29560 <ins>template< typename T, size_t N ></ins>
29561 <ins>concept_map ContiguousStorageContainer< array<T, N>> {};</ins>
29563 </pre></blockquote>
29566 Change 23.3.6 [vector] p1:
29570 A <tt>vector</tt> is a sequence container that supports random access
29571 iterators. In addition, it supports (amortized) constant time insert and
29572 erase operations at the end; insert and erase in the middle take linear
29573 time. Storage management is handled automatically, though hints can be
29574 given to improve efficiency. The elements of a vector are stored
29575 contiguously, meaning that <del>if <tt>v</tt> is</del> a
29576 <tt>vector<T, Alloc></tt> <ins>(</ins>where <tt>T</tt> is some
29577 type other than <tt>bool</tt><ins>)</ins><del>, then it obeys the
29578 identity <tt>&v[n] == &v[0] + n</tt> for all <tt>0 <= n <
29579 v.size()</tt></del> <ins>satisfies the concept <tt>ContiguousStorageContainer<
29580 vector< T, Alloc>></tt></ins>.
29584 Add at the end of the synopsis in 23.3.6 [vector] p2:
29587 <blockquote><pre><ins>template< typename T, typename A >
29588 requires !SameType< T, bool >
29589 concept_map ContiguousStorageContainer< vector<T, A>> {};</ins>
29590 </pre></blockquote>
29598 <h3><a name="1043"></a>1043. Response to US 91</h3>
29599 <p><b>Section:</b> 29.6 [atomics.types.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
29600 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-05-23</p>
29601 <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>
29602 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
29603 <p><b>Discussion:</b></p>
29605 <p><b>Addresses US 91</b></p>
29608 It is unclear whether or not a failed <tt>compare_exchange</tt> is a RMW operation
29609 (as used in 1.10 [intro.multithread]).
29613 Suggested solution:
29617 Make failing <tt>compare_exchange</tt> operations <b>not</b> be RMW.
29621 Anthony Williams adds:
29626 In 29.6 [atomics.types.operations] p18 it says that "These
29627 operations are atomic read-modify-write operations" (final sentence).
29628 This is overly restrictive on the implementations of
29629 <tt>compare_exchange_weak</tt> and <tt>compare_exchange_strong</tt> on platforms without a
29630 native CAS instruction.
29640 Group agrees with the resolution as proposed by Anthony Williams in the attached note.
29648 We recommend the proposed resolution be reviewed
29649 by members of the Concurrency Subgroup.
29653 <p><b>Proposed resolution:</b></p>
29655 Change 29.6 [atomics.types.operations] p18:
29659 -18- <i>Effects:</i> Atomically, compares the value pointed to by
29660 <tt>object</tt> or by <tt>this</tt> for equality with that in
29661 <tt>expected</tt>, and if true, replaces the value pointed to by
29662 <tt>object</tt> or by <tt>this</tt> with desired, and if false, updates
29663 the value in <tt>expected</tt> with the value pointed to by
29664 <tt>object</tt> or by <tt>this</tt>. Further, if the comparison is true,
29665 memory is affected according to the value of <tt>success</tt>, and if the
29666 comparison is false, memory is affected according to the value of
29667 <tt>failure</tt>. When only one <tt>memory_order</tt> argument is
29668 supplied, the value of <tt>success</tt> is <tt>order</tt>, and the value
29669 of <tt>failure</tt> is <tt>order</tt> except that a value of
29670 <tt>memory_order_acq_rel</tt> shall be replaced by the value
29671 <tt>memory_order_acquire</tt> and a value of
29672 <tt>memory_order_release</tt> shall be replaced by the value
29673 <tt>memory_order_relaxed</tt>. <ins>If the comparison is <tt>true</tt>, </ins>
29674 <del>T</del><ins>t</ins>hese operations are atomic
29675 read-modify-write operations (1.10).
29676 <ins>If the comparison is <tt>false</tt>, these
29677 operations are atomic load operations.</ins>
29686 <h3><a name="1044"></a>1044. Response to UK 325</h3>
29687 <p><b>Section:</b> 30.4 [thread.mutex] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
29688 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-05-23</p>
29689 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
29690 <p><b>Discussion:</b></p>
29692 <p><b>Addresses UK 325</b></p>
29695 We believe constexpr literal values should be a more natural expression
29696 of empty tag types than extern objects as it should improve the
29697 compiler's ability to optimize the empty object away completely.
29706 Move to review. The current specification is a "hack", and the proposed
29707 specification is a better "hack".
29715 We agree with the proposed resolution.
29716 Move to Tentatively Ready.
29720 <p><b>Proposed resolution:</b></p>
29722 Change the synopsis in 30.4 [thread.mutex]:
29725 <blockquote><pre>struct defer_lock_t <ins>{}</ins>;
29726 struct try_to_lock_t <ins>{}</ins>;
29727 struct adopt_lock_t <ins>{}</ins>;
29729 <del>extern</del> const<ins>expr</ins> defer_lock_t defer_lock <ins>{}</ins>;
29730 <del>extern</del> const<ins>expr</ins> try_to_lock_t try_to_lock <ins>{}</ins>;
29731 <del>extern</del> const<ins>expr</ins> adopt_lock_t adopt_lock <ins>{}</ins>;
29732 </pre></blockquote>
29740 <h3><a name="1045"></a>1045. Response to UK 326</h3>
29741 <p><b>Section:</b> 30.4.3.2.1 [thread.lock.unique.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
29742 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-05-23</p>
29743 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
29744 <p><b>Discussion:</b></p>
29746 <p><b>Addresses UK 326</b></p>
29749 The precondition that the mutex is not owned by this thread offers
29750 introduces the risk of un-necessary undefined behaviour into the
29751 program. The only time it matters whether the current thread owns the
29752 mutex is in the lock operation, and that will happen subsequent to
29753 construction in this case. The lock operation has the identical
29754 pre-condition, so there is nothing gained by asserting that precondition
29755 earlier and denying the program the right to get into a valid state
29756 before calling lock.
29765 Agree, move to review.
29773 We agree with the proposed resolution.
29774 Move to Tentatively Ready.
29778 <p><b>Proposed resolution:</b></p>
29780 Strike 30.4.3.2.1 [thread.lock.unique.cons] p7:
29783 <blockquote><pre>unique_lock(mutex_type& m, defer_lock_t);
29786 <del>-7- <i>Precondition:</i> If <tt>mutex_type</tt> is not a recursive mutex
29787 the calling thread does not own the mutex.</del>
29797 <h3><a name="1046"></a>1046. Response to UK 329</h3>
29798 <p><b>Section:</b> 30.6 [futures] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
29799 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-03-13</p>
29800 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
29801 <p><b>Discussion:</b></p>
29803 <p><b>Addresses UK 329</b></p>
29806 <tt>future</tt>, <tt>promise</tt> and <tt>packaged_task</tt> provide a
29807 framework for creating future values, but a simple function to tie all
29808 three components together is missing. Note that we only need a *simple*
29809 facility for C++0x. Advanced thread pools are to be left for TR2.
29817 Provide a simple function along the lines of:
29819 <blockquote><pre>template< typename F, typename ... Args >
29820 requires Callable< F, Args... >
29821 future< Callable::result_type > async( F&& f, Args && ... );
29822 </pre></blockquote>
29825 Semantics are similar to creating a <tt>thread</tt> object with a <tt>packaged_task</tt>
29826 invoking <tt>f</tt> with <tt>forward<Args>(args...)</tt>
29827 but details are left unspecified to allow different scheduling and thread
29828 spawning implementations.
29831 It is unspecified whether a task submitted to async is run on its own thread
29832 or a thread previously used for another async task. If a call to <tt>async</tt>
29833 succeeds, it shall be safe to wait for it from any thread.
29836 The state of <tt>thread_local</tt> variables shall be preserved during <tt>async</tt> calls.
29839 No two incomplete async tasks shall see the same value of
29840 <tt>this_thread::get_id()</tt>.
29843 [<i>Note:</i> this effectively forces new tasks to be run on a new thread, or a
29844 fixed-size pool with no queue. If the
29845 library is unable to spawn a new thread or there are no free worker threads
29846 then the <tt>async</tt> call should fail. <i>--end note</i>]
29856 The concurrency subgroup has revisited this issue and decided that it
29857 could be considered a defect according to the Kona compromise. A task
29858 group was formed lead by Lawrence Crowl and Bjarne Stroustrup to write a
29859 paper for Frankfort proposing a simple asynchronous launch facility
29860 returning a <tt>future</tt>. It was agreed that the callable must be run on a
29861 separate thread from the caller, but not necessarily a brand-new thread.
29862 The proposal might or might not allow for an implementation that uses
29863 fixed-size or unlimited thread pools.
29866 Bjarne in c++std-lib-23121: I think that what we agreed was that to
29867 avoid deadlock <tt>async()</tt> would almost certainly be specified to launch in
29868 a different thread from the thread that executed <tt>async()</tt>, but I don't
29869 think it was a specific design constraint.
29875 <p><b>Proposed resolution:</b></p>
29882 <h3><a name="1047"></a>1047. Response to UK 334</h3>
29883 <p><b>Section:</b> 30.6.4 [futures.unique_future] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
29884 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-05-23</p>
29885 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#futures.unique_future">active issues</a> in [futures.unique_future].</p>
29886 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#futures.unique_future">issues</a> in [futures.unique_future].</p>
29887 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
29888 <p><b>Discussion:</b></p>
29890 <p><b>Addresses UK 334</b></p>
29893 Behaviour of <tt>get()</tt> is undefined if calling <tt>get()</tt> while
29894 not <tt>is_ready()</tt>. The intent is that <tt>get()</tt> is a blocking
29895 call, and will wait for the future to become ready.
29905 Agree, move to Review.
29910 2009-04-03 Thomas J. Gritzan adds:
29916 This issue also applies to <tt>shared_future::get()</tt>.
29924 Add a paragraph to [futures.shared_future]:
29927 <blockquote><pre>void shared_future<void>::get() const;
29930 <i>Effects:</i> If <tt>is_ready()</tt> would return <tt>false</tt>, block on the asynchronous
29931 result associated with <tt>*this</tt>.
29941 It is not clear to us that this is an issue,
29942 because the proposed resolution's Effects clause seems to duplicate
29943 information already present in the Synchronization clause.
29944 Keep in Review status.
29948 <p><b>Proposed resolution:</b></p>
29950 Add a paragraph to 30.6.4 [futures.unique_future]:
29953 <blockquote><pre>R&& unique_future::get();
29954 R& unique_future<R&>::get();
29955 void unique_future<void>::get();
29958 <p><i>Note:</i>...</p>
29960 <ins><i>Effects:</i> If <tt>is_ready()</tt> would return <tt>false</tt>,
29961 block on the asynchronous result associated with <tt>*this</tt>.</ins>
29964 <i>Synchronization:</i> if <tt>*this</tt> is associated with a
29965 <tt>promise</tt> object, the completion of <tt>set_value()</tt> or
29966 <tt>set_exception()</tt> to that <tt>promise</tt> happens before (1.10)
29967 <tt>get()</tt> returns.
29977 <h3><a name="1048"></a>1048. Response to UK 335</h3>
29978 <p><b>Section:</b> 30.6.4 [futures.unique_future] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
29979 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-03-13</p>
29980 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#futures.unique_future">active issues</a> in [futures.unique_future].</p>
29981 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#futures.unique_future">issues</a> in [futures.unique_future].</p>
29982 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
29983 <p><b>Discussion:</b></p>
29985 <p><b>Addresses UK 335</b></p>
29988 <tt>std::unique_future</tt> is <tt>MoveConstructible</tt>, so you can transfer the
29989 association with an asynchronous result from one instance to another.
29990 However, there is no way to determine whether or not an instance has
29991 been moved from, and therefore whether or not it is safe to wait for it.
29994 <blockquote><pre>std::promise<int> p;
29995 std::unique_future<int> uf(p.get_future());
29996 std::unique_future<int> uf2(std::move(uf));
29997 uf.wait(); <font color="#c80000">// oops, uf has no result to wait for. </font>
29998 </pre></blockquote>
30001 Suggest we add a <tt>waitable()</tt> function to <tt>unique_future</tt>
30002 (and <tt>shared_future</tt>) akin to <tt>std::thread::joinable()</tt>,
30003 which returns <tt>true</tt> if there is an associated result to wait for
30004 (whether or not it is ready).
30011 <blockquote><pre>if(uf.waitable()) uf.wait();
30012 </pre></blockquote>
30021 Create an issue. Requires input from Howard. Probably NAD.
30026 Post Summit, Howard thows in his two cents:
30032 Here is a copy/paste of my last prototype of <tt>unique_future</tt> which was
30033 several years ago. At that time I was calling <tt>unique_future</tt> <tt>future</tt>:
30036 <blockquote><pre>template <class R>
30040 typedef R result_type;
30042 future(const future&);// = delete;
30043 future& operator=(const future&);// = delete;
30045 template <class R1, class F1> friend class prommise;
30050 future(future&& f);
30051 future& operator=(future&& f);
30053 void swap(future&& f);
30055 <b>bool joinable() const;</b>
30056 bool is_normal() const;
30057 bool is_exceptional() const;
30058 bool is_ready() const;
30063 template <class ElapsedTime>
30064 bool timed_join(const ElapsedTime&);
30066 </pre></blockquote>
30069 <tt>shared_future</tt> had a similar interface. I intentionally reused
30070 the <tt>thread</tt> interface where possible to lessen the learning
30071 curve std::lib clients will be faced with.
30077 <p><b>Proposed resolution:</b></p>
30084 <h3><a name="1049"></a>1049. Response to UK 339</h3>
30085 <p><b>Section:</b> 30.6.6 [futures.promise] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
30086 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-05-23</p>
30087 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#futures.promise">active issues</a> in [futures.promise].</p>
30088 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#futures.promise">issues</a> in [futures.promise].</p>
30089 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
30090 <p><b>Discussion:</b></p>
30092 <p><b>Addresses UK 339</b></p>
30095 Move assignment is goiing in the wrong direction, assigning from
30096 <tt>*this</tt> to the passed rvalue, and then returning a reference to
30097 an unusable <tt>*this</tt>.
30107 Agree, move to Review.
30116 We recommend deferring this issue until after Detlef's paper (on futures)
30121 <p><b>Proposed resolution:</b></p>
30123 Strike 30.6.6 [futures.promise] p6 and change p7:
30126 <blockquote><pre>promise& operator=(promise&& rhs);
30130 <del>-6- <i>Effects:</i> move assigns its associated state to <tt>rhs</tt>.</del>
30133 -7- <i>Postcondition:</i> <del><tt>*this</tt> has no associated
30134 state.</del> <ins>associated state of <tt>*this</tt> is the same as the
30135 associated state of <tt>rhs</tt> before the call. <tt>rhs</tt> has no
30136 associated state.</ins>
30147 <h3><a name="1050"></a>1050. Response to UK 340</h3>
30148 <p><b>Section:</b> 30.6.6 [futures.promise] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
30149 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-05-23</p>
30150 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#futures.promise">active issues</a> in [futures.promise].</p>
30151 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#futures.promise">issues</a> in [futures.promise].</p>
30152 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
30153 <p><b>Discussion:</b></p>
30155 <p><b>Addresses UK 340</b></p>
30158 There is an implied postcondition for <tt>get_future()</tt> that the state of the
30159 <tt>promise</tt> is transferred into the <tt>future</tt> leaving the <tt>promise</tt> with no
30160 associated state. It should be spelled out.
30170 Agree, move to Review.
30175 2009-04-03 Thomas J. Gritzan adds:
30181 <tt>promise::get_future()</tt> must not invalidate the state of the promise object.
30184 A promise is used like this:
30186 <blockquote><pre>promise<int> p;
30187 unique_future<int> f = p.get_future();
30188 <font color="#c80000">// post 'p' to a thread that calculates a value </font>
30189 <font color="#c80000">// use 'f' to retrieve the value. </font>
30190 </pre></blockquote>
30192 So <tt>get_future()</tt> must return an object that shares the same associated
30193 state with <tt>*this</tt>.
30196 But still, this function should throw an <tt>future_already_retrieved</tt> error
30197 when it is called twice.
30200 <tt>packaged_task::get_future()</tt> throws <tt>std::bad_function_call</tt> if its <tt>future</tt>
30201 was already retrieved. It should throw
30202 <tt>future_error(future_already_retrieved)</tt>, too.
30205 Suggested resolution:
30208 Replace p12/p13 30.6.6 [futures.promise]:
30212 -12- <i>Throws:</i> <tt>future_error</tt> if <del><tt>*this</tt> has no associated state</del>
30213 <ins>the <tt>future</tt> has already been retrieved</ins>.
30216 -13- <i>Error conditions:</i> <tt>future_already_retrieved</tt> if <del><tt>*this</tt>
30217 has no associated state</del>
30218 <ins>the <tt>future</tt> associated with
30219 the associated state has already been retrieved</ins>.
30222 <ins><i>Postcondition:</i> The returned object and <tt>*this</tt> share the associated state.</ins>
30226 Replace p14 30.6.8 [futures.task]:
30230 -14- <i>Throws:</i> <tt><del>std::bad_function_call</del> <ins>future_error</ins></tt> if the future <del>associated with
30231 the task</del> has already been retrieved.
30235 <i>Error conditions:</i> <tt>future_already_retrieved</tt> if the <tt>future</tt> associated with
30236 the task has already been retrieved.
30239 <ins><i>Postcondition:</i> The returned object and <tt>*this</tt> share the associated task.</ins>
30249 Keep in Review status
30250 pending Detlef's forthcoming paper on futures.
30254 <p><b>Proposed resolution:</b></p>
30256 Add after p13 30.6.6 [futures.promise]:
30259 <blockquote><pre>unique_future<R> get_future();
30266 <i>Postcondition:</i> <tt>*this</tt> has no associated state.
30277 <h3><a name="1051"></a>1051. Response to UK 279</h3>
30278 <p><b>Section:</b> 24.5.1.2.12 [reverse.iter.opindex], 24.5.3.2.12 [move.iter.op.index] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
30279 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-03-21</p>
30280 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
30281 <p><b>Discussion:</b></p>
30283 <p><b>Addresses UK 279</b></p>
30286 The reason the return type became unspecified is LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#386">386</a>. This
30287 reasoning no longer applies as there are at least two ways to get the right
30288 return type with the new language facilities added since the previous
30293 Proposal: Specify the return type using either decltype or the Iter concept_map.
30303 Under discussion. This is a general question about all iterator
30309 Howard adds post Summit:
30314 I am requesting test cases to demonstrate a position.
30319 <p><b>Proposed resolution:</b></p>
30326 <h3><a name="1052"></a>1052. Response to UK 281</h3>
30327 <p><b>Section:</b> 24.5.1.2.5 [reverse.iter.opref] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
30328 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-03-13</p>
30329 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
30330 <p><b>Discussion:</b></p>
30332 <p><b>Addresses UK 281</b></p>
30335 The current specification for return value for <tt>reverse_iterator::operator-></tt>
30336 will always be a true pointer type, but <tt>reverse_iterator</tt> supports proxy
30337 iterators where the pointer type may be some kind of 'smart pointer'.
30347 <tt>move_iterator</tt> avoids this problem by returning a value of the wrapped
30349 study group formed to come up with a suggested resolution.
30352 <tt>move_iterator</tt> solution shown in proposed wording.
30358 <p><b>Proposed resolution:</b></p>
30360 Change synopsis in 24.5.1.1 [reverse.iterator]:
30363 <blockquote><pre>template <BidirectionalIterator Iter>
30364 class reverse_iterator {
30366 typedef Iter<del>::pointer</del> pointer;
30367 </pre></blockquote>
30370 Change 24.5.1.2.5 [reverse.iter.opref]:
30373 <blockquote><pre>pointer operator->() const;
30377 <blockquote><pre><del>&(operator*());</del>
30378 <ins>this->tmp = current;</ins>
30379 <ins>--this->tmp;</ins>
30380 <ins>return this->tmp;</ins>
30381 </pre></blockquote>
30391 <h3><a name="1053"></a>1053. Response to UK 295</h3>
30392 <p><b>Section:</b> 25 [algorithms] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
30393 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-03-13</p>
30394 <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>
30395 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
30396 <p><b>Discussion:</b></p>
30398 <p><b>Addresses UK 295</b></p>
30401 There is a level of redundancy in the library specification for many
30402 algorithms that can be eliminated with the combination of concepts and
30403 default parameters for function templates. Eliminating redundancy simplified
30404 specification and reduces the risk of introducing accidental
30408 Proposed resolution: Adopt
30409 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2743.pdf">N2743</a>.
30419 NAD, this change would break code that takes the address of an
30425 Post Summit Alisdair adds:
30431 Request 'Open'. The issues in the paper go beyond just reducing
30432 the number of signatures, but cover unifying the idea of the ordering
30433 operation used by algorithms, containers and other library components. At
30434 least, it takes a first pass at the problem.
30438 For me (personally) that was the more important part of the paper, and not
30439 clearly addressed by the Summit resolution.
30445 <p><b>Proposed resolution:</b></p>
30452 <h3><a name="1054"></a>1054. <tt>forward</tt> broken</h3>
30453 <p><b>Section:</b> 20.3.2 [forward] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
30454 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-13 <b>Last modified:</b> 2009-05-23</p>
30455 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forward">issues</a> in [forward].</p>
30456 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
30457 <p><b>Discussion:</b></p>
30460 This is a placeholder issue to track the fact that we (well I) put the standard
30461 into an inconsistent state by requesting that we accept
30462 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2844.html">N2844</a>
30463 except for the proposed changes to [forward].
30467 There will exist in the post meeting mailing
30468 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2835.html">N2835</a>
30469 which in its current state reflects the state of affairs prior to the Summit
30470 meeting. I hope to update it in time for the post Summit mailing, but as I write
30471 this issue I have not done so yet.
30479 Move to Open, awaiting the promised paper.
30484 <p><b>Proposed resolution:</b></p>
30491 <h3><a name="1055"></a>1055. Response to UK 98</h3>
30492 <p><b>Section:</b> 20.6.7 [meta.trans.other] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
30493 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-05-23</p>
30494 <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>
30495 <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>
30496 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
30497 <p><b>Discussion:</b></p>
30499 <p><b>Addresses UK 98</b></p>
30502 It would be useful to be able to determine the underlying
30503 type of an arbitrary enumeration type. This would allow
30504 safe casting to an integral type (especially needed for
30505 scoped enums, which do not promote), and would allow
30506 use of <tt>numeric_limits</tt>. In general it makes generic
30507 programming with enumerations easier.
30515 Pete observes (and Tom concurs)
30516 that the proposed resolution seems to require compiler support
30517 for its implementation,
30518 as it seems necessary to look at the range of values
30519 of the enumerated type.
30520 To a first approximation,
30521 a library solution could give an answer based on the size of the type.
30522 If the user has specialized <tt>numeric_limits</tt> for the enumerated type,
30523 then the library might be able to do better,
30524 but there is no such requirement.
30525 Keep status as Open
30526 and solicit input from CWG.
30530 2009-05-23 Alisdair adds:
30535 Just to confirm that the BSI originator of this comment assumed it did
30536 indeed imply a compiler intrinsic. Rather than request a Core extension, it
30537 seemed in keeping with that the type traits interface provides a library API
30538 to unspecified compiler features - where we require several other traits
30539 (e.g. <tt>has_trivial_*</tt>) to get the 'right' answer now, unlike in TR1.
30543 <p><b>Proposed resolution:</b></p>
30545 Add a new row to the table in 20.6.7 [meta.trans.other]:
30550 <caption>Table 41 -- Other transformations</caption>
30558 <tt>template< class T > struct enum_base;</tt>
30561 <tt>T</tt> shall be an enumeration type (7.2 [dcl.enum])
30564 The member typedef <tt>type</tt> shall name the underlying type
30565 of the enum <tt>T</tt>.
30576 <h3><a name="1056"></a>1056. Must all Engines and Distributions be Streamable?</h3>
30577 <p><b>Section:</b> 26.5 [rand] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
30578 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-05-31</p>
30579 <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>
30580 <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>
30581 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
30582 <p><b>Discussion:</b></p>
30585 Both the concepts <tt>RandomNumberEngine</tt> and <tt>RandomNumberDistribution</tt> have
30586 requirements to be <tt>InputStreamable</tt> and <tt>OutputStreamable</tt>.
30589 I have no problems leaving the WP in an inconsistent state on the best-faith
30590 assumption these concepts will be provided later, however disagree with the
30591 proposers that these constraints are not separable, orthogonal to the basic
30592 concepts of generating random number distributions.
30595 These constraints should be dropped, and applied to specific algorithms as
30599 If a more refined concept (certainly deemed useful by the proposers) is
30600 proposed there is no objection, but the basic concept should not require
30601 persistence via streaming.
30613 2009-05-31 Alisdair adds:
30619 Working on constraining the stream iterators, I have a few more observations
30620 to make on the concepts proposed while constraining the random number
30624 While I still believe the concerns are orthogonal, I don't believe the
30625 existing constraints go far enough either! The goal we want to achieve is
30626 not that a <tt>RandomNumberEngine</tt> / <tt>RandomNumberDistribution</tt> supports the stream
30627 operators, but that it is <tt>Serializable</tt>. I.e. there is a relationship
30628 between the insert and extract operations that guarantees to restore the
30629 state of the original object. This implies a coupling of the concepts
30630 together in a broader concept (<tt>Serializable</tt>) with at least one axiom to
30631 assert the semantics.
30634 One problem is that <tt>istream</tt> and <tt>ostream</tt> may be fundamentally different
30635 types, although we can hook a relation if we are prepared to drop down to
30636 the <tt>char</tt> type and <tt>char_traits</tt> template parameters. Doing so ties us to a
30637 form of serialization that demands implementation via the std iostreams
30638 framework, which seems overly prescriptive. I believe the goal is generally
30639 to support serialization without regard to how it is expressed - although
30640 this is getting even more inventive in terms of concepts we do not have
30646 <p><b>Proposed resolution:</b></p>
30653 <h3><a name="1057"></a>1057. <tt>RandomNumberEngineAdaptor</tt></h3>
30654 <p><b>Section:</b> 26.5 [rand] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
30655 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-05-23</p>
30656 <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>
30657 <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>
30658 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
30659 <p><b>Discussion:</b></p>
30662 The <tt>RandomNumberEngineAdaptor</tt> concept breaks precedent in the
30663 way the library has been specified by grouping requirements into a
30664 concept that is never actually used in the library.
30667 This is undoubtedly a very helpful device for documentation, but we are not
30668 comfortable with the precedent - especially as we have rejected national
30669 body comments on the same grounds.
30672 Suggest either removing the concept, or providing an algorithm/type that
30673 requires this concept in their definition (such as a factory function to
30674 create new engines).
30677 The preference is to create a single new algorithm and retain the value of
30678 the existing documentation.
30687 Walter points out that it is unlikely that any algorithm would ever
30688 require this concept, but that the concept nonetheless is useful as
30689 documentation, and (via concept maps) as a means of checking specific adapters.
30692 Alisdair disagrees as to the concept's value as documentation.
30695 Marc points out that the <tt>RandomNumberDistribution</tt>
30696 is also a concept not used elsewhere in the Standard.
30699 Pete agrees that a policy of not inventing concepts
30700 that aren't used in the Standard is a good starting point,
30701 but should not be used as a criterion for rejecting a concept.
30709 <p><b>Proposed resolution:</b></p>
30716 <h3><a name="1058"></a>1058. New container issue</h3>
30717 <p><b>Section:</b> 23.2.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Tentatively NAD Editorial</a>
30718 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12 <b>Last modified:</b> 2009-05-23</p>
30719 <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>
30720 <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>
30721 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD%20Editorial">Tentatively NAD Editorial</a> status.</p>
30722 <p><b>Discussion:</b></p>
30725 Sequence containers 23.2.3 [sequence.reqmts]:
30729 The return value of new calls added to table 83 are not specified.
30738 We agree with the proposed resolution.
30741 Move to NAD Editorial.
30746 <p><b>Proposed resolution:</b></p>
30748 Add after p6 23.2.3 [sequence.reqmts]:
30756 The iterator returned from <tt>a.insert(p,rv)</tt> points to the copy of <tt>rv</tt>
30757 inserted into <tt>a</tt>.
30760 The iterator returned from <tt>a.emplace(p, args)</tt> points to the new
30761 element constructed from <tt>args</tt> inserted into <tt>a</tt>.
30770 <h3><a name="1059"></a>1059. Usage of no longer existing FunctionType concept</h3>
30771 <p><b>Section:</b> 20.7.16.2 [func.wrap.func] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
30772 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-03-13 <b>Last modified:</b> 2009-05-23</p>
30773 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#func.wrap.func">active issues</a> in [func.wrap.func].</p>
30774 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.wrap.func">issues</a> in [func.wrap.func].</p>
30775 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
30776 <p><b>Discussion:</b></p>
30778 Due to a deliberate core language decision, the earlier called
30779 "foundation" concept <tt>std::FunctionType</tt> had been removed in
30780 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2773.pdf">N2773</a>
30782 before the first "conceptualized" version of the WP
30783 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdf">N2798</a>)
30785 prepared. This caused a break of the library, which already used this
30786 concept in the adapted definition of <tt>std::function</tt>
30787 (20.7 [function.objects]/2, header <tt><functional></tt> synopsis and
30788 20.7.16.2 [func.wrap.func]).
30791 A simple fix would be to either (a) make <tt>std::function</tt>'s primary template
30792 unconstrained or to (b) add constraints based on existing (support) concepts.
30793 A more advanced fix would (c) introduce a new library concept.
30796 The big disadvantage of (a) is, that users can define templates which
30797 cause compiler errors during instantiation time because of under-constrainedness
30798 and would thus violate the basic advantage of constrained
30802 For (b), the ideal constraints for <tt>std::function</tt>'s template parameter would
30803 be one which excludes everything else but the single provided partial
30804 specialization that matches every "free function" type (i.e. any function
30805 type w/o cv-qualifier-seq and w/o ref-qualifier).
30806 Expressing such a type as as single requirement would be written as
30808 <blockquote><pre>template<typename T>
30809 requires ReferentType<T> // Eliminate cv void and function types with cv-qual-seq
30810 // or ref-qual (depending on core issue #749)
30811 && PointeeType<T> // Eliminate reference types
30812 && !ObjectType<T> // Eliminate object types
30813 </pre></blockquote>
30815 Just for completeness approach (c), which would make sense, if the
30816 library has more reasons to constrain for free function types:
30818 <blockquote><pre>auto concept FreeFunctionType<typename T>
30819 : ReferentType<T>, PointeeType<T>, MemberPointeeType<T>
30821 requires !ObjectType<T>;
30823 </pre></blockquote>
30825 I mention that approach because I expect that free function types belong
30826 to the most natural type categories for every days coders. Potential
30827 candidates in the library are <tt>addressof</tt> and class template <tt>packaged_task</tt>.
30836 Alisdair would prefer to have a core-supported <tt>FunctionType</tt> concept
30837 in order that any future changes be automatically correct
30838 without need for a library solution to catch up;
30839 he points to type traits as a precedent.
30840 Further, he believes that a published concept can't in the future
30844 Bill feels this category of entity would change sufficiently slowly
30845 that he would be willing to take the risk.
30848 Of the discussed solutions, we tend toward option (c).
30849 We like the idea of having a complete taxonomy of native types,
30850 and perhaps erred in trimming the set.
30853 We would like to have this issue reviewed by Core and would like
30854 their feedback. Move to Open.
30859 <p><b>Proposed resolution:</b></p>
30863 Change in 20.7 [function.objects]/2, Header <tt><functional></tt> synopsis:
30865 <blockquote><pre>// 20.6.16 polymorphic function wrappers:
30866 class bad_function_call;
30867 template<<del>FunctionType</del><ins>ReferentType F</ins>>
30868 <ins>requires PointeeType<F> && !ObjectType<F></ins>
30869 class function; // undefined
30870 </pre></blockquote>
30874 Change in 20.7.16.2 [func.wrap.func]:
30876 <blockquote><pre>namespace std {
30877 template<<del>FunctionType</del><ins>ReferentType F</ins>>
30878 <ins>requires PointeeType<F> && !ObjectType<F></ins>
30879 class function; // undefined
30880 </pre></blockquote>
30889 <h3><a name="1060"></a>1060. Embedded nulls in NTBS</h3>
30890 <p><b>Section:</b> 17.5.2.1.4.1 [byte.strings] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Tentatively NAD Editorial</a>
30891 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-13 <b>Last modified:</b> 2009-05-23</p>
30892 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD%20Editorial">Tentatively NAD Editorial</a> status.</p>
30893 <p><b>Discussion:</b></p>
30896 Definition of null-terminated sequences allow for embedded nulls. This is
30897 surprising, and probably not supportable with the intended use cases.
30905 We agree with the issue, but believe this can be handled editorially.
30906 Move to NAD Editorial.
30911 <p><b>Proposed resolution:</b></p>
30918 <h3><a name="1061"></a>1061. Bad indexing for tuple access to pair (Editorial?)</h3>
30919 <p><b>Section:</b> 20.3.4 [pair.astuple] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Tentatively NAD Editorial</a>
30920 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-13 <b>Last modified:</b> 2009-05-23</p>
30921 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD%20Editorial">Tentatively NAD Editorial</a> status.</p>
30922 <p><b>Discussion:</b></p>
30925 The definition of <tt>get</tt> implies that <tt>get</tt> must return the second element if
30926 given a negative integer.
30934 Move to NAD Editorial.
30939 <p><b>Proposed resolution:</b></p>
30941 20.3.4 [pair.astuple] p5:
30944 <blockquote><pre>template<<del>int</del> <ins>size_t</ins> I, class T1, class T2>
30945 requires True<(I < 2)>
30946 const P& get(const pair<T1, T2>&);
30956 <h3><a name="1062"></a>1062. Missing insert_iterator for stacks/queues</h3>
30957 <p><b>Section:</b> 24.7 [insert.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
30958 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-13 <b>Last modified:</b> 2009-05-23</p>
30959 <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>
30960 <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>
30961 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
30962 <p><b>Discussion:</b></p>
30965 It is odd that we have an iterator to insert into a <tt>vector</tt>, but not an
30966 iterator to insert into a <tt>vector</tt> that is adapted as a <tt>stack</tt>. The standard
30967 container adapters all have a common interface to <tt>push</tt> and <tt>pop</tt> so it should
30968 be simple to create an iterator adapter to complete the library support.
30972 We should provide an <tt>AdaptedContainer</tt> concept supporting <tt>push</tt> and <tt>pop</tt>
30973 operations. Create a new insert iterator and factory function that inserts
30974 values into the container by calling <tt>push</tt>.
30983 Walter recommends NAD Future.
30986 Move to Open, and recommend deferring the issue until after the next
30987 Committee Draft is issued.
30992 <p><b>Proposed resolution:</b></p>
30999 <h3><a name="1063"></a>1063. 03 iterator compatibilty</h3>
31000 <p><b>Section:</b> D.10.4 [iterator.backward] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
31001 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-15 <b>Last modified:</b> 2009-05-23</p>
31002 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
31003 <p><b>Discussion:</b></p>
31006 Which header must a user <tt>#include</tt> to obtain the library-supplied
31007 <tt>concept_maps</tt> declared in this paragraph?
31011 This is important information, as existing user code will break if this
31012 header is not included, and we should make a point of mandating this header
31013 is <tt>#include</tt>-d by library headers likely to make use of it, notably
31014 <tt><algorithm></tt>. See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1001">1001</a> for more details.
31022 We agree with the direction of the proposed resolution.
31023 Move to Tentatively Ready.
31027 <p><b>Proposed resolution:</b></p>
31028 <p><i>Change D.10 [depr.lib.iterator.primitives], Iterator primitives, as
31032 <p>To simplify the use of iterators and provide backward compatibility with
31033 previous C++ Standard Libraries,
31034 the library provides several classes and functions. <ins>Unless otherwise
31035 specified, these classes and functions shall be defined in header <tt><iterator></tt>.</ins></p>
31037 <p><i>Change D.10.4 [iterator.backward], Iterator backward compatibility, as
31040 <p>The library provides concept maps that allow iterators specified with
31041 <tt>iterator_traits</tt> to interoperate with
31042 algorithms that require iterator concepts. <ins>These concept maps shall be
31043 defined in the same header that defines the iterator.</ins> [<i>Example:</i></p>
31051 <h3><a name="1064"></a>1064. Response to UK 152</h3>
31052 <p><b>Section:</b> 17.3.15 [defns.obj.state] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
31053 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-15 <b>Last modified:</b> 2009-03-15</p>
31054 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
31055 <p><b>Discussion:</b></p>
31057 <p><b>Addresses UK 152</b></p>
31060 Object state is using a definition of object (instance of a class) from
31061 outside the standard, rather than the 'region of storage' definiton in
31062 1.8 [intro.object]p1
31070 We think we're removing this; See 20.7.18.1 [func.referenceclosure.cons].
31074 <p><b>Proposed resolution:</b></p>
31083 <h3><a name="1065"></a>1065. Response to UK 168</h3>
31084 <p><b>Section:</b> 17.6.1.1 [contents] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
31085 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-15 <b>Last modified:</b> 2009-05-23</p>
31086 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#contents">active issues</a> in [contents].</p>
31087 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#contents">issues</a> in [contents].</p>
31088 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
31089 <p><b>Discussion:</b></p>
31090 <p><b>Addresses UK 168</b></p>
31092 We should make it clear (either by note or normatively) that namespace
31093 <tt>std</tt> may contain inline namespaces, and that entities specified to be
31094 defined in std may in fact be defined in one of these inline namespaces.
31095 (If we're going to use them for versioning, eg when TR2 comes along,
31096 we're going to need that.)
31100 Replace "namespace std or namespaces nested within namespace std" with
31101 "namespace std or namespaces nested within namespace std or inline
31102 namespaces nested directly or indirectly within namespace std"
31110 adopt UK words (some have reservations whether it is correct)
31114 2009-05-09 Alisdair improves the wording.
31124 Bill believes there is strictly speaking no need to say that
31125 because no portable test can detect the difference.
31126 However he agrees that it doesn't hurt to say this.
31129 Move to Tentatively Ready.
31134 <p><b>Proposed resolution:</b></p>
31136 Change 17.6.1.1 [contents] p2:
31140 All library entities except macros, <tt>operator new</tt> and
31141 <tt>operator delete</tt> are defined within the namespace <tt>std</tt> or
31142 namespaces nested within namespace <tt>std</tt>.
31143 <ins>It is unspecified whether names declared in a specific namespace
31144 are declared directly in that namespace, or in an inline namespace inside
31145 that namespace. [<i>Footnote:</i> This gives implementers freedom to support
31146 multiple configurations of the library.]</ins>
31154 <h3><a name="1066"></a>1066. Response to UK 189 and JP 27</h3>
31155 <p><b>Section:</b> 18 [language.support] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
31156 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-15 <b>Last modified:</b> 2009-05-23</p>
31157 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
31158 <p><b>Discussion:</b></p>
31159 <p><b>Addresses UK 189 and JP 27</b></p>
31161 The addition of the <tt>[[noreturn]]</tt> attribute to the language will be an
31162 important aid for static analysis tools.
31166 The following functions should be declared in C++ with the
31167 <tt>[[noreturn]]</tt> attribute: <tt>abort</tt> <tt>exit</tt>
31168 <tt>quick_exit</tt> <tt>terminate</tt> <tt>unexpected</tt>
31169 <tt>rethrow_exception</tt> <tt>throw_with_nested</tt>.
31185 We agree with the proposed resolution.
31186 Move to Tentatively Ready.
31190 <p><b>Proposed resolution:</b></p>
31192 Change 18.5 [support.start.term] p3:
31197 <pre><ins>void</ins> abort <ins>[[noreturn]]</ins> (void)
31201 <pre><ins>void</ins> exit<ins> [[noreturn]] </ins>(int status)
31205 <pre>void quick_exit<ins> [[noreturn]] </ins>(int status)
31211 Change the <tt><exception></tt> synopsis in 18.8 [support.exception]:
31214 <blockquote><pre>void unexpected<ins> [[noreturn]] </ins>();
31216 void terminate<ins> [[noreturn]] </ins>();
31218 void rethrow_exception<ins> [[noreturn]] </ins>(exception_ptr p);
31220 template <class T> void throw_with_nested<ins> [[noreturn]] </ins>(T&& t); <del>// [[noreturn]]</del>
31221 </pre></blockquote>
31224 Change 18.8.2.4 [unexpected]:
31227 <blockquote><pre>void unexpected<ins> [[noreturn]] </ins>();
31228 </pre></blockquote>
31231 Change 18.8.3.3 [terminate]:
31234 <blockquote><pre>void terminate<ins> [[noreturn]] </ins>();
31235 </pre></blockquote>
31238 Change 18.8.5 [propagation]:
31241 <blockquote><pre>void rethrow_exception<ins> [[noreturn]] </ins>(exception_ptr p);
31242 </pre></blockquote>
31245 In the synopsis of 18.8.6 [except.nested] and the definition area change:
31248 <blockquote><pre>template <class T> void throw_with_nested<ins> [[noreturn]] </ins>(T&& t); <del>// [[noreturn]]</del>
31249 </pre></blockquote>
31256 <h3><a name="1067"></a>1067. simplified wording for inner_product</h3>
31257 <p><b>Section:</b> 26.7 [numeric.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
31258 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-17 <b>Last modified:</b> 2009-05-23</p>
31259 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
31260 <p><b>Discussion:</b></p>
31263 One of the motivating examples for introducing requirements-aliases was to
31264 simplify the wording of the <tt>inner_product</tt> requirements. As the paper
31265 adopting the feature and constrained wording for the library went through in
31266 the same meeting, it was not possible to make the change at the time. The
31267 simpler form should be adopted now though. Similarly, most the other
31268 numerical algorithms can benefit from a minor cleanup.
31271 Note that in each case, the second more generalised form of the algorithm
31272 does not benefit, as there are already named constraints supplied by the
31273 template type parameters.
31277 2009-05-02 Daniel adds:
31283 one part of the suggested resolution suggests the removal of the
31284 <tt>MoveConstructible<T></tt> requirement from
31285 <tt>inner_product</tt>. According to 26.7.2 [inner.product]
31289 Computes its result by initializing the accumulator <tt>acc</tt> with the
31290 initial value <tt>init</tt>
31294 this step requires at least <tt>MoveConstructible</tt>.
31298 Therefore I strongly suggest to take this removal back (Note also
31299 that the corresponding overload with a functor argument still has
31300 the same <tt>MoveConstructible<T></tt> requirement).
31310 We agree with the proposed resolution as amended by Daniel's suggestion
31311 to restore <tt>MoveConstructible</tt>,
31312 reflected in the updated proposed resolution below.
31315 Move to Tentatively Ready.
31320 <p><b>Proposed resolution:</b></p>
31322 Change in 26.7 [numeric.ops] and [accumulate]:
31325 <blockquote><pre>template <InputIterator Iter, MoveConstructible T>
31326 requires <ins>add =</ins> HasPlus<T, Iter::reference>
31327 && HasAssign<T, <del>HasPlus<T, Iter::reference></del> <ins>add</ins>::result_type>
31328 T accumulate(Iter first, Iter last, T init);
31329 </pre></blockquote>
31332 Change in 26.7 [numeric.ops] and 26.7.2 [inner.product]:
31335 <blockquote><pre>template <InputIterator Iter1, InputIterator Iter2, MoveConstructible T>
31336 requires <ins>mult =</ins> HasMultiply<Iter1::reference, Iter2::reference>
31337 && <ins>add =</ins> HasPlus<T, <del>HasMultiply<Iter1::reference, Iter2::reference></del> <ins>mult</ins>::result_type>
31338 && HasAssign<
31341 HasMultiply<Iter1::reference, Iter2::reference>::result_type></del> <ins>add</ins>::result_type>
31342 T inner_product(Iter1 first1, Iter1 last1, Iter2 first2, T init);
31343 </pre></blockquote>
31346 Change in 26.7 [numeric.ops] and 26.7.3 [partial.sum]:
31349 <blockquote><pre>template <InputIterator InIter, OutputIterator<auto, const InIter::value_type&> OutIter>
31350 requires <ins>add =</ins> HasPlus<InIter::value_type, InIter::reference>
31351 && HasAssign<InIter::value_type,
31352 <del>HasPlus<InIter::value_type, InIter::reference></del> <ins>add</ins>::result_type>
31353 && Constructible<InIter::value_type, InIter::reference>
31354 OutIter partial_sum(InIter first, InIter last, OutIter result);
31355 </pre></blockquote>
31358 Change in 26.7 [numeric.ops] and 26.7.4 [adjacent.difference]:
31361 <blockquote><pre>template <InputIterator InIter, OutputIterator<auto, const InIter::value_type&> OutIter>
31362 requires <ins>sub =</ins> HasMinus<InIter::value_type, InIter::value_type>
31363 && Constructible<InIter::value_type, InIter::reference>
31364 && OutputIterator<OutIter, <del>HasMinus<InIter::value_type, InIter::value_type></del> <ins>sub</ins>::result_type>
31365 && MoveAssignable<InIter::value_type>
31366 OutIter adjacent_difference(InIter first, InIter last, OutIter result);
31367 </pre></blockquote>
31375 <h3><a name="1068"></a>1068. class random_device should be movable</h3>
31376 <p><b>Section:</b> 26.5.6 [rand.device] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
31377 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-18 <b>Last modified:</b> 2009-05-23</p>
31378 <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>
31379 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
31380 <p><b>Discussion:</b></p>
31383 class <tt>random_device</tt> should be movable.
31391 Move to Open, and recommend this issue be deferred until after the next
31392 Committee Draft is issued.
31396 <p><b>Proposed resolution:</b></p>
31403 <h3><a name="1069"></a>1069. class seed_seq should support efficient move operations</h3>
31404 <p><b>Section:</b> 26.5.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
31405 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-18 <b>Last modified:</b> 2009-05-23</p>
31406 <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>
31407 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
31408 <p><b>Discussion:</b></p>
31411 class <tt>seed_seq</tt> should support efficient move operations.
31419 Move to Open, and recommend this issue be deferred until after the next
31420 Committee Draft is issued.
31424 <p><b>Proposed resolution:</b></p>
31431 <h3><a name="1070"></a>1070. Ambiguous move overloads in function</h3>
31432 <p><b>Section:</b> 20.7.16.2 [func.wrap.func] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
31433 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-19 <b>Last modified:</b> 2009-05-23</p>
31434 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#func.wrap.func">active issues</a> in [func.wrap.func].</p>
31435 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.wrap.func">issues</a> in [func.wrap.func].</p>
31436 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
31437 <p><b>Discussion:</b></p>
31439 The synopsis in 20.7.16.2 [func.wrap.func] says:
31442 <blockquote><pre>template<Returnable R, CopyConstructible... ArgTypes>
31443 class function<R(ArgTypes...)>
31446 template<class F>
31447 requires CopyConstructible<F> && Callable<F, ArgTypes...>
31448 && Convertible<Callable<F, ArgTypes...>::result_type, R>
31450 template<class F>
31451 requires CopyConstructible<F> && Callable<F, ArgTypes...>
31452 && Convertible<Callable<F, ArgTypes...>::result_type, R>
31453 function(F&&);
31455 template<class F, Allocator Alloc> function(allocator_arg_t, const Alloc&, F);
31456 template<class F, Allocator Alloc> function(allocator_arg_t, const Alloc&, F&&);
31458 template<class F>
31459 requires CopyConstructible<F> && Callable<F, ArgTypes..>
31460 && Convertible<Callable<F, ArgTypes...>::result_type
31461 function& operator=(F);
31462 template<class F>
31463 requires CopyConstructible<F> && Callable<F, ArgTypes...>
31464 && Convertible<Callable<F, ArgTypes...>::result_type, R>
31465 function& operator=(F&&);
31468 </pre></blockquote>
31471 Each of the 3 pairs above are ambiguous. We need only one of each pair, and we
31472 could do it with either one. If we choose the <tt>F&&</tt> version we
31473 need to bring <tt>decay</tt> into the definition to get the pass-by-value behavior.
31474 In the proposed wording I've gotten lazy and just used the pass-by-value signature.
31478 2009-05-01 Daniel adds:
31483 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1024">1024</a> modifies the second removed constructor.
31492 We briefly discussed whether we ought support moveable function objects,
31493 but decided that should be a separate issue if someone cares to propose it.
31496 Move to Tentatively Ready.
31501 <p><b>Proposed resolution:</b></p>
31503 Change the synopsis of 20.7.16.2 [func.wrap.func], and remove the associated definitions in
31504 20.7.16.2.1 [func.wrap.func.con]:
31507 <blockquote><pre>template<Returnable R, CopyConstructible... ArgTypes>
31508 class function<R(ArgTypes...)>
31511 template<class F>
31512 requires CopyConstructible<F> && Callable<F, ArgTypes...>
31513 && Convertible<Callable<F, ArgTypes...>::result_type, R>
31515 <del>template<class F>
31516 requires CopyConstructible<F> && Callable<F, ArgTypes...>
31517 && Convertible<Callable<F, ArgTypes...>::result_type, R>
31518 function(F&&);</del>
31520 template<class F, Allocator Alloc> function(allocator_arg_t, const Alloc&, F);
31521 <del>template<class F, Allocator Alloc> function(allocator_arg_t, const Alloc&, F&&);</del>
31523 template<class F>
31524 requires CopyConstructible<F> && Callable<F, ArgTypes..>
31525 && Convertible<Callable<F, ArgTypes...>::result_type
31526 function& operator=(F);
31527 <del>template<class F>
31528 requires CopyConstructible<F> && Callable<F, ArgTypes...>
31529 && Convertible<Callable<F, ArgTypes...>::result_type, R>
31530 function& operator=(F&&);</del>
31533 </pre></blockquote>
31541 <h3><a name="1071"></a>1071. is_bind_expression should derive from integral_constant<bool></h3>
31542 <p><b>Section:</b> 20.7.12.1.1 [func.bind.isbind] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
31543 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-19 <b>Last modified:</b> 2009-05-31</p>
31544 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
31545 <p><b>Discussion:</b></p>
31548 Class template is_bind_expression 20.7.12.1.1 [func.bind.isbind]:
31551 <blockquote><pre>namespace std {
31552 template<class T> struct is_bind_expression {
31553 static const bool value = see below;
31556 </pre></blockquote>
31558 <tt>is_bind_expression</tt> should derive from <tt>std::integral_constant<bool></tt> like
31559 other similar trait types.
31567 We need the same thing for the trait <tt>is_placeholder</tt> as well.
31570 2009-03-22 Daniel provided wording.
31580 We recommend this be deferred until after the next Committee Draft is issued.
31588 2009-05-31 Peter adds:
31594 I am opposed to the proposed resolution and to the premise of the issue
31595 in general. The traits's default definitions should NOT derive from
31596 <tt>integral_constant</tt>, because this is harmful, as it misleads people into
31597 thinking that <tt>is_bind_expression<E></tt> always derives from
31598 <tt>integral_constant</tt>, whereas it may not.
31601 <tt>is_bind_expression</tt> and <tt>is_placeholder</tt> allow user
31602 specializations, and in fact, this is their primary purpose. Such user
31603 specializations may not derive from <tt>integral_constant</tt>, and the
31604 places where <tt>is_bind_expression</tt> and <tt>is_placeholder</tt> are
31605 used intentionally do not require such derivation.
31608 The long-term approach here is to switch to
31609 <tt>BindExpression<E></tt> and <tt>Placeholder<P></tt>
31610 explicit concepts, of course, but until that happens, I say leave them
31617 <p><b>Proposed resolution:</b></p>
31621 In 20.7.12.1.1 [func.bind.isbind] change as indicated:
31623 <blockquote><pre>namespace std {
31624 template<class T> struct is_bind_expression <ins>: integral_constant<bool, <i>see below</i>> { };</ins><del>{
31625 static const bool value = <i>see below</i>;
31628 </pre></blockquote>
31632 In 20.7.12.1.1 [func.bind.isbind]/2 change as indicated:
31634 <blockquote><pre><del>static const bool value;</del>
31637 -2- <del><tt>true</tt> if <tt>T</tt> is a type returned from <tt>bind</tt>, <tt>false</tt> otherwise.</del>
31638 <ins>If <tt>T</tt> is a type returned from <tt>bind</tt>, <tt>is_bind_expression<T></tt> shall
31639 be publicly derived from
31640 <tt>integral_constant<bool, true></tt>, otherwise it shall be
31641 publicly derived from
31642 <tt>integral_constant<bool, false></tt>.</ins>
31648 In 20.7.12.1.2 [func.bind.isplace] change as indicated:
31650 <blockquote><pre>namespace std {
31651 template<class T> struct is_placeholder <ins>: integral_constant<int, <i>see below</i>> { };</ins><del>{
31652 static const int value = <i>see below</i>;
31655 </pre></blockquote>
31659 In 20.7.12.1.2 [func.bind.isplace]/2 change as indicated:
31661 <blockquote><pre><del>static const int value;</del>
31664 -2- <del>value is <tt>J</tt> if <tt>T</tt> is the type of <tt>std::placeholders::_J</tt>, 0 otherwise.</del>
31665 <ins>If <tt>T</tt> is the type of <tt>std::placeholders::_J</tt>, <tt>is_placeholder<T></tt>
31667 derived from <tt>integral_constant<int, J></tt> otherwise it shall
31668 be publicly derived
31669 from <tt>integral_constant<int, 0></tt>.</ins>
31680 <h3><a name="1072"></a>1072. Is std::hash a constrained template or not?</h3>
31681 <p><b>Section:</b> 20.7.17 [unord.hash] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
31682 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-19 <b>Last modified:</b> 2009-05-23</p>
31683 <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>
31684 <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>
31685 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
31686 <p><b>Discussion:</b></p>
31689 Is <tt>std::hash</tt> a constrained template or not?
31692 According to Class template hash 20.7.17 [unord.hash], the definition is:
31695 <blockquote><pre>template <class T>
31696 struct hash : public std::unary_function<T, std::size_t> {
31697 std::size_t operator()(T val) const;
31699 </pre></blockquote>
31702 And so unconstrained.
31705 According to the <tt><functional></tt> synopsis in p2 Function objects
31706 20.7 [function.objects] the template is declared as:
31709 <blockquote><pre>template <ReferentType T> struct hash;
31710 </pre></blockquote>
31713 which would make hash a constrained template.
31717 2009-03-22 Daniel provided wording.
31727 Alisdair is not certain that Daniel's proposed resolution is sufficient,
31728 and recommends we leave the hash template unconstrained for now.
31731 Recommend that the Project Editor make the constrained declaration consistent
31732 with the definition in order to make the Working Paper internally consistent,
31733 and that the issue then be revisited.
31741 <p><b>Proposed resolution:</b></p>
31744 [To the editor: This resolution is merge-compatible to the
31745 resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1078">1078</a>]
31751 In 20.7 [function.objects]/2, header <tt><functional></tt> synopsis, change as indicated:
31754 <blockquote><pre>// 20.6.17, hash function base template:
31755 template <ReferentType T> struct hash; <ins>// undefined</ins>
31756 </pre></blockquote>
31760 In 20.7.17 [unord.hash]/1 change as indicated:
31762 <blockquote><pre>namespace std {
31763 <del>template <class T>
31764 struct hash : public std::unary_function<T, std::size_t> {
31765 std::size_t operator()(T val) const;
31767 <ins>template <ReferentType T> struct hash; // undefined</ins>
31769 </pre></blockquote>
31773 In 20.7.17 [unord.hash]/2 change as indicated:
31777 -2- <ins>For all library-provided specializations, the template
31778 instantiation <tt>hash<T></tt>
31779 shall provide a public <tt>operator()</tt> with return type <tt>std::size_t</tt> to
31780 satisfy the concept
31781 requirement <tt>Callable<const hash<T>, const T&></tt>. If <tt>T</tt> is an object
31782 type or reference to
31783 object, <tt>hash<T></tt> shall be publicly derived from
31784 <tt>std::unary_function<T, std::size_t></tt>.
31785 </ins> The return value of <tt>operator()</tt> is unspecified, except that
31787 shall yield the same result. <tt>operator()</tt> shall not throw exceptions.
31792 In 18.7 [support.rtti]/1, header <tt><typeinfo></tt> synopsis change as indicated:
31794 <blockquote><pre>namespace std {
31797 template <<del>class</del><ins>ReferentType</ins> T> struct hash;
31798 </pre></blockquote>
31807 <h3><a name="1073"></a>1073. Declaration of <tt>allocator_arg</tt> should be <tt>constexpr</tt></h3>
31808 <p><b>Section:</b> 20.8 [memory] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
31809 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-19 <b>Last modified:</b> 2009-05-23</p>
31810 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#memory">active issues</a> in [memory].</p>
31811 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#memory">issues</a> in [memory].</p>
31812 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
31813 <p><b>Discussion:</b></p>
31816 Declaration of <tt>allocator_arg</tt> should be <tt>constexpr</tt> to ensure constant
31825 We agree with the proposed resolution. Move to Tentatively Ready.
31829 <p><b>Proposed resolution:</b></p>
31831 Change 20.8 [memory] p2:
31834 <blockquote><pre>// 20.8.1, allocator argument tag
31835 struct allocator_arg_t { };
31836 const<ins>expr</ins> allocator_arg_t allocator_arg = allocator_arg_t();
31837 </pre></blockquote>
31845 <h3><a name="1074"></a>1074. concept map broken by N2840</h3>
31846 <p><b>Section:</b> 20.8.3 [allocator.element.concepts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">Tentatively NAD</a>
31847 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-19 <b>Last modified:</b> 2009-05-23</p>
31848 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD">Tentatively NAD</a> status.</p>
31849 <p><b>Discussion:</b></p>
31852 p7 Allocator-related element concepts 20.8.3 [allocator.element.concepts]
31856 The changes to the <tt>AllocatableElement</tt> concept mean this <tt>concept_map</tt>
31857 specialization no longer matches the original concept:
31860 <blockquote><pre>template <Allocator Alloc, class T, class ... Args>
31861 requires HasConstructor<T, Args...>
31862 concept_map AllocatableElement<Alloc, T, Args&&...> {
31863 void construct_element(Alloc& a, T* t, Args&&... args) {
31864 Alloc::rebind<T>(a).construct(t, forward(args)...);
31867 </pre></blockquote>
31870 2009-03-23 Pablo adds:
31875 Actually, this is incorrect,
31876 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2840.pdf">N2840</a>
31878 20.8.3 [allocator.element.concepts] paragraph 8, modify the definition of the
31879 <tt>AllocatableElement</tt> concept and eliminate the related concept map:" but
31880 then neglects to include the red-lined text of the concept map that was
31881 to be eliminated. Pete also missed this, but I caught it he asked me to
31882 review his edits. Pete's updated WP removes the concept map entirely,
31883 which was the original intent. The issue is, therefore, moot. Note, as
31884 per my presentation of
31885 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2840.pdf">N2840</a>
31886 in summit, <tt>construct()</tt> no longer has a
31887 default implementation. This regrettable fact was deemed (by David
31888 Abrahams, Doug, and myself) to be preferable to the complexity of
31889 providing a default implementation that would not under-constrain a more
31890 restrictive allocator (like the scoped allocators).
31894 2009-05-01 Daniel adds:
31899 it seems to me that #1074 should be resolved as a NAD, because the
31900 current WP has already removed the previous AllocatableElement concept map.
31901 It introduced auto concept AllocatableElement instead, but as of
31902 20.8.3 [allocator.element.concepts]/7 this guy contains now
31904 <blockquote><pre>requires FreeStoreAllocatable<T>;
31905 void Alloc::construct(T*, Args&&...);
31906 </pre></blockquote>
31915 The affected code is no longer part of the Working Draft.
31923 <p><b>Proposed resolution:</b></p>
31925 Change 20.8.3 [allocator.element.concepts]:
31928 <blockquote><pre>template <Allocator Alloc, class T, class ... Args>
31929 requires HasConstructor<T, Args...>
31930 concept_map AllocatableElement<Alloc, T, Args&&...> {
31931 void construct_element(<del>Alloc& a,</del> T* t, Args&&... args) {
31932 Alloc::rebind<T>(a).construct(t, forward(args)...);
31935 </pre></blockquote>
31943 <h3><a name="1075"></a>1075. Response to US 65, US 74.1</h3>
31944 <p><b>Section:</b> 20 [utilities], 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
31945 <b>Submitter:</b> Alan Talbot <b>Opened:</b> 2009-03-20 <b>Last modified:</b> 2009-06-10</p>
31946 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#utilities">issues</a> in [utilities].</p>
31947 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
31948 <p><b>Discussion:</b></p>
31949 <p><b>Addresses US 65 and US 74.1</b></p>
31954 Scoped allocators and allocator propagation traits add a small amount of
31955 utility at the cost of a great deal of machinery. The machinery is user
31956 visible, and it extends to library components that don't have any
31957 obvious connection to allocators, including basic concepts and simple
31958 components like <tt>pair</tt> and <tt>tuple</tt>.
31960 <p>Suggested resolution:</p>
31963 Sketch of proposed resolution: Eliminate scoped allocators, replace
31964 allocator propagation traits with a simple uniform rule (e.g. always
31965 propagate on copy and move), remove all mention of allocators from
31966 components that don't explicitly allocate memory (e.g. pair), and adjust
31967 container interfaces to reflect this simplification.
31970 Components that I propose eliminating include HasAllocatorType,
31971 is_scoped_allocator, allocator_propagation_map, scoped_allocator_adaptor,
31972 and ConstructibleAsElement.
31980 Scoped allocators represent a poor trade-off for standardization, since
31981 (1) scoped-allocator--aware containers can be implemented outside the
31982 C++ standard library but used with its algorithms, (2) scoped
31983 allocators only benefit a tiny proportion of the C++ community
31984 (since few C++ programmers even use today's allocators), and (3) all C++
31985 users, especially the vast majority of the C++ community that won't ever
31986 use scoped allocators are forced to cope with the interface complexity
31987 introduced by scoped allocators.
31990 In essence, the larger community will suffer to support a very small
31991 subset of the community who can already implement their own
31992 data structures outside of the standard library. Therefore, scoped
31993 allocators should be removed from the working paper.
31996 Some evidence of the complexity introduced by scoped allocators:
32000 20.3.3 [pairs], 20.5 [tuple]: Large increase in the
32001 number of pair and tuple constructors.
32004 23 [containers]: Confusing "AllocatableElement" requirements throughout.
32007 <p>Suggested resolution:</p>
32010 Remove support for scoped allocators from the working paper. This
32011 includes at least the following changes:
32016 Remove 20.8.3 [allocator.element.concepts]
32019 Remove 20.8.7 [allocator.adaptor]
32022 Remove 20.8.10 [construct.element]
32025 In Clause 23 [containers]: replace requirements naming the
32026 <tt>AllocatableElement</tt> concept with requirements naming <tt>CopyConstructible</tt>,
32027 <tt>MoveConstructible</tt>, <tt>DefaultConstructible</tt>, or <tt>Constructible</tt>, as
32035 Post Summit Alan moved from NAD to Open.
32040 2009-05-15 Ganesh adds:
32046 The requirement <tt>AllocatableElement</tt> should not be replaced with
32047 <tt>Constructible</tt> on the <tt>emplace_xxx()</tt> functions as suggested. In the
32048 one-parameter case the <tt>Constructible</tt> requirement is not satisfied when
32049 the constructor is explicit (as per 14.10.2.1 [concept.map.fct], twelfth
32050 bullet) but we do want to allow explicit constructors in emplace, as the
32051 following example shows:
32054 <blockquote><pre>vector<shared_ptr<int>> v;
32055 v.emplace_back(new int); <font color="#c80000">// should be allowed</font>
32056 </pre></blockquote>
32059 If the issue is accepted and scoped allocators are removed, I suggest to
32060 add a new pair of concepts to 20.2.7 [concept.construct], namely:
32063 <blockquote><pre>auto concept HasExplicitConstructor<typename T, typename... Args> {
32064 explicit T::T(Args...);
32067 auto concept ExplicitConstructible<typename T, typename... Args>
32068 : HasExplicitConstructor<T, Args...>, NothrowDestructible<T>
32070 </pre></blockquote>
32073 We should then use <tt>ExplicitConstructible</tt> as the requirement for all
32074 <tt>emplace_xxx()</tt> member functions.
32077 For coherence and consistency with the similar concepts
32078 <tt>Convertible/ExplicitlyConvertible</tt>, we might also consider changing
32079 <tt>Constructible</tt> to:
32082 <blockquote><pre>auto concept Constructible<typename T, typename... Args>
32083 : HasConstructor<T, Args...>, ExplicitConstructible<T, Args...>
32085 </pre></blockquote>
32088 Moreover, all emplace-related concepts in 23.2.6 [container.concepts]
32089 should also use <tt>ExplicitConstructible</tt> instead of <tt>Constructible</tt> in the
32090 definitions of their axioms. In fact the concepts in 23.2.6 [container.concepts] should be
32091 corrected even if the issue is not accepted.
32094 On the other hand, if the issue is not accepted, the scoped allocator
32095 adaptors should be fixed because the following code:
32098 <blockquote><pre>template <typename T> using scoped_allocator = scoped_allocator_adaptor<allocator<T>>;
32100 vector<shared_ptr<int>, scoped_allocator<shared_ptr<int>>> v;
32101 v.emplace_back(new int); <font color="#c80000">// ops! doesn't compile</font>
32102 </pre></blockquote>
32105 doesn't compile, as the member function <tt>construct()</tt> of the scoped
32106 allocator requires non-explicit constructors through concept
32107 <tt>ConstructibleWithAllocator</tt>. Fixing that is not difficult but probably
32108 more work than it's worth and is therefore, IMHO, one more reason in
32109 support of the complete removal of scoped allocators.
32114 2009-06-09 Alan adds:
32120 I reopened this issue because I did not think that these National Body
32121 comments were adequately addressed by marking them NAD. My understanding
32122 is that something can be marked NAD if it is clearly a misunderstanding
32123 or trivial, but a substantive issue that has any technical merit
32124 requires a disposition that addresses the concerns.
32127 The notes in the NB comment list (US 65 & US 74.1) say that:
32131 this issue has not introduced any new arguments not previously discussed,
32134 the vote (4-9-3) was not a consensus for removing scoped allocators,
32137 the issue is resolved by
32138 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2840.pdf">N2840</a>.
32146 there are new arguments in both comments regarding concepts (which were
32147 not present in the library when the scoped allocator proposal was voted
32151 the vote was clearly not a consensus for removal, but just saying there
32152 was a vote does not provide a rationale,
32155 I do not believe that N2840 addresses these comments (although it does
32156 many other things and was voted in with strong approval).
32161 My motivation to open the issue was to ensure that the NB comments were
32162 adequately addressed in a way that would not risk a "no" vote on our
32163 FCD. If there are responses to the technical concerns raised, then
32164 perhaps they should be recorded. If the members of the NB who authored
32165 the comments are satisfied with N2840 and the other disposition remarks
32166 in the comment list, then I am sure they will say so. In either case,
32167 this issue can be closed very quickly in Frankfurt, and hopefully will
32168 have helped make us more confident of approval with little effort. If in
32169 fact there is controversy, my thought is that it is better to know now
32170 rather than later so there is more time to deal with it.
32176 <p><b>Proposed resolution:</b></p>
32183 <h3><a name="1076"></a>1076. unary/binary_negate need constraining and move support</h3>
32184 <p><b>Section:</b> 20.7.11 [negators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
32185 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-20 <b>Last modified:</b> 2009-05-23</p>
32186 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
32187 <p><b>Discussion:</b></p>
32189 The class templates <tt>unary/binary_negate</tt> need constraining and move support.
32192 Ideally these classes would be deprecated, allowing <tt>unary/binary_function</tt> to
32193 also be deprecated. However, until a generic negate adaptor is introduced
32194 that can negate any <tt>Callable</tt> type, they must be supported so should be
32195 constrained. Likewise, they should be movable, and support adopting a
32196 move-only predicate type.
32199 In order to preserve ABI compatibility, new rvalue overloads are supplied in
32200 preference to changing the existing pass-by-const-ref to pass-by-value.
32203 Do not consider the issue of forwarding mutable lvalues at this point,
32204 although remain open to another issue on the topic.
32208 2009-05-01 Daniel adds:
32213 IMO the currently proposed resolution needs some updates
32214 because it is ill-formed at several places:
32220 In concept AdaptableUnaryFunction change
32222 <blockquote><pre>typename X::result_type;
32223 typename X::argument_type;
32224 </pre></blockquote>
32228 <blockquote><pre>Returnable result_type = typename X::result_type;
32229 typename argument_type = typename X::argument_type;
32230 </pre></blockquote>
32232 [The replacement "Returnable result_type" instead of "typename
32233 result_type" is non-editorial, but maybe you prefer that as well]
32238 In concept AdaptableBinaryFunction change
32240 <blockquote><pre>typename X::result_type;
32241 typename X::first_argument_type;
32242 typename X::second_argument_type;
32243 </pre></blockquote>
32247 <blockquote><pre>Returnable result_type = typename X::result_type;
32248 typename first_argument_type = typename X::first_argument_type;
32249 typename second_argument_type = typename X::second_argument_type;
32250 </pre></blockquote>
32252 [The replacement "Returnable result_type" instead of "typename
32253 result_type" is non-editorial, but maybe you prefer that as well.]
32259 In class unary/binary_function
32263 I suggest to change "ReturnType" to "Returnable" in both cases.
32266 I think you want to replace the remaining occurrences of "Predicate" by "P"
32267 (in both classes in copy/move from a predicate)
32273 I think you need to change the proposed signatures of not1 and not2, because
32274 they would still remain unconstrained: To make them constrained at least a
32275 single requirement needs to be added to enable requirement implication. This
32276 could be done via a dummy ("requires True<true>") or just explicit as follows:
32280 <blockquote><pre>template <AdaptableUnaryFunction P>
32281 requires Predicate< P, P::argument_type>
32282 unary_negate<P> not1(const P&& pred);
32283 template <AdaptableUnaryFunction P>
32284 requires Predicate< P, P::argument_type >
32285 unary_negate<P> not1(P&& pred);
32288 -3- Returns: unary_negate<P>(pred).
32292 [Don't we want a move call for the second overload as in
32294 <blockquote><pre>unary_negate<P>(std::move(pred))
32295 </pre></blockquote>
32297 in the Returns clause ?]
32301 <pre>template <AdaptableBinaryFunction P>
32302 requires Predicate< P, P::first_argument_type, P::second_argument_type >
32303 binary_negate<P> not2(const P& pred);
32304 template <AdaptableBinaryFunction P>
32305 requires Predicate< P, P::first_argument_type, P::second_argument_type >
32306 binary_negate<P> not2(P&& pred);
32309 -5- Returns: binary_negate<P>(pred).
32312 [Don't we want a move call for the second overload as in
32314 <blockquote><pre>binary_negate<P>(std::move(pred))
32315 </pre></blockquote>
32317 in the Returns clause ?]
32331 There is concern that complicating the solution
32332 to preserve the ABI seems unnecessary,
32333 since we're not in general preserving the ABI.
32336 We would prefer a separate paper consolidating all Clause 20
32337 issues that are for the purpose of providing constrained versions
32338 of the existing facilities.
32346 <p><b>Proposed resolution:</b></p>
32348 Add new concepts where appropriate::
32351 <blockquote><pre>auto concept AdaptableUnaryFunction< typename X > {
32352 typename X::result_type;
32353 typename X::argument_type;
32356 auto concept AdaptableBinaryFunction< typename X > {
32357 typename X::result_type;
32358 typename X::first_argument_type;
32359 typename X::second_argument_type;
32361 </pre></blockquote>
32368 Base 20.7.3 [base] (Only change is constrained Result)
32373 -1- The following classes are provided to simplify the typedefs of the
32374 argument and result types:
32376 <pre>namespace std {
32377 template <class Arg, <del>class</del> <ins>ReturnType</ins> Result>
32378 struct unary_function {
32379 typedef Arg argument_type;
32380 typedef Result result_type;
32383 template <class Arg1, class Arg2, <del>class</del> <ins>ReturnType</ins> Result>
32384 struct binary_function {
32385 typedef Arg1 first_argument_type;
32386 typedef Arg2 second_argument_type;
32387 typedef Result result_type;
32390 </pre></blockquote>
32393 Negators 20.7.11 [negators]:
32398 -1- Negators <tt>not1</tt> and <tt>not2</tt> take a unary and a binary predicate,
32399 respectively, and return their complements (5.3.1).
32402 <pre>template <<del>class</del> <ins>AdaptableUnaryFunction</ins> P<del>redicate</del>>
32403 <ins>requires Predicate< P, P::argument_type ></ins>
32405 : public unary_function<<del>typename</del> P<del>redicate</del>::argument_type,bool> {
32407 <ins>unary_negate(const unary_negate & ) = default;</ins>
32408 <ins>unary_negate(unary_negate && );</ins>
32410 <ins>requires CopyConstructible< P ></ins>
32411 explicit unary_negate(const Predicate& pred);
32412 <ins>requires MoveConstructible< P >
32413 explicit unary_negate(Predicate && pred);</ins>
32415 bool operator()(const <del>typename</del> P<del>redicate</del>::argument_type& x) const;
32419 -2 <tt>operator()</tt> returns <tt>!pred(x)</tt>.
32422 <pre>template <class Predicate>
32423 unary_negate<Predicate> not1(const Predicate&amp; pred);
32424 <ins>template <class Predicate>
32425 unary_negate<Predicate> not1(Predicate&& pred);</ins>
32428 -3- <i>Returns:</i> <tt>unary_negate<Predicate>(pred)</tt>.
32431 <pre>template <<del>class</del> <ins>AdaptableBinaryFunction</ins> P<del>redicate</del> >
32432 <ins>requires Predicate< P, P::first_argument_type, P::second_argument_type ></ins>
32433 class binary_negate
32434 : public binary_function<<del>typename</del> P<del>redicate</del>::first_argument_type,
32435 <del>typename</del> P<del>redicate</del>::second_argument_type, bool> {
32437 <ins>biary_negate(const binary_negate & ) = default;</ins>
32438 <ins>binary_negate(binary_negate && );</ins>
32440 <ins>requires CopyConstructible< P ></ins>
32441 explicit binary_negate(const Predicate& pred);
32442 <ins>requires MoveConstructible< P >
32443 explicit binary_negate(const Predicate& pred);</ins>
32445 bool operator()(const <del>typename</del> P<del>redicate</del>::first_argument_type& x,
32446 const <del>typename</del> P<del>redicate</del>::second_argument_type& y) const;
32450 -4- <tt>operator()</tt> returns <tt>!pred(x,y)</tt>.
32453 <pre>template <class Predicate>
32454 binary_negate<Predicate> not2(const Predicate& pred);
32455 <ins>template <class Predicate>
32456 binary_negate<Predicate> not2(Predicate&& pred);</ins>
32460 -5- <i>Returns:</i> <tt>binary_negate<Predicate>(pred)</tt>.
32470 <h3><a name="1077"></a>1077. Nonesense <tt>tuple</tt> declarations</h3>
32471 <p><b>Section:</b> 20.5.2 [tuple.tuple] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Tentatively NAD Editorial</a>
32472 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-03-20 <b>Last modified:</b> 2009-05-23</p>
32473 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#tuple.tuple">active issues</a> in [tuple.tuple].</p>
32474 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple.tuple">issues</a> in [tuple.tuple].</p>
32475 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD%20Editorial">Tentatively NAD Editorial</a> status.</p>
32476 <p><b>Discussion:</b></p>
32478 Class template tuple 20.5.2 [tuple.tuple]:
32481 <blockquote><pre>template <class... UTypes>
32482 requires Constructible<Types, const UTypes&>...
32483 template <class... UTypes>
32484 requires Constructible<Types, RvalueOf<UTypes>::type>...
32485 </pre></blockquote>
32488 Somebody needs to look at this and say what it should be.
32492 2009-03-21 Daniel provided wording.
32501 The resolution looks correct; move to NAD Editorial.
32505 <p><b>Proposed resolution:</b></p>
32507 In 20.5.2 [tuple.tuple], class <tt>tuple</tt>, change as indicated:
32510 <blockquote><pre>template <class... UTypes>
32511 requires Constructible<Types, const UTypes&>...
32512 <ins>tuple(const pair<UTypes...>&);</ins>
32513 template <class... UTypes>
32514 requires Constructible<Types, RvalueOf<UTypes>::type>...
32515 <ins>tuple(pair<UTypes...>&&);</ins>
32516 </pre></blockquote>
32519 [NB.: The corresponding prototypes do already exist in 20.5.2.1 [tuple.cnstr]/7+8]
32527 <h3><a name="1078"></a>1078. DE-17: Remove class type_index</h3>
32528 <p><b>Section:</b> 18.7.2 [type.index] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
32529 <b>Submitter:</b> Doug Gregor <b>Opened:</b> 2009-03-20 <b>Last modified:</b> 2009-03-31</p>
32530 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
32531 <p><b>Discussion:</b></p>
32533 <p><b>Addresses DE 17</b></p>
32539 The class <tt>type_index</tt> should be removed; it provides no additional
32540 functionality beyond providing appropriate concept maps.
32544 2009-03-31 Peter adds:
32550 It is not true, in principle, that <tt>std::type_index</tt> provides no utility
32551 compared to bare <tt>std::type_info*</tt>.
32554 <tt>std::type_index</tt> can avoid the lifetime issues with <tt>type_info</tt> when the
32555 DLL that has produced the <tt>type_info</tt> object is unloaded. A raw
32556 <tt>type_info*</tt> does not, and cannot, provide any protection in this case.
32557 A <tt>type_index</tt> can (if the implementor so chooses) because it can wrap a
32558 smart (counted or even cloning) pointer to the <tt>type_info</tt> data that is
32559 needed for <tt>name()</tt> and <tt>before()</tt> to work.
32565 <p><b>Proposed resolution:</b></p>
32566 <p>Modify the header <typeinfo> synopsis in
32567 18.7 [support.rtti]p1 as follows:</p>
32569 <blockquote><pre>namespace std {
32571 <del>class type_index;</del>
32572 template <class T> struct hash;
32573 template<> struct hash<<del>type_index</del><ins>const type_info *</ins>> : public std::unary_function<<del>type_index</del><ins>const type_info *</ins>, size_t> {
32574 size_t operator()(<del>type_index</del><ins>const type_info *</ins> <del>index</del><ins>t</ins>) const;
32576 <ins>concept_map LessThanComparable<const type_info *> <i>see below</i></ins>
32580 </pre></blockquote>
32582 <p>Add the following new subsection</p>
32585 <ins>18.7.1.1 Template specialization <code>hash<const type_info *></code>
32586 [type.info.hash]</ins></p>
32588 <pre><ins>size_t operator()(const type_info *x) const;</ins>
32591 <li><ins><i>Returns</i>: <code>x->hash_code()</code></ins></li>
32595 <p>Add the following new subsection</p>
32597 <p><ins>18.7.1.2 <code>type_info</code> concept map [type.info.concepts]</ins></p>
32600 <pre><ins>concept_map LessThanComparable<const type_info *> {</ins>
32601 <ins>bool operator<(const type_info *x, const type_info *y) { return x->before(*y); }</ins>
32602 <ins>bool operator<=(const type_info *x, const type_info *y) { return !y->before(*x); }</ins>
32603 <ins>bool operator>(const type_info *x, const type_info *y) { return y->before(*x); }</ins>
32604 <ins>bool operator>=(const type_info *x, const type_info *y) { return !x->before(*y); }</ins>
32608 <li><ins><i>Note</i>: provides a well-defined ordering among
32609 <code>type_info const</code> pointers, which makes such pointers
32610 usable in associative containers (23.4).</ins></li>
32614 <p>Remove section 18.7.2 [type.index]</p>
32621 <h3><a name="1079"></a>1079. UK-265: <code>RandomAccessIterator</code>'s <code>operator-</code> has nonsensical effects clause</h3>
32622 <p><b>Section:</b> 24.2.6 [random.access.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
32623 <b>Submitter:</b> Doug Gregor <b>Opened:</b> 2009-03-20 <b>Last modified:</b> 2009-03-22</p>
32624 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#random.access.iterators">active issues</a> in [random.access.iterators].</p>
32625 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#random.access.iterators">issues</a> in [random.access.iterators].</p>
32626 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
32627 <p><b>Discussion:</b></p>
32628 <p><b>Addresses UK 265</b></p>
32632 This effects clause is nonesense. It looks more like an axiom stating
32633 equivalence, and certainly an effects clause cannot change the state of
32634 two arguments passed by const reference
32639 <p><b>Proposed resolution:</b></p>
32641 <p>Modify 24.2.6 [random.access.iterators]p7-9 as follows:</p>
32643 <blockquote><pre>difference_type operator-(const X& a, const X& b);
32646 <li><i>Precondition</i>: there exists a value <code>n</code> of
32647 <code>difference_type</code> such that <code>a == b + n</code>.</li>
32648 <li><del><i>Effects</i>: <code>b == a + (b - a)</code></del></li>
32649 <li><i>Returns</i>: <del><code>(a < b) ? distance(a,b) :
32650 -distance(b,a)</code></del><ins><code>n</code></ins></li>
32659 <h3><a name="1080"></a>1080. Concept ArithmeticLike should provide explicit boolean conversion</h3>
32660 <p><b>Section:</b> 20.2.13 [concept.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
32661 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-03-21 <b>Last modified:</b> 2009-05-23</p>
32662 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
32663 <p><b>Discussion:</b></p>
32665 Astonishingly, the current concept ArithmeticLike as specified in
32666 20.2.13 [concept.arithmetic] does not provide explicit conversion
32667 to <tt>bool</tt> although this is a common property of arithmetic types
32668 (4.12 [conv.bool]). Recent proposals that introduced such types
32669 (integers of arbitrary precision,
32670 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2143.pdf">n2143</a>,
32672 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2732.pdf">n2732</a>
32674 via conversion to <tt>long long</tt>) also took care of such a feature.
32677 Adding such an explicit conversion associated function would also
32678 partly solve a currently invalid effects clause in library, which bases
32679 on this property, 24.2.6 [random.access.iterators]/2:
32681 <blockquote><pre>{ difference_type m = n;
32682 if (m >= 0) while (m--) ++r;
32683 else while (m++) --r;
32685 </pre></blockquote>
32688 Both while-loops take advantage of a contextual conversion to <tt>bool</tt>
32689 (Another problem is that the >= comparison uses the no
32690 longer supported existing implicit conversion from <tt>int</tt> to <tt>IntegralLike</tt>).
32693 <b>Original proposed resolution:</b>
32697 In 20.2.13 [concept.arithmetic], add to the list of less refined
32698 concepts one further concept:
32701 <blockquote><pre>concept ArithmeticLike<typename T>
32702 : Regular<T>, LessThanComparable<T>, HasUnaryPlus<T>, HasNegate<T>,
32703 HasPlus<T, T>, HasMinus<T, T>, HasMultiply<T, T>, HasDivide<T, T>,
32704 HasPreincrement<T>, HasPostincrement<T>, HasPredecrement<T>,
32705 HasPostdecrement<T>,
32706 HasPlusAssign<T, const T&>, HasMinusAssign<T, const T&>,
32707 HasMultiplyAssign<T, const T&>,
32708 HasDivideAssign<T, const T&><ins>, ExplicitlyConvertible<T, bool></ins> {
32709 </pre></blockquote>
32713 In 24.2.6 [random.access.iterators]/2 change the current effects clause
32714 as indicated [The proposed insertion fixes the problem that the previous
32715 implicit construction from integrals has been changed to an explicit
32718 <blockquote><pre>{ difference_type m = n;
32719 if (m >= <ins>difference_type(</ins>0<ins>)</ins>) while (m--) ++r;
32720 else while (m++) --r;
32722 </pre></blockquote>
32732 We agree that arithmetic types ought be convertible to <tt>bool</tt>,
32733 and we therefore agree with the proposed resolution's paragraph 1.
32736 We do not agree that the cited effects clause is invalid,
32737 as it expresses intent rather than specific code.
32740 Move to Review, pending input from concepts experts.
32746 <p><b>Proposed resolution:</b></p>
32748 In 20.2.13 [concept.arithmetic], add to the list of less refined
32749 concepts one further concept:
32752 <blockquote><pre>concept ArithmeticLike<typename T>
32753 : Regular<T>, LessThanComparable<T>, HasUnaryPlus<T>, HasNegate<T>,
32754 HasPlus<T, T>, HasMinus<T, T>, HasMultiply<T, T>, HasDivide<T, T>,
32755 HasPreincrement<T>, HasPostincrement<T>, HasPredecrement<T>,
32756 HasPostdecrement<T>,
32757 HasPlusAssign<T, const T&>, HasMinusAssign<T, const T&>,
32758 HasMultiplyAssign<T, const T&>,
32759 HasDivideAssign<T, const T&><ins>, ExplicitlyConvertible<T, bool></ins> {
32760 </pre></blockquote>
32767 <h3><a name="1081"></a>1081. Response to UK 216</h3>
32768 <p><b>Section:</b> 21 [strings] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
32769 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-22 <b>Last modified:</b> 2009-03-22</p>
32770 <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>
32771 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
32772 <p><b>Discussion:</b></p>
32773 <p><b>Addresses UK 216, JP 46, JP 48</b></p>
32776 All the containers use concepts for their iterator usage, exect for
32777 <tt>basic_string</tt>. This needs fixing.
32781 Use concepts for iterator template parameters throughout the chapter.
32789 NB comments to be handled by Dave Abrahams and Howard Hinnant with
32790 advice from PJP: UK216 (which duplicates) JP46, JP48. JP46 supplies
32791 extensive proposed wording; start there.
32795 <p><b>Proposed resolution:</b></p>
32802 <h3><a name="1082"></a>1082. Response to JP 49</h3>
32803 <p><b>Section:</b> 22 [localization] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
32804 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-22 <b>Last modified:</b> 2009-03-22</p>
32805 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#localization">active issues</a> in [localization].</p>
32806 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#localization">issues</a> in [localization].</p>
32807 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
32808 <p><b>Discussion:</b></p>
32809 <p><b>Addresses JP 49</b></p>
32812 <tt>codecvt</tt> does not use concept. For example, create <tt>CodeConvert</tt>
32813 concept and change as follows.
32816 <blockquote><pre>template<CodeConvert Codecvt, class Elem = wchar_t>
32817 class wstring_convert {
32818 </pre></blockquote>
32825 To be handled by Howard Hinnant, Dave Abrahams, Martin Sebor, PJ Plauger.
32829 <p><b>Proposed resolution:</b></p>
32836 <h3><a name="1083"></a>1083. Response to JP 52, 53</h3>
32837 <p><b>Section:</b> 22 [localization] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
32838 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-22 <b>Last modified:</b> 2009-03-22</p>
32839 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#localization">active issues</a> in [localization].</p>
32840 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#localization">issues</a> in [localization].</p>
32841 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
32842 <p><b>Discussion:</b></p>
32843 <p><b>Addresses JP 52, JP 53</b></p>
32846 <tt>InputIterator</tt> does not use concept.
32850 <tt>OutputIterator</tt> does not use concept.
32854 Comments include proposed wording.
32862 To be handled by Howard Hinnant, Dave Abrahams, Martin Sebor, PJ Plauger.
32866 <p><b>Proposed resolution:</b></p>
32873 <h3><a name="1084"></a>1084. Response to UK 250</h3>
32874 <p><b>Section:</b> 24.2.4 [forward.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
32875 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-22 <b>Last modified:</b> 2009-06-09</p>
32876 <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>
32877 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
32878 <p><b>Discussion:</b></p>
32879 <p><b>Addresses UK 250</b></p>
32882 A default implementation should be supplied for the post-increment
32883 operator to simplify implementation of iterators by users.
32887 Copy the Effects clause into the concept description as the default
32888 implementation. Assumes a default value for postincrement_result
32896 Howard will open an issue.
32900 2009-06-07 Daniel adds:
32905 This issue cannot currently be resolved as suggested, because
32906 that would render auto-detection of the return type
32907 <tt>postincrement_result</tt> invalid, see 14.10.2.2 [concept.map.assoc]/4+5. The
32908 best fix would be to add a default type to that associated type, but
32909 unfortunately any default type will prevent auto-deduction of types of
32910 associated functions as quoted above. A corresponding core issue
32915 <p><b>Proposed resolution:</b></p>
32917 This wording assumes the acceptance of UK 251 / <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1009">1009</a>. Both
32918 wordings change the same paragraphs.
32923 Change 24.2.4 [forward.iterators]:
32927 <pre>concept ForwardIterator<typename X> : InputIterator<X>, Regular<X> {
32929 MoveConstructible postincrement_result;
32930 requires HasDereference<postincrement_result>
32931 && Convertible<HasDereference<postincrement_result>::result_type, const value_type&>;
32933 postincrement_result operator++(X& r, int)<del>;</del> <ins>{
32939 axiom MultiPass(X a, X b) {
32940 if (a == b) *a == *b;
32941 if (a == b) ++a == ++b;
32944 </pre></blockquote>
32952 <h3><a name="1085"></a>1085. Response to UK 258</h3>
32953 <p><b>Section:</b> 24.2.5 [bidirectional.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
32954 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-22 <b>Last modified:</b> 2009-06-09</p>
32955 <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>
32956 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
32957 <p><b>Discussion:</b></p>
32958 <p><b>Addresses UK 258</b></p>
32961 A default implementation should be supplied for the post-decrement
32962 operator to simplify implementation of iterators by users.
32966 Copy the Effects clause into the concept description as the default
32967 implementation. Assumes a default value for postincrement_result
32975 Howard will open an issue.
32979 2009-06-07 Daniel adds:
32984 This issue cannot currently be resolved as suggested, because
32985 that would render auto-detection of the return type
32986 <tt>postdecrement_result</tt> invalid, see <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1084">1084</a>.
32990 <p><b>Proposed resolution:</b></p>
32993 Change 24.2.5 [bidirectional.iterators]:
32997 <pre>concept BidirectionalIterator<typename X> : ForwardIterator<X> {
32998 MoveConstructible postdecrement_result;
32999 requires HasDereference<postdecrement_result>
33000 && Convertible<HasDereference<postdecrement_result>::result_type, const value_type&>
33001 && Convertible<postdecrement_result, const X&>;
33002 X& operator--(X&);
33003 postdecrement_result operator--(X& <ins>r</ins>, int)<del>;</del> <ins>{
33009 </pre></blockquote>
33017 <h3><a name="1086"></a>1086. Response to UK 284</h3>
33018 <p><b>Section:</b> 24.6 [stream.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
33019 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-22 <b>Last modified:</b> 2009-03-22</p>
33020 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
33021 <p><b>Discussion:</b></p>
33022 <p><b>Addresses UK 284</b></p>
33025 The stream iterators need constraining with concepts/requrires clauses.
33033 We agree. To be handled by Howard, Martin and PJ.
33037 <p><b>Proposed resolution:</b></p>
33044 <h3><a name="1087"></a>1087. Response to UK 301</h3>
33045 <p><b>Section:</b> 25.4.5 [alg.replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
33046 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-22 <b>Last modified:</b> 2009-06-11</p>
33047 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#alg.replace">active issues</a> in [alg.replace].</p>
33048 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.replace">issues</a> in [alg.replace].</p>
33049 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
33050 <p><b>Discussion:</b></p>
33051 <p><b>Addresses UK 301</b></p>
33054 <tt>replace</tt> and <tt>replace_if</tt> have the requirement: <tt>OutputIterator<Iter,
33055 Iter::reference></tt> Which implies they need to copy some values in the
33056 range the algorithm is iterating over. This is not however the case, the
33057 only thing that happens is <tt>const T&</tt>s might be copied over existing
33058 elements (hence the <tt>OutputIterator<Iter, const T&></tt>.
33062 Remove <tt>OutputIterator<Iter, Iter::reference></tt> from <tt>replace</tt>
33063 and <tt>replace_if</tt>.
33071 We agree. To be handled by Howard.
33075 <p><b>Proposed resolution:</b></p>
33077 Change in 25.2 [algorithms.syn] and 25.4.5 [alg.replace]:
33080 <blockquote><pre>template<ForwardIterator Iter, class T>
33081 requires <del>OutputIterator<Iter, Iter::reference>
33082 &&</del> OutputIterator<Iter, const T&>
33083 && HasEqualTo<Iter::value_type, T>
33084 void replace(Iter first, Iter last,
33085 const T& old_value, const T& new_value);
33087 template<ForwardIterator Iter, Predicate<auto, Iter::value_type> Pred, class T>
33088 requires <del>OutputIterator<Iter, Iter::reference>
33089 &&</del> OutputIterator<Iter, const T&>
33090 && CopyConstructible<Pred>
33091 void replace_if(Iter first, Iter last,
33092 Pred pred, const T& new_value);
33093 </pre></blockquote>
33100 <h3><a name="1088"></a>1088. Response to UK 342</h3>
33101 <p><b>Section:</b> 30.6.6 [futures.promise] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
33102 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-22 <b>Last modified:</b> 2009-03-22</p>
33103 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#futures.promise">active issues</a> in [futures.promise].</p>
33104 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#futures.promise">issues</a> in [futures.promise].</p>
33105 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
33106 <p><b>Discussion:</b></p>
33107 <p><b>Addresses UK 342</b></p>
33110 <tt>std::promise</tt> is missing a non-member overload of <tt>swap</tt>. This is
33111 inconsistent with other types that provide a <tt>swap</tt> member function.
33115 Add a non-member overload <tt>void swap(promise&& x,promise&& y){ x.swap(y); }</tt>
33123 Create an issue. Move to review, attention: Howard. Detlef will also
33128 Post Summit Daniel provided wording.
33133 <p><b>Proposed resolution:</b></p>
33137 In 30.6.6 [futures.promise], before p.1, immediately after class template
33140 <blockquote><pre><ins>
33141 template <class R>
33142 void swap(promise<R>& x, promise<R>& y);
33144 </pre></blockquote>
33148 Change 30.6.6 [futures.promise]/10 as indicated (to fix a circular definition):
33152 -10- <i>Effects:</i> <del>swap(*this, other)</del><ins>Swaps the associated state
33153 of <tt>*this</tt> and <tt>other</tt></ins>
33156 <ins><i>Throws:</i> Nothing.</ins>
33162 After the last paragraph in 30.6.6 [futures.promise] add the following
33163 prototype description:
33165 <blockquote><pre><ins>
33166 template <class R>
33167 void swap(promise<R>& x, promise<R>& y);
33171 <ins><i>Effects:</i> <tt>x.swap(y)</tt></ins>
33174 <ins><i>Throws:</i> Nothing.</ins>
33188 <h3><a name="1089"></a>1089. Response to JP 76</h3>
33189 <p><b>Section:</b> 30 [thread] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
33190 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-22 <b>Last modified:</b> 2009-03-22</p>
33191 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread">active issues</a> in [thread].</p>
33192 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread">issues</a> in [thread].</p>
33193 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
33194 <p><b>Discussion:</b></p>
33195 <p><b>Addresses JP 76</b></p>
33198 A description for "Throws: Nothing." are not unified.
33202 At the part without throw, "Throws: Nothing." should be described.
33206 Add "Throws: Nothing." to the following.
33211 30.3.1.6 [thread.thread.static] p1
33214 30.4.3.1 [thread.lock.guard] p4
33217 30.4.3.2.1 [thread.lock.unique.cons] p6
33220 30.5.1 [thread.condition.condvar] p7 and p8
33223 30.5.2 [thread.condition.condvarany] p6, p7, p19, p21 and p25
33236 Post Summit: Editor declares this non-editorial.
33241 <p><b>Proposed resolution:</b></p>
33248 <h3><a name="1090"></a>1090. Missing description of <tt>packaged_task</tt> member <tt>swap</tt>, missing non-member <tt>swap</tt></h3>
33249 <p><b>Section:</b> 30.6.8 [futures.task] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
33250 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-03-22 <b>Last modified:</b> 2009-05-24</p>
33251 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
33252 <p><b>Discussion:</b></p>
33254 Class template <tt>packaged_task</tt> in 30.6.8 [futures.task] shows a member <tt>swap</tt>
33255 declaration, but misses to
33256 document it's effects (No prototype provided). Further on this class
33257 misses to provide a non-member
33267 Alisdair notes that paragraph 2 of the proposed resolution has already been
33268 applied in the current Working Draft.
33271 We note a pending <tt>future</tt>-related paper by Detlef;
33272 we would like to wait for this paper before proceeding.
33280 2009-05-24 Daniel removed part 2 of the proposed resolution.
33285 <p><b>Proposed resolution:</b></p>
33289 In 30.6.8 [futures.task], immediately after the definition of class
33290 template packaged_task add:
33292 <blockquote><pre><ins>
33293 template<class R, class... Argtypes>
33294 void swap(packaged_task<R(ArgTypes...)>&, packaged_task<R(ArgTypes...)>&);
33296 </pre></blockquote>
33303 In 30.6.8 [futures.task], immediately after <tt>operator=</tt> prototype
33304 description (After p. 8) add:
33306 <blockquote><pre><ins>void swap(packaged_task& other);</ins>
33310 <i>Effects:</i> Swaps the associated state of <tt>*this</tt> and <tt>other</tt>.
33313 <i>Throws:</i> Nothing.
33320 At the end of 30.6.8 [futures.task] (after p. 20), add add the following
33321 prototype description:
33324 <blockquote><pre><ins>
33325 template<class R, class... Argtypes>
33326 void swap(packaged_task<R(ArgTypes...)>& x, packaged_task<R(ArgTypes...)>& y);
33330 <i>Effects:</i> <tt>x.swap(y)</tt>
33333 <i>Throws:</i> Nothing.
33345 <h3><a name="1091"></a>1091. Response to UK 246</h3>
33346 <p><b>Section:</b> 23.4.2.2 [multimap.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
33347 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2009-03-22 <b>Last modified:</b> 2009-05-23</p>
33348 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
33349 <p><b>Discussion:</b></p>
33351 <p><b>Addresses UK 246</b></p>
33353 The content of this sub-clause is purely trying to describe in words the
33354 effect of the requires clauses on these operations, now that we have
33355 Concepts. As such, the description is more confusing than the signature
33356 itself. The semantic for these functions is adequately covered in the
33357 requirements tables in 23.2.4 [associative.reqmts].
33366 Pete is clearly right that
33367 this one is technical rather than editorial.
33376 We agree with the proposed resolution.
33384 <p><b>Proposed resolution:</b></p>
33386 Strike 23.4.2.2 [multimap.modifiers] entirely
33387 (but do NOT strike these signatures from the class template definition!).
33395 <h3><a name="1092"></a>1092. Class template <tt>integral_constant</tt> should be a constrained template</h3>
33396 <p><b>Section:</b> 20.6.3 [meta.help] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
33397 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-03-22 <b>Last modified:</b> 2009-05-23</p>
33398 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta.help">active issues</a> in [meta.help].</p>
33399 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.help">issues</a> in [meta.help].</p>
33400 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
33401 <p><b>Discussion:</b></p>
33403 A first step to change the type traits predicates to constrained templates is to
33404 constrain their common base template <tt>integral_constant</tt>. This can be done,
33405 without enforcing depending classes to be constrained as well, but not
33407 without brute force <tt>late_check</tt> usages. The following proposed resolution depends
33408 on the resolution of LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1019">1019</a>.
33416 Move to Open, pending a paper that looks at constraints
33417 for the entirety of the type traits
33418 and their relationship to the foundation concepts.
33419 We recommend this be deferred
33420 until after the next Committee Draft is issued.
33424 <p><b>Proposed resolution:</b></p>
33428 In 20.6.2 [meta.type.synop], Header <tt><type_traits></tt>
33429 synopsis change as indicated:
33431 <blockquote><pre>namespace std {
33432 // 20.5.3, helper class:
33433 template <<del>class</del><ins>IntegralConstantExpressionType</ins> T, T v> struct integral_constant;
33434 </pre></blockquote>
33438 In 20.6.3 [meta.help] change as indicated:
33440 <blockquote><pre>template <<del>class</del><ins>IntegralConstantExpressionType</ins> T, T v>
33441 struct integral_constant {
33442 static constexpr T value = v;
33443 typedef T value_type;
33444 typedef integral_constant<T,v> type;
33445 constexpr operator value_type() { return value; }
33447 </pre></blockquote>
33456 <h3><a name="1093"></a>1093. Multiple definitions for random_shuffle algorithm</h3>
33457 <p><b>Section:</b> 25.4.12 [alg.random.shuffle] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
33458 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-22 <b>Last modified:</b> 2009-06-09</p>
33459 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.random.shuffle">issues</a> in [alg.random.shuffle].</p>
33460 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
33461 <p><b>Discussion:</b></p>
33464 There are a couple of issues with the declaration of the <tt>random_shuffle</tt>
33465 algorithm accepting a random number engine.
33470 The Iterators must be shuffle iterators, yet this requirement is missing.
33473 The <tt>RandomNumberEngine</tt> concept is now provided by the random number
33475 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2836.pdf">n2836</a>)
33476 and the placeholder should be removed.
33481 2009-05-02 Daniel adds:
33487 this issue completes adding necessary requirement to the
33488 third new <tt>random_shuffle</tt> overload. The current suggestion is:
33491 <blockquote><pre>template<RandomAccessIterator Iter, UniformRandomNumberGenerator Rand>
33492 requires ShuffleIterator<Iter>
33493 void random_shuffle(Iter first, Iter last, Rand&& g);
33494 </pre></blockquote>
33497 IMO this is still insufficient and I suggest to add the requirement
33499 <blockquote><pre>Convertible<Rand::result_type, Iter::difference_type>
33500 </pre></blockquote>
33502 to the list (as the two other overloads already have).
33511 Its true that this third overload is somewhat different from the remaining
33512 two. Nevertheless we know from <tt>UniformRandomNumberGenerator</tt>, that
33513 it's <tt>result_type</tt> is an integral type and that it satisfies
33514 <tt>UnsignedIntegralLike<result_type></tt>.
33517 To realize it's designated task, the algorithm has to invoke the
33518 <tt>Callable</tt> aspect of <tt>g</tt> and needs to perform some algebra involving
33519 it's <tt>min()/max()</tt> limits to compute another index value that
33520 at this point is converted into <tt>Iter::difference_type</tt>. This is so,
33521 because 24.2.6 [random.access.iterators] uses this type as argument
33522 of it's algebraic operators. Alternatively consider the equivalent
33523 iterator algorithms in 24.4 [iterator.operations] with the same result.
33526 This argument leads us to the conclusion that we also need
33527 <tt>Convertible<Rand::result_type, Iter::difference_type></tt> here.
33539 Alisdair notes that point (ii) has already been addressed.
33542 We agree with the proposed resolution to point (i)
33543 with Daniel's added requirement.
33551 2009-06-05 Daniel updated proposed wording as recommended in Batavia.
33556 <p><b>Proposed resolution:</b></p>
33558 Change in 25.2 [algorithms.syn] and 25.4.12 [alg.random.shuffle]:
33561 <blockquote><pre><del>concept UniformRandomNumberGenerator<typename Rand> { }</del>
33562 template<RandomAccessIterator Iter, UniformRandomNumberGenerator Rand>
33563 <ins>requires ShuffleIterator<Iter> &&
33564 Convertible<Rand::result_type, Iter::difference_type></ins>
33565 void random_shuffle(Iter first, Iter last, Rand&& g);
33566 </pre></blockquote>
33574 <h3><a name="1094"></a>1094. Response to JP 65 and JP 66</h3>
33575 <p><b>Section:</b> 27.5.4.3 [iostate.flags] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
33576 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2009-03-24 <b>Last modified:</b> 2009-05-23</p>
33577 <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>
33578 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
33579 <p><b>Discussion:</b></p>
33580 <p><b>Addresses JP 65 and JP 66</b></p>
33583 Switch from "unspecified-bool-type" to "explicit operator bool() const".
33587 Replace <tt>operator unspecified-bool-type() const;</tt>" with <tt>explicit operator bool() const;</tt>
33595 We agree with the proposed resolution.
33600 <p><b>Proposed resolution:</b></p>
33602 Change the synopis in 27.5.4 [ios]:
33605 <blockquote><pre><ins>explicit</ins> operator <del><i>unspecified-bool-type</i></del> <ins>bool</ins>() const;
33606 </pre></blockquote>
33609 Change 27.5.4.3 [iostate.flags]:
33612 <blockquote><pre><ins>explicit</ins> operator <del><i>unspecified-bool-type</i></del> <ins>bool</ins>() const;
33617 -1- <i>Returns:</i> <ins><tt>!fail()</tt></ins> <del>If <tt>fail()</tt> then a value that will evaluate
33618 false in a boolean context; otherwise a value that will evaluate true in
33619 a boolean context. The value type returned shall not be convertible to
33623 <del>[<i>Note:</i> This conversion can be used in contexts where a bool is expected
33624 (e.g., an <tt>if</tt> condition); however, implicit conversions (e.g.,
33625 to <tt>int</tt>) that can occur with <tt>bool</tt> are not allowed,
33626 eliminating some sources of user error. One possible implementation
33627 choice for this type is pointer-to-member. <i>-- end note</i>]</del>
33639 <h3><a name="1095"></a>1095. <i>Shared objects and the library</i> wording unclear</h3>
33640 <p><b>Section:</b> 17.6.3.10 [res.on.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
33641 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2009-03-27 <b>Last modified:</b> 2009-05-23</p>
33642 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
33643 <p><b>Discussion:</b></p>
33645 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2775.htm">N2775</a>,
33646 <i>Small library thread-safety revisions</i>, among other changes, removed a note from
33647 17.6.3.10 [res.on.objects] that read:
33651 [<i>Note:</i> This prohibition against concurrent non-const access means that
33652 modifying an object of a standard library type shared between threads
33653 without using a locking mechanism may result in a data race. <i>--end note</i>.]
33657 That resulted in wording which is technically correct but can only be
33658 understood by reading the lengthy and complex 17.6.4.7 [res.on.data.races]
33659 Data race avoidance. This has the effect of making
33660 17.6.3.10 [res.on.objects] unclear, and has already resulted in a query
33661 to the LWG reflector. See c++std-lib-23194.
33670 The proposed wording seems to need a bit of tweaking
33671 ("really bad idea" isn't quite up to standardese).
33672 We would like feedback
33673 as to whether the original Note's removal was intentional.
33676 Change the phrase "is a really bad idea"
33677 to "risks undefined behavior" and
33678 move to Review status.
33683 <p><b>Proposed resolution:</b></p>
33685 Change 17.6.3.10 [res.on.objects] as indicated:
33690 The behavior of a program is undefined if calls to standard library
33691 functions from different threads may introduce a data race. The
33692 conditions under which this may occur are specified in 17.6.4.7.
33695 [<i>Note:</i> Thus modifying an object of a standard library type shared between
33696 threads risks undefined behavior unless objects of the type are explicitly
33697 specified as being sharable without data races or the user supplies a
33698 locking mechanism. <i>--end note</i>]
33707 <h3><a name="1096"></a>1096. unconstrained rvalue ref parameters</h3>
33708 <p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
33709 <b>Submitter:</b> David Abrahams <b>Opened:</b> 2009-03-21 <b>Last modified:</b> 2009-05-23</p>
33710 <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>
33711 <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>
33712 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
33713 <p><b>Discussion:</b></p>
33715 TODO: Look at all cases of unconstrained rvalue ref parameters and check
33716 that concept req'ts work when <tt>T</tt> deduced as reference.
33720 We found some instances where that was not done correctly and we figure
33721 the possibility of deducing <tt>T</tt> to be an lvalue reference was probably
33722 overlooked elsewhere.
33730 Move to Open, pending proposed wording from Dave for further review.
33734 <p><b>Proposed resolution:</b></p>
33743 <h3><a name="1097"></a>1097. #define __STDCPP_THREADS</h3>
33744 <p><b>Section:</b> 18.2 [support.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
33745 <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2009-04-03 <b>Last modified:</b> 2009-05-23</p>
33746 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#support.types">issues</a> in [support.types].</p>
33747 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
33748 <p><b>Discussion:</b></p>
33749 <p><b>Addresses DE 18</b></p>
33752 Freestanding implementations do not (necessarily) have
33753 support for multiple threads (see 1.10 [intro.multithread]).
33754 Applications and libraries may want to optimize for the
33755 absence of threads. I therefore propose a preprocessor
33756 macro to indicate whether multiple threads can occur.
33760 There is ample prior implementation experience for this
33761 feature with various spellings of the macro name. For
33762 example, gcc implicitly defines <tt>_REENTRANT</tt>
33763 if multi-threading support is selected on the compiler
33768 While this is submitted as a library issue, it may be more
33769 appropriate to add the macro in 16.8 cpp.predefined in the
33775 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2693.html">N2693</a>.
33784 We agree with the issue, and believe it is properly a library issue.
33787 We prefer that the macro be conditionally defined
33788 as part of the <tt><thread></tt> header.
33796 <p><b>Proposed resolution:</b></p>
33798 Insert a new subsection before 18.2 [support.types], entitled
33799 "Feature Macros" (support.macros):
33803 The standard library defines the following macros; no explicit
33804 prior inclusion of any header file is necessary.
33808 <dt><tt>__STDCPP_THREADS</tt></dt>
33810 The macro <tt>__STDCPP_THREADS</tt> shall be defined if and only if a
33811 program can have more than one thread of execution (1.10 [intro.multithread]).
33812 If the macro is defined, it shall have the same
33813 value as the predefined macro <tt>__cplusplus</tt> (16.8 [cpp.predefined]).
33825 <h3><a name="1098"></a>1098. definition of get_pointer_safety()</h3>
33826 <p><b>Section:</b> 20.8.13.7 [util.dynamic.safety] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
33827 <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2009-04-03 <b>Last modified:</b> 2009-05-23</p>
33828 <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>
33829 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
33830 <p><b>Discussion:</b></p>
33831 <p><b>Addresses DE 18</b></p>
33834 In 20.8.13.7 [util.dynamic.safety], <tt>get_pointer_safety()</tt> purports
33835 to define behavior for
33836 non-safely derived pointers (3.7.4.3 [basic.stc.dynamic.safety]). However,
33837 the cited core-language section in paragraph 4 specifies undefined behavior
33838 for the use of such pointer values. This seems an unfortunate near-contradiction.
33839 I suggest to specify the term <i>relaxed pointer safety</i> in
33840 the core language section and refer to it from the library description.
33841 This issue deals with the library part, the corresponding core issue (c++std-core-13940)
33842 deals with the core modifications.
33847 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2693.html">N2693</a>.
33856 We recommend if this issue is to be moved,
33857 the issue be moved concurrently with the cited Core issue.
33860 We agree with the intent of the proposed resolution.
33861 We would like input from garbage collection specialists.
33870 <p><b>Proposed resolution:</b></p>
33872 In 20.8.13.7 [util.dynamic.safety] p16, replace the description of
33873 <tt>get_pointer_safety()</tt> with:
33878 <tt>pointer_safety get_pointer_safety();</tt>
33882 <del><i>Returns:</i> an enumeration value indicating the implementation's treatment
33883 of pointers that are not safely derived (3.7.4.3). Returns
33884 <tt>pointer_safety::relaxed</tt> if pointers that are not safely derived will be
33885 treated the same as pointers that are safely derived for the duration of
33886 the program. Returns <tt>pointer_safety::preferred</tt> if pointers that are not
33887 safely derived will be treated the same as pointers that are safely
33888 derived for the duration of the program but allows the implementation to
33889 hint that it could be desirable to avoid dereferencing pointers that are
33890 not safely derived as described. [<i>Example:</i> <tt>pointer_safety::preferred</tt>
33891 might be returned to detect if a leak detector is running to avoid
33892 spurious leak reports. -- <i>end note</i>] Returns <tt>pointer_safety::strict</tt> if
33893 pointers that are not safely derived might be treated differently than
33894 pointers that are safely derived.</del>
33897 <i>Returns:</i> Returns <tt>pointer_safety::strict</tt> if the implementation has
33898 strict pointer safety (3.7.4.3 [basic.stc.dynamic.safety]). It is
33899 implementation-defined whether <tt>get_pointer_safety</tt> returns
33900 <tt>pointer_safety::relaxed</tt> or <tt>pointer_safety::preferred</tt> if the
33901 implementation has relaxed pointer safety
33902 (3.7.4.3 [basic.stc.dynamic.safety]).<sup>Footnote</sup>
33906 <i>Throws:</i> nothing
33910 Footnote) <tt>pointer_safety::preferred</tt> might be returned to indicate to the
33911 program that a leak detector is running so that the program can avoid
33912 spurious leak reports.
33924 <h3><a name="1099"></a>1099. Various issues</h3>
33925 <p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
33926 <b>Submitter:</b> David Abrahams <b>Opened:</b> 2009-03-21 <b>Last modified:</b> 2009-05-23</p>
33927 <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>
33928 <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>
33929 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
33930 <p><b>Discussion:</b></p>
33936 [2009-03-21 Sat] p. 535 at the top we need MoveConstructible V1,
33937 MoveConstructible V2 (where V1,V2 are defined on 539). Also make_tuple
33941 [2009-03-21 Sat] p1183 thread ctor, and in general, we need a way to
33942 talk about "copiable from generalized rvalue ref argument" for cases
33943 where we're going to forward and copy.
33947 This issue may well be quite large. Language in para 4 about "if
33948 an lvalue" is wrong because types aren't expressions.
33951 p1199, call_once has all the same issues.
33955 [2009-03-21 Sat] p869 InputIterator pointer type should not be required
33956 to be convertible to const value_type*, rather it needs to have a
33957 operator-> of its own that can be used for the value type.
33960 [2009-03-21 Sat] p818 stack has the same problem with default ctor.
33963 [2009-03-21 Sat] p816 priority_queue has the same sorts of problems as queue, only more so
33965 <blockquote><pre> requires MoveConstructible<Cont>
33966 explicit priority_queue(const Compare& x = Compare(), Cont&& = Cont());
33969 Don't require MoveConstructible when default constructing Cont.
33970 Also missing semantics for move ctor.
33974 [2009-03-21 Sat] Why are Allocators required to be CopyConstructible as
33975 opposed to MoveConstructible?
33978 [2009-03-21 Sat] p813 queue needs a separate default ctor (Cont needn't
33979 be MoveConstructible). No documented semantics for move c'tor. Or
33980 *any* of its 7 ctors!
33983 [2009-03-21 Sat] std::array should have constructors for C++0x,
33984 consequently must consider move construction.
33988 2009-05-01 Daniel adds:
33993 This could be done as part of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1035">1035</a>, which already handles
33994 deviation of <tt>std::array</tt> from container tables.
33998 [2009-03-21 Sat] p622 all messed up.
34002 para 8 "implementation-defined" is the wrong term; should be "see
34003 below" or something.
34006 para 12 "will be selected" doesn't make any sense because we're not
34007 talking about actual arg types.
34010 paras 9-13 need to be totally rewritten for concepts.
34015 [2009-03-21 Sat] Null pointer comparisons (p587) have all become
34016 unconstrained. Need to fix that
34019 [2009-03-21 Sat] mem_fun_t etc. definition doesn't match declaration.
34020 We think CopyConstructible is the right reqt.
34023 make_pair needs Constructible<V1, T1&&> requirements!
34026 make_tuple needs something similar
34029 tuple bug in synopsis:
34031 <blockquote><pre> template <class... UTypes>
34032 requires Constructible<Types, const UTypes&>...
34033 template <class... UTypes>
34034 requires Constructible<Types, RvalueOf<UTypes>::type>...
34037 Note: removal of MoveConstructible requirements in std::function makes
34038 these routines unconstrained!
34043 2009-05-02 Daniel adds:
34048 This part of the issue is already covered by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1077">1077</a>.
34052 these unique_ptr constructors are broken [ I think this is covered in "p622 all messed up" ]
34054 <blockquote><pre> unique_ptr(pointer p, implementation-defined d);
34055 unique_ptr(pointer p, implementation-defined d);
34056 </pre></blockquote>
34058 multimap range constructor should not have MoveConstructible<value_type> requirement.
34061 same with insert(..., P&&); multiset has the same issue, as do
34062 unordered_multiset and unordered_multimap. Review these!
34072 Move to Open, pending proposed wording from Dave for further review.
34076 <p><b>Proposed resolution:</b></p>
34085 <h3><a name="1100"></a>1100. <tt>auto_ptr</tt> to <tt>unique_ptr</tt> conversion</h3>
34086 <p><b>Section:</b> D.9 [depr.auto.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
34087 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-04-25 <b>Last modified:</b> 2009-05-23</p>
34088 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
34089 <p><b>Discussion:</b></p>
34091 Message c++std-lib-23182 led to a discussion in which several people
34092 expressed interest in being able to convert an <tt>auto_ptr</tt> to a
34093 <tt>unique_ptr</tt> without the need to call <tt>release</tt>. Below is
34094 wording to accomplish this.
34103 Pete believes it not a good idea to separate parts of a class's definition.
34104 Therefore, if we do this,
34105 it should be part of <tt>unique-ptr</tt>'s specification.
34108 Alisdair believes the lvalue overload may be not necessary.
34111 Marc believes it is more than just sugar,
34112 as it does ease the transition to <tt>unique-ptr</tt>.
34115 We agree with the resolution as presented.
34116 Move to Tentatively Ready.
34121 <p><b>Proposed resolution:</b></p>
34123 Add to D.9 [depr.auto.ptr]:
34128 The following <tt>unique_ptr</tt> constructors are in addition to those specified
34129 in 20.8.12.2.1 [unique.ptr.single.ctor].
34131 <pre>template <class T, class D>
34135 template <class U>
34136 requires SameType<D, default_delete<T>>
34137 && Convertible<U*, T*>
34138 unique_ptr(auto_ptr<U>& u);
34139 template <class U>
34140 requires SameType<D, default_delete<T>>
34141 && Convertible<U*, T*>
34142 unique_ptr(auto_ptr<U>&& u);
34146 <i>Effects:</i> Constructs a <tt>unique_ptr</tt> with <tt>u.release()</tt>.
34150 <i>Postconditions:</i> <tt>get() == </tt> the value <tt>u.get()</tt> had before
34151 the construciton, modulo any required offset adjustments resulting from the cast from
34152 <tt>U*</tt> to <tt>T*</tt>. <tt>u.get() == nullptr</tt>.
34156 <i>Throws:</i> nothing.
34166 <h3><a name="1101"></a>1101. <tt>unique</tt> requirements</h3>
34167 <p><b>Section:</b> 25.4.9 [alg.unique] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Tentatively NAD Editorial</a>
34168 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-04-25 <b>Last modified:</b> 2009-05-23</p>
34169 <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>
34170 <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>
34171 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD%20Editorial">Tentatively NAD Editorial</a> status.</p>
34172 <p><b>Discussion:</b></p>
34174 From Message c++std-core-14160 Howard wrote:
34178 It was the intent of the rvalue reference proposal for unique to only require MoveAssignable:
34179 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1860.html#25.2.9%20-%20Unique">N1860</a>.
34187 That was overridden by the subsequent changes made for concepts in
34188 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2573.pdf">N2573</a>,
34189 which reimposed the C++03 requirements.
34193 My impression is that this overwrite was a simple (unintentional) mistake.
34194 Wording below to correct it.
34203 Howard notes this issue resolves a discrepancy between the synopsis
34204 and the description.
34207 Move to NAD Editorial.
34212 <p><b>Proposed resolution:</b></p>
34214 Change 25.4.9 [alg.unique]:
34217 <blockquote><pre>template<ForwardIterator Iter>
34218 requires OutputIterator<Iter, <ins>RvalueOf<</ins>Iter::reference<ins>>::type</ins>>
34219 && EqualityComparable<Iter::value_type>
34220 Iter unique(Iter first, Iter last);
34222 template<ForwardIterator Iter, EquivalenceRelation<auto, Iter::value_type> Pred>
34223 requires OutputIterator<Iter, RvalueOf<Iter::reference>::type>
34224 && CopyConstructible<Pred>
34225 Iter unique(Iter first, Iter last, Pred pred);
34226 </pre></blockquote>
34229 Note that the synopsis in 25.2 [algorithms.syn] is already correct.
34238 <h3><a name="1102"></a>1102. <tt>std::vector</tt>'s reallocation policy still unclear</h3>
34239 <p><b>Section:</b> 23.3.6.2 [vector.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
34240 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-04-20 <b>Last modified:</b> 2009-05-23</p>
34241 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector.capacity">issues</a> in [vector.capacity].</p>
34242 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
34243 <p><b>Discussion:</b></p>
34245 I have the impression that even the wording of current draft
34246 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2857.pdf">N2857</a>
34247 does insufficiently express the intent of <tt>vector</tt>'s
34248 reallocation strategy. This has produced not too old library
34249 implementations which release memory in the <tt>clear()</tt> function
34250 and even modern articles about C++ programming cultivate
34251 the belief that <tt>clear</tt> is allowed to do exactly this. A typical
34252 example is something like this:
34255 <blockquote><pre>const int buf_size = ...;
34256 std::vector<T> buf(buf_size);
34257 for (int i = 0; i < some_condition; ++i) {
34258 buf.resize(buf_size);
34259 write_or_read_data(buf.data());
34260 buf.clear(); // Ensure that the next round get's 'zeroed' elements
34262 </pre></blockquote>
34264 where still the myth is ubiquitous that <tt>buf</tt> might be
34265 allowed to reallocate it's memory *inside* the <tt>for</tt> loop.
34268 IMO the problem is due to the fact, that
34273 the actual memory-reallocation stability of <tt>std::vector</tt>
34274 is explained in 23.3.6.2 [vector.capacity]/3 and /6 which
34275 are describing just the effects of the <tt>reserve</tt>
34276 function, but in many examples (like above) there
34277 is no explicit call to <tt>reserve</tt> involved. Further-more
34278 23.3.6.2 [vector.capacity]/6 does only mention <em>insertions</em>
34279 and never mentions the consequences of erasing
34284 the effects clause of <tt>std::vector</tt>'s <tt>erase</tt> overloads in
34285 23.3.6.4 [vector.modifiers]/4 is silent about capacity changes. This
34286 easily causes a misunderstanding, because the counter
34287 parting insert functions described in 23.3.6.4 [vector.modifiers]/2
34288 explicitly say, that
34291 Causes reallocation if the new size is greater than the
34292 old capacity. If no reallocation happens, all the iterators
34293 and references before the insertion point remain valid.
34296 It requires a complex argumentation chain about four
34297 different places in the standard to provide the - possibly
34298 weak - proof that calling <tt>clear()</tt> also does <em>never</em> change
34299 the capacity of the <tt>std::vector</tt> container. Since <tt>std::vector</tt>
34300 is the de-facto replacement of C99's dynamic arrays this
34301 type is near to a built-in type and it's specification should
34302 be clear enough that usual programmers can trust their
34314 Bill believes paragraph 1 of the proposed resolution is unnecessary
34315 because it is already implied (even if tortuously) by the current wording.
34323 <p><b>Proposed resolution:</b></p>
34325 This is a minimum version. I also
34326 suggest that the wording explaining the allocation strategy
34327 of <tt>std::vector</tt> in 23.3.6.2 [vector.capacity]/3 and /6 is moved into
34328 a separate sub paragraph of 23.3.6.2 [vector.capacity] <em>before</em>
34329 any of the prototype's are discussed, but I cannot provide
34330 reasonable wording changes now
34337 Change 23.3.6.2 [vector.capacity]/6 as follows:
34340 It is guaranteed that no reallocation takes place during
34341 insertions <ins>or erasures</ins> that happen after a call
34342 to <tt>reserve()</tt> until the time when an insertion would make
34343 the size of the vector greater than the value of <tt>capacity()</tt>.
34348 Change 23.3.6.4 [vector.modifiers]/4 as follows:
34351 <i>Effects:</i> <ins>The capacity shall remain unchanged and no reallocation shall
34353 Invalidates iterators and references at or after the point
34364 <h3><a name="1103"></a>1103. <tt>system_error</tt> constructor postcondition overly strict</h3>
34365 <p><b>Section:</b> 19.5.5.2 [syserr.syserr.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
34366 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-04-25 <b>Last modified:</b> 2009-05-23</p>
34367 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
34368 <p><b>Discussion:</b></p>
34370 19.5.5.2 [syserr.syserr.members] says:
34373 <blockquote><pre>system_error(error_code ec, const string& what_arg);
34377 <i>Effects:</i> Constructs an object of class <tt>system_error</tt>.
34380 <i>Postconditions:</i> <tt>code() == ec</tt> and <tt>strcmp(runtime_error::what(), what_arg.c_str()) == 0</tt>.
34386 However the intent is for:
34389 <blockquote><pre>std::system_error se(std::errc::not_a_directory, "In FooBar");
34391 se.what(); <font color="#c80000">// returns something along the lines of:</font>
34392 <font color="#c80000">// "In FooBar: Not a directory"</font>
34393 </pre></blockquote>
34396 The way the constructor postconditions are set up now, to achieve both
34397 conformance, and the desired intent in the <tt>what()</tt> string, the
34398 <tt>system_error</tt> constructor must store "In FooBar" in the base class,
34399 and then form the desired output each time <tt>what()</tt> is called. Or
34400 alternatively, store "In FooBar" in the base class, and store the desired
34401 <tt>what()</tt> string in the derived <tt>system_error</tt>, and override
34402 <tt>what()</tt> to return the string in the derived part.
34406 Both of the above implementations seem suboptimal to me. In one I'm computing
34407 a new string every time <tt>what()</tt> is called. And since <tt>what()</tt>
34408 can't propagate exceptions, the client may get a different string on different
34413 The second solution requires storing two strings instead of one.
34417 What I would like to be able to do is form the desired <tt>what()</tt> string
34418 once in the <tt>system_error</tt> constructor, and store <em>that</em> in the
34419 base class. Now I'm:
34423 <li>Computing the desired <tt>what()</tt> only once.</li>
34424 <li>The base class <tt>what()</tt> definition is sufficient and nothrow.</li>
34425 <li>I'm not storing multiple strings.</li>
34429 This is smaller code, smaller data, and faster.
34433 <tt>ios_base::failure</tt> has the same issue.
34437 Comments about this change received favorable comments from the <tt>system_error</tt>
34449 We agree with the proposed resolution.
34452 Move to Tentatively Ready.
34457 <p><b>Proposed resolution:</b></p>
34459 In 19.5.5.2 [syserr.syserr.members], change the following constructor postconditions:
34463 <pre>system_error(error_code ec, const string& what_arg);
34466 -2- <i>Postconditions:</i> <tt>code() == ec</tt>
34467 and <tt><del>strcmp(runtime_error::what(), what_arg.c_str()) == 0</del>
34468 <ins>string(what()).find(what_arg) != string::npos</ins></tt>.
34471 <pre>system_error(error_code ec, const char* what_arg);
34474 -4- <i>Postconditions:</i> <tt>code() == ec</tt>
34475 and <tt><del>strcmp(runtime_error::what(), what_arg) == 0</del>
34476 <ins>string(what()).find(what_arg) != string::npos</ins></tt>.
34479 <pre>system_error(error_code ec);
34482 -6- <i>Postconditions:</i> <tt>code() == ec</tt>
34483 <del>and <tt>strcmp(runtime_error::what(), ""</tt></del>.
34486 <pre>system_error(int ev, const error_category& ecat, const string& what_arg);
34489 -8- <i>Postconditions:</i> <tt>code() == error_code(ev, ecat)</tt>
34490 and <tt><del>strcmp(runtime_error::what(), what_arg.c_str()) == 0</del>
34491 <ins>string(what()).find(what_arg) != string::npos</ins></tt>.
34494 <pre>system_error(int ev, const error_category& ecat, const char* what_arg);
34497 -10- <i>Postconditions:</i> <tt>code() == error_code(ev, ecat)</tt>
34498 and <tt><del>strcmp(runtime_error::what(), what_arg) == 0</del>
34499 <ins>string(what()).find(what_arg) != string::npos</ins></tt>.
34502 <pre>system_error(int ev, const error_category& ecat);
34505 -12- <i>Postconditions:</i> <tt>code() == error_code(ev, ecat)</tt>
34506 <del>and <tt>strcmp(runtime_error::what(), "") == 0</tt></del>.
34512 In 19.5.5.2 [syserr.syserr.members], change the description of <tt>what()</tt>:
34516 <pre>const char *what() const throw();
34520 -14- <i>Returns:</i> An NTBS incorporating <del><tt>runtime_error::what()</tt> and
34521 <tt>code().message()</tt></del> <ins>the arguments supplied in the constructor</ins>.
34524 [<i>Note:</i> <del>One possible implementation would be:</del>
34525 <ins>The return NTBS might take the form: <tt>what_arg + ": " + code().message()</tt></ins>
34527 <blockquote><pre><del>
34530 string tmp = runtime_error::what();
34534 tmp += code().message();
34538 return runtime_error::what();
34540 return msg.c_str();
34541 </del></pre></blockquote>
34543 — <i>end note</i>]
34549 In 27.5.2.1.1 [ios::failure], change the synopsis:
34552 <blockquote><pre>namespace std {
34553 class ios_base::failure : public system_error {
34555 explicit failure(const string& msg, const error_code& ec = io_errc::stream);
34556 explicit failure(const char* msg, const error_code& ec = io_errc::stream);
34557 <del>virtual const char* what() const throw();</del>
34560 </pre></blockquote>
34563 In 27.5.2.1.1 [ios::failure], change the description of the constructors:
34568 <pre>explicit failure(const string& msg, , const error_code& ec = io_errc::stream);
34572 -3- <i>Effects:</i> Constructs an object of class <tt>failure</tt>
34573 <ins>by constructing the base class with <tt>msg</tt> and <tt>ec</tt></ins>.
34576 <del>-4- <i>Postcondition:</i> <tt>code() == ec</tt> and <tt>strcmp(what(), msg.c_str()) == 0</tt></del>
34580 <pre>explicit failure(const char* msg, const error_code& ec = io_errc::stream);
34584 -5- <i>Effects:</i> Constructs an object of class <tt>failure</tt>
34585 <ins>by constructing the base class with <tt>msg</tt> and <tt>ec</tt></ins>.
34588 <del>-6- <i>Postcondition:</i> <tt>code() == ec and strcmp(what(), msg) == 0</tt></del>
34595 In 27.5.2.1.1 [ios::failure], remove <tt>what</tt> (the base class definition
34596 need not be repeated here).
34600 <pre><del>const char* what() const;</del>
34603 <del>-7- <i>Returns:</i> The message <tt>msg</tt> with which the exception was created.</del>
34614 <h3><a name="1104"></a>1104. <tt>basic_ios::move</tt> should accept lvalues</h3>
34615 <p><b>Section:</b> 27.5.4.2 [basic.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
34616 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-04-25 <b>Last modified:</b> 2009-05-23</p>
34617 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.ios.members">active issues</a> in [basic.ios.members].</p>
34618 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.ios.members">issues</a> in [basic.ios.members].</p>
34619 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
34620 <p><b>Discussion:</b></p>
34622 With the rvalue reference changes in
34623 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2844.html">N2844</a>
34624 <tt>basic_ios::move</tt> no longer has the most convenient signature:
34627 <blockquote><pre>void move(basic_ios&& rhs);
34628 </pre></blockquote>
34631 This signature should be changed to accept lvalues. It does not need to be
34632 overloaded to accept rvalues. This is a special case that only derived clients
34633 will see. The generic <tt>move</tt> still needs to accept rvalues.
34642 Tom prefers, on general principles, to provide both overloads.
34646 Howard points out that there is no backward compatibility issue
34647 as this is new to C++0X.
34650 We agree that both overloads should be provided,
34651 and Howard will provide the additional wording.
34657 2009-05-23 Howard adds:
34662 Added overload, moved to Review.
34667 <p><b>Proposed resolution:</b></p>
34669 Add a signature to the existing prototype in the synopsis of 27.5.4 [ios]
34670 and in 27.5.4.2 [basic.ios.members]:
34673 <blockquote><pre><ins>void move(basic_ios& rhs);</ins>
34674 void move(basic_ios&& rhs);
34675 </pre></blockquote>
34682 <h3><a name="1105"></a>1105. Shouldn't <tt>Range</tt> be an <tt>auto concept</tt></h3>
34683 <p><b>Section:</b> 24.2.8 [iterator.concepts.range] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
34684 <b>Submitter:</b> David Abrahams <b>Opened:</b> 2009-04-23 <b>Last modified:</b> 2009-05-23</p>
34685 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
34686 <p><b>Discussion:</b></p>
34689 2009-04-26 Herb adds:
34695 Here's a common example: We have many ISV customers who have built lots of
34696 in-house STL-like containers. Imagine that, for the past ten years, the user
34697 has been happily using his <tt>XYZCorpContainer<T></tt> that has <tt>begin()</tt> and <tt>end()</tt>
34698 and an iterator typedef, and indeed satisfies nearly all of <tt>Container</tt>,
34699 though maybe not quite all just like <tt>valarray</tt>. The user upgrades to a
34700 range-enabled version of a library, and now <tt>lib_algo( xyz.begin(), xyz.end());</tt>
34701 no longer works -- compiler error.
34704 Even though <tt>XYZCorpContainer</tt> matches the pre-conceptized version of the
34705 algorithm, and has been working for years, it appears the user has to write
34708 <blockquote><pre>template<class T> concept_map Range<XYZCorpContainer<T>> {};
34710 template<class T> concept_map Range<const XYZCorpContainer<T>> {};
34711 </pre></blockquote>
34716 But he may actually have to write this as we do for initializer list:
34718 <blockquote><pre>template<class T>
34719 concept_map Range<XYZCorpContainer<T>> {
34720 typedef T* iterator;
34721 iterator begin(XYZCorpContainer<T> c) { return c.begin(); }
34722 iterator end(XYZCorpContainer<T> c) { return c.end(); }
34725 template<class T>
34726 concept_map Range<const XYZCorpContainer<T>> {
34727 typedef T* iterator;
34728 iterator begin(XYZCorpContainer<T> c) { return c.begin(); }
34729 iterator end(XYZCorpContainer<T> c) { return c.end(); }
34731 </pre></blockquote>
34736 2009-04-28 Alisdair adds:
34742 I recommend NAD, although remain concerned about header organisation.
34745 A user container will satisfy the <tt>MemberContainer</tt> concept, which IS auto.
34746 There is a concept_map for all <tt>MemberContainers</tt> to <tt>Container</tt>, and then a
34747 further concept_map for all <tt>Container</tt> to <tt>Range</tt>, so the stated problem is not
34748 actually true. User defined containers will automatically match the <tt>Range</tt>
34749 concept without explicitly declaring a concept_map.
34752 The problem is that they should now provide an additional two headers,
34753 <tt><iterator_concepts></tt> and <tt><container_concepts></tt>.
34754 The only difference from
34755 making <tt>Range</tt> an auto concept would be this reduces to a single header,
34756 <tt><iterator_concepts></tt>.
34759 I am strongly in favour of any resolution that tackles the issue of
34760 explicitly requiring concept headers to make these concept maps available.
34770 We observe there is a recent paper by Bjarne that overlaps this issue.
34773 Alisdair continues to recommend NAD.
34776 Move to Open, and recommend the issue be deferred until after the next
34777 Committee Draft is issued.
34782 <p><b>Proposed resolution:</b></p>
34789 <h3><a name="1106"></a>1106. Multiple exceptions from connected <tt>shared_future::get()</tt>?</h3>
34790 <p><b>Section:</b> 30.6.5 [future.shared_future] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
34791 <b>Submitter:</b> Thomas J. Gritzan <b>Opened:</b> 2009-04-03 <b>Last modified:</b> 2009-05-23</p>
34792 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#future.shared_future">active issues</a> in [future.shared_future].</p>
34793 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#future.shared_future">issues</a> in [future.shared_future].</p>
34794 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
34795 <p><b>Discussion:</b></p>
34797 It is not clear, if multiple threads are waiting in a
34798 <tt>shared_future::get()</tt> call, if each will rethrow the stored exception.
34804 <i>Throws:</i> the stored exception, if an exception was stored and not
34808 The "not retrieved before" suggests that only one exception is thrown,
34809 but one exception for each call to <tt>get()</tt> is needed, and multiple calls
34810 to <tt>get()</tt> even on the same <tt>shared_future</tt> object seem to be allowed.
34813 I suggest removing "and not retrieved before" from the Throws paragraph.
34814 I recommend adding a note that explains that multiple calls on <tt>get()</tt> are
34815 allowed, and each call would result in an exception if an exception was
34825 We note there is a pending paper by Detlef
34826 on such <tt>future</tt>-related issues;
34827 we would like to wait for his paper before proceeding.
34830 Alisdair suggests we may want language to clarify that this
34831 <tt>get()</tt> function can be called from several threads
34832 with no need for explicit locking.
34840 <p><b>Proposed resolution:</b></p>
34842 Change 30.6.5 [future.shared_future]:
34845 <blockquote><pre>const R& shared_future::get() const;
34846 R& shared_future<R&>::get() const;
34847 void shared_future<void>::get() const;
34852 -9- <i>Throws:</i> the stored exception, if an exception was stored<del> and not retrieved before</del>.
34854 [<i>Note:</i> Multiple calls on <tt>get()</tt> are
34855 allowed, and each call would result in an exception if an exception was
34856 stored. — <i>end note</i>]
34868 <h3><a name="1107"></a>1107. constructor <tt>shared_future(unique_future)</tt> by value?</h3>
34869 <p><b>Section:</b> 30.6.5 [future.shared_future] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
34870 <b>Submitter:</b> Thomas J. Gritzan <b>Opened:</b> 2009-04-03 <b>Last modified:</b> 2009-05-23</p>
34871 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#future.shared_future">active issues</a> in [future.shared_future].</p>
34872 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#future.shared_future">issues</a> in [future.shared_future].</p>
34873 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
34874 <p><b>Discussion:</b></p>
34876 In the <tt>shared_future</tt> class definition in 30.6.5 [future.shared_future]
34877 the move constructor
34878 that constructs a <tt>shared_future</tt> from an <tt>unique_future</tt> receives the
34879 parameter by value. In paragraph 3, the same constructor receives it as
34884 I think that is a mistake and the constructor should take a r-value
34888 <blockquote><pre>shared_future(unique_future<R>&& rhs);
34889 </pre></blockquote>
34897 We agree with the proposed resolution.
34900 Move to Tentatively Ready.
34905 <p><b>Proposed resolution:</b></p>
34907 Change the synopsis in 30.6.5 [future.shared_future]:
34910 <blockquote><pre>shared_future(unique_future<R><ins>&&</ins> rhs);
34911 </pre></blockquote>
34914 Change the definition of the constructor in 30.6.5 [future.shared_future]:
34917 <blockquote><pre>shared_future(<del>const</del> unique_future<R><ins>&&</ins> rhs);
34918 </pre></blockquote>
34926 <h3><a name="1108"></a>1108. thread.req.exception overly constrains implementations</h3>
34927 <p><b>Section:</b> 30.2.2 [thread.req.exception] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
34928 <b>Submitter:</b> Christopher Kohlhoff <b>Opened:</b> 2009-04-25 <b>Last modified:</b> 2009-05-23</p>
34929 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
34930 <p><b>Discussion:</b></p>
34932 The current formulation of 30.2.2 [thread.req.exception]/2 reads:
34935 The error_category of the <tt>error_code</tt> reported by such an
34936 exception's <tt>code()</tt> member function is as specified in the error
34940 This constraint on the code's associated <tt>error_categor</tt> means an
34941 implementation must perform a mapping from the system-generated
34942 error to a <tt>generic_category()</tt> error code. The problems with this
34948 The mapping is always performed, even if the resultant value is
34953 The original error produced by the operating system is lost.
34958 The latter was one of Peter Dimov's main objections (in a private
34959 email discussion) to the original <tt>error_code</tt>-only design, and led to
34960 the creation of <tt>error_condition</tt> in the first place. Specifically,
34961 <tt>error_code</tt> and <tt>error_condition</tt> are intended to perform the following
34966 <tt>error_code</tt> holds the original error produced by the operating
34970 <tt>error_condition</tt> and the generic category provide a set of well
34971 known error constants that error codes may be tested against.
34975 Any mapping determining correspondence of the returned error code to
34976 the conditions listed in the error condition clause falls under the
34977 "latitude" granted to implementors in 19.5.1.5 [syserr.errcat.objects].
34978 (Although obviously their latitude is restricted a little by the
34979 need to match the right error condition when returning an error code
34980 from a library function.)
34983 It is important that this <tt>error_code/error_condition</tt> usage is done
34984 correctly for the thread library since it is likely to set the
34985 pattern for future TR libraries that interact with the operating
34994 Move to Open, and recommend the issue be deferred until after the next
34995 Committee Draft is issued.
34999 <p><b>Proposed resolution:</b></p>
35001 Change 30.2.2 [thread.req.exception]/2:
35006 -2- <del>The <tt>error_category</tt> (19.5.1.1) of the <tt>error_code</tt> reported by
35007 such an exception's <tt>code()</tt> member function
35008 is as specified in the error condition Clause.</del>
35010 The <tt>error_code</tt> reported by such an exception's <tt>code()</tt> member
35011 function shall compare equal to one of the conditions specified in
35012 the function's error condition Clause. [<i>Example:</i> When the thread
35016 <blockquote><pre><ins>
35017 ec.category() == implementation-defined // probably system_category
35018 ec == errc::resource_unavailable_try_again // holds true
35019 </ins></pre></blockquote>
35022 — <i>end example</i>]
35033 <h3><a name="1109"></a>1109. <tt>std::includes</tt> should require <tt>CopyConstructible</tt> predicate</h3>
35034 <p><b>Section:</b> 25.5.5.1 [includes] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Tentatively NAD Editorial</a>
35035 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-04-28 <b>Last modified:</b> 2009-05-23</p>
35036 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#includes">active issues</a> in [includes].</p>
35037 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#includes">issues</a> in [includes].</p>
35038 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD%20Editorial">Tentatively NAD Editorial</a> status.</p>
35039 <p><b>Discussion:</b></p>
35041 All the set operation algorithms require a <tt>CopyConstructible</tt> predicate, with
35042 the exception of <tt>std::includes</tt>. This looks like a typo as much as anything,
35043 given the general library requirement that predicates are copy
35044 constructible, and wording style of other set-like operations.
35052 We agree with the proposed resolution.
35053 Move to NAD Editorial.
35057 <p><b>Proposed resolution:</b></p>
35059 Change 25.2 [algorithms.syn] and 25.5.5.1 [includes]:
35062 <blockquote><pre>template<InputIterator Iter1, InputIterator Iter2,
35063 <del>typename</del> <ins>CopyConstructible</ins> Compare>
35064 requires Predicate<Compare, Iter1::value_type, Iter2::value_type>
35065 && Predicate<Compare, Iter2::value_type, Iter1::value_type>
35066 bool includes(Iter1 first1, Iter1 last1,
35067 Iter2 first2, Iter2 last2,
35069 </pre></blockquote>
35076 <h3><a name="1110"></a>1110. Is <tt>for_each</tt> overconstrained?</h3>
35077 <p><b>Section:</b> 25.3.4 [alg.foreach] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
35078 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-04-29 <b>Last modified:</b> 2009-05-23</p>
35079 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#alg.foreach">active issues</a> in [alg.foreach].</p>
35080 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.foreach">issues</a> in [alg.foreach].</p>
35081 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
35082 <p><b>Discussion:</b></p>
35084 Quoting working paper for reference (25.3.4 [alg.foreach]):
35088 <pre>template<InputIterator Iter, Callable<auto, Iter::reference> Function>
35089 requires CopyConstructible<Function>
35090 Function for_each(Iter first, Iter last, Function f);
35094 1 Effects: Applies f to the result of dereferencing every iterator in the
35095 range [first,last), starting from first and proceeding to last - 1.
35101 3 Complexity: Applies f exactly last - first times.
35107 P2 implies the passed object <tt>f</tt> should be invoked at each stage, rather than
35108 some copy of <tt>f</tt>. This is important if the return value is to usefully
35109 accumulate changes. So the requirements are an object of type <tt>Function</tt> can
35110 be passed-by-value, invoked multiple times, and then return by value. In
35111 this case, <tt>MoveConstructible</tt> is sufficient. This would open support for
35112 move-only functors, which might become important in concurrent code as you
35113 can assume there are no other references (copies) of a move-only type and so
35114 freely use them concurrently without additional locks.
35118 See further discussion starting with c++std-lib-23686.
35128 Pete suggests we may want to look at this in a broader context
35129 involving other algorithms.
35130 We should also consider the implications of parallelism.
35133 Move to Open, and recommend the issue be deferred until after the next
35134 Committee Draft is issued.
35139 <p><b>Proposed resolution:</b></p>
35141 Change 25.2 [algorithms.syn] and 25.3.4 [alg.foreach]:
35144 <blockquote><pre>template<InputIterator Iter, Callable<auto, Iter::reference> Function>
35145 requires <del>CopyConstructible</del> <ins>MoveConstructible</ins><Function>
35146 Function for_each(Iter first, Iter last, Function f);
35147 </pre></blockquote>
35154 <h3><a name="1111"></a>1111. associative containers underconstrained</h3>
35155 <p><b>Section:</b> 23.4 [associative] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
35156 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-04-29 <b>Last modified:</b> 2009-05-23</p>
35157 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative">active issues</a> in [associative].</p>
35158 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative">issues</a> in [associative].</p>
35159 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
35160 <p><b>Discussion:</b></p>
35162 According to table 87 (n2857) the expression <tt>X::key_equal</tt> for an unordered
35163 container shall return a value of type <tt>Pred</tt>, where <tt>Pred</tt> is an equivalence
35168 However, all 4 containers constrain <tt>Pred</tt> to be merely a <tt>Predicate</tt>,
35169 and not <tt>EquivalenceRelation</tt>.
35178 We agree with the proposed resolution.
35186 <p><b>Proposed resolution:</b></p>
35188 For ordered containers, replace
35190 <blockquote><pre>Predicate<auto, Key, Key> Compare = less<Key>
35191 </pre></blockquote>
35195 <blockquote><pre>StrictWeakOrder<auto, Key, Key> Compare = less<Key>
35196 </pre></blockquote>
35199 For unordered containers, replace
35201 <blockquote><pre>Predicate<auto, Key, Key> Compare = less<Key>
35202 </pre></blockquote>
35206 <blockquote><pre>EquivalenceRelation<auto, Key, Key> Compare = less<Key>
35207 </pre></blockquote>
35209 As in the following declarations:
35214 Associative containers 23.4 [associative]
35217 1 Headers <map> and <set>:
35220 Header <map> synopsis
35222 <blockquote><pre> namespace std {
35223 template <ValueType Key, ValueType T,
35224 <del>Predicate</del><ins>StrictWeakOrder</ins><auto, Key<del>, Key</del>> Compare = less<Key>,
35225 Allocator Alloc = allocator<pair&lt;<b>const Key, T> > >
35226 requires NothrowDestructible<Key> && NothrowDestructible<T>
35227 && CopyConstructible<Compare>
35228 && AllocatableElement<Alloc, Compare, const Compare&>
35229 && AllocatableElement<Alloc, Compare, Compare&&>
35234 template <ValueType Key, ValueType T,
35235 <del>Predicate</del><ins>StrictWeakOrder</ins><auto, Key<del>, Key</del>> Compare = less<Key>,
35236 Allocator Alloc = allocator<pair&lt;<b>const Key, T> > >
35237 requires NothrowDestructible<Key> && NothrowDestructible<T>
35238 && CopyConstructible<Compare>
35239 && AllocatableElement<Alloc, Compare, const Compare&>
35240 && AllocatableElement<Alloc, Compare, Compare&&>
35246 </pre></blockquote>
35249 Header <set> synopsis
35251 <blockquote><pre> namespace std {
35252 template <ValueType Key, <del>Predicate</del><ins>StrictWeakOrder</ins><auto, Key<del>, Key</del>> Compare = less<Key>,
35253 Allocator Alloc = allocator<Key> >
35254 requires NothrowDestructible<Key> && CopyConstructible<Compare>
35255 && AllocatableElement<Alloc, Compare, const Compare&>
35256 && AllocatableElement<Alloc, Compare, Compare&&>
35261 template <ValueType Key, <del>Predicate</del><ins>StrictWeakOrder</ins><auto, Key<del>, Key</del>> Compare = less<Key>,
35262 Allocator Alloc = allocator<Key> >
35263 requires NothrowDestructible<Key> && CopyConstructible<Compare>
35264 && AllocatableElement<Alloc, Compare, const Compare&>
35265 && AllocatableElement<Alloc, Compare, Compare&&>
35271 </pre></blockquote>
35274 23.4.1p2 Class template map [map]
35276 <blockquote><pre> namespace std {
35277 template <ValueType Key, ValueType T,
35278 <del>Predicate</del><ins>StrictWeakOrder</ins><auto, Key<del>, Key</del>> Compare = less<Key>,
35279 Allocator Alloc = allocator<pair&lt;<b>const Key, T> > >
35280 requires NothrowDestructible<Key> && NothrowDestructible<T>
35281 && CopyConstructible<Compare>
35282 && AllocatableElement<Alloc, Compare, const Compare&>
35283 && AllocatableElement<Alloc, Compare, Compare&&>
35288 </pre></blockquote>
35292 23.4.2p2 Class template multimap [multimap]
35294 <blockquote><pre> namespace std {
35295 template <ValueType Key, ValueType T,
35296 <del>Predicate</del><ins>StrictWeakOrder</ins><auto, Key<del>, Key</del>> Compare = less<Key>,
35297 Allocator Alloc = allocator<pair&lt;<b>const Key, T> > >
35298 requires NothrowDestructible<Key> && NothrowDestructible<T>
35299 && CopyConstructible<Compare>
35300 && AllocatableElement<Alloc, Compare, const Compare&>
35301 && AllocatableElement<Alloc, Compare, Compare&&>
35306 </pre></blockquote>
35310 23.4.3p2 Class template set [set]
35312 <blockquote><pre> namespace std {
35313 template <ValueType Key, <del>Predicate</del><ins>StrictWeakOrder</ins><auto, Key<del>, Key</del>> Compare = less<Key>,
35314 Allocator Alloc = allocator<Key> >
35315 requires NothrowDestructible<Key> && CopyConstructible<Compare>
35316 && AllocatableElement<Alloc, Compare, const Compare&>
35317 && AllocatableElement<Alloc, Compare, Compare&&>
35322 </pre></blockquote>
35326 23.4.4p2 Class template multiset [multiset]
35328 <blockquote><pre> namespace std {
35329 template <ValueType Key, <del>Predicate</del><ins>StrictWeakOrder</ins><auto, Key<del>, Key</del>> Compare = less<Key>,
35330 Allocator Alloc = allocator<Key> >
35331 requires NothrowDestructible<Key> && CopyConstructible<Compare>
35332 && AllocatableElement<Alloc, Compare, const Compare&>
35333 && AllocatableElement<Alloc, Compare, Compare&&>
35338 </pre></blockquote>
35341 23.5 Unordered associative containers [unord]
35344 1 Headers <unordered_map> and <unordered_set>:
35347 Header <unordered_map> synopsis
35349 <blockquote><pre> namespace std {
35350 // 23.5.1, class template unordered_map:
35351 template <ValueType Key,
35353 Callable<auto, const Key&> Hash = hash<Key>,
35354 <del>Predicate</del><ins>EquivalenceRelation</ins><auto, Key<del>, Key</del>> Pred = equal_to<Key>,
35355 Allocator Alloc = allocator<pair&lt;<b>const Key, T> > >
35356 requires NothrowDestructible<Key> && NothrowDestructible<T>
35357 && SameType<Hash::result_type, size_t>
35358 && CopyConstructible<Hash> && CopyConstructible<Pred>
35359 && AllocatableElement<Alloc, Pred, const Pred&>
35360 && AllocatableElement<Alloc, Pred, Pred&&>
35361 && AllocatableElement<Alloc, Hash, const Hash&>
35362 && AllocatableElement<Alloc, Hash, Hash&&>
35363 class unordered_map;
35365 // 23.5.2, class template unordered_multimap:
35366 template <ValueType Key,
35368 Callable<auto, const Key&> Hash = hash<Key>,
35369 <del>Predicate</del><ins>EquivalenceRelation</ins><auto, Key<del>, Key</del>> Pred = equal_to<Key>,
35370 Allocator Alloc = allocator<pair&lt;<b>const Key, T> > >
35371 requires NothrowDestructible<Key> && NothrowDestructible<T>
35372 && SameType<Hash::result_type, size_t>
35373 && CopyConstructible<Hash> && CopyConstructible<Pred>
35374 && AllocatableElement<Alloc, Pred, const Pred&>
35375 && AllocatableElement<Alloc, Pred, Pred&&>
35376 && AllocatableElement<Alloc, Hash, const Hash&>
35377 && AllocatableElement<Alloc, Hash, Hash&&>
35378 class unordered_multimap;
35382 </pre></blockquote>
35385 Header <unordered_set> synopsis
35387 <blockquote><pre> namespace std {
35388 // 23.5.3, class template unordered_set:
35389 template <ValueType Value,
35390 Callable<auto, const Value&> Hash = hash<Value>,
35391 <del>Predicate</del><ins>EquivalenceRelation</ins><auto, Value<del>, Value</del>> class Pred = equal_to<Value>,
35392 Allocator Alloc = allocator<Value> >
35393 requires NothrowDestructible<Value>
35394 && SameType<Hash::result_type, size_t>
35395 && CopyConstructible<Hash> && CopyConstructible<Pred>
35396 && AllocatableElement<Alloc, Pred, const Pred&>
35397 && AllocatableElement<Alloc, Pred, Pred&&>
35398 && AllocatableElement<Alloc, Hash, const Hash&>
35399 && AllocatableElement<Alloc, Hash, Hash&&>
35400 class unordered_set;
35402 // 23.5.4, class template unordered_multiset:
35403 template <ValueType Value,
35404 Callable<auto, const Value&> Hash = hash<Value>,
35405 <del>Predicate</del><ins>EquivalenceRelation</ins><auto, Value<del>, Value</del>> class Pred = equal_to<Value>,
35406 Allocator Alloc = allocator<Value> >
35407 requires NothrowDestructible<Value>
35408 && SameType<Hash::result_type, size_t>
35409 && CopyConstructible<Hash> && CopyConstructible<Pred>
35410 && AllocatableElement<Alloc, Pred, const Pred&>
35411 && AllocatableElement<Alloc, Pred, Pred&&>
35412 && AllocatableElement<Alloc, Hash, const Hash&>
35413 && AllocatableElement<Alloc, Hash, Hash&&>
35414 class unordered_multiset;
35418 </pre></blockquote>
35421 23.5.1p3 Class template unordered_map [unord.map]
35423 <blockquote><pre> namespace std {
35424 template <ValueType Key,
35426 Callable<auto, const Key&> Hash = hash<Key>,
35427 <del>Predicate</del><ins>EquivalenceRelation</ins><auto, Key<del>, Key</del>> Pred = equal_to<Key>,
35428 Allocator Alloc = allocator<pair&lt;<b>const Key, T> > >
35429 requires NothrowDestructible<Key> && NothrowDestructible<T>
35430 && SameType<Hash::result_type, size_t>
35431 && CopyConstructible<Hash> && CopyConstructible<Pred>
35432 && AllocatableElement<Alloc, Pred, const Pred&>
35433 && AllocatableElement<Alloc, Pred, Pred&&>
35434 && AllocatableElement<Alloc, Hash, const Hash&>
35435 && AllocatableElement<Alloc, Hash, Hash&&>
35436 class unordered_map
35441 </pre></blockquote>
35444 23.5.2p3 Class template unordered_multimap [unord.multimap]
35446 <blockquote><pre> namespace std {
35447 template <ValueType Key,
35449 Callable<auto, const Key&> Hash = hash<Key>,
35450 <del>Predicate</del><ins>EquivalenceRelation</ins><auto, Key<del>, Key</del>> Pred = equal_to<Key>,
35451 Allocator Alloc = allocator<pair&lt;<b>const Key, T> > >
35452 requires NothrowDestructible<Key> && NothrowDestructible<T>
35453 && SameType<Hash::result_type, size_t>
35454 && CopyConstructible<Hash> && CopyConstructible<Pred>
35455 && AllocatableElement<Alloc, Pred, const Pred&>
35456 && AllocatableElement<Alloc, Pred, Pred&&>
35457 && AllocatableElement<Alloc, Hash, const Hash&>
35458 && AllocatableElement<Alloc, Hash, Hash&&>
35459 class unordered_multimap
35464 </pre></blockquote>
35467 23.5.3p3 Class template unordered_set [unord.set]
35469 <blockquote><pre> namespace std {
35470 template <ValueType Value,
35471 Callable<auto, const Value&> Hash = hash<Value>,
35472 <del>Predicate</del><ins>EquivalenceRelation</ins><auto, Value<del>, Value</del>> class Pred = equal_to<Value>,
35473 Allocator Alloc = allocator<Value> >
35474 requires NothrowDestructible<Value>
35475 && SameType<Hash::result_type, size_t>
35476 && CopyConstructible<Hash> && CopyConstructible<Pred>
35477 && AllocatableElement<Alloc, Pred, const Pred&>
35478 && AllocatableElement<Alloc, Pred, Pred&&>
35479 && AllocatableElement<Alloc, Hash, const Hash&>
35480 && AllocatableElement<Alloc, Hash, Hash&&>
35481 class unordered_set
35486 </pre></blockquote>
35488 23.5.4p3 Class template unordered_multiset [unord.multiset]
35490 <blockquote><pre> namespace std {
35491 template <ValueType Value,
35492 Callable<auto, const Value&> Hash = hash<Value>,
35493 <del>Predicate</del><ins>EquivalenceRelation</ins><auto, Value<del>, Value</del>> class Pred = equal_to<Value>,
35494 Allocator Alloc = allocator<Value> >
35495 requires NothrowDestructible<Value>
35496 && SameType<Hash::result_type, size_t>
35497 && CopyConstructible<Hash> && CopyConstructible<Pred>
35498 && AllocatableElement<Alloc, Pred, const Pred&>
35499 && AllocatableElement<Alloc, Pred, Pred&&>
35500 && AllocatableElement<Alloc, Hash, const Hash&>
35501 && AllocatableElement<Alloc, Hash, Hash&&>
35502 class unordered_multiset
35507 </pre></blockquote>
35517 <h3><a name="1112"></a>1112. bitsets and new style for loop</h3>
35518 <p><b>Section:</b> 20.3.6 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
35519 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-06 <b>Last modified:</b> 2009-05-25</p>
35520 <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>
35521 <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>
35522 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
35523 <p><b>Discussion:</b></p>
35525 <tt>Std::bitset</tt> is a homogeneous container-like sequence of bits, yet it does
35526 not model the Range concept so cannot be used with the new for-loop syntax.
35527 It is the only such type in the library that does NOT support the new for
35531 The obvious reason is that bitset does not support iterators.
35534 At least two reasonable solutions are available:
35538 Add an iterator interface to <tt>bitset</tt>, bringing its interface close to that
35539 of <tt>std::array</tt>
35542 Provide an unspecified concept_map for <tt>Range<bitset></tt>.
35546 The latter will still need some kind of iterator-like adapter for <tt>bitset</tt>,
35547 but gives implementers greater freedom on the details. E.g. begin/end return
35548 some type that simply invokes <tt>operator[]</tt> on the object it wraps, and
35549 increments its index on <tt>operator++</tt>. A vendor can settle for <tt>InputIterator</tt>
35550 support, rather than wrapping up a full <tt>RandomAccessIterator</tt>.
35553 I have a mild preference for option (ii) as I think it is less work to
35554 specify at this stage of the process, although (i) is probably more useful
35558 Hmm, my wording looks a little woolly, as it does not say what the element
35559 type of the range is. Do I get a range of <tt>bool</tt>, <tt>bitset<N>::reference</tt>, or
35560 something else entirely?
35563 I guess most users will assume the behaviour of reference, but expect to
35564 work with <tt>bool</tt>. <tt>Bool</tt> is OK for read-only traversal, but you really need to
35565 take a reference to a <tt>bitset::reference</tt> if you want to write back.
35574 We further recommend this be deferred until after the next Committee Draft.
35578 2009-05-25 Alisdair adds:
35584 I just stumbled over the <tt>Range concept_map</tt> for <tt>valarray</tt> and this should
35585 probably set the precedent on how to write the wording.
35589 Howard: I've replaced the proposed wording with Alisdair's suggestion.
35597 <p><b>Proposed resolution:</b></p>
35600 20.3.6.X bitset concept maps [bitset.concepts] (made up clause name/number)
35602 <pre>template<size_t N>
35603 concept_map Range<bitset<N>> {
35604 typedef unspecified iterator;
35605 iterator begin(bitset<N>& a);
35606 iterator end(bitset<N>& a);
35609 template<typename T>
35610 concept_map Range<const bitset<N>> {
35611 typedef unspecified iterator;
35612 iterator begin(const bitset<N>& a);
35613 iterator end(const bitset<N>& a);
35617 -1- <i>Note:</i> these concept_maps adapt <tt>bitset</tt> to the <tt>Range</tt> concept.
35620 <pre>typedef <i>unspecified</i> iterator;
35624 -2- <i>Requires:</i> <tt>iterator</tt> shall meet the requirements of the
35625 <tt>RandomAccessIterator</tt> concept and <tt>iterator::reference</tt>
35626 shall equal <tt>bitset<N>::reference</tt> or <tt>const bitset<N>::reference</tt>.
35629 <pre>iterator begin(bitset<N>& a);
35630 iterator begin(const bitset<N>& a);
35634 -3- <i>Returns:</i> an <tt>iterator</tt> referencing the first bit in the <tt>bitset</tt>.
35637 <pre>iterator end(bitset<N>& a);
35638 iterator end(const bitset<N>& a);
35642 -4- <i>Returns:</i> an <tt>iterator</tt> referencing one past the last bit in the <tt>bitset</tt>.
35655 <h3><a name="1113"></a>1113. <tt>bitset::to_string</tt> could be simplified</h3>
35656 <p><b>Section:</b> 20.3.6 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
35657 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-09 <b>Last modified:</b> 2009-05-23</p>
35658 <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>
35659 <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>
35660 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
35661 <p><b>Discussion:</b></p>
35663 In <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#853">853</a> our resolution is changing the signature by adding two
35664 defaulting arguments to 3 calls. In principle, this means that ABI breakage
35665 is not an issue, while API is preserved.
35668 With that observation, it would be very nice to use the new ability to
35669 supply default template parameters to function templates to collapse all 3
35670 signatures into 1. In that spirit, this issue offers an alternative resolution
35671 than that of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#853">853</a>.
35680 and look at the issue again after <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#853">853</a> has been accepted.
35681 We further recommend this be deferred until after the next Committee Draft.
35685 <p><b>Proposed resolution:</b></p>
35690 In 20.3.6 [template.bitset]/1 (class bitset) ammend:
35692 <blockquote><pre>template <class charT <ins>= char</ins>,
35693 class traits <ins>= char_traits<charT></ins>,
35694 class Allocator <ins>= allocator<charT></ins>>
35695 basic_string<charT, traits, Allocator>
35696 to_string(charT zero = charT('0'), charT one = charT('1')) const;
35697 <del>template <class charT, class traits>
35698 basic_string<charT, traits, allocator<charT> > to_string() const;
35699 template <class charT>
35700 basic_string<charT, char_traits<charT>, allocator<charT> > to_string() const;
35701 basic_string<char, char_traits<char>, allocator<char> > to_string() const;</del>
35702 </pre></blockquote>
35706 In 20.3.6.2 [bitset.members] prior to p35 ammend:
35708 <blockquote><pre>template <class charT <ins>= char</ins>,
35709 class traits <ins>= char_traits<charT></ins>,
35710 class Allocator <ins>= allocator<charT></ins>>
35711 basic_string<charT, traits, Allocator>
35712 to_string(charT zero = charT('0'), charT one = charT('1')) const;
35713 </pre></blockquote>
35716 Strike 20.3.6.2 [bitset.members] paragraphs 37 -> 39 (including signature
35727 <h3><a name="1114"></a>1114. Type traits underspecified</h3>
35728 <p><b>Section:</b> 20.6 [meta] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
35729 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-05-12 <b>Last modified:</b> 2009-05-23</p>
35730 <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>
35731 <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>
35732 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
35733 <p><b>Discussion:</b></p>
35736 Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#975">975</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1023">1023</a>.
35740 The current wording in 20.6.1 [meta.rqmts] is still unclear concerning
35741 it's requirements on the type traits classes regarding ambiguities.
35742 Specifically it's unclear
35747 if a predicate trait (20.6.4 [meta.unary], 20.6.5 [meta.rel]) could derive from both
35748 <tt>true_type</tt>/<tt>false_type</tt>.
35751 if any of the type traits (20.6.1 [meta.rqmts], 20.6.4 [meta.unary], 20.6.5 [meta.rel]) could ambiguously derive
35752 from the same specified result type.
35755 if any of the type traits (20.6.1 [meta.rqmts], 20.6.4 [meta.unary], 20.6.5 [meta.rel]) could derive from other
35756 <tt>integral_constant</tt> types making the contained names ambiguous
35759 if any of the type traits (20.6.1 [meta.rqmts], 20.6.4 [meta.unary], 20.6.5 [meta.rel]) could have other base
35760 classes that contain members hiding the name of the result type members
35761 or make the contained member names ambiguous.
35771 Alisdair would prefer to factor some of the repeated text,
35772 but modulo a corner case or two,
35773 he believes the proposed wording is otherwise substantially correct.
35781 <p><b>Proposed resolution:</b></p>
35783 The usage of the notion of a <i>BaseCharacteristic</i> below
35785 useful in other places - e.g. to define the base class relation in
35786 20.7.5 [refwrap], 20.7.15 [func.memfn], or 20.7.16.2 [func.wrap.func].
35787 In this case it's definition should probably
35788 be moved to Clause 17
35795 Change 20.6.1 [meta.rqmts]/1 as indicated:
35798 [..] It shall be <tt>DefaultConstructible</tt>, <tt>CopyConstructible</tt>, and publicly
35799 <ins>and unambiguously</ins> derived, directly or indirectly, from
35800 <ins>its <i>BaseCharacteristic</i>, which is</ins> a specialization of the
35801 template <tt>integral_constant</tt> (20.6.3), with the arguments to the template
35802 <tt>integral_constant</tt> determined by the requirements for the particular
35803 property being described. <ins>The member names of the
35804 <i>BaseCharacteristic</i> shall be unhidden and unambiguously
35805 available in the <i>UnaryTypeTrait</i>.</ins>
35810 Change 20.6.1 [meta.rqmts]/2 as indicated:
35813 [..] It shall be <tt>DefaultConstructible</tt>, <tt>CopyConstructible</tt>, and publicly
35814 <ins>and unambiguously</ins> derived, directly or indirectly, from
35815 <del>an instance</del> <ins>its <i>BaseCharacteristic</i>, which is a
35816 specialization</ins> of the template <tt>integral_constant</tt> (20.6.3), with
35817 the arguments to the template <tt>integral_constant</tt> determined by the
35818 requirements for the particular relationship being described. <ins>The
35819 member names of the <i>BaseCharacteristic</i> shall be unhidden
35820 and unambiguously available in the <i>BinaryTypeTrait</i>.</ins>
35825 Change 20.6.4 [meta.unary]/2 as indicated:
35828 Each of these templates shall be a <i>UnaryTypeTrait</i> (20.6.1),
35829 <del>publicly derived directly or indirectly from <tt>true_type</tt> if the
35830 corresponding condition is true, otherwise from <tt>false_type</tt></del>
35831 <ins>where its <i>BaseCharacteristic</i> shall be <tt>true_type</tt> if the
35832 corresponding condition is true, otherwise <tt>false_type</tt></ins>.
35837 Change 20.6.5 [meta.rel]/2 as indicated:
35841 Each of these templates shall be a <i>BinaryTypeTrait</i> (20.6.1),
35842 <del>publicly derived directly or indirectly from <tt>true_type</tt> if the
35843 corresponding condition is true, otherwise from <tt>false_type</tt></del>
35844 <ins>where its <i>BaseCharacteristic</i> shall be <tt>true_type</tt> if the
35845 corresponding condition is true, otherwise <tt>false_type</tt></ins>.
35856 <h3><a name="1115"></a>1115. <tt>va_copy</tt> missing from Standard macros table</h3>
35857 <p><b>Section:</b> C.2 [diff.library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
35858 <b>Submitter:</b> Miles Zhao <b>Opened:</b> 2009-05-23 <b>Last modified:</b> 2009-05-23</p>
35859 <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>
35860 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
35861 <p><b>Discussion:</b></p>
35863 In "Table 122 -- Standard macros" of C.2 [diff.library], which lists the 56 macros
35864 inherited from C library, <tt>va_copy</tt> seems to be missing. But in
35865 "Table 21 -- Header <tt><cstdarg></tt> synopsis" (18.10 [support.runtime]), there is.
35869 <p><b>Proposed resolution:</b></p>
35871 Add <tt>va_copy</tt> to Table 122 -- Standard macros in C.2 [diff.library].
35879 <h3><a name="1116"></a>1116. Literal constructors for tuple</h3>
35880 <p><b>Section:</b> 20.5.2 [tuple.tuple] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
35881 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-23 <b>Last modified:</b> 2009-05-24</p>
35882 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#tuple.tuple">active issues</a> in [tuple.tuple].</p>
35883 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple.tuple">issues</a> in [tuple.tuple].</p>
35884 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
35885 <p><b>Discussion:</b></p>
35887 It is not currently possible to construct <tt>tuple</tt> literal values,
35888 even if the elements are all literal types. This is because parameters
35889 are passed to constructor by reference.
35892 An alternative would be to pass all constructor arguments by value, where it
35893 is known that *all* elements are literal types. This can be determined with
35894 concepts, although note that the negative constraint really requires
35895 factoring out a separate concept, as there is no way to provide an 'any of
35896 these fails' constraint inline.
35899 Note that we will have similar issues with <tt>pair</tt> (and
35900 <tt>tuple</tt> constructors from <tt>pair</tt>) although I am steering
35901 clear of that class while other constructor-related issues settle.
35905 <p><b>Proposed resolution:</b></p>
35907 Ammend the tuple class template declaration in 20.5.2 [tuple.tuple] as
35913 Add the following concept:
35916 <blockquote><pre>auto concept AllLiteral< typename ... Types > {
35917 requires LiteralType<Types>...;
35919 </pre></blockquote>
35922 ammend the constructor
35925 <blockquote><pre><ins>template <class... UTypes>
35926 requires AllLiteral<Types...>
35927 && Constructible<Types, UTypes>...
35928 explicit tuple(UTypes...);</ins>
35930 template <class... UTypes>
35931 requires <ins>!AllLiteral<Types...></ins>
35932 <ins>&&</ins> Constructible<Types, UTypes&&>...
35933 explicit tuple(UTypes&&...);
35934 </pre></blockquote>
35937 ammend the constructor
35940 <blockquote><pre><ins>template <class... UTypes>
35941 requires AllLiteral<Types...>
35942 && Constructible<Types, UTypes>...
35943 tuple(tuple<UTypes...>);</ins>
35945 template <class... UTypes>
35946 requires <ins>!AllLiteral<Types...></ins>
35947 <ins>&&</ins> Constructible<Types, const UTypes&>...
35948 tuple(const tuple<UTypes...>&);
35949 </pre></blockquote>
35954 Update the same signatures in 20.5.2.1 [tuple.cnstr], paras 3 and 5.
35962 <h3><a name="1117"></a>1117. tuple copy constructor</h3>
35963 <p><b>Section:</b> 20.5.2.1 [tuple.cnstr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
35964 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-23 <b>Last modified:</b> 2009-05-30</p>
35965 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#tuple.cnstr">active issues</a> in [tuple.cnstr].</p>
35966 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple.cnstr">issues</a> in [tuple.cnstr].</p>
35967 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
35968 <p><b>Discussion:</b></p>
35970 The copy constructor for the <tt>tuple</tt> template is constrained. This seems an
35971 unusual strategy, as the copy constructor will be implicitly deleted if the
35972 constraints are not met. This is exactly the same effect as requesting an
35973 <tt>=default;</tt> constructor. The advantage of the latter is that it retains
35974 triviality, and provides support for <tt>tuple</tt>s as literal types if issue
35975 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1116">1116</a> is also accepted.
35978 Actually, it might be worth checking with core if a constrained copy
35979 constructor is treated as a constructor template, and as such does not
35980 suppress the implicit generation of the copy constructor which would hide
35981 the template in this case.
35985 2009-05-27 Daniel adds:
35990 This would solve one half of the suggested changes in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#801">801</a>.
35994 <p><b>Proposed resolution:</b></p>
35996 Change 20.5.2 [tuple.tuple] and 20.5.2.1 [tuple.cnstr] p4:
35999 <blockquote><pre><del>requires CopyConstructible<Types>...</del> tuple(const tuple&)<ins> = default</ins>;
36000 </pre></blockquote>
36007 <h3><a name="1118"></a>1118. tuple query APIs do not support cv-qualification</h3>
36008 <p><b>Section:</b> 20.5.2.3 [tuple.helper] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
36009 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-23 <b>Last modified:</b> 2009-05-25</p>
36010 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#tuple.helper">active issues</a> in [tuple.helper].</p>
36011 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple.helper">issues</a> in [tuple.helper].</p>
36012 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
36013 <p><b>Discussion:</b></p>
36015 The APIs <tt>tuple_size</tt> and <tt>tuple_element</tt> do not support
36016 cv-qualified <tt>tuple</tt>s, <tt>pair</tt>s or <tt>array</tt>s.
36019 The most generic solution would be to supply partial specializations once
36020 for each cv-type in the <tt>tuple</tt> header. However, requiring this header for
36021 cv-qualified <tt>pair</tt>s/<tt>array</tt>s seems unhelpful. The BSI editorial
36022 suggestion (UK-198/US-69,
36023 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2533.html">N2533</a>)
36024 to merge <tt>tuple</tt> into <tt><utility></tt> would help with <tt>pair</tt>,
36025 but not <tt>array</tt>. That might be resolved by making a dependency between the
36026 <tt><array></tt> header and <tt><utility></tt>, or simply recognising
36027 the dependency be fulfilled in a Remark.
36031 2009-05-24 Daniel adds:
36037 All <tt>tuple_size</tt> templates with a base class need to derive publicly, e.g.
36040 <blockquote><pre>template <IdentityOf T> class tuple_size< const T > :
36041 <ins>public</ins> tuple_size<T> {};
36042 </pre></blockquote>
36045 The same applies to the tuple_element class hierarchies.
36048 What is actually meant with the comment
36051 this solution relies on 'metafunction forwarding' to inherit the
36052 nested typename type
36058 I ask, because all base classes are currently unconstrained and their
36059 instantiation is invalid in the constrained context of the <tt>tuple_element</tt> partial
36060 template specializations.
36065 2009-05-24 Alisdair adds:
36071 I think a better solution might be to ask Pete editorially to change all
36072 declarations of tupling APIs to use the struct specifier instead of class.
36075 "metafunction forwarding" refers to the MPL metafunction protocol, where a
36076 metafunction result is declared as a nested typedef with the name "type",
36077 allowing metafunctions to be chained by means of inheritance. It is a
36078 neater syntax than repeatedly declaring a typedef, and inheritance syntax is
36079 slightly nicer when it comes to additional typename keywords.
36082 The constrained template with an unconstrained base is a good observation
36089 <p><b>Proposed resolution:</b></p>
36091 Add to 20.5.1 [tuple.general] p2 (Header <tt><tuple></tt> synopsis)
36094 <blockquote><pre>// 20.5.2.3, tuple helper classes:
36095 template <IdentityOf T> class tuple_size; // undefined
36096 <ins>template <IdentityOf T> class tuple_size< const T > : tuple_size<T> {};</ins>
36097 <ins>template <IdentityOf T> class tuple_size< volatile T > : tuple_size<T> {};</ins>
36098 <ins>template <IdentityOf T> class tuple_size< const volatile T > : tuple_size<T> {};</ins>
36100 template <VariableType... Types> class tuple_size<tuple<Types...> >;
36102 template <size_t I, IdentityOf T> class tuple_element; // undefined
36103 <ins>template <size_t I, IdentityOf T> class tuple_element<I, const T>;</ins>
36104 <ins>template <size_t I, IdentityOf T> class tuple_element<I, volatile T>;</ins>
36105 <ins>template <size_t I, IdentityOf T> class tuple_element<I, const volatile T>;</ins>
36107 template <size_t I, VariableType... Types>
36108 requires True<(I < sizeof...(Types))> class tuple_element<I, tuple<Types...> >;
36109 </pre></blockquote>
36112 Add to 20.5.2.3 [tuple.helper]
36115 (note that this solution relies on 'metafunction forwarding' to inherit the
36116 nested typename type)
36120 <blockquote><pre>template <class... Types>
36121 class tuple_size<tuple<Types...> >
36122 : public integral_constant<size_t, sizeof...(Types)> { };
36124 template <size_t I, class... Types>
36125 requires True<(I < sizeof...(Types))>
36126 class tuple_element<I, tuple<Types...> > {
36131 <ins>template <size_t I, IdentityOf T>
36132 class tuple_element<I, const T> : add_const<tuple_element<I,T>> {};</ins>
36134 <ins>template <size_t I, IdentityOf T>
36135 class tuple_element<I, volatile T> : add_volatile<tuple_element<I,T>> {};</ins>
36137 <ins>template <size_t I, IdentityOf T>
36138 class tuple_element<I, const volatile T> : add_cv<tuple_element<I,T>> {};</ins>
36139 </pre></blockquote>
36146 <h3><a name="1119"></a>1119. tuple query APIs do not support references</h3>
36147 <p><b>Section:</b> 20.5.2.3 [tuple.helper] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
36148 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-23 <b>Last modified:</b> 2009-05-24</p>
36149 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#tuple.helper">active issues</a> in [tuple.helper].</p>
36150 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple.helper">issues</a> in [tuple.helper].</p>
36151 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
36152 <p><b>Discussion:</b></p>
36154 The <tt>tuple</tt> query APIs <tt>tuple_size</tt> and
36155 <tt>tuple_element</tt> do not support references-to-tuples. This can be
36156 annoying when a template deduced a parameter type to be a reference,
36157 which must be explicitly stripped with <tt>remove_reference</tt> before calling
36161 I am not proposing a resolution at this point, as there is a
36162 combinatorial explosion with lvalue/rvalue references and
36163 cv-qualification (see previous issue) that suggests some higher
36164 refactoring is in order. This might be something to kick back over to
36168 Note that we have the same problem in numeric_limits.
36172 <p><b>Proposed resolution:</b></p>
36179 <h3><a name="1120"></a>1120. New type trait - remove_all</h3>
36180 <p><b>Section:</b> 20.6 [meta] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
36181 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-23 <b>Last modified:</b> 2009-05-24</p>
36182 <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>
36183 <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>
36184 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
36185 <p><b>Discussion:</b></p>
36187 Sometimes it is necessary to remove all qualifiers from a type before
36188 passing on to a further API. A good example would be calling the
36189 <tt>tuple</tt> query APIs <tt>tuple_size</tt> or <tt>tuple_element</tt>
36190 with a deduced type inside a function template. If the deduced type is
36191 cv-qualified or a reference then the call will fail. The solution is to
36193 <tt>remove_cv<remove_reference<T>::type>::type</tt>, and
36194 note that the order matters.
36197 Suggest it would be helpful to add a new type trait,
36198 <tt>remove_all</tt>, that removes all top-level qualifiers from a type
36199 i.e. cv-qualification and any references. Define the term in such a way
36200 that if additional qualifiers are added to the language, then
36201 <tt>remove_all</tt> is defined as stripping those as well.
36205 <p><b>Proposed resolution:</b></p>
36212 <h3><a name="1121"></a>1121. Support for multiple arguments</h3>
36213 <p><b>Section:</b> 20.4.2 [ratio.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
36214 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-25 <b>Last modified:</b> 2009-05-25</p>
36215 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#ratio.arithmetic">active issues</a> in [ratio.arithmetic].</p>
36216 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ratio.arithmetic">issues</a> in [ratio.arithmetic].</p>
36217 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
36218 <p><b>Discussion:</b></p>
36220 Both add and multiply could sensibly be called with more than two arguments.
36221 The variadic template facility makes such declarations simple, and is likely
36222 to be frequently wrapped by end users if we do not supply the variant
36226 We deliberately ignore divide at this point as it is not transitive.
36227 Likewise, subtract places special meaning on the first argument so I do not
36228 suggest extending that immediately. Both could be supported with analogous
36229 wording to that for add/multiply below.
36232 Note that the proposed resolution is potentially incompatible with that
36233 proposed for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#921">921</a>, although the addition of the typedef to ratio would be
36238 <p><b>Proposed resolution:</b></p>
36240 note that this wording relies on 'metafunction forwarding' as described by
36246 20.4 [ratio] p3 synopsis: change
36249 <blockquote><pre>// ratio arithmetic
36250 template <class R1, class R2<ins>, class ... RList</ins>> struct ratio_add;
36251 template <class R1, class R2> struct ratio_subtract;
36252 template <class R1, class R2<ins>, class ... RList</ins>> struct ratio_multiply;
36253 template <class R1, class R2> struct ratio_divide;
36254 </pre></blockquote>
36257 20.4.2 [ratio.arithmetic] p1: change
36260 <blockquote><pre><ins>template <class R1, class R2, class ... RList> struct ratio_add
36261 : ratio_add< R1, ratio_add<R2, RList...>> {
36264 template <class R1, class R2> struct ratio_add<ins><R1, R2></ins> {
36265 typedef <i>see below</i> type;
36267 </pre></blockquote>
36271 20.4.2 [ratio.arithmetic] p3: change
36274 <blockquote><pre><ins>template <class R1, class R2, class ... RList> struct ratio_multiply
36275 : ratio_multiply< R1, ratio_ multiply <R2, RList...>> {
36278 template <class R1, class R2> struct ratio_ multiply<ins><R1, R2></ins> {
36279 typedef <i>see below</i> type;
36281 </pre></blockquote>
36289 <h3><a name="1122"></a>1122. Ratio values should be constexpr</h3>
36290 <p><b>Section:</b> 20.4.1 [ratio.ratio] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
36291 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-25 <b>Last modified:</b> 2009-05-25</p>
36292 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#ratio.ratio">active issues</a> in [ratio.ratio].</p>
36293 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ratio.ratio">issues</a> in [ratio.ratio].</p>
36294 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
36295 <p><b>Discussion:</b></p>
36297 The values <tt>num</tt> and <tt>den</tt> in the <tt>ratio</tt> template
36298 should be declared <tt>constexpr</tt>.
36302 <p><b>Proposed resolution:</b></p>
36304 20.4.1 [ratio.ratio]
36307 <blockquote><pre>namespace std {
36308 template <intmax_t N, intmax_t D = 1>
36311 static const<ins>expr</ins> intmax_t num;
36312 static const<ins>expr</ins> intmax_t den;
36315 </pre></blockquote>
36323 <h3><a name="1123"></a>1123. no requirement that standard streams be flushed</h3>
36324 <p><b>Section:</b> 27.5.2.1.6 [ios::Init] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
36325 <b>Submitter:</b> James Kanze <b>Opened:</b> 2009-05-14 <b>Last modified:</b> 2009-05-30</p>
36326 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#ios::Init">active issues</a> in [ios::Init].</p>
36327 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios::Init">issues</a> in [ios::Init].</p>
36328 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
36329 <p><b>Discussion:</b></p>
36331 As currently formulated, the standard doesn't require that there
36332 is ever a flush of <tt>cout</tt>, etc. (This implies, for example, that
36333 the classical hello, world program may have no output.) In the
36335 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdf">N2798</a>),
36336 there is a requirement that the objects
36337 be constructed before <tt>main</tt>, and before the dynamic
36338 initialization of any non-local objects defined after the
36339 inclusion of <tt><iostream></tt> in the same translation unit. The only
36340 requirement that I can find concerning flushing, however, is in
36341 27.5.2.1.6 [ios::Init], where the destructor of the last
36342 <tt>std::ios_base::Init</tt> object flushes. But there is, as far as I
36343 can see, no guarantee that such an object ever exists.
36346 Also, the wording in [iostreams.objects] says that:
36350 are constructed and the associations are established at some
36351 time prior to or during the first time an object of class
36352 <tt>ios_base::Init</tt> is constructed, and in any case before the body
36353 of main begins execution.
36356 In 27.5.2.1.6 [ios::Init], however, as an
36357 effect of the constructor, it says that
36360 If <tt>init_cnt</tt> is zero,
36361 the function stores the value one in <tt>init_cnt</tt>, then constructs
36362 and initializes the objects <tt>cin</tt>, <tt>cout</tt>, <tt>cerr</tt>, <tt>clog</tt>
36363 <tt>wcin</tt>, <tt>wcout</tt>, <tt>wcerr</tt>, and <tt>wclog</tt>"
36367 which seems to forbid earlier
36372 (Note that with these changes, the exposition only "<tt>static
36373 int init_cnt</tt>" in <tt>ios_base::Init</tt> can be dropped.)
36376 Of course, a determined programmer can still inhibit the
36377 flush with things like:
36379 <blockquote><pre>new std::ios_base::Init ; // never deleted
36380 </pre></blockquote>
36382 or (in a function):
36384 <blockquote><pre>std::ios_base::Init ensureConstruction ;
36386 exit( EXIT_SUCCESS ) ;
36387 </pre></blockquote>
36389 Perhaps some words somewhere to the effect that all
36390 <tt>std::ios_base::Init</tt> objects should have static lifetime
36395 <p><b>Proposed resolution:</b></p>
36397 Change 27.4 [iostream.objects]/2:
36401 -2- The objects are constructed and the associations are established at
36402 some time prior to or during the first time an object of class
36403 <tt>ios_base::Init</tt> is constructed, and in any case before the body
36404 of main begins execution.<sup>292</sup> The objects are not destroyed
36405 during program execution.<sup>293</sup>
36406 <del>If a translation unit includes
36407 <tt><iostream></tt> or explicitly constructs an
36408 <tt>ios_base::Init</tt> object, these stream objects shall be
36409 constructed before dynamic initialization of non-local objects defined
36410 later in that translation unit.</del>
36411 <ins>The results of including <tt><iostream></tt> in a translation
36412 unit shall be as if <tt><iostream></tt> defined an instance of
36413 <tt>ios_base::Init</tt> with static lifetime. Similarly, the entire
36414 program shall behave as if there were at least one instance of
36415 <tt>ios_base::Init</tt> with static lifetime.</ins>
36419 Change 27.5.2.1.6 [ios::Init]/3:
36426 -3- <i>Effects:</i> Constructs an object of class <tt>Init</tt>.
36427 <del>If <tt>init_cnt</tt> is zero, the function stores the value one in
36428 <tt>init_cnt</tt>, then constructs and initializes the objects
36429 <tt>cin</tt>, <tt>cout</tt>, <tt>cerr</tt>, <tt>clog</tt> (27.4.1),
36430 <tt>wcin</tt>, <tt>wcout</tt>, <tt>wcerr</tt>, and <tt>wclog</tt>
36431 (27.4.2). In any case, the function then adds one to the value stored in
36432 <tt>init_cnt</tt>.</del>
36433 <ins>Constructs and initializes the objects <tt>cin</tt>, <tt>cout</tt>,
36434 <tt>cerr</tt>, <tt>clog</tt>, <tt>wcin</tt>, <tt>wcout</tt>,
36435 <tt>wcerr</tt> and <tt>wclog</tt> if they have not already been
36436 constructed and initialized.</ins>
36441 Change 27.5.2.1.6 [ios::Init]/4:
36448 -4- <i>Effects:</i> Destroys an object of class <tt>Init</tt>.
36449 <del>The function subtracts one from the value stored in <tt>init_cnt</tt> and,
36450 if the resulting stored value is one,</del>
36451 <ins>If there are no other instances of the class still in
36453 calls <tt>cout.flush()</tt>,
36454 <tt>cerr.flush()</tt>, <tt>clog.flush()</tt>, <tt>wcout.flush()</tt>,
36455 <tt>wcerr.flush()</tt>, <tt>wclog.flush()</tt>.
36465 <h3><a name="1124"></a>1124. Invalid definition of concept RvalueOf</h3>
36466 <p><b>Section:</b> 20.2.1 [concept.transform] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
36467 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-05-28 <b>Last modified:</b> 2009-05-30</p>
36468 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#concept.transform">active issues</a> in [concept.transform].</p>
36469 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#concept.transform">issues</a> in [concept.transform].</p>
36470 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
36471 <p><b>Discussion:</b></p>
36473 A recent news group
36474 <a href="http://groups.google.de/group/comp.std.c++/browse_frm/thread/8eb92768a19fb46f">article</a>
36475 points to several defects in the
36476 specification of reference-related concepts.
36479 One problem of the concept <tt>RvalueOf</tt> as currently defined in
36480 20.2.1 [concept.transform]:
36483 <blockquote><pre>concept RvalueOf<typename T> {
36484 typename type = T&&;
36485 requires ExplicitlyConvertible<T&,type> && Convertible<T&&,type>;
36488 template<typename T> concept_map RvalueOf<T&> {
36489 typedef T&& type;
36491 </pre></blockquote>
36494 is that if <tt>T</tt> is an lvalue-reference, the requirement
36495 <tt>Convertible<T&&,type></tt> isn't satisfied for
36496 lvalue-references, because after reference-collapsing in the concept
36497 definition we have <tt>Convertible<T&,type></tt> in this case,
36498 which isn't satisfied in the concept map template and also is not the
36499 right constraint either. I think that the reporter is right that
36500 <tt>SameType</tt> requirements should do the job and that we also should
36501 use the new <tt>RvalueReference</tt> concept to specify a best matching
36506 <p><b>Proposed resolution:</b></p>
36508 In 20.2.1 [concept.transform] before p. 4 change as indicated:
36511 <blockquote><pre>auto concept RvalueOf<typename T> {
36512 <del>typename</del><ins>RvalueReference</ins> type = T&&;
36513 requires <del>ExplicitlyConvertible<T&, type> && Convertible<T&&, type></del><ins>SameType<T&, type&></ins>;
36515 </pre></blockquote>
36522 <h3><a name="1125"></a>1125. ostream_iterator does not work with movable types</h3>
36523 <p><b>Section:</b> 24.6.2.2 [ostream.iterator.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
36524 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-28 <b>Last modified:</b> 2009-05-30</p>
36525 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
36526 <p><b>Discussion:</b></p>
36528 <tt>ostream_iterator</tt> has not been updated to support moveable types, in a
36529 similar manner to the insert iterators.
36530 Note that this is not a problem for <tt>ostreambuf_iterator</tt>, as the types it is
36531 restricted to dealing with do not support extra-efficient moving.
36535 <p><b>Proposed resolution:</b></p>
36537 Add second <tt>operator=</tt> overload to class <tt>template ostream_iterator</tt>
36538 in 24.6.2 [ostream.iterator], para 2:
36541 <blockquote><pre>ostream_iterator<T,charT,traits>& operator=(const T& value);
36542 <ins>ostream_iterator<T,charT,traits>& operator=(T&& value);</ins>
36543 </pre></blockquote>
36546 Add a new paragraph: in 24.6.2.2 [ostream.iterator.ops]:
36550 <pre>ostream_iterator& operator=(T&& value);
36554 -2- <i>Effects:</i>
36556 <blockquote><pre>*out_stream << std::move(value);
36558 *out_stream << delim;
36560 </pre></blockquote>
36570 <h3><a name="1126"></a>1126. <tt>istreambuff_iterator::equal</tt> needs a const & parameter</h3>
36571 <p><b>Section:</b> 24.6.3.5 [istreambuf.iterator::equal] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
36572 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-28 <b>Last modified:</b> 2009-05-30</p>
36573 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#istreambuf.iterator::equal">active issues</a> in [istreambuf.iterator::equal].</p>
36574 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istreambuf.iterator::equal">issues</a> in [istreambuf.iterator::equal].</p>
36575 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
36576 <p><b>Discussion:</b></p>
36578 The <tt>equal</tt> member function of <tt>istreambuf_iterator</tt> is
36579 declared <tt>const</tt>, but takes its argument by non-const reference.
36582 This is not compatible with the <tt>operator==</tt> free function overload, which is
36583 defined in terms of calling <tt>equal</tt> yet takes both arguments by reference to
36588 The proposed wording is consistent with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#110">110</a> with status TC1.
36594 <p><b>Proposed resolution:</b></p>
36596 Ammend in both:<br>
36597 24.6.3 [istreambuf.iterator]<br>
36598 24.6.3.5 [istreambuf.iterator::equal]<br>
36601 <blockquote><pre>bool equal(<ins>const </ins>istreambuf_iterator& b) const;
36602 </pre></blockquote>
36610 <h3><a name="1127"></a>1127. rvalue references and iterator traits</h3>
36611 <p><b>Section:</b> D.10.1 [iterator.traits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
36612 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-28 <b>Last modified:</b> 2009-05-30</p>
36613 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.traits">issues</a> in [iterator.traits].</p>
36614 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
36615 <p><b>Discussion:</b></p>
36617 The deprecated support for <tt>iterator_traits</tt> and legacy (unconstrained)
36618 iterators features the (exposition only) concept:
36621 <blockquote><pre>concept IsReference<typename T> { } // exposition only
36622 template<typename T> concept_map IsReference<T&> { }
36623 </pre></blockquote>
36625 Now this looks exactly like the <tt>LvalueReference</tt> concept recently added to
36626 clause 20, so I wonder if we should use that instead?
36627 Then I consider the lack of rvalue-reference support, which means that
36628 <tt>move_iterator</tt> would always flag as merely supporting the <tt>input_iterator_tag</tt>
36629 category. This suggests we retain the exposition concept, but add a second
36630 concept_map to support rvalue references.
36633 I would suggest adding the extra concept_map is the right way forward, but
36634 still wonder if the two exposition-only concepts in this clause might be
36635 worth promoting to clause 20. That question might better be answered with a
36636 fuller investigation of type_trait/concept unification though.
36640 <p><b>Proposed resolution:</b></p>
36642 In Iterator traits D.10.1 [iterator.traits] para 4 add:
36645 <blockquote><pre>concept IsReference<typename T> { } // exposition only
36646 template<typename T> concept_map IsReference<T&> { }
36647 <ins>template<typename T> concept_map IsReference<T&&> { }</ins>
36648 </pre></blockquote>
36656 <h3><a name="1128"></a>1128. Missing definition of <tt>iterator_traits<T*></tt></h3>
36657 <p><b>Section:</b> 24.3 [iterator.syn] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
36658 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-28 <b>Last modified:</b> 2009-05-30</p>
36659 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
36660 <p><b>Discussion:</b></p>
36662 The <tt><iterator></tt> header synopsis declares a partial specialization of
36663 <tt>iterator_traits</tt> to support pointers, 24.3 [iterator.syn]. The implication
36664 is that specialization will be described in D10, yet it did not follow the
36665 rest of the deprecated material into this clause.
36668 However, this is not as bad as it first seems!
36669 There are partial specializations of <tt>iterator_traits</tt> for types that satisfy
36670 the various Iterator concepts, and there are concept_maps for pointers to
36671 explicitly support the <tt>RandomAccessIterator</tt> concept, so the required
36672 template will be present - just not in the manner advertised.
36675 I can see two obvious solutions:
36680 Restore the <tt>iterator_traits<T*></tt> partial specialization in D.10
36683 Remove the declaration of <tt>iterator_traits<T*></tt> from 24.3 synopsis
36687 I recommend option (ii) in the wording below
36690 Option (ii) could be extended to strike all the declarations of deprecated
36691 material from the synopsis, as it is effectively duplicating D.10 anyway.
36692 This is the approach taken for deprecated library components in the 98/03
36693 standards. This is probably a matter best left to the Editor though.
36697 <p><b>Proposed resolution:</b></p>
36699 In 24.3 [iterator.syn] strike:
36702 <blockquote><pre><del>template<class T> struct iterator_traits<T*>;</del>
36703 </pre></blockquote>
36711 <h3><a name="1129"></a>1129. <tt>istream(buf)_iterator</tt> should support literal sentinel value</h3>
36712 <p><b>Section:</b> 24.6.1.1 [istream.iterator.cons], 24.6.3 [istreambuf.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
36713 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-30 <b>Last modified:</b> 2009-06-09</p>
36714 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
36715 <p><b>Discussion:</b></p>
36717 <tt>istream_iterator</tt> and <tt>istreambuf_iterator</tt> should support literal sentinel
36718 values. The default constructor is frequently used to terminate ranges, and
36719 could easily be a literal value for <tt>istreambuf_iterator</tt>, and
36720 <tt>istream_iterator</tt> when iterating value types. A little more work using a
36721 suitably sized/aligned char-array for storage (or an updated component like
36722 <tt>boost::optional</tt> proposed for TR2) would allow <tt>istream_iterator</tt> to support
36723 <tt>constexpr</tt> default constructor in all cases, although we might leave this
36724 tweak as a QoI issue. Note that requiring <tt>constexpr</tt> be supported also
36725 allows us to place no-throw guarantees on this constructor too.
36729 2009-06-02 Daniel adds:
36735 I agree with the usefulness of the issue suggestion, but we need
36736 to ensure that <tt>istream_iterator</tt> <em>can</em> satisfy be literal if needed.
36737 Currently this is not clear, because 24.6.1 [istream.iterator]/3 declares
36738 a copy constructor and a destructor and explains their semantic in
36739 24.6.1.1 [istream.iterator.cons]/3+4.
36742 The prototype semantic specification is ok (although it seems
36743 somewhat redundant to me, because the semantic doesn't say
36744 anything interesting in both cases), but for support of trivial class
36745 types we also need a trivial copy constructor and destructor as of
36746 9 [class]/6. The current non-informative specification of these
36747 two special members suggests to remove their explicit declaration
36748 in the class and add explicit wording that says that if <tt>T</tt> is
36749 trivial a default constructed iterator is also literal, alternatively it
36750 would be possible to mark both as defaulted and add explicit
36751 (memberwise) wording that guarantees that they are trivial.
36754 Btw.: I'm quite sure that the <tt>istreambuf_iterator</tt> additions to
36755 ensure triviality are not sufficient as suggested, because the
36756 library does not yet give general guarantees that a defaulted
36757 special member declaration makes this member also trivial.
36758 Note that e.g. the atomic types do give a general statement!
36761 Finally there is a wording issue: There does not exist something
36762 like a "literal constructor". The core language uses the term
36763 "constexpr constructor" for this.
36771 Change 24.6.1 [istream.iterator]/3 as indicated:
36773 <blockquote><pre><ins>constexpr</ins> istream_iterator();
36774 istream_iterator(istream_type& s);
36775 istream_iterator(const istream_iterator<del><T,charT,traits,Distance></del>& x)<ins> = default</ins>;
36776 ~istream_iterator()<ins> = default</ins>;
36777 </pre></blockquote>
36781 Change 24.6.1.1 [istream.iterator.cons]/1 as indicated:
36783 <blockquote><pre><ins>constexpr</ins> istream_iterator();
36786 -1- <i>Effects:</i> Constructs the end-of-stream iterator. <ins>If <tt>T</tt> is a literal type,
36787 then this constructor shall be a constexpr constructor.</ins>
36793 Change 24.6.1.1 [istream.iterator.cons]/3 as indicated:
36795 <blockquote><pre>istream_iterator(const istream_iterator<del><T,charT,traits,Distance></del>& x)<ins> = default</ins>;
36798 -3- <i>Effects:</i> Constructs a copy of <tt>x</tt>. <ins>If <tt>T</tt> is a literal type, then
36799 this constructor shall be a trivial copy constructor.</ins>
36805 Change 24.6.1.1 [istream.iterator.cons]/4 as indicated:
36808 <blockquote><pre>~istream_iterator()<ins> = default</ins>;
36811 -4- <i>Effects:</i> The iterator is destroyed. <ins>If <tt>T</tt> is a literal type, then
36812 this destructor shall be a trivial
36819 Change 24.6.3 [istreambuf.iterator] before p. 1 as indicated:
36822 <blockquote><pre><ins>constexpr</ins> istreambuf_iterator() throw();
36823 <ins>istreambuf_iterator(const istreambuf_iterator&) throw() = default;</ins>
36824 <ins>~istreambuf_iterator() throw() = default;</ins>
36825 </pre></blockquote>
36829 Change 24.6.3 [istreambuf.iterator]/1 as indicated:
36832 [..] The default constructor <tt>istreambuf_iterator()</tt> and the constructor
36833 <tt>istreambuf_iterator(0)</tt> both
36834 construct an end of stream iterator object suitable for use as an
36835 end-of-range. <ins>All
36836 specializations of <tt>istreambuf_iterator</tt> shall have a trivial copy
36837 constructor, a constexpr default
36838 constructor and a trivial destructor.</ins>
36845 <p><b>Proposed resolution:</b></p>
36847 24.6.1 [istream.iterator] para 3
36850 <blockquote><pre><ins>constexpr</ins> istream_iterator();
36851 </pre></blockquote>
36854 24.6.1.1 [istream.iterator.cons]
36857 <blockquote><pre><ins>constexpr</ins> istream_iterator();
36860 -1- <i>Effects:</i> Constructs the end-of-stream iterator.
36861 <ins>If <tt>T</tt> is a literal type, then this constructor shall
36862 be a literal constructor.</ins>
36867 24.6.3 [istreambuf.iterator]
36870 <blockquote><pre><ins>constexpr</ins> istreambuf_iterator() throw();
36871 </pre></blockquote>
36879 <h3><a name="1130"></a>1130. <tt>copy_exception</tt> name misleading</h3>
36880 <p><b>Section:</b> 18.8.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
36881 <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2009-05-13 <b>Last modified:</b> 2009-06-02</p>
36882 <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>
36883 <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>
36884 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
36885 <p><b>Discussion:</b></p>
36887 The naming of <tt>std::copy_exception</tt> misleads almost everyone
36888 (experts included!) to think that it is the function that copies an
36889 <tt>exception_ptr</tt>:
36892 <blockquote><pre>exception_ptr p1 = current_exception();
36893 exception_ptr p2 = copy_exception( p1 );
36894 </pre></blockquote>
36897 But this is not at all what it does. The above actually creates an
36898 <tt>exception_ptr p2</tt> that contains a copy of <tt>p1</tt>, not of
36899 the exception to which <tt>p1</tt> refers!
36902 This is, of course, all my fault; in my defence, I used <tt>copy_exception</tt>
36903 because I was unable to think of a better name.
36906 But I believe that, based on what we've seen so far, <em>any</em> other name would be better.
36909 Therefore, I propose <tt>copy_exception</tt> to be renamed to
36910 <tt>create_exception</tt>:
36913 <blockquote><pre>template<class E> exception_ptr create_exception(E e);
36914 </pre></blockquote>
36917 with the following explanatory paragraph after it:
36921 Creates an <tt>exception_ptr</tt> that refers to a copy of <tt>e</tt>.
36925 2009-05-13 Daniel adds:
36933 <blockquote><pre>make_exception_ptr
36934 </pre></blockquote>
36936 in similarity to <tt>make_pair</tt> and <tt>make_tuple</tt>, <tt>make_error_code</tt> and
36937 <tt>make_error_condition</tt>, or <tt>make_shared</tt>? Or, if a stronger symmetry to
36938 <tt>current_exception</tt> is preferred:
36941 <blockquote><pre>make_exception
36942 </pre></blockquote>
36944 We have not a single <tt>create_*</tt> function in the library, it was always
36945 <tt>make_*</tt> used.
36950 2009-05-13 Peter adds:
36955 <tt>make_exception_ptr</tt> works for me.
36959 2009-06-02 Thomas J. Gritzan adds:
36965 To avoid surprises and unwanted recursion, how about making a call to
36966 <tt>std::make_exception_ptr</tt> with an <tt>exception_ptr</tt> illegal?
36969 It might work like this:
36971 <blockquote><pre>template<class E>
36972 exception_ptr make_exception_ptr(E e);
36974 exception_ptr make_exception_ptr<exception_ptr>(exception_ptr e) = delete;
36975 </pre></blockquote>
36980 <p><b>Proposed resolution:</b></p>
36982 Change 18.8.5 [propagation]:
36986 <pre>template<class E> exception_ptr <del>copy_exception</del><ins>make_exception_ptr</ins>(E e);
36991 -11- <i>Effects:</i> <ins>Creates an <tt>exception_ptr</tt> that refers
36992 to a copy of <tt>e</tt>,</ins> as if
36995 <blockquote><pre>try {
36998 return current_exception();
37000 </pre></blockquote>
37013 <h3><a name="1131"></a>1131. C++0x does not need <tt>alignment_of</tt></h3>
37014 <p><b>Section:</b> 20.6.4.3 [meta.unary.prop] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
37015 <b>Submitter:</b> Niels Dekker <b>Opened:</b> 2009-06-01 <b>Last modified:</b> 2009-06-02</p>
37016 <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>
37017 <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>
37018 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
37019 <p><b>Discussion:</b></p>
37021 The <tt>alignment_of</tt> template is no longer necessary, now that the
37022 core language will provide <tt>alignof</tt>. Scott Meyers raised this
37023 issue at comp.std.c++,
37024 <a href="http://groups.google.com/group/comp.std.c++/browse_thread/thread/9b020306e803f08a">C++0x: alignof vs. alignment_of</a>,
37025 May 21, 2009. In a reply, Daniel Krügler pointed out that
37026 <tt>alignof</tt> was added to the working paper <i>after</i>
37027 <tt>alignment_of</tt>. So it appears that <tt>alignment_of</tt> is only
37028 part of the current Working Draft
37029 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2857.pdf">N2857</a>)
37030 because it is in TR1.
37033 Having both <tt>alignof</tt> and <tt>alignment_of</tt> would cause
37034 unwanted confusion. In general, I think TR1 functionality should not be
37035 brought into C++0x if it is entirely redundant with other C++0x language
37036 or library features.
37040 <p><b>Proposed resolution:</b></p>
37042 Remove from Header <type_traits> synopsis 20.6.2 [meta.type.synop]:
37044 <blockquote><pre><del>template <class T> struct alignment_of;</del>
37045 </pre></blockquote>
37048 Remove the first row of Table 34 ("Type property queries"), from
37049 Type properties 20.6.4.3 [meta.unary.prop]:
37053 <caption>Table 34 -- Type property queries</caption>
37055 <td><del><tt>template <class T> struct alignment_of;</tt></del></td>
37056 <td><del><tt>alignof(T)</tt>.</del><br>
37057 <del><i>Precondition:</i> <tt>T</tt> shall be a complete type, a reference
37058 type, or an array of unknown bound, but shall not be a function type or
37059 (possibly cv-qualified) <tt>void</tt>.</del>
37066 Change text in Table 41 ("Other transformations"), from Other
37067 transformations 20.6.7 [meta.trans.other], as follows:
37071 <caption>Table 41 -- Other transformations</caption>
37072 <tbody><tr><td>...</td>
37074 Align shall be equal to <tt>
37075 <del>alignment_of<T>::value</del>
37076 <ins>alignof(T)</ins>
37077 </tt> for some type <tt>T</tt> or to <i>default-alignment</i>.
37080 </tr></tbody></table>
37088 <h3><a name="1132"></a>1132. JP-30: nested exceptions</h3>
37089 <p><b>Section:</b> 18.8.6 [except.nested] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
37090 <b>Submitter:</b> Seiji Hayashida <b>Opened:</b> 2009-06-01 <b>Last modified:</b> 2009-06-02</p>
37091 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#except.nested">active issues</a> in [except.nested].</p>
37092 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#except.nested">issues</a> in [except.nested].</p>
37093 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
37094 <p><b>Discussion:</b></p>
37095 <p><b>Addresses JP 30</b></p>
37098 C++0x <tt>nested_exception</tt> cannot handle a structured exception well. The
37099 following codes show two types of tree structured exception handling.
37102 The first one is based on <tt>nested_exception</tt> in C++0x,
37103 while the second one is based on my library <tt>trickerr.h</tt> (in Japanese).
37104 <a href="http://tricklib.com/cxx/dagger/trickerr.h">http://tricklib.com/cxx/dagger/trickerr.h</a>
37107 Assume that Function <tt>A()</tt> calls two sub functions <tt>A_a()</tt> and <tt>A_b()</tt>, both might
37108 throw tree structured exceptions, and <tt>A_b()</tt> must be called even if <tt>A_a()</tt>
37109 throws an exception.
37112 List A (code of tree structured exception handling based on nested_exception
37116 <blockquote><pre>void A()
37120 std::vector<exception_ptr> exception_list;
37123 // A_a() does a similar processing as A().
37128 exception_list.push_back(current_exception());
37131 // ***The processing A() has to do even when A_a() fails. ***
37134 // A_b() does a similar processing as A().
37139 exception_list.push_back(current_exception());
37141 if (!exception_list.empty())
37143 throw exception_list;
37148 throw_with_nested(A_exception("someone error"));
37151 void print_tree_exception(exception_ptr e, const std::string & indent ="")
37153 const char * indent_unit = " ";
37154 const char * mark = "- ";
37157 rethow_exception(e);
37159 catch(const std::vector<exception_ptr> e)
37161 for(std::vector<exception_ptr>::const_iterator i = e.begin(); i!=e.end(); ++i)
37163 print_tree_exception(i, indent);
37166 catch(const std::nested_exception e)
37168 print_tree_exception(evil_i(e), indent +indent_unit);
37170 catch(const std::exception e)
37172 std::cout << indent << mark << e.what() << std::endl;
37176 std::cout << indent << mark << "unknown exception" << std::endl;
37179 int main(int, char * [])
37187 print_tree_exception(current_exception());
37189 return EXIT_SUCCESS;
37191 </pre></blockquote>
37194 List B ( code of tree structured exception handling based on <tt>trickerr.h</tt>. )
37195 "trickerr.h" (in Japanese), refer to:
37196 <a href="http://tricklib.com/cxx/dagger/trickerr.h">http://tricklib.com/cxx/dagger/trickerr.h</a>.
37199 <blockquote><pre>void A()
37201 tricklib::error_listener_type error_listener;
37202 // A_a() is like A(). A_a() can throw tree structured exception.
37205 // *** It must do process so that A_a() throws exception in A(). ***
37206 // A_b() is like A(). A_b() can throw tree structured exception.
37209 if (error_listener.has_error()) // You can write this "if block" in destructor
37210 // of class derived from error_listener_type.
37212 throw_error(new A_error("someone error",error_listener.listener_off().extract_pending_error()));
37215 void print_tree_error(const tricklib::error_type &a_error, const std::string & indent = "")
37217 const char * indent_unit = " ";
37218 const char * mark = "- ";
37220 tricklib::error_type error = a_error;
37223 std::cout << indent << mark << error->message << std::endl;
37224 if (error->children)
37226 print_tree_error(error->children, indent +indent_unit);
37228 error = error->next;
37231 int main(int, char * [])
37233 tricklib::error_thread_power error_thread_power_on; // This object is necessary per thread.
37239 catch(error_type error)
37241 print_tree_error(error);
37245 std::cout << "- unknown exception" << std::endl;
37247 return EXIT_SUCCESS;
37249 </pre></blockquote>
37255 We will focus on the method A() since the other methods, also main(), occur
37256 only once respectively.
37261 In the List A above (of the nested exception handling), it is hard to
37262 find out an active reason to use the nested exception handling at this
37263 scene. Rather, we can take a simpler description by throwing the entire
37264 exception_list directly to the top level.
37267 The code in the same example gives us a kind of redundant impression,
37268 which might have come from the fact that the try-throw-catch framework does
37269 not assume a tree structured exception handling.
37274 According to the above observation, we cannot help concluding that it is not
37275 so easy to use the nested_exception handling as a tree structured exception
37276 handling mechanism in a practical sense.
37279 This text is based on the web page below (in Japanese).
37280 <a href="http://d.hatena.ne.jp/wraith13/20081231/1230715424">http://d.hatena.ne.jp/wraith13/20081231/1230715424</a>
37284 <p><b>Proposed resolution:</b></p>
37293 <h3><a name="1133"></a>1133. Does N2844 break current specification of list::splice?</h3>
37294 <p><b>Section:</b> 23.3.3.5 [forwardlist.ops], 23.3.4.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
37295 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-09 <b>Last modified:</b> 2009-06-09</p>
37296 <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>
37297 <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>
37298 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
37299 <p><b>Discussion:</b></p>
37302 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2844.html">N2844</a>
37303 means that lvalues will no longer bind to rvalue references.
37304 Therefore, the current specification of <tt>list::splice</tt> (list
37305 operations 23.3.4.4 [list.ops]) will be a breaking change of behaviour for existing
37306 programs. That is because we changed the signature to swallow via an rvalue
37307 reference rather than the lvalue reference used in 03.
37310 Retaining this form would be safer, requiring an explicit move when splicing
37311 from lvalues. However, this will break existing programs.
37312 We have the same problem with <tt>forward_list</tt>, although without the risk of
37313 breaking programs so here it might be viewed as a positive feature.
37316 The problem signatures:
37318 <blockquote><pre>void splice_after(const_iterator position, forward_list<T,Alloc>&& x);
37319 void splice_after(const_iterator position, forward_list<T,Alloc>&& x,
37321 void splice_after(const_iterator position, forward_list<T,Alloc>&& x,
37322 const_iterator first, const_iterator last);
37324 void splice(const_iterator position, list<T,Alloc>&& x);
37325 void splice(const_iterator position, list<T,Alloc>&& x,
37327 void splice(const_iterator position, list<T,Alloc>&& x,
37328 const_iterator first, const_iterator last);
37329 </pre></blockquote>
37331 <b>Possible resolutions:</b>
37334 Option A. Add an additional (non-const) lvalue-reference
37335 overload in each case
37338 Option B. Change rvalue reference back to (non-const)
37339 lvalue-reference overload in each case
37342 Option C. Add an additional (non-const) lvalue-reference
37343 overload in just the <tt>std::list</tt> cases
37346 I think (B) would be very unfortunate, I really like the <tt>forward_list</tt>
37347 behaviour in (C) but feel (A) is needed for consistency.
37350 My actual preference would be NAD, ship with this as a breaking change as it
37351 is a more explicit interface. I don't think that will fly though!
37355 See the thread starting with c++std-lib-23725 for more discussion.
37359 <p><b>Proposed resolution:</b></p>
37366 <h3><a name="1134"></a>1134. Redundant specification of stdint.h, fenv.h, tgmath.h, and maybe complex.h</h3>
37367 <p><b>Section:</b> 18.4.2 [stdinth], 26.3.2 [fenv], 26.8 [c.math], 26.4.11 [cmplxh] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
37368 <b>Submitter:</b> Robert Klarer <b>Opened:</b> 2009-05-26 <b>Last modified:</b> 2009-06-14</p>
37369 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
37370 <p><b>Discussion:</b></p>
37372 This is probably editorial.
37375 The following items should be removed from the draft, because they're
37376 redundant with Annex D, and they arguably make some *.h headers
37380 18.4.2 [stdinth] (regarding <tt><stdint.h></tt>)
37383 26.3.2 [fenv] (regarding <tt><fenv.h></tt>
37386 Line 3 of 26.8 [c.math] (regarding <tt><tgmath.h></tt>)
37389 26.4.11 [cmplxh] (regarding <tt><complex.h></tt>, though the note in this subclause is not redundant)
37393 2009-06-10 Ganesh adds:
37398 While searching for <tt>stdint</tt> in the CD, I found that <tt><stdint.h></tt> is also
37399 mentioned in 3.9.1 [basic.fundamental] /5. It guess it should refer to
37400 <tt><cstdint></tt> instead.
37404 <p><b>Proposed resolution:</b></p>
37406 Remove the section 18.4.2 [stdinth].
37409 Remove the section 26.3.2 [fenv].
37412 Remove 26.8 [c.math], p3:
37416 <del>-3- The header <tt><tgmath.h></tt> effectively includes the headers <tt><complex.h></tt>
37417 and <tt><math.h></tt>.</del>
37420 Remove the section 26.4.11 [cmplxh].
37428 <h3><a name="1135"></a>1135. <tt>exception_ptr</tt> should support contextual conversion to <tt>bool</tt></h3>
37429 <p><b>Section:</b> 18.8.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
37430 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-06-06 <b>Last modified:</b> 2009-06-09</p>
37431 <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>
37432 <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>
37433 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
37434 <p><b>Discussion:</b></p>
37437 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2857.pdf">N2857</a>
37438 18.8.5 [propagation]/5, the implementation-defined type
37439 <tt>exception_ptr</tt> does provide the following ways to check whether
37440 it is a null value:
37442 <blockquote><pre>void f(std::exception_ptr p) {
37445 p == exception_ptr();
37447 </pre></blockquote>
37449 This is rather cumbersome way of checking for the null value
37450 and I suggest to require support for evaluation in a boolean
37454 <blockquote><pre>void g(std::exception_ptr p) {
37458 </pre></blockquote>
37461 <p><b>Proposed resolution:</b></p>
37463 In section 18.8.5 [propagation] insert a new paragraph between p.5 and p.6:
37468 An object <tt>e</tt> of type <tt>exception_ptr</tt> can be contextually converted to <tt>bool</tt>.
37469 The effect shall be as if <tt>e != exception_ptr()</tt> had been evaluated in place
37470 of <tt>e</tt>. There shall be no implicit conversion to arithmetic type, to
37471 enumeration type or to pointer type.
37480 <h3><a name="1136"></a>1136. Incomplete specification of <tt>nested_exception::rethrow_nested()</tt></h3>
37481 <p><b>Section:</b> 18.8.6 [except.nested] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
37482 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-06-06 <b>Last modified:</b> 2009-06-09</p>
37483 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#except.nested">active issues</a> in [except.nested].</p>
37484 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#except.nested">issues</a> in [except.nested].</p>
37485 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
37486 <p><b>Discussion:</b></p>
37488 It was recently mentioned in a newsgroup article
37489 <a href="http://groups.google.de/group/comp.std.c++/msg/f82022aff68edf3d">http://groups.google.de/group/comp.std.c++/msg/f82022aff68edf3d</a>
37490 that the specification of the member function <tt>rethrow_nested()</tt> of the
37491 class <tt>nested_exception</tt> is incomplete, specifically it remains unclear
37492 what happens, if member <tt>nested_ptr()</tt> returns a null value. In
37493 18.8.6 [except.nested] we find only the following paragraph related to that:
37495 <blockquote><pre>void rethrow_nested() const; // [[noreturn]]
37498 -4- <i>Throws:</i> the stored exception captured by this <tt>nested_exception</tt> object.
37502 This is a problem, because it is possible to create an object of
37503 <tt>nested_exception</tt> with exactly such a state, e.g.
37505 <blockquote><pre>#include <exception>
37506 #include <iostream>
37509 std::nested_exception e; // OK, calls current_exception() and stores it's null value
37510 e.rethrow_nested(); // ?
37511 std::cout << "A" << std::endl;
37514 std::cout << "B" << std::endl;
37516 </pre></blockquote>
37518 I suggest to follow the proposal of the reporter, namely to invoke
37519 <tt>terminate()</tt> if <tt>nested_ptr()</tt> return a null value of <tt>exception_ptr</tt> instead
37520 of relying on the fallback position of undefined behavior. This would
37521 be consistent to the behavior of a <tt>throw;</tt> statement when no
37522 exception is being handled.
37526 <p><b>Proposed resolution:</b></p>
37528 Change around 18.8.6 [except.nested]/4 as indicated:
37532 -4- <i>Throws:</i> the stored exception captured by this <tt>nested_exception</tt>
37533 object<ins>, if <tt>nested_ptr() != nullptr</tt></ins>
37536 <ins>- <i>Remarks:</i> If <tt>nested_ptr() == nullptr</tt>, <tt>terminate()</tt>
37537 shall be called.</ins>
37546 <h3><a name="1137"></a>1137. Return type of <tt>conj</tt> and <tt>proj</tt></h3>
37547 <p><b>Section:</b> 26.4.9 [cmplx.over] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
37548 <b>Submitter:</b> Marc Steinbach <b>Opened:</b> 2009-06-11 <b>Last modified:</b> 2009-06-14</p>
37549 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#cmplx.over">issues</a> in [cmplx.over].</p>
37550 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
37551 <p><b>Discussion:</b></p>
37553 In clause 1, the Working Draft
37554 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2857.pdf">N2857</a>)
37555 specifies overloads of the
37558 <blockquote><pre>arg, conj, imag, norm, proj, real
37559 </pre></blockquote>
37561 for non-complex arithmetic types (<tt>float</tt>, <tt>double</tt>,
37562 <tt>long double</tt>, and integers).
37563 The only requirement (clause 2) specifies type promotion of arguments.
37566 I strongly suggest to add the following requirement on the return types:
37569 All the specified overloads must return real (i.e., non-complex) values,
37570 specifically, the nested <tt>value_type</tt> of promoted arguments.
37574 (This has no effect on <tt>arg</tt>, <tt>imag</tt>, <tt>norm</tt>, <tt>real</tt>:
37575 they are real-valued anyway.)
37577 <p><b>Rationale:</b></p>
37579 Mathematically, <tt>conj()</tt> and <tt>proj()</tt>, like the transcendental functions, are
37580 complex-valued in general but map the (extended) real line to itself.
37581 In fact, both functions act as identity on the reals.
37582 A typical user will expect <tt>conj()</tt> and <tt>proj()</tt> to preserve this essential
37583 mathematical property in the same way as <tt>exp()</tt>, <tt>sin()</tt>, etc.
37584 A typical use of <tt>conj()</tt>, e.g., is the generic scalar product of n-vectors:
37587 <blockquote><pre>template<typename T>
37589 scalar_product(size_t n, T const* x, T const* y) {
37591 for (size_t i = 0; i < n; ++i)
37592 result += std::conj(x[i]) * y[i];
37595 </pre></blockquote>
37597 This will work equally well for real and complex floating-point types <tt>T</tt> if
37598 <tt>conj()</tt> returns <tt>T</tt>. It will not work with real types if <tt>conj()</tt>
37599 returns complex values.
37602 Instead, the implementation of <tt>scalar_product</tt> becomes either less efficient
37603 and less useful (if a complex result is always returned), or unnecessarily
37604 complicated (if overloaded versions with proper return types are defined).
37605 In the second case, <tt>conj()</tt> is not used with real arguments.
37608 Any use of <tt>conj()</tt> I can think of would benefit from the proposed return type
37609 requirement, in a similar way.
37610 It will not harm use cases where a complex value is expected, because of
37611 implicit conversion to complex.
37612 Without the proposed return type guarantee, I find an overloaded <tt>conj()</tt> not
37613 only useless but actually troublesome.
37616 I believe that the same applies to <tt>proj()</tt>, althought up to now I had no need
37622 <p><b>Proposed resolution:</b></p>
37624 Insert a new paragraph after 26.4.9 [cmplx.over]/2:
37629 All of the specified overloads shall have a return type which is the nested <tt>value_type</tt> of
37630 the promoted arguments.
37639 <h3><a name="1138"></a>1138. unusal return value for operator+</h3>
37640 <p><b>Section:</b> 21.4.8.1 [string::op+] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
37641 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-06-12 <b>Last modified:</b> 2009-06-15</p>
37642 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
37643 <p><b>Discussion:</b></p>
37645 Many of the <tt>basic_string operator+</tt> overloads return an rvalue-reference. Is
37646 that really intended?
37649 I'm considering it might be a mild performance tweak to avoid making
37650 un-necessary copies of a cheaply movable type, but it opens risk to dangling
37651 references in code like:
37654 <blockquote><pre>auto && s = string{"x"} + string{y};
37655 </pre></blockquote>
37658 and I'm not sure about:
37661 <blockquote><pre>auto s = string{"x"} + string{y};
37662 </pre></blockquote>
37665 <p><b>Proposed resolution:</b></p>
37667 Strike the <tt>&&</tt> from the return type in the following function
37673 21.3 [string.classes] p2 Header Synopsis
37676 <blockquote><pre>template<class charT, class traits, class Allocator>
37677 basic_string<charT,traits,Allocator><del>&&</del>
37678 operator+(basic_string<charT,traits,Allocator>&& lhs,
37679 const basic_string<charT,traits,Allocator>& rhs);
37681 template<class charT, class traits, class Allocator>
37682 basic_string<charT,traits,Allocator><del>&&</del>
37683 operator+(const basic_string<charT,traits,Allocator>& lhs,
37684 basic_string<charT,traits,Allocator>&& rhs);
37686 template<class charT, class traits, class Allocator>
37687 basic_string<charT,traits,Allocator><del>&&</del>
37688 operator+(basic_string<charT,traits,Allocator>&& lhs,
37689 basic_string<charT,traits,Allocator>&& rhs);
37692 template<class charT, class traits, class Allocator>
37693 basic_string<charT,traits,Allocator><del>&&</del>
37694 operator+(const charT* lhs,
37695 basic_string<charT,traits,Allocator>&& rhs);
37697 template<class charT, class traits, class Allocator>
37698 basic_string<charT,traits,Allocator><del>&&</del>
37699 operator+(charT lhs, basic_string<charT,traits,Allocator>&& rhs);
37701 template<class charT, class traits, class Allocator>
37702 basic_string<charT,traits,Allocator><del>&&</del>
37703 operator+(basic_string<charT,traits,Allocator>&& lhs,
37706 template<class charT, class traits, class Allocator>
37707 basic_string<charT,traits,Allocator><del>&&</del>
37708 operator+(basic_string<charT,traits,Allocator>&& lhs, charT rhs);
37709 </pre></blockquote>
37712 21.4.8.1 [string::op+]
37715 <blockquote><pre>template<class charT, class traits, class Allocator>
37716 basic_string<charT,traits,Allocator><del>&&</del>
37717 operator+(basic_string<charT,traits,Allocator>&& lhs,
37718 const basic_string<charT,traits,Allocator>& rhs);
37720 template<class charT, class traits, class Allocator>
37721 basic_string<charT,traits,Allocator><del>&&</del>
37722 operator+(const basic_string<charT,traits,Allocator>& lhs,
37723 basic_string<charT,traits,Allocator>&& rhs);
37725 template<class charT, class traits, class Allocator>
37726 basic_string<charT,traits,Allocator><del>&&</del>
37727 operator+(basic_string<charT,traits,Allocator>&& lhs,
37728 basic_string<charT,traits,Allocator>&& rhs);
37731 template<class charT, class traits, class Allocator>
37732 basic_string<charT,traits,Allocator><del>&&</del>
37733 operator+(const charT* lhs,
37734 basic_string<charT,traits,Allocator>&& rhs);
37736 template<class charT, class traits, class Allocator>
37737 basic_string<charT,traits,Allocator><del>&&</del>
37738 operator+(charT lhs, basic_string<charT,traits,Allocator>&& rhs);
37740 template<class charT, class traits, class Allocator>
37741 basic_string<charT,traits,Allocator><del>&&</del>
37742 operator+(basic_string<charT,traits,Allocator>&& lhs,
37745 template<class charT, class traits, class Allocator>
37746 basic_string<charT,traits,Allocator><del>&&</del>
37747 operator+(basic_string<charT,traits,Allocator>&& lhs, charT rhs);
37748 </pre></blockquote>
37758 <h3><a name="1139"></a>1139. Response to US 93</h3>
37759 <p><b>Section:</b> 30 [thread] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
37760 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2009-06-15 <b>Last modified:</b> 2009-06-15</p>
37761 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread">active issues</a> in [thread].</p>
37762 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread">issues</a> in [thread].</p>
37763 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
37764 <p><b>Discussion:</b></p>
37766 <p><b>Addresses US 93, JP 79, UK 333, JP 81</b></p>
37769 The thread chapter is not concept enabled.
37774 <p><b>Proposed resolution:</b></p>
37781 <h3><a name="1140"></a>1140. Response to US 84</h3>
37782 <p><b>Section:</b> 26 [numerics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
37783 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2009-06-15 <b>Last modified:</b> 2009-06-15</p>
37784 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#numerics">active issues</a> in [numerics].</p>
37785 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#numerics">issues</a> in [numerics].</p>
37786 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
37787 <p><b>Discussion:</b></p>
37789 <p><b>Addresses US 84</b></p>
37792 The numerics chapter is not concept enabled.
37796 The portion of this comment dealing with random numbers was resolved by
37797 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2836.pdf">N2836</a>,
37798 which was accepted in Summit.
37803 <p><b>Proposed resolution:</b></p>
37810 <h3><a name="1141"></a>1141. Response to US 85</h3>
37811 <p><b>Section:</b> 27 [input.output] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
37812 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2009-06-15 <b>Last modified:</b> 2009-06-15</p>
37813 <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>
37814 <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>
37815 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
37816 <p><b>Discussion:</b></p>
37818 <p><b>Addresses US 85, JP 67, JP 68, JP 69, JP 72</b></p>
37821 The input/output chapter is not concept enabled.
37826 <p><b>Proposed resolution:</b></p>
37833 <h3><a name="1142"></a>1142. Response to US 86</h3>
37834 <p><b>Section:</b> 28 [re] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
37835 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2009-06-15 <b>Last modified:</b> 2009-06-15</p>
37836 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#re">active issues</a> in [re].</p>
37837 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re">issues</a> in [re].</p>
37838 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
37839 <p><b>Discussion:</b></p>
37841 <p><b>Addresses US 86, UK 309, UK 310</b></p>
37844 The regular expressions chapter is not concept enabled.
37849 <p><b>Proposed resolution:</b></p>
37856 <h3><a name="1143"></a>1143. Response to US 87</h3>
37857 <p><b>Section:</b> 29 [atomics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
37858 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2009-06-15 <b>Last modified:</b> 2009-06-15</p>
37859 <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>
37860 <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>
37861 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
37862 <p><b>Discussion:</b></p>
37864 <p><b>Addresses US 87, UK 311</b></p>
37867 The atomics chapter is not concept enabled.
37871 Needs to also consider issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#923">923</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#924">924</a>.
37876 <p><b>Proposed resolution:</b></p>