<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/02-0024 = WG21 N1366</TD>
</TR>
<TR>
<TD ALIGN="RIGHT">
      Date:
     </TD><TD>
      &nbsp;10 May, 2002</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:1998(E)
     </TD>
</TR>
<TR>
<TD ALIGN="RIGHT">
      Reply to:
     </TD><TD>
      &nbsp;J. Stephen Adamczyk
     </TD>
</TR>
<TR>
<TD></TD><TD>
      &nbsp;<TT>jsa@edg.com</TT></TD>
</TR>
</TABLE>
<BR CLEAR="ALL">
<BR>
<CENTER>
<H2>



     C++ Standard Core Language
     
       Active Issues,
      



     Revision
     22</H2>
<H3>Committee Version</H3>
</CENTER>
<BR>
<P>
      This document contains the C++ core language issues on which the
      Committee (J16 + WG21) has not yet acted, that is, issues 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:1998(E)
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>This set of documents exists in two slightly different versions.  The
Committee Version (this version) is the master version and should be
made available only to committee members.  The Public Version is
extracted from the Committee Version by removal of sensitive and/or
unnecessary information, such as drafting assignments, reflector
message numbers, and the like.</P>

<P>Committee members with the HTML version of the IS may wish to place
the issues list documents in the same directory; references to the IS
in the issues can then be explored by hyperlink.</P>


<P>The most current public version of this document can be found at
<A HREF="http://www.dkuug.dk/jtc1/sc22/wg21">http://www.dkuug.dk/jtc1/sc22/wg21</A>. 
Requests for further information about these documents should include
the document number, reference ISO/IEC 14882:1998(E), and be
submitted to the Information Technology Information Council (ITI),
1250&nbsp;Eye&nbsp;Street&nbsp;NW, 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.research.att.com/~austern/csc/faq.html ">http://www.research.att.com/~austern/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 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_active.html#214">214</A>,
<A HREF="
     cwg_active.html#244">244</A>,
<A HREF="
     cwg_active.html#245">245</A>,
<A HREF="
     cwg_active.html#254">254</A>,
<A HREF="
     cwg_active.html#255">255</A>,
<A HREF="
     cwg_active.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_active.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_active.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 (and changed the priority of)
 <A HREF="
     cwg_active.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_active.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 sequence numbers to issues for easier reference during meetings;
added drafting assignments and priorities to issues as assigned;

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_active.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_active.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_active.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_active.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 J16 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>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.  Under ISO rules, extensions cannot be
considered for at least five years from the approval of the Standard,
at which time the Standard will be open for review.  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 when extension proposals will be in order.</P>
<SCRIPT type="text/javascript">
  var seqno = 1;
 </SCRIPT>
<HR>
<A NAME="Ready Status"></A>
<H3>Issues with "Ready" Status</H3>
<HR>
<A NAME="261"></A>
<H4>261.
  
When is a deallocation function "used?"
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>3.2&nbsp;



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

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

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

 <B>Date: </B>7 Nov 2000
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Maurer<BR>


<P>From message 8976.</P>

<P>3.2&nbsp;



 <A HREF="basic.html#basic.def.odr">basic.def.odr</A> paragraph 2 says that a deallocation
function is "used" by a <I>new-expression</I> or
<I>delete-expression</I> appearing in a potentially-evaluated
expression.  3.2&nbsp;



 <A HREF="basic.html#basic.def.odr">basic.def.odr</A> paragraph 3 requires only that
"used" functions be defined.</P>

<P>This wording runs afoul of the typical implementation technique for
polymorphic <I>delete-expression</I>s in which the deallocation
function is invoked from the virtual destructor of the most-derived
class.  The problem is that the destructor must be defined, because
it's virtual, and if it contains an implicit reference to the
deallocation function, the deallocation function must also be defined,
even if there are no relevant <I>new-expression</I>s or
<I>delete-expression</I>s in the program.</P>

<P>For example:</P>

<PRE>
        struct B { virtual ~B() { } };

        struct D: B {
            void operator delete(void*);
            ~D() { }
        };
</PRE>

<P>Is it required that <TT>D::operator delete(void*)</TT> be defined,
even if no <TT>B</TT> or <TT>D</TT> objects are ever created or
deleted?</P>

<P>
<B>Suggested resolution:</B> Add the words "or if it is found by
the lookup at the point of definition of a virtual destructor
(12.4&nbsp;



 <A HREF="special.html#class.dtor">class.dtor</A>)" to the specification in 3.2&nbsp;



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

<P>
<B>Notes from 04/01 meeting:</B>
</P>

<P>The consensus was in favor of requiring that any declared
non-placement <TT>operator delete</TT> member function be
defined if the destructor for the class is defined (whether
virtual or not), and similarly for a non-placement
<TT>operator new</TT> if a constructor is defined.</P>

<P>
<B>Proposed resolution (10/01):</B>
</P>

<P> In 3.2&nbsp;



 <A HREF="basic.html#basic.def.odr">basic.def.odr</A> paragraph 2, add the indicated text:
<BLOCKQUOTE>
An allocation or deallocation function for a class is
used by a new expression appearing in a potentially-evaluated
expression as specified in 5.3.4&nbsp;



 <A HREF="expr.html#expr.new">expr.new</A>
and 12.5&nbsp;



 <A HREF="special.html#class.free">class.free</A>.
A deallocation function for a class is used by a delete expression
appearing in a potentially-evaluated expression as specified in
5.3.5&nbsp;



 <A HREF="expr.html#expr.delete">expr.delete</A> and 12.5&nbsp;



 <A HREF="special.html#class.free">class.free</A>.
<B> A non-placement allocation or deallocation function for a
class is used by the definition of a constructor of that class.  A
non-placement deallocation function for a class is used by the
definition of the destructor of that class, or by being selected by
the lookup at
the point of definition of a virtual destructor (12.4&nbsp;



 <A HREF="special.html#class.dtor">class.dtor</A>).
[Footnote: An implementation is not required to call
allocation and deallocation functions from constructors or
destructors; however, this is a permissible implementation
technique.]</B>
</BLOCKQUOTE>
</P>

<BR>
<BR>
<HR>
<A NAME="289"></A>
<H4>289.
  
Incomplete list of contexts requiring a complete type
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>3.2&nbsp;



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

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

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

 <B>Date: </B>25 May 2001
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>0
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Adamczyk<BR>


<P>3.2&nbsp;



 <A HREF="basic.html#basic.def.odr">basic.def.odr</A> paragraph 4 has a note listing the contexts
that require a class type to be complete.  It does not list use as a
base class as being one of those contexts.</P>

<P>
<B>Proposed resolution (10/01):</B>
</P>

<P>In 3.2&nbsp;



 <A HREF="basic.html#basic.def.odr">basic.def.odr</A> paragraph 4 add a new bullet at the
end of the note as the next-to-last bullet:
<UL>
<LI>
a class with a base class of type <TT>T</TT> is defined
(10&nbsp;



 <A HREF="derived.html#class.derived">class.derived</A>), or
</LI>
</UL>
</P>

<BR>
<BR>
<HR>
<A NAME="281"></A>
<H4>281.
  
<TT>inline</TT> specifier in <TT>friend</TT> declarations
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>7.1.2&nbsp;



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

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

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

 <B>Date: </B>24 Apr 2001
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Spicer<BR>


<P>(From message 9134.)</P>

<P>There is currently no restriction on the use of the
<TT>inline</TT> specifier in <TT>friend</TT> declarations.  That
would mean that the following usage is permitted:</P>

<PRE>
    struct A {
        void f();
    };

    struct B {
        friend inline void A::f();
    };

    void A::f(){}
</PRE>

<P>I believe this should be disallowed because a <TT>friend</TT>
declaration in one class should not be able to change attributes of a
member function of another class.</P>

<P>More generally, I think that the <TT>inline</TT> attribute should
only be permitted in <TT>friend</TT> declarations that are definitions.</P>

<P>
<B>Notes from the 04/01 meeting:</B>
</P>

<P>The consensus agreed with the suggested resolution.  This
outcome would be similar to the resolution of
<A HREF="
     cwg_defects.html#136">issue 136</A>.</P>

<P>
<B>Proposed resolution (10/01):</B>
</P>

<P> Add to the end of 7.1.2&nbsp;



 <A HREF="dcl.html#dcl.fct.spec">dcl.fct.spec</A> paragraph 3:</P>

<BLOCKQUOTE>
If the <TT>inline</TT> specifier is used in a friend declaration, that
declaration shall be a definition or the function shall have
previously been declared inline.
</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="283"></A>
<H4>283.
  
Template <I>type-parameter</I>s are not syntactically <I>type-name</I>s
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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>ready
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Clark Nelson
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>01 May 2001
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>1
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Nelson<BR>


<P>Although 14.1&nbsp;



 <A HREF="template.html#temp.param">temp.param</A> paragraph 3 contains an
assertion that</P>

<BLOCKQUOTE>

A <I>type-parameter</I> defines its identifier to be a
<I>type-name</I> (if declared with <TT>class</TT> or
<TT>typename</TT>)

</BLOCKQUOTE>

<P>the grammar in 7.1.5.2&nbsp;



 <A HREF="dcl.html#dcl.type.simple">dcl.type.simple</A> paragraph 1
says that a <I>type-name</I> is either a <I>class-name</I>, an
<I>enum-name</I>, or a <I>typedef-name</I>.  The <I>identifier</I>
in a template <I>type-parameter</I> is none of those.  One
possibility might be to equate the <I>identifier</I> with a
<I>typedef-name</I> instead of directly with a <I>type-name</I>,
which would have the advantage of not requiring parallel treatment
of the two in situations where they are treated the same (e.g.,
in <I>elaborated-type-specifier</I>s, see
<A HREF="
     cwg_active.html#245">issue 245</A>).  See also
<A HREF="
     cwg_active.html#215">issue 215</A>.</P>

<P>
<B>Proposed resolution (Clark Nelson, March 2002):</B>
</P>

<P>In 14.1&nbsp;



 <A HREF="template.html#temp.param">temp.param</A> paragraph 3,
change "A <I>type-parameter</I> defines its identifier to be a
<I>type-name</I>"
to "A <I>type-parameter</I> defines its identifier
to be a <I>typedef-name</I>"</P>

<P>In 7.1.5.3&nbsp;



 <A HREF="dcl.html#dcl.type.elab">dcl.type.elab</A> paragraph 2,
change "If the identifier resolves to a <I>typedef-name</I> or a template
<I>type-parameter</I>"
to "If the identifier resolves to a <I>typedef-name</I>".</P>

<BR>
<BR>
<HR>
<A NAME="172"></A>
<H4>172.
  
Unsigned int as underlying type of enum
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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>Bjarne Stroustrup
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>26 Sep 1999
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Adamczyk<BR>




<P>From reflector messages 8332-4, 8337.</P>


<P>According to 7.2&nbsp;



 <A HREF="dcl.html#dcl.enum">dcl.enum</A>
 paragraph 5,
the underlying type of an enum is an unspecified integral type,
which could potentially be <TT>unsigned int</TT>.  The promotion
rules in 4.5&nbsp;



 <A HREF="conv.html#conv.prom">conv.prom</A>
 paragraph 2 say
that such an enumeration value used in an expression will be promoted
to <TT>unsigned int</TT>.  This means that a conforming
implementation could give the value <TT>false</TT> for the
following code:</P>

<PRE>
    enum { zero };
    -1 &lt; zero;       // might be false
</PRE>

This is counterintuitive.  Perhaps the description of the underlying
type of an enumeration should say that an unsigned underlying type
can be used only if the values of the enumerators cannot be
represented in the corresponding signed type.  This approach would
be consistent with the treatment of integral promotion of
bitfields (4.5&nbsp;



 <A HREF="conv.html#conv.prom">conv.prom</A>
 paragraph 3).

<P>On a related note,
7.2&nbsp;



 <A HREF="dcl.html#dcl.enum">dcl.enum</A>
 paragraph 5 says,</P>

<BLOCKQUOTE>
the underlying type shall not be larger than <TT>int</TT> unless
the value of an enumerator cannot fit in an <TT>int</TT> or
<TT>unsigned int</TT>.
</BLOCKQUOTE>

<P>This specification does not allow for an enumeration like</P>

<PRE>
    enum { a = -1, b = UINT_MAX };
</PRE>

<P>Since each enumerator can fit in an <TT>int</TT>
or <TT>unsigned int</TT>, the underlying type is required to be
no larger than <TT>int</TT>, even though there is no such type that
can represent all the enumerators.</P>

<P>
<B>Proposed resolution (04/01; obsolete, see below):</B>
</P>

<P>Change 7.2&nbsp;



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

<BLOCKQUOTE>

It is implementation-defined which integral type is used as
the underlying type for an enumeration except that the
underlying type shall not be larger than <TT>int</TT> unless
<S>the value of an enumerator cannot fit in an <TT>int</TT>
or <TT>unsigned int</TT></S> <B>neither <TT>int</TT> nor
<TT>unsigned int</TT> can represent all the enumerator values.
Furthermore, the underlying type shall not be an unsigned
type if the corresponding signed type can represent all the
enumerator values.</B>

</BLOCKQUOTE>

<P>See also <A HREF="
     cwg_active.html#58">issue 58</A>.</P>

<P>
<B>Notes from 04/01 meeting:</B>
</P>

<P>It was noted that 4.5&nbsp;



 <A HREF="conv.html#conv.prom">conv.prom</A> promotes unsigned
types smaller than <TT>int</TT> to (signed) <TT>int</TT>.  The
signedness chosen by an implementation for small underlying types
is therefore unobservable, so the last sentence of the proposed
resolution above should apply only to <TT>int</TT> and larger
types.  This observation also prompted discussion of an
alternative approach to resolving the issue, in which the
<I>b<sub>min</sub></I> and <I>b<sub>max</sub></I> of the enumeration
would determine the promoted type rather than the underlying type.
Steve Adamczyk is investigating this
alternative.
</P>

<P>
<B>Proposed resolution (10/01):</B>
</P>

<P>Change 4.5&nbsp;



 <A HREF="conv.html#conv.prom">conv.prom</A> paragraph 2 from
<BLOCKQUOTE>
An rvalue of type <TT>wchar_t</TT> (3.9.1&nbsp;



 <A HREF="basic.html#basic.fundamental">basic.fundamental</A>)
or an enumeration type
(7.2&nbsp;



 <A HREF="dcl.html#dcl.enum">dcl.enum</A>) can be converted to an rvalue of
the first of the following
types  that  can represent all the values of its underlying type:
<TT>int</TT>, <TT>unsigned int</TT>, <TT>long</TT>, or <TT>unsigned long</TT>.
</BLOCKQUOTE>
to
<BLOCKQUOTE>
An rvalue of type <TT>wchar_t</TT> (3.9.1&nbsp;



 <A HREF="basic.html#basic.fundamental">basic.fundamental</A>)
can be converted to an rvalue of the first of the following
types  that  can represent all the values of its underlying type:
<TT>int</TT>, <TT>unsigned int</TT>, <TT>long</TT>, or <TT>unsigned long</TT>.
An rvalue of an enumeration type (7.2&nbsp;



 <A HREF="dcl.html#dcl.enum">dcl.enum</A>)
can be converted to an rvalue of the first of the following
types  that  can represent all the values of the enumeration (i.e., the
values in the range <I>b<SUB>min</SUB></I> to <I>b<SUB>max</SUB></I> as
described in 7.2&nbsp;



 <A HREF="dcl.html#dcl.enum">dcl.enum</A>):
<TT>int</TT>, <TT>unsigned int</TT>, <TT>long</TT>, or <TT>unsigned long</TT>.
</BLOCKQUOTE>
</P>

<BR>
<BR>
<HR>
<A NAME="29"></A>
<H4>29.
  
Linkage of locally declared functions
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>7.5&nbsp;



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

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

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

 <B>Date: </B>19 Mar 1998
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Gibbons/Adamczyk<BR>



<P>[This was never explicitly voted to DR status, even though it was
marked as having DR status between 4/01 and 4/02.  It was overlooked
when <A HREF="
     cwg_defects.html#4">issue 4</A> was moved to DR at the 4/01
meeting; this one should have been moved as well, because it's resolved
by the changes there.]</P>


<P>From reflector message core-7714.</P>


<P>Consider the following:</P>
<PRE>
    extern "C" void foo()
    {
        extern void bar();
        bar();
    }
</PRE>
Does "bar()" have "C" language linkage?

<P>The ARM is explicit and says</P>
<BLOCKQUOTE>A linkage-specification for a function also applies to functions
and objects declared within it.</BLOCKQUOTE>
The DIS says
<BLOCKQUOTE>In a <I>linkage-specification</I>, the specified language linkage
applies to the function types of all function declarators, function names,
and variable names introduced by the declaration(s).</BLOCKQUOTE>
Is the body of a function definition part of the declaration?

<P>
<U>From Mike Miller:</U>
</P>

<P>Yes: from 7&nbsp;



 <A HREF="dcl.html#dcl.dcl">dcl.dcl</A>
 paragraph 1,</P>
<UL>
<I>declaration:</I>
<UL>
<I>function-definition</I>
</UL>
</UL>
and 8.4&nbsp;



 <A HREF="decl.html#dcl.fct.def">dcl.fct.def</A>
 paragraph 1:
<UL>
<I>function-definition:</I>
<UL>
<I>decl-specifier-seq<SUB>opt</SUB> declarator ctor-initializer<SUB>opt</SUB>&nbsp;function-body</I>
</UL>
</UL>
At least that's how I'd read it.

<P>
<U>From Dag Br&uuml;ck:</U>
</P>

<P>Consider the
following where extern "C" has been moved to a separate declaration:</P>
<PRE>
    extern "C" void foo();
    
    void foo() { extern void bar(); bar(); }
</PRE>
I think the ARM wording could possibly be interpreted such that bar() has
"C" linkage in my example, but not the DIS wording.

<P>As a side note, I have always wanted to think that placing extern "C"
on a function definition or a separate declaration would produce identical
programs.</P>

<P>
<B>Proposed Resolution (04/01):</B>
</P>

<P>See the proposed resolution for
<A HREF="
     cwg_defects.html#4">Core issue 4</A>, which covers this case.</P>

<P>The ODR should also be checked to see whether it addresses name and
type linkage.</P>
<BR>
<BR>
<HR>
<A NAME="295"></A>
<H4>295.
  
cv-qualifiers on function types
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>8.3.5&nbsp;



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

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

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

 <B>Date: </B>29 Jun 2001
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>1
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Maurer<BR>


<P>This concerns the inconsistent treatment of cv qualifiers on
reference types and function types. The problem originated with
GCC bug report c++/2810. The bug report is available at
<A HREF="http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&amp;pr=2810&amp;database=gcc">
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&amp;pr=2810&amp;database=gcc
</A>
</P>

<P>8.3.2&nbsp;



 <A HREF="decl.html#dcl.ref">dcl.ref</A> describes references. Of interest is
the statement (my emphasis)</P>
<BLOCKQUOTE>
Cv-qualified references are ill-formed <B>except</B> when
the cv-qualifiers are introduced through the use of a typedef
or of a template type argument, in which case the cv-qualifiers
are ignored.
</BLOCKQUOTE>
<P>Though it is strange to ignore 'volatile' here, that is not the point
of this defect report. 8.3.5&nbsp;



 <A HREF="decl.html#dcl.fct">dcl.fct</A> describes function types.
Paragraph 4 states,</P>
<BLOCKQUOTE>
In fact, if at any time in the determination of a type a
cv-qualified function type is formed, the program is ill-formed.
</BLOCKQUOTE>
<P>No allowance for typedefs or template type parameters is
made here, which is inconsistent with the equivalent reference case.</P>

<P>The GCC bug report was template code which attempted to do,</P>
<PRE>
    template &lt;typename T&gt; void foo (T const &amp;);
    void baz ();
    ...
    foo (baz);
</PRE>

<P>in the instantiation of foo, <TT>T</TT> is `<TT>void ()</TT>' and an attempt
is made to const qualify that, which is ill-formed. This is a surprise.</P>

<P>
<B>Suggested resolution:</B>
</P>

<P>Replace the quoted sentence from paragraph 4 in
8.3.5&nbsp;



 <A HREF="decl.html#dcl.fct">dcl.fct</A> with</P>
<BLOCKQUOTE>
cv-qualified functions are ill-formed, except when the
cv-qualifiers are introduced through the use of a typedef or of
a template type argument, in which case the cv-qualifiers are
ignored.
</BLOCKQUOTE>
<P>Adjust the example following to reflect this.</P>

<P>
<B>Proposed resolution (10/01):</B>
</P>

<P>In 8.3.5&nbsp;



 <A HREF="decl.html#dcl.fct">dcl.fct</A> paragraph 4, replace
<BLOCKQUOTE>
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,
i.e., it does not create a cv-qualified function type.  In fact, if at
any time in the determination of a type a cv-qualified function type
is formed, the program is ill-formed. [<I>Example:
</I>
<PRE>
  typedef void F();
  struct S {
    const F f;          // ill-formed
  };
</PRE>
<I>-- end example</I>]
</BLOCKQUOTE>
by
<BLOCKQUOTE>
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.  [<I>Example:
</I>
<PRE>
  typedef void F();
  struct S {
    const F f;          // ok; equivalent to void f();
  };
</PRE>
<I>-- end example</I>]
</BLOCKQUOTE>
</P>

<P>Strike the last bulleted item in 14.8.2&nbsp;



 <A HREF="template.html#temp.deduct">temp.deduct</A>
paragraph 2, which reads
<BLOCKQUOTE>
Attempting to create a cv-qualified function type.
</BLOCKQUOTE>
</P>

<P>
<U>Nathan Sidwell</U> comments (18 Dec 2001
in message 9423):
The proposed resolution simply states attempts to add cv qualification
on top of a function type are ignored.  There is no mention of whether
the function type was introduced via a typedef or template type parameter.
This would appear to allow
<PRE>
  void (const *fptr) ();
</PRE>
but, that is not permitted by the grammar.  This is inconsistent
with the wording of adding cv qualifiers to a reference type, which does
mention typedefs and template parameters, even though
<PRE>
  int &amp;const ref;
</PRE>
is also not allowed by the grammar.</P>

<P>Is this difference intentional? It seems needlessly confusing.</P>

<P>
<B>Notes from 4/02 meeting:</B>
</P>

<P>Yes, the difference is intentional.  There is no way to add cv-qualifiers
other than those cases.</P>

<BR>
<BR>
<HR>
<A NAME="302"></A>
<H4>302.
  
Value-initialization and generation of default constructor
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>8.5&nbsp;



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

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

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

 <B>Date: </B>23 Jul 2001
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>1
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Adamczyk<BR>


<P>From message 9258.</P>

<P>We've been looking at implementing value-initialization.  At one point,
some years back, I remember Bjarne saying that something like X() in
an expression should produce an X object with the same value one would
get if one created a static X object, i.e., the uninitialized members
would be zero-initialized because the whole object is initialized
at program startup, before the constructor is called.</P>

<P>The formulation for default-initialization that made it into TC1 (in
8.5&nbsp;



 <A HREF="decl.html#dcl.init">dcl.init</A>)
is written a little differently (see <A HREF="
     cwg_defects.html#178">issue 178</A>),
but I had always 
assumed that it would still be a valid implementation to zero the whole 
object and then call the default constructor for the troublesome
"non-POD but no user-written constructor" cases.</P>

<P>That almost works correctly, but I found a problem case:</P>
<PRE>
    struct A {
      A();
      ~A();
    };
    struct B {
      // B is a non-POD with no user-written constructor.
      // It has a nontrivial generated constructor.
      const int i;
      A a;
    };
    int main () {
      // Value-initializing a "B" doesn't call the default constructor for
      // "B"; it value-initializes the members of B.  Therefore it shouldn't
      // cause an error on generation of the default constructor for the
      // following:
      new B();
    }
</PRE>

<P>If the definition of the <TT>B::B()</TT> constructor is generated, an error
is issued because the const member "<TT>i</TT>" is not initialized.  But the
definition of value-initialization doesn't require calling the
constructor, and therefore it doesn't require generating it, and
therefore the error shouldn't be detected.</P>

<P>So this is a case where zero-initializing and then calling the constructor
is not equivalent to value-initializing, because one case generates
an error and the other doesn't.</P>

<P>This is sort of unfortunate, because one doesn't want to generate all
the required initializations at the point where the "<TT>()</TT>"
initialization
occurs.  One would like those initializations to be packaged in a
function, and the default constructor is pretty much the function
one wants.</P>

<P>I see several implementation choices:</P>
<OL>
<LI>
Zero the object, then call the default generated constructor.  This
is not valid unless the standard is changed to say that the default 
constructor might be generated for value-initialization cases like the
above (that is, it's implementation-dependent whether the constructor
definition is generated).  The zeroing operation can of course be
optimized, if necessary, to hit only the pieces of the object that
would otherwise be left uninitialized.  An alternative would be
to <I>require</I> generation of the constructor for value-initialization
cases, even if the implementation technique doesn't call the
constructor at that point.  It's pretty likely that the constructor
is going to have to be generated at some point in the program anyway.
</LI>
<LI>
Make a new value-initialization "constructor," whose body looks a
lot like the usual generated constructor, but which also zeroes other members.
No errors would be generated while generating this modified constructor,
because it generates code that does full initialization.  (Actually,
it wouldn't guarantee initialization of reference members, and that
might be an argument for generating the constructor, in order to get that
error.)  This is standard-conforming, but it destroys object-code 
compatibility.
</LI>
<LI>
Variation on (1):  Zero first, and generate the object code for the 
default constructor when it's needed for value-initialization cases, but 
don't issue any errors at that time.  Issue the errors only if it turns 
out the constructor is "really" referenced.  Aside from the essential
shadiness of this approach, I fear that something in the generation
of the constructor will cause a template instantiation which will be
an abservable side effect.
</LI>
</OL>

<P>Personally, I find option 1 the least objectionable.</P>

<P>
<B>Proposed resolution (10/01):</B>
</P>

<P>Add the indicated wording to the third-to-last sentence of
3.2&nbsp;



 <A HREF="basic.html#basic.def.odr">basic.def.odr</A> pararaph 2:</P>
<BLOCKQUOTE>
A default constructor for a class is used by default initialization
<B>or value initialization</B> as specified in 8.5&nbsp;



 <A HREF="decl.html#dcl.init">dcl.init</A>.
</BLOCKQUOTE>
<P>Add a footnote to the indicated bullet in 8.5&nbsp;



 <A HREF="decl.html#dcl.init">dcl.init</A>
paragraph 5:</P>
<UL>
<LI>
if <TT>T</TT> is a non-union class type without a user-declared constructor,
then every non-static data member and base-class component of <TT>T</TT> is
value-initialized.
<B>[Footnote: Value-initialization for such a class object may be
implemented by zero-initializing the object and then calling the default
constructor.]</B>
</LI>
</UL>
<P>Add the indicated wording to the first sentence of
12.1&nbsp;



 <A HREF="special.html#class.ctor">class.ctor</A> paragraph 7:</P>
<BLOCKQUOTE>
An implicitly-declared default constructor for a class is <I>implicitly
defined</I> when it is used <B>(3.2&nbsp;



 <A HREF="basic.html#basic.def.odr">basic.def.odr</A>)</B> to
create an object of its class type
(1.8&nbsp;



 <A HREF="intro.html#intro.object">intro.object</A>).
</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="273"></A>
<H4>273.
  
POD classes and <TT>operator&amp;()</TT>
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>9&nbsp;



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

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

 <B>Submitter: </B>Andrei Iltchenko
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>10 Mar 2001
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Maurer<BR>


<P>I think that the definition of a POD class in the current version
of the Standard is overly permissive in that it allows for POD classes
for which a user-defined operator function <TT>operator&amp;</TT> may
be defined. Given that the idea behind POD classes was to achieve
compatibility with C structs and unions, this makes 'Plain old'
structs and unions behave not quite as one would expect them to.</P>

<P>In the C language, if <TT>x</TT> and <TT>y</TT> are variables of
struct or union type <TT>S</TT> that has a member <TT>m</TT>, the
following expression are allowed: <TT>&amp;x</TT>, <TT>x.m</TT>, <TT>x
= y</TT>.  While the C++ standard guarantees that if <TT>x</TT> and
<TT>y</TT> are objects of a POD class type <TT>S</TT>, the expressions
<TT>x.m</TT>, <TT>x = y</TT> will have the same effect as they would
in C, it is still possible for the expression <TT>&amp;x</TT> to be
interpreted differently, subject to the programmer supplying an
appropriate version of a user-defined operator function
<TT>operator&amp;</TT> either as a member function or as a non-member
function.</P>

<P>This may result in surprising effects. Consider:</P>

<PRE>
    // POD_bomb is a POD-struct. It has no non-static non-public data members,
    // no virtual functions, no base classes, no constructors, no user-defined
    // destructor, no user-defined copy assignment operator, no non-static data
    // members of type pointer to member, reference, non-POD-struct, or
    // non-POD-union.
    struct  POD_bomb  {
       int   m_value1;
       int   m_value2;
       int  operator&amp;()
       {   return  m_value1++;   }
       int  operator&amp;() const
       {   return  m_value1 + m_value2;   }
    };
</PRE>

<P>3.9&nbsp;



 <A HREF="basic.html#basic.types">basic.types</A> paragraph 2 states:</P>

<BLOCKQUOTE>

For any complete POD object 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 char</TT> [<I>footnote</I>:
By using, for example, the library functions (17.4.1.2&nbsp;



 <A HREF="lib-intro.html#lib.headers">lib.headers</A>) <TT>memcpy</TT> or <TT>memmove</TT>]. If the
content of the array of <TT>char</TT> or <TT>unsigned char</TT> is
copied back into the object, the object shall subsequently hold its
original value. [<I>Example</I>:

<PRE>
    #define N sizeof(T)
    char buf[N];
    T obj;   // obj initialized to its original value
    memcpy(buf, &amp;obj, N);
		// between these two calls to memcpy,
		// obj might be modified
    memcpy(&amp;obj, buf, N);
		// at this point, each subobject of obj of scalar type
		// holds its original value
</PRE>
&mdash;<I>end example</I>]
</BLOCKQUOTE>

<P>Now, supposing that the complete POD object type <TT>T</TT> in the
example above is <TT>POD_bomb</TT>, and we cannot any more count on
the assertions made in the comments to the example. Given a standard
conforming implementation, the code will not even compile. And I see
no legal way of copying the contents of an object of a complete object
type <TT>POD_bomb</TT> into an array of <TT>char</TT> or <TT>unsigned
char</TT> with <TT>memcpy</TT> or <TT>memmove</TT> without making use
of the unary <TT>&amp;</TT> operator. Except, of course, by means of
an ugly construct like:</P>

<PRE>
    struct  POD_without_ampersand  {
       POD_bomb   a_bomb;
    }  obj;
    #define N sizeof(POD_bomb)
    char buf[N];
    memcpy(buf, &amp;obj, N);
    memcpy(&amp;obj, buf, N);
</PRE>

<P>The fact that the definition of a POD class allows for POD classes
for which a user-defined <TT>operator&amp;</TT> is defined, may also
present major obstacles to implementers of the offsetof macro from
&lt;cstddef&gt;</P>

<P>18.1&nbsp;



 <A HREF="lib-support.html#lib.support.types">lib.support.types</A> paragraph 5 says:</P>

<BLOCKQUOTE>

The macro <TT>offsetof</TT> accepts a restricted set of type arguments
in this International Standard. <TT>type</TT> shall be a POD structure
or a POD union (clause 9&nbsp;



 <A HREF="class.html#class">class</A>). The result of
applying the <TT>offsetof</TT> macro to a field that is a static data
member or a function is undefined."

</BLOCKQUOTE>

<P>Consider a well-formed C++ program below:</P>

<PRE>
    #include &lt;cstddef&gt;
    #include &lt;iostream&gt;


    struct  POD_bomb  {
       int   m_value1;
       int   m_value2;
       int  operator&amp;()
       {   return  m_value1++;   }
       int  operator&amp;() const
       {   return  m_value1 + m_value2;   }
    };


    // POD_struct is a yet another example of a POD-struct.
    struct  POD_struct  {
       POD_bomb   m_nonstatic_bomb1;
       POD_bomb   m_nonstatic_bomb2;
    };


    int  main()
    {

       std::cout &lt;&lt; "offset of m_nonstatic_bomb2: " &lt;&lt; offsetof(POD_struct,
           m_nonstatic_bomb2) &lt;&lt; '\n';
       return  0;

    }
</PRE>

<P>See Jens Maurer's paper 01-0038=N1324 for an analysis of this issue.</P>

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

<P>A consensus was forming around the idea of disallowing
<TT>operator&amp;</TT> in POD classes when it was noticed that it is
permitted to declare global-scope <TT>operator&amp;</TT> functions,
which cause the same problems.  After more discussion, it was
decided that such functions should not be prohibited in POD classes,
and implementors should simply be required to "get the right answer"
in constructs such as <TT>offsetof</TT> and <TT>va_start</TT> that
are conventionally implemented using macros that use the "<TT>&amp;</TT>"
operator.  It was noted that one can cast the original operand to
<TT>char &amp;</TT> to de-type it, after which one can use the
built-in "<TT>&amp;</TT>" safely.</P>

<P>
<B>Proposed resolution:</B>
</P>

<UL>
<LI>Add a footnote in 18.1&nbsp;



 <A HREF="lib-support.html#lib.support.types">lib.support.types</A> paragraph 5:
<BLOCKQUOTE>
[<EM>Footnote:</EM> Note that <TT>offsetof</TT> is required to
work as specified even if unary <TT>operator&amp;</TT> is
overloaded for any of the types involved.]
</BLOCKQUOTE>
</LI>
<LI>Add a footnote in 18.7&nbsp;



 <A HREF="lib-support.html#lib.support.runtime">lib.support.runtime</A> paragraph 3:
<BLOCKQUOTE>
[<EM>Footnote:</EM> Note that <TT>va_start</TT> is required to
work as specified even if unary <TT>operator&amp;</TT> is
overloaded for the type of <TT>parmN</TT>.]
</BLOCKQUOTE>
</LI>
</UL>

<BR>
<BR>
<HR>
<A NAME="284"></A>
<H4>284.
  
<I>qualified-id</I>s in class declarations
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>9&nbsp;



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

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

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

 <B>Date: </B>01 May 2001
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>1
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Vandevoorde<BR>


<P>Although 8.3&nbsp;



 <A HREF="decl.html#dcl.meaning">dcl.meaning</A> requires that a declaration of
a <I>qualified-id</I> refer to a member of the specified namespace or
class and that the member not have been introduced by a
<I>using-declaration</I>, it applies only to names declared in a
declarator.  It is not clear whether there is existing wording
enforcing the same restriction for <I>qualified-id</I>s in
<I>class-specifier</I>s and <I>elaborated-type-specifier</I>s or
whether additional wording is required.  Once such wording is
found/created, the proposed resolution of
<A HREF="
     cwg_defects.html#275">issue 275</A> must be modified accordingly.</P>

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

<P>The sentiment was that this should be required on class definitions, but
not on elaborated type specifiers in general (which are references, not
declarations).  We should also make sure we consider explicit instantiations,
explicit specializations, and friend declarations.</P>


<P>
<B>Proposed resolution (10/01):</B>
</P>

<P>Add after the end of 9.1&nbsp;



 <A HREF="class.html#class.name">class.name</A> paragraph 3:</P>
<BLOCKQUOTE>
When a <I>nested-name-specifier</I> is specified in a
<I>class-head</I> or in an
<I>elaborated-type-specifier</I>, the resulting qualified name
shall refer to a previously declared member of the class or namespace to
which the <I>nested-name-specifier</I> refers, and
the member shall not have been introduced by a
using-declaration in the scope of the class or namespace
nominated by the <I>nested-name-specifier</I>.
</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="296"></A>
<H4>296.
  
Can conversion functions be static?
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>12.3.2&nbsp;



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

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

 <B>Submitter: </B>Scott Meyers
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>5 Jul 2001
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>3<BR>


<P>May user-defined conversion functions be static?  That is, should this
compile?</P>
<PRE>
    class Widget {
    public:
      static operator bool() { return true; }
    };
</PRE>
<P>All my compilers hate it.  I hate it, too.  However, I don't see anything
in 12.3.2&nbsp;



 <A HREF="special.html#class.conv.fct">class.conv.fct</A> that makes it illegal.  Is this a
prohibition that arises from
the grammar, i.e., the grammar doesn't allow "static" to be followed by a
<I>conversion-function-id</I> in a member function declaration?  Or am I just
overlooking something obvious that forbids static conversion functions?</P>

<P>
<B>Proposed Resolution (4/02):</B>
</P>

<P>Add to 12.3.2&nbsp;



 <A HREF="special.html#class.conv.fct">class.conv.fct</A> as a new paragraph 7:</P>

<BLOCKQUOTE>
Conversion functions cannot be declared <TT>static</TT>.
</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="244"></A>
<H4>244.
  
Destructor lookup
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>12.4&nbsp;



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

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

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

 <B>Date: </B>6 Sep 2000
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>1
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Merrill<BR>


<P>From messages 8895-6.</P>

<P>12.4&nbsp;



 <A HREF="special.html#class.dtor">class.dtor</A> contains this example:</P>

<PRE>
    struct B {
        virtual ~B() { }
    };
    struct D : B {
        ~D() { }
    };

    D D_object;
    typedef B B_alias;
    B* B_ptr = &amp;D_object;

    void f() {
        D_object.B::~B();               // calls B's destructor
        B_ptr-&gt;~B();                    // calls D's destructor
        B_ptr-&gt;~B_alias();              // calls D's destructor
        B_ptr-&gt;B_alias::~B();           // calls B's destructor
        B_ptr-&gt;B_alias::~B_alias();     // error, no B_alias in class B
    }
</PRE>

<P>On the other hand, 3.4.3&nbsp;



 <A HREF="basic.html#basic.lookup.qual">basic.lookup.qual</A> contains this
example:</P>

<PRE>
    struct C {
        typedef int I;
    };
    typedef int I1, I2;
    extern int* p;
    extern int* q;
    p-&gt;C::I::~I();       // I is looked up in the scope of C
    q-&gt;I1::~I2();        // I2 is looked up in the scope of
                         // the postfix-expression
    struct A {
        ~A();
    };
    typedef A AB;
    int main()
    {
        AB *p;
        p-&gt;AB::~AB();    // explicitly calls the destructor for A
    }
</PRE>

<P>Note that</P>

<PRE>
     B_ptr-&gt;B_alias::~B_alias();
</PRE>

<P>is claimed to be an error, while the equivalent</P>

<PRE>
     p-&gt;AB::~AB();
</PRE>

<P>is claimed to be well-formed.</P>

<P>I believe that clause 3 is correct and that clause 12 is in error.
We worked hard to get the destructor lookup rules in clause 3 to be
right, and I think we failed to notice that a change was also needed
in clause 12.</P>

<P>
<U>Mike Miller</U>:</P>

<P>Unfortunately, I don't believe 3.4.3&nbsp;



 <A HREF="basic.html#basic.lookup.qual">basic.lookup.qual</A> covers
the case of <TT>p-&gt;AB::~AB()</TT>.  It's clearly intended to do so, as
evidenced by 3.4.3.1&nbsp;



 <A HREF="basic.html#class.qual">class.qual</A> paragraph 1 ("a
destructor name is looked up as specified in 3.4.3&nbsp;



 <A HREF="basic.html#basic.lookup.qual">basic.lookup.qual</A>"), but I don't think the language there does so.</P>

<P>The relevant paragraph is 3.4.3&nbsp;



 <A HREF="basic.html#basic.lookup.qual">basic.lookup.qual</A> paragraph
5.  (None of the other paragraphs in that section deal with this topic
at all.)  It has two parts.  The first is</P>

<BLOCKQUOTE>
If a <I>pseudo-destructor-name</I> (5.2.4&nbsp;



 <A HREF="expr.html#expr.pseudo">expr.pseudo</A>)
contains a <I>nested-name-specifier</I>, the <I>type-name</I>s are
looked up as types in the scope designated by the
<I>nested-name-specifier</I>.
</BLOCKQUOTE>

<P>This sentence doesn't apply, because <TT>~AB</TT> isn't a
<I>pseudo-destructor-name</I>.  5.2.4&nbsp;



 <A HREF="expr.html#expr.pseudo">expr.pseudo</A> makes
clear that this syntactic production (5.2&nbsp;



 <A HREF="expr.html#expr.post">expr.post</A>
paragraph 1) only applies to cases where the <I>type-name</I> is not a
<I>class-name</I>.  <TT>p-&gt;AB::~AB</TT> is covered by the production
using <I>id-expression</I>.</P>

<P>The second part of 3.4.3&nbsp;



 <A HREF="basic.html#basic.lookup.qual">basic.lookup.qual</A> paragraph 5 says</P>

<BLOCKQUOTE>
<P>In a <I>qualified-id</I> of the form:</P>

<OL>
<TT>::</TT><SUB>opt</SUB>&nbsp;<I>nested-name-specifier</I>&nbsp;<TT>~</TT>&nbsp;<I>class-name</I>
</OL>

<P>where the <I>nested-name-specifier</I> designates a namespace name,
and in a <I>qualified-id</I> of the form:</P>

<OL>
<TT>::</TT><SUB>opt</SUB>&nbsp;<I>nested-name-specifier&nbsp;class-name</I>&nbsp;<TT>::</TT>&nbsp;<TT>~</TT>&nbsp;<I>class-name</I>
</OL>

<P>the <I>class-name</I>s are looked up as types in the scope
designated by the <I>nested-name-specifier</I>.</P>
</BLOCKQUOTE>

<P>This wording doesn't apply, either.  The first one doesn't because
the <I>nested-name-specifier</I> is a <I>class-name</I>, not a
namespace name.  The second doesn't because there's only one layer of
qualification.</P>

<P>As far as I can tell, there's no normative text that specifies how
the <TT>~AB</TT> is looked up in <TT>p-&gt;AB::~AB()</TT>.
3.4.3.1&nbsp;



 <A HREF="basic.html#class.qual">class.qual</A>, where all the other
class member qualified lookups are handled, defers to
3.4.3&nbsp;



 <A HREF="basic.html#basic.lookup.qual">basic.lookup.qual</A>, and 3.4.3&nbsp;



 <A HREF="basic.html#basic.lookup.qual">basic.lookup.qual</A>
doesn't cover the case.</P>

<P>See also <A HREF="
     cwg_active.html#305">issue 305</A>.</P>

<P>
<U>Jason Merrill</U>, in message 9325:
My thoughts on the subject were that the name we use in a destructor call
is really meaningless; as soon as we see the <TT>~</TT> we know what the
user means,
all we're doing from that point is testing their ability to name the
destructor in a conformant way.  I think that everyone will agree that
<PRE>
  anything::B::~B()
</PRE>
should be well-formed, regardless of the origins of the name "B".  I
believe that the rule about looking up the second "B" in the same context
as the first was intended to provide this behavior, but to me this seems
much more heavyweight than necessary.  We don't need a whole new type of
lookup to be able to use the same name before and after the <TT>~</TT>;
we can just
say that if the two names match, the call is well-formed.  This is
significantly simpler to express, both in the standard and in an
implementation.</P>

<P>Anyone writing two different names here is either deliberately writing
obfuscated code, trying to call the destructor of a nested class, or
fighting an ornery compiler (i.e. one that still wants to see
<TT>B_alias::~B()</TT>).  I think we can ignore the first case.
The third would be
handled by reverting to the old rule (look up the name after <TT>~</TT> in the
normal way) with the lexical matching exception described above -- or we
could decide to break such code, do no lookup at all, and only accept a
matching name.  In a good implementation, the second should probably get an
error message telling them to write <TT>Outer::Inner::~Inner</TT> instead.</P>

<P>We discussed this at the meetings, but I don't remember if we came to
any sort of consensus on a direction.  I see three options:</P>
<OL>
<LI>
Stick with the status quo, i.e. the special lookup rule such that if the
name before <TT>::~</TT> is a class name, the name after <TT>::~</TT>
is looked up in the
same scope as the previous one.  If we choose this option, we just need
better wording that actually expresses this, as suggested in the issue
list.  This option breaks old <TT>B_alias::~B</TT> code where <TT>B_alias</TT>
is declared in a different scope from <TT>B</TT>.
</LI>
<LI>
Revert to the old rules, whereby the name after <TT>::~</TT> is looked up just
like a name after <TT>::</TT>, with the exception that if it matches the name
before <TT>::~</TT> then it is considered to name the same class.  This option
supports old code and code that writes <TT>B_alias::~B_alias</TT>.  It does not
support the <TT>q-&gt;I1::~I2</TT> usage of 3.4.3&nbsp;



 <A HREF="basic.html#basic.lookup.qual">basic.lookup.qual</A>,
but that seems like deliberate
obfuscation.  This option is simpler to implement than #1.
</LI>
<LI>
Do no lookup for a name after <TT>::~</TT>; it must match the
name before.  This
breaks old code as #1, but supports the most important case where the
names match.  This option may be slightly simpler to implement than #2.
It is certainly easier to teach.
</LI>
</OL>

<P>My order of preference is 2, 3, 1.</P>

<P>Incidentally, it seems to me oddly inconsistent to allow
<I>Namespace</I><TT>::~</TT><I>Class</I>,
but not <I>Outer</I><TT>::~</TT><I>Inner</I>.
Prohibiting the latter makes sense from the
standpoint of avoiding ambiguity, but what was the rationale for allowing
the former?</P>

<P>
<U>John Spicer</U>, in message 9328:
I agree that allowing <I>Namespace</I><TT>::~</TT><I>Class</I> is odd.
I'm not sure where this
came from.  If we eliminated that special case, then I believe the #1
rule would just be that in <TT>A::B1::~B2</TT> you look up <TT>B1</TT>
and <TT>B2</TT> in the same place in all cases.</P>

<P>I don't like #2.  I don't think the "old" rules represent a deliberate
design choice, just an error in the way the lookup was described.  The
usage that rule permits <TT>p-&gt;X::~Y</TT>
(where <TT>Y</TT> is a typedef to <TT>X</TT> defined in <TT>X</TT>),
but I doubt people really do that.  In other words, I think that #1
a more useful special case than #2 does, not that I think either special
case is very important.</P>

<P>One problem with the name matching rule is handling cases like:
<PRE>
  A&lt;int&gt; *aip;

  aip-&gt;A&lt;int&gt;::~A&lt;int&gt;();  // should work
  aip-&gt;A&lt;int&gt;::~A&lt;char&gt;(); // should not
</PRE>
I would favor #1, while eliminating the special case of
<I>Namespace</I><TT>::~</TT><I>Class</I>.</P>

<P>
<B>Proposed resolution (10/01):</B>
</P>

<P>Replace the normative text of 3.4.3&nbsp;



 <A HREF="basic.html#basic.lookup.qual">basic.lookup.qual</A> paragraph 5
after the first sentence with:</P>
<BLOCKQUOTE>
<P>Similarly, in a <I>qualified-id</I> of the form:
<PRE>    ::<SUB>opt</SUB> <I>nested-name-specifier</I><SUB>opt</SUB> <I>class-name</I> :: ~ <I>class-name</I>
</PRE>
the second <I>class-name</I> is looked up in the same scope as the first.</P>
</BLOCKQUOTE>
<P>In 12.4&nbsp;



 <A HREF="special.html#class.dtor">class.dtor</A> paragraph 12, change the example to</P>
<BLOCKQUOTE>
<PRE>
D D_object;
typedef B B_alias;
B* B_ptr = &amp;D_object;

void f() {
  D_object.B::~B();                //<I>  calls  </I>B<I>'s destructor</I>
  B_ptr-&gt;~B();                    //<I>  calls  </I>D<I>'s destructor</I>
  B_ptr-&gt;~B_alias();              //<I>  calls  </I>D<I>'s destructor</I>
  B_ptr-&gt;B_alias::~B();           //<I>  calls  </I>B<I>'s destructor</I>
  B_ptr-&gt;B_alias::~B_alias();     //<I>  calls  </I>B<I>'s destructor</I>
}
</PRE>
</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="162"></A>
<H4>162.
  
(<TT>&amp;C::f)()</TT> with nonstatic members
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>13.3.1.1&nbsp;



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

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

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

 <B>Date: </B>26 Aug 1999
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>3
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Adamczyk<BR>




<P>From reflector messages 8289 and 8305.</P>


<P>13.3.1.1&nbsp;



 <A HREF="over.html#over.match.call">over.match.call</A>
 paragraph 3
says that when a call of the form</P>

<PRE>
   (&amp;C::f)()
</PRE>

is written, the set of overloaded functions named by <TT>C::f</TT>
must not contain
any nonstatic member functions.  A footnote gives the rationale: if a member
of <TT>C::f</TT> is a nonstatic member function,
<TT>&amp;C::f</TT> is a pointer to member
constant, and therefore the call is invalid.

<P>This is clear, it's implementable, and it doesn't directly contradict
anything else in the standard.  However, I'm not sure it's consistent
with some similar cases.</P>

<P>In 13.4&nbsp;



 <A HREF="over.html#over.over">over.over</A>
 paragraph 5,
second example, it is made amply clear that when <TT>&amp;C::f</TT> is
used as the address of a function, e.g.,</P>

<PRE>
   int (*pf)(int) = &amp;C::f;
</PRE>

the overload set can contain both static and nonstatic member functions.
The function with the matching signature is selected, and if it is
nonstatic <TT>&amp;C::f</TT>
is a pointer to member function, and otherwise <TT>&amp;C::f</TT> is
a normal pointer to function.

<P>Similarly, 13.3.1.1.1&nbsp;



 <A HREF="over.html#over.call.func">over.call.func</A>

paragraph 3 makes it clear that</P>

<PRE>
   C::f();
</PRE>

is a valid call even if the overload set contains both static and
nonstatic member functions.  Overload resolution is done, and if a
nonstatic member function is selected, an implicit <TT>this-&gt;</TT> is added,
if that is possible.

<P>Those paragraphs seem to suggest the general rule that you do overload
resolution first and then you interpret the construct you have
according to the function selected.  The fact that there are static
and nonstatic functions in the overload set is irrelevant; it's only
necessary that the chosen function be static or nonstatic to match
the context.</P>

<P>Given that, I think it would be more consistent if the
<TT>(&amp;C::f)()</TT> case
would also do overload resolution first.  If a nonstatic member is
chosen, the program would be ill-formed.</P>

<P>
<B>Proposed resolution (04/01):</B>
</P>

<OL>

<LI>
<P>Change the indicated text in 13.3.1.1&nbsp;



 <A HREF="over.html#over.match.call">over.match.call</A>
paragraph 3:</P>

<BLOCKQUOTE>
The fourth case arises from a <I>postfix-expression</I> of the form
<TT>&amp;F</TT>, where
<TT>F</TT> names  a set of overloaded functions.
In the context of a function call,
<S>the set of functions named by <TT>F</TT> shall contain only non-member
functions and static member functions. [Footnote:
If <TT>F</TT> names a non-static member function, <TT>&amp;F</TT>
is a pointer-to-member, which cannot be used with the function call syntax.]
And in this context using <TT>&amp;F</TT> behaves the same as using</S>
<B><TT>&amp;F</TT> is treated the same as</B>
the name <TT>F</TT> by itself.
Thus, <TT>(&amp;F)(</TT><I>expression-list</I><sub>opt</sub><TT>)</TT>
is simply
<TT>(F)(</TT><I>expression-list</I><sub>opt</sub><TT>)</TT>, which is
discussed in 13.3.1.1.1&nbsp;



 <A HREF="over.html#over.call.func">over.call.func</A>.
<B>If the function selected by overload resolution according to 
13.3.1.1.1&nbsp;



 <A HREF="over.html#over.call.func">over.call.func</A> is
a nonstatic member function, the program is
ill-formed. [Footnote: When <TT>F</TT> is a nonstatic member
function, a reference of the form <TT>&amp;A::F</TT> is a
pointer-to-member,
which cannot be used with the function-call syntax, and
a reference of the form <TT>&amp;F</TT> is an invalid use of the
"<TT>&amp;</TT>" operator on a nonstatic member function.]</B>
(The resolution of <TT>&amp;F</TT> in other contexts is described in
13.4&nbsp;



 <A HREF="over.html#over.over">over.over</A>.)
</BLOCKQUOTE>
</LI>
</OL>

<BR>
<BR>
<HR>
<A NAME="60"></A>
<H4>60.
  
Reference binding and valid conversion sequences
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>13.3.3.1.4&nbsp;



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

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

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

 <B>Date: </B>13 Oct 1998
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Adamczyk<BR>



<P>Does dropping a cv-qualifier on a reference binding prevent the binding
as far as overload resolution is concerned?
Paragraph 4 says "Other restrictions
on binding a reference to a particular argument do not affect the formation
of a conversion sequence."  This was intended to refer to things like access
checking, but some readers have taken that to mean that any aspects of
reference binding not mentioned in this section do not preclude the binding.</P>

<P>
<B>Proposed resolution (10/01):</B>
</P>

<P>In 13.3.3.1.4&nbsp;



 <A HREF="over.html#over.ics.ref">over.ics.ref</A> paragraph 4 add the
indicated text:</P>
<BLOCKQUOTE>
Other restrictions on binding a reference to a particular argument <B>that
are not based on the types of the reference and the argument</B> do
not  affect  the formation of a standard conversion sequence, however.
</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="63"></A>
<H4>63.
  
Class instantiation from pointer conversion to void*, null and self
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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>Steve Adamczyk
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>13 Oct 1998
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>3
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Merrill<BR>



<P>A template is implicitly instantiated because of a "pointer conversion"
on an argument. This was intended to include related-class conversions,
but it also inadvertently includes conversions to <TT>void*, </TT>null
pointer conversions, cv-qualification conversions and the identity conversion.</P>

<P>It is not clear whether a <TT>reinterpret_cast</TT> of a pointer should
cause implicit instantiation.</P>

<P>
<B>Proposed resolution (10/01):</B> Replace
14.7.1&nbsp;



 <A HREF="template.html#temp.inst">temp.inst</A>
 paragraph 4, up to the
example, with the following:</P>
<BLOCKQUOTE>
A class template specialization is implicitly instantiated if the
class type is used in a context that requires a completely-defined
object type or if the completeness of the class type might affect the
semantics of the program.  [<I>Note:</I> in particular, if the
semantics of an expression depend on the member or base class lists
of a class template specialization, the class template specialization
is implicitly generated.  For instance, deleting a pointer to class
type depends on whether or not the class declares a destructor, and
conversion between pointer to class types depends on the inheritance
relationship between the two classes involved. ]
</BLOCKQUOTE>

<P>This version differs from the previous version is its use of the
word "might" in the first sentence.</P>

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

<BR>
<BR>
<HR>
<A NAME="300"></A>
<H4>300.
  
References to functions in template argument deduction
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>14.8.2.4&nbsp;



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

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

 <B>Submitter: </B>Andrei Iltchenko
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>11 Jul 2001
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>0
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Adamczyk<BR>


<P>Paragraph 9 of 14.8.2.4&nbsp;



 <A HREF="template.html#temp.deduct.type">temp.deduct.type</A> enumerates the
forms that the types P and A need to have in order for template
argument deduction to succeed.</P>

<P>For P denoting a pointer to function the paragraph lists the following
forms as allowing for template argument deduction:</P>
<PRE>
type(*)(T)
T(*)()
T(*)(T)
</PRE>

<P>On the other hand, no provision has been made to accommodate similar
cases for references to functions, which in light of the wording of
14.8.2.4&nbsp;



 <A HREF="template.html#temp.deduct.type">temp.deduct.type</A> paragraph 11 means that the program below
is ill-formed (some of the C++ compilers do not reject it however):</P>

<PRE>
    template&lt;typename Arg, typename Result, typename T&gt;
    Result  foo_r(Result(&amp; rf)(Arg), T x)
    {   return  rf(Arg(x));   }

    template&lt;typename Arg, typename Result, typename T&gt;
    Result  foo_p(Result(* pf)(Arg), T x)
    {   return  pf(Arg(x));   }

    #include &lt;iostream&gt;
    int  show_arg(char c)
    {
       std::cout &lt;&lt; c &lt;&lt; ' ';
       if(std::cout)  return  0;
       return  -1;
    }

    int  main()
    {
                                                   // The deduction 
       int  (&amp; rf1)(int(&amp;)(char), double) = foo_r; // shall fail here
                                                   // While here
       int  (&amp; rf2)(int(*)(char), double) = foo_p; // it shall succeed
       return  rf2(show_arg, 2);
    }
</PRE>

<P>
<B>Proposed resolution (10/01, same as suggested resolution):</B>
</P>

<P>In the list of allowable forms for the types <TT>P</TT> and
<TT>A</TT> in paragraph 9 of
14.8.2.4&nbsp;



 <A HREF="template.html#temp.deduct.type">temp.deduct.type</A> replace</P>
<PRE>
type(*)(T)
T(*)()
T(*)(T)
</PRE>
<P>by</P>
<PRE>
type(T)
T()
T(T)
</PRE>

<BR>
<BR>
<BR>
<BR>
<HR>
<A NAME="Review Status"></A>
<H3>Issues with "Review" Status</H3>
<HR>
<A NAME="298"></A>
<H4>298.
  
<TT>T::x</TT> when <TT>T</TT> is cv-qualified
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>3.4.3.1&nbsp;



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

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

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

 <B>Date: </B>7 Jul 2001
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Nelson<BR>


<P>Can a typedef <TT>T</TT> to a cv-qualified class type be used
in a qualified name <TT>T::x</TT>?</P>

<PRE>
    struct A { static int i; };
    typedef const A CA;
    int main () {
      CA::i = 0;  // Okay?
    }
</PRE>

<P>Suggested answer: Yes.  All the compilers I tried accept the test case.</P>

<P>
<B>Proposed resolution (10/01):</B>
</P>

<P>In 3.4.3.1&nbsp;



 <A HREF="basic.html#class.qual">class.qual</A> paragraph 1 add the indicated text:
<BLOCKQUOTE>
If the <I>nested-name-specifier</I> of a <I>qualified-id</I> nominates
a class,  the
name  specified  after  the  <I>nested-name-specifier</I> is looked up in the
scope of the  class  (10.2&nbsp;



 <A HREF="derived.html#class.member.lookup">class.member.lookup</A>),  except  for  the  cases
listed  below.   The  name shall represent one or more members of that
class or of one of its base classes (clause 10&nbsp;



 <A HREF="derived.html#class.derived">class.derived</A>). 
<B>If the <I>class-or-namespace-name</I> of the <I>nested-name-specifier</I>
names a cv-qualified class type, it nominates the underlying class
(the cv-qualifiers are ignored).</B>
</BLOCKQUOTE>
</P>

<P>
<B>Notes from 4/02 meeting:</B>
</P>

<P>There is a problem in that <I>class-or-namespace-name</I> does not
include typedef names for cv-qualified class types.  See
7.1.3&nbsp;



 <A HREF="dcl.html#dcl.typedef">dcl.typedef</A> paragraph 4.</P>

<BR>
<BR>
<HR>
<A NAME="318"></A>
<H4>318.
  
<TT>struct A::A</TT> should not name the constructor of <TT>A</TT>
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>3.4.3.1&nbsp;



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

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

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

 <B>Date: </B>18 Oct 2001
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>0
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Spicer<BR>


<P>A use of an injected-class-name in an elaborated-type-specifier
should not name the constructor of the class, but rather the class itself,
because in that context we know that we're looking for a type.
See <A HREF="
     cwg_defects.html#147">issue 147</A>.</P>

<P>
<B>Proposed Resolution (4/02):</B>
</P>

<P> This clarifies the changes made in the TC for issue 147.</P>

<P>In 3.4.3.1&nbsp;



 <A HREF="basic.html#class.qual">class.qual</A> paragraph 1a replace:</P>
<BLOCKQUOTE>
If the <I>nested-name-specifier</I> nominates a class C, and the name
specified after the <I>nested-name-specifier</I>, when looked up in C, is the
injected class name of C (clause 9&nbsp;



 <A HREF="class.html#class">class</A>), the name is instead
considered to name the constructor of class C.
</BLOCKQUOTE>
<P> with </P>
<BLOCKQUOTE>
In a lookup in which the constructor is an acceptable lookup result
if the <I>nested-name-specifier</I> nominates a class C, and the name
specified after the <I>nested-name-specifier</I>, when looked up in C, is the
injected class name of C (clause 9&nbsp;



 <A HREF="class.html#class">class</A>), the name is
instead considered to name the constructor of class C.
[Note: For example, the constructor is not an acceptable lookup result in an
elaborated type specifier so the constructor would not be used in place
of the injected class name.]
</BLOCKQUOTE>

<P>Note that <A HREF="
     cwg_active.html#263">issue 263</A> updates a part of the
same paragraph.</P>

<P>Append to the example:</P>
<PRE>
  struct A::A a2;  // object of type A
</PRE>

<BR>
<BR>
<HR>
<A NAME="245"></A>
<H4>245.
  
Name lookup in <I>elaborated-type-specifier</I>s
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>3.4.4&nbsp;



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

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

 <B>Submitter: </B>Jack Rouse
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>14 Sep 2000
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>1
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Nelson<BR>


<P>From message 8898.</P>

<P>I have some concerns with the description of name lookup for
elaborated type specifiers in 3.4.4&nbsp;



 <A HREF="basic.html#basic.lookup.elab">basic.lookup.elab</A>:</P>

<OL>

<LI>
<P>Paragraph 2 has some parodoxical statements concerning looking up
names that are simple identifers:</P>

<BLOCKQUOTE>
If the <I>elaborated-type-specifier</I> refers to an <I>enum-name</I>
and this lookup does not find a previously declared <I>enum-name</I>,
the <I>elaborated-type-specifier</I> is ill-formed. If the
<I>elaborated-type-specifier</I> refers to an <I>[sic]</I>
<I>class-name</I> and this lookup does not find a previously declared
<I>class-name</I>... the <I>elaborated-type-specifier</I> is a
declaration that introduces the <I>class-name</I> as described in
3.3.1&nbsp;



 <A HREF="basic.html#basic.scope.pdecl">basic.scope.pdecl</A>."
</BLOCKQUOTE>

<P>It is not clear how an <I>elaborated-type-specifier</I> can refer
to an <I>enum-name</I> or <I>class-name</I> given that the lookup does
not find such a name and that <I>class-name</I> and <I>enum-name</I>
are not part of the syntax of an <I>elaborated-type-specifier</I>.</P>
</LI>

<LI>
<P>The second sentence quoted above seems to suggest that the name found
will not be used if it is not a class name.  <I>typedef-name</I> names
are ill-formed due to the sentence preceding the quote.  If lookup
finds, for instance, an <I>enum-name</I> then a new declaration will
be created.  This differs from C, and from the enum case, and can have
surprising effects:</P>

<PRE>
    struct S {
       enum E {
           one = 1
       };
       class E* p;     // declares a global class E?
    };
</PRE>

<P>Was this really the intent?  If this is the case then some more
work is needed on 3.4.4&nbsp;



 <A HREF="basic.html#basic.lookup.elab">basic.lookup.elab</A>.  Note that the
section does not make finding a type template formal ill-formed, as is
done in 7.1.5.3&nbsp;



 <A HREF="dcl.html#dcl.type.elab">dcl.type.elab</A>.  I don't see anything that
makes a type template formal name a <I>class-name</I>.  So the example
in 7.1.5.3&nbsp;



 <A HREF="dcl.html#dcl.type.elab">dcl.type.elab</A> of <TT>friend class T;</TT> where
<TT>T</TT> is a template type formal would no longer be ill-formed
with this interpretation because it would declare a new class
<TT>T</TT>.</P> </LI>
</OL>

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

<P>
<B>Proposed resolution (04/01):</B>
</P>

<P>The guiding principle is to deal only with actual name lookup
issues in 3.4.4&nbsp;



 <A HREF="basic.html#basic.lookup.elab">basic.lookup.elab</A>, and to deal with
issues of conflict with prior declarations (found by name lookup)
in 7.1.5.3&nbsp;



 <A HREF="dcl.html#dcl.type.elab">dcl.type.elab</A>.</P>

<OL>

<LI>
<P>Change 3.4.4&nbsp;



 <A HREF="basic.html#basic.lookup.elab">basic.lookup.elab</A> paragraph 1:</P>

<BLOCKQUOTE>

An <I>elaborated-type-specifier</I> <B>(7.1.5.3&nbsp;



 <A HREF="dcl.html#dcl.type.elab">dcl.type.elab</A>)</B> may be used to refer to a previously declared
<I>class-name</I> or <I>enum-name</I> even though the name has been
hidden by a non-type declaration (3.3.7&nbsp;



 <A HREF="basic.html#basic.scope.hiding">basic.scope.hiding</A>). The
<I>class-name</I> or <I>enum-name</I> in the
<I>elaborated-type-specifier</I> may <B>be</B> either <S>be</S> a
simple identifer or <S>be</S> a <I>qualified-id</I>.

</BLOCKQUOTE>
</LI>

<LI>
<P>Change 3.4.4&nbsp;



 <A HREF="basic.html#basic.lookup.elab">basic.lookup.elab</A> paragraph 2:</P>

<BLOCKQUOTE>

If the name in the <I>elaborated-type-specifier</I> is a simple identifer,
and unless the <I>elaborated-type-specifier</I> has the following form:

<BLOCKQUOTE>
<I>class-key identifier ;</I>
</BLOCKQUOTE>

the identifier is looked up according to 3.4.1&nbsp;



 <A HREF="basic.html#basic.lookup.unqual">basic.lookup.unqual</A>
but ignoring any non-type names that have been declared. <S>If this
name lookup finds a <I>typedef-name</I>, the
<I>elaborated-type-specifier</I> is ill-formed.</S> If the
<I>elaborated-type-specifier</I> <S>refers to an <I>enum-name</I></S>
<B>is introduced by the <TT>enum</TT> keyword</B> and this lookup does
not find a previously declared
<S><I>enum-name</I></S> <B><I>type-name</I></B>, the
<I>elaborated-type-specifier</I> is ill-formed. If the
<I>elaborated-type-specifier</I> <S>refers to an <I>class-name</I></S>
<B>is introduced by a <I>class-key</I></B>
and this lookup does not find a previously declared
<S><I>class-name</I></S> <B><I>type-name</I></B>, or if the
<I>elaborated-type-specifier</I> has the form:
<BLOCKQUOTE>
<I>class-key identifier ;</I>
</BLOCKQUOTE>
the
<I>elaborated-type-specifier</I> is a declaration that introduces the
<I>class-name</I> as described in 3.3.1&nbsp;



 <A HREF="basic.html#basic.scope.pdecl">basic.scope.pdecl</A>.

</BLOCKQUOTE>

</LI>

<LI>
<P>Change 3.4.4&nbsp;



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

<BLOCKQUOTE>

If the name is a <I>qualified-id</I>, the name is looked up according
its qualifications, as described in 3.4.3&nbsp;



 <A HREF="basic.html#basic.lookup.qual">basic.lookup.qual</A>, but
ignoring any non-type names that have been declared. <S>If this name
lookup finds a <I>typedef-name</I>, the
<I>elaborated-type-specifier</I> is ill-formed.</S> If this name
lookup does not find a previously declared <S><I>class-name</I> or
<I>enum-name</I></S> <I>type-name</I>, the
<I>elaborated-type-specifier</I> is ill-formed.

</BLOCKQUOTE>

</LI>

<LI>
<P>To eliminate redundancy, in 7.1.5.3&nbsp;



 <A HREF="dcl.html#dcl.type.elab">dcl.type.elab</A>
paragraph 2, delete:</P>

<BLOCKQUOTE>

If name lookup does not find a declaration for the name, the
<I>elaborated-type-specifier</I> is ill-formed unless it is of the
simple form <I>class-key identifier</I> in which case the
<I>identifier</I> is declared as described in 3.3.1&nbsp;



 <A HREF="basic.html#basic.scope.pdecl">basic.scope.pdecl</A>.

</BLOCKQUOTE>

</LI>

</OL>

<P>(This resolution assumes that the disjunction between
<I>type-name</I>s and template <I>type-parameter</I>s described
in <A HREF="
     cwg_active.html#283">issue 283</A> is resolved.  It also
depends on the resolution of <A HREF="
     cwg_active.html#215">issue 215</A>
for the grammar of <I>nested-name-specifer</I>s, so that all
<I>type-name</I>s and not just <I>class-name</I>s and
<I>namespace-name</I>s can participate in the lookup.)</P>

<P>
<B>Additional changes (Clark Nelson, March 2002):</B>
</P>

<P>In 3.4.4&nbsp;



 <A HREF="basic.html#basic.lookup.elab">basic.lookup.elab</A> paragraph 2:
The grammar of <I>elaborated-type-specifier</I> does not allow a semicolon.
Change "the <I>elaborated-type-specifier</I> has the [following] form"
(which occurs twice) to
"the <I>elaborated-type-specifier</I> appears in a declaration with the
form".</P>

<P>The grammar of <I>elaborated-type-specifier</I> has no <I>class-name</I>,
<I>enum-name</I> or <I>qualified-id</I>.
Therefore, editorially:</P>
<UL>
<P>In 3.4.4&nbsp;



 <A HREF="basic.html#basic.lookup.elab">basic.lookup.elab</A> paragraph 1:
Delete the sentence "The <I>class-name</I> or <I>enum-name</I> in the
<I>elaborated-type-specifier</I> may either be a simple identifier or be a
<I>qualified-id</I>."</P>
<P>In 3.4.4&nbsp;



 <A HREF="basic.html#basic.lookup.elab">basic.lookup.elab</A> paragraph 2:
Change "If the name in the <I>elaborated-type-specifier</I>
is a simple identifier"
to "If the <I>elaborated-type-specifier</I> has no
<I>nested-name-specifier</I>"</P>
<P>In 3.4.4&nbsp;



 <A HREF="basic.html#basic.lookup.elab">basic.lookup.elab</A> paragraph 3:
Change "If the name is a <I>qualified-id</I>, the name is looked up
according to its qualifications"
to "If the <I>elaborated-type-specifier</I> has a <I>nested-name-specifier</I>,
qualified name lookup is performed".</P>
</UL>

<P>
<B>Notes from the 4/02 meeting:</B>
</P>

<P>This will be consolidated with the changes for
<A HREF="
     cwg_active.html#254">issue 254</A>.</P>

<BR>
<BR>
<HR>
<A NAME="254"></A>
<H4>254.
  
Definitional problems with <I>elaborated-type-specifier</I>s
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>3.4.4&nbsp;



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

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

 <B>Submitter: </B>Clark Nelson
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>26 Oct 2000
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Nelson<BR>


<OL>

<LI>
<P>The text in 3.4.4&nbsp;



 <A HREF="basic.html#basic.lookup.elab">basic.lookup.elab</A> paragraph 2 twice
refers to the possibility that an <I>elaborated-type-specifier</I>
might have the form</P>

<PRE>
        <I>class-key identifier</I> <TT>;</TT>
</PRE>

<P>However, the grammar for <I>elaborated-type-specifier</I> does
not include a semicolon.</P>
</LI>

<LI>
<P>In both 3.4.4&nbsp;



 <A HREF="basic.html#basic.lookup.elab">basic.lookup.elab</A> and
7.1.5.3&nbsp;



 <A HREF="dcl.html#dcl.type.elab">dcl.type.elab</A>, the text asserts that an
<I>elaborated-type-specifier</I> that refers to a <I>typedef-name</I>
is ill-formed.  However, it is permissible for the form of
<I>elaborated-type-specifier</I> that begins with <TT>typename</TT>
to refer to a <I>typedef-name</I>.</P>

<P>This problem is the result of adding the <TT>typename</TT> form
to the <I>elaborated-type-name</I> grammar without changing the
verbiage correspondingly.  It could be fixed either by updating the
verbiage or by moving the <TT>typename</TT> syntax into its own
production and referring to both nonterminals when needed.</P>
</LI>

</OL>

<P>(See also <A HREF="
     cwg_defects.html#180">issue 180</A>.  If this
issue is resolved in favor of a separate nonterminal in the
grammar for the <TT>typename</TT> forms, the wording in that
issue's resolution must be changed accordingly.)</P>

<P>
<B>Notes from 04/01 meeting:</B>
</P>

<P>The consensus was in favor of moving the <TT>typename</TT>
forms out of the <I>elaborated-type-specifier</I> grammar.</P>

<P>
<B>Proposed resolution (Clark Nelson, March 2002):</B>
</P>

<P>GRAMMAR CHANGES</P>

<P>In 7.1.5.3&nbsp;



 <A HREF="dcl.html#dcl.type.elab">dcl.type.elab</A>:
Move the typename alternatives from the grammar rule for
<I>elaborated-type-specifier</I> into a new rule named
<I>typename-specifier</I>.</P>

<P>In 7.1.5&nbsp;



 <A HREF="dcl.html#dcl.type">dcl.type</A>:
Add <I>typename-specifier</I> as a new alternative for
<I>type-specifier</I>.</P>

<P>In 5.2&nbsp;



 <A HREF="expr.html#expr.post">expr.post</A>:
Replace the typename alternatives in <I>postfix-expression</I> with</P>
<UL>
<I>typename-specifier</I> <TT>(</TT> <I>expression-list</I><SUB>opt</SUB>
 <TT>)</TT>
</UL>

<P>TEXT CHANGES</P>

<P>In 3.3.1&nbsp;



 <A HREF="basic.html#basic.scope.pdecl">basic.scope.pdecl</A> paragraph 5, first bullet:
The grammar of elaborated-type-specifier does not allow a semicolon;
therefore
change "an <I>elaborated-type-specifier</I> of the form"
to "a declaration of the form".
Editorially, change "the <I>elaborated-type-specifier</I>
declares the identifier"
to "the identifier is declared".</P>

<P>In 3.3.1&nbsp;



 <A HREF="basic.html#basic.scope.pdecl">basic.scope.pdecl</A> paragraph 5, second bullet:
Editorially, change the note to:
"Other forms of <I>elaborated-type-specifier</I>
do not declare a new name,
and therefore
must refer to an existing type-name.
See 3.4.4&nbsp;



 <A HREF="basic.html#basic.lookup.elab">basic.lookup.elab</A> and 7.1.5.3&nbsp;



 <A HREF="dcl.html#dcl.type.elab">dcl.type.elab</A>."</P>

<P>9.1&nbsp;



 <A HREF="class.html#class.name">class.name</A> paragraph 3 is
implied by 3.4.4&nbsp;



 <A HREF="basic.html#basic.lookup.elab">basic.lookup.elab</A>,
so it should be a note.</P>

<P>9.1&nbsp;



 <A HREF="class.html#class.name">class.name</A> paragraph 5 is
implied by 7.1.3&nbsp;



 <A HREF="dcl.html#dcl.typedef">dcl.typedef</A>
and 7.1.5.3&nbsp;



 <A HREF="dcl.html#dcl.type.elab">dcl.type.elab</A>, so it should be a note.</P>

<P>In 14.6&nbsp;



 <A HREF="template.html#temp.res">temp.res</A> paragraph 3, change both instances of
<I>elaborated-type-specifier</I> to
<I>typename-specifier</I>.</P>

<P>
<B>Notes from the 4/02 meeting:</B>
</P>

<P>This will be consolidated with the changes for
<A HREF="
     cwg_active.html#245">issue 245</A>.</P>

<BR>
<BR>
<HR>
<A NAME="274"></A>
<H4>274.
  
Cv-qualification and char-alias access to out-of-lifetime objects
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>3.8&nbsp;



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

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

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

 <B>Date: </B>14 Mar 2001
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>0
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Vandevoorde<BR>


<P>The wording in 3.8&nbsp;



 <A HREF="basic.html#basic.life">basic.life</A> paragraph 6 allows an
lvalue designating an out-of-lifetime object to be used as the
operand of a <TT>static_cast</TT> only if the conversion is
ultimately to "<TT>char&amp;</TT>" or "<TT>unsigned char&amp;</TT>".
This description excludes the possibility of using a cv-qualified
version of these types for no apparent reason.</P>

<P>
<B>Notes on 04/01 meeting:</B>
</P>

<P>The wording should be changed to allow cv-qualified char
types.</P>

<P>
<B>Proposed resolution (04/01):</B>
</P>

<P>In 3.8&nbsp;



 <A HREF="basic.html#basic.life">basic.life</A> paragraph 6 change the third bullet:
<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
char&amp;</TT>), or
</LI>
</UL>
to read:
<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><I>cv</I> char&amp;</TT> or
<TT><I>cv</I> unsigned char&amp;</TT>, or
</LI>
</UL>
</P>

<BR>
<BR>
<HR>
<A NAME="258"></A>
<H4>258.
  
<I>using-declaration</I>s and cv-qualifiers
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>7.3.3&nbsp;



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

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

 <B>Submitter: </B>Liam Fitzpatrick
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>2 Nov 2000
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>0
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Vandevoorde<BR>


<P>From messages 8946 and 8948.</P>

<P>According to 7.3.3&nbsp;



 <A HREF="dcl.html#namespace.udecl">namespace.udecl</A> paragraph 12,</P>

<BLOCKQUOTE>

When a <I>using-declaration</I> brings names from a base class into a
derived class scope, member functions in the derived class override
and/or hide member functions with the same name and parameter types in
a base class (rather than conflicting).

</BLOCKQUOTE>

<P>Note that this description says nothing about the cv-qualification
of the hiding and hidden member functions.  This means, for instance,
that a non-const member function in the derived class hides a const
member function with the same name and parameter types instead of
overloading it in the derived class scope.  For example,</P>

<PRE>
    struct A {
      virtual int f() const;
      virtual int f();
    };
    struct B: A {
      B();
      int f();
      using A::f;
    };

    const B cb;
    int i = cb.f(); // ill-formed: A::f() const hidden in B

</PRE>

<P>The same terminology is used in 10.3&nbsp;



 <A HREF="derived.html#class.virtual">class.virtual</A>
paragraph 2:</P>

<BLOCKQUOTE>

If a virtual member function <TT>vf</TT> is declared in a class
<TT>Base</TT> and in a class <TT>Derived</TT>, derived directly or
indirectly from <TT>Base</TT>, a member function <TT>vf</TT> with the
same name and same parameter list as <TT>Base::vf</TT> is declared,
then <TT>Derived::vf</TT> is also virtual (whether or not it is so
declared) and it overrides <TT>Base::vf</TT>.

</BLOCKQUOTE>

<P>
<B>Notes on the 04/01 meeting:</B>
</P>

<P> The hiding and overriding should
be on the basis of the function signature, which includes any
cv-qualification on the function.</P>

<P>
<B>Proposed resolution (04/02):</B>
</P>

<P>In 7.3.3&nbsp;



 <A HREF="dcl.html#namespace.udecl">namespace.udecl</A> paragraph 12 change:
<BLOCKQUOTE>
When a <I>using-declaration</I> brings names from a base class into a
derived class scope, member functions in the derived class override and/or
hide member functions with the same name and parameter types in a base
class (rather than conflicting).
</BLOCKQUOTE>
to read:
<BLOCKQUOTE>
When a <I>using-declaration</I> brings names from a base class into a
derived class scope, member functions and member function templates in
the derived class override and/or hide member functions and member
function templates with the same name, parameter-type-list
(8.3.5&nbsp;



 <A HREF="decl.html#dcl.fct">dcl.fct</A>),
and <I>cv</I>-qualification in a base class (rather than conflicting).
</BLOCKQUOTE>
</P>
<P>
In 10.3&nbsp;



 <A HREF="derived.html#class.virtual">class.virtual</A> paragraph 2 change:
<BLOCKQUOTE>
If a virtual member function <TT>vf</TT> is declared in a class
<TT>Base</TT> and in a class <TT>Derived</TT>, derived directly or
indirectly from <TT>Base</TT>, a member function <TT>vf</TT> with the
same name and same parameter list as <TT>Base::vf</TT> is declared,
then <TT>Derived::vf</TT> is also virtual (whether or not it is so
declared) and it overrides <TT>Base::vf</TT>.
</BLOCKQUOTE>
to read:
<BLOCKQUOTE>
If a virtual member function <TT>vf</TT> is declared in a class
<TT>Base</TT> and in a class <TT>Derived</TT>, derived directly or
indirectly from <TT>Base</TT>, a member function <TT>vf</TT> with the
same name, parameter-type-list (8.3.5&nbsp;



 <A HREF="decl.html#dcl.fct">dcl.fct</A>), and
<I>cv</I>-qualification as <TT>Base::vf</TT>
is declared, then <TT>Derived::vf</TT> is also virtual (whether or not
it is so declared) and it overrides <TT>Base::vf</TT>.
</BLOCKQUOTE>
</P>

<BR>
<BR>
<HR>
<A NAME="262"></A>
<H4>262.
  
Default arguments and ellipsis
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>8.3.5&nbsp;



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

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

 <B>Submitter: </B>Jamie Schmeiser
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>13 Nov 2000
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>3
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Schmeiser<BR>


<P>From messages 8977 and 8984.</P>

<P>The interaction of default arguments and ellipsis is not clearly
spelled out in the current wording of the Standard.
8.3.6&nbsp;



 <A HREF="decl.html#dcl.fct.default">dcl.fct.default</A> paragraph 4 says,</P>

<BLOCKQUOTE>

In a given function declaration, all parameters subsequent to a
parameter with a default argument shall have default arguments
supplied in this or previous declarations.

</BLOCKQUOTE>

<P>Strictly speaking, ellipsis isn't a parameter, but this could
be clearer.  Also, in 8.3.5&nbsp;



 <A HREF="decl.html#dcl.fct">dcl.fct</A> paragraph 2,</P>

<BLOCKQUOTE>

If the <I>parameter-declaration-clause</I> terminates with an
ellipsis, the number of arguments shall be equal to or greater than
the number of parameters specified.

</BLOCKQUOTE>

<P>This could be interpreted to refer to the number of arguments
after the addition of default arguments to the argument list given
in the call expression, but again it could be clearer.</P>

<P>
<B>Notes from 04/01 meeting:</B>
</P>

<P>The consensus opinion was that an ellipsis is not a parameter
and that default arguments should be permitted preceding an
ellipsis.</P>

<P>
<B>Proposed Resolution (4/02):</B>
</P>

<P>Change the following sentence in 8.3.5&nbsp;



 <A HREF="decl.html#dcl.fct">dcl.fct</A> paragraph 2
from</P>
<BLOCKQUOTE>
If the <I>parameter-declaration-clause</I> terminates with an ellipsis, the
number of arguments shall be equal to or greater than the number of
parameters specified.
</BLOCKQUOTE>
<P>to</P>
<BLOCKQUOTE>
If the <I>parameter-declaration-clause</I> terminates with an ellipsis, the
number of arguments shall be equal to or greater than the number of
parameters that do not have a default argument.
</BLOCKQUOTE>

<P>As noted in the defect, section 8.3.6&nbsp;



 <A HREF="decl.html#dcl.fct.default">dcl.fct.default</A>
is correct but could be clearer.</P>

<P>In 8.3.6&nbsp;



 <A HREF="decl.html#dcl.fct.default">dcl.fct.default</A>, add the following as the first line
of the example in paragraph 4.</P>
<PRE>
  void g(int = 0, ...);  // okay, ellipsis is not a parameter so it can follow 
                         // a parameter with a default argument
</PRE>

<BR>
<BR>
<HR>
<A NAME="328"></A>
<H4>328.
  
Missing requirement that class member types be complete
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>9.2&nbsp;



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

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

 <B>Submitter: </B>Michiel Salters
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>10 Dec 2001
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>0
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Vandevoorde<BR>


<P>Is it legal to use an incomplete type (3.9&nbsp;



 <A HREF="basic.html#basic.types">basic.types</A>
paragraph 6) as a
class member, if no object of such class is ever created ?</P>

<P>And as a class template member, even if the template is instantiated,
but no object of the instantiated class is created?</P>

<P>The consensus seems to be NO, but no wording was found in the standard
which explicitly disallows it.</P>

<P>The problem seems to be that most of the restrictions on incomplete types
are on their use in objects, but class members are not objects.</P>

<P>A possible resolution, if this is considered a defect, is to add to 
3.2&nbsp;



 <A HREF="basic.html#basic.def.odr">basic.def.odr</A> paragraph 4, (situations when T must be complete),
the use of T as a member of a class or instantiated class template.</P>

<P>The thread on comp.std.c++ which brought up the issue was 
"Compiler differences: which is correct?", started 2001 11 30.
&lt;3c07c8fb$0$8507$ed9e5944@reading.news.pipex.net&gt;</P>

<P>
<B>Proposed Resolution (4/02):</B>
</P>

<P>Add after the first bullet of the note in 3.2&nbsp;



 <A HREF="basic.html#basic.def.odr">basic.def.odr</A>
paragraph 4:</P>
<UL>
<LI>
a non-<TT>static</TT> class data member of type <TT>T</TT> is
declared (9.2&nbsp;



 <A HREF="class.html#class.mem">class.mem</A>), or
</LI>
</UL>
<P>
Replace 9.2&nbsp;



 <A HREF="class.html#class.mem">class.mem</A> paragraph 8 by:</P>
<BLOCKQUOTE>
Non-<TT>static</TT> (9.4&nbsp;



 <A HREF="class.html#class.static">class.static</A>) data members shall
not have incomplete types.
In particular, a class <TT>cl</TT> shall not contain a non-<TT>static</TT>
member of class <TT>cl</TT>, but it can contain a pointer or reference to
an object of class <TT>cl</TT>.
</BLOCKQUOTE>

<P>See also 3.9&nbsp;



 <A HREF="basic.html#basic.types">basic.types</A> paragraph 6, which is relevant
but not changed by the Proposed Resolution.</P>

<BR>
<BR>
<HR>
<A NAME="198"></A>
<H4>198.
  
Definition of "use" in local and nested classes
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>9.8&nbsp;



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

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

 <B>Submitter: </B>Erwin Unruh
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>27 Jan 2000
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Wilcox<BR>




<P>From reflector messages 8501-2, 8507.</P>


<P>9.8&nbsp;



 <A HREF="class.html#class.local">class.local</A>
 paragraph 1 says,</P>

<BLOCKQUOTE>
Declarations in a local class can use only type names, static
variables, <TT>extern</TT> variables and functions, and enumerators
from the enclosing scope.
</BLOCKQUOTE>

The definition of when an object or function is "used" is found in
3.2&nbsp;



 <A HREF="basic.html#basic.def.odr">basic.def.odr</A>
 paragraph 2 and
essentially says that the operands of <TT>sizeof</TT> and
non-polymorphic <TT>typeid</TT> operators are not used.  (The
resolution for <A HREF="
     cwg_defects.html#48">issue 48</A> will add
contexts in which integral constant expressions are required to the
list of non-uses.)

<P>This definition of "use" would presumably allow code like</P>

<PRE>
    void foo() {
        int i;
        struct S {
            int a[sizeof(i)];
        };
    };
</PRE>

which is required for C compatibility.

<P>However, the restrictions on nested classes in
9.7&nbsp;



 <A HREF="class.html#class.nest">class.nest</A>
 paragraph 1 are very
similar to those for local classes, and the example there explicitly
states that a reference in a <TT>sizeof</TT> expression is a forbidden
use (abbreviated for exposition):</P>

<PRE>
    class enclose {
    public:
        int x;
        class inner {
            void f(int i)
            {
                int a = sizeof(x);  // <I>error: refers to </I>enclose::x
            }
        };
    };
</PRE>

<P>[As a personal note, I have seen real-world code that was exactly like
this; it was hard to persuade the author that the required
writearound, <TT>sizeof(((enclose*) 0)-&gt;x)</TT>, was an improvement
over <TT>sizeof(x)</TT>. <I>&mdash;wmm</I>]</P>

<P>Similarly, 9.2&nbsp;



 <A HREF="class.html#class.mem">class.mem</A> paragraph 9 would appear to
prohibit examples like the following:</P>

<PRE>
    struct B {
        char x[10];
    };
    struct D: B {
        char y[sizeof(x)];
    };
</PRE>

<P>
<B>Suggested resolution:</B> Add cross-references to
3.2&nbsp;



 <A HREF="basic.html#basic.def.odr">basic.def.odr</A>
 following the word
"use" in both 9.7&nbsp;



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



 <A HREF="class.html#class.local">class.local</A>
, and change the example
in 9.7&nbsp;



 <A HREF="class.html#class.nest">class.nest</A>
 to indicate that a
reference in a <TT>sizeof</TT> expression is permitted.  In
9.2&nbsp;



 <A HREF="class.html#class.mem">class.mem</A> paragraph 9, "referred to" should be
changed to "used" with a cross_reference to
3.2&nbsp;



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

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

<P>It was noted that the suggested resolution did not make the
<TT>sizeof()</TT> example in 9.7&nbsp;



 <A HREF="class.html#class.nest">class.nest</A> valid.
Although the reference to the argument of <TT>sizeof()</TT> is not regarded
as a use, the right syntax must be used nonetheless to reference a non-static
member from the enclosing class. The use of the member name by itself is not
valid. The consensus within the core working group was that nothing should be
done about this case. It was later discovered that
9.4&nbsp;



 <A HREF="class.html#class.static">class.static</A> paragraph 3 states that</P>
<BLOCKQUOTE>
<P>The
definition of a <TT>static</TT>
member shall not use directly the names of the nonstatic members of its class
or of a base class of its class (including as operands of the <TT>sizeof</TT>
operator). The definition of a <TT>static</TT> member may only refer to
these members to
form pointer to members (5.3.1&nbsp;



 <A HREF="expr.html#expr.unary.op">expr.unary.op</A>) or
with the class member access syntax (5.2.5&nbsp;



 <A HREF="expr.html#expr.ref">expr.ref</A>).</P>
</BLOCKQUOTE>

<P>This seems to
reinforce the decision of the working group.</P>

<P>The use of "use" should still be cross-referenced. The
statements in 9.7&nbsp;



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



 <A HREF="class.html#class.local">class.local</A>
should also be rewritten to state the requirement
positively rather than negatively as the list of "can't"s is already missing
some cases such as template parameters. </P>

<P>
<B>Notes from the 4/02 meeting:</B>
</P>

<P>We backed away from "use" in the technical sense, because the
requirements on the form of reference are the same whether or not
the reference occurs inside a <TT>sizeof</TT>.</P>

<P>
<B>Proposed Resolution (4/02):</B>
</P>

<P>In 9.2&nbsp;



 <A HREF="class.html#class.mem">class.mem</A> paragraph 9, replace </P>
<BLOCKQUOTE>
  <P>Except when used to form a pointer to member
(5.3.1&nbsp;



 <A HREF="expr.html#expr.unary.op">expr.unary.op</A>), when used in the body of a
 nonstatic 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>), or when used 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>), a nonstatic data or function member
 of a class shall only be referred to with the class member access syntax
(5.2.5&nbsp;



 <A HREF="expr.html#expr.ref">expr.ref</A>).</P>
</BLOCKQUOTE>
<P>with the following paragraph</P>
<BLOCKQUOTE>
  <P>Each occurrence of the name of a nonstatic data 
  member or nonstatic 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 a pointer to member 
  (5.3.1&nbsp;



 <A HREF="expr.html#expr.unary.op">expr.unary.op</A>), when it appears in the body
  of a nonstatic 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>), 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>).</P>
</BLOCKQUOTE>
<P>
<I>Note: Should the above be "each occurrence of the name in an
expression" so as not to rule out declarations?</I>
</P>
<P>In 9.7&nbsp;



 <A HREF="class.html#class.nest">class.nest</A>
 paragraph 1, replace the last sentence,</P>
<BLOCKQUOTE>
  <P>Except by using explicit pointers, references, and object names, 
  declarations in a nested class can use only type names, static members, and 
  enumerators from the enclosing class.</P>
</BLOCKQUOTE>
<P>with the following</P>
<BLOCKQUOTE>
  <P>[Note: In accordance with 9.2&nbsp;



 <A HREF="class.html#class.mem">class.mem</A>),
  except by using explicit pointers, 
  references, and object names, declarations in a nested class shall not use
  nonstatic data members or nonstatic member functions from the 
  enclosing class. This restriction applies in all constructs including the 
  operands of the <TT>sizeof</TT> operator.]</P>
</BLOCKQUOTE>
<P>In the example following 9.7&nbsp;



 <A HREF="class.html#class.nest">class.nest</A>
paragraph 1, change the comment on the first statement of 
function <TT>f</TT> to emphasize that <TT>sizeof(x)</TT> is an error. The 
example reads in full:</P>
<PRE>
  int x;
  int y;
  class enclose {
  public:
    int x;
    static int s;
    class inner {
      void f(int i)
      {
        int a = sizeof(x);  // <I>error: direct use of</I> <TT>enclose::x</TT> <I>even in sizeof</I>
        x = i;              // <I>error: assign to </I><TT>enclose::x</TT>
        s = i;              // <I>OK: assign to </I><TT>enclose::s</TT>
        ::x = i;            // <I>OK: assign to global</I> <TT>x</TT>
        y = i;              // <I>OK: assign to global</I> <TT>y</TT>
      }
      void g(enclose* p, int i)
      {
        p-&gt;x = i;        // <I>OK: assign to</I> <TT>enclose::x</TT>
      }
    };
  };
   
  inner* p = 0;             // <I>error:</I> <TT>inner</TT><I> not in scope</I>
</PRE>

<BR>
<BR>
<HR>
<A NAME="39"></A>
<H4>39.
  
Conflicting ambiguity rules
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>10.2&nbsp;



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

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

 <B>Submitter: </B>Neal M Gafter
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>20 Aug 1998
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Merrill<BR>




<P>From reflector message core-7816.</P>


<P>The ambiguity text in 10.2&nbsp;



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

may not say what we intended. It makes the
following example ill-formed:</P>
<PRE>
    struct A {
        int x(int);
    };
    struct B: A {
        using A::x;
        float x(float);
    };
    
    int f(B* b) {
        b-&gt;x(3);  // ambiguous
    }
</PRE>
This is a name lookup ambiguity because of 10.2&nbsp;



 <A HREF="derived.html#class.member.lookup">class.member.lookup</A>
 paragraph 2:
<BLOCKQUOTE>... Each of these declarations that was introduced by a using-declaration
is considered to be from each sub-object of C that is of the type containing
the declaration designated by the using-declaration. If the resulting set
of declarations are not all from sub-objects of the same type, or the set
has a nonstatic member and includes members from distinct sub-objects,
there is an ambiguity and the program is ill-formed.</BLOCKQUOTE>
This contradicts the text and example in paragraph 12 of 7.3.3&nbsp;



 <A HREF="dcl.html#namespace.udecl">namespace.udecl</A>
.

<P>
<B>Proposed Resolution (10/00):</B>
</P>

<OL>

<LI>
<P>Replace the two cited sentences from 10.2&nbsp;



 <A HREF="derived.html#class.member.lookup">class.member.lookup</A>
paragraph 2 with the following:</P>

<BLOCKQUOTE>

The resulting set of declarations shall all be from sub-objects
of the same type, or there shall be a set of declarations from
sub-objects of a single type that contains <I>using-declaration</I>s
for the declarations found in all other sub-object types.
Furthermore, for nonstatic members, the resulting set of
declarations shall all be from a single sub-object, or there shall
be a set of declarations from a single sub-object that contains
<I>using-declarations</I> for the declarations found in all other
sub-objects.  Otherwise, there is an ambiguity and the program is
ill-formed.

</BLOCKQUOTE>

</LI>

<LI>
<P>Replace the examples in 10.2&nbsp;



 <A HREF="derived.html#class.member.lookup">class.member.lookup</A>
paragraph 3 with the following:</P>

<PRE>
    struct A {
        int x(int);
        static int y(int);
    };
    struct V {
        int z(int);
    };
    struct B: A, virtual V {
        using A::x;
        float x(float);
        using A::y;
        static float y(float);
        using V::z;
        float z(float);
    };
    struct C: B, A, virtual V {
    };

    void f(C* c) {
        c-&gt;x(3);    // ambiguous -- more than one sub-object A
        c-&gt;y(3);    // not ambiguous
        c-&gt;z(3);    // not ambiguous
    }
</PRE>

</LI>

</OL>

<P>
<B>Notes from 04/01 meeting:</B>
</P>

<P>The following example should be accepted but is rejected by
the wording above:</P>

<PRE>
    struct A { static void f(); };

    struct B1: virtual A {
        using A::f;
    };

    struct B2: virtual A {
        using A::f;
    };

    struct C: B1, B2 { };

    void g() {
        C::f();        // OK, calls A::f()
    }
</PRE>

<P>
<B>Notes from 10/01 meeting (Jason Merrill):</B>
</P>

<P>The example in the issues list:

<PRE>
    struct A {
        int x(int);
    };
    struct B: A {
        using A::x;
        float x(float);
    };
    
    int f(B* b) {
        b-&gt;x(3);  // ambiguous
    }
</PRE>

Is broken under the existing wording:

<BLOCKQUOTE>
... Each of these declarations that was introduced by a using-declaration
is considered to be from each sub-object of C that is of the type containing
the declaration designated by the using-declaration. If the resulting set
of declarations are not all from sub-objects of the same type, or the set
has a nonstatic member and includes members from distinct sub-objects,
there is an ambiguity and the program is ill-formed.</BLOCKQUOTE>

Since the two x's are considered to be "from" different objects, looking up
x produces a set including declarations "from" different objects, and the
program is ill-formed.  Clearly this is wrong.  The problem with the
existing wording is that it fails to consider lookup context.</P>

<P>The first proposed solution:

<BLOCKQUOTE>

The resulting set of declarations shall all be from sub-objects
of the same type, or there shall be a set of declarations from
sub-objects of a single type that contains <I>using-declaration</I>s
for the declarations found in all other sub-object types.
Furthermore, for nonstatic members, the resulting set of
declarations shall all be from a single sub-object, or there shall
be a set of declarations from a single sub-object that contains
<I>using-declarations</I> for the declarations found in all other
sub-objects.  Otherwise, there is an ambiguity and the program is
ill-formed.

</BLOCKQUOTE>

breaks this testcase:

<PRE>
    struct A { static void f(); };

    struct B1: virtual A {
        using A::f;
    };

    struct B2: virtual A {
        using A::f;
    };

    struct C: B1, B2 { };

    void g() {
        C::f();        // OK, calls A::f()
    }
</PRE>

because it considers the lookup context, but not the definition context;
under this definition of "from", the two declarations found are the
using-declarations, which are "from" B1 and B2.</P>

<P>The solution is to separate the notions of lookup and definition context.
I have taken an algorithmic approach to describing the strategy.</P>

<P>Incidentally, the earlier proposal allows one base to have a superset of
the declarations in another base; that was an extension, and my proposal
does not do that.  One algorithmic benefit of this limitation is to
simplify the case of a virtual base being hidden along one arm and not
another ("domination"); if we allowed supersets, we would need to remember
which subobjects had which declarations, while under the following
resolution we need only keep two lists, of subobjects and declarations.</P>

<P>
<B>Proposed resolution (10/01):</B>
</P>

<P>Replace 10.2&nbsp;



 <A HREF="derived.html#class.member.lookup">class.member.lookup</A> paragraph 2 with:</P>

<BLOCKQUOTE>
<P>The following steps define the result of name lookup for a member name f
in a class scope C.</P>

<P>A <I>lookup set</I> consists of two distinct sets: a set of members
named f and a set of subobjects where declarations of these members
(possibly including using-declarations) were found.  In the declaration
set, using-declarations are replaced by the members they designate, and
type declarations (including the injected-class-name) are replaced by the
types they designate.  The lookup set for f in C S<SUB>C</SUB> is
calculated as follows.</P>

<P>If C contains a declaration of the name f, the declaration set contains
every declaration of f in C (excluding bases), the subobject set
contains C itself, and calculation is complete.</P>

<P>If C does not contain a declaration of f, S<SUB>C</SUB> is initially
empty.  If C does not contain a declaration of f but has base classes,
begin with that empty set, calculate the lookup set for f in each base class
subjobject B<SUB>n</SUB>, and merge each such lookup set S<SUB>n</SUB> in
turn into S<SUB>C</SUB>.</P>

<P>The following steps define the result of merging lookup set
S<SUB>i</SUB> for B<SUB>i</SUB> into the intermediate S<SUB>C</SUB>:</P>

<UL>
<LI>If one of the lookup sets is empty, the other is taken as the new
S<SUB>C</SUB>.</LI>
<LI>Otherwise, remove from S<SUB>i</SUB> and S<SUB>C</SUB> any subjobject
which is a base class subobject of at least one of the subobjects in the
other lookup set.  If one of the lookup sets has no subobjects left after
this step, the other is taken as the new S<SUB>C</SUB>.</LI>
<LI>Otherwise, if S<SUB>i</SUB> and S<SUB>C</SUB> do not contain the same
set of declarations, the lookup is ambiguous.</LI>
<LI>Otherwise, consider each declaration d in the set, where d is a member
of class A.  If d is a nonstatic member, compare the A base class
subobjects of the subobject members of S<SUB>i</SUB> and S<SUB>C</SUB>; if
they do not match, the lookup is ambiguous. [Note: It is not necessary to
remember which A subobject each member comes from, since using-declarations
don't disambiguate. ]</LI>
<LI> Otherwise, the new S<SUB>C</SUB> is a lookup set with the shared set
of declarations and the union of the subobject sets.</LI>
</UL>

<P>The result of name lookup for f in C is the set of declarations from the
lookup set for f in C.</P>
</BLOCKQUOTE>
<P>Turn 10.2&nbsp;



 <A HREF="derived.html#class.member.lookup">class.member.lookup</A> paragraphs 5 and 6 into notes.</P>

<P>
<B>Note:</B> This also resolves <A HREF="
     cwg_active.html#306">issue 306</A>.</P>

<P>
<B>Notes from the 4/02 meeting:</B>
</P>

<P>We discussed this at length, but less productively than one would
like due to the absence of Jason Merrill.  A fair amount of rewording
led to the following version, which we now leave to Jason to
reconcile with his version.  Of particular concern was the fact that
it was not clear how the clauses were to be grouped given the
"otherwise"s.</P>

<P>It was also noted that this section probably should define "ambiguous
base class" but doesn't, and that it needs to deal with typedefs (they
get mapped to the underlying type.  See
<A HREF="
     cwg_active.html#306">issue 306</A>).</P>

<P>Replace 10.2&nbsp;



 <A HREF="derived.html#class.member.lookup">class.member.lookup</A> paragraph 2 with:</P>
<BLOCKQUOTE>
<P>The following steps define the result of name lookup for a member name f
in a class scope C.</P>

<P>
<B>The</B> <I>lookup set</I> <B>for f in C, S(C),</B> consists of two distinct sets: a set of <B>declarations for</B> members
named f <EM>[Drafting note: anybody thinks it's ambiguous what's named f?]</EM>, and a set of subobjects where declarations of these members
(possibly including using-declarations) were found.  In the declaration
set, using-declarations are replaced by the members they designate, and
type declarations (including the injected-class-name) are replaced by the
types they designate.  <S>The lookup set for f
in C, S(C),</S> <B>S(C)</B> is calculated as follows.</P>

<P>If C contains a declaration of the name f, the declaration set contains
every declaration of f in C (excluding bases), the subobject set
contains C itself, and calculation is complete.</P>

<P>
<B>Otherwise, <B>S(C)</B> is initially empty.  If C has base classes,</B>
calculate the lookup set for f in each base class subobject
B<SUB>i</SUB>, and merge each such lookup set <B>S(B<SUB>i</SUB>)</B>
in turn into <B>S(C)</B>.</P>


<P>The following steps define the result of merging <B>two</B> lookup sets
<B>S<SUB>p</SUB> and S<SUB>q</SUB></B> <S>S<SUB>i</SUB> for
B<SUB>i</SUB></S>
into a new lookup set <B>S</B><B>, or determine that the lookup is
ambiguous and no merged lookup set <B>S</B> is constructed:</B>
</P>

<OL>
<LI>
<S>If one of the lookup sets is empty, the other is taken as the new
<B>S</B>.</S>
</LI>
<LI>
<S>Otherwise,</S> Remove from <B>S<SUB>p</SUB></B> any
subobject that is a base class subobject of at least one of the
subobjects in <B>S<SUB>q</SUB></B>.  Similarly, remove from
<B>S<SUB>q</SUB></B> any subobject that is a base class subobject of at least one of the
subobjects in <B>S<SUB>p</SUB></B>.</LI>
<LI>If one of the lookup sets has no subobjects left <S>after
this step</S>, the other is taken as the new <B>S</B>.</LI>
<LI>Otherwise, if <B>S<SUB>p</SUB></B> and <B>S<SUB>q</SUB></B> do not contain the same
set of declarations, the lookup is ambiguous.</LI>
<LI>Otherwise, consider each declaration d in the set, where d is a member
of <B>some</B> class A.  If d is a nonstatic member, compare the
subobjects <B>having type A among the</B> subobjects <S>members</S> <B>in S<SUB>p</SUB></B> and <B>S<SUB>q</SUB></B>; if
they do not match, the lookup is ambiguous. <em>[Note:</em> It is not necessary to
remember which subobject <B>having type A</B> each member comes from, since using-declarations
don't disambiguate. <em>]</em>
</LI>
<LI>Otherwise, the new <B>S</B> is a lookup set with the shared set
of declarations and the union of the subobject sets.</LI>
</OL>
<P>The result of name lookup for f in C is the set of declarations from the
lookup set for f in C.</P>
</BLOCKQUOTE>

<P>Turn 10.2&nbsp;



 <A HREF="derived.html#class.member.lookup">class.member.lookup</A> paragraphs 5 and 6 into notes.</P>
 
<BR>
<BR>
<HR>
<A NAME="306"></A>
<H4>306.
  
Ambiguity by class name injection
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>10.2&nbsp;



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

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

 <B>Submitter: </B>Clark Nelson
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>19 Jul 2001
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>1
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Merrill<BR>


<P>Is the following well-formed?
<PRE>
    struct A {
        struct B { };
    };
    struct C : public A, public A::B {
        B *p;
    };
</PRE>
The lookup of <TT>B</TT> finds both the struct <TT>B</TT> in <TT>A</TT>
and the injected <TT>B</TT> from the <TT>A::B</TT> base class.
Are they the same thing?  Does the standard say so?</P>

<P>What if a struct is found along one path and a typedef to that
struct is found along another path?  That should probably be valid,
but does the standard say so?</P>

<P>This is resolved by <A HREF="
     cwg_active.html#39">issue 39</A>
</P>
<BR>
<BR>
<HR>
<A NAME="263"></A>
<H4>263.
  
Can a constructor be declared a friend?
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>12.1&nbsp;



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

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

 <B>Submitter: </B>Martin Sebor
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>13 Nov 2000
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Schmeiser<BR>


<P>From messages 8978-83 and 8985-6.</P>

<P>According to 12.1&nbsp;



 <A HREF="special.html#class.ctor">class.ctor</A> paragraph 1, a
declaration of a constructor has a special limited syntax, in
which only <I>function-specifier</I>s are allowed.  A <TT>friend</TT>
specifier is not a <I>function-specifier</I>, so one interpretation
is that a constructor cannot be declared in a <TT>friend</TT>
declaration.</P>

<P>(It should also be noted, however, that neither <TT>friend</TT>
nor <I>function-specifier</I> is part of the <B>declarator</B>
syntax, so it's not clear that anything conclusive can be derived
from the wording of 12.1&nbsp;



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

<P>
<B>Notes from 04/01 meeting:</B>
</P>

<P>The consensus of the core language working group was that it
should be permitted to declare constructors as <TT>friend</TT>s.</P>

<P>
<B>Proposed Resolution (4/02):</B>
</P>

<P>Change paragraph 1a in 3.4.3.1&nbsp;



 <A HREF="basic.html#class.qual">class.qual</A> (added by
the resolution of issue 147) as follows:</P>
<BLOCKQUOTE>
If the <I>nested-name-specifier</I> nominates a class <TT>C</TT>, and the
name specified after the <I>nested-name-specifier</I>, when looked up in
<TT>C</TT>, is the injected-class-name of <TT>C</TT> (clause
9&nbsp;



 <A HREF="class.html#class">class</A>), the name is instead considered to name the
constructor of class <TT>C</TT>. Such a constructor name shall be used
only in the <I>declarator-id</I> of a <S>constructor definition</S>
<B>declaration</B> that <S>appears outside of the class definition</S>
<B>names a constructor</B>.... 
</BLOCKQUOTE>

<P>Note: the above does not allow qualified names to be used for
in-class declarations; see 8.3&nbsp;



 <A HREF="decl.html#dcl.meaning">dcl.meaning</A> paragraph 1.
Also note that <A HREF="
     cwg_active.html#318">issue 318</A> updates the
same paragraph.</P>

<P>Change 7.1.5&nbsp;



 <A HREF="dcl.html#dcl.type">dcl.type</A> paragraph 2 as follows:</P>
<BLOCKQUOTE>
At least one <I>type-specifier</I> that is not a <I>cv-qualifier</I>
is required in a declaration unless it <S>declares</S> <B>names</B>
a constructor, destructor<B>,</B> or conversion function.
</BLOCKQUOTE>

<P>Change the example in 11.4&nbsp;



 <A HREF="access.html#class.friend">class.friend</A>, paragraph 4
as follows:</P>
<PRE>
class Y {
  friend char* X::foo(int);
  <B>friend X::X(char);   // constructors can be friends</B>
  <B>friend X::~X();      // destructors can be friends</B>
  //...
};
</PRE>

<BR>
<BR>
<HR>
<A NAME="326"></A>
<H4>326.
  
Wording for definition of trivial constructor
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>12.1&nbsp;



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

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

 <B>Submitter: </B>James Kanze
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>9 Dec 2001
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>0
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Nelson<BR>



<P>From message 9419.</P>


<P>In 12.1&nbsp;



 <A HREF="special.html#class.ctor">class.ctor</A> paragraph 5, the standard says
"A constructor is trivial if [...]", and goes on to define a trivial
default constructor.  Taken literally, this would mean that a copy
constructor can't be trivial (contrary to 12.8&nbsp;



 <A HREF="special.html#class.copy">class.copy</A> paragraph 6).  I suggest changing this to "A default
constructor is trivial if [...]".  (I think the change is purely
editorial.)</P>

<P>
<B>Proposed Resolution (4/02):</B>
</P>

<P>The fix is simply to clarify that the definition in
12.1&nbsp;



 <A HREF="special.html#class.ctor">class.ctor</A> paragraph 5-6
applies only to default constructors,
by inserting the word "default" in the appropriate spots.
</P>
<P>
However, in looking at the paragraph,
I found some instances of italicized words which are not being defined.
I propose also to remove the italics.
</P>
<P>
The problem of inappropriate italics also affects 12.4&nbsp;



 <A HREF="special.html#class.dtor">class.dtor</A>
paragraph 3,
in the description of a trivial destructor.
The italics should also be removed from there,
but as there is no actual wording change,
I don't bother to illustrate the changes here.</P>
<BLOCKQUOTE>
<P>
A <I>default</I> constructor for a class <TT>X</TT>
is a constructor of class <TT>X</TT>
that can be called without an argument.
If there is no
<S><I>user-declared</I></S>
<B>user-declared</B>
constructor for class <TT>X</TT>,
a default constructor is implicitly declared.
An
<S><I>implicitly-declared</I></S>
<B>implicitly-declared</B>
default constructor
is an <TT>inline public</TT> member of its class.
A
<B>default</B>
constructor is <I>trivial</I>
if it is an implicitly-declared default constructor
and if:
<UL>
<LI>
its class has no virtual functions (10.3&nbsp;



 <A HREF="derived.html#class.virtual">class.virtual</A>)
and no virtual base classes (10.1&nbsp;



 <A HREF="derived.html#class.mi">class.mi</A>), and
</LI>
<LI>
all the direct base classes of its class
have trivial
<B>default</B>
constructors, and
</LI>
<LI>
for all the nonstatic data members of its class
that are of class type (or array thereof),
each such class has a trivial
<B>default</B>
constructor.
</LI>
</UL>
</P>
<P>
Otherwise, the
<B>default</B>
constructor is non-trivial.
</P>
</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="280"></A>
<H4>280.
  
Access and surrogate call functions
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>13.3.1.1.2&nbsp;



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

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

 <B>Submitter: </B>Andrei Iltchenko
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>16 Apr 2001
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Adamczyk<BR>


<P>According to 13.3.1.1.2&nbsp;



 <A HREF="over.html#over.call.object">over.call.object</A> paragraph 2, when
the <I>primary-expression</I> <TT>E</TT> in the function call syntax
evaluates to a class object of type "<I>cv</I> <TT>T</TT>", a
surrogate call function corresponding to an appropriate conversion
function declared in a direct or indirect base class <TT>B</TT> of
<TT>T</TT> is included or not included in the set of candidate
functions based on class <TT>B</TT> being accessible.</P>

<P>For instance in the following code sample, as per the paragraph in
question, the expression <TT>c(3)</TT> calls <TT>f2</TT>, instead of
the construct being ill-formed due to the conversion function
<TT>A::operator fp1</TT> being inaccessible and its corresponding
surrogate call function providing a better match than the surrogate
call function corresponding to <TT>C::operator fp2</TT>:</P>

<PRE>
    void  f1(int)  {   }
    void  f2(float)  {   }
    typedef void  (* fp1)(int);
    typedef void  (* fp2)(float);

    struct  A  {
       operator fp1()
       {   return  f1;   }
    };

    struct  B :  private A  {   };

    struct  C :  B  {
       operator  fp2()
       {   return  f2;   }
    };

    int  main()
    {
       C   c;
       c(3);  // f2 is called, instead of the construct being ill-formed.
       return  0;
    }
</PRE>

<P>The fact that the accessibility of a base class influences the
overload resolution process contradicts the fundamental language rule
(3.4&nbsp;



 <A HREF="basic.html#basic.lookup">basic.lookup</A> paragraph 1, and 13.3&nbsp;



 <A HREF="over.html#over.match">over.match</A> paragraph 2) that access checks are applied only once
name lookup and function overload resolution (if applicable) have
succeeded.</P>

<P>
<B>Proposed resolution (10/01, same as suggested resolution):</B>
</P>

<P>In 13.3.1.1.2&nbsp;



 <A HREF="over.html#over.call.object">over.call.object</A> paragraph 2, replace the
last sentence</P>

<BLOCKQUOTE>

Similarly, surrogate call functions are added to the set of candidate
functions for each conversion function declared in an accessible base
class provided the function is not hidden within <TT>T</TT> by another
intervening declaration.

</BLOCKQUOTE>

<P>with</P>

<BLOCKQUOTE>

Similarly, surrogate call functions are added to the set of candidate
functions for each conversion function declared in a base class of
<TT>T</TT> provided the function is not hidden within <TT>T</TT> by
another intervening declaration. If such a surrogate function is
eventually selected as the best viable function and its corresponding
conversion function is from an ambiguous (10.2&nbsp;



 <A HREF="derived.html#class.member.lookup">class.member.lookup</A>)
base class of <TT>T</TT>, the program is ill-formed.

</BLOCKQUOTE>

<P>
<B>Notes from 4/02 meeting:</B>
</P>

<P>There was some concern about whether 10.2&nbsp;



 <A HREF="derived.html#class.member.lookup">class.member.lookup</A> (or
anthing else, for that matter) actually defines "ambiguous base class".
See <A HREF="
     cwg_active.html#39">issue 39</A>.  See also
<A HREF="
     cwg_active.html#156">issue 156</A>.</P>

<BR>
<BR>
<HR>
<A NAME="204"></A>
<H4>204.
  
Exported class templates
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>14&nbsp;



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

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

 <B>Submitter: </B>Robert Klarer
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>11 Feb 2000
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Vandevoorde<BR>



<P>14&nbsp;



 <A HREF="template.html#temp">temp</A>
 paragraph 7 allows class
templates to be declared exported, including member classes and member
class templates (implicitly by virtue of exporting the
containing template class).  However, paragraph 8 does not exclude
exported class templates from the statement that</P>

<BLOCKQUOTE>
An exported template need only be declared (and not necessarily
defined) in a translation unit in which it is instantiated.
</BLOCKQUOTE>

This is an incorrect implication; however, it is also not dispelled in
14.7.1&nbsp;



 <A HREF="template.html#temp.inst">temp.inst</A>
 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>

This wording says nothing about the translation unit in which the
definition must be provided.  Contrast this with
14.7.2&nbsp;



 <A HREF="template.html#temp.explicit">temp.explicit</A>
 paragraph 3:

<BLOCKQUOTE>
A definition of a class template or a class member template shall be
in scope at the point of the explicit instantiation of the class
template or class member template.
</BLOCKQUOTE>

<P>
<B>Suggested resolution:</B>
</P>

<BR>
<UL>
<LI>Change 14&nbsp;



 <A HREF="template.html#temp">temp</A>
 paragraph 8 to say
that "An exported <B>non-class</B> template need only be declared..."</LI>

<LI>Change 14.7.1&nbsp;



 <A HREF="template.html#temp.inst">temp.inst</A>
 paragraph 6 to
use wording similar to that of
14.7.2&nbsp;



 <A HREF="template.html#temp.explicit">temp.explicit</A>
 paragraph 3 regarding
the requirement for a definition of the class template to be in scope.</LI>
</UL>

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

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

<P>John Spicer opined that even though 14&nbsp;



 <A HREF="template.html#temp">temp</A>
paragraph 7 speaks of "declaring a class template exported," that does
not mean that the class template is "an exported template" in the
sense of paragraph 8.  He suggested clarifying paragraph 7 to that
effect instead of the change to paragraph 8 suggested above, and
questioned the need for a change to 14.7.1&nbsp;



 <A HREF="template.html#temp.inst">temp.inst</A>.</P>

<P>
<B>Notes from the 4/02 meeting:</B>
</P>

<P>This is resolved by the proposed changes for
<A HREF="
     cwg_active.html#323">issue 323</A>.</P>

<BR>
<BR>
<HR>
<A NAME="323"></A>
<H4>323.
  
Where must <TT>export</TT> appear?
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>14&nbsp;



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

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

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

 <B>Date: </B>14 Nov 2001
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>1
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Vandevoorde<BR>



<P>From message 9386.</P>


<P>The standard doesn't seem to describe whether the keyword <TT>export</TT>
should appear on exported template declarations that are not used or
defined in that particular translation unit.</P>

<P>For example:</P>
<PRE>
  // File 1:
  template&lt;typename T&gt; void f();  // export omitted

  // File 2:
  export template&lt;typename T&gt; void f() {}

  int main() { f&lt;int&gt;(); }
</PRE>
<P>Another example is:</P>
<PRE>
  // File 1:
  struct S {
     template&lt;typename T&gt; void m();
  };

  // File 2:
  struct S {
     template&lt;typename T&gt; void m();
  };

  export template&lt;typename T&gt; void S::m() {}

  int main() {
     S s;
     S.m&lt;int&gt;();
  }
</PRE>

<P>I think both examples should be clarified to be invalid.  If a template is 
exported in one translation unit, it should be declared export in all 
translation units in which it appears.</P>

<P>With the current wording, it seems that even the following is valid:</P>
<PRE>
  // File 1:
  export template&lt;typename T&gt; void f();  // export effectively ignored

  // File 2:
  template&lt;typename T&gt; void f() {}  // Inclusion model
  void g() { f&lt;int&gt;(); }

  // File 3:
  void g();
  template&lt;typename T&gt; void f() {}  // Inclusion model

  int main() {
     g();
     f&lt;int&gt;();
  }
</PRE>
 
<P>In fact, I think the declaration in "File 1" could be a definition and this
would still satisfy the the requirements of the standard, which definitely
seems wrong.</P>

<P>
<B>Proposed Resolution (4/02):</B>
</P>

<P>Replace 14&nbsp;



 <A HREF="template.html#temp">temp</A> paragraphs 6, 7, and 8 by the
following text:</P>
<BLOCKQUOTE>
<P>
A <I>template-declaration</I> may be preceded by the <TT>export</TT> keyword.
Declaring exported a class template is equivalent to declaring
exported all of its non-inline member functions, static data members, 
member classes, member class templates, and non-inline member function 
templates.</P>
<P> If a template is exported in one translation unit, it
shall be exported in all translation units in which
it appears; no diagnostic is required.
A declaration of an exported template shall appear with the <TT>export</TT>
keyword before any point of instantiation (14.6.4.1&nbsp;



 <A HREF="template.html#temp.point">temp.point</A>)
of that template in that translation unit.  In addition, the first
declaration of an exported template containing the <TT>export</TT> keyword
must not follow the definition of that template.  The <TT>export</TT>
keyword shall not be used in a friend declaration.</P>
<P> Templates defined in an unnamed namespace, inline functions, and
inline function templates shall not be exported.
An exported non-class template shall be defined only once in a program;
no diagnostic is required. An exported non-class template
need only be declared (and not necessarily defined) in a translation
unit in which it is instantiated.</P>
<P>A non-exported non-class template must be defined in every translation unit
in which it is implicitly instantiated (14.7.1&nbsp;



 <A HREF="template.html#temp.inst">temp.inst</A>),
unless the corresponding
specialization is explicitly instantiated (14.7.2&nbsp;



 <A HREF="template.html#temp.explicit">temp.explicit</A>)
in some translation unit; no diagnostic is required.</P>
</BLOCKQUOTE>

<P> Note: This change also resolves issues <A HREF="
     cwg_active.html#204">204</A>
and <A HREF="
     cwg_active.html#335">335</A>.</P>

<BR>
<BR>
<HR>
<A NAME="335"></A>
<H4>335.
  
Allowing <TT>export</TT> on template members of nontemplate classes
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>14&nbsp;



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

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

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

 <B>Date: </B>30 Jan 2002
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>1
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Spicer<BR>



<P>From messages 9468, 9470.</P>


<P>The syntax for "export" permits it only on template declarations.
Clause 14&nbsp;



 <A HREF="template.html#temp">temp</A> paragraph 6 further restricts "export"
to appear only
on namespace scope declarations.  This means that you can't export
a member template of a non-template class, as in:
<PRE>
  class A {
    template &lt;class T&gt; void f(T);
  };
</PRE>
You can, of course, put export on the definition:
<PRE>
  export template &lt;class T&gt; void A&lt;T&gt;::f(T){}
</PRE>
but in order for the template to be used from other translation units
(the whole point of export) the declaration in the other translation
unit must also be declared export.</P>

<P>There is also the issue of whether or not we should permit this usage:
<PRE>
  export struct A {
    template &lt;class T&gt; void f(T);
  };
</PRE>
My initial reaction is to retain this prohibition as all current uses
of "export" are preceding the "template" keyword.</P>

<P>If we eliminate the requirement that "export" precede "template" there
is a similar issue regarding this case, which is currently prohibited:
<PRE>
  template &lt;class T&gt; struct B {
    export void f();
  };
</PRE>
My preference is still to permit only "export template".</P>

<P>
<B>Notes from the 4/02 meeting:</B>
</P>

<P>This is resolved by the proposed changes for
<A HREF="
     cwg_active.html#323">issue 323</A>.</P>

<BR>
<BR>
<HR>
<A NAME="184"></A>
<H4>184.
  
Default arguments in template <I>template-parameter</I>s
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>14.1&nbsp;



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

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

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

 <B>Date: </B>11 Nov 1999
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Spicer<BR>




<P>From reflector messages 8356-60.</P>


<P>
<U>John Spicer</U>:
Where can default values for the template parameters of
template template parameters be specified and where so they apply?</P>

<P>For normal template parameters, defaults can be specified only in
class template declarations and definitions, and they accumulate
across multiple declarations in the same way that function default
arguments do.</P>

<P>I think that defaults for parameters of template template parameters should
be handled differently, though.  I see no reason why such a default should
extend beyond the template declaration with which it is associated.
In other words, such defaults are a property of a specific template
declaration and are not part of the interface of the template.</P>

<PRE>
    template &lt;class T = float&gt; struct B {};

    template &lt;template &lt;class _T = float&gt; class T&gt; struct A {
        inline void f();
        inline void g();
    };

    template &lt;template &lt;class _T&gt; class T&gt; void A&lt;T&gt;::f() {
        T&lt;&gt; t;  // Okay? (proposed answer - no)
    }

    template &lt;template &lt;class _T = char&gt; class T&gt; // Okay? (proposed answer - yes)
    void A&lt;T&gt;::g() {
        T&lt;&gt; t;  // T&lt;char&gt; or T&lt;float&gt;?  (proposed answer - T&lt;char&gt;)
    }

    int main() {
        A&lt;B&gt; ab;
        ab.f();
    }
</PRE>

<P>I don't think this is clear in the standard.</P>

<P>
<U>Gabriel Dos Reis</U>:
On the other hand I fail to see the reasons why we should introduce
yet another special rule to handle that situation differently.  I
think we should try to keep rules as uniform as possible.
For default values, it has been the case that one
should look for any declaration specifying default values.  Breaking
that rules doesn't buy us anything, at least as far as I can see.
My feeling is that [allowing different defaults in different
declarations] is very confusing.</P>

<P>
<U>Mike Miller</U>:
I'm with John on this one.  Although we don't have the
concept of "prototype scope" for template parameter lists,
the analogy with function parameters would suggest that the
two declarations of <TT>T</TT> (in the template class definition and
the template member function definition) are separate
declarations and completely unrelated.  While it's true that
you accumulate default arguments on top-level declarations in
the same scope, it seems to me a far leap to say that we ought
also to accumulate default arguments in nested declarations.
I would expect those to be treated as being in different
scopes and thus <B>not</B> to share default argument information.</P>

<P>When you look up the name <TT>T</TT> in the definition of
<TT>A&lt;T&gt;::f()</TT>,
the declaration you find has no default argument for the
parameter of <TT>T</TT>, so <TT>T&lt;&gt;</TT> should not be allowed.</P>

<P>
<B>Proposed Resolution (4/02):</B>
</P>

<P>
In 14.1&nbsp;



 <A HREF="template.html#temp.param">temp.param</A>, add the following as a new paragraph
at the end of this section:</P>

<BLOCKQUOTE>
A <I>template-parameter</I> of a template <I>template-parameter</I>
is permitted to have a default <I>template-argument</I>.  When such
default arguments are specified, they apply to the template
<I>template-parameter</I> in the scope of the template
<I>template-parameter</I>.
<PRE>
    template &lt;class T = float&gt; struct B {};

    template &lt;template &lt;class TT = float&gt; class T&gt; struct A {
        inline void f();
        inline void g();
    };

    template &lt;template &lt;class TT&gt; class T&gt; void A&lt;T&gt;::f() {
        T&lt;&gt; t;  // error - TT has no default template argument
    }

    template &lt;template &lt;class TT = char&gt; class T&gt;void A&lt;T&gt;::g() {
        T&lt;&gt; t;  // OK - T&lt;char&gt;
    }
</PRE>
</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="226"></A>
<H4>226.
  
Default template arguments for function templates
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>14.1&nbsp;



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

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

 <B>Submitter: </B>Bjarne Stroustrup
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>19 Apr 2000
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Spicer<BR>


<P>The prohibition of default template arguments for function
templates is a misbegotten remnant of the time where freestanding
functions were treated as second class citizens and required all 
template arguments to be deduced from the function arguments
rather than specified.
</P>

<P>The restriction seriously cramps programming style by unnecessarily making 
freestanding functions different from member functions, thus making it harder 
to write STL-style code.</P>

<P>
<B>Suggested resolution:</B>
</P>

<P>Replace</P>

<BLOCKQUOTE>

A default <I>template-argument</I> shall not be specified in a
function template declaration or a function template definition, nor
in the <I>template-parameter-list</I> of the definition of a member of
a class template.

</BLOCKQUOTE>

<P>by</P>

<BLOCKQUOTE>

A default <I>template-argument</I> shall not be specified in the
<I>template-parameter-list</I> of the definition of a member of a
class template.

</BLOCKQUOTE>

<P>The actual rules are as stated for arguments to class templates.
</P>

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

<P>The core language working group was amenable to this change.
Questions arose, however, over the interaction between default
template arguments and template argument deduction: should it be
allowed or forbidden to specify a default argument for a deduced
parameter?  If it is allowed, what is the meaning: should one or
the other have priority, or is it an error if the default and
deduced arguments are different?</P>

<P>
<B>Notes from the 10/01 meeting:</B>
</P>

<P>It was decided that default arguments should be allowed on friend
declarations only when the declaration is a definition.  It was
also noted that it is not necessary to insist that if there
is a default argument for a given parameter all following parameters
have default arguments, because (unlike in the class case)
arguments can be deduced if they are not specified.</P>

<P>Note that there is an interaction with
<A HREF="
     cwg_active.html#115">issue 115</A>.</P>

<P>
<B>Proposed resolution (10/01):</B>
</P>

<OL>
<LI>
<P>In 14.1&nbsp;



 <A HREF="template.html#temp.param">temp.param</A> paragraph 9, replace</P>

<BLOCKQUOTE>
A default <I>template-argument</I> may be specified in a class
template declaration or a class template definition.  A default
<I>template-argument</I> shall not be specified in a function
template declaration or a function template definition, nor in the
<I>template-parameter-list</I> of the definition of a member of a
class template.
</BLOCKQUOTE>

<P>with</P>

<BLOCKQUOTE>
A default <I>template-argument</I> may be specified in a template
declaration.  A default
<I>template-argument</I> shall not be specified in the
<I>template-parameter-list</I>s of the definition of a member
of a class template that appears outside of the member's class.
</BLOCKQUOTE>

</LI>

<LI>
<P>In 14.8&nbsp;



 <A HREF="template.html#temp.fct.spec">temp.fct.spec</A> paragraph 9, replace</P>

<BLOCKQUOTE>
A default <I>template-argument</I> shall not be specified in a friend template
declaration.
</BLOCKQUOTE>

<P>with</P>

<BLOCKQUOTE>
A default <I>template-argument</I> shall not be specified in a friend
class template declaration.  If a friend function template declaration
specifies a default <I>template-argument</I>, that declaration must be
a definition and shall be the only declaration of the function template
in the translation unit.
</BLOCKQUOTE>

</LI>

<LI>
<P>In 14.8&nbsp;



 <A HREF="template.html#temp.fct.spec">temp.fct.spec</A> paragraph 11, replace</P>

<BLOCKQUOTE>
If a <I>template-parameter</I> has a default <I>template-argument</I>,
all subsequent <I>template-parameters</I> shall have a default
<I>template-argument</I> supplied.
</BLOCKQUOTE>

<P>with</P>

<BLOCKQUOTE>
If a <I>template-parameter</I> of a class template has a default
<I>template-argument</I>, all subsequent <I>template-parameters</I>
shall have a default <I>template-argument</I> supplied.
</BLOCKQUOTE>
</LI>

<LI>
<P>In 14.8&nbsp;



 <A HREF="template.html#temp.fct.spec">temp.fct.spec</A> paragraph 1, replace</P>

<BLOCKQUOTE>
Template arguments can either be explicitly specified when
naming the function template specialization or be deduced
(14.8.2&nbsp;



 <A HREF="template.html#temp.deduct">temp.deduct</A>) from the context, e.g. from the
function arguments in a call to the function template
specialization.
</BLOCKQUOTE>

<P>with</P>

<BLOCKQUOTE>
Template arguments can be explicitly specified when naming the
function template specialization, deduced from the context
(14.8.2&nbsp;



 <A HREF="template.html#temp.deduct">temp.deduct</A>), e.g., deduced from the function
arguments in a call to the function template specialization), or
obtained from default template arguments.
</BLOCKQUOTE>

</LI>

<LI>
<P>In 14.8.1&nbsp;



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

<BLOCKQUOTE>
Trailing template arguments that can be deduced
(14.8.2&nbsp;



 <A HREF="template.html#temp.deduct">temp.deduct</A>) may be omitted from the list
of explicit <I>template-argument</I>s.
</BLOCKQUOTE>

<P>with</P>

<BLOCKQUOTE>
Trailing template arguments that can be deduced
(14.8.2&nbsp;



 <A HREF="template.html#temp.deduct">temp.deduct</A>) or obtained from default
<I>template-argument</I>s may be omitted from the list of
explicit <I>template-argument</I>s.
</BLOCKQUOTE>

</LI>

<LI>
<P>In 14.8.2&nbsp;



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

<BLOCKQUOTE>
The values can be either explicitly specified or, in some
cases, deduced from the use.
</BLOCKQUOTE>

<P>with</P>

<BLOCKQUOTE>
The values can be explicitly specified or, in some cases,
be deduced from the use or obtained from default
<I>template-argument</I>s.
</BLOCKQUOTE>

</LI>

<LI>
<P>In 14.8.2&nbsp;



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

<BLOCKQUOTE>
The resulting substituted and adjusted function type is used as
the type of the function template for template argument
deduction.  When all template arguments have been deduced, all
uses of template parameters in nondeduced contexts are replaced
with the corresponding deduced argument values.  If the
substitution results in an invalid type, as described above,
type deduction fails.
</BLOCKQUOTE>

<P>with</P>

<BLOCKQUOTE>
<P>The resulting substituted and adjusted function type is used as
the type of the function template for template argument
deduction.  If a template argument has not been deduced, its
default template argument, if any, is used.  [<I>Example:</I>
</P>

<PRE>
    template &lt;class T, class U = double&gt;
    void f(T t = 0, U u = 0);

    void g()
    {
        f(1, 'c');         // f&lt;int,char&gt;(1,'c')
        f(1)               // f&lt;int,double&gt;(1,0)
        f();               // error: T cannot be deduced
        f&lt;int&gt;();          // f&lt;int,double&gt;(0,0)
        f&lt;int,char&gt;();     // f&lt;int,char&gt;(0,0)
    }
</PRE>

<P>---<I>end example</I>]</P>

<P>When all template arguments have been deduced or obtained from
default template arguments, all uses of template parameters in
nondeduced contexts are replaced with the corresponding deduced
or default argument values.  If the substitution results in an
invalid type, as described above, type deduction fails.</P>
</BLOCKQUOTE>
</LI>
</OL>

<BR>
<BR>
<HR>
<A NAME="228"></A>
<H4>228.
  
Use of <TT>template</TT> keyword with non-member templates
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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>Daveed Vandevoorde
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>4 May 2000
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Vandevoorde<BR>



<P>From reflector messages 8726-7.</P>


<P>Consider the following example:</P>

<PRE>
    template&lt;class T&gt;
    struct X {
       virtual void f();
    };

    template&lt;class T&gt;
    struct Y {
       void g(X&lt;T&gt; *p) {
	  p-&gt;template X&lt;T&gt;::f();
       }
    };
</PRE>

<P>This is an error because <TT>X</TT> is not a member template;
14.2&nbsp;



 <A HREF="template.html#temp.names">temp.names</A> paragraph 5 says:</P>

<BLOCKQUOTE>
If a name prefixed by the keyword <TT>template</TT> is not the name 
of a member template, the program is ill-formed.
</BLOCKQUOTE>

<P>In a way this makes perfect sense: <TT>X</TT> is found to be a template
using ordinary lookup even though <TT>p</TT> has a dependent type.
However, I think this makes the use of the <TT>template</TT> prefix
even harder to teach.</P>

<P>Was this intentionally outlawed?</P>

<P>
<B>Proposed Resolution (4/02):</B>
</P>

<P>Elide the first use of the word "member" in
14.2&nbsp;



 <A HREF="template.html#temp.names">temp.names</A> paragraph 5 so that its first sentence reads:</P>
<BLOCKQUOTE>
If a name prefixed by the keyword <TT>template</TT> is not the name of a
<S>member</S> template, the program is ill-formed.
</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="287"></A>
<H4>287.
  
Order dependencies in template instantiation
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>14.6.4.1&nbsp;



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

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

 <B>Submitter: </B>Martin Sebor
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>17 May 2001
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>1
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Spicer<BR>


<P>From messages 9163-70.  The discussion did not
appear to have concluded at the time of this writing, so additional
messages may deal with this topic.
</P>

<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>

<BR>
<BR>
<HR>
<A NAME="182"></A>
<H4>182.
  
Access checking on explicit specializations
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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>John Spicer
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>8 Nov 1999
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Caves<BR>




<P>From reflector messages 8348-8352.</P>


<P>
<U>John Spicer</U>:
Certain access checks are suppressed on explicit instantiations.
14.7.2&nbsp;



 <A HREF="template.html#temp.explicit">temp.explicit</A>
 paragraph 8
says:</P>

<BLOCKQUOTE>
The usual access checking rules do not apply to names used to specify
explicit instantiations. [<I>Note:</I> In particular, the template arguments
and names used in the function declarator (including parameter types,
return types and exception specifications) may be private types or
objects which would normally not be accessible and the template may be
a member template or member function which would not normally be
accessible. ]
</BLOCKQUOTE>

I was surprised that similar wording does not exist (that I could find) for
explicit specializations.  I believe that the two cases should be handled
equivalently in the example below (i.e., that the specialization should be
permitted).

<PRE>
    template &lt;class T&gt; struct C {
    void f();
    void g();
    };

    template &lt;class T&gt; void C&lt;T&gt;::f(){}
    template &lt;class T&gt; void C&lt;T&gt;::g(){}

    class A {
    class B {};
    void f();
    };

    template void C&lt;A::B&gt;::f();    // okay
    template &lt;&gt; void C&lt;A::B&gt;::g(); // error - A::B inaccessible

    void A::f() {
    C&lt;B&gt; cb;
    cb.f();
    }
</PRE>

<P>
<U>Mike Miller</U>:
According to the note in
14.3&nbsp;



 <A HREF="template.html#temp.arg">temp.arg</A>
 paragraph 3,</P>

<BLOCKQUOTE>
if the name of a <I>template-argument</I> is accessible
at the point where it is used as a <I>template-argument</I>,
there is no further access restriction in the
resulting instantiation where the corresponding
<I>template-parameter</I> name is used.
</BLOCKQUOTE>

<P>(Is this specified anywhere in the normative text?  Should
it be?)</P>

<P>In the absence of text to the contrary, this blanket
permission apparently applies to explicitly-specialized
templates as well as to implicitly-generated ones (is that
right?).  If so, I don't see any reason that an explicit
instantiation should be treated differently from an explicit
specialization, even though the latter involves new program
text and the former is just a placement instruction to the
implementation.</P>

<P>
<B>Proposed Resolution (4/02):</B>
</P>

<P>In 14.7.2&nbsp;



 <A HREF="template.html#temp.explicit">temp.explicit</A> delete paragraph 8:</P>
<BLOCKQUOTE>
The usual access checking rules do not apply to names used to specify explicit
instantiations. [Note: In particular, the template arguments and names used in
the function declarator (including parameter types, return types and exception
specifications) may be private types or objects which would normally not be
accessible and the template may be a member template or member function which
would not normally be accessible. ]
</BLOCKQUOTE>

<P>In 14.7&nbsp;



 <A HREF="template.html#temp.spec">temp.spec</A> add the paragraph deleted above as
paragraph 7 with the changes highlighted below:</P>

<BLOCKQUOTE>
The usual access checking rules do not apply to names used to specify explicit
instantiations <B>or explicit specializations</B>. <S>[Note: In
particular, t</S><B>T</B>he template arguments and names used in the
function declarator (including parameter types, return types and exception
specifications) may be private types or objects which would normally not be
accessible and the template may be a member template or member function
which would not normally be accessible. <S>]</S>
</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="337"></A>
<H4>337.
  
Attempt to create array of abtract type should cause deduction to fail
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>14.8.2&nbsp;



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

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

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

 <B>Date: </B>30 Jan 2002
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>0
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Caves<BR>


<P>In 14.8.2&nbsp;



 <A HREF="template.html#temp.deduct">temp.deduct</A>, attempting to create an array
of abstract class type should
be included in the list of things that cause type deduction to fail.</P>

<P>
<B>Proposed Resolution (4/02):</B>
</P>

<P> In 14.8.2&nbsp;



 <A HREF="template.html#temp.deduct">temp.deduct</A> paragraph 2 amend the bullet item:</P>
<BLOCKQUOTE>
Attempting to create an array with an element type that is <TT>void</TT>,
a function type, or a reference type, or attempting to create an array
with a size that is zero or negative.
</BLOCKQUOTE>

<P> To the following:</P>
<BLOCKQUOTE>
Attempting to create an array with an element type that is <TT>void</TT>,
a function type, <S>or</S> a reference type, <B>or an abstract class
type,</B> or
attempting to create an array with a size that is zero or negative.
</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="322"></A>
<H4>322.
  
Deduction of reference conversions
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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>review
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Jason Merrill
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>14 Nov 2001
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>1
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Spicer<BR>



<P>From message 9385.
(Gabriel Dos Reis and Nathan Sidwell raised the same issue a second time
in message 9444.  John Spicer replied in message 9479 with the same proposed
solution that Jason Merrill gave here.)</P>


<P>Consider:
<PRE>
  struct S {
    template &lt;class T&gt; operator T&amp; ();
  };

  int main ()
  {
    S s;
    int i = static_cast&lt;int&amp;&gt; (s);
  }
</PRE>
14.8.2.3&nbsp;



 <A HREF="template.html#temp.deduct.conv">temp.deduct.conv</A> says that we strip the
reference from <TT>int&amp;</TT>, but doesn't say
anything about <TT>T&amp;</TT>.  As a result, <TT>P</TT> (<TT>T&amp;</TT>)
and <TT>A</TT> (<TT>int</TT>) have incompatible forms
and deduction fails.</P>

<P>
<B>Proposed Resolution (4/02):</B>
</P>

<P>Change the last chunk of 14.8.2.3&nbsp;



 <A HREF="template.html#temp.deduct.conv">temp.deduct.conv</A> paragraph 2 from
<BLOCKQUOTE>
     If <TT>A</TT> is a cv-qualified type, the top level cv-qualifiers
     of <TT>A</TT>'s type are ignored for type deduction.  If
     <TT>A</TT> is a reference type, the type referred to by
     <TT>A</TT> is used for type deduction.
</BLOCKQUOTE>
to
<BLOCKQUOTE>
     If <TT>A</TT> is a cv-qualified type, the top level cv-qualifiers
     of A's type are ignored for type deduction.  If <TT>A</TT> is a
     reference type, the type referred to by <TT>A</TT> is used for
     type deduction.  If <TT>P</TT> is a reference type, the type
     referred to by <TT>P</TT> is used for type deduction.
</BLOCKQUOTE>
</P>

<BR>
<BR>
<BR>
<BR>
<HR>
<A NAME="Drafting Status"></A>
<H3>Issues with "Drafting" Status</H3>
<HR>
<A NAME="225"></A>
<H4>225.
  
Koenig lookup and fundamental types
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>3.4.2&nbsp;



 <A HREF="basic.html#basic.lookup.koenig">basic.lookup.koenig</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
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>1
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Spicer<BR>


<P>In discussing <A HREF="
     cwg_active.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>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Merrill<BR>




<P>From reflector messages 8274, 8308, and 8311-13.</P>


<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="305"></A>
<H4>305.
  
Name lookup in destructor call
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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>Mark Mitchell
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>19 May 2001
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>1
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Merrill<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 tyepdef
for the desired type.</P>

<P>See also <A HREF="
     cwg_active.html#244">issue 244</A>.</P>

<BR>
<BR>
<HR>
<A NAME="222"></A>
<H4>222.
  
Sequence points and lvalue-returning operators
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Crowl<BR>



<P>From messages 8395, 8826-32, 8834, 8837, 8840-43, 8845, 8847, and 9297.
</P>


<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>

<BR>
<BR>
<HR>
<A NAME="125"></A>
<H4>125.
  
Ambiguity in <TT>friend</TT> declaration syntax
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>5.1&nbsp;



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

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

 <B>Submitter: </B>Martin von Loewis
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>7 June 1999
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Nelson<BR>



<P>The example below is ambiguous.</P>

<PRE>
    struct A{
      struct B{};
    };

    A::B C();

    namespace B{
      A C();
    }

    struct Test {
      friend A::B ::C();
    };
</PRE>

Here, it is not clear whether the friend declaration denotes
<TT>A B::C()</TT> or <TT>A::B C()</TT>, yet the standard does not resolve this
ambiguity.

<P>The ambiguity arises since both the <I>simple-type-specifier</I>
(7.1.5.2&nbsp;



 <A HREF="dcl.html#dcl.type.simple">dcl.type.simple</A>
 paragra 1) and an
<I>init-declararator</I>
(8&nbsp;



 <A HREF="decl.html#dcl.decl">dcl.decl</A>
 paragraph 1)
contain an optional <TT>::</TT> and an optional
<I>nested-name-specifier</I>
(5.1&nbsp;



 <A HREF="expr.html#expr.prim">expr.prim</A>
 paragraph 1).
Therefore, two different ways to analyse this code are
possible:</P>

<BLOCKQUOTE>
<I>simple-type-specifier</I> = <TT>A::B</TT>
<BR>
<I>init-declarator</I> = <TT>::C()</TT>
<BR>
<I>simple-declaration</I> = <TT>friend A::B ::C();</TT>
</BLOCKQUOTE>

or

<BLOCKQUOTE>
<I>simple-type-specifier</I> = <TT>A</TT>
<BR>
<I>init-declarator</I> = <TT>::B::C()</TT>
<BR>
<I>simple-declaration</I> = <TT>friend A ::B::C();</TT>
</BLOCKQUOTE>

Since it is a friend declaration, the init-declarator may be
qualified, and start with a global scope.

<P>Suggested Resolution: In the definition of
<I>nested-name-specifier</I>, add a
sentence saying that a <TT>::</TT> token immediately following a
<I>nested-name-specifier</I> is always considered as part of the
<I>nested-name-specifier</I>. Under this interpretation, the example is
ill-formed, and should be corrected as either</P>

<PRE>
    friend A (::B::C)();   //or
    friend A::B (::C)();
</PRE>

<P>An alternate suggestion &mdash; changing
7.1&nbsp;



 <A HREF="dcl.html#dcl.spec">dcl.spec</A>
 to say that</P>

<BLOCKQUOTE>
The longest sequence of <B>tokens</B> that could possibly be a type
name is taken as the <I>decl-specifier-seq</I> of a <I>declaration</I>.
</BLOCKQUOTE>

<P>&mdash; is undesirable because it would make the example well-formed
rather than requiring the user to disambiguate the declaration
explicitly.</P>

<P>
<B>Proposed resolution (04/01):</B>
</P>

<P>
<B>(See below for problem with this, from 10/01 meeting.)</B>
</P>

<P>In 5.1&nbsp;



 <A HREF="expr.html#expr.prim">expr.prim</A> paragraph 7,</P>

<OL>

<LI>
<P>Before the grammar for <I>qualified-id</I>, start a new
paragraph 7a with the text </P>

<BLOCKQUOTE>

A <I>qualified-id</I> is an <I>id-expression</I> that contains the
scope resolution operator <TT>::</TT>.

</BLOCKQUOTE>

</LI>

<LI>
<P>Following the grammar fragment, insert the following:</P>

<BLOCKQUOTE>

<P>The longest sequence of tokens that could form a <I>qualified-id</I>
constitutes a single <I>qualified-id</I>.  [<I>Example:</I>
</P>

<PRE>
    // classes C, D; functions F, G, namespace N; non-class type T
    friend C ::D::F();   // ill-formed, means friend (C::D::F)();
    friend C (::D::F)(); // well-formed
    friend N::T ::G();   // ill-formed, means friend (N::T::G)();
    friend N::T (::G)(); // well-formed
</PRE>

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

</BLOCKQUOTE>

</LI>

<LI>
<P>Start a new paragraph 7b following the example.</P>
</LI>

</OL>

<P>(This resolution depends on that of
<A HREF="
     cwg_active.html#215">issue 215</A>.)</P>

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

<P>It was pointed out that the proposed resolution does not deal with
cases like <TT>X::Y</TT> where <TT>X</TT> is a type but not a class type.
The working group reaffirmed its decision that the disambiguation should
be syntactic only, i.e., it should depend only on whether or not the name is a
type.</P>

<U>Jason Merrill</U>
in message 9377:

<P>At the Seattle meeting, I suggested that a solution might be to change the
<I>class-or-namespace-name</I> in the <I>nested-name-specifier</I>
rule to just be
"identifier"; there was some resistance to this idea.  FWIW, I've tried
this in g++.  I had to revise the idea so that only the second and
subsequent names were open to being any identifier, but that seems to work
just fine.</P>

<P>So, instead of</P>

<UL>
<I>nested-name-specifier</I>:
<UL>
<I>class-or-namespace-name</I> <TT>::</TT> <I>nested-name-specifier</I><SUB>opt</SUB>
<BR>
<I>class-or-namespace-name</I> <TT>::</TT> <I>template nested-name-specifier</I>
</UL>
</UL>

<P>it would be</P>

<UL>
<I>nested-name-specifier</I>:
<UL>
<I>type-or-namespace-name</I> <TT>::</TT> (per issue 215)
<BR>
<I>nested-name-specifier</I> <I>identifier</I> <TT>::</TT>
<BR>
<I>nested-name-specifier</I> <TT>template</TT> <I>template-id</I> <TT>::</TT>
</UL>
</UL>

<P>Or some equivalent but right-associative formulation, if people feel that's
important, but it seems irrelevant to me.</P>

<P>
<U>Clark Nelson</U>
in message 9378:</P>

<P>Personally, I prefer the left-associative rule. I think it makes it easier
to understand. I was thinking about this production a lot at the meeting,
considering also some issues related to <A HREF="
     cwg_active.html#301">301</A>.
My formulation was getting kind
of ugly, but with a left-associative rule, it gets a lot nicer.</P>

<P>Your proposal isn't complete, however, as it doesn't allow template
arguments without an explicit template keyword. You probably want to add an
alternative for:</P>

<UL>
<I>nested-name-specifier type-or-namespace-name</I> <TT>::</TT>
</UL>

<P>There is admittedly overlap between this alternative and</P>

<UL>
<I>nested-name-specifier identifier</I> <TT>::</TT>
</UL>

<P>but I think they're both necessary.</P>

<P>
<B>Notes from the 4/02 meeting:</B>
</P>

<P>The changes look good.  Clark Nelson will merge the two proposals
to produce a single proposed resolution.</P>

<BR>
<BR>
<HR>
<A NAME="118"></A>
<H4>118.
  
Calls via pointers to virtual member functions
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>5.2.2&nbsp;



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

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

 <B>Submitter: </B>Martin O'Riordan
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>17 May 1999
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>O'Riordan<BR>



<P>From reflector messages 8063, 8067-8071, 8080, 8082-8090.</P>


<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>
<BR>
<BR>
<HR>
<A NAME="324"></A>
<H4>324.
  
Can "<TT>&amp;</TT>" be applied to assignment to bit-field?
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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>Alasdair Grant
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>27 Nov 2001
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>0
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Adamczyk<BR>


<P>An assignment returns an lvalue for its left operand.  If that
operand refers to a bit field, can the "<TT>&amp;</TT>" operator be
applied to the assignment?  Can a reference be bound to it?</P>
<PRE>
  struct S { int a:3; int b:3; int c:3; };

  void f()
  {
    struct S s;
    const int *p = &amp;(s.b = 0);     // (a)
    const int &amp;r = (s.b = 0);      // (b)
          int &amp;r2 = (s.b = 0);     // (c)
  }
</PRE>

<P>
<B>Notes from the 4/02 meeting:</B>
</P>

<P>The working group agreed that this should be an error.</P>

<BR>
<BR>
<HR>
<A NAME="138"></A>
<H4>138.
  
Friend declaration name lookup
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>1
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Spicer<BR>




<P>From reflector messages 8206-8213, initiated via a message to
<TT>comp.std.c++</TT>.</P>


<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>


<P>Mike Miller and John Spicer will write a paper for the October,
2000 meeting with proposed
wording to implement the recommendations of the preceding paper.</P>


<BR>
<BR>
<HR>
<A NAME="341"></A>
<H4>341.
  
<TT>extern "C"</TT> namespace member function versus global variable
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>1
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Crowl<BR>



<P>From message 9488.</P>


<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>
<BR>
<BR>
<HR>
<A NAME="86"></A>
<H4>86.
  
Lifetime of temporaries in query expressions
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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>Jan 1999
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>O'Riordan<BR>



<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>
<BR>
<BR>
<HR>
<A NAME="115"></A>
<H4>115.
  
Address of template-id
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>13.4&nbsp;



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

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

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

 <B>Date: </B>7 May 1999
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>1
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Adamczyk<BR>



<P>(Issue reopened in messages 9099-9101.)</P>

<PRE>
    template &lt;class T&gt; void f(T);
    template &lt;class T&gt; void g(T);
    template &lt;class T&gt; void g(T,T);

    int main()
    {
        (&amp;f&lt;int&gt;);
        (&amp;g&lt;int&gt;);
    }
</PRE>

The question is whether <TT>&amp;f&lt;int&gt;</TT> identifies a unique function.
<TT>&amp;g&lt;int&gt;</TT> is clearly ambiguous.

<P>13.4&nbsp;



 <A HREF="over.html#over.over">over.over</A>
 paragraph 1
says that a function template name is considered to name a
set of overloaded functions.  I believe it should be expanded to say that
a function template name with an explicit template argument list is also
considered to name a set of overloaded functions.</P>

<P>In the general case, you need to have a destination type in order
to identify a unique function.  While it is possible to permit this, I
don't think it is a good idea because such code depends on there only
being one template of that name that is visible.</P>

<P>The EDG front end issues an error on this use of "<TT>f</TT>".
egcs 1.1.1 allows
it, but the most current snapshot of egcs that I have also issues an error
on it.</P>

<P>It has been pointed out that when dealing with nontemplates, the rules
for taking the address of a single function differ from the rules
for an overload set, but this asymmetry is needed for C compatibility.
This need does not exist for the template case.</P>

<P>My feeling is that a general rule is better than a general rule plus
an exception.  The general rule is that you need a destination type
to be sure that the operation will succeed.  The exception is when
there is only one template in the set and only then when you provide
values for all of the template arguments.</P>

<P>It is true that in some cases you can provide a shorthand, but only if
you encourage a fragile coding style (that will cause programs to break
when additional templates are added).</P>

<P>I think the standard needs to specify one way or the other how this
case should be handled.  My recommendation would be that it is
ill-formed.</P>

<P>
<U>Nico Josuttis</U>: Consider the following example:</P>

<PRE>
    template &lt;int VAL&gt;
    int add (int elem)
    {
	return elem + VAL;
    }

    std::transform(coll.begin(), coll.end()
		   coll.begin(),
		   add&lt;10&gt;);
</PRE>

<P>If John's recommendation is adopted, this code will become
ill-formed.  I bet there will be a lot of explanation for users
necessary why this fails and that they have to change
<TT>add&lt;10&gt;</TT> to something like
<TT>(int (*)(int))add&lt;10&gt;</TT>.</P>

<P>This example code is probably common practice because this
use of the STL is typical and is accepted in many current
implementations.  I strongly urge that this issue be resolved
in favor of keeping this code valid.</P>

<P>
<U>Bill Gibbons</U>:  I find this rather surprising.  Shouldn't
a <I>template-id</I> which specifies all of the template arguments
be treated like a declaration-only explicit instantiation,
producing a set of ordinary function declarations?  And when that
set happens to contain only one function, shouldn't the example
code work?</P>

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

<P>
<B>Notes from 04/01 meeting:</B>
</P>

<P>The consensus of the group was that the <TT>add</TT> example
should not be an error.</P>

<P>
<B>Proposed resolution (04/01):</B>
</P>

<P>In 13.4&nbsp;



 <A HREF="over.html#over.over">over.over</A> paragraph 1 change:
<BLOCKQUOTE>
A function template name is considered to name a set of overloaded
functions in such contexts.
</BLOCKQUOTE>
to:
<BLOCKQUOTE>
A function template name is considered to name a set of overloaded
functions in such contexts, unless it is followed by an explicit template
argument specification (14.8.1&nbsp;



 <A HREF="template.html#temp.arg.explicit">temp.arg.explicit</A>) that identifies a
single function template specialization.
</BLOCKQUOTE>
</P>

<P>
Add just before the first example of 14.8.1&nbsp;



 <A HREF="template.html#temp.arg.explicit">temp.arg.explicit</A> paragraph 2:
<BLOCKQUOTE>
If a template argument list is specified and it, along with any
default template arguments, identifies a single function template
specialization, then the resulting <I>template-id</I> is an lvalue
of function type (which is subject to function-to-pointer conversion
(4.3&nbsp;



 <A HREF="conv.html#conv.func">conv.func</A>)).
</BLOCKQUOTE>
</P>

<P>
Change the first example of 14.8.1&nbsp;



 <A HREF="template.html#temp.arg.explicit">temp.arg.explicit</A> paragraph 2:
<PRE>
  template&lt;class X, class Y&gt; X f(Y);
  void g()
  {
    int i = f&lt;int&gt;(5.6);    // Y <I>is deduced to be</I> double
    int j = f(5.6);         // <I>ill-formed:</I> X <I>cannot be deduced</I>
  }
</PRE>
to read:
<PRE>
  template&lt;class X, class Y&gt; X f(Y);
  void g()
  {
    int i = f&lt;int&gt;(5.6);    // Y <I>is deduced to be</I> double
    int j = f(5.6);         // <I>ill-formed:</I> X <I>cannot be deduced</I>
    f&lt;void&gt;(f&lt;int, bool&gt;);  // Y <I>for outer</I> f <I>deduced to be</I>
                            //   int (*)(bool)
    f&lt;void&gt;(f&lt;int&gt;);        // <I>ill-formed:</I> f&lt;int&gt; <I>does not denote an</I>
                            // <I>lvalue but an overload set</I>
  }
</PRE>
</P>

<P>
<B>Note:</B> this interacts with the resolution of
<A HREF="
     cwg_active.html#226">issue 226</A>.</P>

<P>
<B>Notes from the 4/02 meeting:</B>
</P>

<P>The proposed resolution is not quite right.  We would like to defer
decay to a single function until the template-id is not called and
does not have its address taken in the presence of a destination type.</P>

<BR>
<BR>
<HR>
<A NAME="205"></A>
<H4>205.
  
Templates and static data members
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Vandevoorde<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>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Nelson<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_active.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_active.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>
<BR>
<BR>
<HR>
<A NAME="301"></A>
<H4>301.
  
Syntax for <I>template-name</I>
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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>24 Jul 2001
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Nelson<BR>


<P>From message 9259.</P>

<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>
<BR>
<BR>
<HR>
<A NAME="314"></A>
<H4>314.
  
<TT>template</TT> in base class specifier
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Nelson<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="197"></A>
<H4>197.
  
Issues with two-stage lookup of dependent names
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>14.6.4.2&nbsp;



 <A HREF="template.html#temp.dep.candidate">temp.dep.candidate</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
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Merrill<BR>




<P>From reflector message 8500.</P>


<P>The example in
14.6&nbsp;



 <A HREF="template.html#temp.res">temp.res</A>
 paragraph 9 is incorrect,
according to 14.6.4.2&nbsp;



 <A HREF="template.html#temp.dep.candidate">temp.dep.candidate</A>
.  The
example reads,</P>

<PRE>
    void f(char);

    template &lt;class T&gt; void g(T t)
    {
        f(1);        // f(char);
        f(T(1));     // <I>dependent</I>
        f(t);        // <I>dependent</I>
        dd++;        // <I>not dependent</I>
                     // <I>error: declaration for dd not found</I>
    }

    void f(int);

    double dd;
    void h()
    {
        g(2);        // <I>will cause one call of </I>f(char)<I> followed</I>
                     // <I>by two calls of </I>f(int)
        g('a');      // <I>will cause three calls of </I>f(char)
    }
</PRE>

Since 14.6.4.2&nbsp;



 <A HREF="template.html#temp.dep.candidate">temp.dep.candidate</A>
 says that
only Koenig lookup is done from the instantiation context, and since
3.4.2&nbsp;



 <A HREF="basic.html#basic.lookup.koenig">basic.lookup.koenig</A>
 says that
fundamental types have no associated namespaces, either the example is
incorrect (and <TT>f(int)</TT> will never be called) or the
specification in 14.6.4.2&nbsp;



 <A HREF="template.html#temp.dep.candidate">temp.dep.candidate</A>

is incorrect.

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

<P>The core working group agreed that the example as written is
incorrect and should be reformulated to use a class type instead of a
fundamental type.  It was also decided to open a new issue dealing
more generally with Koenig lookup and fundamental types.</P>

<P>(See also issues <A HREF="
     cwg_defects.html#213">213</A> and
<A HREF="
     cwg_active.html#225">225</A>.)</P>
<BR>
<BR>
<HR>
<A NAME="336"></A>
<H4>336.
  
Explicit specialization examples are still incorrect
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>14.7.3&nbsp;



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

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

 <B>Submitter: </B>Jason Shirk
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>29 Jan 2002
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>0
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Spicer<BR>



<P>From message 9467.</P>


<P>The examples corrected by <A HREF="
     cwg_defects.html#24">issue 24</A> are still
wrong in one case.</P>

<P>In item #4 (a correction to the example in paragraph 18), the proposed
resolution is:</P>
<PRE>
  template&lt;class T1&gt; class A { 
    template&lt;class T2&gt; class B { 
      template&lt;class T3&gt; void mf1(T3); 
        void mf2(); 
      }; 
  }; 
  template&lt;&gt; template&lt;class X&gt; 
    class A&lt;int&gt;::B { }; 
  template&lt;&gt; template&lt;&gt; template&lt;class T&gt; 
    void A&lt;int&gt;::B&lt;double&gt;::mf1(T t) { }
  template&lt;class Y&gt; template&lt;&gt; 
    void A&lt;Y&gt;::B&lt;double&gt;::mf2() { } // ill-formed; B&lt;double&gt; is specialized but 
                                    // its enclosing class template A is not 
</PRE>

<P>The explicit specialization of member <TT>A&lt;int&gt;::B&lt;double&gt;::mf1</TT>
is ill-formed.  The class template <TT>A&lt;int&gt;::B</TT>
is explicitly specialized and
contains no members, so any implicit specialization (such as
<TT>A&lt;int&gt;::B&lt;double&gt;</TT>) would also contain no members.</P>

<P>
<B>Proposed Resolution (4/02):</B>
</P>

<P>
Fix the example in 14.7.3&nbsp;



 <A HREF="template.html#temp.expl.spec">temp.expl.spec</A> paragraph 18 to read:</P>
<PRE>
  template&lt;class T1&gt; class A { 
    template&lt;class T2&gt; class B { 
      template&lt;class T3&gt; void mf1(T3);
      void mf2(); 
    }; 
  }; 
  template&lt;&gt; template&lt;class X&gt; 
    class A&lt;int&gt;::B {
      template&lt;class T&gt; void mf1(T);
    }; 
  template&lt;&gt; template&lt;&gt; template&lt;class T&gt; 
    void A&lt;int&gt;::B&lt;double&gt;::mf1(T t) { }
  template&lt;class Y&gt; template&lt;&gt; 
    void A&lt;Y&gt;::B&lt;double&gt;::mf2() { } // ill-formed; B&lt;double&gt; is specialized but 
                                    // its enclosing class template A is not 
</PRE>

<BR>
<BR>
<BR>
<BR>
<HR>
<A NAME="Open Status"></A>
<H3>Issues with "Open" Status</H3>
<HR>
<A NAME="129"></A>
<H4>129.
  
Stability of uninitialized auto variables
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>3<BR>




<P>From reflector messages 8111-19, 8122, 8124-26, 8129-31, 8139-40, 8142-46,
and 8159-8165.</P>


<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="189"></A>
<H4>189.
  
Definition of <I>operator</I> and <I>punctuator</I>
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>2.12&nbsp;



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

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

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

 <B>Date: </B>20 Dec 1999
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Crowl<BR>




<P>From reflector message 8398.</P>


<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>
<BR>
<BR>
<HR>
<A NAME="309"></A>
<H4>309.
  
Linkage of entities whose names are not simply identifiers, in introduction
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>3<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="191"></A>
<H4>191.
  
Name lookup does not handle complex nesting
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2<BR>




<P>From reflector message 8422.</P>


<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>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2<BR>




<P>From reflector messages 8429-32.</P>


<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="218"></A>
<H4>218.
  
Specification of Koenig lookup
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>3.4.2&nbsp;



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

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

 <B>Submitter: </B>Hyman Rosen
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>28 Mar 2000
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>1
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Spicer<BR>



<P>From reflector messages 8636-49, 8651-2, 8654, 8665-8, 8670-84,
8686-8715, and 8718.</P>


<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.koenig">basic.lookup.koenig</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.koenig">basic.lookup.koenig</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.koenig">basic.lookup.koenig</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.  Mike Miller and John Spicer
volunteered to provide wording implementing the different
positions. </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>

<P>Bjarne Stroustrup suggested that we table this discussion
pending input from Andrew Koenig, who was not able to attend the
Redmond meeting.  The Core Working Group agreed.</P>

<BR>
<BR>
<HR>
<A NAME="321"></A>
<H4>321.
  
Associated classes and namespaces for argument-dependent lookup
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>3.4.2&nbsp;



 <A HREF="basic.html#basic.lookup.koenig">basic.lookup.koenig</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
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>3<BR>


<P>The last bullet of the second paragraph of section
3.4.2&nbsp;



 <A HREF="basic.html#basic.lookup.koenig">basic.lookup.koenig</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.koenig">basic.lookup.koenig</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.koenig">basic.lookup.koenig</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.koenig">basic.lookup.koenig</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>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>3<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="278"></A>
<H4>278.
  
External linkage and nameless entities
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>3<BR>


<P>(From messages 9119, 9131-3.)</P>

<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>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>3<BR>


<P>(From message 9120.)</P>

<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="319"></A>
<H4>319.
  
Use of names without linkage in declaring entities with linkage
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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>Clark Nelson
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>29 Oct 2001
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2<BR>



<P>From message 9371.</P>


<P>According to 3.5&nbsp;



 <A HREF="basic.html#basic.link">basic.link</A> paragraph 8,
"A name with no linkage ... shall not 
be used to declare an entity with linkage." This would appear to rule
out code such as:
<PRE>
  typedef struct {
    int i;
  } *PT;
  extern "C" void f(PT);
</PRE>
[likewise]
<PRE>
  static enum { a } e;
</PRE>
which seems rather harmless to me.</P>

<P>See <A HREF="
     cwg_closed.html#132">issue 132</A>, which dealt with a closely
related issue.</P>

<P>
<U>Andrei Iltchenko</U> submitted the same issue via comp.std.c++ on
17 Dec 2001:</P>

<P>Paragraph 8 of Section 3.5&nbsp;



 <A HREF="basic.html#basic.link">basic.link</A> contains the following
sentences: "A name with no linkage shall not be used to declare an
entity with linkage. If a declaration uses a typedef name, it is the
linkage of the type name to which the typedef refers that is
considered."</P>

<P>The problem with this wording is that it doesn't cover cases where the
type to which a typedef-name refers has no name. As a result it's not
clear whether, for example, the following program is well-formed:</P>
<PRE>
#include &lt;vector&gt;

int  main()
{
   enum  {   sz = 6u   };
   typedef int  (* aptr_type)[sz];
   typedef struct  data  {
      int   i,  j;
   }  * elem_type;
   std::vector&lt;aptr_type&gt;   vec1;
   std::vector&lt;elem_type&gt;   vec2;
}
</PRE>

<P>
<B>Suggested resolution:</B>
</P>

<P>My feeling is that the rules for whether or not a typedef-name used in
a declaration shall be treated as having or not having linkage ought
to be modelled after those for dependent types, which are explained in
14.6.2.1&nbsp;



 <A HREF="template.html#temp.dep.type">temp.dep.type</A>.</P>

<P>Add the following text at the end of Paragraph 8 of Section
3.5&nbsp;



 <A HREF="basic.html#basic.link">basic.link</A> and replace the following example:</P>
<BLOCKQUOTE>
In case of the type referred to by a typedef declaration not having a name,
the newly declared typedef-name has linkage if and only if its referred type
comprises no names of no linkage excluding local names that are eligible for
appearance in an integral constant-expression (5.19&nbsp;



 <A HREF="expr.html#expr.const">expr.const</A>).
[Note: if the referred
type contains a typedef-name that does not denote an unnamed class, the
linkage of that name is established by the recursive application of this
rule for the purposes of using typedef names in declarations.] [Example:
<PRE>
  void f()
  {
     struct A { int x; };        // no linkage
     extern A a;                 // ill-formed
     typedef A Bl
     extern B b;                 // ill-formed

     enum  {   sz = 6u   };
     typedef int  (* C)[sz];     // C has linkage because sz can
                                 // appear in a constant expression
  }
</PRE>
--end example.]
</BLOCKQUOTE>

<P>
<B>Additional issue (13 Jan 2002, from Andrei Iltchenko):</B>
</P>
<P>Paragraph 2 of Section 14.3.1&nbsp;



 <A HREF="template.html#temp.arg.type">temp.arg.type</A> is inaccurate and
unnecessarily prohibits a few important cases; it says "A local type, a type
with no linkage, an unnamed type or a type compounded from any of these
types shall not be used as a template-argument for a template-parameter."
The inaccuracy stems from the fact that it is not a type but its name that
can have a linkage.</P>

<P>For example based on the current wording of 14.3.1&nbsp;



 <A HREF="template.html#temp.arg.type">temp.arg.type</A>,
the following example is ill-formed.</P>
<PRE>
  #include &lt;vector&gt;
  struct  data  {
    int   i,  j;
  };
  int  main()
  {
    enum  {   sz = 6u   };
    std::vector&lt;int(*)[sz]&gt;   vec1; // The types 'int(*)[sz]' and 'data*'
    std::vector&lt;data*&gt;        vec2; // have no names and are thus illegal
                                    // as template type arguments.
  }
</PRE>

<P>
<B>Suggested resolution:</B>
</P>
<P>Replace the whole second paragraph of Section 14.3.1&nbsp;



 <A HREF="template.html#temp.arg.type">temp.arg.type</A>
with the following wording:</P>
<BLOCKQUOTE>
A type whose name does not have a linkage or a type compounded from any such
type shall not be used as a template-argument for a template-parameter. In
case of a type <TT>T</TT> used as a template type argument not having a name,
<TT>T</TT>
constitutes a valid template type argument if and only if the name of an
invented typedef declaration referring to <TT>T</TT> would have linkage;
see 3.5.
[Example:
<PRE>
  template &lt;class T&gt; class X { /* ... */ };
  void f()
  {
    struct S { /* ... */ };
    enum  {   sz = 6u   };

    X&lt;S&gt; x3;                     // error: a type name with no linkage
                                 // used as template-argument
    X&lt;S*&gt; x4;                    // error: pointer to a type name with
                                 // no linkage used as template-argument
    X&lt;int(*)[sz]&gt; x5;            // OK: since the name of typedef int
                                 // (*pname)[sz] would have linkage
  }
</PRE>
--end example] [Note: a template type argument may be an incomplete type
(3.9&nbsp;



 <A HREF="basic.html#basic.types">basic.types</A>).]
</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="338"></A>
<H4>338.
  
Enumerator name with linkage used as class name in other translation unit
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2<BR>



<P>From messages 9480, 9481, 9483, 9485, 9486.</P>


<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="28"></A>
<H4>28.
  
'exit', 'signal' and static object destruction
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>O'Riordan<BR>



<P>From reflector message core-7686.</P>


<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>(Also see reflector messages 7687 7688 7689 7691)</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="312"></A>
<H4>312.
  
"use" of invalid pointer value not defined
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2<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="348"></A>
<H4>348.
  
<TT>delete</TT> and user-written deallocation functions
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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>Ruslan Abdikeev
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>1 April 2002<BR>


<P>Standard is clear on behaviour of default allocation/deallocation
functions.
However, it is surpisingly vague on requirements to the behaviour
of user-defined deallocation function and an interaction between
delete-expression and deallocation function.
This caused a heated argument on fido7.su.c-cpp newsgroup.</P>

<P>Resume:</P>

<P>It is not clear if user-supplied deallocation function is called from
delete-expr when the operand of delete-expr is the null
pointer (5.3.5&nbsp;



 <A HREF="expr.html#expr.delete">expr.delete</A>).
If it is, standard does not specify what user-supplied
deallocation function shall do with
the null pointer operand (18.4.1&nbsp;



 <A HREF="lib-support.html#lib.new.delete">lib.new.delete</A>).
Instead, Standard uses the term "has no effect", which meaning
is too vague in context given (5.3.5&nbsp;



 <A HREF="expr.html#expr.delete">expr.delete</A>).</P>

<P>Description:</P>

<P>Consider statements
<PRE>
   char* p= 0; //result of failed non-throwing ::new char[]
   ::delete[] p;
</PRE>
Argument passed to delete-expression is valid - it is the result
of a call to the non-throwing version of ::new, which has been failed.
5.3.5&nbsp;



 <A HREF="expr.html#expr.delete">expr.delete</A> paragraph 1 explicitly prohibit us to pass 0
without having the ::new failure.</P>

<P>Standard does NOT specify whether user-defined deallocation function
should be called in this case, or not.</P>

<P>Specifically, standard says in 5.3.5&nbsp;



 <A HREF="expr.html#expr.delete">expr.delete</A> paragraph 2:
<BLOCKQUOTE>
   ...if the value of the operand of delete is the null pointer the operation
   has no effect.
</BLOCKQUOTE>
Standard doesn't specify term "has no effect".
It is not clear from this context, whether the called deallocation function
is required to have no effect, or delete-expression shall not call
the deallocation function.</P>
<P>Furthermore, in para 4 standard says on default deallocation function:
<BLOCKQUOTE>
   If the delete-expression calls the implementation deallocation
   function (3.7.3.2&nbsp;



 <A HREF="basic.html#basic.stc.dynamic.deallocation">basic.stc.dynamic.deallocation</A>),
   if the operand of the delete expression is not
   the null pointer constant, ...
</BLOCKQUOTE>
Why it is so specific on interaction of default deallocation function
and delete-expr?</P>

<P>If "has no effect" is a requirement to the deallocation function,
then it should be stated in 3.7.3.2&nbsp;



 <A HREF="basic.html#basic.stc.dynamic.deallocation">basic.stc.dynamic.deallocation</A>,
or in 18.4.1.1&nbsp;



 <A HREF="lib-support.html#lib.new.delete.single">lib.new.delete.single</A> and
18.4.1.2&nbsp;



 <A HREF="lib-support.html#lib.new.delete.array">lib.new.delete.array</A>,
and it should be stated explicitly.</P>

<P>Furthermore, standard does NOT specify what actions shall
be performed by user-supplied deallocation function if NULL
is given (18.4.1.1&nbsp;



 <A HREF="lib-support.html#lib.new.delete.single">lib.new.delete.single</A> paragraph 12):</P>
<BLOCKQUOTE>
   Required behaviour: accept a value of ptr that is null or that was
   returned by an earlier call to the default
<TT>operator new(std::size_t)</TT>
   or <TT>operator new(std::size_t, const std::nothrow_t&amp;)</TT>.
</BLOCKQUOTE>

<P>The same corresponds to ::delete[] case.</P>

<P>Expected solution:</P>

<OL>
<LI>
Make it clear that delete-expr will not call deallocation function
if null pointer is given (in 5.3.5&nbsp;



 <A HREF="expr.html#expr.delete">expr.delete</A>).
</LI>
<LI>
Specify what user deallocation function shall do when null is given
(either in 3.7.3.2&nbsp;



 <A HREF="basic.html#basic.stc.dynamic.deallocation">basic.stc.dynamic.deallocation</A>, or
in 18.4.1.1&nbsp;



 <A HREF="lib-support.html#lib.new.delete.single">lib.new.delete.single</A>, and
18.4.1.2&nbsp;



 <A HREF="lib-support.html#lib.new.delete.array">lib.new.delete.array</A>).
</LI>
</OL>
<BR>
<BR>
<HR>
<A NAME="290"></A>
<H4>290.
  
Should memcpy be allowed into a POD with a const member?
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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>Garry Lancaster
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>12 Jun 2001
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2<BR>


<P>Following the definition in 9&nbsp;



 <A HREF="class.html#class">class</A> paragraph 4
the following is a valid POD (actually a POD-struct):</P>

<PRE>
    struct test
    {
        const int i;
    };
</PRE>

<P>The legality of PODs with const members is also implied by the text of
5.3.4&nbsp;



 <A HREF="expr.html#expr.new">expr.new</A> paragraph 15 bullet 1, sub-bullet 2 and
12.6.2&nbsp;



 <A HREF="special.html#class.base.init">class.base.init</A> paragraph 4 bullet 2.</P>

<P>3.9&nbsp;



 <A HREF="basic.html#basic.types">basic.types</A> paragraph 3 states that</P>

<BLOCKQUOTE>
For any POD type
<TT>T</TT>, if two pointers to <TT>T</TT> point to distinct objects
<TT>obj1</TT> and <TT>obj2</TT>, if the value of <TT>obj1</TT> is copied
into <TT>obj2</TT>, using the <TT>memcpy</TT> library function, <TT>obj2</TT>
shall subsequently hold the same value as <TT>obj1</TT>.
</BLOCKQUOTE>

<P>
<I>[Note: this text was changed by TC1, but the essential point
stays the same.]</I>
</P>

<P>This implies that the following is required to work:</P>

<PRE>
    test obj1 = { 1 };
    test obj2 = { 2 };
    memcpy( &amp;obj2, &amp;obj1, sizeof(test) );
</PRE>

<P>The memcpy of course changes the value of the const member, surely
something that shouldn't be allowed.</P>

<P>
<B>Suggested resolution:</B>
</P>

<P>It is recommended that 3.9&nbsp;



 <A HREF="basic.html#basic.types">basic.types</A> paragraph 3 be
reworded to exclude PODs which contain (directly or indirectly) members
of const-qualified type.</P>

<BR>
<BR>
<HR>
<A NAME="350"></A>
<H4>350.
  
<TT>signed char</TT> underlying representation for objects
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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>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>

<BR>
<BR>
<HR>
<A NAME="146"></A>
<H4>146.
  
Floating-point zero
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>3<BR>




<P>From reflector message 8234.</P>


<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>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>3<BR>


<P>From messages 8932-3 and 8936-7.</P>

<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="240"></A>
<H4>240.
  
Uninitialized values and undefined behavior
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2<BR>


<P>From messages 8866, 8869-71, 8875-6,
8878, and 8886-7.</P>

<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>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>3<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="170"></A>
<H4>170.
  
Pointer-to-member conversions
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>4.11&nbsp;



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

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

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

 <B>Date: </B>16 Sep 1999
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Nelson<BR>




<P>From reflector messages 8324 and 8343.</P>


<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="238"></A>
<H4>238.
  
Precision and accuracy constraints on floating point
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>3<BR>


<P>From messages 8833, 8835-6, 8838-9,
8844, 8846, 8849, 8851-3, and 8856-62.</P>

<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="351"></A>
<H4>351.
  
Sequence point error: unspecified or undefined?
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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>Andrew Koenig
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>23 April 2002<BR>



<P>From message 9526.</P>


<P>I have found what looks like a bug in clause 5&nbsp;



 <A HREF="expr.html#expr">expr</A>,
paragraph 4:</P>
<BLOCKQUOTE>
   Between the previous and next sequence point a scalar object shall
   have its stored value modified at most once by the evaluation of an
   expression.  Furthermore, the prior value shall be accessed only to
   determine the value to be stored.  The requirements of this
   paragraph shall be met for each allowable ordering of the
   subexpressions of a full expression; otherwise the behavior is
   undefined.  Example:
<PRE>
        i = v[i++];                     // the behavior is unspecified
        i = 7, i++, i++;                // i becomes 9

        i = ++i + 1;                    // the behavior is unspecified
        i = i + 1;                      // the value of i is incremented
</PRE>
   --end example]
</BLOCKQUOTE>

<P>So which is it, unspecified or undefined?</P>

<BR>
<BR>
<HR>
<A NAME="282"></A>
<H4>282.
  
Namespace for <TT>extended_type_info</TT>
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>3<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="195"></A>
<H4>195.
  
Converting between function and object pointers
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>5.2.10&nbsp;



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

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

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

 <B>Date: </B>12 Jan 2000
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Salters<BR>




<P>From reflector messages 8439-86 (!).</P>


<P>It is currently not permitted to cast directly between a pointer to
function type and a pointer to object type.  This conversion is not
listed in 5.2.9&nbsp;



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



 <A HREF="expr.html#expr.reinterpret.cast">expr.reinterpret.cast</A>
 and thus
requires a diagnostic to be issued.  However, if a sufficiently long
integral type exists (as is the case in many implementations), it is
permitted to cast between pointer to function types and pointer to
object types using that integral type as an intermediary.</P>

<P>In C the cast results in undefined behavior and thus does not
require a diagnostic, and Unix C compilers generally do not issue
one.  This fact is used in the definition of the standard Unix
function <TT>dlsym</TT>, which is declared to return <TT>void*</TT>
but in fact may return either a pointer to a function or a pointer to
an object.  The fact that C++ compilers are required to issue a
diagnostic is viewed as a "competitive disadvantage" for the language.</P>

<P>
<B>Suggested resolution:</B> Add wording to
5.2.10&nbsp;



 <A HREF="expr.html#expr.reinterpret.cast">expr.reinterpret.cast</A>
 allowing
conversions between pointer to function and pointer to object types,
if the implementation has an integral data type that can be used as an
intermediary.</P>

<P>Several points were raised in opposition to this suggestion:</P>

<BR>
<OL>
<LI>Early C++ supported this conversion and it was deliberately
removed during the standardization process.</LI>

<LI>The existence of an appropriate integral type is irrelevant to
whether the conversion is "safe."  The condition should be on whether
information is lost in the conversion or not.</LI>

<LI>There are numerous ways to address the problem at an
implementation level rather than changing the language.  For example,
the compiler could recognize the specific case of <TT>dlsym</TT> and
omit the diagnostic, or the C++ binding to <TT>dlsym</TT> could be
changed (using templates, for instance) to circumvent the violation.</LI>

<LI>The conversion is, in fact, not supported by C; the <TT>dlsym</TT>
function is simply relying on non-mandated characteristics of C
implementations, and we would be going beyond the requirements of C
compatibility in requiring (some) implementations to support the
conversion.</LI>

<LI>This issue is in fact not a defect (omitted or self-contradictory
requirements) in the current Standard; the proposed change would
actually be an extension and should not be considered until the full
review of the IS.</LI>

<LI>
<TT>dlsym</TT> appears not to be used very widely, and the
declaration in the header file is not problematic, only calls to it.
Since C code generally requires some porting to be valid C++ anyway,
this should be considered one of those items that requires porting.</LI>

</OL>

<P>Martin O'Riordan suggested an alternative approach:</P>

<BR>
<UL>
<LI>Do not allow the conversions to be performed via old-style casts.</LI>

<LI>Allow <TT>reinterpret_cast</TT> to perform the conversions with
the C-style semantics (undefined behavior if not supported).</LI>

<LI>Allow <TT>dynamic_cast</TT> to perform the conversions with
well-defined behavior: the result would be a null pointer if the
implementation could not support the requested conversion.</LI>
</UL>

<P>The advantage of this approach is that it would permit writing
portable, well-defined programs involving such conversions.  However,
it breaks the current degree of compatibility between old and new
casts, and it adds functionality to <TT>dynamic_cast</TT> which is not
obviously related to its current meaning.</P>

<P>
<U>Notes from 04/00 meeting:</U>
</P>

<P>Andrew Koenig suggested yet another approach: specify that "no
diagnostic is required" if the implementation supports the conversion.</P>

<P>
<B>Later note:</B>
</P>

<P>It was observed that conversion between function and data pointers
is listed as a "common extension" in C99.  This
discussion occurred on the -ext reflector in messages 3905-16,
3919-21, 3929-33, 3935, and 3937-8.  The thread may not be complete
at the time of this writing, so additional messages may exist on
this topic.  There appeared to be a solid, if not unanimous,
consensus behind Andy's suggestion about relaxing the requirement
for a diagnostic.</P>

<P>
<B>Notes on the 10/01 meeting:</B>
</P>

<P>It was decided that we want the conversion defined in such a way that
it always exists but is always undefined (as opposed to existing only
when the size relationship is appropriate, and being implementation-defined
in that case).  This would allow an implementation to issue an error
at compile time if the conversion does not make sense.</P>

<P>Bill Gibbons notes that the definitions of the other similar casts are
inconsistent in this regard.  Perhaps they should be updated as well.</P>

<BR>
<BR>
<HR>
<A NAME="342"></A>
<H4>342.
  
Terminology: "indirection" versus "dereference"
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>3<BR>



<P>From message 9324.</P>


<P>Split off from <A HREF="
     cwg_active.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>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>3<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="232"></A>
<H4>232.
  
Is indirection through a null pointer undefined behavior?
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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>Mike Miller
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>5 Jun 2000
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2<BR>


<P>See messages 8740-61.</P>

<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>

<BR>
<BR>
<HR>
<A NAME="267"></A>
<H4>267.
  
Alignment requirement for <I>new-expression</I>s
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>3<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>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>3<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="299"></A>
<H4>299.
  
Conversion on array bound expression in <TT>new</TT>
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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>Mark Mitchell
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>19 Jul 2001
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2<BR>


<P>From message 9257.</P>

<P>In 5.3.4&nbsp;



 <A HREF="expr.html#expr.new">expr.new</A>, the standard says that the
expression in an array-new has to 
have integral type.  There's already a DR (<A HREF="
     cwg_defects.html#74">issue 74</A>)
that says it should also be allowed to have enumeration type.  But, it should
probably also say that it can have a class type with a single
conversion to integral type; in other words the same thing as in
6.4.2&nbsp;



 <A HREF="stmt.html#stmt.switch">stmt.switch</A> paragraph 2.</P>

<P>
<B>Suggested resolution:</B>
</P>

<P>In 5.3.4&nbsp;



 <A HREF="expr.html#expr.new">expr.new</A> paragraph 6, replace
"integral or enumeration type (3.9.1&nbsp;



 <A HREF="basic.html#basic.fundamental">basic.fundamental</A>)" with
"integral or enumeration type (3.9.1&nbsp;



 <A HREF="basic.html#basic.fundamental">basic.fundamental</A>), or a class
type for which a single conversion function to
integral or enumeration type exists".</P>

<BR>
<BR>
<HR>
<A NAME="313"></A>
<H4>313.
  
Class with single conversion function to integral as array size in <TT>new</TT>
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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>Bill Gibbons
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>22 Oct 2001
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2<BR>


<P>Should it be allowed to use an object of a class type having a single
conversion function to an integral type as an array size in the first
bound of the type in an array new?</P>

<PRE>
  struct A {
    operator int();
  } a;
  int main () {
    new int[a];
  }
</PRE>

<P>There are similar accommodations
for the expression in a <TT>delete</TT> (5.3.5&nbsp;



 <A HREF="expr.html#expr.delete">expr.delete</A>
paragraph 1) and in a <TT>switch</TT> (6.4.2&nbsp;



 <A HREF="stmt.html#stmt.switch">stmt.switch</A>
paragraph 2).  There is also widespread existing practice on this
(g++, EDG, MSVC++, and Sun accept it, and even cfront 3.0.2).</P>

<BR>
<BR>
<HR>
<A NAME="196"></A>
<H4>196.
  
Arguments to deallocation functions
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>3<BR>




<P>From reflector messages 8487, 8490-99.</P>


<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>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2<BR>


<P>From message 8988.</P>

<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>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2<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="353"></A>
<H4>353.
  
Is deallocation routine called if destructor throws exception in delete?
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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>Duane Smith
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>30 April 2002<BR>


<P>In a couple of comp.std.c++ threads, people have asked
whether the Standard guarantees that the deallocation function
will be called in a delete-expression if the destructor throws
an exception.  Most/all people have expressed the opinion that 
the deallocation function must be called in this case, although 
no one has been able to cite wording in the Standard supporting 
that view.</P>

<PRE>
#include &lt;new.h&gt;
#include &lt;stdio.h&gt;
#include &lt;stdlib.h&gt;

static int flag = 0;

inline 
void operator delete(void* p) throw() 
{
   if (flag)
        printf("in deallocation function\n");
   free(p);
}

struct S {
    ~S() { throw 0; }
};

void f() {
    try {
        delete new S;
    }
    catch(...) { }
}

int main() {
       flag=1;
       f();
       flag=0;
       return 0;
}
</PRE>

<BR>
<BR>
<HR>
<A NAME="242"></A>
<H4>242.
  
Interpretation of old-style casts
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>3<BR>


<P>From message 8888.</P>

<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>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>3<BR>


<P>From messages 8816-19.</P>

<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>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>1<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>

<BR>
<BR>
<HR>
<A NAME="276"></A>
<H4>276.
  
Order of destruction of parameters and temporaries
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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>James Kanze
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>28 Mar 2001
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Adamczyk<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."  Steve Adamczyk
will investigate.</P>

<BR>
<BR>
<HR>
<A NAME="157"></A>
<H4>157.
  
Omitted typedef declarator
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>3<BR>




<P>From reflector messages 8275-80, 8272-3.</P>


<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="317"></A>
<H4>317.
  
Can a function be declared inline after it has been called?
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>7.1.2&nbsp;



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

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

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

 <B>Date: </B>14 Oct 2001
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2<BR>



<P>From messages 9338-9342.</P>


<P>
<U>Steve Clamage</U>:
Consider this sequence of declarations:
<PRE>
  void foo() { ... }
  inline void foo();
</PRE>
The non-inline definition of foo precedes the inline declaration.
It seems to me this code should be ill-formed, but I could not find
anything in the standard to cover the situation.</P>

<P>
<U>Bjarne Stroustrup</U>:
Neither could I, so I looked in the ARM, which addressed this case (apparently 
for member function only) in some detail in 7.1.2 (pp103-104).</P>

<P>The ARM allows declaring a function inline after its initial declaration,
as long as it has not been called.</P>

<P>
<U>Steve Clamage</U>:
If the above code is valid, how about this:</P>
<PRE>
  void foo() { ... }    // define foo
  void bar() { foo(); } // use foo
  inline void foo();    // declare foo inline
</PRE>

<P>
<U>Bjarne Stroustrup</U>:
... and [the ARM] disallows declaring a function inline after it
has been called.</P>

<P>This may still be a good resolution.</P>

<P>
<U>Steve Clamage</U>:
But the situation in the ARM is the reverse:  Declare a function
inline, and define it later (with no intervening call).  That's
a long-standing rule in C++, and allows you to write member
function definitions outside the class.</P>

<P>In my example, the compiler could reasonably process the entire
function as out-of-line, and not discover the inline declaration
until it was too late to save the information necessary for inline
generation.  The equivalent of another compiler pass would be needed
to handle this situation.</P>

<P>
<U>Bjarne Stroustrup</U>:
I see, and I think your argument it conclusive.</P>

<P>
<U>Steve Clamage</U>:
I'd like to open a core issue on this point, and I recommend wording
along the lines of:  "A function defined without an inline specifier
shall not be followed by a declaration having an inline specifier."</P>

<P>I'd still like to allow the common idiom</P>
<PRE>
  class T {
    int f();
  };
  inline int T::f() { ... }
</PRE>

<P>
<U>Martin Sebor</U>:
Since the inline keyword is just a hint to the compiler, I don't see
any harm in allowing the construct. Your hypothetical compiler can
simply ignore the inline on the second declaration. On the other hand,
I feel that adding another special rule will unnecessarily complicate
the language.</P>

<P>
<U>Steve Clamage</U>:
The inline specifier is more than a hint.  You can have multiple
definitions of inline functions, but only one definition of a
function not declared inline.  In particular, suppose the above
example were in a header file, and included multiple times in
a program.</P>

<BR>
<BR>
<HR>
<A NAME="144"></A>
<H4>144.
  
Position of <TT>friend</TT> specifier
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>3<BR>




<P>From reflector message 8232.</P>


<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="311"></A>
<H4>311.
  
Using qualified name to reopen nested namespace
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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>Bjarne Stroustrup
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>18 Sep 2001
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2<BR>



<P>From messages 9309, 9312, 9313, 9315.</P>


<P>I received an inquiry/complaint that you cannot re-open a namespace using a 
qualified name. For example, the following program is ok, but if you uncomment 
the commented lines you get an error:</P>
<PRE>
namespace A {
    namespace N {
	int a;
    }
    int b;
    namespace M {
	int c;
    }
}

//namespace A::N {
//    int d;
//}

namespace A {
    namespace M {
        int e;
    }
}

int main()
{
    A::N::a = 1;
    A::b = 2;
    A::M::c = 3;
//  A::N::d = 4;
    A::M::e = 5;
}
</PRE>

<P>
<U>Andrew Koenig</U>:
There's a name lookup issue lurking here.  For example:</P>
<PRE>
    int x;

    namespace A {
	int x;
	namespace N {
	   int y;
	};
    }

    namespace A::N {
        int* y = &amp;x;  // which x?
    }
</PRE>

<P>
<U>Jonathan Caves</U>:
I would assume that any rule would state that:
<PRE>
namespace A::B {
</PRE>
would be equivalent to:
<PRE>
namespace A {
   namespace B {
</PRE>
so in your example 'x' would resolve to A::x</P>

<P>BTW: we have received lots of bug reports about this "oversight".</P>

<P>
<U>Lawrence Crowl</U>:
Even worse is
<PRE>
    int x;
    namespace A {
      int x;
    }
    namespace B {
      int x;
      namespace ::A {
         int* y = &amp;x;
      }
    }
</PRE>
I really don't think that the benefits of qualied names here is worth
the cost.</P>

<BR>
<BR>
<HR>
<A NAME="36"></A>
<H4>36.
  
<I>using-declaration</I>s in multiple-declaration contexts
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>3<BR>




<P>From reflector message core-7811.</P>


<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.  Because of its small potential impact
on code, it was given priority 3.</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>
<BR>
<BR>
<HR>
<A NAME="332"></A>
<H4>332.
  
cv-qualified <TT>void</TT> parameter types
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>3<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="325"></A>
<H4>325.
  
When are default arguments parsed?
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2<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 T&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>

<BR>
<BR>
<HR>
<A NAME="155"></A>
<H4>155.
  
Brace initializer for scalar
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>3<BR>




<P>From reflector messages 8265-6.</P>


<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>


<P>
<B>Notes from 10/00 meeting:</B> Priority lowered to 3.</P>

<BR>
<BR>
<HR>
<A NAME="253"></A>
<H4>253.
  
Why must empty or fully-initialized const objects be initialized?
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>3<BR>


<P>From messages 8804-8806.</P>

<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="233"></A>
<H4>233.
  
References vs pointers in UDC overload resolution
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>8.5.3&nbsp;



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

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

 <B>Submitter: </B>Matthias Meixner
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>9 Jun 2000
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Adamczyk<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="291"></A>
<H4>291.
  
Overload resolution needed when binding reference to class rvalue
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>8.5.3&nbsp;



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

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

 <B>Submitter: </B>Andrei Iltchenko
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>15 Jun 2001
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2<BR>


<P>There is a place in the Standard where overload resolution is implied
but the way that a set of candidate functions is to be formed is
omitted. See below.</P>

<P>According to the Standard, when initializing a reference to a
non-volatile const class type (<I>cv1</I> <TT>T1</TT>) with an rvalue
expression (<I>cv2</I> <TT>T2</TT>) where <I>cv1</I> <TT>T1</TT> is
reference compatible with <I>cv2</I> <TT>T2</TT>, the implementation
shall proceed in one of the following
ways (except when initializing the implicit object parameter of a
copy constructor) 8.5.3&nbsp;



 <A HREF="decl.html#dcl.init.ref">dcl.init.ref</A> paragraph 5 bullet 2
sub-bullet 1:</P>

<UL>
<LI>
The reference is bound to the object represented by the rvalue (see
3.10&nbsp;



 <A HREF="basic.html#basic.lval">basic.lval</A>) or to a sub-object within that object.
</LI>
<LI>
A temporary of type "<I>cv1</I> <TT>T2</TT>" [sic] is created, and a
constructor is called to copy the entire rvalue object into the temporary...
</LI>
</UL>

<P>While the first case is quite obvious, the second one is a bit unclear
as it says "a constructor is called to copy the entire rvalue object
into the temporary" without specifying how the temporary is created --
by direct-initialization or by copy-initialization? As stated in DR
152, this can make a difference when the copy constructor is declared
as explicit. How should the set of candidate functions be formed? The
most appropriate guess is that it shall proceed as per
13.3.1.3&nbsp;



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

<P>Another detail worth of note is that in the draft version of the
Standard as of 2 December 1996 the second bullet read:</P>

<UL>
<LI>
A temporary of type "<I>cv1</I> <TT>T2</TT>" [sic] is created, and a copy
constructor is called to copy the entire rvalue object into the
temporary...
</LI>
</UL>

<P>J. Stephen Adamczyk replied that the reason for changing "a copy
constructor" to "a constructor" was to allow for member template
converting constructors.</P>

<P>However, the new wording is somewhat in conflict with the footnote #93
that says that when initializing the implicit object parameter of a
copy constructor an implementation must eventually choose the first
alternative (binding without copying) to avoid infinite recursion.
This seems to suggest that a copy constructor is always used for
initializing the temporary of type "<I>cv1</I> <TT>T2</TT>".</P>

<P>Furthermore, now that the set of candidate functions is not limited to
only the copy constructors of <TT>T2</TT>, there might be some unpleasant
consequences.
Consider a rather contrived sample below:</P>

<PRE>
    int   * pi = ::new(std::nothrow) int;
    const std::auto_ptr&lt;int&gt;   &amp; ri = std::auto_ptr&lt;int&gt;(pi);
</PRE>

<P>In this example the initialization of the temporary of type
'<TT>&lt;TT&gt;const std::auto_ptr&lt;int&gt;</TT>'
(to which '<TT>ri</TT>' is meant to be subsequently bound)
doesn't fail, as it would had the approach with copy constructors been
retained, instead, a yet another temporary gets created as the
well-known sequence:</P>
<PRE>
    std::auto_ptr&lt;int&gt;::operator std::auto_ptr_ref&lt;int&gt;()
    std::auto_ptr&lt;int&gt;(std::auto_ptr_ref&lt;int&gt;)
</PRE>
<P>is called (assuming, of course, that the set of candidate functions is
formed as per 13.3.1.3&nbsp;



 <A HREF="over.html#over.match.ctor">over.match.ctor</A>). The second temporary
is transient and gets
destroyed at the end of the initialization. I doubt that this is the
way that the committee wanted this kind of reference binding to go.</P>

<P>Besides, even if the approach restricting the set of candidates to copy
constructors is restored, it is still not clear how the initialization
of the temporary (to which the reference is intended to be bound) is
to be performed -- using direct-initialization or copy-initialization.</P>

<P>Another place in the Standard that would benefit from a similar
clarification is the creation of an exception object, which is
delineated in 15.1&nbsp;



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

<BR>
<BR>
<HR>
<A NAME="327"></A>
<H4>327.
  
Use of "structure" without definition
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>3<BR>



<P>From message 9419.</P>

<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="315"></A>
<H4>315.
  
Is call of static member function through null pointer undefined?
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>9.4.1&nbsp;



 <A HREF="class.html#class.static.mfct">class.static.mfct</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
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2<BR>



<P>From message 9324.</P>


<P>Another instance to consider is that of invoking a member function from a
null pointer:</P>
<PRE>
  struct A { void f () { } };
  int main ()
  {
    A* ap = 0;
    ap-&gt;f ();
  }
</PRE>
<P>Which is explicitly noted as undefined in 9.3.1&nbsp;



 <A HREF="class.html#class.mfct.nonstatic">class.mfct.nonstatic</A>,
even though one could argue that since <TT>f()</TT> is empty, there is no
lvalue-&gt;rvalue conversion.</P>

<P>If <TT>f</TT> is static, however, there seems to be no such rule, and
the call is only undefined if the dereference implicit in the <TT>-&gt;</TT>
operator is undefined.  IMO it should be.</P>

<P>Incidentally, another thing that ought to be cleaned up is the inconsistent
use of "indirection" and "dereference".  We should pick one. <I>(This
terminology issue has been broken out as
<A HREF="
     cwg_active.html#342">issue 342</A>.)</I>
</P>

<P>This is related to <A HREF="
     cwg_active.html#232">issue 232</A>
</P>

<BR>
<BR>
<HR>
<A NAME="57"></A>
<H4>57.
  
Empty unions
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>3<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="58"></A>
<H4>58.
  
Signedness of bit fields of enum type
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>9.6&nbsp;



 <A HREF="class.html#class.bit">class.bit</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
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>3<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_active.html#172">issue 172</A>.)</P>

<P>
<B>Notes from 10/00 meeting:</B> Priority lowered
to 3.</P>
<BR>
<BR>
<HR>
<A NAME="347"></A>
<H4>347.
  
Use of derived class name in defining base class nested class
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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>From message 9494.</P>


<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="230"></A>
<H4>230.
  
Calls to pure virtual functions
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>3<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="331"></A>
<H4>331.
  
Allowed copy constructor signatures
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>12.1&nbsp;



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

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

 <B>Submitter: </B>Richard Smith
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>8 Jan 2002
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>1<BR>


<P>12.1&nbsp;



 <A HREF="special.html#class.ctor">class.ctor</A> paragraph 10 states</P>
<BLOCKQUOTE>
A copy constructor for a class X is a constructor with a
first parameter of type X &amp; or of type const X &amp;.  [Note:
see 12.8&nbsp;



 <A HREF="special.html#class.copy">class.copy</A> for more information on copy constructors.]
</BLOCKQUOTE>

<P>No mention is made of constructors with first parameters of types
volatile X &amp; or const volatile X &amp;.  This statement seems to be
in contradiction with 12.8&nbsp;



 <A HREF="special.html#class.copy">class.copy</A> paragraph 2 which states</P>
<BLOCKQUOTE>
A non-template constructor for class X is a copy constructor
if its first parameter is of type X &amp;, const X &amp;, volatile X &amp;
or const volatile X &amp;, ...
</BLOCKQUOTE>

<P>12.8&nbsp;



 <A HREF="special.html#class.copy">class.copy</A> paragraph 5 also mentions the volatile
versions of the
copy constructor, and the comparable paragraphs for copy assignment
(12.8&nbsp;



 <A HREF="special.html#class.copy">class.copy</A> paragraphs 9 and 10) all allow volatile
versions, so it seems that 12.1&nbsp;



 <A HREF="special.html#class.ctor">class.ctor</A> is at fault.</P>

<P>
<B>Suggested resolution:</B>
</P>

<P>Change the wording of 12.1&nbsp;



 <A HREF="special.html#class.ctor">class.ctor</A> paragraph 10 to</P>
<BLOCKQUOTE>
A copy constructor for a class <TT>X</TT> is a constructor with a
first parameter of type <TT>X</TT> &amp;,
const <TT>X</TT> &amp;, volatile <TT>X</TT> &amp; or
const volatile <TT>X</TT> &amp;.  [Note: see 12.8&nbsp;



 <A HREF="special.html#class.copy">class.copy</A>
for more information on copy constructors.]
</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="199"></A>
<H4>199.
  
Order of destruction of temporaries
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>3<BR>




<P>From reflector messages 8505-6, 8508, 8510, and 8515.</P>


<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="320"></A>
<H4>320.
  
Question on copy constructor elision example
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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>Steve Clamage
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>2 Nov 2001
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2<BR>


<P>Section 12.2&nbsp;



 <A HREF="special.html#class.temporary">class.temporary</A> paragraph 2, abridged:</P>
<BLOCKQUOTE>
<PRE>
  X f(X);
  void g()
  {
	X a;
	a = f(a);
  }
</PRE>
<P>
<TT>a=f(a)</TT> requires a temporary for either the argument <TT>a</TT>
or the result of <TT>f(a)</TT> to avoid undesired aliasing of <TT>a</TT>.
</P>
</BLOCKQUOTE>

<P>The note seems to imply that an implementation is allowed to omit
copying "a" to f's formal argument, or to omit using a temporary for
the return value of f.  I don't find that license in normative text.</P>

<P>Function f returns an X by value, and in the expression the value is
assigned (not copy-constructed) to "a".  I don't see how that
temporary can be omitted.  (See also 12.8&nbsp;



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

<P>Since "a" is an lvalue and not a temporary, I don't see how copying
"a" to f's formal parameter can be avoided.</P>

<P>Am I missing something, or is 12.2&nbsp;



 <A HREF="special.html#class.temporary">class.temporary</A> p 2 misleading?</P>

<BR>
<BR>
<HR>
<A NAME="344"></A>
<H4>344.
  
Naming destructors
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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_active.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>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>3<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="257"></A>
<H4>257.
  
Abstract base constructors and virtual base initialization
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>3<BR>


<P>From messages 8946 and 8948.</P>

<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>

<BR>
<BR>
<HR>
<A NAME="111"></A>
<H4>111.
  
Copy constructors and cv-qualifiers
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>3<BR>




<P>From reflector messages 8038-8040.</P>


<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="260"></A>
<H4>260.
  
User-defined conversions and built-in <TT>operator=</TT>
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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>Scott Douglas
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>4 Nov 2000
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Adamczyk<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).
Steve Adamczyk will investigate.</P>

<BR>
<BR>
<HR>
<A NAME="110"></A>
<H4>110.
  
Can template functions and classes be declared in the same scope?
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>3<BR>



<P>From reflector messages 8025-8031.</P>


<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="96"></A>
<H4>96.
  
Syntactic disambiguation using the <TT>template</TT> keyword
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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>John Spicer
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>16 Feb 1999
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>1
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Spicer<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_closed.html#11">11</A> and <A HREF="
     cwg_closed.html#109">109</A>.

John Spicer will revise his paper and proposal in light of the
discussion.

</P>

<BR>
<BR>
<HR>
<A NAME="343"></A>
<H4>343.
  
Make <TT>template</TT> optional in contexts that require a type
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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 optionsl 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="354"></A>
<H4>354.
  
Null as nontype template argument
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>14.3.2&nbsp;



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

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

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

 <B>Date: </B>2 May 2002<BR>



<P>From messages 9527-9528.</P>


<P>The standard does not permit a null value to be used as a nontype template
argument for a nontype template parameter that is a pointer.</P>

<P>This code is accepted by EDG, Microsoft, Borland and Cfront, but rejected
by g++ and Sun:</P>
<PRE>
  template &lt;int *p&gt; struct A {};
  A&lt;(int*)0&gt; ai;
</PRE>
<P>I'm not sure this was ever explicitly considered by the committee.
Is there any reason to permit this kind of usage?</P>

<P>
<U>Jason Merrill</U>:
I suppose it might be useful for a program to be able to express a
degenerate case using a null template argument.  I think allowing it would
be harmless.</P>

<BR>
<BR>
<HR>
<A NAME="329"></A>
<H4>329.
  
Evaluation of friends of templates
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>14.5.3&nbsp;



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

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

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

 <B>Date: </B>19 Dec 2001
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>1<BR>


<P>14.5.3&nbsp;



 <A HREF="template.html#temp.friend">temp.friend</A> paragraph 5 says:</P>
<BLOCKQUOTE>
When a function is defined in a friend function declaration in a class
template, the function is defined at each instantiation of  the  class
template.  The function is defined even if it is never used.  The same
restrictions on multiple declarations and definitions which  apply  to
non-template function declarations and definitions also apply to these
implicit definitions.  [Note: if the function definition is ill-formed
for  a  given specialization of the enclosing class template, the program
is ill-formed even if the function is never used.  ]
</BLOCKQUOTE>

<P>This means that the following program is invalid, even without the call
of <TT>f(ai)</TT>:</P>
<PRE>
  template &lt;class T&gt; struct A {
    friend void f(A a) {
      g(a);
    }
  };
  int main()
  {
    A&lt;int&gt; ai;
  // f(ai);  // Error if f(ai) is actually called
  }
</PRE>
<P>The EDG front end issues an error on this case even if <TT>f(ai)</TT>
is never
called.  Of the compilers I tried (g++, Sun, Microsoft, Borland) we
are the only ones to issue such an error.</P>

<P>This issue came up because there is a library that either deliberately or
accidentally makes use of friend functions that are not valid for certain
instantiations.</P>

<P>The wording in the standard is the result of a deliberate decision made
long ago, but given the fact that most implementations do otherwise it
raises the issue of whether we did the right thing.</P>

<P>Upon further investigation, the current rule was adopted as the resolution
to issue 6.47 in my series of template issue papers.  At the time the
issue was discussed (7/96) most compilers did evaluate such friends.
So it seems that a number of compilers have changed their behavior
since then.</P>

<P>Based on current practice, I think the standard should be changed to
evaluate such friends only when used.</P>

<BR>
<BR>
<HR>
<A NAME="229"></A>
<H4>229.
  
Partial specialization of function templates
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>14.5.4&nbsp;



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

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

 <B>Submitter: </B>Dave Abrahams
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>1 Apr 2000
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2<BR>


<P>Library issue 225 poses the following questions:</P>

<OL>

<LI>How can a 3rd party library implementor (lib1) write a version of
a standard algorithm which is specialized to work with his own class
template? </LI>

<LI>How can another library implementor (lib2) write a generic
algorithm which will take advantage of the specialized algorithm in
lib1?</LI>

</OL>

<P>For example, a programmer might want to provide a version of
<TT>std::swap</TT> that would be used for any specialization of a
particular class template.  It is possible to do that for specific
types, but not for all specializations of a template.</P>

<P>The problem is due to the fact that programmers are forbidden to
add overloads to namespace <TT>std</TT>, although specializations are
permitted.  One suggested solution would be to allow partial
specialization of function templates, analogous to partial
specialization of class templates.</P>

<P>Library issue 225 contains a detailed proposal for adding partial
specialization of function templates (not reproduced here in the
interest of space and avoiding multiple-copy problems).  This Core
issue is being opened to provide for discussion of the proposal within
the core language working group.</P>

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

<P>A major concern over the idea of partial specialization of
function templates is that function templates can be overloaded,
unlike class templates.  Simply naming the function template in
the specialization, as is done for class specialization, is not
adequate to identify the template being specialized.</P>

<P>In view of this problem, the library working group is exploring
the other alternative, permitting overloads to be added to functions
in namespace <TT>std</TT>, as long as certain restrictions (to be
determined) are satisfied.</P>

<P>(See also documents N1295 and N1296 and
<A HREF="
     cwg_closed.html#285">issue 285</A>.)</P>

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

<P> The Core Working Group decided to ask the Library Working Group
for guidance on whether this feature is still needed to resolve a
library issue.  The answer at present is "we don't know."</P>

<BR>
<BR>
<HR>
<A NAME="310"></A>
<H4>310.
  
Can function templates differing only in parameter cv-qualifiers be overloaded?
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2<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>
<zsection_ref>14.8.2.2&nbsp;



 <A HREF="template.html#temp.deduct.funcaddr">temp.deduct.funcaddr</A></zsection_ref>, 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>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>3<BR>




<P>(Previously numbered 934.)</P>


<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>John Spicer will propose a resolution, which may or may not require
a change to the standard.</P>


<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="214"></A>
<H4>214.
  
Partial ordering of function templates is underspecified
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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>Martin von Loewis/Martin Sebor
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>13 Mar 2000
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>1
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Spicer<BR>


<P>In 14.5.5.2&nbsp;



 <A HREF="template.html#temp.func.order">temp.func.order</A>, partial ordering is explained in
terms of template argument deduction. However, the exact procedure for
doing so is not specified. A number of details are missing, they are
explained as sub-issues below.</P>

<OL>

<LI>14.5.5.2&nbsp;



 <A HREF="template.html#temp.func.order">temp.func.order</A> paragraph 2 refers to
14.8.2&nbsp;



 <A HREF="template.html#temp.deduct">temp.deduct</A> for argument deduction. This is the
wrong reference; it explains how explicit arguments are processed
(paragraph 2) and how function parameter types are adjusted (paragraph
3). Neither of these steps is meaningful in the context of partial
ordering. Next in deduction follows one of the steps in 14.8.2.1&nbsp;



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



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



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



 <A HREF="template.html#temp.deduct.type">temp.deduct.type</A>. The standard
does not specify which of these contexts apply to partial
ordering. </LI>

<LI>Because 14.8.2.1&nbsp;



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



 <A HREF="template.html#temp.deduct.conv">temp.deduct.conv</A> both start with actual function parameters, it is
meaningful to assume that partial ordering uses 14.8.2.4&nbsp;



 <A HREF="template.html#temp.deduct.type">temp.deduct.type</A>, which only requires types. With that assumption,
the example in 14.5.5.2&nbsp;



 <A HREF="template.html#temp.func.order">temp.func.order</A> paragraph 5 becomes
incorrect, considering the two templates

<PRE>
    template&lt;class T&gt; void g(T);  // #1
    template&lt;class T&gt; void g(T&amp;); // #2
</PRE>

Here, #2 is at least as specialized as #1: With a synthetic type
<TT>U</TT>, #2 becomes <TT>g(U&amp;)</TT>; argument deduction against
#1 succeeds with <TT>T=U&amp;</TT>. However, #1 is not at least as
specialized as #2: Deducing <TT>g(U)</TT> against <TT>g(T&amp;)</TT>
fails. Therefore, the second template is more specialized than the
first, and the call <TT>g(x)</TT> is not ambiguous.</LI>

<LI>According to John Spicer, the intent of the partial ordering was
that it uses deduction as in a function call (14.8.2.1&nbsp;



 <A HREF="template.html#temp.deduct.call">temp.deduct.call</A>), which is indicated by the mentioning of "exact
match" in 14.5.5.2&nbsp;



 <A HREF="template.html#temp.func.order">temp.func.order</A> paragraph 4. If that is
indeed the intent, it should be specified how values are obtained for
the step in 14.8.2.1&nbsp;



 <A HREF="template.html#temp.deduct.call">temp.deduct.call</A> paragraph 1, where the
types of the arguments are determined. Also, since 14.8.2.1&nbsp;



 <A HREF="template.html#temp.deduct.call">temp.deduct.call</A> paragraph 2 drops references from the parameter
type, symmetrically, references should be dropped from the argument
type (which is done in 5&nbsp;



 <A HREF="expr.html#expr">expr</A> paragraph 2, for a true
function call).</LI>

<LI>14.5.5.2&nbsp;



 <A HREF="template.html#temp.func.order">temp.func.order</A> paragraph 4 requires an "exact
match" for the "deduced parameter types". It is not clear whether this
refers to the template parameters, or the parameters of the template
function. Considering the example

<PRE>
    template&lt;class S&gt; void g(S);  // #1
    template&lt;class T&gt; void g(T const &amp;); // #3
</PRE>

Here, #3 is clearly at least as specialized as #1. To determine
whether #1 is at least as specialized as #3, a unique type <TT>U</TT>
is synthesized, and deduction of <TT>g&lt;U&gt;(U)</TT> is performed
against #3. Following the rules in 14.8.2.1&nbsp;



 <A HREF="template.html#temp.deduct.call">temp.deduct.call</A>,
deduction succeeds with <TT>T=U</TT>.  Since the template argument is
<TT>U</TT>, and the deduced template parameter is also <TT>U</TT>, we
have an exact match between the template parameters. Even though the
conversion from <TT>U</TT> to <TT>U const &amp;</TT> is an exact
match, it is not clear whether the added qualification should be taken
into account, as it is in other places.</LI>

</OL>

<P>
<A HREF="
     cwg_closed.html#200">Issue 200</A> covers a related issue,
illustrated by the following example:</P>

<PRE>
    template &lt;class T&gt; T f(int);
    template &lt;class T, class U&gt; T f(U);
    void g() {
        f&lt;int&gt;(1);
    }
</PRE>

<P>Even though one template is "obviously" more specialized than the
other, deduction fails in both directions because neither function
parameter list allows template parameter <TT>T</TT> to be deduced.</P>

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



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

<P>John Spicer volunteered to draft examples illustrating possible
choices, so that the group can agree on desired outcomes.  This will
facilitate formulation of general rules.</P>



<P>
<U>Nathan Sidwell</U>, in message 9445:</P>

<P>14.5.5.2&nbsp;



 <A HREF="template.html#temp.func.order">temp.func.order</A> describes the partial ordering of function
templates. Paragraph 5 states,
<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>
To paraphrase, given two templates A &amp; B, if A's template
parameters can be deduced by B, but B's cannot be deduced by
A, then A is more specialized than B. Deduction is done as
if for a function call. In particular, except for conversion
operators, the return type is not involved in deduction.
This leads to the following templates and use being
unordered. (This example is culled from G++ bug report 4672
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&amp;pr=4672)
<PRE>
  template &lt;typename T, class U&gt; T checked_cast(U from); //#1
  template &lt;typename T, class U&gt; T checked_cast(U * from); //#2
  class C {};

  void foo (int *arg)
  {
    checked_cast &lt;C const *&gt; (arg);
  }
</PRE>
In the call,</P>
<P>#1 can be deduced with T = 'C const *' and U = 'int *'</P>
<P>#2 can be deduced with T = 'C const *' and U = 'int'</P>

<P>It looks like #2 is more specialized that #1, but
14.5.5.2&nbsp;



 <A HREF="template.html#temp.func.order">temp.func.order</A> does not make it so, as neither template can
deduce 'T' from the other template's function parameters.</P>

<P>Possible Resolutions:</P>
<P>There are several possible solutions, however through
experimentation I have discounted two of them.</P>

<P>Option 1:</P>
<P>When deducing function ordering, if the return type of one of
the templates uses a template parameter, then return types
should be used for deduction.  This, unfortunately, makes
existing well formed programs ill formed. For example
<PRE>
  template &lt;class T&gt; class X {};

  template &lt;class T&gt; X&lt;T&gt; Foo (T *);	// #1
  template &lt;class T&gt; int Foo (T const *); // #2

  void Baz (int *p1, int const *p2)
  {
    int j = Foo (p2); //#3
  }
</PRE>
Here, neither #1 nor #2 can deduce the other, as the return
types fail to match. Considering only the function parameters
gives #2 more specialized than #1, and hence makes the call
#3 well formed.</P>

<P>Option 2:</P>
<P>As option 1, but only consider the return type when deducing
the template whose return type involves template parameters.
This has the same flaw as option 1, and that example is
similarly ill formed, as #1's return type 'X&lt;T,0&gt;' fails to
match 'int' so #1 cannot deduce #2. In the converse direction,
return types are not considered, but the function parameters
fail to deduce.</P>

<P>Option 3:</P>
<P>It is observed that the original example is only callable
with a template-id-expr to supply a value for the first,
undeducible, parameter.  If that parameter were deducible it
would also appear within at least one of the function
parameters.  We can alter paragraph 4 of [temp.func.order]
to indicate that it is not necessary to deduce the parameters
which are provided explicitly, when the call has the form
of a template-id-expr.  This is a safe extension as it only
serves to make ill formed programs well formed. It is also
in line with the concept that deduction for function
specialization order should proceed in a similar manner to
function calling, in that explicitly provided parameter
values are taken into consideration.</P>

<P>
<B>Suggested resolution</B>:</P>
<P>Insert after the first sentence of paragraph 4 in
&nbsp;



 <A HREF=".html#"></A>
</P>
<BLOCKQUOTE>
Should any template parameters remain undeduced, and
the function call be of the form of a <I>template-id-expr</I>,
those template parameters provided in the
<I>template-id-expr</I> may be arbitrarily synthesized prior
to determining whether the deduced arguments generate
a valid function type.
</BLOCKQUOTE>

<P>See also <A HREF="
     cwg_closed.html#200">issue 200</A>.</P>

<BR>
<BR>
<HR>
<A NAME="345"></A>
<H4>345.
  
Misleading comment on example in templates chapter
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>14.6&nbsp;



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

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

 <B>Submitter: </B>Jason Shirk
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>18 March 2002<BR>



<P>From message 9493.</P>


<P>The following example from 14.6&nbsp;



 <A HREF="template.html#temp.res">temp.res</A> paragraph 4:</P>
<PRE>
struct A {
	struct X { };
	int X;
};
template&lt;class T&gt; void f(T t) {
	typename T::X x;        //  ill-formed: finds the data member  X
					//  not the member type  X
}
</PRE>
<P>
is not ill-formed.  The intent of the example is obvious, but some
mention should be made that it is only ill-formed when T=A.  For other
T's, it could be well formed.</P>

<BR>
<BR>
<HR>
<A NAME="186"></A>
<H4>186.
  
Name hiding and template <I>template-parameter</I>s
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>3<BR>




<P>From reflector message 8361.</P>


<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="334"></A>
<H4>334.
  
Is a comma-expression dependent if its first operand is?
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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>John Spicer
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>10 Jan 2002
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2<BR>


<P>Is the comma expression in the following dependent?</P>
<PRE>
  template &lt;class T&gt; static void f(T)
  {
  }
  template &lt;class T&gt; void g(T)
  {
    f((T::x, 0));
  }
  struct A {
    static int x;
  };
  void h()
  {
    g(A());
  }
</PRE>
<P>According to the standard, it is, because 14.6.2.2&nbsp;



 <A HREF="template.html#temp.dep.expr">temp.dep.expr</A>
says that an expression is dependent if any of its sub-expressions is
dependent, but there is a question about whether the language should
say something different.  The type and value of the expression are not really
dependent, and similar cases (like casting <TT>T::x</TT>
to <TT>int</TT>) are not dependent.</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>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>14.6.4&nbsp;



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

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

 <B>Submitter: </B>unknown
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>1
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Spicer<BR>




<P>(Previously numbered 737.)</P>


<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>


<P>John Spicer will propose a clarification.</P>

<BR>
<BR>
<HR>
<A NAME="212"></A>
<H4>212.
  
Implicit instantiation is not described clearly enough
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>14.7.1&nbsp;



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

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

 <B>Submitter: </B>Christophe de Dinechin
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>7 Mar 2000
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Spicer<BR>



<P>From reflector messages 8580-94 and 8601.</P>


<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_active.html#204">204</A> and
<A HREF="
     cwg_active.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_active.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="237"></A>
<H4>237.
  
Explicit instantiation and base class members
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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>Christophe de Dinechin
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>28 Jul 2000
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2<BR>


<P>From message 8822.</P>

<P>In 14.7.2&nbsp;



 <A HREF="template.html#temp.explicit">temp.explicit</A> paragraph 7 we read:</P>

<BLOCKQUOTE>
 The explicit instantiation of a class template specialization 
implies the instantiation of all of its members not previously 
explicitly specialized in the translation unit containing the 
explicit instantiation.
</BLOCKQUOTE>

<P>Is "member" intended to mean "non-inherited member?"
If yes, maybe it should be clarified since
10&nbsp;



 <A HREF="derived.html#class.derived">class.derived</A> paragraph 1 says,</P>

<BLOCKQUOTE>
Unless redefined in the derived class, members of a 
base class are also considered to be members of the derived 
class. 

</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="293"></A>
<H4>293.
  
Syntax of explicit instantiation/specialization too permissive
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2<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>


<P>John Spicer points out that the problem of limiting these to a single
declarator, addressed in the suggested solution by replacing
<I>declaration</I> by <I>decl-specifier-seq</I> followed by <I>declarator</I>,
is solved for similar template cases by a non-syntactic constraint,
e.g., 14&nbsp;



 <A HREF="template.html#temp">temp</A> paragraph 3, and perhaps a similar approach
should be taken here.</P>


<BR>
<BR>
<HR>
<A NAME="264"></A>
<H4>264.
  
Unusable template constructors and conversion functions
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>3<BR>


<P>From message 8987.</P>

<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>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2<BR>


<P>(From message 9092.)</P>

<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>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2<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="352"></A>
<H4>352.
  
Nondeduced contexts
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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>Andrei Iltchenko
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>24 April 2002<BR>


<P>The current definition of the C++ language speaks about nondeduced
contexts only in terms of deducing template arguments from a type
14.8.2.4&nbsp;



 <A HREF="template.html#temp.deduct.type">temp.deduct.type</A> paragraph 4. Those cases, however, don't
seem to be the only ones when template argument deduction is not
possible. The example below illustrates that:</P>
<PRE>
namespace  A  {
   enum  ae  {   };
   template&lt;class R, class A&gt;
   int  foo(ae, R(*)(A))
   {   return  1;   }
}

template&lt;typename T&gt;
void  tfoo(T)
{   }

template&lt;typename T&gt;
int  tfoo(T)
{   return  1;   }

/*int  tfoo(int)
{   return  1;   }*/


int  main()
{
   A::ae   a;
   foo(a, &amp;tfoo);
}
</PRE>
<P>Here argument-dependent name lookup finds the function template
'A::foo' as a candidate function. None of the function template's
function parameter types constitutes a nondeduced context as per
14.8.2.4&nbsp;



 <A HREF="template.html#temp.deduct.type">temp.deduct.type</A> paragraph 4. And yet, quite clearly,
argument deduction is not possible in this context. Furthermore it is
not clear what a conforming implementation shall do when the
definition of the non-template function '::tfoo' is uncommented.</P>

<P>
<B>Suggested resolution:</B>
</P>

<P>Add the following as a new paragraph immediately before paragraph 3 of
14.8.2.1&nbsp;



 <A HREF="template.html#temp.deduct.call">temp.deduct.call</A>:</P>
<BLOCKSCOPE>
<P>After the above transformations, in the event of P being a function
type, a pointer to function type, or a pointer to member function type
and the corresponding A designating a set of overloaded (member)
functions with at least one of the (member) functions introduced by
the use of a (member) function template name (13.4&nbsp;



 <A HREF="over.html#over.over">over.over</A>)
or by the use of a
conversion function template (14.8.2.3&nbsp;



 <A HREF="template.html#temp.deduct.conv">temp.deduct.conv</A>),
the whole function call
expression is considered to be a nondeduced context. [Example:</P>
<PRE>
namespace  A  {
   enum  ae  {   };
   template&lt;class R, class A&gt;
   int  foo(ae, R(*)(A))
   {   return  1;   }
}

template&lt;typename T&gt;
void  tfoo(T)
{   }

template&lt;typename T&gt;
int  tfoo(T)
{   return  1;   }

int  tfoo(int)
{   return  1;   }

int  main()
{
   A::ae   a;
   foo(a, &amp;tfoo);   //  ill-formed, the call is a nondeduced context
   using  A::foo;
   foo&lt;void,int&gt;(a, &amp;tfoo);  // well-formed, the address of the spe-
                             // cialization 'void tfoo&lt;int&gt;(int)' is
                             // the second argument of the call
}
</PRE>
</BLOCKSCOPE>


<P>
<U>John Spicer</U>:</P>

<P>Two notes:</P>
<OL>
<LI>
The standard actually prohibits what he is trying to do
(14.8.2.4&nbsp;



 <A HREF="template.html#temp.deduct.type">temp.deduct.type</A> paragraph 16).
I think this rule is strange and conflicts with most other deduction
cases that simply cause a function to be discarded for deduction purposes.
</LI>
<LI>
I'm not sure that treating this as a nondeduced context is correct, but
it should be discussed.  A nondeduced context inherits the template arguments
deduced elsewhere.  Other nondeduced contexts are a result of a certain form
of parameter, not argument.
</LI>
</OL>
<P>I think some kind of change should be made here. 
At least, I think we should
remove the error required by 14.8.2.4&nbsp;



 <A HREF="template.html#temp.deduct.type">temp.deduct.type</A> paragraph 16.
In addition, we should consider whether a change like the one suggested
is desired.</P>


<BR>
<BR>
<HR>
<A NAME="349"></A>
<H4>349.
  
Template argument deduction for conversion functions and qualification conversions
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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>open
 &nbsp;&nbsp;&nbsp;

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

 <B>Date: </B>16 April 2002<BR>



<P>From message 9502.</P>


<P>We ran into an issue concerning qualification conversions when doing
template argument deduction for conversion functions.</P>

<P>The question is: What is the type of T in the conversion functions
called by this example?  Is T "int" or "const int"?</P>

<P>If T is "int", the conversion function in class A works and the one in
class B fails (because the return expression cannot be converted to
the return type of the function).  If T is "const int", A fails and B
works.</P>

<P>Because the qualification conversion is performed on the result of the
conversion function, I see no benefit in deducing T as const int.</P>

<P>In addition, I think the code in class A is more likely to occur than
the code in class B.  If the author of the class was planning on returning
a pointer to a const entity, I would expect the function to have been
written with a const in the return type.</P>

<P>Consequently, I believe the correct result should be that T is int.</P>
<PRE>
struct A {
	template &lt;class T&gt; operator T***() {
		int*** p = 0;
		return p;
	}
};

struct B {
	template &lt;class T&gt; operator T***() {
		const int*** p = 0;
		return p;
	}
};

int main()
{
	A a;
	const int * const * const * p1 = a;
	B b;
	const int * const * const * p2 = b;
}
</PRE>
<P>We have just implemented this feature, and pending clarification by
the committee, we deduce T as int.  It appears that g++ and the Sun
compiler deduce T as const int.</P>

<P>One way or the other, I think the standard should be clarified to
specify how cases like this should be handled.</P>

<BR>
<BR>
<HR>
<A NAME="92"></A>
<H4>92.
  
Should exception specifications be part of the type system?
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2<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="346"></A>
<H4>346.
  
Typo in 15.4
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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>Lois Goldthwaite
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>18 March 2002<BR>


<P>15.4&nbsp;



 <A HREF="except.html#except.spec">except.spec</A> paragraph 13 contains the following text.
I believe 'implicitLY' marked below should be replaced with
'implicit.'</P>
<BLOCKQUOTE>
<P>An implicitly declared special member
 function (clause 12&nbsp;



 <A HREF="special.html#special">special</A>)
shall have an exception-specification. If f is an implicitly
declared default constructor, copy constructor, destructor, or copy 
assignment operator, its implicit exception-specification
specifies the <I>type-id</I> T if and only if T is allowed by the 
exception-specification of a function directly invoked 
by f's <B>implicitly</B> definition;
f shall allow all exceptions if any function it directly invokes 
allows all exceptions, and f shall allow no exceptions if
every function it directly invokes allows no exceptions. [Example: </P>
<PRE>
    struct A {
        A();
        A(const A&amp;) throw();
        ~A() throw(X);
    };
    struct B {
        B() throw();
        B(const B&amp;) throw();
        ~B() throw(Y);
    };
    struct D : public A, public B {
            //  Implicit declaration of  D::D();
            //  Implicit declaration of  D::D(const   D&amp;)   throw();
            //  Implicit declaration of  D::~D()   throw   (X,Y);
    };
</PRE>

<P>Furthermore, if A::~A() or B::~B() were virtual, D::~D() would not be as
restrictive as that of A::~A, and the program would
be ill-formed since a function that overrides a virtual function from a
base class shall have an exception-specification at least as
restrictive as that in the base class. ] </P>
</BLOCKQUOTE>

<P>The example code shows structs whose destructors have exception
specifications which throw certain types. There is no defect here, but
it doesn't sit well with our general advice elsewhere that destructors
should not throw. I wish I could think of some other way to illustrate
this section.</P>

<BR>
<BR>
<HR>
<A NAME="219"></A>
<H4>219.
  
Cannot defend against destructors that throw exceptions
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2<BR>



<P>From reflector messages 8650, 8655-64, and 8669.</P>


<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="268"></A>
<H4>268.
  
Macro name suppression in rescanned replacement text
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>3<BR>


<P>(From messages 9033-40.)</P>

<P>It is not clear from the Standard what the result of the
following example should be:</P>

<PRE>
    #define NIL(xxx) xxx
    #define G_0(arg) NIL(G_1)(arg)
    #define G_1(arg) NIL(arg)
    G_0(42)
</PRE>

<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>

<PRE>
G0(42)
NIL(G_1)(42)
G_1(42)
NIL(42)
</PRE>

<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.
(This was cited in message core-9035 and came
from document X3J11/86-196.)
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>

<BR>
<BR>
<HR>
<A NAME="223"></A>
<H4>223.
  
The meaning of deprecation
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>3<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>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2<BR>


<P>From messages 8914-15 and 8918.</P>

<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>

<BR>
<BR>
<BR>
<BR>
</BODY>
</HTML>
