<HTML>
<HEAD>
<TITLE>



    C++ Standard Core Language
    
      Active Issues
     </TITLE>
</HEAD>
<BODY>
<TABLE ALIGN="RIGHT" CELLSPACING="0" CELLPADDING="0">
<TR>
<TD ALIGN="RIGHT">
      Document number:
     </TD><TD>
        &nbsp;J16/05-0189 = WG21 N1929</TD>
</TR>
<TR>
<TD ALIGN="RIGHT">
      Date:
     </TD><TD>
      &nbsp;2005-12-16</TD>
</TR>
<TR>
<TD ALIGN="RIGHT">
      Project:
     </TD><TD>
      &nbsp;Programming Language C++
     </TD>
</TR>
<TR>
<TD ALIGN="RIGHT">
      Reference:
     </TD><TD>
      &nbsp;ISO/IEC IS 14882:2003
     </TD>
</TR>
<TR>
<TD ALIGN="RIGHT">
      Reply to:
     </TD><TD>
      &nbsp;William M. Miller
     </TD>
</TR>
<TR>
<TD></TD><TD>
      &nbsp;Edison Design Group, Inc.
     </TD>
</TR>
<TR>
<TD></TD><TD>
      &nbsp;<TT>wmm@edg.com</TT></TD>
</TR>
</TABLE>
<BR CLEAR="ALL">
<BR>
<CENTER>
<H2>



     C++ Standard Core Language
     
       Active Issues,
      



     Revision
     39</H2>
</CENTER>
<BR>
<P>
      This document contains the C++ core language issues on which the
      Committee (J16 + WG21) has not yet acted, that is, issues
      with status
      "<A HREF="#Ready Status">Ready</A>,"
      "<A HREF="#Review Status">Review</A>,"
      "<A HREF="#Drafting Status">Drafting</A>," and
      "<A HREF="#Open Status">Open</A>."
     </P>
<P>
    This document is part of a group of related documents that
    together describe the issues that have been raised regarding the
    C++ Standard.  The other documents in the group are:
   </P>
<UL>
<LI>
<A HREF="cwg_closed.html">Closed Issues List</A>, which contains
      the issues which the Committee has decided are not defects
      in the International Standard, including a brief rationale
      explaining the reason for the decision.
     </LI>
<LI>
<A HREF="cwg_defects.html">Defect Reports List</A>, which contains
      the issues that have been categorized by the Committee as Defect
      Reports, along with their proposed resolutions.
     </LI>
<LI>
<A HREF="cwg_toc.html">Table of Contents</A>, which contains a
     summary listing of all issues in numerical order.
    </LI>
<LI>
<A HREF="cwg_index.html">Index by Section</A>, which contains a
     summary listing of all issues arranged in the order of the
     sections of the Standard with which they deal most directly.
    </LI>
<LI>
<A HREF="cwg_status.html">Index by Status</A>, which contains a
     summary listing of all issues grouped by status.
    </LI>
</UL>
<P>The purpose of these documents is to record the disposition of issues
which have come before the Core Language Working Group of the ANSI
(J16) and ISO (WG21) C++ Standard Committee.</P>

<P>Issues represent potential defects in the ISO/IEC IS 14882:2003
document and corrected defects in the earlier ISO/IEC 14882:1998 document;
they are not necessarily formal ISO Defect Reports (DRs).
While some issues will eventually be elevated to DR status, others
will be disposed of in other ways.  (See <A HREF="#Issue Status">Issue
Status</A> below.)</P>



<P>The most current public version of this document can be found at
<A HREF="http://www.open-std.org/jtc1/sc22/wg21">http://www.open-std.org/jtc1/sc22/wg21</A>. 
Requests for further information about these documents should include
the document number, reference ISO/IEC 14882:2003, and be
submitted to the InterNational Committee for Information Technology Standards
(INCITS),
1250&nbsp;Eye&nbsp;Street&nbsp;NW, Suite 200, Washington,&nbsp;DC&nbsp;20005,
USA.</P>

<P>Information regarding how to obtain a copy of the C++ Standard,
join the Standard Committee, or submit an issue
can be found in the C++ FAQ at
<A HREF="http://www.jamesd.demon.co.uk/csc/faq.html">http://www.jamesd.demon.co.uk/csc/faq.html</A>.
Public discussion of the C++ Standard and related issues occurs on
newsgroup <A HREF="news:comp.std.c++">comp.std.c++</A>.</P>

<BR>
<H3>Revision History</H3>

<UL>

<LI>
<B>Revision 39, 2005-12-16:</B> Updated
<A HREF="
     cwg_active.html#488">issue 488</A> with additional discussion.
Added issues
<A HREF="
     cwg_active.html#538">538</A>,
<A HREF="
     cwg_active.html#539">539</A>,
<A HREF="
     cwg_active.html#540">540</A>,
<A HREF="
     cwg_active.html#541">541</A>,
<A HREF="
     cwg_active.html#542">542</A>,
<A HREF="
     cwg_active.html#543">543</A>,
<A HREF="
     cwg_active.html#544">544</A>,
<A HREF="
     cwg_active.html#545">545</A>,
<A HREF="
     cwg_active.html#546">546</A>,
<A HREF="
     cwg_active.html#547">547</A>,
<A HREF="
     cwg_active.html#548">548</A>,
<A HREF="
     cwg_active.html#549">549</A>,
<A HREF="
     cwg_active.html#550">550</A>, and
<A HREF="
     cwg_active.html#551">551</A>.
</LI>

<LI>
<B>Revision 38, 2005-10-22:</B> Reflected deliberations from the
Mont Tremblant (October, 2005) meeting.  Added isues
<A HREF="
     cwg_active.html#530">530</A>,
<A HREF="
     cwg_active.html#531">531</A>,
<A HREF="
     cwg_active.html#532">532</A>,
<A HREF="
     cwg_active.html#533">533</A>,
<A HREF="
     cwg_active.html#534">534</A>,
<A HREF="
     cwg_active.html#535">535</A>,
<A HREF="
     cwg_active.html#536">536</A>, and
<A HREF="
     cwg_active.html#537">537</A>.
</LI>

<LI>
<B>Revision 37, 2005-08-27:</B> Added issues
<A HREF="
     cwg_active.html#523">523</A>,
<A HREF="
     cwg_active.html#524">524</A>,
<A HREF="
     cwg_active.html#525">525</A>,
<A HREF="
     cwg_active.html#526">526</A>,
<A HREF="
     cwg_active.html#527">527</A>,
<A HREF="
     cwg_active.html#528">528</A>, and
<A HREF="
     cwg_active.html#529">529</A>.
</LI>

<LI>
<B>Revision 36, 2005-06-27:</B> Reopened <A HREF="
     cwg_active.html#484">issue 484</A> for additional discussion.
Added issues
<A HREF="
     cwg_active.html#517">517</A>,
<A HREF="
     cwg_active.html#518">518</A>,
<A HREF="
     cwg_active.html#519">519</A>,
<A HREF="
     cwg_active.html#520">520</A>,
<A HREF="
     cwg_active.html#521">521</A>, and
<A HREF="
     cwg_active.html#522">522</A>.
</LI>

<LI>
<B>Revision 35, 2005-05-01:</B> Reflected deliberations from
the Lillehammer (April, 2005) meeting.  Updated issues
<A HREF="
     cwg_active.html#189">189</A> and <A HREF="
     cwg_active.html#459">459</A> with additional
discussion.  Added new issues
<A HREF="
     cwg_closed.html#504">504</A>,
<A HREF="
     cwg_active.html#505">505</A>,
<A HREF="
     cwg_active.html#506">506</A>,
<A HREF="
     cwg_active.html#507">507</A>,
<A HREF="
     cwg_active.html#508">508</A>,
<A HREF="
     cwg_active.html#509">509</A>,
<A HREF="
     cwg_active.html#510">510</A>,
<A HREF="
     cwg_active.html#511">511</A>,
<A HREF="
     cwg_active.html#512">512</A>,
<A HREF="
     cwg_active.html#513">513</A>,
<A HREF="
     cwg_active.html#514">514</A>,
<A HREF="
     cwg_active.html#515">515</A>, and
<A HREF="
     cwg_active.html#516">516</A>.
</LI>

<LI>
<B>Revision 34: 2005-03-06:</B> Closed <A HREF="
     cwg_closed.html#471">issue 471</A> as NAD; updated issues
<A HREF="
     cwg_active.html#58">58</A>,
<A HREF="
     cwg_active.html#232">232</A>,
<A HREF="
     cwg_active.html#339">339</A>,
<A HREF="
     cwg_active.html#407">407</A>, and
<A HREF="
     cwg_active.html#494">494</A>
with additional discussion; and added new issues
<A HREF="
     cwg_active.html#498">498</A>,
<A HREF="
     cwg_active.html#499">499</A>,
<A HREF="
     cwg_active.html#500">500</A>,
<A HREF="
     cwg_closed.html#501">501</A>,
<A HREF="
     cwg_active.html#502">502</A>, and
<A HREF="
     cwg_active.html#503">503</A>.
</LI>

<LI>
<B>Revision 33: 2005-01-14:</B> Updated <A HREF="
     cwg_active.html#36">issue 36</A> with additional discussion.  Added new
issues
<A HREF="
     cwg_active.html#485">485</A>,
<A HREF="
     cwg_active.html#486">486</A>,
<A HREF="
     cwg_closed.html#487">487</A>,
<A HREF="
     cwg_active.html#488">488</A>,
<A HREF="
     cwg_closed.html#489">489</A>,
<A HREF="
     cwg_active.html#490">490</A>,
<A HREF="
     cwg_active.html#491">491</A>,
<A HREF="
     cwg_active.html#492">492</A>,
<A HREF="
     cwg_active.html#493">493</A>,
<A HREF="
     cwg_active.html#494">494</A>,
<A HREF="
     cwg_active.html#495">495</A>,
<A HREF="
     cwg_active.html#496">496</A>, and
<A HREF="
     cwg_defects.html#497">497</A>.
</LI>

<LI>
<B>Revision 32: 2004-11-07:</B> Reflected deliberations from
the Redmond (October, 2004) meeting.  Added new issues
<A HREF="
     cwg_active.html#475">475</A>,
<A HREF="
     cwg_active.html#476">476</A>,
<A HREF="
     cwg_active.html#477">477</A>,
<A HREF="
     cwg_closed.html#478">478</A>,
<A HREF="
     cwg_active.html#479">479</A>,
<A HREF="
     cwg_active.html#480">480</A>,
<A HREF="
     cwg_active.html#481">481</A>,
<A HREF="
     cwg_active.html#482">482</A>,
<A HREF="
     cwg_active.html#483">483</A>, and
<A HREF="
     cwg_active.html#484">484</A>.
</LI>

<LI>
<B>Revision 31: 2004-09-10:</B> Updated <A HREF="
     cwg_active.html#268">issue 268</A> with comments from WG14; added comments and changed
the status of <A HREF="
     cwg_defects.html#451">issue 451</A> back to
&ldquo;open&rdquo;; added discussion to issues
<A HREF="
     cwg_closed.html#334">334</A>,
<A HREF="
     cwg_active.html#341">341</A>,
<A HREF="
     cwg_defects.html#385">385</A>,
<A HREF="
     cwg_active.html#399">399</A>, and
<A HREF="
     cwg_active.html#430">430</A>;
and added new issues
<A HREF="
     cwg_defects.html#470">470</A>,
<A HREF="
     cwg_closed.html#471">471</A>,
<A HREF="
     cwg_active.html#472">472</A>,
<A HREF="
     cwg_active.html#473">473</A>, and
<A HREF="
     cwg_defects.html#474">474</A>.
</LI>

<LI>
<B>Revision 30: 2004-04-09:</B> Reflected deliberations from the
Sydney (March, 2004) meeting.  Added issues 461-469, updated issues
<A HREF="
     cwg_defects.html#39">39</A>,
<A HREF="
     cwg_active.html#86">86</A>,
<A HREF="
     cwg_active.html#257">257</A>,
<A HREF="
     cwg_defects.html#291">291</A>,
<A HREF="
     cwg_defects.html#391">391</A>,
<A HREF="
     cwg_defects.html#389">389</A>,
<A HREF="
     cwg_closed.html#435">435</A>,
<A HREF="
     cwg_defects.html#436">436</A>,
<A HREF="
     cwg_defects.html#437">437</A>,
<A HREF="
     cwg_defects.html#439">439</A>,
<A HREF="
     cwg_defects.html#441">441</A>,
<A HREF="
     cwg_defects.html#442">442</A>,
<A HREF="
     cwg_defects.html#446">446</A>,
<A HREF="
     cwg_defects.html#450">450</A>,
<A HREF="
     cwg_active.html#453">453</A>,
and
<A HREF="
     cwg_active.html#458">458</A>.
</LI>

<LI>
<B>Revision 29: 2004-02-13:</B> Added issues 441-460, updated issues
<A HREF="
     cwg_defects.html#39">39</A>,
<A HREF="
     cwg_defects.html#291">291</A>,
<A HREF="
     cwg_defects.html#306">306</A>,
<A HREF="
     cwg_defects.html#319">319</A>,
<A HREF="
     cwg_defects.html#389">389</A>,
<A HREF="
     cwg_defects.html#394">394</A>,
<A HREF="
     cwg_active.html#413">413</A>,
and
<A HREF="
     cwg_defects.html#417">417</A>.
</LI>

<LI>
<B>Revision 28: 2003-11-15:</B> Reflected deliberations from the
Kona (October, 2003) meeting.  Added issues 435-438.
</LI>

<LI>
<B>Revision 27: 2003-09-19:</B> Added new issues 412-434, updated
<A HREF="
     cwg_defects.html#54">issues 54</A>,
<A HREF="
     cwg_active.html#301">301</A>,
<A HREF="
     cwg_active.html#372">372</A>,
<A HREF="
     cwg_defects.html#382">382</A>,
<A HREF="
     cwg_defects.html#391">391</A>, and
<A HREF="
     cwg_active.html#399">399</A>.
</LI>

<LI>
<B>Revision 26: 2003-04-25:</B>  Reflected deliberations from
the Oxford (April, 2003) meeting.  Added new issues 402-411.
</LI>

<LI>
<B>Revision 25: 2003-03-03:</B> Added new issues 390-401, updated
<A HREF="
     cwg_defects.html#214">issue 214</A>.
</LI>
<LI>
<B>Revision 24: 2002-11-08:</B> Reflected deliberations from the
Santa Cruz (October, 2002) meeting.  Added new issues 379-389.
</LI>

<LI>
<B>Revision 23: 2002-09-10:</B> Added new issues 355-378, updated
<A HREF="
     cwg_defects.html#298">issue 298</A> and <A HREF="
     cwg_defects.html#214">issue 214</A>.
</LI>
<LI>
<B>Revision 22: 2002-05-10:</B> Reflected deliberations from the
Curacao (April, 2002) meeting.  Added issues 342-354.
</LI>
<LI>
<B>Revision 21: 2002-03-11:</B> Added new issues 314-341, updated issues
<A HREF="
     cwg_closed.html#132">132</A>,
<A HREF="
     cwg_defects.html#214">214</A>,
<A HREF="
     cwg_defects.html#244">244</A>,
<A HREF="
     cwg_defects.html#245">245</A>,
<A HREF="
     cwg_defects.html#254">254</A>,
<A HREF="
     cwg_active.html#255">255</A>,
<A HREF="
     cwg_defects.html#283">283</A>.
</LI>

<LI>
<B>Revision 20: 2001-11-09:</B> Reflected deliberations from the
Redmond (October, 2001) meeting.  Added issue <A HREF="
     cwg_closed.html#313">313</A>.
</LI>

<LI>
<B>Revision 19: 2001-09-12:</B> Added new issues 289-308, updated
issues <A HREF="
     cwg_active.html#222">222</A>, <A HREF="
     cwg_defects.html#261">261</A>,
<A HREF="
     cwg_defects.html#270">270</A>.
</LI>

<LI>
<B>Revision 18: 2001-05-19:</B> Reflected deliberations from the
Copenhagen (April, 2001) meeting.  Added new issues 282-288.
</LI>

<LI>
<B>Revision 17: 2001-04-29:</B> Added new issues 276-81.
</LI>

<LI>
<B>Revision 16: 2001-03-27:</B> Updated <A HREF="
     cwg_active.html#138">issue 138</A> to discuss the interaction of <I>using-declaration</I>s
and "forward declarations."  Noted a problem with the proposed
resolution of <A HREF="
     cwg_defects.html#139">issue 139</A>.  Added some
new discussion to  <A HREF="
     cwg_defects.html#115">issue 115</A>.  Added
proposed resolution for <A HREF="
     cwg_defects.html#160">issue 160</A>.  Updated
address of C++ FAQ.  Added new issues 265-275.
</LI>

<LI>
<B>Revision 15: 2000-11-18:</B> Reflected deliberations from the
Toronto (October, 2000) meeting; moved the discussion of empty and
fully-initialized const objects from <A HREF="
     cwg_defects.html#78">issue 78</A> into <A HREF="
     cwg_active.html#253">new issue 253</A>;
added new issues 254-264.
</LI>

<LI>
<B>Revision 14: 2000-10-21:</B> Added issues 246-252; added an extra
question to <A HREF="
     cwg_defects.html#221">issue 221</A> and changed its
status back to "review."
</LI>

<LI>
<B>Revision 13: 2000-09-16:</B> Added issues 229-245; changed status
of <A HREF="
     cwg_defects.html#106">issue 106</A> to "review" because of problem
detected in proposal; added wording for issues <A HREF="
     cwg_defects.html#87">87</A> and <A HREF="
     cwg_defects.html#216">216</A> and moved to "review"
status; updated discussion of issues
<A HREF="
     cwg_defects.html#5">5</A>,
<A HREF="
     cwg_defects.html#78">78</A>,
<A HREF="
     cwg_defects.html#198">198</A>,
<A HREF="
     cwg_active.html#203">203</A>, and
<A HREF="
     cwg_active.html#222">222</A>.
</LI>

<LI>
<B>Revision 12: 2000-05-21:</B> Reflected deliberations from the
Tokyo (April, 2000) meeting; added new issues 222-228.
</LI>

<LI>
<B>Revision 11, 2000-04-13:</B> Added proposed wording and moved
issues
<A HREF="
     cwg_defects.html#62">62</A>,
<A HREF="
     cwg_defects.html#73">73</A>,
<A HREF="
     cwg_defects.html#89">89</A>,
<A HREF="
     cwg_defects.html#94">94</A>,
<A HREF="
     cwg_defects.html#106">106</A>,
<A HREF="
     cwg_defects.html#121">121</A>,
<A HREF="
     cwg_defects.html#134">134</A>,
<A HREF="
     cwg_defects.html#142">142</A>, and
<A HREF="
     cwg_defects.html#145">145</A>
to "review" status.  Moved <A HREF="
     cwg_closed.html#13">issue 13</A>
from "extension" to "open" status because of recent additional
discussion.
Added new issues 217-221.
</LI>

<LI>
<B>Revision 10, 2000-03-21:</B> Split the issues list and indices into
multiple documents.  Added further discussion to issues
<A HREF="
     cwg_defects.html#84">84</A> and <A HREF="
     cwg_defects.html#87">87</A>.
Added proposed wording and moved issues
<A HREF="
     cwg_defects.html#1">1</A>,
<A HREF="
     cwg_defects.html#69">69</A>,
<A HREF="
     cwg_defects.html#85">85</A>,
<A HREF="
     cwg_defects.html#98">98</A>,
<A HREF="
     cwg_defects.html#105">105</A>,
<A HREF="
     cwg_defects.html#113">113</A>,
<A HREF="
     cwg_closed.html#132">132</A>, and
<A HREF="
     cwg_defects.html#178">178</A>
to "review" status.
Added new issues 207-216.
</LI>

<LI>
<B>Revision 9, 2000-02-23:</B> Incorporated decisions from the
October, 1999 meeting of the Committee;

added issues 174 through 206.</LI>

<LI>
<B>Revision 8, 1999-10-13:</B> Minor editorial changes to issues
<A HREF="
     cwg_defects.html#90">90</A> and
<A HREF="
     cwg_defects.html#24">24</A>; updated issue
<A HREF="
     cwg_defects.html#89">89</A> to include a related question;
added issues
<A HREF="
     cwg_closed.html#169">169</A>,
<A HREF="
     cwg_active.html#170">170</A>,
<A HREF="
     cwg_defects.html#171">171</A>,
<A HREF="
     cwg_defects.html#172">172</A>, and
<A HREF="
     cwg_defects.html#173">173</A>.</LI>

<LI>
<B>Revision 7, 1999-09-14:</B> Removed unneeded change to
14.7.3&nbsp;



 <A HREF="template.html#temp.expl.spec">temp.expl.spec</A> paragraph 9 from
<A HREF="
     cwg_defects.html#24">issue 24</A>; changed
<A HREF="
     cwg_defects.html#85">issue 85</A> to refer to
3.4.4&nbsp;



 <A HREF="basic.html#basic.lookup.elab">basic.lookup.elab</A>;
added issues
<A HREF="
     cwg_defects.html#122">122</A>,
<A HREF="
     cwg_defects.html#123">123</A>,
<A HREF="
     cwg_defects.html#124">124</A>,
<A HREF="
     cwg_defects.html#125">125</A>,
<A HREF="
     cwg_defects.html#126">126</A>,
<A HREF="
     cwg_defects.html#127">127</A>,
<A HREF="
     cwg_defects.html#128">128</A>,
<A HREF="
     cwg_active.html#129">129</A>,
<A HREF="
     cwg_closed.html#130">130</A>,
<A HREF="
     cwg_defects.html#131">131</A>,
<A HREF="
     cwg_closed.html#132">132</A>,
<A HREF="
     cwg_closed.html#133">133</A>,
<A HREF="
     cwg_defects.html#134">134</A>,
<A HREF="
     cwg_defects.html#135">135</A>,
<A HREF="
     cwg_defects.html#136">136</A>,
<A HREF="
     cwg_defects.html#137">137</A>,
<A HREF="
     cwg_active.html#138">138</A>,
<A HREF="
     cwg_defects.html#139">139</A>,
<A HREF="
     cwg_defects.html#140">140</A>,
<A HREF="
     cwg_active.html#141">141</A>,
<A HREF="
     cwg_defects.html#142">142</A>,
<A HREF="
     cwg_defects.html#143">143</A>,
<A HREF="
     cwg_active.html#144">144</A>,
<A HREF="
     cwg_defects.html#145">145</A>,
<A HREF="
     cwg_active.html#146">146</A>,
<A HREF="
     cwg_defects.html#147">147</A>,
<A HREF="
     cwg_defects.html#148">148</A>,
<A HREF="
     cwg_defects.html#149">149</A>,
<A HREF="
     cwg_closed.html#150">150</A>,
<A HREF="
     cwg_defects.html#151">151</A>,
<A HREF="
     cwg_defects.html#152">152</A>,
<A HREF="
     cwg_defects.html#153">153</A>,
<A HREF="
     cwg_closed.html#154">154</A>,
<A HREF="
     cwg_active.html#155">155</A>,
<A HREF="
     cwg_active.html#156">156</A>,
<A HREF="
     cwg_active.html#157">157</A>,
<A HREF="
     cwg_defects.html#158">158</A>,
<A HREF="
     cwg_defects.html#159">159</A>,
<A HREF="
     cwg_defects.html#160">160</A>,
<A HREF="
     cwg_defects.html#161">161</A>,
<A HREF="
     cwg_defects.html#162">162</A>,
<A HREF="
     cwg_defects.html#163">163</A>,
<A HREF="
     cwg_defects.html#164">164</A>,
<A HREF="
     cwg_closed.html#165">165</A>,
<A HREF="
     cwg_defects.html#166">166</A>,
<A HREF="
     cwg_closed.html#167">167</A>, and
<A HREF="
     cwg_closed.html#168">168</A>.</LI>

<LI>
<B>Revision 6, 1999-05-31:</B> Moved
<A HREF="
     cwg_closed.html#72">issue 72</A> to "dup" status; added
proposed wording and moved <A HREF="
     cwg_defects.html#90">issue 90</A>
to "review" status; updated <A HREF="
     cwg_defects.html#98">issue 98</A>
with additional question; added issues
<A HREF="
     cwg_active.html#110">110</A>,
<A HREF="
     cwg_active.html#111">111</A>,
<A HREF="
     cwg_defects.html#112">112</A>,
<A HREF="
     cwg_defects.html#113">113</A>,
<A HREF="
     cwg_closed.html#114">114</A>,
<A HREF="
     cwg_defects.html#115">115</A>,
<A HREF="
     cwg_defects.html#116">116</A>,
<A HREF="
     cwg_closed.html#117">117</A>,
<A HREF="
     cwg_active.html#118">118</A>,
<A HREF="
     cwg_defects.html#119">119</A>,
<A HREF="
     cwg_defects.html#120">120</A>, and
<A HREF="
     cwg_defects.html#121">121</A>.</LI>

<LI>
<B>Revision 5, 1999-05-24:</B> Reordered issues by status; added revision
history; first public version.</LI>
</UL>

<A NAME="Issue Status"></A>
<H3>Issue status</H3>

<P>Issues progress through various statuses as the Core Language
Working Group and, ultimately, the full J16 and WG21 committees
deliberate and act.  For ease of reference, issues are grouped in these
documents by their status.  Issues have one of the following statuses:</P>

<P>
<B>Open:</B> The issue is new or the working group has not yet
formed an opinion on the issue.  If a <I>Suggested Resolution</I> is
given, it reflects the opinion of the issue's submitter, not
necessarily that of the working group or the Committee as a whole.</P>

<P>
<B>Drafting:</B> Informal consensus has been reached in the
working group and is described in rough terms in a <I>Tentative
Resolution</I>, although precise wording for the change is not yet
available.</P>

<P>
<B>Review:</B> Exact wording of a <I>Proposed Resolution</I> is now
available for an issue on which the working group previously reached
informal consensus.</P>

<P>
<B>Ready:</B> The working group has reached consensus that the
issue is a defect in the Standard, the <I>Proposed Resolution</I> is
correct, and the issue is ready to forward to the full Committee for
ratification as a proposed defect report.</P>

<P>
<B>DR:</B> The full Committee has approved the item as a proposed
defect report.  The <I>Proposed Resolution</I> in an issue with this
status reflects the best judgment of the Committee at this time
regarding the action that will be taken to remedy the defect; however,
the current wording of the Standard remains in effect until such time
as a <I>Technical Corrigendum</I> or a revision of the Standard is
issued by ISO.</P>

<P>
<B>TC1:</B> A DR issue included in Technical Corrigendum 1.
TC1 is a revision of the Standard issued in 2003.</P>

<P>
<B>WP:</B> A DR issue whose resolution is reflected in
the current Working Paper.  The Working Paper is a draft for a
future version of the Standard.</P>

<P>
<B>Dup:</B> The issue is identical to or a subset of another issue,
identified in a <I>Rationale</I> statement.</P>

<P>
<B>NAD:</B> The working group has reached consensus that the issue
is not a defect in the Standard. A <I>Rationale</I> statement
describes the working group's reasoning.</P>

<P>
<B>Extension:</B> The working group has reached consensus that the
issue is not a defect in the Standard but is a request for an
extension to the language.  The working group
expresses no opinion on the merits of an issue with this status;
however, the issue will be maintained on the list for possible future
consideration as an extension proposal.</P>
<HR>
<A NAME="Ready Status"></A>
<H3>Issues with "Ready" Status</H3>
<HR>
<A NAME="513"></A>
<H4>513.
  
Non-class &ldquo;most-derived&rdquo; objects
</H4>
<B>Section: </B>1.8&nbsp;



 <A HREF="intro.html#intro.object">intro.object</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>ready
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Marc Schoolderman
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>20 Mar 2005<BR>


<P>The standard uses &ldquo;most derived object&rdquo; in some places
(for example, 1.3.3&nbsp;



 <A HREF="intro.html#defns.dynamic.type">defns.dynamic.type</A>, 5.3.5&nbsp;



 <A HREF="expr.html#expr.delete">expr.delete</A>) to refer to objects of both class and non-class
type. However, 1.8&nbsp;



 <A HREF="intro.html#intro.object">intro.object</A> only formally defines it for
objects of class type.</P>

<P>Possible fix: Change the wording in 1.8&nbsp;



 <A HREF="intro.html#intro.object">intro.object</A>
paragraph 4 from</P>

<BLOCKQUOTE>
an object of a most derived class type is called a most derived object
</BLOCKQUOTE>

<P>to</P>

<BLOCKQUOTE>
an object of a most derived class type, or of non-class type, is called
a most derived object
</BLOCKQUOTE>

<P>
<B>Proposed resolution (October, 2005):</B>
</P>

<P>Add the indicated words to 1.8&nbsp;



 <A HREF="intro.html#intro.object">intro.object</A> paragraph 4:</P>

<BLOCKQUOTE>

If a complete object, a data member (9.2&nbsp;



 <A HREF="class.html#class.mem">class.mem</A>), or
an array element is of class type, its type is considered the <I>most
derived</I> class, to distinguish it from the class type of any base
class subobject; an object of a most derived class type<B>, or of a
non-class type,</B> is called a <I>most derived object</I>.

</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="519"></A>
<H4>519.
  
Null pointer preservation in <TT>void*</TT> conversions
</H4>
<B>Section: </B>4.10&nbsp;



 <A HREF="conv.html#conv.ptr">conv.ptr</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>ready
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>comp.std.c++
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>19 May 2005<BR>


<P>The C standard says in 6.3.2.3, paragraph 4:</P>

<BLOCKQUOTE>

Conversion of a null pointer to another pointer type yields a null
pointer of that type. Any two null pointers shall compare equal.

</BLOCKQUOTE>

<P>C++ appears to be incompatible with the first sentence in only two
areas:</P>

<PRE>
    A *a = 0;
    void *v = a;
</PRE>

<P>C++ (4.10&nbsp;



 <A HREF="conv.html#conv.ptr">conv.ptr</A> paragraph 2) says nothing about the
value of <TT>v</TT>.</P>

<PRE>
    void *v = 0;
    A *b = (A*)v; // aka static_cast&lt;A*&gt;(v)
</PRE>

<P>C++ (5.2.9&nbsp;



 <A HREF="expr.html#expr.static.cast">expr.static.cast</A> paragraph 10) says nothing about
the value of <TT>b</TT>.</P>

<P>
<U>Suggested changes</U>:</P>

<OL>

<LI>
<P>Add the following sentence to 4.10&nbsp;



 <A HREF="conv.html#conv.ptr">conv.ptr</A>
paragraph 2:</P>
</LI>

<BLOCKQUOTE>

The null pointer value is converted to the null pointer value of the
destination type.

</BLOCKQUOTE>

<LI>
<P>Add the following sentence to 5.2.9&nbsp;



 <A HREF="expr.html#expr.static.cast">expr.static.cast</A>
paragraph 10:</P>
</LI>

<BLOCKQUOTE>

The null pointer value (4.10&nbsp;



 <A HREF="conv.html#conv.ptr">conv.ptr</A>) is converted
to the null pointer value of the destination type.

</BLOCKQUOTE>

</OL>

<P>
<B>Proposed resolution (October, 2005):</B>
</P>

<OL>
<LI>
<P>Add the indicated words to 4.10&nbsp;



 <A HREF="conv.html#conv.ptr">conv.ptr</A>
paragraph 2:</P>
</LI>

<BLOCKQUOTE>

An rvalue of type &ldquo;pointer to <I>cv</I> <TT>T</TT>,&rdquo; where
<TT>T</TT> is an object type, can be converted to an rvalue of type &ldquo;pointer to
<I>cv</I> <TT>void</TT>&rdquo;. The result of converting a &ldquo;pointer to
<I>cv</I> <TT>T</TT>&rdquo; to a &ldquo;pointer
to <I>cv</I> <TT>void</TT>&rdquo; points to the start of the storage
location where the object of type <TT>T</TT> resides, as if the object
is a most derived object (1.8&nbsp;



 <A HREF="intro.html#intro.object">intro.object</A>) of
type <TT>T</TT> (that is, not a base class subobject). <B>The null
pointer value is converted to the null pointer value of the
destination type.</B>

</BLOCKQUOTE>

<LI>
<P>Add the indicated words to 5.2.9&nbsp;



 <A HREF="expr.html#expr.static.cast">expr.static.cast</A>
paragraph 11:</P>
</LI>

<BLOCKQUOTE>

An rvalue of type &ldquo;pointer to <I>cv1</I> <TT>void</TT>&rdquo;
can be converted to an rvalue of type &ldquo;pointer
to <I>cv2</I> <TT>T</TT>,&rdquo; where <TT>T</TT> is an object type
and <i>cv2</i> is the same cv-qualification as, or greater
cv-qualification than, <I>cv1</I>. <B>The null pointer value is
converted to the null pointer value of the destination type.</B> A
value of type pointer to object converted to &ldquo;pointer
to <I>cv</I> <TT>void</TT>&rdquo; and back, possibly with different
cv-qualification, shall have its original value...

</BLOCKQUOTE>

</OL>

<BR>
<BR>
<HR>
<A NAME="466"></A>
<H4>466.
  
cv-qualifiers on pseudo-destructor type
</H4>
<B>Section: </B>5.2.4&nbsp;



 <A HREF="expr.html#expr.pseudo">expr.pseudo</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>ready
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Mark Mitchell
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>18 Mar 2004<BR>


<P>5.2.4&nbsp;



 <A HREF="expr.html#expr.pseudo">expr.pseudo</A> paragraph 2 says both:
<BLOCKQUOTE>
  The type designated by the pseudo-destructor-name shall be the same
  as the object type.
</BLOCKQUOTE>
and also:
<BLOCKQUOTE>
  The cv-unqualified versions of the object type and of the type
  designated by the pseudo-destructor-name shall be the same type.
</BLOCKQUOTE>
Which is it?  "The same" or "the same up to cv-qualifiers"?  The
second sentence is more generous than the first.  Most compilers seem
to implement the less restrictive form, so I guess that's what I think
we should do.</P>

<P>See also issues <A HREF="
     cwg_active.html#305">305</A> and
<A HREF="
     cwg_active.html#399">399</A>.</P>

<P>
<B>Proposed resolution (October, 2005):</B>
</P>

<P>Change 5.2.4&nbsp;



 <A HREF="expr.html#expr.pseudo">expr.pseudo</A> paragraph 2 as follows:</P>

<BLOCKQUOTE>

The left-hand side of the dot operator shall be of scalar type. The
left-hand side of the arrow operator shall be of pointer to scalar
type. This scalar type is the object type. <S>The type designated by the
<I>pseudo-destructor-name</I> shall be the same as the object
type.</S> <B>The cv-unqualified versions of
the object type and of the type designated by the
<I>pseudo-destructor-name</I> shall be the same type.</B> Furthermore,
the two <I>type-name</I>s in a <I>pseudo-destructor-name</I> of the
form

<UL>
<TT>::</TT><I><SUB>opt</SUB> nested-name-specifier<SUB>opt</SUB> type-name </I><TT>::~</TT><I> type-name</I>
</UL>

shall designate the same scalar type. <S>The cv-unqualified versions of
the object type and of the type designated by the
<I>pseudo-destructor-name</I> shall be the same type.</S>

</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="492"></A>
<H4>492.
  
<TT>typeid</TT> constness inconsistent with example
</H4>
<B>Section: </B>5.2.8&nbsp;



 <A HREF="expr.html#expr.typeid">expr.typeid</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>ready
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Ron Natalie
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>15 Dec 2004<BR>


<P>There is an inconsistency between the normative text in
section 5.2.8&nbsp;



 <A HREF="expr.html#expr.typeid">expr.typeid</A> and
the example that follows.</P>

<P>Here is the relevant passage (starting with paragraph 4):</P>

<BLOCKQUOTE>

<P>
When <TT>typeid</TT> is applied to a <I>type-id</I>, the result
refers to a <TT>std::type_info</TT> object representing the type of the
<I>type-id</I>. If the type of the <I>type-id</I> is a reference
type, the result of the <TT>typeid</TT> expression refers to a
<TT>std::type_info</TT> object representing the referenced type.
</P>

<P>
The top-level cv-qualifiers of the lvalue expression or the
<I>type-id</I> that is the operand of <TT>typeid</TT> are always
ignored.
</P>

</BLOCKQUOTE>

<P>and the example:</P>

<PRE>
    typeid(D) == typeid(const D&amp;); // yields true
</PRE>

<P>
The second paragraph above says the &ldquo;<I>type-id</I> that is
the operand&rdquo;.  This would be <TT>const D&amp;</TT>.  In
this case, the <TT>const</TT> is not at the top-level (i.e.,
applied to the operand itself).
</P>

<P>By a strict reading, the above should yield <TT>false</TT>.</P>

<P>
My proposal is that the strict reading of the normative test is correct.
The example is wrong.   Different compilers here give different
answers.
</P>

<P>
<B>Proposed resolution (April, 2005):</B>
</P>

<P>Change the second sentence of 5.2.8&nbsp;



 <A HREF="expr.html#expr.typeid">expr.typeid</A>
paragraph 4 as follows:</P>

<BLOCKQUOTE>

If the type of the <I>type-id</I> is a reference <B>to a possibly
cv-qualified</B> type, the result of the <TT>typeid</TT> expression
refers to a <TT>std::type_info</TT> object representing the
<B>cv-unqualified</B> referenced type.

</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="463"></A>
<H4>463.
  
<TT>reinterpret_cast&lt;T*&gt;(0)</TT>
</H4>
<B>Section: </B>5.2.10&nbsp;



 <A HREF="expr.html#expr.reinterpret.cast">expr.reinterpret.cast</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>ready
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Gennaro Prota
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>14 Feb 2004<BR>


<P>Is <TT>reinterpret_cast&lt;T*&gt;(</TT><I>null_pointer_constant</I><TT>)</TT>
guaranteed to yield the
null pointer value of type T*?</P>

<P>I think a committee clarification is needed. Here's why:
5.2.10&nbsp;



 <A HREF="expr.html#expr.reinterpret.cast">expr.reinterpret.cast</A>
par. 8 talks of "null pointer value", not
"null pointer constant", so it would seem that
<PRE>
  reinterpret_cast&lt;T*&gt;(0)
</PRE>
is a normal int-&gt;T* conversion, with an implementation-defined result.</P>

<P>However a little note to
5.2.10&nbsp;



 <A HREF="expr.html#expr.reinterpret.cast">expr.reinterpret.cast</A> par. 5 says:
<BLOCKQUOTE>
   Converting an integral constant expression (5.19) with value zero
   always yields a null pointer (4.10), but converting other
   expressions that happen to have value zero need not yield a null
   pointer.
</BLOCKQUOTE>
Where is this supported in normative text? It seems that either the
footnote or paragraph 8 doesn't reflect the intent.</P>

<P>SUGGESTED RESOLUTION: I think it would be better to drop the footnote
#64 (and thus the special case for ICEs), for two reasons:</P>

<P>a) it's not normative anyway; so I doubt anyone is relying on the
guarantee it hints at, unless that guarantee is given elsewhere in a
normative part</P>

<P>b) users expect reinterpret_casts to be almost always implementation
dependent, so this special case is a surprise. After all, if one wants
a null pointer there's static_cast. And if one wants reinterpret_cast
semantics the special case requires doing some explicit cheat, such as
using a non-const variable as intermediary:</P>
<PRE>
   int v = 0;
   reinterpret_cast&lt;T*&gt;(v); // implementation defined

   reinterpret_cast&lt;T*&gt;(0); // null pointer value of type T*
   const int w = 0;
   reinterpret_cast&lt;T*&gt;(w); // null pointer value of type T*
</PRE>

<P>It seems that not only that's providing a duplicate functionality, but
also at the cost to hide what seems the more natural one.</P>

<P>
<B>Notes from October 2004 meeting:</B>
</P>

<P>This footnote was added in 1996, after the invention of
<TT>reinterpret_cast</TT>, so the presumption must be that it was
intentional.  At this time, however, the CWG feels that there is
no reason to require that <TT>reinterpret_cast&lt;T*&gt;(0)</TT>
produce a null pointer value as its result.</P>

<P>
<B>Proposed resolution (April, 2005):</B>
</P>

<OL>
<LI>
<P>Delete the footnote in 5.2.10&nbsp;



 <A HREF="expr.html#expr.reinterpret.cast">expr.reinterpret.cast</A>
paragraph 5 reading,</P>

<BLOCKQUOTE>

Converting an integral constant expression
(5.19&nbsp;



 <A HREF="expr.html#expr.const">expr.const</A>) with value zero always yields a null
pointer (4.10&nbsp;



 <A HREF="conv.html#conv.ptr">conv.ptr</A>), but converting other expressions
that happen to have value zero need not yield a null pointer.

</BLOCKQUOTE>

</LI>

<LI>
<P>Add the indicated note to 5.2.10&nbsp;



 <A HREF="expr.html#expr.reinterpret.cast">expr.reinterpret.cast</A> paragraph
8:</P>

<BLOCKQUOTE>

The null pointer value (4.10&nbsp;



 <A HREF="conv.html#conv.ptr">conv.ptr</A>) is converted to
the null pointer value of the destination type.  <B>[<I>Note:</I>
A null pointer constant, which has integral type, is not necessarily
converted to a null pointer value. &mdash;<I>end note</I>]</B>

</BLOCKQUOTE>
</LI>

</OL>

<BR>
<BR>
<HR>
<A NAME="530"></A>
<H4>530.
  
Nontype template arguments in constant expressions
</H4>
<B>Section: </B>5.19&nbsp;



 <A HREF="expr.html#expr.const">expr.const</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>ready
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Mark Mitchell
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>21 August 2005<BR>


<P>Consider:</P>

<PRE>
    template &lt;int* p&gt; struct S {
        static const int I = 3;
    };
    int i;
    int a[S&lt;&amp;i&gt;::I];
</PRE>

<P>Clearly this should be valid, but a pedantic reading of
5.19&nbsp;



 <A HREF="expr.html#expr.const">expr.const</A> would suggest that this is invalid because
&ldquo;<TT>&amp;i</TT>&rdquo; is not permitted in integral constant
expressions.</P>

<P>
<B>Proposed resolution (October, 2005):</B>
</P>

<P>Change the last sentence of 5.19&nbsp;



 <A HREF="expr.html#expr.const">expr.const</A> paragraph 1
as indicated:</P>

<BLOCKQUOTE>

In particular, except in <B>non-type <I>template-argument</I>s
or</B> <TT>sizeof</TT> expressions, functions, class objects,
pointers, or references shall not be used, and assignment, increment,
decrement, function-call, or comma operators shall not be used.

</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="518"></A>
<H4>518.
  
Trailing comma following <I>enumerator-list</I>
</H4>
<B>Section: </B>7.2&nbsp;



 <A HREF="dcl.html#dcl.enum">dcl.enum</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>ready
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Charles Bryant
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>10 May 2005<BR>


<P>The C language (since C99), and some C++ compilers, accept:</P>

<PRE>
    enum { FOO, };
</PRE>

<P>as syntactically valid. It would be useful</P>

<UL>

<LI>
<P>for machine generated code</P>
</LI>

<LI>
<P>for minimising changes when editing</P>
</LI>

<LI>
<P>to allow a distinction between the final item being intended as
an ordinary item or as a limit:</P>
</LI>

<PRE>
  enum { red, green, blue, num_colours };  // note no comma
  enum { fred, jim, sheila, };             // last is not special
</PRE>

</UL>

<P>This proposed change is to permit a trailing comma in enum by adding:</P>

<BLOCKQUOTE>

<TT>enum</TT> <I>identifier<SUB>opt</SUB></I> <TT>{</TT> <I>enumerator-list</I> <TT>,</TT> <TT>}</TT> 

</BLOCKQUOTE>

<P>as an alternative definition for the <I>enum-specifier</I> nonterminal
in <secton_ref>7.2&nbsp;



 <A HREF="dcl.html#dcl.enum">dcl.enum</A></secton_ref> paragraph 1.</P>

<P>
<B>Proposed resolution (October, 2005):</B>
</P>

<P>Change the grammar in 7.2&nbsp;



 <A HREF="dcl.html#dcl.enum">dcl.enum</A> paragraph 1 as
indicated:</P>

<BLOCKQUOTE>

<I>enum-specifier:</I>
<UL>
<TT>enum</TT> <I>identifier<SUB>opt</SUB> </I><TT>{</TT><I> enumerator-list<SUB>opt</SUB> </I><TT>}</TT>
</UL>
<B>
<UL>
<TT>enum</TT> <I>identifier<SUB>opt</SUB> </I><TT>{</TT><I> enumerator-list </I><TT>,</TT> <TT>}</TT>
</UL>
</B>

</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="86"></A>
<H4>86.
  
Lifetime of temporaries in query expressions
</H4>
<B>Section: </B>12.2&nbsp;



 <A HREF="special.html#class.temporary">class.temporary</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>ready
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Steve Adamczyk
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>Jan 1999<BR>



<P>[Voted into WP at October 2005 meeting.]</P>

<P>In
12.2&nbsp;



 <A HREF="special.html#class.temporary">class.temporary</A>

 paragraph 5,
should binding a reference to the result of a "<TT>?</TT>" operation, each
of whose branches is a temporary, extend both temporaries?</P>

<P>Here's an example:</P>
<PRE>
    const SFileName &amp;C = noDir ? SFileName("abc") : SFileName("bcd");
</PRE>
<P>Do the temporaries created by the <TT>SFileName</TT> conversions survive
the end of the full expression?</P>

<P>
<B>Notes from 10/00 meeting:</B>
</P>

<P>Other problematic examples include cases where the temporary
from one branch is a base class of the temporary from the other (i.e.,
where the implementation must remember which type of temporary must
be destroyed), or where one branch is a temporary and the other is
not.  Similar questions also apply to the comma operator.  The sense
of the core language working group was that implementations should
be required to support these kinds of code.</P>

<P>
<B>Notes from the March 2004 meeting:</B>
</P>

<P>We decided that the cleanest model is one in which any "?" operation
that returns a class rvalue always copies one of its operands to
a temporary and returns the temporary as the result of the operation.
(Note that this may involve slicing.)  An implementation would be
free to optimize this using the rules in 12.8&nbsp;



 <A HREF="special.html#class.copy">class.copy</A>
paragraph 15, and in fact we would expect that in many cases
compilers would do such optimizations.  For example, the compiler
could construct both rvalues in the above example into a
single temporary, and thus avoid a copy.</P>

<P>See also <A HREF="
     cwg_defects.html#446">issue 446</A>.</P>

<P>
<B>Proposed resolution (October, 2004):</B>
</P>

<P>This issue is resolved by the resolutions of <A HREF="
     cwg_defects.html#446">issue 446</A>.</P>

<P>
<B>Note (October, 2005):</B>
</P>

<P>This issue was overlooked when <A HREF="
     cwg_defects.html#446">issue 446</A>
was moved to &ldquo;ready&rdquo; status and was thus inadvertently
omitted from the list of issues accepted as Defect Reports at the
October, 2005 meeting.</P>

<BR>
<BR>
<HR>
<A NAME="464"></A>
<H4>464.
  
Wording nit on lifetime of temporaries to which references are bound
</H4>
<B>Section: </B>12.2&nbsp;



 <A HREF="special.html#class.temporary">class.temporary</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>ready
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Allan Odgaard
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>21 Feb 2004<BR>


<P>Section 12.2&nbsp;



 <A HREF="special.html#class.temporary">class.temporary</A> paragraph 5 ends with this "rule":</P>
<BLOCKSCOPE>
    [...] if obj2 is an object with static or automatic
    storage  duration created  after  the temporary  is
    created,  the temporary  shall  be destroyed  after
    obj2 is destroyed.
</BLOCKSCOPE>
<P>For the temporary to be destroyed after obj2 is destroyed, when obj2 has
static storage, I would say that the reference to the temporary should
also have static storage, but that is IMHO not clear from the
paragraph.</P>

<P>Example:</P>
<PRE>
    void f ()
    {
       const T1&amp; ref = T1();
       static T2 obj2;
       ...
    }
</PRE>
<P>Here the temporary would be destoyed <I>before</I> obj2, contrary to the
rule above.</P>

<P>
<U>Steve Adamczyk:</U> I agree there's a minor issue here.  I think
the clause quoted above meant for obj1 and obj2 to have the same storage
duration.  Replacing "obj2 is an object with static or automatic
storage duration" by "obj2 is an object with the same storage duration as
obj1" would, I believe, fix the problem.</P>

<P>
<B>Notes from October 2004 meeting:</B>
</P>

<P>We agreed with Steve Adamczyk's suggestion.</P>

<P>
<B>Proposed resolution (October, 2005):</B>
</P>

<P>Change 12.2&nbsp;



 <A HREF="special.html#class.temporary">class.temporary</A> paragraph 5 as follows:</P>

<BLOCKQUOTE>

... In addition, the destruction of temporaries bound to references
shall take into account the ordering of destruction of objects with
static or automatic storage duration (3.7.1&nbsp;



 <A HREF="basic.html#basic.stc.static">basic.stc.static</A>,
3.7.2&nbsp;



 <A HREF="basic.html#basic.stc.auto">basic.stc.auto</A>); that is, if <TT>obj1</TT> is an object
<S>with static or automatic storage duration</S> created before the
temporary is created <B>with the same storage duration as the
temporary</B>, the temporary shall be destroyed before <TT>obj1</TT>
is destroyed; if <TT>obj2</TT> is an object <S>with static or
automatic storage duration</S> created after the temporary is
created <B>with the same storage duration as the temporary</B>, the
temporary shall be destroyed after <TT>obj2</TT> is destroyed...

</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="510"></A>
<H4>510.
  
Default initialization of POD classes?
</H4>
<B>Section: </B>12.6&nbsp;



 <A HREF="special.html#class.init">class.init</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>ready
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Mike Miller
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>18 Mar 2005<BR>


<P>8.5&nbsp;



 <A HREF="decl.html#dcl.init">dcl.init</A> paragraph 10 makes it clear that
non-static POD class objects with no initializer are left uninitialized
and have an indeterminate initial value:</P>

<BLOCKQUOTE>

If no initializer is specified for an object, and the object is of
(possibly cv-qualified) non-POD class type (or array thereof), the
object shall be default-initialized; if the object is of
const-qualified type, the underlying class type shall have a
user-declared default constructor. Otherwise, if no initializer is
specified for a non-static object, the object and its subobjects, if
any, have an indeterminate initial value; if the object or any of
its subobjects are of const-qualified type, the program is ill-formed.

</BLOCKQUOTE>

<P>12.6&nbsp;



 <A HREF="special.html#class.init">class.init</A> paragraph 1, however, implies that all
class objects without initializers, whether POD or not, are
default-initialized:</P>

<BLOCKQUOTE>

When no initializer is specified for an object of (possibly
cv-qualified) class type (or array thereof), or the initializer has
the form <TT>()</TT>, the object is initialized as specified in
8.5&nbsp;



 <A HREF="decl.html#dcl.init">dcl.init</A>. The object is default-initialized if there
is no initializer, or value-initialized if the initializer
is <TT>()</TT>.

</BLOCKQUOTE>

<P>
<B>Proposed resolution (October, 2005):</B>
</P>

<P>Remove the indicated words from 12.6&nbsp;



 <A HREF="special.html#class.init">class.init</A> paragraph 1:</P>

<BLOCKQUOTE>

When no initializer is specified for an object of (possibly
cv-qualified) class type (or array thereof), or the initializer has
the form <TT>()</TT>, the object is initialized as specified in
8.5&nbsp;



 <A HREF="decl.html#dcl.init">dcl.init</A>. <S>The object is default-initialized if
there is no initializer, or value-initialized if the initializer
is <TT>()</TT>.</S>

</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="420"></A>
<H4>420.
  
postfixexpression-&gt;scalar_type_dtor() inconsistent
</H4>
<B>Section: </B>13.5.6&nbsp;



 <A HREF="over.html#over.ref">over.ref</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>ready
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Markus Mauhart
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>8 June 2003<BR>


<P>Lets start with the proposed solution.
In 13.5.6&nbsp;



 <A HREF="over.html#over.ref">over.ref</A>, replace line ...
<BLOCKQUOTE>
<I>postfix-expression</I> <TT>-&gt;</TT> <I>id-expression</I>
</BLOCKQUOTE>
.... with the lines ...
<BLOCKQUOTE>
<I>postfix-expression</I> <TT>-&gt;</TT> <I>template<SUB>opt</SUB> id-expression</I>
<BR>
<I>postfix-expression</I> <TT>-&gt;</TT> <I>pseudo-destructor-name</I>
</BLOCKQUOTE>
(This then is a copy of the two lines in 5.2&nbsp;



 <A HREF="expr.html#expr.post">expr.post</A>
covering "-&gt;dtor")</P>
<P>Alternatively remove the sentence "It implements class member
access using -&gt;" and the syntax line following.</P>

<P>Reasons:</P>

<P>Currently stdc++ is inconsistent when handling expressions of
the form "postfixexpression-&gt;scalar_type_dtor()":
If "postfixexpression" is a pointer to the scalar type, it is OK,
but if "postfixexpression" refers to any smart pointer class
(e.g. iterator or allocator::pointer) with class specific
CLASS::operator-&gt;() returning pointer to the scalar type, then
it is ill-formed; so while c++98 does allow CLASS::operator-&gt;()
returning pointer to scalar type, c++98 prohibits any '-&gt;'-expression
involving this overloaded operator function.</P>

<P>Not only is this behaviour inconsistent, but also when
comparing the corresponding chapters of c++pl2 and stdc++98
it looks like an oversight and unintended result.
Mapping between stdc++98 and c++pl2:
<BLOCKQUOTE>
  c++pl2.r.5.2 -&gt; 5.2 [expr.post]<BR>
  c++pl2.r.5.2.4 -&gt; 5.2.4 [expr.pseudo] + 5.2.5 [expr.ref]<BR>
  c++pl2.r.13.4 -&gt; 13.3.1.2 [over.match.oper]<BR>
  c++pl2.r.13.4.6 -&gt; 13.5.6 [over.ref]
</BLOCKQUOTE>
For the single line of c++pl2.r.5.2 covering "-&gt;dtor",
5.2 [expr.post] has two lines.
Analogously c++pl2.r.5.2.4 has been doubled to 5.2.4 [expr.pseudo]
and 5.2.5 [expr.ref].
From 13.5.6 [over.ref], the sentence forbiding CLASS::operator-&gt;()
returning pointer to scalar type has been removed.
Only the single line of c++pl2.r.13.4.6 (&lt;-&gt; c++pl2.r.5.2's
single line) has not gotten its 2nd line when converted
into 13.5.6 [over.ref].</P>

<P>Additionally GCC32 does is right (but against 13.5.6 [over.ref]).</P>

<P>AFAICS this would not break old code except compilers like VC7x
and Comeau4301.</P>

<P>It does not add new functionality, cause any expression
class_type-&gt;scalar_type_dtor() even today can be substituted
through (*class_type).scalar_type_dtor().</P>

<P>Without this fix, template functions like
some_allocator&lt;T&gt;::destroy(p)
must use "(*p).~T()" or "(*p).T::~T()" when calling the destructor,
otherwise the simpler versions "p-&gt;~T()" or "p-&gt;T::~T()"
could be used.</P>

<P>Sample code, compiled with GCC32, VC7[1] and Comeau4301:</P>
<PRE>
struct A {};//any class

template &lt;class T&gt;
struct PTR
    {
    T&amp; operator*  () const;
    T* operator-&gt; () const;
    };

template &lt;class T&gt;
void f ()
    {
        {
        T*  p               ;
        p = new T           ;
        (*p).T::~T()        ;//OK
        p = new T           ;
        (*p).~T()           ;//OK
        p = new T           ;
        p-&gt;T::~T()          ;//OK
        p = new T           ;
        p-&gt;~T()             ;//OK
        }

        {
        PTR&lt;T&gt; p = PTR&lt;T&gt;() ;
        (*p).T::~T()        ;//OK
        (*p).~T()           ;//OK
        p.operator-&gt;()      ;//OK !!!
        p-&gt;T::~T()          ;//GCC32: OK; VC7x,Com4301: OK for A; ERROR w/ int
        p-&gt;~T()             ;//GCC32: OK; VC7x,Com4301: OK for A; ERROR w/ int
        }
    }

void test ()
    {
    f &lt;A&gt;  ();
    f &lt;int&gt;();
    }
</PRE>

<P>
<B>Proposed resolution (April, 2005):</B>
</P>

<P>Change 13.5.6&nbsp;



 <A HREF="over.html#over.ref">over.ref</A> paragraph 1 as indicated:</P>

<BLOCKQUOTE>

<P>
<TT>operator-&gt;</TT> shall be a non-static member function taking
no parameters. It implements <B>the</B> class member
access <S>using</S> <B>syntax that uses</B> <TT>-&gt;</TT>
</P>

<UL>
<I>postfix-expression</I> <TT>-&gt;</TT> <B><TT>template</TT><SUB><I><SMALL>opt</SMALL></I></SUB></B> <I>id-expression</I>
<BR>
<B><I>postfix-expression</I> <TT>-&gt;</TT> <I>pseudo-destructor-name</I></B>
</UL>

<P>An expression <TT>x-&gt;m</TT> is interpreted
as <TT>(x.operator-&gt;())-&gt;m</TT> for a class object <TT>x</TT> of
type <TT>T</TT> if <TT>T::operator-&gt;()</TT> exists and if the
operator is selected as the best match function by the overload
resolution mechanism (13.3&nbsp;



 <A HREF="over.html#over.match">over.match</A>).</P>

</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="525"></A>
<H4>525.
  
Missing <TT>*</TT> in example
</H4>
<B>Section: </B>14.7.1&nbsp;



 <A HREF="template.html#temp.inst">temp.inst</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>ready
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Mike Miller
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>25 July 2005<BR>


<P>The example in 14.7.1&nbsp;



 <A HREF="template.html#temp.inst">temp.inst</A> paragraph 4 has a
typographical error: the third parameter of function <TT>g</TT>
should be <TT>D&lt;double&gt;* ppp</TT>, but it is missing the
<TT>*</TT>:</P>

<PRE>
  template &lt;class T&gt; class B { /* ... */ };
  template &lt;class T&gt; class D : public B&lt;T&gt; { /* ... */ };
  void f(void*);
  void f(B&lt;int &gt;*);

  void g(D&lt;int&gt;* p, D&lt;char&gt;* pp, D&lt;double&gt; ppp)
  {
    f(p);             //<SPAN STYLE="font-family:Times"><I> instantiation of </I><TT>D&lt;int&gt;</TT><I> required: call </I><TT>f(B&lt;int&gt;*)</TT></SPAN>

    B&lt;char&gt;* q = pp;  //<SPAN STYLE="font-family:Times"><I> instantiation of </I><TT>D&lt;char&gt;</TT><I> required:</I></SPAN>
                      //<SPAN STYLE="font-family:Times"><I> convert </I><TT>D&lt;char&gt;*</TT><I> to </I><TT>B&lt;char&gt;*</TT></SPAN>
    delete ppp;       //<SPAN STYLE="font-family:Times"><I> instantiation of </I><TT>D&lt;double&gt;</TT><I> required</I></SPAN>
  }
</PRE>

<P>
<B>Proposed resolution (October, 2005):</B>
</P>

<P>As suggested.</P>

<BR>
<BR>
<HR>
<A NAME="486"></A>
<H4>486.
  
Invalid return types and template argument deduction
</H4>
<B>Section: </B>14.8.2&nbsp;



 <A HREF="template.html#temp.deduct">temp.deduct</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>ready
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>John Spicer
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>16 Nov 2004<BR>


<P>According to 14.8.2&nbsp;



 <A HREF="template.html#temp.deduct">temp.deduct</A> paragraph 2,</P>

<BLOCKQUOTE>

If a substitution in a template parameter or in the function type
of the function template results in an invalid type, type
deduction fails.

</BLOCKQUOTE>

<P>That would seem to apply to cases like the following:</P>

<PRE>
    template &lt;class T&gt; T f(T&amp;){}
    void f(const int*){}
    int main() {
      int a[5];
      f(a);
    }
</PRE>

<P>Here, the return type of <TT>f</TT> is deduced as
<TT>int[5]</TT>, which is invalid according to 8.3.5&nbsp;



 <A HREF="decl.html#dcl.fct">dcl.fct</A> paragraph 6.  The outcome of this example, then,
should presumably be that type deduction fails and overload
resolution selects the non-template function.  However, the list
of reasons in 14.8.2&nbsp;



 <A HREF="template.html#temp.deduct">temp.deduct</A> for which type
deduction can fail does not include function and array types as a
function return type.  Those cases should be added to the
list.</P>

<P>
<B>Proposed resolution (October, 2005):</B>
</P>

<P>Change the last sub-bullet of 14.8.2&nbsp;



 <A HREF="template.html#temp.deduct">temp.deduct</A>
paragraph 2 as indicated:</P>

<UL>
<LI>
<P>Attempting to create a function type in which a parameter
has a type of <TT>void</TT><B>, or in which the return type is a
function type or array type</B>.</P>
</LI>
</UL>

<BR>
<BR>
<HR>
<A NAME="488"></A>
<H4>488.
  
Local types, overload resolution, and template argument deduction
</H4>
<B>Section: </B>14.8.2&nbsp;



 <A HREF="template.html#temp.deduct">temp.deduct</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>ready
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Mark Mitchell
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>24 Nov 2004<BR>


<P>It is not clear how to handle the following example:</P>

<PRE>
    struct S {
        template &lt;typename T&gt; S(const T&amp;);
    };
    void f(const S&amp;);
    void f(int);
    void g() {
        enum E { e };
        f(e);    //<SPAN STYLE="font-family:Times"><I> ill-formed?</I></SPAN>
    }
</PRE>

<P>Three possibilities suggest themselves:</P>

<OL>

<LI>
<P>
<B>Fail during overload resolution.</B> In order to
perform overload resolution for the call to <TT>f</TT>, the
declaration of the required specialization of the <TT>S</TT>
constructor must be instantiated.  This instantiation uses a
local type and is thus ill-formed (14.3.1&nbsp;



 <A HREF="template.html#temp.arg.type">temp.arg.type</A>
paragraph 2), rendering the example as a whole ill-formed, as
well.</P>
</LI>

<LI>
<P>
<B>Treat this as a type-deduction failure.</B> Although it
is not listed currently among the causes of type-deduction
failure in 14.8.2&nbsp;



 <A HREF="template.html#temp.deduct">temp.deduct</A> paragraph 2, it could
plausibly be argued that instantiating a function declaration
with a local type as a template type-parameter falls under the
rubric of &ldquo;If a substitution in a template parameter or in
the function type of the function template results in an invalid
type&rdquo; and thus should be a type-deduction failure.  The
result would be that the example is well-formed because
<TT>f(const S&amp;)</TT> would be removed from the list of viable
functions.</P>
</LI>

<LI>
<P>
<B>Fail only if the function selected by overload
resolution requires instantiation with a local type.</B> This
approach would require that the diagnostic resulting from the
instantiation of the function type during overload resolution be
suppressed and either regenerated or regurgitated once overload
resolution is complete.  (The example would be well-formed under
this approach because <TT>f(int)</TT> would be selected as the
best match.)</P>
</LI>

</OL>

<P>(See also <A HREF="
     cwg_closed.html#489">issue 489</A>.)</P>

<P>
<B>Notes from the April, 2005 meeting:</B>
</P>

<P>The question in the original example was whether there should be
an error, even though the uninstantiable template was not needed for
calling the best-matching function.  The broader issue is whether a
user would prefer to get an error or to call a &ldquo;worse&rdquo;
non-template function in such cases.  For example:</P>

<PRE>
    template&lt;typename T&gt; void f(T);
    void f(int);
    void g() {
        enum E { e };
        f(e);    //<SPAN STYLE="font-family:Times"><I> call </I></SPAN>f(int)<SPAN STYLE="font-family:Times"><I> or get an error?</I></SPAN>
    }
</PRE>

<P>It was observed that the type deduction rules are intended to model,
albeit selectively, the other rules of the language.  This would argue
in favor of the second approach, a type-deduction failure, and the
consensus of the group was that the incremental benefit of other
approaches was not enough to outweigh the additional complexity of
specification and implementation.</P>

<P>
<B>Proposed resolution (October, 2005):</B>
</P>

<P>Add a new sub-bullet following bullet 3, sub-bullet 7 ("Attempting
to give an invalid type to a non-type template parameter") of
14.8.2&nbsp;



 <A HREF="template.html#temp.deduct">temp.deduct</A> paragraph 2:</P>

<UL>
<LI>
<P>Attempting to use a local or unnamed type as the value of
a template type parameter.</P>
</LI>
</UL>

<P>
<B>Additional note (December, 2005):</B>
</P>

<P>The Evolution Working Group is currently considering an extension
that would effectively give linkage to some (but perhaps not all)
types that currently have no linkage.  If the proposed resolution above
is adopted and then later a change along the lines that the EWG is
considering were also adopted, the result would be a silent change
in the result of overload resolution, because the newly-acceptable
specializations would become part of the overload set.  It is not
clear whether that possibility is sufficient reason to delay adoption
of this resolution or not.  </P>

<BR>
<BR>
<HR>
<A NAME="479"></A>
<H4>479.
  
Copy elision in exception handling
</H4>
<B>Section: </B>15.1&nbsp;



 <A HREF="except.html#except.throw">except.throw</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>ready
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Mike Miller
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>07 Oct 2004<BR>




<P>I have noticed a couple of confusing and overlapping passages
dealing with copy elision.  The first is 15.1&nbsp;



 <A HREF="except.html#except.throw">except.throw</A> paragraph 5:</P>

<BLOCKQUOTE>

If the use of the temporary object can be eliminated without
changing the meaning of the program except for the execution of
constructors and destructors associated with the use of the
temporary object (12.2&nbsp;



 <A HREF="special.html#class.temporary">class.temporary</A>), then the exception
in the handler can be initialized directly with the argument of
the throw expression.

</BLOCKQUOTE>

<P>The other is 15.3&nbsp;



 <A HREF="except.html#except.handle">except.handle</A> paragraph 17:</P>

<BLOCKQUOTE>

If the use of a temporary object can be eliminated without
changing the meaning of the program except for execution of
constructors and destructors associated with the use of the
temporary object, then the optional name can be bound directly to
the temporary object specified in a <I>throw-expression</I>
causing the handler to be executed.

</BLOCKQUOTE>

<P>I <I>think</I> these two passages are intended to describe the
same optimization.  However, as is often the case where something
is described twice, there are significant differences.  One is
just different terminology &mdash; is &ldquo;the exception in the
handler&rdquo; the same as &ldquo;the object declared in the
<I>exception-declaration</I> or, if the
<I>exception-declaration</I> does not specify a name, a temporary
object of that type&rdquo; (15.3&nbsp;



 <A HREF="except.html#except.handle">except.handle</A> paragraph
16)?</P>

<P>More significant, there is a difference in which kinds of
<I>throw-expression</I>s are eligible for the optimization.  In
15.1&nbsp;



 <A HREF="except.html#except.throw">except.throw</A> paragraph 5, it appears that any
object is a candidate, while in 15.3&nbsp;



 <A HREF="except.html#except.handle">except.handle</A>
paragraph 17 the thrown object must be
a temporary (&ldquo;the temporary object specified in a
<I>throw-expression</I>&rdquo;).  For example, it's not clear
looking at these two passages whether the copy of a local
automatic can be elided.  I.e., by analogy with the return value
optimization described in 12.8&nbsp;



 <A HREF="special.html#class.copy">class.copy</A> paragraph
15:</P>

<PRE>
    X x;
    return x;    // copy may be elided

    X x;
    throw x;     // unclear whether copy may be elided
</PRE>

<P>Which brings up another point: 12.8&nbsp;



 <A HREF="special.html#class.copy">class.copy</A>
paragraph 15 purports to be an exhaustive list in which copy
elision is permitted even if the constructor and/or destructor
have side effects; however, these two passages describe another
case that is not mentioned in 12.8&nbsp;



 <A HREF="special.html#class.copy">class.copy</A>
paragraph 15.</P>

<P>A final point of confusion: in the unoptimized abstract
machine, there are actually <I>two</I> copies in throwing and
handling an exception: the copy from the object being thrown to
the exception object, and the copy from the exception object to
the object or temporary in the <I>exception-declaration</I>.
15.1&nbsp;



 <A HREF="except.html#except.throw">except.throw</A> paragraph 5 speaks only of eliminating
the exception object, copying the thrown object directly into the
<I>exception-declaration</I> object, while 15.3&nbsp;



 <A HREF="except.html#except.handle">except.handle</A> paragraph 17 refers to directly binding the
<I>exception-declaration</I> object to the thrown object (if it's
a temporary).  Shouldn't these be separated, with a throw of an
automatic object or temporary being like the return value
optimization and the initialization of the object/temporary in
the <I>exception-declaration</I> being a separate optimizable
step (which could, presumably, be combined to effectively alias
the <I>exception-declaration</I> onto the thrown object)?</P>

<P>(See paper J16/04-0165 = WG21 N1725.)</P>

<P>
<B>Proposed resolution (April, 2005):</B>
</P>

<OL>
<LI>
<P>Add two items to the bulleted list in 12.8&nbsp;



 <A HREF="special.html#class.copy">class.copy</A>
paragraph 15 as follows: </P>

<BLOCKQUOTE>

<P>This elision of copy operations is permitted in the following
circumstances (which may be combined to eliminate multiple copies):</P>

<UL>

<LI>
<P>in a <TT>return</TT> statement in a function with a class return type,
when the expression is the name of a non-volatile automatic object
with the same cv-unqualified type as the function return type, the
copy operation can be omitted by constructing the automatic object
directly into the function&rsquo;s return value</P>
</LI>

<B>
<LI>
<P>in a <I>throw-expression</I>, when the operand is the name
of a non-volatile automatic object, the copy operation from the
operand to the exception object (15.1&nbsp;



 <A HREF="except.html#except.throw">except.throw</A>) can be
omitted by constructing the automatic object directly into the
exception object</P>
</LI>
</B>

<LI>
<P>when a temporary class object that has not been bound to a
reference (12.2&nbsp;



 <A HREF="special.html#class.temporary">class.temporary</A>) would be copied to a class
object with the same cv-unqualified type, the copy operation can be
omitted by constructing the temporary object directly into the target
of the omitted copy</P>
</LI>

<B>
<LI>
<P>when the <I>exception-declaration</I> of an exception
handler (clause 15&nbsp;



 <A HREF="except.html#except">except</A>) declares an object of the
same type (except for cv-qualification) as the exception object
(15.1&nbsp;



 <A HREF="except.html#except.throw">except.throw</A>), the copy operation can be omitted by
treating the <I>exception-declaration</I> as an alias for the
exception object if the meaning of the program will be unchanged
except for the execution of constructors and destructors for the
object declared by the <I>exception-declaration</I>
</P>
</LI>
</B>

</UL>

</BLOCKQUOTE>

</LI>

<LI>
<P>Change 15.1&nbsp;



 <A HREF="except.html#except.throw">except.throw</A> paragraph 5 as follows:</P>

<BLOCKQUOTE>

<S>If the use of the temporary object can be eliminated without
changing the meaning of the program except for the execution of
constructors and destructors associated with the use of the temporary
object (12.2&nbsp;



 <A HREF="special.html#class.temporary">class.temporary</A>), then the exception in the handler
can be initialized directly with the argument of the throw
expression.</S> When the thrown object is a class object, <S>and</S>
the copy constructor <S>used to initialize the temporary copy is not</S>
<B>and the destructor shall be</B> accessible, <S>the program is
ill-formed (even when the temporary object could otherwise be
eliminated)</S> <B>even if the copy operation is elided (12.8&nbsp;



 <A HREF="special.html#class.copy">class.copy</A>)</B>. <S>Similarly, if the destructor for that object is
not accessible, the program is ill-formed (even when the temporary
object could otherwise be eliminated).</S>

</BLOCKQUOTE>

</LI>

<LI>
<P>Change 15.3&nbsp;



 <A HREF="except.html#except.handle">except.handle</A> paragraph 17 as follows:</P>

<BLOCKQUOTE>

<S>If the use of a temporary object can be eliminated without changing
the meaning of the program except for execution of constructors and
destructors associated with the use of the temporary object, then the
optional name can be bound directly to the temporary object specified
in a <I>throw-expression</I> causing the handler to be executed.</S>  The
copy constructor and destructor associated with the object shall be
accessible even <S>when the temporary object is eliminated</S>
<B>if the copy operation is elided (12.8&nbsp;



 <A HREF="special.html#class.copy">class.copy</A>)</B>.

</BLOCKQUOTE>

</LI>

</OL>

<BR>
<BR>
<BR>
<BR>
<HR>
<A NAME="Review Status"></A>
<H3>Issues with "Review" Status</H3>
<HR>
<A NAME="505"></A>
<H4>505.
  
Conditionally-supported behavior for unknown character escapes
</H4>
<B>Section: </B>2.13.2&nbsp;



 <A HREF="lex.html#lex.ccon">lex.ccon</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>review
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Mike Miller
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>14 Apr 2005<BR>


<P>The current wording of 2.13.2&nbsp;



 <A HREF="lex.html#lex.ccon">lex.ccon</A> paragraph 3
states,</P>

<BLOCKQUOTE>

If the character following a backslash is not one of those specified,
the behavior is undefined.

</BLOCKQUOTE>

<P>Paper J16/04-0167=WG21 N1727 suggests that such character escapes
be ill-formed.  In discussions at the Lillehammer meeting, however,
the CWG felt that the newly-approved category of
conditionally-supported behavior would be more appropriate.</P>

<P>
<B>Proposed resolution (October, 2005):</B>
</P>

<P>Change the next-to-last sentence of 2.13.2&nbsp;



 <A HREF="lex.html#lex.ccon">lex.ccon</A>
paragraph 3 from:</P>

<BLOCKQUOTE>

If the character following a backslash is not one of those specified,
the behavior is undefined.

</BLOCKQUOTE>

<P>to:</P>

<BLOCKQUOTE>

Escape sequences in which the character following the backslash is not
listed in Table 5 are conditionally-supported, with
implementation-defined semantics.

</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="514"></A>
<H4>514.
  
Is the initializer for a namespace member in the scope of the namespace?
</H4>
<B>Section: </B>3.4.1&nbsp;



 <A HREF="basic.html#basic.lookup.unqual">basic.lookup.unqual</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>review
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Mike Miller
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>24 Mar 2005<BR>


<P>Is the following code well-formed?</P>

<PRE>
    namespace N {
      int i;
      extern int j;
    }
    int N::j = i;
</PRE>

<P>The question here is whether the lookup for <TT>i</TT> in the
initializer of <TT>N::j</TT> finds the declaration in namespace
<TT>N</TT> or not.  Implementations differ on this question.</P>

<P>If <TT>N::j</TT> were a static data member of a class, the
answer would be clear: both 3.4.1&nbsp;



 <A HREF="basic.html#basic.lookup.unqual">basic.lookup.unqual</A>
paragraph 12 and 8.5&nbsp;



 <A HREF="decl.html#dcl.init">dcl.init</A> paragraph 11 say that
the initializer &ldquo;is in the scope of the member's
class.&rdquo;  There is no such provision for namespace
members defined outside the namespace, however.</P>

<P>The reasoning given in 3.4.1&nbsp;



 <A HREF="basic.html#basic.lookup.unqual">basic.lookup.unqual</A> may be
instructive:</P>

<BLOCKQUOTE>

A name used in the definition of a <TT>static</TT> data member of
class <TT>X</TT> (9.4.2&nbsp;



 <A HREF="class.html#class.static.data">class.static.data</A>) (after the
<I>qualified-id</I> of the static member) is looked up as if the name
was used in a member function of <TT>X</TT>.

</BLOCKQUOTE>

<P>It is certainly the case that a name used in a function that is
a member of a namespace is looked up in that namespace
(3.4.1&nbsp;



 <A HREF="basic.html#basic.lookup.unqual">basic.lookup.unqual</A> paragraph 6), regardless of whether
the definition is inside or outside that namespace.  Initializers
for namespace members should probably be looked up the same way.</P>

<P>
<B>Proposed resolution (October, 2005):</B>
</P>

<P>Add a new paragraph following 3.4.1&nbsp;



 <A HREF="basic.html#basic.lookup.unqual">basic.lookup.unqual</A>
paragraph 12:</P>

<BLOCKQUOTE>

<P>If a variable member of a namespace is defined outside of the scope
of its namespace then any name used in the definition of the variable
member (after the <I>qualified-id</I>) is looked up as if the
definition of the variable member occurred in its
namespace. [<I>Example:</I>
</P>

<PRE>
    namespace N {
      int i = 4;
      extern int j;
    }

    int i = 2;

    int N::j = i;	//<SPAN STYLE="font-family:Times"> <TT>N::j</TT><I> == 4</I></SPAN>
</PRE>

<P>&mdash;<I>end example</I>]</P>

</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="305"></A>
<H4>305.
  
Name lookup in destructor call
</H4>
<B>Section: </B>3.4.5&nbsp;



 <A HREF="basic.html#basic.lookup.classref">basic.lookup.classref</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>review
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Mark Mitchell
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>19 May 2001<BR>


<P>I believe this program is invalid:
<PRE>
    struct A {
    };

    struct C {
      struct A {};
      void f ();
    };

    void C::f () {
      ::A *a;
      a-&gt;~A ();
    }
</PRE>
The problem is that 3.4.5&nbsp;



 <A HREF="basic.html#basic.lookup.classref">basic.lookup.classref</A> says that you have to look
up <TT>A</TT> in both the context of the pointed-to-type (i.e.,
<TT>::A</TT>), and
in the context of the postfix-expression (i.e., the body of <TT>C::f</TT>), and
that if the name is found in both places it must name the same type in
both places.</P>

<P>The EDG front end does not issue an error about this program, though.</P>

<P>Am I reading the standardese incorrectly?</P>

<P>
<U>John Spicer</U>: I think you are reading it correctly.  I think
I've been hoping that this would
get changed.  Unlike other dual lookup contexts, this is one in which the
compiler already knows the right answer (the type must match that of the left
hand of the <TT>-&gt;</TT> operator).  So I think that if either of the types
found matches
the one required, it should be sufficient.  You can't say <TT>a-&gt;~::A()</TT>,
which
means you are forced to say <TT>a-&gt;::A::~A()</TT>, which disables the virtual
mechanism.  So you would have to do something like create a local typedef
for the desired type.</P>

<P>See also issues <A HREF="
     cwg_defects.html#244">244</A>,
<A HREF="
     cwg_active.html#399">399</A>, and
<A HREF="
     cwg_active.html#466">466</A>.</P>

<P>
<B>Proposed resolution (October, 2005):</B>
</P>

<P>Change 3.4.5&nbsp;



 <A HREF="basic.html#basic.lookup.classref">basic.lookup.classref</A> paragraph 3 as indicated:</P>

<BLOCKQUOTE>

If the <I>unqualified-id</I> is <TT>~</TT><I>type-name</I>,
<B>the <I>type-name</I> is looked up in the context of the entire
<I>postfix-expression</I>.</B> <S>and</S> <B>If</B> the
type <B><TT>T</TT></B> of the object expression is of a class
type <TT>C</TT> <S>(or of pointer to a class type <TT>C</TT>)</S>,
the <I>type-name</I> is <B>also</B> looked up <S>in the context of the
entire <I>postfix-expression</I> and</S> in the scope of
class <TT>C</TT>. <S>The <I>type-name</I> shall refer to
a <I>class-name</I>. If <I>type-name</I> is found in both contexts,
the name shall refer to the same class type. If the type of the object
expression is of scalar type, the <I>type-name</I> is looked up in the
scope of the complete <I>postfix-expression</I>.</S> <B>At least one
of the lookups shall find a name that refers to (possibly
cv-qualified)
<TT>T</TT>.  [<I>Example:</I>

<PRE>
    struct A { };

    struct B {
      struct A { };
      void f(::A* a);
    };

    void B::f(::A* a) {
      a-&gt;~A();  //<SPAN STYLE="font-family:Times"><I> OK, lookup in </I><TT>*a</TT><I> finds the injected-class-name</I></SPAN>
    }
</PRE>

&mdash;<I>end example</I>]</B>

</BLOCKQUOTE>

<P>
<I>[Note: this change also resolves <A HREF="
     cwg_active.html#414">issue 414</A>.]</I>
</P>

<BR>
<BR>
<HR>
<A NAME="414"></A>
<H4>414.
  
Multiple types found on destructor lookup
</H4>
<B>Section: </B>3.4.5&nbsp;



 <A HREF="basic.html#basic.lookup.classref">basic.lookup.classref</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>review
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>John Spicer
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>1 May 2003<BR>


<P>By 3.4.5&nbsp;



 <A HREF="basic.html#basic.lookup.classref">basic.lookup.classref</A> paragraph 3, the following is
ill-formed because the two lookups of the destructor name (in
the scope of the class of the object and in the surrounding
context) find different Xs:</P>
<PRE>
  struct X {};
  int main() {
    X x;
    struct X {};
    x.~X();  // Error?
  }
</PRE>
<P>This is silly, because the compiler knows what the type has
to be, and one of the things found matches that.  The lookup
should require only that one of the lookups finds the required
class type.</P>

<P>
<B>Proposed resolution (April, 2005):</B>
</P>

<P>This issue is resolved by the resolution of <A HREF="
     cwg_active.html#305">issue 305</A>.</P>

<BR>
<BR>
<HR>
<A NAME="426"></A>
<H4>426.
  
Identically-named variables, one internally and one externally linked, allowed?
</H4>
<B>Section: </B>3.5&nbsp;



 <A HREF="basic.html#basic.link">basic.link</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>review
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Steve Adamczyk
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>2 July 2003<BR>


<P>An example in
3.5&nbsp;



 <A HREF="basic.html#basic.link">basic.link</A> paragraph 6 creates two file-scope variables
with the same name,
one with internal linkage and one with external.</P>
<PRE>
  static void f();
  static int i = 0;                       //1
  void g() {
          extern void f();                // internal linkage
          int i;                          //2: i has no linkage
          {
                  extern void f();        // internal linkage
                  extern int i;           //3: external linkage
          }
  }
</PRE>
<P>Is this really what we want?
C99 has 6.2.2.7/7,
which gives undefined behavior for having an identifier appear with
internal and external linkage in the same translation unit.  C++
doesn't seem to have an equivalent.</P>

<P>
<B>Notes from October 2003 meeting:</B>
</P>

<P>We agree that this is an error.  We propose to leave the example
but change the comment to indicate that line //3 has undefined
behavior, and elsewhere add a normative rule giving such a
case undefined behavior.</P>

<P>
<B>Proposed resolution (October, 2005):</B>
</P>

<P>Change 3.5&nbsp;



 <A HREF="basic.html#basic.link">basic.link</A> paragraph 6 as indicated:</P>

<BLOCKQUOTE>

<P>...Otherwise, if no matching entity is found, the block scope entity
receives external linkage.  <B>If, within a translation unit, the same
entity is declared with both internal and external linkage, the
behavior is undefined.</B>
</P>

<P>[<I>Example:</I>
</P>

<PRE>
    static void f();
    static int i = 0;            //<SPAN STYLE="font-family:Times"><I> 1</I></SPAN>
    void g () {
        extern void f ();        //<SPAN STYLE="font-family:Times"><I> internal linkage</I></SPAN>
        int i;                   //<SPAN STYLE="font-family:Times"><I> 2: </I><TT>i</TT><I> has no linkage</I></SPAN>
        {
            extern void f ();    //<SPAN STYLE="font-family:Times"><I> internal linkage</I></SPAN>
            extern int i;        //<SPAN STYLE="font-family:Times"><I> 3: external linkage</I></SPAN>
        }
    }
</PRE>

<P>
<S>There are three objects named <TT>i</TT> in this program.  The
object with internal linkage introduced by the declaration in global
scope (line <TT>//1</TT> ), the object with automatic storage duration
and no linkage introduced by the declaration on line <TT>//2</TT>, and
the object with static storage duration and external linkage
introduced by the declaration on line <TT>//3</TT>.</S> <B>Without the
declaration at line <TT>//2</TT>, the declaration at line <TT>//3</TT>
would link with the declaration at line <TT>//1</TT>.  But because the
declaration with internal linkage is hidden, <TT>//3</TT> is given
external linkage, resulting in a linkage conflict.</B> &mdash;<I>end
example</I>]</P>

</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="521"></A>
<H4>521.
  
Requirements for exceptions thrown by allocation functions
</H4>
<B>Section: </B>3.7.3.1&nbsp;



 <A HREF="basic.html#basic.stc.dynamic.allocation">basic.stc.dynamic.allocation</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>review
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Alisdair Meredith
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>22 May 2005<BR>


<P>According to 3.7.3.1&nbsp;



 <A HREF="basic.html#basic.stc.dynamic.allocation">basic.stc.dynamic.allocation</A> paragraph 3,</P>

<BLOCKQUOTE>

Any other allocation function that fails to allocate storage shall
only indicate failure by throwing an exception of
class <TT>std::bad_alloc</TT> (18.4.2.1&nbsp;



 <A HREF="lib-support.html#lib.bad.alloc">lib.bad.alloc</A>) or a
class derived from <TT>std::bad_alloc</TT>.

</BLOCKQUOTE>

<P>Shouldn't this statement have the usual requirements for an
unambiguous and accessible base class?</P>

<P>
<B>Proposed resolution (October, 2005):</B>
</P>

<P>Change the last sentence of 3.7.3.1&nbsp;



 <A HREF="basic.html#basic.stc.dynamic.allocation">basic.stc.dynamic.allocation</A>
paragraph 3 as indicated:</P>

<BLOCKQUOTE>

Any other allocation function that fails to allocate storage shall
only indicate failure by throwing an exception of
<S>class <TT>std::bad_alloc</TT> (18.4.2.1&nbsp;



 <A HREF="lib-support.html#lib.bad.alloc">lib.bad.alloc</A>) or a
class derived from <TT>std::bad_alloc</TT></S> <B>a type that would
match a handler (15.3&nbsp;



 <A HREF="except.html#except.handle">except.handle</A>) of type
<TT>std::bad_alloc</TT> (18.4.2.1&nbsp;



 <A HREF="lib-support.html#lib.bad.alloc">lib.bad.alloc</A>)</B>.

</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="480"></A>
<H4>480.
  
Is a base of a virtual base also virtual?
</H4>
<B>Section: </B>4.11&nbsp;



 <A HREF="conv.html#conv.mem">conv.mem</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>review
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Mark Mitchell
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>18 Oct 2004<BR>


<P>When the Standard refers to a virtual base class, it should be
understood to include base classes of virtual bases.  However,
the Standard doesn't actually say this anywhere, so when
4.11&nbsp;



 <A HREF="conv.html#conv.mem">conv.mem</A> (for example) forbids casting to a
derived class member pointer from a virtual base class member
pointer, it could be read as meaning:</P>

<PRE>
  struct B {};
  struct D : public B {};
  struct D2 : virtual public D {};

  int B::*p;
  int D::*q;

  void f() {
    static_cast&lt;int D2::*&gt;(p);  // <SPAN STYLE="font-family:Times"><I>permitted</I></SPAN>
    static_cast&lt;int D2::*&gt;(q);  // <SPAN STYLE="font-family:Times"><I>forbidden</I></SPAN>
  }
</PRE>

<P>
<B>Proposed resolution (October, 2005):</B>
</P>

<OL>
<LI>
<P>Change 4.11&nbsp;



 <A HREF="conv.html#conv.mem">conv.mem</A> paragraph 2 as indicated:</P>
</LI>

<BLOCKQUOTE>

...If <TT>B</TT> is an inaccessible (clause 11&nbsp;



 <A HREF="access.html#class.access">class.access</A>),
ambiguous (10.2&nbsp;



 <A HREF="derived.html#class.member.lookup">class.member.lookup</A>) or virtual (10.1&nbsp;



 <A HREF="derived.html#class.mi">class.mi</A>) base class of <TT>D</TT>, <B>or a base class of a
virtual base class of <TT>D</TT>,</B> a program that necessitates this
conversion is ill-formed...

</BLOCKQUOTE>

<LI>
<P>Change 5.2.9&nbsp;



 <A HREF="expr.html#expr.static.cast">expr.static.cast</A> paragraph 2 as indicated:</P>
</LI>

<BLOCKQUOTE>

...and <TT>B</TT> is <S>not</S> <B>neither</B> a virtual base class
of <TT>D</TT> <B>nor a base class of a virtual base class
of <TT>D</TT></B>...

</BLOCKQUOTE>

<LI>
<P>Change 5.2.9&nbsp;



 <A HREF="expr.html#expr.static.cast">expr.static.cast</A> paragraph 9 as indicated:</P>
</LI>

<BLOCKQUOTE>

...and <TT>B</TT> is <S>not</S> <B>neither</B> a virtual base class
of <TT>D</TT> <B>nor a base class of a virtual base class of
<TT>D</TT></B>...

</BLOCKQUOTE>

</OL>

<BR>
<BR>
<HR>
<A NAME="506"></A>
<H4>506.
  
Conditionally-supported behavior for non-POD objects passed to ellipsis
</H4>
<B>Section: </B>5.2.2&nbsp;



 <A HREF="expr.html#expr.call">expr.call</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>review
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Mike Miller
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>14 Apr 2005<BR>


<P>The current wording of 5.2.2&nbsp;



 <A HREF="expr.html#expr.call">expr.call</A> paragraph 7
states:</P>

<BLOCKQUOTE>

When there is no parameter for a given argument, the argument is
passed in such a way that the receiving function can obtain the
value of the argument by invoking <TT>va_arg</TT>
(18.7&nbsp;



 <A HREF="lib-support.html#lib.support.runtime">lib.support.runtime</A>).  The lvalue-to-rvalue
(4.1&nbsp;



 <A HREF="conv.html#conv.lval">conv.lval</A>), array-to-pointer
(4.2&nbsp;



 <A HREF="conv.html#conv.array">conv.array</A>), and function-to-pointer
(4.3&nbsp;



 <A HREF="conv.html#conv.func">conv.func</A>) standard conversions are performed
on the argument expression.  After these conversions, if the
argument does not have arithmetic, enumeration, pointer,
pointer to member, or class type, the program is ill-formed.
If the argument has a non-POD class type (clause
9&nbsp;



 <A HREF="class.html#class">class</A>), the behavior is undefined.

</BLOCKQUOTE>

<P>Paper J16/04-0167=WG21 N1727 suggests that passing a non-POD
object to ellipsis be ill-formed.  In discussions at the
Lillehammer meeting, however, the CWG felt that the newly-approved
category of conditionally-supported behavior would be more
appropriate.</P>

<P>
<B>Proposed resolution (October, 2005):</B>
</P>

<P>Change 5.2.2&nbsp;



 <A HREF="expr.html#expr.call">expr.call</A> paragraph 7 as indicated:</P>

<BLOCKQUOTE>

...After these conversions, if the argument does not have arithmetic,
enumeration, pointer, pointer to member, or class type, the program is
ill-formed. <S>If the argument has a non-POD class type (clause 9),
the behavior is undefined.</S> <B>Passing an argument of non-POD class
type (clause 9) with no corresponding parameter is
conditionally-supported, with implementation-defined semantics.</B>

</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="520"></A>
<H4>520.
  
Old-style casts between incomplete class types
</H4>
<B>Section: </B>5.4&nbsp;



 <A HREF="expr.html#expr.cast">expr.cast</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>review
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>comp.std.c++
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>19 May 2005<BR>


<P>5.4&nbsp;



 <A HREF="expr.html#expr.cast">expr.cast</A> paragraph 6 says,</P>

<BLOCKQUOTE>

The operand of a cast using the cast notation can be an rvalue of type
&ldquo;pointer to incomplete class type&rdquo;. The destination type
of a cast using the cast notation can be &ldquo;pointer to incomplete
class type&rdquo;. In such cases, even if there is a inheritance
relationship between the source and destination classes, whether the
<TT>static_cast</TT> or <TT>reinterpret_cast</TT> interpretation is
used is unspecified.

</BLOCKQUOTE>

<P>The wording seems to allow the following:</P>

<OL>

<LI>
<P>casting from void pointer to incomplete type</P>
</LI>

<PRE>
    struct A;
    struct B;

    void *v;
    A *a = (A*)v; // allowed to choose reinterpret_cast
</PRE>

<LI>
<P>variant application of static or reinterpret casting</P>
</LI>

<PRE>
    B *b = (B*)a;    // compiler can choose static_cast here
    A *aa = (A*)b;   // compiler can choose reinterpret_cast here
    assert(aa == a); // might not hold
</PRE>

<LI>
<P>ability to somehow choose static_cast</P>
</LI>

<P>It's not entirely clear how a compiler can
choose <TT>static_cast</TT> as 5.4&nbsp;



 <A HREF="expr.html#expr.cast">expr.cast</A> paragraph 6
seems to allow. I believe the intent of 5.4&nbsp;



 <A HREF="expr.html#expr.cast">expr.cast</A>
paragraph 6 is to force the use of <TT>reinterpret_cast</TT> when
either are incomplete class types and <TT>static_cast</TT> iff the
compiler knows both types and there is a non-ambiguous
hierarchy-traversal between that cast (or maybe not, <A HREF="
     cwg_active.html#242">core issue 242</A> talks about this). I cannot see any
other interpretation because it isn't intuitive, every compiler I've
tried agrees with me, and neither standard pointer conversions
(4.10&nbsp;



 <A HREF="conv.html#conv.ptr">conv.ptr</A> paragraph 3) nor <TT>static_cast</TT>
(5.2.9&nbsp;



 <A HREF="expr.html#expr.static.cast">expr.static.cast</A> paragraph 5) talk about incomplete
class types. If the committee agrees with me, I would like to see
<secton_ref>4.10&nbsp;



 <A HREF="conv.html#conv.ptr">conv.ptr</A></secton_ref> paragraph 3 and 5.2.9&nbsp;



 <A HREF="expr.html#expr.static.cast">expr.static.cast</A> paragraph 5 explicitly disallow incomplete class
types and the wording of 5.4&nbsp;



 <A HREF="expr.html#expr.cast">expr.cast</A> paragraph 6
changed to not allow any other interpretation.</P>

</OL>

<P>
<B>Proposed resolution (October, 2005):</B>
</P>

<P>Change 5.4&nbsp;



 <A HREF="expr.html#expr.cast">expr.cast</A> paragraph 6 as indicated:</P>

<BLOCKQUOTE>

The operand of a cast using the cast notation can be an rvalue of type
&ldquo;pointer to incomplete class type.&rdquo; The destination type
of a cast using the cast notation can be &ldquo;pointer to incomplete
class type.&rdquo; In such cases, even if there is <S>a</S> <B>an</B>
inheritance relationship between the source and destination classes,
whether the <TT>static_cast</TT> or <TT>reinterpret_cast</TT>
interpretation is used is unspecified. <B>[<I>Note:</I> For example,
if the classes were defined later in the translation unit, a
multi-pass compiler would be permitted to interpret a cast between
pointers to the classes as if the class types were complete at that
point.  &mdash;<I>end note</I>]</B>

</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="367"></A>
<H4>367.
  
<TT>throw</TT> operator allowed in constant expression?
</H4>
<B>Section: </B>5.19&nbsp;



 <A HREF="expr.html#expr.const">expr.const</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>review
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Martin v. Loewis
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>29 July 2002<BR>


<P>The following translation unit appears to be well-formed.</P>
<PRE>
int x[true?throw 4:5];
</PRE>
<P>According to 5.19&nbsp;



 <A HREF="expr.html#expr.const">expr.const</A>, this appears to be an
integral constant expression:
it is a conditional expression, involves only literals, and no
assignment, increment, decrement, function-call, or comma operators.
However, if this is well-formed, the standard gives no meaning to 
this declaration, since the array bound (8.3.4&nbsp;



 <A HREF="decl.html#dcl.array">dcl.array</A>
paragraph 1) cannot be computed.</P>

<P>I believe the defect is that throw expressions should also be banned
from constant expressions.</P>

<P>
<B>Notes from October 2002 meeting:</B>
</P>

<P>We should also check on <TT>new</TT> and <TT>delete</TT>.</P>

<P>
<B>Notes from the April, 2005 meeting:</B>
</P>

<P>Although it could be argued that all three of these operators
potentially involve function calls &mdash; <TT>throw</TT>
to <TT>std::terminate</TT>, <TT>new</TT> and <TT>delete</TT> to the
corresponding allocation and deallocation functions &mdash; and thus
would already be excluded from constant expressions, this reasoning
was considered to be too subtle to allow closing the issue with no
change.  A modification that explicitly clarifies the status of these
operators will be drafted.</P>

<P>
<B>Proposed resolution (October, 2005):</B>
</P>

<P>Change the last sentence of 5.19&nbsp;



 <A HREF="expr.html#expr.const">expr.const</A> as indicated:</P>

<BLOCKQUOTE>

In particular, except in <TT>sizeof</TT> expressions, functions, class
objects, pointers, or references shall not be used, and assignment,
increment, decrement, <S>function-call</S> <B>function call (including
<I>new-expression</I>s and <I>delete-expression</I>s)</B>, <S>or</S> comma
operators<B>, or <I>throw-expression</I>s</B> shall not be used.

</BLOCKQUOTE>

<P>
<I>Note: this sentence is also changed by the resolution of
<A HREF="
     cwg_active.html#530">issue 530</A>.</I>
</P>

<BR>
<BR>
<HR>
<A NAME="397"></A>
<H4>397.
  
Same address for string literals from default arguments in inline functions?
</H4>
<B>Section: </B>7.1.2&nbsp;



 <A HREF="dcl.html#dcl.fct.spec">dcl.fct.spec</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>review
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Mark Mitchell
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>13 Jan 2003<BR>


<P>Are string literals from default arguments
used in extern inlines supposed to have the same addresses across
all translation units?</P>
<PRE>
  void f(const char* = "s")
  inline g() {
    f();
  }
</PRE>
<P>Must the "s" strings be the same in all copies of the
inline function?</P>

<P>
<U>Steve Adamczyk</U>:
The totality of the standard's wisdom on this topic is
(7.1.2&nbsp;



 <A HREF="dcl.html#dcl.fct.spec">dcl.fct.spec</A> paragraph 4):</P>
<BLOCKQUOTE>
A string literal in an extern inline function is the same object 
in different translation units.
</BLOCKQUOTE>
 
<P>I'd hazard a guess that a literal in a default argument expression 
is not "in" the extern inline function (it doesn't appear in the
tokens of the function), and therefore it need not be
the same in different translation units.</P>

<P>I don't know that users would expect such strings to have
the same address, and an equally valid (and incompatible) expectation
would be that the same string literal would be used for every expansion of
a given default argument in a single translation unit.</P>

<P>
<B>Notes from April 2003 meeting:</B>
</P>

<P>The core working group feels that the address of a string literal
should be guaranteed to be the same only if it actually appears
textually within the body of the inline function.  So a string in
a default argument expression
in a block extern declaration inside the body of a function would
be the same in all instances of the function.  On the other
hand, a string in a default argument expression in the header of
the function (i.e., outside of the body) would not be the same.</P>

<P>
<B>Proposed resolution (April 2003):</B>
</P>

<P>Change the last sentence and add the note to the end of 
7.1.2&nbsp;



 <A HREF="dcl.html#dcl.fct.spec">dcl.fct.spec</A> paragraph 4:</P>
<BLOCKQUOTE>
A string literal in <B>the body of</B> an <TT>extern inline</TT>
function is the same
object in different translation units.
<B>[<I>Note:</I> A string literal that is encountered only in the context of a
function call (in the default argument expression of the called function),
is not &ldquo;in&rdquo; the <TT>extern inline</TT> function.]</B>
</BLOCKQUOTE>

<P>
<B>Notes from October 2003 meeting:</B>
</P>

<P>We discussed ctor-initializer lists and decided that they are
also part of the body.  We've asked Clark Nelson to work on
syntax changes to give us a syntax term for the body of a
function so we can refer to it here.  See also
<A HREF="
     cwg_active.html#452">issue 452</A>, which could use this term.</P>

<P>
<I>(October, 2005: moved to &ldquo;review&rdquo; status in concert with
<A HREF="
     cwg_active.html#452">issue 452</A>.  With that resolution, the wording
above needs no further changes.)</I>
</P>

<BR>
<BR>
<HR>
<A NAME="477"></A>
<H4>477.
  
Can <TT>virtual</TT> appear in a <TT>friend</TT> declaration?
</H4>
<B>Section: </B>7.1.2&nbsp;



 <A HREF="dcl.html#dcl.fct.spec">dcl.fct.spec</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>review
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Daveed Vandevoorde
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>23 Sep 2004<BR>


<P>I couldn't find wording that makes it invalid to say
<TT>friend&nbsp;virtual...</TT>  The closest seems to be
7.1.2&nbsp;



 <A HREF="dcl.html#dcl.fct.spec">dcl.fct.spec</A> paragraph 5, which says:</P>

<BLOCKQUOTE>

The <TT>virtual</TT> specifier shall only be used in declarations
of nonstatic class member functions that appear within a
<I>member-specification</I> of a class definition; see
10.3&nbsp;



 <A HREF="derived.html#class.virtual">class.virtual</A>.

</BLOCKQUOTE>

<P>I don't think that excludes a friend declaration (which is a
valid <I>member-specification</I> by 9.2&nbsp;



 <A HREF="class.html#class.mem">class.mem</A>).</P>

<P>
<U>John Spicer</U>: I agree that virtual should not be allowed
on friend declarations.  I think the wording in 7.1.2&nbsp;



 <A HREF="dcl.html#dcl.fct.spec">dcl.fct.spec</A> is intended to be <I>the</I> declaration of a
function within its class, although I think the wording should be
improved to make it clearer.</P>

<P>
<B>Proposed resolution (October, 2005):</B>
</P>

<P>Change 7.1.2&nbsp;



 <A HREF="dcl.html#dcl.fct.spec">dcl.fct.spec</A> paragraphs 5-6 as indicated:</P>

<BLOCKQUOTE>

<P>The <TT>virtual</TT> specifier shall <S>only</S> be
used <B>only</B> in <S>declarations</S> <B>the declaration</B>
of <B>a</B> non-static class member <S>functions that appear within a</S>
<B>function that appears within the</B> <I>member-specification</I>
of <S>a</S> <B>its</B> class definition; see <secion_ref>10.3&nbsp;



 <A HREF="derived.html#class.virtual">class.virtual</A></secion_ref>.</P>

<P>The <TT>explicit</TT> specifier shall be used only
in <S>declarations</S> <B>the declaration</B> of <S>constructors</S>
<B>a constructor</B> within <S>a</S> <B>its</B> class definition; see
12.3.1&nbsp;



 <A HREF="special.html#class.conv.ctor">class.conv.ctor</A>.</P>

</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="516"></A>
<H4>516.
  
Use of <TT>signed</TT> in bit-field declarations
</H4>
<B>Section: </B>7.1.5.2&nbsp;



 <A HREF="dcl.html#dcl.type.simple">dcl.type.simple</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>review
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>comp.std.c++
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>25 Apr 2005<BR>


<P>7.1.5.2&nbsp;



 <A HREF="dcl.html#dcl.type.simple">dcl.type.simple</A> paragraph 3 reads,</P>

<BLOCKQUOTE>

It is implementation-defined whether bit-fields and objects
of <TT>char</TT> type are represented as signed or unsigned
quantities.  The <TT>signed</TT> specifier forces <TT>char</TT>
objects and bit-fields to be signed; it is redundant with other
integral types.

</BLOCKQUOTE>

<P>The last sentence in that quote is misleading w.r.t. bit-fields. The
first sentence in that quote is correct but incomplete.</P>

<P>Proposed fix: change the two sentences to read:</P>

<BLOCKQUOTE>

It is implementation-defined whether objects of <TT>char</TT> type are
represented as signed or unsigned quantities. The <TT>signed</TT>
specifier forces <TT>char</TT> objects signed; it is redundant with
other integral types except when declaring bit-fields (9.6&nbsp;



 <A HREF="class.html#class.bit">class.bit</A>).

</BLOCKQUOTE>

<P>
<B>Proposed resolution (October, 2005):</B>
</P>

<P>Change 7.1.5.2&nbsp;



 <A HREF="dcl.html#dcl.type.simple">dcl.type.simple</A> paragraph 3 as indicated:</P>

<BLOCKQUOTE>

When multiple <I>simple-type-specifier</I>s are allowed, they can be
freely intermixed with other <I>decl-specifier</I>s in any
order. <B>[<I>Note:</I></B> It is implementation-defined whether
<S>bit-fields and</S> objects of <TT>char</TT> type <B>and certain
bit-fields (9.6&nbsp;



 <A HREF="class.html#class.bit">class.bit</A>)</B> are represented as signed
or unsigned quantities.  The <TT>signed</TT> specifier
forces <B>bit-fields and</B> <TT>char</TT> objects <S>and
bit-fields</S> to be signed; it is redundant <S>with other integral
types</S> <B>in other contexts</B>. <B>&mdash;<I>end note</I>]o</B>

</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="453"></A>
<H4>453.
  
References may only bind to &ldquo;valid&rdquo; objects
</H4>
<B>Section: </B>8.3.2&nbsp;



 <A HREF="decl.html#dcl.ref">dcl.ref</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>review
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Gennaro Prota
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>18 Jan 2004<BR>


<P>8.3.2&nbsp;



 <A HREF="decl.html#dcl.ref">dcl.ref</A> paragraph 4 says:</P>
<BLOCKQUOTE>
  A reference shall be initialized to refer to a valid object or
  function. [Note: in particular, a null reference cannot exist
  in a well-defined program, because the only way to create such
  a reference would be to bind it to the "object" obtained by
  dereferencing a null pointer, which causes undefined behavior
  ...]
</BLOCKQUOTE>
<P>What is a "valid" object? In particular the expression "valid object"
seems to exclude uninitialized objects, but the response to Core Issue
363 clearly says that's not the intent. This is an example
(overloading construction on constness of *this) by John Potter, which
I think is supposed to be legal C++ though it binds references to
objects that are not initialized yet:</P>
<PRE>
 struct Fun {
    int x, y;
    Fun (int x, Fun const&amp;) : x(x), y(42) { }
    Fun (int x, Fun&amp;) : x(x), y(0) { }
  };
  int main () {
    const Fun f1 (13, f1);
    Fun f2 (13, f2);
    cout &lt;&lt; f1.y &lt;&lt; " " &lt;&lt; f2.y &lt;&lt; "\n";
  }
</PRE>

<P>Suggested resolution: Changing the final part of
8.3.2&nbsp;



 <A HREF="decl.html#dcl.ref">dcl.ref</A> paragraph 4 to:</P>
<BLOCKQUOTE>
  A reference shall be initialized to refer to an object or function.
  From its point of declaration on (see 3.3.1&nbsp;



 <A HREF="basic.html#basic.scope.pdecl">basic.scope.pdecl</A>)
  its name is an lvalue
  which refers to that object or function. The reference may be
  initialized to refer to an uninitialized object but, in that case,
  it is usable in limited ways (3.8&nbsp;



 <A HREF="basic.html#basic.life">basic.life</A>, paragraph 6)
  [Note: On the other hand, a declaration like this:
<PRE>
    int &amp; ref = *(int*)0;
</PRE>
  is ill-formed because ref will not refer to any object or function
  ]
</BLOCKQUOTE>

<P>I also think a "No diagnostic is required." would better be added
(what about something like int&amp; r = r; ?)</P>

<P>
<B>Proposed Resolution (October, 2004):</B>
</P>

<P>(Note: the following wording depends on the proposed
resolution for <A HREF="
     cwg_active.html#232">issue 232</A>.)</P>

<P>Change 8.3.2&nbsp;



 <A HREF="decl.html#dcl.ref">dcl.ref</A> paragraph 4 as follows:</P>
<BLOCKQUOTE>

<P>
<S>A reference shall be initialized to refer to a valid object
or function.</S> <B>If an lvalue to which a reference is directly
bound designates neither an existing object or function of an
appropriate type (8.5.3&nbsp;



 <A HREF="decl.html#dcl.init.ref">dcl.init.ref</A>), nor a region of
memory of suitable size and alignment to contain an object of the
reference's type (1.8&nbsp;



 <A HREF="intro.html#intro.object">intro.object</A>, 3.8&nbsp;



 <A HREF="basic.html#basic.life">basic.life</A>, 3.9&nbsp;



 <A HREF="basic.html#basic.types">basic.types</A>), the behavior is
undefined.</B> [<I>Note:</I> in particular, a null reference cannot
exist in a well-defined program, because the only way to create
such a reference would be to bind it to the
<S>&ldquo;object&rdquo;</S> <B>empty lvalue</B> obtained by
dereferencing a null pointer, which <S>causes undefined behavior.
As</S> <B>does not designate an object or function.  Also, as
</B> described in 9.6&nbsp;



 <A HREF="class.html#class.bit">class.bit</A>,
a reference cannot be bound directly to a
bit-field. ]</P>

<P>
<B>The name of a reference shall not be used in its own
initializer.  Any other use of a reference before it is
initialized results in undefined behavior.  [<I>Example:</I>
</B>
</P>

<B>
<PRE>
  int&amp; f(int&amp;);
  int&amp; g();

  extern int&amp; ir3;
  int* ip = 0;

  int&amp; ir1 = *ip;     // <I>undefined behavior: null pointer</I>
  int&amp; ir2 = f(ir3);  // <I>undefined behavior: </I>ir3<I> not yet initialized</I>
  int&amp; ir3 = g();
  int&amp; ir4 = f(ir4);  // <I>ill-formed: </I>ir4<I> used in its own initializer</I>
</PRE>
&mdash;<I>end example</I>]
</B>
</BLOCKQUOTE>

<P>
<B>Rationale: </B> The proposed wording goes beyond the specific
concerns of the issue, primarily in response to messages 10498-10506
on the core reflector.  It was noted that, while the current wording
makes cases like <TT>int&amp; r = r;</TT> ill-formed
(because <TT>r</TT> in the initializer does not "refer to a
valid object"), an inappropriate initialization can only be
detected, if at all, at runtime and thus "undefined
behavior" is a more appropriate treatment.  Nevertheless, it was
deemed desirable to continue to require a diagnostic for obvious
compile-time cases.
</P>

<P>It was also noted that the current Standard does not say anything
about using a reference before it is initialized.  It seemed
reasonable to address both of these concerns in the same wording
proposed to resolve this issue.
</P>

<P>
<B>Notes from the April, 2005 meeting:</B>
</P>

<P>The CWG decided that whether to require an implementation to
diagnose initialization of a reference to itself should be handled as
a separate issue (<A HREF="
     cwg_closed.html#504">504</A>) and also suggested referring
to &ldquo;storage&rdquo; instead of &ldquo;memory&rdquo; (because
1.8&nbsp;



 <A HREF="intro.html#intro.object">intro.object</A> defines an object as a &ldquo;region of
storage&rdquo;).</P>

<P>
<B>Proposed Resolution (April, 2005):</B>
</P>

<P>(Note: the following wording depends on the proposed
resolution for <A HREF="
     cwg_active.html#232">issue 232</A>.)</P>

<P>Change 8.3.2&nbsp;



 <A HREF="decl.html#dcl.ref">dcl.ref</A> paragraph 4 as follows:</P>
<BLOCKQUOTE>

<P>
<S>A reference shall be initialized to refer to a valid object
or function.</S> <B>If an lvalue to which a reference is directly
bound designates neither an existing object or function of an
appropriate type (8.5.3&nbsp;



 <A HREF="decl.html#dcl.init.ref">dcl.init.ref</A>), nor a region of
storage of suitable size and alignment to contain an object of the
reference's type (1.8&nbsp;



 <A HREF="intro.html#intro.object">intro.object</A>, 3.8&nbsp;



 <A HREF="basic.html#basic.life">basic.life</A>, 3.9&nbsp;



 <A HREF="basic.html#basic.types">basic.types</A>), the behavior is
undefined.</B> [<I>Note:</I> in particular, a null reference cannot
exist in a well-defined program, because the only way to create
such a reference would be to bind it to the
<S>&ldquo;object&rdquo;</S> <B>empty lvalue</B> obtained by
dereferencing a null pointer, which <S>causes undefined behavior.
As</S> <B>does not designate an object or function.  Also, as
</B> described in 9.6&nbsp;



 <A HREF="class.html#class.bit">class.bit</A>,
a reference cannot be bound directly to a
bit-field. ]</P>

<P>
<B>Any use of a reference before it is initialized results in
undefined behavior.  [<I>Example:</I>
</B>
</P>

<B>
<PRE>
  int&amp; f(int&amp;);
  int&amp; g();

  extern int&amp; ir3;
  int* ip = 0;

  int&amp; ir1 = *ip;     // <SPAN STYLE="font-family:Times"><I>undefined behavior: null pointer</I></SPAN>
  int&amp; ir2 = f(ir3);  // <SPAN STYLE="font-family:Times"><I>undefined behavior: </I></SPAN>ir3<SPAN STYLE="font-family:Times"><I> not yet initialized</I></SPAN>
  int&amp; ir3 = g();
  int&amp; ir4 = f(ir4);  // <SPAN STYLE="font-family:Times"><I>undefined behavior: </I></SPAN>ir4<SPAN STYLE="font-family:Times"><I> used in its own initializer</I></SPAN>
</PRE>
&mdash;<I>end example</I>]
</B>
</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="508"></A>
<H4>508.
  
Non-constructed value-initialized objects
</H4>
<B>Section: </B>8.5&nbsp;



 <A HREF="decl.html#dcl.init">dcl.init</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>review
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Alisdair Meredith
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>18 Mar 2005<BR>


<P>According to the definition of <I>value initialization</I>
(8.5&nbsp;



 <A HREF="decl.html#dcl.init">dcl.init</A> paragraph 5), non-union class types without
user-declared constructors are value-initialized by value-initializing
each of their members rather than by executing the (generated)
default constructor.  However, a number of other items in the
Standard are described in relationship to the execution of the
constructor:</P>

<UL>

<LI>
<P>12.4&nbsp;



 <A HREF="special.html#class.dtor">class.dtor</A> paragraph 6: &ldquo;Bases and
members are destroyed in the reverse order of the completion of their
constructor.&rdquo;  If a given base or member is value-initialized without
running its constructor, is it destroyed?  (For that matter, paragraph
10 refers to &ldquo;constructed&rdquo; objects; is an object that is
value-initialized without invoking a constructor
&ldquo;constructed?&rdquo;)</P>
</LI>

<LI>
<P>15.2&nbsp;



 <A HREF="except.html#except.ctor">except.ctor</A> paragraph 2: &ldquo;An object that is
partially constructed or partially destroyed will have destructors
executed for all of its fully constructed subobjects, that is, for
subobjects for which the constructor has completed
execution...&rdquo;</P>
</LI>

<LI>
<P>3.8&nbsp;



 <A HREF="basic.html#basic.life">basic.life</A> paragraph 1: The lifetime of an
object begins when &ldquo;the constructor call has completed.&rdquo;
(In the TC1 wording&nbsp;&mdash; &ldquo;if <TT>T</TT> is a class type
with a non-trivial constructor (12.1&nbsp;



 <A HREF="special.html#class.ctor">class.ctor</A>), the
constructor call has completed&rdquo;&nbsp;&mdash; the lifetime of
some value-initialized objects never began; in the current wording
&mdash;&nbsp;&ldquo;the constructor invoked to create the object is
non-trivial&rdquo;&nbsp;&mdash; the lifetime begins before any of the
members are initialized.)</P>
</LI>

</UL>

<P>
<B>Proposed resolution (October, 2005):</B>
</P>

<P>Add the indicated words to 8.5&nbsp;



 <A HREF="decl.html#dcl.init">dcl.init</A> paragraph 6:</P>

<BLOCKQUOTE>

A program that calls for default-initialization or
value-initialization of an entity of reference type is ill-formed. If
<TT>T</TT> is a cv-qualified type, the cv-unqualified version
of <TT>T</TT> is used for these definitions of zero-initialization,
default-initialization, and value-initialization. <B>Even when
value-initialization of an object does not call that object's
constructor, the object is deemed to have been fully constructed once
its initialization is complete and thus subject to provisions of this
International Standard applying to &ldquo;constructed&rdquo; objects,
objects &ldquo;for which the constructor has completed
execution,&rdquo; etc.</B>

</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="491"></A>
<H4>491.
  
Initializers for empty-class aggregrate members
</H4>
<B>Section: </B>8.5.1&nbsp;



 <A HREF="decl.html#dcl.init.aggr">dcl.init.aggr</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>review
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Nathan Sidwell
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>15 Dec 2004<BR>


<P>The current wording of 8.5.1&nbsp;



 <A HREF="decl.html#dcl.init.aggr">dcl.init.aggr</A> paragraph
8 requires that</P>

<BLOCKQUOTE>

An <I>initializer</I> for an aggregate member that is an empty class
shall have the form of an empty initializer-list <TT>{}</TT>.

</BLOCKQUOTE>

<P>This is overly constraining.  There is no reason that the
following should be ill-formed:</P>

<PRE>
    struct S { };
    S s;
    S arr[1] = { s };
</PRE>

<P>
<U>Mike Miller</U>: The wording of 8.5.1&nbsp;



 <A HREF="decl.html#dcl.init.aggr">dcl.init.aggr</A> paragraph 8 is unclear.  &ldquo;An aggregate
member&rdquo; would most naturally mean &ldquo;a member of an
aggregate.&rdquo; In context, however, I think it must mean
&ldquo;a member [of an aggregate] that is an aggregate&rdquo;,
that is, a subaggregate.  Members of aggregates need not
themselves be aggregates (cf paragraph 13 and 12.6.1&nbsp;



 <A HREF="special.html#class.expl.init">class.expl.init</A>); it cannot be the case that an object of an
empty class with a user-declared constructor must be initialized
with <TT>{}</TT> when it is a member of an aggregate.  This
wording should be clarified, regardless of the decision on
Nathan's point.</P>

<P>
<B>Proposed resolution (October, 2005):</B>
</P>

<P>This issue is resolved by the resolution of
<A HREF="
     cwg_active.html#413">issue 413</A>.</P>

<BR>
<BR>
<HR>
<A NAME="413"></A>
<H4>413.
  
Definition of "empty class"
</H4>
<B>Section: </B>9&nbsp;



 <A HREF="class.html#class">class</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>review
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Pete Becker
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>30 Apr 2003<BR>




<P>The proposal says that value is true if "T is an empty class (10)".
Clause 10 doesn't define an empty class, although it has a note that
says a base class may "be of zero size (clause 9)" 9/3 says "Complete
objects and member subobjects of class type shall have nonzero size."
This has a footnote, which says "Base class subobjects are not so
constrained."</P>

<P>The standard uses the term "empty class" in two places
(8.5.1&nbsp;



 <A HREF="decl.html#dcl.init.aggr">dcl.init.aggr</A>), but neither of
those places defines it. It's also listed in the index, which refers to
the page that opens clause 9, i.e. the nonzero size stuff cited above.</P>

<P>So, what's the definition of "empty class" that determines whether the
predicate is_empty is true?</P>

<P>The one place where it's used is
8.5.1&nbsp;



 <A HREF="decl.html#dcl.init.aggr">dcl.init.aggr</A> paragraph 8, which says (roughly paraphrased) 
that an aggregate initializer for an empty class must be "{}", and when 
such an initializer is used for an aggregate that is not an empty class the 
members are default-initialized. In this context it's pretty clear what's 
meant. In the type traits proposal it's not as clear, and it was probably 
intended to have a different meaning. The boost implementation, after it 
eliminates non-class types, determines whether the trait is true by 
comparing the size of a class derived from T to the size of an 
otherwise-identical class that is not derived from T.</P>

<P>
<U>Howard Hinnant:</U>
<TT>is_empty</TT> was created to find out whether a type could be derived from 
and have the empty base class optimization successfully applied.  It 
was created in part to support <TT>compressed_pair</TT> which attempts to 
optimize away the space for one of its members in an attempt to reduce 
spatial overhead.  An example use is:</P>
<PRE>
  template &lt;class T, class Compare = std::less&lt;T&gt; &gt;
  class SortedVec
  {
  public:
  ...
  private:
    T* data_;
    compressed_pair&lt;Compare, size_type&gt; comp_;

    Compare&amp;       comp()       {return comp_.first();}
    const Compare&amp; comp() const {return comp_.first();}
    size_type&amp;     sz()         {return comp_.second();}
    size_type      sz() const   {return comp_.second();}
  };
</PRE>
<P>Here the compare function is optimized away via the empty base 
optimization if Compare turns out to be an "empty" class.  If Compare 
turns out to be a non-empty class, or a function pointer, the space is 
not optimized away.  <TT>is_empty</TT> is key to making this work.</P>

<P>This work built on Nathan's article:
<A HREF="http://www.cantrip.org/emptyopt.html">
http://www.cantrip.org/emptyopt.html</A>.</P>

<P>
<U>Clark Nelson:</U>
I've been looking at issue 413, and I've reached the conclusion that
there are two different kinds of empty class. A class containing only
one or more anonymous bit-field members is empty for purposes of
aggregate initialization, but not (necessarily) empty for purposes of
empty base-class optimization.</P>

<P>Of course we need to add a definition of emptiness for purposes of
aggregate initialization. Beyond that, there are a couple of questions:</P>
<OL>
<LI>
Should the definition of emptiness used by the is_empty predicate be
defined in a language clause or a library clause?
</LI>
<LI>
Do we need to open a new core issue pointing out the fact that the
section on aggregate initialization does not currently say that unnamed
bit-fields are skipped?
</LI>
</OL>

<P>
<B>Notes from the October, 2005 meeting:</B>
</P>

<P>There are only two places in the Standard where the phrase
&ldquo;empty class&rdquo; appears, both in 8.5.1&nbsp;



 <A HREF="decl.html#dcl.init.aggr">dcl.init.aggr</A> paragraph 8.  Because it is not clear whether the
definition of &ldquo;empty for initialization purposes&rdquo; is
suitable for use in defining the <TT>is_empty</TT> predicate, it would
be better just to avoid using the phrase in the language clauses.  The
requirements of 8.5.1&nbsp;



 <A HREF="decl.html#dcl.init.aggr">dcl.init.aggr</A> paragraph 8 appear to be
redundant; paragraph 6 says that an <I>initializer-list</I> must have
no more initializers than the number of elements to initialize, so an
empty class already requires an empty <I>initializer-list</I>, and
using an empty <I>initializer-list</I> with a non-empty class is
covered adequately by paragraph 7's description of the handling of an
<I>initializer-list</I> with fewer <I>initializer</I>s than the
number of members to initialize.</P>

<P>
<B>Proposed resolution (October, 2005):</B>
</P>

<OL>

<LI>
<P>Change <xection_ref>8.5.1&nbsp;



 <A HREF="decl.html#dcl.init.aggr">dcl.init.aggr</A></xection_ref> paragraph 5 by inserting
the indicated text:</P>
</LI>

<BLOCKQUOTE>

<P>Static data members <B>and anonymous bit fields</B> are not
considered members of the class for purposes of aggregate
initialization. [<I>Example:</I>
</P>

<PRE>
    struct A {
        int i;
        static int s;
        int j;<B>
        int :17;
        int k;</B>
    } a = { 1 , 2<B> , 3</B> };
</PRE>

<P>Here, the second initializer 2 initializes <TT>a.j</TT> and not the
static data member <TT>A::s</TT><B>, and the third initializer 3
initializes <TT>a.k</TT> and not the padding before it.</B>
&mdash;<I>end example</I>]</P>

</BLOCKQUOTE>

<LI>
<P>Delete 8.5.1&nbsp;



 <A HREF="decl.html#dcl.init.aggr">dcl.init.aggr</A> paragraph 8:</P>
</LI>

<BLOCKQUOTE>

<P>An <I>initializer</I> for an aggregate member that is an empty
class shall have the form of an empty <I>initializer-list</I>
<TT>{}</TT>.  [<I>Example:</I>
</P>

<PRE>
    struct S { };
    struct A {
        S s;
        int i;
    } a = { { } , 3 };
</PRE>

<P>&mdash;<I>end example</I>] An empty initializer-list can be used to
initialize any aggregate. If the aggregate is not an empty class, then
each member of the aggregate shall be initialized with a value of the
form <TT>T()</TT> (5.2.3&nbsp;



 <A HREF="expr.html#expr.type.conv">expr.type.conv</A>), where <TT>T</TT>
represents the type of the uninitialized member.</P>

</BLOCKQUOTE>

</OL>

<P>
<I>This resolution also resolves
<A HREF="
     cwg_active.html#491">issue 491</A>.</I>
</P>

<P>
<B>Additional note (October, 2005):</B>
</P>

<P>Deleting 8.5.1&nbsp;



 <A HREF="decl.html#dcl.init.aggr">dcl.init.aggr</A> paragraph 8 altogether may
not be a good idea.  It would appear that, in its absence, the
initializer elision rules of paragraph 11 would allow the initializer
for <TT>a</TT> in the preceding example to be written <TT>{ 3 }</TT>
(because the empty-class member <TT>s</TT> would consume no
<I>initializer</I>s from the list).</P>

<BR>
<BR>
<HR>
<A NAME="452"></A>
<H4>452.
  
Wording nit on description of <TT>this</TT>
</H4>
<B>Section: </B>9.3.2&nbsp;



 <A HREF="class.html#class.this">class.this</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>review
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Gennaro Prota
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>8 Jan 2004<BR>


<P>9.3.2&nbsp;



 <A HREF="class.html#class.this">class.this</A> paragraph 1, which specifies the
meaning of the
keyword 'this', seems to limit its usage to the *body* of non-static
member functions. However 'this' is also usable in ctor-initializers
which, according to the grammar in
8.4&nbsp;



 <A HREF="decl.html#dcl.fct.def">dcl.fct.def</A> par. 1, are not
part of the body.</P>

<P>Proposed resolution: Changing the first part of
9.3.2&nbsp;



 <A HREF="class.html#class.this">class.this</A> par. 1 to:</P>
<BLOCKQUOTE>
  In the body of a nonstatic (9.3) member function <B>or in a
   ctor-initializer (12.6.2)</B>, the keyword <TT>this</TT> is a non-lvalue
   expression whose value is the address of the object for which
   the function is called.
</BLOCKQUOTE>
<P>NOTE: I'm talking of constructors as functions that are "called";
there have been discussions on c.l.c++.m as to whether constructors
are "functions" and to whether this terminology is correct or not; I
think it is both intuitive and in agreement with the standard wording.</P>

<P>
<U>Steve Adamczyk:</U> See also <A HREF="
     cwg_active.html#397">issue 397</A>,
which is defining a new syntax term for the body of a function
including the ctor-initializers.</P>

<P>
<B>Notes from the March 2004 meeting:</B>
</P>

<P>This will be resolved when
<A HREF="
     cwg_active.html#397">issue 397</A> is resolved.</P>

<P>
<B>Proposed resolution (October, 2005):</B>
</P>

<OL>

<LI>
<P>Change 8.4&nbsp;



 <A HREF="decl.html#dcl.fct.def">dcl.fct.def</A> paragraph 1 as indicated:</P>
</LI>

<BLOCKQUOTE>

<P>Function definitions have the form</P>

<P>
<UL>
<I>function-definition:</I>
<UL>
<I>decl-specifier-seq<SUB>opt</SUB> declarator <S>ctor-initializer<SUB>opt</SUB></S> function-body</I>
</UL>
<UL>
<I><S>decl-specifier-seq<SUB>opt</SUB> declarator function-try-block</S></I>
</UL>
<I>function-body:</I>
<UL>
<I><B>ctor-initializer</B> compound-statement</I>
</UL>
<UL>
<I><B>function-try-block</B></I>
</UL>
</UL>
</P>

<P>
<B>An informal reference to the body of a function should be
interpreted as a reference to the nonterminal <I>function-body</I>.</B>
</P>

</BLOCKQUOTE>

<LI>
<P>Change the definition of <I>function-try-block</I> in
15&nbsp;



 <A HREF="except.html#except">except</A> paragraph 1:</P>
</LI>

<BLOCKQUOTE>

<UL>
<I>function-try-block:</I>
<UL>
<TT>try</TT><I> ctor-initializer<SUB>opt</SUB> <S>function-body</S> <B>compound-statement</B> handler-seq</I>
</UL>
</UL>

</BLOCKQUOTE>

<LI>
<P>Change 3.3.6&nbsp;



 <A HREF="basic.html#basic.scope.class">basic.scope.class</A> paragraph 1, point 1, as
indicated:</P>
</LI>

<BLOCKQUOTE>

The potential scope of a name declared in a class consists not only of
the declarative region following the name's point of declaration, but
also of all function <S>bodies,</S> <B>bodies and</B> default
arguments<S>, and constructor <I>ctor-initializer</I>s</S> in that
class (including such things in nested classes).

</BLOCKQUOTE>

<LI>
<P>Change 3.3.6&nbsp;



 <A HREF="basic.html#basic.scope.class">basic.scope.class</A> paragraph 1, point 5, as
indicated:</P>
</LI>

<BLOCKQUOTE>

The potential scope of a declaration that extends to or past the end
of a class definition also extends to the regions defined by its
member definitions, even if the members are defined lexically outside
the class (this includes static data member definitions, nested class
definitions, member function definitions (including the member
function body <S>and, for constructor functions (12.1&nbsp;



 <A HREF="special.html#class.ctor">class.ctor</A>), the ctor-initializer (<sectionj_ref>12.6.2&nbsp;



 <A HREF="special.html#class.base.init">class.base.init</A></sectionj_ref>)</S>)
and any portion of the declarator part of such definitions which
follows the identifier, including a <I>parameter-declaration-clause</I>
and any default arguments (8.3.6&nbsp;



 <A HREF="decl.html#dcl.fct.default">dcl.fct.default</A>).
[<I>Example:</I>...

</BLOCKQUOTE>

<LI>
<P>Change footnote 32 in 3.4.1&nbsp;



 <A HREF="basic.html#basic.lookup.unqual">basic.lookup.unqual</A> paragraph 8
as indicated:</P>
</LI>

<BLOCKQUOTE>

That is, an unqualified name that occurs, for instance, in a type or
default argument expression in the <S><I>parameter-declaration-clause</I>,</S>
<B><I>parameter-declaration-clause</I> or</B> in the function body<S>,
or in an expression of a <I>mem-initializer</I> in a constructor
definition</S>.

</BLOCKQUOTE>

<LI>
<P>Change 5.1&nbsp;



 <A HREF="expr.html#expr.prim">expr.prim</A> paragraph 3 as indicated:</P>
</LI>

<BLOCKQUOTE>

...The keyword <TT>this</TT> shall be used only inside a non-static
class member function body (9.3&nbsp;



 <A HREF="class.html#class.mfct">class.mfct</A>) <S>or in a
constructor <I>mem-initializer</I> (12.6.2&nbsp;



 <A HREF="special.html#class.base.init">class.base.init</A>)</S>...

</BLOCKQUOTE>

<LI>
<P>Change 9.2&nbsp;



 <A HREF="class.html#class.mem">class.mem</A> paragraph 2 as indicated:</P>
</LI>

<BLOCKQUOTE>

...Within the class <I>member-specification</I>, the class is regarded as
complete within function bodies, default arguments, <B>and</B>
<I>exception-specification</I>s<S>, and constructor
<I>ctor-initializer</I>s</S> (including such things in nested classes)...

</BLOCKQUOTE>

<LI>
<P>Change 9.2&nbsp;



 <A HREF="class.html#class.mem">class.mem</A> paragraph 9 as indicated:</P>
</LI>

<BLOCKQUOTE>

Each occurrence in an expression of the name of a non-static data
member or non-static member function of a class shall be expressed as
a class member access (5.2.5&nbsp;



 <A HREF="expr.html#expr.ref">expr.ref</A>), except when it
appears in the formation of a pointer to member (5.3.1&nbsp;



 <A HREF="expr.html#expr.unary.op">expr.unary.op</A>)<S>, or</S> <B>or</B> when it appears in the body of
a non-static member function of its class or of a class derived from
its class (9.3.1&nbsp;



 <A HREF="class.html#class.mfct.nonstatic">class.mfct.nonstatic</A>)<S>, or when it appears in
a <I>mem-initializer</I> for a constructor for its class or for a
class derived from its class (12.6.2&nbsp;



 <A HREF="special.html#class.base.init">class.base.init</A>)</S>.

</BLOCKQUOTE>

<LI>
<P>Change the note in 9.3&nbsp;



 <A HREF="class.html#class.mfct">class.mfct</A> paragraph 5 as
indicated:</P>
</LI>

<BLOCKQUOTE>

[<I>Note:</I> a name used in a member function definition (that is, in the
<I>parameter-declaration-clause</I> including the default arguments
(8.3.6&nbsp;



 <A HREF="decl.html#dcl.fct.default">dcl.fct.default</A>)<S>, or</S> <B>or</B> in the member
function body<S>, or, for a constructor function (12.1&nbsp;



 <A HREF="special.html#class.ctor">class.ctor</A>), in a <TT>mem-initializer</TT> expression (12.6.2&nbsp;



 <A HREF="special.html#class.base.init">class.base.init</A>)</S>) is looked up as described in 3.4&nbsp;



 <A HREF="basic.html#basic.lookup">basic.lookup</A>. &mdash;<I>end note</I>]

</BLOCKQUOTE>

<LI>
<P>Change 9.3.1&nbsp;



 <A HREF="class.html#class.mfct.nonstatic">class.mfct.nonstatic</A> paragraph 1 as indicated:</P>
</LI>

<BLOCKQUOTE>

<P>...A non-static member function may also be called directly using
the function call syntax (5.2.2&nbsp;



 <A HREF="expr.html#expr.call">expr.call</A>, 13.3.1.1&nbsp;



 <A HREF="over.html#over.match.call">over.match.call</A>) <B>from within the body of a member function of its class or of a class derived from its class.</B>
</P>

<UL>
<S>
<LI>from within the body of a member function of its class or of a
class derived from its class, or</LI>
<LI>from a <I>mem-initializer</I> (12.6.2&nbsp;



 <A HREF="special.html#class.base.init">class.base.init</A>) for
a constructor for its class or for a class derived from its class.</LI>
</S>
</UL>

</BLOCKQUOTE>

<LI>
<P>Change 9.3.1&nbsp;



 <A HREF="class.html#class.mfct.nonstatic">class.mfct.nonstatic</A> paragraph 3 as indicated:</P>
</LI>

<BLOCKQUOTE>

When an <I>id-expression</I> (5.1&nbsp;



 <A HREF="expr.html#expr.prim">expr.prim</A>) that is not
part of a class member access syntax (5.2.5&nbsp;



 <A HREF="expr.html#expr.ref">expr.ref</A>)
and not used to form a pointer to member (5.3.1&nbsp;



 <A HREF="expr.html#expr.unary.op">expr.unary.op</A>) is used in the body of a non-static member function
of class <TT>X</TT> <S>or used in the <I>mem-initializer</I> for a
constructor of class <TT>X</TT></S>, if name lookup (3.4.1&nbsp;



 <A HREF="basic.html#basic.lookup.unqual">basic.lookup.unqual</A>) resolves the name in the <I>id-expression</I> to a
non-static non-type member of class <TT>X</TT> or of a base class
of <TT>X</TT>, the <I>id-expression</I> is transformed into a class
member access expression (5.2.5&nbsp;



 <A HREF="expr.html#expr.ref">expr.ref</A>)
using <TT>(*this)</TT> (9.3.2&nbsp;



 <A HREF="class.html#class.this">class.this</A>) as the
<I>postfix-expression</I> to the left of the <TT>.</TT>  operator...

</BLOCKQUOTE>

<LI>
<P>Change 12.1&nbsp;



 <A HREF="special.html#class.ctor">class.ctor</A> paragraph 7 as indicated:</P>
</LI>

<BLOCKQUOTE>

...The implicitly-defined default constructor performs the set of
initializations of the class that would be performed by a user-written
default constructor for that class with <S>an
empty <I>mem-initializer-list</I></S> <B>no <I>ctor-initializer</I></B> (12.6.2&nbsp;



 <A HREF="special.html#class.base.init">class.base.init</A>)
and an empty <S>function body</S> <B><I>compound-statement</I></B>...

</BLOCKQUOTE>

<LI>
<P>Change 12.6.2&nbsp;



 <A HREF="special.html#class.base.init">class.base.init</A> paragraph 4 as indicated:</P>
</LI>

<BLOCKQUOTE>

...After the call to a constructor for class <TT>X</TT> has completed, if a
member of <TT>X</TT> is neither specified in the constructor&rsquo;s
<I>mem-initializer</I>s, nor default-initialized, nor
value-initialized, nor given a value during execution
of <B>the <I>compound-statement</I> of</B> the body of the
constructor, the member has indeterminate value.

</BLOCKQUOTE>

<LI>
<P>Change the last bullet of 12.6.2&nbsp;



 <A HREF="special.html#class.base.init">class.base.init</A>
paragraph 5 as indicated:</P>
</LI>

<UL>
<LI>
<P>Finally, the <S>body</S> <B>compound statement</B> of the
constructor <B>body</B> is executed.</P>
</LI>
</UL>

<LI>
<P>Change 15&nbsp;



 <A HREF="except.html#except">except</A> paragraph 4 as indicated:</P>
</LI>

<BLOCKQUOTE>

<P>A <I>function-try-block</I> associates a <I>handler-seq</I> with the
<I>ctor-initializer</I>, if present, and the <S><I>function-body</I></S>
<B><I>compound-statement</I></B>. An exception thrown during the
execution of the initializer expressions in
the <I>ctor-initializer</I> or during the execution of
the <S><I>function-body</I></S> <B><I>compound-statement</I></B>
transfers control to a handler in a
<I>function-try-block</I> in the same way as an exception thrown
during the execution of a <I>try-block</I> transfers control to other
handlers. [<I>Example:</I>
</P>

<PRE>
    int f(int);
    class C {
        int i;
        double d;
    public:
        C(int, double);
    };

    C::C(int ii, double id)
    try
        : i(f(ii)), d(id)
    {
        //<SPAN STYLE="font-family:Times"><I> constructor <S>function body</S> <B>statements</B></I></SPAN>
    }
    catch (...)
    {
        //<SPAN STYLE="font-family:Times"><I> handles exceptions thrown from the ctor-initializer</I></SPAN>
        //<SPAN STYLE="font-family:Times"><I> and from the constructor <S>function body</S> <B>statements</B></I></SPAN>
    }
</PRE>

<P>&mdash;<I>end example</I>]</P>

</BLOCKQUOTE>

<LI>
<P>Change 15.2&nbsp;



 <A HREF="except.html#except.ctor">except.ctor</A> paragraph 2 as indicated:</P>
</LI>

<BLOCKQUOTE>

When an exception is thrown, control is transferred to the nearest
handler with a matching type (15.3&nbsp;



 <A HREF="except.html#except.handle">except.handle</A>);
&ldquo;nearest&rdquo; means the handler for which the
<S><I>compound-statement</I>,</S> <B><I>compound-statement</I>
or</B> <I>ctor-initializer</I><S>, or <I>function-body</I></S> following
the <TT>try</TT> keyword was most recently entered by the thread of
control and not yet exited.

</BLOCKQUOTE>

</OL>

<BR>
<BR>
<HR>
<A NAME="454"></A>
<H4>454.
  
When is a definition of a static data member required?
</H4>
<B>Section: </B>9.4.2&nbsp;



 <A HREF="class.html#class.static.data">class.static.data</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>review
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Gennaro Prota
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>18 Jan 2004<BR>


<P>As a result of the resolution of <A HREF="
     cwg_defects.html#48">core issue 48</A>, the current C++ standard is not in sync with existing
practice and with user expectations as far as definitions of static
data members having const integral or const enumeration type are
concerned. Basically what current implementations do is to require a
definition only if the address of the constant is taken. Example:</P>
<PRE>
void f() {

  std::string s;
  ... 

  // current implementations don't require a definition
  if (s.find('a', 3) == std::string::npos) {
   ...
  }
</PRE>
<P>To the letter of the standard, though, the above requires a
definition of <TT>npos</TT>, since the
expression <TT>std::string::npos</TT> is potentially evaluated. I
think this problem would be easily solved with simple changes to
9.4.2&nbsp;



 <A HREF="class.html#class.static.data">class.static.data</A> paragraph 4, 9.4.2&nbsp;



 <A HREF="class.html#class.static.data">class.static.data</A> paragraph 5 and 3.2&nbsp;



 <A HREF="basic.html#basic.def.odr">basic.def.odr</A> paragraph
3.</P>


<P>Suggested resolution:</P>

<P>Replace 9.4.2&nbsp;



 <A HREF="class.html#class.static.data">class.static.data</A> paragraph 4 with:</P>
<BLOCKQUOTE>
<P>If a static data member is of const integral or const enumeration
type, its declaration in the class definition can specify a
constant-initializer which shall be [note1] an integral constant
expression (5.19). In that case, the member can appear in integral
constant expressions. No definition of the member is required, unless
an lvalue expression that designates it is potentially evaluated and
either used as operand to the built-in unary &amp; operator [note 2] or
directly bound to a reference.</P>

<P>If a definition exists, it shall be at namespace scope and shall not
contain an initializer.</P>
</BLOCKQUOTE>

<P>In 9.4.2&nbsp;



 <A HREF="class.html#class.static.data">class.static.data</A> paragraph 5 change</P>
<BLOCKQUOTE>
There shall be exactly one definition of a static data member that is
used in a program; no diagnostic is required; see 3.2.
</BLOCKQUOTE>
<P>to</P>
<BLOCKQUOTE>
Except as allowed by 9.4.2 par. 4, there shall be exactly one
definition of a static data member that is potentially evaluated (3.2)
in a program; no diagnostic is required.
</BLOCKQUOTE>

<P>In 3.2&nbsp;



 <A HREF="basic.html#basic.def.odr">basic.def.odr</A> paragraph 3 add, at the beginning:</P>
<BLOCKQUOTE>
Except for the omission allowed by 9.4.2, par. 4, ...
</BLOCKQUOTE>


<P>[note 1] Actually it shall be a "= followed by a constant-expression".
This could probably be an editorial fix, rather than a separate DR.</P>


<P>[note 2] Note that this is the case when reinterpret_cast-ing to a
reference, like in
<PRE>
struct X { static const int value = 0; };
const char &amp; c = reinterpret_cast&lt;const char&amp;&gt;(X::value);
</PRE>
 
See 5.2.10&nbsp;



 <A HREF="expr.html#expr.reinterpret.cast">expr.reinterpret.cast</A>/10</P>

<P>
<I>More information, in response to a question about why
<A HREF="
     cwg_defects.html#48">issue 48</A> does not resolve the problem:</I>
</P>

<P>The problem is that the issue was settled in a way that solves much
less than it was supposed to solve; that's why I decided to file, so
to speak, a DR on a DR.</P>

<P>I understand this may seem a little 'audacious' on my part, but please
keep reading. Quoting from the text of DR 48 (emphasis mine):</P>
<BLOCKQUOTE>
 <P>
 Originally, all static data members still had to be defined
  outside the class whether they were used or not.</P>

  <P>But that restriction was supposed to be lifted [...]</P>

  <P>In particular, if an integral/enum const static data member is
  initialized within the class, <I>and its address is never taken</I>,
  we agreed that no namespace-scope definition was required.</P>
</BLOCKQUOTE>

<P>The corresponding resolution doesn't reflect this intent, with the
definition being still required in most situations anyway: it's enough
that the constant appears outside a place where constants are
<I>required</I> (ignoring the obvious cases of sizeof and typeid) and you
have to provide a definition. For instance:</P>
<PRE>
  struct X {
   static const int c = 1;
  };

  void f(int n)
  {
   if (n == X::c)   // &lt;-- potentially evaluated
    ...
  }
</PRE>

<P>&lt;start digression&gt;</P>

<P>Most usages of non-enum BOOST_STATIC_COSTANTs, for instance, are (or
were, last time I checked) non-conforming. If you recall, Paul
Mensonides pointed out that the following template</P>
<PRE>
// map_integral

template&lt;class T, T V&gt; struct map_integral : identity&lt;T&gt; {
  static const T value = V;
};

template&lt;class T, T V&gt; const T map_integral&lt;T, V&gt;::value;
</PRE>

<P>whose main goal is to map the same couples (type, value) to the same
storage, also solves the definition problem. In this usage it is an
excellent hack (if your compiler is good enough), but IMHO still a
hack on a language defect.</P>

<P>&lt;end digression&gt;</P>

<P>What I propose is to solve the issue according to the original intent,
which is also what users expect and all compilers that I know of
already do. Or, in practice, we would have a rule that exists only as
words in a standard document.</P>

<P>PS: I've sent a copy of this to Mr. Adamczyk to clarify an important
doubt that occurred to me while writing this reply:</P>

<P>if no definition is provided for an integral static const data member
is that member an object? Paragraph 1.8/1 seems to say no, and in fact
it's difficult to think it is an object without assuming/pretending
that a region of storage exists for it (an object *is* a region of
storage according to the standard).</P>

<P>I would think that when no definition is required we have to assume
that it could be a non-object. In that case there's nothing in 3.2
which says what 'used' means for such an entity and the current
wording would thus be defective. Also, since the name of the member is
an lvalue and 3.10/2 says an lvalue refers to an object we would have
another problem.</P>

<P>OTOH the standard could pretend it is always an object (though the
compiler can optimize it away) and in this case it should probably
make a special case for it in 3.2/2.</P>

<P>
<B>Notes from the March 2004 meeting:</B>
</P>

<P>We sort of like this proposal, but we don't feel it has very
high priority.  We're not going to spend time discussing it, but
if we get drafting for wording we'll review it.</P>

<P>
<B>Proposed resolution (October, 2005):</B>
</P>

<OL>
<LI>
<P>Change the first two sentences of 3.2&nbsp;



 <A HREF="basic.html#basic.def.odr">basic.def.odr</A>
paragraph 2 from:</P>

<BLOCKQUOTE>

An expression is <I>potentially evaluated</I> unless it appears where
an integral constant expression is required (see 5.19&nbsp;



 <A HREF="expr.html#expr.const">expr.const</A>), is the operand of the <TT>sizeof</TT> operator
(5.3.3&nbsp;



 <A HREF="expr.html#expr.sizeof">expr.sizeof</A>), or is the operand of
the <TT>typeid</TT> operator and the expression does not designate an
lvalue of polymorphic class type (5.2.8&nbsp;



 <A HREF="expr.html#expr.typeid">expr.typeid</A>). An
object or non-overloaded function is <I>used</I> if its name appears
in a potentially-evaluated expression.

</BLOCKQUOTE>

<P>to</P>

<BLOCKQUOTE>

An expression that is the operand of the <TT>sizeof</TT> operator
(5.3.3&nbsp;



 <A HREF="expr.html#expr.sizeof">expr.sizeof</A>) is <I>unevaluated</I>, as is an
expression that is the operand of the <TT>typeid</TT> operator if it
is not an lvalue of a polymorphic class type (5.2.8&nbsp;



 <A HREF="expr.html#expr.typeid">expr.typeid</A>); all other expressions are <I>potentially
evaluated</I>. An object or non-overloaded function whose name appears
as a potentially-evaluated expression is <I>used</I>, unless it is an
object that satisfies the requirements for appearing in an integral
constant expression (5.19&nbsp;



 <A HREF="expr.html#expr.const">expr.const</A>) and the lvalue-to-rvalue
conversion (4.1&nbsp;



 <A HREF="conv.html#conv.lval">conv.lval</A>) is immediately applied.

</BLOCKQUOTE>

</LI>

<LI>
<P>Change the first sentence of 9.4.2&nbsp;



 <A HREF="class.html#class.static.data">class.static.data</A>
paragraph 2 as indicated:</P>
</LI>

<BLOCKQUOTE>

If a static data member is of const integral or const enumeration
type, its declaration in the class definition can specify a
<I>constant-initializer</I> <S>which</S> <B>whose <I>constant-expression</I></B>
shall be an integral constant expression (5.19&nbsp;



 <A HREF="expr.html#expr.const">expr.const</A>).

</BLOCKQUOTE>

</OL>

<BR>
<BR>
<HR>
<A NAME="58"></A>
<H4>58.
  
Signedness of bit fields of enum type
</H4>
<B>Section: </B>9.6&nbsp;



 <A HREF="class.html#class.bit">class.bit</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>review
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Steve Adamczyk
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>13 Oct 1998<BR>



<P>Section 9.6&nbsp;



 <A HREF="class.html#class.bit">class.bit</A>

paragraph 4 needs to be more specific about the signedness of bit
fields of enum type. How much leeway does an implementation have
in choosing the signedness of a bit field? In particular, does the
phrase "large enough to hold all the values of the enumeration" mean "the
implementation decides on the signedness, and then we see whether all the
values will fit in the bit field", or does it require the implementation
to make the bit field signed or unsigned if that's what it takes to make
it "large enough"?</P>

<P>(See also <A HREF="
     cwg_defects.html#172">issue 172</A>.)</P>



<P>
<B>Note (March, 2005):</B> Clark Nelson observed that there is
variation among implementations on this point.  </P>

<P>
<B>Notes from April, 2005 meeting:</B>
</P>

<P>Although implementations enjoy a great deal of latitude in handling
bit-fields, it was deemed more user-friendly to ensure that the
example in paragraph 4 will work by requiring implementations to use
an unsigned underlying type if the enumeration type has no negative
values.  (If the implementation is allowed to choose a signed
representation for such bit-fields, the comparison against
<TT>TRUE</TT> will be <TT>false</TT>.)</P>

<P>In addition, it was observed that there is an apparent circularity
between 7.2&nbsp;



 <A HREF="dcl.html#dcl.enum">dcl.enum</A> paragraph 7 and 9.6&nbsp;



 <A HREF="class.html#class.bit">class.bit</A> paragraph 4 that should be resolved.
</P>

<P>
<B>Proposed resolution (October, 2005):</B>
</P>

<P>Replace 7.2&nbsp;



 <A HREF="dcl.html#dcl.enum">dcl.enum</A> paragraph 7, deleting the
embedded footnote 85, with the following:</P>

<BLOCKQUOTE>

For an enumeration where <I>e<SUB>min</SUB></I> is the smallest
enumerator and <I>e<SUB>max</SUB></I> is the largest, the values of
the enumeration are the values in the range <I>b<SUB>min</SUB></I> to
<I>b<SUB>max</SUB></I>, defined as follows: Let <I>K</I> be 1 for a
two's complement representation and 0 for a one's complement or
sign-magnitude representation.  <I>b<SUB>max</SUB></I> is the smallest
value greater than or equal to
max(|<I>e<SUB>min</SUB></I>|-<I>K</I>,|<I>e<SUB>max</SUB></I>|) and
equal to 2<I><SUP>M</SUP></I>-1, where <I>M</I> is a non-negative
integer.  <I>b<SUB>min</SUB></I> is zero if <I>e<SUB>min</SUB></I> is
non-negative and -(<I>b<SUB>max</SUB></I>+<I>K</I>) otherwise.  The
size of the smallest bit-field large enough to hold all the values of
the enumeration type is max(<I>M</I>,1) if <I>b<SUB>min</SUB></I> is
zero and <I>M</I>+1 otherwise.  It is possible to define an
enumeration that has values not defined by any of its enumerators.

</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="484"></A>
<H4>484.
  
Can a <I>base-specifier</I> name a cv-qualified class type?
</H4>
<B>Section: </B>10&nbsp;



 <A HREF="derived.html#class.derived">class.derived</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>review
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Richard Corden
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>21 Oct 2004<BR>


<P>
<A HREF="
     cwg_defects.html#298">Issue 298</A>, recently approved,
affirms that cv-qualified class types can be used as
<I>nested-name-specifier</I>s.  Should the same be true for
<I>base-specifier</I>s?</P>

<P>
<B>Rationale (April, 2005):</B>
</P>

<P>The resolution of <A HREF="
     cwg_defects.html#298">issue 298</A> added
new text to 9.1&nbsp;



 <A HREF="class.html#class.name">class.name</A> paragraph 5 making it
clear that a typedef that names a cv-qualified class type is a
<I>class-name</I>.  Because the definition of <I>base-specifier</I>
simply refers to <I>class-name</I>, it is already the case that
cv-qualified class types are permitted as <I>base-specifier</I>s.</P>

<P>
<B>Additional notes (June, 2005):</B>
</P>

<P>It's not completely clear what it means to have a cv-qualified
type as a <I>base-specifier</I>.  The original proposed resolution
for <A HREF="
     cwg_defects.html#298">issue 298</A> said that &ldquo;the
cv-qualifiers are ignored,&rdquo; but that wording is not in the
resolution that was ultimately approved.</P>

<P>If the cv-qualifiers are <I>not</I> ignored, does that mean that
the base-class subobject should be treated as always similarly
cv-qualified, regardless of the cv-qualification of the derived-class
lvalue used to access the base-class subobject?  For instance:</P>

<PRE>
    typedef struct B {
        void f();
        void f() const;
        int i;
    } const CB;

    struct D: CB { };

    void g(D* dp) {
        dp-&gt;f();    // which B::f?
        dp-&gt;i = 3;  // permitted?
    }
</PRE>

<P>
<B>Proposed resolution (October, 2005):</B>
</P>

<OL>
<LI>
<P>Change 9.1&nbsp;



 <A HREF="class.html#class.name">class.name</A> paragraph 5 as indicated:</P>
</LI>

<BLOCKQUOTE>

A <I>typedef-name</I> (7.1.3&nbsp;



 <A HREF="dcl.html#dcl.typedef">dcl.typedef</A>) that names a
class type, or a cv-qualified version thereof, is also
a <S><I>class-name</I>, but</S> <B><I>class-name</I>. If
a <I>typedef-name</I> that names a cv-qualified class type is used
where a <I>class-name</I> is required, the cv-qualifiers are ignored.
A <I>typedef-name</I></B> shall not be used as the <I>identifier</I>
in a
<I>class-head</I>.

</BLOCKQUOTE>

<LI>
<P>Delete 7.1.3&nbsp;



 <A HREF="dcl.html#dcl.typedef">dcl.typedef</A> paragraph 8:</P>
</LI>

<BLOCKQUOTE>

<P>[<I>Note:</I> if the <I>typedef-name</I> is used where
a <I>class-name</I> (or <I>enum-name</I>) is required, the program is
ill-formed. For example,</P>

<PRE>
    typedef struct {
        S();     //<SPAN STYLE="font-family:Times"><I> error: requires a return type because </I><TT>S</TT><I> is</I></SPAN>
                  //<SPAN STYLE="font-family:Times"><I> an ordinary member function, not a constructor</I></SPAN>
    } S;
</PRE>

<P>&mdash;<I>end note</I>]</P>

</BLOCKQUOTE>

</OL>

<BR>
<BR>
<HR>
<A NAME="494"></A>
<H4>494.
  
Problems with the resolution of issue 45
</H4>
<B>Section: </B>11&nbsp;



 <A HREF="access.html#class.access">class.access</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>review
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Lloyd J. Lewins
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>17 Dec 2004<BR>


<P>The proposed resolution for <A HREF="
     cwg_defects.html#45">issue 45</A> inserts the following sentence after 11&nbsp;



 <A HREF="access.html#class.access">class.access</A> paragraph 1:</P>

<BLOCKQUOTE>
A member of a class can also access all names as the class of
which it is a member.
</BLOCKQUOTE>

<P>I don't think that this is correctly constructed English. I see two
possibilities:</P>

<OL>
<LI>
<P>
This is a typo, and the correct change is:

<BLOCKQUOTE>
A member of a class can also access all names of the class of which
it is a member.
</BLOCKQUOTE>
</P>
</LI>

<LI>
<P>
The intent is something more like:

<BLOCKQUOTE>
A member of a nested class can also access all names accessible by
any other member of the class of which it is a member.
</BLOCKQUOTE>
</P>
</LI>
</OL>

<P>[Note: this was editorially corrected at the time defect
resolutions were being incorporated into the Working Paper to
read, &ldquo;...can also access all the names declared in the
class of which it is a member,&rdquo; which is essentially the
same as the preceding option 1.]</P>

<P>I would prefer to use the language proposed for 11.8&nbsp;



 <A HREF="access.html#class.access.nest">class.access.nest</A>:</P>

<BLOCKQUOTE>
A nested class is a member and as such has the same access rights
as any other member.
</BLOCKQUOTE>

<P>A second problem is with the text in 11.4&nbsp;



 <A HREF="access.html#class.friend">class.friend</A> paragraph 2:</P>

<BLOCKQUOTE>

[<I>Note:</I> this means that access to private and protected
names is also granted to member functions of the friend class (as
if the functions were each friends) and to the static data member
definitions of the friend class. This also means that private and
protected type names from the class granting friendship can be
used in the <I>base-clause</I> of a nested class of the friend
class. However, the declarations of members of classes nested
within the friend class cannot access the names of private and
protected members from the class granting friendship. Also,
because the <I>base-clause</I> of the friend class is not part of
its member declarations, the <I>base-clause</I> of the friend
class cannot access the names of the private and protected
members from the class granting friendship. For example,

<PRE>
    class A {
        class B { };
        friend class X;
    };
    class X : A::B {     //<SPAN STYLE="font-family:Times"><I> ill-formed: </I></SPAN>A::B<SPAN STYLE="font-family:Times"><I> cannot be accessed</I></SPAN>
                         //<SPAN STYLE="font-family:Times"><I> in the base-clause for </I></SPAN>X
        A::B mx;         //<SPAN STYLE="font-family:Times"><I> OK: </I></SPAN>A::B<SPAN STYLE="font-family:Times"><I> used to declare member of </I></SPAN>X
        class Y: A::B {  //<SPAN STYLE="font-family:Times"><I> OK: </I></SPAN>A::B<SPAN STYLE="font-family:Times"><I> used to declare member of </I></SPAN>X
            A::B my;     //<SPAN STYLE="font-family:Times"><I> ill-formed: </I></SPAN>A::B<SPAN STYLE="font-family:Times"><I> cannot be accessed</I></SPAN>
                         //<SPAN STYLE="font-family:Times"><I> to declare members of nested class of </I></SPAN>X
        };
    };
</PRE>
&mdash;<I>end note</I>]

</BLOCKQUOTE>

<P>
This seems to be an oversight. The proposed change to
11.8&nbsp;



 <A HREF="access.html#class.access.nest">class.access.nest</A> paragraph 1 would appear to have
eliminated the restrictions on nested class access.  However, at
least one compiler (gcc 3.4.3) doesn't appear to take my view,
and continues with the restrictions on access by classes within a
friend class, while implementing the rest of the resolution of
<A HREF="
     cwg_defects.html#45">issue 45</A>.
</P>

<P>
<B>Note (March, 2005):</B>
</P>



<P>
<U>Andreas Hommel</U>: I think <A HREF="
     cwg_defects.html#45">issue 45</A>
requires an additional change in 9.7&nbsp;



 <A HREF="class.html#class.nest">class.nest</A> paragraph
4:</P>

<BLOCKQUOTE>

Like a member function, a friend function (11.4&nbsp;



 <A HREF="access.html#class.friend">class.friend</A>)
defined within a nested class is in the lexical scope of that class;
it obeys the same rules for name binding as a static member function
of that class (9.4&nbsp;



 <A HREF="class.html#class.static">class.static</A>) and has no special access
rights to members of an enclosing class.

</BLOCKQUOTE>

<P>I believe the &ldquo;no special access rights&rdquo;
language should be removed.</P>

<P>
<B>Proposed resolution (October, 2005):</B>
</P>

<P>This issue is resolved by the resolution of <A HREF="
     cwg_active.html#372">issue 372</A>.</P>

<BR>
<BR>
<HR>
<A NAME="500"></A>
<H4>500.
  
Access in <I>base-specifier</I>s of friend and nested classes
</H4>
<B>Section: </B>11.4&nbsp;



 <A HREF="access.html#class.friend">class.friend</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>review
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Andreas Hommel
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>25 Jan 2005<BR>




<P>I don't know the reason for this distinction, but it seems to be
surprising that <TT>Base::A</TT> is legal and <TT>D</TT> is illegal in
this example:
</P>

<PRE>
    class D;
    class Base 
    { 
        class A;
        class B;
        friend class D;
    }; 
    class Base::B 
    {
    };
    class Base::A : public Base::B  // OK because of issue 45
    { 
    };
    class D : public Base::B        // illegal because of 11.4p4
    { 
    };
</PRE>

<P>Shouldn't this be consistent (either way)?</P>

<P>
<B>Notes from the April, 2005 meeting:</B>
</P>

<P>In discussing <A HREF="
     cwg_active.html#372">issue 372</A>, the CWG decided
that access in the <I>base-specifier</I>s of a class should be the
same as for its members, and that resolution will apply
to <TT>friend</TT> declarations, as well.</P>

<P>
<B>Proposed resolution (October, 2005):</B>
</P>

<P>This issue is resolved by the resolution of <A HREF="
     cwg_active.html#372">issue 372</A>.</P>

<BR>
<BR>
<HR>
<A NAME="301"></A>
<H4>301.
  
Syntax for <I>template-name</I>
</H4>
<B>Section: </B>14.2&nbsp;



 <A HREF="template.html#temp.names">temp.names</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>review
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Mark Mitchell
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>24 Jul 2001<BR>




<P>The grammar for a <I>template-name</I> is:</P>
<UL>
<I>template-name</I>:
<UL>
<I>identifier</I>
</UL>
</UL>

<P>That's not right; consider:</P>
<PRE>
    template &lt;class T&gt; T operator+(const T&amp;, const T&amp;);
    template &lt;&gt; S operator+&lt;S&gt;(const S&amp;, const S&amp;);
</PRE>

<P>This is ill-formed according to the standard, since <TT>operator+</TT> is
not a template-name.</P>

<P>
<B>Suggested resolution:</B>
</P>

<P>I think the right rule is</P>
<UL>
<I>template-name:</I>
<UL>
<I>identifier</I>
<BR>
<I>operator-function-id</I>
<BR>
<I>conversion-function-id</I>
</UL>
</UL>

<P>John Spicer adds that there's some question about whether
conversion functions should be included, as they cannot have template
argument lists.</P>

<P>
<B>Notes from 4/02 meeting:</B>
</P>

<P>If the change is made as a syntax change, we'll need a semantic
restriction to avoid <TT>operator+&lt;int&gt;</TT> as a class.
Clark Nelson will work on a compromise proposal -- not the minimal
change to the syntax proposed, not the maximal change either.</P>

<P>
<B>Clark Nelson (April 2003):</B>
</P>

<P> The proposed solution (adding <I>operator-function-id</I> as an
alternative for <I>template-name</I>) would have a large impact on
the language described by the grammar.  Specifically, for example,
<TT>operator+&lt;int&gt;</TT> would become a syntactically valid
<I>class-name</I>.  </P>

<P> On the other hand, a change with (I believe) exactly the desired
effect on the language accepted, would be to modify
<I>operator-function-id</I> itself: </P>

<UL>
<I>operator-function-id</I>:
<UL>
<TT>operator</TT> <I>operator</I>
<BR>
<B><TT>operator</TT> <I>operator</I> <TT>&lt;</TT>
<I>template-argument-list<SUB>opt</SUB></I> <TT>&gt;</TT></B>
</UL>
</UL>

<P>
<I>(Steve Adamczyk: this change was already made by
<A HREF="
     cwg_defects.html#38">issue 38</A> and is in TC1.)</I>
</P>

<P> Then there is the first sentence of 14.2&nbsp;



 <A HREF="template.html#temp.names">temp.names</A>
paragraph 3: </P>

<BLOCKQUOTE> After name lookup (3.4&nbsp;



 <A HREF="basic.html#basic.lookup">basic.lookup</A>)
finds that a name is a
<I>template-name</I>, if this name is followed by a
<TT>&lt;</TT>, the <TT>&lt;</TT> is always taken as the
beginning of a <I>template-argument-list</I> and never as a name
followed by the less-than operator.  </BLOCKQUOTE>

<P> This description seems to be adequate for names of class templates.
As far as I can tell, the only ambiguity it resolves is from something
that starts with <TT>new X &lt;</TT>, in the
scope of a class template <TT>X</TT>.  But as far as I can tell is
already inadequate for names of function templates, and is even worse
for operator function templates.  </P>

<P>Probably <TT>&lt;</TT> should always be interpreted as
introducing a <I>template-argument-list</I> if any member of the
overload set is a function template.  After all, function pointers are
very rarely compared for ordering, and it's not clear what other rule
might be workable.  </P>

<P> I'm inclined to propose the simplest rule possible for
<I>operator-function-ids</I>: if one is followed by
<TT>&lt;</TT>, then what follows is interpreted as a
<I>template-argument-list</I>, unconditionally.  Of course, if no
template for that operator has been declared, then there's an error.
</P>

<P> Also, note that if the operator in question is <TT>&lt;</TT> or <TT>&lt;&lt;</TT>, it is possible to run into a problem similar to the famous <TT>&gt;&gt;</TT> nested template argument list closing delimiter problem.
However, since in this case (at least) one of the <TT>&lt;</TT> characters has a radically different interpretation than the other, and for other reasons as well, this is unlikely to be nearly as much of a practical problem as the <TT>&gt;&gt;</TT> problem.
</P>

<P>
<B>Notes from April 2003 meeting:</B>
</P>

<P>We felt that the operator functions should not be special-cased.
They should be treated like any other name.</P>

<P>
<B>September 2003:</B>
</P>

<P>Clark Nelson has provided the changes in N1490=03-0073.</P>

<P>
<B>Notes from October 2003 meeting:</B>
</P>

<P>We reviewed Clark Nelson's N1490.  Clark will revise it and
introduce a new syntax term for an identifier or
the name of an operator function.</P>

<P>
<B>Notes from the April, 2005 meeting:</B>
</P>

<P>The CWG suggested a new approach to resolving this issue: the
existing term <I>template-id</I> will be renamed
to <I>class-template-id</I>, the term <I>template-id</I> will be
defined to include operator functions with template arguments, and any
current uses of <I>template-id</I> (such as in the definition
of <I>elaborated-type-specifier</I>) where an operator function is not
appropriate will be changed to refer to <I>class-template-id</I>.</P>

<P>
<B>Proposed resolution (October, 2005):</B>
</P>

<P>As specified in document J16/05-0156 = WG21 N1896.</P>

<BR>
<BR>
<HR>
<A NAME="468"></A>
<H4>468.
  
Allow <TT>::template</TT> outside of templates
</H4>
<B>Section: </B>14.2&nbsp;



 <A HREF="template.html#temp.names">temp.names</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>review
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>John Spicer
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>9 Apr 2004<BR>


<P>For the same reasons that <A HREF="
     cwg_defects.html#382">issue 382</A>
proposes for relaxation of the requirements on <TT>typename</TT>,
it would make sense to allow the <TT>::template</TT> disambiguator
outside of templates.</P>

<P>See also issues <A HREF="
     cwg_defects.html#11">11</A>,
<A HREF="
     cwg_defects.html#30">30</A>,
<A HREF="
     cwg_active.html#96">96</A>, and <A HREF="
     cwg_closed.html#109">109</A>.</P>

<P>
<B>Proposed resolution (October, 2005):</B>
</P>

<P>Change 14.2&nbsp;



 <A HREF="template.html#temp.names">temp.names</A> paragraph 5 as indicated:</P>

<BLOCKQUOTE>

If a name prefixed by the keyword <TT>template</TT> is not the name of
a template, the program is ill-formed. [<I>Note:</I> the
keyword <TT>template</TT> may not be applied to non-template members
of class templates. &mdash;<I>end note</I>] <S>Furthermore, names of
member templates shall not be prefixed by the
keyword <TT>template</TT> if the <I>postfix-expression</I>
or <I>qualified-id</I> does not appear in the scope of a template.</S>
[<I>Note:</I> just as is the case with the <TT>typename</TT> prefix,
the <TT>template</TT> prefix is allowed in cases where it is not
strictly necessary; i.e., when <B>the <I>nested-name-specifier
or</I></B> the expression on the left of the <TT>-&gt;</TT>
or <TT>.</TT><S>, or the <I>nested-name-specifier</I></S> is not
dependent on a <I>template-parameter</I><B>, or the use does not
appear in the scope of a template</B>. &mdash;<I>end note</I>]

</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="372"></A>
<H4>372.
  
Is access granted by base class specifiers available in following base class specifiers?
</H4>
<B>Section: </B>14.3&nbsp;



 <A HREF="template.html#temp.arg">temp.arg</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>review
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Clark Nelson
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>13 August 2002<BR>


<P>I'm not really sure what the standard
says about this. Personally, I'd like for it to be ill-formed, but I can't
find any words that I can interpret to say so.</P>
<PRE>
  template&lt;class T&gt;
  class X
  {
  protected:
    typedef T Type;
  };
  template&lt;class T&gt;
  class Y
  {
  };
  template&lt;class T,
           template&lt;class&gt; class T1,
           template&lt;class&gt; class T2&gt;
  class Z:
    public T2&lt;typename T1&lt;T&gt;::Type&gt;,
    public T1&lt;T&gt;
  {
  };
  Z&lt;int, X, Y&gt; z;
</PRE>
<P>
<U>John Spicer</U>:
I don't think the standard really addresses this case.  There
is wording about access checking of things used as template arguments,
but that doesn't address accessing members of the template argument
type (or template) from within the template.</P>

<P>This example is similar, but does not use template template arguments.</P>
<PRE>
  class X {
  private:
    struct Type {};
  };
  template &lt;class T&gt; struct A {
    typename T::Type t;
  };
  A&lt;X&gt; ax;
</PRE>

<P>This gets an error from most compilers, though the standard is probably
mute on this as well.  An error makes sense -- if there is no error,
there is a hole in the access checking.  (The special rule about
no access checks on template parameters is not a hole, because the access
is checked on the type passed in as an argument.  But when you look
up something in the scope of a template parameter type, you need to
check the access to the member found.)</P>

<P>The logic in the template template parameter case should be similar:
anytime you look up something in a template-dependent class, the
member's access must be checked, because it could be different for
different template instances.</P>

<P>
<B>Proposed Resolution (October 2002):</B>
</P>

<P>Change the last sentence of 14.3&nbsp;



 <A HREF="template.html#temp.arg">temp.arg</A>
paragraph 3 from:
<BLOCKQUOTE>
For a <I>template-argument</I> of class type, the template definition has no
special access rights to the inaccessible members of the template
argument type.
</BLOCKQUOTE>
to:
<BLOCKQUOTE>
For a <I>template-argument</I> that is a class type or a class template, the
template definition has no special access rights to the members
of the <I>template-argument</I>.  [<I>Example</I>:
<PRE>
  template &lt;template &lt;class TT&gt; class T&gt; class A {
    typename T&lt;int&gt;::S s;
  };

  template &lt;class U&gt; class B {
    private:
    struct S { /* ... */ };
  };

  A&lt;B&gt; b;   // ill-formed, A has no access to B::S
</PRE>
-- <I>end example</I>]
</BLOCKQUOTE>
</P>

<P>
<B>Daniel Frey posts on comp.std.c++ in July 2003:</B>
I just read DR 372 and I think that the problem presented is not really 
discussed/solved properly. Consider this example:</P>
<PRE>
  class A {
  protected:
     typedef int N;
  };

  template&lt; typename T &gt;
  class B
  {};

  template&lt; typename U &gt;
  class C : public U, public B&lt; typename U::N &gt;
  {};

  C&lt; A &gt; x;
</PRE>
<P>The question is: If C is derived from A as above, is it allowed to 
access A::N before the classes opening '{'?</P>

<P>The main problem is that you need to access U's protected parts in C's 
base-clause. This pattern is common when using policies, Andrei's Loki 
library was bitten by it as he tried to make some parts of the policies 
'protected' but some compilers rejected the code. They were right to 
reject it, I think it's
11.4&nbsp;



 <A HREF="access.html#class.friend">class.friend</A>/2 that applies here and prevents the code 
above to be legal, although it addresses a different and reasonable 
example. To me, it seems wrong to reject the code as it is perfectly 
reasonable to write such stuff. The questions are:</P>

<UL>
<LI>Do you agree it's reasonable?</LI>
<LI>Is it a DR or is it a request for an extension?</LI>
<LI>Is DR 372 the right place to address it or shall it be a new DR?</LI>
</UL>

<P>
<U>Steve Adamczyk:</U>
In other words, the point of the issue is over what range access derived
from base class specifiers is granted, and whether any part of that range 
is the base specifier list itself, either the parts afterwards or the whole 
base specifier list.  (Clark Nelson confirms this is what he was
asking with the original question.)
Personally, I find it somewhat disturbing that access might
arrive incrementally; I'd prefer that the access happen all 
at once, at the opening brace of the class.</P>

<P>
<B>Notes from October 2003 meeting:</B>
</P>

<P>We decided it makes sense to delay the access checking for the
base class specifiers until the opening brace of the class is
seen.  In other words, the base specifiers will be checked using
the full access available for the class, and the order of the
base classes is not significant in that determination. The
implementors present all said they already had code to handle
accumulation of delayed access checks, because it is already
needed in other contexts.</P>

<P>
<B>Proposed resolution (October, 2004):</B>
</P>

<OL>

<LI>
<P>Change the last sentence of 14.3&nbsp;



 <A HREF="template.html#temp.arg">temp.arg</A>
paragraph 3 as indicated:</P>

<BLOCKQUOTE>

For a <I>template-argument</I> <S>of</S> <B>that is a</B> class
type <B>or a class template</B>, the template definition
has no special access rights to the <S>inaccessible</S> members of the
<S>template argument type</S> <B><I>template-argument</I>.
[<I>Example:</I>

<PRE>
    template &lt;template &lt;class TT&gt; class T&gt; class A {
       typename T&lt;int&gt;::S s;
    };

    template &lt;class U&gt; class B {
       private:
       struct S { /* ... */ };
    };

    A&lt;B&gt; b;   // ill-formed, A has no access to B::S
</PRE>

<P>&mdash;<I>end example</I>]</P>

</B>

</BLOCKQUOTE>

</LI>

<LI>
<P>Insert the following as a new paragraph after the final
paragraph of 11&nbsp;



 <A HREF="access.html#class.access">class.access</A>:</P>

<BLOCKQUOTE>

<P>The access of names in a class <I>base-specifier-list</I> are
checked at the end of the list after all base classes are known.
[<I>Example:</I>
</P>

<PRE>
    class A {
      protected:
         typedef int N;
    };

    template&lt;typename T&gt; class B {};

    template&lt;typename U&gt; class C : public B&lt;typename U::N&gt;, public U {};

    C&lt;A&gt; x;  // OK: A is a base class so A::N in B&lt;A::N&gt; is accessible
</PRE>

</BLOCKQUOTE>

<P>&mdash;<I>end example</I>]</P>

</LI>

</OL>

<P>
<B>Notes from the April, 2005 meeting:</B>
</P>

<P>The 10/2004 resolution is not sufficient to implement the CWG's
intent to allow these examples: clause 11&nbsp;



 <A HREF="access.html#class.access">class.access</A>
paragraph 1 grants protected access only to &ldquo;members and
friends&rdquo; of derived classes, not to their
<I>base-specifier</I>s.  The resolution needs to be extended to say
either that access in <I>base-specifiers</I> is determined as if they
were members of the class being defined or that access is granted to
the class as an entity, including its <I>base-specifier</I>s.  See
also <A HREF="
     cwg_active.html#500">issue 500</A>, which touches on the same
issue and should be resolved in the same way.</P>

<P>
<B>Proposed resolution (October, 2005):</B>
</P>

<OL>

<LI>
<P>Change the second bullet of 11&nbsp;



 <A HREF="access.html#class.access">class.access</A> paragraph
1 as indicated:</P>

<UL>
<LI>
<P>
<TT>protected</TT>; that is, its name can be used only by
members and friends of the class in which it is declared, <S>and by
members and friends of classes derived from this class</S> <B>by
classes derived from that class, and by their friends</B> (see
11.5&nbsp;



 <A HREF="access.html#class.protected">class.protected</A>).</P>
</LI>
</UL>

</LI>

<LI>
<P>Change 11&nbsp;



 <A HREF="access.html#class.access">class.access</A> paragraph 2 as indicated:</P>

<BLOCKQUOTE>

A member of a class can also access all the names <S>declared in the
class of which it is a member</S> <B>to which the class has access</B>.

</BLOCKQUOTE>

</LI>

<LI>
<P>Change 11&nbsp;



 <A HREF="access.html#class.access">class.access</A> paragraph 6 as indicated:</P>

<BLOCKQUOTE>

All access controls in clause 11&nbsp;



 <A HREF="access.html#class.access">class.access</A> affect the
ability to access a class member name from a particular scope. <S>The
access control for names used in the definition of a class member that
appears outside of the member's class definition is done as if the
entire member definition appeared in the scope of the member's
class.</S> <B>For purposes of access control, the <I>base-specifier</I>s
of a class and the definitions of class members that appear outside of
the class definition are considered to be within the scope of that
class.</B> In particular...

</BLOCKQUOTE>

</LI>

<LI>
<P>Change the example and commentary in 11&nbsp;



 <A HREF="access.html#class.access">class.access</A>
paragraphs 6-7 as indicated:</P>

<BLOCKQUOTE>

<P>[<I>Example:</I>
</P>

<PRE>
    class A {
      typedef int I; //<SPAN STYLE="font-family:Times"><I> private member</I></SPAN>
      I f();
      friend I g(I);
      static I x;
    <B>protected:
      struct B { };</B>
    };

    A::I A::f () { return 0; }
    A::I g(A::I p = A::x);
    A::I g(A::I p ) { return 0; }
    A::I A::x = 0;

    <B>struct D: A::B, A { };</B>
</PRE>

Here, all the uses of <TT>A::I</TT> are well-formed
because <TT>A::f</TT> and <TT>A::x</TT> are members of
class <TT>A</TT> and <TT>g</TT> is a friend of class <TT>A</TT>.  This
implies, for example, that access checking on the first use
of <TT>A::I</TT> must be deferred until it is determined that this use
of <TT>A::I</TT> is as the return type of a member of
class <TT>A</TT>. <B>Similarly, the use of <TT>A::B</TT> as a
<I>base-specifier</I> is well-formed because <TT>D</TT> is derived
from <TT>A</TT>, so access checking of <I>base-specifier</I>s must be
deferred until the entire <I>base-specifier-list</I> has been seen.</B>
&mdash;<I>end example</I>]

</BLOCKQUOTE>

</LI>

<LI>
<P>In 11.4&nbsp;



 <A HREF="access.html#class.friend">class.friend</A> paragraph 2, replace the following
text:</P>

<BLOCKQUOTE>

<P>Declaring a class to be a friend implies that the names of private
and protected members from the class granting friendship can be
accessed in declarations of members of the befriended
class. [<I>Note:</I> this means that access to private and protected
names is also granted to member functions of the friend class (as if
the functions were each friends) and to the static data member
definitions of the friend class. This also means that private and
protected type names from the class granting friendship can be used in
the <I>base-clause</I> of a nested class of the friend class. However,
the declarations of members of classes nested within the friend class
cannot access the names of private and protected members from the
class granting friendship. Also, because the <I>base-clause</I> of the
friend class is not part of its member declarations,
the <I>base-clause</I> of the friend class cannot access the names of
the private and protected members from the class granting
friendship. For example,</P>

<PRE>
    class A {
      class B { };
      friend class X;
    };
    class X: A::B {     //<SPAN STYLE="font-family:Times"><I> ill-formed: </I><TT>A::B</TT><I> cannot be accessed</I></SPAN>
                        //<SPAN STYLE="font-family:Times"><I> in the base-clause for </I><TT>X</TT></SPAN>
      A::B mx;          //<SPAN STYLE="font-family:Times"><I> OK: </I><TT>A::B</TT><I> used to declare member of </I><TT>X</TT></SPAN>
      class Y: A::B {   //<SPAN STYLE="font-family:Times"><I> OK: </I><TT>A::B</TT><I> used to declare member of </I><TT>X</TT></SPAN>
        A::B my;        //<SPAN STYLE="font-family:Times"><I> ill-formed: </I><TT>A::B</TT><I> cannot be accessed</I></SPAN>
                        //<SPAN STYLE="font-family:Times"><I> to declare members of nested class of </I><TT>X</TT></SPAN>
      };
    };
</PRE>

<P>&mdash;<I>end note</I>]</P>

</BLOCKQUOTE>

<P>with:</P>

<BLOCKQUOTE>

<P>Declaring a class to be a friend implies that the names of private and
protected members from the class granting friendship can be accessed
in the <I>base-specifier</I>s and member declarations of the befriended
class. [<I>Example:</I>
</P>

<PRE>
    class A {
      class B { };
      friend class X;
    };

    struct X: A::B {   //<SPAN STYLE="font-family:Times"><I> OK: </I><TT>A::B</TT><I> accessible to friend</I></SPAN>
      A::B mx;         //<SPAN STYLE="font-family:Times"><I> OK: </I><TT>A::B</TT><I> accessible to member of friend</I></SPAN>
      class Y {
        A::B my;       //<SPAN STYLE="font-family:Times"><I> OK: </I><TT>A::B</TT><I> accessible to nested member of friend</I></SPAN>
      };
    };
</PRE>

<P>&mdash;<I>end example</I>]</P>

</BLOCKQUOTE>

</LI>

<LI>
<P>Change the last sentence of 14.3&nbsp;



 <A HREF="template.html#temp.arg">temp.arg</A> paragraph 3
as indicated:</P>

<BLOCKQUOTE>

<P>For a <I>template-argument</I> <S>of</S> <B>that is a</B> class type
<B>or a class template</B>, the template definition has no special
access rights to the <S>inaccessible</S> members of the <S>template
argument type.</S> <B><I>template-argument</I>.  [<I>Example:</I></B>
</P>

<PRE>
<B>
    template &lt;template &lt;class TT&gt; class T&gt; class A {
      typename T&lt;int&gt;::S s;
    };

    template &lt;class U&gt; class B {
    private:
      struct S { /* ... */ };
    };

    A&lt;B&gt; b;    //<SPAN STYLE="font-family:Times"><I> ill-formed, </I><TT>A</TT><I> has no access to </I><TT>B::S</TT></SPAN>
</B>
</PRE>

<P>
<B>&mdash;<I>end example</I>]</B>
</P>

</BLOCKQUOTE>

</LI>

<LI>
<P>Change 9.7&nbsp;



 <A HREF="class.html#class.nest">class.nest</A> paragraph 4 as indicated:</P>

<BLOCKQUOTE>

Like a member function, a friend function (11.4&nbsp;



 <A HREF="access.html#class.friend">class.friend</A>)
defined within a nested class is in the lexical scope of that class;
it obeys the same rules for name binding as a static member function
of that class (9.4&nbsp;



 <A HREF="class.html#class.static">class.static</A>)<B>, but it</B> <S>and</S>
has no special access rights to members of an enclosing class.

</BLOCKQUOTE>

</LI>

</OL>

<P>
<I>(Note: this resolution also resolves issues <A HREF="
     cwg_active.html#494">494</A> and <A HREF="
     cwg_active.html#500">500</A>.)</I>
</P>

<BR>
<BR>
<HR>
<A NAME="517"></A>
<H4>517.
  
Partial specialization following explicit instantiation
</H4>
<B>Section: </B>14.5.4&nbsp;



 <A HREF="template.html#temp.class.spec">temp.class.spec</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>review
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>John Spicer
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>03 May 2005<BR>


<P>According to 14.5.4&nbsp;



 <A HREF="template.html#temp.class.spec">temp.class.spec</A> paragraph 1,</P>

<BLOCKQUOTE>

If a template is partially specialized then that partial
specialization shall be declared before the first use of that partial
specialization that would cause an implicit instantiation to take
place, in every translation unit in which such a use occurs; no
diagnostic is required.

</BLOCKQUOTE>

<P>This leaves the impression that an explicit instantiation of the
primary template may precede the declaration of an applicable partial
specialization.  Is the following example well-formed?</P>

<PRE>
    template&lt;typename T&gt; class X{
        public:
        void foo(){};
    };

    template class X&lt;void *&gt;;

    template&lt;typename T&gt; class X&lt;T*&gt;{
        public:
        void baz();
    };

    void bar() {
        X&lt;void *&gt; x;
        x.foo();
    }
</PRE>

<P>
<B>Proposed resolution (October, 2005):</B>
</P>

<P>Replace the last sentence of 14.5.4&nbsp;



 <A HREF="template.html#temp.class.spec">temp.class.spec</A>
paragraph 1:</P>

<BLOCKQUOTE>

If a template is partially specialized then that partial
specialization shall be declared before the first use of that partial
specialization that would cause an implicit instantiation to take
place, in every translation unit in which such a use occurs; no
diagnostic is required.

</BLOCKQUOTE>

<P>with:</P>

<BLOCKQUOTE>

A partial specialization shall be declared before the first use of a
class template specialization that would make use of the partial
specialization as the result of an implicit or explicit instantiation
in every translation unit in which such a use occurs; no diagnostic is
required.

</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="515"></A>
<H4>515.
  
Non-dependent references to base class members
</H4>
<B>Section: </B>14.6.2&nbsp;



 <A HREF="template.html#temp.dep">temp.dep</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>review
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Mike Miller
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>18 Apr 2005<BR>


<P>Implementations vary in their treatment of the following code:</P>

<PRE>
    struct A {
      int foo_;
    };
    template &lt;typename T&gt; struct B: public A { };
    template &lt;typename T&gt; struct C: B&lt;T&gt; {
      int foo() {
        return A::foo_;  //<SPAN STYLE="font-family:Times"><I> #1</I></SPAN>
      }
    };
    int f(C&lt;int&gt;* p) {
      return p-&gt;foo();
    }
</PRE>

<P>According to <A HREF="http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21008">one
analysis</A>, because the expression <TT>A::foo_</TT> on line #1
is non-dependent, it must be analyzed in the definition
context.  It that context, it violates the restrictions of
9.2&nbsp;



 <A HREF="class.html#class.mem">class.mem</A> paragraph 10 on how the name of a
nonstatic data member of a class can be used and thus should be
treated as an error.</P>

<P>On the other hand, the description of the transformation of
an <I>id-expression</I> into a class member access expression
(9.3.1&nbsp;



 <A HREF="class.html#class.mfct.nonstatic">class.mfct.nonstatic</A> paragraph 3) does not have any special
treatment of templates; when <TT>C&lt;int&gt;::foo()</TT> is
instantiated, the reference to <TT>A::foo_</TT> turns out to be to a
base class member and is thus transformed into
<TT>(*this).A::foo_</TT> and is thus not an error.</P>

<P>
<B>Proposed resolution (October, 2005):</B>
</P>

<P>Change 9.3.1&nbsp;



 <A HREF="class.html#class.mfct.nonstatic">class.mfct.nonstatic</A> paragraph 3 as indicated:</P>

<BLOCKQUOTE>

When an <I>id-expression</I> (5.1&nbsp;



 <A HREF="expr.html#expr.prim">expr.prim</A>) that is not
part of a class member access syntax (5.2.5&nbsp;



 <A HREF="expr.html#expr.ref">expr.ref</A>)
and not used to form a pointer to member (5.3.1&nbsp;



 <A HREF="expr.html#expr.unary.op">expr.unary.op</A>) is used in the body of a non-static member function
of class <TT>X</TT> or used in the <I>mem-initializer</I> for a
constructor of class <TT>X</TT>, if name lookup (3.4.1&nbsp;



 <A HREF="basic.html#basic.lookup.unqual">basic.lookup.unqual</A>) resolves the name in the <I>id-expression</I> to a
non-static non-type member of <S>class <TT>X</TT> or of a base class
of <TT>X</TT></S> <B>some class <TT>C</TT></B>,
the <I>id-expression</I> is transformed into a class member access
expression (5.2.5&nbsp;



 <A HREF="expr.html#expr.ref">expr.ref</A>) using <TT>(*this)</TT>
(9.3.2&nbsp;



 <A HREF="class.html#class.this">class.this</A>) as the
<I>postfix-expression</I> to the left of the <TT>.</TT>
operator.  <B>[<I>Note:</I> If <TT>C</TT> is not <TT>X</TT> or a base
class of <TT>X</TT>, the class member access expression is ill-formed.
&mdash;<I>end note</I>]</B> <S>The member name then refers to the
member of the object for which the function is called.</S> Similarly
during name lookup...

</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="524"></A>
<H4>524.
  
Can function-notation calls to operator functions be dependent?
</H4>
<B>Section: </B>14.6.2&nbsp;



 <A HREF="template.html#temp.dep">temp.dep</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>review
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Daveed Vandevoorde
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>19 July 2005<BR>


<P>The description of dependent function calls in
14.6.2&nbsp;



 <A HREF="template.html#temp.dep">temp.dep</A> paragraph 1 applies only to
<I>identifier</I>s in postfix-notation function calls and to operator
notation calls for operator functions:</P>

<BLOCKQUOTE>

<P>In an expression of the form:</P>

<UL>
<I>postfix-expression</I> <TT>(</TT> <I>expression-list<SUB>opt</SUB></I> <TT>)</TT>
</UL>

<P>where the <I>postfix-expression</I> is an <I>identifier</I>,
the <I>identifier</I> denotes a <I>dependent name</I> if and only if
any of the expressions in the <I>expression-list</I> is a
type-dependent expression (14.6.2.2&nbsp;



 <A HREF="template.html#temp.dep.expr">temp.dep.expr</A>). If an
operand of an operator is a type-dependent expression, the operator
also denotes a dependent name.</P>

</BLOCKQUOTE>

<P>It would appear from the related passage in
14.6.4.2&nbsp;



 <A HREF="template.html#temp.dep.candidate">temp.dep.candidate</A> paragraph 1 that the description of
postfix-notation function calls should apply to all
<I>unqualified-id</I>s that are not <I>template-id</I>s,
including <I>operator-function-id</I>s, not just to
<I>identifier</I>s:</P>

<BLOCKQUOTE>

For a function call that depends on a template parameter, if the
function name is an <I>unqualified-id</I> but not
a <I>template-id</I>, the candidate functions are found...

</BLOCKQUOTE>

<P>
<B>Proposed resolution (October, 2005):</B>
</P>

<OL>
<LI>
<P>Change 14.6.2&nbsp;



 <A HREF="template.html#temp.dep">temp.dep</A> paragraph 1 as
indicated:</P>
</LI>

<BLOCKQUOTE>

<P>...In an expression of the form:</P>

<UL>
<I>postfix-expression </I><TT>(</TT><I> expression-list<SUB>opt</SUB> </I><TT>)</TT>
</UL>

<P>where the <I>postfix-expression</I> is an <S><I>identifier</I></S>
<B><I>unqualified-id</I> but not a <I>template-id</I></B>,
the <S><I>identifier</I></S> <B><I>unqualified-id</I></B> denotes
a <I>dependent name</I> if and only if any of the expressions in
the <I>expression-list</I> is a type-dependent expression
(14.6.2.2&nbsp;



 <A HREF="template.html#temp.dep.expr">temp.dep.expr</A>)...</P>

</BLOCKQUOTE>

<LI>
<P>Change 14.6.4.2&nbsp;



 <A HREF="template.html#temp.dep.candidate">temp.dep.candidate</A> paragraph 1 as
indicated:</P>
</LI>

<BLOCKQUOTE>

For a function call that depends on a template parameter, if the
function name is an <I>unqualified-id</I> but not
a <I>template-id</I>, <B>or if the function is called using operator
notation,</B> the candidate functions are found using the
usual lookup rules (3.4.1&nbsp;



 <A HREF="basic.html#basic.lookup.unqual">basic.lookup.unqual</A>, 3.4.2&nbsp;



 <A HREF="basic.html#basic.lookup.argdep">basic.lookup.argdep</A>) except that...

</BLOCKQUOTE>

</OL>

<BR>
<BR>
<HR>
<A NAME="529"></A>
<H4>529.
  
Use of <TT>template&lt;&gt;</TT> with &ldquo;explicitly-specialized&rdquo; class templates
</H4>
<B>Section: </B>14.7.3&nbsp;



 <A HREF="template.html#temp.expl.spec">temp.expl.spec</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>review
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>James Widman
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>16 August 2005<BR>


<P>Paragraph 17 of 14.7.3&nbsp;



 <A HREF="template.html#temp.expl.spec">temp.expl.spec</A> says,</P>

<BLOCKQUOTE>

A member or a member template may be nested within many enclosing
class templates. In an explicit specialization for such a member, the
member declaration shall be preceded by a <TT>template&lt;&gt;</TT>
for each enclosing class template that is explicitly specialized.

</BLOCKQUOTE>

<P>This is curious, because paragraph 3 only allows explicit
specialization of members of implicitly-instantiated class
specializations, not explicit specializations.  Furthermore,
paragraph 4 says,</P>

<BLOCKQUOTE>

Definitions of members of an explicitly specialized class are defined
in the same manner as members of normal classes, and not using the
explicit specialization syntax.

</BLOCKQUOTE>

<P>Paragraph 18 provides a clue for resolving the apparent
contradiction:</P>

<BLOCKQUOTE>

In an explicit specialization declaration for a member of a class
template or a member template that appears in namespace scope, the
member template and some of its enclosing class templates may remain
unspecialized, except that the declaration shall not explicitly
specialize a class member template if its enclosing class templates
are not explicitly specialized as well. In such explicit
specialization declaration, the keyword <TT>template</TT> followed by
a <I>template-parameter-list</I> shall be provided instead of
the <TT>template&lt;&gt;</TT> preceding the explicit specialization
declaration of the member.

</BLOCKQUOTE>

<P>It appears from this and the following example that the phrase
&ldquo;explicitly specialized&rdquo; in paragraphs 17 and 18, when
referring to enclosing class templates, does not mean that explicit
specializations have been declared for them but that their names in
the <I>qualified-id</I> are followed by template argument lists.  This
terminology is confusing and should be changed.</P>

<P>
<B>Proposed resolution (October, 2005):</B>
</P>

<OL>
<LI>
<P>Change 14.7.3&nbsp;



 <A HREF="template.html#temp.expl.spec">temp.expl.spec</A> paragraph 17 as
indicated:</P>
</LI>

<BLOCKQUOTE>

A member or a member template may be nested within many enclosing
class templates. In an explicit specialization for such a member, the
member declaration shall be preceded by a <TT>template&lt;&gt;</TT>
for each enclosing class template <S>that is explicitly specialized</S>
<B>specialization</B>. [<I>Example:</I>...

</BLOCKQUOTE>

<LI>
<P>Change 14.7.3&nbsp;



 <A HREF="template.html#temp.expl.spec">temp.expl.spec</A> paragraph 18 as
indicated:</P>
</LI>

<BLOCKQUOTE>

In an explicit specialization declaration for a member of a class
template or a member template that appears in namespace scope, the
member template and some of its enclosing class templates may remain
unspecialized, <S>except that the declaration shall not explicitly
specialize a class member template if its enclosing class templates
are not explicitly specialized as well</S> <B>that is, the
<I>template-id</I> naming the template may be composed of template
parameter names rather than <I>template-argument</I>s</B>. <S>In</S>
<B>For each unspecialized template in</B> such <B>an</B> explicit
specialization declaration, the keyword <TT>template</TT> followed by
a <I>template-parameter-list</I> shall be provided instead of
the <TT>template&lt;&gt;</TT> preceding the <S>explicit
specialization</S> declaration of the member. The types of
the <I>template-parameter</I>s in the <I>template-parameter-list</I>
shall be the same as those specified in the primary template
definition. <B>In such declarations, an unspecialized <I>template-id</I>
shall not precede the name of a template specialization in the
<I>qualified-id</I> naming the member.</B> [<I>Example:</I>...

</BLOCKQUOTE>

</OL>

<BR>
<BR>
<HR>
<A NAME="522"></A>
<H4>522.
  
Array-to-pointer decay in template argument deduction
</H4>
<B>Section: </B>14.8.2.1&nbsp;



 <A HREF="template.html#temp.deduct.call">temp.deduct.call</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>review
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Daveed Vandevoorde
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>3 June 2005<BR>


<P>Consider the following example:</P>

<PRE>
    char* cmdline3_[1] = {};

    template&lt;class charT&gt;
    void func(const charT* const argv[]) {}

    int main()
    {
        func(cmdline3_);
    }
</PRE>

<P>In terms of the process described in 14.8.2.1&nbsp;



 <A HREF="template.html#temp.deduct.call">temp.deduct.call</A>,
<TT>P</TT> is <TT>const charT* const *</TT> and <TT>A</TT> is
<TT>char*[1]</TT>.  According to the first bullet in paragraph 2,
the type used in deduction is not <TT>A</TT> but &ldquo;the pointer
type produced by the array-to-pointer standard conversion.&rdquo;</P>

<P>According to paragraph 4,</P>

<BLOCKQUOTE>

In general, the deduction process attempts to find template argument
values that will make the deduced <TT>A</TT> identical to <TT>A</TT>
(after the type <TT>A</TT> is transformed as described
above). However, there are three cases that allow a difference:

</BLOCKQUOTE>

<P>In this example, the deduced <TT>A</TT> is <I>not</I>
identical to the transformed <TT>A</TT>, because the deduced
<TT>A</TT> has additional cv-qualification, so the three exceptions
must be examined to see if they apply.  The only one that might
apply is the second bullet of paragraph 4:</P>

<BLOCKQUOTE>

<UL>
<LI>
<TT>A</TT> can be another pointer or pointer to member type
that can be converted to the deduced <TT>A</TT> via a qualification
conversion (4.4&nbsp;



 <A HREF="conv.html#conv.qual">conv.qual</A>).</LI>
</UL>

</BLOCKQUOTE>

<P>However, <TT>A</TT> is not a pointer type but an array type;
this provision does not apply and deduction fails.</P>

<P>It has been argued that the phrase &ldquo;after the type <TT>A</TT>
is transformed as described above&rdquo; should be understood to
apply to the <TT>A</TT> in the three bullets of paragraph 4.  If
that is the intent, the wording should be changed to make that
explicit.</P>

<P>
<B>Proposed resolution (October, 2005):</B>
</P>

<P>Add the indicated words to 14.8.2&nbsp;



 <A HREF="template.html#temp.deduct">temp.deduct</A> paragraph 4:</P>

<BLOCKQUOTE>

<P>In general, the deduction process attempts to find template
argument values that will make the deduced <TT>A</TT> identical
to <TT>A</TT> (after the type <TT>A</TT> is transformed as described
above). However, there are three cases that allow a difference:</P>

<UL>

<LI>
<P>If the original <TT>P</TT> is a reference type, the
deduced <TT>A</TT> (i.e., the type referred to by the reference) can
be more cv-qualified than <B>the transformed</B> A.</P>
</LI>

<LI>
<P>
<B>The transformed</B> <TT>A</TT> can be another pointer or
pointer to member type that can be converted to the deduced <TT>A</TT>
via a qualification conversion (4.4&nbsp;



 <A HREF="conv.html#conv.qual">conv.qual</A>).</P>
</LI>

<LI>
<P>If <TT>P</TT> is a class, and <TT>P</TT> has the
form <I>template-id</I>, then <B>the transformed</B> <TT>A</TT> can be
a derived class of the deduced <TT>A</TT>. Likewise, if <TT>P</TT> is
a pointer to a class of the form <I>template-id</I>, <B>the
transformed</B> <TT>A</TT> can be a pointer to a derived class pointed
to by the deduced <TT>A</TT>.</P>
</LI>

</UL>

</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="526"></A>
<H4>526.
  
Confusing aspects in the specification of non-deduced contexts
</H4>
<B>Section: </B>14.8.2.5&nbsp;



 <A HREF="template.html#temp.deduct.type">temp.deduct.type</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>review
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Mike Miller
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>25 July 2005<BR>


<P>14.8.2.5&nbsp;



 <A HREF="template.html#temp.deduct.type">temp.deduct.type</A> paragraph 5 reads:</P>

<BLOCKQUOTE>

<P>The non-deduced contexts are:</P>

<UL>

<LI>
<P>The <I>nested-name-specifier</I> of a type that was specified
using a <I>qualified-id</I>.</P>
</LI>

<LI>
<P>A non-type template argument or an array bound that is an
expression that references a template parameter.</P>
</LI>

<LI>
<P>A template parameter used in the parameter type of a function
parameter that has a default argument that is being used in the call
for which argument deduction is being done.</P>
</LI>

<LI>
<P>A function parameter for which argument deduction cannot be
done because the associated function argument is a function, or a set
of overloaded functions (13.4&nbsp;



 <A HREF="over.html#over.over">over.over</A>), and one or more
of the following apply:</P>
</LI>

<UL>

<LI>
<P>more than one function matches the function parameter type
(resulting in an ambiguous deduction), or</P>
</LI>

<LI>
<P>no function matches the function parameter type, or</P>
</LI>

<LI>
<P>the set of functions supplied as an argument contains one or
more function templates.</P>
</LI>

</UL>

<LI>
<P>An array bound that is an expression that references
a <I>template-parameter</I>.</P>
</LI>

</UL>

</BLOCKQUOTE>

<P>There are two problems with this list:</P>

<OL>

<LI>
<P>The last bullet is redundant with the second bullet.  This
appears to have been the result of applying the resolutions of issues
<A HREF="
     cwg_defects.html#70">70</A> and <A HREF="
     cwg_defects.html#352">352</A>
independently instead of in coordination.</P>
</LI>

<LI>
<P>The second bullet
appears to be contradicted by the statement in paragraph 8 saying that
an argument can be deduced if <TT>P</TT> and <TT>A</TT> have the
forms <I>type</I><TT>[i]</TT> and
<I>template-name</I><TT>&lt;i&gt;</TT>.</P>

<P>The intent of the wording in bullet 2 appears to have been that
deduction cannot be done if the template parameter is a sub-expression
of the template argument or array bound expression and that it can be
done if it is the complete expression, but the current wording does
not say that very clearly.  (Similar wording also appears in
14.6.2.1&nbsp;



 <A HREF="template.html#temp.dep.type">temp.dep.type</A> paragraph 3 and 14.8.2.5&nbsp;



 <A HREF="template.html#temp.deduct.type">temp.deduct.type</A> paragraph 14.)</P>
</LI>

</OL>

<P>
<B>Proposed resolution (October, 2005):</B>
</P>

<OL>
<LI>
<P>Change 14.8.2.5&nbsp;



 <A HREF="template.html#temp.deduct.type">temp.deduct.type</A> paragraph 5 as
indicated:</P>
</LI>

<BLOCKQUOTE>

<P>The non-deduced contexts are:</P>

<UL>
<LI>
<P>The <I>nested-name-specifier</I> of a type that was specified
using a <I>qualified-id</I>.</P>
</LI>

<LI>
<P>A non-type template argument or an array bound <S>that is an
expression that</S> <B>in either of which a subexpression</B>
references a template parameter.</P>
</LI>

<LI>
<P>A template parameter used in the parameter type of a function
parameter that has a default argument that is being used in the call
for which argument deduction is being done.</P>
</LI>

<LI>
<P>A function parameter for which argument deduction cannot be done
because the associated function argument is a function, or a set of
overloaded functions (13.4&nbsp;



 <A HREF="over.html#over.over">over.over</A>), and one or more of
the following apply:</P>
</LI>

<UL>
<LI>
<P>more than one function matches the function parameter type
(resulting in an ambiguous deduction), or</P>
</LI>

<LI>
<P>no function matches the function parameter type, or</P>
</LI>

<LI>
<P>the set of functions supplied as an argument contains one or more function templates.</P>
</LI>
</UL>

<S>
<LI>
<P>An array bound that is an expression that references a
<I>template-parameter</I>.</P>
</LI>
</S>
</UL>

</BLOCKQUOTE>

<LI>
<P>Change 14.8.2.5&nbsp;



 <A HREF="template.html#temp.deduct.type">temp.deduct.type</A> paragraph 14 as
indicated:</P>
</LI>

<BLOCKQUOTE>

If, in the declaration of a function template with a non-type template
parameter, the non-type template parameter is used in <S>an
expression</S> <B>a subexpression</B> in the function parameter list,
the expression is a non-deduced context <B>as specified above</B>...

</BLOCKQUOTE>

<LI>
<P>Change 14.6.2.1&nbsp;



 <A HREF="template.html#temp.dep.type">temp.dep.type</A> paragraph 3 as
indicated:</P>
</LI>

<BLOCKQUOTE>

A template argument that is equivalent to a template parameter (i.e.,
has the same constant value or the same type as the template
parameter) can be used in place of that template parameter in a
reference to the current instantiation. In the case of a non-type
template argument, the argument must have been given the value of the
template parameter and not an expression <S>involving</S> <B>that
contains</B> the template parameter <B>as a subexpression</B>...

</BLOCKQUOTE>

</OL>

<BR>
<BR>
<HR>
<A NAME="415"></A>
<H4>415.
  
Template deduction does not cause instantiation
</H4>
<B>Section: </B>14.8.3&nbsp;



 <A HREF="template.html#temp.over">temp.over</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>review
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>John Spicer
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>4 May 2003<BR>




<P>
<U>Mike Miller:</U>
In fact, now that I've looked more closely, that appears not to be the
case.  (At least, it's not the error I get when I compile his example.)
Here's a minimal extract (without the inflammatory using-directive :-)
that illustrates what I think is going on:</P>
<PRE>
  template &lt;typename _Iterator&gt;
  struct iterator_traits {
    typedef typename _Iterator::difference_type difference_type;
  };

  template &lt;typename _InputIterator&gt;
  inline typename iterator_traits&lt;_InputIterator&gt;::difference_type
  distance(_InputIterator, _InputIterator);

  double distance(const int&amp;, const int&amp;);

  void f() {
    int i = 0;
    int j = 0;
    double d = distance(i, j);
  }
</PRE>
<P>What happens is that <TT>iterator_traits&lt;int&gt;</TT>
is instantiated as part of
type deduction for the function template <TT>distance</TT>,
 and the instantiation
fails.  (Note that it can't be instantiation of <TT>distance&lt;int&gt;</TT>,
as I had originally posited, because in this case only a declaration, not a
definition, of that template is in scope.)</P>

<P>
<U>John Spicer:</U> Yes, I believe that is what is going on.</P>

<P>
<U>Mike Miller:</U> 
I seem to recall that there was some discussion of questions related
to this during the core meetings in Oxford.  I think Steve Adamczyk
said something to the effect that it's infeasible to suppress all
instantiation errors during template type deduction and simply call
any such errors a deduction failure.  (I could be misremembering, and
I could be misapplying that comment to this situation.)</P>

<P>
<U>John Spicer</U>:
Regardless of other conditions in which this may apply, I don't think
it would be reasonable for compilers to have to do "speculative
instantiations" during template argument deduction.  One class
instantiation could kick off a series of other instantiations, etc.</P>

<P>
<U>Mike Miller:</U>
I don't see anything in the Standard that tells me whether it's
legitimate or not to report an error in this case.  I hope John or
another template expert can enlighten me on that.</P>

<P>
<U>John Spicer:</U>
My opinion is that, because this case is not among those enumerated
that cause deduction failure (rather than being ill-formed) that
reporting an error is the right thing to do.</P>

<P>
<U>Mike Miller:</U>
I am still interested, though, in the question of why
14.8.3&nbsp;



 <A HREF="template.html#temp.over">temp.over</A> says that
viable function template specializations are instantiated, even if they
are not selected by overload resolution.</P>

<P>
<U>John Spicer:</U>
I believe the wording in
14.8.3&nbsp;



 <A HREF="template.html#temp.over">temp.over</A> is incorrect.  I researched this and
found that a change was made during the clause 14 restructuring that
was incorporated in March of 1996.  The prior wording was "the deduced
template arguments are used to generate a single template function".
This was changed to "deduced template arguments are used to
instantiate a single function template specialization".  I believe
this resulted from what was basically a global replace of "generate"
with "instantiate" and of "template function" with "function template
specialization".  In this case, the substitution changed the meaning.
This paragraph needs reworking.</P>

<P>
<B>Proposed resolution (October, 2005):</B>
</P>

<P>Change 14.8.3&nbsp;



 <A HREF="template.html#temp.over">temp.over</A> paragraph 1 as indicated:</P>

<BLOCKQUOTE>

...For each function template, if the argument deduction and checking
succeeds, the <I>template-argument</I>s (deduced and/or explicit) are used to
<S>instantiate</S> <B>synthesize</B> a single function template
specialization <B>declaration</B> which is added to the candidate
functions set to be used in overload resolution. If, for a given
function template, argument deduction fails, no such function is added
to the set of candidate functions for that template. The complete set
of candidate functions includes all the function <S>templates
instantiated</S> <B>template specialization declarations
synthesized</B> in this way and all of the non-template overloaded
functions of the same name. The function template <S>specializations</S>
<B>specialization declarations</B> are treated like any other
functions in the remainder of overload resolution, except as
explicitly noted in 13.3.3&nbsp;



 <A HREF="over.html#over.match.best">over.match.best</A>.

</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="475"></A>
<H4>475.
  
When is <TT>std::uncaught_exception()</TT> true? (take 2)
</H4>
<B>Section: </B>15.5.3&nbsp;



 <A HREF="except.html#except.uncaught">except.uncaught</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>review
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Martin Sebor
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>27 Sep 2004<BR>


<P> See also <A HREF="
     cwg_closed.html#37">issue 37</A>.</P>

<P>Given this piece of code and <TT>S</TT> having a user-defined
ctor, at precisely which point must
<TT>std::uncaught_exception()</TT> return <TT>true</TT> and where
<TT>false</TT>?</P>

<PRE>
    try { S s0; throw s0; } catch (S s2) { }
</PRE>

<P>My understanding of the semantics of the code is as
follows:</P>

<OL>

<LI>The throw expression creates a temporary for a copy of
<TT>s0</TT>, say <TT>s1</TT>, using the copy ctor of
<TT>S</TT>. In this invocation of the copy ctor
<TT>uncaught_exception()</TT> must return <TT>true</TT>.</LI>

<LI>
<TT>s0</TT> is destroyed during stack unwinding. In the
invocation of <TT>S</TT> dtor <TT>uncaught_exception()</TT> must
still return <TT>true</TT>.</LI>

<LI>The variable <TT>s2</TT> is initialized from <TT>s1</TT> by
invoking the copy ctor of <TT>S</TT>. In this invocation
<TT>uncaught_exception()</TT> must also return
<TT>true</TT>.</LI>

<LI>
<TT>s2</TT> and <TT>s1</TT> are destroyed. In the invocations
of <TT>S</TT> dtor <TT>uncaught_exception()</TT> must return
<TT>false</TT>.</LI>

</OL>

<P>Is my understanding correct?</P>

<P>15.1&nbsp;



 <A HREF="except.html#except.throw">except.throw</A> paragraph 3 talks about &ldquo;the
exception object&rdquo; when describing the semantics of the
<I>throw-expression</I>:</P>

<BLOCKQUOTE>
a <I>throw-expression</I> initializes a temporary object, called
the <I>exception object</I>...  </BLOCKQUOTE>

<P>However, 15.5.1&nbsp;



 <A HREF="except.html#except.terminate">except.terminate</A> paragraph 1 talks about
&ldquo;the expression to be thrown&rdquo; when enumerating the
conditions under which <TT>terminate()</TT> is called:</P>

<BLOCKQUOTE>
when the exception handling mechanism, after completing
evaluation of the expression to be thrown but before the
exception is caught (15.1&nbsp;



 <A HREF="except.html#except.throw">except.throw</A>), calls a user
function that exits via an uncaught exception... </BLOCKQUOTE>

<P>And, 15.5.3&nbsp;



 <A HREF="except.html#except.uncaught">except.uncaught</A> paragraph 1 refers to
&ldquo;the object to be thrown&rdquo; in the description of
<TT>uncaught_exception()</TT>:</P>

<BLOCKQUOTE>
The function <TT>std::uncaught_exception()</TT> returns
<TT>true</TT> after completing evaluation of the object to be
thrown... </BLOCKQUOTE>

<P>Are all these objects one and the same? I believe the answer
is important in case the construction of the temporary exception
object throws another exception.</P>

<P>Suppose they are the same. Then <TT>uncaught_exception()</TT>
invoked from the copy ctor for <TT>s1</TT> (from the example
[above]) must return <TT>false</TT> and a new exception (e.g.,
<TT>bad_alloc</TT>) may be thrown and caught by a matching
handler (i.e., without calling <TT>terminate()</TT>).</P>

<P>But if they are not the same, then
<TT>uncaught_exception()</TT> invoked from the copy ctor for
<TT>s1</TT> must return <TT>true</TT> and throwing another
exception would end up calling <TT>terminate()</TT>. This would,
IMO, have pretty severe consequences on writing exception safe
exception classes.</P>

<P>As in the first case, different compilers behave differently,
with most compilers not calling <TT>terminate()</TT> when the
ctor for the temporary exception object throws. Unfortunately,
the two compilers that I trust the most do call
<TT>terminate()</TT>.</P>

<P>FWIW, my feeling is that it should be possible for the copy
ctor invoked to initialize the temporary exception object to
safely exit by throwing another exception, and that the new
exception should be allowed to be caught without calling
<TT>terminate</TT>.</P>

<P>
<U>Mike Miller</U>: The way I see this, a <I>throw-expression</I> has an 
<I>assignment-expression</I> as an operand.  This expression is
&ldquo;the expression to be thrown.&rdquo; Evaluation of this
expression yields an object; this object is &ldquo;the object to
be thrown.&rdquo; This object is then copied to the exception
object.</P>

<P>
<U>Martin Sebor</U>: Here's a survey of the return value from
<TT>uncaught_exception()</TT> in the various stages of exception
handling, implemented by current compilers:</P>

<TABLE FRAME="BOX" RULES="ALL">
<THEAD>
<TR>
<TH></TH>
<TH>expr</TH>
<TH>temp</TH>
<TH>unwind</TH>
<TH>handlr</TH>
<TH>2nd ex</TH>
</TR>
</THEAD>
<TBODY>
<TR>
<TD>HP aCC 6</TD>
<TD ALIGN="CENTER">0</TD>
<TD ALIGN="CENTER">0</TD>
<TD ALIGN="CENTER">1</TD>
<TD ALIGN="CENTER">0</TD>
<TD ALIGN="CENTER">OK</TD>
</TR>
<TR>
<TD>Compaq C++ 6.5</TD>
<TD ALIGN="CENTER">0</TD>
<TD ALIGN="CENTER">0</TD>
<TD ALIGN="CENTER">1</TD>
<TD ALIGN="CENTER">1</TD>
<TD ALIGN="CENTER">ABRT</TD>
</TR>
<TR>
<TD>EDG eccp 3.4</TD>
<TD ALIGN="CENTER">0</TD>
<TD ALIGN="CENTER">1</TD>
<TD ALIGN="CENTER">1</TD>
<TD ALIGN="CENTER">1</TD>
<TD ALIGN="CENTER">ABRT</TD>
</TR>
<TR>
<TD>g++ 3.4.2</TD>
<TD ALIGN="CENTER">0</TD>
<TD ALIGN="CENTER">0</TD>
<TD ALIGN="CENTER">1</TD>
<TD ALIGN="CENTER">0</TD>
<TD ALIGN="CENTER">OK</TD>
</TR>
<TR>
<TD>Intel C++ 7.0</TD>
<TD ALIGN="CENTER">0</TD>
<TD ALIGN="CENTER">0</TD>
<TD ALIGN="CENTER">1</TD>
<TD ALIGN="CENTER">0</TD>
<TD ALIGN="CENTER">OK</TD>
</TR>
<TR>
<TD>MIPSpro 7.4.1</TD>
<TD ALIGN="CENTER">0</TD>
<TD ALIGN="CENTER">0</TD>
<TD ALIGN="CENTER">1</TD>
<TD ALIGN="CENTER">1</TD>
<TD ALIGN="CENTER">ABRT</TD>
</TR>
<TR>
<TD>MSVC 7.0</TD>
<TD ALIGN="CENTER">0</TD>
<TD ALIGN="CENTER">0</TD>
<TD ALIGN="CENTER">1</TD>
<TD ALIGN="CENTER">0</TD>
<TD ALIGN="CENTER">OK</TD>
</TR>
<TR>
<TD>SunPro 5.5</TD>
<TD ALIGN="CENTER">1</TD>
<TD ALIGN="CENTER">1</TD>
<TD ALIGN="CENTER">1</TD>
<TD ALIGN="CENTER">0</TD>
<TD ALIGN="CENTER">OK</TD>
</TR>
<TR>
<TD>VisualAge 6.0</TD>
<TD ALIGN="CENTER">0</TD>
<TD ALIGN="CENTER">1</TD>
<TD ALIGN="CENTER">1</TD>
<TD ALIGN="CENTER">1</TD>
<TD ALIGN="CENTER">OK</TD>
</TR>
</TBODY>
</TABLE>

<P>In the table above:</P>

<UL>
<TABLE FRAME="VOID" RULES="NONE" CELLPADDING="10">
<TR>
<TD VALIGN="TOP">expr</TD>
<TD VALIGN="TOP">is the evaluation of the <I>assignment-expression</I> in the
<I>throw-expression</I></TD>
</TR>
<TR>
<TD VALIGN="TOP">temp</TD>
<TD VALIGN="TOP">is the invocation of the copy ctor for the unnamed temporary
exception object created by the runtime.</TD>
</TR>
<TR>
<TD VALIGN="TOP">unwind</TD>
<TD VALIGN="TOP">is stack unwinding.</TD>
</TR>
<TR>
<TD VALIGN="TOP">handlr</TD>
<TD VALIGN="TOP">is the invocation of the copy ctor in the
<I>exception-declaration</I> in the catch handler.</TD>
</TR>
<TR>
<TD VALIGN="TOP">2nd ex</TD>
<TD VALIGN="TOP">describes the behavior of the implementation when the
invocation of the copy ctor for the unnamed temporary exception
object [temp] throws another exception.</TD>
</TR>
</TABLE>
</UL>

<P>
<B>Proposed resolution (October, 2004):</B>
</P>

<OL>

<LI>
<P>Change 15.1&nbsp;



 <A HREF="except.html#except.throw">except.throw</A> paragraph 3 as
follows:</P>

<BLOCKQUOTE>

A <I>throw-expression</I> initializes a temporary object, called the
<I>exception object</I>, <S>the</S> <B>by copying the <I>thrown
object</I> (i.e., the result of evaluating its
<I>assignment-expression</I> operand) to it. The</B> type of
<S>which</S> <B>the exception object</B> is determined by
removing any top-level <I>cv-qualifier</I>s from the static type
of the operand of <TT>throw</TT> and adjusting the type from
&ldquo;array of <TT>T</TT>&rdquo; or &ldquo;function returning
<TT>T</TT>&rdquo; to &ldquo;pointer to <TT>T</TT>&rdquo; or
&ldquo;pointer to function returning <TT>T</TT>,&rdquo;
respectively.  [<I>Note:</I> the temporary object created <S>for</S>
<B>by</B> a <I>throw-expression</I> <S>that</S> <B>whose
operand</B> is a string literal is never of type <TT>char*</TT>
or <TT>wchar_t*</TT>; that is, the special conversions for string
literals from the types &ldquo;array of <TT>const
char</TT>&rdquo; and &ldquo;array of <TT>const
wchar_t</TT>&rdquo; to the types &ldquo;pointer to
<TT>char</TT>&rdquo; and &ldquo;pointer to
<TT>wchar_t</TT>,&rdquo; respectively (4.2&nbsp;



 <A HREF="conv.html#conv.array">conv.array</A>), are never applied to <B>the operand of</B> a
<I>throw-expression</I>. &mdash;<I>end note</I>] The temporary is
an lvalue and is used to initialize the variable named in the
matching handler (15.3&nbsp;



 <A HREF="except.html#except.handle">except.handle</A>).  The type of the
<B>operand of a</B> <I>throw-expression</I> shall not be an
incomplete type, or a pointer to an incomplete type other than
(possibly cv-qualified) <TT>void</TT>. [...]

</BLOCKQUOTE>

</LI>

<LI>
<P>Change the note in 15.3&nbsp;



 <A HREF="except.html#except.handle">except.handle</A> paragraph 3
as follows:</P>

<BLOCKQUOTE>

[<I>Note:</I> a <I>throw-expression</I> <B>operand that</B>
<S>which</S> is an integral constant expression of integer type
that evaluates to zero does not match a handler of pointer type;
that is, the null pointer constant conversions (4.10&nbsp;



 <A HREF="conv.html#conv.ptr">conv.ptr</A>, 4.11&nbsp;



 <A HREF="conv.html#conv.mem">conv.mem</A>) do not
apply. &mdash;<I>end note</I>]

</BLOCKQUOTE>

</LI>

<LI>
<P>Change 15.5.1&nbsp;



 <A HREF="except.html#except.terminate">except.terminate</A> paragraph 1 bullet 1
as follows:</P>

<BLOCKQUOTE>

when the exception handling mechanism, after completing
evaluation of the <S>expression to be thrown</S> <B>operand of
<TT>throw</TT></B> but before the exception is caught
(15.1&nbsp;



 <A HREF="except.html#except.throw">except.throw</A>), calls a user function that exits
via an uncaught exception,

</BLOCKQUOTE>

</LI>

<LI>
<P>Change 15.5.3&nbsp;



 <A HREF="except.html#except.uncaught">except.uncaught</A> paragraph 1 as
follows:</P>

<BLOCKQUOTE>

The function <TT>std::uncaught_exception()</TT> returns
<TT>true</TT> after completing evaluation of the <S>object to be
thrown</S> <B>operand of <TT>throw</TT></B> until completing the
initialization of the <I>exception-declaration</I> in the
matching handler (18.6.4&nbsp;



 <A HREF="lib-support.html#lib.uncaught">lib.uncaught</A>).

</BLOCKQUOTE>

</LI>

<LI>
<P>Change 18.6.4&nbsp;



 <A HREF="lib-support.html#lib.uncaught">lib.uncaught</A> paragraph 1 by adding
the indicated words:</P>

<BLOCKQUOTE>

<I>Returns:</I> <TT>true</TT> after completing evaluation of
<B>the operand of</B> a <I>throw-expression</I> until either
completing initialization of the <I>exception-declaration</I> in
the matching handler or entering <TT>unexpected()</TT> due to the
throw; or after entering <TT>terminate()</TT> for any reason
other than an explicit call to <TT>terminate()</TT>.
[<I>Note:</I> This includes stack unwinding (15.2&nbsp;



 <A HREF="except.html#except.ctor">except.ctor</A>). &mdash;<I>end note</I>]

</BLOCKQUOTE>

</LI>

</OL>

<P>
<B>Notes from the April, 2005 meeting:</B>
</P>

<P>The CWG discussed this resolution both within the group and with
other interested parties.  Among the points that were made:</P>

<UL>
<LI>
<P>Martin Sebor  pointed to a
<A HREF="http://gcc.gnu.org/ml/libstdc++/2005-01/msg00033.html">posting</A>
in which he argues that writing copy constructors is more difficult if
an exception during the copy to the exception object will result in a
call to <TT>std::terminate()</TT>.</P>
</LI>

<LI>
<P>In response to a question about why the copy to the exception
object is different from the copy from the exception object to the
object in the <I>exception-declaration</I>, it was observed that the
writer of the handler can avoid the second copy (by using a reference
declaration), but the first copy is unavoidable.</P>
</LI>

<LI>
<P>John Spicer observed that not exiting via exception should be a
design constraint for copy constructors in exception objects,
regardless of whether <TT>std::terminate()</TT> is called or
not.</P>
</LI>

<LI>
<P>Adopting the position that <TT>uncaught_exception()</TT>
returns <TT>false</TT> during the copy to the exception object would
reduce the differences between the case where that copy is elided and
the case where it is performed.</P>
</LI>

<LI>
<P>Jason Merrill observed that making <TT>uncaught_exception()</TT>
return <TT>false</TT> during the copy to the exception object would
simplify the code generated by g++; as it currently stands, the
compiler must generate code to catch exceptions during that copy so
<TT>std::terminate()</TT> can be called.</P>
</LI>

<LI>
<P>Bjarne Stroustrup worried that allowing the copy constructor to
throw an exception during the copy to the exception object could
result in a serious and specific exception being silently transformed
into a more trivial and generic one (although the CWG later noted that
this risk already exists if something in the expression being thrown
throws an exception before the expression completes).</P>
</LI>

</UL>

<P>The CWG felt that more input from a wider audience was necessary
before a decision could be made on the appropriate resolution.
</P>

<BR>
<BR>
<HR>
<A NAME="370"></A>
<H4>370.
  
Can <TT>#include &lt;...&gt;</TT> form be used other than for standard C++ headers?
</H4>
<B>Section: </B>16.2&nbsp;



 <A HREF="cpp.html#cpp.include">cpp.include</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>review
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Beman Dawes
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>01 August 2002<BR>


<P>The motivation for this issue is a desire to write portable programs which 
will work with any conforming implementation.</P>
<P>The C++ Standard (16.2&nbsp;



 <A HREF="cpp.html#cpp.include">cpp.include</A>) provides two forms of
<TT>#include</TT> directives, with the &lt;...&gt; form being described
(16.2&nbsp;



 <A HREF="cpp.html#cpp.include">cpp.include</A> paragraph 2) as "for a header", and
the "..." form (16.2&nbsp;



 <A HREF="cpp.html#cpp.include">cpp.include</A> paragraph 3) as
for "the source file" identified between the delimiters. When the 
standard uses the term "header", it often appears to be limiting
the term to apply to the Standard Library headers only. Users of the
standard almost always use the term "header" more broadly, to
cover all <TT>#include</TT>d source files, but 
particularly those containing interface declarations.</P>

<P>Headers, including source files, can be categorized according to
their origin and usage:</P>
<OL>
  <LI>C++ Standard Library headers (which aren't necessarily files).</LI>
  <LI>Other standard libraries such as the POSIX headers.</LI>
  <LI>Operating system API's such as <I>windows.h</I>.</LI>
  <LI>Third party libraries, such as Boost, ACE, or commercial offerings.</LI>
  <LI>Organization-wide "standard" header files, such as a company's <I>
  config.hpp</I>.</LI>
  <LI>A project's "public" header files, often shared by all
      developers working on the same project.</LI>
  <LI>A project or user's "private", "local", or
      "detail" headers, in the same directory or sub-directory
      as the compilation unit.</LI>
</OL>
<P>Existing practice varies widely, but it is fairly easy to find users 
advocating:</P>
<UL>
  <LI>For (1), Standard Library headers, use &lt;...&gt;. All others
      use "...".</LI>
  <LI>For (7),  use "...". All others use &lt;...&gt;.</LI>
  <LI>Draw a line somewhere below (1) and above (7), and use
      &lt;...&gt; above the line and "..." below.
      The exact location of the line may be based on a perception of
      how often the header involved changes; some "make" utilities
      use this to optimize builds.</LI>
</UL>
<P>Do any of the practices A, B, or C result in programs which can be rejected 
by a conforming implementation?</P>

<P>The first defect is that readers of the standard have not been
able to reach consensus on the answers to the above question.</P>

<P>A second possible defect is that if A, B, or C can be rejected by a 
conforming implementation, then the standard should be changed because would 
mean there is a wide variance between the standard and existing practice.</P>

<P>
<U>Matt Austern</U>:
I really only see two positions:</P>
<OL>
<LI>Implementations have some unspecified mechanism (copying
files to a magic directory, adding a magic flag,...) such that the
line <TT>#include &lt;foo&gt;</TT> results in textual inclusion of
the file foo.</LI>
<LI>Implementations are not required to have any mechanism for
getting <TT>#include &lt;foo&gt;</TT> to perform textual inclusion of an 
arbitrary file <TT>foo</TT>.  That form is reserved for standard
library headers only.</LI>
</OL>
<P>I agree that the standard should clarify which of those two is the
case (I imagine it'll hinge on finding one crucual sentence that
either says "implementation defined" or "unspecified"), but from
the standpoint of portability I don't see much difference between
the two.  I claim that, with either of those two interpretations, using
<TT>#include &lt;foo&gt;</TT> is already nonportable.</P>

<P>(Of course, I claim that almost anything having to do with headers,
including the <TT>#include "foo"</TT> form, is also nonportable.  In practice
there's wide variation in how compilers handle paths, especially
relative paths.)</P>

<P>
<U>Beman Dawes</U>:
The whole issue can be resolved by replacing "header" with "header or 
source file" in 16.2&nbsp;



 <A HREF="cpp.html#cpp.include">cpp.include</A> paragraph 2.
That will bring the standard into 
alignment with existing practice by both users and implementations.  
The "header and/or source file" wording is used at least three other 
places in the standard where otherwise there might be some confusion.</P>

<P>
<U>John Skaller</U>:
In light of Andrew Koenig's comments, this doesn't appear to be the case,
since the mapping of include names to file names is implementation defined,
and therefore source file inclusion cannot be made portable
within the ISO C/C++ standards (since that provision obviously cannot be
removed).</P>

<P>A possible idea is to create a binding standard, outside the
C/C++ ISO Standards, which specifies not only the path lookup
mechanism but also the translation from include names to file
names. Clearly that is OS dependent, encoding dependent, etc,
but there is no reason not to have a binding standard for Unix,
Windows, etc, and specify these bindings in such a way that
copying directories from one OS to the other can result in
programs working on both OS's.</P>

<P>
<U>Andy Koenig</U>:
An easier solution might be to specify a (presumably unbounded, or
bounded only by implementation capacity) collection of header-file
names that every implementation must make it possible for programs
to access somehow, without specifying exactly how.</P>

<P>
<B>Notes from October 2002 meeting:</B>
</P>

<P>This was discussed at some length.  While there was widespread
agreement that such inclusion is inherently implementation-dependent,
we agreed to try to add wording that would make it clear that
implementations are permitted (but not required) to allow inclusion
of files using the &lt;...&gt; form of <TT>#include</TT>.</P>

<P>
<B>Proposed resolution (April, 2005):</B>
</P>

<P>Change 16.2&nbsp;



 <A HREF="cpp.html#cpp.include">cpp.include</A> paragraph 7 from:</P>

<BLOCKQUOTE>

[<I>Example:</I> The most common uses of <TT>#include</TT> preprocessing
directives are as in the following:

<PRE>
    #include &lt;stdio.h&gt;
    #include "myprog.h"
</PRE>

&mdash;<I>end example</I>] 

</BLOCKQUOTE>

<P>to:</P>

<BLOCKQUOTE>

[<I>Note:</I> Although an implementation may provide a mechanism for
making arbitrary source files available to the <TT>&lt; &gt;</TT>
search, in general programmers should use the <TT>&lt; &gt;</TT> form
for headers provided with the implementation, and the <TT>" "</TT>
form for sources outside the control of the implementation. For
instance:

<PRE>
    #include &lt;stdio.h&gt;
    #include &lt;unistd.h&gt;
    #include "usefullib.h"
    #include "myprog.h"
</PRE>

&mdash;<I>end note</I>] 

</BLOCKQUOTE>

<P>
<B>Notes from October, 2005 meeting:</B>
</P>

<P>Some doubt was expressed as to whether the benefit of this
non-normative clarification outweighs the overall goal of synchronizing
clause 16 with the corresponding text in the C99 Standard.  As a
result, this issue is being left in &ldquo;review&rdquo; status to
allow further discussion.</P>

<BR>
<BR>
<BR>
<BR>
<HR>
<A NAME="Drafting Status"></A>
<H3>Issues with "Drafting" Status</H3>
<HR>
<A NAME="189"></A>
<H4>189.
  
Definition of <I>operator</I> and <I>punctuator</I>
</H4>
<B>Section: </B>2.12&nbsp;



 <A HREF="lex.html#lex.operators">lex.operators</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>drafting
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Mike Miller
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>20 Dec 1999<BR>





<P>The nonterminals <I>operator</I> and <I>punctuator</I> in
2.6&nbsp;



 <A HREF="lex.html#lex.token">lex.token</A>
 are not defined.  There is
a definition of the nonterminal <I>operator</I> in
13.5&nbsp;



 <A HREF="over.html#over.oper">over.oper</A>
 paragraph 1, but it is
apparent that the two nonterminals are not the same: the latter
includes keywords and multi-token operators and does not include the
nonoverloadable operators mentioned in paragraph 3.</P>

<P>There is a definition of <I>preprocessing-op-or-punc</I> in
2.12&nbsp;



 <A HREF="lex.html#lex.operators">lex.operators</A>
, with the notation that</P>

<BLOCKQUOTE>
Each <I>preprocessing-op-or-punc</I> is converted to a single token in
translation phase 7 (2.1).
</BLOCKQUOTE>

However, this list doesn't distinguish between <I>operator</I>s and
<I>punctuator</I>s, it includes digraphs and keywords (can a given
<I>token</I> be both a <I>keyword</I> and an <I>operator</I> at the
same time?), etc.

<P>
<B>Suggested resolution:</B>
</P>

<BR>
<OL>
<LI>Change 13.5&nbsp;



 <A HREF="over.html#over.oper">over.oper</A>
 to use the term
<I>overloadable-operator</I>.</LI>

<LI>Change 2.6&nbsp;



 <A HREF="lex.html#lex.token">lex.token</A>
 to use the term
<I>operator-token</I> instead of <I>operator</I> (since there are
operators that are keywords and operators that are composed of more
than one token).</LI>

<LI>Change 2.12&nbsp;



 <A HREF="lex.html#lex.operators">lex.operators</A>
 to define
the nonterminals <I>operator-token</I> and <I>punctuator</I>.</LI>
</OL>

<P>
<B>Additional note (April, 2005):</B>
</P>

<P>The resolution for this problem should also address the fact that
<TT>sizeof</TT> and <TT>typeid</TT> (and potentially others like
<TT>decltype</TT> that may be added in the future) are described in
some places as &ldquo;operators&rdquo; but are not listed in
13.5&nbsp;



 <A HREF="over.html#over.oper">over.oper</A> paragraph 3 among the operators that cannot be
overloaded.</P>
<BR>
<BR>
<HR>
<A NAME="490"></A>
<H4>490.
  
Name lookup in friend declarations
</H4>
<B>Section: </B>3.4.1&nbsp;



 <A HREF="basic.html#basic.lookup.unqual">basic.lookup.unqual</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>drafting
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Ben Hutchings
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>7 Dec 2004<BR>


<P>When 3.4.1&nbsp;



 <A HREF="basic.html#basic.lookup.unqual">basic.lookup.unqual</A> paragraph 10 says,</P>

<BLOCKQUOTE>

In a <TT>friend</TT> declaration naming a member function, a name used in
the function declarator and not part of a <I>template-argument</I> in a
<I>template-id</I> is first looked up in the scope of the member
function's class. If it is not found, or if the name is part of a
<I>template-argument</I> in a <I>template-id</I>, the look up is
as described for unqualified names in the definition of the class
granting friendship.

</BLOCKQUOTE>

<P>what does &ldquo;in the scope of the member function's
class&rdquo; mean?  Does it mean that only members of the class
and its base classes are considered?  Or does it mean that the
same lookup is to be performed as if the name appeared in the
member function's class?  Implementations vary in this regard.
For example:</P>

<PRE>
     struct s1;

     namespace ns {
         struct s1;
     }

     struct s2 {
         void f(s1 &amp;);
     };

     namespace ns {
         struct s3 {
             friend void s2::f(s1 &amp;);
         };
     }
</PRE>

<P>Microsoft Visual C++ and Comeau C++ resolve <TT>s1</TT> in the
friend declaration to <TT>ns::s1</TT> and issue an error, while
g++ resolves it to <TT>::s1</TT> and accepts the code.</P>

<P>
<B>Notes from the April, 2005 meeting:</B>
</P>

<P>The phrase &ldquo;looked up in the scope of [a] class&rdquo; occurs
frequently throughout the Standard and always refers to the member name
lookup described in 10.2&nbsp;



 <A HREF="derived.html#class.member.lookup">class.member.lookup</A>.  This is the first
interpretation mentioned above (&ldquo;only members of the class and its
base classes&rdquo;), resolving <TT>s1</TT> to <TT>ns::s1</TT>.  A
cross-reference to 10.2&nbsp;



 <A HREF="derived.html#class.member.lookup">class.member.lookup</A> will be added to
3.4.1&nbsp;



 <A HREF="basic.html#basic.lookup.unqual">basic.lookup.unqual</A> paragraph 10 to make this clearer.</P>

<P>In discussing this question, the CWG noticed another problem: the
text quoted above applies to all <I>template-argument</I>s appearing in
the function declarator.  The intention of this rule, however, is that
only <I>template-argument</I>s in the <I>declarator-id</I> should
ignore the member function's class scope; <I>template-argument</I>s
used elsewhere in the function declarator should be treated like other
names.  For example:</P>

<PRE>
     template&lt;typename T&gt; struct S;
     struct A {
       typedef int T;
       void foo(S&lt;T&gt;);
     };
     template &lt;typename T&gt; struct B {
       friend void A::foo(S&lt;T&gt;);  //<SPAN STYLE="font-family:Times"><I> i.e., </I></SPAN>S&lt;A::T&gt;
     };
</PRE>

<BR>
<BR>
<HR>
<A NAME="218"></A>
<H4>218.
  
Specification of Koenig lookup
</H4>
<B>Section: </B>3.4.2&nbsp;



 <A HREF="basic.html#basic.lookup.argdep">basic.lookup.argdep</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>drafting
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Hyman Rosen
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>28 Mar 2000<BR>




<P>The original intent of the Committee when Koenig lookup was added
to the language was apparently something like the following:</P>

<OL>
<LI>The name in the function call expression is looked up like any
other unqualified name.</LI>

<LI>If the ordinary unqualified lookup finds nothing or finds the
declaration of a (non-member) function, function template, or overload
set, argument-dependent lookup is done and any functions found in
associated namespaces are added to the result of the ordinary
lookup.</LI>
</OL>

<P>This approach is not reflected in the current wording of the
Standard.  Instead, the following appears to be the status quo:</P>

<OL>

<LI>Lookup of an unqualified name used as the
<I>postfix-expression</I> in the function call syntax always performs
Koenig lookup (3.4.1&nbsp;



 <A HREF="basic.html#basic.lookup.unqual">basic.lookup.unqual</A> paragraph 3).</LI>

<LI>Unless ordinary lookup finds a class member function, the result
of Koenig lookup always includes the declarations found in associated
namespaces (3.4.2&nbsp;



 <A HREF="basic.html#basic.lookup.argdep">basic.lookup.argdep</A> paragraph 2), regardless of
whether ordinary lookup finds a declaration and, if so, what kind of
entity is found.</LI>

<LI>The declarations from associated namespaces are not limited to
functions and template functions by anything in 3.4.2&nbsp;



 <A HREF="basic.html#basic.lookup.argdep">basic.lookup.argdep</A>.  However, if Koenig lookup results in more than one
declaration and at least one of the declarations is a non-function,
the program is ill-formed (7.3.4&nbsp;



 <A HREF="dcl.html#namespace.udir">namespace.udir</A>, paragraph 4;
although this restriction is in the description of the
<I>using-directive</I>, the wording applies to any lookup that spans
namespaces).</LI>

</OL>

<P>
<U>John Spicer</U>: Argument-dependent lookup was created to solve
the problem of looking up function names within templates where you
don't know which namespace to use because it may depend on the
template argument types (and was then expanded to permit use in
nontemplates).  The original intent only concerned functions.  The
safest and simplest change is to simply clarify the existing wording
to that effect.</P>

<P>
<U>Bill Gibbons</U>: I see no reason why non-function declarations
should not be found.  It would take a special rule to exclude
"function objects", as well as pointers to functions, from
consideration.  There is no such rule in the standard and I see no
need for one.</P>

<P>There is also a problem with the wording in 3.4.2&nbsp;



 <A HREF="basic.html#basic.lookup.argdep">basic.lookup.argdep</A> paragraph 2:</P>

<BLOCKQUOTE>
If the ordinary unqualified lookup of the name finds the declaration
of a class member function, the associated namespaces and classes are
not considered.
</BLOCKQUOTE>

<P>This implies that if the ordinary lookup of the name finds the
declaration of a data member which is a pointer to function or
function object, argument-dependent lookup is still done.</P>

<P>My guess is that this is a mistake based on the incorrect
assumption that finding any member other than a member function would
be an error.  I would just change "class member function" to "class
member" in the quoted sentence.</P>

<P>
<U>Mike Miller</U>: In light of the issue of "short-circuiting"
Koenig lookup when normal lookup finds a non-function, perhaps it
should be written as "...finds the declaration of a class member, an
object, or a reference, the associated namespaces..."?</P>

<P>
<U>Andy Koenig</U>: I think I have to weigh in on the side of
extending argument-dependent lookup to include function objects and
pointers to functions.  I am particularly concerned about [function
objects], because I think that programmers should be able to replace
functions by function objects without changing the behavior of their
programs in fundamental ways.</P>

<P>
<U>Bjarne Stroustrup</U>: I don't think we could seriously argue
from first principles that [argument-dependent lookup should find only
function declarations].  In general, C++ name lookup is designed to be
independent of type: First we find the name(s), then, we consider
its(their) meaning.  3.4&nbsp;



 <A HREF="basic.html#basic.lookup">basic.lookup</A> states "The name
lookup rules apply uniformly to all names ..." That is an important
principle.</P>

<P>Thus, I consider text that speaks of "function call" instead of
plain "call" or "application of ()" in the context of koenig lookup an
accident of history. I find it hard to understand how 5.2.2&nbsp;



 <A HREF="expr.html#expr.call">expr.call</A> doesn't either disallow all occurrences of
<TT>x(y)</TT> where <TT>x</TT> is a class object (that's clearly not
intended) or requires koenig lookup for <TT>x</TT> independently of
its type (by reference from 3.4&nbsp;



 <A HREF="basic.html#basic.lookup">basic.lookup</A>).  I suspect
that a clarification of 5.2.2&nbsp;



 <A HREF="expr.html#expr.call">expr.call</A> to mention
function objects is in order. If the left-hand operand of () is a
name, it should be looked up using koenig lookup.</P>

<P>
<U>John Spicer</U>: This approach causes otherwise well-formed
programs to be ill-formed, and it does so by making names visible that
might be completely unknown to the author of the program.
Using-directives already do this, but argument-dependent lookup is
different.  You only get names from using-directives if you actually
<I>use</I> using-directives.  You get names from argument-dependent
lookup whether you want them or not.</P>

<P>This basically breaks an important reason for having namespaces.
You are not supposed to need any knowledge of the names used by a
namespace.</P>

<P>But this example breaks if argument-dependent lookup finds
non-functions and if the translation unit includes the &lt;list&gt;
header somewhere.</P>

<PRE>
    namespace my_ns {
        struct A {};
        void list(std::ostream&amp;, A&amp;);

        void f() {
            my_ns::A a;
            list(cout, a);
        }
    }
</PRE>

<P>This really makes namespaces of questionable value if you still
need to avoid using the same name as an entity in another namespace to
avoid problems like this.</P>

<P>
<U>Erwin Unruh</U>: Before we really decide on this topic, we should
have more analysis on the impact on programs. I would also like to see
a paper on the possibility to overload functions with function
surrogates (no, I won't write one).  Since such an extension is bound
to wait until the next official update, we should not preclude any
outcome of the discussion.</P>

<P>I would like to have a change right now, which leaves open several
outcomes later. I would like to say that:</P>

<BLOCKQUOTE>
Koenig lookup will find non-functions as well. If it finds a variable, the
program is ill-formed. 
If the primary lookup finds a variable, Koenig lookup is done. If the result
contains both functions and variables, the program is ill-formed.
[<I>Note:</I> A future standard will assign semantics to such a program.]
</BLOCKQUOTE>

<P>I myself are not comfortable with this as a long-time result, but it
prepares the ground for any of the following long term solutions:</P>

<UL>
<LI>Do overloading on mixed function/variable sets.</LI>
<LI>Ignore variables on Koenig lookup.</LI>
<LI>Don't do Koenig lookup if the primary lookup finds a variable.</LI>
<LI>Find variables on Koenig lookup and give an error if there is a
variable/function mix.</LI>
</UL>

<P>The note is there to prevent compiler vendors to put their own
extensions in here.</P>

<P>(See also issues <A HREF="
     cwg_defects.html#113">113</A> and
<A HREF="
     cwg_defects.html#143">143</A>.)</P>

<P>
<B>Notes from 04/00 meeting:</B>
</P>

<P>Although many agreed that there were valid concerns motivating a
desire for Koenig lookup to find non-function declarations, there was
also concern that supporting this capability would be more dangerous
than helpful in the absence of overload resolution for mixed function
and non-function declarations.</P>

<P>A straw poll of the group revealed 8 in favor of Koenig lookup
finding functions and function templates only, while 3 supported the
broader result.   </P>

<P>
<B>Notes from the 10/01 meeting:</B>
</P>

<P>There was unanimous agreement on one less controversial point:
if the normal lookup of the identifier finds a non-function, argument-dependent
lookup should not be done.</P>

<P>On the larger issue, the primary point of consensus is that making
this change is
an extension, and therefore it should wait until the point at
which we are considering extensions (which could be very soon).
There was also consensus on the fact that the standard as it
stands is not clear: some introductory text suggests that
argument-dependent lookup finds only functions, but the more
detailed text that describes the lookup does not have any
such restriction.</P>

<P>It was also noted that some existing implementations (e.g., g++) do
find some non-functions in some cases.</P>

<P>The issue at this point is whether we should (1) make a small change
to make the standard clear (presumably in the direction of not
finding the non-functions in the lookup), and revisit the issue
later as an extension, or (2) leave the standard alone for now and
make any changes only as part of considering the extension.
A straw vote favored option (1) by a strong majority.</P>



<BR>
<BR>
<HR>
<A NAME="225"></A>
<H4>225.
  
Koenig lookup and fundamental types
</H4>
<B>Section: </B>3.4.2&nbsp;



 <A HREF="basic.html#basic.lookup.argdep">basic.lookup.argdep</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>drafting
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Derek Inglis
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>26 Jan 2000<BR>


<P>In discussing <A HREF="
     cwg_defects.html#197">issue 197</A>, the question
arose as to whether the handling of fundamental types in
argument-dependent lookup is actually what is desired.  This question
needs further discussion.</P>
<BR>
<BR>
<HR>
<A NAME="156"></A>
<H4>156.
  
Name lookup for conversion functions
</H4>
<B>Section: </B>3.4.5&nbsp;



 <A HREF="basic.html#basic.lookup.classref">basic.lookup.classref</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>drafting
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Derek Inglis
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>18 Aug 1999<BR>





<P>Paragraph 7 of
3.4.5&nbsp;



 <A HREF="basic.html#basic.lookup.classref">basic.lookup.classref</A>
 says,</P>

<BLOCKQUOTE>
If the <I>id-expression</I> is a <I>conversion-function-id</I>, its
<I>conversion-type-id</I> shall denote the same
type in both the context in which the
entire <I>postfix-expression</I> occurs
and in the context of the class of the object
expression (or the class pointed to by the pointer expression).
</BLOCKQUOTE>

Does this mean that the following example is ill-formed?

<PRE>
    struct A { operator int(); } a;
    void foo() {
      typedef int T;
      a.operator T(); // 1) error T is not found in the context
		      // of the class of the object expression?
    }
</PRE>

The second bullet in paragraph 1 of 
3.4.3.1&nbsp;



 <A HREF="basic.html#class.qual">class.qual</A>
 says,

<BLOCKQUOTE>
a <I>conversion-type-id</I> of an
<I>operator-function-id</I> is looked up both
in the scope of the class and in the
context in which the entire <I>postfix-expression</I>
occurs and shall refer to the
same type in both contexts
</BLOCKQUOTE>

How about:

<PRE>
    struct A { typedef int T; operator T(); };
    struct B : A { operator T(); } b;
    void foo() {
      b.A::operator T(); // 2) error T is not found in the context
			 // of the postfix-expression?
    }
</PRE>

Is this interpretation correct?  Or was the intent for
this to be an error only if
<TT>T</TT> was found in both scopes and referred to different entities?

<P>If the intent was for these to be errors,
how do these rules apply to template
arguments?</P>

<PRE>
    template &lt;class T1&gt; struct A { operator T1(); }
    template &lt;class T2&gt; struct B : A&lt;T2&gt; {
      operator T2();
      void foo() {
	T2 a = A&lt;T2&gt;::operator T2(); // 3) error? when instantiated T2 is not
				     // found in the scope of the class
	T2 b = ((A&lt;T2&gt;*)this)-&gt;operator T2(); // 4) error when instantiated?
      }
    }
</PRE>

<P>(Note bullets 2 and 3 in paragraph 1 of
3.4.3.1&nbsp;



 <A HREF="basic.html#class.qual">class.qual</A>
 refer to
<I>postfix-expression</I>.  It would be better to use
<I>qualified-id</I> in both cases.)</P>

<P>
<U>Erwin Unruh</U>:
The intent was that you look in both contexts. If you find it only once,
that's the symbol. If you find it in both, both symbols must be "the same"
in some respect. (If you don't find it, its an error).</P>

<P>
<U>Mike Miller</U>:
What's not clear to me in these examples is whether what is
being looked up is <TT>T</TT> or <TT>int</TT>.
Clearly the <TT>T</TT> has to be
looked up somehow, but the "name" of a conversion function
clearly involves the base (non-typedefed) type, not typedefs
that might be used in a definition or reference (cf
3&nbsp;



 <A HREF="basic.html#basic">basic</A>
 paragraph 7 and
12.3&nbsp;



 <A HREF="special.html#class.conv">class.conv</A>
 paragraph 5).
(This is true even for types that must be written
using typedefs because of the limited syntax in
<I>conversion-type-id</I>s &mdash; e.g., the "name" of the conversion
function in the following example</P>

<PRE>
    typedef void (*pf)();
    struct S {
	operator pf();
    };
</PRE>

is <TT>S::operator void(*)()</TT>, even though you can't write its name
directly.)

<P>My guess is that this means that in each scope you look up
the type named in the reference and form the canonical
operator name; if the name used in the reference isn't found
in one or the other scope, the canonical name constructed
from the other scope is used.  These names must be identical,
and the <I>conversion-type-id</I> in the canonical operator name must
not denote different types in the two scopes (i.e., the type
might not be found in one or the other scope, but if it's found
in both, they must be the same type).</P>

<P>I think this is all very vague in the current wording.</P>
<BR>
<BR>
<HR>
<A NAME="350"></A>
<H4>350.
  
<TT>signed char</TT> underlying representation for objects
</H4>
<B>Section: </B>3.9&nbsp;



 <A HREF="basic.html#basic.types">basic.types</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>drafting
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Noah Stein
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>16 April 2002<BR>


<P>Sent in by David Abrahams:</P>

<P>Yes, and to add to this tangent, 3.9.1&nbsp;



 <A HREF="basic.html#basic.fundamental">basic.fundamental</A>
paragraph 1 states "Plain char, signed char, and unsigned char are
three distinct types."  Strangely, 3.9&nbsp;



 <A HREF="basic.html#basic.types">basic.types</A>
paragraph 2 talks about how "... the underlying bytes making up
the object can be copied into an array of char or unsigned char.
If the content of the array of char or unsigned char is copied back
into the object, the object shall subsequently hold its original
value."  I guess there's no requirement that this copying
work properly with signed chars!</P>

<P>
<B>Notes from October 2002 meeting:</B>
</P>

<P>We should do whatever C99 does.  6.5p6 of the C99 standard says
"array of character type", and "character type" includes signed
char (6.2.5p15), and 6.5p7 says "character type".
But see also 6.2.6.1p4, which mentions (only) an array of unsigned char.</P>

<P>
<B>Proposed resolution (April 2003):</B>
</P>

<P>Change 3.8&nbsp;



 <A HREF="basic.html#basic.life">basic.life</A> paragraph 5 bullet 3 from</P>

<UL>
<LI>
the pointer is used as the operand of a
<TT>static_cast</TT>
(5.2.9&nbsp;



 <A HREF="expr.html#expr.static.cast">expr.static.cast</A>)
(except when the conversion is to
<TT>void*</TT>,
or to
<TT>void*</TT>
and subsequently to
<TT>char*</TT>,
or
<TT>unsigned</TT>
<TT>char*</TT>).
</LI>
</UL>

<P>to</P>

<UL>
<LI>
the pointer is used as the operand of a
<TT>static_cast</TT>
(5.2.9&nbsp;



 <A HREF="expr.html#expr.static.cast">expr.static.cast</A>)
(except when the conversion is to
<TT>void*</TT>,
or to
<TT>void*</TT>
and subsequently to a pointer to byte-character type).
</LI>
</UL>

<P>Change 3.8&nbsp;



 <A HREF="basic.html#basic.life">basic.life</A> paragraph 6 bullet 3 from </P>
<UL>
<LI>
the lvalue is used as the operand of a
<TT>static_cast</TT>
(5.2.9&nbsp;



 <A HREF="expr.html#expr.static.cast">expr.static.cast</A>)
(except when the conversion is ultimately to
<TT>char&amp;</TT>
or
<TT>unsigned</TT>
<TT>char&amp;</TT>),
or
</LI>
</UL>
<P>to</P>
<UL>
<LI>
the lvalue is used as the operand of a
<TT>static_cast</TT>
(5.2.9&nbsp;



 <A HREF="expr.html#expr.static.cast">expr.static.cast</A>)
(except when the conversion is ultimately to a reference to
byte-character type),
or
</LI>
</UL>

<P>Change the beginning of 3.9&nbsp;



 <A HREF="basic.html#basic.types">basic.types</A> paragraph 2 from</P>
<BLOCKQUOTE>
For any object (other than a base-class subobject) of POD type
<TT>T</TT>,
whether or not the object holds a valid value of type
<TT>T</TT>,
the underlying bytes (1.7&nbsp;



 <A HREF="intro.html#intro.memory">intro.memory</A>)
making up the object can be copied
into an array of
<TT>char</TT>
or
<TT>unsigned</TT>
<TT>char</TT>.
</BLOCKQUOTE>
<P>to</P>
<BLOCKQUOTE>
For any object (other than a base-class subobject) of POD type
<TT>T</TT>,
whether or not the object holds a valid value of type
<TT>T</TT>,
the underlying bytes (1.7&nbsp;



 <A HREF="intro.html#intro.memory">intro.memory</A>)
making up the object can be copied
into an array of byte-character type.
</BLOCKQUOTE>

<P>Add the indicated text to 3.9.1&nbsp;



 <A HREF="basic.html#basic.fundamental">basic.fundamental</A> paragraph 1:</P>

<BLOCKQUOTE>
Objects declared as characters
(<TT>char</TT>)
shall be large enough to store any member of
the implementation's basic character set.
If a character from this set is stored in a character object,
the integral value of that character object
is equal to
the value of the single character literal form of that character.
It is implementation-defined whether a
<TT>char</TT>
object can hold negative values.
Characters can be explicitly declared
<TT>unsigned</TT>
or
<TT>signed</TT>.
Plain
<TT>char</TT>,
<TT>signed char</TT>,
and
<TT>unsigned char</TT>
are three distinct types<B>, called the <I>byte-character types</I></B>.
A
<TT>char</TT>,
a
<TT>signed char</TT>,
and an
<TT>unsigned char</TT>
occupy the same amount of storage and have the same alignment requirements
(3.9&nbsp;



 <A HREF="basic.html#basic.types">basic.types</A>); that is, they have the
same object representation.
For <B>byte-</B>character types, all bits of the object representation participate in
the value representation.
For unsigned <B>byte-</B>character types, all possible bit
patterns of the value representation represent numbers.
These requirements
do not hold for other types.
In any particular implementation, a plain
<TT>char</TT>
object can take on either the same values as a
<TT>signed char</TT>
or an
<TT>unsigned char</TT>;
which one is implementation-defined.
</BLOCKQUOTE>

<P>Change 3.10&nbsp;



 <A HREF="basic.html#basic.lval">basic.lval</A> paragraph 15 last bullet from</P>
<UL>
<LI>
a
<TT>char</TT>
or
<TT>unsigned</TT>
<TT>char</TT>
type.
</LI>
</UL>
<P>to</P>
<UL>
<LI>
a byte-character type.
</LI>
</UL>

<P>
<B>Notes from October 2003 meeting:</B>
</P>

<P>It appears that in C99 signed char may have padding bits but no trap
representation, whereas in C++ signed char has no padding bits but
may have -0.  A memcpy in C++ would have to copy the array preserving
the actual representation and not just the value.</P>

<P>March 2004: The liaisons to the C committee have been asked to tell us
whether this change would introduce any unnecessary incompatibilities
with C.</P>

<P>
<B>Notes from October 2004 meeting:</B>
</P>

<P>The C99 Standard appears to be inconsistent in its
requirements.  For example, 6.2.6.1 paragraph 4 says:</P>

<BLOCKQUOTE>

The value may be copied into an object of type
<TT>unsigned&nbsp;char&nbsp;[</TT><I>n</I><TT>]</TT> (e.g., by
<TT>memcpy</TT>); the resulting set of bytes is called the
<I>object representation</I> of the value.

</BLOCKQUOTE>

<P>On the other hand, 6.2 paragraph 6 says,</P>

<BLOCKQUOTE>

If a value is copied into an object having no declared type using
<TT>memcpy</TT> or <TT>memmove</TT>, or is copied as an array of
character type, then the effective type of the modified object
for that access and for subsequent accesses that do not modify
the value is the effective type of the object from which the
value is copied, if it has one.

</BLOCKQUOTE>

<P>Mike Miller will investigate further.</P>

<BR>
<BR>
<HR>
<A NAME="170"></A>
<H4>170.
  
Pointer-to-member conversions
</H4>
<B>Section: </B>4.11&nbsp;



 <A HREF="conv.html#conv.mem">conv.mem</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>drafting
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Mike Stump
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>16 Sep 1999<BR>





<P>The descriptions of explicit
(5.2.9&nbsp;



 <A HREF="expr.html#expr.static.cast">expr.static.cast</A>
 paragraph 9) and
implicit (4.11&nbsp;



 <A HREF="conv.html#conv.mem">conv.mem</A>
 paragraph 2)
pointer-to-member conversions differ in two significant ways:</P>

<OL>
<LI>In a <TT>static_cast</TT>, a conversion in which the class in
the target pointer-to-member type is a base of the class in which
the member is declared is permitted and required to work correctly,
as long as the resulting pointer-to-member is eventually
dereferenced with an object whose dynamic type contains the
member.  That is, the class of the target pointer-to-member type
is not required to contain the member referred to by the value
being converted.  The specification of implicit pointer-to-member
conversion is silent on this question.

<P>(This situation cannot arise in an implicit pointer-to-member
conversion where the source value is something like <TT>&amp;X::f</TT>,
since you can only implicitly convert from pointer-to-base-member
to pointer-to-derived-member.  However, if the source value is
the result of an explicit "up-cast," the target type of the
conversion might still not contain the member referred to by the
source value.)</P>
</LI>

<LI>The target type in a <TT>static_cast</TT> is allowed to be
more cv-qualified than the source type; in an implicit conversion,
however, the cv-qualifications of the two types are required to
be identical.</LI>
</OL>

The first difference seems like an oversight.  It is not clear
whether the latter difference is intentional or not.
<BR>
<BR>
<HR>
<A NAME="222"></A>
<H4>222.
  
Sequence points and lvalue-returning operators
</H4>
<B>Section: </B>5&nbsp;



 <A HREF="expr.html#expr">expr</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>drafting
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Andrew Koenig
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>20 Dec 1999<BR>




<P>I believe that the committee has neglected to take into
account one of the differences between C and C++ when defining
sequence points.  As an example, consider</P>

<PRE>
    (a += b) += c;
</PRE>

<P>where <TT>a</TT>, <TT>b</TT>, and <TT>c</TT> all have type
<TT>int</TT>.  I believe that this expression has undefined behavior,
even though it is well-formed.  It is not well-formed in C, because +=
returns an rvalue there.  The reason for the undefined behavior is
that it modifies the value of `<TT>a</TT>' twice between sequence
points.</P>

<P>Expressions such as this one are sometimes genuinely useful.
Of course, we could write this particular example as</P>

<PRE>
    a += b; a += c;
</PRE>

<P>but what about</P>

<PRE>
    void scale(double* p, int n, double x, double y) {
        for (int i = 0; i &lt; n; ++i) {
            (p[i] *= x) += y;
        }
    }
</PRE>

<P>All of the potential rewrites involve multiply-evaluating
<TT>p[i]</TT> or unobvious circumlocations like creating references
to the array element.</P>

<P>One way to deal with this issue would be to include built-in operators
in the rule that puts a sequence point between evaluating a function's
arguments and evaluating the function itself.  However, that might
be overkill:  I see no reason to require that in</P>

<PRE>
    x[i++] = y;
</PRE>

<P>the contents of `<TT>i</TT>' must be incremented before the
assignment.</P>

<P>A less stringent alternative might be to say that when a built-in
operator yields an lvalue, the implementation shall not subsequently
change the value of that object as a consequence of that operator.</P>

<P>I find it hard to imagine an implementation that does not do this
already.  Am I wrong?  Is there any implementation out there that
does not `do the right thing' already for <TT>(a += b) += c</TT>?</P>

<P>5.17&nbsp;



 <A HREF="expr.html#expr.ass">expr.ass</A> paragraph 1 says,</P>

<BLOCKQUOTE>

The result of the assignment operation is the value stored in the left
operand after the assignment has taken place; the result is an lvalue.

</BLOCKQUOTE>

<P>What is the normative effect of the words "after the assignment has
taken place"?  I think that phrase ought to mean that in addition to
whatever constraints the rules about sequence points might impose on
the implementation, assignment operators on built-in types have the
additional constraint that they must store the left-hand side's new
value before returning a reference to that object as their result.</P>

<P>One could argue that as the C++ standard currently stands, the
effect of <TT>x = y = 0;</TT> is undefined.  The reason is that it
both fetches and stores the value of <TT>y</TT>, and does not fetch
the value of <TT>y</TT> in order to compute its new value.</P>

<P>I'm suggesting that the phrase "after the assignment has taken
place" should be read as constraining the implementation to set
<TT>y</TT> to 0 before yielding the value of <TT>y</TT> as the result
of the subexpression <TT>y = 0</TT>.</P>

<T>Note that this suggestion is different from asking that there be a
sequence point after evaluation of an assignment.  In particular, I am
not suggesting that an order constraint be imposed on any side effects
other than the assignment itself.</T>

<P>
<U>Francis Glassborow</U>:</P>

<P>My understanding is
that for a single variable:</P>

<OL>
<LI>Multiple read accesses without a write are OK</LI>

<LI>A single read access followed by a single write (of a value
dependant on the read, so that the read MUST happen first) is OK</LI>

<LI>A write followed by an actual read is undefined behaviour</LI>

<LI>Multiple writes have undefined behaviour</LI>
</OL>

<P>It is the 3) that is often ignored because in practice the compiler
hardly ever codes for the read because it already has that value but
in complicated evaluations with a shortage of registers, that is not
always the case. Without getting too close to the hardware, I think we
both know that a read too close to a write can be problematical on
some hardware.</P>

<P>So, in <TT>x = y = 0;</TT>, the implementation must NOT fetch a
value from <TT>y</TT>, instead it has to "know" what that value will
be (easy because it has just computed that in order to know what it
must, at some time, store in <TT>y</TT>).  From this I deduce that
computing the lvalue (to know where to store) and the rvalue to know
what is stored are two entirely independent actions that can occur in
any order commensurate with the overall requirements that both
operands for an operator be evaluated before the operator is.</P>

<P>
<U>Erwin Unruh</U>:</P>

<P>C
distinguishes between the resulting value of an assignment and putting the
value in store. So in C a compiler might implement the statement
<TT>x=y=0;</TT>
either as <TT>x=0;y=0;</TT> or as <TT>y=0;x=0;</TT>
In C the statement <TT>(x += 5) += 7;</TT> is not allowed because the first <TT>+=</TT> yields
an rvalue which is not allowed as left operand to <TT>+=</TT>.
So in C an assignment is not a sequence of write/read because the result is
not really "read".</P>

<P>In C++ we decided to make the result of assignment an lvalue. In
this case we do not have the option to specify the "value" of the
result. That is just the variable itself (or its address in a
different view). So in C++, strictly speaking, the statement
<TT>x=y=0;</TT> must be implemented as <TT>y=0;x=y;</TT> which makes a
big difference if <TT>y</TT> is declared <TT>volatile</TT>.</P>

<P>Furthermore, I think undefined behaviour should not be the result of a
single mentioning of a variable within an expression. So the statement
<TT>(x +=5) += 7;</TT> should NOT have undefined behaviour.</P>

<P>In my view the semantics could be:</P>

<OL>

<LI>if the result of an assignment is used as an rvalue, its value is that of
the variable after assignment. The actual store takes place before the next
sequence point, but may be before the value is used. This is consistent with
C usage.</LI>

<LI>if the result of an assignment is used as an lvalue to store another
value, then the new value will be stored in the variable before the next
sequence point. It is unspecified whether the first assigned value is stored
intermediately.</LI>

<LI>if the result of an assignment is used as an lvalue to take an address,
that address is given (it doesn't change). The actual store of the new value
takes place before the next sequence point.</LI>

</OL>

<P>
<U>Jerry Schwarz</U>:</P>

<P>My recollection is different from Erwin's. I am confident that the
intention when we decided to make assignments lvalues was not to
change the semantics of evaluation of assignments. The semantics was
supposed to remain the same as C's.</P>

<P>Ervin seems to assume that because assignments are lvalues, an
assignment's value must be determined by a read of the location. But
that was definitely not our intention. As he notes this has a
significant impact on the semantics of assignment to a volatile
variable.  If Erwin's interpretation were correct we would have no way
to write a volatile variable without also reading it. </P>

<P>
<U>Lawrence Crowl</U>:</P>

<P>For <TT>x=y=0</TT>, lvalue semantics implies an lvalue to rvalue
conversion on the result of <TT>y=0</TT>, which in turn implies a
read.  If <TT>y</TT> is <TT>volatile</TT>, lvalue semantics implies
both a read and a write on <TT>y</TT>.</P>

<P>The standard apparently doesn't state whether there is a value
dependence of the lvalue result on the completion of the assignment.
Such a statement in the standard would solve the non-volatile C
compatibility issue, and would be consistent with a user-implemented
<TT>operator=</TT>.</P>

<P>Another possible approach is to state that primitive assignment
operators have two results, an lvalue and a corresponding
"after-store" rvalue.  The rvalue result would be used when an rvalue
is required, while the lvalue result would be used when an lvalue is
required.  However, this semantics is unsupportable for user-defined
assignment operators, or at least inconsistent with all
implementations that I know of.  I would not enjoy trying to write
such two-faced semantics.</P>

<P>
<U>Erwin Unruh</U>:</P>

<P>The intent was for assignments to behave the
same as in C. Unfortunately the change of the result to lvalue did not keep
that. An "lvalue of type int" has no "int" value! So there is a difference
between intent and the standard's wording.</P>

<P>So we have one of several choices:</P>

<UL>
<LI>live with the incompatibility (and the problems it has for volatile
variables)</LI>

<LI>make the result of assignment an rvalue (only builtin-assignment, maybe
only for builtin types), which makes some presently valid programs
invalid</LI>

<LI>introduce "two-face semantics" for builtin assignments, and clarify the
sequence problematics</LI>

<LI>make a special rule for assignment to a volatile lvalue of builtin
type</LI>

</UL>

<P>I think the last one has the least impact on existing programs, but it is an
ugly solution.</P>

<P>
<U>Andrew Koenig</U>:</P>
<P>Whatever we may have intended, I do not think that there is any clean
way of making
<PRE>
    volatile int v;
    int i;

    i = v = 42;
</PRE>
have the same semantics in C++ as it does in C.  Like it or not, the
subexpression <TT>v = 42</TT> has the type ``reference to volatile int,''
so if this statement has any meaning at all, the meaning must be to store 42
in <TT>v</TT> and then fetch the value of <TT>v</TT> to assign it to i.</P>

<P>Indeed, if <TT>v</TT> is volatile, I cannot imagine a
conscientious programmer
writing a statement such as this one.  Instead, I would expect to see
<PRE>
    v = 42;
    i = v;
</PRE>
if the intent is to store 42 in <TT>v</TT> and then fetch the (possibly
changed) value of <TT>v</TT>, or
<PRE>
    v = 42;
    i = 42;
</PRE>
if the intent is to store 42 in both <TT>v</TT> and <TT>i</TT>.</P>

<P>What I do want is to ensure that expressions such as ``<TT>i = v = 42</TT>''
have well-defined semantics, as well as expressions such as
<TT>(i = v) = 42</TT> or, more realistically, <TT>(i += v) += 42</TT> .</P>

<P>I wonder if the following resolution is sufficient:</P>

<P>Append to 5.17&nbsp;



 <A HREF="expr.html#expr.ass">expr.ass</A> paragraph 1:</P>
<BLOCKQUOTE>
There is a sequence point between assigning the new value to
the left operand and yielding the result of the assignment
expression.
</BLOCKQUOTE>

<P>I believe that this proposal achieves my desired effect of not
constraining when <TT>j</TT> is incremented in <TT>x[j++] = y</TT>,
because I don't
think there is a constraint on the relative order of incrementing <TT>j</TT>
and executing the assignment.  However, I do think it allows expressions
such as <TT>(i += v) += 42</TT>, although with different semantics from C if
<TT>v</TT> is volatile.</P>

<P>
<B>Notes on 10/01 meeting:</B>
</P>

<P>There was agreement that adding a sequence point is probably the
right solution.</P>

<P>
<B>Notes from the 4/02 meeting:</B>
</P>

<P>The working group reaffirmed the sequence-point solution, but
we will look for any counter-examples where efficiency would be harmed.</P>

<P>For drafting, we note that <TT>++x</TT> is defined in 5.3.2&nbsp;



 <A HREF="expr.html#expr.pre.incr">expr.pre.incr</A> as equivalent to <TT>x+=1</TT> and is therefore
affected by this change.  <TT>x++</TT> is not affected. Also, we
should update any list of all sequence points.</P>

<P>
<B>Notes from October 2004 meeting:</B>
</P>

<P>Discussion centered around whether a sequence point &ldquo;between
assigning the new value to the left operand and yielding the result of
the expression&rdquo; would require completion of all side effects of
the operand expressions before the value of the assignment expression
was used in another expression.  The consensus opinion was that it
would, that this is the definition of a sequence point.  Jason Merrill
pointed out that adding a sequence point after the assignment is
essentially the same as rewriting</P>

<PRE>
    b += a
</PRE>

<P>as</P>

<PRE>
    b += a, b
</PRE>

<P>Clark Nelson expressed a desire for something like a
&ldquo;weak&rdquo; sequence point that would force the assignment to
occur but that would leave the side effects of the operands
unconstrained.  In support of this position, he cited the following
expression:</P>

<PRE>
    j = (i = j++)
</PRE>

<P>With the proposed addition of a full sequence point after the
assignment to <TT>i</TT>, the net effect is no change to <TT>j</TT>.
However, both g++ and MSVC++ behave differently: if the previous value
of <TT>j</TT> is 5, the value of the expression is 5 but <TT>j</TT>
gets the value 6.</P>

<P>Clark Nelson will investigate alternative approaches and report
back to the working group.</P>

<BR>
<BR>
<HR>
<A NAME="232"></A>
<H4>232.
  
Is indirection through a null pointer undefined behavior?
</H4>
<B>Section: </B>5.3.1&nbsp;



 <A HREF="expr.html#expr.unary.op">expr.unary.op</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>drafting
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Mike Miller
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>5 Jun 2000<BR>




<P>At least a couple of places in the IS state that indirection
through a null pointer produces undefined behavior: 1.9&nbsp;



 <A HREF="intro.html#intro.execution">intro.execution</A> paragraph 4 gives "dereferencing the null pointer" as an
example of undefined behavior, and 8.3.2&nbsp;



 <A HREF="decl.html#dcl.ref">dcl.ref</A>
paragraph 4 (in a note) uses this supposedly undefined behavior as
justification for the nonexistence of "null references."</P>

<P>However, 5.3.1&nbsp;



 <A HREF="expr.html#expr.unary.op">expr.unary.op</A> paragraph 1, which describes
the unary "*" operator, does <I>not</I> say that the behavior is
undefined if the operand is a null pointer, as one might expect.
Furthermore, at least one passage gives dereferencing a null pointer
well-defined behavior: 5.2.8&nbsp;



 <A HREF="expr.html#expr.typeid">expr.typeid</A> paragraph 2
says</P>

<BLOCKQUOTE>
If the lvalue expression is obtained by applying the unary * operator
to a pointer and the pointer is a null pointer value (4.10&nbsp;



 <A HREF="conv.html#conv.ptr">conv.ptr</A>), the <TT>typeid</TT> expression throws the
<TT>bad_typeid</TT> exception (18.5.3&nbsp;



 <A HREF="lib-support.html#lib.bad.typeid">lib.bad.typeid</A>).
</BLOCKQUOTE>

<P>This is inconsistent and should be cleaned up.</P>

<P>
<U>Bill Gibbons</U>:</P>

<P>At one point we agreed that dereferencing a null pointer was
<I>not</I> undefined; only using the resulting value had undefined
behavior.</P>

<P>For example:</P>

<PRE>
    char *p = 0;
    char *q = &amp;*p;
</PRE>

<P>Similarly, dereferencing a pointer to the end of an array should be
allowed as long as the value is not used:</P>

<PRE>
    char a[10];
    char *b = &amp;a[10];   // equivalent to "char *b = &amp;*(a+10);"
</PRE>

<P>Both cases come up often enough in real code that they should be
allowed.</P>

<P>
<U>Mike Miller</U>:</P>

<P>I can see the value in this, but it doesn't seem to be well
reflected in the wording of the Standard.  For instance, presumably
<TT>*p</TT> above would have to be an lvalue in order to be the
operand of "<TT>&amp;</TT>", but the definition of "lvalue" in
3.10&nbsp;



 <A HREF="basic.html#basic.lval">basic.lval</A> paragraph 2 says that "an lvalue refers to
an object."  What's the object in <TT>*p</TT>?  If we were to allow
this, we would need to augment the definition to include the result of
dereferencing null and one-past-the-end-of-array.</P>

<P>
<U>Tom Plum</U>:</P>

<P>Just to add one more recollection of the intent: I was <I>very</I>
happy when (I thought) we decided that it was only the attempt to
actually fetch a value that creates undefined behavior.  The words
which (I thought) were intended to clarify that are the first three
sentences of the lvalue-to-rvalue conversion, 4.1&nbsp;



 <A HREF="conv.html#conv.lval">conv.lval</A>:</P>

<BLOCKQUOTE>

An lvalue (3.10&nbsp;



 <A HREF="basic.html#basic.lval">basic.lval</A>) of a non-function, non-array
type <TT>T</TT> can be converted to an rvalue.  If <TT>T</TT> is an
incomplete type, a program that necessitates this conversion is
ill-formed.  If the object to which the lvalue refers is not an object
of type <TT>T</TT> and is not an object of a type derived from
<TT>T</TT>, or if the object is uninitialized, a program that
necessitates this conversion has undefined behavior.

</BLOCKQUOTE>

<P>In other words, it is only the act of "fetching", of
lvalue-to-rvalue conversion, that triggers the ill-formed or undefined
behavior.  Simply forming the lvalue expression, and then for example
taking its address, does not trigger either of those errors.  I
described this approach to WG14 and it may have been incorporated into
C 1999.</P>

<P>
<U>Mike Miller</U>:</P>

<P>If we admit the possibility of null lvalues, as Tom is suggesting
here, that significantly undercuts the rationale for prohibiting "null
references" -- what is a reference, after all, but a named lvalue?  If
it's okay to create a null lvalue, as long as I don't invoke the
lvalue-to-rvalue conversion on it, why shouldn't I be able to capture
that null lvalue as a reference, with the same restrictions on its
use?</P>

<P>I am not arguing in favor of null references.  I don't want them in
the language.  What I am saying is that we need to think carefully
about adopting the permissive approach of saying that it's all right
to create null lvalues, as long as you don't use them in certain ways.
If we do that, it will be very natural for people to question why they
can't pass such an lvalue to a function, as long as the function
doesn't do anything that is not permitted on a null lvalue.
</P>

<P>If we want to allow <TT>&amp;*(p=0)</TT>, maybe we should change
the definition of "<TT>&amp;</TT>" to handle dereferenced null
specially, just as <TT>typeid</TT> has special handling, rather than
changing the definition of lvalue to include dereferenced nulls, and
similarly for the array_end+1 case.  It's not as general, but I think
it might cause us fewer problems in the long run.
</P>

<P>
<B>Notes from the October 2003 meeting:</B>
</P>

<P>See also <A HREF="
     cwg_closed.html#315">issue 315</A>, which deals with
the call of a static member function through a null pointer.</P>

<P>We agreed that the approach in the standard seems okay:
<TT>p = 0; *p;</TT> is not inherently an error.  An
lvalue-to-rvalue conversion would give it undefined behavior.</P>

<P>
<B>Proposed resolution (October, 2004):</B>
</P>

<P>(Note: the resolution of <A HREF="
     cwg_active.html#453">issue 453</A>
also resolves part of this issue.)</P>

<OL>

<LI>
<P>Add the indicated words to 3.10&nbsp;



 <A HREF="basic.html#basic.lval">basic.lval</A>
paragraph 2:</P>

<BLOCKQUOTE>

An lvalue refers to an object or function <B>or is an empty lvalue
(5.3.1&nbsp;



 <A HREF="expr.html#expr.unary.op">expr.unary.op</A>)</B>.

</BLOCKQUOTE>

</LI>

<LI>
<P>Add the indicated words to 5.3.1&nbsp;



 <A HREF="expr.html#expr.unary.op">expr.unary.op</A>
paragraph 1:</P>

<BLOCKQUOTE>

The unary <TT>*</TT> operator performs <I>indirection</I>: the
expression to which it is applied shall be a pointer to an object
type, or a pointer to a function type and the result is an lvalue
referring to the object or function to which the expression
points<B>, if any. If the pointer is a null pointer value
(4.10&nbsp;



 <A HREF="conv.html#conv.ptr">conv.ptr</A>) or points one past the last element
of an array object (5.7&nbsp;



 <A HREF="expr.html#expr.add">expr.add</A>), the result is an
<I>empty lvalue</I> and does not refer to any object or function.
An empty lvalue is not modifiable</B>.  If the type of the
expression is &ldquo;pointer to <TT>T</TT>,&rdquo; the type of
the result is &ldquo;<TT>T</TT>.&rdquo; [<I>Note:</I> a pointer to an
incomplete type (other than cv void) can be dereferenced. The
lvalue thus obtained can be used in limited ways (to initialize a
reference, for example); this lvalue must not be converted to an
rvalue, see 4.1&nbsp;



 <A HREF="conv.html#conv.lval">conv.lval</A>.&mdash;<I>end note</I>]

</BLOCKQUOTE>

</LI>

<LI>
<P>Add the indicated words to 4.1&nbsp;



 <A HREF="conv.html#conv.lval">conv.lval</A>
paragraph 1:</P>

<BLOCKQUOTE>

If the object to which the lvalue refers is not an object of type
<TT>T</TT> and is not an object of a type derived from
<TT>T</TT>, or if the object is uninitialized, <B>or if the
lvalue is an empty lvalue (5.3.1&nbsp;



 <A HREF="expr.html#expr.unary.op">expr.unary.op</A>),</B> a
program that necessitates this conversion has undefined behavior.

</BLOCKQUOTE>

</LI>

<LI>
<P>Change 1.9&nbsp;



 <A HREF="intro.html#intro.execution">intro.execution</A> as indicated:</P>

<BLOCKQUOTE>

Certain other operations are described in this International
Standard as undefined (for example, the effect of <S>dereferencing
the null pointer</S> <B>division by zero</B>).

</BLOCKQUOTE>

</LI>

</OL>

<P>
<B>Note (March, 2005):</B>
</P> 

<P>The 10/2004 resolution interacts with the resolution of <A HREF="
     cwg_defects.html#73">issue 73</A>.  We added wording to 3.9.2&nbsp;



 <A HREF="basic.html#basic.compound">basic.compound</A> paragraph 3 to the effect that a pointer containing
the address one past the end of an array is considered to &ldquo;point
to&rdquo; another object of the same type that might be located there.
The 10/2004 resolution now says that it would be undefined behavior to
use such a pointer to fetch the value of that object.  There is at
least the appearance of conflict here; it may be all right, but it at
needs to be discussed further.</P>

<P>
<B>Notes from the April, 2005 meeting:</B>
</P>

<P>The CWG agreed that there is no contradiction between this
direction and the resolution of <A HREF="
     cwg_defects.html#73">issue 73</A>.
However, &ldquo;not modifiable&rdquo; is a compile-time concept, while
in fact this deals with runtime values and thus should produce
undefined behavior instead.  Also, there are other contexts in which
lvalues can occur, such as the left operand of <TT>.</TT>
or <TT>.*</TT>, which should also be restricted.  Additional drafting
is required.</P>

<BR>
<BR>
<HR>
<A NAME="531"></A>
<H4>531.
  
Defining members of explicit specializations
</H4>
<B>Section: </B>5.19&nbsp;



 <A HREF="expr.html#expr.const">expr.const</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>drafting
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Mike Miller
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>1 October 2005<BR>


<P>The Standard does not fully describe the syntax to be used when a
member of an explicitly-specialized member class or member class
template is defined in namespace scope.  14.7.3&nbsp;



 <A HREF="template.html#temp.expl.spec">temp.expl.spec</A>
paragraph 4 says that the &ldquo;explicit specialization syntax&rdquo;
(presumably referring to &ldquo;<TT>template&lt;&gt;</TT>&rdquo;) is
not used in defining a member of an explicit specialization when a
class template is explicitly specialized as a class.  However, nothing
is said anywhere about how to define a member of a specialization
when:</P>

<OL>
<LI>
<P>the entity being specialized is a class (member of a
template class) rather than a class template.</P>
</LI>

<LI>
<P>the result of the specialization is a class template rather
than a class (cf 14.7.3&nbsp;



 <A HREF="template.html#temp.expl.spec">temp.expl.spec</A> paragraph 18, which
describes this case as a &ldquo;member template that...
remain[s] unspecialized&rdquo;).</P>
</LI>
</OL>

<P>(See paper J16/05-0148 = WG21 N1888 for further details, including
a survey of existing implementation practice.)</P>

<P>
<B>Notes from the October, 2005 meeting:</B>
</P>

<P>The CWG felt that the best approach, balancing consistency with
implementation issues and existing practice, would be to require that
<TT>template&lt;&gt;</TT> be used when defining members of all
explicit specializations, including those currently covered by
14.7.3&nbsp;



 <A HREF="template.html#temp.expl.spec">temp.expl.spec</A> paragraph 4.</P>

<BR>
<BR>
<HR>
<A NAME="276"></A>
<H4>276.
  
Order of destruction of parameters and temporaries
</H4>
<B>Section: </B>6.6&nbsp;



 <A HREF="stmt.html#stmt.jump">stmt.jump</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>drafting
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>James Kanze
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>28 Mar 2001<BR>


<P>According to 6.6&nbsp;



 <A HREF="stmt.html#stmt.jump">stmt.jump</A> paragraph 2,</P>

<BLOCKQUOTE>

On exit from a scope (however accomplished), destructors (12.4&nbsp;



 <A HREF="special.html#class.dtor">class.dtor</A>) are called for all constructed objects with automatic
storage duration (3.7.2&nbsp;



 <A HREF="basic.html#basic.stc.auto">basic.stc.auto</A>) (named objects or
temporaries) that are declared in that scope, in the reverse order of
their declaration.

</BLOCKQUOTE>

<P>This wording is problematic for temporaries and for parameters.
First, temporaries are not "declared," so this requirement does not
apply to them, in spite of the assertion in the quoted text that it
does.</P>

<P>Second, although the parameters of a function are <I>declared</I>
in the called function, they are constructed and destroyed in the
calling context, and the order of evaluation of the arguments is
unspecified (cf 5.2.2&nbsp;



 <A HREF="expr.html#expr.call">expr.call</A> paragraphs 4 and 8).
The order of destruction of the parameters might, therefore, be
different from the reverse order of their declaration.</P>

<P>
<B>Notes from 04/01 meeting:</B>
</P>

<P>Any resolution of this issue should be careful not to introduce
requirements that are redundant or in conflict with those of other
parts of the IS.  This is especially true in light of the pending
issues with respect to the destruction of temporaries (see issues
<A HREF="
     cwg_active.html#86">86</A>, <A HREF="
     cwg_defects.html#124">124</A>,
<A HREF="
     cwg_active.html#199">199</A>, and <A HREF="
     cwg_defects.html#201">201</A>).
If possible, the wording of a resolution should simply reference
the relevant sections.</P>

<P>It was also noted that the temporary for a return value is
also destroyed "out of order."  </P>

<P>Note that <A HREF="
     cwg_active.html#378">issue 378</A> picks a nit
with the wording of this same paragraph.</P>

<BR>
<BR>
<HR>
<A NAME="407"></A>
<H4>407.
  
Named class with associated typedef: two names or one?
</H4>
<B>Section: </B>7.1.3&nbsp;



 <A HREF="dcl.html#dcl.typedef">dcl.typedef</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>drafting
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Clark Nelson
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>31 March 2003<BR>


<P>Here's an example:</P>
<PRE>
  typedef struct S { ... } S;
  void fs(S *x) { ... }
</PRE>
<P>The big question is, to what declaration does the reference to identifier S
actually refer? Is it the S that's declared as a typedef name, or the S
that's declared as a class name (or in C terms, as a struct tag)? (In either
case, there's clearly only one type to which it could refer, since a typedef
declaration does not introduce a new type. But the debugger apparently cares
about more than just the identity of the type.)</P>

<P>Here's a classical, closely related example:</P>
<PRE>
  struct stat { ... };
  int stat();
  ... stat( ... ) ...
</PRE>
<P>Does the identifier stat refer to the class or the function? Obviously, in
C, you can't refer to the struct tag without using the struct keyword,
because it is in a different name space, so the reference must be to the
function. In C++, the reference is also to the function, but for a
completely different reason.</P>

<P>Now in C, typedef names and function names are in the same name space, so
the natural extrapolation would be that, in the first example, S refers to
the typedef declaration, as it would in C. But C++ is not C. For the
purposes of this discussion, there are two important differences between C
and C++</P>

<P>The first difference is that, in C++, typedef names and class names are not
in separate name spaces. On the other hand, according to section
3.3.7&nbsp;



 <A HREF="basic.html#basic.scope.hiding">basic.scope.hiding</A> (Name hiding), paragraph 2:</P>
<BLOCKQUOTE>
A class name (9.1) or enumeration name (7.2) can be hidden by <B>the name of
an object, function, or enumerator</B> declared in the same scope. If a class
or enumeration name and an object, function, or enumerator are declared in
the same scope (in any order) with the same name, the class or enumeration
name is hidden wherever the object, function, or enumerator name is
visible.
</BLOCKQUOTE>

<P>Please consider carefully the phrase I have highlighted, and the fact that a
typedef name is not the name of an object, function or enumerator. As a
result, this example:</P>
<PRE>
  struct stat { ... };
  typedef int stat;
</PRE>
<P>Which would be perfectly legal in C, is disallowed in C++, both implicitly
(see the above quote) and explicitly (see section
7.1.3&nbsp;



 <A HREF="dcl.html#dcl.typedef">dcl.typedef</A> (The typedef
specifier), paragraph 3):</P>
<BLOCKQUOTE>
In a given scope, a typedef specifier shall not be used to redefine the
name of any type declared in that scope to refer to a different type.
Similarly, in a given scope, a class or enumeration shall not be declared
with the same name as a typedef-name that is declared in that scope and
refers to a type other than the class or enumeration itself.
</BLOCKQUOTE>

<P>From which we can conclude that in C++ typedef names do not hide class names
declared in the same scope. If they did, the above example would be legal.</P>

<P>The second difference is that, in C++, a typedef name that refers to a class
is a class-name; see 7.1.3&nbsp;



 <A HREF="dcl.html#dcl.typedef">dcl.typedef</A> paragraph 4:</P>
<BLOCKQUOTE>
A typedef-name that names a class is a class-name(9.1). If a typedef-name
is used following the class-key in an elaborated-type-specifier (7.1.5.3) or
in the class-head of a class declaration (9), or is used as the identifier
in the declarator for a constructor or destructor declaration (12.1, 12.4),
the program is ill-formed.
</BLOCKQUOTE>

<P>This implies, for instance, that a typedef-name referring to a class can be
used in a nested-name-specifier (i.e. before :: in a qualified name) or
following ~ to refer to a destructor. Note that using a typedef-name as a
class-name in an elaborated-type-specifier is not allowed. For example:</P>
<PRE>
  struct X { };
  typedef struct X X2;
  X x; // legal
  X2 x2; // legal
  struct X sx; // legal
  struct X2 sx2; // illegal
</PRE>

<P>The final relevant piece of the standard is
7.1.3&nbsp;



 <A HREF="dcl.html#dcl.typedef">dcl.typedef</A> paragraph 2:</P>
<BLOCKQUOTE>
In a given scope, a typedef specifier can be used to redefine the name of
any type declared in that scope to refer to the type to which it already
refers.
</BLOCKQUOTE>

<P>This of course is what allows the original example, to which let us now
return:</P>
<PRE>
  typedef struct S { ... } S;
  void fs(S *x) { ... }
</PRE>
<P>The question, again is, to which declaration of S does the reference
actually refer? In C, it would clearly be to the second, since the first
would be accessible only by using the struct keyword. In C++, if typedef
names hid class names declared in the same scope, the answer would be the
same. But we've already seen that typedef names do not hide class names
declared in the same scope.</P>

<P>So to which declaration does the reference to S refer? The answer is that it
doesn't matter. The second declaration of S, which appears to be a
declaration of a typedef name, is actually a declaration of a class name
(7.1.3&nbsp;



 <A HREF="dcl.html#dcl.typedef">dcl.typedef</A> paragraph 4), and as such is simply a
redeclaration. Consider the following example:</P>
<PRE>
  typedef int I, I;
  extern int x, x;
  void f(), f();
</PRE>
<P>To which declaration would a reference to I, x or f refer? It doesn't
matter, because the second declaration of each is really just a
redeclaration of the thing declared in the first declaration. So to save
time, effort and complexity, the second declaration of each doesn't add any
entry to the compiler's symbol table.</P>

<P>
<B>Note (March, 2005):</B>
</P>



<P>
<U>Matt Austern</U>: Is this legal?</P>

<PRE>
    struct A { };
    typedef struct A A;
    struct A* p;
</PRE>

<P>Am I right in reading the standard [to say that this is
ill-formed]?  On the one hand it's a nice uniform rule.  On the other
hand, it seems likely to confuse users.  Most people are probably used
to thinking that 'typedef struct A A' is a null operation, and, if
this code really is illegal, it would seem to be a gratuitous C/C++
incompatibility.</P>

<P>
<U>Mike Miller</U>: I think you're right.  7.1.3&nbsp;



 <A HREF="dcl.html#dcl.typedef">dcl.typedef</A> paragraph 1:</P>

<BLOCKQUOTE>

A name declared with the <TT>typedef</TT> specifier becomes a
<I>typedef-name</I>.

</BLOCKQUOTE>

<P>7.1.3&nbsp;



 <A HREF="dcl.html#dcl.typedef">dcl.typedef</A> paragraph 2:</P>

<BLOCKQUOTE>

In a given non-class scope, a <TT>typedef</TT> specifier can be used
to redefine the name of any type declared in that scope
to refer to the type to which it already refers.

</BLOCKQUOTE>

<P>After the <TT>typedef</TT> declaration in the example, the name
<TT>X</TT> has been &ldquo;redefined&rdquo; &mdash; it is no longer
just a <I>class-name</I>, it has been &ldquo;redefined&rdquo; to be a
<I>typedef-name</I> (that, by virtue of the fact that it refers to a
class type, is also a <I>class-name</I>).</P>

<P>
<U>John Spicer</U>: In C, and originally in C++, an
<I>elaborated-type-specifier</I> did not consider typedef names, so
&ldquo;<TT>struct X* x</TT>&rdquo; would find the class and not the
typedef.</P>

<P>When C++ was changed to make typedefs visible to
<I>elaborated-type-specifier</I> lookups, I believe this issue was
overlooked and inadvertantly made ill-formed.
</P>

<P>I suspect we need add text saying that if a given scope contains
both a class/enum and a typedef, that an elaborated type specifier
lookup finds the class/enum.
</P>

<P>
<U>Mike Miller</U>: I'm a little uncomfortable with this approach.
The model we have for declaring a typedef in the same scope as a
class/enum is redefinition, not hiding (like the &ldquo;<TT>struct
stat</TT>&rdquo; hack).  This approach seems to assume that the
typedef hides the class/enum, which can then be found by an
<I>elaborated-type-specifier</I>, just as if it were hidden by a
variable, function, or enumerator.
</P>

<P>Also, this approach reduces but doesn't eliminate the
incompatibility with C.  For example:
</P>

<PRE>
    struct S { };
    {
        typedef struct S S;
        struct S* p;        // still ill-formed
    }
</PRE>

<P>My preference would be for something following the basic principle
that declaring a <I>typedef-name</I> <TT>T</TT> in a scope where
<TT>T</TT> already names the type designated by the typedef should
have no effect on whether an <I>elaborated-type-specifier</I> in that
or a nested scope is well-formed or not.  Another way of saying that
is that a <I>typedef-name</I> that designates a same-named class or
enumeration in the same or a containing scope is transparent with
respect to <I>elaborated-type-specifier</I>s.</P>

<P>
<U>John Spicer</U>: This strikes me as being a rather complicated
solution. When we made the change to make typedefs visible to
<I>elaborated-type-specifier</I>s we did so knowing it would make some
C cases ill-formed, so this does not bother me.  We've lived with the
C incompatibility for many years now, so I don't personally feel a
need to undo it.  I also don't like the fact that you have to
essentially do the old-style <I>elaborated-type-specifier</I> lookup
to check the result of the lookup that found the typedef.
</P>

<P>I continue to prefer the direction I described earlier where if a
given scope contains both a class/enum and a typedef, that an
<I>elaborated-type-specifier</I> lookup finds the class/enum.
</P>

<P>
<B>Notes from the April, 2005 meeting:</B>
</P>

<P>The CWG agreed with John Spicer's approach, i.e., permitting
a <I>typedef-name</I> to be used in an
<I>elaborated-type-specifier</I> only if it is declared in the same
scope as the class or enumeration it names.</P>

<BR>
<BR>
<HR>
<A NAME="138"></A>
<H4>138.
  
Friend declaration name lookup
</H4>
<B>Section: </B>7.3.1.2&nbsp;



 <A HREF="dcl.html#namespace.memdef">namespace.memdef</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>drafting
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Martin von Loewis
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>14 Jul 1999<BR>





<P>7.3.1.2&nbsp;



 <A HREF="dcl.html#namespace.memdef">namespace.memdef</A>
 paragraph 3 says,</P>

<BLOCKQUOTE>
If a <TT>friend</TT> declaration in a non-local class first declares a
class or function the friend class or function is a member of the
innermost enclosing namespace...  When looking for a prior declaration
of a class or a function declared as a <TT>friend</TT>, scopes outside
the innermost enclosing namespace scope are not considered.
</BLOCKQUOTE>

It is not clear from this passage how to determine whether an entity
is "first declared" in a <TT>friend</TT> declaration.  One question is
whether a <I>using-declaration</I> influences this determination.
For instance:

<PRE>
    void foo();
    namespace A{
      using ::foo;
      class X{
	friend void foo();
      };
    }
</PRE>

Is the <TT>friend</TT> declaration a reference to <TT>::foo</TT> or
a different <TT>foo</TT>?

<P>Part of the question involves determining the meaning of
the word "synonym" in
7.3.3&nbsp;



 <A HREF="dcl.html#namespace.udecl">namespace.udecl</A>
 paragraph 1:</P>

<BLOCKQUOTE>
A <I>using-declaration</I> introduces a name into the declarative
region in which the <I>using-declaration</I> appears.  That name
is a synonym for the name of some entity declared elsewhere.
</BLOCKQUOTE>

Is "<TT>using ::foo;</TT>" the declaration of a function or not?

<P>More generally, the question is how to describe the lookup of the
name in a <TT>friend</TT> declaration.</P>

<P>
<U>John Spicer</U>:
When a declaration specifies an unqualified name, that
name is declared, not looked up.  There is a mechanism in which that
declaration is linked to a prior declaration, but that mechanism is
not, in my opinion, via normal name lookup.  So, the friend always
declares a member of the nearest namespace scope regardless of how
that name may or may not already be declared there.</P>

<P>
<U>Mike Miller</U>:
3.4.1&nbsp;



 <A HREF="basic.html#basic.lookup.unqual">basic.lookup.unqual</A>
 paragraph 7 says:</P>

<BLOCKQUOTE>
A name used in the definition of a class <TT>X</TT> outside of a
member function body or nested class definition shall be declared in
one of the following ways:...  [<I>Note:</I> when looking for a
prior declaration of a class or function introduced by a <TT>friend</TT>
declaration, scopes outside of the innermost enclosing namespace scope
are not considered.]
</BLOCKQUOTE>

The presence of this note certainly implies that this paragraph
describes the lookup of names in <TT>friend</TT> declarations.

<P>
<U>John Spicer</U>:
It most certainly does not.  If that section described the friend
lookup it would yield the incorrect results for the friend declarations
of <TT>f</TT> and <TT>g</TT> below.
I don't know why that note is there, but it can't
be taken to mean that that is how the friend lookup is done.</P>

<PRE>
    void f(){}
    void g(){}
    class B {
        void g();
    };
    class A : public B {
        void f();
        friend void f(); // ::f not A::f
        friend void g(); // ::g not B::g
    };
</PRE>

<P>
<U>Mike Miller</U>:
If so, the lookups for friend functions and classes behave differently.
Consider the example in
3.4.4&nbsp;



 <A HREF="basic.html#basic.lookup.elab">basic.lookup.elab</A>
 paragraph 3:</P>

<PRE>
    struct Base {
        struct Data;         // <I>OK: declares nested</I> Data
        friend class Data;   // <I>OK: nested</I> Data <I>is a friend</I>
    };
</PRE>

<P>If the <TT>friend</TT> declaration is <I>not</I> a reference to
<TT>::foo</TT>, there is a related but separate question: does the
<TT>friend</TT> declaration introduce a conflicting (albeit "invisible")
declaration into namespace <TT>A</TT>, or is it simply a reference
to an as-yet undeclared (and, in this instance, undeclarable)
<TT>A::foo</TT>?  Another part of the example in
3.4.4&nbsp;



 <A HREF="basic.html#basic.lookup.elab">basic.lookup.elab</A>
 paragraph 3 is
related:</P>

<PRE>
    struct Data {
        friend struct Glob;  // <I>OK: Refers to (as yet) undeclared</I> Glob
                             // <I>at global scope.</I>
    };
</PRE>

<P>
<U>John Spicer</U>:
You can't refer to something that has not yet been declared.  The friend
is a declaration of <TT>Glob</TT>,
it just happens to declare it in a such a way that
its name cannot be used until it is redeclared.</P>

<P>(A somewhat similar question has been raised in connection with
<A HREF="
     cwg_active.html#36">issue 36</A>.  Consider:</P>

<PRE>
    namespace N {
        struct S { };
    }
    using N::S;
    struct S;          // legal?
</PRE>

<P>According to 9.1&nbsp;



 <A HREF="class.html#class.name">class.name</A> paragraph 2,</P>

<BLOCKQUOTE>

A declaration consisting solely of <I>class-key identifier ;</I>
is either a redeclaration of the name in the current scope or a
forward declaration of the identifier as a class name.

</BLOCKQUOTE>

<P>Should the elaborated type declaration in this example be
considered a redeclaration of <TT>N::S</TT> or an invalid
forward declaration of a different class?)</P>

<P>(See also issues
<A HREF="
     cwg_closed.html#95">95</A>,
<A HREF="
     cwg_defects.html#136">136</A>,
<A HREF="
     cwg_defects.html#139">139</A>,
<A HREF="
     cwg_defects.html#143">143</A>,
<A HREF="
     cwg_closed.html#165">165</A>, and
<A HREF="
     cwg_defects.html#166">166</A>, as well as paper J16/00-0006 = WG21
N1229.)</P>



<BR>
<BR>
<HR>
<A NAME="341"></A>
<H4>341.
  
<TT>extern "C"</TT> namespace member function versus global variable
</H4>
<B>Section: </B>7.5&nbsp;



 <A HREF="dcl.html#dcl.link">dcl.link</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>drafting
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Steve Adamczyk
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>1 Mar 2002<BR>




<P>Here's an interesting case:
<PRE>
  int f;
  namespace N {
    extern "C" void f () {}
  }
</PRE>
As far as I can tell, this is not precluded by the ODR section
(3.2&nbsp;



 <A HREF="basic.html#basic.def.odr">basic.def.odr</A>)
or the extern "C" section (7.5&nbsp;



 <A HREF="dcl.html#dcl.link">dcl.link</A>).
However, I believe many compilers
do not do name mangling on variables and (more-or-less by definition)
on extern "C" functions.  That means the variable and the function
in the above end up having the same name at link time.  EDG's front
end, g++, and the Sun compiler all get essentially the same error,
which is a compile-time assembler-level error because of the
duplicate symbols (in other words, they fail to check for this, and the
assembler complains).  MSVC++ 7 links the program without error,
though I'm not sure how it is interpreted.</P>

<P>Do we intend for this case to be valid?  If not, is it a compile time
error (required), or some sort of ODR violation (no diagnostic
required)?  If we do intend for it to be valid, are we forcing
many implementations to break binary compatibility by requiring
them to mangle variable names?</P>

<P>Personally, I favor a compile-time error, and an ODR prohibition on
such things in separate translation units.</P>

<P>
<B>Notes from the 4/02 meeting:</B>
</P>

<P>The working group agreed with the proposal.  We feel a diagnostic
should be required for declarations within one translation unit.
We also noted that if the variable in global scope in the above example
were declared static we would still expect an error.</P>

<P>Relevant sections in the
standard are 7.5&nbsp;



 <A HREF="dcl.html#dcl.link">dcl.link</A> paragraph 6 and
3.5&nbsp;



 <A HREF="basic.html#basic.link">basic.link</A> paragraph 9.  We feel that the definition
should be written such that the entities in conflict are not "the same
entity" but merely not allowed together.</P>

<P>
<B>Additional note (September, 2004)</B>
</P>

<P>This problem need not involve a conflict between a function
and a variable; it can also arise with two variable
declarations:</P>

<PRE>
    int x;
    namespace N {
        extern "C" int x;
    }
</PRE>
<BR>
<BR>
<HR>
<A NAME="374"></A>
<H4>374.
  
Can explicit specialization outside namespace use qualified name?
</H4>
<B>Section: </B>8.3&nbsp;



 <A HREF="decl.html#dcl.meaning">dcl.meaning</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>drafting
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Steve Adamczyk
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>23 August 2002<BR>


<P>This case is nonstandard by 8.3&nbsp;



 <A HREF="decl.html#dcl.meaning">dcl.meaning</A> paragraph 1
(there is a requirement that the specialization first be declared within
the namespace before being defined outside of the namespace),
but probably should be allowed:</P>
<PRE>
  namespace NS1 {
    template&lt;class T&gt;
    class CDoor {
    public:
      int mtd() { return 1; }
    };
  }
  template&lt;&gt; int NS1::CDoor&lt;char&gt;::mtd()
  {
    return 0;
  }
</PRE>

<P>
<B>Notes from October 2002 meeting:</B>
</P>

<P>There was agreement that we wanted to allow this.</P>

<BR>
<BR>
<HR>
<A NAME="393"></A>
<H4>393.
  
Pointer to array of unknown bound in template argument list in parameter
</H4>
<B>Section: </B>8.3.5&nbsp;



 <A HREF="decl.html#dcl.fct">dcl.fct</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>drafting
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Mark Mitchell
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>12 Dec 2002<BR>


<P>EDG rejects this code:
<PRE>
  template &lt;typename T&gt;
  struct S {};

  void f (S&lt;int (*)[]&gt;);
</PRE>
G++ accepts it.</P>

<P>This is another case where the standard isn't very clear:</P>

<P>The language from 8.3.5&nbsp;



 <A HREF="decl.html#dcl.fct">dcl.fct</A> is:
 <BLOCKQUOTE>
   If the type of a parameter includes a type of the form "pointer to
   array of unknown bound of T" or "reference to array of unknown bound
   of T," the program is ill-formed.
 </BLOCKQUOTE>
 Since "includes a type" is not a term defined in the standard, we're
 left to guess what this means.  (It would be better if this were a
 recursive definition, the way a type theoretician would do it:
 <UL>
 <LI> Every type includes itself. </LI>
 <LI> T* includes T </LI>
 <LI> T[] includes T </LI>
 <LI> ... </LI>
 </UL>
 )
 </P>

<P>
<B>Notes from April 2003 meeting:</B>
</P>

<P>We agreed that the example should be allowed.</P>

<BR>
<BR>
<HR>
<A NAME="233"></A>
<H4>233.
  
References vs pointers in UDC overload resolution
</H4>
<B>Section: </B>8.5.3&nbsp;



 <A HREF="decl.html#dcl.init.ref">dcl.init.ref</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>drafting
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Matthias Meixner
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>9 Jun 2000<BR>


<P>There is an inconsistency in the handling of references
vs pointers in user defined conversions and overloading. The reason
for that is that the combination of 8.5.3&nbsp;



 <A HREF="decl.html#dcl.init.ref">dcl.init.ref</A> and
4.4&nbsp;



 <A HREF="conv.html#conv.qual">conv.qual</A> circumvents the standard way of ranking
conversion functions, which was probably not the intention of the
designers of the standard.</P>

<P>Let's start with some examples, to show what it is about:</P>

<PRE>
    struct Z { Z(){} };

    struct A {
       Z x;

       operator Z *() { return &amp;x; }
       operator const Z *() { return &amp;x; }
    };

    struct B {
       Z x;

       operator Z &amp;() { return x; }
       operator const Z &amp;() { return x; }
    };

    int main()
    {
       A a;
       Z *a1=a;
       const Z *a2=a; // not ambiguous

       B b;
       Z &amp;b1=b;
       const Z &amp;b2=b; // ambiguous
    }
</PRE>

<P>So while both classes <TT>A</TT> and <TT>B</TT> are structurally
equivalent, there is a difference in operator overloading. I want to
start with the discussion of the pointer case (<TT>const Z
*a2=a;</TT>): 13.3.3&nbsp;



 <A HREF="over.html#over.match.best">over.match.best</A> is used to select the best
viable function. Rule 4 selects <TT>A::operator const Z*()</TT> as
best viable function using 13.3.3.2&nbsp;



 <A HREF="over.html#over.ics.rank">over.ics.rank</A> since the
implicit conversion sequence <TT>const Z*</TT> -&gt; <TT>const Z*</TT>
is a better conversion sequence than <TT>Z*</TT> -&gt; <TT>const
Z*</TT>.</P>

<P>So what is the difference to the reference case?  Cv-qualification
conversion is only applicable for pointers according to 4.4&nbsp;



 <A HREF="conv.html#conv.qual">conv.qual</A>. According to 8.5.3&nbsp;



 <A HREF="decl.html#dcl.init.ref">dcl.init.ref</A> paragraphs
4-7 references are initialized by binding using the concept of
reference-compatibility. The problem with this is, that in this
context of binding, there is no conversion, and therefore there is
also no comparing of conversion sequences. More exactly all
conversions can be considered identity conversions according to
13.3.3.1.4&nbsp;



 <A HREF="over.html#over.ics.ref">over.ics.ref</A> paragraph 1, which compare equal
and which has the same effect.  So binding <TT>const Z*</TT> to
<TT>const Z*</TT> is as good as binding <TT>const Z*</TT> to
<TT>Z*</TT> in terms of overloading. Therefore <TT>const Z
&amp;b2=b;</TT> is ambiguous.  [13.3.3.1.4&nbsp;



 <A HREF="over.html#over.ics.ref">over.ics.ref</A>
paragraph 5 and 13.3.3.2&nbsp;



 <A HREF="over.html#over.ics.rank">over.ics.rank</A> paragraph 3 rule 3
(S1 and S2 are reference bindings ...) do not seem to apply to this
case]</P>

<P>There are other ambiguities, that result in the special treatment
of references: Example:</P>

<PRE>
    struct A {int a;};
    struct B: public A { B() {}; int b;};

    struct X {
       B x;
       operator A &amp;() { return x; }
       operator B &amp;() { return x; }
    };

    main()
    {
       X x;
       A &amp;g=x; // ambiguous
    }
</PRE>

<P>Since both references of class <TT>A</TT> and <TT>B</TT> are
reference compatible with references of class <TT>A</TT> and since
from the point of ranking of implicit conversion sequences they are
both identity conversions, the initialization is ambiguous.
</P>

<P>So why should this be a defect?</P>

<UL>

<LI>References behave fundamentally different from pointers in combination 
with user defined conversions, although there is no reason to have this
different treatment.</LI>

<LI>This difference only shows up in combination with user defined
conversion sequences, for all other cases, there are special rules,
e.g. 13.3.3.2&nbsp;



 <A HREF="over.html#over.ics.rank">over.ics.rank</A> paragraph 3 rule 3.</LI>

</UL>

<P>So overall I think this was not the intention of the authors of the
standard.</P>

<P>So how could this be fixed? For comparing conversion sequences (and
only for comparing) reference binding should be treated as if it was a
normal assignment/initialization and cv-qualification would have to be
defined for references. This would affect 8.5.3&nbsp;



 <A HREF="decl.html#dcl.init.ref">dcl.init.ref</A> paragraph 6, 4.4&nbsp;



 <A HREF="conv.html#conv.qual">conv.qual</A> and probably
13.3.3.2&nbsp;



 <A HREF="over.html#over.ics.rank">over.ics.rank</A> paragraph 3.</P>

<P>Another fix could be to add a special case in 13.3.3&nbsp;



 <A HREF="over.html#over.match.best">over.match.best</A> paragraph 1. </P>

<BR>
<BR>
<HR>
<A NAME="472"></A>
<H4>472.
  
Casting across protected inheritance
</H4>
<B>Section: </B>11.5&nbsp;



 <A HREF="access.html#class.protected">class.protected</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>drafting
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Mike Miller
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>16 Jun 2004<BR>


<P>Does the restriction in 11.5&nbsp;



 <A HREF="access.html#class.protected">class.protected</A> apply to
upcasts across protected inheritance, too?  For instance,</P>

<PRE>
    struct B {
        int i;
    };
    struct I: protected B { };
    struct D: I {
        void f(I* ip) {
            B* bp = ip;    // well-formed?
            bp-&gt;i = 5;     // aka "ip-&gt;i = 5;"
        }
    };
</PRE>

<P>I think the rationale for the 11.5&nbsp;



 <A HREF="access.html#class.protected">class.protected</A>
restriction applies equally well here &mdash; you don't know whether
<TT>ip</TT> points to a <TT>D</TT> object or not, so <TT>D::f</TT> can't be trusted to treat
the protected <TT>B</TT> subobject consistently with the policies of its
actual complete object type.</P>

<P>The current treatment of &ldquo;accessible base class&rdquo;
in 11.2&nbsp;



 <A HREF="access.html#class.access.base">class.access.base</A> paragraph 4
clearly makes the conversion from <TT>I*</TT> to <TT>B*</TT> well-formed.  I
think that's wrong and needs to be fixed.  The rationale for
the accessibility of a base class is whether &ldquo;an invented
public member&rdquo; of the base would be accessible at the point of
reference, although we obscured that a bit in the
reformulation; it seems to me that the invented member ought to
be considered a non-static member for this purpose and thus
subject to 11.5&nbsp;



 <A HREF="access.html#class.protected">class.protected</A>.</P>

(See also issues <A HREF="
     cwg_defects.html#385">385</A> and <A HREF="
     cwg_closed.html#471">471</A>.).

<P>
<B>Notes from October 2004 meeting:</B>
</P>

<P>The CWG tentatively agreed that casting across protective
inheritance should be subject to the additional restriction in
11.5&nbsp;



 <A HREF="access.html#class.protected">class.protected</A>.</P>



<BR>
<BR>
<HR>
<A NAME="462"></A>
<H4>462.
  
Lifetime of temporaries bound to comma expressions
</H4>
<B>Section: </B>12.2&nbsp;



 <A HREF="special.html#class.temporary">class.temporary</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>drafting
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Steve Adamczyk
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>April 2004<BR>


<P>Split off from <A HREF="
     cwg_active.html#86">issue 86</A>.</P>

<P>Should binding a reference to the result of a "," operation
whose second operand is a temporary extend the lifetime of the
temporary?</P>
<PRE>
  const SFileName &amp;C = ( f(), SFileName("abc") );
</PRE>

<P>
<B>Notes from the March 2004 meeting:</B>
</P>

<P>We think the temporary should be extended.</P>

<P>
<B>Proposed resolution (October, 2004):</B>
</P>

<P>Change 12.2&nbsp;



 <A HREF="special.html#class.temporary">class.temporary</A> paragraph 2 as
indicated:</P>

<BLOCKQUOTE>

... In all these cases, the temporaries created during the
evaluation of the expression initializing the reference, except
the temporary <B>that is the overall result of the expression
[<I>Footnote:</I> For example, if the expression is a comma
expression (5.18&nbsp;



 <A HREF="expr.html#expr.comma">expr.comma</A>) and the value of its
second operand is a temporary, the reference is bound to that
temporary.] and</B> to which the reference is bound, are destroyed at
the end of the full-expression in which they are created and in
the reverse order of the completion of their construction...

</BLOCKQUOTE>

<P>
<I>[Note: this wording partially resolves <A HREF="
     cwg_active.html#86">issue 86</A>.  See also <A HREF="
     cwg_defects.html#446">issue 446</A>.]</I>
</P>

<P>
<B>Notes from the April, 2005 meeting:</B>
</P>

<P>The CWG suggested a different approach from the 10/2004 resolution,
leaving 12.2&nbsp;



 <A HREF="special.html#class.temporary">class.temporary</A> unchanged and adding normative
wording to 5.18&nbsp;



 <A HREF="expr.html#expr.comma">expr.comma</A> specifying that, if the result
of the second operand is a temporary, that temporary is the result of
the comma expression as well.</P>

<BR>
<BR>
<HR>
<A NAME="399"></A>
<H4>399.
  
Destructor lookup redux
</H4>
<B>Section: </B>12.4&nbsp;



 <A HREF="special.html#class.dtor">class.dtor</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>drafting
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>John Spicer
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>17 Jan 2003<BR>


<P>Mark Mitchell raised a number of issues related to the resolution of
<A HREF="
     cwg_defects.html#244">issue 244</A> and of destructor lookup in general.</P>

<P>
<A HREF="
     cwg_defects.html#244">Issue 244</A> says:</P>
<BLOCKQUOTE>
	... in a <I>qualified-id</I> of the form:
<UL>
::<SUB>opt</SUB> <I>nested-name-specifier</I><SUB>opt</SUB>
   <I>class-name</I> :: ~ <I>class-name</I>
</UL>
	the second class-name is looked up in the same scope as the first.
</BLOCKQUOTE>
<P>But if the reference is "<TT>p-&gt;X::~X()</TT>", the first
<I>class-name</I> is looked up
in two places (normal lookup and a lookup in the class of p).  Does
the new wording mean:
<OL>
<LI>
You look up the second class-name in the scope that you found the first
one.
</LI>
<LI>You look up the second class-name using the same kind of lookup that
   found the first one (normal vs. class).
</LI>
<LI>If you did a dual lookup for the first you do a dual lookup for the
   second.
</LI>
</OL>
</P>

<P>This is a test case that illustrates the issue:</P>
<PRE>
  struct A {
    typedef A C;
  };

  typedef A B;

  void f(B* bp) {
    bp-&gt;B::~B();  // okay B found by normal lookup
    bp-&gt;C::~C();  // okay C found by class lookup
    bp-&gt;B::~C();  // B found by normal lookup C by class -- okay?
    bp-&gt;C::~B();  // C found by class lookup B by normal -- okay?
  }
</PRE>

<P>A second issue concerns destructor references when the class involved is
a template class.</P>
<PRE>
  namespace N {
    template &lt;typename T&gt; struct S {
      ~S();
    };
  }

  void f(N::S&lt;int&gt;* s) {
    s-&gt;N::S&lt;int&gt;::~S();
  }
</PRE>
<P>The issue here is that the grammar uses "~<I>class-name</I>" for destructor
names, but in this case S is a template name when looked up in N.</P>

<P>Finally, what about cases like:</P>
<PRE>
  template &lt;typename T&gt; void f () {
    typename T::B x;
    x.template A&lt;T&gt;::template B&lt;T&gt;::~B();
  }
</PRE>
<P>When parsing the template definition, what checks can be done on "~B"?</P>

<P>
<U>Sandor Mathe</U> adds
:</P>

<P>The standard correction for <A HREF="
     cwg_defects.html#244">issue 244</A>
(now in DR status) is still incomplete.</P>

<P>Paragraph 5 of 3.4.3&nbsp;



 <A HREF="basic.html#basic.lookup.qual">basic.lookup.qual</A> is
not applicable for p-&gt;T::~T since there is no nested-name-specifier.
Section 3.4.5&nbsp;



 <A HREF="basic.html#basic.lookup.classref">basic.lookup.classref</A>
describes the lookup of p-&gt;~T but p-&gt;T::~T is still not
described.  There are examples (which are non-normative) that illustrate
this sort of lookup but they still leave questions unanswered.  The
examples imply that the name after ~ should be looked up in the same
scope as the name before the :: but it is not stated.  The problem is
that the name to the left of the :: can be found in two
different scopes.  Consider the following:</P>
<PRE>
  struct S {
    struct C { ~C() { } };
  };

  typedef S::C D;

  int main() {
    D* p;
    p-&gt;C::~D();  // valid?
  }
</PRE>

<P>Should the destructor call be valid?  If there were a nested name
specifier, then D should be looked for in the same scope as C.  But
here, C is looked for in 2 different ways.  First, it is searched for in
the type of the left hand side of -&gt; and it is also looked for in the
lexical context.  It is found in one or if both, they must match.  So, C
is found in the scope of what p points at.  Do you only look for D there?
If so, this is invalid.  If not, you would then look for D in the context
of the expression and find it.  They refer to the same underlying
destructor so this is valid.  The intended resolution of the original
defect report of the standard was that the name before the :: did not
imply a scope and you did not look for D inside of C.  However, it was
not made clear whether this was to be resolved by using the same lookup
mechanism or by introducing a new form of lookup which is to look in the
left hand side if that is where C was found, or in the context of the
expression if that is where C was found.  Of course, this begs the
question of what should happen when it is found in both?  Consider
the modification to the above case when C is also found in the context
of the expression.  If you only look where you found C, is this now
valid because it is in 1 of the two scopes or is it invalid because C
was in both and D is only in 1?</P>

<PRE>
  struct S {
    struct C { ~C() { } };
  };

  typedef S::C D;
  typedef S::C C;

  int main() {
    D* p;
    p-&gt;C::~D();  // valid?
  }
</PRE>

<P>I agree that the intention of the committee is that the original test
case in this defect is broken.  The standard committee clearly thinks
that the last name before the last :: does not induce a new scope which
is our current interpretation.  However, how this is supposed to work
is not defined.  This needs clarification of the standard.</P>

<P>
<U>Martin Sebor</U> adds this example (September 2003), along
with errors produced by the EDG front end:</P>
<PRE>
namespace N {
    struct A { typedef A NA; };
    template &lt;class T&gt; struct B { typedef B NB; typedef T BT; };
    template &lt;template &lt;class&gt; class T&gt; struct C { typedef C NC; typedef T&lt;A&gt; CA; };
}

void foo (N::A *p)
{
    p-&gt;~NA ();
    p-&gt;NA::~NA ();
}

template &lt;class T&gt;
void foo (N::B&lt;T&gt; *p)
{
    p-&gt;~NB ();
    p-&gt;NB::~NB ();
}

template &lt;class T&gt;
void foo (typename N::B&lt;T&gt;::BT *p)
{
    p-&gt;~BT ();
    p-&gt;BT::~BT ();
}

template &lt;template &lt;class&gt; class T&gt;
void foo (N::C&lt;T&gt; *p)
{
    p-&gt;~NC ();
    p-&gt;NC::~NC ();
}

template &lt;template &lt;class&gt; class T&gt;
void foo (typename N::C&lt;T&gt;::CA *p)
{
    p-&gt;~CA ();
    p-&gt;CA::~CA ();
}

Edison Design Group C/C++ Front End, version 3.3 (Sep  3 2003 11:54:55)
Copyright 1988-2003 Edison Design Group, Inc.

"t.cpp", line 16: error: invalid destructor name for type "N::B&lt;T&gt;"
      p-&gt;~NB ();
          ^

"t.cpp", line 17: error: qualifier of destructor name "N::B&lt;T&gt;::NB" does not
          match type "N::B&lt;T&gt;"
      p-&gt;NB::~NB ();
              ^

"t.cpp", line 30: error: invalid destructor name for type "N::C&lt;T&gt;"
      p-&gt;~NC ();
          ^

"t.cpp", line 31: error: qualifier of destructor name "N::C&lt;T&gt;::NC" does not
          match type "N::C&lt;T&gt;"
      p-&gt;NC::~NC ();
              ^

4 errors detected in the compilation of "t.cpp".
</PRE>

<P>
<U>John Spicer:</U>
The issue here is that we're unhappy with the destructor names when doing 
semantic analysis of the template definitions (not during an
instantiation).</P>

<P>My personal feeling is that this is reasonable.  After all, why 
would you call p-&gt;~NB for a class that you just named
as N::B&lt;T&gt; and you could just say p-&gt;~B?</P>

<P>
<B>Additional note (September, 2004)</B>
</P>

<P>The resolution for <A HREF="
     cwg_defects.html#244">issue 244</A> removed
the discussion of <TT>p-&gt;N::~S</TT>, where <TT>N</TT> is a
<I>namespace-name</I>.  However, the resolution did not make this
construct ill-formed; it simply left the semantics undefined.
The meaning should either be defined or the construct made
ill-formed.</P>

<P>See also issues <A HREF="
     cwg_active.html#305">305</A> and
<A HREF="
     cwg_active.html#466">466</A>.</P>

<BR>
<BR>
<HR>
<A NAME="495"></A>
<H4>495.
  
Overload resolution with template and non-template conversion functions
</H4>
<B>Section: </B>13.3.3&nbsp;



 <A HREF="over.html#over.match.best">over.match.best</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>drafting
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Nathan Sidwell
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>20 Dec 2004<BR>


<P>
The overload resolution rules for ranking a template against a
non-template function differ for conversion functions in a
surprising way.  13.3.3&nbsp;



 <A HREF="over.html#over.match.best">over.match.best</A> lists four checks,
the last three concern this report.  For the non-conversion
operator case, checks 2 and 3 are applicable, whereas for the
conversion operator case checks 3 and 4 are applicable. Checks 2
and 4 concern the ranking of argument and return value conversion
sequences respectively.  Check 3 concerns only the templatedness
of the functions being ranked, and will prefer a non-template to
a template.  Notice that this check happens after argument
conversion sequence ranking, but <I>before</I> return value
conversion sequence ranking.  This has the effect of always
selecting a non-template conversion operator, as the following
example shows:
</P>

<PRE>
    struct C
    {
      inline operator int () { return 1; }
      template &lt;class T&gt; inline operator T () { return 0; }
    };

    inline long f (long x) { return x; }

    int
    main (int argc, char *argv[])
    {
      return f (C ());
    }
</PRE>

<P>
The non-templated <TT>C::operator int</TT> function will be
selected, rather than the apparently better
<TT>C::operator long&lt;long&gt;</TT> instantiation.  This is a
surprise, and resulted in a bug report where the user expected
the template to be selected.  In addition some C++ compilers have
implemented the overload ranking as if checks 3 and 4 were
transposed.
</P>

<P>
Is this ordering accidental, or is there a rationale?
</P>

<P>
<B>Notes from the April, 2005 meeting:</B>
</P>

<P>The CWG agreed that the template/non-template distinction should
be the final tie-breaker.</P>

<BR>
<BR>
<HR>
<A NAME="260"></A>
<H4>260.
  
User-defined conversions and built-in <TT>operator=</TT>
</H4>
<B>Section: </B>13.6&nbsp;



 <A HREF="over.html#over.built">over.built</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>drafting
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Scott Douglas
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>4 Nov 2000<BR>


<P>According to the Standard (although not implemented this way
in most implementations), the following code exhibits non-intuitive
behavior:</P>

<PRE>
  struct T {
    operator short() const;
    operator int() const;
  };

  short s;

  void f(const T&amp; t) {
    s = t;  // surprisingly calls T::operator int() const
  }
</PRE>

<P>The reason for this choice is 13.6&nbsp;



 <A HREF="over.html#over.built">over.built</A>
paragraph 18:</P>

<BLOCKQUOTE>

<P>For every triple (<I>L</I>, <I>VQ</I>, <I>R</I>), where <I>L</I> is an
arithmetic type, <I>VQ</I> is either <TT>volatile</TT> or empty, and
<I>R</I> is a promoted arithmetic type, there exist candidate operator
functions of the form</P> 

<UL>
<I>VQ</I> <I>L</I><TT>&amp; operator=(</TT><I>VQ L</I><TT>&amp;,</TT> <I>R</I><TT>);</TT>
</UL>

</BLOCKQUOTE>

<P>Because <I>R</I> is a "promoted arithmetic type," the second argument
to the built-in assignment operator is <TT>int</TT>, causing the
unexpected choice of conversion function.</P>

<P>
<B>Suggested resolution:</B> Provide built-in assignment operators
for the unpromoted arithmetic types.</P>

<P>Related to the preceding, but not resolved by the suggested
resolution, is the following problem.  Given:</P>

<PRE>
    struct T {
	 operator int() const;
	 operator double() const;
    };
</PRE>

<P>I believe the standard requires the following assignment to be
ambiguous (even though I expect that would surprise the user):</P>

<PRE>
    double x;
    void f(const T&amp; t) { x = t; }
</PRE>

<P>The problem is that both of these built-in <TT>operator=()</TT>s exist
(13.6&nbsp;



 <A HREF="over.html#over.built">over.built</A> paragraph 18):</P>

<PRE>
    double&amp; operator=(double&amp;, int);
    double&amp; operator=(double&amp;, double);
</PRE>

<P>Both are an exact match on the first argument and a user conversion
on the second.  There is no rule that says one is a better match than
the other.</P>

<P>The compilers that I have tried (even in their strictest setting)
do not give a peep.  I think they are not following the standard.
They pick <TT>double&amp; operator=(double&amp;, double)</TT> and use
<TT>T::operator double() const</TT>.</P>

<P>I hesitate to suggest changes to overload resolution, but a
possible resolution might be to introduce a rule that, for built-in
<TT>operator=</TT> only, also considers the conversion sequence from
the second to the first type.  This would also resolve the earlier
question.</P>

<P>It would still leave <TT>x += t</TT> etc. ambiguous -- which might
be the desired behavior and is the current behavior of some
compilers.</P>

<P>
<B>Notes from the 04/01 meeting:</B>
</P>

<P>The difference between initialization and assignment is
disturbing.  On the other hand, promotion is ubiquitous in the
language, and this is the beginning of a very slippery slope (as
the second report above demonstrates).
</P>

<BR>
<BR>
<HR>
<A NAME="205"></A>
<H4>205.
  
Templates and static data members
</H4>
<B>Section: </B>14&nbsp;



 <A HREF="template.html#temp">temp</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>drafting
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Mike Miller
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>11 Feb 2000<BR>



<P>Static data members of template classes and of nested classes of
template classes are not themselves templates but receive much the
same treatment as template.  For instance,
14&nbsp;



 <A HREF="template.html#temp">temp</A>
 paragraph 1 says that templates
are only "classes or functions" but implies that "a static data member
of a class template or of a class nested within a class template" is
defined using the <I>template-declaration</I> syntax.</P>

<P>There are many places in the clause, however, where static data
members of one sort or another are overlooked.  For instance,
14&nbsp;



 <A HREF="template.html#temp">temp</A>
 paragraph 6 allows static data
members of class templates to be declared with the <TT>export</TT>
keyword.  I would expect that static data members of (non-template)
classes nested within class templates could also be exported, but they
are not mentioned here.</P>

<P>Paragraph 8, however, overlooks static data members altogether and
deals only with "templates" in defining the effect of the
<TT>export</TT> keyword; there is no description of the semantics of
defining a static data member of a template to be exported.</P>

<P>These are just two instances of a systematic problem.  The entire
clause needs to be examined to determine which statements about
"templates" apply to static data members, and which statements about
"static data members of class templates" also apply to static data
members of non-template classes nested within class templates.</P>

<P>(The question also applies to member functions of template classes;
see <A HREF="
     cwg_defects.html#217">issue 217</A>, where the phrase
"non-template function" in 8.3.6&nbsp;



 <A HREF="decl.html#dcl.fct.default">dcl.fct.default</A> paragraph 4
is apparently intended <I>not</I> to include non-template member
functions of template classes.  See also <A HREF="
     cwg_defects.html#108">issue 108</A>, which would benefit from understanding nested classes of
class templates as templates.  Also, see <A HREF="
     cwg_defects.html#249">issue 249</A>, in which the usage of the phrase "member function
template" is questioned.)</P>

<P>
<B>Notes from the 4/02 meeting:</B>
</P>

<P>Daveed Vandevoorde will propose appropriate terminology.</P>

<BR>
<BR>
<HR>
<A NAME="215"></A>
<H4>215.
  
Template parameters are not allowed in <I>nested-name-specifier</I>s
</H4>
<B>Section: </B>14.1&nbsp;



 <A HREF="template.html#temp.param">temp.param</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>drafting
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Martin von Loewis
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>13 Mar 2000<BR>


<P>According to 14.1&nbsp;



 <A HREF="template.html#temp.param">temp.param</A> paragraph 3, the following
fragment is ill-formed:</P>

<PRE>
    template &lt;class T&gt;
    class X{
      friend void T::foo();
    };
</PRE>

<P>In the friend declaration, the <TT>T::</TT> part is a
<I>nested-name-specifier</I> (8&nbsp;



 <A HREF="decl.html#dcl.decl">dcl.decl</A> paragraph 4),
and <TT>T</TT> must be a <I>class-name</I> or a <I>namespace-name</I>
(5.1&nbsp;



 <A HREF="expr.html#expr.prim">expr.prim</A> paragraph 7). However, according to
14.1&nbsp;



 <A HREF="template.html#temp.param">temp.param</A> paragraph 3, it is only a
<I>type-name</I>. The fragment should be well-formed, and
instantiations of the template allowed as long as the actual template
argument is a class which provides a function member <TT>foo</TT>. As
a result of this defect, any usage of template parameters in nested
names is ill-formed, e.g., in the example of 14.6&nbsp;



 <A HREF="template.html#temp.res">temp.res</A> paragraph 2.</P>

<P>
<B>Notes from 04/00 meeting:</B>
</P>

<P>The discussion at the meeting revealed a self-contradiction in the
current IS in the description of <I>nested-name-specifier</I>s.
According to the grammar in 5.1&nbsp;



 <A HREF="expr.html#expr.prim">expr.prim</A> paragraph 7,
the components of a <I>nested-name-specifier</I> must be either
<I>class-name</I>s or <I>namespace-name</I>s, i.e., the constraint is
syntactic rather than semantic.  On the other hand, 3.4.3&nbsp;



 <A HREF="basic.html#basic.lookup.qual">basic.lookup.qual</A> paragraph 1 describes a semantic constraint: only
object, function, and enumerator names are ignored in the lookup for
the component, and the program is ill-formed if the lookup finds
anything other than a <I>class-name</I> or <I>namespace-name</I>.  It
was generally agreed that the syntactic constraint should be
eliminated, i.e., that the grammar ought to be changed not to use
<I>class-or-namespace-name</I>.</P>

<P>A related point is the explicit prohibition of use of template
parameters in <I>elaborated-type-specifier</I>s in 7.1.5.3&nbsp;



 <A HREF="dcl.html#dcl.type.elab">dcl.type.elab</A> paragraph 2.  This rule was the result of an
explicit Committee decision and should not be unintentionally voided
by the resolution of this issue.</P>

<P>
<B>Proposed resolution (04/01):</B>
</P>

<P>Change 5.1&nbsp;



 <A HREF="expr.html#expr.prim">expr.prim</A> paragraph 7 and
A.4&nbsp;



 <A HREF="gram.html#gram.expr">gram.expr</A> from</P>

<UL>
<I>nested-name-specifier</I>:
<UL>
<I>class-or-namespace-name</I> <TT>::</TT> <I>nested-name-specifier<SUB>opt</SUB></I>
</UL>
<UL>
<I>class-or-namespace-name</I> <TT>:: template</TT> <I>nested-name-specifier</I>
</UL>
</UL>
<UL>
<I>class-or-namespace-name</I>:
<UL>
<I>class-name</I>
</UL>
<UL>
<I>namespace-name</I>
</UL>
</UL>

<P>to</P>

<UL>
<I>nested-name-specifier</I>:
<UL>
<I>type-or-namespace-name</I> <TT>::</TT> <I>nested-name-specifier<SUB>opt</SUB></I>
</UL>
<UL>
<I>type-or-namespace-name</I> <TT>:: template</TT> <I>nested-name-specifier</I>
</UL>
</UL>
<UL>
<I>type-or-namespace-name</I>:
<UL>
<I>type-name</I>
</UL>
<UL>
<I>namespace-name</I>
</UL>
</UL>

<P>This resolution depends on the resolutions for issues
<A HREF="
     cwg_defects.html#245">245</A> (to change the name lookup rules in
<I>elaborated-type-specifier</I>s to include all <I>type-name</I>s)
and <A HREF="
     cwg_defects.html#283">283</A> (to categorize template
<I>type-parameter</I>s as <I>type-name</I>s).</P>

<P>
<B>Notes from 10/01 meeting:</B>
</P>

<P>There was some sentiment for going with simply <I>identifier</I>
in front of the "<TT>::</TT>", and stronger sentiment for going
with something with a more descriptive name if possible.
See also <A HREF="
     cwg_defects.html#180">issue 180</A>.</P>

<P>
<B>Notes from April 2003 meeting:</B>
</P>

<P>This was partly resolved by the changes for <A HREF="
     cwg_defects.html#125">issue 125</A>.  However, we also need to add a semantic check in
3.4.3&nbsp;



 <A HREF="basic.html#basic.lookup.qual">basic.lookup.qual</A> to allow <TT>T::foo</TT> and we need to
reword the first sentence of 3.4.3&nbsp;



 <A HREF="basic.html#basic.lookup.qual">basic.lookup.qual</A>.</P>

<P>
<B>Proposed resolution (October, 2004):</B>
</P>

<P>Change 3.4.3&nbsp;



 <A HREF="basic.html#basic.lookup.qual">basic.lookup.qual</A> paragraph 1 as
follows:</P>

<BLOCKQUOTE>

The name of a class or namespace member can be referred to after
the <TT>::</TT> scope resolution operator (5.1&nbsp;



 <A HREF="expr.html#expr.prim">expr.prim</A>) applied to a <I>nested-name-specifier</I> that
nominates its class or namespace. During the lookup for a name
preceding the <TT>::</TT> scope resolution operator, object,
function, and enumerator names are ignored. If the name found
<S>is not a <I>class-name</I> (clause 9&nbsp;



 <A HREF="class.html#class">class</A>) or
<I>namespace-name</I> (7.3.1&nbsp;



 <A HREF="dcl.html#namespace.def">namespace.def</A>)</S> <B>does
not designate a class or namespace</B>, the program is
ill-formed. [...]

</BLOCKQUOTE>

<P>
<B>Notes from the April, 2005 meeting:</B>
</P>

<P>The 10/2004 resolution does not take into account the fact that
template type parameters do not designate class types in the context
of the template definition.  Further drafting is required.
</P>

<BR>
<BR>
<HR>
<A NAME="96"></A>
<H4>96.
  
Syntactic disambiguation using the <TT>template</TT> keyword
</H4>
<B>Section: </B>14.2&nbsp;



 <A HREF="template.html#temp.names">temp.names</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>drafting
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>John Spicer
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>16 Feb 1999<BR>



<P>The following is the wording from
14.2&nbsp;



 <A HREF="template.html#temp.names">temp.names</A>

paragraphs 4 and 5 that discusses the use of the "template" keyword following
<TT>.</TT> or <TT>-&gt;</TT> and in qualified names.</P>
<UL>When the name of a member template specialization appears after <TT>.</TT>
or <TT>-&gt;</TT> in a <I>postfix-expression</I>, or after <I>nested-name-specifier</I>
in a <I>qualified-id</I>, and the <I>postfix-expression</I> or <I>qualified-id</I>
explicitly depends on a <I>template-parameter</I>
(14.6.2&nbsp;



 <A HREF="template.html#temp.dep">temp.dep</A>
),
the member template name must be prefixed by the keyword <TT>template</TT>.
Otherwise the name is assumed to name a non-template. [<I>Example:</I>
<PRE>
    class X {
    public:
        template&lt;std::size_t&gt; X* alloc();
        template&lt;std::size_t&gt; static X* adjust();
    };
    
    template&lt;class T&gt; void f(T* p) {
        T* p1 = p-&gt;alloc&lt;200&gt;();
                // ill-formed: &lt; means less than
    
        T* p2 = p-&gt;template alloc&lt;200&gt;();
                // OK: &lt; starts template argument list
     
        T::adjust&lt;100&gt;();
                // ill-formed: &lt; means less than
     
        T::template adjust&lt;100&gt;();
                // OK: &lt; starts explicit qualification
    }
</PRE>
&mdash;<I>end example</I>]

<P>If a name prefixed by the keyword <TT>template</TT> is not the name
of a member template, the program is ill-formed.
[<I>Note:</I> the keyword <TT>template</TT>
may not be applied to non-template members of class templates. ]</P>
</UL>
The whole point of this feature is to say that the "<TT>template</TT>"
keyword is needed to indicate that a "<TT>&lt;</TT>" begins a template
parameter list in certain contexts. The constraints in paragraph 5 leave
open to debate certain cases.

<P>First, I think it should be made more clear that the template name must
be followed by a template argument list when the "<TT>template</TT>" keyword
is used in these contexts. If we don't make this clear, we would have to
add several semantic clarifications instead. For example, if you say "<TT>p-&gt;template
f()</TT>", and "<TT>f</TT>" is an overload set containing both templates
and nontemplates: a) is this valid? b) are the nontemplates in the overload
set ignored? If the user is forced to write "<TT>p-&gt;template f&lt;&gt;()</TT>"
it is clear that this is valid, and it is equally clear that nontemplates
in the overload set are ignored. As this feature was added purely to provide
syntactic guidance, I think it is important that it otherwise have no semantic
implications.</P>

<P>I propose that paragraph 5 be modified to:</P>
<UL>If a name prefixed by the keyword <TT>template</TT> is not the name
of a member template, or an overload set containing one or more member
templates, the program is ill-formed. If the name prefixed by the <TT>template</TT>
keyword is not followed by a <I>template-argument-list</I>, the program
is ill-formed.</UL>

<P>(See also <A HREF="
     cwg_defects.html#30">issue 30</A> and document
J16/00-0008 = WG21 N1231.)</P>

<P>
<B>Notes from 04/00 meeting:</B>
</P>

<P>The discussion of this issue revived interest in issues
<A HREF="
     cwg_defects.html#11">11</A> and <A HREF="
     cwg_closed.html#109">109</A>.

</P>

<P>
<B>Notes from the October 2003 meeting:</B>
</P>

<P>We reviewed John Spicer's paper N1528 and agreed with his
recommendations therein.</P>

<BR>
<BR>
<HR>
<A NAME="314"></A>
<H4>314.
  
<TT>template</TT> in base class specifier
</H4>
<B>Section: </B>14.2&nbsp;



 <A HREF="template.html#temp.names">temp.names</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>drafting
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Mark Mitchell
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>23 Aug 2001<BR>


<P>The EDG front-end accepts:</P>
<PRE>
template &lt;typename T&gt;
struct A {
  template &lt;typename U&gt;
  struct B {};
};

template &lt;typename T&gt;
struct C : public A&lt;T&gt;::template B&lt;T&gt; {
};
</PRE>
<P>It rejects this code if the base-specifier is spelled
<TT>A&lt;T&gt;::B&lt;T&gt;</TT>.</P>

<P>However, the grammar for a base-specifier does not allow the
<TT>template</TT> keyword.</P>

<P>
<B>Suggested resolution:</B>
</P>

It seems to me that a consistent approach to the solution that looks like
it will be adopted for <A HREF="
     cwg_defects.html#180">issue 180</A> (which deals
with the <TT>typename</TT> keyword in similar contexts) would be to
assume that <TT>B</TT> is a template if it is followed by a
"&lt;".  After all, an expression cannot appear in this context.

<P>
<B>Notes from the 4/02 meeting:</B>
</P>

<P>We agreed that <TT>template</TT> must be allowed in this context.
The syntax needs to be changed.  We also opened the related
<A HREF="
     cwg_active.html#343">issue 343</A>.</P>
<BR>
<BR>
<HR>
<A NAME="431"></A>
<H4>431.
  
Defect in wording in 14.2
</H4>
<B>Section: </B>14.2&nbsp;



 <A HREF="template.html#temp.names">temp.names</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>drafting
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Mat Marcus
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>10 August 2003<BR>




<P>Consider this example:</P>
<PRE>
   class Foo {
   public:
       template&lt; typename T &gt; T *get();
   };

   template&lt; typename U &gt;
   U *testFoo( Foo &amp;foo ) {
       return foo.get&lt; U &gt;(); //#1
   }
</PRE>
<P>I am under the impression that this should compile without requiring
the insertion of the template keyword before get in the expression at
//#1. This notion is supported by this note excerpted from
14.2&nbsp;



 <A HREF="template.html#temp.names">temp.names</A>/5:</P>
<BLOCKQUOTE>
   [Note: just as is the case with the typename prefix, the template
   prefix is allowed in cases where it is not strictly necessary;
   i.e.,  when the expression on the left of the -&gt; or ., or the
   nested-name-specifier is not dependent on a template parameter.]
</BLOCKQUOTE>

<P>But 14.2&nbsp;



 <A HREF="template.html#temp.names">temp.names</A>/4 contains this text:</P>
<BLOCKQUOTE>
   When the name of a member template specialization appears after .
   or -&gt; in a postfix-expression, or after nested-name-specifier in
   a qualified-id, and the postfix-expression or qualified-id
   explicitly depends on a template-parameter (14.6.2), the member
   template name must be prefixed by the keyword template. Otherwise
   the name is assumed to name a non-template.
</BLOCKQUOTE>

<P>The only way that I can read this to support my assumption above is if
I assume that the phrase postfix-expression is used twice above with
different meaning. That is I read the first use as referring to the
full expression while the second use refers to the subexpression
preceding the operator. Is this the correct determination of intent? I
find this text confusing. Would it be an improvement if the second
occurrence of "postfix-expression" should be replaced by "the
subexpression preceding the operator". Of course that begs the
question "where is subexpression actually defined in the standard?"</P>

<P>
<U>John Spicer:</U>
I agree that the code should work, and that we should tweak 
the wording.</P>

<BR>
<BR>
<HR>
<A NAME="408"></A>
<H4>408.
  
sizeof applied to unknown-bound array static data member of template
</H4>
<B>Section: </B>14.5.1.3&nbsp;



 <A HREF="template.html#temp.static">temp.static</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>drafting
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Nathan Myers
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>14 Apr 2003<BR>




<P>Is this allowed?</P>
<PRE>
  template&lt;typename T&gt; 
    struct X
    {
        static int s[];
        int c;
    };

  template&lt;typename T&gt;
    int X&lt;T&gt;::s[sizeof(X&lt;T&gt;)];

  int* p = X&lt;char&gt;::s;
</PRE>

<P>I have a compiler claiming that, for the purpose of sizeof(), X&lt;T&gt; is 
an incomplete type, when it tries to instantiate X&lt;T&gt;::s.  It seems to 
me that X&lt;char&gt; should be considered complete enough for sizeof even
though the size of s isn't known yet.</P>


<P>
<U>John Spicer:</U>
This is a problematic construct that is currently allowed but which I think 
should be disallowed.</P>

<P>I tried this with a number of compilers.
None of which did the right thing. 
The EDG front end accepts it, but gives X&lt;...&gt;::s the wrong size.</P>

<P>It appears that most compilers evaluate the
"declaration" part of the static 
data member definition only once when the definition is processed.  The 
initializer (if any) is evaluated for each instantiation.</P>

<P>This problem is solvable, and if it were
the only issue with incomplete arrays 
as template static data members, then it would make
sense to solve it, but there are other problems.</P>

<P>The first problem is that the size of the static data member is
only known if a template definition of the static data member is
present.  This is weird to start with, but it also means that sizes
would not be available in general for exported templates.</P>

<P>The second problem concerns the rules for specialization.  An explicit 
specialization for a template instance can be provided up until the
point that a use is made that would cause an implicit instantiation.
A reference like "sizeof(X&lt;char&gt;::s)" is not currently a reference
that would cause an implicit instantiation of X&lt;char&gt;::s.
This means you could use such a sizeof and later 
specialize the static data member with a different size, meaning the earlier 
sizeof gave the wrong result.  We could, of course, change the "use"
rules, but I'd rather see us require that static data members that
are arrays have a size specified in the class or have a size based
on their initializer.</P>

<P>
<B>Notes from the October 2003 meeting:</B>
</P>

<P>The example provided is valid according to the current
standard.  A static data member must be
instantiated (including the processing of its initializer, if any)
if there is any reference to it.  The compiler need not, however, put out
a definition in that translation unit.  The standard doesn't really
have a concept of a "partial instantiation" for a static data
member, and although we considered adding that, we decided that
to get all the size information that seems to be available one
needs a full instantiation in any case, so there's no need
for the concept of a partial instantiation.</P>

<BR>
<BR>
<HR>
<A NAME="448"></A>
<H4>448.
  
Set of template functions in call with dependent explicit argument
</H4>
<B>Section: </B>14.6.1&nbsp;



 <A HREF="template.html#temp.local">temp.local</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>drafting
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Mark Mitchell
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>4 Jan 2004<BR>


<P>Is this program valid?</P>
<PRE>
  template &lt;typename T&gt; int g(int);
  class h{};
  template &lt;typename T&gt; int l(){h j; return g&lt;T&gt;(j);}
  template &lt;typename T&gt; int g(const h&amp;);
  class j{};
  int jj(){return l&lt;j&gt;();}
</PRE>
<P>The key issue is when "g" is looked up, i.e., whether both overloaded
template "g" functions are available at the call site or only the
first.  Clearly, the entire postfix-expression "g&lt;T&gt;(j)" is dependent,
but when is the set of available template functions determined?</P>

<P>For consistency with the rules about when the set of available
overloads is determined when calling a function given by an
unqualified-id, I would think that we should postpone determining the
set of template functions if (and only if) any of the explicit
template arguments are dependent.</P>

<P>
<U>John Spicer:</U>
I agree that there should be a core issue for this.  The definition of 
"dependent name" (14.6.2&nbsp;



 <A HREF="template.html#temp.dep">temp.dep</A> paragraph 1)
should probably be modified to cover this case.  It 
currently only handles cases where the function name is a simple
identifier.</P>

<P>
<B>Notes from the March 2004 meeting:</B>
</P>

<P>A related issue is a call with a qualified name and dependent
arguments, e.g., <TT>x::y(depa, depb)</TT>.</P>

<BR>
<BR>
<HR>
<A NAME="458"></A>
<H4>458.
  
Hiding of member template parameters by other members
</H4>
<B>Section: </B>14.6.1&nbsp;



 <A HREF="template.html#temp.local">temp.local</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>drafting
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Gabriel Dos Reis
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>2 Feb 2004<BR>




<P>The list of cases in 14.6.1&nbsp;



 <A HREF="template.html#temp.local">temp.local</A>
about when a template parameter is hidden
seems to be incomplete.</P>

<P>Consider</P>
<PRE>
      // example-1
    struct S {
       int C;
       template&lt;class&gt; void f();
    };

    template&lt;class C&gt;
      void S::f()
      {
         C c;           // #1
      }
</PRE>
<P>Someone asked whether line #1 is well-formed and I responded "no"
based on my understanding of the rules in 14.6.1.
After a second looking, I've realized that the above case is currently
missing from the list.</P>

<P>The list in 14.6.1 covers cases like
<PRE>
     // example-2
   template&lt;class T&gt;
     struct S {
        int C;
        void f();
     };

   template&lt;class C&gt;
     void S&lt;C&gt;::f()
     {
       C c;     // ERROR: 'C' is 'S::C' not the template parameter
     }
</PRE>
or
<PRE>
     // example-3
   struct A { int C; }

   template&lt;class C&gt;
      struct S : A {
        C c;    // ERROR: 'C' is 'A::C', not the template parameter
      };
</PRE>
But the case of a 'member template' is missing.  I believe it should
follow the same rule as above.  The reason is this.</P>

<P>In the case listed in 14.6.1 (having to do with members of classes),
the "algorithm" seems to be this:
<OL>
<LI>
put the "template parameter scope"[1] on the top of active
       scope stack.  That will make the template parameter
       declarations the innermost bindings.
</LI>
<LI>
Enter the class scope. That will push more scopes on the stack.
       In particular, any bindings from non-dependent base classes or
       from the class definition will hide any previous bindings,
       especially the template parameter declarations.
</LI>
</OL>
The above formulation uniformly covers paragraphs 5 and 7 of section
14.6.1 and gives a general view of how name lookup is supposed to 
happen.</P>

<P>I believe that any rule, coherent with 14.6.1/5 and 14.6.1/7, for
covering the  cases of member templates (example-1) will be described
by the above "algorithm".</P>

<P>Am I missing something?</P>

<P>[1] of course, the standard text does not formally speak of "template
    parameter scope", but we all know that the template parameters
    "live" somewhere.  I'm using that terminology to designate the
    declarative region of the template parameters.</P>

<P>
<U>Mike Miller:</U>
I have a somewhat different perspective on this question.  I
think your example-1 is fundamentally different from your
example-2 and example-3.  Looking, for instance, at your
example-2, I see four nested scopes:</P>
<PRE>
     namespace scope
       template scope (where the parameter is)
         class S scope
           S::f() block scope
</PRE>
<P>Naturally, S::C hides the template parameter C.  The same is
true of your example-3, with three scopes:</P>
<PRE>
     namespace scope
       template scope
         class S scope (includes 10.2 base class lookup)
</PRE>
<P>Again, it's clear that the C inherited from A hides the template
parameter in the containing scope.</P>

<P>The scopes I see in your example-1, however, are different:</P>
<PRE>
     namespace scope
       struct S scope
         template scope (where the parameter is)
           S::f() block scope
</PRE>
<P>Here it seems clear to me that the template parameter hides the
class member.</P>

<P>It might help to look at the case where the function template is
defined inline in the class:</P>
<PRE>
     struct S {
        int C;
        template&lt;class C&gt; int f() {
            C c;   // #1
        }
     };
</PRE>
<P>It would be pretty strange, I think, if the #1 C were the member
and not the template parameter.  It would also be odd if the
name lookup were different between an inline definition and an
out-of-line definition.</P>

<P>See also <A HREF="
     cwg_active.html#459">issue 459</A>.</P>

<P>
<B>Notes from the March 2004 meeting:</B>
</P>

<P>Basically, the standard is okay.  We think Gaby's desired
cases like #1 should be ill-formed.</P>

<P> There is a wording problem in 14.6.1&nbsp;



 <A HREF="template.html#temp.local">temp.local</A> paragraph 7.
It says:</P>
<BLOCKQUOTE>
In the definition of a member of a class template that appears outside of the 
class template definition, the name of a member of this template hides
the name of a template-parameter.
</BLOCKQUOTE>

<P>It should say "hides the name of a template-parameter of the class template 
(but not a template-parameter of the member, if the member is itself a 
template)" or words to that effect.</P>

<BR>
<BR>
<HR>
<A NAME="2"></A>
<H4>2.
  
How can dependent names be used in member declarations that appear outside of the class template definition?
</H4>
<B>Section: </B>14.6.4&nbsp;



 <A HREF="template.html#temp.dep.res">temp.dep.res</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>drafting
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>unknown
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown<BR>





<PRE>
    template &lt;class T&gt; class Foo {
    
       public:
       typedef int Bar;
       Bar f();
    };
    template &lt;class T&gt; typename Foo&lt;T&gt;::Bar Foo&lt;T&gt;::f() { return 1;}
                       --------------------
</PRE>
In the class template definition, the declaration of the member function
is interpreted as:
<PRE>
   int Foo&lt;T&gt;::f();
</PRE>
In the definition of the member function that appears outside of the class
template, the return type is not known until the member function
is instantiated.
Must the return type of the member function be known when this out-of-line
definition is seen (in which case the definition above is ill-formed)?
Or is it OK to wait until the member function is instantiated to see if
the type of the return type matches the return type in the class template
definition (in which case the definition above is well-formed)?
    
<P>
<B>Suggested resolution:</B> (John Spicer)</P>
    
<P>My opinion (which I think matches several posted on the reflector recently)
is that the out-of-class definition must match the
declaration in the template. 
In your example they do match, so it is well formed.</P>
    
<P>I've added some additional cases that illustrate cases that I think
either are allowed or should be allowed, and some cases that I don't think
are allowed.</P>
<PRE>
    template &lt;class T&gt; class A { typedef int X; };
    
    
    template &lt;class T&gt; class Foo {
     public:
       typedef int Bar;
       typedef typename A&lt;T&gt;::X X;
       Bar f();
       Bar g1();
       int g2();
       X h();
       X i();
       int j();
     };
    
     // Declarations that are okay
     template &lt;class T&gt; typename Foo&lt;T&gt;::Bar Foo&lt;T&gt;::f()
                                                     { return 1;}
     template &lt;class T&gt; typename Foo&lt;T&gt;::Bar Foo&lt;T&gt;::g1()
                                                     { return 1;}
     template &lt;class T&gt; int Foo&lt;T&gt;::g2() { return 1;}
     template &lt;class T&gt; typename Foo&lt;T&gt;::X Foo&lt;T&gt;::h() { return 1;}
    
     // Declarations that are not okay
     template &lt;class T&gt; int Foo&lt;T&gt;::i() { return 1;}
     template &lt;class T&gt; typename Foo&lt;T&gt;::X Foo&lt;T&gt;::j() { return 1;}
</PRE>
In general, if you can match the declarations up using only information
from the template, then the declaration is valid.

<P>Declarations like <TT>Foo::i</TT> and <TT>Foo::j </TT>are invalid because
for a given instance of <TT>A&lt;T&gt;</TT>, <TT>A&lt;T&gt;::X</TT> may not actually
be int if the class is specialized.</P>

<P>This is not a problem for <TT>Foo::g1</TT> and <TT>Foo::g2</TT> because
for any instance of <TT>Foo&lt;T&gt;</TT> that is generated from the template
you know that Bar will always be int. If an instance of <TT>Foo</TT> is
specialized, the template member definitions are not used so it doesn't
matter whether a specialization defines <TT>Bar</TT> as int or not.</P>


<BR>
<BR>
<HR>
<A NAME="287"></A>
<H4>287.
  
Order dependencies in template instantiation
</H4>
<B>Section: </B>14.6.4.1&nbsp;



 <A HREF="template.html#temp.point">temp.point</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>drafting
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Martin Sebor
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>17 May 2001<BR>




<P>Implementations differ in their treatment of the following
code:</P>

<PRE>
    template &lt;class T&gt;
    struct A {
	typename T::X x;
    };

    template &lt;class T&gt;
    struct B {
	typedef T* X;
	A&lt;B&gt; a;
    };

    int main ()
    {
	B&lt;int&gt; b;
    }
</PRE>

<P>Some implementations accept it.  At least one rejects it
because the instantiation of <TT>A&lt;B&lt;int&gt; &gt;</TT>
requires that <TT>B&lt;int&gt;</TT> be complete, and it is
not at the point at which <TT>A&lt;B&lt;int&gt; &gt;</TT>
is being instantiated.</P>

<P>
<U>Erwin Unruh</U>:</P>

<P>In my view the programm is ill-formed. My reasoning:</P>

<UL>

<LI>you need a complete type <TT>B&lt;int&gt;</TT> because you declare
a variable in <TT>main</TT>
</LI>

<LI>
<TT>B&lt;int&gt;</TT> contains a member of type
<TT>A&lt;B&lt;int&gt; &gt;</TT>, so you need that complete.</LI>

<LI>
<TT>A&lt;B&lt;int&gt; &gt;</TT> tries to access
<TT>B&lt;int&gt;::X</TT>, which in turn needs <TT>B&lt;int&gt;</TT>
being complete.</LI>

</UL>

<P>So each class needs the other to be complete.</P>

<P>The problem can be seen much easier if you replace the typedef with</P>
<PRE>
    typedef T (*X) [sizeof(B::a)];
</PRE>

<P>Now you have a true recursion. The compiler cannot easily distinguish
between a true recursion and a potential recursion.</P>

<P>
<U>John Spicer</U>:</P>

<P>Using a class to form a qualified name does not require the class to be
complete, it only requires that the named member already have been declared.
In other words, this kind of usage is permitted:</P>

<PRE>
    class A {
        typedef int B;
        A::B ab;
    };
</PRE>

<P>In the same way, once <TT>B</TT> has been declared in <TT>A</TT>,
it is also visible to any template that uses <TT>A</TT> through a
template parameter.</P>

<P>The standard could be more clear in this regard, but there are two
notes that make this point.  Both 3.4.3.1&nbsp;



 <A HREF="basic.html#class.qual">class.qual</A> and
5.1&nbsp;



 <A HREF="expr.html#expr.prim">expr.prim</A> paragraph 7 contain a note that says "a
class member can be referred to using a qualified-id at any point in
its potential scope (3.3.6&nbsp;



 <A HREF="basic.html#basic.scope.class">basic.scope.class</A>)."  A member's
potential scope begins at its point of declaration.</P>

<P>In other words, a class has three states: incomplete, being
completed, and complete.  The standard permits a qualified name to be
used once a name has been declared.  The quotation of the notes about
the potential scope was intended to support that.</P>

<P>So, in the original example, class <TT>A</TT> does not require the
type of <TT>T</TT> to be complete, only that it have already declared
a member <TT>X</TT>.</P>

<P>
<U>Bill Gibbons</U>:</P>

<P>The template and non-template cases are different.  In the non-template
case the order in which the members become declared is clear.  In the
template case the members of the instantiation are conceptually all
created at the same time.  The standard does not say anything about
trying to mimic the non-template case during the instantiation of a class
template.</P>

<P>
<U>Mike Miller</U>:</P>

<P>I think the relevant specification is 14.6.4.1&nbsp;



 <A HREF="template.html#temp.point">temp.point</A> paragraph 3, dealing with the point of
instantiation:</P>

<BLOCKQUOTE>

For a class template specialization... if the specialization is
implicitly instantiated because it is referenced from within
another template specialization, if the context from which the
specialization is referenced depends on a template parameter, and
if the specialization is not instantiated previous to the
instantiation of the enclosing template, the point of
instantiation is immediately before the point of instantiation
of the enclosing template.  Otherwise, the point of instantiation
for such a specialization immediately precedes the namespace scope
declaration or definition that refers to the specialization.

</BLOCKQUOTE>

<P>That means that the point of instantiation of <TT>A&lt;B&lt;int&gt;
&gt;</TT> is before that of <TT>B&lt;int&gt;</TT>, not in the middle
of <TT>B&lt;int&gt;</TT> after the declaration of <TT>B::X</TT>, and
consequently a reference to <TT>B&lt;int&gt;::X</TT> from
<TT>A&lt;B&lt;int&gt; &gt;</TT> is ill-formed.</P>

<P>To put it another way, I believe John's approach requires that there
be an instantiation stack, with the results of partially-instantiated
templates on the stack being available to instantiations above them.
I don't think the Standard mandates that approach; as far as I can
see, simply determining the implicit instantiations that need to be
done, rewriting the definitions at their respective points of
instantiation with parameters substituted (with appropriate "forward
declarations" to allow for non-instantiating references), and
compiling the result normally should be an acceptable implementation
technique as well.  That is, the implicit instantiation of the
example (using, e.g., <TT>B_int</TT> to represent the generated name of the
<TT>B&lt;int&gt;</TT> specialization) could be something like</P>

<PRE>
        struct B_int;

        struct A_B_int {
            B_int::X x;    // error, incomplete type
        };

        struct B_int {
            typedef int* X;
            A_B_int a;
        };
</PRE>

<P>
<B>Notes from 10/01 meeting:</B>
</P>

<P>This was discussed at length.  The consensus was that the template case
should be treated the same as the non-template class case it terms of
the order in which members get declared/defined and classes get completed.</P>

<P>
<B>Proposed resolution:</B>
</P>

<P>
In 14.6.4.1&nbsp;



 <A HREF="template.html#temp.point">temp.point</A> paragraph 3 change:</P>
<BLOCKQUOTE>
the point of instantiation is immediately before the point of
instantiation of the enclosing template. Otherwise, the point of
instantiation for such a specialization immediately precedes the
namespace scope declaration or definition that refers to the
specialization.
</BLOCKQUOTE>
<P> To:</P>
<BLOCKQUOTE>
the point of instantiation is <B>the same as</B> the point of
instantiation of the enclosing template. Otherwise, the point of
instantiation for such a specialization immediately precedes the
<B>nearest enclosing declaration</B>.
<B>[Note: The point of instantiation is still at namespace scope but
any declarations preceding the point of instantiation, even if not
at namespace scope, are considered to have been seen.]</B>
</BLOCKQUOTE>

<P> Add following paragraph 3:</P>
<BLOCKQUOTE>
If an implicitly instantiated class template specialization, class
member specialization, or specialization of a class template references
a class, class template specialization, class member specialization, or
specialization of a class template containing a specialization reference
that directly or indirectly caused the instantiation, the requirements
of completeness and ordering of the class reference are applied in the
context of the specialization reference.
</BLOCKQUOTE>

<P>and the following example</P>

<PRE>
  template &lt;class T&gt; struct A {
          typename T::X x;
  };

  struct B {
          typedef int X;
          A&lt;B&gt; a;
  };

  template &lt;class T&gt; struct C {
          typedef T* X;
          A&lt;C&gt; a;
  };

  int main ()
  {
          C&lt;int&gt; c;
  }
</PRE>

<P>
<B>Notes from the October 2002 meeting:</B>
</P>

<P>This needs work.  Moved back to drafting status.</P>

<BR>
<BR>
<HR>
<A NAME="212"></A>
<H4>212.
  
Implicit instantiation is not described clearly enough
</H4>
<B>Section: </B>14.7.1&nbsp;



 <A HREF="template.html#temp.inst">temp.inst</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>drafting
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Christophe de Dinechin
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>7 Mar 2000<BR>




<P>Three points have been raised where the wording in
14.7.1&nbsp;



 <A HREF="template.html#temp.inst">temp.inst</A> may not be sufficiently clear.</P>

<OL>

<LI>

In paragraph 4, the statement is made that

<BLOCKQUOTE>

A class template specialization is implicitly instantiated...  if the
completeness of the class type affects the semantics of the program...

</BLOCKQUOTE>

<P>It is not clear what it means for the "completeness... [to affect]
the semantics."  Consider the following example:</P>

<PRE>
        template&lt;class T&gt; struct A;
        extern A&lt;int&gt; a;

        void *foo() { return &amp;a; }

        template&lt;class T&gt; struct A
        {
        #ifdef OPTION
                void *operator &amp;() { return 0; }
        #endif
        };
</PRE>

<P>The question here is whether it is necessary for template class
<TT>A</TT> to declare an <TT>operator &amp;</TT> for the semantics of the
program to be affected.  If it does not do so, the meaning of
<TT>&amp;a</TT> will be the same whether the class is complete or
not and thus arguably the semantics of the program are not
affected.</P>

<P>Presumably what was intended is whether the presence or absence of
certain member declarations in the template class might be relevant in
determining the meaning of the program.  A clearer statement may be
desirable.</P>

</LI>

<LI>

Paragraph 5 says,

<BLOCKQUOTE>

If the overload resolution process can determine the correct function
to call without instantiating a class template definition, it is
unspecified whether that instantiation actually takes place.

</BLOCKQUOTE>

<P>The intent of this wording, as illustrated in the example in that
paragraph, is to allow a "smart" implementation not to instantiate
class templates if it can determine that such an instantiation will
not affect the result of overload resolution, even though the
algorithm described in clause 13&nbsp;



 <A HREF="over.html#over">over</A> requires that
all the viable functions be enumerated, including functions that might
be found as members of specializations.</P>

<P>Unfortunately, the looseness of the wording allowing this latitude
for implementations makes it unclear what "the overload resolution
process" is &mdash; is it the algorithm in 13&nbsp;



 <A HREF="over.html#over">over</A> or
something else? &mdash; and what "the correct function" is.</P>

</LI>

<LI>

According to paragraph 6,

<BLOCKQUOTE>

If an implicit instantiation of a class template specialization is
required and the template is declared but not defined, the program is
ill-formed.

</BLOCKQUOTE>

<P>Here, it is not clear what conditions "require" an implicit
instantiation.  From the context, it would appear that the intent is
to refer to the conditions in paragraph 4 that cause a specialization
to be instantiated.</P>

<P>This interpretation, however, leads to different treatment of
template and non-template incomplete classes.  For example, by this
interpretation,</P>

<PRE>
    class A;
    template &lt;class T&gt; struct TA;
    extern A a;
    extern TA&lt;int&gt; ta;

    void f(A*);
    void f(TA&lt;int&gt;*);

    int main()
    {
        f(&amp;a);    // well-formed; undefined if A
                  // has operator &amp;() member
        f(&amp;ta);   // ill-formed: cannot instantiate
    }
</PRE>

<P>A different approach would be to understand "required" in paragraph
6 to mean that a complete type is required in the expression.  In this
interpretation, if an incomplete type is acceptable in the context and
the class template definition is not visible, the instantiation is not
attempted and the program is well-formed.</P>

<P>The meaning of "required" in paragraph 6 must be clarified.</P>

</LI>

</OL>

<P>(See also issues <A HREF="
     cwg_defects.html#204">204</A> and
<A HREF="
     cwg_defects.html#63">63</A>.)</P>

<P>
<B>Notes on 10/01 meeting:</B>
</P>

<P>It was felt that item 1 is solved by addition of the word "might"
in the resolution for <A HREF="
     cwg_defects.html#63">issue 63</A>; item 2
is not much of a problem; and item 3 could be solved by changing
"required" to "required to be complete".</P>

<BR>
<BR>
<HR>
<A NAME="493"></A>
<H4>493.
  
Type deduction from a <TT>bool</TT> context
</H4>
<B>Section: </B>14.8.2.3&nbsp;



 <A HREF="template.html#temp.deduct.conv">temp.deduct.conv</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>drafting
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>John Spicer
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>17 Dec 2004<BR>


<P>An expression used in an <TT>if</TT> statement is implicitly
converted to type <TT>bool</TT> (6.4&nbsp;



 <A HREF="stmt.html#stmt.select">stmt.select</A>).
According to the rules of template argument deduction for
conversion functions given in 14.8.2.3&nbsp;



 <A HREF="template.html#temp.deduct.conv">temp.deduct.conv</A>,
the following example is ill-formed:</P>

<PRE>
    struct X {
      template&lt;class T&gt; operator const T&amp;() const;
    };
    int main()
    {
      if( X() ) {}
    }
</PRE>

<P>Following the logic in 14.8.2.3&nbsp;



 <A HREF="template.html#temp.deduct.conv">temp.deduct.conv</A>,
<TT>A</TT> is <TT>bool</TT> and <TT>P</TT> is <TT>const T</TT>
(because cv-qualification is dropped from <TT>P</TT> before the
reference is removed), and deduction fails.</P>

<P>It's not clear whether this is the intended outcome or
not.</P>

<P>
<B>Notes from the April, 2005 meeting:</B>
</P>

<P>The CWG observed that there is nothing special about either
<TT>bool</TT> or the context in the example above; instead, it
will be a problem wherever a copy occurs, because cv-qualification
is always dropped in a copy operation.  This appears to be a case
where the conversion deduction rules are not properly symmetrical
with the rules for arguments.  The example should be accepted.</P>

<BR>
<BR>
<HR>
<A NAME="499"></A>
<H4>499.
  
Throwing an array of unknown size
</H4>
<B>Section: </B>15.1&nbsp;



 <A HREF="except.html#except.throw">except.throw</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>drafting
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Mike Miller
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>19 Jan 2005<BR>


<P>According to 15.1&nbsp;



 <A HREF="except.html#except.throw">except.throw</A> paragraph 3,</P>

<BLOCKQUOTE>

The type of the <I>throw-expression</I> shall not be an incomplete
type, or a pointer to an incomplete type other than (possibly
cv-qualified) <TT>void</TT>.

</BLOCKQUOTE>

<P>This disallows cases like the following, because <TT>str</TT> has
an incomplete type (an array of unknown size):</P>

<PRE>
    extern const char str[];
    void f() {
        throw str;
    }
</PRE>

<P>The array-to-pointer conversion is applied to the operand of
<TT>throw</TT>, so there's no problem creating the exception object,
which is the reason for the restriction on incomplete types.  I
believe this case should be permitted.</P>

<P>
<B>Notes from the April, 2005 meeting:</B>
</P>

<P>The CWG agreed that the example should be permitted.  Note
that the reference to <I>throw-expression</I> in the cited text
is incorrect; a <I>throw-expression</I> includes the <TT>throw</TT>
keyword and is always of type <TT>void</TT>.  This wording problem
is addressed in the proposed resolution for <A HREF="
     cwg_active.html#475">issue 475</A>.</P>

<BR>
<BR>
<BR>
<BR>
<HR>
<A NAME="Open Status"></A>
<H3>Issues with "Open" Status</H3>
<HR>
<A NAME="357"></A>
<H4>357.
  
Definition of signature should include name
</H4>
<B>Section: </B>1.3.10&nbsp;



 <A HREF="intro.html#defns.signature">defns.signature</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Steve Clamage
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>26 May 2002<BR>




<P>Section 1.3.10&nbsp;



 <A HREF="intro.html#defns.signature">defns.signature</A>, definition of "signature"
omits the function name as part of the signature. Since the name participates
in overload resolution, shouldn't it be included in the definition?
I didn't find a definition of signature in the ARM,
but I might have missed it.</P>

<P>
<U>Fergus Henderson:</U>
I think so.  In particular, 17.4.3.1.2&nbsp;



 <A HREF="lib-intro.html#lib.global.names">lib.global.names</A>
reserves certain "function
signatures" for use by the implementation, which would be wrong
unless the signature includes the name.</P>
<BLOCKQUOTE>
<P>-2- Each global function signature declared with external linkage in a
header is reserved to the implementation to designate that function
signature with external linkage.</P>
<P>-5- Each function signature from the Standard C library declared with
external linkage is reserved to the implementation for use as a
function signature with both extern "C" and extern "C++" linkage,
or as a name of namespace scope in the global namespace.
</P>
</BLOCKQUOTE>
<P>Other uses of the term "function signature" in the description of the
standard library also seem to assume that it includes the name.</P>

<BR>
<BR>
<HR>
<A NAME="537"></A>
<H4>537.
  
Definition of &ldquo;signature&rdquo;
</H4>
<B>Section: </B>1.3.10&nbsp;



 <A HREF="intro.html#defns.signature">defns.signature</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Daveed Vandevoorde
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>12 October 2005<BR>




<P>The standard defines &ldquo;signature&rdquo; in two places:
1.3.10&nbsp;



 <A HREF="intro.html#defns.signature">defns.signature</A> and 14.5.5.1&nbsp;



 <A HREF="template.html#temp.over.link">temp.over.link</A>
paragraphs 3-4.  The former seems to be meant as a formal definition
(I think it's the only place covering the nontemplate case), yet it
lacks some bits mentioned in the latter (specifically, the notion of a
&ldquo;signature of a function template,&rdquo; which is part of every
signature of the associated function template specializations).</P>

<P>Also, I think the 1.3.10&nbsp;



 <A HREF="intro.html#defns.signature">defns.signature</A> words &ldquo;the
information about a function that participates in overload
resolution&rdquo; isn't quite right either.  Perhaps, &ldquo;the
information about a function that distinguishes it in a set of
overloaded functions?&rdquo;</P>

<P>
<U>Eric Gufford</U>:</P>

<P>In 1.3.10&nbsp;



 <A HREF="intro.html#defns.signature">defns.signature</A> the definition states that
&ldquo;Function signatures do not include return type, because that
does not participate in overload resolution,&rdquo; while 14.5.5.1&nbsp;



 <A HREF="template.html#temp.over.link">temp.over.link</A> paragraph 4 states &ldquo;The signature of a
function template consists of its function signature, its return type
and its template parameter list.&rdquo; This seems inconsistent and
potentially confusing. It also seems to imply that two identical
function templates with different return types are distinct
signatures, which is in direct violation of 13.3&nbsp;



 <A HREF="over.html#over.match">over.match</A>. 14.5.5.1&nbsp;



 <A HREF="template.html#temp.over.link">temp.over.link</A> paragraph 4 should be
amended to include verbiage relating to overload resolution.</P>

<P>Either return types are included in function signatures, or they're
not, across the board. IMHO, they should be included as they are an
integral part of the function declaration/definition irrespective of
overloads.  Then verbiage should be added about overload resolution to
distinguish between signatures and overload rules. This would help
clarify things, as it is commonly understood that overload
resolution is based on function signature.</P>

<P>In short, the term &ldquo;function signature&rdquo; should be made
consistent, and removed from its (implicit, explicit or otherwise)
linkage to overload resolution as it is commonly understood.</P>

<BR>
<BR>
<HR>
<A NAME="129"></A>
<H4>129.
  
Stability of uninitialized auto variables
</H4>
<B>Section: </B>1.9&nbsp;



 <A HREF="intro.html#intro.execution">intro.execution</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Nathan Myers
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>26 June 1999<BR>





<P>Does the Standard require that an uninitialized auto variable have
a stable (albeit indeterminate) value?  That is, does the Standard
require that the following function return <TT>true</TT>?</P>

<PRE>
    bool f() {
        unsigned char i;  // not initialized
        unsigned char j = i;
        unsigned char k = i;
        return j == k;    // true iff "i" is stable
    }
</PRE>

3.9.1&nbsp;



 <A HREF="basic.html#basic.fundamental">basic.fundamental</A>
 paragraph 1
requires that uninitialized <TT>unsigned char</TT> variables have a
valid value, so the initializations of <TT>j</TT> and <TT>k</TT> are
well-formed and required not to trap.  The question here is whether
the value of <TT>i</TT> is allowed to change between those
initializations.

<P>
<U>Mike Miller</U>:
1.9&nbsp;



 <A HREF="intro.html#intro.execution">intro.execution</A>
 paragraph 10 says,</P>

<BLOCKQUOTE>
An instance of each object with automatic storage
duration (3.7.2&nbsp;



 <A HREF="basic.html#basic.stc.auto">basic.stc.auto</A>
) is
associated with each entry into
its block.  Such an object exists and retains its
last-stored value during the execution of the block
and while the block is suspended...
</BLOCKQUOTE>

I think that the most reasonable way to read this is that the
only thing that is allowed to change the value of an automatic
(non-volatile?) value is a "store" operation in the abstract
machine.  There are no "store" operations to <TT>i</TT> between the
initializations of <TT>j</TT> and <TT>k</TT>, so it must retain its
original (indeterminate but valid) value, and the result of
the program is well-defined.

<P>The quibble, of course, is whether the wording "last-stored
value" should be applied to a "never-stored" value.  I
think so, but others might differ.</P>

<P>
<U>Tom Plum</U>:
7.1.5.1&nbsp;



 <A HREF="dcl.html#dcl.type.cv">dcl.type.cv</A>
 paragraph 8 says,</P>

<BLOCKQUOTE>
[<I>Note:</I> <TT>volatile</TT> is a hint to the implementation
to avoid aggressive
optimization involving
the object because the value of the object might be changed by means
undetectable 
by an implementation. See
1.9&nbsp;



 <A HREF="intro.html#intro.execution">intro.execution</A>
 for detailed
semantics. In general, the semantics
of <TT>volatile</TT>
are intended to be the same in C++ as they are in C. ]
</BLOCKQUOTE>

&gt;From this I would infer that non-volatile means "shall not be
changed
by means undetectable by an implementation"; that the compiler is entitled to
safely cache accesses to non-volatile objects if it can prove that no
"detectable"
means can modify them; and that therefore  i  <I>shall</I>
maintain the same value
during the example above.

<P>
<U>Nathan Myers</U>:
This also has practical code-generation consequences.  If the
uninitialized auto variable lives in a register, and its value is 
<I>really</I> unspecified, then until it is initialized that register 
can be used as a temporary.  Each time it's "looked at" the variable
has the value that last washed up in that register.  After it's 
initialized it's "live" and cannot be used as a temporary any more, 
and your register pressure goes up a notch.  Fixing the uninit'd 
value would make it "live" the first time it is (or might be) looked 
at, instead.</P>

<P>
<U>Mike Ball</U>:
I agree with this.  I also believe that it was certainly never
my intent that an uninitialized variable be stable, and I would
have strongly argued against such a provision.  Nathan has well
stated the case.
And I am quite certain that it would be disastrous for optimizers.
To ensure it, the frontend would have to generate an initializer,
because optimizers track not only the lifetimes of variables, but
the lifetimes of values assigned to those variables.  This would
put C++ at a significant performance disadvantage compared to
other languages.  Not even Java went this route.  Guaranteeing 
defined behavior for a very special case of a generally undefined
operation seems unnecessary.</P>
<BR>
<BR>
<HR>
<A NAME="369"></A>
<H4>369.
  
Are <TT>new</TT>/<TT>delete</TT> identifiers or <I>preprocessing-op-or-punc</I>?
</H4>
<B>Section: </B>2.4&nbsp;



 <A HREF="lex.html#lex.pptoken">lex.pptoken</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Martin v. Loewis
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>30 July 2002<BR>


<P>2.4&nbsp;



 <A HREF="lex.html#lex.pptoken">lex.pptoken</A> paragraph 2 specifies that there are 5
categories of tokens in phases 3 to 6. With 2.12&nbsp;



 <A HREF="lex.html#lex.operators">lex.operators</A>
paragraph 1, it is unclear whether <TT>new</TT> is an <I>identifier</I> or a
<I>preprocessing-op-or-punc</I>; likewise for <TT>delete</TT>. This is
relevant to answer the question whether</P>
<PRE>
#define delete foo
</PRE>
<P>is a well-formed control-line, since that requires an identifier 
after the <TT>define</TT> token.</P>

<BR>
<BR>
<HR>
<A NAME="411"></A>
<H4>411.
  
Use of universal-character-name in character versus string literals
</H4>
<B>Section: </B>2.13.4&nbsp;



 <A HREF="lex.html#lex.string">lex.string</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>James Kanze
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>23 Apr 2003<BR>


<P>2.13.4&nbsp;



 <A HREF="lex.html#lex.string">lex.string</A> paragraph 5 reads</P>
<BLOCKQUOTE>
Escape sequences and
universal-character-names in string literals have the same meaning as in
character literals, except that the single quote ' is representable
either by itself or by the escape sequence \', and the double quote "
shall be preceded by a \. In a narrow string literal, a
universal-character-name may map to more than one char element due to
multibyte encoding.
</BLOCKQUOTE>

<P>The first sentence refers us to 2.13.2&nbsp;



 <A HREF="lex.html#lex.ccon">lex.ccon</A>,
where we read in the
first paragraph that "An ordinary character literal that contains a
single c-char has type char [...]."  Since the grammar shows that a
universal-character-name is a c-char, something like '\u1234' must have
type char (and thus be a single char element); in paragraph 5, we read
that "A universal-character-name is translated to the encoding, in the
execution character set, of the character named.  If there is no such
encoding, the universal-character-name is translated to an
implemenation-defined encoding."</P>

<P>This is in obvious contradiction with the second sentence.  In addition,
I'm not really clear what is supposed to happen in the case where the
execution (narrow-)character set is UTF-8.  Consider the character
\u0153 (the oe in the French word oeuvre).  Should '\u0153' be a char,
with an "error" value, say '?' (in conformance with the requirement that
it be a single char), or an int, with the two char values 0xC5, 0x93, in
an implementation defined order (in conformance with the requirement
that a character representable in the execution character set be
represented).  Supposing the former, should "\u0153" be the equivalent of
"?" (in conformance with the first sentence), or "\xC5\x93" (in
conformance with the second).</P>

<P>
<B>Notes from October 2003 meeting:</B>
</P>

<P>We decided we should forward this to the C committee and let them
resolve it.  Sent via e-mail to John Benito on November 14, 2003.</P>

<P>
<B>Reply from John Benito:</B>
</P>
<BLOCKQUOTE>
<P>I talked this over with the C project editor, we believe this was
handled by the C committee before publication of the current standard.</P>

<P>WG14 decided there needed to be a more restrictive rule 
for one-to-one mappings: rather than saying "a single c-char" 
as C++ does, the C standard says "a single character that
maps to a single-byte execution character"; WG14 fully expect
some (if not many or even most) UCNs to map to multiple characters.</P>

<P>Because of the fundamental differences between C and C++ character
types, I am not sure the C committee is qualified to answer this
satisfactorily for WG21.  WG14 is willing to review any decision reached
for compatibility.</P>

<P>I hope this helps.</P>
</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="309"></A>
<H4>309.
  
Linkage of entities whose names are not simply identifiers, in introduction
</H4>
<B>Section: </B>3&nbsp;



 <A HREF="basic.html#basic">basic</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Mike Miller
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>17 Sep 2001<BR>


<P>
3&nbsp;



 <A HREF="basic.html#basic">basic</A> paragraph 8, while not incorrect, does not
allow for linkage of operators and conversion functions. It says:</P>
<BLOCKQUOTE>
An identifier used in more than one translation unit can potentially
refer to the same entity in these translation units depending on the
linkage (3.5&nbsp;



 <A HREF="basic.html#basic.link">basic.link</A>) of the identifier specified in each
translation unit.
</BLOCKQUOTE>
<BR>
<BR>
<HR>
<A NAME="485"></A>
<H4>485.
  
What is a &ldquo;name&rdquo;?
</H4>
<B>Section: </B>3&nbsp;



 <A HREF="basic.html#basic">basic</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Gabriel Dos Reis
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>9 Nov 2004<BR>



<P>Clause 3&nbsp;



 <A HREF="basic.html#basic">basic</A> paragraph 4 says:</P>

<BLOCKQUOTE>

A <I>name</I> is a use of an identifier (2.10&nbsp;



 <A HREF="lex.html#lex.name">lex.name</A>)
that denotes an entity or label (6.6.4&nbsp;



 <A HREF="stmt.html#stmt.goto">stmt.goto</A>,
6.1&nbsp;



 <A HREF="stmt.html#stmt.label">stmt.label</A>).

</BLOCKQUOTE>

<P>Just three paragraphs later, it says</P>

<BLOCKQUOTE>

<P>Two names are the <I>same</I> if</P>

<P>
<UL>

<LI>they are identifiers composed of the same character sequence;
or</LI>

<LI>they are the names of overloaded operator functions formed with
the same operator; or</LI>

<LI>they are the names of user-defined conversion functions formed
with the same type.</LI>
</UL>
</P>

</BLOCKQUOTE>

<P>The last two bullets contradict the definition of <I>name</I>
in paragraph 4 because they are not identifiers.</P>

<P>This definition affects other parts of the Standard, as well.
For example, in 3.4.2&nbsp;



 <A HREF="basic.html#basic.lookup.argdep">basic.lookup.argdep</A> paragraph 1,</P>

<BLOCKQUOTE>

When an unqualified name is used as the <I>postfix-expression</I>
in a function call (5.2.2&nbsp;



 <A HREF="expr.html#expr.call">expr.call</A>), other
namespaces not considered during the usual unqualified lookup
(3.4.1&nbsp;



 <A HREF="basic.html#basic.lookup.unqual">basic.lookup.unqual</A>) may be searched, and in those
namespaces, namespace-scope friend function declarations
(11.4&nbsp;



 <A HREF="access.html#class.friend">class.friend</A>) not otherwise visible may be found.

</BLOCKQUOTE>

<P>With the current definition of <I>name</I>, argument-dependent
lookup apparently does not apply to function-notation calls to
overloaded operators.</P>

<P>Another related question is whether a <I>template-id</I> is a
name or not and thus would trigger an argument-dependent lookup.
Personally, I have always viewed a <I>template-id</I> as a name,
just like <TT>operator+</TT>.</P>

<BR>
<BR>
<HR>
<A NAME="481"></A>
<H4>481.
  
Scope of template parameters
</H4>
<B>Section: </B>3.3&nbsp;



 <A HREF="basic.html#basic.scope">basic.scope</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Gabriel Dos Reis
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>01 Nov 2004<BR>




<P>Sections 3.3.2&nbsp;



 <A HREF="basic.html#basic.scope.local">basic.scope.local</A> to 3.3.6&nbsp;



 <A HREF="basic.html#basic.scope.class">basic.scope.class</A> define and summarize different kinds of scopes
in a C++ program.  However it is missing a description for the
scope of template parameters.  I believe a section is needed
there &mdash; even though some information may be found in clause
14.</P>

<BR>
<BR>
<HR>
<A NAME="191"></A>
<H4>191.
  
Name lookup does not handle complex nesting
</H4>
<B>Section: </B>3.4.1&nbsp;



 <A HREF="basic.html#basic.lookup.unqual">basic.lookup.unqual</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Alan Nash
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>29 Dec 1999<BR>





<P>The current description of unqualified name lookup in
3.4.1&nbsp;



 <A HREF="basic.html#basic.lookup.unqual">basic.lookup.unqual</A>
 paragraph 8 does
not correctly handle complex cases of nesting.  The Standard
currently reads,</P>

<BLOCKQUOTE>
A name used in the definition of a function that is a member function
(9.3) of a class <TT>X</TT> shall be declared in one of the following
ways:

<BR>
<UL>
<LI>before its use in the block in which it is used or in an enclosing
block (6.3), or</LI>

<LI>shall be a member of class <TT>X</TT> or be a member of a base
class of <TT>X</TT> (10.2), or</LI>

<LI>if <TT>X</TT> is a nested class of class <TT>Y</TT> (9.7), shall
be a member of <TT>Y</TT>, or shall be a member of a base class of
<TT>Y</TT> (this lookup applies in turn to <TT>Y</TT>'s enclosing
classes, starting with the innermost enclosing class), or</LI>

<LI>if <TT>X</TT> is a local class (9.8) or is a nested class of a
local class, before the definition of class <TT>X</TT> in a block
enclosing the definition of class <TT>X</TT>, or</LI>

<LI>if <TT>X</TT> is a member of namespace <TT>N</TT>, or is a nested
class of a class that is a member of <TT>N</TT>, or is a local class
or nested class within a local class of a function that is a member of
<TT>N</TT>, before the member function definition, in namespace
<TT>N</TT> or in one of <TT>N</TT>'s enclosing namespaces.</LI>
</UL>
</BLOCKQUOTE>

In particular, this formulation does not handle the following example:

<PRE>
    struct outer {
        static int i;
        struct inner {
            void f() {
                struct local {
                    void g() {
                        i = 5;
                    }
                };
            }
        };
    };
</PRE>

Here the reference to <TT>i</TT> is from a member function of a local
class of a member function of a nested class.  Nothing in the rules
allows <TT>outer::i</TT> to be found, although intuitively it should
be found.

<P>A more comprehensive formulation is needed that allows traversal of
any combination of blocks, local classes, and nested classes.
Similarly, the final bullet needs to be augmented so that a function
need not be a (direct) member of a namespace to allow searching that
namespace when the reference is from a member function of a class
local to that function.  That is, the current rules do not allow the
following example:</P>

<PRE>
    int j;    // global namespace
    struct S {
        void f() {
            struct local2 {
                void g() {
                    j = 5;
                }
            };
        }
    };
</PRE>
<BR>
<BR>
<HR>
<A NAME="192"></A>
<H4>192.
  
Name lookup in parameters
</H4>
<B>Section: </B>3.4.1&nbsp;



 <A HREF="basic.html#basic.lookup.unqual">basic.lookup.unqual</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Alan Nash
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>6 Jan 2000<BR>





<P>The description of name lookup in the
<I>parameter-declaration-clause</I> of member functions in
3.4.1&nbsp;



 <A HREF="basic.html#basic.lookup.unqual">basic.lookup.unqual</A>
 paragraphs 7-8 is
flawed in at least two regards.</P>

<P>First, both paragraphs 7 and 8 apply to the
<I>parameter-declaration-clause</I> of a member function definition
and give different rules for the lookup.  Paragraph 7 applies to names
"used in the definition of a class <TT>X</TT> outside of a member
function body...," which includes the
<I>parameter-declaration-clause</I> of a member function definition,
while paragraph 8 applies to names following the function's
<I>declarator-id</I> (see the proposed resolution of
<A HREF="
     cwg_defects.html#41">issue 41</A>), including the
<I>parameter-declaration-clause</I>.</P>

<P>Second, paragraph 8 appears to apply to the type names used in the
<I>parameter-declaration-clause</I> of a member function defined
inside the class definition.  That is, it appears to allow the
following code, which was not the intent of the Committee:</P>

<PRE>
    struct S {
        void f(I i) { }
        typedef int I;
    };
</PRE>
<BR>
<BR>
<HR>
<A NAME="405"></A>
<H4>405.
  
Unqualified function name lookup
</H4>
<B>Section: </B>3.4.1&nbsp;



 <A HREF="basic.html#basic.lookup.unqual">basic.lookup.unqual</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>William M. Miller
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>14 Apr 2003<BR>


<P>There seems to be some confusion in the Standard regarding the
relationship between 3.4.1&nbsp;



 <A HREF="basic.html#basic.lookup.unqual">basic.lookup.unqual</A> (Unqualified name
lookup) and 3.4.2&nbsp;



 <A HREF="basic.html#basic.lookup.argdep">basic.lookup.argdep</A>
(Argument-dependent lookup).  For example,
3.4.1&nbsp;



 <A HREF="basic.html#basic.lookup.unqual">basic.lookup.unqual</A> paragraph 3 says,</P>

<BLOCKQUOTE>
The lookup for an unqualified name used as the
<I>postfix-expression</I> of a function call is described in
3.4.2&nbsp;



 <A HREF="basic.html#basic.lookup.argdep">basic.lookup.argdep</A>.
</BLOCKQUOTE>

<P>In other words, nothing in 3.4.1&nbsp;



 <A HREF="basic.html#basic.lookup.unqual">basic.lookup.unqual</A>
applies to function names; the entire lookup is described in
3.4.2&nbsp;



 <A HREF="basic.html#basic.lookup.argdep">basic.lookup.argdep</A>.</P>

<P>3.4.2&nbsp;



 <A HREF="basic.html#basic.lookup.argdep">basic.lookup.argdep</A> does not appear to share this
view of its responsibility.
The closest it comes is in 3.4.2&nbsp;



 <A HREF="basic.html#basic.lookup.argdep">basic.lookup.argdep</A> paragraph 2a:</P>

<BLOCKQUOTE>
...the set of declarations found by the lookup of the function
name is the union of the set of declarations found using ordinary
unqualified lookup and the set of declarations found in the namespaces
and classes associated with the argument types.
</BLOCKQUOTE>

<P>Presumably, "ordinary unqualified lookup" is a reference
to the processing described in
3.4.1&nbsp;



 <A HREF="basic.html#basic.lookup.unqual">basic.lookup.unqual</A>, but, as noted above,
3.4.1&nbsp;



 <A HREF="basic.html#basic.lookup.unqual">basic.lookup.unqual</A>
explicitly precludes applying that processing to function names.  The
details of "ordinary unqualified lookup" of function names
are not described anywhere.</P>

<P>The other clauses that reference
3.4.2&nbsp;



 <A HREF="basic.html#basic.lookup.argdep">basic.lookup.argdep</A>, clauses
13&nbsp;



 <A HREF="over.html#over">over</A> and 14&nbsp;



 <A HREF="template.html#temp">temp</A>, are
split over the question of the relationship between
3.4.1&nbsp;



 <A HREF="basic.html#basic.lookup.unqual">basic.lookup.unqual</A> and 3.4.2&nbsp;



 <A HREF="basic.html#basic.lookup.argdep">basic.lookup.argdep</A>.
13.3.1.1.1&nbsp;



 <A HREF="over.html#over.call.func">over.call.func</A> paragraph 3, for instance, says</P>

<BLOCKQUOTE>
The name is looked up in the context of the function call
following the normal rules for name lookup in function calls
(3.4.2&nbsp;



 <A HREF="basic.html#basic.lookup.argdep">basic.lookup.argdep</A>).
</BLOCKQUOTE>

<P>I.e., this reference assumes that
3.4.2&nbsp;



 <A HREF="basic.html#basic.lookup.argdep">basic.lookup.argdep</A> is self-contained.  The
same is true of 13.3.1.2&nbsp;



 <A HREF="over.html#over.match.oper">over.match.oper</A> paragraph 3,
second bullet:</P>

<BLOCKQUOTE>
The set of non-member candidates is the result of the
unqualified lookup of operator@ in the context of the expression
according to the usual rules for name lookup in unqualified function
calls (3.4.2&nbsp;



 <A HREF="basic.html#basic.lookup.argdep">basic.lookup.argdep</A>), except that all member
functions are ignored.
</BLOCKQUOTE>

<P>On the other hand, however, 14.6.4.2&nbsp;



 <A HREF="template.html#temp.dep.candidate">temp.dep.candidate</A>
paragraph 1 explicitly assumes that
3.4.1&nbsp;



 <A HREF="basic.html#basic.lookup.unqual">basic.lookup.unqual</A> and 3.4.2&nbsp;



 <A HREF="basic.html#basic.lookup.argdep">basic.lookup.argdep</A> are
both involved in function name lookup and do different things:</P>

<BLOCKQUOTE>
For a function call that depends on a template parameter, if
the function name is an <I>unqualified-id</I> but not a
<I>template-id</I>, the candidate functions are found using the usual
lookup rules (3.4.1&nbsp;



 <A HREF="basic.html#basic.lookup.unqual">basic.lookup.unqual</A>,
3.4.2&nbsp;



 <A HREF="basic.html#basic.lookup.argdep">basic.lookup.argdep</A>) except that:
<UL>
<LI>For the part of the lookup using unqualified name lookup
(3.4.1&nbsp;



 <A HREF="basic.html#basic.lookup.unqual">basic.lookup.unqual</A>),
only function declarations with external linkage from the template
definition context are found.</LI>

<LI>For the part of the lookup using associated
namespaces (3.4.2&nbsp;



 <A HREF="basic.html#basic.lookup.argdep">basic.lookup.argdep</A>),
only function declarations with external linkage found in either the
template definition context or the template instantiation context are
found.</LI>
</UL>
</BLOCKQUOTE>

<B>
<P>Suggested resolution:</P>
</B>

<P>Change 3.4.1&nbsp;



 <A HREF="basic.html#basic.lookup.unqual">basic.lookup.unqual</A> paragraph 1 from</P>

<BLOCKQUOTE>
...name lookup ends as soon as a declaration is found for the
name.
</BLOCKQUOTE>

<P>to</P>

<BLOCKQUOTE>
...name lookup ends with the first scope containing one or more
declarations of the name.
</BLOCKQUOTE>

<P>Change the first sentence of 3.4.1&nbsp;



 <A HREF="basic.html#basic.lookup.unqual">basic.lookup.unqual</A>
paragraph 3 from</P>

<BLOCKQUOTE>
The lookup for an unqualified name used as the
<I>postfix-expression</I> of a function call is described in
3.4.2&nbsp;



 <A HREF="basic.html#basic.lookup.argdep">basic.lookup.argdep</A>.
</BLOCKQUOTE>

<P>to</P>

<BLOCKQUOTE>
An unqualified name used as the <I>postfix-expression</I> of a
function call is looked up as described below.  In addition,
argument-dependent lookup (3.4.2&nbsp;



 <A HREF="basic.html#basic.lookup.argdep">basic.lookup.argdep</A>) is
performed on this name to
complete the resulting set of declarations.
</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="321"></A>
<H4>321.
  
Associated classes and namespaces for argument-dependent lookup
</H4>
<B>Section: </B>3.4.2&nbsp;



 <A HREF="basic.html#basic.lookup.argdep">basic.lookup.argdep</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Andrei Iltchenko
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>12 Nov 2001<BR>


<P>The last bullet of the second paragraph of section
3.4.2&nbsp;



 <A HREF="basic.html#basic.lookup.argdep">basic.lookup.argdep</A> says that:</P>
<BLOCKQUOTE>
If T is a template-id, its associated namespaces and classes are the
namespace in which the template is defined; for member templates, the member
template's class; the namespaces and classes associated with the types of
the template arguments provided for template type parameters (excluding
template template parameters); the namespaces in which any template template
arguments are defined; and the classes in which any member templates used as
template template arguments are defined.
</BLOCKQUOTE>

<P>The first problem with this wording is that it is misleading, since one
cannot get such a function argument whose type would be a template-id. The
bullet should be speaking about template specializations instead.</P>

<P>The second problem is owing to the use of the word "defined" in the phrases
"are the namespace in which the template is defined", "in which any template
template arguments are defined", and "as template template arguments are
defined". The bullet should use the word "declared" instead, since scenarios
like the one below are possible:</P>
<PRE>
namespace  A  {

   template&lt;class T&gt;
   struct  test  {

      template&lt;class U&gt;
      struct  mem_templ  {   };

   };

   // declaration in namespace 'A'
   template&lt;&gt; template&lt;&gt;
   struct  test&lt;int&gt;::mem_templ&lt;int&gt;;

   void  foo(test&lt;int&gt;::mem_templ&lt;int&gt;&amp;)
   {   }

}

// definition in the global namespace
template&lt;&gt; template&lt;&gt;
struct  A::test&lt;int&gt;::mem_templ&lt;int&gt;  {
};

int  main()
{
   A::test&lt;int&gt;::mem_templ&lt;int&gt;   inst;
   // According to the current definition of 3.4.2
   // foo is not found.
   foo(inst);
}
</PRE>

<P>In addition, the bullet doesn't make it clear whether a T which is a class
template specialization must also be treated as a class type, i.e. if the
contents of the second bullet of the second paragraph of section
3.4.2&nbsp;



 <A HREF="basic.html#basic.lookup.argdep">basic.lookup.argdep</A>.
<BLOCKQUOTE>
<UL>
<LI>
If T is a class type (including unions), its associated classes are: the
class itself; the class of which it is a member, if any; and its direct and
indirect base classes. Its associated namespaces are the namespaces in which
its associated classes are defined.
[This wording is as updated by core issue 90.]
</LI>
</UL>
</BLOCKQUOTE>
must apply to it or not. The same stands for a T which is a function
template specialization. This detail can make a difference in an example
such as the one below:
<PRE>
template&lt;class T&gt;
struct  slist_iterator  {
   friend bool  operator==(const slist_iterator&amp; x, const slist_iterator&amp; y)
   {   return  true;   }
};

template&lt;class T&gt;
struct  slist  {
   typedef slist_iterator&lt;T&gt;   iterator;
   iterator  begin()
   {   return  iterator();   }
   iterator  end()
   {   return  iterator();   }
};

int  main()
{
   slist&lt;int&gt;   my_list;
   slist&lt;int&gt;::iterator   mi1 = my_list.begin(),  mi2 = my_list.end();
   // Must the the friend function declaration
   // bool  operator==(const slist_iterator&lt;int&gt;&amp;, const slist_iterator&lt;int&gt;&amp;);
   // be found through argument dependent lookup? I.e. is the specialization
   // 'slist&lt;int&gt;' the associated class of the arguments 'mi1' and 'mi2'. If we
   // apply only the contents of the last bullet of 3.4.2/2, then the type
   // 'slist_iterator&lt;int&gt;' has no associated classes and the friend declaration
   // is not found.
   mi1 == mi2;
}
</PRE>
</P>

<P>
<B>Suggested resolution</B>:</P>

<P>Replace the last bullet of the second paragraph of section
3.4.2&nbsp;



 <A HREF="basic.html#basic.lookup.argdep">basic.lookup.argdep</A>
<BLOCKQUOTE>
<UL>
<LI>
If <TT>T</TT> is a <I>template-id</I>,
its associated namespaces and classes are the
namespace in which the template is defined; for member templates, the member
template's class; the namespaces and classes associated with the types of
the template arguments provided for template type parameters (excluding
template template parameters); the namespaces in which any template template
arguments are defined; and the classes in which any member templates used as
template template arguments are defined.
</LI>
</UL>
</BLOCKQUOTE>
with
<BLOCKQUOTE>
<UL>
<LI>
If <TT>T</TT> is a class template
specialization, its associated namespaces and
classes are those associated with <TT>T</TT> when
<TT>T</TT> is regarded as a class type; the
namespaces and classes associated with the types of the template arguments
provided for template type parameters (excluding template template
parameters); the namespaces in which the primary templates making template
template arguments are declared; and the classes in which any primary member
templates used as template template arguments are declared.
</LI>
<LI>
If <TT>T</TT> is a function template specialization,
its associated namespaces and
classes are those associated with <TT>T</TT> when
<TT>T</TT> is regarded as a function type;
the namespaces and classes associated with the types of the template
arguments provided for template type parameters (excluding template template
parameters); the namespaces in which the primary templates making template
template arguments are declared; and the classes in which any primary member
templates used as template template arguments are declared.
</LI>
</UL>
</BLOCKQUOTE>
</P>
<P>Replace the second bullet of the second paragraph of section
3.4.2&nbsp;



 <A HREF="basic.html#basic.lookup.argdep">basic.lookup.argdep</A>
<BLOCKQUOTE>
<UL>
<LI>
If <TT>T</TT> is a class type (including unions),
its associated classes are: the
class itself; the class of which it is a member, if any; and its direct and
indirect base classes. Its associated namespaces are the namespaces in which
its associated classes are defined.
</LI>
</UL>
</BLOCKQUOTE>
with
<BLOCKQUOTE>
<UL>
<LI>
If <TT>T</TT> is a class type (including unions),
its associated classes are: the
class itself; the class of which it is a member, if any; and its direct and
indirect base classes. Its associated namespaces are the namespaces in which
its associated classes are declared [Note: in case of any of the associated
classes being a class template specialization, its associated namespace is
acually the namespace containing the declaration of the primary class
template of the class template specialization].
</LI>
</UL>
</BLOCKQUOTE>
</P>

<BR>
<BR>
<HR>
<A NAME="141"></A>
<H4>141.
  
Non-member function templates in member access expressions
</H4>
<B>Section: </B>3.4.5&nbsp;



 <A HREF="basic.html#basic.lookup.classref">basic.lookup.classref</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>fvali
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>31 July 1999<BR>



<P>3.4.5&nbsp;



 <A HREF="basic.html#basic.lookup.classref">basic.lookup.classref</A>
 paragraph 1 says,</P>

<BLOCKQUOTE>
In a class member access expression
(5.2.5&nbsp;



 <A HREF="expr.html#expr.ref">expr.ref</A>
), if the <TT>.</TT> or
<TT>-&gt;</TT> token is immediately followed by an <I>identifier</I>
followed by a <TT>&lt;</TT>, the identifier must be looked up to
determine whether the <TT>&lt;</TT> is the beginning of a template
argument list
(14.2&nbsp;



 <A HREF="template.html#temp.names">temp.names</A>
) or a less-than
operator.  The identifier is first looked up in the class of the
object expression.  If the identifier is not found, it is then looked
up in the context of the entire <I>postfix-expression</I> and shall
name a class or function template.
</BLOCKQUOTE>

There do not seem to be any circumstances in which use of a
non-member template function would be well-formed as the
<I>id-expression</I> of a class member access expression.
<BR>
<BR>
<HR>
<A NAME="373"></A>
<H4>373.
  
Lookup on namespace qualified name in using-directive
</H4>
<B>Section: </B>3.4.6&nbsp;



 <A HREF="basic.html#basic.lookup.udir">basic.lookup.udir</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Clark Nelson
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>15 August 2002<BR>


<P>Is this case valid?  G++ compiles it.</P>
<PRE>
namespace X {
  namespace Y {
    struct X {
      void f()
      {
        using X::Y;
        namespace Z = X::Y;
      }
    };
  }
}
</PRE>
<P>The relevant citation from the standard is
3.4.6&nbsp;



 <A HREF="basic.html#basic.lookup.udir">basic.lookup.udir</A>: "When looking up a
namespace-name in a using-directive or namespace-alias-definition, only
namespace names are considered." This statement could reasonably be
interpreted to apply only to the last element of a qualified name, and
that's the way EDG and Microsoft seem to interpret it.</P>

<P>However, since a class can't contain a namespace, it seems to me that this
interpretation is, shall we say, sub optimal. If the X qualifiers in the
above example are interpreted as referring to the struct X, an error of some
sort is inevitable, since there can be no namespace for the qualified name
to refer to. G++ apparently interprets 3.4.6&nbsp;



 <A HREF="basic.html#basic.lookup.udir">basic.lookup.udir</A>
as applying to
nested-name-specifiers in those contexts as well, which makes a valid
interpretation of the test possible.</P>

<P>I'm thinking it might be worth
tweaking the words in 3.4.6&nbsp;



 <A HREF="basic.html#basic.lookup.udir">basic.lookup.udir</A>
to basically mandate the more useful
interpretation. Of course a person could argue that the difference would
matter only to a perverse program. On the other hand, namespaces were
invented specifically to enable the building of programs that would
otherwise be considered perverse. Where name clashes are concerned, one
man's perverse is another man's real world.</P>

<BR>
<BR>
<HR>
<A NAME="278"></A>
<H4>278.
  
External linkage and nameless entities
</H4>
<B>Section: </B>3.5&nbsp;



 <A HREF="basic.html#basic.link">basic.link</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Daveed Vandevoorde
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>12 Apr 2000<BR>




<P>It is unclear to what extent entities without names match
across translation units.  For example,</P>

<PRE>
    struct S {
       int :2;
       enum { a, b, c } x;
       static class {} *p;
    };
</PRE>

<P>If this declaration appears in multiple translation units, are
all these members "the same" in each declaration?</P>

<P>A similar question can be asked about non-member declarations:</P>

<PRE>
    // Translation unit 1:
    extern enum { d, e, f } y;

    // Translation unit 2:
    extern enum { d, e, f } y;

    // Translation unit 3:
    enum { d, e, f } y;
</PRE>

<P>Is this valid C++?  Is it valid C?</P>

<P>
<U>James Kanze</U>: <TT>S::p</TT> cannot be defined, because to
do so requires a type specifier and the type cannot be named.
<TT>::y</TT> is valid C because C only requires compatible, not
identical, types.  In C++, it appears that there is a new type in
each declaration, so it would not be valid.  This differs from
<TT>S::x</TT> because the unnamed type is part of a named type
&mdash; but I don't know where or if the Standard says that.</P>

<P>
<U>John Max Skaller</U>:
It's not valid C++, because the type is a synthesised, unique name
for the enumeration type which differs across translation units, as if:</P>

<PRE>
    extern enum _synth1 { d,e,f} y;
    ..
    extern enum _synth2 { d,e,f} y;
</PRE>

<P>had been written.</P>

<P>However, within a class, the ODR implies the types are the same:</P>

<PRE>
    class X { enum { d } y; };
</PRE>

<P>in two translation units ensures that the type of member <TT>y</TT>
is the same: the two <TT>X</TT>'s obey the ODR and so denote the same class,
and it follows that there's only one member <TT>y</TT> and one type that it
has.</P>

<P>(See also issues <A HREF="
     cwg_closed.html#132">132</A> and
<A HREF="
     cwg_defects.html#216">216</A>.)</P>

<BR>
<BR>
<HR>
<A NAME="279"></A>
<H4>279.
  
Correspondence of "names for linkage purposes"
</H4>
<B>Section: </B>3.5&nbsp;



 <A HREF="basic.html#basic.link">basic.link</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Daveed Vandevoorde
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>4 Apr 2001<BR>




<P>The standard says that an unnamed class or enum definition can be given
a "name for linkage purposes" through a typedef.  E.g.,</P>

<PRE>
    typedef enum {} E;
    extern E *p;
</PRE>

<P>can appear in multiple translation units.</P>

<P>How about the following combination?</P>

<PRE>
    // Translation unit 1:
    struct S;
    extern S *q;

    // Translation unit 2:
    typedef struct {} S;
    extern S *q;
</PRE>

<P>Is this valid C++?</P>

<P>Also, if the answer is "yes", consider the following slight variant:</P>

<PRE>
    // Translation unit 1:
    struct S {};  // &lt;&lt;-- class has definition
    extern S *q;

    // Translation unit 2:
    typedef struct {} S;
    extern S *q;
</PRE>

<P>Is this a violation of the ODR because two definitions
of type <TT>S</TT> consist of differing token sequences?</P>

<BR>
<BR>
<HR>
<A NAME="338"></A>
<H4>338.
  
Enumerator name with linkage used as class name in other translation unit
</H4>
<B>Section: </B>3.5&nbsp;



 <A HREF="basic.html#basic.link">basic.link</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Daveed Vandevoorde
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>26 Feb 2002<BR>




<P>The following declarations are allowed within a translation
unit:</P>
<PRE>
  struct S;
  enum { S };
</PRE>
<P>However, 3.5&nbsp;



 <A HREF="basic.html#basic.link">basic.link</A> paragraph 9 seems to say
these two declarations
cannot appear in two different translation units.  That also
would mean that the inclusion of a header containing the above
in two different translation units is not valid C++.</P>

<P>I suspect this is an oversight and that users should be allowed
to have the declarations above appear in different translation
units.  (It is a fairly common thing to do, I think.)</P>

<P>
<U>Mike Miller</U>:
I think you meant "<TT>enum E { S };</TT>" -- enumerators only have
external linkage if the enumeration does (3.5&nbsp;



 <A HREF="basic.html#basic.link">basic.link</A>
paragraph 4), and 3.5&nbsp;



 <A HREF="basic.html#basic.link">basic.link</A> paragraph 9 only
applies to entities with external linkage.</P>

<P>I don't remember why enumerators were given linkage; I don't
think it's necessary for mangling non-type template arguments.
In any event, I can't think why cross-TU name collisions between
enumerators and other entities would cause a problem, so I guess
a change here would be okay.  I can think of three changes that
would have that effect:</P>

<OL>
<LI>
Saying that enumerators do not have linkage.
</LI>
<LI>
Removing enumerators from the list of entities in the first
sentence of 3.5&nbsp;



 <A HREF="basic.html#basic.link">basic.link</A> paragraph 9.
</LI>
<LI>
Saying that it's okay for an enumerator in one TU to have the
same name as a class type in another TU only if the enumerator
hides that same class type in both TUs (the example you gave).
</LI>
</OL>

<P>
<U>Daveed Vandevoorde</U>:
I don't think any of these are sufficient in the sense that the problem
isn't limited to enumerators.  E.g.:
<PRE>
  struct X;
  extern void X();
</PRE>
shouldn't create cross-TU collisions either.</P>

<P>
<U>Mike Miller</U>:
So you're saying that cross-TU collisions should only be
prohibited if both names denote entities of the same kind (both
functions, both objects, both types, etc.), or if they are both
references (regardless of what they refer to, presumably)?</P>

<P>
<U>Daveed Vandevoorde</U>:
Not exactly.  Instead, I'm saying that if two entities (with
external linkage) can coexist when they're both declared in the
same translation unit (TU), then they should also be allowed to
coexist when they're declared in two different translation units.</P>

<P>For example:
<PRE>
  int i;
  void i();  // Error
</PRE>
This is an error within a TU, so I don't see a reason to make it
valid across TUs.</P>

<P>However, "tag names" (class/struct/union/enum) can sometimes
coexist with identically named entities (variables, functions &amp;
enumerators, but not namespaces, templates or type names).</P>

<BR>
<BR>
<HR>
<A NAME="527"></A>
<H4>527.
  
Problems with linkage of types
</H4>
<B>Section: </B>3.5&nbsp;



 <A HREF="basic.html#basic.link">basic.link</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Daveed Vandevoorde
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>28 July 2005<BR>


<P>The resolution of <A HREF="
     cwg_defects.html#389">issue 389</A> makes code
like</P>

<PRE>
    static struct {
        int i;
        int j;
    } X;
</PRE>

<P>ill-formed.  This breaks a lot of code for no apparent reason,
since the name <TT>X</TT> is not known outside the translation
unit in which it appears; there is therefore no danger of collision
and no need to mangle its name.</P>

<P>There has also been recent discussion on the email reflectors as to
whether the restrictions preventing use of types without linkage as
template arguments is needed or not, with the suggestion that a
mechanism like that used to give members of the unnamed namespace
unique names could be used for unnamed and local types.
  See also
<A HREF="
     cwg_active.html#488">issue 488</A>, which would become moot if
types without linkage could be used as template parameters.
</P>

<P>
<B>Notes from the October, 2005 meeting:</B>
</P>

<P>The Evolution Working Group is discussing changes that would
address this issue.  CWG will defer consideration until the outcome
of the EWG discussions is clear.</P>

<BR>
<BR>
<HR>
<A NAME="371"></A>
<H4>371.
  
Interleaving of constructor calls
</H4>
<B>Section: </B>3.6.2&nbsp;



 <A HREF="basic.html#basic.start.init">basic.start.init</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Matt Austern
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>7 August 2002<BR>




<P>Is a compiler allowed to interleave constructor calls when
performing dynamic initialization of nonlocal objects?
What I mean by interleaving is: beginning to execute a
particular constructor, then going off and doing
something else, then going back to the original constructor.
I can't find anything explicit about this in clause
3.6.2&nbsp;



 <A HREF="basic.html#basic.start.init">basic.start.init</A>.</P>

<P>I'll present a few different examples, some of which get a
bit wild.  But a lot of what this comes down to is exactly
what the standard means when it talks about the order
of initialization.  If it says that some object x must be
initialized before a particular event takes place, does that
mean that x's constructor must be entered before that
event, or does it mean that it must be exited before that
event?  If object x must be initialized before object y,
does that mean that x's constructor must exit before y's
constructor is entered?</P>

<P>(The answer to that question might just be common sense,
but I couldn't find an answer in clause 3.6.2&nbsp;



 <A HREF="basic.html#basic.start.init">basic.start.init</A>.
Actually, when I read 3.6.2&nbsp;



 <A HREF="basic.html#basic.start.init">basic.start.init</A>
carefully, I find there are a lot of things I took
for granted that aren't there.)</P>

<P>OK, so a few specific scenerios.</P>
<OL>
<LI>We have a translation unit with nonlocal objects A and B,
both of which require dynamic initialization.  A comes before
B.  A must be initialized before B.  May the compiler start
to construct A, get partway through the constructor, then
construct B, and then go back to finishing A?</LI>

<LI>We have a translation unit with nonlocal object A and
function f.  Construction of A is deferred until after the
first statement of main.  A must be constructed before the
first use of f.  Is the compiler permitted to start constructing
A, then execute f, then go back to constructing A?</LI>

<LI>We have nonlocal objects A and B, in two different
translation units.  The order in which A and B are constructed
is unspecified by the Standard.  Is the compiler permitted to
begin constructing A, then construct B, then finish A's
constructor?  Note the implications of a 'yes' answer.  If A's
and B's constructor both call some function f, then the call
stack might look like this:
<PRE>
   &lt;runtime gunk&gt;
     &lt;Enter A's constructor&gt;
        &lt;Enter f&gt;
           &lt;runtime gunk&gt;
              &lt;Enter B's constructor&gt;
                 &lt;Enter f&gt;
                 &lt;Leave f&gt;
              &lt;Leave B's constructor&gt;
        &lt;Leave f&gt;
     &lt;Leave A's constructor&gt;
</PRE>
The implication of a 'yes' answer for users is that any function
called by a constructor, directly or indirectly, must be reentrant.</LI>

<LI>This last example is to show why a 'no' answer to #3 might
be a problem too.  New scenerio: we've got one translation
unit containing a nonlocal object A and a function f1, and another
translation unit containing a nonlocal object B and a function f2.
A's constructor calls f2.  Initialization of A and B is deferred until
after the first statement of main().  Someone in main calls f1.
Question: is the compiler permitted to start constructing A, then
go off and construct B at some point before f2 gets called, then
go back and finish constructing A?  In fact, is the compiler
required to do that?  We've got an unpleasant tension here between
the bad implications of a 'yes' answer to #3, and the explicit
requirement in 3.6.2&nbsp;



 <A HREF="basic.html#basic.start.init">basic.start.init</A> paragraph 3.</LI>
</OL>

<P>At this point, you might be thinking we could avoid all of this
nonsense by removing compilers' freedom to defer initialization
until after the beginning of main().  I'd resist that, for two reasons.
First, it would be a huge change to make after the standard has
been out.  Second, that freedom is necessary if we want to have
support for dynamic libraries.  I realize we don't yet say anything
about dynamic libraries, but I'd hate to make decisions that would
make such support even harder.</P>

<BR>
<BR>
<HR>
<A NAME="28"></A>
<H4>28.
  
'exit', 'signal' and static object destruction
</H4>
<B>Section: </B>3.6.3&nbsp;



 <A HREF="basic.html#basic.start.term">basic.start.term</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Martin J. O'Riordan
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>19 Oct 1997<BR>




<P>The C++ standard has inherited the definition of the 'exit' function
more or less unchanged from ISO C.</P>

<P>However, when the 'exit' function is called, objects of static extent
which have been initialised, will be destructed if their types posses a
destructor.</P>

<P>In addition, the C++ standard has inherited the definition of the 'signal'
function and its handlers from ISO C, also pretty much unchanged.</P>

<P>The C standard says that the only standard library functions that may
be called while a signal handler is executing, are the functions 'abort',
'signal' and 'exit'.</P>

<P>This introduces a bit of a nasty turn, as it is not at all unusual for
the destruction of static objects to have fairly complex destruction semantics,
often associated with resource release. These quite commonly involve apparently
simple actions such as calling 'fclose' for a FILE handle.</P>

<P>Having observed some very strange behaviour in a program recently which
in handling a SIGTERM signal, called the 'exit' function as indicated by
the C standard.</P>

<P>But unknown to the programmer, a library static object performed some
complicated resource deallocation activities, and the program crashed.</P>

<P>The C++ standard says nothing about the interaction between signals,
exit and static objects. My observations, was that in effect, because the
destructor called a standard library function other than 'abort', 'exit'
or 'signal', while transitively in the execution context of the signal
handler, it was in fact non-compliant, and the behaviour was undefined
anyway.</P>

<P>This is I believe a plausible judgement, but given the prevalence of
this common programming technique, it seems to me that we need to say something
a lot more positive about this interaction.</P>

<P>Curiously enough, the C standard fails to say anything about the analogous
interaction with functions registered with 'atexit' ;-)</P>



<P>
<B>Proposed Resolution (10/98):</B>
</P>

<P>The current Committee Draft of the next version of the ISO C standard
specifies that the only standard library function that may be called while
a signal handler is executing is 'abort'. This would solve the above problem.</P>

<P>[This issue should remain open until it has been decided that the next
version of the C++ standard will use the next version of the C standard
as the basis for the behavior of 'signal'.]</P>
<BR>
<BR>
<HR>
<A NAME="365"></A>
<H4>365.
  
Storage duration and temporaries
</H4>
<B>Section: </B>3.7&nbsp;



 <A HREF="basic.html#basic.stc">basic.stc</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>James Kanze
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>24 July 2002<BR>


<P>There are several problems with 3.7&nbsp;



 <A HREF="basic.html#basic.stc">basic.stc</A>:</P>
<UL>
<LI>
<P>3.7&nbsp;



 <A HREF="basic.html#basic.stc">basic.stc</A> paragraph 2 says that "Static and automatic
storage durations are associated with objects introduced by
declarations (3.1&nbsp;



 <A HREF="basic.html#basic.def">basic.def</A>) and implicitly created
by the implementation (12.2&nbsp;



 <A HREF="special.html#class.temporary">class.temporary</A>)."</P>

<P>In fact, objects "implicitly created by the implementation" are the
temporaries described in (12.2&nbsp;



 <A HREF="special.html#class.temporary">class.temporary</A>), and have neither
static nor automatic storage duration, but a totally different duration,
described in 12.2&nbsp;



 <A HREF="special.html#class.temporary">class.temporary</A>.</P>
</LI>
<LI>
<P>3.7&nbsp;



 <A HREF="basic.html#basic.stc">basic.stc</A> uses the expression "local object" in several 
places, without ever defining it.  Presumably, what is meant is "an 
object declared at block scope", but this should be said explicitly.</P>

<P>In a recent discussion in comp.lang.c++.moderated, on poster 
interpreted "local objects" as including temporaries.  This would require them 
to live until the end of the block in which they are created, which
contradicts 12.2&nbsp;



 <A HREF="special.html#class.temporary">class.temporary</A>. If temporaries are covered by
this section, and the statement in 3.7&nbsp;



 <A HREF="basic.html#basic.stc">basic.stc</A>
seems to suggest, and they aren't local objects, then they must have
static storage duration, which isn't right either.</P>

<P>I propose adding a fourth storage duration to the list after
3.7&nbsp;



 <A HREF="basic.html#basic.stc">basic.stc</A> paragraph 1:</P>
<UL>
<LI>
temporary storage duration
</LI>
</UL>
<P>And rewriting the second paragraph of this section as follows:</P>
<BLOCKQUOTE>
Temporary storage duration is associated with objects implicitly
created by the implementation, and is described in 12.2&nbsp;



 <A HREF="special.html#class.temporary">class.temporary</A>.
Static and automatic storage durations are associated with objects defined
by declarations; in the following, an object defined by a declaration
with block scope is a local object.  The dynamic storage duration is
associated with objects created by the <TT>operator new</TT>.
</BLOCKQUOTE>
</LI>
</UL>

<P>
<U>Steve Adamczyk</U>:
There may well be an issue here, but one should bear in mind the
difference between storage duration and object lifetime.  As far
as I can see, there is no particular problem with temporaries having
automatic or static storage duration, as appropriate.  The point
of 12.2&nbsp;



 <A HREF="special.html#class.temporary">class.temporary</A> is that they have an unusual object
lifetime.</P>

<P>
<B>Notes from Ocrober 2002 meeting:</B>
</P>

<P>It might be desirable to shorten the storage duration of temporaries
to allow reuse of them.  The as-if rule allows some reuse, but such
reuse requires analysis, including noting whether the addresses of
such temporaries have been taken.</P>

<BR>
<BR>
<HR>
<A NAME="312"></A>
<H4>312.
  
"use" of invalid pointer value not defined
</H4>
<B>Section: </B>3.7.3.2&nbsp;



 <A HREF="basic.html#basic.stc.dynamic.deallocation">basic.stc.dynamic.deallocation</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Martin von Loewis
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>20 Sep 2001<BR>


<P>3.7.3.2&nbsp;



 <A HREF="basic.html#basic.stc.dynamic.deallocation">basic.stc.dynamic.deallocation</A> paragraph 4 mentions that the effect
of using an invalid pointer value is undefined. However, the standard
never says what it means to 'use' a value.</P>

<P>There are a number of possible interpretations, but it appears that
each of them leads to undesired conclusions:</P>
<OL>
<LI>
A value is 'used' in a program if a variable holding this value
appears in an expression that is evaluated.
This interpretation would render the sequence
<PRE>
   int *x = new int(0);
   delete x;
   x = 0;
</PRE>
into undefined behaviour. As this is a common idiom, this is
clearly undesirable.
</LI>
<LI>
A value is 'used' if an expression evaluates to that value.
This would render the sequence
<PRE>
   int *x = new int(0);
   delete x;
   x-&gt;~int();
</PRE>
into undefined behaviour; according to 5.2.4&nbsp;



 <A HREF="expr.html#expr.pseudo">expr.pseudo</A>,
the variable x is
'evaluated' as part of evaluating the pseudo destructor call. This,
in turn, would mean that all containers (23&nbsp;



 <A HREF="lib-containers.html#lib.containers">lib.containers</A>)
of pointers show
undefined behaviour, e.g. 23.2.2.3&nbsp;



 <A HREF="lib-containers.html#lib.list.modifiers">lib.list.modifiers</A>
requires to invoke the
destructor as part of the <TT>clear()</TT> method of the container.
</LI>
</OL>

<P>If any other meaning was intended for 'using an expression', that
meaning should be stated explicitly.</P>

<BR>
<BR>
<HR>
<A NAME="523"></A>
<H4>523.
  
Can a one-past-the-end pointer be invalidated by deleting an adjacent object?
</H4>
<B>Section: </B>3.7.3.2&nbsp;



 <A HREF="basic.html#basic.stc.dynamic.deallocation">basic.stc.dynamic.deallocation</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>comp.std.c++
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>8 July 2005<BR>


<P>When an object is deleted, 3.7.3.2&nbsp;



 <A HREF="basic.html#basic.stc.dynamic.deallocation">basic.stc.dynamic.deallocation</A> says
that the deallocation &ldquo;[renders] invalid all pointers referring
to any part of the deallocated storage.&rdquo; According to
3.9.2&nbsp;



 <A HREF="basic.html#basic.compound">basic.compound</A> paragraph 3, a pointer whose address is
one past the end of an array is considered to point to an unrelated
object that happens to reside at that address.  Does this need to be
clarified to specify that the one-past-the-end pointer of an array is
not invalidated by deleting the following object?  (See also
5.3.5&nbsp;



 <A HREF="expr.html#expr.delete">expr.delete</A> paragraph 4, which also mentions that
the system deallocation function renders a pointer invalid.)</P>

<BR>
<BR>
<HR>
<A NAME="419"></A>
<H4>419.
  
Can cast to virtual base class be done on partially-constructed object?
</H4>
<B>Section: </B>3.8&nbsp;



 <A HREF="basic.html#basic.life">basic.life</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Judy Ward
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>2 June 2003<BR>


<P>Consider</P>
<PRE>
  extern "C" int printf (const char *,...);

  struct Base { Base();};
  struct Derived: virtual public Base {
     Derived() {;}
  };

  Derived d;
  extern Derived&amp; obj = d;

  int i;

  Base::Base() {
    if ((Base *) &amp;obj) i = 4;
    printf ("i=%d\n", i);
  }

  int main() { return 0; }
</PRE>

<P>12.7&nbsp;



 <A HREF="special.html#class.cdtor">class.cdtor</A> paragraph 2 makes this valid, but
3.8&nbsp;



 <A HREF="basic.html#basic.life">basic.life</A> paragraph 5 implies that it isn't valid.</P>

<P>
<U>Steve Adamczyk:</U>
A second issue:</P>
<PRE>
  extern "C" int printf(const char *,...);
  struct A                      { virtual ~A(); int x; };
  struct B : public virtual A   { };
  struct C : public B           { C(int); };
  struct D : public C           { D(); };
 
  int main()                    { D t; printf("passed\n");return 0; }
 
  A::~A()                       {} 
  C::C(int)                     {} 
  D::D() : C(this-&gt;x)           {}
</PRE>
<P>
<A HREF="
     cwg_defects.html#52">Core issue 52</A> almost, but not quite,
says that in evaluating "this-&gt;x"
you do a cast to the virtual base class A, which would be an error
according to 12.7&nbsp;



 <A HREF="special.html#class.cdtor">class.cdtor</A> paragraph 2 because the base
class B constructor hasn't started yet.
5.2.5&nbsp;



 <A HREF="expr.html#expr.ref">expr.ref</A> should be clarified to say that
the cast does need to get done.</P>

<P>
<U>James Kanze</U> submitted the same issue via comp.std.c++
on 11 July 2003:</P>
<BLOCKQUOTE>
Richard Smith:
Nonsense. You can use "this" perfectly happily in a constructor, just
be careful that (a) you're not using any members that are not fully
initialised, and (b) if you're calling virtual functions you know
exactly what you're doing.
</BLOCKQUOTE>

<P>In practice, and I think in intent, you are right.  However, the
standard makes some pretty stringent restrictions in
3.8&nbsp;



 <A HREF="basic.html#basic.life">basic.life</A>.  To start
with, it says (in paragraph 1): </P>
<BLOCKQUOTE>
    The lifetime of an object is a runtime property of the object.  The
    lifetime of an object of type T begins when:
<UL>
<LI>
        storage with the proper alignment and size for type T is
        obtained, and
</LI>
<LI>

        if T is a class type with a non-trivial constructor, the
        constructor calls has COMPLETED.
</LI>
</UL>
    The lifetime of an object of type T ends when:
<UL>
<LI>
        if T is a class type with a non-trivial destructor, the
        destructor call STARTS, or
</LI>
<LI>
        the storage which the object occupies is reused or released.
</LI>
</UL>
</BLOCKQUOTE>
(Emphasis added.)  Then when we get down to paragraph 5, it says:
<BLOCKQUOTE>
<P>
    Before the lifetime of an object has started but after the storage
    which the object will occupy has been allocated [which sounds to me
    like it would include in the constructor, given the text above] or,
    after the lifetime of an object has ended and before the storage
    which the object occupied is reused or released, any pointer that
    refers to the storage location where the object will be or was
    located may be used but only in limited ways. [...] If the object
    will be or was of a non-POD class type, the program has undefined
    behavior if:
</P>
<P>
    [...]
</P>
<UL>
<LI>
        the pointer is implicitly converted to a pointer to a base class
        type, or [...]
</LI>
</UL>
</BLOCKQUOTE>

<P>I can't find any exceptions for the this pointer.</P>

<P>Note that calling a non-static function in the base class, or even
constructing the base class in initializer list, involves an implicit
conversion of this to a pointer to the base class.  Thus undefined
behavior.  I'm sure that this wasn't the intent, but it would seem to be
what this paragraph is saying.</P>

<BR>
<BR>
<HR>
<A NAME="496"></A>
<H4>496.
  
Is a volatile-qualified type really a POD?
</H4>
<B>Section: </B>3.9&nbsp;



 <A HREF="basic.html#basic.types">basic.types</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>John Maddock
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>30 Dec 2004<BR>




<P>In 3.9&nbsp;



 <A HREF="basic.html#basic.types">basic.types</A> paragraph 10, the standard makes
it quite clear that volatile qualified types are PODs:</P>

<BLOCKQUOTE>

Arithmetic types (3.9.1&nbsp;



 <A HREF="basic.html#basic.fundamental">basic.fundamental</A>), enumeration
types, pointer types, and pointer to member types (3.9.2&nbsp;



 <A HREF="basic.html#basic.compound">basic.compound</A>), and <I>cv-qualified</I> versions of these
types (3.9.3&nbsp;



 <A HREF="basic.html#basic.type.qualifier">basic.type.qualifier</A>) are collectively called
<I>scalar types</I>. Scalar types, POD-struct types, POD-union
types (clause 9&nbsp;



 <A HREF="class.html#class">class</A>), arrays of such types and
<I>cv-qualified</I> versions of these types (3.9.3&nbsp;



 <A HREF="basic.html#basic.type.qualifier">basic.type.qualifier</A>) are collectively called <I>POD types</I>.

</BLOCKQUOTE>

<P>However in 3.9&nbsp;



 <A HREF="basic.html#basic.types">basic.types</A> paragraph 3, the
standard makes it clear that PODs can be copied &ldquo;as
if&rdquo; they were a collection of bytes by <TT>memcpy</TT>:</P>

<BLOCKQUOTE>

For any POD type <TT>T</TT>, if two pointers to <TT>T</TT> point to
distinct <TT>T</TT> objects <TT>obj1</TT> and <TT>obj2</TT>, where
neither <TT>obj1</TT> nor <TT>obj2</TT> is a base-class subobject, if
the value of <TT>obj1</TT> is copied into <TT>obj2</TT>, using
the <TT>std::memcpy</TT> library function, <TT>obj2</TT> shall
subsequently hold the same value as <TT>obj1</TT>.

</BLOCKQUOTE>

<P>The problem with this is that a volatile qualified type may
need to be copied in a specific way (by copying using only atomic
operations on multithreaded platforms, for example) in order to
avoid the &ldquo;memory tearing&rdquo; that may occur with a
byte-by-byte copy.</P>

<P>I realise that the standard says very little about volatile
qualified types, and nothing at all (yet) about multithreaded
platforms, but nonetheless this is a real issue, for the
following reason:</P>

<P>The forthcoming TR1 will define a series of traits that
provide information about the properties of a type, including
whether a type is a POD and/or has trivial construct/copy/assign
operations.  Libraries can use this information to optimise their
code as appropriate, for example an array of type <TT>T</TT>
might be copied with a <TT>memcpy</TT> rather than an
element-by-element copy if <TT>T</TT> is a POD.  This was one of
the main motivations behind the type traits chapter of the TR1.
However it's not clear how volatile types (or POD's which have a
volatile type as a member) should be handled in these cases.</P>

<P>
<B>Notes from the April, 2005 meeting:</B>
</P>

<P>It is not clear whether the volatile qualifier actually guarantees
atomicity in this way.  Also, the work on the memory model for
multithreading being done by the Evolution Working Group seems at this
point likely to specify additional semantics for volatile data, and
that work would need to be considered before resolving this issue.</P>

<BR>
<BR>
<HR>
<A NAME="146"></A>
<H4>146.
  
Floating-point zero
</H4>
<B>Section: </B>3.9.1&nbsp;



 <A HREF="basic.html#basic.fundamental">basic.fundamental</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Andy Sawyer
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>23 Jul 1999<BR>





<P>3.9.1&nbsp;



 <A HREF="basic.html#basic.fundamental">basic.fundamental</A>
 does not impose
a requirement on the floating point types that there be an exact
representation of the value zero.  This omission is significant in
4.12&nbsp;



 <A HREF="conv.html#conv.bool">conv.bool</A>
 paragraph 1, in which any
non-zero value converts to the <TT>bool</TT> value <TT>true</TT>.</P>

<P>Suggested resolution: require that all floating point types have an
exact representation of the value zero.</P>
<BR>
<BR>
<HR>
<A NAME="251"></A>
<H4>251.
  
How many signed integer types are there?
</H4>
<B>Section: </B>3.9.1&nbsp;



 <A HREF="basic.html#basic.fundamental">basic.fundamental</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Beman Dawes
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>18 Oct 2000<BR>




<P>3.9.1&nbsp;



 <A HREF="basic.html#basic.fundamental">basic.fundamental</A> paragraph 2 says that</P>

<BLOCKQUOTE>

There are four <I>signed integer types</I>: "<TT>signed char</TT>",
"<TT>short int</TT>", "<TT>int</TT>", and "<TT>long int</TT>."

</BLOCKQUOTE>

<P>This would indicate that <TT>const int</TT> is not a signed
integer type.</P>

<BR>
<BR>
<HR>
<A NAME="483"></A>
<H4>483.
  
Normative requirements on integral ranges
</H4>
<B>Section: </B>3.9.1&nbsp;



 <A HREF="basic.html#basic.fundamental">basic.fundamental</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Steve Adamczyk
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>21 Oct 2004<BR>


<P>There is no normative requirement on the ranges of the integral
types, although the footnote in 3.9.1&nbsp;



 <A HREF="basic.html#basic.fundamental">basic.fundamental</A>
paragraph 2 indicates the intent (for <TT>int</TT>, at least)
that they match the values given in the <TT>&lt;climits&gt;</TT>
header.  Should there be an explicit requirement of some sort?</P>

<P>(See also paper N1693.)</P>

<BR>
<BR>
<HR>
<A NAME="240"></A>
<H4>240.
  
Uninitialized values and undefined behavior
</H4>
<B>Section: </B>4.1&nbsp;



 <A HREF="conv.html#conv.lval">conv.lval</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Mike Miller
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>8 Aug 2000<BR>




<P>4.1&nbsp;



 <A HREF="conv.html#conv.lval">conv.lval</A> paragraph 1 says,</P>

<BLOCKQUOTE>

If the object to which the lvalue refers is not an object of type
<TT>T</TT> and is not an object of a type derived from <TT>T</TT>, or
if the object is uninitialized, a program that necessitates this
conversion has undefined behavior.

</BLOCKQUOTE>

<P>I think there are at least three related issues around this
specification:</P>

<OL>

<LI>
<P>Presumably assigning a valid value to an uninitialized
object allows it to participate in the lvalue-to-rvalue
conversion without undefined behavior (otherwise the number of
programs with defined behavior would be vanishingly small :-).
However, the wording here just says "uninitialized" and doesn't
mention assignment.</P>
</LI>

<LI>
<P>There's no exception made for <TT>unsigned char</TT> types.
The wording in 3.9.1&nbsp;



 <A HREF="basic.html#basic.fundamental">basic.fundamental</A> was carefully crafted to
allow use of <TT>unsigned char</TT> to access uninitialized data so
that <TT>memcpy</TT> and such could be written in C++ without
undefined behavior, but this statement undermines that
intent.</P>
</LI>

<LI>
<P>It's possible to get an uninitialized rvalue without invoking
the lvalue-to-rvalue conversion.  For instance:</P>

<PRE>
        struct A {
            int i;
            A() { } // no init of A::i
        };
        int j = A().i;  // uninitialized rvalue
</PRE>

<P>There doesn't appear to be anything in the current IS wording
that says that this is undefined behavior.  My guess is that we
thought that in placing the restriction on use of uninitialized
objects in the lvalue-to-rvalue conversion we were catching all
possible cases, but we missed this one.</P>
</LI>

</OL>

<P>In light of the above, I think the discussion of uninitialized
objects ought to be removed from 4.1&nbsp;



 <A HREF="conv.html#conv.lval">conv.lval</A> paragraph
1.  Instead, something like the following ought to be added to
3.9&nbsp;



 <A HREF="basic.html#basic.types">basic.types</A> paragraph 4 (which is where the concept of
"value" is introduced):</P>

<BLOCKQUOTE>
Any use of an indeterminate value (5.3.4&nbsp;



 <A HREF="expr.html#expr.new">expr.new</A>,
8.5&nbsp;



 <A HREF="decl.html#dcl.init">dcl.init</A>, 12.6.2&nbsp;



 <A HREF="special.html#class.base.init">class.base.init</A>) of any type
other than <TT>char</TT> or <TT>unsigned char</TT> results in
undefined behavior.
</BLOCKQUOTE>

<P>
<U>John Max Skaller</U>:</P>

<P>
<TT>A().i</TT> had better be an lvalue; the rules are wrong.
Accessing a member of a structure requires it be converted to
an lvalue, the above calculation is 'as if':</P>

<PRE>
    struct A {
        int i;
        A *get() { return this; }
    };
    int j = (*A().get()).i;
</PRE>

<P>and you can see the bracketed expression is an lvalue. </P>

<P>A consequence is:</P>

<PRE>
    int &amp;j= A().i; // OK, even if the temporary evaporates
</PRE>

<P>
<TT>j</TT> now refers to a 'destroyed' value. Any use of <TT>j</TT>
is an error.  But the binding at the time is valid.</P>

<BR>
<BR>
<HR>
<A NAME="330"></A>
<H4>330.
  
Qualification conversions and pointers to arrays of pointers
</H4>
<B>Section: </B>4.4&nbsp;



 <A HREF="conv.html#conv.qual">conv.qual</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Roger Orr
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>2 Jan 2002<BR>


<P>Section 4.4&nbsp;



 <A HREF="conv.html#conv.qual">conv.qual</A>
covers the case of multi-level pointers, but does not appear to cover the
case of pointers to arrays of pointers.
The effect is that arrays are treated differently from simple scalar
values.</P>

<P>Consider for example the following code:
(from the thread "Pointer to array conversion question" begun in
comp.lang.c++.moderated)
<PRE>
  int main()
  {
     double *array2D[2][3];
  
     double       *       (*array2DPtr1)[3] = array2D;     // Legal
     double       * const (*array2DPtr2)[3] = array2DPtr1; // Legal
     double const * const (*array2DPtr3)[3] = array2DPtr2; // Illegal
  }
</PRE>
and compare this code with:-
<PRE>
  int main()
  {
     double *array[2];
  
     double       *       *ppd1 = array; // legal
     double       * const *ppd2 = ppd1;  // legal
     double const * const *ppd3 = ppd2;  // certainly legal (4.4/4)
  }
</PRE>
</P>

<P>The problem appears to be that the pointed to types in example 1 are
unrelated since nothing in the
relevant section of the standard covers it - 4.4&nbsp;



 <A HREF="conv.html#conv.qual">conv.qual</A>
does not mention conversions of the form
"cv array of N pointer to T"
into
"cv array of N pointer to cv T"</P>

<P>It appears that reinterpret_cast is the only way to perform the
conversion.</P>

<P>
<B>Suggested resolution:</B>
</P>

<P>Artem Livshits proposed a resolution :-</P>

<P>"I suppose if the definition of "similar" pointer types in
4.4&nbsp;



 <A HREF="conv.html#conv.qual">conv.qual</A> paragraph 4 was
rewritten like this:
<BLOCKQUOTE>
<P>T1 is cv1,0 P0 cv1,1 P1 ... cv1,n-1 Pn-1 cv1,n T</P>
<P>and</P>
<P>T2 is cv1,0 P0 cv1,1 P1 ... cv1,n-1 Pn-1 cv1,n T</P>

<P>where Pi is either a "pointer to" or a "pointer to an array of Ni"; besides
P0 may be also a "reference to" or a "reference to an array of N0" (in the
case of P0 of T2 being a reference, P0 of T1 may be nothing).</P>
</BLOCKQUOTE>
it would address the problem.</P>

<P>In fact I guess Pi in this notation may be also a "pointer to member", so
4.4&nbsp;



 <A HREF="conv.html#conv.qual">conv.qual</A>/{4,5,6,7} would be nicely wrapped in one
paragraph."</P>

<BR>
<BR>
<HR>
<A NAME="238"></A>
<H4>238.
  
Precision and accuracy constraints on floating point
</H4>
<B>Section: </B>5&nbsp;



 <A HREF="expr.html#expr">expr</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Christophe de Dinechin
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>31 Jul 2000<BR>




<P>It is not clear what constraints are placed on a floating point
implementation by the wording of the Standard.  For instance, is
an implementation permitted to generate a "fused multiply-add"
instruction if the result would be different from what would
be obtained by performing the operations separately?  To what
extent does the "as-if" rule allow the kinds of optimizations
(e.g., loop unrolling) performed by FORTRAN compilers?</P>

<BR>
<BR>
<HR>
<A NAME="438"></A>
<H4>438.
  
Possible flaw in wording for multiple accesses to object between sequence points
</H4>
<B>Section: </B>5&nbsp;



 <A HREF="expr.html#expr">expr</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Jason Merrill
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>29 Oct 2003<BR>


<P>Lisa Lippincott mentioned this case to me:</P>
<PRE>
  A[0] = 0;
  A[A[0]] = 1;
</PRE>
<P>This seems to use the old value of A[0] other than to calculate the new
value, which is said to be undefined, but it also seems reasonable, since
the old value is used in order to select the object to modify, so there's
no ordering ambiguity.</P>

<P>
<U>Steve Adamczyk</U>: the ordering rule referred to is in
5&nbsp;



 <A HREF="expr.html#expr">expr</A> paragraph 4.</P>

<P>
<B>Notes from the March 2004 meeting:</B>
</P>

<P>Clark Nelson mentions that the C committee may have done something on
this.</P>

<BR>
<BR>
<HR>
<A NAME="536"></A>
<H4>536.
  
Problems in the description of <I>id-expression</I>s
</H4>
<B>Section: </B>5.1&nbsp;



 <A HREF="expr.html#expr.prim">expr.prim</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Mike Miller
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>13 October 2005<BR>


<P>There are at least a couple of problems in the description of
the various <I>id-expression</I>s in 5.1&nbsp;



 <A HREF="expr.html#expr.prim">expr.prim</A>:</P>

<OL>
<LI>
<P>Paragraph 4 embodies an incorrect assumption about the
syntax of <I>qualified-id</I>s:</P>

<BLOCKQUOTE>

The operator <TT>::</TT> followed by an <I>identifier</I>, a
<I>qualified-id</I>, or an <I>operator-function-id</I> is a
<I>primary-expression</I>.

</BLOCKQUOTE>

<P>The problem here is that the <TT>::</TT> is actually part of the
syntax of <I>qualified-id</I>; consequently, &ldquo;<TT>::</TT> followed by...
a <I>qualified-id</I>&rdquo; could be something like
&ldquo;<TT>:: ::i</TT>,&rdquo; which is ill-formed.  Presumably
this should say something like, &ldquo;A <I>qualified-id</I> with
no <I>nested-name-specifier</I> is a <I>primary-expression</I>.&rdquo;</P>
</LI>

<LI>
<P>More importantly, some kinds of <I>id-expression</I>s are not
described by 5.1&nbsp;



 <A HREF="expr.html#expr.prim">expr.prim</A>.  The structure of this
section is that the result, type, and lvalue-ness are specified for
each of the cases it covers:</P>

<UL>
<LI>
<P>paragraph 4 deals with <I>qualified-id</I>s that have no
<I>nested-name-specifier</I>
</P>
</LI>

<LI>
<P>paragraph 7 deals with bare <I>identifier</I>s and with
<I>qualified-id</I>s containing a <I>nested-name-specifier</I>
that names a class</P>
</LI>

<LI>
<P>paragraph 8 deals with <I>qualified-id</I>s containing a
<I>nested-name-specifier</I> that names a namespace</P>
</LI>

</UL>

<P>This treatment leaves unspecified all the non-<I>identifier</I>
<I>unqualified-id</I>s (<I>operator-function-id</I>,
<I>conversion-function-id</I>, and <I>template-id</I>), as well as
(perhaps) &ldquo;<TT>::</TT> <I>template-id</I>&rdquo; (it's not clear
whether the &ldquo;<TT>::</TT> followed by a <I>qualified-id</I>&rdquo; case
is supposed to apply to <I>template-id</I>s or not).  Note also that the
proposed resolution of <A HREF="
     cwg_active.html#301">issue 301</A> slightly
exacerbates this problem by removing the form
of <I>operator-function-id</I> that contains
a <I>tmeplate-argument-list</I>; as a result, references like
&ldquo;<TT>::operator+&lt;X&gt;</TT>&rdquo; are no longer covered in
5.1&nbsp;



 <A HREF="expr.html#expr.prim">expr.prim</A>.</P>
</LI>

</OL>

<BR>
<BR>
<HR>
<A NAME="118"></A>
<H4>118.
  
Calls via pointers to virtual member functions
</H4>
<B>Section: </B>5.2.2&nbsp;



 <A HREF="expr.html#expr.call">expr.call</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Martin O'Riordan
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>17 May 1999<BR>




<P>
<U>Martin O'Riordan:</U>
Having gone through all the relevant references in the IS, it is not
conclusive that a call via a pointer to a virtual member function
is polymorphic at all, and could legitimately be
interpreted as being static.</P>

<P>Consider 5.2.2&nbsp;



 <A HREF="expr.html#expr.call">expr.call</A>
 paragraph 1:</P>
<BLOCKQUOTE>

The function called in a member function call is normally selected
according to the static type of the object expression (clause
10&nbsp;



 <A HREF="derived.html#class.derived">class.derived</A>
), but if that function is
<TT>virtual</TT> and is not specified using a <I>qualified-id</I> then
the function actually called will be the final overrider
(10.3&nbsp;



 <A HREF="derived.html#class.virtual">class.virtual</A>
) of the selected
function in the dynamic type of the object expression.

</BLOCKQUOTE>
Here it is quite specific that you get the polymorphic call only if you use
the unqualified syntax.  But, the address of a member function is "always"
taken using the qualified syntax, which by inference would indicate that
call with a PMF is static and not polymorphic!  Not what was intended.

<P>Yet other references such as
5.5&nbsp;



 <A HREF="expr.html#expr.mptr.oper">expr.mptr.oper</A>
 paragraph 4:</P>
<BLOCKQUOTE>

If the dynamic type of the object does not contain the member to which
the pointer refers, the behavior is undefined.

</BLOCKQUOTE>
indicate that the opposite may have been intended, by stating that it is the
dynamic type and not the static type that matters.  Also,
5.5&nbsp;



 <A HREF="expr.html#expr.mptr.oper">expr.mptr.oper</A>
 paragraph 6:
<BLOCKQUOTE>

If the result of <TT>.*</TT> or <TT>-&gt;*</TT> is a function,
then that result can be used
only as the operand for the function
call operator (). [<I>Example:</I>
<PRE>
        (ptr_to_obj-&gt;*ptr_to_mfct)(10);
</PRE>
calls the member function denoted by <TT>ptr_to_mfct</TT>
for the object pointed
to by <TT>ptr_to_obj</TT>. ]

</BLOCKQUOTE>

which also implies that it is the object pointed to that determines both the
validity of the expression (the static type of '<TT>ptr_to_obj</TT>'
may not have a
compatible function) and the implicit (polymorphic) meaning.   Note too,
that this is stated in the non-normative example text.

<P>
<U>Andy Sawyer:</U>
Assuming the resolution is what I've assumed it is for the
last umpteen years (i.e. it does the polymorphic thing), then
the follow on to that is "Should there also be a way of selecting
the non-polymorphic behaviour"?</P>

<P>
<U>Mike Miller:</U>
It might be argued that the current wording of
5.2.2&nbsp;



 <A HREF="expr.html#expr.call">expr.call</A>
 paragraph 1 does give
polymorphic behavior to simple calls via pointers to members.
(There is no <I>qualified-id</I> in <TT>obj.*pmf</TT>, and the IS says
that if the function is not specified using a <I>qualified-id</I>, the
final overrider will be called.)  However, it clearly says the wrong
thing when the pointer-to-member itself is specified using a
<I>qualified-id</I> (<TT>obj.*X::pmf</TT>).</P>

<P>
<U>Bill Gibbons:</U>
The phrase <I>qualified-id</I> in
5.2.2&nbsp;



 <A HREF="expr.html#expr.call">expr.call</A>
 paragraph 1 refers to the
<I>id-expression</I> and not to the "pointer-to-member expression"
earlier in the paragraph:</P>

<BLOCKQUOTE>
For a member function call, the postfix expression shall be an
implicit (9.3.1&nbsp;



 <A HREF="class.html#class.mfct.nonstatic">class.mfct.nonstatic</A>
,
9.4&nbsp;



 <A HREF="class.html#class.static">class.static</A>
) or explicit class member
access (5.2.5&nbsp;



 <A HREF="expr.html#expr.ref">expr.ref</A>
) whose
<I>id-expression</I> is a function member name, or a pointer-to-member
expression (5.5&nbsp;



 <A HREF="expr.html#expr.mptr.oper">expr.mptr.oper</A>
) selecting
a function member.
</BLOCKQUOTE>

<P>
<U>Mike Miller:</U>
To be clear, here's an example:</P>

<PRE>
    struct S {
	virtual void f();
    };
    void (S::*pmf)();
    void g(S* sp) {
	sp-&gt;f();         // 1: polymorphic
	sp-&gt;S::f();      // 2: non-polymorphic
	(sp-&gt;S::f)();    // 3: non-polymorphic
	(sp-&gt;*pmf)();    // 4: polymorphic
	(sp-&gt;*&amp;S::f)();  // 5: polymorphic
    }
</PRE>

<P>
<B>Notes from October 2002 meeting:</B>
</P>

<P>This was moved back to open for lack of a champion.  Martin O'Riordan
is not expected to be attending meetings.</P>

<BR>
<BR>
<HR>
<A NAME="282"></A>
<H4>282.
  
Namespace for <TT>extended_type_info</TT>
</H4>
<B>Section: </B>5.2.8&nbsp;



 <A HREF="expr.html#expr.typeid">expr.typeid</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Jens Maurer
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>01 May 2001<BR>


<P>The original proposed resolution for <A HREF="
     cwg_defects.html#160">issue 160</A>
included changing <TT>extended_type_info</TT>
(5.2.8&nbsp;



 <A HREF="expr.html#expr.typeid">expr.typeid</A> paragraph 1, footnote 61) to
<TT>std::extended_type_info</TT>.  There was no consensus on whether
this name ought to be part of namespace <TT>std</TT> or in a
vendor-specific namespace, so the question was moved into a
separate issue.</P>

<BR>
<BR>
<HR>
<A NAME="528"></A>
<H4>528.
  
Why are incomplete class types not allowed with <TT>typeid</TT>?
</H4>
<B>Section: </B>5.2.8&nbsp;



 <A HREF="expr.html#expr.typeid">expr.typeid</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Dave Abrahams
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>18 May 2005<BR>




<P>5.2.8&nbsp;



 <A HREF="expr.html#expr.typeid">expr.typeid</A> paragraph 4 says,</P>

<BLOCKQUOTE>

When <TT>typeid</TT> is applied to a <I>type-id</I>, the result refers
to a <TT>std::type_info</TT> object representing the type of
the <I>type-id</I>.  If the type of the <I>type-id</I> is a reference
type, the result of the <TT>typeid</TT> expression refers to
a <TT>std::type_info</TT> object representing the referenced type. If
the type of the <I>type-id</I> is a class type or a reference to a
class type, the class shall be completely-defined.

</BLOCKQUOTE>

<P>I'm wondering whether this is not overly restrictive.  I can't
think of a reason to require that <TT>T</TT> be completely-defined
in <TT>typeid(T)</TT> when <TT>T</TT> is a class type.  In fact,
several popular compilers enforce that restriction
for <TT>typeid(T)</TT>, but not for <TT>typeid(T&amp;)</TT>.  Can
anyone explain this?
</P>

<P>
<U>Nathan Sidwell</U>: I think this restriction is so that whenever
the compiler has to emit a typeid object of a class type, it knows
what the base classes are, and can therefore emit an array of
pointers-to-base-class typeids.  Such a tree is necessary to implement
<TT>dynamic_cast</TT> and exception catching (in a commonly
implemented and obvious manner).  If the class could be incomplete,
the compiler might have to emit a typeid for incomplete <TT>Foo</TT>
in one object file and a typeid for complete <TT>Foo</TT> in another
object file.  The compilation system will then have to make sure that
(a) those compare equal and (b) the complete <TT>Foo</TT> gets
priority, if that is applicable.
</P>

<P>Unfortunately, there is a problem with exceptions that means there
still can be a need to emit typeids for incomplete class.  Namely one
can throw a pointer-to-pointer-to-incomplete.  To implement the
matching of pointer-to-derived being caught by pointer-to-base, it is
necessary for the typeid of a pointer type to contain a pointer to the
typeid of the pointed-to type.  In order to do the qualification
matching on a multi-level pointer type, one has a chain of pointer
typeids that can terminate in the typeid of an incomplete type.  You
cannot simply NULL-terminate the chain, because one must distinguish
between different incomplete types.</P>

<P>
<U>Dave Abrahams</U>: So if implementations are still required to
be able to do it, for all practical purposes, why aren't we letting
the user have the benefits?</P>

<BR>
<BR>
<HR>
<A NAME="342"></A>
<H4>342.
  
Terminology: "indirection" versus "dereference"
</H4>
<B>Section: </B>5.3&nbsp;



 <A HREF="expr.html#expr.unary">expr.unary</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Jason Merrill
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>7 Oct 2001<BR>




<P>Split off from <A HREF="
     cwg_closed.html#315">issue 315</A>.</P>

<P>Incidentally, another thing that ought to be cleaned up is the inconsistent
use of "indirection" and "dereference".  We should pick one.</P>

<BR>
<BR>
<HR>
<A NAME="203"></A>
<H4>203.
  
Type of address-of-member expression
</H4>
<B>Section: </B>5.3.1&nbsp;



 <A HREF="expr.html#expr.unary.op">expr.unary.op</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Lisa Lippincott
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>8 Feb 2000<BR>



<P>5.3.1&nbsp;



 <A HREF="expr.html#expr.unary.op">expr.unary.op</A>
 paragraph 2 indicates
that the type of an address-of-member expression reflects the class in
which the member was declared rather than the class identified in the
<I>nested-name-specifier</I> of the <I>qualified-id</I>.  This
treatment is unintuitive and can lead to strange code and unexpected
results.  For instance, in</P>

<PRE>
    struct B { int i; };
    struct D1: B { };
    struct D2: B { };

    int (D1::* pmD1) = &amp;D2::i;   // NOT an error
</PRE>

More seriously, template argument deduction can give surprising
results:

<PRE>
    struct A {
       int i;
       virtual void f() = 0;
    };

    struct B : A {
       int j;
       B() : j(5)  {}
       virtual void f();
    };

    struct C : B {
       C() { j = 10; }
    };

    template &lt;class T&gt;
    int DefaultValue( int (T::*m) ) {
       return T().*m;
    }

    ... DefaultValue( &amp;B::i )    // Error: A is abstract
    ... DefaultValue( &amp;C::j )    // returns 5, not 10.
</PRE>

<P>
<B>Suggested resolution:</B>
5.3.1&nbsp;



 <A HREF="expr.html#expr.unary.op">expr.unary.op</A>
 should be changed to
read,</P>

<BLOCKQUOTE>
If the member is a nonstatic member (perhaps by inheritance) of the
class nominated by the <I>nested-name-specifier</I> of the
<I>qualified-id</I> having type <TT>T</TT>, the type of the result is
"pointer to member of class <I>nested-name-specifier</I> of type
<TT>T</TT>."
</BLOCKQUOTE>

and the comment in the example should be changed to read,

<BLOCKQUOTE>
<TT>// <I>has type </I>int B::*</TT>
</BLOCKQUOTE>

<P>
<B>Notes from 04/00 meeting:</B>
</P>

<P>The rationale for the current treatment is to permit the widest
possible use to be made of a given address-of-member expression.
Since a pointer-to-base-member can be implicitly converted to a
pointer-to-derived-member, making the type of the expression a
pointer-to-base-member allows the result to initialize or be assigned
to either a pointer-to-base-member or a pointer-to-derived-member.
Accepting this proposal would allow only the latter use.</P>

<P>
<B>Additional notes:</B>
</P>

<P>Another problematic example has been mentioned:</P>

<PRE>
    class Base {
    public:
      int func() const;
    };

    class Derived : public Base {
    };

    template&lt;class T&gt;
    class Templ {
    public:
      template&lt;class S&gt;
      Templ(S (T::*ptmf)() const);
    };

    void foo()
    {
      Templ&lt;Derived&gt; x(&amp;Derived::func);    // <I>ill-formed</I>
    }
</PRE>

<P>In this example, even though the conversion of
<TT>&amp;Derived::func</TT> to <TT>int (Derived::*)() const</TT> is
permitted, the initialization of <TT>x</TT> cannot be done because
template argument deduction for the constructor fails.</P>

<P>If the suggested resolution were adopted, the amount of code broken
by the change might be reduced by adding an implicit conversion from
pointer-to-derived-member to pointer-to-base-member for appropriate
address-of-member expressions (not for arbitrary pointers to members,
of course).</P>

<P>(See also <A HREF="
     cwg_closed.html#247">issue 247</A>.)</P>

<BR>
<BR>
<HR>
<A NAME="267"></A>
<H4>267.
  
Alignment requirement for <I>new-expression</I>s
</H4>
<B>Section: </B>5.3.4&nbsp;



 <A HREF="expr.html#expr.new">expr.new</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>James Kuyper
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>4 Dec 2000<BR>


<P>Requirements for the alignment of pointers returned by
<I>new-expression</I>s are given in 5.3.4&nbsp;



 <A HREF="expr.html#expr.new">expr.new</A>
paragraph 10:</P>

<BLOCKQUOTE>

For arrays of <TT>char</TT> and <TT>unsigned char</TT>, the difference
between the result of the <I>new-expression</I> and the address
returned by the allocation function shall be an integral multiple of
the most stringent alignment requirement (3.9&nbsp;



 <A HREF="basic.html#basic.types">basic.types</A>)
of any object type whose size is no greater than the size of the array
being created.

</BLOCKQUOTE>

<P>The intent of this wording is that the pointer returned by the
<I>new-expression</I> will be suitably aligned for any data type
that might be placed into the allocated storage (since the
allocation function is constrained to return a pointer to
maximally-aligned storage).  However, there is an implicit
assumption that each alignment requirement is an integral multiple
of all smaller alignment requirements.  While this is probably a
valid assumption for all real architectures, there's no reason
that the Standard should require it.</P>

<P>For example, assume that <TT>int</TT> has an alignment requirement
of 3 bytes and <TT>double</TT> has an alignment requirement of 4
bytes.  The current wording only requires that a buffer that is big
enough for an <TT>int</TT> or a <TT>double</TT> be aligned on a 4-byte
boundary (the more stringent requirement), but that would allow the
buffer to be allocated on an 8-byte boundary &mdash; which might
<I>not</I> be an acceptable location for an <TT>int</TT>.</P>

<P>
<U>Suggested resolution</U>: Change "of any object type" to
"of every object type."</P>

<P>A similar assumption can be found in
5.2.10&nbsp;



 <A HREF="expr.html#expr.reinterpret.cast">expr.reinterpret.cast</A> paragraph 7:</P>

<BLOCKQUOTE>

...converting an rvalue of type "pointer to <TT>T1</TT>" to the type
"pointer to <TT>T2</TT>" (where ... the alignment requirements of
<TT>T2</TT> are no stricter than those of <TT>T1</TT>) and back to its
original type yields the original pointer value...

</BLOCKQUOTE>

<P>
<U>Suggested resolution</U>: Change the wording to</P>

<BLOCKQUOTE>

...converting an rvalue of type "pointer to <TT>T1</TT>" to the type
"pointer to <TT>T2</TT>" (where ...  the alignment requirements of
<B><TT>T1</TT> are an integer multiple of those of <TT>T2</TT></B>)
and back to its original type yields the original pointer value...

</BLOCKQUOTE>

<P>The same change would also be needed in paragraph 9.</P>

<BR>
<BR>
<HR>
<A NAME="292"></A>
<H4>292.
  
Deallocation on exception in <TT>new</TT> before arguments evaluated
</H4>
<B>Section: </B>5.3.4&nbsp;



 <A HREF="expr.html#expr.new">expr.new</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Andrei Iltchenko
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>26 Jun 2001<BR>


<P>According to the C++ Standard section 5.3.4&nbsp;



 <A HREF="expr.html#expr.new">expr.new</A>
paragraph 21 it is unspecified whether the allocation function is called before
evaluating the constructor arguments or after evaluating the
constructor arguments but before entering the constructor.</P>

<P>On top of that paragraph 17 of the same section insists that</P>
<BLOCKQUOTE>
If any
part of the object initialization described above [Footnote: This may
include evaluating a new-initializer and/or calling a constructor.]
terminates by throwing an exception and a suitable deallocation
function is found, the deallocation function is called to free the
memory in which the object was being constructed... If no unambiguous
matching deallocation function can be found, propagating the exception
does not cause the object's memory to be freed...
</BLOCKQUOTE>

<P>Now suppose we have:</P>
<OL>
<LI>
An implementation that always evaluates the constructor arguments
first (for a new-expression that creates an object of a class type and
has a new-initializer) and calls the allocation function afterwards.
</LI>
<LI>
A class like this:
<PRE>
    struct  copy_throw  {
       copy_throw(const copy_throw&amp;)
       {   throw  std::logic_error("Cannot copy!");   }
       copy_throw(long, copy_throw)
       {   }
       copy_throw()
       {   }
    };
</PRE>
</LI>
<LI>
And a piece of code that looks like the one below:
<PRE>
    int  main()
    try  {
       copy_throw   an_object,     /* undefined behaviour */
          * a_pointer = ::new copy_throw(0, an_object);
       return  0;
    }
    catch(const std::logic_error&amp;)
    {   }
</PRE>
</LI>
</OL>
<P>Here the new-expression '<TT>::new copy_throw(0, an_object)</TT>' throws an
exception when evaluating the constructor's arguments and before the
allocation function is called. However, 5.3.4&nbsp;



 <A HREF="expr.html#expr.new">expr.new</A>
paragraph 17
prescribes that in such a case the implementation shall call the
deallocation function to free the memory in which the object was being
constructed, given that a matching deallocation function can be found.</P>

<P>So a call to the Standard library deallocation function '<TT>::operator
delete(void*)</TT>' shall be issued, but what argument is an implementation
supposed to supply to the deallocation function? As per
5.3.4&nbsp;



 <A HREF="expr.html#expr.new">expr.new</A> paragraph 17 - the argument is the address
of the memory in
which the object was being constructed. Given that no memory has yet
been allocated for the object, this will qualify as using an invalid
pointer value, which is undefined behaviour by virtue of
3.7.3.2&nbsp;



 <A HREF="basic.html#basic.stc.dynamic.deallocation">basic.stc.dynamic.deallocation</A> paragraph 4.</P>

<P>
<B>Suggested resolution:</B>
</P>

<P>Change the first sentence of 5.3.4&nbsp;



 <A HREF="expr.html#expr.new">expr.new</A> paragraph 17
to read:</P>
<BLOCKQUOTE>
If the memory for the object being created has already been
successfully allocated and any part of the object initialization
described above...
</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="473"></A>
<H4>473.
  
Block-scope declarations of allocator functions
</H4>
<B>Section: </B>5.3.4&nbsp;



 <A HREF="expr.html#expr.new">expr.new</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>John Spicer
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>12 Jul 2004<BR>


<P>Looking up <TT>operator new</TT> in a <I>new-expression</I>
uses a different mechanism from ordinary lookup.  According to
5.3.4&nbsp;



 <A HREF="expr.html#expr.new">expr.new</A> paragraph 9,</P>

<BLOCKQUOTE>
If the <I>new-expression</I> begins with a unary <TT>::</TT>
operator, the allocation function's name is looked up in the
global scope. Otherwise, if the allocated type is a class type
<TT>T</TT> or array thereof, the allocation function's name is
looked up in the scope of <TT>T</TT>. If this lookup fails to
find the name, or if the allocated type is not a class type, the
allocation function's name is looked up in the global scope.
</BLOCKQUOTE>

<P>Note in particular that the scope in which the
<I>new-expression</I> occurs is not considered.  For example,</P>

<PRE>
    void f() {
        void* operator new(std::size_t, void*);
        int* i = new int;    // okay?
    }
</PRE>

<P>In this example, the implicit reference to <TT>operator
new(std::size_t)</TT> finds the global declaration, even though
the block-scope declaration of <tt>operator new</tt> with a
different signature would hide it from an ordinary reference.</P>

<P>This seems strange; either the block-scope declaration should
be ill-formed or it should be found by the lookup.</P>

<P>
<B>Notes from October 2004 meeting:</B>
</P>

<P>The CWG agreed that the block-scope declaration should not be
found by the lookup in a <I>new-expression</I>.  It would,
however, be found by ordinary lookup if the allocation function
were invoked explicitly.</P>

<BR>
<BR>
<HR>
<A NAME="476"></A>
<H4>476.
  
Determining the buffer size for placement new
</H4>
<B>Section: </B>5.3.4&nbsp;



 <A HREF="expr.html#expr.new">expr.new</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Ben Hutchings
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>14 Sep 2004<BR>


<P>(See also <A HREF="
     cwg_closed.html#256">issue 256</A>.)</P>

<P>An implementation may have an unspecified amount of array
allocation overhead (5.3.4&nbsp;



 <A HREF="expr.html#expr.new">expr.new</A> paragraph 10),
so that evaluation of a <I>new-expression</I> in which the
<I>new-type-id</I> is <TT>T[n]</TT> involves a request for more
than <TT>n * sizeof(T)</TT> bytes of storage through the relevant
<TT>operator new[]</TT> function.</P>

<P>The placement <TT>operator new[]</TT> function does not and
cannot check whether the requested size is less than or equal to
the size of the provided region of memory (18.4.1.3&nbsp;



 <A HREF="lib-support.html#lib.new.delete.placement">lib.new.delete.placement</A> paragraphs 5-6).  A program using placement
array new must calculate what the requested size will be in
advance.</P>

<P>Therefore any program using placement array new must take into
account the implementation's array allocation overhead, which
cannot be obtained or calculated by any portable means.</P>

<P>
<B>Notes from the April, 2005 meeting:</B>
</P>

<P>While the CWG agreed that there is no portable means to
accomplish this task in the current language, they felt that a
paper is needed to analyze the numerous mechanisms that might
address the problem and advance a specific proposal.  There is
no volunteer to write such a paper at this time.</P>

<BR>
<BR>
<HR>
<A NAME="196"></A>
<H4>196.
  
Arguments to deallocation functions </H4>
<B>Section: </B>5.3.5&nbsp;



 <A HREF="expr.html#expr.delete">expr.delete</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Matt Austern
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>20 Jan 2000<BR>





<P>5.3.4&nbsp;



 <A HREF="expr.html#expr.new">expr.new</A>
 paragraph 10 says that
the result of an array allocation function and the value of the array
<I>new-expression</I> from which it was invoked may be different,
allowing for space preceding the array to be used for implementation
purposes such as saving the number of elements in the array.  However,
there is no corresponding description of the relationship between the
operand of an array <I>delete-expression</I> and the argument passed
to its deallocation function.</P>

<P>3.7.3.2&nbsp;



 <A HREF="basic.html#basic.stc.dynamic.deallocation">basic.stc.dynamic.deallocation</A>

paragraph 3 does state that</P>

<BLOCKQUOTE>
the value supplied to <TT>operator delete[](void*)</TT> in the
standard library shall be one of the values returned by a previous
invocation of either <TT>operator new[](std::size_t)</TT> or
<TT>operator new[](std::size_t, const std::nothrow_t&amp;)</TT> in the
standard library.
</BLOCKQUOTE>

<P>This statement might be read as requiring an implementation, when
processing an array <I>delete-expression</I> and calling the
deallocation function, to perform the inverse of the calculation
applied to the result of the allocation function to produce the value
of the <I>new-expression</I>.
(5.3.5&nbsp;



 <A HREF="expr.html#expr.delete">expr.delete</A>
 paragraph 2 requires
that the operand of an array <I>delete-expression</I> "be the pointer
value which resulted from a previous array <I>new-expression</I>.")
However, it is not completely clear whether the "shall" expresses an
implementation requirement or a program requirement (or both).
Furthermore, there is no direct statement about user-defined
deallocation functions.</P>

<P>
<B>Suggested resolution:</B> A note should be added to
5.3.5&nbsp;



 <A HREF="expr.html#expr.delete">expr.delete</A>
 to clarify that any
offset added in an array <I>new-expression</I> must be subtracted in
the array <I>delete-expression</I>.</P>
<BR>
<BR>
<HR>
<A NAME="265"></A>
<H4>265.
  
Destructors, exceptions, and deallocation
</H4>
<B>Section: </B>5.3.5&nbsp;



 <A HREF="expr.html#expr.delete">expr.delete</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Mike Miller
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>21 Nov 2000<BR>




<P>Does the Standard require that the deallocation function will
be called if the destructor throws an exception?  For example,</P>

<PRE>
    struct S {
        ~S() { throw 0; }
    };
    void f() {
        try {
            delete new S;
        }
        catch(...) { }
    }
</PRE>

<P>The question is whether the memory for the S object will be freed
or not.  It doesn't appear that the Standard answers the question,
although most people would probably assume that it will be freed.</P>

<P>
<B>Notes from 04/01 meeting:</B>
</P>

<P>There is a widespread feeling that it is a poor programming
practice to allow destructors to terminate with an exception
(see <A HREF="
     cwg_active.html#219">issue 219</A>).  This question is
thus viewed as a tradeoff between efficiency and supporting "bad
code."  It was observed that there is no way in the current
language to protect against a throwing destructor, since the
throw might come from a virtual override.</P>

<P>It was suggested that the resolution to the issue might be
to make it implementation-defined whether the storage is freed
if the destructor throws.  Others suggested that the Standard
should require that the storage be freed, with the understanding
that implementations might have a flag to allow optimizing away
the overhead.  Still others thought that both this issue and
<A HREF="
     cwg_active.html#219">issue 219</A> should be resolved by
forbidding a destructor to exit via an exception.  No consensus
was reached.</P>

<BR>
<BR>
<HR>
<A NAME="288"></A>
<H4>288.
  
Misuse of "static type" in describing pointers
</H4>
<B>Section: </B>5.3.5&nbsp;



 <A HREF="expr.html#expr.delete">expr.delete</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>James Kuyper
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>19 May 2001<BR>


<P>For delete expressions, 5.3.5&nbsp;



 <A HREF="expr.html#expr.delete">expr.delete</A> paragraph 1
says</P>

<BLOCKQUOTE>
The operand shall have a pointer type, or a class type having
a single conversion function to a pointer type.
</BLOCKQUOTE>

<P>However,
paragraph 3 of that same section says:</P>

<BLOCKQUOTE>
if the static type of the
operand is different from its dynamic type, the static type shall be a
base class of the operand's dynamic type and the static type shall
have a virtual destructor or the behavior is undefined.
</BLOCKQUOTE>

<P>Since the operand must be of pointer type, its static type is
necessarily the same as its dynamic type. That clause is clearly
referring to the object being pointed at, and not to the pointer operand
itself.</P>

<P>Correcting the wording gets a little complicated, because dynamic
and static types are attributes of expressions, not objects, and
there's no sub-expression of a <I>delete-expression</I> which has the
relevant types.</P>

<P>
<B>Suggested resolution:</B>
</P>

<BLOCKQUOTE>
then there is a static type and a dynamic type that the hypothetical
expression <TT>(*</TT> <I>const-expression</I><TT>)</TT> would
have. If that static type is different from that dynamic type, then
that static type shall be a base class of that dynamic type, and that
static type shall have a virtual destructor, or the behavior is
undefined.
</BLOCKQUOTE>

<P>There's precedent for such use of hypothetical constructs: see
5.10&nbsp;



 <A HREF="expr.html#expr.eq">expr.eq</A> paragraph 2, and 8.1&nbsp;



 <A HREF="decl.html#dcl.name">dcl.name</A>
paragraph 1.</P>

<P>10.3&nbsp;



 <A HREF="derived.html#class.virtual">class.virtual</A> paragraph 3 has a similar problem. It
refers to</P>

<BLOCKQUOTE>
 the type of the pointer or reference denoting the object
(the static type).
</BLOCKQUOTE>

<P>The type of the pointer is different from the type of the
reference, both of which are different from the static type of
'*pointer', which is what I think was actually intended. Paragraph 6
contains the exact same wording, in need of the same correction. In
this case, perhaps replacing "pointer or reference" with "expression"
would be the best fix. In order for this fix to be sufficient,
<TT>pointer-&gt;member</TT> must be considered equivalent to
<TT>(*pointer).member</TT>, in which case the "expression" referred to
would be <TT>(*pointer)</TT>.</P>

12.5&nbsp;



 <A HREF="special.html#class.free">class.free</A> paragraph 4 says that

<BLOCKQUOTE>
if a <I>delete-expression</I> is used to deallocate a class object
whose static type has...
</BLOCKQUOTE>

<P>This should be changed to</P>

<BLOCKQUOTE>
if a <I>delete-expression</I> is used to deallocate a class object
through a pointer expression whose dereferenced static type would
have...
</BLOCKQUOTE>

<P>The same problem occurs later,
when it says that the</P>

<BLOCKQUOTE>
static and dynamic types of the object shall be
identical
</BLOCKQUOTE>

<P>In this case you could replace "object" with "dereferenced
pointer expression".</P>

<P>Footnote 104 says that</P>

<BLOCKQUOTE>
5.3.5&nbsp;



 <A HREF="expr.html#expr.delete">expr.delete</A> requires that ... the static type of the
<I>delete-expression</I>'s operand be the same as its dynamic type.
</BLOCKQUOTE>

<P>This
would need to be changed to</P>

<BLOCKQUOTE>
the <I>delete-expression</I>'s dereferenced
operand
</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="242"></A>
<H4>242.
  
Interpretation of old-style casts
</H4>
<B>Section: </B>5.4&nbsp;



 <A HREF="expr.html#expr.cast">expr.cast</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Mike Miller
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>30 Aug 2000<BR>




<P>The meaning of an old-style cast is described in terms of
<TT>const_cast</TT>, <TT>static_cast</TT>, and
<TT>reinterpret_cast</TT> in 5.4&nbsp;



 <A HREF="expr.html#expr.cast">expr.cast</A> paragraph 5.
Ignoring <TT>const_cast</TT> for the moment, it basically says that if
the conversion performed by a given old-style cast is one of those
performed by <TT>static_cast</TT>, the conversion is interpreted as if
it were a <TT>static_cast</TT>; otherwise, it's interpreted as if it
were a <TT>reinterpret_cast</TT>, if possible.  The following example
is given in illustration:</P>

<PRE>
    struct A {};
    struct I1 : A {};
    struct I2 : A {};
    struct D : I1, I2 {};
    A *foo( D *p ) {
	return (A*)( p ); // ill-formed static_cast interpretation
    }
</PRE>

<P>The obvious intent here is that a derived-to-base pointer
conversion is one of the conversions that can be performed using
<TT>static_cast</TT>, so <TT>(A*)(p)</TT> is equivalent to
<TT>static_cast&lt;A*&gt;(p)</TT>, which is ill-formed because of the
ambiguity.</P>

<P>Unfortunately, the description of <TT>static_cast</TT> in
5.2.9&nbsp;



 <A HREF="expr.html#expr.static.cast">expr.static.cast</A> does NOT support this interpretation.
The problem is in the way 5.2.9&nbsp;



 <A HREF="expr.html#expr.static.cast">expr.static.cast</A> lists the
kinds of casts that can be performed using <TT>static_cast</TT>.
Rather than saying something like "All standard conversions can be
performed using <TT>static_cast</TT>," it says</P>

<BLOCKQUOTE>
An expression e can be explicitly converted to a type <TT>T</TT> using
a <TT>static_cast</TT> of the form <TT>static_cast&lt;T&gt;(e)</TT> if
the declaration "<TT>T t(e);</TT>" is well-formed, for some invented
temporary variable <TT>t</TT>.
</BLOCKQUOTE>

<P>Given the declarations above, the hypothetical declaration</P>

<PRE>
    A* t(p);
</PRE>

<P>is NOT well-formed, because of the ambiguity.  Therefore the old-style
cast <TT>(A*)(p)</TT> is NOT one of the conversions that can be performed
using <TT>static_cast</TT>, and <TT>(A*)(p)</TT> is equivalent to
<TT>reinterpret_cast&lt;A*&gt;(p)</TT>, which is well-formed under
5.2.10&nbsp;



 <A HREF="expr.html#expr.reinterpret.cast">expr.reinterpret.cast</A> paragraph 7.</P>

<P>Other situations besides ambiguity which might raise similar
questions include access violations, casting from virtual base
to derived, and casting pointers-to-members when virtual
inheritance is involved.</P>

<BR>
<BR>
<HR>
<A NAME="236"></A>
<H4>236.
  
Explicit temporaries and integral constant expressions
</H4>
<B>Section: </B>5.19&nbsp;



 <A HREF="expr.html#expr.const">expr.const</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Mike Miller
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>19 Jul 2000<BR>




<P>Does an explicit temporary of an integral type qualify as an
integral constant expression?  For instance,</P>

<PRE>
    void* p = int();    // well-formed?
</PRE>

<P>It would appear to be, since <TT>int()</TT> is an explicit type
conversion according to 5.2.3&nbsp;



 <A HREF="expr.html#expr.type.conv">expr.type.conv</A> (at least, it's
described in a section entitled "Explicit type conversion") and type
conversions to integral types are permitted in integral constant
expressions (5.19&nbsp;



 <A HREF="expr.html#expr.const">expr.const</A>).  However, this reasoning is
somewhat tenuous, and some at least have argued otherwise.</P>

<BR>
<BR>
<HR>
<A NAME="339"></A>
<H4>339.
  
Overload resolution in operand of <TT>sizeof</TT> in constant expression
</H4>
<B>Section: </B>5.19&nbsp;



 <A HREF="expr.html#expr.const">expr.const</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Steve Adamczyk
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>11 Mar 2002<BR>


<P>I've seen some pieces of code recently that put complex expressions
involving overload resolution inside <TT>sizeof</TT> operations in constant
expressions in templates.</P>

<P>5.19&nbsp;



 <A HREF="expr.html#expr.const">expr.const</A> paragraph 1 implies that some kinds of
nonconstant expressions are allowed inside a <TT>sizeof</TT> in
a constant expression, but it's not clear that this was intended
to extend all the way to things like overload resolution.
Allowing such things has some hidden
costs.  For example, name mangling has to be able to represent all
operators, including calls, and not just the operators that can appear
in constant expressions.</P>

<PRE>
  template &lt;int I&gt; struct A {};

  char xxx(int);
  char xxx(float);

  template &lt;class T&gt; A&lt;sizeof(xxx((T)0))&gt; f(T){}

  int main()
  {
    f(1);
  }
</PRE>

<P>If complex expressions are
indeed allowed, it should be because of an explicit
committee decision rather than because of some looseness in this
section of the standard.</P>

<P>
<B>Notes from the 4/02 meeting:</B>
</P>

<P>Any argument for restricting such expressions must involve a
cost/benefit ratio: a restriction would be palatable only if it
causes minimum hardship for users and allows a substantial
reduction in implementation cost. If we propose a restriction,
it must be one that library writers can live with.</P>

<P>Lots of these cases fail with current compilers, so there can't
be a lot of existing code using them.  We plan to find out what
cases there are in libraries like Loki and Boost.</P>

<P>We noted that in many cases one can move the code into a class
to get the same result.  The implementation problem comes up
when the expression-in-sizeof is in a template deduction
context or part of a template signature.  The problem cases
are ones where an error causes deduction to fail, as opposed
to contexts where an error causes a diagnostic.  The latter
contexts are easier to handle; however, there are situations
where "fail deduction" may be the desired behavior.</P>

<P>
<B>Notes from the April 2003 meeting:</B>
</P>

<P>Here is a better example:</P>
<PRE>
  extern "C" int printf(const char *, ...);
  char f(int);
  int f(...);
  // Approach 1 -- overload resolution in template class
  // No problem
  template &lt;class T&gt; struct conv_int {
    static const bool value = (sizeof(f(T())) == 1);
  };
  // Approach 2 -- overload resolution in type deduction
  // Difficult
  template &lt;int I&gt; struct A {
    static const int value = I;
  };
  template &lt;class T&gt; bool conv_int2(A&lt;sizeof(f(T()))&gt; p) {
    return p.value == 1;
  }
  int main() {
    printf("short: %d\n", conv_int&lt;short&gt;::value);
    printf("int *: %d\n", conv_int&lt;int *&gt;::value);
    printf("short: %d\n", conv_int2&lt;short&gt;());
    printf("int *: %d\n", conv_int2&lt;int *&gt;());
  }
</PRE>

<P>The core working group liked the idea of a restriction that
says that expressions inside sizeof in template signature contexts
must be otherwise valid as nontype template argument expressions
(i.e., integer operations only, limited casts).  This of
course is subject to whether users can live with that restriction.
This topic was brought up in full committee, but there was
limited feedback from other groups.</P>

<P>It was also noted that if typeof (whatever it is called)
is added, there may be a similar issue there.</P>

<P>
<B>Note (March, 2005):</B>
</P>



<P>
<U>Dave Abrahams</U> (quoting a Usenet posting by Vladimir Marko):
The decltype and auto proposal (revision 3: N1607) presents</P>

<PRE>
    template &lt;class T,class U&gt;
    decltype((*(T*)0)+(*(U*)0)) add(const T&amp; t,const U&amp; u);
</PRE>

<P>as a valid declaration (if the proposal is accepted). If [the
restrictions in the April, 2003 note] really applied to decltype, the
declaration above would be invalid. AFAICT every non-trivial use of
decltype in a template function declaration would be invalid.  And for
me this would render my favorite proposal useless.</P>

<P>I would propose to allow any kind of expression inside <TT>sizeof</TT> (and
<TT>decltype</TT>) and explicitly add <TT>sizeof</TT> (and
<TT>decltype</TT>) expressions
involving template-parameters to non-deduced contexts (add a bullet to
14.8.2.4&nbsp;



 <A HREF="template.html#temp.deduct.partial">temp.deduct.partial</A> paragraph 4).
</P>

<P>
<U>Jaakko Jarvi</U>: Just reinforcing that this is important and
hope for insights. The topic is discussed a bit on page 10 of the
latest revision of the proposal (N1705).  Here's a quote from the
proposal:
</P>

<BLOCKQUOTE>

However, it is crucial that no restrictions are placed on what kinds
of expressions are allowed inside <B><I>decltype</I></B>, and
therefore also inside <B><I>sizeof</I></B>. We suggest that issue 339
is resolved to require the compiler to fail deduction (apply the
SFINAE principle), and not produce an error, for as large set of
invalid expressions in operands of <B><I>sizeof</I></B> or
<B><I>decltype</I></B> as is possible to comfortably implement. We wish
that implementors aid in classifying the kinds of expressions that
should produce errors, and the kinds that should lead to failure of
deduction.


</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="378"></A>
<H4>378.
  
Wording that says temporaries are declared
</H4>
<B>Section: </B>6.6&nbsp;



 <A HREF="stmt.html#stmt.jump">stmt.jump</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Gennaro Prota
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>07 September 2002<BR>


<P>Paragraph 6.6&nbsp;



 <A HREF="stmt.html#stmt.jump">stmt.jump</A> paragraph 2 of the standard says:</P>
<BLOCKQUOTE>
On exit from a scope (however accomplished), destructors
(12.4&nbsp;



 <A HREF="special.html#class.dtor">class.dtor</A>)
are called for all constructed objects with automatic storage
duration (3.7.2&nbsp;



 <A HREF="basic.html#basic.stc.auto">basic.stc.auto</A>)
(named objects or temporaries) that are declared
in that scope.
</BLOCKQUOTE>

<P>It refers to objects "that are declared" but the text in parenthesis
also mentions temporaries, which cannot be declared. I think that text
should be removed.</P>

<P>This is related to <A HREF="
     cwg_active.html#276">issue 276</A>.</P>

<BR>
<BR>
<HR>
<A NAME="157"></A>
<H4>157.
  
Omitted typedef declarator
</H4>
<B>Section: </B>7&nbsp;



 <A HREF="dcl.html#dcl.dcl">dcl.dcl</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Daveed Vandevoorde
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>19 Aug 1999<BR>





<P>7&nbsp;



 <A HREF="dcl.html#dcl.dcl">dcl.dcl</A>
 paragraph 3 reads,</P>

<BLOCKQUOTE>
In a <I>simple-declaration</I>, the optional
<I>init-declarator-list</I> can be omitted only when... the
<I>decl-specifier-seq</I> contains either a <I>class-specifier</I>,
an <I>elaborated-type-specifier</I> with a <I>class-key</I>
(9.1&nbsp;



 <A HREF="class.html#class.name">class.name</A>
), or an
<I>enum-specifier</I>.  In these cases and whenever a
<I>class-specifier</I> or <I>enum-specifier</I> is present in the
<I>decl-specifier-seq</I>, the identifiers in those specifiers are
among the names being declared by the declaration...  In such cases,
and except for the declaration of an unnamed bit-field
(9.6&nbsp;



 <A HREF="class.html#class.bit">class.bit</A>
), the
<I>decl-specifier-seq</I> shall introduce one or more names into the
program, or shall redeclare a name introduced by a previous
declaration.  [<I>Example:</I>

<PRE>
    enum { };           // <I>ill-formed</I>
    typedef class { };  // <I>ill-formed</I>
</PRE>

<I>&mdash;end example</I>]
</BLOCKQUOTE>

In the absence of any explicit restrictions in
7.1.3&nbsp;



 <A HREF="dcl.html#dcl.typedef">dcl.typedef</A>
, this paragraph appears
to allow declarations like the following:

<PRE>
    typedef struct S { };    // no declarator
    typedef enum { e1 };     // no declarator
</PRE>

In fact, the final example in
7&nbsp;



 <A HREF="dcl.html#dcl.dcl">dcl.dcl</A>
 paragraph 3 would seem to
indicate that this is intentional: since it is illustrating the
requirement that the <I>decl-specifier-seq</I> must introduce a name
in declarations in which the <I>init-declarator-list</I> is omitted,
presumably the addition of a class name would have made the example
well-formed.

<P>On the other hand, there is no good reason to allow such
declarations; the only reasonable scenario in which they might occur
is a mistake on the programmer's part, and it would be a service to
the programmer to require that such errors be diagnosed.</P>
<BR>
<BR>
<HR>
<A NAME="498"></A>
<H4>498.
  
Storage class specifiers in definitions of class members
</H4>
<B>Section: </B>7.1.1&nbsp;



 <A HREF="dcl.html#dcl.stc">dcl.stc</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Matt Austern
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>13 Jan 2005<BR>




<P>Suppose we've got this class definition:</P>

<PRE>
    struct X {
       void f();
       static int n;
    };
</PRE>

<P>I think I can deduce from the existing standard that the following 
member definitions are ill-formed:</P>

<PRE>
    static void X::f() { }
    static int X::n;
</PRE>

<P>To come to that conclusion, however, I have to put together several
things in different parts of the standard.  I would have expected to
find an explicit statement of this somewhere; in particular, I would
have expected to find it in 7.1.1&nbsp;



 <A HREF="dcl.html#dcl.stc">dcl.stc</A>.  I don't
see it there, or anywhere.</P>

<P>
<U>Gabriel Dos Reis</U>: Or in 3.5&nbsp;



 <A HREF="basic.html#basic.link">basic.link</A> which is
about linkage.  I would have expected that paragraph to say that that
members of class types have external linkage when the enclosing class
has an external linkage.  Otherwise 3.5&nbsp;



 <A HREF="basic.html#basic.link">basic.link</A>
paragraph 8:
</P>

<BLOCKQUOTE>

Names not covered by these rules have no linkage.

</BLOCKQUOTE>

<P>might imply that such members do not have linkage.</P>

<P>
<B>Notes from the April, 2005 meeting:</B>
</P>

<P>The question about the linkage of class members is already
covered by 3.5&nbsp;



 <A HREF="basic.html#basic.link">basic.link</A> paragraph 5.</P>

<BR>
<BR>
<HR>
<A NAME="539"></A>
<H4>539.
  
Constraints on <I>type-specifier-seq</I>
</H4>
<B>Section: </B>7.1.5&nbsp;



 <A HREF="dcl.html#dcl.type">dcl.type</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Mike Miller
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>5 October 2005<BR>


<P>The constraints on <I>type-specifier</I>s given in
7.1.5&nbsp;



 <A HREF="dcl.html#dcl.type">dcl.type</A> paragraphs 2 and 3 (at most one
<I>type-specifier</I> except as specified, at least one
<I>type-specifier</I>, no redundant cv-qualifiers) are couched in
terms of <I>decl-specifier-seq</I>s and <I>declaration</I>s.  However,
they should also apply to constructs that are not syntatically
<I>declaration</I>s and that are defined to use
<I>type-specifier-seq</I>s, including 5.3.4&nbsp;



 <A HREF="expr.html#expr.new">expr.new</A>,
6.6&nbsp;



 <A HREF="stmt.html#stmt.jump">stmt.jump</A>, 8.1&nbsp;



 <A HREF="decl.html#dcl.name">dcl.name</A>, and
12.3.2&nbsp;



 <A HREF="special.html#class.conv.fct">class.conv.fct</A>.</P>

<BR>
<BR>
<HR>
<A NAME="144"></A>
<H4>144.
  
Position of <TT>friend</TT> specifier
</H4>
<B>Section: </B>7.1.5.3&nbsp;



 <A HREF="dcl.html#dcl.type.elab">dcl.type.elab</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Daveed Vandevoorde
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>22 Jul 1999<BR>





<P>7.1.5.3&nbsp;



 <A HREF="dcl.html#dcl.type.elab">dcl.type.elab</A>
 paragraph 1 seems to
impose an ordering constraint on the elements of friend class
declarations.  However, the general rule is that declaration
specifiers can appear in any order.  Should</P>

<PRE>
    class C friend;
</PRE>

be well-formed?
<BR>
<BR>
<HR>
<A NAME="540"></A>
<H4>540.
  
Propagation of cv-qualifiers in reference-to-reference collapse
</H4>
<B>Section: </B>7.3.1&nbsp;



 <A HREF="dcl.html#namespace.def">namespace.def</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Russell Yanofsky
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>24 September 2005<BR>




<P>The resolution of <A HREF="
     cwg_defects.html#106">issue 106</A> specifies
that an attempt to create a type &ldquo;reference to <I>cv1</I>
<TT>T</TT>,&rdquo; where <TT>T</TT> is a typedef or template parameter
of the type &ldquo;reference to <I>cv2</I> <TT>S</TT>,&rdquo; actually
creates the type &ldquo;reference to <I>cv12</I> <TT>S</TT>,&rdquo;
where <I>cv12</I> is the union of the two sets of cv-qualifiers.</P>

<P>One objection that has been raised to this resolution is that it
is inconsistent with the treatment of cv-qualification and references
specified in 8.3.2&nbsp;



 <A HREF="decl.html#dcl.ref">dcl.ref</A> paragraph 1, which says
that cv-qualifiers applied to a typedef or template argument that is
a reference type are ignored.  For example:</P>

<PRE>
    typedef int&amp; intref;
    const intref r1;       //<SPAN STYLE="font-family:Times"><I> reference to int</I></SPAN>
    const intref&amp; r2;      //<SPAN STYLE="font-family:Times"><I> reference to const int</I></SPAN>
</PRE>

<P>In fact, however, these two declarations are quite different. In the
declaration of <TT>r1</TT>, <TT>const</TT> applies to a
&ldquo;top-level&rdquo; reference, while in the declaration of <TT>t2</TT>,
it occurs under a reference.  In general, cv-qualifiers that appear under
a reference are preserved, even if the type appears in a context in which
top-level cv-qualification is removed, for example, in determining the
type of a function from parameter types (8.3.5&nbsp;



 <A HREF="decl.html#dcl.fct">dcl.fct</A>
paragraph 3) and in template argument deduction
(14.8.2.1&nbsp;



 <A HREF="template.html#temp.deduct.call">temp.deduct.call</A> paragraph 2).</P>

<P>Another objection to the resolution is that type composition gives
different results in a single declaration than it does when separated
into two declarations.  For example:</P>

<PRE>
    template &lt;class T&gt;
    struct X {
       typedef T const T_const;
       typedef T_const&amp; type1;
       typedef T const&amp; type2;
    };

    X&lt;int&amp;&gt;::type1 t1;    // int&amp;
    X&lt;int&amp;&gt;::type2 t2;    // int const&amp;
</PRE>

<P>The initial motivation for the propagation of cv-qualification
during reference-to-reference collapse was prevent inadvertent
loss of cv-qualifiers in contexts in which it could make a
difference.  For example, if the resolution were changed to discard,
rather than propagate, embedded cv-qualification, overload
resolution could surprisingly select a non-const version of a member
function:</P>

<PRE>
   struct X {
       void g();
       void g() const;
   };

   template &lt;typename T&gt; struct S {
       static void f(const T&amp; t) {
           t.g();    //<SPAN STYLE="font-family:Times"><I> const or non-const???</I></SPAN>
       }
   };

   X x;

   void q() {
       S&lt;X&gt;::f(x);    //<SPAN STYLE="font-family:Times"><I> calls </I></SPAN>X::g() const
       S&lt;X&amp;&gt;::f(x);   //<SPAN STYLE="font-family:Times"><I> calls </I></SPAN>X::g()
   }
</PRE>

<P>Another potentially-surprising outcome of dropping embedded
cv-qualifiers would be:</P>

<PRE>
   template &lt;typename T&gt; struct A {
       void f(T&amp;);          //<SPAN STYLE="font-family:Times"><I> mutating version</I></SPAN>
       void f(const T&amp;);    //<SPAN STYLE="font-family:Times"><I> non-mutating version</I></SPAN>
   };

   A&lt;int&amp;&gt; ai;    //<SPAN STYLE="font-family:Times"><I> Ill-formed: </I></SPAN>A&lt;int&amp;&gt;<SPAN STYLE="font-family:Times"><I> declares</I></SPAN> f(int&amp;)<SPAN STYLE="font-family:Times"><I> twice</I></SPAN>

</PRE>

<P>On the other hand, those who would like to see the resolution
changed to discard embedded cv-qualifiers observe that these examples
are too simple to be representative of real-world code.  In general,
it is unrealistic to expect that a template written with non-reference
type parameters in mind will automatically work correctly with
reference type parameters as a result of applying the issue 106
resolution.  Instead, template metaprogramming allows the template
author to choose explicitly whether cv-qualifiers are propagated or
dropped, according to the intended use of the template, and it is more
important to respect the reasonable intuition that a declaration
involving a template parameter will not change the type that the
parameter represents.</P>

<P>As a sample of real-world code, <TT>tr1::tuple</TT> was examined.
In both cases &mdash; the current resolution of issue 106 and one in
which embedded cv-qualifiers were dropped &mdash; some metaprogramming
was required to implement the intended interface, although the version
reflecting the revised resolution was somewhat simpler.</P>

<P>
<B>Notes from the October, 2005 meeting:</B>
</P>

<P>The consensus of the CWG was that the resolution of
<A HREF="
     cwg_defects.html#106">issue 106</A> should be revised not to
propagate embedded cv-qualification.</P>

<BR>
<BR>
<HR>
<A NAME="36"></A>
<H4>36.
  
<I>using-declaration</I>s in multiple-declaration contexts
</H4>
<B>Section: </B>7.3.3&nbsp;



 <A HREF="dcl.html#namespace.udecl">namespace.udecl</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Andrew Koenig
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>20 Aug 1998<BR>





<P>Section 7.3.3&nbsp;



 <A HREF="dcl.html#namespace.udecl">namespace.udecl</A>
 paragraph 8 says:</P>
<BLOCKQUOTE>A <I>using-declaration</I> is a declaration and can therefore be used
repeatedly where (and only where) multiple declarations are allowed.</BLOCKQUOTE>
It contains the following example:
<PRE>
    namespace A {
            int i;
    }
    
    namespace A1 {
            using A::i;
            using A::i;             // OK: double declaration
    }
    
    void f()
    {
            using A::i;
            using A::i;             // error: double declaration
    }
</PRE>
However, if "<TT>using A::i;</TT>" is really a declaration, and not a definition, it is far from clear that repeating it should be an error in either context.
Consider:
<PRE>
    namespace A {
            int i;
            void g();
    }
    
    void f() {
            using A::g;
            using A::g;
    }
</PRE>
Surely the definition of f should be analogous to
<PRE>
    void f() {
            void g();
            void g();
    }
</PRE>
which is well-formed because "<TT>void g();</TT>" is a declaration and
not a definition.

<P>Indeed, if the double using-declaration for <TT>A::i</TT> is prohibited
in <TT>f</TT>, why should it be allowed in namespace <TT>A1</TT>?</P>

<P>
<B>Proposed Resolution (04/99):</B>

Change the comment "<TT>// error: double declaration</TT>" to
"<TT>// OK: double declaration</TT>".

(This should be reviewed against existing practice.)</P>

<P>
<B>Notes from 04/00 meeting:</B>
</P>

<P>The core language working group was unable to come to consensus
over what kind of declaration a <I>using-declaration</I> should
emulate.  In a straw poll, 7 members favored allowing
<I>using-declaration</I>s wherever a non-definition declaration could
appear, while 4 preferred to allow multiple <I>using-declaration</I>s
only in namespace scope (the rationale being that the permission for
multiple <I>using-declaration</I>s is primarily to support its use in
multiple header files, which are seldom included anywhere other than
namespace scope).  John Spicer pointed out that <TT>friend</TT>
declarations can appear multiple times in class scope and asked if
<I>using-declaration</I>s would have the same property under the "like
a declaration" resolution.</P>

<P>As a result of the lack of agreement, the issue was returned to
"open" status.  </P>

<P>See also issues
<A HREF="
     cwg_defects.html#56">56</A>, <A HREF="
     cwg_defects.html#85">85</A>,
and <A HREF="
     cwg_active.html#138">138</A>..</P>

<P>
<B>Additional notes (January, 2005):</B>
</P>

<P>Some related issues have been raised concerning the following
example (modified from a C++ validation suite test):</P>

<PRE>
    struct A
    {
        int i;
        static int j;
    };

    struct B : A { };
    struct C : A { };

    struct D : virtual B, virtual C
    {
        using B::i;
        using C::i;
        using B::j;
        using C::j;
    };
</PRE>

<P>Currently, it appears that the <I>using-declaration</I>s of
<TT>i</TT> are ill-formed, on the basis of 7.3.3&nbsp;



 <A HREF="dcl.html#namespace.udecl">namespace.udecl</A> paragraph 10:</P>

<BLOCKQUOTE>

Since a <I>using-declaration</I> is a declaration, the
restrictions on declarations of the same name in the same
declarative region (3.3&nbsp;



 <A HREF="basic.html#basic.scope">basic.scope</A>) also apply to
<I>using-declaration</I>s.

</BLOCKQUOTE>

<P>Because the <I>using-declaration</I>s of <TT>i</TT> refer to
different objects, declaring them in the same scope is not
permitted under 3.3&nbsp;



 <A HREF="basic.html#basic.scope">basic.scope</A>.  It might, however,
be preferable to treat this case as many other ambiguities are:
allow the declaration but make the program ill-formed if a name
reference resolves to the ambiguous declarations.</P>

<P>The status of the <I>using-declaration</I>s of <TT>j</TT>,
however, is less clear.  They both declare the same entity and
thus do not violate the rules of 3.3&nbsp;



 <A HREF="basic.html#basic.scope">basic.scope</A>.
This might (or might not) violate the restrictions of
9.2&nbsp;



 <A HREF="class.html#class.mem">class.mem</A> paragraph 1:</P>

<BLOCKQUOTE>

Except when used to declare friends (11.4&nbsp;



 <A HREF="access.html#class.friend">class.friend</A>)
or to introduce the name of a member of a base class into a
derived class (7.3.3&nbsp;



 <A HREF="dcl.html#namespace.udecl">namespace.udecl</A>, 11.3&nbsp;



 <A HREF="access.html#class.access.dcl">class.access.dcl</A>), <I>member-declaration</I>s declare members of the
class, and each such member-declaration shall declare at least
one member name of the class. A member shall not be declared
twice in the <I>member-specification</I>, except that a nested
class or member class template can be declared and then later
defined.

</BLOCKQUOTE>

<P>Do the <I>using-declaration</I>s of <TT>j</TT> repeatedly
declare the same member?  Or is the preceding sentence an
indication that a <I>using-declaration</I> is not a declaration
of a member?</P>

<BR>
<BR>
<HR>
<A NAME="386"></A>
<H4>386.
  
Friend declaration of name brought in by using-declaration
</H4>
<B>Section: </B>7.3.3&nbsp;



 <A HREF="dcl.html#namespace.udecl">namespace.udecl</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Herb Sutter
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>8 Oct 2002<BR>


<P>The following came up recently on comp.lang.c++.moderated (edited for
brevity):</P>
<PRE>
  namespace N1 {
    template&lt;typename T&gt; void f( T* x ) {
      // ... other stuff ...
      delete x;
    }
  }

  namespace N2 {
    using N1::f;

    template&lt;&gt; void f&lt;int&gt;( int* ); // A: ill-formed

    class Test {
      ~Test() { }
      friend void f&lt;&gt;( Test* x );   // B: ill-formed?
    };
  }
</PRE>
<P>I strongly suspect, but don't have standardese to prove, that the friend
declaration in line B is ill-formed. Can someone show me the text that
allows or disallows line B?</P>

<P>Here's my reasoning: Writing "using" to pull the name into namespace N2
merely allows code in N2 to use the name in a call without qualification
(per 7.3.3&nbsp;



 <A HREF="dcl.html#namespace.udecl">namespace.udecl</A>).
But just as declaring a specialization must be done in the
namespace where the template really lives (hence line A is ill-formed), I
suspect that declaring a specialization as a friend must likewise be done
using the original namespace name, not obliquely through a "using". I see
nothing in 7.3.3&nbsp;



 <A HREF="dcl.html#namespace.udecl">namespace.udecl</A>
that would permit this use. Is there?</P>

<P>
<U>Andrey Tarasevich</U>:
14.5.3&nbsp;



 <A HREF="template.html#temp.friend">temp.friend</A> paragraph 2 seems to get pretty close:
"A friend declaration that is not a
template declaration and in which the name of the friend is an unqualified
'template-id' shall refer to a specialization of a function template
declared in the nearest enclosing namespace scope". </P>

<P>
<U>Herb Sutter</U>:
OK, thanks. Then the question in this is the word "declared" -- in
particular, we already know we cannot declare a specialization of a template
in any other namespace but the original one.</P>

<P>
<U>John Spicer</U>:
This seems like a simple question, but it isn't.</P>

<P>First of all, I don't think the standard comments on this usage one way 
or the other.</P>

<P>A similar example using a namespace qualified name is ill-formed based 
on 8.3&nbsp;



 <A HREF="decl.html#dcl.meaning">dcl.meaning</A> paragraph 1:</P>
<PRE>
  namespace N1 {
        void f();
  }

  namespace N2 {
        using N1::f;
        class A {
                friend void N2::f();
        };
  }
</PRE>

<P>
<A HREF="
     cwg_active.html#138">Core issue 138</A> deals with this example:</P>
<PRE>
  void foo();
  namespace A{
    using ::foo;
    class X{
      friend void foo();
    };
  }
</PRE>
<P>The proposed resolution (not yet approved) for
<A HREF="
     cwg_active.html#138">issue 138</A> is that the 
friend declares a new
foo that conflicts with the using-declaration and results in an error.</P>

<P>Your example is different than this though because the presence of the 
explicit argument list
means that this is not declaring a new f but is instead using a 
previously declared f.</P>

<P>One reservation I have about allowing the example is the desire to have 
consistent rules for all of the "declaration like" uses of template 
functions.   <A HREF="
     cwg_defects.html#275">Issue 275</A> (in DR status) addresses the
issue of unqualified names in explicit instantiation and explicit 
specialization declarations.
It requires that such declarations refer to templates from the namespace 
containing the
explicit instantiation or explicit specialization.  I believe this rule 
is necessary for those directives but is not really required for friend 
declarations -- but there is the consistency issue.</P>

<P>
<B>Notes from April 2003 meeting:</B>
</P>

<P>This is related to <A HREF="
     cwg_active.html#138">issue 138</A>.  John Spicer
is supposed to update his paper on this topic.  This is a new case
not covered in that paper.  We agreed that the B line should be
allowed.</P>

<BR>
<BR>
<HR>
<A NAME="482"></A>
<H4>482.
  
Qualified declarators in redeclarations
</H4>
<B>Section: </B>8.3&nbsp;



 <A HREF="decl.html#dcl.meaning">dcl.meaning</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Daveed Vandevoorde
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>03 Nov 2004<BR>


<P>According to 8.3&nbsp;



 <A HREF="decl.html#dcl.meaning">dcl.meaning</A> paragraph 1,</P>

<BLOCKQUOTE>

A <I>declarator-id</I> shall not be qualified except for the
definition of a member function (9.3&nbsp;



 <A HREF="class.html#class.mfct">class.mfct</A>) or
static data member (9.4&nbsp;



 <A HREF="class.html#class.static">class.static</A>) outside of its
class, the definition or explicit instantiation of a function or
variable member of a namespace outside of its namespace, or the
definition of a previously declared explicit specialization
outside of its namespace, or the declaration of a friend function
that is a member of another class or namespace (11.4&nbsp;



 <A HREF="access.html#class.friend">class.friend</A>). When the <I>declarator-id</I> is qualified, the
declaration shall refer to a previously declared member of the
class or namespace to which the qualifier refers...

</BLOCKQUOTE>

<P>This restriction prohibits examples like the following:</P>

<PRE>
    void f();
    void ::f();        // error: qualified declarator

    namespace N {
      void f();
      void N::f() { }  // error: qualified declarator
    }
</PRE>

<P>There doesn't seem to be any good reason for disallowing such
declarations, and a number of implementations accept them in
spite of the Standard's prohibition.  Should the Standard be
changed to allow them?</P>

<BR>
<BR>
<HR>
<A NAME="548"></A>
<H4>548.
  
<I>qualified-id</I>s in declarations
</H4>
<B>Section: </B>8.3&nbsp;



 <A HREF="decl.html#dcl.meaning">dcl.meaning</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Martin Sebor
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>18 November 2005<BR>


<P>According to 8.3&nbsp;



 <A HREF="decl.html#dcl.meaning">dcl.meaning</A> paragraph 1, the declarator
in the definition or explicit instantiation of a namespace member can
only be qualified if the definition or explicit instantiation appears
outside the member's namespace:</P>

<BLOCKQUOTE>

A <I>declarator-id</I> shall not be qualified except for the
definition of a member function (9.3&nbsp;



 <A HREF="class.html#class.mfct">class.mfct</A>) or static
data member (9.4&nbsp;



 <A HREF="class.html#class.static">class.static</A>) outside of its class, the
definition or explicit instantiation of a function or variable member
of a namespace outside of its namespace, or the definition of a
previously declared explicit specialization outside of its namespace,
or the declaration of a friend function that is a member of another
class or namespace (11.4&nbsp;



 <A HREF="access.html#class.friend">class.friend</A>). When
the <I>declarator-id</I> is qualified, the declaration shall refer to
a previously declared member of the class or namespace to which the
qualifier refers, and the member shall not have been introduced by
a <I>using-declaration</I> in the scope of the class or namespace
nominated by the <I>nested-name-specifier</I> of
the <I>declarator-id</I>.

</BLOCKQUOTE>

<P>There is no similar restriction on a <I>qualified-id</I> in a
class definition (9&nbsp;



 <A HREF="class.html#class">class</A> paragraph 5):</P>

<BLOCKQUOTE>

If a <I>class-head</I> contains a <I>nested-name-specifier</I>,
the <I>class-specifier</I> shall refer to a class that was previously
declared directly in the class or namespace to which the
<I>nested-name-specifier</I> refers (i.e., neither inherited nor
introduced by a <I>using-declaration</I>), and
the <I>class-specifier</I> shall appear in a namespace enclosing the
previous declaration.

</BLOCKQUOTE>

<P>An <I>elaborated-type-specifier</I> in an explicit instatiation
containing a <I>qualified-id</I> is also not prohibited from appearing
in the namespace nominated by its <I>nested-name-specifier</I>
(14.7.2&nbsp;



 <A HREF="template.html#temp.explicit">temp.explicit</A> paragraph 2):</P>

<BLOCKQUOTE>

An explicit instantiation shall appear in an enclosing namespace of
its template. If the name declared in the explicit instantiation is an
unqualified name, the explicit instantiation shall appear in the
namespace where its template is declared.

</BLOCKQUOTE>

<P>(This asymmetry is due to the removal of inappropriate mention
of classes in 8.3&nbsp;



 <A HREF="decl.html#dcl.meaning">dcl.meaning</A> by
<A HREF="
     cwg_defects.html#40">issue 40</A> and a failure to insert the
intended restrictions elsewhere.)</P>

<P>An example of this inconsistency is:</P>

<PRE>
    namespace N {
      template &lt;class T&gt; struct S { };
      template &lt;class T&gt; void foo () { }

      template struct N::S&lt;int&gt;;   //<SPAN STYLE="font-family:Times"><I> OK</I></SPAN>
      template void N::foo&lt;int&gt;(); //<SPAN STYLE="font-family:Times"><I> ill-formed</I></SPAN>
    }
</PRE>

<P>It is not clear that any purpose is served by the &ldquo;outside of
its namespace&rdquo; restriction on declarators in definitions and
explicit instantiations; if possible, it would be desirable to
reconcile the treatment of declarators and class names by removing
the restriction on declarators (which appears to be widespread
implementation practice, anyway).</P>

<BR>
<BR>
<HR>
<A NAME="332"></A>
<H4>332.
  
cv-qualified <TT>void</TT> parameter types
</H4>
<B>Section: </B>8.3.5&nbsp;



 <A HREF="decl.html#dcl.fct">dcl.fct</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Michiel Salters
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>9 Jan 2002<BR>


<P>8.3.5&nbsp;



 <A HREF="decl.html#dcl.fct">dcl.fct</A>/2 restricts the use of void
as parameter type, but does not
mention CV qualified versions. Since <TT>void f(volatile void)</TT>
isn't a callable
function anyway, 8.3.5&nbsp;



 <A HREF="decl.html#dcl.fct">dcl.fct</A>
should also ban cv-qualified versions.
(BTW, this follows C)</P>

<P>
<B>Suggested resolution:</B>
</P>

<P>A possible resolution would be to add (cv-qualified) before void in</P>
<BLOCKQUOTE>
The parameter list <TT>(void)</TT> is equivalent to the empty
parameter list. Except
for this special case, <B>(cv-qualified)</B> <TT>void</TT> shall
not be a parameter type (though types derived from <TT>void</TT>, such as
<TT>void*</TT>, can).
</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="547"></A>
<H4>547.
  
Partial specialization on member function types
</H4>
<B>Section: </B>8.3.5&nbsp;



 <A HREF="decl.html#dcl.fct">dcl.fct</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Peter Dimov
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>04 November 2005<BR>




<P>The following example appears to be well-formed, with the partial
specialization matching the type of <TT>Y::f()</TT>, even though it
is rejected by many compilers:</P>

<PRE>
    template&lt;class T&gt; struct X;

    template&lt;class R&gt; struct X&lt; R() &gt; {
    };

    template&lt;class F, class T&gt; void test(F T::* pmf) {
        X&lt;F&gt; x;
    }

    struct Y {
        void f() {
        }
    };

    int main() {
        test( &amp;Y::f );
    }
</PRE>

<P>However, 8.3.5&nbsp;



 <A HREF="decl.html#dcl.fct">dcl.fct</A> paragraph 4 says,</P>

<BLOCKQUOTE>

A <I>cv-qualifier-seq</I> shall only be part of the function type for
a non-static member function, the function type to which a pointer to
member refers, or the top-level function type of a function typedef
declaration. The effect of a <I>cv-qualifier-seq</I> in a function
declarator is not the same as adding cv-qualification on top of the
function type. In the latter case, the cv-qualifiers are ignored.

</BLOCKQUOTE>

<P>This specification makes it impossible to write a partial
specialization for a <TT>const</TT> member function:</P>

<PRE>
    template&lt;class R&gt; struct X&lt;R() const&gt; {
    };
</PRE>

<P>A template argument is not one of the permitted contexts for
cv-qualification of a function type.  This restriction should be
removed.</P>

<BR>
<BR>
<HR>
<A NAME="550"></A>
<H4>550.
  
Pointer to array of unknown bound in parameter declarations
</H4>
<B>Section: </B>8.3.5&nbsp;



 <A HREF="decl.html#dcl.fct">dcl.fct</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Daveed Vandevoorde
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>22 November 2005<BR>


<P>The current wording of 8.3.5&nbsp;



 <A HREF="decl.html#dcl.fct">dcl.fct</A> paragraph 6
encompasses more than it should:</P>

<BLOCKQUOTE>

If the type of a parameter includes a type of the form &ldquo;pointer
to array of unknown bound of <TT>T</TT>&rdquo; or &ldquo;reference to
array of unknown bound of <TT>T</TT>,&rdquo; the program is
ill-formed. [<I>Footnote:</I> This excludes parameters of type
&ldquo;<I>ptr-arr-seq</I> <TT>T2</TT>&rdquo; where <TT>T2</TT> is
&ldquo;pointer to array of unknown bound of <TT>T</TT>&rdquo; and
where <I>ptr-arr-seq</I> means any sequence of &ldquo;pointer
to&rdquo; and &ldquo;array of&rdquo; derived declarator types. This
exclusion applies to the parameters of the function, and if a
parameter is a pointer to function or pointer to member function then
to its parameters also, etc. &mdash;<I>end footnote</I>]

</BLOCKQUOTE>

<P>The normative wording (contrary to the intention expressed in the
footnote) excludes declarations like</P>

<PRE>
    template&lt;class T&gt; struct S {};
    void f(S&lt;int (*)[]&gt;);
</PRE>

<P>and</P>

<PRE>
    struct S {};
    void f(int(*S::*)[]);
</PRE>

<P>but not</P>

<PRE>
    struct S {};
    void f(int(S::*)[]);
</PRE>

<BR>
<BR>
<HR>
<A NAME="325"></A>
<H4>325.
  
When are default arguments parsed?
</H4>
<B>Section: </B>8.3.6&nbsp;



 <A HREF="decl.html#dcl.fct.default">dcl.fct.default</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Nathan Sidwell
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>27 Nov 2001<BR>


<P>The standard is not precise enough about when the default arguments of
member functions are parsed.  This leads to confusion over whether certain
constructs are legal or not, and the validity of certain compiler
implementation algorithms.</P>

<P>8.3.6&nbsp;



 <A HREF="decl.html#dcl.fct.default">dcl.fct.default</A> paragraph 5 says "names in the
expression are bound, and
the semantic constraints are checked, at the point where the default
argument expression appears"</P>

<P>However, further on at paragraph 9 in the same section there is an example,
where the salient parts are
<PRE>
  int b;
  class X {
    int mem2 (int i = b); // OK use X::b
    static int b;
  };
</PRE>
which appears to contradict the former constraint. At the point the default
argument expression appears in the definition of X, X::b has not been
declared, so one would expect ::b to be bound.  This of course appears to
violate 3.3.6&nbsp;



 <A HREF="basic.html#basic.scope.class">basic.scope.class</A> paragraph 1(2) "A name N used in
a class S shall
refer to the same declaration in its context and when reevaluated in the
complete scope of S. No diagnostic is required."</P>

<P>Furthermore 3.3.6&nbsp;



 <A HREF="basic.html#basic.scope.class">basic.scope.class</A> paragraph 1(1) gives the
 scope of names declared
in class to "consist not only of the declarative region following
the name's declarator, but also of .. default arguments ...". Thus implying
that X::b is in scope in the default argument of X::mem2 previously.</P>

<P>That previous paragraph hints at an implementation technique of saving the
token stream of a default argument expression and parsing it at the end of
the class definition (much like the bodies of functions defined in the
class).  This is a technique employed by GCC and, from its behaviour, in
the EDG front end.  The standard leaves two things unspecified. 
Firstly, is a default argument expression permitted to call a static member
function declared later in the class in such a way as to require evaluation of
that function's default arguments? I.e. is the following well formed?
<PRE>
  class A {
    static int Foo (int i = Baz ());
    static int Baz (int i = Bar ());
    static int Bar (int i = 5);
 };
</PRE>
If that is well formed, at what point does the non-sensicalness of
<PRE>
  class B {
    static int Foo (int i = Baz ());
    static int Baz (int i = Foo());
  };
</PRE>
become detected? Is it when B is complete? Is it when B::Foo or B::Baz is
called in such a way to require default argument expansion? Or is no
diagnostic required?</P>

<P>The other problem is with collecting the tokens that form the default
argument expression.  Default arguments which contain template-ids with
more than one parameter present a difficulty in determining when the
default argument finishes.  Consider,
<PRE>
  template &lt;int A, typename B&gt; struct T { static int i;};
  class C {
    int Foo (int i = T&lt;1, int&gt;::i);
  };
</PRE>
The default argument contains a non-parenthesized comma.  Is it required
that this comma is seen as part of the default argument expression and not
the beginning of another of argument declaration?  To accept this as
part of the default argument would require name lookup of T (to determine
that the '&lt;' was part of a template argument list and not a less-than
operator) before C is complete.  Furthermore, the more pathological
<PRE>
  class D {
    int Foo (int i = T&lt;1, int&gt;::i);
    template &lt;int A, typename B&gt; struct T {static int i;};
  };
</PRE>
would be very hard to accept. Even though T is declared after Foo, T is
in scope within Foo's default argument expression.</P>

<P>
<B>Suggested resolution:</B>
</P>

<P>Append the following text to 8.3.6&nbsp;



 <A HREF="decl.html#dcl.fct.default">dcl.fct.default</A> paragraph 8.</P>
<BLOCKQUOTE>
	The default argument expression of a member function declared in 
	the class definition consists of the sequence of tokens up until
	the next non-parenthesized, non-bracketed comma or close
	parenthesis.  Furthermore such default argument expressions shall
	not require evaluation of a default argument of a function
	declared later in the class.
</BLOCKQUOTE>

<P>This would make the above A, B, C and D ill formed and is in line with the
existing compiler practice that I am aware of.</P>

<P>
<B>Notes from the October, 2005 meeting:</B>
</P>

<P>The CWG agreed that the first example (<TT>A</TT>) is currently
well-formed and that it is not unreasonable to expect implementations
to handle it by processing default arguments recursively.</P>

<BR>
<BR>
<HR>
<A NAME="361"></A>
<H4>361.
  
Forward reference to default argument
</H4>
<B>Section: </B>8.3.6&nbsp;



 <A HREF="decl.html#dcl.fct.default">dcl.fct.default</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Steve Clamage
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>17 June 2002<BR>




<P>Is this program well-formed?</P>
<PRE>
  struct S {
    static int f2(int = f1()); // OK?
    static int f1(int = 2);
  };
  int main()
  {
    return S::f2();
  }
</PRE>
<P>A class member function can in general refer to class members that
are declared lexically later.  But what about referring to default
arguments of member functions that haven't yet been declared?</P>

<P>It seems to me that if f2 can refer to f1, it can also refer to the
default argument of f1, but at least one compiler disagrees.</P>

<BR>
<BR>
<HR>
<A NAME="155"></A>
<H4>155.
  
Brace initializer for scalar
</H4>
<B>Section: </B>8.5&nbsp;



 <A HREF="decl.html#dcl.init">dcl.init</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Steve Clamage
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>12 Aug 1999<BR>





<P>It is not clear whether the following declaration is well-formed:</P>

<PRE>
    struct S { int i; } s = { { 1 } };
</PRE>

According to 8.5.1&nbsp;



 <A HREF="decl.html#dcl.init.aggr">dcl.init.aggr</A>

paragraph 2, a brace-enclosed initializer is permitted for a
subaggregate of an aggregate; however, <TT>i</TT> is a scalar, not an
aggregate.  8.5&nbsp;



 <A HREF="decl.html#dcl.init">dcl.init</A>
 paragraph 13
says that a standalone declaration like

<PRE>
    int i = { 1 };
</PRE>

is permitted, but it is not clear whether this says anything about the
form of initializers for scalar members of aggregates.

<P>This is (more) clearly permitted by the C89 Standard.</P>


<BR>
<BR>
<HR>
<A NAME="253"></A>
<H4>253.
  
Why must empty or fully-initialized const objects be initialized?
</H4>
<B>Section: </B>8.5&nbsp;



 <A HREF="decl.html#dcl.init">dcl.init</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Mike Miller
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>11 Jul 2000<BR>




<P>Paragraph 9 of
8.5&nbsp;



 <A HREF="decl.html#dcl.init">dcl.init</A>

 says:</P>
<BLOCKQUOTE>If no initializer is specified for an object, and the object
is of (possibly cv-qualified) non-POD class type (or array thereof), the
object shall be default-initialized; if the object is of const-qualified
type, the underlying class type shall have a user-declared default constructor.
Otherwise, if no initializer is specified for an object, the object and
its subobjects, if any, have an indeterminate initial value; if the object
or any of its subobjects are of const-qualified type, the program is ill-formed.</BLOCKQUOTE>

<P>What if a const POD object has no non-static data members?
This wording requires an empty initializer for such cases:</P>

<PRE>
    struct Z {
        // no data members
        operator int() const { return 0; }
    };

    void f() {
        const Z z1;         // ill-formed: no initializer
        const Z z2 = { };   // well-formed
    }
</PRE>

<P>Similar comments apply to a non-POD const object, all of whose
non-static data members and base class subobjects have default
constructors.  Why should the class of such an object be required
to have a user-declared default constructor?</P>

<P>(See also <A HREF="
     cwg_defects.html#78">issue 78</A>.)</P>

<BR>
<BR>
<HR>
<A NAME="509"></A>
<H4>509.
  
Dead code in the specification of default initialization
</H4>
<B>Section: </B>8.5&nbsp;



 <A HREF="decl.html#dcl.init">dcl.init</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Mike Miller
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>18 Mar 2005<BR>


<P>The definition of default initialization (8.5&nbsp;



 <A HREF="decl.html#dcl.init">dcl.init</A>
paragraph 5) is:</P>

<BLOCKQUOTE>

<UL>

<LI>
<P>if <TT>T</TT> is a non-POD class type (clause 9&nbsp;



 <A HREF="class.html#class">class</A>), the default constructor for <TT>T</TT> is called (and the
initialization is ill-formed if <TT>T</TT> has no accessible default
constructor);</P>
</LI>

<LI>
<P>if <TT>T</TT> is an array type, each element is
default-initialized;</P>
</LI>

<LI>
<P>otherwise, the object is zero-initialized.</P>
</LI>

</UL>

</BLOCKQUOTE>

<P>However, default initialization is invoked only for non-POD class
types and arrays thereof (5.3.4&nbsp;



 <A HREF="expr.html#expr.new">expr.new</A> paragraph 15
for <I>new-expression</I>s, 8.5&nbsp;



 <A HREF="decl.html#dcl.init">dcl.init</A> paragraph 10
for top-level objects, and 12.6.2&nbsp;



 <A HREF="special.html#class.base.init">class.base.init</A> paragraph 4
for member and base class subobjects&nbsp;&mdash; but see
<A HREF="
     cwg_active.html#510">issue 510</A>).  Consequently, all cases that
invoke default initialization are handled by the first two bullets;
the third bullet can never be reached.  Its presence is misleading, so
it should be removed.</P>

<BR>
<BR>
<HR>
<A NAME="543"></A>
<H4>543.
  
Value initialization and default constructors
</H4>
<B>Section: </B>8.5&nbsp;



 <A HREF="decl.html#dcl.init">dcl.init</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Mike Miller
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>27 October 2005<BR>


<P>The wording resulting from the resolution of
<A HREF="
     cwg_defects.html#302">issue 302</A> does not quite implement the intent
of the issue.  The revised wording of 3.2&nbsp;



 <A HREF="basic.html#basic.def.odr">basic.def.odr</A>
paragraph 2 is:</P>

<BLOCKQUOTE>

A default constructor for a class is used by default initialization or
value initialization as specified in 8.5&nbsp;



 <A HREF="decl.html#dcl.init">dcl.init</A>.

</BLOCKQUOTE>

<P>This sounds as if 8.5&nbsp;



 <A HREF="decl.html#dcl.init">dcl.init</A> specifies how and
under what circumstances value initialization uses a default
constructor (which was, in fact, the case for default initialization
in the original wording).  However, the normative text there makes it
plain that value initialization does <I>not</I> call the default
constructor (the permission granted to implementations to call the
default constructor for value initialization is in a non-normative
footnote).</P>

<P>The example that occasioned this observation raises an
additional question.  Consider:</P>

<PRE>
    struct POD {
      const int x;
    };

    POD data = POD();
</PRE>

<P>According to the (revised) resolution of issue 302, this code is
ill-formed because the implicitly-declared default constructor will
be implicitly defined as a result of being used by value initialization
(12.1&nbsp;



 <A HREF="special.html#class.ctor">class.ctor</A> paragraph 7), and the implicitly-defined
constructor fails to initialize a const-qualified member
(12.6.2&nbsp;



 <A HREF="special.html#class.base.init">class.base.init</A> paragraph 4).  This seems unfortunate,
because the (trivial) default constructor of a POD class is otherwise
not used &mdash; default initialization applies only to non-PODs
&mdash; and it is not actually needed in value initialization.
Perhaps value initialization should be defined to &ldquo;use&rdquo;
the default constructor only for non-POD classes?  If so, both of
these problems would be resolved by rewording the above-referenced
sentence of 3.2&nbsp;



 <A HREF="basic.html#basic.def.odr">basic.def.odr</A> paragraph 2 as:</P>

<BLOCKQUOTE>

A default constructor for a <B>non-POD</B> class is used by
default initialization or value initialization <S>as specified in</S>
<B>(</B>8.5&nbsp;



 <A HREF="decl.html#dcl.init">dcl.init</A><B>)</B>.

</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="430"></A>
<H4>430.
  
Ordering of expression evaluation in initializer list
</H4>
<B>Section: </B>8.5.1&nbsp;



 <A HREF="decl.html#dcl.init.aggr">dcl.init.aggr</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Nathan Sidwell
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>23 July 2003<BR>




<P>A recent GCC bug report
(<A HREF="http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11633">
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11633</A>)
asks about the validity of
<PRE>
  int count = 23;
  int foo[] = { count++, count++, count++ };
</PRE>
is this undefined or unspecified or something else? I can find nothing in
8.5.1&nbsp;



 <A HREF="decl.html#dcl.init.aggr">dcl.init.aggr</A> that indicates whether the components of
an initializer-list are evaluated in order or not, or whether they
have sequence points between them.</P>

<P>6.7.8/23 of the C99 std has this to say
<BLOCKQUOTE>
The order in which any side effects occur among the initialization list
expressions is unspecified.
</BLOCKQUOTE>
I think similar wording is needed in 8.5.1&nbsp;



 <A HREF="decl.html#dcl.init.aggr">dcl.init.aggr</A>
</P>

<P>
<U>Steve Adamczyk:</U>
I believe the standard is clear that each initializer
expression in the above is a full-expression
(1.9&nbsp;



 <A HREF="intro.html#intro.execution">intro.execution</A>/12-13; see also
<A HREF="
     cwg_defects.html#392">issue 392</A>) and therefore there is a sequence point
after each expression (1.9&nbsp;



 <A HREF="intro.html#intro.execution">intro.execution</A>/16).  I agree that the
standard does not seem to dictate the order in which the expressions
are evaluated, and perhaps it should.  Does anyone know of a compiler
that would not evaluate the expressions left to right?</P>

<P>
<U>Mike Simons:</U> Actually there is one, that does not do
left to right: gcc/C++.  None of the post increment operations
take effect until after the statement finishes.  So in the sample
code gcc stores 23 into all positions in the array.  The
commercial vendor C++ compilers for AIX, Solaris, Tru64, HPUX
(parisc and ia64), and Windows, all do sequence points at each
',' in the initializer list.</P>

<BR>
<BR>
<HR>
<A NAME="327"></A>
<H4>327.
  
Use of "structure" without definition
</H4>
<B>Section: </B>9&nbsp;



 <A HREF="class.html#class">class</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>James Kanze
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>9 Dec 2001<BR>



<P>In 9&nbsp;



 <A HREF="class.html#class">class</A> paragraph 4, the first sentence says
"A structure is a class
definition defined with the <I>class-key</I> <TT>struct</TT>".
As far as I know,
there is no such thing as a structure in C++; it certainly isn't
listed as one of the possible compound types in 3.9.2&nbsp;



 <A HREF="basic.html#basic.compound">basic.compound</A>.
And defining structures opens the question of whether a forward
declaration is a structure or not.  The parallel here with union
(which follows immediately) suggests that structures and classes are
really different things, since the same wording is used, and classes
and unions do have some real differences, which manifest themselves
outside of the definition.  It also suggests that since one can't
forward declare union with class and vice versa, the same should
hold for struct and class -- I believe that the intent was that one
could use struct and class interchangeably in forward declaration.</P>

<P>
<B>Suggested resolution:</B>
</P>

<P>I suggest something like the following:</P>
<BLOCKQUOTE>
If a class is defined with the <I>class-key</I> <TT>class</TT>, its members and
base classes are private by default.  If a class is defined with
the <I>class-key</I> <TT>struct</TT>,
its members and base classes are public by
default.  If a class is defined with the <I>class-key</I> <TT>union</TT>, its
members are public by default, and it holds only one data member
at a time.  Such classes are called unions, and obey a number of
additional restrictions, see 9.5&nbsp;



 <A HREF="class.html#class.union">class.union</A>.
</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="355"></A>
<H4>355.
  
Global-scope <TT>::</TT> in <I>elaborated-type-specifier</I>
</H4>
<B>Section: </B>9&nbsp;



 <A HREF="class.html#class">class</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Clark Nelson
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>16 May 2002<BR>




<P>
In looking at a large handful of core issues related to
<I>elaborated-type-specifier</I>s and the naming of classes in general, I
discovered an odd fact. It turns out that there is exactly one place in the
grammar where <I>nested-name-specifier</I>
is not immediately preceded by "<TT>::</TT><SUB><I>opt</I></SUB>":
in <I>class-head</I>, which is used only for class definitions. So technically,
this example is ill-formed, and should evoke a syntax error:
</P>
<PRE>
  struct A;
  struct ::A { };
</PRE>
<P>
However, all of EDG, GCC and Microsoft's compiler accept it without a qualm.
In fact, I couldn't get any of them to even warn about it.</P>

<P>
<B>Suggested resolution:</B>
</P>

<P>It would simplify the grammar, and apparently better reflect existing
practice, to factor the global-scope operator into the rule for
<I>nested-name-specifier</I>.</P>

<BR>
<BR>
<HR>
<A NAME="511"></A>
<H4>511.
  
POD-structs with template assignment operators
</H4>
<B>Section: </B>9&nbsp;



 <A HREF="class.html#class">class</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Alisdair Meredith
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>19 Mar 2005<BR>


<P>A POD-struct is not permitted to have a user-declared copy
assignment operator (9&nbsp;



 <A HREF="class.html#class">class</A> paragraph 4).  However, a
template assignment operator is not considered a copy assignment
operator, even though its specializations can be selected by overload
resolution for performing copy operations (12.8&nbsp;



 <A HREF="special.html#class.copy">class.copy</A>
paragraph 9 and especially footnote 114).  Consequently, <TT>X</TT> in
the following code is a POD, notwithstanding the fact that copy
assignment (for a non-const operand) is a member function call
rather than a bitwise copy:</P>

<PRE>
    struct X {
      template&lt;typename T&gt; const X&amp; operator=(T&amp;);
    };
    void f() {
      X x1, x2;
      x1 = x2;  //<SPAN STYLE="font-family:Times"><I> calls </I></SPAN>X::operator=&lt;X&gt;(X&amp;)
    }
</PRE>

<P>Is this intentional?</P>

<BR>
<BR>
<HR>
<A NAME="538"></A>
<H4>538.
  
Definition and usage of <I>structure</I>, <I>POD-struct</I>, <I>POD-union</I>, and <I>POD class</I>
</H4>
<B>Section: </B>9&nbsp;



 <A HREF="class.html#class">class</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Alisdair Meredith
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>10 August 2005<BR>


<P>There are several problems with the terms defined in
9&nbsp;



 <A HREF="class.html#class">class</A> paragraph 4:</P>

<BLOCKQUOTE>

A <I>structure</I> is a class defined with
the <I>class-key</I> <TT>struct</TT>; its members and base classes
(clause 10&nbsp;



 <A HREF="derived.html#class.derived">class.derived</A>) are public by default (clause
11&nbsp;



 <A HREF="access.html#class.access">class.access</A>). A <I>union</I> is a class defined with the
<I>class-key</I> <TT>union</TT>; its members are public by default and
it holds only one data member at a time (9.5&nbsp;



 <A HREF="class.html#class.union">class.union</A>). [<I>Note:</I> aggregates of class type are described
in 8.5.1&nbsp;



 <A HREF="decl.html#dcl.init.aggr">dcl.init.aggr</A>. &mdash;<I>end note</I>]
A <I>POD-struct</I> is an aggregate class that has no non-static data
members of type non-POD-struct, non-POD-union (or array of such types)
or reference, and has no user-declared copy assignment operator and no
user-declared destructor. Similarly, a <I>POD-union</I> is an
aggregate union that has no non-static data members of type
non-POD-struct, non-POD-union (or array of such types) or reference,
and has no user-declared copy assignment operator and no user-declared
destructor. A <I>POD class</I> is a class that is either a POD-struct
or a POD-union.

</BLOCKQUOTE>

<OL>

<LI>
<P>Although the term <I>structure</I> is defined here, it is
used only infrequently throughout the Standard, often apparently
inadvertently and consequently incorrectly:</P>

<UL>

<LI>
<P>5.2.5&nbsp;



 <A HREF="expr.html#expr.ref">expr.ref</A> paragraph 4: the use is in a
note and is arguably correct and helpful.</P>
</LI>

<LI>
<P>9.2&nbsp;



 <A HREF="class.html#class.mem">class.mem</A> paragraph 11: the term is used
(three times) in an example.  There appears to be no reason to use
it instead of &ldquo;class,&rdquo; but its use is not
problematic.</P>
</LI>

<LI>
<P>17.1.8&nbsp;



 <A HREF="lib-intro.html#defns.iostream.templates">defns.iostream.templates</A>: the <TT>traits</TT> argument
to the iostream class templates is (presumably unintentionally)
constrained to be a structure, i.e., to use the <TT>struct</TT>
keyword and not the <TT>class</TT> keyword in its definition.</P>
</LI>

<LI>
<P>B&nbsp;



 <A HREF="limits.html#limits">limits</A> paragraph 2: the minimum number of
declarator operators is given for structures and unions but not
for classes defined using the <TT>class</TT> keyword.</P>
</LI>

<LI>
<P>B&nbsp;



 <A HREF="limits.html#limits">limits</A> paragraph 2: class, structure,
and union are used as disjoint terms in describing nesting
levels.  (The nonexistent nonterminal <I>struct-declaration-list</I>
is used, as well.)</P>
</LI>

</UL>

<P>There does not appear to be a reason for defining the term
<I>structure</I>.  The one reference where it is arguably useful,
in the note in 5.2.5&nbsp;



 <A HREF="expr.html#expr.ref">expr.ref</A>, could be rewritten
as something like, &ldquo;'class objects' may be defined using the
<TT>class</TT>, <TT>struct</TT>, or <TT>union</TT>
<I>class-key</I>s; see clause 9&nbsp;



 <A HREF="class.html#class">class</A>.&rdquo;</P>

</LI>

<LI>
<P>Based on its usage later in the paragraph and elsewhere,
&ldquo;POD-struct&rdquo; appears to be intended to exclude unions.
However, the definition of &ldquo;aggregate class&rdquo; in
8.5.1&nbsp;



 <A HREF="decl.html#dcl.init.aggr">dcl.init.aggr</A> paragraph 1 includes unions.
Furthermore, the name itself is confusing, leading to the question of
whether it was intended that only classes defined
using <TT>struct</TT> could be POD-structs or
if <TT>class</TT>-classes are included.  The definition should
probably be rewritten as, &ldquo;A <I>POD-struct</I> is an aggregate
class <B>defined with the <I>class-key</I> <TT>struct</TT> or
the <I>class-key</I> <TT>class</TT></B> that has no...</P>

</LI>

<LI>
<P>In most references outside clause 9&nbsp;



 <A HREF="class.html#class">class</A>,
POD-struct and POD-union are mentioned together and treated
identically.  These references should be changed to refer to the
unified term, &ldquo;POD class.&rdquo;</P>
</LI>

<LI>
<P>Noted in passing: 18.1&nbsp;



 <A HREF="lib-support.html#lib.support.types">lib.support.types</A> paragraph 4
refers to the undefined terms &ldquo;POD structure&rdquo; and
(unhyphenated) &ldquo;POD union;&rdquo; the pair should be replaced
by a single reference to &ldquo;POD-class.&rdquo;</P>
</LI>

</OL>

<BR>
<BR>
<HR>
<A NAME="57"></A>
<H4>57.
  
Empty unions
</H4>
<B>Section: </B>9.5&nbsp;



 <A HREF="class.html#class.union">class.union</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Steve Adamczyk
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>13 Oct 1998<BR>



<P>There doesn't seem to be a prohibition in 9.5&nbsp;



 <A HREF="class.html#class.union">class.union</A>
 against a declaration
like</P>
<PRE>
    union { int : 0; } x;
</PRE>
Should that be valid?  If so, 8.5&nbsp;



 <A HREF="decl.html#dcl.init">dcl.init</A>

paragraph 5 third bullet, which deals with
default-initialization of unions, should say that no initialization is
done if there are no data members.
    
<P>What about:</P>
<PRE>
    union { } x;
    static union { };
</PRE>
If the first example is well-formed, should either or both of these cases
be well-formed as well?

<P>(See also the resolution for
<A HREF="
     cwg_defects.html#151">issue 151</A>.)</P>

<P>
<B>Notes from 10/00 meeting:</B> The resolution to
<A HREF="
     cwg_defects.html#178">issue 178</A>, which was accepted as a
DR, addresses the first point above (default initialization).
The other questions have not yet been decided, however.</P>
<BR>
<BR>
<HR>
<A NAME="512"></A>
<H4>512.
  
Union members with user-declared non-default constructors
</H4>
<B>Section: </B>9.5&nbsp;



 <A HREF="class.html#class.union">class.union</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Alisdair Meredith
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>19 Mar 2005<BR>


<P>Can a member of a union be of a class that has a user-declared
non-default constructor?  The restrictions on union membership in
9.5&nbsp;



 <A HREF="class.html#class.union">class.union</A> paragraph 1 only mention default and
copy constructors:</P>

<BLOCKQUOTE>

An object of a class with a non-trivial default constructor
(12.1&nbsp;



 <A HREF="special.html#class.ctor">class.ctor</A>), a non-trivial copy constructor
(12.8&nbsp;



 <A HREF="special.html#class.copy">class.copy</A>), a non-trivial destructor (12.4&nbsp;



 <A HREF="special.html#class.dtor">class.dtor</A>), or a non-trivial copy assignment operator
(13.5.3&nbsp;



 <A HREF="over.html#over.ass">over.ass</A>, 12.8&nbsp;



 <A HREF="special.html#class.copy">class.copy</A>) cannot be
a member of a union...

</BLOCKQUOTE>

<P>(12.1&nbsp;



 <A HREF="special.html#class.ctor">class.ctor</A> paragraph 11 does say,
&ldquo;a non-trivial constructor,&rdquo; but it's not clear whether
that was intended to refer only to default and copy constructors
or to any user-declared constructor.  For example,
12.2&nbsp;



 <A HREF="special.html#class.temporary">class.temporary</A> paragraph 3 also speaks of a
&ldquo;non-trivial constructor,&rdquo; but the cross-references
there make it clear that only default and copy constructors are
in view.)</P>

<BR>
<BR>
<HR>
<A NAME="347"></A>
<H4>347.
  
Use of derived class name in defining base class nested class
</H4>
<B>Section: </B>9.7&nbsp;



 <A HREF="class.html#class.nest">class.nest</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Jason Shirk
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>21 March 2002<BR>




<P>9.3&nbsp;



 <A HREF="class.html#class.mfct">class.mfct</A> paragraph 5 says this about member
functions defined lexically outside the class:</P>
<BLOCKQUOTE>
the member function name shall be qualified by its class name using
the :: operator
</BLOCKQUOTE>

<P>9.4.2&nbsp;



 <A HREF="class.html#class.static.data">class.static.data</A> paragraph 2 says this about static
data members:</P>
<BLOCKQUOTE>
In the definition at namespace scope, the name of the static data
member shall be qualified by its class name using the :: operator
</BLOCKQUOTE>

<P>I would have expected similar wording in 9.7&nbsp;



 <A HREF="class.html#class.nest">class.nest</A>
paragraph 3 for nested classes. Without such wording, the following
seems to be legal (and is allowed by all the compilers I have):</P>
<PRE>
  struct base {
    struct nested;
  };

  struct derived : base {};
  struct derived::nested {};
</PRE>

<P>Is this just an oversight, or is there some rationale for this behavior?</P>

<BR>
<BR>
<HR>
<A NAME="380"></A>
<H4>380.
  
Definition of "ambiguous base class" missing
</H4>
<B>Section: </B>10.2&nbsp;



 <A HREF="derived.html#class.member.lookup">class.member.lookup</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Jason Merrill
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>22 Oct 2002<BR>


<P>The term "ambiguous base class" doesn't seem to be actually defined
anywhere.  10.2&nbsp;



 <A HREF="derived.html#class.member.lookup">class.member.lookup</A> paragraph 7 seems like the place
to do it.</P>

<BR>
<BR>
<HR>
<A NAME="230"></A>
<H4>230.
  
Calls to pure virtual functions
</H4>
<B>Section: </B>10.4&nbsp;



 <A HREF="derived.html#class.abstract">class.abstract</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Jim Hill
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>4 May 2000<BR>


<P>According to 10.4&nbsp;



 <A HREF="derived.html#class.abstract">class.abstract</A> paragraph 6,</P>

<BLOCKQUOTE>

Member functions can be called from a constructor (or destructor) of
an abstract class; the effect of making a virtual call (10.3&nbsp;



 <A HREF="derived.html#class.virtual">class.virtual</A>) to a pure virtual function directly or indirectly for
the object being created (or destroyed) from such a constructor (or
destructor) is undefined.

</BLOCKQUOTE>

<P>This prohibition is unnecessarily restrictive.  It should not apply
to cases in which the pure virtual function has been defined.</P>

<P>Currently the "pure" specifier for a virtual member function has
two meanings that need not be related:</P>

<OL>

<LI>A pure virtual function need not be defined.</LI>

<LI>A pure virtual function must be overridden in any concrete derived
class.</LI>

</OL>

<P>The prohibition of virtual calls to pure virtual functions arises
from the first meaning and unnecessarily penalizes those who only need
the second.</P>

<P>For example, consider a scenario such as the following.  A class
<TT>B</TT> is defined containing a (non-pure) virtual function
<TT>f</TT> that provides some initialization and is thus called from
the base class constructor.  As time passes, a number of classes are
derived from <TT>B</TT> and it is noticed that each needs to override
<TT>f</TT>, so it is decided to make <TT>B::f</TT> pure to enforce
this convention while still leaving the original definition of
<TT>B::f</TT> to perform its needed initialization.  However, the act
of making <TT>B::f</TT> pure means that every reference to <TT>f</TT>
that might occur during the execution of one of <TT>B</TT>'s
constructors must be tracked down and edited to be a qualified
reference to <TT>B::f</TT>.  This process is tedious and error-prone:
needed edits might be overlooked, and calls that actually should be
virtual when the containing function is called other than during
construction/destruction might be incorrectly changed.</P>

<P>
<B>Suggested resolution:</B> Allow virtual calls to pure virtual
functions if the function has been defined.</P>

<BR>
<BR>
<HR>
<A NAME="360"></A>
<H4>360.
  
Using-declaration that reduces access
</H4>
<B>Section: </B>11.2&nbsp;



 <A HREF="access.html#class.access.base">class.access.base</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Steve Clamage
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>4 June 2002<BR>




<P>I have heard a claim that the following code is valid, but I don't
see why.</P>
<PRE>
  struct A {
    int foo ();
  };

  struct B: A {
  private:
    using A::foo;
  };

  int main ()
  {
    return B ().foo ();
  }
</PRE>
<P>
It seems to me that the using declaration in B should hide the
public foo in A. Then the call to B::foo should fail because B::foo
is not accessible in main.</P>

<P>Am I missing something?</P>

<P>
<U>Steve Adamczyk</U>:
This is similar to the last example in 11.2&nbsp;



 <A HREF="access.html#class.access.base">class.access.base</A>.
In prose, the rule is
that if you have access to cast to a base class and you have access
to the member in the base class, you are given access in the derived
class.  In this case, A is a public base class of B and foo is public
in A, so you can access foo through a B object.  The actual permission
for this is in the fourth bullet in
11.2&nbsp;



 <A HREF="access.html#class.access.base">class.access.base</A> paragraph 4.</P>

<P>The wording changes for <A HREF="
     cwg_defects.html#9">issue 9</A>
make this clearer, but I believe
even without them this example could be discerned to be valid.</P>

<P>See my paper J16/96-0034, WG21/N0852 on this topic.</P>

<P>
<U>Steve Clamage</U>:
But a using-declaration is a declaration (7.3.3&nbsp;



 <A HREF="dcl.html#namespace.udecl">namespace.udecl</A>).
Compare with</P>
<PRE>
  struct B : A {
  private:
    int foo();
  };
</PRE>
<P>In this case, the call would certainly be invalid, even though your
argument about casting B to an A would make it OK. Your argument
basically says that an access adjustment to make something less
accessible has no effect. That also doesn't sound right.</P>

<P>
<U>Steve Adamczyk</U>:
I agree that is strange.  I do think that's what 11.2&nbsp;



 <A HREF="access.html#class.access.base">class.access.base</A>
says, but perhaps that's not what we want it to say.</P>

<BR>
<BR>
<HR>
<A NAME="199"></A>
<H4>199.
  
Order of destruction of temporaries
</H4>
<B>Section: </B>12.2&nbsp;



 <A HREF="special.html#class.temporary">class.temporary</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Alan Nash
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>27 Jan 2000<BR>





<P>12.2&nbsp;



 <A HREF="special.html#class.temporary">class.temporary</A>
 paragraph 3 simply
states the requirement that temporaries created during the evaluation
of an expression</P>

<BLOCKQUOTE>
are destroyed as the last step in evaluating the
full-expression (1.9) that (lexically) contains the point where they
were created.
</BLOCKQUOTE>

There is nothing said about the relative order in which these
temporaries are destroyed.

<P>Paragraph 5, dealing with temporaries bound to references, says</P>

<BLOCKQUOTE>
the temporaries created during the evaluation of the expression
initializing the reference, except the temporary to which the
reference is bound, are destroyed at the end of the full-expression in
which they are created and in the reverse order of the completion of
their construction.
</BLOCKQUOTE>

Is this difference intentional?  May temporaries in expressions other
than those initializing references be deleted in non-LIFO order?

<P>
<B>Notes from 04/00 meeting:</B>
</P>

<P>Steve Adamczyk expressed concern about constraining implementations
that are capable of fine-grained parallelism -- they may be
unable to determine the order of construction without adding
undesirable overhead.</P>

<BR>
<BR>
<HR>
<A NAME="395"></A>
<H4>395.
  
Conversion operator template syntax
</H4>
<B>Section: </B>12.3.2&nbsp;



 <A HREF="special.html#class.conv.fct">class.conv.fct</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Daveed Vandevoorde
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>18 Dec 2002<BR>




<P>A posting in comp.lang.c++.moderated prompted me to
try the following code:</P>
<PRE>
  struct S {
    template&lt;typename T, int N&gt; (&amp;operator T())[N];
  };
</PRE>
<P>The goal is to have a (deducible) conversion operator
template to a reference-to-array type.</P>

<P>This is accepted by several front ends (g++, EDG), but
I now believe that 12.3.2&nbsp;



 <A HREF="special.html#class.conv.fct">class.conv.fct</A> paragraph 1
actually prohibits this.
The issue here is that we do in fact specify (part of)
a return type.</P>

<P>OTOH, I think it is legitimate to expect that this is
expressible in the language (preferably not using the
syntax above ;-).  Maybe we should extend the syntax
to allow the following alternative?</P>
<PRE>
  struct S {
    template&lt;typename T, int N&gt; operator (T(&amp;)[N])();
  };
</PRE>

<P>
<U>Eric Niebler</U>:
If the syntax is extended to support this, similar constructs should also be
considered.  For instance, I can't for the life of me figure out how to
write a conversion member function template to return a member function
pointer.  It could be useful if you were defining a null_t type.  This is
probably due to my own ignorance, but getting the syntax right is tricky.</P>

<P>Eg.</P>
<PRE>
  struct null_t {
    // null object pointer. works.
    template&lt;typename T&gt; operator T*() const { return 0; }
    // null member pointer. works.
    template&lt;typename T,typename U&gt; operator T U::*() const { return 0; }
    // null member fn ptr.  doesn't work (with Comeau online).  my error?
    template&lt;typename T,typename U&gt; operator T (U::*)()() const { return 0; }
  };
</PRE>

<P>
<U>Martin Sebor</U>:
Intriguing question. I have no idea how to do it in a single
declaration but splitting it up into two steps seems to work:</P>
<PRE>
  struct null_t {
    template &lt;class T, class U&gt;
    struct ptr_mem_fun_t {
      typedef T (U::*type)();
    };

    template &lt;class T, class U&gt;
    operator typename ptr_mem_fun_t&lt;T, U&gt;::type () const {
      return 0;
    }
  };
</PRE>

<P>
<I>Note:</I> In the April 2003 meeting, the core working group
noticed that the above doesn't actually work.</P>

<BR>
<BR>
<HR>
<A NAME="344"></A>
<H4>344.
  
Naming destructors
</H4>
<B>Section: </B>12.4&nbsp;



 <A HREF="special.html#class.dtor">class.dtor</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Jamie Schmeiser
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>25 April 2002<BR>


<P>Note that destructors suffer from similar problems as those of
constructors dealt with in <A HREF="
     cwg_defects.html#194">issue 194</A>
and in <A HREF="
     cwg_defects.html#263">263</A> (constructors as
friends).  Also, the wording in 12.4&nbsp;



 <A HREF="special.html#class.dtor">class.dtor</A>,
paragraph 1 does not permit a
destructor to be defined outside of the memberlist.</P>

<P>Change 12.4&nbsp;



 <A HREF="special.html#class.dtor">class.dtor</A>, paragraph 1 from</P>
<BLOCKQUOTE>
...A special declarator syntax using an optional <I>function-specifier</I>
(7.1.2&nbsp;



 <A HREF="dcl.html#dcl.fct.spec">dcl.fct.spec</A>) followed by <TT>~</TT> followed by
the destructor's class name followed
by an empty parameter list is used to declare the destructor in a
class definition.  In such a declaration, the <TT>~</TT> followed by the
destructor's class name can be enclosed in optional parentheses; such
parentheses are ignored....
</BLOCKQUOTE>
<P>to</P>
<BLOCKQUOTE>
...A special declarator syntax using an optional sequence of
<I>function-specifier</I>s (7.1.2&nbsp;



 <A HREF="dcl.html#dcl.fct.spec">dcl.fct.spec</A>),
an optional friend keyword, an optional
sequence of <I>function-specifier</I>s (7.1.2&nbsp;



 <A HREF="dcl.html#dcl.fct.spec">dcl.fct.spec</A>)
followed by an optional <TT>::</TT>
scope-resolution-operator followed by an optional
<I>nested-name-specifier</I> followed by <TT>~</TT>
followed by the destructor's class
name followed by an empty parameter list is used to declare the
destructor.  The optional <I>nested-name-specifier</I> shall not be specified
in the declaration of a destructor within the member-list of the class
of which the destructor is a member.  In such a declaration, the
optional <TT>::</TT> scope-resolution-operator followed by an optional
<I>nested-name-specifier</I> followed by <TT>~</TT>
 followed by the destructor's class
name can be enclosed in optional parentheses; such parentheses are
ignored....
</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="255"></A>
<H4>255.
  
Placement deallocation functions and lookup ambiguity
</H4>
<B>Section: </B>12.5&nbsp;



 <A HREF="special.html#class.free">class.free</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Mike Miller
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>26 Oct 2000<BR>


<P>Paragraph 4 of 12.5&nbsp;



 <A HREF="special.html#class.free">class.free</A> speaks of looking up a
deallocation function.  While it is an error if a placement
deallocation function alone is found by this lookup, there seems to be
an assumption that a placement deallocation function and a usual
deallocation function can both be declared in a given class scope
without creating an ambiguity.  The normal mechanism by which
ambiguity is avoided when functions of the same name are declared in
the same scope is overload resolution; however, there is no mention of
overload resolution in the description of the lookup.  In fact, there
appears to be nothing in the current wording that handles this case.
That is, the following example appears to be ill-formed, according to
the current wording:</P>

<PRE>
    struct S {
        void operator delete(void*);
        void operator delete(void*, int);
    };
    void f(S* p) {
        delete p;    // ill-formed: ambiguous operator delete
    }
</PRE>

<P>
<B>Suggested resolution</B> (Mike Miller, March 2002):</P>

<P>I think you might get the right effect by replacing
the last sentence of 12.5&nbsp;



 <A HREF="special.html#class.free">class.free</A> paragraph 4
with something like:</P>
<BLOCKQUOTE>
After removing all placement deallocation functions,
the result of the lookup shall contain an unambiguous
and accessible deallocation function.
</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="542"></A>
<H4>542.
  
Value initialization of arrays of POD-structs
</H4>
<B>Section: </B>12.6&nbsp;



 <A HREF="special.html#class.init">class.init</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Alisdair Meredith
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>27 October 2005<BR>


<P>12.6&nbsp;



 <A HREF="special.html#class.init">class.init</A> paragraph 2 says,</P>

<BLOCKQUOTE>

When an array of class objects is initialized (either explicitly or
implicitly), the constructor shall be called for each element of the
array, following the subscript order;

</BLOCKQUOTE>

<P>That implies that, given</P>

<PRE>
    struct POD {
      int x;
    };

    POD data[10] = {};
</PRE>

<P>this should call the implicitly declared default ctor 10 times,
leaving 10 uninitialized ints, rather than value initialize each
member of data, resulting in 10 initialized ints (which is required
by 8.5.1&nbsp;



 <A HREF="decl.html#dcl.init.aggr">dcl.init.aggr</A> paragraph 7).</P>

<P>I suggest rephrasing along the lines:</P>

<BLOCKQUOTE>

When an array is initialized (either explicitly or implicitly), each
element of the array shall be initialized in turn, following the
subscript order;

</BLOCKQUOTE>

<P>This would allow for PODs and other classes with a dual nature under
value/default initialization, and cover copy initialization for arrays
too.</P>

<BR>
<BR>
<HR>
<A NAME="257"></A>
<H4>257.
  
Abstract base constructors and virtual base initialization
</H4>
<B>Section: </B>12.6.2&nbsp;



 <A HREF="special.html#class.base.init">class.base.init</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Mike Miller
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>1 Nov 2000<BR>




<P>Must a constructor for an abstract base class provide a
<I>mem-initializer</I> for each virtual base class from which it is
directly or indirectly derived?  Since the initialization of
virtual base classes is performed by the most-derived class, and
since an abstract base class can never be the most-derived class,
there would seem to be no reason to require constructors for
abstract base classes to initialize virtual base classes.</P>

<P>It is not clear from the Standard whether there actually is
such a requirement or not.  The relevant text is found in
12.6.2&nbsp;



 <A HREF="special.html#class.base.init">class.base.init</A> paragraph 6:</P>

<BLOCKQUOTE>

All sub-objects representing virtual base classes are initialized by
the constructor of the most derived class (1.8&nbsp;



 <A HREF="intro.html#intro.object">intro.object</A>). If the constructor of the most derived class does not
specify a <I>mem-initializer</I> for a virtual base class <TT>V</TT>,
then <TT>V</TT>'s default constructor is called to initialize the virtual
base class subobject. If <TT>V</TT> does not have an accessible default
constructor, the initialization is ill-formed. A <I>mem-initializer</I>
naming a virtual base class shall be ignored during execution of the
constructor of any class that is not the most derived class.

</BLOCKQUOTE>

<P>This paragraph requires only that the most-derived class's
constructor have a <I>mem-initializer</I> for virtual base classes.
Should the silence be construed as permission for constructors
of classes that are not the most-derived to omit such
<I>mem-initializer</I>s?</P>

<P>
<U>Christopher Lester</U>, on comp.std.c++, March 19, 2004:
If any of you reading this posting happen to be members of the above
working group, I would like to encourage you to review the suggestion
contained therein, as it seems to me that the final tenor of the
submission is both (a) correct (the silence of the standard DOES
mandate the omission) and (b) describes what most users would
intuitively expect and desire from the C++ language as well.</P>

<P>The suggestion is to make it clearer that constructors for abstract
base classes should not be required to provide initialisers for any
virtual base classes they contain (as only the most-derived class has
the job of initialising virtual base classes, and an abstract base
class cannot possibly be a most-derived class).</P>

<P>For example:</P>
<PRE>
struct A {
  A(const int i, const int j) {};
};

struct B1 : virtual public A {
  virtual void moo()=0;
  B1() {};   // (1) Look! not "B1() : A(5,6) {};"
};

struct B2 : virtual public A {
  virtual void cow()=0;
  B2() {};   // (2) Look! not "B2() : A(7,8) {};"
};

struct C : public B1, public B2 {
  C() : A(2,3) {};
  void moo() {};
  void cow() {};
};

int main() {
  C c;
  return 0;
};
</PRE>

<P>I believe that, by not expressly forbidding it, the standard does
(and should!) allow the above code.  However, as the standard doesn't
expressly allow it either (have I missed something?) there appears to
be room for misunderstanding. For example, g++ version 3.2.3 (and
maybe other versions as well) rejects the above code with messages 
like:</P>
<PRE>
	In constructor `B1::B1()':
	no matching function for call to `A::A()'
	candidates are: A::A(const A&amp;)
         	        A::A(int, int)
</PRE>

<P>Fair enough, the standard is perhaps not clear enough.  But it seems
to be a shame that although this issue was first raised in 2000, we
are still living with it today.</P>

<P>Note that we can work-around, and persuade g++ to compile the above
by either (a) providing a default constructor A() for A, or (b)  
supplying default values for i and j in A(i,j), or (c) replace the
construtors B1() and B2() with the forms shown in the two comments in
the above example.</P>

<P>All three of these workarounds may at times be appropriate, but 
equally there are other times when all of these workarounds are 
particularly bad.  (a) and (b) may be very bad if you are trying to 
enforce string contracts among objects, while (c) is just barmy (I 
mean why did I have to invent random numbers like 5, 6, 7 and 8 just 
to get the code to compile?).</P>

<P>So to to round up, then, my plea to the working group is:

	"at the very least, please make the standard clearer on 
this issue, but preferrably make the decision to expressly allow 
code that looks something like the above"</P>

<BR>
<BR>
<HR>
<A NAME="111"></A>
<H4>111.
  
Copy constructors and cv-qualifiers
</H4>
<B>Section: </B>12.8&nbsp;



 <A HREF="special.html#class.copy">class.copy</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Jack Rouse
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>4 May 1999<BR>





<P>
<U>Jack Rouse:</U>
In 12.8&nbsp;



 <A HREF="special.html#class.copy">class.copy</A>
 paragraph 8,
the standard includes
the following about the copying of class subobjects in such a
constructor:</P>
<UL>
<LI>if the subobject is of class type, the copy constructor for
the class is used;</LI>
</UL>

But there can be multiple copy constructors declared by the user with
differing cv-qualifiers on the source parameter.  I would assume
overload resolution would be used in such cases.  If so then the
passage above seems insufficient.

<P>
<B>Mike Miller:</B>
I'm more concerned about
12.8&nbsp;



 <A HREF="special.html#class.copy">class.copy</A>
 paragraph 7,
which lists the situations in
which an implicitly-defined copy constructor can render a
program ill-formed.  Inaccessible and ambiguous copy
constructors are listed, but not a copy constructor with a
cv-qualification mismatch.  These two paragraphs taken together
could be read as requiring the calling of a copy constructor
with a non-const reference parameter for a const data member.</P>
<BR>
<BR>
<HR>
<A NAME="535"></A>
<H4>535.
  
Copy construction without a copy constructor
</H4>
<B>Section: </B>12.8&nbsp;



 <A HREF="special.html#class.copy">class.copy</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Mike Miller
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>7 October 2005<BR>


<P>Footnote 112 (12.8&nbsp;



 <A HREF="special.html#class.copy">class.copy</A> paragraph 2) says,</P>

<BLOCKQUOTE>

Because a template constructor is never a copy constructor, the
presence of such a template does not suppress the implicit declaration
of a copy constructor. Template constructors participate in overload
resolution with other constructors, including copy constructors, and a
template constructor may be used to copy an object if it provides a
better match than other constructors.

</BLOCKQUOTE>

<P>However, many of the stipulations about copy construction are
phrased to refer only to &ldquo;copy constructors.&rdquo;  For
example, 12.8&nbsp;



 <A HREF="special.html#class.copy">class.copy</A> paragraph 14 says,</P>

<BLOCKQUOTE>

A program is ill-formed if the copy constructor...
for an object is implicitly used and the special member
function is not accessible (clause 11&nbsp;



 <A HREF="access.html#class.access">class.access</A>).

</BLOCKQUOTE>

<P>Does that mean that using an inaccessible template constructor
to copy an object is permissible, because it is not a &ldquo;copy
constructor?&rdquo;  Obviously not, but each use of the term
&ldquo;copy constructor&rdquo; in the Standard should be examined
to determine if it applies strictly to copy constructors or to
any constructor used for copying.  (A similar issue applies to
&ldquo;copy assignment operators,&rdquo; which have the same
relationship to assignment operator function tempolates.)</P>

<BR>
<BR>
<HR>
<A NAME="545"></A>
<H4>545.
  
User-defined conversions and built-in operator overload resolution
</H4>
<B>Section: </B>13.3.1.2&nbsp;



 <A HREF="over.html#over.match.oper">over.match.oper</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Steve Clamage
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>31 October 2005<BR>




<P>Consider the following example:</P>

<PRE>
    class B1 {};
    typedef void (B1::*PB1) (); //<SPAN STYLE="font-family:Times"><I> memptr to </I></SPAN>B1

    class B2 {};
    typedef void (B2::*PB2) (); //<SPAN STYLE="font-family:Times"><I> memptr to </I></SPAN>B2

    class D1 : public B1, public B2 {};
    typedef void (D1::*PD) (); //<SPAN STYLE="font-family:Times"><I> memptr to </I></SPAN>D1

    struct S {
         operator PB1(); //<SPAN STYLE="font-family:Times"><I> can be converted to </I></SPAN>PD
    } s;
    struct T {
         operator PB2(); //<SPAN STYLE="font-family:Times"><I> can be converted to </I></SPAN>PD
    } t;

    void foo() {
         s == t; //<SPAN STYLE="font-family:Times"><I> Is this an error?</I></SPAN>
    }
</PRE>

<P>According to 13.6&nbsp;



 <A HREF="over.html#over.built">over.built</A> paragraph 16, there is an
<TT>operator==</TT> for <TT>PD</TT> (&ldquo;For every pointer to
member type...&rdquo;), so why wouldn't it be used for this
comparison?</P>

<P>
<U>Mike Miller</U>: The problem, as I understand it, is that
13.3.1.2&nbsp;



 <A HREF="over.html#over.match.oper">over.match.oper</A> paragraph 3, bullet 3, sub-bullet 3
is broader than it was intended to be.  It says that candidate
built-in operators must &ldquo;accept operand types to which the given
operand or operands can be converted according to 13.3.3.1&nbsp;



 <A HREF="over.html#over.best.ics">over.best.ics</A>.&rdquo; 13.3.3.1.2&nbsp;



 <A HREF="over.html#over.ics.user">over.ics.user</A>
describes user-defined conversions as having a second standard
conversion sequence, and there is nothing to restrict that second
standard conversion sequence.</P>

<P>My initial thought on addressing this would be to say that
user-defined conversion sequences whose second standard conversion
sequence contains a pointer conversion or a pointer-to-member
conversion are not considered when selecting built-in candidate
operator functions.  They would still be applicable after the hand-off
to Clause 5 (e.g., in bringing the operands to their common type,
5.10&nbsp;



 <A HREF="expr.html#expr.eq">expr.eq</A>, or composite pointer type, 5.9&nbsp;



 <A HREF="expr.html#expr.rel">expr.rel</A>), just not in constructing the list of built-in
candidate operator functions.</P>

<P>I started to suggest restricting the second standard conversion
sequence to conversions having Promotion or Exact Match rank, but that
would exclude the Boolean conversions, which are needed
for <TT>!</TT>, <TT>&amp;&amp;</TT>, and <TT>||</TT>.  (It would have
also restricted the floating-integral conversions, though, which might
be a good idea.  They can't be used implicitly, I think, because there
would be an ambiguity among all the promoted integral types; however,
none of the compilers I tested even tried those conversions because
the errors I got were not ambiguities but things like &ldquo;floating
point operands not allowed for <TT>%</TT>&rdquo;.)</P>

<P>
<U>Bill Gibbons</U>: I recall seeing this problem before, though
possibly not in committee discussions.  As written this rule makes the
set of candidate functions dependent on what classes have been
defined, including classes not otherwise required to have been defined
in order for "==" to be meaningful.  For templates this implies that
the set is dependent on what templates have been instantiated,
e.g.</P>

<PRE>
  template&lt;class T&gt; class U : public T { };
  U&lt;B1&gt; u;  //<SPAN STYLE="font-family:Times"><I> changes the set of candidate functions to include</I></SPAN>
            //<SPAN STYLE="font-family:Times"><I> </I></SPAN>operator==(U&lt;B1&gt;,U&lt;B1&gt;)<SPAN STYLE="font-family:Times"><I>?</I></SPAN>
</PRE>

<P>There may be other places where the existence of a class
definition, or worse, a template instantiation, changes the semantics
of an otherwise valid program (e.g. pointer conversions?) but it seems
like something to be avoided.</P>

<BR>
<BR>
<HR>
<A NAME="418"></A>
<H4>418.
  
Imperfect wording on error on multiple default arguments on a called function
</H4>
<B>Section: </B>13.3.3&nbsp;



 <A HREF="over.html#over.match.best">over.match.best</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Chris Bowler
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>27 May 2003<BR>




<P>According to
13.3.3&nbsp;



 <A HREF="over.html#over.match.best">over.match.best</A> paragraph 4, the following program
appears to be ill-formed:</P>
<PRE>
  void f(int, int=0);
  void f(int=0, int);

  void g() {
    f();
  }
</PRE>
<P>Though I do not expect this is the intent of this paragraph in the
standard.</P>

<P>13.3.3&nbsp;



 <A HREF="over.html#over.match.best">over.match.best</A> paragraph 4:</P>
<BLOCKQUOTE>
If the best viable function resolves to a function for which multiple
declarations were found, and if at least
two of these declarations or the declarations they refer to in the case of
using-declarations specify a
default argument that made the function viable, the program is ill-formed.
[Example:
<PRE>
namespace A {
  extern "C" void f(int = 5);
}
namespace B {
  extern "C" void f(int = 5);
}
using A::f;
using B::f;
void use() {
f(3); //OK, default argument was not used for viability
f(); //Error: found default argument twice
}
</PRE>
end example]</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="455"></A>
<H4>455.
  
Partial ordering and non-deduced arguments
</H4>
<B>Section: </B>13.3.3&nbsp;



 <A HREF="over.html#over.match.best">over.match.best</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Rani Sharoni
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>19 Jan 2004<BR>


<P>
It's not clear how overloading and partial ordering handle non-deduced pairs
of corresponding arguments. For example:</P>
<PRE>
template&lt;typename T&gt;
struct A { typedef char* type; };

template&lt;typename T&gt; char* f1(T, typename A&lt;T&gt;::type);  // #1
template&lt;typename T&gt; long* f1(T*, typename A&lt;T&gt;::type*); // #2

long* p1 = f1(p1, 0); // #3
</PRE>
<P>I thought that #3 is ambiguous but different compilers disagree on that.
Comeau C/C++ 4.3.3 (EDG 3.0.3) accepted the code, GCC 3.2 and BCC 5.5
selected #1 while VC7.1+ yields ambiguity.</P>

<P>I intuitively thought that the second pair should prevent overloading from
triggering partial ordering since both arguments are non-deduced and has
different types - (char*, char**). Just like in the following:</P>
<PRE>
template&lt;typename T&gt; char* f2(T, char*);   // #3
template&lt;typename T&gt; long* f2(T*, char**); // #4

long* p2 = f2(p2, 0); // #5
</PRE>
<P>In this case all the compilers I checked found #5 to be ambiguous.
The standard and DR <A HREF="
     cwg_defects.html#214">214</A> is not clear
about how partial ordering handle such
cases.</P>

<P>I think that overloading should not trigger partial ordering (in step
13.3.3&nbsp;



 <A HREF="over.html#over.match.best">over.match.best</A>/1/5) if some candidates have
non-deduced pairs with different
(specialized) types. In this stage the arguments are already adjusted so no
need to mention it (i.e. array to pointer). In case that one of the
arguments is non-deuced then partial ordering should only consider the type
from the specialization:</P>
<PRE>
template&lt;typename T&gt; struct B { typedef T type; };

template&lt;typename T&gt; char* f3(T, T);                   // #7
template&lt;typename T&gt; long* f3(T, typename B&lt;T&gt;::type); // #8

char* p3 = f3(p3, p3); // #9
</PRE>
<P>According to my reasoning #9 should yield ambiguity since second pair is (T,
long*). The second type (i.e. long*) was taken from the specialization
candidate of #8.
EDG and GCC accepted the code. VC and BCC found an ambiguity.</P>

<P>
<U>John Spicer:</U>
There may (or may not) be an issue concerning whether nondeduced
contexts are handled properly in the partial ordering rules.  In
general, I think nondeduced contexts work, but we should walk through
some examples to make sure we think they work properly.</P>

<P>Rani's description of the problem suggests that he believes that
partial ordering is done on the specialized types.  This is not
correct.  Partial ordering is done on the templates themselves,
independent of type information from the specialization.</P>

<P>
<B>Notes from October 2004 meeting:</B>
</P>

<P>John Spicer will investigate further to see if any action is
required.</P>

<BR>
<BR>
<HR>
<A NAME="507"></A>
<H4>507.
  
Ambiguity assigning class object to built-in type
</H4>
<B>Section: </B>13.6&nbsp;



 <A HREF="over.html#over.built">over.built</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Steve Adamczyk
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>9 Mar 2005<BR>


<P>The following example is ambiguous according to the Standard:</P>

<PRE>
    struct Y {
      operator int();
      operator double();
    };
    void f(Y y) {
      double d;
      d = y;    //<SPAN STYLE="font-family:Times"><I> Ambiguous: </I></SPAN>Y::operator int()<SPAN STYLE="font-family:Times"><I> or </I></SPAN>Y::operator double()<SPAN STYLE="font-family:Times"><I>?</I></SPAN>
    }
</PRE>

<P>The reason for the ambiguity is that 13.6&nbsp;



 <A HREF="over.html#over.built">over.built</A>
paragraph 18 says that there are candidate functions
<TT>double&amp;&nbsp;operator=(double&amp;,&nbsp;int)</TT> and
<TT>double&amp;&nbsp;operator=(double&amp;,&nbsp;double)</TT> (among
others).  In each case, the second argument is converted by a
user-defined conversion sequence (13.3.3.1.2&nbsp;



 <A HREF="over.html#over.ics.user">over.ics.user</A>)
where the initial and final standard conversion sequences are the
identity conversion &mdash; i.e., the conversion sequences for the
second argument are indistinguishable for each of these candidate
functions, and they are thus ambiguous.</P>

<P>Intuitively one might expect that, because it converts directly
to the target type in the assignment, <TT>Y::operator&nbsp;double()</TT>
would be selected, and in fact, most compilers do select it, but there
is currently no rule to distinghish between these user-defined
conversions.  Should there be?</P>

<BR>
<BR>
<HR>
<A NAME="110"></A>
<H4>110.
  
Can template functions and classes be declared in the same scope?
</H4>
<B>Section: </B>14&nbsp;



 <A HREF="template.html#temp">temp</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>John Spicer
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>28 Apr 1999<BR>




<P>According to 14&nbsp;



 <A HREF="template.html#temp">temp</A>
 paragraph 5,</P>
<BLOCKQUOTE>

Except that a function template can be overloaded either by
(non-template) functions with the same name or by other function
templates with the same name
(14.8.3&nbsp;



 <A HREF="template.html#temp.over">temp.over</A>
), a template name declared
in namespace scope or in class scope shall be unique in that scope.

</BLOCKQUOTE>
3.3.7&nbsp;



 <A HREF="basic.html#basic.scope.hiding">basic.scope.hiding</A>
 paragraph 2 agrees
that only functions, not function templates, can hide a class name
declared in the same scope:
<BLOCKQUOTE>

A class name (9.1&nbsp;



 <A HREF="class.html#class.name">class.name</A>
) or
enumeration name (7.2&nbsp;



 <A HREF="dcl.html#dcl.enum">dcl.enum</A>
) can be
hidden by the name of an object, function, or enumerator declared in
the same scope.

</BLOCKQUOTE>
However, 3.3&nbsp;



 <A HREF="basic.html#basic.scope">basic.scope</A>
 paragraph 4
treats functions and template functions together in this regard:
<BLOCKQUOTE>

Given a set of declarations in a single declarative region, each of
which specifies the same unqualified name,

<UL>
<LI>they shall all refer to the same entity, or all refer to functions
and function templates; or</LI>

<LI>exactly one declaration shall declare a class name or enumeration
name that is not a typedef name and the other declarations shall all
refer to the same object or enumerator, or all refer to functions and
function templates; in this case the class name or enumeration name is
hidden</LI>

</UL>
</BLOCKQUOTE>

<P>
<B>John Spicer:</B> You should be able to take an existing program
and replace an existing function with a function template without
breaking unrelated parts of the program.

In addition, all of the compilers I tried allow this usage (EDG, Sun,
egcs, Watcom, Microsoft, Borland).

I would recommend that function templates be handled exactly like functions
for purposes of name hiding.</P>

<P>
<B>Martin O'Riordan:</B> I don't see any justification for extending
the purview of what is decidedly a hack, just for the sake of consistency.
In fact, I think we should go further and in the interest of consistency, we
should deprecate the hack, scheduling its eventual removal from the C++
language standard.</P>

<P>The hack is there to allow old C programs and especially the
'stat.h' file to compile with minimum effort (also several other Posix and X
headers).  People changing such older programs have ample opportunity to "do
it right".  Indeed, if you are adding templates to an existing program, you
should probably be placing your templates in a 'namespace', so the issue
disappears anyway.  The lookup rules should be able to provide the behaviour
you need without further hacking.</P>
<BR>
<BR>
<HR>
<A NAME="534"></A>
<H4>534.
  
<I>template-name</I>s and <I>operator-function-id</I>s
</H4>
<B>Section: </B>14&nbsp;



 <A HREF="template.html#temp">temp</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Jens Maurer
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>5 October 2005<BR>


<P>Taken literally, 14&nbsp;



 <A HREF="template.html#temp">temp</A> paragraph 2 does not
permit operator functions to be templates:</P>

<BLOCKQUOTE>

In a function template declaration, the <I>declarator-id</I> shall be a
<I>template-name</I> (i.e., not a <I>template-id</I>).

</BLOCKQUOTE>

<P>and, in <section-ref>14.2&nbsp;



 <A HREF="template.html#temp.names">temp.names</A></section-ref> paragraph 1, a <I>template-name</I>
is defined to be simply an <I>identifier</I>.</P>

<P>
<A HREF="
     cwg_active.html#301">Issue 301</A> considered and rejected the
idea of changing the definition of <I>template-name</I> to include
<I>operator-function-id</I>s and <I>conversion-function-id</I>s.
Either that decision should be reconsidered or the various references
in the text to <I>template-name</I> should be examined to determine
if they should also mention the non-<I>identifier</I> possibilities
for function template names.</P>

<BR>
<BR>
<HR>
<A NAME="343"></A>
<H4>343.
  
Make <TT>template</TT> optional in contexts that require a type
</H4>
<B>Section: </B>14.2&nbsp;



 <A HREF="template.html#temp.names">temp.names</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Steve Adamczyk
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>23 April 2002<BR>


<P>By analogy with <TT>typename</TT>, the keyword <TT>template</TT>
used to indicate that a dependent name will be a template name should
be optional in contexts where a type is required, e.g.,
base class lists.  We could also consider member and parameter
declarations.</P>

<P>This was suggested by <A HREF="
     cwg_active.html#314">issue 314</A>.</P>

<BR>
<BR>
<HR>
<A NAME="440"></A>
<H4>440.
  
Allow implicit pointer-to-member conversion on nontype template argument
</H4>
<B>Section: </B>14.3&nbsp;



 <A HREF="template.html#temp.arg">temp.arg</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>David Abrahams
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>13 Nov 2003<BR>


<P>None of my compilers accept this, which surprised me a little.  Is
the base-to-derived member function conversion considered to be a
runtime-only thing?</P>
<PRE>
  template &lt;class D&gt;
  struct B
  {
      template &lt;class X&gt; void f(X) {}
      template &lt;class X, void (D::*)(X) = &amp;B&lt;D&gt;::f&lt;X&gt; &gt;
      struct row {};
  };
  struct D : B&lt;D&gt;
  {
      void g(int);
      row&lt;int,&amp;D::g&gt; r1;
      row&lt;char*&gt; r2;
  };
</PRE>
<P>
<U>John Spicer</U>:
This is not among the permitted conversions listed in 14.3.</P>

<P>I'm not sure there is a terribly good reason for that.  Some of the
template argument rules for external entities were made conservatively
because of concerns about issues of mangling template argument names.</P>

<P>
<U>David Abrahams</U>:
I'd really like to see that restriction loosened.  It is a serious
inconvenience because there appears to be no way to supply a usable
default in this case.  Zero would be an OK default if I could use the
function pointer's equality to zero as a compile-time switch to
choose an empty function implementation:</P>
<PRE>
  template &lt;bool x&gt; struct tag {};

  template &lt;class D&gt;
  struct B
  {
      template &lt;class X&gt; void f(X) {}

      template &lt;class X, void (D::*pmf)(X) = 0 &gt;
      struct row {
          void h() { h(tag&lt;(pmf == 0)&gt;(), pmf); }
          void h(tag&lt;1&gt;, ...) {}
          void h(tag&lt;0&gt;, void (D::*q)(X)) { /*something*/}
      };
  };

  struct D : B&lt;D&gt;
  {
      void g(int);
      row&lt;int,&amp;D::g&gt; r1;
      row&lt;char*&gt; r2;
  };
</PRE>

<P>But there appears to be no way to get that effect either.  The result
is that you end up doing something like:</P>
<PRE>
      template &lt;class X, void (D::*pmf)(X) = 0 &gt;
      struct row {
          void h() { if (pmf) /*something*/ }
      };
</PRE>

<P>which invariably makes compilers warn that you're switching on a
constant expression.</P>

<BR>
<BR>
<HR>
<A NAME="549"></A>
<H4>549.
  
Non-deducible parameters in partial specializations
</H4>
<B>Section: </B>14.5.4.1&nbsp;



 <A HREF="template.html#temp.class.spec.match">temp.class.spec.match</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Martin Sebor
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>18 November 2005<BR>


<P>In the following example, the template parameter in the partial
specialization is non-deducible:</P>

<PRE>
    template &lt;class T&gt; struct A { typedef T U; };
    template &lt;class T&gt; struct C { };
    template &lt;class T&gt; struct C&lt;typename A&lt;T&gt;::U&gt; { };
</PRE>

<P>Several compilers issue errors for this case, but there appears
to be nothing in the Standard that would make this ill-formed; it
simply seems that the partial specialization will never be matched,
so the primary template will be used for all specializations.
Should it be ill-formed?</P>

<BR>
<BR>
<HR>
<A NAME="310"></A>
<H4>310.
  
Can function templates differing only in parameter cv-qualifiers be overloaded?
</H4>
<B>Section: </B>14.5.5.1&nbsp;



 <A HREF="template.html#temp.over.link">temp.over.link</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Andrei Iltchenko
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>29 Aug 2001<BR>


<P>I get the following error diagnostic [from the EDG front end]:
<PRE>
line 8: error: function template "example&lt;T&gt;::foo&lt;R,A&gt;(A)" has
          already been declared
     R  foo(const A);
        ^
</PRE>
when compiling this piece of code:
<PRE>
struct  example  {
   template&lt;class R, class A&gt;   // 1-st member template
   R  foo(A);
   template&lt;class R, class A&gt;   // 2-nd member template
   const R  foo(A&amp;);
   template&lt;class R, class A&gt;   // 3-d  member template
   R  foo(const A);
};

/*template&lt;&gt; template&lt;&gt;
int  example&lt;char&gt;::foo(int&amp;);*/


int  main()
{
   int  (example&lt;char&gt;::* pf)(int&amp;) =
      &amp;example&lt;char&gt;::foo;
}
</PRE>
</P>

<P>The implementation complains that
<PRE>
   template&lt;class R, class A&gt;   // 1-st member template
   R  foo(A);
   template&lt;class R, class A&gt;   // 3-d  member template
   R  foo(const A);
</PRE>
cannot be overloaded and I don't see any reason for it
since it is function template specializations that are
treated like ordinary non-template functions, meaning
that the transformation of a
parameter-declaration-clause into the corresponding
parameter-type-list is applied to specializations
(when determining its type) and not to function
templates.</P>

<P>What makes me think so is the contents of 14.5.5.1&nbsp;



 <A HREF="template.html#temp.over.link">temp.over.link</A>
and the following sentence from 14.8.2.1&nbsp;



 <A HREF="template.html#temp.deduct.call">temp.deduct.call</A> "If P is a
cv-qualified type, the top level cv-qualifiers of P
are ignored for type deduction". If the transformation
was to be applied to function templates, then there
would be no reason for having that sentence in
14.8.2.1&nbsp;



 <A HREF="template.html#temp.deduct.call">temp.deduct.call</A>.</P>

<P>14.8.2.2&nbsp;



 <A HREF="template.html#temp.deduct.funcaddr">temp.deduct.funcaddr</A>, which my example is
based upon, says nothing
about ignoring the top level cv-qualifiers of the
function parameters of the function template whose
address is being taken.</P>

<P>As a result, I expect that template argument deduction
will fail for the 2-nd and 3-d member templates and
the 1-st one will be used for the instantiation of the
specialization.</P>

<BR>
<BR>
<HR>
<A NAME="23"></A>
<H4>23.
  
Some questions regarding partial ordering of function templates
</H4>
<B>Section: </B>14.5.5.2&nbsp;



 <A HREF="template.html#temp.func.order">temp.func.order</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>unknown
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown<BR>





<P>
<U><B>Issue 1:</B></U>
</P>

<P>14.5.5.2&nbsp;



 <A HREF="template.html#temp.func.order">temp.func.order</A>
 paragraph 2 says:
<BLOCKQUOTE>Given two overloaded function templates, whether one is more
specialized than another can be determined by transforming each template
in turn and using argument deduction (14.8.2&nbsp;



 <A HREF="template.html#temp.deduct">temp.deduct</A>
) to compare it to the other.</BLOCKQUOTE>
14.8.2&nbsp;



 <A HREF="template.html#temp.deduct">temp.deduct</A>
 now has 4 subsections describing argument deduction in different
situations. I think this paragraph should point to a subsection of
14.8.2&nbsp;



 <A HREF="template.html#temp.deduct">temp.deduct</A>
.</P>

<P>
<B>Rationale:</B>
</P>

<P>This is not a defect; it is not necessary to pinpoint cross-references
to this level of detail.</P>

<P>
<B><U>Issue 2:</U></B>
</P>

<P>14.5.5.2&nbsp;



 <A HREF="template.html#temp.func.order">temp.func.order</A>
 paragraph 4 says:</P>
<BLOCKQUOTE>Using the transformed function parameter list, perform argument
deduction against the other function template. The transformed template
is at least as specialized as the other if, and only if, the deduction
succeeds and the deduced parameter types are an exact match (so the deduction
does not rely on implicit conversions).</BLOCKQUOTE>
In "the deduced parameter types are an exact match", the terms exact match
do not make it clear what happens when a type T is compared to the reference
type T&amp;. Is that an exact match?



<P>
<B><U>Issue 3:</U></B>
</P>

<P>14.5.5.2&nbsp;



 <A HREF="template.html#temp.func.order">temp.func.order</A>
 paragraph 5 says:</P>
<BLOCKQUOTE>A template is more specialized than another if, and only if,
it is at least as specialized as the other template and that template is
not at least as specialized as the first.</BLOCKQUOTE>
What happens in this case:
<PRE>
    template&lt;class T&gt; void f(T,int);
    template&lt;class T&gt; void f(T, T);
    void f(1,1);
</PRE>
For the first function template, there is no type deduction for the second
parameter. So the rules in this clause seem to imply that the second function
template will be chosen.

<P>
<B>Rationale:</B>
</P>

<P>This is not a defect; the standard unambiguously makes the above example
ill-formed due to ambiguity.</P>
<BR>
<BR>
<HR>
<A NAME="402"></A>
<H4>402.
  
More on partial ordering of function templates
</H4>
<B>Section: </B>14.5.5.2&nbsp;



 <A HREF="template.html#temp.func.order">temp.func.order</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Nathan Sidwell
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>7 Apr 2003<BR>




<P>This was split off from <A HREF="
     cwg_defects.html#214">issue 214</A> at
the April 2003 meeting.</P>

<P>
<U>Nathan Sidwell</U>:
John Spicer's proposed resolution does not make the following
well-formed.</P>
<PRE>
  template &lt;typename T&gt; int Foo (T const *) {return 1;} //#1
  template &lt;unsigned I&gt; int Foo (char const (&amp;)[I]) {return 2;} //#2

  int main ()
  {
    return Foo ("a") != 2;
  }
</PRE>
<P>Both #1 and #2 can deduce the "a" argument, #1 deduces T as char and
#2 deduces I as 2. However, neither is more specialized because the
proposed rules do not have any array to pointer decay.</P>

<P>#1 is only deduceable because of the rules in
14.8.2.1&nbsp;



 <A HREF="template.html#temp.deduct.call">temp.deduct.call</A> paragraph 2 that
decay array and function type arguments when the template parameter is
not a reference. Given that such behaviour happens in deduction, I believe
there should be equivalent behaviour during partial ordering. #2 should be
resolved as more specialized as #1. The following alteration to the
proposed resolution of DR214 will do that.</P>

<P>Insert before,</P>
<UL>
<LI>If A is a cv-qualified type, A is replaced by the
         cv-unqualified version of A.</LI>
</UL>
<P>the following</P>
<UL>
<LI>If P was not originally a reference type,
<UL>
<LI>If A is an array type, A is replaced by the pointer type produced
            by the array to pointer conversion</LI>
<LI>If A is a function type, A is replaced by the pointer type
            produced by the function to pointer conversion</LI>
</UL>
</LI>
</UL>

<P>For the example above, this change results in deducing 'T const *' against
'char const *' in one direction (which succeeds), and 'char [I]'
against 'T const *' in the other (which fails).</P>

<P>
<U>John Spicer</U>:
I don't consider this a shortcoming of my proposed wording, as I don't
think this is part of the current rules.  In other words, the
resolution of 214 might make it clearer how this case is handled
(i.e., clearer that it is not allowed), but I don't believe it
represents a change in the language.</P>

<P>I'm not necessarily opposed to such a change, but I think it should be
reviewed by the core group as a related change and not a defect in the
proposed resolution to 214.</P>

<P>
<B>Notes from the October 2003 meeting:</B>
</P>

<P>There was some sentiment that it would be desirable to have
this case ordered, but we don't think it's worth spending the
time to work on it now.  If we look at some larger partial
ordering changes at some point, we will consider this again.</P>

<BR>
<BR>
<HR>
<A NAME="532"></A>
<H4>532.
  
Member/nonmember operator template partial ordering
</H4>
<B>Section: </B>14.5.5.2&nbsp;



 <A HREF="template.html#temp.func.order">temp.func.order</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Nathan Sidwell
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>16 September 2005<BR>




<P>The Standard does not specify how member and nonmember function
templates are to be ordered.  This question arises with an example
like the following:</P>

<PRE>
    struct A {
        template&lt;class T&gt; void operator&lt;&lt;(T&amp;);
    };

    template&lt;class T&gt; struct B { };
    template&lt;class T&gt; void operator&lt;&lt;(A&amp;, B&lt;T&gt;&amp;);

    int main() {
        A a;
        B&lt;A&gt; b;
        a &lt;&lt; b;
    }
</PRE>

<P>The two candidates for &ldquo;<TT>a &lt;&lt; b</TT>&rdquo; are:</P>

<OL>

<LI>
<TT>A::operator&lt;&lt; &lt;B&lt;A&gt; &gt;(B&lt;A&gt;&amp;)</TT>
</LI>

<LI>
<TT>::operator&lt;&lt; &lt;A&gt;(A&amp;, B&lt;A&gt;&amp;)</TT>
</LI>

</OL>

<P>How should we treat the implicit <TT>this</TT> parameter of #1 and the
explicit first parameter of #2?</P>

<UL>

<P>Option 0: Make them unordered.</P>

<P>Option 1: If either function is a non-static member function, ignore
any <TT>this</TT> parameter and ignore the first parameter of any
non-member function.  This option will select #2, as
&ldquo;<TT>B&lt;T&gt;&amp;</TT>&rdquo; is more specialized than
&ldquo;<TT>T&amp;</TT>&rdquo;.</P>

<P>Option 2: Treat the <TT>this</TT> parameter as if it were of
reference to object type, and then perform comparison to the first
parameter of the other function.  The other function's first parameter
will either be another <TT>this</TT> parameter, or it will be a
by-value or by-reference object parameter.  In the example above,
this option will also select #2.</P>

</UL>

<P>The difference between option 1 and option 2 can be seen in the
following example:</P>

<PRE>
    struct A { };

    template&lt;class T&gt; struct B {
        template&lt;typename R&gt; int operator*(R&amp;);   //<SPAN STYLE="font-family:Times"><I> #1</I></SPAN>
    };

    template &lt;typename T&gt; int operator*(T&amp;, A&amp;);  //<SPAN STYLE="font-family:Times"><I> #2</I></SPAN>

    int main() {
        A a;
        B&lt;A&gt; b;
        b * a;
    }
</PRE>

<P>Should this select #1, select #2, or be ambiguous?  Option 1 will
select #2, because &ldquo;<TT>A&amp;</TT>&rdquo; is more specialized
than &ldquo;<TT>T&amp;</TT>&rdquo;.  Option 2 will make this example
ambiguous, because &ldquo;<TT>B&lt;A&gt;&amp;</TT>&rdquo; is more
specialized than &ldquo;<TT>T&amp;</TT>&rdquo;.</P>

<P>If one were considering two non-member templates,</P>

<PRE>
    template &lt;typename T&gt; int operator*(T&amp;, A&amp;);                 //<SPAN STYLE="font-family:Times"><I> #2</I></SPAN>
    template &lt;typename T, typename R&gt; int operator*(B&lt;A&gt;&amp;, R&amp;);  //<SPAN STYLE="font-family:Times"><I> #3</I></SPAN>
</PRE>

<P>the current rules would make these unordered.  Option 2 thus seems
more consistent with this existing behavior.</P>

<BR>
<BR>
<HR>
<A NAME="186"></A>
<H4>186.
  
Name hiding and template <I>template-parameter</I>s
</H4>
<B>Section: </B>14.6.1&nbsp;



 <A HREF="template.html#temp.local">temp.local</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>John Spicer
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>11 Nov 1999<BR>





<P>The standard prohibits a class template from having the same name as
one of its template parameters
(14.6.1&nbsp;



 <A HREF="template.html#temp.local">temp.local</A>
 paragraph 4).  This prohibits</P>

<PRE>
    template &lt;class X&gt; class X;
</PRE>

for the reason that the template name would hide the parameter, and
such hiding is in general prohibited.

<P>Presumably, we should also prohibit</P>

<PRE>
    template &lt;template &lt;class T&gt; class T&gt; struct A;
</PRE>

for the same reason.
<BR>
<BR>
<HR>
<A NAME="459"></A>
<H4>459.
  
Hiding of template parameters by base class members
</H4>
<B>Section: </B>14.6.1&nbsp;



 <A HREF="template.html#temp.local">temp.local</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Daveed Vandevoorde
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>2 Feb 2004<BR>


<P>Currently, member of nondependent base classes hide
references to template parameters in the definition
of a derived class template.</P>

<P>Consider the following example:</P>
<PRE>
   class B {
      typedef void *It;    // (1)
      // ...
    };

    class M: B {};

    template&lt;typename&gt; X {};

    template&lt;typename It&gt; struct S   // (2)
        : M, X&lt;It&gt; {   // (3)
      S(It, It);   // (4)
      // ...
    };
</PRE>
<P>As the C++ language currently stands, the name "It"
in line (3) refers to the template parameter declared
in line (2), but the name "It" in line (4) refers to
the typedef in the private base class (declared in
line (1)).</P>

<P>This situation is both unintuitive and a hindrance
to sound software engineering.  (See also the Usenet
discussion at http://tinyurl.com/32q8d .)  Among
other things, it implies that the private section
of a base class may change the meaning of the derived
class, and (unlike other cases where such things
happen) there is no way for the writer of the derived
class to defend the code against such intrusion (e.g.,
by using a qualified name).</P>

<P>Changing this can break code that is valid today.
However, such code would have to:
<OL>
<LI>
name a template parameter and not use it
         after the opening brace, and
</LI>
<LI>
use that same name to access a base-class
         name within the braces.
</LI>
</OL>
I personally have no qualms breaking such a program.</P>

<P>It has been suggested to make situations like these
ill-formed.  That solution is unattractive however
because it still leaves the writer of a derived class
template without defense against accidental name
conflicts with base members.  (Although at least the
problem would be guaranteed to be caught at compile
time.)  Instead, since just about everyone's intuition
agrees, I would like to see the rules changed to
make class template parameters hide members of the
same name in a base class.</P>

<P>See also <A HREF="
     cwg_active.html#458">issue 458</A>.</P>

<P>
<B>Notes from the March 2004 meeting:</B>
</P>

<P>We have some sympathy for a change, but the current rules fall
straightforwardly out of the lookup rules, so they're not
&ldquo;wrong.&rdquo; Making private members invisible also would solve
this problem.  We'd be willing to look at a paper proposing that.</P>

<P>
<B>Additional discussion (April, 2005):</B>
</P>



<P>
<U>John Spicer</U>: Base class members are more-or-less treated as
members of the class, [so] it is only natural that the base [member]
would hide the template parameter.</P>

<P>
<U>Daveed Vandevoorde</U>: Are base class members really
&ldquo;more or less&rdquo; members of the class from a lookup
perspective?  After all, derived class members can hide base class
members of the same name.  So there is some pretty definite
boundary between those two sets of names.  IMO, the template
parameters should either sit between those two sets, or they
should (for lookup purposes) be treated as members of the class
they parameterize (I cannot think of a practical difference
between those two formulations).</P>

<P>
<U>John Spicer</U>: How is [hiding template parameters]
different from the fact that namespace members can be hidden
by private parts of a base class?  The addition of <TT>int C</TT>
to <TT>N::A</TT> breaks the code in namespace <TT>M</TT> in this
example:</P>

<PRE>
    namespace N {
       class A {
    private:
         int C;
       };
    }

    namespace M {
       typedef int C;
       class B : public N::A {
         void f() {
             C c;
         }
       };
    }
</PRE>

<P>
<U>Daveed Vandevoorde</U>: C++ has a mechanism in place to handle
such situations: qualified names.  There is no such mechanism in place
for template parameters.</P>

<P>
<U>Nathan Myers</U>: What I see as obviously incorrect ... is
simply that a name defined right where I can see it, and directly
attached to the textual scope of <TT>B</TT>'s class body, is ignored
in favor of something found in some other file.  I don't care that
<TT>C1</TT> is defined in <TT>A</TT>, I have a <TT>C1</TT> right
here that I have chosen to use.  If I want <TT>A::C1</TT>, I can
say so.</P>

<P>I doubt you'll find any regular C++ coder who doesn't find the
standard behavior bizarre.  If the meaning of any code is changed
by fixing this behavior, the overwhelming majority of cases will
be mysterious bugs magically fixed.</P>

<P>
<U>John Spicer</U>: I have not heard complaints that this is
actually a cause of problems in real user code.  Where is the
evidence that the status quo is actually causing problems?</P>

<P>In this example, the <TT>T2</TT> that is found is the one from
the base class.  I would argue that this is natural because base
class members are found as part of the lookup in class <TT>B</TT>:</P>

<PRE>
    struct A {
             typedef int T2;
    };
    template &lt;class T2&gt; struct B : public A {
             typedef int T1;
             T1 t1;
             T2 t2;
    };
</PRE>

<P>This rule that base class members hide template parameters was
formalized about a dozen years ago because it fell out of the
principle that base class members should be found at the same
stage of lookup as derived class members, and that to do otherwise
would be surprising.</P>

<P>
<U>Gabriel Dos Reis</U>: The bottom line is that:</P>

<OL>

<LI>the proposed change is a <B>silent</B> change of meaning;</LI>

<LI>the proposed change does not make the language any more regular;
the current behavior is consistent with everything else, however
&ldquo;surprising&rdquo; that might be;</LI>

<LI>the proposed change does have its own downsides.</LI>

</OL>

<P>Unless presented with real major programming problems the current
rules exhibit, I do not think the simple rule &ldquo;scopes
nest&rdquo; needs a change that silently mutates program meaning.</P>

<P>
<U>Mike Miller</U>: The rationale for the current specification is
really very simple:</P>

<OL>

<LI>&ldquo;Unless redeclared in the derived class, members of a base
class are also considered to be members of the derived class.&rdquo;
(10&nbsp;



 <A HREF="derived.html#class.derived">class.derived</A> paragraph 2)</LI>

<LI>In class scope, members hide nonmembers.</LI>

</OL>

<P>That's it.  Because template parameters are not members, they
are hidden by member names (whether inherited or not).  I don't find
that &ldquo;bizarre,&rdquo; or even particularly surprising.</P>

<P>I believe these rules are straightforward and consistent, so I
would be opposed to changing them.  However, I am not unsympathetic
toward Daveed's concern about name hijacking from base classes.  How
about a rule that would make a program ill-formed if a direct or
inherited member hides a template parameter?</P>

<P>Unless this problem is a lot more prevalent than I've heard so
far, I would not want to change the lookup rules; making this kind of
collision a diagnosable error, however, would prevent hijacking
without changing the lookup rules.</P>

<P>
<U>Erwin Unruh</U>: I have a different approach that is consistent
and changes the interpretation of the questionable code.  At present
lookup is done in this sequence:</P>

<UL>
block scope<BR>
derived class scope<BR>
base class scope<BR>
template parameters<BR>
namespace scope
</UL>

<P>If we change this order to</P>

<UL>
template parameters<BR>
block scope<BR>
derived class scope<BR>
base class scope<BR>
namespace scope<BR>
</UL>

<P>it is still consistent in that no lookup is placed between the base
class and the derived class.  However, it introduces another
inconsistency: now scopes do not nest the same way as curly braces
nest &mdash; but base classes are already inconsistent this way.</P>

<P>
<U>Nathan Myers</U>: This looks entirely satisfactory.  If even this
seems like too big a change, it would suffice to say that finding a
different name by this search order makes the program ill-formed.
Of course, a compiler might issue only a portability warning in that
case and use the name found Erwin's way, anyhow.</P>

<P>
<U>Gabriel Dos Reis</U>: It is a simple fact, even without
templates, that a writer of a derived class cannot protect himself
against declaration changes in the base class.</P>

<P>
<U>Richard Corden</U>: If a change is to be made, then making it
ill-formed is better than just changing the lookup rules.</P>

<PRE>
    struct B
    {
      typedef int T;
      virtual void bar (T const &amp; );
    };

    template &lt;typename T&gt;
    struct D : public B
    {
      virtual void bar (T const &amp; );
    };

    template class D&lt;float&gt;;
</PRE>

<P>I think changing the semantics of the above code silently would
result in very difficult-to-find problems.</P>

<P>
<U>Mike Miller</U>: Another case that may need to be considered in
deciding on Erwin's suggestion or the &ldquo;ill-formed&rdquo;
alternative is the treatment of <TT>friend</TT> declarations
described in 3.4.1&nbsp;



 <A HREF="basic.html#basic.lookup.unqual">basic.lookup.unqual</A> paragraph 10:</P>

<PRE>
    struct A {
        typedef int T;
        void f(T);
    };
    template&lt;typename T&gt; struct B {
        friend void A::f(T);  //<SPAN STYLE="font-family:Times"><I> Currently </I></SPAN>T<SPAN STYLE="font-family:Times"><I> is </I></SPAN>A::T
    };
</PRE>

<P>
<B>Notes from the October, 2005 meeting:</B>
</P>

<P>The CWG decided not to consider a change to the existing rules at
this time without a paper exploring the issue in more detail.</P>
<BR>
<BR>
<HR>
<A NAME="544"></A>
<H4>544.
  
Base class lookup in explicit specialization
</H4>
<B>Section: </B>14.6.2&nbsp;



 <A HREF="template.html#temp.dep">temp.dep</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>John Spicer
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>01 November 2005<BR>


<P>There is some question as to whether 14.6.2&nbsp;



 <A HREF="template.html#temp.dep">temp.dep</A>
paragraph 3 applies to the definition of an explicitly-specialized
member of a class template:</P>

<BLOCKQUOTE>

In the definition of a class template or a member of a class template,
if a base class of the class template depends on
a <I>template-parameter</I>, the base class scope is not examined
during unqualified name lookup either at the point of definition of
the class template or member or during an instantiation of the class
template or member.

</BLOCKQUOTE>

<P>Consider an example like the following:</P>

<PRE>
    template &lt;class T&gt;
    struct A {
     void foo() {}
    };

    template &lt;class T&gt;
    struct B: A&lt;T&gt; {
     int bar();
    };

    int foo() { return 0; }

    template &lt;&gt;
    int B&lt;int&gt;::bar() { return foo(); }

    int main() {
     return B&lt;int&gt;().bar();
    }
</PRE>

<P>Does <TT>foo</TT> in the definition of <TT>B&lt;int&gt;::bar()</TT>
refer to <TT>::foo()</TT> or to <TT>A&lt;int&gt;::foo()</TT>?</P>

<BR>
<BR>
<HR>
<A NAME="502"></A>
<H4>502.
  
Dependency of nested enumerations and enumerators
</H4>
<B>Section: </B>14.6.2.1&nbsp;



 <A HREF="template.html#temp.dep.type">temp.dep.type</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Mark Mitchell
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>05 Feb 2005<BR>


<P>The Standard is currently silent on the dependency status of
enumerations and enumerators that are members of class templates.
There are three questions that must be answered in this regard:</P>

<OL>

<LI>
<P>
<B>Are enumeration members of class templates dependent
types?</B>
</P>

<P>It seems clear that nested enumerations must be dependent.  For
example:</P>

<PRE>
    void f(int);

    template&lt;typename T&gt; struct S {
        enum E { e0 };
        void g() {
            f(e0);
        }
    };

    void f(S&lt;int&gt;::E);

    void x() {
        S&lt;int&gt; si;
        si-&gt;g();       // Should call f(S&lt;int&gt;::E)
    }
</PRE>

</LI>

<LI>
<P>
<B>Is <TT>sizeof</TT> applied to a nested enumeration a
value-dependent expression (14.6.2.3&nbsp;



 <A HREF="template.html#temp.dep.constexpr">temp.dep.constexpr</A>)?</B>
</P>

<P>There are three distinct cases that might have different answers
to this question:</P>

<UL>

<LI>
<PRE>
    template&lt;typename T&gt; struct S {
        enum E { e0 };
    };
</PRE>

<P>Here, the size of <TT>E</TT> is, in principle, known at the time
the template is defined.</P>

</LI>

<LI>
<PRE>
    template&lt;short I&gt; struct S {
        enum E { e0 = I };
    };
</PRE>

<P>In this case, the minimum size required for <TT>E</TT> cannot be
determined until instantiation, but it is clear that the underlying
type need be no larger than <TT>short</TT>.</P>

</LI>

<LI>
<PRE>
    template&lt;typename T&gt; struct S {
        enum E { e0 = T::e0; };
    }
</PRE>

<P>Here, nothing can be known about the size of <TT>E</TT> at the time
the template is defined.</P>

</LI>

</UL>

<P>14.6.2.3&nbsp;



 <A HREF="template.html#temp.dep.constexpr">temp.dep.constexpr</A> paragraph 2 says that a
<TT>sizeof</TT> expression is value-dependent if the type of the
operand is type-dependent.  Unless enumerations are given special
treatment, all three of these examples will have value-dependent
sizes.  This could be surprising for the first case, at least, if not
the second as well.</P>

</LI>

<LI>
<P>
<B>Are nested enumerators value-dependent expressions?</B>
</P>

<P>Again the question of dependent initializers comes into play.  As an
example, consider:</P>

<PRE>
    template&lt;short I&gt; struct S {
        enum E { e0, e1 = I, e2 };
    };
</PRE>

<P>There seem to be three possible approaches as to whether the
enumerators of <TT>E</TT> are value-dependent:</P>

<OL type="A">

<LI>
<P>The enumerators of a nested enumeration are all
value-dependent, regardless of whether they have a value-dependent
initializer or not.  This is the current position of 14.6.2.3&nbsp;



 <A HREF="template.html#temp.dep.constexpr">temp.dep.constexpr</A> paragraph 2, which says that an identifier is
value-dependent if it is a name declared with a dependent
type.</P>
</LI>

<LI>
<P>The enumerators of a nested enumeration are all value-dependent
if any of the enumeration's enumerators has a value-dependent
initializer.  In this approach, <TT>e0</TT> would be value-dependent,
even though it is clear that it has the value 0.</P>
</LI>

<LI>
<P>An enumerator of a nested enumeration is value-dependent only
if it has a value-dependent initializer (explict or implicit).  This
approach would make <TT>e1</TT> and <TT>e2</TT> value-dependent, but
not <TT>e0</TT>.</P>
</LI>

</OL>

<P>An example that bears on the third approach is the following:</P>

<PRE>
    template&lt;typename T&gt; struct S {
        enum E { N = UINT_MAX, O = T::O };
        int a[N + 2];
    };
</PRE>

<P>With the normal treatment of enumerations, the type of <TT>a</TT>
might be either <TT>int[UINT_MAX+2]</TT> or <TT>int[1]</TT>, depending
on whether the value of <TT>T::O</TT> was such that the underlying
type of <TT>E</TT> is <TT>unsigned int</TT> or <TT>long</TT>.
</P>

<P>One possibility for addressing this problem under the third
approach would be to treat a given enumerator as having the type of
its initializer in such cases, rather than the enumeration type.  This
would be similar to the way enumerators are treated within the
enumerator list, before the enumeration declaration is complete
(<sectioin_ref>7.2&nbsp;



 <A HREF="dcl.html#dcl.enum">dcl.enum</A></sectioin_ref> paragraph 5).  The argument against this
is that it makes arithmetic using enumerators behave differently when
the enumeration is a member of a class template and when it is not.</P>

</LI>

</OL>

<P>
<B>Notes from the April, 2005 meeting:</B>
</P>

<P>The CWG agreed on the following positions:</P>

<OL>
<LI>
<P>Nested enumerations are dependent types.</P>
</LI>

<LI>
<P>The result of the <TT>sizeof</TT> operator applied to a
nested enumeration is value-dependent unless there are no
dependent initializers in its definition; the first case above
is not dependent, while the second and third are dependent.</P>
</LI>

<LI>
<P>The approach described in 3.C above is correct.  This is
similar to the treatment of static const integral data members,
which are dependent only if their initializer is dependent.</P>
</LI>

</OL>

<P>
<B>Notes from the October, 2005 meeting:</B>
</P>

<P>There was no consensus among the CWG regarding question #3
(which enumerators should be considered value-dependent).  The
argument in favor of 3.C is principally that the values of enumerators
with non-dependent initializers are known at definition time, so there
is no need to treat them as dependent.</P>

<P>One objection to 3.C is that, according to the consensus of the
CWG, the enumeration type is dependent and thus even the known values
of the enumeration would have a dependent type, which could affect the
results when such enumerations are used in expressions.  A possible
response to this concern would be to treat non-dependent initializers
as having the type of the initializer rather than the enumeration
type, similar to the treatment of enumerators within
the <I>enumerator-list</I> (7.2&nbsp;



 <A HREF="dcl.html#dcl.enum">dcl.enum</A> paragraph 5).
However, this approach would be inconsistent with the treatment of
other enumeration types.  It would also interfere with overload
resolution (e.g., the call in the example under question #1 above
would resolve to <TT>f(int)</TT> with this approach rather
than <TT>f(S&lt;int&gt;::E)</TT>).</P>

<P>Those in favor of option 3.A also suggested that it would be simpler
and require less drafting: if all the enumerators have the (dependent)
type of the enumeration, 14.6.2.3&nbsp;



 <A HREF="template.html#temp.dep.constexpr">temp.dep.constexpr</A> paragraph 2
already says that a name with a dependent type is value-dependent, so
nothing further would need to be said.  Option 3.C would require
additional caveats to exempt some enumerators.</P>

<P>The proponents of 3.A also pointed out that there are many other
cases where a known value with a dependent type is treated as dependent:</P>

<PRE>
    static const T t = 0;
    ... A&lt;t&gt; ...
</PRE>

<P>or</P>

<PRE>
    template &lt;int I&gt; void f() {
        g(I-I);
    }
</PRE>

<P>With regard to current practice, g++ and MSVC++ implement 3.A, while
EDG implements 3.C.</P>

<BR>
<BR>
<HR>
<A NAME="541"></A>
<H4>541.
  
Dependent function types
</H4>
<B>Section: </B>14.6.2.2&nbsp;



 <A HREF="template.html#temp.dep.expr">temp.dep.expr</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Daveed Vandevoorde
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>22 October 2005<BR>


<P>14.6.2.2&nbsp;



 <A HREF="template.html#temp.dep.expr">temp.dep.expr</A> paragraph 3 says,</P>

<BLOCKQUOTE>

An <I>id-expression</I> is type-dependent if it contains:

<UL>
<LI>an identifier that was declared with a dependent type...</LI>
</UL>

</BLOCKQUOTE>

<P>This treatment seems inadequate with regard to
<I>id-expression</I>s in function calls:</P>

<OL>

<LI>
<P>According to 14.6.2.1&nbsp;



 <A HREF="template.html#temp.dep.type">temp.dep.type</A> paragraph 6,</P>

<BLOCKQUOTE>

A type is dependent if it is

<UL>

<LI>...</LI>

<LI>a compound type constructed from any dependent type...</LI>

</UL>

</BLOCKQUOTE>

<P>This would apply to the type of a member function of a class
template if any of its parameters are dependent, even if the return
type is not dependent.  However, there is no need for a call to such a
function to be a type-dependent expression because the type of the
expression is known at definition time.</P>

</LI>

<LI>
<P>This wording does not handle the case of overloaded functions,
some of which might have dependent types (however defined) and others
not.</P>

</LI>

</OL>

<BR>
<BR>
<HR>
<A NAME="293"></A>
<H4>293.
  
Syntax of explicit instantiation/specialization too permissive
</H4>
<B>Section: </B>14.7.2&nbsp;



 <A HREF="template.html#temp.explicit">temp.explicit</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Mark Mitchell
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>27 Jun 2001<BR>


<P>14.7.2&nbsp;



 <A HREF="template.html#temp.explicit">temp.explicit</A> defines an explicit instantiation as</P>

<UL>
<I>explicit-instantiation</I>:
<UL>
<TT>template</TT> <I>declaration</I>
</UL>
</UL>

<P>Syntactically, that allows things like:</P>
<PRE>
    template int S&lt;int&gt;::i = 5, S&lt;int&gt;::j = 7;
</PRE>

<P>which isn't what anyone actually expects.  As far as I can tell,
nothing in the standard explicitly forbids this, as written.  Syntactically,
this also allows:</P>

<PRE>
    template namespace N { void f(); }
</PRE>

<P>although perhaps the surrounding context is enough to suggest that this is
invalid.</P>

<P>
<B>Suggested resolution:</B>
</P>

<P>I think we should say:</P>

<UL>
<I>explicit-instantiation</I>:
<UL>
<I>type-specifier-seq</I><SUB>opt</SUB>
    <I>declarator</I><SUB>opt</SUB> <TT>;</TT>
</UL>
</UL>

<P>
<I>[Steve Adamczyk: presumably, this should have</I>
<TT>template</TT> <I>at the beginning.]</I>
</P>

<P>and then say that:</P>

<UL>
<LI>
The declarator can be omitted only when the <I>type-specifier-seq</I>
consists solely of an <I>elaborated-type-specifier</I> for a class type, in
which case the instantiation is for the named class.  If the
declarator is present the instantiation is for the named entity.
</LI>
<LI>
The <I>type-specifier-seq</I> can be omitted only when the declarator
is for a constructor, destructor, or conversion operator.
</LI>
<LI>
The <I>type-specifier-seq</I> cannot define any new types.
</LI>
</UL>

<P>There are similar problems in 14.7.3&nbsp;



 <A HREF="template.html#temp.expl.spec">temp.expl.spec</A>:</P>

<UL>
<I>explicit-specialization</I>:
<UL>
<TT>template</TT> &lt;&gt; <I>declaration</I>
</UL>
</UL>

<P>Here, I think we want:</P>

<UL>
<I>explicit-specialization</I>:
<UL>
<I>decl-specifier-seq</I><SUB>opt</SUB> <I>init-declarator</I><SUB>opt</SUB> <TT>;</TT>
</UL>
</UL>

<P>with similar restrictions as above.</P>

<P>
<I>[Steve Adamczyk: This also needs to have</I>
<TT>template &lt;&gt;</TT> <I>at the beginning, possibly repeated.]</I>
</P>



<BR>
<BR>
<HR>
<A NAME="546"></A>
<H4>546.
  
Explicit instantiation of class template members
</H4>
<B>Section: </B>14.7.2&nbsp;



 <A HREF="template.html#temp.explicit">temp.explicit</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Martin Sebor
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>29 October 2005<BR>


<P>
<A HREF="
     cwg_defects.html#470">Issue 470</A> specified the explicit
instantiation of members of explicitly-instantiated class templates.
In restricting the affected members to those &ldquo;whose definition
is visible at the point of instantiation,&rdquo; however, this
resolution introduced an incompatibility between explicitly
instantiating a member function or static data member and explicitly
instantiating the class template of which it is a member (14.7.2&nbsp;



 <A HREF="template.html#temp.explicit">temp.explicit</A> paragraph 3 requires only that the class template
definition, not that of the member function or static data member, be
visible at the point of the explicit instantiation).  It would be
better to treat the member instantiations the same, regardless of
whether they are directly or indirectly explicitly instantiated.</P>

<BR>
<BR>
<HR>
<A NAME="551"></A>
<H4>551.
  
When is <TT>inline</TT> permitted in an explicit instantiation?
</H4>
<B>Section: </B>14.7.2&nbsp;



 <A HREF="template.html#temp.explicit">temp.explicit</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Steve Clamage
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>07 December 2005<BR>


<P>The Standard does not definitively say when the <TT>inline</TT>
specifier may be used in an explicit instantiation.  For example,
the following would seem to be innocuous, as the function being
instantiated is already inline:</P>

<PRE>
    template &lt;typename T&gt; struct S {
        void f() { }
    };
    template inline void S&lt;int&gt;::f();
</PRE>

<P>However, presumably one would want to prohibit something like:</P>

<PRE>
    template &lt;typename T&gt; void f(T) { }
    template inline void f(int);
</PRE>

<P>7.1.2&nbsp;



 <A HREF="dcl.html#dcl.fct.spec">dcl.fct.spec</A> paragraph 4 (after application of the
resolution of <A HREF="
     cwg_defects.html#317">issue 317</A>) comes close to
covering the obvious problematic cases:</P>

<BLOCKQUOTE>

If the definition of a function appears in a translation unit before
its first declaration as inline, the program is ill-formed.  If a
function with external linkage is declared inline in one translation
unit, it shall be declared inline in all translation units in which it
appears; no diagnostic is required.

</BLOCKQUOTE>

<P>This would seem to prohibit the latter case, but apparently would
not handle an exported template that was instantiated as inline
(because the definition might not appear in the same translation unit
as the inline instantiation).  It would be better to make a clear
statement regarding the use of <TT>inline</TT> in explicit
instantiations.</P>

<BR>
<BR>
<HR>
<A NAME="264"></A>
<H4>264.
  
Unusable template constructors and conversion functions
</H4>
<B>Section: </B>14.8.1&nbsp;



 <A HREF="template.html#temp.arg.explicit">temp.arg.explicit</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>John Spicer
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>17 Nov 2000<BR>




<P>The note in paragraph 5 of 14.8.1&nbsp;



 <A HREF="template.html#temp.arg.explicit">temp.arg.explicit</A> makes
clear that explicit template arguments cannot be supplied in
invocations of constructors and conversion functions because they are
called without using a name.  However, there is nothing in the current
wording of the Standard that makes declaring a constructor or
conversion operator that is unusable because of nondeduced parameters
(i.e., that would need to be specified explicitly) ill-formed.  It
would be a service to the programmer to diagnose this useless
construct as early as possible.</P>

<BR>
<BR>
<HR>
<A NAME="271"></A>
<H4>271.
  
Explicit instantiation and template argument deduction
</H4>
<B>Section: </B>14.8.2&nbsp;



 <A HREF="template.html#temp.deduct">temp.deduct</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>John Spicer
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>20 Feb 2001<BR>




<P>Nicolai Josuttis sent me an example like the following:</P>

<PRE>
    template &lt;typename RET, typename T1, typename T2&gt;
    const RET&amp; min (const T1&amp; a, const T2&amp; b)
    {
	return (a &lt; b ? a : b);
    }
    template const int&amp; min&lt;int&gt;(const int&amp;,const int&amp;);  // #1
    template const int&amp; min(const int&amp;,const int&amp;);       // #2
</PRE>

<P>Among the questions was whether explicit instantiation #2 is valid,
where deduction is required to determine the type of <TT>RET</TT>.</P>

<P>The first thing I realized when researching this is that the standard
does not really spell out the rules for deduction in declarative
contexts (friend declarations, explicit specializations, and
explicit instantiations).  For explicit instantiations,
14.7.2&nbsp;



 <A HREF="template.html#temp.explicit">temp.explicit</A> paragraph 2 does
mention deduction, but it doesn't say which set of deduction rules from
14.8.2&nbsp;



 <A HREF="template.html#temp.deduct">temp.deduct</A> should be applied.</P>

<P>Second, Nicolai pointed out that
14.7.2&nbsp;



 <A HREF="template.html#temp.explicit">temp.explicit</A> paragraph 6 says</P>

<BLOCKQUOTE>
A trailing <I>template-argument</I>
can be left unspecified in an explicit instantiation provided it can
be deduced from the type of a function parameter
(14.8.2&nbsp;



 <A HREF="template.html#temp.deduct">temp.deduct</A>).
</BLOCKQUOTE>

<P>This prohibits cases
like #2, but I believe this was not considered in the wording as there
is no reason not to include the return type in the deduction process.</P>

<P>I think there may have been some confusion because the return type is
excluded when doing deduction on a function call.  But there are
contexts where the return type is included in deduction, for example,
when taking the address of a function template specialization.</P>

<P>
<U>Suggested resolution</U>:</P>

<OL>

<LI>Update 14.8.2&nbsp;



 <A HREF="template.html#temp.deduct">temp.deduct</A> to include a section
"Deducing template arguments from a declaration" that describes how
deduction is done when finding a template that matches a declaration.
This should, I believe, include the return type.</LI>

<LI>Update 14.7.2&nbsp;



 <A HREF="template.html#temp.explicit">temp.explicit</A> to make reference to the new
rules in 14.8.2&nbsp;



 <A HREF="template.html#temp.deduct">temp.deduct</A> and remove the description of
the deduction details from 14.7.2&nbsp;



 <A HREF="template.html#temp.explicit">temp.explicit</A> paragraph
6.</LI>

</OL>
<BR>
<BR>
<HR>
<A NAME="297"></A>
<H4>297.
  
Which template does an explicit specialization specialize?
</H4>
<B>Section: </B>14.8.2&nbsp;



 <A HREF="template.html#temp.deduct">temp.deduct</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Andrei Iltchenko
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>7 Jul 2001<BR>


<P>Andrei Iltchenko points out that the standard has no wording that
defines how to determine which template is specialized by an
explicit specialization of a function template.
He suggests "template argument deduction
in such cases proceeds in the same way as when taking the address
of a function template,
which is described in 14.8.2.2&nbsp;



 <A HREF="template.html#temp.deduct.funcaddr">temp.deduct.funcaddr</A>."</P>

<P>John Spicer points out that the same problem exists for all
similar declarations, i.e., friend declarations and explicit
instantiation directives.  Finding a corresponding placement
<TT>operator delete</TT> may have a similar problem.</P>

<P>
<U>John Spicer</U>:
There are two aspects of "determining which template" is referred to by
a declaration: determining the function template associated with the
named specialization, and determining the values of the template arguments
of the specialization.</P>
<PRE>
    template &lt;class T&gt; void f(T);  #1
    template &lt;class T&gt; void f(T*); #2
    template &lt;&gt; void f(int*);
</PRE>

<P>In other words, which <TT>f</TT> is being specialized (#1 or #2)?
And then, what are the deduced template arguments?</P>

<P>14.5.5.2&nbsp;



 <A HREF="template.html#temp.func.order">temp.func.order</A> does say that partial ordering is
done in contexts such as this.
Is this sufficient, or do we need to say more about the selection of the
function template to be selected? </P>

<P>14.8.2&nbsp;



 <A HREF="template.html#temp.deduct">temp.deduct</A> probably needs a new section to cover
argument deduction for cases like this.</P>

<BR>
<BR>
<HR>
<A NAME="503"></A>
<H4>503.
  
Cv-qualified function types in template argument deduction
</H4>
<B>Section: </B>14.8.2.1&nbsp;



 <A HREF="template.html#temp.deduct.call">temp.deduct.call</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Gabriel Dos Reis
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>22 Feb 2005<BR>




<P>Consider the following program:</P>

<PRE>
    template &lt;typename T&gt; int ref (T&amp;)                { return 0; }
    template &lt;typename T&gt; int ref (const T&amp;)          { return 1; }
    template &lt;typename T&gt; int ref (const volatile T&amp;) { return 2; }
    template &lt;typename T&gt; int ref (volatile T&amp;)       { return 4; }

    template &lt;typename T&gt; int ptr (T*)                { return 0; }
    template &lt;typename T&gt; int ptr (const T*)          { return 8; }
    template &lt;typename T&gt; int ptr (const volatile T*) { return 16; }
    template &lt;typename T&gt; int ptr (volatile T*)       { return 32; }

    void foo() {}

    int main()
    {
        return ref(foo) + ptr(&amp;foo);
    }
</PRE>

<P>The Standard appears to specify that the value returned from
<TT>main</TT> is 2.  The reason for this result is that references and
pointers are handled differently in template argument deduction.</P>

<P>For the reference case, 14.8.2.1&nbsp;



 <A HREF="template.html#temp.deduct.call">temp.deduct.call</A> paragraph
3 says that &ldquo;If <TT>P</TT> is a reference type, the type
referred to by <TT>P</TT> is used for type deduction.&rdquo; Because
of <A HREF="
     cwg_defects.html#295">issue 295</A>, all four of the types for the
<TT>ref</TT> function parameters are the same, with no
cv-qualification; overload resolution does not find a best match among
the parameters and thus the most-specialized function is selected.</P>

<P>For the pointer type, argument deduction does not get as far as
forming a cv-qualified function type; instead, argument deduction
fails in the cv-qualified cases because of the cv-qualification
mismatch, and only the cv-unqualified version of <TT>ptr</TT> survives
as a viable function.</P>

<P>I think the choice of ignoring cv-qualifiers in the reference case
but not the pointer case is very troublesome.  The reason is that when
one considers function objects as function parameters, it introduces a
semantic difference whether the function parameter is declared a
reference or a pointer.  In all other contexts, it does not matter: a
function name decays to a pointer and the resulting semantics are the
same.</P>

<BR>
<BR>
<HR>
<A NAME="469"></A>
<H4>469.
  
Const template specializations and reference arguments
</H4>
<B>Section: </B>14.8.2.5&nbsp;



 <A HREF="template.html#temp.deduct.type">temp.deduct.type</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Matt Austern
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>19 Mar 2004<BR>




<P>Consider the following:</P>
<PRE>
	template &lt;typename T&gt; struct X {};  // #1
	template &lt;typename T&gt; struct X&lt;const T&gt;; //#2
	template struct X&lt;int&amp;&gt;; //#3
</PRE>

<P>Which specialization are we instantiating in #3?  The "obvious" answer 
is #1, because "int&amp;" doesn't have a top level cv-qualification.  
However, there's also an argument saying that we should actually be 
instantiating #2.  The argument is: int&amp; can be taken as a match for 
either one (top-level cv-qualifiers are ignored on references, so 
they're equally good), and given two equally good matches we must 
choose the more specialized one.</P>

<P>Is this a valid argument?  If so, is this behavior intentional?</P>

<P>
<U>John Spicer:</U>
I don't see the rationale for any choice other than #1.  While it is
true that if you attempt to apply const to a reference type it just
gets dropped, that is very different from saying that a reference type
is acceptable where a const-qualified type is required.</P>

<P>
<I>If</I> the type matched both templates, the const one would be
more specialized, but "int&amp;" does not match "const T".</P>

<P>
<U>Nathan Sidwell:</U>
thanks for bringing this one to the committee.  However this is
resolved, I'd like clarification on the followup questions in the
gcc bug report regarding deduced and non-deduced contexts and
function templates.  Here're those questions for y'all,</P>
<PRE>
template &lt;typename T&gt; void Foo (T *); // #1
template &lt;typename T&gt; void Foo (T const *); // #2
void Baz ();
Foo (Baz); // which?

template &lt;typename T&gt; T const *Foo (T *); // #1
void Baz ();
Foo (Baz); // well formed?

template &lt;typename T&gt; void Foo (T *, T const * = 0);
void Baz ();
Foo (Baz); // well formed?
</PRE>
<P>BTW, I didn't go trying to break things, I implemented the cv-qualifier
ignoring requirements and fell over this.  I could find nothing in the
standard saying 'don't do this ignoring during deduction'.</P>



<BR>
<BR>
<HR>
<A NAME="388"></A>
<H4>388.
  
Catching base<TT>*&amp;</TT> from a throw of derived<TT>*</TT>
</H4>
<B>Section: </B>15.3&nbsp;



 <A HREF="except.html#except.handle">except.handle</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>John Spicer
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>28 Oct 2002<BR>




<P>I have a question about exception handling with respect to derived to base
conversions of pointers caught by reference.</P>

<P>What should the result of this program be?</P>
<PRE>
  struct S             {};
  struct SS : public S {};

  int main()
  {
  	SS ss;
  	int result = 0;
  	try
  	{
  		throw &amp;ss; // throw object has type SS*
  		           // (pointer to derived class)
  	}
  	catch (S*&amp; rs) // (reference to pointer to base class)
  	{
  		result = 1;
  	}
  	catch (...)
  	{
  		result = 2;
  	}
  	return result;
  }
</PRE>

<P>The wording of 15.3&nbsp;



 <A HREF="except.html#except.handle">except.handle</A> paragraph 3
would seem to say that the catch of S*&amp; does not
match and so the catch ... would be taken.</P>

<P>All of the compilers I tried (EDG, g++, Sun, and Microsoft) used the catch
of S*&amp; though.</P>

<P>What do we think is the desired behavior for such cases?</P>

<P>My initial reaction is that this is a bug in all of these compilers, but
the fact that they all do the same thing gives me pause.</P>

<P>On a related front, if the handler changes the parameter using the
reference, what is caught by a subsequent handler?</P>
<PRE>
  extern "C" int printf(const char *, ...);
  struct S             {};
  struct SS : public S {};
  SS ss;

  int f()
  {
  	try
  	{
  		throw &amp;ss;
  	}
  	catch (S*&amp; rs) // (reference to pointer to base class)
  	{
  		rs = 0;
  		throw;
  	}
  	catch (...)
  	{
  	}
  	return 0;
  }

  int main()
  {
  	try { f(); }
  	catch (S*&amp; rs) {
  		printf("rs=%p, &amp;ss=%p\n", rs, &amp;ss);
  	}
  }
</PRE>

<P>EDG, g++, and Sun all catch the original (unmodified) value.  Microsoft
catches the modified value.  In some sense the EDG/g++/Sun behavior makes
sense because the later catch could catch the derived class instead of the
base class, which would be difficult to do if you let the catch clause
update the value to be used by a subsequent catch.</P>

<P>But on this non-pointer case, all of the compilers later catch the
modified value:</P>
<PRE>
  extern "C" int printf(const char *, ...);
  int f()
  {
  	try
  	{
  		throw 1;
  	}
  	catch (int&amp; i)
  	{
  		i = 0;
  		throw;
  	}
  	catch (...)
  	{
  	}
  	return 0;
  }

  int main()
  {
  	try { f(); }
  	catch (int&amp; i) {
  		printf("i=%p\n", i);
  	}
  }
</PRE>

<P>To summarize:</P>
<OL>
<LI>Should "base*const&amp;" be able to catch a "derived*"? 
The current standard
seems to say "no" but parallels to how calls work, and existing practice,
suggest that the answer should be "yes".</LI>

<LI>Should "base*&amp;" be able to catch a "derived*".  Again,
the standard seems
seems to say "no".  Parallels to how calls work still suggest "no", but
existing practice suggests "yes".</LI>

<LI>If either of the above is "yes", what happens if you modify the pointer
referred to by the reference.  This requires a cast to remove const for
case #2.</LI>

<LI>On a related front, if you catch
"derived*&amp;" when a "derived*" is thrown,
what happens if you modify the pointer referred to by the reference?
EDG/g++/Sun still don't modify the underlying value that would be
caught by a rethrow in this case.  This case seems like it should be
the same as the "int&amp;" example above, but is not on the three compilers
mentioned.</LI>
</OL>

<BR>
<BR>
<HR>
<A NAME="92"></A>
<H4>92.
  
Should exception specifications be part of the type system?
</H4>
<B>Section: </B>15.4&nbsp;



 <A HREF="except.html#except.spec">except.spec</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Jonathan Schilling
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>2 Feb 1999<BR>


    
<P>It was tentatively agreed at the Santa Cruz meeting
that exception specifications
should fully participate in the type system.  This change would
address gaps in the current static checking of exception specifications
such as</P>

<PRE>
    void (*p)() throw(int);
    void (**pp)() throw() = &amp;p;   // not currently an error
</PRE>
    
<P>This is such a major change that it deserves to be a separate
issue.</P>

<P>See also issues <A HREF="
     cwg_defects.html#25">25</A>,
<A HREF="
     cwg_defects.html#87">87</A>, and
<A HREF="
     cwg_closed.html#133">133</A>.</P>
<BR>
<BR>
<HR>
<A NAME="219"></A>
<H4>219.
  
Cannot defend against destructors that throw exceptions
</H4>
<B>Section: </B>15.5.1&nbsp;



 <A HREF="except.html#except.terminate">except.terminate</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Herb Sutter
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>31 Mar 2000<BR>




<P>Destructors that throw can easily cause programs to terminate,
with no possible defense.  Example: Given</P>

<PRE>
    struct XY { X x; Y y; };
</PRE>

<P>Assume that <TT>X::~X()</TT> is the only destructor in the entire
program that can throw. Assume further that <TT>Y</TT> construction is
the only other operation in the whole program that can throw. Then
<TT>XY</TT> cannot be used safely, in any context whatsoever, period
&mdash; even simply declaring an <TT>XY</TT> object can crash the
program:</P>

<PRE>
    XY xy; // construction attempt might terminate program:
	   //   1. construct x -- succeeds
	   //   2. construct y -- fails, throws exception
	   //   3. clean up by destroying x -- fails, throws exception,
	   //      but an exception is already active, so call 
	   //      std::terminate() (oops)
	   // there is no defense
</PRE>

So it is highly dangerous to have even one destructor that could throw.

<P>Suggested Resolution:</P>

<P>Fix the above problem in one of the following two ways. I prefer
the first.</P>

<OL>

<LI>We already have text that specifies that any destructor operation in 
the standard library (presumably including the destructors of UDTs used in 
containers or as predicates, etc.) may not throw. There is good reason to 
widen this injunction to specify that destructors may never throw at all.
(I realize this would render existing programs nonconforming if they did
do this, but it's unsafe anyway.)</LI>

<LI>Specify what happens in the above case so that
<TT>std::terminate()</TT> won't be called.</LI>

</OL>

<P>
<U>Fergus Henderson</U>: I disagree.  Code using <TT>XY</TT> may
well be safe, if <TT>X::~X()</TT> only throws if
<TT>std::uncaught_exception()</TT> is <TT>false</TT>.</P>

<P>I think the current exception handling scheme in C++ is certainly
flawed, but the flaws are IMHO design flaws, not minor technical
defects, and I don't think they can be solved by minor tweaks to the
existing design.  I think that at this point it is probably better to
keep the standard stable, and learn to live with the existing flaws,
rather than trying to solve them via TC.</P>

<P>
<U>Bjarne Stroustrup</U>: I strongly prefer to have the call to
<TT>std::terminate()</TT> be conforming. I see <TT>std::terminate()</TT> as a
proper way to blow away "the current mess" and get to the next level
of error handling. I do not want that escape to be non-conforming
&mdash; that would imply that programs relying on a error handling
based on serious errors being handled by terminating a process (which
happens to be a C++ program) in <TT>std::terminate()</TT> becomes
non-conforming. In many systems, there are &mdash; and/or should be
&mdash; error-handling and recovery mechanisms beyond what is offered
by a single C++ program.</P>

<P>
<U>Andy Koenig</U>: If we were to prohibit writing a destructor
that can throw, how would I solve the following problem?</P>

<P>I want to write a class that does buffered output.  Among the
other properties of that class is that destroying an object of
that class writes the last buffer on the output device before
freeing memory.</P>

<P>What should my class do if writing that last buffer indicates a
hardware output error?  My user had the option to flush the last
buffer explicitly before destroying the object, but didn't do so, and
therefore did not anticipate such a problem.  Unfortunately, the
problem happened anyway.  Should I be required to suppress this
error indication anyway?  In all cases?</P>

<P>In practice, I would rather thrown an exception, even at the risk
of crashing the program if we happen to be in the middle of stack
unwinding.  The reason is that the program would crash only if a
hardware error occurred in the middle of cleaning up from some other
error that was in the process of being handled.  I would rather have
such a bizarre coincidence cause a crash, which stands a chance of
being diagnosed later, than to be ignored entirely and leave the
system in a state where the ignore error could cause other trouble
later that is even harder to diagnose.</P>

<P>If I'm not allowed to throw an exception when I detect this problem,
what are my options?</P>

<P>
<U>Herb Sutter</U>: I understand that some people might feel that
"a failed dtor during stack unwinding is preferable in certain cases"
(e.g., when recovery can be done beyond the scope of the program), but
the problem is "says who?"  It is the application program that should
be able to decide whether or not such semantics are correct for it,
and the problem here is that with the status quo a program cannot
defend itself against a <TT>std::terminate()</TT> &mdash; period. The
lower-level code makes the decision for everyone. In the original
example, the mere existence of an <TT>XY</TT> object puts at risk
every program that uses it, whether <TT>std::terminate()</TT> makes sense
for that program or not, and there is no way for a program to protect
itself.</P>

<P>That the "it's okay if the process goes south should a rare
combination of things happen" decision should be made by lower-level
code (e.g., <TT>X</TT> dtor) for all apps that use it, and which
doesn't even understand the context of any of the hundreds of apps
that use it, just cannot be correct.</P>

<P>(See also <A HREF="
     cwg_active.html#265">issue 265</A>.)</P>

<BR>
<BR>
<HR>
<A NAME="533"></A>
<H4>533.
  
Special treatment for C-style header names
</H4>
<B>Section: </B>16.2&nbsp;



 <A HREF="cpp.html#cpp.include">cpp.include</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Jens Maurer
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>4 October 2005<BR>


<P>In language imported directly from the C Standard,
16.2&nbsp;



 <A HREF="cpp.html#cpp.include">cpp.include</A> paragraph 5 says,</P>

<BLOCKQUOTE>

The implementation provides unique mappings for sequences consisting
of one or more <I>nondigit</I>s (2.10&nbsp;



 <A HREF="lex.html#lex.name">lex.name</A>) followed
by a period (<TT>.</TT>)  and a single <I>nondigit</I>.

</BLOCKQUOTE>

<P>This is clearly intended to support C header names like
<TT>stdio.h</TT>.  However, C++ has header names like <TT>cstdio</TT>
that do not conform to this pattern but still presumably require
&ldquo;unique mappings.&rdquo;</P>

<BR>
<BR>
<HR>
<A NAME="268"></A>
<H4>268.
  
Macro name suppression in rescanned replacement text
</H4>
<B>Section: </B>16.3.4&nbsp;



 <A HREF="cpp.html#cpp.rescan">cpp.rescan</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Bjarne Stroustrup
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>18 Jan 2001<BR>




<P>It is not clear from the Standard what the result of the
following example should be:</P>

<BLOCKQUOTE>
<PRE>
#define NIL(xxx) xxx
#define G_0(arg) NIL(G_1)(arg)
#define G_1(arg) NIL(arg)
G_0(42)
</PRE>
</BLOCKQUOTE>

<P>The relevant text from the Standard is found in
16.3.4&nbsp;



 <A HREF="cpp.html#cpp.rescan">cpp.rescan</A> paragraph 2:</P>

<BLOCKQUOTE>

If the name of the macro being replaced is found during this scan of
the replacement list (not including the rest of the source file's
preprocessing tokens), it is not replaced. Further, if any nested
replacements encounter the name of the macro being replaced, it is not
replaced. These nonreplaced macro name preprocessing tokens are no
longer available for further replacement even if they are later
(re)examined in contexts in which that macro name preprocessing token
would otherwise have been replaced.

</BLOCKQUOTE>

<P>The sequence of expansion of <TT>G0(42)</TT> is as follows:</P>

<BLOCKQUOTE>
<PRE>
G0(42)
NIL(G_1)(42)
G_1(42)
NIL(42)
</PRE>
</BLOCKQUOTE>

<P>The question is whether the use of <TT>NIL</TT> in the last
line of this sequence qualifies for non-replacement under the
cited text.  If it does, the result will be <TT>NIL(42)</TT>.  If
it does not, the result will be simply <TT>42</TT>.</P>

<P>The original intent of the J11 committee in this text was
that the result should be <TT>42</TT>, as demonstrated by the
original pseudo-code description of the replacement algorithm
provided by Dave Prosser, its author.

The English description,
however, omits some of the subtleties of the pseudo-code and
thus arguably gives an incorrect answer for this case.</P>

<P>
<U>Suggested resolution (Mike Miller)</U>: Replace the cited
paragraph with the following:</P>

<BLOCKQUOTE>

<P>As long as the scan involves only preprocessing tokens from
a given macro's replacement list, or tokens resulting from a
replacement of those tokens, an occurrence of the macro's name
will not result in further replacement, even if it is later
(re)examined in contexts in which that macro name preprocessing
token would otherwise have been replaced.</P>

<P>Once the scan reaches the preprocessing token following a
macro's replacement list &mdash; including as part of the
argument list for that or another macro &mdash; the macro's
name is once again available for replacement.  [<I>Example:</I>
</P>

<PRE>
    #define NIL(xxx) xxx
    #define G_0(arg) NIL(G_1)(arg)
    #define G_1(arg) NIL(arg)
    G_0(42)                         // result is 42, not NIL(42)
</PRE>

<P>The reason that <TT>NIL(42)</TT> is replaced is that <TT>(42)</TT>
comes from outside the replacement list of <TT>NIL(G_1)</TT>, hence
the occurrence of <TT>NIL</TT> within the replacement list for
<TT>NIL(G_1)</TT> (via the replacement of <TT>G_1(42)</TT>) is not
marked as nonreplaceable.  <I>&mdash;end example</I>]</P>

</BLOCKQUOTE>

<P>(Note: The resolution of this issue must be coordinated with
J11/WG14.)</P>

<P>
<B>Notes (via Tom Plum) from April, 2004 WG14 Meeting:</B>
</P>

<P>Back in the 1980's it was understood by several WG14 people
that there were tiny differences between the "non-replacement"
verbiage and the attempts to produce pseudo-code.  The
committee's decision was that no realistic programs "in the wild"
would venture into this area, and trying to reduce the
uncertainties is not worth the risk of changing conformance
status of implementations or programs.</P>

<BR>
<BR>
<HR>
<A NAME="223"></A>
<H4>223.
  
The meaning of deprecation
</H4>
<B>Section: </B>D&nbsp;



 <A HREF="future.html#depr">depr</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Mike Miller
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>19 Apr 2000<BR>


<P>During the discussion of issues <A HREF="
     cwg_closed.html#167">167</A> and
<A HREF="
     cwg_closed.html#174">174</A>, it became apparent that there was no
consensus on the meaning of deprecation.  Some thought that
deprecating a feature reflected an intent to remove it from
the language.  Others viewed it more as an encouragement to
programmers not to use certain constructs, even though they might be
supported in perpetuity.</P>

<P>There is a formal-sounding definition of deprecation in Annex
D&nbsp;



 <A HREF="future.html#depr">depr</A> paragraph 2:

<BLOCKQUOTE>

deprecated is defined as: Normative for the current edition of the
Standard, but not guaranteed to be part of the Standard in future
revisions.

</BLOCKQUOTE>

However, this definition would appear to say that any
non-deprecated feature <I>is</I> "guaranteed to be part of the
Standard in future revisions."  It's not clear that that implication
was intended, so this definition may need to be amended.
</P>

<P>This issue is intended to provide an avenue for discussing and
resolving those questions, after which the original issues may be
reopened if that is deemed desirable.</P>
<BR>
<BR>
<HR>
<A NAME="248"></A>
<H4>248.
  
Identifier characters
</H4>
<B>Section: </B>E&nbsp;



 <A HREF="extendid.html#extendid">extendid</A>
 &nbsp;&nbsp;&nbsp;

 <B>Status: </B>open
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>John Spicer
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>6 Oct 2000<BR>




<P>The list of identifier characters specified in the C++ standard
annex E&nbsp;



 <A HREF="extendid.html#extendid">extendid</A> and the C99 standard annex D are
different.  The C99 standard includes more characters.</P>

<P>The C++ standard says that the characters are from "ISO/IEC PDTR
10176" while the C99 standard says "ISO/IEC TR 10176".  I'm guessing
that the PDTR is an earlier draft of the TR.</P>

<P>Should the list in the C++ standard be updated?</P>

<P>
<U>Tom Plum</U>: In my opinion, the "identifier character" issue
has not been resolved with certainty within SC22.</P>

<P>One critical difference in C99 was the decision to allow a compiler
to accept more characters than are given in the annex.  This allows
for future expansion.</P>

<P>The broader issue concerns the venue in which the "identifier
character" issue will receive ongoing resolution.</P>

<P>
<B>Notes from 10/00 meeting:</B>
</P>

<P>The core language working group expressed a strong preference
(13/0/5 in favor/opposed/abstaining) that the list of identifier
characters should be extensible, as is the case in C99.  However,
the fact that this topic is under active discussion by other bodies
was deemed sufficient reason to defer any changes to the C++
specification until the situation is more stable.</P>

<P>
<B>Notes from October, 2005 meeting:</B>
</P>

<P>The working group expressed interest in the kind of approach taken by
<A href="http://www.w3.org/TR/2004/REC-xml11-20040204/#NT-NameStartChar">
XML 1.1</A>, in which the definition of an identifier character is done
by excluding large ranges of the Unicode character set and accepting any
character outside those ranges, rather than by affirmatively designating
each identifier character in each language.  As noted above, 
consideration of this issue was previously deferred pending other
related standardization efforts.  Clark Nelson will investigate whether
these have reached a point at which progress on this issue in C++ is now
possible.</P>

<BR>
<BR>
<BR>
<BR>
</BODY>
</HTML>
