<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/01-0055 = WG21 N1341</TD>
</TR>
<TR>
<TD ALIGN="RIGHT">
      Date:
     </TD><TD>
      &nbsp;9 November, 2001</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
     20</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 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_active.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_active.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_active.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_active.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="143"></A>
<H4>143.
  
Friends and 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>ready
 &nbsp;&nbsp;&nbsp;

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

 <B>Date: </B>21 Jul 1999
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Miller<BR>




<P>From reflector message 8228.</P>


<P>Paragraphs 1 and 2 of
3.4.2&nbsp;



 <A HREF="basic.html#basic.lookup.koenig">basic.lookup.koenig</A>
 say, in part,</P>

<BLOCKQUOTE>
When an unqualified name is used as the <I>postfix-expression</I>
in a function call
(5.2.2&nbsp;



 <A HREF="expr.html#expr.call">expr.call</A>
)... namespace-scope
friend function declarations
(11.4&nbsp;



 <A HREF="access.html#class.friend">class.friend</A>
) not otherwise
visible may be found... the set of declarations found
by the lookup of the function name [includes] the set
of declarations found in the... classes associated with
the argument types.
</BLOCKQUOTE>

The most straightforward reading of this wording is that if a function of
namespace scope (as opposed to a class member function) is
declared as a friend in a class, and that class is an
associated class in a function call, the friend function will
be part of the overload set, even if it is not visible to
normal lookup.

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

<PRE>
    namespace A {
	class S;
    };
    namespace B {
	void f(A::S);
    };
    namespace A {
	class S {
	    int i;
	    friend void B::f(S);
	};
    }
    void g() {
	A::S s;
	f(s); // should find B::f(A::S)
    }
</PRE>

This example would seem to satisfy the criteria from
3.4.2&nbsp;



 <A HREF="basic.html#basic.lookup.koenig">basic.lookup.koenig</A>
:
<TT>A::S</TT> is an associated class of the argument, and
<TT>A::S</TT> has a
friend declaration of the namespace-scope function
<TT>B::f(A::S)</TT>,
so Koenig lookup should include <TT>B::f(A::S)</TT> as part of the
overload set in the call.

<P>Another interpretation is that, instead of finding the friend
declarations in associated classes, one only looks for namespace-scope
functions, visible or invisible, in the namespaces of which the the
associated classes are members; the only use of the friend
declarations in the associated classes is to validate whether an
invisible function declaration came from an associated class or not
and thus whether it should be included in the overload set or not.
By this interpretation, the call <TT>f(s)</TT> in the example will
fail, because <TT>B::f(A::S)</TT> is not a member of namespace
<TT>A</TT> and thus is not found by the lookup.</P>

<P>
<B> Notes from 10/99 meeting:</B> The second interpretation
is correct.  The wording should be revised to make clear that Koenig
lookup works by finding "invisible" declarations in namespace scope
and not by finding <TT>friend</TT> declarations in associated
classes.</P>

<P>
<B>Proposed resolution (04/01):</B> The "associated classes"
are handled adequately under this interpretation by
3.4.2&nbsp;



 <A HREF="basic.html#basic.lookup.koenig">basic.lookup.koenig</A> paragraph 3, which describes the
lookup in the associated namespaces as including the friend
declarations from the associated classes.  Other mentions of the
associated classes should be removed or qualified to avoid the
impression that there is a lookup in those classes:</P>

<OL>

<LI>
<P>In 3.4.2&nbsp;



 <A HREF="basic.html#basic.lookup.koenig">basic.lookup.koenig</A>, change</P>

<BLOCKQUOTE>

When an unqualified name is used as the <I>postfix-expression</I>
in a function call (5.2.2&nbsp;



 <A HREF="expr.html#expr.call">expr.call</A>), other
namespaces not considered during the usual unqualified lookup
(3.4.1&nbsp;



 <A HREF="basic.html#basic.lookup.unqual">basic.lookup.unqual</A>) may be searched, and
namespace-scope friend function declarations
(11.4&nbsp;



 <A HREF="access.html#class.friend">class.friend</A>) not otherwise visible may be found.

</BLOCKQUOTE>

<P>to</P>

<BLOCKQUOTE>

When an unqualified name is used as the <I>postfix-expression</I>
in a function call (5.2.2&nbsp;



 <A HREF="expr.html#expr.call">expr.call</A>), other
namespaces not considered during the usual unqualified lookup
(3.4.1&nbsp;



 <A HREF="basic.html#basic.lookup.unqual">basic.lookup.unqual</A>) may be searched, and
<B>in those namespaces,</B>
namespace-scope friend function declarations
(11.4&nbsp;



 <A HREF="access.html#class.friend">class.friend</A>) not otherwise visible may be found.

</BLOCKQUOTE>

</LI>

<LI>
<P>In 3.4.2&nbsp;



 <A HREF="basic.html#basic.lookup.koenig">basic.lookup.koenig</A> paragraph 2, delete
the words <B>and classes</B> in the following two sentences:</P>

<BLOCKQUOTE>

If the ordinary unqualified lookup of the name finds the
declaration of a class member function, the associated namespaces
<B><S>and classes</S></B> are not considered.  Otherwise the
set of declarations found by the lookup of the function name is
the union of the set of declarations found using ordinary
unqualified lookup and the set of declarations found in the
namespaces <B><S>and classes</S></B> associated with the
argument types.

</BLOCKQUOTE>

</LI>

</OL>

<P>(See also issues
<A HREF="
     cwg_closed.html#95">95</A>,
<A HREF="
     cwg_defects.html#136">136</A>,
<A HREF="
     cwg_active.html#138">138</A>,
<A HREF="
     cwg_defects.html#139">139</A>,
<A HREF="
     cwg_closed.html#165">165</A>,
<A HREF="
     cwg_defects.html#166">166</A>, and
<A HREF="
     cwg_active.html#218">218</A>.)</P>
<BR>
<BR>
<HR>
<A NAME="270"></A>
<H4>270.
  
Order of initialization of static data members of class templates
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>3.6.2&nbsp;



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

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

 <B>Submitter: </B>Jonathan H. Lundquist
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>9 Feb 2001
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>0
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Crowl<BR>


<P>The Standard does not appear to address how the rules for order
of initialization apply to static data members of class templates.</P>

<P>
<U>Suggested resolution</U>: Add the following verbiage to either
3.6.2&nbsp;



 <A HREF="basic.html#basic.start.init">basic.start.init</A> or 9.4.2&nbsp;



 <A HREF="class.html#class.static.data">class.static.data</A>:</P>

<BLOCKQUOTE>

Initialization of static data members of class templates shall be
performed during the initialization of static data members for the
first translation unit to have static initialization performed for
which the template member has been instantiated.  This requirement
shall apply to both the static and dynamic phases of initialization.

</BLOCKQUOTE>

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

<P>Enforcing an order of initialization on static data members of
class templates will result in substantial overhead on access to such
variables. The problem is that the initialization be required as the
result of instantiation in a function used in the initialization of a
variable in another translation unit. In current systems, the order of
initialization of static data data members of class templates is not
predictable. The proposed resolution is to state that the order of
initialization is undefined.</P>

<P>
<B>Proposed resolution (04/01, updated slightly 10/01):</B>
</P>

<P>Replace the following sentence in 3.6.2&nbsp;



 <A HREF="basic.html#basic.start.init">basic.start.init</A>
paragraph 1:</P>

<BLOCKQUOTE>

Objects with static storage duration defined in namespace scope in the
same translation unit and dynamically initialized shall be initialized
in the order in which their definition appears in the translation
unit.

</BLOCKQUOTE>

<P>with</P>

<BLOCKQUOTE>

Dynamic initialization of an object is either ordered or unordered.
Explicit specializations and definitions
of class template static data members have ordered
initialization. Other class template static data member instances have
unordered initialization. Other objects defined in namespace scope
have ordered initialization. Objects defined within a single
translation unit and with ordered initialization shall be initialized
in the order of their definitions in the translation unit. The order
of initialization is unspecified for objects with unordered
initialization and for objects defined in different translation units.

</BLOCKQUOTE>

<P>
<B>Note (07/01):</B>
</P>

<P>
<U>Brian McNamara</U> argues against the proposed
resolution.  The following excerpt captures the central point of
a long message on comp.std.c++:</P>

<P>(The full text is in core message 9263.)</P>

<BLOCKQUOTE>
I have a class for representing linked lists which looks something like
<PRE>
    template &lt;class T&gt;
    class List {
       ...  static List&lt;T&gt;* sentinel; ...
    };
 
    template &lt;class T&gt;
    List&lt;T&gt;* List&lt;T&gt;::sentinel( new List&lt;T&gt; ); // static member definition
</PRE>
<P>The sentinel list node is used to represent "nil" (the null pointer
cannot be used with my implementation, for reasons which are immaterial
to this discussion).  All of the List's non-static member functions and
constructors depend upon the value of the sentinel.  Under the proposed
resolution for issue #270, Lists cannot be safely instantiated before
main() begins, as the sentinel's initialization is "unordered".</P>

<P>(Some readers may propose that I should use the "singleton pattern" in the
List class.  This is undesirable, for reasons I shall describe at the
end of this post at the location marked "[*]".  For the moment, indulge
me by assuming that "singleton" is not an adequate solution.)</P>

<P>Though this is a particular example from my own experience, I believe it
is representative of a general class of examples.  It is common to use
static data members of a class to represent the "distinguished values"
which are important to instances of that class.  It is imperative that
these values be initialized before any instances of the class are
created, as the instances depend on the values.</P>
</BLOCKQUOTE>

<P>In a comp.std.c++ posting on 28 Jul 2001, Brian McNamara proposes
the following alternative resolution:</P>

<P>Replace the following sentence in 3.6.2&nbsp;



 <A HREF="basic.html#basic.start.init">basic.start.init</A>
paragraph 1:</P>
<BLOCKQUOTE>
Objects with static storage duration defined in namespace scope in
the same translation unit and dynamically initialized shall be
initialized in the order in which their definition appears in the
translation unit.
</BLOCKQUOTE>
with
<BLOCKQUOTE>
Objects with static storage duration defined in namespace scope 
shall be initialized in the order described below.
</BLOCKQUOTE>
and then after paragraph 1, add this text:
<BLOCKQUOTE>
Dynamic initialization is either ordered or quasi-ordered. Explicit
specializations of class template static data members have ordered
initialization. Other class template static data member instances have
quasi-ordered initialization. All other objects defined in namespace
scope have ordered initialization.  The order of initialization is
specified as follows:
<UL>
<LI>
Objects that are defined within a single translation unit and 
that have ordered initialization shall be initialized in the
order of their definitions in the translation unit.
</LI>
<LI>
Objects that are defined only within a single translation unit 
and that have quasi-ordered initialization shall also be
initialized in the order of their definitions in the translation
unit -- that is, as though these objects had ordered initialization.
</LI>
<LI>
Objects that are defined within multiple translation units (which,
therefore, must have quasi-ordered initialization) shall be
initialized as follows: in exactly one translation unit
(<I>which</I> one is unspecified), the object shall be treated as
though it has ordered initialization; in the other translation
units which define the object, the object will be initialized
before all other objects that have ordered initialization in
those translation units.
</LI>
<LI>
For any two objects, "X" and "Y", with static storage duration 
and defined in namespace scope, if the previous bullets do not
imply a relationship for the initialization ordering between "X"
and "Y", then the relative initialization order of these objects
is unspecified.
</LI>
</UL>
</BLOCKQUOTE>
along with a non-normative note along the lines of
<BLOCKQUOTE>
[ Note: The intention is that translation units can each be compiled
separately with no knowledge of what objects may be re-defined in
other translation units.  Each translation unit can contain a method
which initializes all objects (both quasi-ordered and ordered) as
though they were ordered.  When these translation units are linked
together to create an executable program, all of these objects can
be initialized by simply calling the initialization methods (one
from each translation unit) in any order.  Quasi-ordered objects
require some kind of guard to ensure that they are not initialized
more than once (the first attempt to initialize such an object
should succeed; any subsequent attempts should simply be ignored). ]
</BLOCKQUOTE>

<P>
<U>Erwin Unruh</U> replies:
There is a point which is not mentioned with this posting.
It is the cost for implementing the scheme. It requires that each
static template variable is instantiated in ALL translation units
where it is used. There has to be a flag for each of these variables
and this flag has to be checked in each TU where the instantiation
took place.</P>

<P>I would reject this idea and stand with the proposed resolution of
issue 270.</P>

<P>There just is no portable way to ensure the "right" ordering of
construction.</P>

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

<P>The Core Working Group reaffirmed its previous decision.</P>

<BR>
<BR>
<HR>
<A NAME="119"></A>
<H4>119.
  
Object lifetime and aggregate initialization
</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>ready
 &nbsp;&nbsp;&nbsp;

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

 <B>Date: </B>20 May 1999
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Miller<BR>



<P>From reflector messages 8072-8073.</P>


<P>
<B>Jack Rouse:</B>
3.8&nbsp;



 <A HREF="basic.html#basic.life">basic.life</A>
 paragraph 1
includes:</P>
<BLOCKQUOTE>
The lifetime of an object is a runtime property of the object. The
lifetime of an object of type <TT>T</TT> begins when:
<UL>
<LI>storage with the proper alignment and size for type <TT>T</TT>
is obtained, and</LI>

<LI>if <TT>T</TT> is a class type with a non-trivial constructor
(12.1&nbsp;



 <A HREF="special.html#class.ctor">class.ctor</A>
), the
constructor call has completed.</LI>
</UL>
</BLOCKQUOTE>

Consider the code:
<PRE>
    struct B {
        B( int = 0 );
        ~B();
    };

    struct S {
        B b1;
    };

    int main()
    {
        S s = { 1 };
        return 0;
    }
</PRE>

In the code above, class <TT>S</TT> does have a non-trivial constructor, the
default constructor generated by the compiler.  According the text
above, the lifetime of the auto <TT>s</TT> would never begin because a
constructor for <TT>S</TT> is never called.  I think the second case in the
text needs to include aggregate initialization.

<P>
<B>Mike Miller:</B>
I see a couple of ways of fixing the problem.  One way would be
to change "the constructor call has completed" to "the object's
initialization is complete."</P>

<P>Another would be to add following "a class type with a non-trivial
constructor" the phrase "that is not initialized with the brace
notation (8.5.1&nbsp;



 <A HREF="decl.html#dcl.init.aggr">dcl.init.aggr</A>
)."</P>

<P>The first formulation treats aggregate initialization like a
constructor call; even POD-type members of an aggregate could
not be accessed before the aggregate initialization completed.
The second is less restrictive; the POD-type members of the
aggregate would be usable before the initialization, and the
members with non-trivial constructors (the only way an
aggregate can acquire a non-trivial constructor) would be
protected by recursive application of the lifetime rule.</P>

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

<P>In 3.8&nbsp;



 <A HREF="basic.html#basic.life">basic.life</A> paragraph 1, change</P>

<BLOCKQUOTE>

If <TT>T</TT> is a class type with a non-trivial constructor
(12.1&nbsp;



 <A HREF="special.html#class.ctor">class.ctor</A>), the constructor call has
completed.

</BLOCKQUOTE>

<P>to</P>

<BLOCKQUOTE>

If <TT>T</TT> is a class type with a non-trivial constructor
(12.1&nbsp;



 <A HREF="special.html#class.ctor">class.ctor</A>), the initialization is complete.
[<I>Note:</I> the initialization can be performed by a
constructor call or, in the case of an aggregate with an
implicitly-declared non-trivial default constructor, an
aggregate initialization (8.5.1&nbsp;



 <A HREF="decl.html#dcl.init.aggr">dcl.init.aggr</A>).]

</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="158"></A>
<H4>158.
  
Aliasing and qualification conversions
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>3.10&nbsp;



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

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

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

 <B>Date: </B>20 Aug 1999
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Nelson<BR>



<P>3.10&nbsp;



 <A HREF="basic.html#basic.lval">basic.lval</A> paragraph 15 lists the types via which
an lvalue can be used to access the stored value of an object; using
an lvalue type that is not listed results in undefined behavior.  It
is permitted to add cv-qualification to the actual type of the object
in this access, but only at the top level of the type ("a cv-qualified
version of the dynamic type of the object").</P>

<P>However, 4.4&nbsp;



 <A HREF="conv.html#conv.qual">conv.qual</A> paragraph 4 permits a
"conversion [to] add cv-qualifiers at levels other than the first in
multi-level pointers."  The combination of these two rules
allows creation of pointers that cannot be dereferenced without
causing undefined behavior.  For instance:</P>

<PRE>
    int* jp;
    const int * const * p1 = &amp;jp;
    *p1;    // undefined behavior!
</PRE>

<P>The reason that <TT>*p1</TT> results in undefined behavior
is that the type of the lvalue is <TT>const int * const"</TT>,
which is <I>not</I> "a cv-qualified version of" <TT>int*</TT>.</P>

<P>Since the conversion is permitted, we must give it defined
semantics, hence we need to fix the wording in 3.10&nbsp;



 <A HREF="basic.html#basic.lval">basic.lval</A> to include all possible conversions of the type via
4.4&nbsp;



 <A HREF="conv.html#conv.qual">conv.qual</A>.</P>

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

<P>Add a new bullet to 3.10&nbsp;



 <A HREF="basic.html#basic.lval">basic.lval</A> paragraph 15,
following "a cv-qualified version of the dynamic type of the
object:"</P>

<UL>
<LI>A type similar (as defined in 4.4&nbsp;



 <A HREF="conv.html#conv.qual">conv.qual</A>) to
the dynamic type of the object,</LI>
</UL>

<BR>
<BR>
<HR>
<A NAME="177"></A>
<H4>177.
  
Lvalues vs rvalues in copy-initialization
</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>25 October 1999
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Schmeiser<BR>



<P>Is the temporary created during copy-initialization of a class object
treated as an lvalue or an rvalue?  That is, is the following example
well-formed or not?</P>

<PRE>
    struct B { };
    struct A {
        A(A&amp;);    // not const
        A(const B&amp;);
    };
    B b;
    A a = b;
</PRE>

<P>According to 8.5&nbsp;



 <A HREF="decl.html#dcl.init">dcl.init</A>
 paragraph
14, the initialization of <TT>a</TT> is performed in two steps.
First, a temporary of type <TT>A</TT> is created using <TT>A::A(const
B&amp;)</TT>.  Second, the resulting temporary is used to
direct-initialize <TT>a</TT> using <TT>A::A(A&amp;)</TT>.</P>

<P>The second step requires binding a reference to non-const to the
temporary resulting from the first step.  However,
8.5.3&nbsp;



 <A HREF="decl.html#dcl.init.ref">dcl.init.ref</A>
 paragraph 5 requires
that such a reference be bound only to lvalues.</P>

<P>It is not clear from 3.10&nbsp;



 <A HREF="basic.html#basic.lval">basic.lval</A>

whether the temporary created in the process of copy-initialization
should be treated as an lvalue or an rvalue.  If it is an lvalue, the
example is well-formed, otherwise it is ill-formed.</P>

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

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



 <A HREF="decl.html#dcl.init">dcl.init</A> paragraph 14, insert
the following after "the call initializes a temporary of
the destination type":</P>

<BLOCKQUOTE>

The temporary is an rvalue.

</BLOCKQUOTE>
</LI>

<LI>
<P>In 15.1&nbsp;



 <A HREF="except.html#except.throw">except.throw</A> paragraph 3, replace</P>

<BLOCKQUOTE>

The temporary is used to initialize the variable...

</BLOCKQUOTE>

<P>with</P>

<BLOCKQUOTE>

The temporary is an lvalue and is used to initialize
the variable...

</BLOCKQUOTE>

</LI>

</OL>

<P>(See also <A HREF="
     cwg_defects.html#84">issue 84</A>.)</P>
<BR>
<BR>
<HR>
<A NAME="77"></A>
<H4>77.
  
The definition of friend does not allow nested classes to be friends
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>11.4&nbsp;



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

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

 <B>Submitter: </B>Judy Ward
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>15 Dec 1998
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Adamczyk<BR>



<P>The definition of "friend" in
11.4&nbsp;



 <A HREF="access.html#class.friend">class.friend</A>

says:</P>
<BLOCKQUOTE>A friend of a class is a function or class that is not a member
of the class but is permitted to use the private and protected member names
from the class. ...</BLOCKQUOTE>
A nested class, i.e. INNER in the example below, is a member of class OUTER.
The sentence above states that it cannot be a friend. I think this is a
mistake.
<PRE>
    class OUTER {
        class INNER;
        friend class INNER;
        class INNER {};
    };
</PRE>

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

<P>Change the first sentence of 11.4&nbsp;



 <A HREF="access.html#class.friend">class.friend</A>
as follows:</P>

<BLOCKQUOTE>

A friend of a class is a function or class that is <S>not a
member of the class but is allowed</S> <B>given permission</B>
to use the private and protected member names from the class.
<S>The name of a friend is not in the scope of the class, and
the friend is not called with the member access operators
(5.2.5&nbsp;



 <A HREF="expr.html#expr.ref">expr.ref</A>) unless it is a member of
another class.</S> <B>A class specifies its friends, if any,
by way of friend declarations.  Such declarations give special
access rights to the friends, but they do not make the nominated
friends members of the befriending class.</B>

</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="286"></A>
<H4>286.
  
Incorrect example in partial specialization
</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>ready
 &nbsp;&nbsp;&nbsp;

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

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


<P>From messages 9152-3.</P>

<P>The example in 14.5.4&nbsp;



 <A HREF="template.html#temp.class.spec">temp.class.spec</A> paragraph 6 is
incorrect.  It reads,</P>

<PRE>
    template&lt;class T&gt; struct A {
        class C {
            template&lt;class T2&gt; struct B { };
        };
    };

    // partial specialization of A&lt;T&gt;::C::B&lt;T2&gt;
    template&lt;class T&gt; template&lt;class T2&gt;
        struct A&lt;T&gt;::C::B&lt;T2*&gt; { };

    A&lt;short&gt;::C::B&lt;int*&gt; absip; // uses partial specialization
</PRE>

<P>Because <TT>C</TT> is a <TT>class</TT> rather than a <TT>struct</TT>,
the use of the name <TT>B</TT> is inaccessible.</P>

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

<P>Change <TT>class C</TT> to <TT>struct C</TT> in the example in
14.5.4&nbsp;



 <A HREF="template.html#temp.class.spec">temp.class.spec</A> paragraph 6.  The example becomes</P>
<PRE>
    template&lt;class T&gt; struct A {
        struct C {
            template&lt;class T2&gt; struct B { };
        };
    };

    // partial specialization of A&lt;T&gt;::C::B&lt;T2&gt;
    template&lt;class T&gt; template&lt;class T2&gt;
        struct A&lt;T&gt;::C::B&lt;T2*&gt; { };

    A&lt;short&gt;::C::B&lt;int*&gt; absip; // uses partial specialization
</PRE>

<BR>
<BR>
<HR>
<A NAME="180"></A>
<H4>180.
  
<TT>typename</TT> and elaborated types
</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>ready
 &nbsp;&nbsp;&nbsp;

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

 <B>Date: </B>21 Dec 1999
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Miller<BR>




<P>From reflector messages 8377-8380.</P>


<P>
<U>Mike Miller</U>:
A question about <TT>typename</TT> came up in the discussion of
<A HREF="
     cwg_defects.html#68">issue 68</A> that is somewhat relevant
to the idea of omitting
typename in contexts where it is clear that a type is
required: consider something like</P>

<PRE>
        template &lt;class T&gt;
        class X {
            friend class T::nested;
        };
</PRE>

Is <TT>typename</TT> required here?  If so, where would it go?  (The
grammar doesn't seem to allow it anywhere in an
<I>elaborated-type-specifier</I> that has a <I>class-key</I>.)

<P>
<U>Bill Gibbons</U>:
The <TT>class</TT> applies to the last identifier in the qualified name,
since all the previous names must be classes or namespaces.  Since the
name is specified to be a class it does not need <TT>typename</TT>.
[However,] it looks like
14.6&nbsp;



 <A HREF="template.html#temp.res">temp.res</A>
 paragraph 3 requires
<TT>typename</TT> and the following paragraphs
do not exempt this case.  This is not what we agreed on.</P>

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

<P>In 14.6&nbsp;



 <A HREF="template.html#temp.res">temp.res</A> paragraph 5, change</P>

<BLOCKQUOTE>

The keyword <TT>typename</TT> is not permitted in a
<I>base-specifier</I> or in a <I>mem-initializer</I>; in these
contexts a <I>qualified-name</I> that depends on a
<I>template-parameter</I> (14.6.2&nbsp;



 <A HREF="template.html#temp.dep">temp.dep</A>) is
implicitly assumed to be a type name.

</BLOCKQUOTE>

<P>to</P>

<BLOCKQUOTE>

A qualified name used as the name in a <I>mem-initializer-id</I>,
a <I>base-specifier</I>, or an <I>elaborated-type-specifier</I>
(in the <I>class-key</I> and <TT>enum</TT> forms) is implicitly
assumed to name a type, without the use of the <TT>typename</TT>
keyword.  [<I>Note:</I> the <TT>typename</TT> keyword is not
permitted by the syntax of these constructs.]

</BLOCKQUOTE>

<P>(The expected resolution for <A HREF="
     cwg_active.html#254">issue 254</A> will remove the <TT>typename</TT> forms from the
grammar for <I>elaborated-type-specifier</I>.  If that
resolution is adopted, the parenthetical phrase "(in the
<I>class-key</I> and <TT>enum</TT> forms)" in the preceding
wording should be removed because those will be the only forms
of <I>elaborated-type-specifier</I>.)</P>
<BR>
<BR>
<HR>
<A NAME="259"></A>
<H4>259.
  
Restrictions on explicit specialization and instantiation
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>14.7&nbsp;



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

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

 <B>Submitter: </B>Matt Austern
 &nbsp;&nbsp;&nbsp;

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


<P>From messages 8956, 8959, and 8975.</P>

<P>According to 14.7&nbsp;



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

<BLOCKQUOTE>

No program shall explicitly instantiate any template more than once,
both explicitly instantiate and explicitly specialize a template, or
specialize a template more than once for a given set of
<I>template-argument</I>s.

</BLOCKQUOTE>

<P>This rule has an impact on library issue 120.  Library authors
would like to have the freedom to specialize (or not) various
library functions without having to document their choices, while
users need the flexibility to explicitly instantiate library
functions in certain translation units.</P>

<P>If this rule could be slightly weakened, it would reduce the need
for constraining either the library author or the programmer.  For
instance, the rule might be recast to say that if a specialization is
followed by an explicit instantiation in the same translation unit,
the explicit instantiation is ignored.  A specialization and an
explicit instantiation of the same template in two different
translation units would still be an error, no diagnostic required.</P>

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

<OL>
<LI>
<P>Replace the first sentence of 14.7&nbsp;



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

<BLOCKQUOTE>

No program shall explicitly instantiate any template more
than once, both explicitly instantiate and explicitly
specialize a template, or specialize a template more than
once for a given set of <I>template-argument</I>s.

</BLOCKQUOTE>

<P>by</P>

<BLOCKQUOTE>

For a given template and a given set of <I>template-argument</I>s,

<UL>
<LI>an explicit instantiation shall appear at most once in a
program,</LI>

<LI>an explicit specialization shall be defined at most once
according to 3.2&nbsp;



 <A HREF="basic.html#basic.def.odr">basic.def.odr</A> in a program, and</LI>

<LI>both an explicit instantiation and a declaration of an
explicit specialization shall not appear in a program unless
the explicit instantiation follows a declaration of the explicit
specialization.</LI>

</UL>

</BLOCKQUOTE>
</LI>

<LI>
<P>Replace 14.7.2&nbsp;



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

<BLOCKQUOTE>

The definition of a non-exported function template, a non-exported
member function template, or a non-exported member function or
static data member of a class template shall be present in every
translation unit in which it is explicitly instantiated.

</BLOCKQUOTE>

<P>by</P>

<BLOCKQUOTE>

For a given set of template parameters, if an explicit
instantiation of a template appears after a declaration of
an explicit specialization for that template, the explicit
instantiation has no effect.  Otherwise, the definition of a
non-exported function template, a non-exported member
function template, or a non-exported member function or static
data member of a class template shall be present in every
translation unit in which it is explicitly instantiated.

</BLOCKQUOTE>
</LI>

</OL>

<BR>
<BR>
<HR>
<A NAME="275"></A>
<H4>275.
  
Explicit instantiation/specialization and <I>using-directive</I>s
</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>ready
 &nbsp;&nbsp;&nbsp;

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

 <B>Date: </B>15 Feb 2001
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>1
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Maurer<BR>


<P>(From messages 9067-8, 9070-91.)</P>

<P>Consider this example:</P>

<PRE>
    namespace N {
	template &lt;class T&gt; void f(T){}
	template &lt;class T&gt; void g(T){}
	template &lt;&gt; void f(int);
	template &lt;&gt; void f(char);
	template &lt;&gt; void g(char);
    }

    using namespace N;

    namespace M {
	template &lt;&gt; void N::f(char){}  // prohibited by standard
	template &lt;class T&gt; void g(T){}
	template &lt;&gt; void g(char){}     // specialization of M::g or ambiguous?
	template void f(long);         // instantiation of N::f?
    }

    template &lt;class T&gt; void g(T){}

    template &lt;&gt; void N::f(char){}  // okay
    template &lt;&gt; void f(int){}      // is this a valid specialization of N::f?

    template void g(int);          // instantiation of ::g(int) or ambiguous?
</PRE>

<P>The question here is whether unqualified names made visible by a
<I>using-directive</I> can be used as the declarator in an explicit
instantiation or explicit specialization.</P>

<P>Note that this question is already answered for qualified names in
8.3&nbsp;



 <A HREF="decl.html#dcl.meaning">dcl.meaning</A> paragraph 1.  In a qualified name such as
<TT>N::f</TT>, <TT>f</TT> must be a member of class or namespace
<TT>N</TT>, not a name made visible in <TT>N</TT> by a
<I>using-directive</I> (or a <I>using-declaration</I>, for that
matter).</P>

<P>The standard does not, as far as I can tell, specify the behavior of
these cases one way or another.</P>

<P>My opinion is that names from <I>using-directive</I>s should not be
considered when looking up the name in an unqualified declarator in an
explicit specialization or explicit instantiation.  In such cases, it
is reasonable to insist that the programmer know exactly which
template is being specialized or instantiated, and that a qualified
name must be used if the template is a member of a namespace.</P>

<P>As the example illustrates, allowing names from
<I>using-directive</I>s to be used would also have the affect of
making ambiguous otherwise valid instantiation and specialization
directives.</P>

<P>Furthermore, permitting names from <I>using-directive</I>s would
require an additional rule to prohibit the explicit instantiation of
an entity in one namespace from being done in another (non-enclosing)
namespace (as in the instantiation of <TT>f</TT> in namespace
<TT>M</TT> in the example).</P>

<P>
<U>Mike Miller</U>: I believe the explicit specialization case
is already covered by 7.3.1.2&nbsp;



 <A HREF="dcl.html#namespace.memdef">namespace.memdef</A> paragraph 2,
which requires using a qualified name to define a namespace member
outside its namespace.</P>

<P>
<U>John Spicer</U>: 7.3.1.2&nbsp;



 <A HREF="dcl.html#namespace.memdef">namespace.memdef</A> deals with
namespace members.  An explicit specialization directive deals with
something that is a specialization of a namespace member.  I don't
think the rules in 7.3.1.2&nbsp;



 <A HREF="dcl.html#namespace.memdef">namespace.memdef</A> could be taken to
apply to specializations unless the standard said so explicitly.</P>

<P>
<B>Proposed resolution (suggested 04/01, proposed 10/01)</B>:</P>

<P>(The first change below will need to be revised in accordance
with the resolution of <A HREF="
     cwg_active.html#284">issue 284</A> to
add a cross-reference to the text dealing with class names.)</P>

<OL>

<LI>
<P>Add in 14.7.2&nbsp;



 <A HREF="template.html#temp.explicit">temp.explicit</A> paragraph 2 before the
example:</P>

<BLOCKQUOTE>

An explicit instantiation shall appear in an enclosing namespace
of its template.  If the name declared in the explicit
instantiation is an unqualified name, the explicit instantiation
shall appear in the namespace where its template is declared.
[<I>Note:</I> Regarding qualified names in declarators, see
8.3&nbsp;



 <A HREF="decl.html#dcl.meaning">dcl.meaning</A>.]

</BLOCKQUOTE>

</LI>

<LI>
<P>Change the first sentence of 7.3.1.2&nbsp;



 <A HREF="dcl.html#namespace.memdef">namespace.memdef</A>
paragraph 1 from</P>

<BLOCKQUOTE>

Members of a namespace can be defined within that namespace.

</BLOCKQUOTE>

<P>to</P>

<BLOCKQUOTE>

Members (including explicit specializations of templates
(14.7.3&nbsp;



 <A HREF="template.html#temp.expl.spec">temp.expl.spec</A>)) of a namespace can be defined
within that namespace.

</BLOCKQUOTE>

</LI>

<LI>
<P>Change the first sentence of 7.3.1.2&nbsp;



 <A HREF="dcl.html#namespace.memdef">namespace.memdef</A>
paragraph 2 from</P>

<BLOCKQUOTE>

Members of a named namespace can also be defined...

</BLOCKQUOTE>

<P>to</P>

<BLOCKQUOTE>

Members (including explicit specializations of templates (14.7.3&nbsp;



 <A HREF="template.html#temp.expl.spec">temp.expl.spec</A>)) of a named namespace can also be defined...

</BLOCKQUOTE>

</LI>

<LI>
<P>Change the last sentence of 14.7.3&nbsp;



 <A HREF="template.html#temp.expl.spec">temp.expl.spec</A>
paragraph 2 from</P>

<BLOCKQUOTE>

If the declaration is not a definition, the specialization may be
defined later in the namespace in which the explicit specialization
was declared, or in a namespace that encloses the one in which the
explicit specialization was declared.

</BLOCKQUOTE>

<P>to</P>

<BLOCKQUOTE>

If the declaration is not a definition, the specialization may be
defined later (7.3.1.2&nbsp;



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

</BLOCKQUOTE>

</LI>

</OL>

<BR>
<BR>
<BR>
<BR>
<HR>
<A NAME="Review Status"></A>
<H3>Issues with "Review" 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>review
 &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>review
 &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="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>0
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Adamczyk<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>

<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="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>review
 &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="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>review
 &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):</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="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/01):</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 and signature
(1.3.1&nbsp;



 <A HREF="intro.html#defns.argument">defns.argument</A>) 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 and signature (1.3.10&nbsp;



 <A HREF="intro.html#defns.signature">defns.signature</A>) 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>

<P>
<B>Note:</B> Should this use the term "parameter-type-list" introduced
in <A HREF="
     cwg_defects.html#140">issue 140</A> instead of "signature"?</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>review
 &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>

<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>review
 &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>(in the sense defined in
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="304"></A>
<H4>304.
  
Value-initialization of a reference
</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>review
 &nbsp;&nbsp;&nbsp;

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

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


<P>From message 9264.</P>

<P>Another glitch in the TC1/<A HREF="
     cwg_defects.html#178">core issue 178</A>
definition of value-initialization:
it's no longer an error to value-initialize a reference.  That makes an example
like
<PRE>
typedef struct { int &amp;r; } S;
int main() {
  S();  // Error in C++98, okay in TC1!
}
</PRE>
valid, which has got to be wrong.  See 8.5&nbsp;



 <A HREF="decl.html#dcl.init">dcl.init</A> paragraph
5, where there is wording that forbids default-initialization of a
reference, but not value-initialization thereof. As noted in
<A HREF="
     cwg_active.html#302">issue 302</A>, if
the default constructor were required to be generated when a
value-initialization is done, that would force an error.</P>

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

<P>Add the indicated wording to the indicated sentence in
8.5&nbsp;



 <A HREF="decl.html#dcl.init">dcl.init</A> paragraph 5:</P>
<BLOCKQUOTE>
A program that calls for default-initialization <B>or value-initialization</B>
of an entity of reference type is ill-formed.
</BLOCKQUOTE>

<P>In message 9323, Andrew Koenig said that he
has made this proposed change as a quasi-editorial change in TC1.
He has since confirmed that the change has been made already.</P>


<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>review
 &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 <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>review
 &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_active.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="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>Proposed resolution:</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 use (3.2&nbsp;



 <A HREF="basic.html#basic.def.odr">basic.def.odr</A>) 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>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>Except by using explicit pointers, references, and
object names, declarations in a nested class <B>shall not use (including as
operands of the </B><TT><B>sizeof</B></TT><B>
operator) nonstatic data members or nonstatic member functions </B>from the
enclosing class<B>.</B>
</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>
<P>
--- end example] </P>

<P>In
9.8&nbsp;



 <A HREF="class.html#class.local">class.local</A>
paragraph 1, replace the last sentence,</P>
<BLOCKQUOTE>
<P>Declarations
in a local class can use only type names, static variables, <TT>extern</TT>
variables and functions, and enumerators from the enclosing scope.</P>
</BLOCKQUOTE>
<P>with the following</P>
<BLOCKQUOTE>
<P>Declarations
in a local class <B>shall not use (3.2&nbsp;



 <A HREF="basic.html#basic.def.odr">basic.def.odr</A>) objects with
automatic storage duration</B> from the enclosing scope. </P>
</BLOCKQUOTE>
<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>

<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>review
 &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="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>

<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>review
 &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="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>review
 &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>Vandevoorde<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>

<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="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>Gibbons<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="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>review
 &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>review
 &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="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="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>drafting
 &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>

<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>drafting
 &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_active.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>

<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="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>

<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="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>drafting
 &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>

<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_active.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="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>drafting
 &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>

<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>drafting
 &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>See also <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>drafting
 &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>

<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="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>drafting
 &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>
<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_active.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>
<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>
<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="231"></A>
<H4>231.
  
Visibility of names after <I>using-directive</I>s
</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>J&ouml;rg Barfurth
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>31 May 2000
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2<BR>


<P>The wording of 3.4.1&nbsp;



 <A HREF="basic.html#basic.lookup.unqual">basic.lookup.unqual</A> paragraph 2 is
misleading.  It says:</P>

<BLOCKQUOTE>

The declarations from the namespace nominated by a
<I>using-directive</I> become visible in a namespace enclosing the
<I>using-directive</I>; see 7.3.4&nbsp;



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

</BLOCKQUOTE>

<P>According to 7.3.4&nbsp;



 <A HREF="dcl.html#namespace.udir">namespace.udir</A> paragraph 1, that
namespace is</P>

<BLOCKQUOTE>

the nearest enclosing namespace which contains both the
<I>using-directive</I> and the nominated namespace.

</BLOCKQUOTE>

<P>That would seem to imply the following:</P>

<PRE>
    namespace outer {
        namespace inner {
            int i;
        }
        void f() {
            using namespace inner;
        }
        int j = i;   // inner::i is "visible" in namespace outer
    }
</PRE>

<P>
<B>Suggested resolution:</B> Change the first sentence of
3.4.1&nbsp;



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

<BLOCKQUOTE>

The declarations from the namespace nominated by a
<I>using-directive</I> become visible in the scope in which the
<I>using-directive</I> appears after the <I>using-directive</I>.

</BLOCKQUOTE>

<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_active.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="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="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="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="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>
<secton_ref>4.1&nbsp;



 <A HREF="conv.html#conv.lval">conv.lval</A></secton_ref> 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="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="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>open
 &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>

<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="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="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<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="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="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="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="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="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="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="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="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>open
 &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>

<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.4&nbsp;



 <A HREF="special.html#class.dtor">class.dtor</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>

<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="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>open
 &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>Spicer<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>

<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>open
 &nbsp;&nbsp;&nbsp;

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

 <B>Date: </B>11 Feb 2000
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2<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>
<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>open
 &nbsp;&nbsp;&nbsp;

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

 <B>Date: </B>11 Nov 1999
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2<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 to 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>
<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="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>open
 &nbsp;&nbsp;&nbsp;

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

 <B>Date: </B>4 May 2000
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2<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>

<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>



<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="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="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>open
 &nbsp;&nbsp;&nbsp;

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

 <B>Date: </B>8 Nov 1999
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2<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>

(Is this specified anywhere in the normative text?  Should
it be?)

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.
<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="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="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>
