<HTML>
<HEAD>
<META http-equiv="Content-Type" content="text/html; charset=us-ascii">
<TITLE>
    C++ FCD Comment Status
   </TITLE>
</HEAD>
<BODY>
<TABLE align="right" cellspacing="0" cellpadding="0">
<TR>
<TD align="right">Document number:</TD>
<TD>&#160;PL22.16 10/0214 = WG21 N3224</TD>
</TR>
<TR>
<TD align="right">Date:</TD>
<TD>&#160;2010-11-29</TD>
</TR>
<TR>
<TD align="right" valign="top">Reply to:</TD>
<TD>
      &#160;William M. Miller<BR>
      &#160;Edison Design Group, Inc.<BR>
      &#160;<A href="mailto://wmm@edg.com">wmm@edg.com</A><BR><BR>
      &#160;Beman Dawes<BR>
      &#160;<A href="mailto://bdawes@acm.org">bdawes@acm.org</A></TD>
</TR>
</TABLE><BR><BR><BR><BR><BR><BR><BR><BR><BR><CENTER>
<H1>
     C++ FCD Comment Status
    </H1>
<H2>Rev. 4</H2>
</CENTER>
<P>
    This document summarizes the status of WG21 as of the conclusion
    of the November, 2010 (Batavia) meeting in addressing National Body
    comments on Final Committee Draft document N3092.</P>
<P>
    In
    total, 573 comments
    were received. To date,
    300
    have been accepted as proposed,
    93
    have been accepted with modifications,
    101
    have been rejected, and
    79
    remain to be addressed. The detailed breakdown:
   </P>
<UL><UL>
<TABLE>
<THEAD>
<TR><TH></TH><TH>Unresolved</TH><TH>Accepted</TH><TH>Modified</TH><TH>Rejected</TH><TH>Total</TH></TR>
</THEAD>
<TBODY>
<TR>
<TD><B>CWG</B></TD>
<TD align="center">5</TD>
<TD align="center">90</TD>
<TD align="center">8</TD>
<TD align="center">42</TD>
<TD align="center">145</TD>
</TR>
<TR>
<TD><B>LWG</B></TD>
<TD align="center">51</TD>
<TD align="center">38</TD>
<TD align="center">75</TD>
<TD align="center">38</TD>
<TD align="center">202</TD>
</TR>
<TR>
<TD><B>editor</B></TD>
<TD align="center">19</TD>
<TD align="center">168</TD>
<TD align="center">10</TD>
<TD align="center">20</TD>
<TD align="center">217</TD>
</TR>
</TBODY>
</TABLE>
</UL></UL>
<P>
    This document consists of three tables.  <A href="#TOC">The
    first</A> is a table of contents, listing each issue by National
    Body and comment number and giving its current status.  <A href="#OPEN">The second</A> is a list of all as-yet unresolved
    comments, sorted by the responsible party. <A href="#RR">The
    third</A> is a comprehensive listing of all the comments received
    in the same order and with roughly the same organization as in
    document N3102; the &#8220;Disposition&#8221; field gives the
    response, as well as any explanatory comments provided by the
    responsible party.
   </P>
<HR><A NAME="TOC"></A><H3><U>SORTED LISTING OF COMMENTS:</U></H3>
<P>In the following table, the &#8220;Date&#8221; field represents
    the date on which the Committee affirmed the listed
    disposition.</P>
<TABLE border="1" cellspacing="0" cellpadding="4" frame="box">
<THEAD>
<TR>
<TH>ID</TH>
<TH>Responsible</TH>
<TH>Disposition</TH>
<TH>Date</TH>
<TH>Issue</TH>
<TH>Document</TH>
</TR>
</THEAD>
<TBODY>
<TR>
<TD><A HREF="
          #CA1">CA 1</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1461">1461</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CA2">CA 2</A></TD>
<TD></TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CA3">CA 3</A></TD>
<TD>CWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CA4">CA 4</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1449">1449</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CA5">CA 5</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1218">1218</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CA6">CA 6</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1162">1162</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CA7">CA 7</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1157">1157</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CA8">CA 8</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3196.html">
          N3196</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CA9">CA 9</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1442">1442</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3196.html">
          N3196</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CA10">CA 10</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>2010-08-07&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CA11">CA 11</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3196.html">
          N3196</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CA12">CA 12</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1176">1176</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CA13">CA 13</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3196.html">
          N3196</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CA14">CA 14</A></TD>
<TD>CWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3196.html">
          N3196</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CA15">CA 15</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1177">1177</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3196.html">
          N3196</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CA16">CA 16</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CA17">CA 17</A></TD>
<TD>editor</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CA18">CA 18</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3196.html">
          N3196</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CA19">CA 19</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3196.html">
          N3196</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CA20">CA 20</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3196.html">
          N3196</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CA21">CA 21</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1459">1459</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CA22">CA 22</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3196.html">
          N3196</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CA23">CA 23</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3193.html">
          N3193</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CA24">CA 24</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1105">1105</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3146.html">
          N3146</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CH1">CH 1</A></TD>
<TD></TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CH2">CH 2</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3196.html">
          N3196</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CH3">CH 3</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CH4">CH 4</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1062">1062</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CH5">CH 5</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CH6">CH 6</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CH7">CH 7</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CH8">CH 8</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CH9">CH 9</A></TD>
<TD>CWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1147">1147</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3204.html">
          N3204</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CH10">CH 10</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CH11">CH 11</A></TD>
<TD>editor</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CH12">CH 12</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CH13">CH 13</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CH14">CH 14</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CH15">CH 15</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1421, 1350">1421, 1350</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CH16">CH 16</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1351">1351</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3148.html">
          N3148</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CH17">CH 17</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1352">1352</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3195.html">
          N3195</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CH18">CH 18</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1353">1353</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CH19">CH 19</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1364">1364</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CH20">CH 20</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>2010-08-07&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CH21">CH 21</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1412">1412</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3191.html">
          N3191</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CH22">CH 22</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1455, 1454">1455, 1454</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3193.html">
          N3193</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CH23">CH 23</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1475">1475</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CH24">CH 24</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1486">1486</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CH25">CH 25</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1487">1487</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CH26">CH 26</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1489">1489</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3197.html">
          N3197</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CH27">CH 27</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1490">1490</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3197.html">
          N3197</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CH28">CH 28</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1496">1496</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3191.html">
          N3191</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CH29">CH 29</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1498">1498</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3191.html">
          N3191</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CH30">CH 30</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1497">1497</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CH31">CH 31</A></TD>
<TD>editor</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CH32">CH 32</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-08-07&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1500">1500</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CH33">CH 33</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CH34">CH 34</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CH35">CH 35</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1503">1503</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CH36">CH 36</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1513">1513</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/N3188.html">
          N3188</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #DE1">DE 1</A></TD>
<TD></TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #DE2">DE 2</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #DE3">DE 3</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1106">1106</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #DE4">DE 4</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1113">1113</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #DE5">DE 5</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #DE7">DE 7</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #DE8">DE 8</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1125">1125</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3218.html">
          N3218</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #DE9">DE 9</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1110">1110</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #DE10">DE 10</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1138">1138</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #DE11">DE 11</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1148">1148</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #DE12">DE 12</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1155">1155</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #DE13">DE 13</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1169">1169</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #DE14">DE 14</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1366">1366</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/N3189.html">
          N3189</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #DE15">DE 15</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1378">1378</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3140.html">
          N3140</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #DE16">DE 16</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1380">1380</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3140.html">
          N3140</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #DE17">DE 17</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1390">1390</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3142.htm">
          N3142</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #DE18">DE 18</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1391">1391</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3142.htm">
          N3142</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #DE19">DE 19</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-08-07&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1394">1394</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3047.html">
          N3047</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #DE20">DE 20</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1411">1411</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3191.html">
          N3191</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #DE21">DE 21</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-08-07&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1416">1416</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #DE22">DE 22</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1421">1421</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #DE23">DE 23</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-08-07&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1483">1483</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #ES1">ES 1</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>2010-08-07&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #ES2">ES 2</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>2010-08-07&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #ES3">ES 3</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-08-07&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FI1">FI 1</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1135">1135</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FI2">FI 2</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1136">1136</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FI3">FI 3</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1137">1137</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FI4">FI 4</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1145">1145</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FI5">FI 5</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1149">1149</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FI6">FI 6</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1012">1012</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FI7">FI 7</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FI8">FI 8</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FI9">FI 9</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FI10">FI 10</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-08-07&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#924">924</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FI11">FI 11</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FI12">FI 12</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>2010-08-07&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FI13">FI 13</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FI14">FI 14</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FI15">FI 15</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FI16">FI 16</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FI17">FI 17</A></TD>
<TD>CWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1123">1123</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3204.html">
          N3204</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FI18">FI 18</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>2010-11-132010-08-07&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3142.htm">
          N3142</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FI19">FI 19</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1118">1118</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB1">GB 1</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB2">GB 2</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB3">GB 3</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB4">GB 4</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB5">GB 5</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB6">GB 6</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1102">1102</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB7">GB 7</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1173">1173</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB8">GB 8</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3196.html">
          N3196</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB9">GB 9</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1176">1176</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB10">GB 10</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3196.html">
          N3196</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB11">GB 11</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3196.html">
          N3196</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB12">GB 12</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3196.html">
          N3196</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB13">GB 13</A></TD>
<TD></TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB14">GB 14</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB15">GB 15</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3196.html">
          N3196</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB16">GB 16</A></TD>
<TD>editor</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB17">GB 17</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB18">GB 18</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1114">1114</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB19">GB 19</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB20">GB 20</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB21">GB 21</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB22">GB 22</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1120">1120</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB23">GB 23</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB24">GB 24</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1122">1122</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB25">GB 25</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1126">1126</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB26">GB 26</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1127">1127</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB27">GB 27</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB28">GB 28</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB29">GB 29</A></TD>
<TD>CWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1129">1129</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB30">GB 30</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB31">GB 31</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1115">1115</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3190.html">
          N3190</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB32">GB 32</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1132">1132</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB33">GB 33</A></TD>
<TD>CWG</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1130">1130</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB34">GB 34</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB35">GB 35</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB36">GB 36</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB37">GB 37</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1138">1138</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB38">GB 38</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#675">675</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB39">GB 39</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1146">1146</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB40">GB 40</A></TD>
<TD>CWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1147">1147</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3204.html">
          N3204</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB41">GB 41</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1146">1146</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB42">GB 42</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB43">GB 43</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1160">1160</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB44">GB 44</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1161">1161</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB45">GB 45</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1166">1166</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB46">GB 46</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1167">1167</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB47">GB 47</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1168">1168</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB48">GB 48</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB49">GB 49</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB50">GB 50</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1355">1355</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3142.htm">
          N3142</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB51">GB 51</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1356">1356</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3142.htm">
          N3142</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB52">GB 52</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1354">1354</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB53">GB 53</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1357">1357</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3110.htm">
          N3110</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB54">GB 54</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB55">GB 55</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1358">1358</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB56">GB 56</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1359">1359</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB57">GB 57</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-08-07&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1360">1360</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB58">GB 58</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1361">1361</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB59">GB 59</A></TD>
<TD>editor</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB60">GB 60</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1344">1344</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3148.html">
          N3148</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB61">GB 61</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1345">1345</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB62">GB 62</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1346">1346</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3195.html">
          N3195</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB63">GB 63</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1347">1347</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3155.html">
          N3155</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB64">GB 64</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1348">1348</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB65">GB 65</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1349">1349</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB66">GB 66</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB68">GB 68</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-08-07&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1363">1363</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB69">GB 69</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB70">GB 70</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB71">GB 71</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1365">1365</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/N3189.html">
          N3189</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB72">GB 72</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-08-07&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1367">1367</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB73">GB 73</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1368">1368</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB74">GB 74</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1369">1369</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB75">GB 75</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1371">1371</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB76">GB 76</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-08-07&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1372">1372</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB77">GB 77</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB78">GB 78</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>2010-08-07&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB79">GB 79</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1373">1373</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB80">GB 80</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>2010-08-07&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB81">GB 81</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB82">GB 82</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB84">GB 84</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB85">GB 85</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-08-07&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1381">1381</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB86">GB 86</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>2010-08-07&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB87">GB 87</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-08-07&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1387">1387</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB88">GB 88</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1385">1385</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB89">GB 89</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1389">1389</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/N3210.pdf">
          N3210</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB90">GB 90</A></TD>
<TD>editor</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB91">GB 91</A></TD>
<TD>editor</TD>
<TD>rejected&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3142.htm">
          N3142</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB92">GB 92</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1393">1393</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3142.htm">
          N3142</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB93">GB 93</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>2010-08-07&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB94">GB 94</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB95">GB 95</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1397">1397</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3198.html">
          N3198</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB96">GB 96</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1398">1398</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB97">GB 97</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>2010-08-07&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB98">GB 98</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB99">GB 99</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1401">1401</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB100">GB 100</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-08-07&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1402">1402</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB101">GB 101</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB102">GB 102</A></TD>
<TD>editor</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB103">GB 103</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1408">1408</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB104">GB 104</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB105">GB 105</A></TD>
<TD>editor</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB106">GB 106</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>2010-08-07&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB107">GB 107</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1410">1410</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3191.html">
          N3191</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB108">GB 108</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB109">GB 109</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1414">1414</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB110">GB 110</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>2010-08-07&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB111">GB 111</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB112">GB 112</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-08-07&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1417">1417</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB113">GB 113</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1418">1418</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB114">GB 114</A></TD>
<TD>editor</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB115">GB 115</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1420">1420</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB116">GB 116</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB117">GB 117</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB118">GB 118</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1422">1422</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB119">GB 119</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1433">1433</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB120">GB 120</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1435">1435</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB121">GB 121</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1436">1436</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB122">GB 122</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1442, 1443">1442, 1443</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB123">GB 123</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1414, 1444">1414, 1444</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB124">GB 124</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1448">1448</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB125">GB 125</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1452">1452</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB126">GB 126</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1453">1453</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3158.html">
          N3158</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB127">GB 127</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1450">1450</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB128">GB 128</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1455, 1454">1455, 1454</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3193.html">
          N3193</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB129">GB 129</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1456">1456</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB130">GB 130</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1457">1457</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB131">GB 131</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1458">1458</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB132">GB 132</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1462">1462</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3193.html">
          N3193</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB133">GB 133</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1469">1469</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3193.html">
          N3193</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB134">GB 134</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB135">GB 135</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1477">1477</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB136">GB 136</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1478">1478</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB137">GB 137</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1480">1480</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB138">GB 138</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1481">1481</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3197.html">
          N3197</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB139">GB 139</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB140">GB 140</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB141">GB 141</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB142">GB 142</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1516">1516</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #ITTF1">ITTF 1</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #ITTF2">ITTF 2</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #ITTF3">ITTF 3</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #ITTF4">ITTF 4</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #ITTF5">ITTF 5</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #ITTF6">ITTF 6</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #ITTF7">ITTF 7</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP1">JP 1</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1117">1117</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP2">JP 2</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1124">1124</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP3">JP 3</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-08-07&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1399">1399</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP4">JP 4</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-08-07&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1400">1400</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP5">JP 5</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1406">1406</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP6">JP 6</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-08-07&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1423">1423</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP7">JP 7</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-08-07&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP8">JP 8</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-08-07&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1425">1425</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP9">JP 9</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-08-07&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1426">1426</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP10">JP 10</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-08-07&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1427">1427</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP11">JP 11</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-08-07&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1428">1428</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP12">JP 12</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-08-07&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1429">1429</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP13">JP 13</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-08-07&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1430">1430</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP14">JP 14</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>2010-08-07&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP15">JP 15</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP16">JP 16</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP17">JP 17</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP18">JP 18</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP19">JP 19</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP20">JP 20</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP21">JP 21</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP22">JP 22</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP23">JP 23</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP24">JP 24</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP25">JP 25</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP26">JP 26</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP27">JP 27</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP28">JP 28</A></TD>
<TD>editor</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP29">JP 29</A></TD>
<TD>editor</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP30">JP 30</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP31">JP 31</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP32">JP 32</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1395">1395</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP33">JP 33</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP34">JP 34</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP35">JP 35</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP36">JP 36</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP37">JP 37</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP38">JP 38</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP39">JP 39</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP40">JP 40</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP41">JP 41</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP42">JP 42</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP43">JP 43</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP44">JP 44</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP45">JP 45</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP46">JP 46</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP47">JP 47</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP48">JP 48</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP49">JP 49</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP50">JP 50</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP51">JP 51</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP52">JP 52</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP53">JP 53</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP54">JP 54</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP55">JP 55</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP56">JP 56</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP57">JP 57</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP58">JP 58</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP59">JP 59</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP60">JP 60</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP61">JP 61</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP62">JP 62</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP63">JP 63</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP64">JP 64</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP65">JP 65</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP67">JP 67</A></TD>
<TD>editor</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP68">JP 68</A></TD>
<TD>editor</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP69">JP 69</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP70">JP 70</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP71">JP 71</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP72">JP 72</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP73">JP 73</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP74">JP 74</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP75">JP 75</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP76">JP 76</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP77">JP 77</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP78">JP 78</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP79">JP 79</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP80">JP 80</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP81">JP 81</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP82">JP 82</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP83">JP 83</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP84">JP 84</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP85">JP 85</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-08-07&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1403">1403</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP86">JP 86</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP87">JP 87</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP88">JP 88</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP89">JP 89</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP90">JP 90</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP91">JP 91</A></TD>
<TD>editor</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP92">JP 92</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP93">JP 93</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP94">JP 94</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP95">JP 95</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP96">JP 96</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP97">JP 97</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP98">JP 98</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP99">JP 99</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP100">JP 100</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP101">JP 101</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP102">JP 102</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP103">JP 103</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP104">JP 104</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP105">JP 105</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP106">JP 106</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP107">JP 107</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP108">JP 108</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP109">JP 109</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #JP110">JP 110</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #RU1">RU 1</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #RU2">RU 2</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #RU3">RU 3</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #RU4">RU 4</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #RU5">RU 5</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US1">US 1</A></TD>
<TD></TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US2">US 2</A></TD>
<TD></TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US3">US 3</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/N3209.htm">
          N3209</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US4">US 4</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US5">US 5</A></TD>
<TD>editor</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US6">US 6</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US7">US 7</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US8">US 8</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US9">US 9</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3196.html">
          N3196</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US10">US 10</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3196.html">
          N3196</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US11">US 11</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3196.html">
          N3196</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US12">US 12</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3196.html">
          N3196</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US13">US 13</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1103">1103</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US14">US 14</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1103">1103</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US15">US 15</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1104">1104</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US16">US 16</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US17">US 17</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1107">1107</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US18">US 18</A></TD>
<TD>CWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1108">1108</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US19">US 19</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1109">1109</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3214.html">
          N3214</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US20">US 20</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US21">US 21</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US22">US 22</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1110">1110</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US23">US 23</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1111">1111</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US24">US 24</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1112">1112</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US25">US 25</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1115">1115</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US26">US 26</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US27">US 27</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1116">1116</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US28">US 28</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US29">US 29</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#974">974</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US30">US 30</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#975">975</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US31">US 31</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1022">1022</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US32">US 32</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1119">1119</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US33">US 33</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1121">1121</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US34">US 34</A></TD>
<TD></TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US35">US 35</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US36">US 36</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US37">US 37</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US38">US 38</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3196.html">
          N3196</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US39">US 39</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1128">1128</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US40">US 40</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1130">1130</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US41">US 41</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1131">1131</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US42">US 42</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US43">US 43</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US44">US 44</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1133">1133</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3206.html">
          N3206</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US45">US 45</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US46">US 46</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US47">US 47</A></TD>
<TD>CWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1134">1134</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US48">US 48</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1138">1138</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US49">US 49</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1139">1139</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US50">US 50</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1140">1140</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US51">US 51</A></TD>
<TD>CWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1141">1141</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US52">US 52</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1142">1142</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US53">US 53</A></TD>
<TD>CWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1143">1143</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US54">US 54</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US55">US 55</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US56">US 56</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1144">1144</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US57">US 57</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US58">US 58</A></TD>
<TD>editor</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US59">US 59</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US60">US 60</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US61">US 61</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US62">US 62</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1051">1051</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US63">US 63</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1064">1064</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US64">US 64</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1066">1066</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US65">US 65</A></TD>
<TD>CWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1150">1150</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US66">US 66</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1151">1151</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US67">US 67</A></TD>
<TD>CWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1152">1152</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US68">US 68</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1153">1153</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US69">US 69</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1154">1154</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US70">US 70</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1156">1156</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US71">US 71</A></TD>
<TD></TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US72">US 72</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US73">US 73</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1158">1158</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US74">US 74</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1159">1159</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US75">US 75</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US76">US 76</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1163">1163</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US77">US 77</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1164">1164</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US78">US 78</A></TD>
<TD>CWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1165">1165</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US79">US 79</A></TD>
<TD>CWG</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US80">US 80</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1347">1347</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3155.html">
          N3155</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US81">US 81</A></TD>
<TD>editor</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US82">US 82</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1362">1362</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US83">US 83</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US84">US 84</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1370">1370</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US85">US 85</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1374">1374</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US86">US 86</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US87">US 87</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1375">1375</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US88">US 88</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1376">1376</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US89">US 89</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US90">US 90</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1377">1377</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3143.html">
          N3143</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US91">US 91</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1377">1377</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3143.html">
          N3143</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US92">US 92</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>2010-08-07&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US93">US 93</A></TD>
<TD></TD>
<TD>rejected&#160;
       </TD>
<TD>2010-08-07&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US94">US 94</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US95">US 95</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1379">1379</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3140.html">
          N3140</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US96">US 96</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1382">1382</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3140.html">
          N3140</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US97">US 97</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1383">1383</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3140.html">
          N3140</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US98">US 98</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-08-07&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1384">1384</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US99">US 99</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-08-07&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1386">1386</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US100">US 100</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-08-07&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1388">1388</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US101">US 101</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>2010-08-07&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US102">US 102</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1392">1392</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3123.html">
          N3123</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US103">US 103</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>2010-08-07&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US104">US 104</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1396">1396</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US105">US 105</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>2010-08-07&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US106">US 106</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1404">1404</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US107">US 107</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-08-07&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1405">1405</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US108">US 108</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-08-07&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1407">1407</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3109.html">
          N3109</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US109">US 109</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US110">US 110</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>2010-08-07&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US111">US 111</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1409">1409</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3191.html">
          N3191</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US112">US 112</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1413">1413</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US113">US 113</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>2010-08-07&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US114">US 114</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-08-07&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3108.pdf">
          N3108</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US115">US 115</A></TD>
<TD>editor</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3173.pdf">
          N3173</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US116">US 116</A></TD>
<TD>editor</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US117">US 117</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-08-07&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1419">1419</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US118">US 118</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>2010-08-07&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US119">US 119</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>2010-08-07&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US120">US 120</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-08-07&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1431">1431</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US121">US 121</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1432">1432</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US122">US 122</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-08-07&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1434">1434</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3106.pdf">
          N3106</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US123">US 123</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US124">US 124</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1437">1437</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US125">US 125</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US126">US 126</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1438">1438</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US127">US 127</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US128">US 128</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US129">US 129</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US130">US 130</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US131">US 131</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US132">US 132</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US133">US 133</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US134">US 134</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1439">1439</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US135">US 135</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1440">1440</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US136">US 136</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-08-07&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1441">1441</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US137">US 137</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1445">1445</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3168.htm">
          N3168</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US138">US 138</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1446">1446</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3179.html">
          N3179</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US139">US 139</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1447">1447</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3168.htm">
          N3168</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US140">US 140</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>2010-08-07&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US141">US 141</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1451">1451</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US142">US 142</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US143">US 143</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US144">US 144</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US145">US 145</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US146">US 146</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US147">US 147</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US148">US 148</A></TD>
<TD>editor</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US149">US 149</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US150">US 150</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US151">US 151</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US152">US 152</A></TD>
<TD>editor</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US153">US 153</A></TD>
<TD>editor</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US154">US 154</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1460">1460</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US155">US 155</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US156">US 156</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US157">US 157</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1463">1463</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3193.html">
          N3193</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US158">US 158</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US159">US 159</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US160">US 160</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1464">1464</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3193.html">
          N3193</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US161">US 161</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1465">1465</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3193.html">
          N3193</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US162">US 162</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1466">1466</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3193.html">
          N3193</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US163">US 163</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1467">1467</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3193.html">
          N3193</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US164">US 164</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1468">1468</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3193.html">
          N3193</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US165">US 165</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1470">1470</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US166">US 166</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US167">US 167</A></TD>
<TD>editor</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US168">US 168</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1471">1471</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3196.html">
          N3196</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US169">US 169</A></TD>
<TD>editor</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US170">US 170</A></TD>
<TD>editor</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US171">US 171</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1472">1472</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3196.html">
          N3196</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US172">US 172</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1473">1473</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US173">US 173</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US174">US 174</A></TD>
<TD>editor</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US175">US 175</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1474">1474</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US176">US 176</A></TD>
<TD>editor</TD>
<TD>rejected&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US177">US 177</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1476">1476</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US178">US 178</A></TD>
<TD>editor</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US179">US 179</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1479">1479</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US180">US 180</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US181">US 181</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1482">1482</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3191.html">
          N3191</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US182">US 182</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>2010-08-07&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US183">US 183</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1484">1484</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US184">US 184</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1485">1485</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US185">US 185</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1488">1488</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US186">US 186</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1491">1491</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/N3209.htm">
          N3209</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US187">US 187</A></TD>
<TD>editor</TD>
<TD>modified&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US188">US 188</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1492">1492</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3197.html">
          N3197</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US189">US 189</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1493">1493</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US190">US 190</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1494">1494</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US191">US 191</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1495">1495</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3191.html">
          N3191</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US192">US 192</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US193">US 193</A></TD>
<TD>LWG</TD>
<TD>rejected&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1499">1499</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US194">US 194</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1501">1501</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3192.html">
          N3192</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US195">US 195</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1502">1502</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US196">US 196</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1504">1504</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US197">US 197</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1505">1505</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US198">US 198</A></TD>
<TD>LWG</TD>
<TD>accepted&#160;
       </TD>
<TD>2010-08-07&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1506">1506</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US199">US 199</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1507">1507</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US200">US 200</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US201">US 201</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1508">1508</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3194.html">
          N3194</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US202">US 202</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1509">1509</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3194.html">
          N3194</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US203">US 203</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1510">1510</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3194.html">
          N3194</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US204">US 204</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1511">1511</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3194.html">
          N3194</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US205">US 205</A></TD>
<TD>LWG</TD>
<TD>modified&#160;
       </TD>
<TD>2010-11-13&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1512">1512</A>&#160;
       </TD>
<TD><A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3194.html">
          N3194</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US206">US 206</A></TD>
<TD>editor</TD>
<TD>accepted&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US207">US 207</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1514">1514</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US208">US 208</A></TD>
<TD>LWG</TD>
<TD>&#160;
       </TD>
<TD>&#160;
       </TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1515">1515</A>&#160;
       </TD>
<TD>&#160;
       </TD>
</TR>
</TBODY>
</TABLE>
<HR><A NAME="OPEN"></A><H3><U>UNRESOLVED COMMENTS:</U></H3>
<P>
    The following table lists the comments for which no resolution has
    yet been proposed.
   </P>
<TABLE border="1" cellspacing="0" cellpadding="4" frame="box">
<THEAD>
<TR>
<TH>ID</TH>
<TH>Responsible</TH>
<TH>Issue</TH>
</TR>
</THEAD>
<TBODY>
<TR>
<TD><A HREF="
          #CA2">CA 2</A></TD>
<TD></TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB13">GB 13</A></TD>
<TD></TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US1">US 1</A></TD>
<TD></TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US34">US 34</A></TD>
<TD></TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CA3">CA 3</A></TD>
<TD>CWG</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US18">US 18</A></TD>
<TD>CWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1108">1108</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US51">US 51</A></TD>
<TD>CWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1141">1141</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US53">US 53</A></TD>
<TD>CWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1143">1143</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US65">US 65</A></TD>
<TD>CWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1150">1150</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CH8">CH 8</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #FI11">FI 11</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB2">GB 2</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB94">GB 94</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB98">GB 98</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB108">GB 108</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB111">GB 111</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB117">GB 117</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #ITTF7">ITTF 7</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US7">US 7</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US123">US 123</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US125">US 125</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US127">US 127</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US128">US 128</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US129">US 129</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US130">US 130</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US131">US 131</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US132">US 132</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US133">US 133</A></TD>
<TD>editor</TD>
<TD>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CA1">CA 1</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1461">1461</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CA21">CA 21</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1459">1459</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CH15">CH 15</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1421, 1350">1421, 1350</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CH18">CH 18</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1353">1353</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CH19">CH 19</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1364">1364</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CH23">CH 23</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1475">1475</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CH24">CH 24</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1486">1486</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CH25">CH 25</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1487">1487</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CH30">CH 30</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1497">1497</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #CH35">CH 35</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1503">1503</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #DE22">DE 22</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1421">1421</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB55">GB 55</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1358">1358</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB61">GB 61</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1345">1345</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB64">GB 64</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1348">1348</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB65">GB 65</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1349">1349</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB74">GB 74</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1369">1369</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB75">GB 75</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1371">1371</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB88">GB 88</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1385">1385</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB99">GB 99</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1401">1401</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB103">GB 103</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1408">1408</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB113">GB 113</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1418">1418</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB115">GB 115</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1420">1420</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB122">GB 122</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1442, 1443">1442, 1443</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB124">GB 124</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1448">1448</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB125">GB 125</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1452">1452</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB127">GB 127</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1450">1450</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB129">GB 129</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1456">1456</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB130">GB 130</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1457">1457</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB131">GB 131</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1458">1458</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB135">GB 135</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1477">1477</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB136">GB 136</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1478">1478</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #GB137">GB 137</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1480">1480</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US85">US 85</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1374">1374</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US87">US 87</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1375">1375</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US104">US 104</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1396">1396</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US112">US 112</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1413">1413</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US126">US 126</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1438">1438</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US141">US 141</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1451">1451</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US154">US 154</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1460">1460</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US165">US 165</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1470">1470</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US175">US 175</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1474">1474</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US177">US 177</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1476">1476</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US179">US 179</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1479">1479</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US184">US 184</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1485">1485</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US190">US 190</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1494">1494</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US195">US 195</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1502">1502</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US196">US 196</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1504">1504</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US197">US 197</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1505">1505</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US199">US 199</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1507">1507</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US207">US 207</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1514">1514</A>&#160;
       </TD>
</TR>
<TR>
<TD><A HREF="
          #US208">US 208</A></TD>
<TD>LWG</TD>
<TD><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1515">1515</A>&#160;
       </TD>
</TR>
</TBODY>
</TABLE>
<HR><A name="RR"></A><H2><U>ALL COMMENTS</U></H2>
<TABLE border="1" cellspacing="0" cellpadding="4" frame="box">
<THEAD>
<TR>
<TH width="4%" align="center">ID</TH>
<TH width="6%" align="center">Ref</TH>
<TH width="30%" align="center">Comment</TH>
<TH width="30%" align="center">Proposed Resolution</TH>
<TH width="6%" align="center">Owner</TH>
<TH width="4%" align="center">Issue</TH>
<TH width="20%" align="center">Disposition</TH>
</TR>
</THEAD>
<TBODY>
<TR>
<TD valign="top"><A NAME="ITTF1">ITTF 1</A></TD>
<TD valign="top">
General
&#160;
  </TD>
<TD valign="top">
The ISO/IEC headers and footers should appear at the
top and bottom of every page.
&#160;
  </TD>
<TD valign="top">
Insert the ISO/IEC headers and footers at the top
and bottom of every page.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US1">US 1</A></TD>
<TD valign="top">
1-30
&#160;
  </TD>
<TD valign="top">
It appears that the C committee could possibly make
some changes for C1X that we may still want to follow for
C++0X to avoid gratuitous incompatibilities.
&#160;
  </TD>
<TD valign="top">
Make any appropriate changes to avoid
unnecessary incompatibilities with C1X resulting
from changes to the WG14 C standard draft.
&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US2">US 2</A></TD>
<TD valign="top">
1-30
&#160;
  </TD>
<TD valign="top">
The active issues identified in the CWG and LWG issues
lists as if the date that the FCD was published (N3083 and
N3087) must be addressed and appropriate action taken.
&#160;
  </TD>
<TD valign="top">
Appropriate action would include making changes
to the FCD, identifying an issue as not requiring a
change to the FCD, or deferring an issue to a later
draft or a later standard.
&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="DE1">DE 1</A></TD>
<TD valign="top">
1 through 15
&#160;
  </TD>
<TD valign="top">
Consider applying the resolutions of the active core issues
in Ready status (see WG21 N3083).
&#160;
  </TD>
<TD valign="top">
&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="CH1">CH 1</A></TD>
<TD valign="top">
all
&#160;
  </TD>
<TD valign="top">
The issues on the issues lists (WG21 N3083 and N3087)
shall be addressed before the standard becomes final.
&#160;
  </TD>
<TD valign="top">
&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US3">US 3</A></TD>
<TD valign="top">
1 - 29
&#160;
  </TD>
<TD valign="top">
The threading model does not make basic guarantees
needed to write correct programs. We should not repeat
the error that POSIX made in early standards (and later
corrected).
&#160;
  </TD>
<TD valign="top">
Add requirements that all no-blocked threads will
(however slowly) make progress and that all
visible side effects will (eventually) be seen by
other threads. Possibly use the word &#8220;should&#8221; if
an absolute requirement is impossible.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/N3209.htm">
     N3209</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US4">US 4</A></TD>
<TD valign="top">
all

    &#182;
    
all
&#160;
  </TD>
<TD valign="top">
Many identifiers are hyphenated and broken across line
boundaries. As a consequence, searching for the
identifier fails.
&#160;
  </TD>
<TD valign="top">
Protect all identifiers against hyphenation.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US5">US 5</A></TD>
<TD valign="top">
all

    &#182;
    
all
&#160;
  </TD>
<TD valign="top">
The word "object" often copies as "ob ject".
&#160;
  </TD>
<TD valign="top">
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
Some PDF viewers do this. Don't know why, or how to avoid it.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US6">US 6</A></TD>
<TD valign="top">
various

    &#182;
    
various
&#160;
  </TD>
<TD valign="top">
~ (U+007E) is sometimes replaced with &#8764; (U+223C),
causing cut and paste from the standard to fail, notably in
2.14.5.
&#160;
  </TD>
<TD valign="top">
Use U+007E consistently
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US7">US 7</A></TD>
<TD valign="top">
various

    &#182;
    
various
&#160;
  </TD>
<TD valign="top">
' (U+0027) is consistently replaced with &#8217; (U+2019),
causing cut and paste to fail. This is also an issue with
the 1998 standard.
&#160;
  </TD>
<TD valign="top">
Use U+0027 consistently in code samples (i.e.
monospace font)
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB1">GB 1</A></TD>
<TD valign="top">
1.1

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
The C99 standard supports inline functions, so this should
not be listed as a distinguishing feature of C++.
&#160;
  </TD>
<TD valign="top">
strike "inline functions" from the list of C++
'additional facilities'
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB2">GB 2</A></TD>
<TD valign="top">
1.2
&#160;
  </TD>
<TD valign="top">
In [intro.refs] the spec references ISO/IEC 9945:2003
even though a later revision, ISO/IEC 9945:2008 has
already been released:
http://www.iso.org/iso/catalogue_detail.htm?csnumber=50
516
&#160;
  </TD>
<TD valign="top">
The section should be updated to reference the
latest version.<BR>
In addition, since POSIX is a registered trademark
of the IEEE, the spec should use the registered
trademark (R) symbol wherever it references it.
Alternatively, it can refer to ISO/IEC 9945.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="ITTF2">ITTF 2</A></TD>
<TD valign="top">
1.2
&#160;
  </TD>
<TD valign="top">
The introductory text to the Normative references is not
correct.
&#160;
  </TD>
<TD valign="top">
Delete the current introductory text to the
Normative references and replace with the
following:<BR>
&#8220;The following referenced documents are
indispensable for the application of this document.
For dated references, only the edition cited
applies. For undated references, the latest edition
of the referenced document (including any
amendments) applies.&#8221;
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="ITTF3">ITTF 3</A></TD>
<TD valign="top">
1.3
&#160;
  </TD>
<TD valign="top">
The title to the subclause does not accurately reflect the
content.
&#160;
  </TD>
<TD valign="top">
Change the title to &#8220;Terms and definitions&#8221;.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="ITTF4">ITTF 4</A></TD>
<TD valign="top">
1.3
&#160;
  </TD>
<TD valign="top">
3.1 of the ISO/IEC Directives, Part 2, states that the
following introductory wording shall be used where all
terms and definitions are given the document itself:
&#8220;For the purposes of this document, the following terms
and definitions apply.&#8221;
&#160;
  </TD>
<TD valign="top">
Change the introductory text to:<BR>
&#8220;For the purposes of this document, the following
terms and definitions apply.&#8221;
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="ITTF5">ITTF 5</A></TD>
<TD valign="top">
1.3
&#160;
  </TD>
<TD valign="top">
D.1.5.3 of the ISO/IEC Directives, Part 2 states that the
form of a definition shall be such that it can replace the
term in context.
&#160;
  </TD>
<TD valign="top">
Delete the definite or indefinite article at the
beginning of each definition.<BR>
Redraft definitions 1.3.11 and 1.3.13 so that they
can replace the term in context (i.e. they should
not be more than one sentence).
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="ITTF6">ITTF 6</A></TD>
<TD valign="top">
1.3
&#160;
  </TD>
<TD valign="top">
D.3.1 of the ISO/IEC Directives, Part 2, states that the
definition shall not be followed by a full stop.
&#160;
  </TD>
<TD valign="top">
Remove the full stops at the end of the definitions.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="ITTF7">ITTF 7</A></TD>
<TD valign="top">
1.3
&#160;
  </TD>
<TD valign="top">
D.3.9 of the ISO/IEC Directives, Part 2, provides
examples on how to present examples and notes to terms
and definitions. The examples and notes to the terms and
definitions are not presented in accordance with D.3.9 of
the ISO/IEC Directives, Part 2.
&#160;
  </TD>
<TD valign="top">
Redraft the notes and examples to the terms and
definitions in accordance with D.3.9 of the
ISO/IEC Directives, Part 2.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB3">GB 3</A></TD>
<TD valign="top">
1.3

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
The library stretches out to clause 30 now, and the terms
in 17.3 should cover them too.
&#160;
  </TD>
<TD valign="top">
Update reference to clause 27 to say clause 30.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP15">JP 15</A></TD>
<TD valign="top">
1.3

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
There is a description, "17.3 defines additional terms that
are used only in Clauses 17 through 27 and Annex D.",
but the terms defined in 17.3 are also used in Clauses 28
through 30, which are added recently. So the scope
should be expanded to include them.
&#160;
  </TD>
<TD valign="top">
17.3 defines additional terms that are used only in
Clauses 17 through 30 and Annex D.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB4">GB 4</A></TD>
<TD valign="top">
1.3.10
&#160;
  </TD>
<TD valign="top">
The phrase "catch clause" in the 2003 standard has
become "catch Clause"
&#160;
  </TD>
<TD valign="top">
Change back the "catch clause"
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="RU1">RU 1</A></TD>
<TD valign="top">
1.7

    &#182;
    
p.5, line 5 from end
&#160;
  </TD>
<TD valign="top">
Reference missed
&#160;
  </TD>
<TD valign="top">
Insert reference "(2.3)" after "basic execution
character set"
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB5">GB 5</A></TD>
<TD valign="top">
1.9

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
The evaluation of function arguments are now
indeterminately sequenced, rather than left completely
unspecified, as part of the new language describing the
memory model. A clearer example of unspecified behavior
should be used here.
&#160;
  </TD>
<TD valign="top">
[Need to identify a better example to propose]
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB6">GB 6</A></TD>
<TD valign="top">
1.9

    &#182;
    
4
&#160;
  </TD>
<TD valign="top">
There are core issues surrounding the undefined behavior
of dereferencing a null pointer. It appears the intent is that
dereferencing *is* well defined, but using the result of the
dereference will yield undefined behavior. This topic is too
confused to be the reference example of undefined
behavior, or should be stated more precisely if it is to be
retained.
&#160;
  </TD>
<TD valign="top">
[Identify a better example of undefined behavior to
propose]
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1102">1102</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="CH2">CH 2</A></TD>
<TD valign="top">
1.9 and 1.10
&#160;
  </TD>
<TD valign="top">
It's not clear whether relaxed atomic operations are
observable behaviour.
&#160;
  </TD>
<TD valign="top">
Clarify it.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
Normatively, the behavior is well-defined by 1.9p8. If
the atomic object is volatile, then all operations on it
are observable, otherwise not. Note that &#8220;observable&#8221;
means &#8220;observable outside of the program.&#8221;
<BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3196.html">
     N3196</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB7">GB 7</A></TD>
<TD valign="top">
1.9.6

    &#182;
    
p6
&#160;
  </TD>
<TD valign="top">
From a naive, first-time reader's point of view, 1.9.6 made
me double take, as it seemed it could imply any signal
would leave the program in an unspecified state after
completing. I believe I understand the intent, but to clarify
it, I'd change it to make it clear that the unspecified state
applies only for the duration of the signal handler.
&#160;
  </TD>
<TD valign="top">
Change:<BR>
6 When the processing of the abstract machine is
interrupted by receipt of a signal, the values of
objects which are neither
of type volatile std::sig_atomic_t nor
lock-free atomic objects (29.4)
are unspecified, and the value of any object not in
either of these two categories that is modified by
the handler becomes undefined.

to:

6 When the processing of the abstract machine is
interrupted by receipt of a signal, the values of
objects which are neither
of type volatile std::sig_atomic_t nor
lock-free atomic objects (29.4)
are unspecified for the duration of the signal
handler, and the value of any object not in either
of these two categories that is modified by the
handler becomes undefined.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1173">1173</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
The reference should be 1.9 paragraph 6, not 1.9.6 (which does
not exist).
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US8">US 8</A></TD>
<TD valign="top">
1.9

    &#182;
    
footnote 7
&#160;
  </TD>
<TD valign="top">
The footnote "Overloaded operators are never assumed
to be associative or commutative." is either meaningless
or overly restrictive.
&#160;
  </TD>
<TD valign="top">
Change the footnote to "Overloaded operators are
assumed to be non-associative and noncommutative
until proven otherwise.".
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
The statement involved is non-normative and is, in general, correct.
An implementation can treat overloaded operators as associative or
commutative only under the &#8220;as-if&#8221; rule, so the statement
is clear enough.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="CA23">CA 23</A></TD>
<TD valign="top">
1.10, 29

    &#182;
    
1.10, 29
&#160;
  </TD>
<TD valign="top">
C1x has added new atomics
C1x has added new atomics syntax, and in some cases
new semantics and operations. C++0x needs to consider
aligning with the new C1x atomics
&#160;
  </TD>
<TD valign="top">
Add back compatibility between C++0x and C1x
atomics
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3193.html">
     N3193</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="CA14">CA 14</A></TD>
<TD valign="top">
1.10p4

    &#182;
    
1.10p4
&#160;
  </TD>
<TD valign="top">
Initialisation of atomics

Add the following to 1.10p4:

[ Note: There may be non-atomic writes to atomic
objects, for example on initialization and reinitialization.
- end note]

Rationale: We believe the intent is that for any atomic
there is a distinguished initialisation write, but that this
need not happens-before all the other operations on that
atomic - specifically so that the initialisation write might be
non-atomic and hence give rise to a data race, and hence
undefined behaviour, in examples such as this (from
Hans):
<PRE>
atomic&lt; atomic&lt;int&gt; * &gt; p
f()                    |
{ atomic&lt;int&gt;x;        | W_na x
  p.store(&amp;x,mo_rlx);  | W_rlx p=&amp;x
}                      |
</PRE>
(where na is nonatomic and rlx is relaxed). We suspect
also that no other mixed atomic/nonatomic access to the
same location is intended to be permitted. The possibility
of non-atomic writes on atomic objects is not mentioned in
1.10, and (before talking with Hans) we didn't realise it
was intended, so we suggest adding the note above to
clarify things.
&#160;
  </TD>
<TD valign="top">
Add the following to 1.10p4:<BR>
[ Note: There may be non-atomic
writes to atomic objects, for example
on initialization and renitialization. - end note]
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
The suggested update from US 168 was adopted.
<BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3196.html">
     N3196</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="CA12">CA 12</A></TD>
<TD valign="top">
1.10p6

    &#182;
    
1.10p6
&#160;
  </TD>
<TD valign="top">
The use of maximal in the definition of release sequence
(proposed edit seems reasonable to Clark)<BR>
We suggest that 1.10p6 be changed to:<BR>
A release sequence from a release operation A on an
atomic object M is a maximal contiguous sub-sequence
of side effects in the modification order of M, where
the first operation is A, and every subsequent
operation<BR>
- is performed by the same thread that performed
the release, or<BR>
- is an atomic read-modify-write operation.<BR>
Rationale: The current wording of the standard suggests
that release sequences are maximal with respect to
sequence inclusion, i.e. that if there are two release
operations in the modification order,<BR>
<PRE>
mod       mod
rel1-----&gt;rel2-----&gt;w
</PRE>
then [rel1;rel2;w] is the only release sequence, as the
other candidate [rel2;w] is included in it. This interpretation
precludes synchronizing with releases which have other
releases sequenced-before them. We believe that the
intention is actually to define the maximal release
sequence from a particular release operation, which would
admit both [rel1;rel2;w] and [rel2;w].&#160;
  </TD>
<TD valign="top">
We suggest that 1.10p6 be changed to:<BR>
A release sequence from a release
operation A on an atomic object M is
a maximal contiguous sub-sequence
of side effects in the modification
order of M, where the first
operation is A, and every subsequent
operation<BR>
- is performed by the same thread
that performed the release, or<BR>
- is an atomic read-modify-write
operation.&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1176">1176</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US9">US 9</A></TD>
<TD valign="top">
1.10

    &#182;
    
para 4
&#160;
  </TD>
<TD valign="top">
The "operations on locks" do not provide synchronization,
as locks are defined in Clause 30.
&#160;
  </TD>
<TD valign="top">
Change "operations on locks" to "locking
operations".
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3196.html">
     N3196</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="CA20">CA 20</A></TD>
<TD valign="top">
1.10p1

    &#182;
    
1.10p1
&#160;
  </TD>
<TD valign="top">
Reading from the last element in a vsse?
Paul wrote:<BR>
&gt; If every element in a vsse happens-before a given value<BR>
&gt; computation, then that value computation must return<BR>
&gt; the value stored by the last element in the vsse.<BR>
We wrote:<BR>
We're not sure about that. Consider the following, with two
relaxed writes to x on one thread that are not sequencedbefore
related to each other (eg in different arguments to
the same function), but are followed by a release/acquire
on a different variable y to another thread that then reads
x. We think the final read (e) could read from either (a) or
(b), regardless of how (a) and (b) are related in
modification order.
<PRE>
a:Wrlx x=1   b:Wrlx x=2
      \     /
     sb\   /sb
        \ /
        c:Wrel y-----------
                           \sw
                            \
                         d:Racq y
                             |
                             |sb
                             |
                         e:Rrlx x=?
</PRE>
|
Paul&gt; In that case IIRC, the standard does not specify<BR>
Paul&gt; the order, but the code will be generated in some<BR>
Paul&gt; order, and that arbitrary choice on the part of the<BR>
Paul&gt; compiler will determine the modification order.<BR>
We agree that in a normal implementation (eg where the<BR>
argument evaluations are not spawned off to new threads
- is that intended to be forbidden?), the two writes will
indeed be ordered according to the generated-code order
(and before the release fence), and hardware coherence
will ensure that (e) reads the later one.<BR>
But in the draft standard as written, that execution is
allowed - the draft doesn't currently impose that aspect of
coherence. To make the example more concrete, if there
were another thread with<BR>
<PRE>
c --sw--&gt; f:Racq y --sb--&gt; g:Rrlx x
</PRE>
then e and g could read different values.<BR>
Paul notes:<BR>
&gt; But 1.10p1 says:<BR>
&gt;<BR>
&gt; A thread of execution (also known as a thread) is a<BR>
&gt; single flow of control within a program, including<BR>
&gt; the initial invocation of a specific top-level<BR>
&gt; function, and recursively including every function<BR>
&gt; invocation subsequently executed by the thread.<BR>
&gt;<BR>
&gt; This excludes the possibility of the implementation<BR>
&gt; spawing off a new thread -unless- the implementation<BR>
&gt; can make things appear as if there was only one thread.<BR>
&gt; From this viewpoint, your example shows just how<BR>
&gt; careful an implementation must be if it is to fully<BR>
&gt; comply with this as-if rule.<BR>
We replied<BR>
&gt;ok, thanks<BR>
to this, but in fact the situation is still unclear.<BR>
1.10p1 does indeed rule out the hypothetical
implementation that we mentioned, but even if (a) and (b)
would be ordered by any reasonable implementation, in
terms of the concepts of the standard, that doesn't
introduce a sequenced-before edge between (a) and (b).<BR>
It seems that Paul is assuming the individual memory
accesses in function arguments are indeterminately
sequenced rather than unsequenced?
&#160;
  </TD>
<TD valign="top">
Please clarify.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3196.html">
     N3196</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="CA19">CA 19</A></TD>
<TD valign="top">
1.10p5 1.10p13

    &#182;
    
1.10p5 1.10p13
&#160;
  </TD>
<TD valign="top">
Alternative definition of the value read by an atomic
operation<BR>
Here's an interesting example involving a
release/consume pair. We believe that in a direct
implementation on hardware, this would be forbidden by
coherence, but that the current text allows it. We don't
know whether it should be allowed or not.
<PRE>
            hb
            do
            rf
Wx_release ----&gt; Rx_consume
         ^         |
          \        |sb,hb
        mo \       v
             --- Wx_release
</PRE>
Paul claims this is forbidden by 1.10p5, but we don't see
how that can be the case. We don't see much room in
1.10p5 for any other interpretation - it says:<BR>
- "All modifications to a particular atomic object M occur in
some particular total order, called the modification order of
M"<BR>
- "If A and B are modifications of an atomic object M and
A happens before (as defined below) B, then A shall
precede B in the modification order of M, which is defined
below."<BR>
Both of which seem very clear. The only wiggle room is in
the Note<BR>
- "[Note: This states that the modification orders must
respect the "happens before" relationship]"<BR>
We took that "must respect" to be a gloss rather than to
add any additional constraint.<BR>
Earlier we suggested a change, to the constraint on the
value read by an atomic operation, that would forbid this
example:<BR>
The standard introduces visible side effects, which are
used first to define the values read by non-atomic
operations. They are then re-used to constrain the value
read by atomic operations: 1.10p13 says that an atomic
operation must read from somewhere in "the" visible
sequence of side effects, which must start from *a* visible
side effect, i.e. a side effect that (a) happens before the
read, and (b) is not happens-before-hidden. We suspect
that this re-use of the notion of visible side effect may be a
drafting artifact, in which case one might remove the
requirement that there is a vse for atomics, and replacing
the first two sentences of 1.10p13 by<BR>
"An atomic operation must read from somewhere in the
modification order that is not happens-before-hidden
and does not follow (in modification order) any side
effect that happens-after the read."BR/&gt;
Now we're not sure how this would fit in with initialisation
and reading of indeterminate values; we need to think
about it more.
&#160;
  </TD>
<TD valign="top">
Please clarify.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3196.html">
     N3196</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="CA22">CA 22</A></TD>
<TD valign="top">
1.10p8

    &#182;
    
1.10p8
&#160;
  </TD>
<TD valign="top">
Control dependencies for atomics<BR>
Given the examples of compilers interchanging data and
control dependencies, and that control dependencies are
architecturally respected on Power/ARM for load-&gt;store
(and on Power for load-&gt;load with a relatively cheap
isync), we're not sure why carries-a-dependency-to does
not include control dependencies between atomics.
&#160;
  </TD>
<TD valign="top">
Please clarify.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
At the time that the memory model was formulated, there
was considerable uncertainty as to what architectures
respect control dependencies, and to what extent. It
appears that this uncertainty is being cleared up, and
our hope is that it will be ripe for standardization in
a later TR. 
<BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3196.html">
     N3196</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="CA15">CA 15</A></TD>
<TD valign="top">
1.10p9

    &#182;
    
1.10p9
&#160;
  </TD>
<TD valign="top">
Intra-thread dependency-ordered-before<BR>
The current draft has release/acquire synchronize-with
edges only between a release on one thread and an
acquire on a *different* thread, whereas the definition of
dependency-ordered-before permits the release and
consume to be on the same thread; it seems odd to permit
the latter. (At the moment function arguments can't race or
sync with each other, but they can be dependency
ordered before each other.)<BR>
We don't currently have an example in which this makes a
real difference, but for symmetry could suggest changing
the definition of dependency-ordered-before in 1.10p9 to
the following:<BR>
An evaluation A is dependency-ordered before an
evaluation B if<BR>
- A performs a release operation on an atomic object
M, and on another thread, B performs a consume
operation on M and reads a value written by any
side effect in the release sequence headed by A,<BR>
or<BR>
- for some evaluation X, A is dependency-ordered
before X and X carries a dependency to B.
&#160;
  </TD>
<TD valign="top">
We suggest changing the definition of
dependency-ordered-before in 1.10p9 to the
following:<BR>
An evaluation A is dependency-ordered
before an evaluation B if<BR>
- A performs a release operation
on an atomic object M, and on
another thread, B performs a
consume operation on M and reads
a value written by any side
effect in the release sequence
headed by A, or<BR>
- for some evaluation X, A is
dependency-ordered before X and
X carries a dependency to B.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1177">1177</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3196.html">
     N3196</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="CA11">CA 11</A></TD>
<TD valign="top">
1.10p12

    &#182;
    
1.10p12
&#160;
  </TD>
<TD valign="top">
"Subsequent" in vsse definition<BR>
Remove the word "subsequent" from the definition of
visible sequence of side effects in 1.10p12.<BR>
(as suggested by Hans)<BR>
Rationale: if every element in a vsse happens-before a
read, the read should not take the value of the visible side
effect.
&#160;
  </TD>
<TD valign="top">
Remove the word "subsequent" from the definition
of visible sequence of side effects in 1.10p12.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3196.html">
     N3196</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="CA17">CA 17</A></TD>
<TD valign="top">
1.10p12

    &#182;
    
1.10p12
&#160;
  </TD>
<TD valign="top">
1.10p12 phrasing<BR>
1.10p12 last note:
"...as defined here..." should be
"...as defined below...".
&#160;
  </TD>
<TD valign="top">
1.10p12 last note:<BR>
"...as defined here..." should be
"...as defined below...".
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
The reference really should be to "data races as defined
in this International Standard", because the note compares
this definition with the generally-understood meaning of
data races in sequentially-consistent executions. That's
far too stilted, and "as defined here" seems like a
reasonable way to phrase it in the less formal context of
a note.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="CA13">CA 13</A></TD>
<TD valign="top">
1.10p13

    &#182;
    
1.10p13
&#160;
  </TD>
<TD valign="top">
Wording of the read-read coherence condition<BR>
In 1.10p13 a coherence condition is stated on the values
of atomic reads:<BR>
"Furthermore, if a value computation A of an atomic
object M happens before a value computation B of M,
and the value computed by A corresponds to the value
stored by side effect X, then the value computed by B
shall either equal the value computed by A, or be the
value stored by side effect Y, where Y follows X in
the modification order of M."<BR>
We suggest that this be replaced with the following:<BR>
"Furthermore, if a value computation A of an atomic
object M happens before a value computation B of M,
and A takes its value from the side effect X, then
the value computed by B shall either be the value
stored by X, or the value stored by a side effect Y,
where Y follows X in the modification order of M."<BR>
Rationale: The words "corresponds to" are not used
elsewhere in the standard, as far as we can see, and it is
unclear whether they have a special meaning here. In
addition taking the value of the read B from the value read
by A seems unnecessarily indirect. B could take its value
from X instead.
&#160;
  </TD>
<TD valign="top">
In 1.10p13 a coherence condition is stated on the
values of atomic reads:<BR>
"Furthermore, if a value
computation A of an atomic object M
happens before a value computation
B of M, and the value computed by A
corresponds to the value stored by
side effect X, then the value
computed by B shall either equal
the value computed by A, or be the
value stored by side effect Y,
where Y follows X in the
modification order of M."<BR>
We suggest that this be replaced with the
following:<BR>
"Furthermore, if a value
computation A of an atomic object M
happens before a value computation
B of M, and A takes its value from
the side effect X, then the value
computed by B shall either be the
value stored by X, or the value
stored by a side effect Y, where Y
follows X in the modification order
of M."
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3196.html">
     N3196</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="CA18">CA 18</A></TD>
<TD valign="top">
1.10p13

    &#182;
    
1.10p13
&#160;
  </TD>
<TD valign="top">
Non-unique visible sequences of side effects and
happens-before ordering<BR>
In 1.10p13, replace<BR>
"The visible sequence of side effects on..." by
"A visible sequence of side effects on..."<BR>
and<BR>
"in the visible sequence of M with respect to B" by
"in a visible sequence of M with respect to B"<BR>
Rationale: the current standard allows multiple visible
sequences of side effects (vsse's) for a given read
(despite the use of "The" at the start of 1.10p13). We
demonstrate this by constructing an execution with two
vsse's. The following execution has five memory
operations, four of which are read modify writes (RMW's).
There are two threads, one with four operations each
ordered by sequenced before (sb), the other with a single
RMW release.
<PRE>
RMW1             +---RMW3_release
|               /
|sb          do/
v             /
R_consume&lt;---+
|
|sb
v
RMW2
|
|sb
v
RMW4
</PRE>
The modification order in this example is as
follows:
<PRE>
mod       mod               mod
RMW1-----&gt;RMW2-----&gt;RMW3_release-----&gt;RMW4
</PRE>
With the modification order we give above, the
happens-before relation
has exactly these edges, according to 1.10p10:
<PRE>
From sequenced-before:
RMW1      -&gt; R_consume, RMW2, RMW4
R_consume -&gt; RMW2, RMW4
RMW2      -&gt; RMW4
From ithb:
From dependency-ordered-before:
RMW3_release -&gt; R_consume
</PRE>
In particular, there are no edges
<PRE>
RMW3_release -&gt; RMW2 or RMW4.
</PRE>
As we understand it, this is the intended
absence of transitivity from dependency-orderedbefore
to sequenced-before.<BR>
1.10p5 says that if A happens-before B then A precedes B
in the modification order, which is true for all the happensbefore
edges and the modification order above.<BR>
RMW1 and RMW3_release are visible side effects<BR>
RMW2 and RMW4 follow R_consume in happens-before,
so cannot be in a visible sequence of side effects.<BR>
Hence the two visible sequences of side effects are
[RMW1] and [RMW3].<BR>
The R_consume here must read from the later vsse in
modification order for the dependency_ordered edge to
exist. The existence of two vsse's relies on the lack of
transitivity of happens before (which only occurs in the
presence of consume operations).
&#160;
  </TD>
<TD valign="top">
In 1.10p13, replace<BR>
"The visible sequence of side
effects on..."<BR>
by<BR>
"A visible sequence of side effects
on..."<BR>
and<BR>
"in the visible sequence of M with
respect to B"<BR>
by<BR>
"in a visible sequence of M with
respect to B"
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3196.html">
     N3196</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US10">US 10</A></TD>
<TD valign="top">
1.10

    &#182;
    
Paragraph 14
&#160;
  </TD>
<TD valign="top">
The definition of a data race does not take into account
two overlapping atomic operations
&#160;
  </TD>
<TD valign="top">
Augment the first sentence:<BR>
The execution of a program contains a data race if
it contains two conflicting actions in different
threads, at least one of which is not atomic <ins>(or
both are atomic and operate on overlapping, but
not-identical, memory locations)</ins>, and neither
happens before the other.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
The premise is incorrect; atomic objects may not
overlap. The type argument to the atomic template
must be a trivially-copyable type (29.5.3p1) and
atomic objects are not trivially copyable. The atomic
types provide no means to obtain a reference to
internal members; all atomic operations are
copy-in/copy-out. In short, any attempt to generate a
pair of atomic variables whose memory overlaps results
in undefined behavior.
<BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3196.html">
     N3196</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US11">US 11</A></TD>
<TD valign="top">
1.10

    &#182;
    
para7
&#160;
  </TD>
<TD valign="top">
There is some confusion between locks and mutexes.
&#160;
  </TD>
<TD valign="top">
Change "lock" when used as a noun to "mutex".
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3196.html">
     N3196</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US12">US 12</A></TD>
<TD valign="top">
1.10

    &#182;
    
P4,p14, p6,p12,p13
&#160;
  </TD>
<TD valign="top">
Adapt N3074:<BR>
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3074.html
&#160;
  </TD>
<TD valign="top">
Proposed change in N3074:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3074.html
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3196.html">
     N3196</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="CA2">CA 2</A></TD>
<TD valign="top">
various

    &#182;
    
various
&#160;
  </TD>
<TD valign="top">
Canada agrees with US 12, 14, 142, 145, 159
&#160;
  </TD>
<TD valign="top">
Resolve as suggested in these comments
&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB8">GB 8</A></TD>
<TD valign="top">
1.10

    &#182;
    
4, 7
&#160;
  </TD>
<TD valign="top">
The text says that the library "provides ... operations on
locks". It should say "operations on mutexes", since it is
the mutexes that provide the synchronization. A lock is
just an abstract concept (though the library types
unique_lock and lock_guard model ownership of locks)
and as such cannot have operations performed on it. This
mistake is carried through in the notes in that paragraph
and in 1.10p7
&#160;
  </TD>
<TD valign="top">
Change 1.10p4 as follows:<BR>
"The library defines a number of atomic
operations (Clause 29) and operations on
mutexes (Clause 30) that are specially identified
as synchronization operations. These operations
play a special role in making assignments in one
thread visible to another. A synchronization
operation on one or more memory locations
is either a consume operation, an acquire
operation, a release operation, or both an acquire
and release operation. A synchronization
operation without an associated memory location
is a fence and can be either an acquire fence, a
release fence, or both an acquire and release
fence. In addition, there are relaxed atomic
operations, which are not synchronization
operations, and atomic read-modify-write
operations, which have special characteristics. [
Note: For example, a call that acquires a lock on a
mutex will perform an acquire operation on the
locations comprising the mutex. Correspondingly,
a call that releases the same lock will perform a
release operation on those same locations.
Informally, performing a release operation on A
forces prior side effects on other memory
locations to become visible to other threads that
later perform a consume or an acquire operation
on A. &#8220;Relaxed&#8221; atomic operations are not
synchronization operations even though, like
synchronization operations, they cannot contribute
to data races.  end note ]"<BR>
Change 1.10p7 as follows:<BR>
"Certain library calls synchronize with other library
calls performed by another thread. In particular,
an atomic operation A that performs a release
operation on an atomic object M synchronizes
with an atomic operation B that performs an
acquire operation on M and reads a value written
by any side effect in the release sequence headed
by A. [ Note: Except in the specified cases,
reading a later value does not necessarily ensure
visibility as described below. Such a requirement
would sometimes interfere with efficient
implementation.  end note ] [ Note: The
specifications of the synchronization operations
define when one reads the value written by
another. For atomic objects, the definition is clear.
All operations on a given mutex occur in a single
total order. Each lock acquisition &#8220;reads the value
written&#8221; by the last lock release on the same
mutex.  &#8212;end note ]"
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3196.html">
     N3196</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB9">GB 9</A></TD>
<TD valign="top">
1.10

    &#182;
    
6
&#160;
  </TD>
<TD valign="top">
See (B) in attachment Appendix 1 - Additional Details
&#160;
  </TD>
<TD valign="top">
Request the concurrency working group to
determine if changes are needed
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1176">1176</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB10">GB 10</A></TD>
<TD valign="top">
1.10

    &#182;
    
10
&#160;
  </TD>
<TD valign="top">
See (C) in attachment Appendix 1 - Additional Details<BR>
The GB would like WG21 to confirm there is no issue
related to this.<BR>
GB adds:<BR>
We agree that if the read from x reads the value written by
the write to
x the write to x inter-thread-happens-before the write to y.
However, the read from y is sequenced before the write to
x, so if the
read from x reads the value written by the write to x, then
the read
from y also inter-thread-happens-before the write to y.
Consequently,
the read from y cannot see the value written by the write
to y.
The reciprocal ordering also applies, but they cannot both
apply in the
same execution since if the write to x happens-before the
read from x
then the read from y happens-before the write to y, and
vice-versa.
There is thus no contradiction.
[see comment below for proper formatting]
&#160;
  </TD>
<TD valign="top">
Request the concurrency working group to
determine if changes are needed
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3196.html">
     N3196</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="CA8">CA 8</A></TD>
<TD valign="top">
1.10p10

    &#182;
    
1.10p10
&#160;
  </TD>
<TD valign="top">
Rationale: Without this the standard
permits executions with a cyclic
happens-before relation that it seems
clear should be forbidden, e.g.
<PRE>
Rx_consume&lt;--+   +--&gt;Ry_consume
|           rf\ /rf  |
|sb            X     |sb
v             / \    v
Wy_release---+   +---Wx_release
</PRE>
One could instead impose acyclicity on
happens-before; that would be
equivalent.
&#160;
  </TD>
<TD valign="top">
1.10p10, before the Note, add:<BR>
"The inter-thread happens-before relation of an
execution must be acyclic"
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3196.html">
     N3196</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB11">GB 11</A></TD>
<TD valign="top">
1.10

    &#182;
    
12
&#160;
  </TD>
<TD valign="top">
See (E) in attachment Appendix 1 - Additional Details
The GB would like WG21 to confirm there is no issue
related to this.<BR>
GB adds:
[see comment below for proper formatting]
The variable in question has a single modification order,
which is any of<BR>
(a) RMW3, RMW1, RMW2, RMW4.<BR>
(b) RMW1, RMW3, RMW2, RMW4.<BR>
(c) RMW1, RMW2, RMW3, RMW4.<BR>
(d) RMW1, RMW2, RMW4, RMW3.<BR>
since RMW1, RMW2 and RMW4 occur in a single thread
in that sequence, and
RMW3 occurs in a separate thread with no other ordering
constraints.
Since the R_consume lies between RMW1 and RMW2 in
that thread, it must
either read the value written by RMW1 (which could
happen if it
immediately follows RMW1 in any of the sequences), or
RMW3 (which could
happen with sequence (b)).
The visible sequence of side effects for R_consume is
thus either RMW3,
RMW1 (from (a)), RMW1 (from (b), (c) or (d)), or RMW1,
RMW3 (from (b)).
Which sequence applies in practice may vary from
execution to execution.
There is however only a single sequence on any given
execution.
&#160;
  </TD>
<TD valign="top">
Request the concurrency working group to
determine if changes are needed
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3196.html">
     N3196</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB12">GB 12</A></TD>
<TD valign="top">
1.10

    &#182;
    
13
&#160;
  </TD>
<TD valign="top">
See (F) in attachment Appendix 1 - Additional Details<BR>
The GB would like WG21 to confirm there is no issue
related to this.
GB adds:<BR>
The cycle given is clearly forbidden by the current text.
The read is sequenced-before the write in the same
thread. If the read sees the value written by the other
thread then that write is dependency-ordered-before the
read, and thus happens-before the read,
and happens-before the write from the reading thread.
The write from the left-hand thread thus must occur before
the write from the right-hand thread in the modification
order of the object by 1.10p5.
&#160;
  </TD>
<TD valign="top">
Request the concurrency working group to
determine if changes are needed
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3196.html">
     N3196</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB13">GB 13</A></TD>
<TD valign="top">
1.10

    &#182;
    
13
&#160;
  </TD>
<TD valign="top">
See (G) in attachment Appendix 1 - Additional Details<BR>
GB suggests alternative wording to that in the attached
paper:<BR>
"Furthermore, if a value computation A of an atomic object
M happens before a value computation B of M, and A
uses the value of M from the side effect X, then the value
computed by B shall either be the value stored by X, or
the value stored by a side effect Y, where Y follows X in
the modification order of M."
&#160;
  </TD>
<TD valign="top">
Request the concurrency working group to
determine if changes are needed
&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB14">GB 14</A></TD>
<TD valign="top">
1.10

    &#182;
    
8
&#160;
  </TD>
<TD valign="top">
See (I) in attachment Appendix 1 - Additional Details<BR>
GB adds:
If an implementation can't guarantee the ordering it should
refrain from performing the optimisation
&#160;
  </TD>
<TD valign="top">
Request the concurrency working group to
determine if changes are needed.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
We agree that the implementation needs to address this, and it can.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB15">GB 15</A></TD>
<TD valign="top">
1.10
&#160;
  </TD>
<TD valign="top">
See (J) in attachment Appendix 1 - Additional Details
&#160;
  </TD>
<TD valign="top">
Request the concurrency working group to
determine if changes are needed.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
At the time that the memory model was formulated,
there was considerable uncertainty as to what
architectures respect control dependencies, and to
what extent. It appears that this uncertainty is
being cleared up, and our hope is that it will be
ripe for standardization in a later TR. 
<BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3196.html">
     N3196</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB16">GB 16</A></TD>
<TD valign="top">
1.10

    &#182;
    
12
&#160;
  </TD>
<TD valign="top">
See (L) in attachment Appendix 1 - Additional Details
&#160;
  </TD>
<TD valign="top">
"...as defined here..." should be "...as defined
below...".
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
"As defined here" refers to this standard, which is the
intention. If it were normative text the correct phrase
would be "in this International Standard", but for a note,
the text as written is sufficient.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US13">US 13</A></TD>
<TD valign="top">
2.2

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
&#8220;Raw&#8221; strings are still only Pittsburgh-rare strings: the
reversion in phase 3 only applies to an r-char-sequence.
&#160;
  </TD>
<TD valign="top">
Make the reversion apply to the entire raw-string.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1103">1103</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US14">US 14</A></TD>
<TD valign="top">
2.2 2.3 2.5 2.14.5

    &#182;
    
P1
&#160;
  </TD>
<TD valign="top">
Precedence of reversal and tokenization<BR>
The current paper implies that determination of the
characters forming an r-char-sequence occurs while the
transformations done in phase 1 and phase 2 are still in
effect.<BR>
Consider these cases:<BR>
<UL><LI> Line splicing occurred in translation phase 2; the
backslash is not there on entry to phase 3 when
we try to tokenize:<BR>
const char str[] = R"a()\a")a";</LI>
<LI> Trigraph replacement occurred in phase 1. The
right parenthesis is not there on entry to phase 3:<BR>
const char str[] = R"(??)";</LI>
<LI> Trigraph replacement (again). In [lex.string]
paragraph 2, there is a footnote 24 in N3092.
Note that this provides fuel for anti-trigraph
sentiment:<BR>
const char str[] = R"#()??=")#";</LI></UL>
Change in [lex.string] from N3077:<BR>
Escape sequences and universal-character-names
in non-raw string literals have the same
meaning as in character literals ....<BR>
should be reflected in [lex.phases] paragraph 1, phase 5
(CD2 wording):<BR>
Each source character set member and universal-character-name
in a character literal or a string literal, as
well as each escape sequence in a character literal or a
non-raw string literal, is converted to the corresponding
member of the execution character set (2.14.3, 2.14.5); if
there is no corresponding member, it is converted to an
implementation-defined member other than the null (wide)
character<BR>
and [lex.charset] paragraph 2 (CD2 wording):<BR>
Additionally, if the hexadecimal value for a universal-character-name
outside the <I>c-char-sequence</I>, <I>s-char-sequence</I>,
or <I>r-char-sequence</I> of a character or string
literal corresponds to a control character (in either of the
ranges 0x00-0x1F or 0x7F-0x9F, both inclusive) or to a
character in the basic source character set, the program is
ill-formed.<BR>
UCNs simply do not occur in the grammar for r-char-sequence
anyway.
&#160;
  </TD>
<TD valign="top">
In 2.14.5 [lex.string] paragraph 2: Remove
footnote 24:<BR>
In 2.2 [lex.phases] paragraph 1, phase 1; insert
exception:<BR>
Physical source file characters are
mapped, in an implementation-defined
manner, to the basic source character
set (introducing new-line characters for
end-of-line indicators) if necessary. The
set of physical source file characters
accepted is implementation-defined.
Trigraph sequences (2.4) are replaced by
corresponding single-character internal
representations. Any source file
character not in the basic source
character set (2.3) is replaced by the
universal-character-name that
designates that character. (An
implementation may use any internal
encoding, so long as an actual extended
character encountered in the source file,
and the same extended character
expressed in the source file as a
universal-character-name (i.e., using the
\uXXXX notation), are handled
equivalently except where this
replacement is reverted.)<BR>
In 2.2 [lex.phases] paragraph 1, phase 3:<BR>
The source file is decomposed into
preprocessing tokens (2.5) and
sequences of white-space characters
(including comments). A source file shall
not end in a partial preprocessing token
or in a partial comment. Each comment
is replaced by one space character.
New-line characters are retained.
Whether each nonempty sequence of
white-space characters other than newline
is retained or replaced by one space
character is unspecified. The process of
dividing a source file's characters into
preprocessing tokens is contextdependent.
[ Example: see the handling
of &lt; within a #include preprocessing
directive. &#8212;end example ]<BR>
In 2.2 [lex.phases] paragraph 1, phase 5:<BR>
Each source character set member in a
character literal or a string literal, as well
as each escape sequence and universal-character-name
in a character literal or a
non-raw string literal, is converted to the
corresponding member of the execution
character set (2.14.3, 2.14.5); if there is
no corresponding member, it is
converted to an implementation-defined
member other than the null (wide)
character.<BR>
In 2.3 [lex.charset] paragraph 2:<BR>
.... Additionally, if the hexadecimal value
for a universal-character-name outside
the c-char-sequence or s-char-sequence
of a character or string literal
corresponds to a control character (in
either of the ranges 0x000x1F or 0x7F
0x9F, both inclusive) or to a character in
the basic source character set, the
program is ill-formed. [ Footnote: A
sequence of characters resembling a
universal-character-name in an r-char-sequence
(2.14.5 [lex.string]) does not
form a universal-character-name. ]<BR>
In 2.5 [lex.pptoken] paragraph 3:<BR>
If the input stream has been parsed into
preprocessing tokens up to a given
character:
<UL><LI> if the next character begins a
sequence of characters that
could be the prefix and initial
double quote of a raw string
literal, such as R", the next
preprocessing token shall be a
raw string literal and any
transformations performed in
phases 1 and 2 on this input
stream (trigraphs, universal-character-names, and line
splicing) are reverted for the
remainder of the stream until
said raw string literal (2.14.5) is
matched; [ Footnote: A raw
string literal formed through
token concatenation (16.3.3) is
not parsed from an input stream
and is not subject to this
reverting. Destringization (16.9)
involves an alternate input
stream, thus there are no phase
1 or phase 2 transformations to
revert. ]</LI>
<LI> otherwise, the next
preprocessing token is the
longest sequence of characters
that could constitute a
preprocessing token, even if
that would cause further lexical
analysis to fail.</LI></UL>
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1103">1103</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US15">US 15</A></TD>
<TD valign="top">
2.6

    &#182;
    
para 2
&#160;
  </TD>
<TD valign="top">
The &lt;: digraph causes problem with users unfamiliar with
digraphs when passing global objects as template
arguments.
&#160;
  </TD>
<TD valign="top">
Add a special hack for &lt;:: much like the special
hack for &gt;&gt;.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1104">1104</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="CA24">CA 24</A></TD>
<TD valign="top">
2.11

    &#182;
    
Various
&#160;
  </TD>
<TD valign="top">
A list of issues related TR 10176:2003<BR>
1)
"Combining characters should not appear as the first
character of an identifier."
Reference: ISO/IEC TR 10176:2003 (Annex A)
This is not reflected in FCD.<BR>
2)
Restrictions on the first character of an identifier are not
observed as
recommended in TR 10176:2003. The inclusion of digits
(outside of those in
the basic character set) under identifer-nondigit is implied
by FCD.<BR>
3)
It is implied that only the "main listing" from Annex A is
included for C++.
That is, the list ends with the Special Characters section.
This is not made
explicit in FCD. Existing practice in C++03 as well as WG
14 (C, as of N1425)
and WG 4 (COBOL, as of N4315) is to include a list in a
normative Annex.<BR>
4)
Specify width sensitivity as implied by C++03: \uFF21 is
not the same as A
Case sensitivity is already stated in [lex.name].
&#160;
  </TD>
<TD valign="top">
Please clarify.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1105">1105</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3146.html">
     N3146</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB17">GB 17</A></TD>
<TD valign="top">
2.14.2

    &#182;
    
Table 5
&#160;
  </TD>
<TD valign="top">
[lex.icon] 2.14.2/2 Table 5 - 'Types of integer constants' In
the penultimate row for this table (for suffix `ll or LL') it
gives the `Octal or hexadecimal constant' in the third
column as one of: long long int unsigned long int Unless I
am misunderstanding something fundamental, this second
should be: unsigned long long int
&#160;
  </TD>
<TD valign="top">
Replace the entry for "ll or LL" and "Octal or
hexadecimal constant" in table 5 with "long long
int unsigned long long int"
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP16">JP 16</A></TD>
<TD valign="top">
2.14.3

    &#182;
    
2 Note
&#160;
  </TD>
<TD valign="top">
Typo, "wide-charater" should be "wide-character".
&#160;
  </TD>
<TD valign="top">
Correct typo.<BR>
[ Note: the type wchar_t is able to represent all
members of the execution wide-character set (see
3.9.1).
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="RU2">RU 2</A></TD>
<TD valign="top">
2.14.3

    &#182;
    
p.23, par.3, line 1
&#160;
  </TD>
<TD valign="top">
Reference missed
&#160;
  </TD>
<TD valign="top">
Insert reference "(3.9.1)" after "extended integer
type"
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="DE2">DE 2</A></TD>
<TD valign="top">
2.14.4
&#160;
  </TD>
<TD valign="top">
C++ does not support hexadecimal floating-point literals,
although they are useful to specify exact floating-point
constants.
&#160;
  </TD>
<TD valign="top">
Consider supporting the C99 syntax for
hexadecimal floating-point literals.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
There was no consensus to adopt this feature at this point in the
standardization process.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US16">US 16</A></TD>
<TD valign="top">
2.14.5 [lex.string]
&#160;
  </TD>
<TD valign="top">
Raw string literals have no implementation experience.
&#160;
  </TD>
<TD valign="top">
Either demonstrate a complete implementation of
this feature or remove N2146 from the working
paper prior the FDIS.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
The feature has been implemented.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="DE3">DE 3</A></TD>
<TD valign="top">
2.14.7
&#160;
  </TD>
<TD valign="top">
It is not sufficiently clear that std::nullptr_t is a distinct type
and neither a pointer type nor a pointer-to-member type.
&#160;
  </TD>
<TD valign="top">
Add a note in 2.14.7 stating that, preferably with
cross-references to the normative statements in
3.9.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1106">1106</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="RU5">RU 5</A></TD>
<TD valign="top">
2.14.7

    &#182;
    
p. 28
&#160;
  </TD>
<TD valign="top">
Page layout bug
&#160;
  </TD>
<TD valign="top">
Move footnote 24 from page 28 to page 27
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US17">US 17</A></TD>
<TD valign="top">
2.14.8

    &#182;
    
6
&#160;
  </TD>
<TD valign="top">
In general, the parameter type of a literal operator must be
the same as the argument passed to it. That is not the
case for a user-defined-character-literal, where the
argument could inadvertently match a literal operator
intended for use with user-defined-integer-literals:
<PRE>
typedef unsigned long long ULL;
int operator "" X(ULL);
int i = 'c'X; // operator"" X(ULL('c'))
</PRE>
&#160;
  </TD>
<TD valign="top">
Add the following phrase to the description in
paragraph 6:<BR>
S shall contain a literal operator whose parameter
type is the same as the type of ch.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1107">1107</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP17">JP 17</A></TD>
<TD valign="top">
2.14.8

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
Typo, missing ",".<BR>
If S contains a raw literal operator the literal L is treated as
&#160;
  </TD>
<TD valign="top">
Correct typo.<BR>
If S contains a raw literal operator, the literal L is
treated as
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP18">JP 18</A></TD>
<TD valign="top">
2.14.8

    &#182;
    
4
&#160;
  </TD>
<TD valign="top">
Typo, missing ",".<BR>
If S contains a raw literal operator the literal L is treated as
&#160;
  </TD>
<TD valign="top">
Correct typo.<BR>
If S contains a raw literal operator, the literal L is
treated as
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US18">US 18</A></TD>
<TD valign="top">
2.24.8 [lex.ext]
&#160;
  </TD>
<TD valign="top">
User-defined literals have no implementation experience.
&#160;
  </TD>
<TD valign="top">
Either demonstrate a complete implementation of
this feature or remove N2750 from the working
paper prior the FDIS.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1108">1108</A>&#160;
  </TD>
<TD valign="top">
(Reference should be to 2.14.8, not 2.24.8.)
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US19">US 19</A></TD>
<TD valign="top">
3

    &#182;
    
4
&#160;
  </TD>
<TD valign="top">
It is not always clear when the term "use" is intended as a
reference to the definition in 3.2 and when it has its
normal English meaning. For example, 3 paragraph 4
reads, "A name is a use of an identifier..."
&#160;
  </TD>
<TD valign="top">
Replace all occurrences of the word "use" that are
not intended as references to 3.2 with some other
term, such as "occurrence" or "appearance" or
"reference to".
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1109">1109</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3214.html">
     N3214</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US20">US 20</A></TD>
<TD valign="top">
3.1

    &#182;
    
para 1 bullet 4
&#160;
  </TD>
<TD valign="top">
Grammatical number mismatch in "an assignment
expressions".
&#160;
  </TD>
<TD valign="top">
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US21">US 21</A></TD>
<TD valign="top">
3.1

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
using N::d; does not declare N::d.
&#160;
  </TD>
<TD valign="top">
using N::d; // declares d
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US22">US 22</A></TD>
<TD valign="top">
3.2

    &#182;
    
4
&#160;
  </TD>
<TD valign="top">
The type of the expression of a decltype-specifier is
apparently required to be complete.
&#160;
  </TD>
<TD valign="top">
Make an exception so that a template
specialization type is not instantiated merely
because it's the type of the expression in
decltype( expression )
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1110">1110</A>&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
The premise is incorrect: it is the function call, not <TT>decltype</TT>,
that requires a complete type.
As described in core language issue 1110, failing to instantiate the
return type of a function could prevent plausible uses of SFINAE.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP19">JP 19</A></TD>
<TD valign="top">
3.2

    &#182;
    
4
&#160;
  </TD>
<TD valign="top">
Representations of reference link are not unified.
Most reference links to clause (table) number, say X, are
in the form "Clause X" ("Table X") capitalized, and
subsection Y.Y.Y is referenced with its number only in the
form "Y.Y.Y". Whether they are parenthesized or not
depends on the context.
However there are some notations "(Z)" consisting of only
a number Z in parentheses to confer Clause or Table
number Z.
&#160;
  </TD>
<TD valign="top">
Change "(10)" to "(Clause 10)".
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP20">JP 20</A></TD>
<TD valign="top">
3.3.2

    &#182;
    
7
&#160;
  </TD>
<TD valign="top">
Representations of reference link are not unified.
Most reference links to clause (table) number, say X, are
in the form "Clause X" ("Table X") capitalized, and
subsection Y.Y.Y is referenced with its number only in the
form "Y.Y.Y". Whether they are parenthesized or not
depends on the context.
However there are some notations "(Z)" consisting of only
a number Z in parentheses to confer Clause or Table
number Z.
&#160;
  </TD>
<TD valign="top">
Change "(9)" to "(Clause 9)".
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US23">US 23</A></TD>
<TD valign="top">
3.4.5

    &#182;
    
para 1
&#160;
  </TD>
<TD valign="top">
Global class templates should not hide member
templates.
&#160;
  </TD>
<TD valign="top">
Strike the end of para 1 starting with "If the lookup
in the class of the object expression finds a
template,". See Appendix 1 - Additional Details
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1111">1111</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US24">US 24</A></TD>
<TD valign="top">
3.5

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
One of the critieria for giving a name internal linkage is "a
variable that is explicitly declared const and neither
explicitly declared extern nor previously declared to have
external linkage." This should presumably apply to
variables declared constexpr as well.
&#160;
  </TD>
<TD valign="top">
Add parallel wording for the constexpr specifier.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1112">1112</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="DE4">DE 4</A></TD>
<TD valign="top">
3.5
&#160;
  </TD>
<TD valign="top">
It is odd that "N" has no linkage and "g" has external
linkage in this example:
<PRE>
namespace {
namespace N // has no linkage
{
void g(); // has external linkage
} }
</PRE>
&#160;
  </TD>
<TD valign="top">
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1113">1113</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="DE5">DE 5</A></TD>
<TD valign="top">
3.7.3
&#160;
  </TD>
<TD valign="top">
The term "local" was changed globally to "block-scope",
but this section still contains the term "local" (see also
core issue 642).
&#160;
  </TD>
<TD valign="top">
Change "local" to "block-scope" in the first
paragraph.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="RU3">RU 3</A></TD>
<TD valign="top">
3.7.4.3

    &#182;
    
p.65, line 7
&#160;
  </TD>
<TD valign="top">
Reference missed
&#160;
  </TD>
<TD valign="top">
Insert reference "(5.7)" after "well-define pointer
arithmetic"
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="RU4">RU 4</A></TD>
<TD valign="top">
3.7.4.3

    &#182;
    
p. 65, line 8
&#160;
  </TD>
<TD valign="top">
Reference missed
&#160;
  </TD>
<TD valign="top">
Insert references "(4.10, 5.4)" after "well-define
pointer conversion"
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB18">GB 18</A></TD>
<TD valign="top">
3.8

    &#182;
    
9
&#160;
  </TD>
<TD valign="top">
It isn't clear that the comment in the example actually
reflects the result of the placement new.
If the intended placement operator new is supposed to be
the one given by the standard library
,by including , the example is ill-formed as the placement-new
expression &amp;b is const B*
which doesn't implicitly convert to void*.
&#160;
  </TD>
<TD valign="top">
Replace:<BR>
new (&amp;b) const B;<BR>
With:<BR>
new (const_cast&lt;B*&gt;(&amp;b)) const B;
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1114">1114</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US25">US 25</A></TD>
<TD valign="top">
3.11
&#160;
  </TD>
<TD valign="top">
C/C++ compatibility problems defined in WG21/N3093.
&#160;
  </TD>
<TD valign="top">
Make the changes proposed in WG21/N3093
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1115">1115</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US26">US 26</A></TD>
<TD valign="top">
3.7.4, 5.3.5, 12.5, 17.6.3.6, 18.6
&#160;
  </TD>
<TD valign="top">
Programmers may define a static member function
operator delete that takes a size parameter indicating the
size of the object to be deleted. The equivalent global
operator delete is not available. This omission has
unfortunate performance consequences.
&#160;
  </TD>
<TD valign="top">
Permit implementations and programmers to
define sized versions of the global operator delete
for use in preference to the unsized version. See
Appendix 1 - Additional Details
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
There was no consensus for making the suggested change at this
point in the standardization process.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US27">US 27</A></TD>
<TD valign="top">
3.8

    &#182;
    
4
&#160;
  </TD>
<TD valign="top">
Related to core issue 1027, consider:
<PRE>
int f() {
union U { double d; } u1, u2;
(int&amp;)u1.d = 1;
u2 = u1;
return (int&amp;)u2.d;
}
</PRE>
Does this involve undefined behavior? 3.8/4 seems to say
that it's OK to clobber u1 with an int object. Then union
assignment copies the object representation, possibly
creating an int object in u2 and making the return
statement well-defined. If this is well-defined, compilers
are significantly limited in the assumptions they can make
about type aliasing. On the other hand, the variant where
U has an array of unsigned char member must be well-defined
in order to support std::aligned_storage.
&#160;
  </TD>
<TD valign="top">
Clarify that this testcase is undefined, but that
adding an array of unsigned char to union U would
make it well-defined--if a storage location is
allocated with a particular type, it should be
undefined to create an object in that storage if it
would be undefined to access the stored value of
the object through the allocated type.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1116">1116</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US28">US 28</A></TD>
<TD valign="top">
4.4

    &#182;
    
para 3
&#160;
  </TD>
<TD valign="top">
A const member function pointer could safely be applied
to a non-const object without violating const correctness.
&#160;
  </TD>
<TD valign="top">
Add an implicit conversion. See Appendix 1 -
Additional Details
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
There was no consensus for adding this feature at this point in the
standardization process.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="FI7">FI 7</A></TD>
<TD valign="top">
4.11 [conv.mem], 5.2.9 [expr.static.cast]
&#160;
  </TD>
<TD valign="top">
The CD1 comment CH1 should be reconsidered. The
request for being able to cast a pointer to member to a
pointer to a base class (or any other implicitly convertible
type) of the member is a bugfix rather than an extension.
It's a safe conversion, thus it should be allowed. There are
valid use cases for such conversions that are currently
forbidden.
&#160;
  </TD>
<TD valign="top">
The standard should allow implicit conversions
from &#8220;pointer to member of T of type cv D&#8221; to
'pointer to member of T of type cv B', where D is
of class type and B is a public base of D, It should
allow explicit conversion the other way around.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
There was no consensus for making this change at this point in the
standardization process.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="CH3">CH 3</A></TD>
<TD valign="top">
4.11 and 5.2.9
&#160;
  </TD>
<TD valign="top">
With respect to the target type, pointer to members should
behave like normal pointers. The current situation creates
an inconsistency in the C++ type system and is therefore
a defect in the Standard.
&#160;
  </TD>
<TD valign="top">
The standard should allow implicit conversions
from ``pointer to member of T of type cv D'' to
``pointer to member of T of type cv B'', where D is
of class type and B is a public base of D. It should
allow explicit conversion in the other direction.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
There was no consensus for making this change at this point in the
standardization process.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP21">JP 21</A></TD>
<TD valign="top">
4.13

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
Representations of reference link are not unified.
Most reference links to clause (table) number, say X, are
in the form "Clause X" ("Table X") capitalized, and
subsection Y.Y.Y is referenced with its number only in the
form "Y.Y.Y". Whether they are parenthesized or not
depends on the context.
However there are some notations "(Z)" consisting of only
a number Z in parentheses to confer Clause or Table
number Z.
&#160;
  </TD>
<TD valign="top">
Change "(5)" to "(Clause 5)".
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP1">JP 1</A></TD>
<TD valign="top">
5

    &#182;
    
Paragraph 6
&#160;
  </TD>
<TD valign="top">
The first half of the Note(before "In general") indicates
that the expression "E1.E2" produces xvalue if E1 is
xvalue regardless of E2's type. It will be true even if E2 is
of reference type. On the other hand, according to 5.2.5
paragraph 4, if E2 is of reference type, the result of
"E1.E2" is lvalue regardless of E1's type. These two
descriptions contradict each other. As 5.2.5 paragraph 4
seems correct, 5 paragraph 6 should be corrected.
&#160;
  </TD>
<TD valign="top">
Modify 5 paragraph 6 so that the result of E1.E2 is
lvalue instead of xvalue when E2 is of reference
type.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1117">1117</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="FI8">FI 8</A></TD>
<TD valign="top">
5.1.2 [expr.prim.lambda]
&#160;
  </TD>
<TD valign="top">
As requested in JP 9 on CD, capturing by moving should
be allowed for lambdas. Roshan Naik presents a very
compelling use case in the Core Reflector message
c++std-core-16341.
&#160;
  </TD>
<TD valign="top">
Allow specifying capture by move.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
There was no consensus for making the suggested change at this point
in the standardization process.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="CH4">CH 4</A></TD>
<TD valign="top">
5.1.2

    &#182;
    
p1
&#160;
  </TD>
<TD valign="top">
Document N3067 changed the position of attribute
specifiers in various places. However, it left out lambda
expressions as an oversight, so that the position of
attribute-specifier opt in a lambda-declarator is
inconsistent with a function declarator
&#160;
  </TD>
<TD valign="top">
change the rule for lambda-declarator to<BR>
lambda-declarator:<BR>
( parameter-declaration-clause ) mutableopt
exception-specificationopt attribute-specifieropt
trailing-return-typeopt
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1062">1062</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="CH5">CH 5</A></TD>
<TD valign="top">
5.1.2

    &#182;
    
p4 first bullet
&#160;
  </TD>
<TD valign="top">
typo
&#160;
  </TD>
<TD valign="top">
Change second 'if' to 'is'.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US29">US 29</A></TD>
<TD valign="top">
5.1.2

    &#182;
    
5
&#160;
  </TD>
<TD valign="top">
default arguments should be allowed in lambdas (core
issue 974)
&#160;
  </TD>
<TD valign="top">
See Appendix 1 - Additional Details
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#974">974</A>&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
There was no consensus for making the suggested change at this point in
the standardization process.  However, core language issue 974 remains
open for consideration in a future revision.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US30">US 30</A></TD>
<TD valign="top">
5.1.2

    &#182;
    
4
&#160;
  </TD>
<TD valign="top">
lambda return type deduction should allow arbitrary
function structure (core issue 975)
&#160;
  </TD>
<TD valign="top">
See Appendix 1 - Additional Details
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#975">975</A>&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
There was no consensus for making the suggested change at this point in
the standardization process.  However, core language issue 975 remains
open for consideration in a future revision.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP22">JP 22</A></TD>
<TD valign="top">
5.1.2

    &#182;
    
7
&#160;
  </TD>
<TD valign="top">
Representations of reference link are not unified.
Most reference links to clause (table) number, say X, are
in the form "Clause X" ("Table X") capitalized, and
subsection Y.Y.Y is referenced with its number only in the
form "Y.Y.Y". Whether they are parenthesized or not
depends on the context.
However there are some notations "(Z)" consisting of only
a number Z in parentheses to confer Clause or Table
number Z.
&#160;
  </TD>
<TD valign="top">
Change "(5)" to "(Clause 5)".
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="CH6">CH 6</A></TD>
<TD valign="top">
5.1.2

    &#182;
    
p8 and p10
&#160;
  </TD>
<TD valign="top">
The current capturing rules seem too restrictive.
&#160;
  </TD>
<TD valign="top">
Consider to make those rules less restrictive.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
The comment made no specific suggestions for change.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB19">GB 19</A></TD>
<TD valign="top">
5.1.2

    &#182;
    
16
&#160;
  </TD>
<TD valign="top">
[expr.prim.lambda] 5.1.2/16 has text which begins "If a
lambda-expression m1 captures an entity and that entity is
captured by an immediately enclosing lambda expression
m2..." - that is, it describes a situation with m2 enclosing
m1, and then describes the capture transformation in
these terms.
The example given to support this, however, turns this all
around and shows m1 enclosing m2. This doesn't make
either the text or the example incorrect in any sense, but I
would suggest that it adds a level of confusion that is
easily avoided.
&#160;
  </TD>
<TD valign="top">
All references to m1 from the beginning of
5.1.2/16 up to the last occurrence before
'[Example ' to be replaced by m2, and vice versa.
Rationale for suggested wording: all other
examples that use the 'mN' notation for lambda
expressions and which involve nesting apply
increasing N (by 1, from 1) to indicate increasing
nesting depth.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB20">GB 20</A></TD>
<TD valign="top">
5.1.2

    &#182;
    
12
&#160;
  </TD>
<TD valign="top">
[expr.prim.lambda] 5.1.2/12. In the example code given
the local struct s1 has a member function with signature
int s1::work(int n) whose definition does not include an
appropriate return statement; neither does it include the
conventional "// ..." to indicate that the example is
intended to be incomplete.
&#160;
  </TD>
<TD valign="top">
Suggested change: change the signature of this
member function to void s1::work(int n), as the
return of int does not contribute to the example.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB21">GB 21</A></TD>
<TD valign="top">
5.1.2
&#160;
  </TD>
<TD valign="top">
A lambda-capture can be &amp;, which indicates it captures
everything by reference (unless otherwise specified), or &amp;
/identifier/, which indicates it captures the /identifier/ by
reference. It can also be =, to capture everything by value,
or /identifier/, for a single thing. Why is = /identifier/ not
allowed, for consistency?
&#160;
  </TD>
<TD valign="top">
Add "= identifier" to the grammar in 5.1.2p1. (The
wording already covers the semantics of this,
since it refers to captures that "are preceded by &amp;"
or "do not contain &amp;")
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
There was no consensus for making the suggested change.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="FI19">FI 19</A></TD>
<TD valign="top">
5.1.2 [expr.prim.lambda]

    &#182;
    
21
&#160;
  </TD>
<TD valign="top">
&#8220;When the lambda-expression is evaluated, the entities
that are captured by copy are used to direct-initialize each
corresponding non-static data member of the resulting
closure object.&#8221; This apparently means that if the capture-default
is to copy, entities captured by default, implicitly,
are copied even in cases where the copy constructors of
such entities are explicit.
&#160;
  </TD>
<TD valign="top">
Don't implicitly copy entities that have explicit copy
constructors declared. Require that such entities
be captured explicitly, by enumerating them in the
capture list. This seems related to Core Issue
1020, so I'd like that issue to be resolved as well.
See Appendix 1 - Additional Details
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1118">1118</A>&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
There was no consensus for the suggested change.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB23">GB 23</A></TD>
<TD valign="top">
5.2.2

    &#182;
    
4
&#160;
  </TD>
<TD valign="top">
Order of initialization of arguments in a function is
fundamental to the memory model of C++, and the
obvious place to look for the definition is in the clause
defining function call operators - which currently says
nothing. The rules covering this are buried in paragraph
15 of [1.9]. A cross-reference to these words would be
most helpful. In particular, it should be made clear that
such initialization is indeterminately sequenced (and not
unsequenced.)
&#160;
  </TD>
<TD valign="top">
Add a non-normative note with cross-reference
after the first sentance of paragraph 4: "[Note -
such initializations are indeterminately sequenced
with respect to each other [1.9] - end note]"
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US31">US 31</A></TD>
<TD valign="top">
5.2.9;7.2

    &#182;
    
10
&#160;
  </TD>
<TD valign="top">
it is unclear from the text in 7.2 and 5.2.9 that the "values
of the enumeration" term does not exclude a prvalue of an
enumeration type from having other values representable
in its underlying type (c++std-core-15652).
&#160;
  </TD>
<TD valign="top">
clarify this. "The value is unchanged if it is in the
range of enumeration values of the enumeration
type; otherwise the resulting <del>enumeration</del> value is
unspecified <ins>(and might not be in that range)</ins>."
Also add a note after paragraph 7 "[Footnote: this
set of values is used to define promotion and
conversion semantics for the enumeration type; it
does not exclude an expression of enumeration
type from having a value that falls outside this
range.]"
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1022">1022</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US32">US 32</A></TD>
<TD valign="top">
5.2.5

    &#182;
    
5
&#160;
  </TD>
<TD valign="top">
The description of ambiguity ("...if the class of which E2 is
directly a member is an ambiguous base (10.2) of the
naming class (11.2) of E2") does not cover the following
case:
<PRE>
struct A { int i; };
struct B: A { };
struct C: A, B { };
void f(C* p) {
p-&gt;i; // Should be ambiguous
}
</PRE>
&#160;
  </TD>
<TD valign="top">
Change the wording to apply also to the case
when the naming class is an ambiguous base of
the class of the object expression.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1119">1119</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP64">JP 64</A></TD>
<TD valign="top">
5.2.8

    &#182;
    
5
&#160;
  </TD>
<TD valign="top">
In some code examples, ellipsis(...) is used in ill-formed.
In these cases, "..." represents omission of some codes
like this:<BR>
class A { /* ... */ } ;<BR>
But in some cases, it is used without commented-out as
below:<BR>
class A { ... } ;<BR>
It is an inconsistent usage. They all should be enclosed in
a comment.
&#160;
  </TD>
<TD valign="top">
Change to:<BR>
class D { /* ... */ };
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB22">GB 22</A></TD>
<TD valign="top">
5.2.10
&#160;
  </TD>
<TD valign="top">
It is not legal to use reinterpret_cast&lt;&gt; with pointers to
void.
&#160;
  </TD>
<TD valign="top">
Here's an additional paragraph to add to 5.2.10
that would fix this:<BR>
* A pointer to an object type can be explicitly
converted to a pointer to void, and vice versa.[1]
The result of such a pointer conversion will have
the same result as the standard pointer
conversion described in 4.10. A value of type
&#8220;pointer to object&#8221; converted to &#8220;pointer to void&#8221;
and back, possibly with different cv-qualification,
shall have its original value.<BR>
[1] The types may have different cv-qualifiers,
subject to the overall restriction that a
reinterpret_cast cannot cast away constness.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1120">1120</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US33">US 33</A></TD>
<TD valign="top">
5.3.1

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
The resolution of issue 983 added an error for finding the
named member in an ambiguous base. This is an
unnecessary special case, since the value of the
expression is pointer to member of base. If this value is
then converted to pointer to member of derived, an error
will be given at that point.
&#160;
  </TD>
<TD valign="top">
Revert the change for issue 983 (and in the issues
list, add a link to issue 203).
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1121">1121</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB24">GB 24</A></TD>
<TD valign="top">
5.3.3

    &#182;
    
6
&#160;
  </TD>
<TD valign="top">
The return type of the sizeof operator is defined as being
of type std::size_t, defined in library clause 18.2. This, in
turn, says that size_t is defined in the C standard, which in
turn says that size_t is defined as the type of the result of
the sizeof operator!
The C definition of sizeof returns an implementation-defined
unsigned integer type, recommended not to have
"an integer conversion rank greater than signed long int,
unless the implementation supports objects large enough
to make this necessary."
&#160;
  </TD>
<TD valign="top">
The result type of the sizeof operator should
explicitly be implementation defined in clause
5.3.3.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1122">1122</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US34">US 34</A></TD>
<TD valign="top">
5.3.4, 5.3.5
&#160;
  </TD>
<TD valign="top">
Allocations functions are missing happens-before
requirements and guarantees.
&#160;
  </TD>
<TD valign="top">
Add requirements. See Appendix 1 - Additional
Details
&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US35">US 35</A></TD>
<TD valign="top">
5.3.7

    &#182;
    
[expr.unary.noexcept], 15.4 [except.spec]
&#160;
  </TD>
<TD valign="top">
noexcept has no implementation experience.
&#160;
  </TD>
<TD valign="top">
Either demonstrate a complete implementation of
this feature or remove N3050 from the working
paper prior the FDIS.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
The feature has been implemented.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="FI17">FI 17</A></TD>
<TD valign="top">
5.3.7 [expr.unary.noexcept]
&#160;
  </TD>
<TD valign="top">
Destructors should by default be noexcept. Such a rule
should, I think, be obeyed even for cases where a
destructor is defaulted. Then a throwing destructor would
need to be declared noexcept(false), and I think the
resulting code breakage is acceptable.
&#160;
  </TD>
<TD valign="top">
Clarify the implicit generation rules and defaulting
rules so that destructors are noexcept unless
explicitly declared noexcept(false).
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1123">1123</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
The rule that was adopted makes destructors noexcept if all the base
and member destructors are.
<BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3204.html">
     N3204</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP2">JP 2</A></TD>
<TD valign="top">
5.5

    &#182;
    
6
&#160;
  </TD>
<TD valign="top">
Should be corrected because it contradicts with rules in
5.2.5 paragraph 4.
&#160;
  </TD>
<TD valign="top">
Add the condition that a type of e2 is not a
reference type
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1124">1124</A>&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
There are no pointers to members of reference type (8.3.3p3).
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US36">US 36</A></TD>
<TD valign="top">
5.19 [expr.const]
&#160;
  </TD>
<TD valign="top">
Generalized constant expressions have no
implementation experience.
&#160;
  </TD>
<TD valign="top">
Either demonstrate a complete implementation of
this feature or remove N2235 from the working
paper prior the FDIS.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
An implementation is in progress and is expected to be complete before
the publication of the FDIS. Also, this feature is needed in the Standard
library and thus should not be removed.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="DE7">DE 7</A></TD>
<TD valign="top">
5.19

    &#182;
    
4, note
&#160;
  </TD>
<TD valign="top">
The note in paragraph 4 alludes to the possibility that
compile-time and run-time evaluations of floating-point
expressions might yield different results. There is no clear
normative statement (other than the absence of a
restriction) that gives such permission.
&#160;
  </TD>
<TD valign="top">
Move the second sentence of the note into
normative text.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
The possibility of differing results of calculations is implicit in
the absence of normative statements constraining their accuracy, so
no normative change is needed; the existing note is sufficient to
point out this implication.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="DE8">DE 8</A></TD>
<TD valign="top">
5.19

    &#182;
    
6
&#160;
  </TD>
<TD valign="top">
In the definition of "potential constant expression" in
paragraph 6, it is unclear how "arbitrary" the substitution
of the function parameters is. Does it mean "there exists a
value for which the result is a constant expression" or
does it mean "for all possible values, the result needs to
be a constant expression"? Example:
<PRE>
constexpr int f(int x){return x + 1; }
</PRE>
is a constant expression under the first interpretation, but
not under the second (because overflow occurs for x ==
INT_MAX, cf. 5.19p2 bullet 5). The answer also affects
expressions such as:
<PRE>
constexpr int f2(bool v) { return v ? throw 0 : 0; }
constexpr int f3(bool v) { return v &amp;&amp; (throw 0, 0); }
</PRE>
&#160;
  </TD>
<TD valign="top">
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1125">1125</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3218.html">
     N3218</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB25">GB 25</A></TD>
<TD valign="top">
5.19
&#160;
  </TD>
<TD valign="top">
In trying to pin down the behaviour of constexpr functions,
it became apparent that there is disagreement over
whether or not the following example is well-formed.
<PRE>
constexpr int f() { return 42 + 84; }
const int sz = f();
int a[sz];
</PRE>
This should have the same effect as
<PRE>
const int sz = 42 + 84;
int a[sz];
</PRE>
otherwise constexpr functions are broken.
&#160;
  </TD>
<TD valign="top">
Update the wording in 5.19 to make it clear that
both the examples are valid.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1126">1126</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB26">GB 26</A></TD>
<TD valign="top">
5.19
&#160;
  </TD>
<TD valign="top">
It is not clear how overload resolution applies within a
constexpr function. In particular, if an expression in the
function body yields an integral value of 0 for some
parameter values, and not for others, is it usable as a null
pointer constant when evaluated as a constant
expression.
<PRE>
typedef char (&amp;One)[1];
typedef char (&amp;Two)[2];
One f(void*); // #1
Two f(...); // #2
constexpr int test(int n) { return sizeof f(n); }
constexpr int test2(int n) { return sizeof f(n*0); }
int q = 0;
#include
int main() {
char a[test(0)];
std::cout &lt;&lt; sizeof(a) &lt;&lt; std::endl; // #3
std::cout &lt;&lt; test(q) &lt;&lt; std::endl; // #4
char b[test2(0)];
std::cout &lt;&lt; sizeof(b) &lt;&lt; std::endl; // #5
std::cout &lt;&lt; test2(q) &lt;&lt; std::endl; // #6
}
</PRE>
#3 and #4 should print 2, since n is not an integral
constant expression with value 0 in the body of test() ---
though it is a constant expression when test() is evaluated
as a constant expression, it's value is dependent on the
invocation. Permitting different results of overload
resolution within the same function body in different calling
contexts would violate ODR.<BR>
On the other hand, in test2(), the answer is no longer
dependent on the value of n, since "n*0" always evaluates
to 0. However, it is not clear from the FCD whether "n*0"
is thus a constant expression (and therefore a valid null
pointer constant) inside the body of test2. Either way both
#5 and #6 should print the same value; it would violate
ODR for #5 to print "1" (indicating that "n*0" was a valid
null pointer constant when test2() is evaluated in a
constant expression context) whilst #6 prints "2" (since
n*0 is not a constant expression if n is not constant). #5
and #6 should thus both print "1", or both print "2".
&#160;
  </TD>
<TD valign="top">
Updated 5.19 to make it clear that overload
resolution in a constexpr function is not dependent
on the context of use, or the value of the
arguments.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1127">1127</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US37">US 37</A></TD>
<TD valign="top">
6.5
&#160;
  </TD>
<TD valign="top">
"for (auto e : range)" creates copies of elements. This
seems like a gotcha for new users. Not only are copies
inefficient for reading, but writing to copies won't modify
the original elements.<BR>
Permitting "for ( identifier : expression )" and giving it the
same meaning as "for ( auto&amp; identifier : expression )"
would make the range-based for statement easier to teach
and to use, and should be trivial to specify and to
implement.
&#160;
  </TD>
<TD valign="top">
Permit "for ( identifier : expression )" or similar,
with the same meaning as "for ( auto&amp; identifier :
expression )".
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
There was no consensus for making the suggested change at this point
in the standardization process.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="CA3">CA 3</A></TD>
<TD valign="top">
Various

    &#182;
    
various
&#160;
  </TD>
<TD valign="top">
Canada agrees with US 37, 44, 47, 85, 77, 92, 97, 102,
105, 109
&#160;
  </TD>
<TD valign="top">
Resolve as suggested in these comments
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US38">US 38</A></TD>
<TD valign="top">
6.5 5
&#160;
  </TD>
<TD valign="top">
The statement that certain infinite loops may be assumed
to terminate should also apply to go-to loops and possibly
infinite recursion. We expect that compiler analyses that
would take advantage of this can often no longer identify
the origin of such a loop.
&#160;
  </TD>
<TD valign="top">
As a strawman, replace the paragraph with<BR>
"The implementation may assume that any
program will eventually do one of the following:<BR>
- terminate,<BR>
- make a call to a library I/O function,<BR>
- access or modify a volatile object, or<BR>
- perform a synchronization operation (1.10) or
atomic operation (Clause 29)."<BR>
Possibly move this and the attached note to
section 1.9, after p8.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3196.html">
     N3196</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP69">JP 69</A></TD>
<TD valign="top">
6.35.1

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
Constant width font should be used for 3 "while"s in the
paragraph as described in Syntax notation (1.6).
&#160;
  </TD>
<TD valign="top">
Change the font for "while" to constant width type.
When the condition of a while statement is a
declaration, the scope of the variable that is
declared extends
from its point of declaration (3.3.2) to the end of
the while statement. A while statement of the
form
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB27">GB 27</A></TD>
<TD valign="top">
6.5.4p1
&#160;
  </TD>
<TD valign="top">
6.5.4/1 requires that range-based for loops behave as if
they had "{ auto&amp;&amp; __range = (expression); for (auto
__begin = begin_expr, __end = end_expr; ..." which
implies that __begin and __end must have the same type.
However, this prevents stateful iterators with an end
sentinel of a different type. Since range-based for loops'
equivalent code already introduces a block (for the
__range variable), could __begin and __end be placed
there, as "auto __begin = begin_expr; auto __end =
end_expr;"?<BR>
Example of what this change would allow, only the
relevant details shown with ctors, op*, op++, etc. omitted:
(apologies if the formatting is lost)<BR>
struct End {}; struct Counter { Counter&amp; begin() { return
*this; } // used by begin_expr End end() { return End(); } //
used by end_expr bool operator!=(End) const { return
_current != _end; }<BR>
Counter(int begin, int end) : _current(begin), _end(end) {}
int _current, _end; };<BR>
void use_example() { for (auto n : Counter(0, 10)) { // n
takes values from 0..9 } }
&#160;
  </TD>
<TD valign="top">
Change the "as if" for a range-based for-loop in
6.5.4p1 to move the initialization of __begin and
__end outside the loop into the enclosing block:
<PRE>
{ auto&amp;&amp; __range = (expression);
auto __begin = begin_expr; auto __end =
end_expr;
for (; ...
</PRE>
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
There was no consensus for making the suggested change. Use of iterators
of different types is incompatible with the Standard library containers
and with the earlier concepts-based specification.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="CH7">CH 7</A></TD>
<TD valign="top">
6.5.4

    &#182;
    
p1
&#160;
  </TD>
<TD valign="top">
The phrasing "is equivalent to" is too restrictive and might
constrain future improvements.
&#160;
  </TD>
<TD valign="top">
Make clear that the specification is not necessarily
the implementation, i.e. that the expressions in the
specification are not necessarily called at all and
that the order in which the statement is executed
for different values of for-range-declaration is not
necessarily the same as if the for loop would have
been written the way in the specification.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
There was no consensus for making the suggested change. The Standard
needs to specify the meaning of the statement; removing the
&#8220;equivalent to&#8221; phrasing would leave the feature underspecified.
Implementations have a good deal of latitude under the &#8220;as-if&#8221;
rule.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB28">GB 28</A></TD>
<TD valign="top">
7

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
"Attributes" is misspelled
&#160;
  </TD>
<TD valign="top">
Replace "Atrributes" with "Attributes"
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US39">US 39</A></TD>
<TD valign="top">
7.1

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
The current wording is, "The optional attribute-specifier in
a decl-specifier-seq appertains to the type determined by
the decl-specifier-seq." However, the rule for decl-specifier-seq
in the grammar is recursive, and the intent is
for the attribute-specifier to appertain to the top decl-specifier-seq,
not the one in which the attribute-specifier
directly appears.
&#160;
  </TD>
<TD valign="top">
Change the wording to indicate that the complete
or outermost decl-specifier-seq is intended.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1128">1128</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB29">GB 29</A></TD>
<TD valign="top">
7.1.5
&#160;
  </TD>
<TD valign="top">
A constexpr function is not permitted to return via an
exception. This should be recognised, and a function
declared 'constexpr' without an explicit exception
specification should be treated as if declared
'noexcept(true)' rather than the usual 'noexcept(false)'. For
a function template declared constexpr without an explicit
exception specification, it should be considered
'noexcept(true)' if and only if the constexpr keyword is
respected on a given instantiation.
&#160;
  </TD>
<TD valign="top">
Give constexpr functions an implicit non-throwing
exception specification.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1129">1129</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
The premise is not correct: an exception is forbidden only when a
<TT>constexpr</TT> function is invoked in a context that requires
a constant expression. Used as an ordinary function, it can throw.
Instead of changing the default exception specification, the result
of the <TT>noexcept</TT> operator was changed, based on whether the
invocation of the function is a constant expression or not.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US40">US 40</A></TD>
<TD valign="top">
7.1.6.2

    &#182;
    
4
&#160;
  </TD>
<TD valign="top">
The description of decltype does not specify whether the
type of a parameter is the declared type or the type as
adjusted in 8.3.5p5:
<PRE>
auto f(int a[])-&gt;decltype(a);
// ill-formed or int*?
auto g(const int i)-&gt;decltype(i);
// int or const int?
</PRE>
&#160;
  </TD>
<TD valign="top">
Clarify the wording to indicate that the type of a
parameter is after the array- and function-to-pointer
decay but before the removal of cv-qualification.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1130">1130</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="DE9">DE 9</A></TD>
<TD valign="top">
7.1.6.2

    &#182;
    
p4
&#160;
  </TD>
<TD valign="top">
decltype applied to a function call expression requires a
complete type (5.2.2 paragraph 3 and 3.2 paragraph 4),
even though decltype's result might be used in a way that
does not actually require a complete type. This might
cause undesired and excessive template instantiations.
&#160;
  </TD>
<TD valign="top">
When immediately applying decltype, do not
require a complete type, for example for the return
type of a function call.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1110">1110</A>&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
As described in core language issue 1110, failing to instantiate the
return type of a function could prevent plausible uses of SFINAE.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US41">US 41</A></TD>
<TD valign="top">
7.1.6.3

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
The current wording disallows use of typedef-names in
elaborated-type-specifiers. This prohibition should also
apply to template aliases:
<PRE>
struct A { };
template&lt;typename T&gt; using X = A;
struct X&lt;int&gt;* p2; // ill-formed
</PRE>
&#160;
  </TD>
<TD valign="top">
Add the necessary wording to prohibit a
specialization of a template alias in an elaborated-type-specifier.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1131">1131</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US42">US 42</A></TD>
<TD valign="top">
7.1.6.4
&#160;
  </TD>
<TD valign="top">
The overloaded meaning of the auto specifier is confusing
and prevents possible future language enhancements.
&#160;
  </TD>
<TD valign="top">
Choose another keyword to indicate a late-specified
return type. The identifiers lateret and
postret have no Google code search hits. The
identifiers late, latetype, and posttype have 30-40
hits.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
There was no consensus to make the suggested change.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US43">US 43</A></TD>
<TD valign="top">
7.6

    &#182;
    
4
&#160;
  </TD>
<TD valign="top">
The contexts in which an attribute-specifier can appear
include statements, described in clause 6, but the crossreferences
to clauses describing those contexts do not
include clause 6.
&#160;
  </TD>
<TD valign="top">
Add clause 6 to the list of cross-references in the
first sentence.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB30">GB 30</A></TD>
<TD valign="top">
7.6.1

    &#182;
    
6
&#160;
  </TD>
<TD valign="top">
Making the use of [[ illegal except where introducing an
attribute specifier is just reintroducing the problem we had
with &gt;&gt; for closing nested templates, albeit in a minor and
less common form.
As Jason Merrill commented in c++std-core-16046, there
is no ambiguity in practice because code couldn't actually
be well-formed under interpretation as both an attribute
specifier and a lambda introducer. A small amount of
lookahead would be required to differentiate the cases,
but this should not be a problem.
This restriction also means that lambdas in macros must
be enclosed in parentheses to avoid accidental
interpretation as an illegal attribute specifier if used as an
array index.
&#160;
  </TD>
<TD valign="top">
Delete 7.6.1 paragraph 6.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
There was no consensus for reconsidering the previous explicit
decision of the Committee on this issue.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP23">JP 23</A></TD>
<TD valign="top">
7.6.1

    &#182;
    
4
&#160;
  </TD>
<TD valign="top">
Representations of reference link are not unified.
Most reference links to clause (table) number, say X, are
in the form "Clause X" ("Table X") capitalized, and
subsection Y.Y.Y is referenced with its number only in the
form "Y.Y.Y". Whether they are parenthesized or not
depends on the context.
However there are some notations "(Z)" consisting of only
a number Z in parentheses to confer Clause or Table
number Z.
&#160;
  </TD>
<TD valign="top">
Change "(clause 7, clause 8)" to "(Clause 7,
Clause 8)".
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB31">GB 31</A></TD>
<TD valign="top">
7.6.2
&#160;
  </TD>
<TD valign="top">
After reviewing the case for attributes, wg14 has opted not
to adopt this feature, and is instead using keywords for the
few important cases identified in the attributes proposal.
For compatibility with C, the change of the 'alignas'
keyword to the '[[align]]' attribute should be reversed.
&#160;
  </TD>
<TD valign="top">
Revert the changes in the initial alignment
proposal that changed the 'alignas' keyword into
an attribute.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1115">1115</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3190.html">
     N3190</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB32">GB 32</A></TD>
<TD valign="top">
7.6.3
&#160;
  </TD>
<TD valign="top">
C has rejected the notion of attributes, and introduced the
noreturn facility as a keyword. To continue writing clean,
portable code we should replace the [[noreturn]] attribute
with a 'noreturn' keyword, following the usual convention
that while C obfuscates new keywords with _Capital and
adds a macro to map to the comfortable spelling, C++
simply adopts the all-lowercase spelling.
&#160;
  </TD>
<TD valign="top">
Replace the [[noreturn]] attribute with a new
keyword, 'noreturn', with identical semantics. Note
that this implies the keyword will not be something
that a function can be overloaded upon.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1132">1132</A>&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
There was no consensus to make the suggested change.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US44">US 44</A></TD>
<TD valign="top">
7.6.5
&#160;
  </TD>
<TD valign="top">
Even if attributes continue to be standardized over
continued objections from both of the two vendors who
are cited as the principal prior art, we can live with them
with the exception of the virtual override controls. This
result is just awful, as already shown in the example in
7.6.5 (excerpted):
<PRE>
class D [[base_check]] : public B {
void sone_func [[override]] ();
virtual void h [[ hiding]] (char*);
};
</PRE>
Here we have six keywords (not counting void and char)
three normal keywords, and three [[decorated]]
keywords. There has already been public ridicule of
C++0x about this ugliness. This is just a poor language
design, even in the face of backward compatibility
concerns (e.g., that some existing code may already use
those words as identifiers) because those concerns have
already been resolved in other ways in existing practice
(see below)<BR>
More importantly, this is exactly the abuse of attributes as
disguised keywords that was objected to and was
explicitly promised not to happen in order to get this
proposal passed. The use of attributes for the virtual
control keywords is the most egregious abuse of the
attribute syntax, and at least that use of attributes must be
fixed by replacing them with non-attribute syntax.
These virtual override controls are language features, not
annotations.<BR>
It is possible to have nice names and no conflicts with
existing code by using contextual keywords, such as
recognizing the word as having the special meaning when
it appears in a grammar position where no user identifier
can appear, as demonstrated in C++/CLI which has five
years of actual field experience with a large number of
customers (and exactly no name conflict or programmer
confusion problems reported in the field during the five
years this has been available):
<PRE>
class D : public B {
void sone_func() override; // same meaning as
[[override]] - explicit override
virtual void h (char*) new; // same meaning as
[[hiding]] - a new function, not an override
};
int override = 42; // ok, override is not a
reserved keyword
</PRE>
The above forms are implementable, have been
implemented, have years of practical field experience, and
work. Developers love them. Whether the answer is to
follow this existing practice or something else, there needs
to be a more natural replacement for the currently
[[attributed]] keywords for virtual override control which is
an ugly novelty that has no field experience and that
developers have already ridiculed.
&#160;
  </TD>
<TD valign="top">
Change the syntax for virtual override control to
not use attributes.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1133">1133</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3206.html">
     N3206</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US45">US 45</A></TD>
<TD valign="top">
7.6.5

    &#182;
    
6
&#160;
  </TD>
<TD valign="top">
The example includes a line reading
<PRE>
class D [[base_check]] : public B {
</PRE>
However, the current syntax in 9p1 places the attribute-specifier
before the class name.
&#160;
  </TD>
<TD valign="top">
Change the example to read
<PRE>
class [[base_check]] D : public B {
</PRE>
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="CH8">CH 8</A></TD>
<TD valign="top">
8.1

    &#182;
    
p1 (syntax)
&#160;
  </TD>
<TD valign="top">
'noptr-abstract-declarator:' rule misses 'opt' subscript from
the constant expression within the array brackets. This
seems to be an editorial oversight
&#160;
  </TD>
<TD valign="top">
change: "noptr-abstract-declarator<SUB>opt</SUB> [ constant-expression
] attribute-specifier<SUB>opt</SUB>"<BR>
to<BR>
"noptrabstract-declarator<SUB>opt</SUB> [ constant-expression<SUB>opt</SUB> ]
attribute-specifier<SUB>opt</SUB>"
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US46">US 46</A></TD>
<TD valign="top">
8.3.2 20.7.6.2

    &#182;
    
all Table 49
&#160;
  </TD>
<TD valign="top">
There is no way to create a prvalue of array type, so there
ought to be no way create a (nonsensical) rvalue
reference to array type.
&#160;
  </TD>
<TD valign="top">
In [dcl.ref]/2, disallow declarations of T (&amp;&amp;A)[].<BR>
In [dec.ref]/6 add a sentence: <ins>If a typedef, a type
template-parameter, or a decltype-specifier
denotes a type A that is an array type (of known or
unknown size), an attempt to create the type
&#8220;rvalue reference to cv A&#8221; creates the type A&amp;.</ins><BR>
In [meta.trans.ref]/Table 49 change the third row
as follows:<BR>
If <ins>T names an array type, then the member
typedef type shall name T&amp;, otherwise if</ins> T names
an object or function type...
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
It is possible to create an array prvalue: an array member of a class
prvalue is an array prvalue.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB33">GB 33</A></TD>
<TD valign="top">
8.3.5

    &#182;
    
5
&#160;
  </TD>
<TD valign="top">
The register keyword is deprecated, so does not make for
a good example. Suggest substituting the new storage
class specifier, 'thread_local', instead.
&#160;
  </TD>
<TD valign="top">
Use 'thread_local' in place of 'register' in the
following sentance: "[ Example: register char*
becomes char* end example ]"
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1130">1130</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
<TT>thread_local</TT> cannot be used for a parameter. However,
storage class specifiers do not affect the type, so mentioning
storage class specifiers was incorrect and has been removed.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US47">US 47</A></TD>
<TD valign="top">
8.4.2
&#160;
  </TD>
<TD valign="top">
8.4.2 [dcl.fct.def.default]/4 says: "A special member
function is user-provided if it is user-declared and not
explicitly defaulted on its first declaration. A user-provided
explicitly-defaulted function is..." The second sentence
here should say "A user-declared explicitly-defaulted
function is...".
&#160;
  </TD>
<TD valign="top">
Change<BR>
"A user-provided explicitly-defaulted function is..."<BR>
to<BR>
"A user-declared explicitly-defaulted function is...".
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1134">1134</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB34">GB 34</A></TD>
<TD valign="top">
8.4.2

    &#182;
    
p2
&#160;
  </TD>
<TD valign="top">
It is confusing when a normative paragraph starts with a
note. The note starting this paragraph, with its reference
to 'this' relating to the previous paragraph and not the
content that follows, should be moved into the first
paragraph, or the rest of this paragraph after the note
should start a new numbered paragraph.
&#160;
  </TD>
<TD valign="top">
The note starting this paragraph should be moved
into the first paragraph, or the rest of this
paragraph after the note should start a new
numbered paragraph.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="FI1">FI 1</A></TD>
<TD valign="top">
8.4.2 [dcl.fct.def.default]

    &#182;
    
Paragraph 2
&#160;
  </TD>
<TD valign="top">
It should be allowed to explicitly default a non-public
special member function on its first declaration. It is very
likely that users will want to default protected/private
constructors and copy constructors without having to write
such defaulting outside the class.
&#160;
  </TD>
<TD valign="top">
Strike the &#8220;it shall be public&#8221; bullet.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1135">1135</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="FI2">FI 2</A></TD>
<TD valign="top">
8.4.2 [dcl.fct.def.default]

    &#182;
    
Paragraph 2
&#160;
  </TD>
<TD valign="top">
It should be allowed to explicitly default an explicit special
member function on its first declaration. It is very likely
that users will want to default explicit copy constructors
without having to write such defaulting outside of the
class.
&#160;
  </TD>
<TD valign="top">
Strike the &#8220;it shall not be explicit&#8221; bullet.
See Appendix 1 - Additional Details
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1136">1136</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="FI3">FI 3</A></TD>
<TD valign="top">
8.4.2 [dcl.fct.def.default]

    &#182;
    
Paragraph 2
&#160;
  </TD>
<TD valign="top">
It should be allowed to explicitly default a virtual special
member function on its first declaration. It is very likely
that users will want to default virtual copy assignment
operators and destructors without having to write such
defaulting outside of the class.
&#160;
  </TD>
<TD valign="top">
Strike the &#8220;it shall not be virtual&#8221; bullet.
See Appendix 1 - Additional Details
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1137">1137</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB35">GB 35</A></TD>
<TD valign="top">
8.5.1

    &#182;
    
7
&#160;
  </TD>
<TD valign="top">
With the removal of the deprecated string-literal-to-nonconst-char*
conversion, member 'b' of struct S should be
declared as a 'const' char *.
&#160;
  </TD>
<TD valign="top">
Fix struct S as: "struct S { int a; const char* b; int
c; };"
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP71">JP 71</A></TD>
<TD valign="top">
8.5.1

    &#182;
    
7
&#160;
  </TD>
<TD valign="top">
"char*" should be "const char *".<BR>
The special rule to convert character literal to pointer has
been removed from "4.2 Array-to-pointer conversion
[conv.array]".
<PRE>
char * p1 = "..." ; // ill-formed.(removing const'ness)
char const *p2 = "..." ;// well-formed.
</PRE>
There are many code fragments depending on the
removed rule. They are ill-formed.
&#160;
  </TD>
<TD valign="top">
Change to:
<PRE>
struct S { int a; const char* b; int c; };
S ss = { 1, "asdf" };
</PRE>
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP72">JP 72</A></TD>
<TD valign="top">
8.5.1

    &#182;
    
15
&#160;
  </TD>
<TD valign="top">
"char*" should be "const char *".<BR>
The special rule to convert character literal to pointer has
been removed from "4.2 Array-to-pointer conversion
[conv.array]".
<PRE>
char * p1 = "..." ; // ill-formed.(removing const'ness)
char const *p2 = "..." ;// well-formed.
</PRE>
There are many code fragments depending on the
removed rule. They are ill-formed.
&#160;
  </TD>
<TD valign="top">
Change to:
<PRE>
union u { int a; const char* b; };
u a = { 1 };
u b = a;
u c = 1; // error
u d = { 0, "asdf" }; // error
u e = { "asdf" }; // error
</PRE>
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB36">GB 36</A></TD>
<TD valign="top">
8.5.1

    &#182;
    
17
&#160;
  </TD>
<TD valign="top">
The 'b' member of union u should be declared const char *
to better illustrate the expected cause of failures.
&#160;
  </TD>
<TD valign="top">
Update union u as: "union u { int a; const char* b;
};"
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US48">US 48</A></TD>
<TD valign="top">
8.5.3

    &#182;
    
5
&#160;
  </TD>
<TD valign="top">
The rule "...or the reference shall be an rvalue reference
and the initializer expression shall be an rvalue or have a
function type" is stated in terms of the rvalue-ness of the
expression rather than the eventual target of the
reference; this leads to some undesirable results, such as
<PRE>
struct A { };
struct B {
operator A&amp;();
};
A&amp;&amp; aref = B(); // binds to lvalue
</PRE>
(c++std-core-16305)
&#160;
  </TD>
<TD valign="top">
Correct the formulation to deal with the rvalueness
of the initializer after conversion to the
appropriate type.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1138">1138</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US49">US 49</A></TD>
<TD valign="top">
8.5.3

    &#182;
    
5
&#160;
  </TD>
<TD valign="top">
The FCD does not specify direct binding for this example:
<PRE>
int i;
int main()
{
int&amp;&amp; ir = static_cast&lt;int&amp;&amp;&gt;(i);
ir = 42;
return (i != 42);
}
</PRE>
(c++std-core-16181)
&#160;
  </TD>
<TD valign="top">
See Appendix 1 - Additional Details
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1139">1139</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB37">GB 37</A></TD>
<TD valign="top">
8.5.3
&#160;
  </TD>
<TD valign="top">
It seems that lvalues of any sort don't bind to non-const
rvalue ref args, even if an intermediate temporary would
be created.
See the discussion at
http://stackoverflow.com/questions/2748866/c0x-rvalue-references-and-temporaries.<BR>
I'll summarise that here: Assume that std::vector has
push_back overloads declared as follows, with SFINAE
omitted for clarity:
<PRE>
void push_back(const T &amp;);
//Copies the const T &amp; into the vector's storage
void push_back(T &amp;&amp;);
//Moves the T &amp;&amp; into the vector's storage
</PRE>
Then this code appears to behave as commented, as of
N3090:
<PRE>
const char * cchar = "Hello, world"; std::vector&lt;std::string&gt;
v;
v.push_back(cchar);
//makes a temporary string, copies the string
into vector storage using push_back(const T&amp;)
v.push_back(std::string(cchar));
//makes a temporary string, moves the string into vector
storage using push_back(T&amp;&amp;)
v.push_back(std::move(cchar));
//makes a temporary string, moves the string into the
vector using push_back(T&amp;&amp;)
</PRE>
Johannes Schaub (litb) convincingly argued that the
reason for this is clause 8.5.3/5 describing reference
binding - it allows direct binding of lvalues, bindings that
require conversion sequences to const lvalue refs, and
rvalues to rvalue refs. But it doesn't allow for lvalues to
ever bind to rvalue refs, even if an intermediate temporary
would otherwise need to be created.<BR>
This isn't what I (as a user of std::vector) expect to
happen. I expect all of these push_back calls to do the
same thing, namely, select the push_back(T&amp;&amp;) overload,
create a temporary string object from 'cchar', bind the
temporary string to the argument, and hence move (not
copy) the temporary string into vector's storage.<BR>
It seems particularly strange that v.push_back(cchar)
"requires" an extra copy, but
v.push_back(std::move(cchar)) does not. It almost
seems like indicating that 'cchar' is potentially-movable (by
casting it to an rvalue ref using std::move) allows moving
from a completely different object - the temporary string.<BR>
I suggest extending the rules for initializing const lvalue
refs via implicit conversions (8.5.3/5), to also apply to
rvalue refs.<BR>
This also raises an additional question of whether lvalues
of _copyable_ types should be copied into a temporary
object so that they may bind to an rvalue ref. Allowing this
would not affect const T&amp;/T&amp;&amp; overload pairs. But
it could be potentially useful when writing functions that
wish to accept a number of rvalue refs to copyable-but-not-movable
types (such as all C++03 classes with user-defined
copy constructors), or when writing functions that
"take apart" a number their arguments in a way that is
different from a straightforward move (perhaps some
tree operations would want to do this).<BR>
Conversely, it might seem odd that declarations such as:
<PRE>
string &amp;&amp; s = string_lvalue;
string &amp;&amp; s = string_rvalue_ref_variable;
//mistake, std::move(string_rvalue_ref_variable) was
intended
</PRE>
...would both
silently copy their arguments and bind to the copy, instead
of being invalid as they are now.<BR>
We believe this is core issue 953
&#160;
  </TD>
<TD valign="top">
Possible wording: amend the second list
item in 8.5.3/5:<BR>
Otherwise, the reference shall be an lvalue
reference to a non-volatile const type (i.e., cv1
shall be const), or the reference shall be an rvalue
reference [deleted the rest of the sentence]. [The
last example would also need to be deleted.]
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1138">1138</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="DE10">DE 10</A></TD>
<TD valign="top">
8.5.3

    &#182;
    
te
&#160;
  </TD>
<TD valign="top">
Reference binding rules for rvalue references should
consider temporaries generated from lvalues by implicit
conversions. Consider to postpone the lvalue/rvalue
analysis of an expression to after the implicit conversion
chain has been deduced. Example:
<PRE>
void f(std::string&amp;&amp;);
void g() {
f(std::string("hello")); // #1, ok
f("hello"); // #2, error,
// but should be the same as #1
}
</PRE>
&#160;
  </TD>
<TD valign="top">
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1138">1138</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US50">US 50</A></TD>
<TD valign="top">
9

    &#182;
    
9
&#160;
  </TD>
<TD valign="top">
the class "struct A { const int i; };" was a POD in C++98,
but is not a POD under the FCD rules because it does not
have a trivial default constructor; I believe that C++0x
POD was intended to be a superset of C++98 POD.
&#160;
  </TD>
<TD valign="top">
change POD to be standard layout and trivially
copyable?
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1140">1140</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="FI16">FI 16</A></TD>
<TD valign="top">
9 9 9 3.9

    &#182;
    
5 trivial 6 std-layout 9 POD 10 literal type
&#160;
  </TD>
<TD valign="top">
There are definitions for these types in the text, yet it is left
unclear what use these classifications have. The types are
very close to each other, which makes them confusing. If
the reader must rely on external references, then these
references should be specified (which is undesirable, or
even disallowed by ISO(?)). As it stands, there is an
example for using standard-layout classes (with other
programming languages). There are also uses specified
for literal types. One can imagine many uses for these
four/five types, so it is important to have a clear
specification of the intent as to where each of these types
is expected to be used.
&#160;
  </TD>
<TD valign="top">
It is necessary to have detailed information on the
expected uses of standard-layout, trivial, trivially
copyable, literal and POD types.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
The current wording is clear enough.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP81">JP 81</A></TD>
<TD valign="top">
9

    &#182;
    
9
&#160;
  </TD>
<TD valign="top">
Missing description of acronym "POD", which existed in
C++03: The acronym POD stands for "plain old data."
&#160;
  </TD>
<TD valign="top">
Add "The acronym POD stands for "plain old
data." as an annotation.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US51">US 51</A></TD>
<TD valign="top">
9.2 [class.mem]
&#160;
  </TD>
<TD valign="top">
Non-static data member initializers have no
implementation experience.
&#160;
  </TD>
<TD valign="top">
Either demonstrate a complete implementation of
this feature or remove N2756 from the working
paper prior the FDIS.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1141">1141</A>&#160;
  </TD>
<TD valign="top">
C++/CLI has a very similar feature that has been implemented.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US52">US 52</A></TD>
<TD valign="top">
9.3

    &#182;
    
7
&#160;
  </TD>
<TD valign="top">
The current wording allows friend declarations to name
member functions "after their class has been defined."
This appears to prohibit a friend declaration in a nested
class defined inside its containing class that names a
member function of the containing class, because the
containing class is still considered to be incomplete at that
point.
&#160;
  </TD>
<TD valign="top">
Change the wording to allow a friend declaration
of a "previously-declared member function."
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1142">1142</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US53">US 53</A></TD>
<TD valign="top">
9.3.1 [class.mfct.non-static]
&#160;
  </TD>
<TD valign="top">
Move semantics for *this have no implementation
experience.
&#160;
  </TD>
<TD valign="top">
Either demonstrate a complete implementation of
this feature or remove N1821 from the working
paper prior the FDIS.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1143">1143</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP73">JP 73</A></TD>
<TD valign="top">
9.3.1

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
"char*" should be "const char *".<BR>
The special rule to convert character literal to pointer has
been removed from "4.2 Array-to-pointer conversion
[conv.array]".
<PRE>
char * p1 = "..." ; // ill-formed.(removing const'ness)
char const *p2 = "..." ;// well-formed.
</PRE>
There are many code fragments depending on the
removed rule. They are ill-formed.
&#160;
  </TD>
<TD valign="top">
Change to:
<PRE>
struct tnode {
char tword[20];
int count;
tnode *left;
tnode *right;
void set(const char*, tnode* l, tnode* r);
};
void tnode::set(const char* w, tnode* l, tnode* r) {
count = strlen(w)+1;
if (sizeof(tword)&lt;=count)
perror("tnode string too long");
strcpy(tword,w);
left = l;
right = r;
}
void f(tnode n1, tnode n2) {
n1.set("abc",&amp;n2,0);
n2.set("def",0,0);
}
</PRE>
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US54">US 54</A></TD>
<TD valign="top">
9.5 [class.union]
&#160;
  </TD>
<TD valign="top">
Unrestricted unions have no implementation experience.
&#160;
  </TD>
<TD valign="top">
Either demonstrate a complete implementation of
this feature or remove N2544 from the working
paper prior the FDIS.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
The feature has been implemented
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP74">JP 74</A></TD>
<TD valign="top">
9.5

    &#182;
    
6
&#160;
  </TD>
<TD valign="top">
"char*" should be "const char *".<BR>
The special rule to convert character literal to pointer has
been removed from "4.2 Array-to-pointer conversion
[conv.array]".
<PRE>
char * p1 = "..." ; // ill-formed.(removing const'ness)
char const *p2 = "..." ;// well-formed.
</PRE>
There are many code fragments depending on the
removed rule. They are ill-formed.
&#160;
  </TD>
<TD valign="top">
Change to:
<PRE>
void f() {
union { int a; const char* p; };
a = 1;
p = "Jennifer";
}
</PRE>
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB38">GB 38</A></TD>
<TD valign="top">
9.6
&#160;
  </TD>
<TD valign="top">
The signedness of bit-fields is the only time when 'signed
int' is any different to just 'int'.<BR>
In C it is possible to remember whether a typedef uses
'signed' but in C++ it doesn't make sense and will result in
ODR violations if A&lt;long&gt; and A&lt;signed long&gt; are not
exactly equivalent.<BR>
This also causes portability problems because it is not
specified whether typedefs such as int32_t are defined
with 'signed' so using the &lt;cstdint&gt; types in bitfields is
problematic.<BR>
It is common to want to guarantee a bit-field has a
minimum number of bits, for which the &lt;cstdint&gt; types are
useful, except that the signedness of a bit-field using
int32_t might depend on both unspecified and
implementation-defined behaviour.
&#160;
  </TD>
<TD valign="top">
'signed int' should always be equivalent to 'int' in
all contexts.<BR>
A possible alternative would be to specify that
signed types in &lt;cstdint&gt; are declared with
'signed' so that using them for bit-fields has
predictable results, but this doesn't address the
ODR issue with A&lt;long&gt; and A&lt;signed long&gt;
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#675">675</A>&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
Resolving this question was not deemed essential for this revision of
the Standard, but core language issue 675 remains open for
possible consideration in a future revision.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US55">US 55</A></TD>
<TD valign="top">
10.3

    &#182;
    
Paragraph 5
&#160;
  </TD>
<TD valign="top">
The following code not only does not compile on the
compilers I've tested, but cannot be fixed through any
combinations of forward references
<PRE>
class B {
public:
virtual B *f() = 0;
};
class D1 : public B {
public:
virtual D2 *f();
};
class D2 : public B {
public:
virtual D1 *f();
};</PRE>
&#160;
  </TD>
<TD valign="top">
In the core mailing list, Daniel Krugler points out
that the current wording is ambiguous as to
whether this is legal (although an editorial
example suggests otherwise), and observes that it
should be OK as long as D2 is complete at the
point of definition of D1::f. The standard should
resolve the ambiguity by saying that D2 only
needs to be complete at the point of definition of
D1::f.<BR>
The core mailing list message text is below:<BR>
I would be happy, if the standard would just allow
this, but IMO the
current wording seems to be readable in different
ways (e.g.
Comeau rejects the code). I think the reason is
that [class.virtual]/5
just says:<BR>
"The return type of an overriding function shall be
either identical to
the return type of the overridden function or
covariant with the
classes of the functions.[..]"<BR>
This restriction is IMO only necessary for the
*definition* of D::f.
Secondly p. 6 says:<BR>
"If the return type of D::f differs from the return
type of B::f, the class
type in the return type of D::f shall be complete at
the point of
declaration of D::f or shall be the class type D.[..]"<BR>
and shows the following example that explicitly
forbids that (simplified):
<PRE>
struct Base {
virtual B* vf5();
};
class A;
struct Derived : public Base {
A* vf5(); // error: returns pointer to incomplete
class
};
</PRE>
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
It is necessary to be able to calculate the offsets applied to
covariant return values when only the class definition is available.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US56">US 56</A></TD>
<TD valign="top">
11.3 [class.access.decl]
&#160;
  </TD>
<TD valign="top">
Access declarations were deprecated in the 1998
standard and have no benefits over using declarations.
&#160;
  </TD>
<TD valign="top">
Remove access declarations from the working
paper.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1144">1144</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="FI4">FI 4</A></TD>
<TD valign="top">
12.1 [class.ctor]

    &#182;
    
Paragraph 5
&#160;
  </TD>
<TD valign="top">
What effect does defaulting have on triviality? Related to
FI 1, non-public special members defaulted on their first
declaration should retain triviality, because they shouldn't
be considered user-provided. Related to FI 3, defaulted
member functions that are virtual should not be
considered trivial, but there's no reason why non-virtuals
could not be.<BR>
Furthermore, a class with a non-public explicitly-defaulted
constructor isn't ever trivially constructible under the
current rules. If such a class is used as a subobject, the
constructor of the aggregating class should be trivial if it
can access the non-public explicitly defaulted constructor
of a subobject.
&#160;
  </TD>
<TD valign="top">
Change the triviality rules so that a class can have
a trivial default constructor if the class has access
to the default constructors of its subobjects and
the default constructors of the subobjects are
explicitly defaulted on first declaration, even if said
defaulted constructors are non-public.<BR>
See Appendix 1 - Additional Details
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1145">1145</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="FI15">FI 15</A></TD>
<TD valign="top">
12.3.1

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
12.3.1. 2: "A default constructor may be an explicit
constructor; such a constructor will be used to perform
default-initialization or value-initialization (8.5)."<BR>
12.3. 1 also says that an explicit ctor is different from a
non-explicit ctor in that it is only invoked when
direct-initialization (T a(1); T a{1}. presumably also T a;)
or casting is used.<BR>
What are the scenarios for the default ctor where explicit
actually matters? Temporaries, arrays, ???
When, if ever, is an explicit default ctor different from a
non-explicit ctor?
&#160;
  </TD>
<TD valign="top">
The difference between a no argument default
constructor and an explicit no argument default
constructor should be explained in the standard.
If there is no difference, this should be explicitly
specified.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
The current wording is clear enough.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US57">US 57</A></TD>
<TD valign="top">
12.3.2 [class.conv.fct]
&#160;
  </TD>
<TD valign="top">
Explicit conversion operators have no implementation
experience.
&#160;
  </TD>
<TD valign="top">
Either demonstrate a complete implementation of
this feature or remove N2437 from the working
paper prior the FDIS.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
The feature has been implemented.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB39">GB 39</A></TD>
<TD valign="top">
12.4

    &#182;
    
4
&#160;
  </TD>
<TD valign="top">
Contradiction between the note and normative language
describing when defaulted function definitions might have
an exception specification. (See 8.4.2p2 for requirement
to provide the exception specification)
&#160;
  </TD>
<TD valign="top">
Either strike the second sentance of this note, or
update it to reflect under which conditions a
defaulted definition might have an exception
specification.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1146">1146</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB40">GB 40</A></TD>
<TD valign="top">
12.4
&#160;
  </TD>
<TD valign="top">
It is very difficult to write correct programs that do not call
'terminate' in the presence of destructors that can throw
exceptions, and this practice has long been discouraged.
Many implicitly declared destructors already carry
noexcept declarations (mostly types with trivial
destructors) and it is anticipated it will become common
practice to want a user-declared destructor to be declared
noexcept. This becomes important evaluating the
noexcept operator, where any of the unevaluated subexpressions
may produce a temporary object. As this is
expected to be the overwhelmingly common case, a user-declared
destructor that does not supply an exception
specification should be considered as if declared
noexcept(true) rather than noexcept(false), the default for
every other function.
&#160;
  </TD>
<TD valign="top">
a user-declared destructor that does not supply an
exception specification should be considered as if
declared noexcept(true) rather than
noexcept(false), the default for every other
function
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1147">1147</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
The rule that was adopted makes destructors noexcept if all the base
and member destructors are.
<BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3204.html">
     N3204</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="CH9">CH 9</A></TD>
<TD valign="top">
12.4 and 15.4
&#160;
  </TD>
<TD valign="top">
Destructors should generally not throw exceptions.
Consider giving an explicit rule for this.
&#160;
  </TD>
<TD valign="top">
Add in 12.4 or 15.4 a paragraph to the effect that
all destructors not having an exception
soecification are considered noexcept(true).
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1147">1147</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
The rule that was adopted makes destructors noexcept if all the base
and member destructors are.
<BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3204.html">
     N3204</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US58">US 58</A></TD>
<TD valign="top">
12.5

    &#182;
    
foot 117
&#160;
  </TD>
<TD valign="top">
Missing comma in "is not virtual the size might".
&#160;
  </TD>
<TD valign="top">
Add the comma.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
Because of the comma later in the sentence, a comma here would be wrong.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US59">US 59</A></TD>
<TD valign="top">
12.6.2 [class.base.init]
&#160;
  </TD>
<TD valign="top">
Delegating constructors have no implementation
experience.
&#160;
  </TD>
<TD valign="top">
Either demonstrate a complete implementation of
this feature or remove N1986 from the working
paper prior the FDIS.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
The feature has been implemented.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US60">US 60</A></TD>
<TD valign="top">
12.8 [class.copy]
&#160;
  </TD>
<TD valign="top">
Implicitly-defined move constructors and move
assignment operators have no implementation
experience.
&#160;
  </TD>
<TD valign="top">
Either demonstrate a complete implementation of
this feature or remove N3053 from the working
paper prior the FDIS.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
The feature has been implemented.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="DE11">DE 11</A></TD>
<TD valign="top">
12.8
&#160;
  </TD>
<TD valign="top">
It is unclear whether copy elision can or cannot apply to a
case like C f(C c) { return c; }, i.e. where a parameter of
class type is returned. Furthermore, if copy elision cannot
apply there, it should still be possible to move (instead of
copy) the return value.
&#160;
  </TD>
<TD valign="top">
Amend paragraph 34 to explicitly exclude function
parameters from copy elision. Amend paragraph
35 to include function parameters as eligible for
move-construction.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1148">1148</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="FI5">FI 5</A></TD>
<TD valign="top">
12.8 [class.copy]

    &#182;
    
Paragraph 13, paragraph 27
&#160;
  </TD>
<TD valign="top">
Same as FI 4, the parts involving copy constructors and
copy assignment operators.<BR>
A class with a non-public explicitly-defaulted copy
constructor isn't ever trivially copyable under the current
rules. If such a class is used as a subobject, the copy
constructor of the aggregating class should be trivial if it
can access the non-public explicitly defaulted copy
constructor of a subobject.
&#160;
  </TD>
<TD valign="top">
Change the triviality rules so that a class can
have a trivial copy constructor if the class has
access to the copy constructors of its subobjects
and the copy constructors of the subobjects are
explicitly defaulted on first declaration, even if said
defaulted copy constructors are non-public.
See Appendix 1 - Additional Details
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1149">1149</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB41">GB 41</A></TD>
<TD valign="top">
12.8

    &#182;
    
15, 29
&#160;
  </TD>
<TD valign="top">
Contradiction between the notes claiming that defaulted
definitions to not have exception specifications, and the
normative language in 8.4.2 which declares that they
might.
&#160;
  </TD>
<TD valign="top">
Either strike the second sentance of each note, or
update it to reflect under which conditions a
defaulted definition might have an exception
specification.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1146">1146</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US61">US 61</A></TD>
<TD valign="top">
12.8;20.2.5

    &#182;
    
17,31;table 42
&#160;
  </TD>
<TD valign="top">
static_cast is broken across two lines
&#160;
  </TD>
<TD valign="top">
do not hyphenate static_cast
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US62">US 62</A></TD>
<TD valign="top">
12.8

    &#182;
    
16
&#160;
  </TD>
<TD valign="top">
The new wording describing generated copy constructors
does not describe the initialization of members of
reference type. (Core issue 1051 in N3083.)
&#160;
  </TD>
<TD valign="top">
Add the required description.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1051">1051</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US63">US 63</A></TD>
<TD valign="top">
12.8

    &#182;
    
16-18
&#160;
  </TD>
<TD valign="top">
The new wording specifies the behavior of an implicitlydefined
copy constructor for a non-union class (p16), an
implicitly-defined move constructor for a non-union class
(p17), and an implicitly-defined copy constructor for a
union (p18), but not an implicitly-defined move constructor
for a union. (Core issue 1064 in N3083.)
&#160;
  </TD>
<TD valign="top">
Add the required description.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1064">1064</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US64">US 64</A></TD>
<TD valign="top">
12.8

    &#182;
    
28
&#160;
  </TD>
<TD valign="top">
The current wording reads, "A copy/move assignment
operator that is defaulted and not defined as deleted is
implicitly defined when an object of its class type is
assigned a value of its class type or a value of a class
type derived from its class type or when it is explicitly
defaulted after its first declaration." This sounds as if any
assignment to a class object, regardless of whether it is a
copy or a move assignment, defines both the copy and
move operators. Presumably an assignment should only
define the assignment operator chosen by overload
resolution for the operation. (Compare the corresponding
wording in p14 for the copy/move constructors:
"...implicitly defined if it is used to initialize an object of its
class type..." (Core issue 1066 in N3083.)
&#160;
  </TD>
<TD valign="top">
Clarify the wording so that only the operator
needed for the operation is implicitly defined.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1066">1066</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US65">US 65</A></TD>
<TD valign="top">
12.9 [class.inhctor]
&#160;
  </TD>
<TD valign="top">
Inheriting constructors have no implementation
experience.
&#160;
  </TD>
<TD valign="top">
Either demonstrate a complete implementation of
this feature or remove N2540 from the working
paper prior the FDIS.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1150">1150</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP65">JP 65</A></TD>
<TD valign="top">
13.1

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
In some code examples, ellipsis(...) is used in ill-formed.
In these cases, "..." represents omission of some codes
like this:<BR>
class A { /* ... */ } ;<BR>
But in some cases, it is used without commented-out as
below:<BR>
class A { ... } ;<BR>
It is an inconsistent usage. They all should be enclosed in
a comment.
&#160;
  </TD>
<TD valign="top">
Change to:<BR>
<PRE>
int f (int) { /* ... */ } // definition of f(int)
int f (cInt) { /* ... */ } // error: redefinition of f(int)
</PRE>
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US66">US 66</A></TD>
<TD valign="top">
13.3.1.7

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
overload resolution should first look for a viable list
constructor, then look for a non-list constructor if no list
constructor is viable
&#160;
  </TD>
<TD valign="top">
See Appendix 1 - Additional Details
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1151">1151</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US67">US 67</A></TD>
<TD valign="top">
13.3.2

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
To determine whether there is an ICS, 13.3.2 uses
13.3.3.1 instead of just saying &#8220;there is an ICS if-and-only-if
a copy init would be well-formed.&#8221; Apparently this is
desired, but to a casual reader or an implementor reading
these rules for the first time for a new implementation, it's
not clear why that's desired.
&#160;
  </TD>
<TD valign="top">
Insert a note or annex explaining why 13.3.2 does
things as it does.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1152">1152</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
The resolution for core language issue 1152 fixes a related problem,
but a rationale was not deemed necessary at this time.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP75">JP 75</A></TD>
<TD valign="top">
13.2

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
"char*" should be "const char *".<BR>
The special rule to convert character literal to pointer has
been removed from "4.2 Array-to-pointer conversion
[conv.array]".
<PRE>
char * p1 = "..." ; // ill-formed.(removing const'ness)
char const *p2 = "..." ;// well-formed.
</PRE>
There are many code fragments depending on the
removed rule. They are ill-formed.
&#160;
  </TD>
<TD valign="top">
Change to:
<PRE>
struct B {
int f(int);
};
struct D : B {
int f(const char*);
};
</PRE>
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP76">JP 76</A></TD>
<TD valign="top">
13.2

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
"char*" should be "const char *".<BR>
The special rule to convert character literal to pointer has
been removed from "4.2 Array-to-pointer conversion
[conv.array]".
<PRE>
char * p1 = "..." ; // ill-formed.(removing const'ness)
char const *p2 = "..." ;// well-formed.
</PRE>
There are many code fragments depending on the
removed rule. They are ill-formed.
&#160;
  </TD>
<TD valign="top">
Change to:
<PRE>
void f(const char*);
void g() {
extern void f(int);
f("asdf"); // error: f(int) hides f(const char*)
// so there is no f(const char*) in this scope
}
</PRE>
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP77">JP 77</A></TD>
<TD valign="top">
13.3.1.2

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
"char*" should be "const char *".<BR>
The special rule to convert character literal to pointer has
been removed from "4.2 Array-to-pointer conversion
[conv.array]".
<PRE>
char * p1 = "..." ; // ill-formed.(removing const'ness)
char const *p2 = "..." ;// well-formed.
</PRE>
There are many code fragments depending on the
removed rule. They are ill-formed.
&#160;
  </TD>
<TD valign="top">
Change to:
<PRE>
struct String {
String (const String&amp;);
String (const char*);
operator char* ();
};
String operator + (const String&amp;, const String&amp;);
void f(void) {
char* p= "one" + "two"; // ill-formed because
neither
// operand has user-defined type
int I = 1 + 1; // Always evaluates to 2 even if
// user-defined types exist which
// would perform the operation.
}
</PRE>
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US68">US 68</A></TD>
<TD valign="top">
13.4

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
Overload resolution within the operand of a unary &amp;
operator is done by selecting the function "whose type
matches the target type required in the context." The
criterion for determining whether the types match,
however, is not defined. At least three possibilities
suggest themselves:<BR>
1. The types are identical.<BR>
2. The source type can be implicitly converted to
the target type.<BR>
3. The expression would be well-formed if the
function under consideration were not
overloaded.<BR>
This question arises for pointer-to-member types, where
there is an implicit conversion from a pointer-to-base-member
to a pointer-to-derived-member, as well as when
the context is an explicit type conversion (which allows for
static_cast a conversion from pointer-to-derived-member
to a pointer-to-base-member and, in the reinterpret_cast
interpretation of functional and old-style casts, essentially
any conversion).
&#160;
  </TD>
<TD valign="top">
Specify the intended criterion for determining
whether the types match.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1153">1153</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP82">JP 82</A></TD>
<TD valign="top">
13.5.8

    &#182;
    
8
&#160;
  </TD>
<TD valign="top">
Typo, "lteral" should be "literal".<BR>
// error: invalid lteral suffix identifier
&#160;
  </TD>
<TD valign="top">
Correct typo.<BR>
// error: invalid literal suffix identifier
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US69">US 69</A></TD>
<TD valign="top">
14.3.2

    &#182;
    
para 1
&#160;
  </TD>
<TD valign="top">
The standard permits the address of thread_local variable
as a non-type template parameter. The addresses of
these variables are not constant, however.
&#160;
  </TD>
<TD valign="top">
Require static storage duration for non-type
parameters.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1154">1154</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="DE12">DE 12</A></TD>
<TD valign="top">
14.3.2
&#160;
  </TD>
<TD valign="top">
Now that local classes can be used as template
arguments, it seems odd that there are "external linkage"
restrictions on non-type template parameters.
&#160;
  </TD>
<TD valign="top">
Permit addresses of objects and functions with
internal linkage as arguments for non-type
template parameters.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1155">1155</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP78">JP 78</A></TD>
<TD valign="top">
14.3.2

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
"char*" should be "const char *".
If not corrected, type mismatch is another cause of error in
the example below, which is not appropriate for an
example here.
<PRE>
template&lt;class T, char* p&gt; class X {
X();
X(const char* q) { / ... / }
};
X&lt;int, "Studebaker"&gt; x1; // error: string literal as templateargument
char p[] = "Vivisectionist";
X&lt;int,p&gt; x2; // OK
</PRE>
&#160;
  </TD>
<TD valign="top">
template&lt;class T, const char* p&gt; class X {
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP83">JP 83</A></TD>
<TD valign="top">
14.3.2

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
Constructors in template declaration are not essential for
this example to explain string literal error use.
<PRE>
template&lt;class T, char* p&gt; class X {
X();
X(const char* q) { /* ... */ }
};
X&lt;int, "Studebaker"&gt; x1; // error: string literal as templateargument
char p[] = "Vivisectionist";
X&lt;int,p&gt; x2; // OK
</PRE>
&#160;
  </TD>
<TD valign="top">
Delete two constructors in template declaration as
follows.
<PRE>
template&lt;class T, const char* p&gt; class X {
/* ... */
};
X&lt;int, "Studebaker"&gt; x1; // error: string literal as
template-argument
char p[] = "Vivisectionist";
X&lt;int,p&gt; x2; // OK
</PRE>
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB42">GB 42</A></TD>
<TD valign="top">
14.5.3

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
The name "eror" should probably be "error".
&#160;
  </TD>
<TD valign="top">
Replace:<BR>
Tuple&lt;0&gt; eror;<BR>
With:<BR>
Tuple&lt;0&gt; error;<BR>
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP24">JP 24</A></TD>
<TD valign="top">
14.5.3

    &#182;
    
4
&#160;
  </TD>
<TD valign="top">
Representations of reference link are not unified.
Most reference links to clause (table) number, say X, are
in the form "Clause X" ("Table X") capitalized, and
subsection Y.Y.Y is referenced with its number only in the
form "Y.Y.Y". Whether they are parenthesized or not
depends on the context.
However there are some notations "(Z)" consisting of only
a number Z in parentheses to confer Clause or Table
number Z.
&#160;
  </TD>
<TD valign="top">
Change "(10)" to "(Clause 10)".
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US70">US 70</A></TD>
<TD valign="top">
14.5.6.2

    &#182;
    
2, 4
&#160;
  </TD>
<TD valign="top">
14.8.2.4p3 specifies that the deduction used in partial
ordering in a non-call context is based on the complete
function type of the function templates. The wording in
14.5.6.2p2 (and echoed in p4) reflects an earlier
specification, however, saying that the deduction uses
only "the function parameter types, or in the case of a
conversion function the return type." This is a
contradiction.
&#160;
  </TD>
<TD valign="top">
Update the wording in 14.5.6.2 to say only that
deduction is performed as described in 14.8.2.4
and not to specify which types are used.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1156">1156</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US71">US 71</A></TD>
<TD valign="top">
unused

    &#182;
    
unused
&#160;
  </TD>
<TD valign="top">
&#160;
  </TD>
<TD valign="top">
&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="CA7">CA 7</A></TD>
<TD valign="top">
14.5.6.2p3

    &#182;
    
P3
&#160;
  </TD>
<TD valign="top">
r country In FCD sub-clause 14.5.6.2 [temp.func.order]
paragraph 3, we are told to synthesize, "for each type,
non-type, or template template parameter... a unique type,
value, or class template respectively."
These are then substituted for each occurrence of the
respective parameter in the function type of the function
template.
It is not specified what the properties of said synthetics
are, for example, members of a dependent type referred
to in non-deduced contexts are not specified to exist,
although the transformed function type would be invalid if
they do not exist.
We may assume, for example, that each synthetic will be
given minimal properties such that the transformed
function type is valid at the point of definition of the
template.<BR>
Example 1:<BR>
template &lt;typename T, typename U&gt; struct A; template
&lt;typename T&gt; void foo(A&lt;T, typename T::u&gt; *) { } // #1 //
synthetic T1 has member T1::u template &lt;typename T&gt;
void foo(A&lt;T, typename T::u::v&gt; *) { } // #2 // synthetic T2
has member T2::u and member T2::u::v // T in #1 deduces
to synthetic T2 in partial ordering; // deduced A for the
parameter is A&lt;T2, T2::u&gt; *--this is not necessarily
compatible // with A&lt;T2, T2::u::v&gt; * and it does not need
to be. See Note 1. The effect is that // (in the call below)
the compatibility of B::u and B::u::v is respected. // T in #2
cannot be successfully deduced in partial ordering from
A&lt;T1, T1::u&gt; *; // invalid type T1::u::v will be formed when
T1 is substituted into non-deduced contexts. struct B {
struct u { typedef u v; }; }; int main() { foo((A&lt;B, B::u&gt; *)0);
// calls #2 } *Note 1: Template argument deduction is an
attempt to match a P and to a deduced A; however,
template argument deduction is not specified to fail if the
P and the deduced A are incompatible. This may occur in
the presence of non-deduced contexts. Notwithstanding
the parenthetical statement in [temp.deduct.partial]
paragraph 9, template argument deduction may succeed
in determining a template argument for every template
parameter while producing a deduced A that is not
compatible with the corresponding P.<BR>
Example 2:<BR>
template &lt;typename T, typename U, typename V&gt; struct
A; template &lt;typename T&gt; void foo(A&lt;T, struct T::u, struct
T::u::u&gt; *); #2.1 // synthetic T1 has member non-union
class T1::u template &lt;typename T, typename U&gt; void
foo(A&lt;T, U , U&gt; *); #2.2 // synthetic T2 and U2 has no
required properties // T in #2.1 cannot be deduced in
partial ordering from A&lt;T2, U2, U2&gt; *;// invalid types T2::u
and T2::u::u will be formed when T2 is substituted in nondeduced
contexts. // T and U in #2.2 deduces to,
respectively, T1 and T1::u from A&lt;T1, T1::u, struct
T1::u::u&gt; * unless // struct T1::u::u does not refer to the
injected-class-name of the class T1::u (if that is possible).
struct B { struct u { }; }; int main() { foo((A&lt;B, B::u, struct
B::u::u&gt; *)0); // calls #2.1 } It is however unclear to what
extent an implementation will have to go to determine
these minimal properties.
&#160;
  </TD>
<TD valign="top">
This is a test of the interpretation of the resolution
to Issue 214. In particular, we would like for the
committee to spell out how properties of the
synthetics produced for partial ordering are
determined
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1157">1157</A>&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
Resolving this issue was not deemed essential for this revision of
the Standard.  Core language issue 1157 was opened, however, to
allow for possible consideration for a future revision.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US72">US 72</A></TD>
<TD valign="top">
14.5.7 [temp.alias]
&#160;
  </TD>
<TD valign="top">
Template aliases have no implementation experience.
&#160;
  </TD>
<TD valign="top">
Either demonstrate a complete implementation of
this feature or remove N2258 from the working
paper prior the FDIS.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
The feature has been implemented.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US73">US 73</A></TD>
<TD valign="top">
14.5.7

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
The current wording of 7.1.3p2 requires that the identifier
in an alias-declaration "...shall not appear in the type-id."
With template aliases, however, the name of the alias can
be used indirectly:
<PRE>
template&lt;typename T&gt; struct A;
template&lt;typename T&gt; using B=typename A&lt;T&gt;::U;
template&lt;typename T&gt; struct A {
typedef B&lt;T&gt; U;
};
B&lt;short&gt; b;
</PRE>
Here the instantiation of B&lt;short&gt; causes the instantiation
of A&lt;short&gt;, and the typedef in A&lt;short&gt; ends up
attempting to use B&lt;short&gt;, which is still in the process of
being instantiated.
&#160;
  </TD>
<TD valign="top">
Add wording to indicate that such usages in
template aliases are ill-formed.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1158">1158</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US74">US 74</A></TD>
<TD valign="top">
14.5.7

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
An alias-declaration allows a class or enumeration type to
be defined in its type-id (7.1.6p3). However, it's not clear
that this is desirable when the alias-declaration is part of a
template alias:
<PRE>
template&lt;typename T&gt; using A =
struct { void f(T) { } };
</PRE>
&#160;
  </TD>
<TD valign="top">
Either prohibit the definition of classes and
enumerations in template aliases, or prohibit the
use of template parameters in such definitions, or
add an example illustrating this usage.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1159">1159</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
Definition of a class or enumeration is now prohibited in a template
alias.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="FI10">FI 10</A></TD>
<TD valign="top">
14.5.7 [temp.alias]
&#160;
  </TD>
<TD valign="top">
Can template aliases be declared in class scope?
&#160;
  </TD>
<TD valign="top">
Allow declaring template aliases in class scope, if
not allowed by the current grammar.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#924">924</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="FI11">FI 11</A></TD>
<TD valign="top">
14.5.7 [temp.alias]
&#160;
  </TD>
<TD valign="top">
We have class templates and function templates,
shouldn't we call template aliases alias templates for
consistency?
&#160;
  </TD>
<TD valign="top">
Change &#8220;template alias&#8221; -&gt; &#8220;alias template&#8221;
everywhere.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP25">JP 25</A></TD>
<TD valign="top">
14.5.7

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
Representations of reference link are not unified.
Most reference links to clause (table) number, say X, are
in the form "Clause X" ("Table X") capitalized, and
subsection Y.Y.Y is referenced with its number only in the
form "Y.Y.Y". Whether they are parenthesized or not
depends on the context.
However there are some notations "(Z)" consisting of only
a number Z in parentheses to confer Clause or Table
number Z.
&#160;
  </TD>
<TD valign="top">
Change "(clause 7)" to "(Clause 7)".
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP26">JP 26</A></TD>
<TD valign="top">
14.6.2.1

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
Representations of reference link are not unified.
Most reference links to clause (table) number, say X, are
in the form "Clause X" ("Table X") capitalized, and
subsection Y.Y.Y is referenced with its number only in the
form "Y.Y.Y". Whether they are parenthesized or not
depends on the context.
However there are some notations "(Z)" consisting of only
a number Z in parentheses to confer Clause or Table
number Z.
&#160;
  </TD>
<TD valign="top">
Change "(9)" to "(Clause 9)".
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB43">GB 43</A></TD>
<TD valign="top">
14.6.2.1p3
&#160;
  </TD>
<TD valign="top">
If I'm not missing something, 14.6.2.1/3 says that in the
definition of a class template or member of a class
template, the injected-class-name refers to the current
instantiation. The template name followed by the
argument list enclosed in &#8220;&lt;..&gt;&#8221; also refers to the current
instantiation, but only in the definition of a primary class
template. That results in an odd situation:<BR>
template&lt;typename T&gt; struct A { typedef int type; void
f(type); }; // here we are outside the definition of 'A'<BR>
template&lt;typename T&gt; void A::f(A::type) { } // OK: 'A' is
the injected-class-name<BR>
template&lt;typename T&gt; void A::f(A&lt;T&gt;::type) { } // ill-formed:
'A&lt;T&gt;' is not the injected-class-name. Needs
'typename '!<BR>
If you would define the member-function within the
primary class template, bullet 2 would apply:<BR>
template&lt;typename T&gt; struct A {<BR>
typedef int type; void f(A&lt;T&gt;::type) { } // OK: name of A
followed by arguments enclosed in &lt;..&gt;<BR>
};<BR>
I think that this state of affairs isn't any good.<BR>
-&gt; Suggested solution: Change 14.6.2.1/1 bullet2 to apply
also to members of the primary class template. The same
for bullet4 talking about partial specializations. Since
partial specializations are also class templates, i wonder
whether one could also smelt together bullet2 and bullet4
and only talk about &#8220;class template&#8221;.
&#160;
  </TD>
<TD valign="top">
Updated 14.6.2.1 [temp.dep.type] p1 bullet 2:
" in the definition of a primary class template or
a member of a class template, the name of the
class template followed by the template argument
list of the primary template (as described below)
enclosed in &lt;&gt;,"
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1160">1160</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB44">GB 44</A></TD>
<TD valign="top">
14.6p5
&#160;
  </TD>
<TD valign="top">
C++0x does not allow this code
<PRE>
template&lt;typename T&gt; struct id { typedef T type; };
template&lt;typename T&gt; void f() { int id&lt;T&gt;::type::*p = 0; }
struct A { };
int main() { f&lt;A&gt;(); }
</PRE>
The reason is that it requires &#8220;typename&#8221; before
&#8220;id&lt;T&gt;::type&#8221;, but &#8220;typename&#8221; is not allowed at that place
by the syntax. Ultimately, current compilers accept this.
&#160;
  </TD>
<TD valign="top">
Change 14.6/5 to<BR>
A qualified name used as the name in a mem-initializer-id,
a base-specifier, an elaborated-type-specifier
or the nested-name-specifier of a pointer-to-member
declarator is implicitly assumed to
name a type, without the use of the typename
keyword.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1161">1161</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="CA6">CA 6</A></TD>
<TD valign="top">
14.6p5

    &#182;
    
P5
&#160;
  </TD>
<TD valign="top">
Given the change in N1376=02-0034 to [temp.res], found
in FCD in [temp.res] paragraph 5:<BR>
A qualified name used as the name in a mem-initializer-id,
a base-specifier, or an elaborated-type-specifier is
implicitly assumed to name a
type, without the use of the typename keyword<BR>
the following appears to be well-formed, with templates
foo() being distinct since any type T will produce an invalid
type for the second parameter for at least one foo() when
T is replaced within the non-deduced context:
<PRE>
template &lt;typename T&gt;
bool *foo(T *, enum T::u_type * = 0) { return 0; }
template &lt;typename T&gt; char *foo(T *, struct T::u_type * =
0) { return 0; }
struct A { enum u_type { I }; }; int main(void) { foo((A*)0); }
</PRE>
In particular, while determining the signature (1.3.11
[defns.signature]) for the function templates foo(), an
elaborated-type-specifier qualifies as part of the decl-specifier-seq
under 8.3.5 [dcl.fct] paragraph 5 in
determining the type of a parameter in the parameter-type-list
(absent additional wording).
Also, the return type is included in the signature of a
function template.<BR>
A portion of the GCC 4.5.0 output:<BR>
Internal compiler error: Error reporting routines re-entered.
Please submit a full bug report, with preprocessed source
if appropriate. See &lt; http://gcc.gnu.org/bugs.html &gt; for
instructions.<BR>
Implementations do not appear to support this case and
the ability to do so brings little value since type traits such
as is_enum and is_class cannot be defined using this and
equivalent functionality can be achieved using the
aforementioned type traits.
<PRE>
template &lt;typename T&gt; struct MY_is_enum :
std::false_type { };
template &lt;typename T&gt; struct MY_is_enum&lt;enum T&gt; :
std::true_type { }; // ill-formed,
</PRE>
elaborated-type-specifier resolves to typedef-name
&#160;
  </TD>
<TD valign="top">
Please clarify as the following case appears to be
expensive to implement with little functional value
to the language.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1162">1162</A>&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
The specification is as intended; compilers should handle cases like
these.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US75">US 75</A></TD>
<TD valign="top">
14.7
&#160;
  </TD>
<TD valign="top">
As described in c++std-core-16425 and its followup
messages, writing metaprograms is needlessly hard
because specializing template members inside a class is
(inadvertently?) not permitted. In addition, this surprising
restriction makes C++ less simple and more arbitrary-seeming.
&#160;
  </TD>
<TD valign="top">
Accept the code like that in c++std-core-16425,
like Visual C++ does already
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
There was no consensus for making the suggested change.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP79">JP 79</A></TD>
<TD valign="top">
14.7.1

    &#182;
    
10
&#160;
  </TD>
<TD valign="top">
"char*" should be "const char *".<BR>
The special rule to convert character literal to pointer has
been removed from "4.2 Array-to-pointer conversion
[conv.array]".
<PRE>
char * p1 = "..." ; // ill-formed.(removing constness)
char const *p2 = "..." ;// well-formed.
</PRE>
There are many code fragments depending on the
removed rule. They are ill-formed.
&#160;
  </TD>
<TD valign="top">
Change to:
<PRE>
namespace N {
template&lt;class T&gt; class List {
public:
T* get();
};
}
template&lt;class K, class V&gt; class Map {
public:
N::List&lt;V&gt; lt;
V get(K);
};
void g(Map&lt;const char*,int&gt;&amp; m) {
int i = m.get("Nicholas");
}
</PRE>
a call of lt.get() from Map&lt;const char*,int&gt;::get()
would place List&lt;int&gt;::get() in the namespace N
rather
than in the global namespace. &#8212;end example ]
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="FI9">FI 9</A></TD>
<TD valign="top">
14.7.3 [temp.expl.spec]

    &#182;
    
Paragraph 2
&#160;
  </TD>
<TD valign="top">
Explicit specializations in class scope inside class
templates should be allowed. It's weird, confusing and
inconsistent that they can be declared/defined in some
scopes but not in others.
&#160;
  </TD>
<TD valign="top">
Allow explicit specialization of member templates
inside class templates.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
There was no consensus for making the suggested change.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP80">JP 80</A></TD>
<TD valign="top">
14.8.1

    &#182;
    
5
&#160;
  </TD>
<TD valign="top">
"char*" should be "const char *".<BR>
The special rule to convert character literal to pointer has
been removed from "4.2 Array-to-pointer conversion
[conv.array]".
<PRE>
char * p1 = "..." ; // ill-formed.(removing const'ness)
char const *p2 = "..." ;// well-formed.
</PRE>
There are many code fragments depending on the
removed rule. They are ill-formed.
&#160;
  </TD>
<TD valign="top">
Change to:
<PRE>
template&lt;class X, class Y, class Z&gt; X f(Y,Z);
template&lt;class ... Args&gt; void f2();
void g() {
f&lt;int,const char*,double&gt;("aa",3.0);
f&lt;int,const char*&gt;("aa",3.0); // Z is deduced to be
double
f&lt;int&gt;("aa",3.0); // Y is deduced to be const char*,
and
// Z is deduced to be double
f("aa",3.0); // error: X cannot be deduced
f2&lt;char, short, int, long&gt;(); // OK
}
</PRE>
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US76">US 76</A></TD>
<TD valign="top">
14.8.2

    &#182;
    
para 9
&#160;
  </TD>
<TD valign="top">
"extern template" prevents inlining functions not marked
inline.
&#160;
  </TD>
<TD valign="top">
Remove wording about "suppressing the implicit
instantiation". See Appendix 1 - Additional Details
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1163">1163</A>&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
Section reference should be 14.7.2. The suggested change could result
in a silent change of meaning between implementations if speculative
instantiation for inlining is allowed.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US77">US 77</A></TD>
<TD valign="top">
14.8.2.1
&#160;
  </TD>
<TD valign="top">
Core Issue 1014 claims that calling f(const T&amp;) and f(T&amp;&amp;)
with a const int lvalue is ambiguous. It's unambiguous
because the partial ordering rules consider f(const T&amp;) to
be more specialized than f(T&amp;&amp;), for the same reasons
that they consider h(const T&amp;) to be more specialized than
h(T&amp;).<BR>
However, calling z(T&amp;) and z(T&amp;&amp;) with an int lvalue is
ambiguous. Because z(T&amp;) accepts a strict subset of the
things that z(T&amp;&amp;) accepts, it seems that the partial
ordering rules should be modified to consider z(T&amp;) to be
more specialized than z(T&amp;&amp;). There may be additional
subtleties.
&#160;
  </TD>
<TD valign="top">
Modify the partial ordering rules to consider z(T&amp;)
to be more specialized than z(T&amp;&amp;).
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1164">1164</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US78">US 78</A></TD>
<TD valign="top">
15.2

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
This paragraph says that "An object that is... partially
destroyed will have destructors executed... for subobjects
for which the principal constructor (12.6.2) has completed
execution and the destructor has not yet begun
execution." This would presumably apply to an example
like
<PRE>
struct S { ~S(); } s[10];
</PRE>
If the destructor for s[5] throws an exception, elements 0-4
should still be destroyed. However, the wording
specifically refers to "fully constructed base classes and
non-variant members," even though array elements are
subobjects of the array (1.8p2). This is presumably the
effect of stack unwinding (p1), which applies to "all
automatic objects constructed since the try block was
entered," but whether that should also be expected for
arrays of static, thread, and dynamic storage duration is
not clear.
&#160;
  </TD>
<TD valign="top">
Clarify the intent with respect to array elements
and storage duration.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1165">1165</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB45">GB 45</A></TD>
<TD valign="top">
15.3

    &#182;
    
16
&#160;
  </TD>
<TD valign="top">
The phrasing of this clause suggests all exception-declarations
produce objects. There should be some
additional wording to clarify that exception-declarations
that declare references bind to the exception object by
appropriate initialization, and *are* allowed to be
references to abstract classes. Likewise, the elipsis form
does not initialize any object or temporary.
&#160;
  </TD>
<TD valign="top">
Distinguish between initializing objects, initializing
references, and initializing nothing in the case of
an elipsis.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1166">1166</A>&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
Resolving this issue was not deemed essential for this revision of
the Standard.  However, issue 1166 was opened for possible consideration
in a future revision.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="CA5">CA 5</A></TD>
<TD valign="top">
15.3p8, 15.1p7

    &#182;
    
P8, p7
&#160;
  </TD>
<TD valign="top">
There is an issue with the definition of "currently handled
exception" in 15.3 [except.handle] paragraph 8:<BR>
The exception with the most recently activated
handler that is still active is called the currently
handled exception.<BR>
This wording implies that the currently handled exception
may be changed by another thread. Thus, by 15.1
[except.throw] paragraph 7,<BR>
A throw-expression with no operand rethrows the
currently handled exception (15.3).<BR>
the following may throw an exception that is not of type
int. try { throw 0; } catch (...) { throw; } Any solution should
also specify what the currently handled exception will be
for a thread that is spawned during the handling of an
exception by its parent.
&#160;
  </TD>
<TD valign="top">
Clarify and fix as suggested.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1218">1218</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US79">US 79</A></TD>
<TD valign="top">
15.4

    &#182;
    
p1
&#160;
  </TD>
<TD valign="top">
Because C has no exception mechanism, functions
having "C" language linkage should implicitly be declared
noexcept.
&#160;
  </TD>
<TD valign="top">
Insert a sentence such as:<BR>
Any function declared to have "C" linkage shall be
treated as if declared noexcept even if the
declaration lacks the noexcept keyword.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
There was no consensus for making the suggested change.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB46">GB 46</A></TD>
<TD valign="top">
15.4
&#160;
  </TD>
<TD valign="top">
It is not entirely clear that a function-try-block on a
destructor will catch exceptions for a base or member
destructor destructor; whether such exceptions might be
swallowed with a simple return statement rather than
being rethrown; and whether such a clause might be
entered multiple times if multiple bases/members throw, or
if that is an automatic terminate call.
&#160;
  </TD>
<TD valign="top">
[Add words to 15.4 clarifying the problem cases.]
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1167">1167</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="CH10">CH 10</A></TD>
<TD valign="top">
15.4

    &#182;
    
p9
&#160;
  </TD>
<TD valign="top">
In case of incorrect program specification, the general rule
is that the behaviour is undefined. This should be true for
noexcept as well.
&#160;
  </TD>
<TD valign="top">
Change the second bullet of p9 to "otherwise, the
behaviour is undefined.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
There was no consensus to reconsider the explicit decision of the
Committee on this point.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB47">GB 47</A></TD>
<TD valign="top">
15.5.1

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
15.5.1:1 [except.terminate] lists the situations in which
"exception handling must be abandoned for less subtle
error handling techniques".
The list seems to omit some new situations added by
other c++0x features.
&#160;
  </TD>
<TD valign="top">
The list should be augmented with the following:
<UL><LI>when function
std::nested_exception::rethrow_nested is called
for an object that stores a null exception pointer.</LI>
<LI>when execution of a function registered with
std::at_quick_exit
exits using an exception.</LI></UL>
Also, after the list, add the following sentence:<BR>
Function std::terminate is also called by the
implementation, when the
destrductor or a copy constructor of a class
std::thread is called for
the object that is joinable.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1168">1168</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB48">GB 48</A></TD>
<TD valign="top">
15.5.2

    &#182;
    
1-4
&#160;
  </TD>
<TD valign="top">
This subclause is dealing exclusively with dynamic
exception specifications, and should clearly say so.
&#160;
  </TD>
<TD valign="top">
Replace each italicised occurrence of 'exceptionspecification'
with 'dynamic-exceptionspecification'
in clause 15.5.2,
[except.unexpected]
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB49">GB 49</A></TD>
<TD valign="top">
15.5.2

    &#182;
    
all
&#160;
  </TD>
<TD valign="top">
Dynamic exception specifications are deprecated, so
clause 15.5.2 that describes how they work should move
to Annex D.
&#160;
  </TD>
<TD valign="top">
Move 15.5.2 [except.unexpected] to Annex D.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
The convention in the core clauses is to note the deprecation but
leave the specification <I>in situ</I>.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="CH11">CH 11</A></TD>
<TD valign="top">
16.1

    &#182;
    
p3
&#160;
  </TD>
<TD valign="top">
constant-expression as given by C++'s grammar allows
far more syntactical constructs than those that are allowed
in preprocessor context. The footnote 145 provides some
hints on the limitations, but in our opinion it should be
made more clear that the "constant-expression" allows
less than a lookup of the corresponding grammar rule
suggests
&#160;
  </TD>
<TD valign="top">
Add a note or extend footnote 145 with "Note that
constant-expression is much more limited than the
C++ grammar rule would suggest. See the
following paragraphs how it is limited in the
context of conditional inclusion."
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
The current wording is the same as in C++03, and hasn't caused confusion.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="CH12">CH 12</A></TD>
<TD valign="top">
16.3.5

    &#182;
    
p5
&#160;
  </TD>
<TD valign="top">
missing space between '~' and '5' in expansion
&#160;
  </TD>
<TD valign="top">
line
<PRE>
"f(2 * (2+(3,4)-0,1)) | f(2 *
(~5)) &amp; f(2 * (0,1))^m(0,1);"
</PRE>
should
read
<PRE>
"f(2 * (2+(3,4)-0,1)) | f(2 * (~
5)) &amp; f(2 * (0,1))^m(0,1);"
</PRE>
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="CH13">CH 13</A></TD>
<TD valign="top">
16.3.5

    &#182;
    
p7
&#160;
  </TD>
<TD valign="top">
superfluous braces in source
&#160;
  </TD>
<TD valign="top">
change
<PRE>
"int j[] = { t(1,2,3), t(,4,5),
t(6,{,}7), t(8,9,),"
</PRE>
to
<PRE>
"int j[] = {
t(1,2,3), t(,4,5), t(6,,7), t(8,9,),"
</PRE>
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="CH14">CH 14</A></TD>
<TD valign="top">
16.3.5

    &#182;
    
p9
&#160;
  </TD>
<TD valign="top">
superfluous spaces after/before parentheses
&#160;
  </TD>
<TD valign="top">
change
<PRE>
fprintf(stderr, "Flag" );
fprintf(stderr, "X = %d\n", x );
puts( "The first, second, and
third items." );
</PRE>
to
<PRE>
fprintf(stderr, "Flag");
fprintf(stderr, "X = %d\n", x);
puts("The first, second, and third
items.");
</PRE>
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="DE13">DE 13</A></TD>
<TD valign="top">
16.8
&#160;
  </TD>
<TD valign="top">
Committee Draft comment DE 18 has only been partially
addressed, and the record of response ignores the
missing item, namely the absence of a macro
__STDCPP_STRICT_POINTER_SAFETY__ that
indicates that a given implementation has strict pointer
safety (see 3.7.4.3).
&#160;
  </TD>
<TD valign="top">
Add the macro to the list of predefined macros in
16.8.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1169">1169</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US80">US 80</A></TD>
<TD valign="top">
[library] 17 - 30
&#160;
  </TD>
<TD valign="top">
Consider applying noexcept to all of the std::lib.
&#160;
  </TD>
<TD valign="top">
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1347">1347</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3155.html">
     N3155</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB60">GB 60</A></TD>
<TD valign="top">
17-30
&#160;
  </TD>
<TD valign="top">
Dyanamic exception specifications are deprecated; the
library should recognise this by replacing all non-throwing
exception specifications of the form 'throw()' with the
'noexcept' form.
&#160;
  </TD>
<TD valign="top">
Replace all non-throwing exception specifications
of the form 'throw()' with the 'noexcept' form.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1344">1344</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
See documents N3148, N3150, N3195, N3155, N3156, N3199, and N3180.
<BR><BR>
    See paper <A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3148.html">
     N3148</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB61">GB 61</A></TD>
<TD valign="top">
17-30
&#160;
  </TD>
<TD valign="top">
All library types should have non-throwing move
constructors and move-assignment operators unless
wrapping a type with a potentially throwing moveoperation.
When such a type is a class-template, these
operations should have a conditional noexcept
specification.<BR>
There are many other places where a noexcept
specification may be considered, but the move operations
are a special case that must be called out, to effectively
support the move_if_noexcept function template.
&#160;
  </TD>
<TD valign="top">
Review every class and class template in the
library. If noexcept move constructor/assignment
operators can be implicitly declared, then they
should be implicitly declared, or explicitly
defaulted. Otherwise, a move constructor/moveassingment
operator with a 'noexcept' exception
specification should be provided.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1345">1345</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB62">GB 62</A></TD>
<TD valign="top">
17-30
&#160;
  </TD>
<TD valign="top">
Issues with efficiency and unsatisfactory semantics mean
many library functions document they do not throw
exceptions with a Throws: Nothing clause, but do not
advertise it with an exception specification. The semantic
issues are largely resolved with the new 'noexcept'
specifications, and the noexcept operator means we will
want to detect these guarantees programatically in order
to construct programs taking advantage of the guarantee.
&#160;
  </TD>
<TD valign="top">
Add a 'noexcept' exception specification on each
libary API that offers an unconditional Throws:
Nothing guarantee. Where the guarantee is
conditional, add the appropriate
noexcept(constant-expression) if an appropriate
constant expression exists.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1346">1346</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3195.html">
     N3195</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB63">GB 63</A></TD>
<TD valign="top">
17-30
&#160;
  </TD>
<TD valign="top">
Since the newly introduced operator noexcept makes it
easy (easier than previously) to detect whether or not a
function has been declared with the empty exception
specification (including noexcept) library functions that
cannot throw should be decorated with the empty
exception specification. Failing to do so and leaving it as a
matter of QoI would be detrimental to portability and
efficiency.
&#160;
  </TD>
<TD valign="top">
Review the whole library, and apply the noexcept
specification where it is appropriate.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1347">1347</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3155.html">
     N3155</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB64">GB 64</A></TD>
<TD valign="top">
17-30
&#160;
  </TD>
<TD valign="top">
There are a number of unspecified types used throughout
the library, such as the container iterators. Many of these
unspecified types have restrictions or expectations on
their behaviour in terms of exceptions. Are they permitted
or required to use exception specifications, more
specifically the new noexcept specification? For example,
if vector&lt;T&gt;::iterator is implemented as a native pointer,
all its operations will have an (effective) nothrow
specification. If the implementation uses a class type to
implement this iterator, is it permitted or required to
support that same guarantee?
&#160;
  </TD>
<TD valign="top">
Clearly state the requirements for exception
specifications on all unspecified library types. For
example, all container iterator operations should
be conditionally noexcept, with the condition
matching the same operation applied to the
allocator pointer_type, a certain subset of which
are already required not to throw.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1348">1348</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB65">GB 65</A></TD>
<TD valign="top">
17-30
&#160;
  </TD>
<TD valign="top">
Nothrowing swap operations are key to many C++ idioms,
notably the common copy/swap idiom to provide the
strong exception safety guarantee.
&#160;
  </TD>
<TD valign="top">
Where possible, all library types should provide a
swap operation with an exception specification
guaranteeing no exception shall propagate.
Where noexcept(true) cannot be guaranteed to
not terminate the program, and the swap in
questions is a template, an exception specification
with the appropriate conditional expression could
be specified.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1349">1349</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB66">GB 66</A></TD>
<TD valign="top">
17-30
&#160;
  </TD>
<TD valign="top">
The syntax for attributes was altered specifically to make it
legal do declare attributes on functions by making the
attribute the first token in the declaration, rather than
inserting it between the function name and the opening
paren of the parameter list. This is much more readable,
and should be the preferred style throughout the library.
For example, prefer:<BR>
[[noreturn]] void exit(int status);<BR>
to<BR>
void exit [[noreturn]] (int status);
&#160;
  </TD>
<TD valign="top">
Update all function declarations throughout the
library to use the preferred placement of functionlevel
attributes.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="CH15">CH 15</A></TD>
<TD valign="top">
Library clauses
&#160;
  </TD>
<TD valign="top">
Due to the new rules about implicit copy and move
constructors some library facilities are now move-only.
&#160;
  </TD>
<TD valign="top">
Make them copyable again.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1421, 1350">1421, 1350</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="CH16">CH 16</A></TD>
<TD valign="top">
Library clauses
&#160;
  </TD>
<TD valign="top">
Dynamic exception specifications are deprecated.
Deprecated features shouldn't be used in the Standard.
&#160;
  </TD>
<TD valign="top">
Replace dynamic exception specifications with
noexcept.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1351">1351</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
See documents N3148, N3150, N3195, N3155, N3156, N3199, and N3180.
<BR><BR>
    See paper <A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3148.html">
     N3148</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="CH17">CH 17</A></TD>
<TD valign="top">
Library clauses
&#160;
  </TD>
<TD valign="top">
The introduction of noexcept makes "Throws: Nothing"
clauses looking strange.
&#160;
  </TD>
<TD valign="top">
Consider replacing "Throws: Nothing." clause by
the respective noexcept specification.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1352">1352</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3195.html">
     N3195</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="CH18">CH 18</A></TD>
<TD valign="top">
17
&#160;
  </TD>
<TD valign="top">
The general approach on moving is that a library object
after moving out is in a "valid but unspecified state". But
this is stated at the single object specifications, which is
error prone (especially if the move operations are implicit)
and unnecessary duplication.
&#160;
  </TD>
<TD valign="top">
Consider putting a general statement to the same
effect into clause 17.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1353">1353</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP27">JP 27</A></TD>
<TD valign="top">
17.1

    &#182;
    
9
&#160;
  </TD>
<TD valign="top">
Representations of reference link are not unified.
Most reference links to clause (table) number, say X, are
in the form "Clause X" ("Table X") capitalized, and
subsection Y.Y.Y is referenced with its number only in the
form "Y.Y.Y". Whether they are parenthesized or not
depends on the context.
However there are some notations "(Z)" consisting of only
a number Z in parentheses to confer Clause or Table
number Z.
&#160;
  </TD>
<TD valign="top">
Change "(25)" to "(Clause 25)".
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB52">GB 52</A></TD>
<TD valign="top">
17.3.7
&#160;
  </TD>
<TD valign="top">
The definition of deadlock in 17.3.7 excludes cases
involving a single thread making it incorrect.
&#160;
  </TD>
<TD valign="top">
The definition should be corrected.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1354">1354</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB50">GB 50</A></TD>
<TD valign="top">
17.3.13
&#160;
  </TD>
<TD valign="top">
This definition of move-assignment operator redundant
and confusing now that the term move-assignment
operator is defined by the core language in subclause
12.8p21.
&#160;
  </TD>
<TD valign="top">
Strike suclause 17.3.13 [defns.move.assign.op].
Add a cross-reference to (12.8) to 17.3.12.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1355">1355</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3142.htm">
     N3142</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB51">GB 51</A></TD>
<TD valign="top">
17.3.14
&#160;
  </TD>
<TD valign="top">
This definition of move-constructor redundant and
confusing now that the term constructor is defined by the
core language in subclause 12.8p3.
&#160;
  </TD>
<TD valign="top">
Strike subclause 17.3.14, [defns.move.ctor]
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1356">1356</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3142.htm">
     N3142</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP67">JP 67</A></TD>
<TD valign="top">
17.5.2.1.2

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
In some code examples, ellipsis(...) is used in ill-formed.
In these cases, "..." represents omission of some codes
like this:<BR>
class A { /* ... */ } ;<BR>
But in some cases, it is used without commented-out as
below:<BR>
class A { ... } ;<BR>
It is an inconsistent usage. They all should be enclosed in
a comment.
In addition, the number of period should be 3 rather than
5.
&#160;
  </TD>
<TD valign="top">
Change to:
<PRE>
enum bitmask {
V0 = 1 &lt;&lt; 0, V1 = 1 &lt;&lt; 1, V2 = 1 &lt;&lt; 2, V3 = 1 &lt;&lt;
3, ...
};
static const
/* ... */
</PRE>
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
This is pseudo-code; okay as written.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB53">GB 53</A></TD>
<TD valign="top">
17.5.2.1.3
&#160;
  </TD>
<TD valign="top">
The bitmask types defined in 27.5.2 and 28.5 contradict
the bitmask type requirements in 17.5.2.1.3, and have
missing or incorrectly defined operators.
&#160;
  </TD>
<TD valign="top">
See Appendix 1 - Additional Details
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1357">1357</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3110.htm">
     N3110</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB54">GB 54</A></TD>
<TD valign="top">
17.5.2.1.4.x
&#160;
  </TD>
<TD valign="top">
The defined terms NTC16S, NTC32S, NTWCS, char16-character
sequence, null-terminated char16-character
string, char32-character sequence, null-terminated
char32-character string, wide-character sequence and
null-terminated wide-character string do not occur at any
point in the standard outside their definitional subclauses
and associated footnotes.
&#160;
  </TD>
<TD valign="top">
Strike 17.5.2.1.4.3, 17.5.2.1.4.4, 17.5.2.1.4.5 and
associated footnotes 170, 171, 172, 173, 174 and
175.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB55">GB 55</A></TD>
<TD valign="top">
17.6.1.3

    &#182;
    
Table 15
&#160;
  </TD>
<TD valign="top">
The thread header uses duration types, found in the
&lt;chrono&gt; header, and which rely on the ratio types
declared in the &lt;ratio&gt; header.
&#160;
  </TD>
<TD valign="top">
Add the &lt;chrono&gt; and &lt;ratio&gt; headers to the
freestanding requirements.
It might be necessary to address scaled-down
expectations of clock support in a freestanding
environment, much like &lt;thread&gt;.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1358">1358</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB56">GB 56</A></TD>
<TD valign="top">
17.6.1.3

    &#182;
    
Table 15
&#160;
  </TD>
<TD valign="top">
The &lt;utility&gt; header provides support for several
important C++ idioms with move, forward and swap.
Likewise, declval will be frequently used like a type trait.
In order to complete cycles introduced by std::pair, the
&lt;tuple&gt; header should also be made available. This is a
similarly primitive set of functionality, with no dependency
of a hosted environment, but does go beyond the minimal
set of functionality otherwise suggested by the
freestanding libraries.
Alternatively, split the move/forward/swap/declval
functions out of &lt;utility&gt; and into a new primitive header,
requiring only that of freestanding implementation.
&#160;
  </TD>
<TD valign="top">
Add &lt;utility&gt; and &lt;tuple&gt; to table 15, headers
required for a free-standing implementation.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1359">1359</A>&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>No consensus for a change at this time. 
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB57">GB 57</A></TD>
<TD valign="top">
17.6.1.3

    &#182;
    
Table 15
&#160;
  </TD>
<TD valign="top">
The atomic operations facility is closely tied to clause 1
and the memory model. It is not easily supplied as an
after-market extension, and should be trivial to implement
of a single-threaded serial machine. The consequence of
not having this facility will be poor interoperability with
future C++ libraries that memory model concerns
seriously, and attempt to treat them in a portable way.
&#160;
  </TD>
<TD valign="top">
Add &lt;atomic&gt; to table 15, headers required for a
free-standing implementation.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1360">1360</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB58">GB 58</A></TD>
<TD valign="top">
17.6.2
&#160;
  </TD>
<TD valign="top">
It is not clear whether a library header specified in terms
of a typedef name makes that same typedef name
available for use, or if it simply requires that the specified
type is an alias of the same type, and so the typedef name
cannot be used without including the specific header that
defines it. For example, is the following code required to
be accepted:
<PRE>
#include &lt;vector&gt;
std::size_t x = 0;
</PRE>
Most often, this question concerns the typedefs defined in
header &lt;cstddef&gt;
&#160;
  </TD>
<TD valign="top">
Add a paragraph under 17.6.2 clarifying whether
or not headers specified in terms of std::size_t can
be used to access the typedef size_t, or whether
the header &lt;cstddef&gt; must be included to reliably
use this name.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1361">1361</A>&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>The standard is correct as written. 
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB59">GB 59</A></TD>
<TD valign="top">
17.6.3.6

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
The replaceable functions in header &lt;new&gt; are all
described in clause 18.6 [support.dynamic], where it can
be seen that all the listed functions have an exception
specification which must be compatible with any
replacement function.
Narrow the reference to (Clause 18) to (Clause
18.6).
&#160;
  </TD>
<TD valign="top">
Add the missing exception specification on each
function signature:<BR>
void* operator new(std::size_t size)
throw(std::bad_alloc);<BR>
void* operator new(std::size_t size, const
std::nothrow_t&amp;) throw();<BR>
void operator delete(void* ptr) throw();<BR>
void operator delete(void* ptr, const
std::nothrow_t&amp;) throw();<BR>
void* operator new[](std::size_t size)
throw(std::bad_alloc);<BR>
void* operator new[](std::size_t size, const
std::nothrow_t&amp;) throw();<BR>
void operator delete[](void* ptr) throw();<BR>
void operator delete[](void* ptr, const
std::nothrow_t&amp;) throw();<BR>
(note that other comments might further want to
replace 'throw()' with 'noexcept')
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
Cross-reference changed as requested.  Additions to name mentions
not done: these are not declarations.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US81">US 81</A></TD>
<TD valign="top">
17.6.3.9

    &#182;
    
p1
&#160;
  </TD>
<TD valign="top">
International Standards do not make &#8220;statements&#8221;; they
&#8220;specify&#8221; or &#8220;require&#8221; instead.
&#160;
  </TD>
<TD valign="top">
s/statements/ specifications/
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
Removed the offending word.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US82">US 82</A></TD>
<TD valign="top">
17.6.3.9

    &#182;
    
p1, bullet 3
&#160;
  </TD>
<TD valign="top">
The second Note can benefit by adopting recent
nomenclature.
&#160;
  </TD>
<TD valign="top">
Rephrase the Note in terms of xvalue.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1362">1362</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US83">US 83</A></TD>
<TD valign="top">
17.6.3.10

    &#182;
    
p2, first sent.
&#160;
  </TD>
<TD valign="top">
The word &#8220;constructor&#8221; is misspelled.
&#160;
  </TD>
<TD valign="top">
s/contructor/constructor/
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB68">GB 68</A></TD>
<TD valign="top">
18.2

    &#182;
    
4
&#160;
  </TD>
<TD valign="top">
There is no reason for the offsetof macro to invoke
potentially throwing operations, so the result of
noexcept(offsetof(type,member-designator)) should be
true.
&#160;
  </TD>
<TD valign="top">
Add to the end of 18.2p4:<BR>
"No operation invoked by the offsetof macro shall
throw an exception, and
noexcept(offsetof(type,member-designator)) shall
be true."
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1363">1363</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP68">JP 68</A></TD>
<TD valign="top">
18.3.1.5

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
In some code examples, ellipsis(...) is used in ill-formed.
In these cases, "..." represents omission of some codes
like this:<BR>
class A { /* ... */ } ;<BR>
But in some cases, it is used without commented-out as
below:<BR>
class A { ... } ;<BR>
It is an inconsistent usage. They all should be enclosed in
a comment.
More over, in this case, "implementation-defined" would
be better than "...".
&#160;
  </TD>
<TD valign="top">
Change to:<BR>
<PRE>
inline static constexpr float infinity() throw() {
return /* ... */; }
inline static constexpr float quiet_NaN() throw() {
return /* ... */; }
inline static constexpr float signaling_NaN()
throw() { return /* ... */; }
</PRE>
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
Replaced "..." by "value".
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP84">JP 84</A></TD>
<TD valign="top">
18.5

    &#182;
    
5 note
&#160;
  </TD>
<TD valign="top">
Note in paragraph 5 says "the atexit() functions shall not
introduce a data race" and Note in paragraph 10 says "the
at_quick_exit() functions do not introduce ...".
Such different expressions in similar functions are
confusing.
If these notes are written for unspecified behaviors just
before the sentence, "do" would be preferred.
&#160;
  </TD>
<TD valign="top">
Replace "shall" with "do".
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB69">GB 69</A></TD>
<TD valign="top">
18.5

    &#182;
    
14
&#160;
  </TD>
<TD valign="top">
("The function quick_exit() never returns to its caller.")
should be removed as redundant. The function is already
attributed
with [[noreturn]].
&#160;
  </TD>
<TD valign="top">
Remove paragraph 14
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="CH19">CH 19</A></TD>
<TD valign="top">
18.8.5
&#160;
  </TD>
<TD valign="top">
It's not clear how exception_ptr is synchronized.
&#160;
  </TD>
<TD valign="top">
Make clear that accessing in different threads
multiple exception_ptr objects that all refer to the
same exception introduce a race.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1364">1364</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB70">GB 70</A></TD>
<TD valign="top">
18.6
&#160;
  </TD>
<TD valign="top">
std::nothrow_t is a literal type (being an empty POD) so
the preferred form of declaration for std::nothrow is as a
constexpr literal, rather than an extern symbol.
&#160;
  </TD>
<TD valign="top">
Replace:<BR>
extern const nothrow_t nothrow;<BR>
with<BR>
constexpr nothrow_t nothrow{};
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>There was consensus that it is too late to make such a change at this time.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB71">GB 71</A></TD>
<TD valign="top">
18.6.2.4 / 18.8.2.2 / 18.8.3.2
&#160;
  </TD>
<TD valign="top">
The thread safety of std::set_new_handler(),
std::set_unexpected(), std::set_terminate(), is unspecified
making the the functions impossible to use in a thread
safe manner.
&#160;
  </TD>
<TD valign="top">
The thread safety guarantees for the functions
must be specified and new interfaces should be
provided to make it possible to query and install
handlers in a thread safe way.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1365">1365</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/N3189.html">
     N3189</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="DE14">DE 14</A></TD>
<TD valign="top">
18.6.1.4
&#160;
  </TD>
<TD valign="top">
It is unclear how a user replacement function can
simultaneously satisfy the race-free conditions imposed in
this clause and query the new-handler in case of a failed
allocation with the only available, mutating interface
std::set_new_handler.
&#160;
  </TD>
<TD valign="top">
Offer a non-mutating interface to query the current
new-handler.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1366">1366</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/N3189.html">
     N3189</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB72">GB 72</A></TD>
<TD valign="top">
18.8.2
&#160;
  </TD>
<TD valign="top">
Dynamic exception specifications are deprecated, so
clause 18.8.2 that describes library support for this facility
should move to Annex D, with the exception of the
bad_exception class which is retained to indicate other
failures in the exception dispatch mechanism (e.g. calling
current_exception()).
&#160;
  </TD>
<TD valign="top">
With the exception of 18.8.2.1 [bad.exception],
move clause 18.8.2 diectly to Annex D.
[bad.exception] should simply become the new
18.8.2.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1367">1367</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB73">GB 73</A></TD>
<TD valign="top">
18.8.4
&#160;
  </TD>
<TD valign="top">
The thread safety std::uncaught_exception() and the
result of the function when multiple threads throw
exceptions at the same time are unspecified. To make the
function safe to use in the presence of exceptions in
multiple threads the specification needs to be updated.
&#160;
  </TD>
<TD valign="top">
Update this clause to support safe calls from
multiple threads without placing synchronization
requirements on the user.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1368">1368</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB74">GB 74</A></TD>
<TD valign="top">
18.8.5

    &#182;
    
10
&#160;
  </TD>
<TD valign="top">
One idea for the exception_ptr type was that a referencecounted
implementation could simply 'reactivate' the same
exception object in the context of a call to
'rethrow_exception'. Such an implementation would allow
the same exception object to be active in multiple threads
(such as when multiple threads join on a shared_future)
and introduce potential data races in any exception
handler that catches exceptions by reference - notably
existing library code written before this capability was
added. 'rethrow_exception' should *always* make a copy
of the target exception object.
&#160;
  </TD>
<TD valign="top">
Throws: a copy of the exception object to which p
refers.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1369">1369</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US84">US 84</A></TD>
<TD valign="top">
18.8.6 [except.nested]

    &#182;
    
6-7
&#160;
  </TD>
<TD valign="top">
The throw_with_nested spec passes in its argument as
T&amp;&amp; (perfect forwarding pattern), but then discusses
requirements on T without taking into account that T may
be an lvalue-reference type. It is also not clear in the
spec that t is intended to be perfectly forwarded.
&#160;
  </TD>
<TD valign="top">
Patch 6-7 to match the intent with regards to
requirements on T and the use of
std::forward&lt;T&gt;(t).
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1370">1370</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB75">GB 75</A></TD>
<TD valign="top">
19
&#160;
  </TD>
<TD valign="top">
None of the exception types defined in clause 19 are
allowed to throw an exception on copy or move
operations, but there is no clear specification that the
operations have an exception specification to prove it.
Note that the implicitly declared constructors, taking the
exception specification from their base class (ultimately
std::exception) will implicitly generate a noexcept
exception specification if all of their data members
similarly declare noexcept operations. As the
representation is unspecified, we cannot assume nonthrowing
operations unless we explicitly state this as a
constraint on the implementation.
&#160;
  </TD>
<TD valign="top">
Add a global guarantee that all exception types
defined in clause 19 that rely on implicitly declared
operations have a non-throwing exception
specification on those operations.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1371">1371</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB76">GB 76</A></TD>
<TD valign="top">
19.5.1.5
&#160;
  </TD>
<TD valign="top">
The C++0x FCD recommends, in a note (see 19.5.1.1/1),
that users
create a single error category object for each user defined
error
category and specifies error_category equality
comparsions based on
equality of addresses (19.5.1.3). The Draft apparently
ignores this
when specifying standard error category objects in section
19.5.1.5,
by allowing the generic_category() and system_category()
functions to
return distinct objects for each invocation.
&#160;
  </TD>
<TD valign="top">
Append a new sentence to 19.5.1.5
[syserr.errcat.objects]/1, which
reads "All calls of this function return references to
the same
object.", and append the same sentence to
19.5.1.5/3.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1372">1372</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB77">GB 77</A></TD>
<TD valign="top">
19.5.6.2

    &#182;
    
14
&#160;
  </TD>
<TD valign="top">
The description for system_error::what (19.5.6.2/14)
changed between
the C++ Working Papers N2914 and N2960. The latter
document indicates
that the Returns clause shall read "Returns: An NTBS
incorporating the
arguments supplied in the constructor.". Instead, in the
FCD it now
reads "Returns: An NTBS incorporating and
code().message() the
arguments supplied in the constructor.".&#160;
  </TD>
<TD valign="top">
Remove the extra words from 19.5.6.2
[syserr.syserr.members]/14:
"Returns: A NTBS incorporating the arguments
supplied in the
constructor."
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB78">GB 78</A></TD>
<TD valign="top">
19.5.6.2
&#160;
  </TD>
<TD valign="top">
The FCD contains a requirement that all standard classes
which are
derived from std::exception have a copy constructor and
copy
assignment operator which essentially copy the stored
what() message
(See 18.8.1/2). In contrast, it is unspecified whether
copies of
system_error return the same error_code on calls to
system_error::code().
&#160;
  </TD>
<TD valign="top">
Insert a new paragraph after 19.5.6.1
[syserr.syserr.overview]/1 which
reads "The copy constructor and copy assignment
operator of class
system_error both have a strengthened
postcondition which supplements
the basic postcondition for standard library
exception classes copy
construction and copy assigment (18.8.1): If two
objects lhs and rhs
both have type system_error and lhs is a copy of
rhs, then lhs.code()
== rhs.code() shall hold."
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>This is already addressed by 17.5.2.2 [functions.within.classes]/1. 
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB79">GB 79</A></TD>
<TD valign="top">
20, 22, 24, 28
&#160;
  </TD>
<TD valign="top">
The library provides several traits mechanisms intended a
customization points for users. Typically, they are
declared in headers that are growing quite large. This is
not a problem for standard library vendors, who can
manage their internal file structure to avoid large
dependencies, but can be a problem for end users who
have no option but to include these large headers.
&#160;
  </TD>
<TD valign="top">
Move the following traits classes into their own
headers, and require the existing header to
#include the traits header to support backwards
compatibility:<BR>
iterator_traits (plus the iterator tag-types)<BR>
allocator_traits<BR>
pointer_traits<BR>
char_traits<BR>
regex_traits
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1373">1373</A>&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>This suggest is not a defect, as the likely benefit is small, if any, compared to the cost of not just implementating the feature, but also explaining/teaching it. 
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US85">US 85</A></TD>
<TD valign="top">
20.2.1

    &#182;
    
Table 34
&#160;
  </TD>
<TD valign="top">
20.2.1 Table 34 "MoveConstructible requirements" says
"Note: rv remains a valid object. Its state is unspecified".
Some components give stronger guarantees. For
example, moved-from shared_ptrs are guaranteed empty
(20.9.11.2.1/25).
In general, what the standard really should say (preferably
as a global blanket statement) is that moved-from objects
can be destroyed and can be the destination of an
assignment. Anything else is radioactive. For example,
containers can be "emptier than empty". This needs to be
explicit and required generally.<BR>
Note: The last time that one of us mentioned "emptier
than empty" (i.e. containers missing sentinel nodes, etc.)
the objection was that containers can store sentinel nodes
inside themselves in order to avoid dynamically allocating
them. This is unacceptable because (a) it forces existing
implementations (i.e. Dinkumware's, Microsoft's, IBM's,
etc.) to change for no good reason (i.e. permitting more
operations on moved-from objects), and (b) it invalidates
end iterators when swapping containers. (The Working
Paper currently permits end iterator invalidation, which we
consider to be wrong, but that's a separate argument. In
any event, *mandating* end iterator invalidation is very
different from permitting it.)
&#160;
  </TD>
<TD valign="top">
State as a general requirement that moved-from
objects can be destroyed and can be the
destination of an assignment. Any other use is
undefined behavior.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1374">1374</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB80">GB 80</A></TD>
<TD valign="top">
20.2.3

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
See (A) in attachment std_issues.txt
&#160;
  </TD>
<TD valign="top">
as stated in the attached paper
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="CA10">CA 10</A></TD>
<TD valign="top">
20.2.3p2

    &#182;
    
20.2.3p2
&#160;
  </TD>
<TD valign="top">
Reads of indeterminate value result in undefined
behaviour<BR>
In 20.2.3p2, NullablePointer requirements
[nullablepointer.requirements], the standard specifies the
behaviour of programs that read indeterminate values:<BR>
... A default-initialized object of type P may have
an indeterminate value. [ Note: Operations involving
indeterminate values may cause undefined behaviour.
end note ]<BR>
We suggest changing the note to:<BR>
[ Note: Operations involving indeterminate values
cause undefined behaviour. end note ]<BR>
Rationale: The note uses the word "may", but we believe
the intention is that such reads will cause undefined
behaviour, but implementations are not required to
produce an error.<BR>
Clark adds:<BR>
&gt; Unfortunately, this issue goes deeper than can be<BR>
&gt; addressed by deleting the word "may" from a note in<BR>
&gt; clause 20. The term "indeterminate value" and its<BR>
&gt; meaning were introduced in C99. While the term is<BR>
&gt; generally understood to be applicable to C++ (and<BR>
&gt; section 20.2.3 reflects that), the term isn't actually<BR>
&gt; defined in the C++ WD, and worse yet, there's no<BR>
&gt; statement that use of an indeterminate value can result<BR>
&gt; in undefined behavior (so the existing note can't be<BR>
&gt; deduced from the normative statements of the<BR>
standard).
&gt; This is tracked by core issue 616. The wording in<BR>
&gt; 20.2.3 should be noted as relating to that issue, and<BR>
&gt; should be handled as part thereof.<BR>
Further on this, in the current draft standard, we can
construct executions in which an atomic read happensbefore
the initialization of the atomic object, so there is no
place to take a read value from. We imagine that such
reads should also be of indeterminate values and result in
undefined behaviour?
&#160;
  </TD>
<TD valign="top">
In 20.2.3p2, the standard specifies the behaviour
of programs that read indeterminate values:<BR>
... A default-initialized object of
type P may have an indeterminate
value. [ Note: Operations involving<BR>
We suggest changing the note to:<BR>
[ Note: Operations involving
indeterminate values cause
undefined behaviour. end note ]
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
It is an accurate statement because there is at least one operation, assignment with the
indeterminate value on the left hand side, that does not involve undefined behavior.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US86">US 86</A></TD>
<TD valign="top">
20.2.5

    &#182;
    
Table 42
&#160;
  </TD>
<TD valign="top">
In the row for
X::propagate_on_container_move_assignment, the note
says &#8220;copied&#8221; when it should say &#8220;moved&#8221;
&#160;
  </TD>
<TD valign="top">
Change the note as follows:<BR>
true_type only if an allocator
of type X should be <del>copied</del><ins>moved</ins>
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US87">US 87</A></TD>
<TD valign="top">
20.2.5

    &#182;
    
Table 42
&#160;
  </TD>
<TD valign="top">
reference_type should not have been removed from the
allocator requirements. Even if it is always the same as
value_type&amp;, it is an important customization point for
extensions and future features.
&#160;
  </TD>
<TD valign="top">
Add a row (after value_type) with columns:<BR>
Expression: X::reference_type<BR>
Return type: T&amp;<BR>
Assertion/note...: (empty)<BR>
Default: T&amp;<BR>
[allocator.traits]: Add reference_type to
allocator_traits template, defaulted to
value_type&amp;.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1375">1375</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US88">US 88</A></TD>
<TD valign="top">
20.2.5
&#160;
  </TD>
<TD valign="top">
Allocator interface is not backward compatible.
&#160;
  </TD>
<TD valign="top">
See Appendix 1 - Additional Details
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1376">1376</A>&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>Withdrawn by the submitter. 
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US89">US 89</A></TD>
<TD valign="top">
20.3 [utility]
&#160;
  </TD>
<TD valign="top">
make_pair is missing from the &lt;utility&gt; synopsis.
&#160;
  </TD>
<TD valign="top">
Add template &lt;class T1, class T2&gt; pair&lt;V1, V2&gt;
make_pair(T1&amp;&amp;, T2&amp;&amp;); to the synopsis in
[utility].
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB81">GB 81</A></TD>
<TD valign="top">
20.3

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
make_pair should be declared in the synopsis of &lt;utility&gt;
&#160;
  </TD>
<TD valign="top">
add to 20.3 [utility] paragraph 1:<BR>
template<BR>
see below make_pair(T1&amp;&amp;, T2&amp;&amp;);
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB82">GB 82</A></TD>
<TD valign="top">
20.3

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
The &lt;utility&gt; synopsis precedes the tuple_size and
tuple_element declarations with a comment saying "//
20.3.5, tuple-like access to pair:" but the sub-clause
should be 20.3.5.3 and the comment should probably be
below those declarations (since they, like the tuple
declaration above them, are defined in &lt;tuple&gt; and are
not related to pair.)<BR>
Also, there should be a comment above
piecewise_construct_t giving the sub-clause 20.3.5.5, and
it should be at the end of the synopsis,
&#160;
  </TD>
<TD valign="top">
correct the sub-clause reference for tuple-like
access to 20.3.5.3, move the comment after the
uple_element declaration, and add "// defined in
&lt;tuple&gt;" to the tuple_size and tuple_element
declarations. Move the piecewise_construct_t and
piecewise_constrct declarations to the end of the
synopsis and precede them with "// 20.3.5.5
Piecewise construction"
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US90">US 90</A></TD>
<TD valign="top">
20.3

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
In n3090, at variance with previous iterations of the idea
discussed in papers and incorporated in WDs,
std::forward is constrained via std::is_convertible, thus is
not robust wrt access control. This causes problems in
normal uses as implementation detail of member
functions. For example, the following snippet leads to a
compile time failure, whereas that was not the case for an
implementation along the lines of n2835 (using enable_ifs
instead of concepts for the constraining, of course)
<PRE>
#include &lt;utility&gt;
struct Base { Base(Base&amp;&amp;); };
struct Derived
: private Base
{
Derived(Derived&amp;&amp; d)
: Base(std::forward&lt;Base&gt;(d)) { }
};
</PRE>
In other terms, LWG 1054 can be resolved in a better
way, the present status is not acceptable.
&#160;
  </TD>
<TD valign="top">
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1377">1377</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3143.html">
     N3143</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP28">JP 28</A></TD>
<TD valign="top">
20.3.1

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
Representations of reference link are not unified.
Most reference links to clause (table) number, say X, are
in the form "Clause X" ("Table X") capitalized, and
subsection Y.Y.Y is referenced with its number only in the
form "Y.Y.Y". Whether they are parenthesized or not
depends on the context.
However there are some notations "(Z)" consisting of only
a number Z in parentheses to confer Clause or Table
number Z.
&#160;
  </TD>
<TD valign="top">
Change "(31)" to "(Clause 31)".
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
Changed to "(Table 31)".
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP29">JP 29</A></TD>
<TD valign="top">
20.3.1

    &#182;
    
4, 6, 8
&#160;
  </TD>
<TD valign="top">
Representations of reference link are not unified.
Most reference links to clause (table) number, say X, are
in the form "Clause X" ("Table X") capitalized, and
subsection Y.Y.Y is referenced with its number only in the
form "Y.Y.Y". Whether they are parenthesized or not
depends on the context.
However there are some notations "(Z)" consisting of only
a number Z in parentheses to confer Clause or Table
number Z.
&#160;
  </TD>
<TD valign="top">
Change "(32)" to "(Clause 32)".
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
Changed to "(Table 32)".
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP30">JP 30</A></TD>
<TD valign="top">
20.3.2

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
Representations of reference link are not unified.
Most reference links to clause (table) number, say X, are
in the form "Clause X" ("Table X") capitalized, and
subsection Y.Y.Y is referenced with its number only in the
form "Y.Y.Y". Whether they are parenthesized or not
depends on the context.
However there are some notations "(Z)" consisting of only
a number Z in parentheses to confer Clause or Table
number Z.
&#160;
  </TD>
<TD valign="top">
Change "(34)" to "(Table 34)".<BR>
Change "(36)" to "(Table 36)".
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US91">US 91</A></TD>
<TD valign="top">
Merged with US 90
&#160;
  </TD>
<TD valign="top">

&#160;
  </TD>
<TD valign="top">
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1377">1377</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3143.html">
     N3143</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US92">US 92</A></TD>
<TD valign="top">
20.3.3
&#160;
  </TD>
<TD valign="top">
std::identity was removed from 20.3.3 [forward],
apparently because std::forward() no longer needs it.
However, std::identity was useful by itself (to disable
template argument deduction, and to provide no
transformation when one is requested).
&#160;
  </TD>
<TD valign="top">
Restore std::identity, possibly in a different
section.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>No consensus to restore at this time. common_type can be used for the use case given. 
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US93">US 93</A></TD>
<TD valign="top">
20.3.3

    &#182;
    
6
&#160;
  </TD>
<TD valign="top">
When teaching C++0x, students have consistently found
the name std::move confusing because it doesn't actually
move the object (it just makes it possible to move). It was
also confusing for me.
&#160;
  </TD>
<TD valign="top">
Choose a name that expresses the semantics
more clearly. Suggestion: std::unpin
&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>No consensus for a change. 
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US94">US 94</A></TD>
<TD valign="top">
20.3.3

    &#182;
    
9
&#160;
  </TD>
<TD valign="top">
Returns clause for move_if_noexcept d refers to a nonexistent
symbol, t, which should be x.
&#160;
  </TD>
<TD valign="top">
Modify the Returns clause:<BR>
Returns: std::move(<del>t</del><ins>x</ins>).
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="DE15">DE 15</A></TD>
<TD valign="top">
20.3.5.2, 20.4.2.1
&#160;
  </TD>
<TD valign="top">
Several function templates of pair and tuple allow for too
many implicit conversions, for example:
<PRE>
#include &lt;tuple&gt;
std::tuple&lt;char*&gt; p(0); // Error?
struct A { explicit A(int){} };
A a = 1; // Error
std::tuple&lt;A&gt; ta = std::make_tuple(1); // OK?
</PRE>
&#160;
  </TD>
<TD valign="top">
Consider to add wording to constrain these
function templates.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1378">1378</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3140.html">
     N3140</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP31">JP 31</A></TD>
<TD valign="top">
20.5.1

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
Representations of reference link are not unified.
Most reference links to clause (table) number, say X, are
in the form "Clause X" ("Table X") capitalized, and
subsection Y.Y.Y is referenced with its number only in the
form "Y.Y.Y". Whether they are parenthesized or not
depends on the context.
However there are some notations "(Z)" consisting of only
a number Z in parentheses to confer Clause or Table
number Z.
&#160;
  </TD>
<TD valign="top">
Change "(section 3.9)" to "(3.9)".
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB84">GB 84</A></TD>
<TD valign="top">
20.3.5.2
&#160;
  </TD>
<TD valign="top">
[pairs.pair] defines the class template pair as well as
related non-member functions such as comparison
operators and make_pair. The related non-member
functions should be in a separate sub-clause, otherwise
it's not clear that paragraphs below 17 do not refer to
members of pair.
&#160;
  </TD>
<TD valign="top">
Create a new "Pair specialized algorithms" section
containing everything below paragraph 17 in
[pairs.pair]
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US95">US 95</A></TD>
<TD valign="top">
20.3.5.2

    &#182;
    
9
&#160;
  </TD>
<TD valign="top">
Copy-assignment for pair is defaulted and does not work
for pairs with reference members. This is inconsistent with
conversion-assignment, which deliberately succeeds even
if one or both elements are reference types, just as for
tuple. The copy-assignment operator should be
consistent with the conversion-assignment operator and
with tuple's assignment operators.
&#160;
  </TD>
<TD valign="top">
Add to pair synopsis:<BR>
pair&amp; operator=(const pair&amp; p);<BR>
Add before paragraph 9:<BR>
pair&amp; operator=(const pair&amp; p);<BR>
Requires: T1 and T2 shall satisfy the
requirements of CopyAssignable.<BR>
Effects: Assigns p.first to first and p.second to
second.<BR>
Returns: *this.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1379">1379</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3140.html">
     N3140</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="DE16">DE 16</A></TD>
<TD valign="top">
20.3.5.2, 20.4.2.1
&#160;
  </TD>
<TD valign="top">
Several pair and tuple functions in regard to move
operations are incorrectly specified if the member types
are references, because the result of a std::move cannot
be assigned to lvalue-references. In this context the usage
of the requirement sets MoveConstructible and
CopyConstructible also doesn't make sense, because
non-const lvalue-references cannot satisfy these
requirements.
&#160;
  </TD>
<TD valign="top">
Replace the usage of std::move by that of
std::forward and replace MoveConstructible and
CopyConstructible requirements by other
requirements.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1380">1380</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3140.html">
     N3140</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB85">GB 85</A></TD>
<TD valign="top">
20.3.5.4
&#160;
  </TD>
<TD valign="top">
While std::pair may happen to hold a pair of iterators
forming a valid range, this is more likely a coincidence
than a feature guaranteed by the semantics of the pair
template. A distinct range-type should be supplied to
enable the new for-loop syntax rather than overloading an
existing type with a different semantic.
&#160;
  </TD>
<TD valign="top">
Strike 20.3.5.4 and the matching declarations in
20.3 header synopsis.
If a replacement facility is required for C++0x,
consider n2995.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1381">1381</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="ES1">ES 1</A></TD>
<TD valign="top">
20.3.5.4 [pair.range]
&#160;
  </TD>
<TD valign="top">
Using pair to represent a range of iterators is too general
and does not provide additional useful restrictions (see
N2995 and preceding papers).
&#160;
  </TD>
<TD valign="top">
Provide a separate template range&lt;Iterator&gt;.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>No consensus to make this change.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US96">US 96</A></TD>
<TD valign="top">
20.3.5.2 20.4.2.1 20.4.2.2

    &#182;
    
p 6-14 p 6-20 p 6-18
&#160;
  </TD>
<TD valign="top">
pair and tuple constructors and assignment operators use
std::move when they should use std::forward. This
causes lvalue references to be erroneously converted to
rvalue references. Related requirements clauses are also
wrong.
&#160;
  </TD>
<TD valign="top">
See Appendix 1 - Additional Details
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1382">1382</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3140.html">
     N3140</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US97">US 97</A></TD>
<TD valign="top">
20.3.5.2 and 20.4.2
&#160;
  </TD>
<TD valign="top">
pair's class definition in N3092 20.3.5.2 [pairs.pair]
contains "pair(const pair&amp;) = default;" and "pair&amp;
operator=(pair&amp;&amp; p);". The latter is described by
20.3.5.2/12-13.<BR>
"pair(const pair&amp;) = default;" is a user-declared explicitlydefaulted
copy constructor. According to 12.8
[class.copy]/10, this inhibits the implicitly-declared move
constructor. pair should be move constructible. (12.8/7
explains that "pair(pair&lt;U, V&gt;&amp;&amp; p)" will never be
instantiated to move pair&lt;T1, T2&gt; to pair&lt;T1, T2&gt;.)<BR>
"pair&amp; operator=(pair&amp;&amp; p);" is a user-provided move
assignment operator (according to 8.4.2
[dcl.fct.def.default]/4: "A special member function is userprovided
if it is user-declared and not explicitly defaulted
on its first declaration."). According to 12.8/20, this inhibits
the implicitly-declared copy assignment operator. pair
should be copy assignable, and was in C++98/03. (Again,
12.8/7 explains that "operator=(const pair&lt;U, V&gt;&amp; p)" will
never be instantiated to copy pair&lt;T1, T2&gt; to pair&lt;T1,
T2&gt;.)<BR>
Additionally, "pair&amp; operator=(pair&amp;&amp; p);" is
unconditionally defined, whereas according to 12.8/25,
defaulted copy/move assignment operators are defined as
deleted in several situations, such as when non-static data
members of reference type are present.<BR>
If "pair(const pair&amp;) = default;" and "pair&amp;
operator=(pair&amp;&amp; p);" were removed from pair's class
definition in 20.3.5.2 and from 20.3.5.2/12-13, pair would
receive implicitly-declared copy/move constructors and
copy/move assignment operators, and 12.8/25 would
apply. The implicitly-declared copy/move constructors
would be trivial when T1 and T2 have trivial copy/move
constructors, according to 12.8/13, and similarly for the
assignment operators, according to 12.8/27. Notes could
be added as a reminder that these functions would be
implicitly-declared, but such notes would not be necessary
(the Standard Library specification already assumes a
high level of familiarity with the Core Language, and
casual readers will simply assume that pair is copyable
and movable).<BR>
Alternatively, pair could be given explicitly-defaulted
copy/move constructors and copy/move assignment
operators. This is a matter of style.<BR>
tuple is also affected. tuple's class definition in 20.4.2
[tuple.tuple] contains:
<PRE>
tuple(const tuple&amp;) = default;
tuple(tuple&amp;&amp;);
tuple&amp; operator=(const tuple&amp;);
tuple&amp; operator=(tuple&amp;&amp;);
</PRE>
They should all be removed or all be explicitly-defaulted,
to be consistent with pair. Additionally, 20.4.2.1
[tuple.cnstr]/8-9 specifies the behavior of an explicitlydefaulted
function, which is currently inconsistent with
pair.
&#160;
  </TD>
<TD valign="top">
Either remove "pair(const pair&amp;) = default;" and
"pair&amp; operator=(pair&amp;&amp; p);" from pair's class
definition in 20.3.5.2 and from 20.3.5.2/12-13, or
give pair explicitly-defaulted copy/move
constructors and copy/move assignment
operators.<BR>
Change tuple to match.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1383">1383</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3140.html">
     N3140</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB86">GB 86</A></TD>
<TD valign="top">
20.4
&#160;
  </TD>
<TD valign="top">
tuple and pair are essentially two implementations of the
same type, with the same public interface, and their
specification in becoming increasingly intertwined. The
tuple library should be merged into the &lt;utility&gt; header to
reduce library dependencies and simplify user
expectations. The &lt;tuple&gt; header could optionally be
retained as a deprecated alias to the &lt;utility&gt; header.
&#160;
  </TD>
<TD valign="top">
Merge everything declared in 20.4 into the
&lt;utility&gt; header. Either remove the &lt;tuple&gt; header
entirely, or move it to Annex D as a deprecated
alias of the &lt;utility&gt; header.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>There was no consensus to make this change.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US98">US 98</A></TD>
<TD valign="top">
20.4.2.4

    &#182;
    
Paragraph 4
&#160;
  </TD>
<TD valign="top">
pack_arguments is poorly named. It does not reflect the
fact that it is a tuple creation function and that it forwards
arguments.
&#160;
  </TD>
<TD valign="top">
Rename pack_arguments to forward_as_tuple
throughout the standard.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1384">1384</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB88">GB 88</A></TD>
<TD valign="top">
20.4.2.4
&#160;
  </TD>
<TD valign="top">
The tuple_cat template consists of four overloads and that
can concatenate only two tuples. A single variadic
signature that can concatenate an arbitrary number of
tuples would be preferred.
&#160;
  </TD>
<TD valign="top">
Adopt a simplified form of the proposal in n2795,
restricted to tuples and neither requiring nor
outlawing support for other tuple-like types.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1385">1385</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US99">US 99</A></TD>
<TD valign="top">
20.4.2.4

    &#182;
    
4 - 6
&#160;
  </TD>
<TD valign="top">
pack_arguments is overly complex.
&#160;
  </TD>
<TD valign="top">
This issue resulted from a lack of understanding of
how references are forwarded. The definition of
pack_arguments should be simply:<BR>
template &lt;class... Types&gt;
tuple&lt;<del>A</del>Types<ins>&amp;&amp;</ins>&gt;
pack_arguments(Types&amp;&amp;...t);<BR>
<del>Types:Let Ti be each type in Types....</del><BR>
Effects: ...<BR>
Returns:<BR>
tuple&lt;<del>A</del>Types<ins>&amp;&amp;</ins>...&gt;(std::forward&lt;Types&gt;(t)...)<BR>
The synopsis should also change to reflect this
simpler signature.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1386">1386</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB87">GB 87</A></TD>
<TD valign="top">
20.4.2.10
&#160;
  </TD>
<TD valign="top">
There is no compelling reason to assume a
heterogeneous tuple of two elements holds a pair of
iterators forming a valid range. Unlike std::pair, there are
no functions in the standard library using this as a return
type with a valid range, so there is even less reason to try
to adapt this type for the new for-loop syntax.
&#160;
  </TD>
<TD valign="top">
Strike 20.4.2.10 and the matching declarations in
the header synopsis in 20.4.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1387">1387</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US100">US 100</A></TD>
<TD valign="top">
20.6.1 [ratio.ratio]
&#160;
  </TD>
<TD valign="top">
LWG 1281 was discussed in Pittsburgh, and the decision
there was to accept the typedef as proposed and move to
Review. Unfortunately the issue was accidentally applied
to the FCD, and incorrectly. The FCD version of the
typedef refers to ratio&lt;N, D&gt;, but the typedef is intended
to refer to ratio&lt;num, den&gt; which in general is not the
same type.
&#160;
  </TD>
<TD valign="top">
Accept the current proposed wording of LWG
1281 which adds:<BR>
typedef ratio&lt;num, den&gt; type;
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1388">1388</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB89">GB 89</A></TD>
<TD valign="top">
20.6.2
&#160;
  </TD>
<TD valign="top">
The alias representations of the ratio arithmetic templates
do not allow implementations to avoid overflow, since they
explicitly specify the form of the aliased template
instantiation. For example
ratio_multiply,ratio&lt;2,LLONG_MAX&gt;&gt; is *required* to
alias ratio&lt;2*LLONG_MAX,LLONG_MAX*2&gt;, which
overflows, so is ill-formed. However, this is trivially equal
to ratio&lt;1,1&gt;. It also contradicts the opening statement of
20.6.2p1 "implementations may use other algorithms to
compute these values".
&#160;
  </TD>
<TD valign="top">
Change the wording in 20.6.2p2-5 as follows:<BR>
template &lt;class R1, class R2&gt; using ratio_add =
see below;<BR>
The type ratio_add&lt;R1, R2&gt; shall be a synonym
for
<del>ratio&lt;T1,T2&gt;</del> <ins>ratio&lt;U, V&gt; such
that ratio&lt;U,V&gt;::num and
ratio&lt;U,V&gt;::den are the same as the
corresponding members of
ratio&lt;T1,T2&gt; would be in the absence of
arithmetic overflow</ins>
where T1 has the value R1::num * R2::den +
R2::num * R1::den and T2
has the value R1::den * R2::den. <ins>If the
required values of
ratio&lt;U,V&gt;::num and ratio&lt;U,V&gt;::den cannot be
represented in intmax_t
then the program is illformed.</ins><BR>
template &lt;class R1, class R2&gt; using
ratio_subtract = see below;<BR>
The type ratio_subtract&lt;R1, R2&gt; shall be a
synonym for
<del>ratio&lt;T1,T2&gt;</del> <ins>ratio&lt;U, V&gt; such
that ratio&lt;U,V&gt;::num and
ratio&lt;U,V&gt;::den are the same as the
corresponding members of
ratio&lt;T1,T2&gt; would be in the absence of
arithmetic overflow</ins>
where T1 has the value R1::num * R2::den -
R2::num * R1::den and T2
has the value R1::den * R2::den. <ins>If the
required values of
ratio&lt;U,V&gt;::num and ratio&lt;U,V&gt;::den cannot be
represented in intmax_t
then the program is illformed.</ins><BR>
template &lt;class R1, class R2&gt; using ratio_multiply
= see below;<BR>
The type ratio_multiply&lt;R1, R2&gt; shall be a
synonym for
<del>ratio&lt;T1,T2&gt;</del> <ins>ratio&lt;U, V&gt; such
that ratio&lt;U,V&gt;::num and
ratio&lt;U,V&gt;::den are the same as the
corresponding members of
ratio&lt;T1,T2&gt; would be in the absence of
arithmetic overflow</ins>
where T1 has the value R1::num * R2::num and
T2 has the value R1::den
* R2::den. <ins>If the required values of
ratio&lt;U,V&gt;::num and
ratio&lt;U,V&gt;::den cannot be represented in
intmax_t then the program is
illformed.</ins><BR>
template &lt;class R1, class R2&gt; using ratio_divide
= see below;<BR>
The type ratio_divide&lt;R1, R2&gt; shall be a
synonym for
<del>ratio&lt;T1,T2&gt;</del> <ins>ratio&lt;U, V&gt; such
that ratio&lt;U,V&gt;::num and
ratio&lt;U,V&gt;::den are the same as the
corresponding members of
ratio&lt;T1,T2&gt; would be in the absence of
arithmetic overflow</ins>
where T1 has the value R1::num * R2::den and T2
has the value R1::den
* R2::num. <ins>If the required values of
ratio&lt;U,V&gt;::num and
ratio&lt;U,V&gt;::den cannot be represented in
intmax_t then the program is
illformed.</ins>
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1389">1389</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/N3210.pdf">
     N3210</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US101">US 101</A></TD>
<TD valign="top">
20.7
&#160;
  </TD>
<TD valign="top">
Paper n2965 was largely rejected after the last CD on the
grounds there was no associated national body comment,
so I am submitting a national body comment this time.
&#160;
  </TD>
<TD valign="top">
Consider n2965 in the context of a national body
comment.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>There is no consensus to adopt this proposal at this time. 
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB90">GB 90</A></TD>
<TD valign="top">
20.7
&#160;
  </TD>
<TD valign="top">
type_traits is a core support facility offered by the
compiler, and exposed with a library interface that is
required in a free-standing implementation. It has far more
in common with numeric_limits than the utility components
in clause 20, and should move to clause 18.
&#160;
  </TD>
<TD valign="top">
Move clause 20.7 into clause 18.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
Type traits support queries about all types, not just
built-in types. They do not belong in Clause 18.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="DE17">DE 17</A></TD>
<TD valign="top">
20.7
&#160;
  </TD>
<TD valign="top">
Speculative compilation for std::is_constructible and
std::is_convertible should be limited, similar to the core
language (see 14.8.2 paragraph 8).
&#160;
  </TD>
<TD valign="top">
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1390">1390</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3142.htm">
     N3142</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="DE18">DE 18</A></TD>
<TD valign="top">
20.7
&#160;
  </TD>
<TD valign="top">
Several type traits require compiler support, e.g.
std::is_constructible or std::is_convertible. Their current
specification seems to imply, that the corresponding test
expressions should be well-formed, even in absense of
access:
<PRE>
class X { X(int){} };
constexpr bool test = std::is_constructible&lt;X, int&gt;::value;
</PRE>
The specification does not clarify the context of this test
and because it already goes beyond normal language
rules, it's hard to argue by means of normal language
rules what the context and outcome of the test should be.
&#160;
  </TD>
<TD valign="top">
Specify that std::is_constructible and
std::is_convertible will return true only for public
constructors/conversion functions.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1391">1391</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3142.htm">
     N3142</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US102">US 102</A></TD>
<TD valign="top">
20.7.4
&#160;
  </TD>
<TD valign="top">
Despite Library Issue 520's ("Result_of and pointers to
data members") resolution of CD1, the FCD's result_of
supports neither pointers to member functions nor
pointers to data members. It should.
&#160;
  </TD>
<TD valign="top">
Ensure result_of supports pointers to member
functions and pointers to data members.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1392">1392</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3123.html">
     N3123</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB91">GB 91</A></TD>
<TD valign="top">
20.7.4.3

    &#182;
    
Table 45
&#160;
  </TD>
<TD valign="top">
It is mildly distasteful to dereference a null pointer as part
of our specification, as we are playing on the edges of
undefined behaviour. With the addition of the declval
function template, already used in these same
expressions, this is no longer necessary.
&#160;
  </TD>
<TD valign="top">
Replace the sub-expression '*(U*)0' with the subexpression
'declval&lt;U&amp;&gt;()' in the specification for
has_nothrow_copy_assign and
has_nothrow_move_assign type traits.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
There is no undefined behavior because the expression
is an unevaluated operand. It's not at all clear that
the proposed change would be clearer.
<BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3142.htm">
     N3142</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB92">GB 92</A></TD>
<TD valign="top">
20.7.4.3

    &#182;
    
Table 45
&#160;
  </TD>
<TD valign="top">
Trivial functions implicitly declare a noexcept exception
specification, so the references to has_trivial_* traits in the
has_nothrow_* traits are redundant, and should be struck
for clarity.
&#160;
  </TD>
<TD valign="top">
For each of the has_nothrow_something traits,
remove all references to the matching
has_trivial_something traits.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1393">1393</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3142.htm">
     N3142</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="FI18">FI 18</A></TD>
<TD valign="top">
20.7.4.3, Table 45 (Type property predicates)
&#160;
  </TD>
<TD valign="top">
Related to the change proposed in FI 17, there should be
a trait for checking whether a destructor throws.
&#160;
  </TD>
<TD valign="top">
Add the following type predicate:
Template
<PRE>
template &lt;typename T&gt; struct
has_nothrow_destructor;
</PRE>
Condition<BR>
has_trivial_destructor&lt;T&gt;::value is true or the
expression
noexcept((*(U*)0).~U()) is well-formed and true,
where U is
remove_all_extents&lt;T&gt;::type.<BR>
Precondition<BR>
T shall be a complete type, (possibly cv-qualified)
void, or an array of
unknown bound.<BR>
Reasoning:<BR>
With this metafunction the destructor of a class
template can adjust its
noexcept specification depending on whether
destructors of its unbound
members (or unbound base classes) might throw:
<PRE>
template &lt;typename T&gt;
struct C
{
T t;
~C()
noexcept(has_nothrow_destructor&lt;T&gt;::value) {}
};
</PRE>
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>No consensus to make this change at this time. 
<BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3142.htm">
     N3142</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="DE19">DE 19</A></TD>
<TD valign="top">
20.7.4.3
&#160;
  </TD>
<TD valign="top">
The fundamental trait is_constructible reports false
positives, e.g.
<PRE>
is_constructible&lt;char*, void*&gt;::value
</PRE>
evaluates to true, even though a corresponding variable
initialization would be ill-formed.
&#160;
  </TD>
<TD valign="top">
Remove all false positives from the domain of
is_constructible.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1394">1394</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3047.html">
     N3047</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP32">JP 32</A></TD>
<TD valign="top">
20.7.5

    &#182;
    
2, table 47
&#160;
  </TD>
<TD valign="top">
Representations of reference link are not unified.
Most reference links to clause (table) number, say X, are
in the form "Clause X" ("Table X") capitalized, and
subsection Y.Y.Y is referenced with its number only in the
form "Y.Y.Y". Whether they are parenthesized or not
depends on the context.
However there are some notations "(Z)" consisting of only
a number Z in parentheses to confer Clause or Table
number Z.
&#160;
  </TD>
<TD valign="top">
Change "(10)" to "(Clause 10)".
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1395">1395</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB93">GB 93</A></TD>
<TD valign="top">
20.7.6.2

    &#182;
    
Table 49
&#160;
  </TD>
<TD valign="top">
The comments for add_rvalue_reference say "this rule
reflects the semantics of reference collapsing", but
reference collapsing is not defined anywhere.
&#160;
  </TD>
<TD valign="top">
Add a new sentence at the end of 8.3.2p6 "This is
called reference collapsing".
Add a reference to 8.3.2 to the use of "reference
collapsing" in 20.7.6.2/table 49
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US103">US 103</A></TD>
<TD valign="top">
20.7.6.6 [meta.trans.other]
&#160;
  </TD>
<TD valign="top">
The current definition of result_of works for function
pointers but the condition statement outlaws them. There
is even an example in the WP that shows result_of
working for function pointers.
&#160;
  </TD>
<TD valign="top">
Add &#8220;pointer to function&#8221; to the list of things that
Fn shall be.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>Standard is correct as written. 
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US104">US 104</A></TD>
<TD valign="top">
28.8
&#160;
  </TD>
<TD valign="top">
std::basic_regex should have an allocator for all the
reasons that a std::string does. For example, I can use
boost::interprocess to put a string or vector in shared
memory, but not a regex.
&#160;
  </TD>
<TD valign="top">
Add allocators to regexes
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1396">1396</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB94">GB 94</A></TD>
<TD valign="top">
20.8
&#160;
  </TD>
<TD valign="top">
This subclause has grown large, with many components,
and so should stand alone.
&#160;
  </TD>
<TD valign="top">
Promote 20.8 and all its contents up to a new
numbered clause.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB95">GB 95</A></TD>
<TD valign="top">
20.8
&#160;
  </TD>
<TD valign="top">
The adaptable function protocol supported by
unary_function/binary_function has been superceded by
lambda expressions and std::bind. Despite the name, the
protocol is not very adaptable as it requires intrusive
support in the adaptable types, rather than offering an
external traits-like adaption mechanism. This protocol and
related support functions should be deprecated, and we
should not make onerous requirements for the
specification to support this protocol for callable types
introduced in this standard revision, including those
adopted from TR1. It is expected that high-quality
implementations will provide such support, but we should
not have to write robust standard specifications mixing this
restricted support with more general components such as
function, bind and reference_wrapper.
&#160;
  </TD>
<TD valign="top">
Move clauses 20.8.3, 20.8.9, 20.8.11 and 20.8.12
to Annex D. Remove the requirements to
conditionally derive from unary/binary_function
from function, reference_wrapper, and the results
of calling mem_fn and bind.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1397">1397</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3198.html">
     N3198</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB96">GB 96</A></TD>
<TD valign="top">
20.8
&#160;
  </TD>
<TD valign="top">
The function templates 'hash', 'less' and 'equal_to' are
important customization points for user-defined types to
be supported by several standard containers. These are
accessed through the &lt;functional&gt; header which has
grown significantly larger in C++0x, exposing many more
facilities than a user is likely to need through there own
header, simply to declare the necessary specialization.
There should be a smaller header available for users to
make the necessary customization.
&#160;
  </TD>
<TD valign="top">
Provide a tiny forwarding header for important
functor types in the &lt;functional&gt; header that a
user may want to specialize. This should contain
the template declaration for 'equal_to', 'hash' and
'less'.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1398">1398</A>&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>No consensus to make a change.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB97">GB 97</A></TD>
<TD valign="top">
20.8.10
&#160;
  </TD>
<TD valign="top">
The bind template is intended as a singe, simple to use
replacement for the '98 adaptable function APIs and
machinery. It works well in almost all respects, but lacks
the ability to easily negate a predicate, or equivalently, act
as a replacement for not1 and not2. Two easy ways to
solve this omission would be to add a 'bind_not' function
that produces a binder that negates its result. However,
preference is given to requiring the unspecified bind result
type to overload operator! to produce the same effect.
This is preferred due to (i) its simpler usage, being the
naively expected syntax, but more importantly (ii) some
(limited) field experience.
&#160;
  </TD>
<TD valign="top">
Require the unspecified result of a bind
expression to support unary operator! to yield
another bind result that, when evaluated, yields
'!res', where 'res' is the result of evaluating the
original function.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>No consensus for a change at this time. 
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP3">JP 3</A></TD>
<TD valign="top">
20.8.14.2
&#160;
  </TD>
<TD valign="top">
explicit default contructor is defined in std::function.
Although it is allowed according to 12.3.1, it seems
unnecessary to qualify the constructor as explicit.
If it is explicit, there will be a limitation in initializer_list.
&#160;
  </TD>
<TD valign="top">
Remove explicit.
<PRE>
namespace std {
template&lt;class&gt; class function;
// undefined
template&lt;class R, class... ArgTypes&gt;
class function&lt;R(ArgTypes...)&gt;
: public unary_function&lt;T1, R&gt;
// iff sizeof...(ArgTypes) == 1 and ArgTypes
contains T1
: public binary_function&lt;T1, T2, R&gt;
// iff sizeof...(ArgTypes) == 2 and ArgTypes
contains T1 andT2
{
public:typedef R result_type;
// 20.8.14.2.1, construct/copy/destroy:function();
</PRE>
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1399">1399</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP33">JP 33</A></TD>
<TD valign="top">
20.8.15

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
Representations of reference link are not unified.
Most reference links to clause (table) number, say X, are
in the form "Clause X" ("Table X") capitalized, and
subsection Y.Y.Y is referenced with its number only in the
form "Y.Y.Y". Whether they are parenthesized or not
depends on the context.
However there are some notations "(Z)" consisting of only
a number Z in parentheses to confer Clause or Table
number Z.
&#160;
  </TD>
<TD valign="top">
Change "(37)" to "(Table 37)".
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP34">JP 34</A></TD>
<TD valign="top">
20.8.15

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
Representations of reference link are not unified.
Most reference links to clause (table) number, say X, are
in the form "Clause X" ("Table X") capitalized, and
subsection Y.Y.Y is referenced with its number only in the
form "Y.Y.Y". Whether they are parenthesized or not
depends on the context.
However there are some notations "(Z)" consisting of only
a number Z in parentheses to confer Clause or Table
number Z.
&#160;
  </TD>
<TD valign="top">
Change "(33)" to "(Table 33)".
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP4">JP 4</A></TD>
<TD valign="top">
20.8.14.2.1

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
Really does the function require that default constructor is
explicit?
&#160;
  </TD>
<TD valign="top">
Remove explicit.
<PRE>
function();
template &lt;class A&gt;
function(allocator_arg_t, const A&amp; a);
</PRE>
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1400">1400</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US105">US 105</A></TD>
<TD valign="top">
20.8.15.2
&#160;
  </TD>
<TD valign="top">
unique_ptr and shared_ptr are inconsistent in their
handling of arrays. We can write:
<PRE>
unique_ptr&lt;int[]&gt; p( new int[10] );
// handles deletion correctly
</PRE>
But we cannot write:
<PRE>
shared_ptr&lt;int[]&gt; p( new int[10] );
// incorrect
</PRE>
This is an inconsistency. It is true that we have the
following workaround:
<PRE>
std::shared_ptr&lt;int&gt; s(new int[5],
std::default_delete&lt;int[]&gt;());
</PRE>
But this is still inconsistent, not to mention awkward and
error-prone because the programmer will occasionally
forget the deleter and the code will silently compile and
may appear to work on some platforms.
&#160;
  </TD>
<TD valign="top">
Support:
<PRE>
shared_ptr&lt;int[]&gt; p( new int[10] );
</PRE>
to handle deletion correctly by calling delete[] on
the stored pointer.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB98">GB 98</A></TD>
<TD valign="top">
20.9
&#160;
  </TD>
<TD valign="top">
This subclause has grown large, with many components,
and so should stand alone.
&#160;
  </TD>
<TD valign="top">
Promote 20.9 and all of its contents to a new, toplevel,
numbered clause.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB99">GB 99</A></TD>
<TD valign="top">
20.9

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
One reason that the unique_ptr constructor taking a
nullptr_t argument is not explicit is to allow conversion of
nullptr to unique_ptr in contexts like equality comparison.
Unfortunately operator== for unique_ptr is a little more
clever than that, deducing template parameters for both
arguments. This means that nullptr does not get deduced
as unique_ptr type, and there are no other comparison
functions to match.
&#160;
  </TD>
<TD valign="top">
Add the following signatures to 20.9p1, &lt;memory&gt;
header synopsis:
<PRE>
template&lt;typename T, typename D&gt; bool
operator==(const unique_ptr&lt;T, D&gt; &amp; lhs,
nullptr_t);
template&lt;typename T, typename D&gt; bool
operator==(nullptr_t, const unique_ptr&lt;T, D&gt; &amp;
rhs);
template&lt;typename T, typename D&gt; bool
operator!=(const unique_ptr&lt;T, D&gt; &amp; lhs,
nullptr_t);
template&lt;typename T, typename D&gt; bool
operator!=(nullptr_t, const unique_ptr&lt;T, D&gt; &amp;
rhs);
</PRE>
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1401">1401</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB100">GB 100</A></TD>
<TD valign="top">
20.9
&#160;
  </TD>
<TD valign="top">
The unique_ptr and shared_ptr constructors taking
nullptr_t delegate to a constexpr constructor, and could be
constexpr themselves.
&#160;
  </TD>
<TD valign="top">
In the 20.9.10.2 [unique.ptr.single] synopsis add
"constexpr" to unique_ptr(nullptr_t).<BR>
In the 20.9.10.3 [unique.ptr.runtime] synopsis add
"constexpr" to unique_ptr(nullptr_t).<BR>
In the 20.9.11.2 [util.smartptr.shared] synopsis
add "constexpr" to shared_ptr(nullptr_t).
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1402">1402</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP85">JP 85</A></TD>
<TD valign="top">
20.9.1
&#160;
  </TD>
<TD valign="top">
There are inconsistent definitions for allocator_arg.
In 20.9 [memory] paragraph 1,
<PRE>
constexpr allocator_arg_t allocator_arg =
allocator_arg_t();
</PRE>
and in 20.9.1,
<PRE>
const allocator_arg_t allocator_arg = allocator_arg_t();
</PRE>
&#160;
  </TD>
<TD valign="top">
Change "const" to "constexpr" in 20.9.1 as
follows.
<PRE>
constexpr allocator_arg_t allocator_arg =
allocator_arg_t();
</PRE>
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1403">1403</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US106">US 106</A></TD>
<TD valign="top">
20.9.3

    &#182;
    
all
&#160;
  </TD>
<TD valign="top">
pointer_traits should have a size_type member for
completeness.
&#160;
  </TD>
<TD valign="top">
Add &#8220;typedef see below size_type;&#8221; to the generic
pointer_traits template and &#8220;typedef size_t
size_type;&#8221; to pointer_traits&lt;T*&gt;. Use
pointer_traits::size_type and
pointer_traits::difference_type as the defaults for
allocator_traits::size_type and
allocator_traits::difference_type.<BR>
See Appendix 1 - Additional Details
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1404">1404</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB104">GB 104</A></TD>
<TD valign="top">
20.9.5.1

    &#182;
    
13
&#160;
  </TD>
<TD valign="top">
The ~ is missing from the invokation of the destructor of
U.
&#160;
  </TD>
<TD valign="top">
Add the missing ~ : Effects: p-&gt;~U()
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB105">GB 105</A></TD>
<TD valign="top">
20.9.6

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
There is a missing '_' in the piecewise-construct call for
pair in the class definition.
&#160;
  </TD>
<TD valign="top">
Fix the declaration:
<PRE>
template &lt;class T1, class T2, class... Args1,
class... Args2&gt; void construct(pair&lt;T1, T2&gt;* p,
piecewise_construct_t, tuple&lt;Args1...&gt; x,
tuple&lt;Args2...&gt; y);
</PRE>
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
The declaration is identical to the proposed text.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US107">US 107</A></TD>
<TD valign="top">
20.9.6
&#160;
  </TD>
<TD valign="top">
scoped_allocator_adaptor should have its own header.
&#160;
  </TD>
<TD valign="top">
See Appendix 1 - Additional Details
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1405">1405</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB101">GB 101</A></TD>
<TD valign="top">
20.9.10

    &#182;
    
5
&#160;
  </TD>
<TD valign="top">
The first sentence of the paragraph says "Each object of a
type U instantiated form the unique_ptr template..." "form"
should be "from"
&#160;
  </TD>
<TD valign="top">
Replace "form" with "from" in the opening
sentence:
"Each object of a type U instantiated from the
unique_ptr template..."
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="FI13">FI 13</A></TD>
<TD valign="top">
20.9.10.

    &#182;
    
5
&#160;
  </TD>
<TD valign="top">
typo
&#160;
  </TD>
<TD valign="top">
"form the unique_ptr" should be "from the
unique_ptr."
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB102">GB 102</A></TD>
<TD valign="top">
20.9.10
&#160;
  </TD>
<TD valign="top">
unique_ptr is a smart pointer so [unique.ptr] should be a
sub-clause of [util.smartptr]
&#160;
  </TD>
<TD valign="top">
move [unique.ptr] to a sub-clause of [util.smartptr]
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
[util.smartptr] deals with shared_ptr and weak_ptr,
which work together. Adding unique_ptr would create a muddle.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP35">JP 35</A></TD>
<TD valign="top">
20.9.10.2

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
Representations of reference link are not unified.
Most reference links to clause (table) number, say X, are
in the form "Clause X" ("Table X") capitalized, and
subsection Y.Y.Y is referenced with its number only in the
form "Y.Y.Y". Whether they are parenthesized or not
depends on the context.
However there are some notations "(Z)" consisting of only
a number Z in parentheses to confer Clause or Table
number Z.
&#160;
  </TD>
<TD valign="top">
Change "(38)" to "(Table 38)".
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP36">JP 36</A></TD>
<TD valign="top">
20.9.10.2.1

    &#182;
    
1, 6
&#160;
  </TD>
<TD valign="top">
Representations of reference link are not unified.
Most reference links to clause (table) number, say X, are
in the form "Clause X" ("Table X") capitalized, and
subsection Y.Y.Y is referenced with its number only in the
form "Y.Y.Y". Whether they are parenthesized or not
depends on the context.
However there are some notations "(Z)" consisting of only
a number Z in parentheses to confer Clause or Table
number Z.
&#160;
  </TD>
<TD valign="top">
Change "(33)" to "(Table 33)".
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP37">JP 37</A></TD>
<TD valign="top">
20.9.10.2.1

    &#182;
    
18
&#160;
  </TD>
<TD valign="top">
Representations of reference link are not unified.
Most reference links to clause (table) number, say X, are
in the form "Clause X" ("Table X") capitalized, and
subsection Y.Y.Y is referenced with its number only in the
form "Y.Y.Y". Whether they are parenthesized or not
depends on the context.
However there are some notations "(Z)" consisting of only
a number Z in parentheses to confer Clause or Table
number Z.
&#160;
  </TD>
<TD valign="top">
Change "(34)" to "(Table 34)".
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP38">JP 38</A></TD>
<TD valign="top">
20.9.10.2.3

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
Representations of reference link are not unified.
Most reference links to clause (table) number, say X, are
in the form "Clause X" ("Table X") capitalized, and
subsection Y.Y.Y is referenced with its number only in the
form "Y.Y.Y". Whether they are parenthesized or not
depends on the context.
However there are some notations "(Z)" consisting of only
a number Z in parentheses to confer Clause or Table
number Z.
&#160;
  </TD>
<TD valign="top">
Change "(36)" to "(Table 36)".
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP5">JP 5</A></TD>
<TD valign="top">
20.9.11.2

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
Hash support based on ownership sharing should be
supplied for shared_ptr and weak_ptr.
For two shared_ptr objects p and q, two distinct
equivalence relations can be defined. One is based on
equivalence of pointer values, which is derived from the
expression p.get() == q.get() (hereafter called addressbased
equivalence relation), the other is based on
equivalence of ownership sharing, which is derived from
the expression !p.owner_before(q) &amp;&amp; !q.owner_before(p)
(hereafter called ownership-based equivalence relation).
These two equivalence relations are independent in
general. For example, a shared_ptr object created by the
constructor of the signature shared_ptr(shared_ptr&lt;U&gt;
const &amp;, T *) could reveal a difference between these two
relations. Therefore, hash support based on each
equivalence relation should be supplied for shared_ptr.
However, while the standard library provides the hash
support for address-based one (20.9.11.6 paragraph 2), it
lacks the hash support for ownership-based one. In
addition, associative containers work well in combination
with the shared_ptr's ownership-based comparison but
unordered associative containers don't. This is
inconsistent.&gt;BR/&gt;
For the case of weak_ptr, hash support for the ownershipbased
equivalence relation can be safely defined on
weak_ptrs, and even on expired ones. The absence of
hash support for the ownership-based equivalence
relation is fatal, especially for expired weak_ptrs. And the
absence of such hash support precludes some quite
effective use-cases, e.g. erasing the unordered_map entry
of an expired weak_ptr key from a customized deleter
supplied to shared_ptrs.<BR>
Hash support for the ownership-based equivalence
relation cannot be provided by any user-defined manner
because information about ownership sharing is not
available to users at all. Therefore, the only way to provide
ownership-based hash support is to offer it intrusively by
the standard library.<BR>
As far as we know, such hash support is implementable.
Typical implementation of such hash function could return
the hash value of the pointer of the counter object that is
internally managed by shared_ptr and weak_ptr.
&#160;
  </TD>
<TD valign="top">
Add the following non-static member functions to
shared_ptr and weak_ptr class template;
<PRE>
// 20.9.11.2 paragraph 1
namespace std{
template&lt;class T&gt; class shared_ptr {
public:
...
size_t owner_hash() const;
...
};
}
// 20.9.11.3 paragraph 1
namespace std{
template&lt;class T&gt; class weak_ptr {
public:
...
size_t owner_hash() const;
...
};
}
</PRE>
These functions satisfy the following
requirements. Let p and q be objects of either
shared_ptr or weak_ptr, H be a hypothetical
function object type that satisfies the hash
requirements (20.2.4) and h be an object of the
type H. The expression p.owner_hash() behaves
as if it were equivalent to the expression h(p). In
addition, h(p) == h(q) must become true if p and q
share ownership.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1406">1406</A>&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>No consensus to make this change at this time. 
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="CH20">CH 20</A></TD>
<TD valign="top">
20.9.11.2

    &#182;
    
p4
&#160;
  </TD>
<TD valign="top">
Requiring shared_ptr and weak_ptr to always synchronize
the use count makes it potentially slow and is inconsistent
with the general approach to leave the synchronization to
the user of a facility.
&#160;
  </TD>
<TD valign="top">
Strike 'not' from 'Changes in use_count() do not
reflect modifications that can introduce data
races.' Possibly add additional synchronized
constructors and assignments.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>No consensus to make a change at this time. 
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US108">US 108</A></TD>
<TD valign="top">
20.9.11.2.1 [util.smartptr.shared.const]
&#160;
  </TD>
<TD valign="top">
shared_ptr should have the same policy for constructing
from auto_ptr as unique_ptr. Currently it does not.
&#160;
  </TD>
<TD valign="top">
Add &#8220;template &lt;class Y&gt; explicit
shared_ptr(auto_ptr&lt;Y&gt;&amp;); to
[util.smartptr.shared.const] (and to the synopsis).
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1407">1407</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3109.html">
     N3109</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US109">US 109</A></TD>
<TD valign="top">
20.9.11.2.6
&#160;
  </TD>
<TD valign="top">
20.9.11.2.6 [util.smartptr.shared.create]/2 says: "the
placement new expression ::new (pv) T() or ::new (pv)
T(std::forward&lt;Args&gt;(args)...)". It should simply say "the
placement new expression ::new (pv)
T(std::forward&lt;Args&gt;(args)...)", because empty parameter
packs expand to nothing. This would be consistent with
the requirements in paragraph 1.
&#160;
  </TD>
<TD valign="top">
Change<BR>
"the placement new expression ::new (pv) T() or
::new (pv) T(std::forward&lt;Args&gt;(args)...)"<BR>
to<BR>
"the placement new expression ::new (pv)
T(std::forward&lt;Args&gt;(args)...)"
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB103">GB 103</A></TD>
<TD valign="top">
20.9.12

    &#182;
    
12
&#160;
  </TD>
<TD valign="top">
The precondition to calling declare_no_pointers is that no
bytes in the range "have been previously registered" with
this call. As written, this precondition includes bytes in
ranges, even after they have been explicitly unregistered
with a later call to 'undeclare_no_pointers'.
&#160;
  </TD>
<TD valign="top">
Replace "have been previously registered" with
"are currently registered"
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1408">1408</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB106">GB 106</A></TD>
<TD valign="top">
20.10.3
&#160;
  </TD>
<TD valign="top">
duration is an arithmetic type, unlike time_point, and so
should provide a specialization of numeric_limits.
&#160;
  </TD>
<TD valign="top">
Add a declaration of a partial specialization of
numeric_limits for duration to the header synopsis
in 20.10.<BR>
Add 20.3.8 [time.duration.limits]
"duration is an arithmetic type, and so provides an
appropriate specialization of numeric_limits."
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>No consensus for a change. 
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US110">US 110</A></TD>
<TD valign="top">
20.10.5
&#160;
  </TD>
<TD valign="top">
Significant parts of the clock section are "unspecified",
rather than "implementation-defined".
&#160;
  </TD>
<TD valign="top">
Make those parts "implementation-defined".
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>No consensus to make a change. 
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US111">US 111</A></TD>
<TD valign="top">
20.10.5.2

    &#182;
    
para 1
&#160;
  </TD>
<TD valign="top">
What it means for monotonic_clock to be a synonym is
undefined. If it may or may not be a typedef, then certain
classes of programs become unportable.
&#160;
  </TD>
<TD valign="top">
Require that it be a distinct class type.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1409">1409</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3191.html">
     N3191</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB107">GB 107</A></TD>
<TD valign="top">
20.10.5.2

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
1.4p9 states that which conditionally supported constructs
are available should be provided in the documentation for
the implementation. This doesn't help programmers trying
to write portable code, as they must then rely on
implementation-specific means to determine the
availability of such constructs. In particular, the presence
or absence of std::chrono::monotonic_clock may require
different code paths to be selected. This is the only
conditionally-supported library facility, and differs from the
conditionally-supported language facilities in that it has
standard-defined semantics rather than implementationdefined
semantics.
&#160;
  </TD>
<TD valign="top">
Provide feature test macro for determining the
presence of std::chrono::monotonic_clock. Add
_STDCPP_HAS_MONOTONIC_CLOCK to the
&lt;chrono&gt; header, which is defined if
monotonic_clock is present, and not defined if it is
not present.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1410">1410</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3191.html">
     N3191</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="DE20">DE 20</A></TD>
<TD valign="top">
20.10.5.2
&#160;
  </TD>
<TD valign="top">
The library component monotonic_clock is conditionally
supported, but no compile-time flag exists that allows
user-code to query its existence. Further-on there exist no
portable means to simulate such a query. (To do so, user
code would be required to add types to namespace
std::chrono.)
&#160;
  </TD>
<TD valign="top">
Provide a compile-time flag (preferably a macro)
that can be used to query the existence of
monotonic_clock.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1411">1411</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3191.html">
     N3191</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="CH21">CH 21</A></TD>
<TD valign="top">
20.10.5.2

    &#182;
    
p2
&#160;
  </TD>
<TD valign="top">
Monotonic clocks are generally easy to provide on all
systems and are implicitely required by some of the library
facilities anyway.
&#160;
  </TD>
<TD valign="top">
Make monotonic clocks mandatory, i.e. remove
p2. Also change 30.2.4p2 accordingly.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1412">1412</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3191.html">
     N3191</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US112">US 112</A></TD>
<TD valign="top">
20.10.5.3

    &#182;
    
para 1
&#160;
  </TD>
<TD valign="top">
What it means for high_resolution_clock to be a synonym
is undefined. If it may or may not be a typedef, then
certain classes of programs become unportable.
&#160;
  </TD>
<TD valign="top">
Require that it be a distinct class type.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1413">1413</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP39">JP 39</A></TD>
<TD valign="top">
21.2.2

    &#182;
    
4
&#160;
  </TD>
<TD valign="top">
Representations of reference link are not unified.
Most reference links to clause (table) number, say X, are
in the form "Clause X" ("Table X") capitalized, and
subsection Y.Y.Y is referenced with its number only in the
form "Y.Y.Y". Whether they are parenthesized or not
depends on the context.
However there are some notations "(Z)" consisting of only
a number Z in parentheses to confer Clause or Table
number Z.
&#160;
  </TD>
<TD valign="top">
Change "(35)" to "(Table 35)".
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB108">GB 108</A></TD>
<TD valign="top">
21.2.3.1

    &#182;
    
2,3
&#160;
  </TD>
<TD valign="top">
The definition of streamoff/streampos defers to the
definition of off_type and pos_type in 21.2.2, which defers
back to 27.2.2 for the definition of streamoff/streampos.
The actual definition appears to be supplied in 27.3, the
synopsis of &lt;iosfwd&gt;.
&#160;
  </TD>
<TD valign="top">
Update the reference in 21.2.3.1 to refer forward
to 27.2.2, rather than back to 21.2.2.
Add a cross-reference to from 27.2.2 to 27.3.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB109">GB 109</A></TD>
<TD valign="top">
21.2.3.2/3/4
&#160;
  </TD>
<TD valign="top">
It is not clear what the specification means for
u16streampos, u32streampos or wstreampos when they
refer to the requirements for POS_T in 21.2.2, as there
are no longer any such requirements. Similarly the annex
D.7 refers to the requirements of type POS_T in 27.3 that
no longer exist either.
&#160;
  </TD>
<TD valign="top">
Clarify the meaning of all cross-reference to the
removed type POS_T.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1414">1414</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP40">JP 40</A></TD>
<TD valign="top">
21.4

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
Representations of reference link are not unified.
Most reference links to clause (table) number, say X, are
in the form "Clause X" ("Table X") capitalized, and
subsection Y.Y.Y is referenced with its number only in the
form "Y.Y.Y". Whether they are parenthesized or not
depends on the context.
However there are some notations "(Z)" consisting of only
a number Z in parentheses to confer Clause or Table
number Z.
&#160;
  </TD>
<TD valign="top">
Change "(96)" to "(Table 96)".
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB110">GB 110</A></TD>
<TD valign="top">
21.4.7.1
&#160;
  </TD>
<TD valign="top">
data() is the function of choice for calling into legacy 'C'-like
APIs. Both vector and array designed this function to
be callable in a const-correct way while allowing for
functions that want to use the result to designate a return
buffer.
&#160;
  </TD>
<TD valign="top">
Add the following overload to basic_string data():
<PRE>
charT * data();
</PRE>
Relax the requirement that programs do not alter
values in the array through the pointe retrieved
through this new overload.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>No consensus to make this change. 
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB111">GB 111</A></TD>
<TD valign="top">
21.5
&#160;
  </TD>
<TD valign="top">
Section 17.6.4.8, Data Race Avoidance, requires the C++
Standard Library to avoid data races that might otherwise
result from two threads making calls to C++ Standard
Library functions on distinct objects. The C standard
library is part of the C++ Standard Library and some C++
Standary library functions (parts of the Localization library,
as well as Numeric Conversions in 21.5), are specified to
make use of the C standard library. Therefore, the C++
standard indirectly imposes a requirement on the thread
safety of the C standard library. However, since the C
standard does not address the concept of thread safety
conforming C implementations exist that do no provide
such guarantees. This conflict needs to be reconciled.
&#160;
  </TD>
<TD valign="top">
remove the requirement to make use of strtol()
and sprintf() since these functions depend on the
global C locale and thus cannot be made thread
safe.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP86">JP 86</A></TD>
<TD valign="top">
21.7

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
Table numbers are listed incorrectly. "74,75. and" should
be "74, 75, and".
&#160;
  </TD>
<TD valign="top">
Correct typo as follows.<BR>
Tables 71, 72, 73, 74, 75, and 76 describe
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP87">JP 87</A></TD>
<TD valign="top">
22.3.1
&#160;
  </TD>
<TD valign="top">
While usage of "traits" and "Traits" are explained in 21.2
as template parameters and arguments respectively,
specifying "Traits" as template parameter seems misuse.
template &lt;class charT, class Traits, class Allocator&gt;
bool operator()(const
basic_string&lt;charT,Traits,Allocator&gt;&amp; s1,
const basic_string&lt;charT,Traits,Allocator&gt;&amp; s2) const;
&#160;
  </TD>
<TD valign="top">
Change "Traits" to "traits" in three places.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP88">JP 88</A></TD>
<TD valign="top">
22.6

    &#182;
    
3, Table 91
&#160;
  </TD>
<TD valign="top">
Typo, duplicated "ispunct" and missing "iswpunct".
&#160;
  </TD>
<TD valign="top">
Correct as follows.<BR>
isprint<BR>
ispunct<BR>
isspace<BR>
:<BR>
iswprint<BR>
iswpunct<BR>
iswspace
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP89">JP 89</A></TD>
<TD valign="top">
23.1

    &#182;
    
2, Table 92
&#160;
  </TD>
<TD valign="top">
Typo, "&lt;forwardlist&gt;" should be "&lt;forward_list&gt;".
&#160;
  </TD>
<TD valign="top">
Correct typo.
&lt;forward_list&gt;
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US113">US 113</A></TD>
<TD valign="top">
23.2

    &#182;
    
5
&#160;
  </TD>
<TD valign="top">
Resolve LWG 579 one way or the other, but preferably in
the direction of changing the two erase overloads to return
void.
&#160;
  </TD>
<TD valign="top">
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>No consensus for a change. 
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US114">US 114</A></TD>
<TD valign="top">
23.2.1

    &#182;
    
Paragraph 9
&#160;
  </TD>
<TD valign="top">
Requirements on iterators swapping allegiance would
disallow the small-string optimization.
&#160;
  </TD>
<TD valign="top">
Add an exclusion for basic_string to the sentence
beginning &#8220;Every iterator referring to an
element...&#8221;. Add a sentence to 21.4.6.8/2 saying
that iterators and references to string elements
remain valid, but it is not specified whether they
refer to the same string or the other string.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3108.pdf">
     N3108</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="DE21">DE 21</A></TD>
<TD valign="top">
23.2.1, 23.3.3.4
&#160;
  </TD>
<TD valign="top">
23.2.1/11 provides a general no-throw guarantee for
erase() container functions, exceptions from this are
explicitly mentioned for individual containers. Because of
its different name, forward_list's erase_after() function is
not ruled by this but should so.
&#160;
  </TD>
<TD valign="top">
Add a "Throws: Nothing" clause to both
erase_after overloads in 23.3.3.4.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1416">1416</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US115">US 115</A></TD>
<TD valign="top">
23.2.1

    &#182;
    
Paragraph 15
&#160;
  </TD>
<TD valign="top">
The terms CopyConstructible, MoveConstructible, and
constructible from are redefined, then used inconsistently
and often incorrectly within the section. New terms should
have been introduced and used correctly.
&#160;
  </TD>
<TD valign="top">
Better terms would be X can copy-insert T, X can
move-insert T, and X can construct-insert T with
args. See Appendix 1 - Additional Details
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3173.pdf">
     N3173</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US116">US 116</A></TD>
<TD valign="top">
23.2.1

    &#182;
    
Table 96
&#160;
  </TD>
<TD valign="top">
The requirement for X(rv) that move construction of the
allocator not throw can be misread as requiring that move
construction of the whole container not throw.
&#160;
  </TD>
<TD valign="top">
Add non-normative note:<BR>
Requires: move construction of A shall not exit via
an exception. <ins>[Note: This requirement on
allocators exists so that implementations can
(optionally) provide a nothrow guarantee on move
construction of some containers.  end note]</ins>
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
The text as is seems quite clear; the proposed note just muddles things.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="FI12">FI 12</A></TD>
<TD valign="top">
23.2.3 [sequence.reqmts]

    &#182;
    
Table 97 Sequence container requirements (in addition to container)
&#160;
  </TD>
<TD valign="top">
The requirement for insert says: &#8220;Requires:T shall be
CopyConstructible. For vector and deque, T shall also be
CopyAssignable.&#8221;. Why must T be CopyAssignable? Is it
for cases where the object may be already constructed
and insert will first copy the existing data out of the way
and assign to an existing object? Can't such an
implementation do the same with placement-new?
&#160;
  </TD>
<TD valign="top">
CopyAssignable seems like an overly strict
requirement for insert, exposing implementation
details in the specification. If such implementation
details are achievable without assignment, eg.
with placement-new, the CopyAssignable
requirement should be removed.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>No consensus to make the change.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP90">JP 90</A></TD>
<TD valign="top">
23.2.3

    &#182;
    
17, Table 98
&#160;
  </TD>
<TD valign="top">
In Operational semantics for "a.emplace_front(args)",
&lt;Arg&gt; should be &lt;Args&gt;.
Prepends an object of type T
constructed with
std::forward&lt;Arg&gt;(args)...."
&#160;
  </TD>
<TD valign="top">
Change &lt;Arg&gt; to &lt;Args&gt;.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP91">JP 91</A></TD>
<TD valign="top">
23.2.5

    &#182;
    
10, Table 100
&#160;
  </TD>
<TD valign="top">
Typo, unnecessary new-line.
a_uniq.<BR>
emplace(args)<BR>
Typo, unnecessary space.
a_eq. emplace(args)
&#160;
  </TD>
<TD valign="top">
Remove space characters between "." and
"emplace" same as other word wrapped columns
in the table.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
The newline is needed, but the space is unnecessary.  Removed the
space.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP92">JP 92</A></TD>
<TD valign="top">
23.2.5

    &#182;
    
11
&#160;
  </TD>
<TD valign="top">
Typo, "unodified" should be "unmodified".
&#160;
  </TD>
<TD valign="top">
Correct typo.
unmodified
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="ES2">ES 2</A></TD>
<TD valign="top">
23.2.5 [unord.req], Table 100 (Unordered associative container requirements (in addition to container))

    &#182;
    
Row for expression a.erase(q)
&#160;
  </TD>
<TD valign="top">
The expression is required to return the iterator
immediately following <TT>q</TT> prior to the erasure. As explained
in N2023, this requirement makes it impossible to achieve
average O(1) complexity for unordered associative
containers implemented with singly linked lists. This has a
theoretical as well as a practical impact, as reported by
users of early implementations of these containers.
Discussions among committee members have not found
any way of remedying this deficiency (other than
acknowledging it) by some smart modification of usual
singly linked lists implementations.
&#160;
  </TD>
<TD valign="top">
Change the return type of the expression from
<TT>iterator</TT> to <TT>void</TT>. Eliminate the sentence
&#8220;Return value is the iterator immediately following
<TT>q</TT> prior to the erasure&#8221;. Change accordingly the
appearances of &#8220;<TT>iterator
erase(const_iterator position)</TT>&#8221; in
23.5.1, 23.5.2, 23.5.3 and 23.5.4.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB112">GB 112</A></TD>
<TD valign="top">
23.3.1.7

    &#182;
    
p3
&#160;
  </TD>
<TD valign="top">
Should the effect of calling front/back on a zero sized
array really be implementation defined i.e. require the
implementor to define behaviour?
&#160;
  </TD>
<TD valign="top">
Change "implementation defined" to "undefined"
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1417">1417</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB113">GB 113</A></TD>
<TD valign="top">
23.3.2.2

    &#182;
    
p1
&#160;
  </TD>
<TD valign="top">
There is no mention of what happens if sz==size(). While
it obviously does nothing I feel a standard needs to say
this explicitely.
&#160;
  </TD>
<TD valign="top">
Append "If sz == size(), does nothing" to the
effects.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1418">1418</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US117">US 117</A></TD>
<TD valign="top">
23.3.3
&#160;
  </TD>
<TD valign="top">
forward_list::erase_after should return an iterator.
&#160;
  </TD>
<TD valign="top">
See Appendix 1 - Additional Details
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1419">1419</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP41">JP 41</A></TD>
<TD valign="top">
23.3.3

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
Representations of reference link are not unified.
Most reference links to clause (table) number, say X, are
in the form "Clause X" ("Table X") capitalized, and
subsection Y.Y.Y is referenced with its number only in the
form "Y.Y.Y". Whether they are parenthesized or not
depends on the context.
However there are some notations "(Z)" consisting of only
a number Z in parentheses to confer Clause or Table
number Z.
&#160;
  </TD>
<TD valign="top">
Change "(table 93)" to "(Table 93)".
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB114">GB 114</A></TD>
<TD valign="top">
23.3.4.1

    &#182;
    
p11 &amp; p12
&#160;
  </TD>
<TD valign="top">
It looks like the erase/insert effects given in p11 are
intended for p12.
&#160;
  </TD>
<TD valign="top">
Move the erase/insert effects down to p12
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
The code in question is a remmant from a previous version.  It has
now been removed.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB115">GB 115</A></TD>
<TD valign="top">
23.3.4.2

    &#182;
    
p1
&#160;
  </TD>
<TD valign="top">
There is no mention of what happens if sz==size(). While
it obviously does nothing I feel a standard needs to say
this explicitly.
&#160;
  </TD>
<TD valign="top">
Express the semantics as pseudo-code similarly
to the way it is done for the copying overload that
follows (in p3). Include an else clause that does
nothing and covers the sz==size() case.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1420">1420</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB116">GB 116</A></TD>
<TD valign="top">
23.3.5
&#160;
  </TD>
<TD valign="top">
The sequence container adaptors consume sequence
containers, but are neither containers nor sequences
themselves. While they clearly belong in clause 23, they
should not interrupt the presentation of the sequence
container themselves.
&#160;
  </TD>
<TD valign="top">
Move clause 23.3.5 out of clause 23.3.
Recommending inserting as a 'new' 23.4
immediately following sequence containers, and
before the current 23.4 (associative containers)
which would be renumbered 23.5.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="DE22">DE 22</A></TD>
<TD valign="top">
23.3.5.1, 23.3.5.2, 23.3.5.3
&#160;
  </TD>
<TD valign="top">
With the final acceptance of move operations as special
members and introduction of corresponding suppression
rules of implicitly generated copy operations the some
library types that were copyable in C++03 are no longer
copyable (only movable) in C++03, among them queue,
priority_queue, and stack.
&#160;
  </TD>
<TD valign="top">
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1421">1421</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP93">JP 93</A></TD>
<TD valign="top">
23.3.5.2

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
Typo, missing ";".
<PRE>
template &lt;class... Args&gt; void emplace(Args&amp;&amp;... args)
</PRE>n
&#160;
  </TD>
<TD valign="top">
Correct typo.
<PRE>
template &lt;class... Args&gt; void emplace(Args&amp;&amp;...
args);
</PRE>
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB117">GB 117</A></TD>
<TD valign="top">
23.3.6.2

    &#182;
    
p9
&#160;
  </TD>
<TD valign="top">
(Same as for 23.3.2.2p1 i.e. deque::resize).
There is no mention of what happens if sz==size(). While
it obviously does nothing I feel a standard needs to say
this explicitely.
&#160;
  </TD>
<TD valign="top">
Append "If sz == size(), does nothing" to the
effects.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB118">GB 118</A></TD>
<TD valign="top">
23.3.7
&#160;
  </TD>
<TD valign="top">
vector&lt;bool&gt; iterators are not random access iterators
because their reference type is a special class, and not
'bool &amp;'. All standard libary operations taking iterators
should treat this iterator as if it was a random access
iterator, rather than a simple input iterator.
&#160;
  </TD>
<TD valign="top">
Either revise the iterator requirements to support
proxy iterators (restoring functionality that was lost
when the Concept facility was removed) or add an
extra paragraph to the vector&lt;bool&gt; specification
requiring the library to treat vector&lt;bool&gt; iterators
as-if they were random access iterators, despite
having the wrong reference type.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1422">1422</A>&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>The LWG does not wish to address this problem at this time. The preference is to deal with it with the more general proxy iterator problem. 
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP6">JP 6</A></TD>
<TD valign="top">
23.4.1

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
Constructor accepting an allocator as a single parameter
should be qualified as explicit.
<PRE>
namespace std {
template &lt;class Key, class T, class Compare =
less&lt;Key&gt;,
class Allocator = allocator&lt;pair&lt;const Key, T&gt; &gt; &gt;
class map {
public:
...
map(const Allocator&amp;);
</PRE>
&#160;
  </TD>
<TD valign="top">
Add explicit.
<PRE>
namespace std {
template &lt;class Key, class T, class Compare =
less&lt;Key&gt;,
class Allocator = allocator&lt;pair&lt;const Key, T&gt; &gt; &gt;
class map {
public:
...
explicit map(const Allocator&amp;);
</PRE>
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1423">1423</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP7">JP 7</A></TD>
<TD valign="top">
23.4.2

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
Constructor accepting an allocator as a single parameter
should be qualified as explicit.
&#160;
  </TD>
<TD valign="top">
Add explicit.
<PRE>
namespace std {
template &lt;class Key, class T, class Compare =
less&lt;Key&gt;,
class Allocator = allocator&lt;pair&lt;const Key, T&gt; &gt; &gt;
class multimap {
public:
...
explicit multimap(const Allocator&amp;);
</PRE>
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP8">JP 8</A></TD>
<TD valign="top">
23.4.3

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
Constructor accepting an allocator as a single parameter
should be qualified as explicit.
&#160;
  </TD>
<TD valign="top">
Add explicit.
<PRE>
namespace std {
template &lt;class Key, class Compare = less&lt;Key&gt;,
class Allocator = allocator&lt;Key&gt; &gt;
class set {
public:
...
explicit set(const Allocator&amp;);
</PRE>
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1425">1425</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP9">JP 9</A></TD>
<TD valign="top">
23.4.4

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
Constructor accepting an allocator as a single parameter
should be qualified as explicit.
&#160;
  </TD>
<TD valign="top">
Add explicit.
<PRE>
namespace std {
template &lt;class Key, class Compare = less&lt;Key&gt;,
class Allocator = allocator&lt;Key&gt; &gt;
class multiset {
public:
...
explicit multiset(const Allocator&amp;);
</PRE>
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1426">1426</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US118">US 118</A></TD>
<TD valign="top">
23.5
&#160;
  </TD>
<TD valign="top">
Some unordered associative container operations have
undesirable complexities when the container is
implemented using singly linked lists.
&#160;
  </TD>
<TD valign="top">
See Appendix 1 - Additional Details
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>No consensus for a change. 
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP10">JP 10</A></TD>
<TD valign="top">
23.5.1

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
Constructor accepting an allocator as a single parameter
should be qualified as explicit.
&#160;
  </TD>
<TD valign="top">
Add explicit.
<PRE>
namespace std {
template &lt;class Key,
template &lt;class Key,
class T,
class Hash = hash&lt;Key&gt;,
class Pred = std::equal_to&lt;Key&gt;,
class Alloc = std::allocator&lt;std::pair&lt;const Key,
T&gt; &gt; &gt;
class unordered_map
{
public:
...
explicit unordered_map(const Allocator&amp;);
</PRE>
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1427">1427</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP11">JP 11</A></TD>
<TD valign="top">
23.5.2

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
Constructor accepting an allocator as a single parameter
should be qualified as explicit.
&#160;
  </TD>
<TD valign="top">
Add explicit.
<PRE>
namespace std {
template &lt;class Key,
class T,
class Hash = hash&lt;Key&gt;,
class Pred = std::equal_to&lt;Key&gt;,
class Alloc = std::allocator&lt;std::pair&lt;const Key,
T&gt; &gt; &gt;
class unordered_multimap
{
public:
...
explicit unordered_multimap(const Allocator&amp;);
</PRE>
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1428">1428</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP94">JP 94</A></TD>
<TD valign="top">
23.5.2

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
"see below" should be in italic and need one space
between words.<BR>
explicit unordered_multimap(size_type n = seebelow,
&#160;
  </TD>
<TD valign="top">
Change to:<BR>
explicit unordered_multimap(size_type n = see
below,
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP12">JP 12</A></TD>
<TD valign="top">
23.5.3

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
Constructor accepting an allocator as a single parameter
should be qualified as explicit.
&#160;
  </TD>
<TD valign="top">
Add explicit.
<PRE>
namespace std {
template &lt;class Key,
class Hash = hash&lt;Key&gt;,
class Pred = std::equal_to&lt;Key&gt;,
class Alloc = std::allocator&lt;Key&gt; &gt;
class unordered_set
{
public:
...
explicit unordered_set(const Allocator&amp;);
</PRE>
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1429">1429</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP13">JP 13</A></TD>
<TD valign="top">
23.5.4

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
Constructor accepting an allocator as a single parameter
should be qualified as explicit.
&#160;
  </TD>
<TD valign="top">
Add explicit.
<PRE>
namespace std {
template &lt;class Key,
class Hash = hash&lt;Key&gt;,
class Pred = std::equal_to&lt;Key&gt;,
class Alloc = std::allocator&lt;Key&gt; &gt;
class unordered_multiset
{
public:
...
explicit unordered_multiset(const Allocator&amp;);
</PRE>
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1430">1430</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US119">US 119</A></TD>
<TD valign="top">
[input.iterators] 24.2.3

    &#182;
    
Table 104
&#160;
  </TD>
<TD valign="top">
Although the section talks about operator==, there is no
requirement that it exist.
&#160;
  </TD>
<TD valign="top">
Add a == b to Table 104
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>Standard is correct as is. 
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP42">JP 42</A></TD>
<TD valign="top">
25.1

    &#182;
    
8, 9
&#160;
  </TD>
<TD valign="top">
Representations of reference link are not unified.
Most reference links to clause (table) number, say X, are
in the form "Clause X" ("Table X") capitalized, and
subsection Y.Y.Y is referenced with its number only in the
form "Y.Y.Y". Whether they are parenthesized or not
depends on the context.
However there are some notations "(Z)" consisting of only
a number Z in parentheses to confer Clause or Table
number Z.
&#160;
  </TD>
<TD valign="top">
Change "(4)" to "(Clause 4)".
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US120">US 120</A></TD>
<TD valign="top">
25.2.12

    &#182;
    
para 1
&#160;
  </TD>
<TD valign="top">
is_permutation is underspecified for anything but the
simple case where both ranges have the same value type
and the comparison function is an equivalence relation.
&#160;
  </TD>
<TD valign="top">
Restrict is_permutation to the case where it is well
specified. See Appendix 1 - Additional Details
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1431">1431</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="ES3">ES 3</A></TD>
<TD valign="top">
25.2.12
&#160;
  </TD>
<TD valign="top">
is_permutation does not require ForwardIterator1 and
ForwardIterator2 to have the same value type. This opens
the door to nonsense heterogeneous usage where both
ranges have different value types
&#160;
  </TD>
<TD valign="top">
Require both iterator types to have the same
value type
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP43">JP 43</A></TD>
<TD valign="top">
25.3.9

    &#182;
    
5
&#160;
  </TD>
<TD valign="top">
Representations of reference link are not unified.
Most reference links to clause (table) number, say X, are
in the form "Clause X" ("Table X") capitalized, and
subsection Y.Y.Y is referenced with its number only in the
form "Y.Y.Y". Whether they are parenthesized or not
depends on the context.
However there are some notations "(Z)" consisting of only
a number Z in parentheses to confer Clause or Table
number Z.
&#160;
  </TD>
<TD valign="top">
Change "(4)" to "(Clause 4)".
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US121">US 121</A></TD>
<TD valign="top">
25.3.12 [alg.random.shuffle]

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
random_shuffle and shuffle should be consistent in how
they accept their source of randomness: either both by
rvalue reference or both by lvalue reference.
&#160;
  </TD>
<TD valign="top">
Change random_shuffle to accept its
RandomNumberGenerator by lvalue reference.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1432">1432</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB119">GB 119</A></TD>
<TD valign="top">
25.3.12
&#160;
  </TD>
<TD valign="top">
The functions random_shuffle and shuffle both take
arguments providing a source of randomness, but one
take its argument by rvalue reference, and the other
requires an lvalue reference. The technical merits of which
form of argument passing should be settled for this
specific case, and a single preferred form used
consistently.
&#160;
  </TD>
<TD valign="top">
[DEPENDS ON WHETHER RVALUE OR
LVALUE REFERENCE IS THE PREFERRED
FORM]
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1433">1433</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP44">JP 44</A></TD>
<TD valign="top">
25.4

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
Representations of reference link are not unified.
Most reference links to clause (table) number, say X, are
in the form "Clause X" ("Table X") capitalized, and
subsection Y.Y.Y is referenced with its number only in the
form "Y.Y.Y". Whether they are parenthesized or not
depends on the context.
However there are some notations "(Z)" consisting of only
a number Z in parentheses to confer Clause or Table
number Z.
&#160;
  </TD>
<TD valign="top">
Change "(4)" to "(Clause 4)".
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP45">JP 45</A></TD>
<TD valign="top">
25.4.7

    &#182;
    
1, 10, 19
&#160;
  </TD>
<TD valign="top">
Representations of reference link are not unified.
Most reference links to clause (table) number, say X, are
in the form "Clause X" ("Table X") capitalized, and
subsection Y.Y.Y is referenced with its number only in the
form "Y.Y.Y". Whether they are parenthesized or not
depends on the context.
However there are some notations "(Z)" consisting of only
a number Z in parentheses to confer Clause or Table
number Z.
&#160;
  </TD>
<TD valign="top">
Change "(32)" to "(Table 32)".
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US122">US 122</A></TD>
<TD valign="top">
25.4.7 [alg.min.max]
&#160;
  </TD>
<TD valign="top">
It was the LWG's intent in Pittsburgh that N2772 be
applied to the WP
&#160;
  </TD>
<TD valign="top">
Apply N2772 to the WP.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1434">1434</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3106.pdf">
     N3106</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US123">US 123</A></TD>
<TD valign="top">
25.5

    &#182;
    
p5b, and all uses of lshift
&#160;
  </TD>
<TD valign="top">
N3056, as adopted, calls for each use of lshift to be
followed by a subscripted value.
&#160;
  </TD>
<TD valign="top">
Adjust all occurrences of the lshift notation so as
to match the notation of N3056.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="FI14">FI 14</A></TD>
<TD valign="top">
26.3.1.

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
typo
&#160;
  </TD>
<TD valign="top">
"floating-point environmnet" should be "floating-point
environment."
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB120">GB 120</A></TD>
<TD valign="top">
26.4.7
&#160;
  </TD>
<TD valign="top">
The complex number functions added for compatibility
with the C99 standard library are defined purely as a
cross-reference, with no hint of what they should return.
This is distinct from the style of documentation for the
functions in the earlier standard. In the case of the
inverse-trigonometric and hyperbolic functions, a
reasonable guess of the functionality may be made from
the name, this is not true of the cproj function, which
apparently returns the projection on the Reimann Sphere.
A single line description of each function, associated with
the cross-reference, will greatly improve clarity.
&#160;
  </TD>
<TD valign="top">
[ONE LINE DESCRIPTIONS, AND ASSOCIATED
PARAGRAPH NUMBERS, TO FOLLOW IF THE
INTENT IS APPROVED]
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1435">1435</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP46">JP 46</A></TD>
<TD valign="top">
26.5.1.6

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
Representations of reference link are not unified.
Most reference links to clause (table) number, say X, are
in the form "Clause X" ("Table X") capitalized, and
subsection Y.Y.Y is referenced with its number only in the
form "Y.Y.Y". Whether they are parenthesized or not
depends on the context.
However there are some notations "(Z)" consisting of only
a number Z in parentheses to confer Clause or Table
number Z.
&#160;
  </TD>
<TD valign="top">
Change "Clause 21 and 27" to "Clauses 21 and
27".
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB121">GB 121</A></TD>
<TD valign="top">
26.5.3
&#160;
  </TD>
<TD valign="top">
All the random number engine types in this clause have a
constructor taking an unsigned integer type, and a
constructor template for seed sequences. This means that
an attempt to create a random number engine seeded by
an integer literal must remember to add the appropriate
unsigned suffix to the literal, as a signed integer will
attempt to use the seed sequence template, yielding
undefined behaviour, as per 26.5.1.1p1a. It would be
helpful if at least these anticipated cases produced a
defined behaviour, either an erroneous program with
diagnostic, or a conversion to unsigned int forwarding to
the appropriate constructor.
&#160;
  </TD>
<TD valign="top">
[WORDING TO FOLLOW ONCE A PREFERRED
DIRECTION IS INDICATED]
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1436">1436</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US124">US 124</A></TD>
<TD valign="top">
26.5.3.2

    &#182;
    
p4
&#160;
  </TD>
<TD valign="top">
The Mersenne twister algorithm is meaningless for word
sizes less than two, as there are then insufficient bits
available to be &#8220;twisted&#8221;.
&#160;
  </TD>
<TD valign="top">
Insert the following among the relations that are
required to hold: 2u &lt; w.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1437">1437</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US125">US 125</A></TD>
<TD valign="top">
26.5.4.1 [rand.adapt.disc]

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
The synopsis for min() and max() is lacking &#8220;()&#8221; in the
return statements.
&#160;
  </TD>
<TD valign="top">
return Engine::min();<BR>
return Engine::max();
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US126">US 126</A></TD>
<TD valign="top">
26.5.4.1 [rand.adapt.disc], 26.5.4.2 [rand.adapt.ibits], 26.5.4.3 [rand.adapt.shuf]

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
Each adaptor has a member function called base() which
has no definition.
&#160;
  </TD>
<TD valign="top">
Give it the obvious definition.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1438">1438</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US127">US 127</A></TD>
<TD valign="top">
26.5.4.1

    &#182;
    
synopsis after p3
&#160;
  </TD>
<TD valign="top">
Engine::min is a function and ought be invoked in the
context where mentioned, as should Engine::max.
&#160;
  </TD>
<TD valign="top">
Append parentheses so as to become return
Engine::min() and return Engine::max().
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US128">US 128</A></TD>
<TD valign="top">
26.5.4.3

    &#182;
    
synopsis after p3
&#160;
  </TD>
<TD valign="top">
Engine::min is a function and ought be invoked in the
context where mentioned, as should Engine::max.
&#160;
  </TD>
<TD valign="top">
Append parentheses so as to become return
Engine::min() and return Engine::max().
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US129">US 129</A></TD>
<TD valign="top">
26.5.7.1

    &#182;
    
p8b
&#160;
  </TD>
<TD valign="top">
The expression begin[x+q] is incorrect since x is
unspecified .
&#160;
  </TD>
<TD valign="top">
Replace x by k so as to obtain begin[k+q].
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US130">US 130</A></TD>
<TD valign="top">
26.5.7.1

    &#182;
    
p8c
&#160;
  </TD>
<TD valign="top">
The phrase &#8220;three more times&#8221; is misleading.
&#160;
  </TD>
<TD valign="top">
s/three more times,/again,/
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US131">US 131</A></TD>
<TD valign="top">
26.5.7.1

    &#182;
    
p8c
&#160;
  </TD>
<TD valign="top">
Values <I>r</I><SUB>3</SUB> and <I>r</I><SUB>4</SUB>
are correctly specified, but in their
subsequent use they are interchanged with respect to the
original algorithm by Mutso Saito.
&#160;
  </TD>
<TD valign="top">
Exchange subscripts so as to read as follows: &#8220;...
update begin[k + p] by xoring it with <I>r</I><SUB>3</SUB>, update
begin[k + q] by xoring it with <I>r</I><SUB>4</SUB>, and ...&#8221;
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US132">US 132</A></TD>
<TD valign="top">
26.5.7.1 [rand.util.seedseq]

    &#182;
    
8b
&#160;
  </TD>
<TD valign="top">
The last sentence includes &#8220;begin[x + q]&#8221; but &#8220;x&#8221;
is nonsensical here.
&#160;
  </TD>
<TD valign="top">
Change &#8220;begin[x + q]&#8221; to &#8220;begin[k + q]&#8221;
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US133">US 133</A></TD>
<TD valign="top">
26.5.7.1 [rand.util.seedseq]

    &#182;
    
8c
&#160;
  </TD>
<TD valign="top">
The use of r3 and r4 is reversed in the final sentence of 8c
according to the defect report on comp.std.c++ that this
specification is based on:
http://groups.google.com/group/comp.std.c++/browse_thre
ad/thread/e34cbee1932efdb8/aad523dccec12aed?q=grou
p:comp.std.c%2B%2B+insubject:seed_seq
If you follow the SFMT link to the software, the software
also uses r3 and r4 in a manner inconsistent with N3092.
I believe N3092 should be changed to be consistent with
the defect report.
&#160;
  </TD>
<TD valign="top">
Change 8c to end:<BR>
... update begin[k + p] by xoring it with r3, update
begin[k + q] by xoring it with
r4, and ...
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US134">US 134</A></TD>
<TD valign="top">
26.5.8.5.2 [rand.dist.samp.pconst], 26.5.8.5.3 [rand.dist.samp.plinear]
&#160;
  </TD>
<TD valign="top">
These two distributions have a member function called
densities() which returns a vector&lt;double&gt;. The
distribution is templated on RealType. The distribution
also has another member called intervals() which returns
a vector&lt;RealType&gt;. Why doesn't densities return
vector&lt;RealType&gt; as well? If RealType is long double,
the computed densities property isn't being computed to
the precision the client desires. If RealType is float, the
densities vector is taking up twice as much space as the
client desires.
&#160;
  </TD>
<TD valign="top">
Change the piecewise constant and linear
distributions to hold / return the densities in a
vector&lt;result_type&gt;.<BR>
If this is not done, at least
correct[rand.dist.samp.pconst]/13 which describes
the return of densities as a vector&lt;result_type&gt;.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1439">1439</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US135">US 135</A></TD>
<TD valign="top">
26.5.8.5.3

    &#182;
    
10
&#160;
  </TD>
<TD valign="top">
This paragraph says: Let bk = xmin+k&#183;&#948; for k = 0,...,n,
and wk = fw(bk +&#948;) for k = 0,...,n.
However I believe that fw(bk) would be far more desirable.
I strongly suspect that this is nothing but a type-o.
&#160;
  </TD>
<TD valign="top">
Change p10 to read:<BR>
Let bk = xmin+k&#183;&#948; for k = 0,...,n, and wk = fw(bk)
for k = 0,...,n.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1440">1440</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP47">JP 47</A></TD>
<TD valign="top">
26.7.1

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
Representations of reference link are not unified.
Most reference links to clause (table) number, say X, are
in the form "Clause X" ("Table X") capitalized, and
subsection Y.Y.Y is referenced with its number only in the
form "Y.Y.Y". Whether they are parenthesized or not
depends on the context.
However there are some notations "(Z)" consisting of only
a number Z in parentheses to confer Clause or Table
&#160;
  </TD>
<TD valign="top">
Change "(35)" to "(Table 35)".
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP48">JP 48</A></TD>
<TD valign="top">
26.7.2

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
Representations of reference link are not unified.
Most reference links to clause (table) number, say X, are
in the form "Clause X" ("Table X") capitalized, and
subsection Y.Y.Y is referenced with its number only in the
form "Y.Y.Y". Whether they are parenthesized or not
depends on the context.
However there are some notations "(Z)" consisting of only
a number Z in parentheses to confer Clause or Table
number Z.
&#160;
  </TD>
<TD valign="top">
Change "(35)" to "(Table 35)".
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP49">JP 49</A></TD>
<TD valign="top">
26.7.4

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
Representations of reference link are not unified.
Most reference links to clause (table) number, say X, are
in the form "Clause X" ("Table X") capitalized, and
subsection Y.Y.Y is referenced with its number only in the
form "Y.Y.Y". Whether they are parenthesized or not
depends on the context.
However there are some notations "(Z)" consisting of only
a number Z in parentheses to confer Clause or Table
number Z.
&#160;
  </TD>
<TD valign="top">
Change "(36)" to "(Table 36)".
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US136">US 136</A></TD>
<TD valign="top">
26.8
&#160;
  </TD>
<TD valign="top">
Floating-point test functions are incorrectly specified.
&#160;
  </TD>
<TD valign="top">
See Appendix 1 - Additional Details
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1441">1441</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="CA9">CA 9</A></TD>
<TD valign="top">
27.2.3p2 30.3.1.2p6 30.3.1.5p7 30.6.4p7 30.6.9p5 30.6.10.1p23

    &#182;
    
27.2.3p2 30.3.1.2p6 30.3.1.5p7 30.6.4p7 30.6.9p5 30.6.10.1p23
&#160;
  </TD>
<TD valign="top">
Imposed happens-before edges should be in
synchronizes-with<BR>
Each use of the words "happens-before" should be
replaced with the words "synchronizes-with" in the
following sentences:<BR>
27.2.3p2<BR>
30.3.1.2p6<BR>
30.3.1.5p7<BR>
30.6.4p7<BR>
30.6.9p5<BR>
30.6.10.1p23<BR>
Rationale: Happens-before is defined in 1.10p11 in a way
that (deliberately) does not make it explicitly transitively
closed. Adding edges to happens-before directly, as in
27.2.3p2 etc., does not provide transitivity with
sequenced-before or any other existing happens-before
edge. This lack of transitivity seems to be unintentional.
&#160;
  </TD>
<TD valign="top">
Each use of the words "happens-before" should
be replaced with the words "synchronizes-with" in
the following sentences:<BR>
27.2.3p2<BR>
30.3.1.2p6<BR>
30.3.1.5p7<BR>
30.6.4p7<BR>
30.6.9p5<BR>
30.6.10.1p23
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1442">1442</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3196.html">
     N3196</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB122">GB 122</A></TD>
<TD valign="top">
27, 30
&#160;
  </TD>
<TD valign="top">
See (D) in attachment Appendix 1 - Additional Details
&#160;
  </TD>
<TD valign="top">
Request the concurrency working group to
determine if changes are needed
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1442, 1443">1442, 1443</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB123">GB 123</A></TD>
<TD valign="top">
27.5.3.2

    &#182;
    
Table 124
&#160;
  </TD>
<TD valign="top">
Several rows in table 124 specify a Return type of
'OFF_T', which does not appear to be a type defined in
this standard.
&#160;
  </TD>
<TD valign="top">
Resolve outstanding references to the removed
type 'OFF_T'.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1414, 1444">1414, 1444</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US137">US 137</A></TD>
<TD valign="top">
27.7
&#160;
  </TD>
<TD valign="top">
Several iostreams member functions are incorrectly
specified.
&#160;
  </TD>
<TD valign="top">
See Appendix 1 - Additional Details
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1445">1445</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3168.htm">
     N3168</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US138">US 138</A></TD>
<TD valign="top">
27.7
&#160;
  </TD>
<TD valign="top">
For istreams and ostreams, the move-constructor does
not move-construct, the move-assignment operator does
not move-assign, and the swap function does not swap
because these operations do not manage the rdbuf()
pointer. Useful applications of these operations are
prevented both by their incorrect semantics and because
they are protected.
&#160;
  </TD>
<TD valign="top">
In short: reverse the resolution of issue 900, then
change the semantics to move and swap the
rdbuf() pointer. Add a new protected constructor
that takes an rvalue reference to a stream and a
pointer to a streambuf, a new protected assign()
operator that takes the same arguments, and a
new protected partial_swap() function that doesn't
swap rdbuf().
See Appendix 1 - Additional Details
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1446">1446</A>&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>The Library Working Group reviewed n3179 and concluded that this change alone was not sufficient, as it would require changes to some of the derived stream types in the library. The preference is not make such a broad fix, and retain the current semnatic. This is closed as NAD rather than NAD future as it will be difficult to rename the new functions introduced in the C++0x revision of the standard at a later date. 
<BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3179.html">
     N3179</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US139">US 139</A></TD>
<TD valign="top">
27.7

    &#182;
    
1.1.3
&#160;
  </TD>
<TD valign="top">
Resolve issue LWG 1328 one way or the other, but
preferably in the direction outlined in the proposed
resolution, which, however, is not complete as-is: in any
case, the sentry must not set ok_ = false if is.good() ==
false, otherwise istream::seekg, being an unformatted
input function, does not take any action because the
sentry object returns false when converted to type bool.
Thus, it remains impossible to seek away from end of file.
&#160;
  </TD>
<TD valign="top">
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1447">1447</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3168.htm">
     N3168</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US140">US 140</A></TD>
<TD valign="top">
27.8
&#160;
  </TD>
<TD valign="top">
It should be possible to construct a stringstream with a
specific allocator.
&#160;
  </TD>
<TD valign="top">
Add an allocator_type and overloaded
constructors that take an Allocator argument to
basic_stringbuf, basic_istringstream,
basic_ostringstream, and basic_stringstream.
The semantics of allocator propagation should be
the same as if the stringbuf contained an
embedded basic_string using the same allocator.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>No consensus for a change at this time. 
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB124">GB 124</A></TD>
<TD valign="top">
27.8.1.3

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
N3092 27.8.1.3 Member functions contains this text
specifying the postconditions of
basic_stringbuf::str(basic_string):<BR>
"Postconditions: If mode &amp; ios_base::out is true, pbase()
points to the first underlying character and epptr() &gt;=
pbase() + s.size() holds; in addition, if mode &amp;
ios_base::in is true, pptr() == pbase() + s.data() holds,
otherwise pptr() == pbase() is true. [...]"<BR>
Firstly, there's a simple mistake: It should be pbase() +
s.length(), not pbase() + s.data().<BR>
Secondly, it doesn't match existing implementations. As
far as I can tell, GCC 4.5 does not test for mode &amp;
ios_base::in in the second part of that sentence, but for
mode &amp; (ios_base::app | ios_base_ate), and Visual C++ 9
for mode &amp; ios_base::app. Besides, the wording of the
C++0x draft doesn't make any sense to me. I suggest
changing the second part of the sentence to one of the
following:<BR>
Replace ios_base::in with (ios_base::ate | ios_base::app),
but this would require Visual C++ to change (replacing
only with ios_base::ate would require GCC to change, and
would make ios_base::app completely useless with
stringstreams):<BR>
in addition, if mode &amp; (ios_base::ate | ios_base::app) is
true, pptr() == pbase() + s.length() holds, otherwise pptr()
== pbase() is true.<BR>
Leave pptr() unspecified if mode &amp; ios_base::app, but not
mode &amp; ios_base::ate (implementations already differ in
this case, and it's always possible to use ios_base::ate to
get the effect of appending, so it's not necessary to
require any implementation to change):
in addition, if mode &amp; ios_base::ate is true, pptr() ==
pbase() + s.length() holds, if neither mode &amp; ios_base::ate
nor mode &amp; ios_base::app is true, pptr() == pbase() holds,
otherwise pptr() &gt;= pbase() &amp;&amp; pptr() &lt;= pbase() +
s.length() (which of the values in this range is
unspecified).<BR>
Slightly stricter:<BR>
in addition, if mode &amp; ios_base::ate is true, pptr() ==
pbase() + s.length() holds, if neither mode &amp; ios_base::ate
nor mode &amp; ios_base::app is true, pptr() == pbase() holds,
otherwise pptr() == pbase() || pptr() == pbase() +
s.length() (which of these two values is unspecified).
A small table might help to better explain the three cases.
BTW, at the end of the postconditions is this text: "egptr()
== eback() + s.size() hold". Is there a perference for
basic_string::length or basic_string::size? It doesn't really
matter, but it looks a bit inconsistent.
&#160;
  </TD>
<TD valign="top">
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1448">1448</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="CA4">CA 4</A></TD>
<TD valign="top">
27.8.2

    &#182;
    
various
&#160;
  </TD>
<TD valign="top">
Subclause 27.9.2 [c.files] specifies that &lt;cinttypes&gt; has
declarations for abs() and div(); however, the signatures
are not present in this subclause. The signatures
proposed under TR1 ([tr.c99.inttypes]) are not present in
FCD (unless if intmax_t happened to be long long). It is
unclear as to which, if any of the abs() and div() functions
in [c.math] are meant to be declared by &lt;cinttypes&gt;. This
subclause mentions imaxabs() and imaxdiv(). These
functions, among other things, are not specified in FCD to
be the functions from Subclause 7.8 of the C Standard.
Finally, &lt;cinttypes&gt; is not specified in FCD to include
&lt;cstdint&gt; (whereas &lt;inttypes.h&gt; includes &lt;stdint.h&gt; in C).
&#160;
  </TD>
<TD valign="top">
Please clarify.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1449">1449</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP14">JP 14</A></TD>
<TD valign="top">
28.4
&#160;
  </TD>
<TD valign="top">
Support of char16_t/char32_t is insufficient. The &lt;regex&gt;
does not have typedefs for char16_t/char32_t.<BR>
The reason we need this typedefs is, because anybody
may define
exactly same type with different typedef names.
Doesn't &lt;locale&gt; offer enough operations which is
required by regex
implementation?
&#160;
  </TD>
<TD valign="top">
Add typedefs below
<PRE>
typedef basic_regex&lt;char16_t&gt; u16regex;
typedef basic_regex&lt;char32_t&gt; u32regex;
</PRE>
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>No consensus to make a change at this time. 
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB127">GB 127</A></TD>
<TD valign="top">
28.5.2
&#160;
  </TD>
<TD valign="top">
The Bitmask Type requirements in 17.5.2.1.3 p3 say that
all elements on a bitmask type have distinct values, but
28.5.2 defines regex_constants::match_default and
regex_constants::format_default as elements of the
bitmask type regex_constants::match-flag_type, both with
value 0. This is a contradiction.
&#160;
  </TD>
<TD valign="top">
One of the bitmask elements should be removed
from the declaration and should be defined
separately, in the same manner as
ios_base::adjustfield, ios_base::basefield and
ios_base::floatfield are defined by 27.5.2.1.2p2
and Table 120. These are constants of a bitmask
type, but are not distinct elements, they have
more than one value set in the bitmask.
regex_constants::format_default should be
specified as a constant with the same value as
regex_constants::match_default.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1450">1450</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP50">JP 50</A></TD>
<TD valign="top">
28.5.2

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
Representations of reference link are not unified.
Most reference links to clause (table) number, say X, are
in the form "Clause X" ("Table X") capitalized, and
subsection Y.Y.Y is referenced with its number only in the
form "Y.Y.Y". Whether they are parenthesized or not
depends on the context.
However there are some notations "(Z)" consisting of only
a number Z in parentheses to confer Clause or Table
number Z.
&#160;
  </TD>
<TD valign="top">
Change "table 136" to "Table 136".
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP51">JP 51</A></TD>
<TD valign="top">
28.5.3

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
Representations of reference link are not unified.
Most reference links to clause (table) number, say X, are
in the form "Clause X" ("Table X") capitalized, and
subsection Y.Y.Y is referenced with its number only in the
form "Y.Y.Y". Whether they are parenthesized or not
depends on the context.
However there are some notations "(Z)" consisting of only
a number Z in parentheses to confer Clause or Table
number Z.
&#160;
  </TD>
<TD valign="top">
Change "table 137" to "Table 137".
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US141">US 141</A></TD>
<TD valign="top">
28.8
&#160;
  </TD>
<TD valign="top">
std::basic_regex should have an allocator for all the
reasons that a std::string does. For example, I can use
boost::interprocess to put a string or vector in shared
memory, but not a regex.
&#160;
  </TD>
<TD valign="top">
Add allocators to regexes
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1451">1451</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB125">GB 125</A></TD>
<TD valign="top">
28.10.3

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
The term "target sequence" is not defined.
&#160;
  </TD>
<TD valign="top">
Replace "target sequence" with "string being
searched/matched"
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1452">1452</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB126">GB 126</A></TD>
<TD valign="top">
28.10.3
&#160;
  </TD>
<TD valign="top">
It's unclear how match_results should behave if it has
been default-constructed. The sub_match objects
returned by operator[], prefix and suffix cannot point to the
end of the sequence that was searched if no search was
done. The iterators held by unmatched sub_match objects
might be singular.
&#160;
  </TD>
<TD valign="top">
Add to match_results::operator[],
match_results::prefix and match_results::suffix:<BR>
Requires: !empty()
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1453">1453</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3158.html">
     N3158</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP52">JP 52</A></TD>
<TD valign="top">
28.11.2

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
Representations of reference link are not unified.
Most reference links to clause (table) number, say X, are
in the form "Clause X" ("Table X") capitalized, and
subsection Y.Y.Y is referenced with its number only in the
form "Y.Y.Y". Whether they are parenthesized or not
depends on the context.
However there are some notations "(Z)" consisting of only
a number Z in parentheses to confer Clause or Table
number Z.
&#160;
  </TD>
<TD valign="top">
Change "table 139" to "Table 139".
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP95">JP 95</A></TD>
<TD valign="top">
28.11.3

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
The section number "(24.1.4)" for "Bidirectional Iterator" is
wrong. The correct one is "(24.2.6)".
In addition, it is written as normal text, but it should be
embedded as a link to the section.
&#160;
  </TD>
<TD valign="top">
Change "(24.1.4)" to "(24.2.6)" and make it a link
to section (24.2.6).
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP53">JP 53</A></TD>
<TD valign="top">
28.11.3

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
Representations of reference link are not unified.
Most reference links to clause (table) number, say X, are
in the form "Clause X" ("Table X") capitalized, and
subsection Y.Y.Y is referenced with its number only in the
form "Y.Y.Y". Whether they are parenthesized or not
depends on the context.
However there are some notations "(Z)" consisting of only
a number Z in parentheses to confer Clause or Table
number Z.&#160;
  </TD>
<TD valign="top">
Change "table 140" to "Table 140".
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP54">JP 54</A></TD>
<TD valign="top">
28.13

    &#182;
    
6
&#160;
  </TD>
<TD valign="top">
Representations of reference link are not unified.
Most reference links to clause (table) number, say X, are
in the form "Clause X" ("Table X") capitalized, and
subsection Y.Y.Y is referenced with its number only in the
form "Y.Y.Y". Whether they are parenthesized or not
depends on the context.
However there are some notations "(Z)" consisting of only
a number Z in parentheses to confer Clause or Table
number Z.
&#160;
  </TD>
<TD valign="top">
Change "table 135" to "Table 135".
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB128">GB 128</A></TD>
<TD valign="top">
29
&#160;
  </TD>
<TD valign="top">
WG14 has made some late changes to their specification
of atomics, and care should be taken to ensure that we
retain a common subset of language/library syntax to
declare headers that are portable to both languages.
Ideally, such headers would not require users to define
their own macros, especially not macros that map to
keywords (which remains undefined behaviour)
&#160;
  </TD>
<TD valign="top">
Depends on result of the review of WG14 work,
which is expected to be out to ballot during the
time wg21 is resolving its own ballot comments.
Liaison may also want to file comments in WG14
to ensure compatibity from both sides.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1455, 1454">1455, 1454</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3193.html">
     N3193</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="CH22">CH 22</A></TD>
<TD valign="top">
29
&#160;
  </TD>
<TD valign="top">
WG14 currently plans to introduce atomic facilities that are
intended to be compatible with the facilities of clause 29.
They should be compatible.
&#160;
  </TD>
<TD valign="top">
Make sure the headers in clause 29 are defined in
a way that is compatible with the planned C
standard.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1455, 1454">1455, 1454</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3193.html">
     N3193</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB129">GB 129</A></TD>
<TD valign="top">
29

    &#182;
    
Table 143
&#160;
  </TD>
<TD valign="top">
Table 143 lists the typedefs for various atomic types
corresponding to the various standard integer typedefs,
such as atomic_int_least8_t for int_least8_t, and
atomic_uint_fast64_t for uint_fast64_t. However, there are
no atomic typedefs corresponding to the fixed-size
standard typedefs int8_t, int16_t, and so forth.
&#160;
  </TD>
<TD valign="top">
Add the following entries to table 143:<BR>
atomic_int8_t =&gt; int8_t (optional),<BR>
atomic_int16_t =&gt; int16_t (optional),<BR>
atomic_int32_t =&gt; int32_t (optional),<BR>
atomic_int64_t =&gt; int64_t (optional),<BR>
atomic_uint8_t =&gt; uint8_t (optional),<BR>
atomic_uint16_t =&gt; uint16_t (optional),<BR>
atomic_uint32_t =&gt; uint32_t (optional),<BR>
atomic_uint64_t =&gt; uint64_t (optional)<BR>
These typedefs should be available if the
corresponding typedefs from are available.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1456">1456</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="CA16">CA 16</A></TD>
<TD valign="top">
29.1p1 29.3p8

    &#182;
    
29.1p1 footnote 343 29.3p8 footnote 344
&#160;
  </TD>
<TD valign="top">
Radioactivity<BR>
Footnotes 343 and 344 from 29.1p1 and 29.3p8 read:
"Atomic objects are neither active nor radioactive" and
"Among other implications, atomic variables shall not
decay".<BR>
We suggest that these be removed - the first is pretty
clearly a joke, but it's not obvious that the second doesn't
have some technical meaning.
&#160;
  </TD>
<TD valign="top">
Footnotes 343 and 344 from 29.1p1 and 29.3p8
should be removed.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US142">US 142</A></TD>
<TD valign="top">
29.1

    &#182;
    
P2 table 141
&#160;
  </TD>
<TD valign="top">
Missing 29.8 Fences
&#160;
  </TD>
<TD valign="top">
Add 29.8 Fences
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US143">US 143</A></TD>
<TD valign="top">
[atomics.syn] 29.2

    &#182;
    
before 1
&#160;
  </TD>
<TD valign="top">
There is no free function
atomic_compare_exchange_strong for volatile atomic
integral types; there is one for non-volatile types.
&#160;
  </TD>
<TD valign="top">
Add atomic_compare_exchange_strong for
volatile integral types to the synopsis.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US144">US 144</A></TD>
<TD valign="top">
[atomics.syn] 29.2

    &#182;
    
before 1
&#160;
  </TD>
<TD valign="top">
The synopsis lists the macros
ATOMIC_INTEGRAL_LOCK_FREE and
ATOMIC_ADDRESS_LOCK_FREE; the Lock-free
Property requirements don't have
ATOMIC_INTEGRAL_LOCK_FREE, but have 8 macros
for the various integral types.
&#160;
  </TD>
<TD valign="top">
Change 29.2 [atomics.syn] to match 29.4
[atomics.lockfree].
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US145">US 145</A></TD>
<TD valign="top">
29.2
&#160;
  </TD>
<TD valign="top">
missing atomic_compare_exchange_strong(volatile ....)
and atomic_compare)exchange_strong_explict( ...//no
volatile *?<BR>
&gt; bool atomic_compare_exchange_weak(volatile
atomic_itype*, integral*, integral);<BR>
&gt; bool atomic_compare_exchange_weak(atomic_itype*,
integral*, integral);<BR>
&gt; bool atomic_compare_exchange_strong(atomic_itype*,
integral*, integral);<BR>
&gt; bool atomic_compare_exchange_weak_explicit(volatile
atomic_itype*, integral*,<BR>
&gt; integral, memory_order, memory_order);<BR>
&gt; bool
atomic_compare_exchange_weak_explicit(atomic_itype*,
integral*,<BR>
&gt; integral, memory_order, memory_order);<BR>
&gt; bool atomic_compare_exchange_strong_explicit(volatile
atomic_itype*, integral*,<BR>
&gt; integral, memory_order, memory_order);
&#160;
  </TD>
<TD valign="top">
Repair as suggested
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB130">GB 130</A></TD>
<TD valign="top">
29.2
&#160;
  </TD>
<TD valign="top">
The synopsis for the &lt;atomic&gt; header lists the macros
ATOMIC_INTEGRAL_LOCK_FREE and
ATOMIC_ADDRESS_LOCK_FREE. The
ATOMIC_INTEGRAL_LOCK_FREE macro has been
replaced with a set of macros for each integral type, as
listed in 29.4
&#160;
  </TD>
<TD valign="top">
Replace "#define
ATOMIC_INTEGRAL_LOCK_FREE unspecified"
with
<PRE>
#define ATOMIC_CHAR_LOCK_FREE
implementation-defined
#define ATOMIC_CHAR16_T_LOCK_FREE
implementation-defined
#define ATOMIC_CHAR32_T_LOCK_FREE
implementation-defined
#define ATOMIC_WCHAR_T_LOCK_FREE
implementation-defined
#define ATOMIC_SHORT_LOCK_FREE
implementation-defined
#define ATOMIC_INT_LOCK_FREE
implementation-defined
#define ATOMIC_LONG_LOCK_FREE
implementation-defined
#define ATOMIC_LLONG_LOCK_FREE
implementation-defined
</PRE>
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1457">1457</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US146">US 146</A></TD>
<TD valign="top">
29.2

    &#182;
    
syn 29.4
&#160;
  </TD>
<TD valign="top">
The ATOMIC_..._LOCK_FREE macros have not had
changes applied.
&#160;
  </TD>
<TD valign="top">
Change to match 29.4/0.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US147">US 147</A></TD>
<TD valign="top">
29.2

    &#182;
    
syn 29.7
&#160;
  </TD>
<TD valign="top">
The declaration of ATOMIC_VAR_INIT should be
referenced to section 29.6 [atomics.types.operations], not
29.7.
&#160;
  </TD>
<TD valign="top">
Change it to 29.6.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US148">US 148</A></TD>
<TD valign="top">
29.2

    &#182;
    
syn 29.7
&#160;
  </TD>
<TD valign="top">
The definition of ATOMIC_VAR_INIT should be
'implementation defined' rather than 'see below'.
&#160;
  </TD>
<TD valign="top">
Change it to 'implementation defined'.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
No, definitely not implementation defined. "See below "is correct.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US149">US 149</A></TD>
<TD valign="top">
29.2

    &#182;
    
syn 29.5.1
&#160;
  </TD>
<TD valign="top">
The synopsis is missing the atomic_init function
declarations for the bool, integral and address types.
&#160;
  </TD>
<TD valign="top">
Copy them from 29.5.1.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US150">US 150</A></TD>
<TD valign="top">
29.2

    &#182;
    
syn 29.5.1
&#160;
  </TD>
<TD valign="top">
There are missing function prototypes bool
atomic_compare_exchange_strong(volatile atomic_itype*,
integral*, integral); and integral atomic_fetch_add(volatile
atomic_itype*, integral);
&#160;
  </TD>
<TD valign="top">
Add them.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US151">US 151</A></TD>
<TD valign="top">
29.2

    &#182;
    
syn 29.5.1
&#160;
  </TD>
<TD valign="top">
There is a duplicate function declaration of integral
atomic_fetch_or(volatile atomic_itype*, integral);
&#160;
  </TD>
<TD valign="top">
Remove the volatile qualifier from the second
declaration.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US152">US 152</A></TD>
<TD valign="top">
29.3

    &#182;
    
para 1
&#160;
  </TD>
<TD valign="top">
The table shows no disinct meaning for
memory_order_seq_cst.
&#160;
  </TD>
<TD valign="top">
Add another bullet: "- memory_order_seq_cst:
See below."
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
It's named in the second and fourth bullet items.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB131">GB 131</A></TD>
<TD valign="top">
29.3

    &#182;
    
8
&#160;
  </TD>
<TD valign="top">
See (H) in attachment Appendix 1 - Additional Details
&#160;
  </TD>
<TD valign="top">
Request the concurrency working group to
determine if changes are needed. Consider
changing the use of "sequence" in 29.3
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1458">1458</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="CA21">CA 21</A></TD>
<TD valign="top">
9.3p8 1.9p13

    &#182;
    
29.3p8 1.9p13
&#160;
  </TD>
<TD valign="top">
Overlapping evaluations are allowed<BR>
29.3p8 states:<BR>
"An atomic store shall only store a value that has
been computed from constants and program input values
by a finite sequence of program evaluations, such
that each evaluation observes the values of variables
as computed by the last prior assignment in the
sequence."<BR>
... but 1.9p13 states:
"If A is not sequenced before B and B is not
sequenced before A, then A and B are unsequenced.
[ Note: The execution of unsequenced evaluations can
overlap. -end note ]"<BR>
Overlapping executions can make it impossible to
construct the sequence described in 29.3p8. We are not
sure of the intention here and do not offer a suggestion for
change, but note that 29.3p8 is the condition that prevents
out-of-thin-air reads.<BR>
For an example, suppose we have a function invocation
f(e1,e2). The evaluations of e1 and e2 can overlap.
Suppose that the evaluation of e1 writes y and reads x
whereas the evaluation of e2 reads y and writes x, with
reads-from edges as below (all this is within a single
thread).
<PRE>
 e1           e2
Wrlx y--   --Wrlx x
      rf\ /rf
         X
        / \
Rrlx x&lt;-   -&gt;Rrlx y
</PRE>
This seems like it should be allowed, but there seems to
be no way to produce a sequence of evaluations with the
property above.<BR>
In more detail, here the two evaluations, e1 and e2, are
being executed as the arguments of a function and are
consequently not sequenced-before each other. In
practice we'd expect that they could overlap (as allowed
by 1.9p13), with the two writes taking effect before the two
reads. However, if we have to construct a linear order of
evaluations, as in 29.3p8, then the execution above is not
permited. Is that really intended?
&#160;
  </TD>
<TD valign="top">
Please clarify.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1459">1459</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US153">US 153</A></TD>
<TD valign="top">
[atomics.lockfree] 29.4

    &#182;
    
before 1
&#160;
  </TD>
<TD valign="top">
The macros are all specified as "implementation-deifned";
they should be "see below", since the required values are
spelled out.
&#160;
  </TD>
<TD valign="top">
Change the definitions of the macros in 29.4
[atomics.lockfree] from "implementation-defined"
to "see below".
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
Implementation defined requires that the implementation
document what it does. Removing this requirement would be a
technical change.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US154">US 154</A></TD>
<TD valign="top">
[atomics.lockfree] 29.4

    &#182;
    
before 1
&#160;
  </TD>
<TD valign="top">
There is no ATOMIC_BOOL_LOCK_FREE macro.
&#160;
  </TD>
<TD valign="top">
Add ATOMIC_BOOL_LOCK_FREE to 29.4
[atomics.lockfree] and to 29.2 [atomics.syn]
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1460">1460</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US155">US 155</A></TD>
<TD valign="top">
29.4

    &#182;
    
para 3
&#160;
  </TD>
<TD valign="top">
The 'via' 'by' word pairing is awkward.
&#160;
  </TD>
<TD valign="top">
Replace 'by' with 'via' in 'communication via
memory ... and by memory'.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="CA1">CA 1</A></TD>
<TD valign="top">
29.4, 29.6 29.7

    &#182;
    
various
&#160;
  </TD>
<TD valign="top">
All ATOMIC_... macros should be prefixed with STD_ as
in STD_ATOMIC_... to indicate they are STD macros as
other standard macros. The rationale that they all seem
too long seems weak.
&#160;
  </TD>
<TD valign="top">
This covers the following macros which we
suggest prepending with STD_:<BR>
29.4:<BR>
#define ATOMIC_CHAR_LOCK_FREE
implementation-defined<BR>
#define ATOMIC_CHAR16_T_LOCK_FREE
implementation-defined<BR>
#define ATOMIC_CHAR32_T_LOCK_FREE
implementation-defined<BR>
#define ATOMIC_WCHAR_T_LOCK_FREE
implementation-defined<BR>
#define ATOMIC_SHORT_LOCK_FREE
implementation-defined<BR>
#define ATOMIC_INT_LOCK_FREE
implementation-defined<BR>
#define ATOMIC_LONG_LOCK_FREE
implementation-defined<BR>
#define ATOMIC_LLONG_LOCK_FREE
implementation-defined<BR>
#define ATOMIC_ADDRESS_LOCK_FREE
implementation-defined<BR>
29.6:<BR>
#define ATOMIC_VAR_INIT(value) see below<BR>
29.7:<BR>
#define ATOMIC_FLAG_INIT see below
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1461">1461</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US156">US 156</A></TD>
<TD valign="top">
[atomics.types.integral] 29.5.1

    &#182;
    
before 1
&#160;
  </TD>
<TD valign="top">
The list of member functions for atomic_bool has four
versions of compare_exchange_weak taking one
memory_order argument; the last two should be
compare_exchange_strong.
&#160;
  </TD>
<TD valign="top">
Change the last two member functions
comapare_exchange_weak taking two
memory_order arguments to
compare_exchange_strong.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP55">JP 55</A></TD>
<TD valign="top">
29.5.1

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
Representations of reference link are not unified.
Most reference links to clause (table) number, say X, are
in the form "Clause X" ("Table X") capitalized, and
subsection Y.Y.Y is referenced with its number only in the
form "Y.Y.Y". Whether they are parenthesized or not
depends on the context.
However there are some notations "(Z)" consisting of only
a number Z in parentheses to confer Clause or Table
number Z.
&#160;
  </TD>
<TD valign="top">
Change "table 142" to "Table 142".
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB132">GB 132</A></TD>
<TD valign="top">
29.5.1
&#160;
  </TD>
<TD valign="top">
The atomic_itype types and atomic_address have two
overloads of operator= --- one is volatile qualified, and the
other is not. atomic_bool only has the volatile qualified
version:<BR>
bool operator=(bool) volatile;<BR>
On a non-volatile-qualified object this is ambiguous with
the deleted copy-assignment operator<BR>
atomic_bool&amp; operator=(atomic_bool const&amp;) = delete;<BR>
due to the need for a single standard conversion in each
case when assigning a bool to an atomic_bool as in:
<PRE>
atomic_bool b;
b=true;
</PRE>
The conversions are atomic_bool&amp; -&gt; atomic_bool
volatile&amp; vs bool -&gt; atomic_bool
&#160;
  </TD>
<TD valign="top">
Add the "bool operator=(bool);" overload to
atomic_bool in 29.5.1
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1462">1462</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3193.html">
     N3193</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US157">US 157</A></TD>
<TD valign="top">
[atomics.types.integral] 29.5.1

    &#182;
    
before 1
&#160;
  </TD>
<TD valign="top">
atomic_bool has a volatile assignment operator but not a
non-volatile operator The other integral types have both..
&#160;
  </TD>
<TD valign="top">
Add a non-volatile assignment operator to
atomic_bool.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1463">1463</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3193.html">
     N3193</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US158">US 158</A></TD>
<TD valign="top">
29.5.1

    &#182;
    
para 0
&#160;
  </TD>
<TD valign="top">
There is a space before the second &amp; in the declaration
atomic_itype&amp; operator=(const atomic_itype &amp;) = delete;
&#160;
  </TD>
<TD valign="top">
Remove the space.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US159">US 159</A></TD>
<TD valign="top">
29.5.1
&#160;
  </TD>
<TD valign="top">
Last 2 should be compare_exchane_strong<BR>
&gt; bool compare_exchange_weak(bool&amp;, bool,
memory_order, memory_order) volatile;<BR>
&gt; bool compare_exchange_weak(bool&amp;, bool,
memory_order, memory_order);<BR>
&gt; bool compare_exchange_strong(bool&amp;, bool,
memory_order, memory_order) volatile;<BR>
&gt; bool compare_exchange_strong(bool&amp;, bool,
memory_order, memory_order);<BR>
&gt; bool compare_exchange_weak(bool&amp;, bool,
memory_order = memory_order_seq_cst) volatile;<BR>
&gt; bool compare_exchange_weak(bool&amp;, bool,
memory_order = memory_order_seq_cst);<BR>
&gt; bool compare_exchange_weak(bool&amp;, bool,
memory_order = memory_order_seq_cst) volatile;<BR>
&gt; bool compare_exchange_weak(bool&amp;, bool,
memory_order = memory_order_seq_cst);
&#160;
  </TD>
<TD valign="top">
Fix last 2
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US160">US 160</A></TD>
<TD valign="top">
[atomic.types.integral] 29.5.1

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
The last sentence of 29.5.1 [atomics.types.integral]/1 says
"Table 143 shows typedefs to atomic integral classes and
the corresponding typedefs." That's nice, but nothing says
these are supposed to be part of the implementation, and
they are not listed in the synopsis.
&#160;
  </TD>
<TD valign="top">
Remove Table 143 and the last sentence of
29.5.1 [atomics.types.integral]/1.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1464">1464</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3193.html">
     N3193</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US161">US 161</A></TD>
<TD valign="top">
[atomic.types.address] 29.5.2

    &#182;
    
before 1
&#160;
  </TD>
<TD valign="top">
atomic_address has operator+= and operator-=, but no
operator++ or operator--. The template specialization
atomic&lt;Ty*&gt; has all of them.
&#160;
  </TD>
<TD valign="top">
Add operator++(int) volatile, operator++(int),
operator++() volatile, operator++(), operator--(int)
volatile, operator--(int), operator--() volatile, and
operator--() to atomic_address.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1465">1465</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3193.html">
     N3193</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US162">US 162</A></TD>
<TD valign="top">
[atomics.typres.address] 29.5.2
&#160;
  </TD>
<TD valign="top">
The compare_exchange_weak and
compare_exchange_strong member functions that take
const void* arguments lead to a silent removal of const,
because the load member function and other acessors
return the stored value as a void*.
&#160;
  </TD>
<TD valign="top">
Remove the const void* overloads of
compare_exchange_weak and
compare_exchange_strong
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1466">1466</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3193.html">
     N3193</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US163">US 163</A></TD>
<TD valign="top">
[atomics.type.address], [atomics.types.generic] 29.5.2, 29.5.3
&#160;
  </TD>
<TD valign="top">
Requiring atomic&lt;Ty*&gt; to be derived from atomic_address
breaks type safety:
<PRE>
atomic&lt;double*&gt; ip;
char ch;
atomic_store(&amp;ip, &amp;ch);
*ip.load() = 3.14159;
</PRE>
The last line overwrites ch with a value of type double
&#160;
  </TD>
<TD valign="top">
Remove the requirement that atomic&lt;Ty*&gt; be
derived from atomic_address.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1467">1467</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3193.html">
     N3193</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US164">US 164</A></TD>
<TD valign="top">
[atomics.types.address] 29.5.2

    &#182;
    
before 1
&#160;
  </TD>
<TD valign="top">
atomic_address has member functions
compare_exchange_weak and
compare_exchange_strong that take arguments of type
const void*, in addition to the void* versions. If these
member functions survive, there should be corresponding
free functions.
&#160;
  </TD>
<TD valign="top">
Add atomic_compare_exchange_weak and
atomic_compare_exchange_strong free functions
taking pointers to volatile and non-volatile
atomic_address objects and const void*
arguments.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1468">1468</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3193.html">
     N3193</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP56">JP 56</A></TD>
<TD valign="top">
29.5.3

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
Representations of reference link are not unified.
Most reference links to clause (table) number, say X, are
in the form "Clause X" ("Table X") capitalized, and
subsection Y.Y.Y is referenced with its number only in the
form "Y.Y.Y". Whether they are parenthesized or not
depends on the context.
However there are some notations "(Z)" consisting of only
a number Z in parentheses to confer Clause or Table
number Z.
&#160;
  </TD>
<TD valign="top">
Change "table 142 or table 143" to "Table 142 or
Table 143".
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB133">GB 133</A></TD>
<TD valign="top">
29.5.3
&#160;
  </TD>
<TD valign="top">
The free functions that operate on atomic_address can be
used to store a pointer to an unrelated type in an
atomic&lt;T*&gt; without a cast. e.g.
<PRE>
int i;
atomic&lt;int*&gt; ai(&amp;i);
string s;
atomic_store(&amp;ai,&amp;s);
</PRE>
&#160;
  </TD>
<TD valign="top">
Overload the atomic_store, atomic_exchange and
atomic_compare_exchange_[weak/strong]
operations for atomic&lt;T*&gt; to allow storing only
pointers to T:
<PRE>
template&lt;typename T&gt;
void atomic_store(atomic&lt;T*&gt;&amp;,T*);
template&lt;typename T&gt;
void atomic_store(atomic&lt;T*&gt;&amp;,void*) = delete;
template&lt;typename T&gt;
void
atomic_store_explicit(atomic&lt;T*&gt;&amp;,T*,memory_or
der);
template&lt;typename T&gt;
void
atomic_store_explicit(atomic&lt;T*&gt;&amp;,void*,memory
_order) = delete;
template&lt;typename T&gt;
T* atomic_exchange(atomic&lt;T*&gt;&amp;,T*);
template&lt;typename T&gt;
T* atomic_exchange(atomic&lt;T*&gt;&amp;,void*) = delete;
template&lt;typename T&gt;
T*
atomic_exchange_explicit(atomic&lt;T*&gt;&amp;,T*,memor
y_order);
template&lt;typename T&gt;
T*
atomic_exchange_explicit(atomic&lt;T*&gt;&amp;,void*,me
mory_order) = delete;
template&lt;typename T&gt;
T*
atomic_compare_exchange_weak(atomic&lt;T*&gt;&amp;,T
**,T*);
template&lt;typename T&gt;
T*
atomic_compare_exchange_weak(atomic&lt;T*&gt;&amp;,v
oid**,void*) = delete;
template&lt;typename T&gt;
T*
atomic_compare_exchange_weak_explicit(atomic
&lt;T*&gt;&amp;,T**,T*,memory_order);
template&lt;typename T&gt;
T*
atomic_compare_exchange_weak_explicit(atomic
&lt;T*&gt;&amp;,void**,void*,memory_order) = delete;
template&lt;typename T&gt;
T*
atomic_compare_exchange_strong(atomic&lt;T*&gt;&amp;,
T**,T*);
template&lt;typename T&gt;
T*
atomic_compare_exchange_strong(atomic&lt;T*&gt;&amp;,
void**,void*) = delete;
template&lt;typename T&gt;
T*
atomic_compare_exchange_strong_explicit(atomi
c&lt;T*&gt;&amp;,T**,T*,memory_order);
template&lt;typename T&gt;
T*
atomic_compare_exchange_strong_explicit(atomi
c&lt;T*&gt;&amp;,void**,void*,memory_order) = delete;
</PRE>
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1469">1469</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3193.html">
     N3193</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US165">US 165</A></TD>
<TD valign="top">
29.5.3

    &#182;
    
Paragraph 23
&#160;
  </TD>
<TD valign="top">
&#8220;is the same that same as that of&#8221; is not grammatical (and
is not clear)
&#160;
  </TD>
<TD valign="top">
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1470">1470</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US166">US 166</A></TD>
<TD valign="top">
29.6

    &#182;
    
para 2
&#160;
  </TD>
<TD valign="top">
The first three bullets seem to be missing terminal
punctuation.
&#160;
  </TD>
<TD valign="top">
Add semicolons to ends of the bullets.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US167">US 167</A></TD>
<TD valign="top">
29.6

    &#182;
    
para 3
&#160;
  </TD>
<TD valign="top">
The first three bullets seem to be missing terminal
punctuation.
&#160;
  </TD>
<TD valign="top">
Add semicolons to ends of the bullets.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
Seems to be a duplicate of US 166 but with the wrong section number.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US168">US 168</A></TD>
<TD valign="top">
29.6

    &#182;
    
para 4
&#160;
  </TD>
<TD valign="top">
The definition of the default constructor needs exposition.
&#160;
  </TD>
<TD valign="top">
Add a new paragraph: A::A() = default; Effects:
Leaves the atomic object in an uninitialized state.
[Note: These semantics ensure compatiblity with
C. --end note]
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1471">1471</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3196.html">
     N3196</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US169">US 169</A></TD>
<TD valign="top">
29.6

    &#182;
    
para 5
&#160;
  </TD>
<TD valign="top">
The definition of ATOMIC_VAR_INIT should be
'implementation defined' rather than 'see below'.
&#160;
  </TD>
<TD valign="top">
Change it to 'implementation defined'.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
No, we should not require implementors to document
the details of how they do this.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US170">US 170</A></TD>
<TD valign="top">
29.6

    &#182;
    
para 6
&#160;
  </TD>
<TD valign="top">
The definition of atomic_init should be grouped with the
value constructor.
&#160;
  </TD>
<TD valign="top">
Move the atomic_init definition to just after the
constructor definition.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
The current order reflects the order of declarations. No need to change it.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB134">GB 134</A></TD>
<TD valign="top">
29.6

    &#182;
    
5
&#160;
  </TD>
<TD valign="top">
Some of the declarations of is_lock_free seem to be
missing return types.
&#160;
  </TD>
<TD valign="top">
Replace:<BR>
A::is_lock_free() const volatile;<BR>
A::is_lock_free() const;<BR>
With:<BR>
bool A::is_lock_free() const volatile;<BR>
bool A::is_lock_free() const;
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US171">US 171</A></TD>
<TD valign="top">
29.6

    &#182;
    
para 6
&#160;
  </TD>
<TD valign="top">
The atomic_init definition "Non-atomically assigns the
value" is not quite correct, as the atomic_init purpose is
initialization.
&#160;
  </TD>
<TD valign="top">
Change "Non-atomically assigns the value desired
to *object." with "Initializes *object with value
desired". Add the note: "[Note: This function
should only be applied to objects that have been
default constructed. These semantics ensure
compatibility with C. --end note]"
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1472">1472</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3196.html">
     N3196</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US172">US 172</A></TD>
<TD valign="top">
29.6

    &#182;
    
para 9, 13, 17, 20
&#160;
  </TD>
<TD valign="top">
The order specifications are incomplete because the non-_explicit
functions do not have such parameters.
&#160;
  </TD>
<TD valign="top">
Add a new sentence: "If the program does not
specify an order, it shall be
memory_order_seq_cst." Or perhaps: "The non-_explicit
non-member functions shall affect
memory as though they were _explicit with
memory_order_seq_cst."
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1473">1473</A>&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>The Concurrency subgroup reviewed this, and deemed it NAD according to 29.6 [atomics.types.operations] paragraph 2, bullet 4. 
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US173">US 173</A></TD>
<TD valign="top">
29.6

    &#182;
    
para 20
&#160;
  </TD>
<TD valign="top">
Misspelling.
&#160;
  </TD>
<TD valign="top">
Replace "operations ate atomic" with "operations
are atomic".
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US174">US 174</A></TD>
<TD valign="top">
29.6

    &#182;
    
para 22
&#160;
  </TD>
<TD valign="top">
The first note is about effects, not returns.
&#160;
  </TD>
<TD valign="top">
Move this note to just after the Effects paragraph.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
This would require a significant rewrite, because
the Returns clause refers to the "result of the comparison"
from the Effects clause. Okay as written.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US175">US 175</A></TD>
<TD valign="top">
29.6

    &#182;
    
para 23
&#160;
  </TD>
<TD valign="top">
The first sentence is grammatically incorrect.
&#160;
  </TD>
<TD valign="top">
Replace the sentence with two: "The weak
compare-and-exchange operations may fail
spuriously. That is, it may return false while
leaving the contents of memory pointed to by
expected the same as it was before the
operation."
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1474">1474</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="CH23">CH 23</A></TD>
<TD valign="top">
29.6

    &#182;
    
p23
&#160;
  </TD>
<TD valign="top">
The first sentence has non-English syntax.
&#160;
  </TD>
<TD valign="top">
Change to "The weak compare-and-exchange
operations may fail spuriously, that is, return false
while leaving the contents of memory pointed to
by expected unchanged."
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1475">1475</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US176">US 176</A></TD>
<TD valign="top">
29.6

    &#182;
    
para 23
&#160;
  </TD>
<TD valign="top">
Unintended paragraph break.
&#160;
  </TD>
<TD valign="top">
Proposal: Remove the paragraph break between
"will be in a loop." and "When a compare-andexchange
is in a loop,".
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
Okay as written. Two different subjects, two paragraphs.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US177">US 177</A></TD>
<TD valign="top">
[atomics.types.operations] 29.6

    &#182;
    
23
&#160;
  </TD>
<TD valign="top">
The first sentence of this paragraph doesn't make sense.
&#160;
  </TD>
<TD valign="top">
Figure out what it's supposed to say, and say it.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1476">1476</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB135">GB 135</A></TD>
<TD valign="top">
29.6

    &#182;
    
23
&#160;
  </TD>
<TD valign="top">
The first sentence of 29.6p23 was changed by n2992 but
now makes no sense: "that is, return false while leaving
the contents of memory pointed to by expected before the
operation is the same that same as that of the object and
the same as that of expected after the operation."
There's a minor editorial difference between n2992 ("is
that same as that" vs "is the same that same as that") but
neither version makes sense.
Also, the remark talks about "object" which should
probably be "object or this" to cover the member functions
which have no object parameter.
&#160;
  </TD>
<TD valign="top">
Fix the Remark to say whatever was intended.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1477">1477</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB136">GB 136</A></TD>
<TD valign="top">
29.6
&#160;
  </TD>
<TD valign="top">
See (K) in attachment Appendix 1 - Additional Details
&#160;
  </TD>
<TD valign="top">
GB requests normative clarification in 29.6p4 that
concurrent access constitutes a race, as already
done on p6 and p7.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1478">1478</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US178">US 178</A></TD>
<TD valign="top">
29.7

    &#182;
    
para 7
&#160;
  </TD>
<TD valign="top">
The sentence "The order argument shall not be
memory_order_acquire nor memory_order_acq_rel." is
awkwardly phrased.
&#160;
  </TD>
<TD valign="top">
Change the sentence to "The order argument
shall be neither memory_order_acquire nor
memory_order_acq_rel."
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
Changed "nor" to "or".
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US179">US 179</A></TD>
<TD valign="top">
29.8

    &#182;
    
para 5, 6
&#160;
  </TD>
<TD valign="top">
The fence functions should be extern "C", for C
compatibility.
&#160;
  </TD>
<TD valign="top">
Add extern "C" to their declarations in 29.8 and in
29.2.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1479">1479</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB137">GB 137</A></TD>
<TD valign="top">
29.8

    &#182;
    
6
&#160;
  </TD>
<TD valign="top">
Thread fence not only establish synchronizes with
relationships,
there are semantics of fences that are expressed not in
terms of
synchronizes with relationships (for example see 29.3p5).
These semantics also need to apply to the use of
atomic_signal_fence in a restricted way.
&#160;
  </TD>
<TD valign="top">
Change 29.8p6 to "Effects: equivalent to
atomic_thread_fence(order), except that the
resulting ordering constraints are
established only between a thread and a signal
handler executed in the same thread."
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1480">1480</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US180">US 180</A></TD>
<TD valign="top">
30.1

    &#182;
    
para 1
&#160;
  </TD>
<TD valign="top">
The introductory sentence is missing futures.
&#160;
  </TD>
<TD valign="top">
Replace "communicate conditions between
threads" with "communicate conditions and values
between threads".
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB138">GB 138</A></TD>
<TD valign="top">
30.2
&#160;
  </TD>
<TD valign="top">
The FCD combines the requirements for lockable objects
with those for the standard mutex objects. These should
be separate. This is LWG issue 1268.
&#160;
  </TD>
<TD valign="top">
See attached Appendix 1 - Additional Details
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1481">1481</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3197.html">
     N3197</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US181">US 181</A></TD>
<TD valign="top">
30.2.4

    &#182;
    
para 2
&#160;
  </TD>
<TD valign="top">
The timeout operations are under-specified.
&#160;
  </TD>
<TD valign="top">
Define precise semantics for timeout_until and
timeout_for. See Appendix 1 - Additional Details
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1482">1482</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3191.html">
     N3191</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US182">US 182</A></TD>
<TD valign="top">
[thread.req.native] 30.2.3
&#160;
  </TD>
<TD valign="top">
native_handle and native-handle_type should be
removed. It is implementation-defined whether these
names are present in the various thread support classes,
and if present, it is implementation-defined what the name
native_handle_type refers to. This is exactly what the
implementor namespace is for. There is no benefit to
programmers from providing a way to portably detect that
an implementation provides non-portable extensions. The
standard should not reserve these names, with
unspecified semantics; it if does, the names will never
become portable because implementations will differ on
what they mean.
&#160;
  </TD>
<TD valign="top">
Remove [thread.req.native] 30.2.3 and remove all
mentions of native_handle and
native_handle_type.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>No consensus to make a change at this time. 
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="DE23">DE 23</A></TD>
<TD valign="top">
30.3
&#160;
  </TD>
<TD valign="top">
Predefined macros usually start and end with two
underscores, see 16.8 and FDIS 29124 = WG21 N3060
clause 7. __STDCPP_THREADS should blend in.
&#160;
  </TD>
<TD valign="top">
Change the macro name to
__STDCPP_THREADS__.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1483">1483</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US183">US 183</A></TD>
<TD valign="top">
30.3.1
&#160;
  </TD>
<TD valign="top">
There is no way to join a thread with a timeout.
&#160;
  </TD>
<TD valign="top">
Add join_for and join_until. Or decide one should
never join a thread with a timeout since
pthread_join doesn't have a timeout version.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1484">1484</A>&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>The concurrency working group deemed this an extension beyond the scope of C++0x. 
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US184">US 184</A></TD>
<TD valign="top">
30.3.1.1

    &#182;
    
para 2
&#160;
  </TD>
<TD valign="top">
It is unclear when a thread::id ceases to be meaningful.
The sentence "The library may reuse the value of a
thread::id of a terminated thread that can no longer be
joined." implies that some terminated threads can be
joined. It says nothing about detached threads.
&#160;
  </TD>
<TD valign="top">
Require a unique thread::id for every thread that is
(1) detached and not terminated or (2) has an
associated std::thread object.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1485">1485</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP97">JP 97</A></TD>
<TD valign="top">
30.3.1.5

    &#182;
    
9
&#160;
  </TD>
<TD valign="top">
In Throw clause, both "Throws: system_error" and
"Throws: std::system_error" are used. They should be in a
unified way, and we propose to use system_error instead
of std::system_error.
&#160;
  </TD>
<TD valign="top">
Change to:<BR>
Throws: system_error
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP98">JP 98</A></TD>
<TD valign="top">
30.3.1.5

    &#182;
    
14
&#160;
  </TD>
<TD valign="top">
In Throw clause, both "Throws: system_error" and
"Throws: std::system_error" are used. They should be in a
unified way, and we propose to use system_error instead
of std::system_error.
&#160;
  </TD>
<TD valign="top">
Change to:<BR>
Throws: system_error
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="CH24">CH 24</A></TD>
<TD valign="top">
30.3.2

    &#182;
    
p1
&#160;
  </TD>
<TD valign="top">
What would be the value this_thread::get_id() when called
from a detached thread?
&#160;
  </TD>
<TD valign="top">
Add some text to clarify that get_id() still returns
the same value even after detaching.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1486">1486</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="CH25">CH 25</A></TD>
<TD valign="top">
30.3.2

    &#182;
    
p8 and p11
&#160;
  </TD>
<TD valign="top">
Clock related operations are currently not required not to
throw. So "Throws: Nothing." is not always true.
&#160;
  </TD>
<TD valign="top">
Either require clock related operations not to throw
(in 20.10) or change the Throws clauses in 30.3.2.
Also possibly add a note that abs_time in the past
or negative rel_time is allowed.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1487">1487</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US185">US 185</A></TD>
<TD valign="top">
30.4
&#160;
  </TD>
<TD valign="top">
Cooperate with WG14 to improve interoperability between
the C++0x and C1x threads APIs. In particular, C1x
mutexes should be conveniently usable with a C++0x
lock_guard. Performance overheads for this combination
should be considered.
&#160;
  </TD>
<TD valign="top">
Remove C++0x timed_mutex and
timed_recursive_mutex if that facilitates
development of more compatible APIs.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1488">1488</A>&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>The concurrency group reviewed the options, and decided that closer harmony should wait until both standards are published.
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="CH26">CH 26</A></TD>
<TD valign="top">
30.4
&#160;
  </TD>
<TD valign="top">
Specifications of unlock member functions and unlock
mutex requirements are inconsistent wrt to exceptions and
pre- and postconditions.
&#160;
  </TD>
<TD valign="top">
unlock should specifiy the precondition that the
current thread "owns the lock", this will make calls
without holding the locks "undefined behavior".
unlock in [mutex.requirements] should either be
noexcept(true) or be allowed to throw
system_error like unique_lock::unlock, or the latter
should be nothrow(true) and have the precondition
owns==true.
Furthermore unique_lock's postcondition is wrong
in the case of a recursive mutex where owns
might stay true, when it is not the last unlock
needed to be called.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1489">1489</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3197.html">
     N3197</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="CH27">CH 27</A></TD>
<TD valign="top">
30.4.1

    &#182;
    
p18
&#160;
  </TD>
<TD valign="top">
The mutex requirements force try_lock to be
noexcept(true). However, where they are used by the
generic algorithms, those relax this requirement and say
that try_lock may throw. This means the requirement is
too stringent, also a non-throwing try_lock does not allow
for a diagnostic such as system_error that lock() will give
us.
&#160;
  </TD>
<TD valign="top">
delete p18, adjust 30.4.4 p1 and p4 accordingly
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1490">1490</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3197.html">
     N3197</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP99">JP 99</A></TD>
<TD valign="top">
30.4.1

    &#182;
    
11
&#160;
  </TD>
<TD valign="top">
In Throw clause, both "Throws: system_error" and
"Throws: std::system_error" are used. They should be in a
unified way, and we propose to use system_error instead
of std::system_error.
&#160;
  </TD>
<TD valign="top">
Change to:<BR>
Throws: system_error
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US186">US 186</A></TD>
<TD valign="top">
30.4.1

    &#182;
    
14
&#160;
  </TD>
<TD valign="top">
try_lock does not provide a guarantee of forward progress
because it is allowed to spuriously fail.
&#160;
  </TD>
<TD valign="top">
The standard mutex types must not fail spuriously
in try_lock. See Appendix 1 - Additional Details
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1491">1491</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/N3209.htm">
     N3209</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US187">US 187</A></TD>
<TD valign="top">
30.4.1

    &#182;
    
14
&#160;
  </TD>
<TD valign="top">
Paragraph mentions compare_exchange, which no longer
exists.
&#160;
  </TD>
<TD valign="top">
Change &#8220;compare_exchange&#8221; to
&#8220;compare_exchange_weak&#8221;.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
Changed <TT>compare_exchange</TT> to "compare and exchange".
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP57">JP 57</A></TD>
<TD valign="top">
30.4.1

    &#182;
    
14
&#160;
  </TD>
<TD valign="top">
Representations of reference link are not unified.
Most reference links to clause (table) number, say X, are
in the form "Clause X" ("Table X") capitalized, and
subsection Y.Y.Y is referenced with its number only in the
form "Y.Y.Y". Whether they are parenthesized or not
depends on the context.
However there are some notations "(Z)" consisting of only
a number Z in parentheses to confer Clause or Table
number Z.
&#160;
  </TD>
<TD valign="top">
Change "(29)" to "(Clause 29)".
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US188">US 188</A></TD>
<TD valign="top">
30.4.1

    &#182;
    
20, 21
&#160;
  </TD>
<TD valign="top">
Mutex requirements should not be bound to threads
&#160;
  </TD>
<TD valign="top">
See Appendix 1 - Additional Details
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1492">1492</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3197.html">
     N3197</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP58">JP 58</A></TD>
<TD valign="top">
30.4.1.1

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
Representations of reference link are not unified.
Most reference links to clause (table) number, say X, are
in the form "Clause X" ("Table X") capitalized, and
subsection Y.Y.Y is referenced with its number only in the
form "Y.Y.Y". Whether they are parenthesized or not
depends on the context.
However there are some notations "(Z)" consisting of only
a number Z in parentheses to confer Clause or Table
number Z.
&#160;
  </TD>
<TD valign="top">
Change "(9)" to "(Clause 9)".
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US189">US 189</A></TD>
<TD valign="top">
30.4.1.1 30.4.1.2
&#160;
  </TD>
<TD valign="top">
mutex and recursive_mutex should have an is_locked()
member function. is_locked allows a user to test a lock
without acquiring it and can be used to implement a lightweight
try_try_lock.
&#160;
  </TD>
<TD valign="top">
Add a member function:
<PRE>
bool is_locked() const;
</PRE>
to std::mutex and std::recursive_mutex. These
functions return true if the current thread would
not be able to obtain a mutex. These functions do
not synchronize with anything (and, thus, can
avoid a memory fence).
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1493">1493</A>&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>The Concurrency subgroup reviewed this issue and deemed it to be an extension to be handled after publishing C++0x. 
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP59">JP 59</A></TD>
<TD valign="top">
30.4.1.2

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
Representations of reference link are not unified.
Most reference links to clause (table) number, say X, are
in the form "Clause X" ("Table X") capitalized, and
subsection Y.Y.Y is referenced with its number only in the
form "Y.Y.Y". Whether they are parenthesized or not
depends on the context.
However there are some notations "(Z)" consisting of only
a number Z in parentheses to confer Clause or Table
number Z.
&#160;
  </TD>
<TD valign="top">
Change "(9)" to "(Clause 9)".
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP60">JP 60</A></TD>
<TD valign="top">
30.4.2.1

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
Representations of reference link are not unified.
Most reference links to clause (table) number, say X, are
in the form "Clause X" ("Table X") capitalized, and
subsection Y.Y.Y is referenced with its number only in the
form "Y.Y.Y". Whether they are parenthesized or not
depends on the context.
However there are some notations "(Z)" consisting of only
a number Z in parentheses to confer Clause or Table
number Z.
&#160;
  </TD>
<TD valign="top">
Change "(9)" to "(Clause 9)".
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP61">JP 61</A></TD>
<TD valign="top">
30.4.2.2

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
Representations of reference link are not unified.
Most reference links to clause (table) number, say X, are
in the form "Clause X" ("Table X") capitalized, and
subsection Y.Y.Y is referenced with its number only in the
form "Y.Y.Y". Whether they are parenthesized or not
depends on the context.
However there are some notations "(Z)" consisting of only
a number Z in parentheses to confer Clause or Table
number Z.
&#160;
  </TD>
<TD valign="top">
Change "(9)" to "(Clause 9)".
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP70">JP 70</A></TD>
<TD valign="top">
30.4.3.2

    &#182;
    
18
&#160;
  </TD>
<TD valign="top">
Constant width font should be used for
"std::system_error"s in the paragraph as described in
Syntax notation (1.6).
&#160;
  </TD>
<TD valign="top">
Change the font for "std::system_error" to
constant width type.<BR>
Throws: <B><TT>system_error</TT></B> when an exception is
required
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP100">JP 100</A></TD>
<TD valign="top">
30.4.3.2.2

    &#182;
    
18
&#160;
  </TD>
<TD valign="top">
In Throw clause, both "Throws: system_error" and
"Throws: std::system_error" are used. They should be in a
unified way, and we propose to use system_error instead
of std::system_error.
&#160;
  </TD>
<TD valign="top">
Change to:<BR>
Throws: system_error
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US190">US 190</A></TD>
<TD valign="top">
30.4.5.2

    &#182;
    
para 2, 3
&#160;
  </TD>
<TD valign="top">
The term "are serialized" is never defined.
&#160;
  </TD>
<TD valign="top">
Remove the sentence with "are serialized" from
paragraph 2. Add "Calls to call_once on the same
once_flag object shall not introduce data races
(17.6.4.8)." to paragraph 3.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1494">1494</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP101">JP 101</A></TD>
<TD valign="top">
30.4.5.2

    &#182;
    
4
&#160;
  </TD>
<TD valign="top">
In Throw clause, both "Throws: system_error" and
"Throws: std::system_error" are used. They should be in a
unified way, and we propose to use system_error instead
of std::system_error.
&#160;
  </TD>
<TD valign="top">
Change to:<BR>
Throws: system_error
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US191">US 191</A></TD>
<TD valign="top">
30.5
&#160;
  </TD>
<TD valign="top">
The condition variable wait_for returning cv_status is
insufficient.
&#160;
  </TD>
<TD valign="top">
Return a duration of timeout remaining instead.
See Appendix 1 - Additional Details
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1495">1495</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3191.html">
     N3191</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB139">GB 139</A></TD>
<TD valign="top">
30.5

    &#182;
    
7
&#160;
  </TD>
<TD valign="top">
The text says "... ownership of the lock as the current
thred exits, ...", with "thread" misspelled.
&#160;
  </TD>
<TD valign="top">
Replace "thred" with "thread"
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB140">GB 140</A></TD>
<TD valign="top">
30.5

    &#182;
    
9
&#160;
  </TD>
<TD valign="top">
The text says "... waiting threds ..." with "threads"
misspelled.
&#160;
  </TD>
<TD valign="top">
Replace "threds" with "threads".
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="CH28">CH 28</A></TD>
<TD valign="top">
30.5.1
&#160;
  </TD>
<TD valign="top">
Requiring wait_until makes it impossible to implement
condition_variable correctly using respective objects
provided by the operating system (i.e. implementing the
native_handle() function) on many platforms (e.g. POSIX,
Windows, MacOS X) or using the same object as for the
condition variable proposed for C.
&#160;
  </TD>
<TD valign="top">
Remove the wait_until functions or make them at
least conditionally supported.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1496">1496</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3191.html">
     N3191</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP102">JP 102</A></TD>
<TD valign="top">
30.5.1

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
In Throw clause, both "Throws: system_error" and
"Throws: std::system_error" are used. They should be in a
unified way, and we propose to use system_error instead
of std::system_error.
&#160;
  </TD>
<TD valign="top">
Change to:<BR>
Throws: system_error
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="CH30">CH 30</A></TD>
<TD valign="top">
30.5.1 and 30.5.2

    &#182;
    
p13, last bullet, and corresponding paragraphs in all wait functions
&#160;
  </TD>
<TD valign="top">
If lock.lock() throws an exception, the postcondition can
not be generally achieved.
&#160;
  </TD>
<TD valign="top">
Either state that the postcondition might not be
achieved, depending on the error condition, or
state that terminate() is called in this case.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1497">1497</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP103">JP 103</A></TD>
<TD valign="top">
30.5.1

    &#182;
    
15
&#160;
  </TD>
<TD valign="top">
In Throw clause, both "Throws: system_error" and
"Throws: std::system_error" are used. They should be in a
unified way, and we propose to use system_error instead
of std::system_error.
&#160;
  </TD>
<TD valign="top">
Change to:<BR>
Throws: system_error
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="CH31">CH 31</A></TD>
<TD valign="top">
30.5.1 and 30.5.2

    &#182;
    
p19, third bullet, and corresponding paragraphs in all wait_for/wait_until functions
&#160;
  </TD>
<TD valign="top">
The sentences contain superflous "or"s.
&#160;
  </TD>
<TD valign="top">
Change "The function will unblock when signaled
by a call to notify_one() or a call to notify_all(), if
abs_time &lt;= Clock::now(), or spuriously." to "The
function will unblock when signaled by a call to
notify_one(), a call to notify_all(), if abs_time &lt;=
Clock::now(), or spuriously."
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>
This is correct as written. There are three conditions:
"when signalled", "if", "spuriously". The first has two
parts, separated by "or".
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP104">JP 104</A></TD>
<TD valign="top">
30.5.1

    &#182;
    
22
&#160;
  </TD>
<TD valign="top">
In Throw clause, both "Throws: system_error" and
"Throws: std::system_error" are used. They should be in a
unified way, and we propose to use system_error instead
of std::system_error.
&#160;
  </TD>
<TD valign="top">
Change to:<BR>
Throws: system_error
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US192">US 192</A></TD>
<TD valign="top">
30.5.1

    &#182;
    
para 26
&#160;
  </TD>
<TD valign="top">
The identifier cv_status::no_timeout is not in code font.
&#160;
  </TD>
<TD valign="top">
Change it to code font.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="CH29">CH 29</A></TD>
<TD valign="top">
30.5.1 and 30.5.2

    &#182;
    
p34 and p28, respectively
&#160;
  </TD>
<TD valign="top">
It is unclear if a spurious wake-up during the loop and reentering
of the blocked state due to a repeated execution
of the loop will adjust the timer of the blocking with the
respect to the previously specified rel_time value.
&#160;
  </TD>
<TD valign="top">
Make it clear (e.g. by a note) that when reexecuting
the loop the waiting time when blocked
will be adjusted with respect to the elapsed time of
the previous loop executions.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1498">1498</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3191.html">
     N3191</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US193">US 193</A></TD>
<TD valign="top">
30.5.1, 30.5.2
&#160;
  </TD>
<TD valign="top">
Condition variables preclude a wakeup optimization.
&#160;
  </TD>
<TD valign="top">
Change condition_variable to allow such
optimization. See Appendix 1 - Additional Details
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1499">1499</A>&#160;
  </TD>
<TD valign="top">
     REJECTED
    <BR><BR>THe Concurrency subgroup reviewed the issue, and deemed it an extension to be handled after C++0x. 
&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP62">JP 62</A></TD>
<TD valign="top">
30.5.1

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
Representations of reference link are not unified.
Most reference links to clause (table) number, say X, are
in the form "Clause X" ("Table X") capitalized, and
subsection Y.Y.Y is referenced with its number only in the
form "Y.Y.Y". Whether they are parenthesized or not
depends on the context.
However there are some notations "(Z)" consisting of only
a number Z in parentheses to confer Clause or Table
number Z.
&#160;
  </TD>
<TD valign="top">
Change "(9)" to "(Clause 9)".
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="CH32">CH 32</A></TD>
<TD valign="top">
30.5.2
&#160;
  </TD>
<TD valign="top">
Given that the lock type can be something the underlying
doesn't know 'native_handle()' is probably
unimplementable on essentially all platforms.
&#160;
  </TD>
<TD valign="top">
Consider the removal of 'native_handle()'.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1500">1500</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP105">JP 105</A></TD>
<TD valign="top">
30.5.2

    &#182;
    
12
&#160;
  </TD>
<TD valign="top">
In Throw clause, both "Throws: system_error" and
"Throws: std::system_error" are used. They should be in a
unified way, and we propose to use system_error instead
of std::system_error.
&#160;
  </TD>
<TD valign="top">
Change to:<BR>
Throws: system_error
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP106">JP 106</A></TD>
<TD valign="top">
30.5.2

    &#182;
    
18
&#160;
  </TD>
<TD valign="top">
In Throw clause, both "Throws: system_error" and
"Throws: std::system_error" are used. They should be in a
unified way, and we propose to use system_error instead
of std::system_error.
&#160;
  </TD>
<TD valign="top">
Change to:<BR>
Throws: system_error
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="CH33">CH 33</A></TD>
<TD valign="top">
30.5.2

    &#182;
    
before p25
&#160;
  </TD>
<TD valign="top">
Template function wait_until is missing class Clock
template parameter.
&#160;
  </TD>
<TD valign="top">
Change "template &lt;class Lock, class Duration,
class Predicate&gt;" to "template &lt;class Lock, class
Clock, class Duration, class Predicate&gt;".
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP96">JP 96</A></TD>
<TD valign="top">
30.5.3

    &#182;
    
2
&#160;
  </TD>
<TD valign="top">
Inconsistency between 30.4 paragraph 1 and 30.4.3
paragraph 2.
In 30.4 paragraph 1:
<PRE>
namespace std {
...
constexpr defer_lock_t defer_lock { };
constexpr try_to_lock_t try_to_lock { };
constexpr adopt_lock_t adopt_lock { };
}
</PRE>
In 30.4.3 paragraph 2:
<PRE>
namespace std {
...
extern const defer_lock_t defer_lock { };
extern const try_to_lock_t try_to_lock { };
extern const adopt_lock_t adopt_lock { };
}
</PRE>
The writer seems to have forgotten to rewrite latter cases,
so 30.4.3 paragraph 2 should be modified as this
proposal.
&#160;
  </TD>
<TD valign="top">
Change "extern const" to "constexpr".
<PRE>
namespace std {
...
constexpr defer_lock_t defer_lock { };
constexpr try_to_lock_t try_to_lock { };
constexpr adopt_lock_t adopt_lock { };
}
</PRE>
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US194">US 194</A></TD>
<TD valign="top">
30.6
&#160;
  </TD>
<TD valign="top">
The specification for managing associated asynchronous
state is confusing, sometimes omitted, and redundantly
specified.
&#160;
  </TD>
<TD valign="top">
Define terms-of-art for releasing, making ready,
and abandoning an associated asynchronous
state. Use those terms where appropriate. See
Appendix 1 - Additional Details
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1501">1501</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3192.html">
     N3192</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="CH34">CH 34</A></TD>
<TD valign="top">
30.6.1

    &#182;
    
p1
&#160;
  </TD>
<TD valign="top">
The paragraph is misleading and incorrect wrt to the
current specification, since an async call with launch::sync
will execute in the same thread.
&#160;
  </TD>
<TD valign="top">
Change the paragraph to '30.6 describes
components that a C++ program can use to
retrieve the result (value or exception) of a
function that has run in a (potentially different)
thread.'
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US195">US 195</A></TD>
<TD valign="top">
30.6.4

    &#182;
    
para 8
&#160;
  </TD>
<TD valign="top">
The intent and meaning of the paragraph is not apparent.
&#160;
  </TD>
<TD valign="top">
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1502">1502</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="CH35">CH 35</A></TD>
<TD valign="top">
30.6.4ff
&#160;
  </TD>
<TD valign="top">
The term "associated asynchronous state" is long, ugly
and misleading terminology. When introduced we agreed
upon that we should come up with a better name. Here it
is: "liaison state". Since the state is hidden and provides
synchronization of a future with its corresponding promise,
we believe "liaison state" is a much better and shorter
name (liaison ~ (typically hidden) relationship)
&#160;
  </TD>
<TD valign="top">
Change all occurrences of "associated
asynchronous state" to "liaison state".
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1503">1503</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US196">US 196</A></TD>
<TD valign="top">
30.6.5

    &#182;
    
para 21, 25
&#160;
  </TD>
<TD valign="top">
The term "are serialized" is not defined.
&#160;
  </TD>
<TD valign="top">
Replace "are serialized" with "shall not introduce a
data race (17.6.4.8)".
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1504">1504</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US197">US 197</A></TD>
<TD valign="top">
30.6.5

    &#182;
    
para 21, 25
&#160;
  </TD>
<TD valign="top">
There is no defined synchronization between
promise::set_value and future::get.
&#160;
  </TD>
<TD valign="top">
Replace "[Note: and they synchronize and
serialize with other functions through the referred
associated asynchronous state. --end note]" with
the normative "They synchronize with (1.10) any
operation on a future object with the same
associated asynchronous state marked ready."
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1505">1505</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US198">US 198</A></TD>
<TD valign="top">
30.6.5

    &#182;
    
22
&#160;
  </TD>
<TD valign="top">
promise::set_exception can be called with a null pointer,
but none of the descriptions of the get() functions for the
three types of futures say what happens for this case.
&#160;
  </TD>
<TD valign="top">
Add the following sentence to the end of
30.6.5/22: The behavior of a program that calls
set_exception with a null pointer is undefined.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1506">1506</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US199">US 199</A></TD>
<TD valign="top">
[futures.promise] 30.6.5

    &#182;
    
26ff, 29ff
&#160;
  </TD>
<TD valign="top">
promise::XXX_at_thread_exit functions have no
synchronization requirements. Specifying synchronization
for these member functions requires coordinating with the
words in 30.6.5/21 and 25, which give synchronization
requirements for promise::set_value and
promise::set_exception.
&#160;
  </TD>
<TD valign="top">
Change 30.6.5/21 to mention
set_value_at_thread_exit and
set_exception_at_thread_exit; with this text,
replace 30.6.5/25 and add two new paragraphs,
after 30.6.5/28 and 30.6.5/31.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1507">1507</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US200">US 200</A></TD>
<TD valign="top">
30.6.6

    &#182;
    
para 26
&#160;
  </TD>
<TD valign="top">
The paragraph is missing the "Returns:" label.
&#160;
  </TD>
<TD valign="top">
Add the label.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US201">US 201</A></TD>
<TD valign="top">
[futures.unique_future], [futures.shared_future], [futures.atomic_future], [futures.task] 30.6.6 30.6.7 30.6.8 30.6.10
&#160;
  </TD>
<TD valign="top">
packaged_task provides operator bool() to check whether
an object has an associated asynchronous state. The
various future types provide a member function valid() that
does the same thing. The names of these members
should be the same.
&#160;
  </TD>
<TD valign="top">
Replaced the name packaged_task::operator
bool() with packaged_task::valid() in the synopsis
(30.6.10 [futures.task]/2) and the member function
specification (before 30.6.10.1
[futures.task.members]/15).
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1508">1508</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3194.html">
     N3194</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US202">US 202</A></TD>
<TD valign="top">
[futures.atomic_future] 30.6.8

    &#182;
    
18
&#160;
  </TD>
<TD valign="top">
The note in this paragraph says "unlike future, calling get
more than once on the same atomic_future object is well
defined and produces the result again." There is nothing
in future that says anything negative about calling get
more than once.
&#160;
  </TD>
<TD valign="top">
Remove this note, or add words to the
requirements for future that reflect what this note
says.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1509">1509</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3194.html">
     N3194</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US203">US 203</A></TD>
<TD valign="top">
[futures.atomic_future] 30.6.8
&#160;
  </TD>
<TD valign="top">
Both future and shared_future specify that calling most
member functions on an object for which valid() == false
produces undefined behavior. There is no such statement
for atomic_future.
&#160;
  </TD>
<TD valign="top">
Add a new paragraph after 30.6.8
[futures.atomic_future]/2 with the same words as
30.6.7 [futures.shared_future]/3.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1510">1510</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3194.html">
     N3194</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US204">US 204</A></TD>
<TD valign="top">
30.6.8

    &#182;
    
Paragraph 7-8
&#160;
  </TD>
<TD valign="top">
According to the definition of atomic_future, all members
of atomic_future are synchronizing except constructors.
However, it would probably be appropriate for a move
constructor to be synchronizing on the source object. If
not, the postconditions on paragraphs 7-8, might not be
satisfied. This may be applicable if a collection of futures
are being doled out to a set of threads that process their
value.
&#160;
  </TD>
<TD valign="top">
Make the move constructor for atomic future lock
the source
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1511">1511</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3194.html">
     N3194</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US205">US 205</A></TD>
<TD valign="top">
[futures.async] 30.6.9

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
The third sentence says "If the invocation is not deferred,
a call to a waiting function on an asynchronous return
object that shares the associated asynchronous state
created by this async call shall block until the associated
thread has completed." The next sentence says "If the
invocation is not deferred, the join() on the created
thread..." Blocking until a thread completes is not
necessarily a join.
&#160;
  </TD>
<TD valign="top">
Decide whether the requirement is to block until
finished or to call join, and rewrite to match.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1512">1512</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3194.html">
     N3194</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="CH36">CH 36</A></TD>
<TD valign="top">
30.6.9 and 30.6.1

    &#182;
    
&lt;future&gt; synopsis and p3, respectively
&#160;
  </TD>
<TD valign="top">
Providing only three different possible values for the enum
launch and saying that launch::any means either
launch::sync or launch::async is very restricting. This
hinders future implementors to provide clever
infrastructures that can simply by used by a call to
async(launch::any,...). Also there is no hook for an
implementation to provide additional alternatives to launch
enumeration and no useful means to combine those (i.e.
interpret them like flags). We believe something like
async(launch::sync | launch::async, ...) should be allowed
and can become especially useful if one could say also
something like async(launch::any &amp; ~launch::sync, ....)
respectively. This flexibility might limit the features usable
in the function called through async(), but it will allow a
path to effortless profit from improved hardware/software
without complicating the programming model when just
using async(launch::any,...)
&#160;
  </TD>
<TD valign="top">
Change in 30.6.1 'enum class launch' to allow
further implementation defined values and provide
the following bit-operators on the launch values
(operator|, operator&amp;, operator~ delivering a
launch value).<BR>
Note: a possible implementation might use an
unsigned value to represent the launch enums,
but we shouldn't limit the standard to just 32 or 64
available bits in that case and also should keep
the launch enums in their own enum namespace.<BR>
Change [future.async] p3 according to the
changes to enum launch. change --launch::any to
"the implementation may choose any of the
policies it provides." Note: this can mean that an
implementation may restrict the called function to
take all required information by copy in case it will
be called in a different address space, or even, on
a different processor type. To ensure that a call is
either performed like launch::async or
launch::sync describe one should call
async(launch::sync|launch::async,...)
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1513">1513</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED with MODIFICATIONS
    <BR><BR>
    See paper <A HREF="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/N3188.html">
     N3188</A>&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP107">JP 107</A></TD>
<TD valign="top">
30.6.9

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
Typo, "." should be "&gt;".
decay_copy(std::forward&lt;Args.(args))...
&#160;
  </TD>
<TD valign="top">
Correct typo.
decay_copy(std::forward&lt;Args&gt;(args))...
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP108">JP 108</A></TD>
<TD valign="top">
30.6.9

    &#182;
    
3
&#160;
  </TD>
<TD valign="top">
&lt;Arg&gt; should be &lt;Args&gt;.
launch::sync  Stores decay_copy(std::forward&lt;F&gt;(f))
and
decay_copy(std::forward&lt;Arg&gt;(args))...
&#160;
  </TD>
<TD valign="top">
Change to:<BR>
launch::sync  Stores
decay_copy(std::forward&lt;F&gt;(f)) and
decay_copy(std::forward&lt;Args&gt;(args))...
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US206">US 206</A></TD>
<TD valign="top">
[futures.task.members] 30.6.10.1

    &#182;
    
27, 28
&#160;
  </TD>
<TD valign="top">
The text of paragraph 27 says that reset() moves the
function object, but the text of paragraph 28 talks about
exceptions thrown by the copy constructor.
&#160;
  </TD>
<TD valign="top">
Change "copy constructor" to "move constructor"
in 30.6.10.1/28, bullet 2.
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US207">US 207</A></TD>
<TD valign="top">
[futures.task.members] 30.6.10.1

    &#182;
    
1-8
&#160;
  </TD>
<TD valign="top">
The constructor that takes R(*)(ArgTypes...) is not
needed; the constructor that takes a callable type works
for this argument type. More generally, the constructors
for packaged_task should parallel those for function.
&#160;
  </TD>
<TD valign="top">
Review the constructors for packaged_task and
provide the same ones as function, except where
inappropriate.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1514">1514</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="US208">US 208</A></TD>
<TD valign="top">
[futures.task.members] 30.6.10.1

    &#182;
    
24-26
&#160;
  </TD>
<TD valign="top">
packaged_task::make_ready_at_thread_exit has no
synchronization requirements.
&#160;
  </TD>
<TD valign="top">
Figure out what the synchronization requirements
should be and write them.
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1515">1515</A>&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB141">GB 141</A></TD>
<TD valign="top">
Appendix A [gram] paragraph 1
&#160;
  </TD>
<TD valign="top">
The links for disambiguation rules go to 6.8, 7.1 and 10.2.
Section 8.2 covers ambiguity in declarators, so should be
added
&#160;
  </TD>
<TD valign="top">
Added a link to 8.2 [dcl.ambig.res] to Appendix A
p1
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP63">JP 63</A></TD>
<TD valign="top">
A.1

    &#182;
    
1
&#160;
  </TD>
<TD valign="top">
Representations of reference link are not unified.
Most reference links to clause (table) number, say X, are
in the form "Clause X" ("Table X") capitalized, and
subsection Y.Y.Y is referenced with its number only in the
form "Y.Y.Y". Whether they are parenthesized or not
depends on the context.
However there are some notations "(Z)" consisting of only
a number Z in parentheses to confer Clause or Table
number Z.
&#160;
  </TD>
<TD valign="top">
Change "(clause 9)" to "(Clause 9)".
Change "(clause 14)" to "(Clause 14)".
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="FI6">FI 6</A></TD>
<TD valign="top">
D.2 [depr.static]

    &#182;
    
Paragraph 1
&#160;
  </TD>
<TD valign="top">
The use of static in namespace scope should not be
deprecated. Anonymous namespaces are not a sufficient
replacement for the functionality.
&#160;
  </TD>
<TD valign="top">
Strike [depr.static] completely.
&#160;
  </TD>
<TD valign="top">CWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1012">1012</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="GB142">GB 142</A></TD>
<TD valign="top">
D10
&#160;
  </TD>
<TD valign="top">
auto_ptr does not appear in the &lt;memory&gt; synopsis and
[depr.auto.ptr] doesn't say which header declares it.
Conversely, the deprecated binders bind1st etc. are in the
&lt;functional&gt; synopsis, this is inconsistent
&#160;
  </TD>
<TD valign="top">
Either auto_ptr should be declared in the
&lt;memory&gt; synopsis, or the deprecated binders
should be removed from the &lt;functional&gt; synopsis
and appendix D should say which header declares
the binders and auto_ptr
&#160;
  </TD>
<TD valign="top">LWG&#160;
  </TD>
<TD valign="top"><A href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html#1516">1516</A>&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP109">JP 109</A></TD>
<TD valign="top">
Annex B
&#160;
  </TD>
<TD valign="top">
Although implementation limits for at_quick_exit() is
mentioned in 18.5 paragraph 5, it is not on the list of
Implementation quantities.
&#160;
  </TD>
<TD valign="top">
Add the following line.
&#8212; Functions registered by at_quick_exit()[32].
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
<TR>
<TD valign="top"><A NAME="JP110">JP 110</A></TD>
<TD valign="top">
Index
&#160;
  </TD>
<TD valign="top">
"local scope" has been renamed to "block scope", but the
reference to "local scope" still remains in Index.<BR>
block scope; see local scope, 37<BR>
"local scope" should refer to "block scope".
&#160;
  </TD>
<TD valign="top">
Change to:<BR>
local scope; see block scope, 37
&#160;
  </TD>
<TD valign="top">editor&#160;
  </TD>
<TD valign="top">&#160;
  </TD>
<TD valign="top">
     ACCEPTED
    &#160;
  </TD>
</TR>
</TBODY>
</TABLE>
</BODY>
</HTML>
