<HTML>
<HEAD>
<TITLE>



    C++ Standard Core Language
    
      Defect Reports
     </TITLE>
</HEAD>
<BODY>
<TABLE ALIGN="RIGHT" CELLSPACING="0" CELLPADDING="0">
<TR>
<TD ALIGN="RIGHT">
      Document number:
     </TD><TD>
      &nbsp;



      J16/01-0056 = WG21 N1342</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
     
       Defect Reports,
      



     Revision
     20</H2>
<H3>Committee Version</H3>
</CENTER>
<BR>
<P>
      This document contains the C++ core language issues that have been
      categorized as Defect Reports by the C++ Standard Committee (J16 +
      WG21), along with their proposed resolutions.  <B>THESE RESOLUTIONS
      ARE NOT YET PART OF THE INTERNATIONAL STANDARD FOR C++.</B>  They are
      provided for informational purposes only, as an indication of the
      intent of the Committee.  They should not be considered definitive
      until or unless they appear in an approved Technical Corrigendum
      or revised International Standard for C++.
     </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_active.html">Active Issues List</A>, which contains
      explanatory material for the entire document group and a list of
      the issues that have not yet been acted upon by the Committee.
     </LI>
<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_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>
     For more information, including a description of the meaning of
     the issue status codes and instructions on reporting new issues,
     please see <A HREF="cwg_active.html">the Active Issues List</A>.
    </P>
<SCRIPT type="text/javascript">
  var seqno = 1;
 </SCRIPT>
<HR>
<A NAME="DR Status"></A>
<H3>Issues with "DR" Status</H3>
<HR>
<A NAME="173"></A>
<H4>173.
  
Constraints on execution character set
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>2.2&nbsp;



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

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

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

 <B>Date: </B>27 Sep 1999
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Nelson<BR>



<P>22.2.1.1.2&nbsp;



 <A HREF="lib-locales.html#lib.locale.ctype.virtuals">lib.locale.ctype.virtuals</A>

paragraph 13 states a constraint on the values of the characters
representing the decimal digits in the execution character set:</P>

<BLOCKQUOTE>
for any digit character <TT>c</TT>, the expression
<TT>(do_narrow( c, dfault)-'0')</TT> evaluates to the digit
value of the character.
</BLOCKQUOTE>

This requirement is not reflected in the description of the
execution character set
(2.2&nbsp;



 <A HREF="lex.html#lex.charset">lex.charset</A>
 paragraph 3).

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

<P>In 2.2&nbsp;



 <A HREF="lex.html#lex.charset">lex.charset</A>
 paragraph 3,
after the sentence</P>

<BLOCKQUOTE>
For each basic execution character
set, the values of the members shall be non-negative and distinct
from one another.
</BLOCKQUOTE>

insert the following:

<BLOCKQUOTE>
In both the source and execution basic character sets, the value of each
character after 0 in the above list of decimal digits shall be one
greater than the value of the previous.
</BLOCKQUOTE>
<BR>
<BR>
<HR>
<A NAME="41"></A>
<H4>41.
  
Clarification of lookup of names after declarator-id
</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>DR
 &nbsp;&nbsp;&nbsp;

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

 <B>Date: </B>1 Sep 1998<BR>




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


<P>Footnotes 26 and 29 both use the phrase "following the function declarator"
incorrectly: the function declarator includes the parameter list, but the
footnotes make clear that they intend what's said to apply to names inside
the parameter list. Presumably the phrase should be "following the function
<I>declarator-id</I>."</P>

<P>
<B>Proposed Resolution (04/99):</B>
Change the text in 3.4.1&nbsp;



 <A HREF="basic.html#basic.lookup.unqual">basic.lookup.unqual</A>
 
paragraph 6 from:</P>
<BLOCKQUOTE>A name used in the definition of a function [<I>footnote:</I> This
refers to unqualified names following the function declarator; such a name
may be used as a type or as a default argument name in the
<I>parameter-declaration-clause</I>,
or may be used in the function body. <I>end footnote</I>] that is ...</BLOCKQUOTE>
to:
<BLOCKQUOTE>A name used in the definition of a function following the function's
<I>declarator-id [footnote:</I>
This refers to unqualified names that occur, for instance, in a type or
default argument expression in the <I>parameter-declaration-clause</I>
or used in the function body. <I>end footnote</I>] that is ...</BLOCKQUOTE>
Change the text in 3.4.1&nbsp;



 <A HREF="basic.html#basic.lookup.unqual">basic.lookup.unqual</A>
paragraph 8 from:
<BLOCKQUOTE>A name used in the definition of a function that is a member
function (9.3&nbsp;



 <A HREF="class.html#class.mfct">class.mfct</A>
)
[<I>footnote:</I> That is, an unqualified name following the function
declarator; such a name may be used as a type or as a default argument
name in the <I>parameter-declaration-clause</I>, or may be used in the function
body, or, if the function is a constructor, may be used in the expression
of a <I>mem-initializer</I>. <I>end footnote</I>] of class <TT>X</TT> shall be ...</BLOCKQUOTE>
to:
<BLOCKQUOTE>A name used in the definition of a member function
(9.3&nbsp;



 <A HREF="class.html#class.mfct">class.mfct</A>
) of
class <TT>X</TT> following the function's <I>declarator-id</I>
[<I>footnote:</I>
That is, an unqualified name that occurs, for instance, in a type or default
argument expression in the <I>parameter-declaration-clause</I>, in the
function body, or in an expression of a <I>mem-initializer</I> in a constructor
definition.
<I>end footnote</I>] shall be ...</BLOCKQUOTE>
<BR>
<BR>
<HR>
<A NAME="139"></A>
<H4>139.
  
Error in <TT>friend</TT> lookup example
</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>DR
 &nbsp;&nbsp;&nbsp;

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

 <B>Date: </B>14 Jul 1999
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Miller<BR>



<P>The example in
3.4.1&nbsp;



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

<PRE>
    typedef int f;
    struct A {
        friend void f(A &amp;);
        operator int();
        void g(A a) {
            f(a);
        }
    };
</PRE>

Regardless of the resolution of other issues concerning the lookup
of names in <TT>friend</TT> declarations, this example is ill-formed
(the function and the typedef cannot exist in the same scope).

<P>One possible repair of the example would be to make <TT>f</TT>
a class with a constructor taking either <TT>A</TT> or <TT>int</TT>
as its parameter.</P>

<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_active.html#143">143</A>,
<A HREF="
     cwg_closed.html#165">165</A>, and
<A HREF="
     cwg_defects.html#166">166</A>.)</P>

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

<OL>

<LI>
<P>Change the example in 3.4.1&nbsp;



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

<PRE>
    typedef int f;
    namespace N {
        struct A {
            friend int f(A &amp;);
            operator int();
            void g(A a) {
                int i = f(a);
                      // f is the typedef, not the friend function:
                      // equivalent to int(a)
            }
        };
    }
</PRE>
</LI>

<LI>
<P>Delete the sentence immediately following the example:</P>

<BLOCKQUOTE>

The expression <TT>f(a)</TT> is a <I>cast-expression</I>
equivalent to <TT>int(a)</TT>.

</BLOCKQUOTE>
</LI>

</OL>

<BR>
<BR>
<HR>
<A NAME="33"></A>
<H4>33.
  
Argument dependent lookup and overloaded functions
</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>DR
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Jason Merrill
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>15 Jul 1998<BR>




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


<P>If an argument used for lookup is the address of a group of overloaded
functions, are there any associated namespaces or classes? What if it's
the address of a function template?</P>

<P>My inclination is to say no to both.</P>

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

<P>We discussed this on the reflector a few weeks ago. I'll leave the template
case for the Core III experts, but I'd find it surprising if the overload
case weren't handled as the obvious generalization of the single-function
case. For a single function, the associated namespaces are those of the
types used in the parameters and return type; I would expect that using
an overloaded function name would simply be the union of the namespaces
from the members of the overload set. That would be the simplest and most
intuitive, IMHO &mdash; is there an argument for doing it differently?</P>

<P>
<B>Proposed Resolution (04/99):</B>
In 3.4.2&nbsp;



 <A HREF="basic.html#basic.lookup.koenig">basic.lookup.koenig</A>
 paragraph 2,
add following the last bullet in the list of associated classes and namespaces
for various argument types (not a bullet itself because overload sets and
templates do not have a type):</P>
<BLOCKQUOTE>In addition, if the argument is the name or address of a set
of overloaded functions and/or function templates, its associated classes
and namespaces are the union of those associated with each of the members
of the set: the namespace in which the function or function template is
defined and the classes and namespaces associated with its (non-dependent)
parameter types and return type.</BLOCKQUOTE>
<BR>
<BR>
<HR>
<A NAME="90"></A>
<H4>90.
  
Should the enclosing class be an "associated class" too?
</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>DR
 &nbsp;&nbsp;&nbsp;

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

 <B>Date: </B>2 Feb 1999<BR>




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


<P>Section
3.4.2&nbsp;



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

 includes the following:</P>
<UL>
<LI>
If T is a class type, its associated classes are the class itself and its
direct and indirect base classes. Its associated namespaces are the namespaces
in which its associated classes are defined.</LI>

<LI>
If T is a union or enumeration type, its associated namespace is the namespace
in which it is defined. If it is a class member, its associated class is
the member's class; else it has no associated class.</LI>
</UL>
Note that for a union, the enclosing class is an "associated class", but
for a class type the enclosing class is not an "associated class". This
results in some surprising behavior, as shown in the example below.
<PRE>
    struct A {
        union U {};
        friend void f(U);
    };
            
    struct B {
        struct S {};
        friend void f(S);
    };
             
    int main() { 
        A::U    u; 
        f(u);        // okay: A is an associated class
        B::S    s;
        f(s);        // error: no matching f(), B is not an associated class
    }

</PRE>
Certainly the enclosing class should also be an associated class for nested
class types, shouldn't it?

<P>
<B>Proposed Resolution (10/99):</B>
Change the two referenced bullets to read:</P>
<UL>
<LI>If <TT>T</TT> is a class type (including unions),
its associated classes are:
the class itself; the
class of which it is a member, if any; and its direct and indirect base
classes. Its associated namespaces are the namespaces in which its
associated classes are defined.</LI>

<LI>If <TT>T</TT> is an enumeration type,
its associated namespace is the namespace in
which it is defined. If it is class member, its associated class is the
member's class; else it has no associated class.</LI>
</UL>
(This proposal also addresses
<A HREF="
     cwg_closed.html#91">Core issue 91</A>.)
<BR>
<BR>
<HR>
<A NAME="164"></A>
<H4>164.
  
Overlap between Koenig and normal 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>DR
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Derek Inglis
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>3 Sep 1999
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Spicer<BR>



<P>The description of Koenig lookup in
3.4.2&nbsp;



 <A HREF="basic.html#basic.lookup.koenig">basic.lookup.koenig</A>
 paragraph 1 says,</P>

<BLOCKQUOTE>
...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.
</BLOCKQUOTE>

Does this mean that Koenig lookup does <I>not</I> search namespaces
that were already searched during the usual unqualified lookup?  The
answer is academic except for the two-stage lookup during template
instantiation.  If a given namespace is searched in the context of the
template definition, are declarations in that namespace in the
instantiation context ignored during the Koenig lookup?  For instance,

<PRE>
    void f(int);

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

    enum E { e };

    void f(E);

    void h() {
        g(e);
    }
</PRE>

In this example, the call <TT>f(t)</TT> in the template function will
resolve to <TT>f(E)</TT> if Koenig lookup reexamines already-searched
namespaces and to <TT>f(int)</TT> if not.

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

<P>Immediately preceding the example
at the end of
3.4.2&nbsp;



 <A HREF="basic.html#basic.lookup.koenig">basic.lookup.koenig</A>
 paragraph 2, add
the following:</P>

<BLOCKQUOTE>
[<I>Note:</I> the namespaces and classes associated with the argument
types can include namespaces and classes already considered by the
ordinary unqualified lookup.]
</BLOCKQUOTE>
<BR>
<BR>
<HR>
<A NAME="85"></A>
<H4>85.
  
Redeclaration of member class
</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>DR
 &nbsp;&nbsp;&nbsp;

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

 <B>Date: </B>25 Jan 1999
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Adamczyk<BR>



<P>In
3.4.4&nbsp;



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

 paragraph 3, there is the example</P>
<PRE>
    struct Base {
        // ...
        struct Data { /* ... */ };  // <I>Defines nested </I>Data
        struct Data;                // <I>OK: Redeclares nested </I>Data
    };
</PRE>

The final redeclaration is invalid according to
9.2&nbsp;



 <A HREF="class.html#class.mem">class.mem</A> paragraph 1 last sentence.

<P>
<B>Proposed resolution (10/00):</B> Remove the line</P>

<PRE>
        struct Data;                // <I>OK: Redeclares nested </I>Data
</PRE>

<P>See also
<A HREF="
     cwg_active.html#36">Core issue 36</A>
 and
<A HREF="
     cwg_defects.html#56">Core issue 56</A>.</P>
<BR>
<BR>
<HR>
<A NAME="216"></A>
<H4>216.
  
Linkage of nameless class-scope enumeration types
</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>DR
 &nbsp;&nbsp;&nbsp;

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

 <B>Date: </B>13 Mar 2000
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Vandevoorde<BR>



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


3.5&nbsp;



 <A HREF="basic.html#basic.link">basic.link</A> paragraph 4 says (among other things):

<BLOCKQUOTE>
A name having namespace scope has external linkage if it is the name of
<UL>
<LI>[...]</LI>

<LI>a named enumeration (7.2&nbsp;



 <A HREF="dcl.html#dcl.enum">dcl.enum</A>), or an
unnamed enumeration defined
in a typedef declaration in which the enumeration has the typedef
name for linkage purposes (7.1.3&nbsp;



 <A HREF="dcl.html#dcl.typedef">dcl.typedef</A>) </LI>
</UL>
</BLOCKQUOTE>

That prohibits for example:

<PRE>
    typedef enum { e1 } *PE;
    void f(PE) {}  // Cannot declare a function (with linkage) using a 
		   // type with no linkage.
</PRE>

<P>However, the same prohibition was not made for class scope types.  Indeed,
3.5&nbsp;



 <A HREF="basic.html#basic.link">basic.link</A> paragraph 5 says:</P>

<BLOCKQUOTE>
In addition, a member function, static data member, class or 
enumeration of class scope has external linkage if the name of the
class has external linkage.
</BLOCKQUOTE>

<P>That allows for:</P>

<PRE>
    struct S {
       typedef enum { e1 } *MPE;
       void mf(MPE) {}
    };
</PRE>

<P>My guess is that this is an unintentional consequence of
3.5&nbsp;



 <A HREF="basic.html#basic.link">basic.link</A> paragraph 5, but I would like confirmation
on that.</P>

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

<P>Change text in 3.5&nbsp;



 <A HREF="basic.html#basic.link">basic.link</A> paragraph 5 from:</P>

<BLOCKQUOTE>

In addition, a member function, static data member, class or
enumeration of class scope has external linkage if the name of the
class has external linkage.

</BLOCKQUOTE>

to: 

<BLOCKQUOTE>

In addition, a member function, a static data member, a named class or
enumeration of class scope, or an unnamed class or enumeration defined
in a class-scope typedef declaration such that the class or
enumeration has the typedef name for linkage purposes
(7.1.3&nbsp;



 <A HREF="dcl.html#dcl.typedef">dcl.typedef</A>),
has external linkage if the name of the class has external linkage.

</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="89"></A>
<H4>89.
  
Object lifetime does not account for reference rebinding
</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>DR
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>AFNOR
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>27 Oct 1998
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Miller<BR>



<BR>From J16/98-0026 = WG21 N1169, "Proposed Defect Reports on ISO/IEC
14882, Programming Languages - C++":
<BLOCKQUOTE>
A reference is rebindable. This is surprising and unnatural. This can
also cause subtle optimizer bugs.

<P>Example:</P>
<PRE>
    struct T {
        int&amp; ri;
        T (int&amp; r) : ri (r) { }
    };
    
    void bar (T*);
    
    void foo () {
        int i;
        T x (i);
        x.ri = 3;   // the optimizer understands that this is really i = 3
        bar (&amp;x);
        x.ri = 4;   // optimizer assumes that this writes to i, but this is incorrect
    }
    
    int gi;
    
    void bar (T* p) {
        p-&gt;~T ();
        new (p) T (gi);
    }
</PRE>
If we replace <TT>T&amp;</TT> with <TT>T* const</TT> in the example then
undefined behavior result and the optimizer is correct.

<P>Proposal: make <TT>T&amp;</TT> equivalent to <TT>T* const</TT> by extending
the scope of
3.8&nbsp;



 <A HREF="basic.html#basic.life">basic.life</A>
 paragraph
9 to references.</P>
</BLOCKQUOTE>
<P>(See also J16/99-0005 = WG21 N1182, "Proposed Resolutions for Core
Language Issues 6, 14, 20, 40, and 89")</P>

<P>In addition, Lisa Lippincott pointed out the following example:</P>

<PRE>
    void f( const bool * );
    void g();

    int main() {
       const bool *b = new const bool( false );
       f(b);
       if (*b)
          g();
    }

    void f( const bool *b ) {
       new ( const_cast&lt;bool *&gt;(b) ) const bool( true );
    }
</PRE>

<P>The proposed wording in the paper would still permit this usage and
thus prevent an optimizer from eliminating the call to <TT>g()</TT>.</P>

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

<P>Add a new bullet to the list of restrictions in
3.8&nbsp;



 <A HREF="basic.html#basic.life">basic.life</A>
paragraph 7, following the second bullet ("the new object is of the same
type..."):</P>
<UL>
<LI>
the type of the original object is not const-qualified, and,
if a class type, does not contain any non-static
data member whose type is const-qualified or a reference type, and</LI>
</UL>
<BR>
<BR>
<HR>
<A NAME="93"></A>
<H4>93.
  
Missing word in 3.8 <U>basic.life</U> paragraph 2
</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>DR
 &nbsp;&nbsp;&nbsp;

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

 <B>Date: </B>6 Feb 1999<BR>




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


<P>The text of
3.8&nbsp;



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

 paragraph
2 currently reads,</P>
<UL>[<I>Note:</I> the lifetime of an array object or of an object of
type (3.9&nbsp;



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


) starts...]</UL>
<P>The phrase "an object of type" is obviously incorrect. I believe it should
read "an object of POD type." Does anyone disagree?</P>

<P>
<B>Proposed Resolution (10/99):</B>
As suggested.</P>
<BR>
<BR>
<HR>
<A NAME="43"></A>
<H4>43.
  
Copying base classes (PODs) using memcpy
</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>DR
 &nbsp;&nbsp;&nbsp;

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

 <B>Date: </B>15 Sep 1998<BR>




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


<P>Can you use memcpy on non-member POD subobjects of non-POD objects?</P>

<P>In 3.9&nbsp;



 <A HREF="basic.html#basic.types">basic.types</A>
 paragraphs 2 and 3 we have:</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>*. 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 elided]</I>
<BLOCKQUOTE>*[<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>. <I>end footnote</I>]</BLOCKQUOTE>
For any POD type <TT>T</TT>, if two pointers to <TT>T</TT> point
to distinct <TT>T</TT> objects <TT>obj1</TT>
and <TT>obj2</TT>, 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>
Paragraph 3 doesn't repeat the restriction of paragraph 2. Should it be
assumed? Otherwise only complete POD types are copyable to an array of
<TT>char</TT> and back, but scribbling over subobjects is OK.
(Or perhaps a "distinct <TT>T</TT> object" is a complete object...)

<P>
<B>Proposed Resolution (04/99):</B>
Change the text in 3.9&nbsp;



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

paragraph 2 from:</P>
<BLOCKQUOTE>For any complete POD object type <TT>T</TT>, ...</BLOCKQUOTE>
to:
<BLOCKQUOTE>For any object (other than a base class subobject) of POD type
<TT>T</TT>, ...</BLOCKQUOTE>
Change the text in 3.9&nbsp;



 <A HREF="basic.html#basic.types">basic.types</A>
 paragraph 3 from:
<BLOCKQUOTE>For any POD type <TT>T</TT>, if two pointers to <TT>T</TT>
point to distinct <TT>T</TT> objects <TT>obj1</TT> and <TT>obj2</TT>,</BLOCKQUOTE>
to:
<BLOCKQUOTE>For any POD type <TT>T</TT>, if two pointers to <TT>T</TT>
point to distinct <TT>T</TT> objects <TT>obj1</TT> and <TT>obj2</TT>,
where neither <TT>obj1</TT> nor <TT>obj2</TT> is a base class subobject,
...</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="149"></A>
<H4>149.
  
Accessibility and ambiguity
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>4.10&nbsp;



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

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

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

 <B>Date: </B>31 Jul 1999
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Adamczyk<BR>



<P>The Standard uses confusing terminology when referring to
accessibility in connection with ambiguity.  For instance:</P>

<P>4.10&nbsp;



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

<BLOCKQUOTE>
If <TT>B</TT> is an inaccessible or ambiguous base ...
</BLOCKQUOTE>

5.2.7&nbsp;



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

<BLOCKQUOTE>
... has an unambiguous public base ...
</BLOCKQUOTE>

10.3&nbsp;



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

<BLOCKQUOTE>
... is an unambiguous direct or indirect base ... and
is accessible ...
</BLOCKQUOTE>

15.3&nbsp;



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

<BLOCKQUOTE>
not involving conversions to pointers to private or
protected or ambiguous classes
</BLOCKQUOTE>

<P>The phrase "unambiguous public base" is unfortunate as it
could mean either "an
unambiguous base not considering accessibility, which is public"
or "an
unambiguous base considering only the publicly accessible bases."
I believe the
former interpretation correct, as accessibility is applied after visibility
(11&nbsp;



 <A HREF="access.html#class.access">class.access</A>
 paragraph 4)
and ambiguity is described in terms of visibility
(10.2&nbsp;



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

<P>Suggested Resolution:
Use the phrases "public and unambiguous,"
"accessible and unambiguous,"
"non-public or ambiguous," or "inaccessible or ambiguous" as appropriate.</P>

<P>
<B>Proposed resolution (10/00):</B>
<UL>
<LI>
5.2.7&nbsp;



 <A HREF="expr.html#expr.dynamic.cast">expr.dynamic.cast</A>
 paragraph 8,
bullet 2: change "unambiguous public base class" to "unambiguous
and public base class"</LI>
<LI>
10.3&nbsp;



 <A HREF="derived.html#class.virtual">class.virtual</A>
 paragraph 5: change
"the class in the return type... is an unambiguous direct or
indirect base class... and is accessible in <TT>D</TT>" to "the
class in the return type... is an unambiguous and accessible direct
or indirect base class..."</LI>
</UL>
</P>
<BR>
<BR>
<HR>
<A NAME="122"></A>
<H4>122.
  
<I>template-id</I>s as <I>unqualified-id</I>s
</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>DR
 &nbsp;&nbsp;&nbsp;

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

 <B>Date: </B>3 June 1999
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Miller<BR>




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


<P>5.1&nbsp;



 <A HREF="expr.html#expr.prim">expr.prim</A>
 paragraph 11 reads,</P>

<BLOCKQUOTE>
A <I>template-id</I> shall be used as an <I>unqualified-id</I> only
as specified in
14.7.2&nbsp;



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



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



 <A HREF="template.html#temp.class.spec">temp.class.spec</A>
.
</BLOCKQUOTE>

<P>What uses of <I>template-id</I>s
as <I>unqualified-id</I>s is this supposed to prevent?  And is the
list of referenced sections correct/complete?  For instance,
what about 14.8.1&nbsp;



 <A HREF="template.html#temp.arg.explicit">temp.arg.explicit</A>,
"Explicit template argument specification?"
Does its absence from the list in
5.1&nbsp;



 <A HREF="expr.html#expr.prim">expr.prim</A> paragraph 11 mean that
"<TT>f&lt;int&gt;()</TT>" is ill-formed?</P>

<P>This is even more confusing when you recall that <I>unqualified-id</I>s
are contained in <I>qualified-id</I>s:</P>

<BLOCKQUOTE>
    <I>qualified-id</I>:
        <TT>::</TT><SUB>opt</SUB>&nbsp;<I>nested-name-specifier</I>&nbsp;<TT>template</TT><SUB>opt</SUB>&nbsp;<I>unqualified-id</I>
</BLOCKQUOTE>

<P>Is the wording intending to say "used as an <I>unqualified-id</I>
that is not part of a <I>qualified-id</I>?"  Or something else?</P>

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

<P>Remove the referenced sentence altogether.</P>

<BR>
<BR>
<HR>
<A NAME="123"></A>
<H4>123.
  
Bad cross-reference
</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>DR
 &nbsp;&nbsp;&nbsp;

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

 <B>Date: </B>3 June 1999<BR>




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


The cross-reference is incorrect in the first
sentence after the grammar in
5.1&nbsp;



 <A HREF="expr.html#expr.prim">expr.prim</A>
 paragraph 7:

<BLOCKQUOTE>
A <I>nested-name-specifier</I> that names a class, optionally
followed by the keyword <TT>template</TT>
(14.8.1&nbsp;



 <A HREF="template.html#temp.arg.explicit">temp.arg.explicit</A>
), ...
</BLOCKQUOTE>

The use of the <TT>template</TT> keyword in this context is discussed
in 14.2&nbsp;



 <A HREF="template.html#temp.names">temp.names</A>
, not
14.8.1&nbsp;



 <A HREF="template.html#temp.arg.explicit">temp.arg.explicit</A>
.  

<BR>
<BR>
<HR>
<A NAME="147"></A>
<H4>147.
  
Naming the constructor
</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>DR
 &nbsp;&nbsp;&nbsp;

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

 <B>Date: </B>21 Feb 1999
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Spicer<BR>



<P>From paper J16/99-0010 = WG21 N1187.</P>

<P>5.1&nbsp;



 <A HREF="expr.html#expr.prim">expr.prim</A>
 paragraph 7 says that
<I>class-name::class-name</I> names the constructor when both
<I>class-name</I> refer to the same class.  (Note the different
perspective, at least, in
12.1&nbsp;



 <A HREF="special.html#class.ctor">class.ctor</A>
 paragraph 1, in which
constructors have no names and are recognized by syntactic context
rather than by name.)</P>

<P>This formulation does not address the case of classes in which a
function template is declared as a constructor, for example:</P>

<PRE>
    template &lt;class T&gt; struct A {
        template &lt;class T2&gt; A(T2);
    };
    template&lt;&gt; template&lt;&gt; A&lt;int&gt;::A&lt;int&gt;(int);
</PRE>

<P>Here there is an ambiguity as to whether the second template argument
list is for the injected class name or for the constructor.</P>

<P>Suggested resolution: restate the rule as a component of name
lookup.  Specifically, if when doing a qualified lookup in a given
class you look up a name that is the same as the name of the class,
the entity found is the constructor and not the injected class name.
In all other cases, the name found is the injected class name.  For
example:</P>

<PRE>
    class B { };
    class A: public B {
        A::B ab;       // B is the inherited injected B
        A::A aa;       // Error: A::A is the constructor
    };
</PRE>

<P>Without this rule some very nasty backtracking is needed.  For
example, if the injected class name could be qualified by its own
class name, the following code would be well-formed:</P>

<PRE>
    template &lt;class T&gt; struct A {
        template &lt;class T2&gt; A(T2);
        static A x;
    };
    template&lt;&gt; A&lt;int&gt;::A&lt;int&gt;(A&lt;int&gt;::x);
</PRE>

<P>Here the declarator for the definition of the static data member
has redundant parentheses, and it's only after seeing the declarator
that the parser can know that the second <TT>A&lt;int&gt;</TT> is the
injected class name rather than the constructor.</P>

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

<P>In
9&nbsp;



 <A HREF="class.html#class">class</A>
 paragraph 2, change</P>

<BLOCKQUOTE>
The <I>class-name</I> is also inserted into the scope of the class
itself.  For purposes of access checking the inserted class name...
</BLOCKQUOTE>

<P>to</P>

<BLOCKQUOTE>
The <I>class-name</I> is also inserted into the scope of the class
itself; this is known as the <I>injected-class-name</I>.  For purposes
of access checking, the injected-class-name...
</BLOCKQUOTE>

<P>Also, in 3.4.3.1&nbsp;



 <A HREF="basic.html#class.qual">class.qual</A>, add the following
before paragraph 2:</P>

<BLOCKQUOTE>
If the <I>nested-name-specifier</I> nominates a class <TT>C</TT>, and the
name specified after the <I>nested-name-specifier</I>, when looked up in
<TT>C</TT>, is the injected-class-name of <TT>C</TT> (clause
9&nbsp;



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

<PRE>
    struct A { A(); };
    struct B: public A { B(); };

    A::A() { }
    B::B() { }

    B::A ba;    // object of type A
    A::A a;     // error, A::A is not a type name
</PRE>

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

<P>Also, change 3.4&nbsp;



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

<BLOCKQUOTE>

Because the name of a class is inserted in its class scope (clause
9&nbsp;



 <A HREF="class.html#class">class</A>), the name of a class is also considered a
member of that class for the purposes of name hiding and lookup.

</BLOCKQUOTE>

<P>to</P>

<BLOCKQUOTE>

The injected-class-name of a class (clause 9&nbsp;



 <A HREF="class.html#class">class</A>) is
also considered to be a member of that class for the purposes of name
hiding and lookup.

</BLOCKQUOTE>

<P>(See also <A HREF="
     cwg_defects.html#194">issue 194</A>.)</P>
<BR>
<BR>
<HR>
<A NAME="113"></A>
<H4>113.
  
Visibility of called function
</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>DR
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Christophe de Dinechin
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>5 May 1999
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Vandevoorde<BR>




<P>From reflector messages 8046-8047.</P>


<P>
<B>Christophe de Dinechin:</B>
In 5.2.2&nbsp;



 <A HREF="expr.html#expr.call">expr.call</A>
, paragraph 2 reads:</P>

<BLOCKQUOTE>
If no declaration of the called function is visible from the scope  of
the call the program is ill-formed.
</BLOCKQUOTE>

I think nothing there or in the previous paragraph indicates that  
this does not apply to calls through pointer or virtual calls.

<P>
<B>Mike Miller:</B>
"The called function" is unfortunate phraseology; it makes it
sound as if it's referring to the function actually called, as
opposed to the identifier in the postfix expression.  It's
wrong with respect to Koenig lookup, too (the declaration need
not be visible if it can be found in a class or namespace
associated with one or more of the arguments).</P>

<P>In fact, this paragraph should be a note.  There's a general
rule that says you have to find an unambiguous declaration of
any name that is used
(3.4&nbsp;



 <A HREF="basic.html#basic.lookup">basic.lookup</A>
 paragraph 1);
the only reason this paragraph
is here is to contrast with C's implicit declaration of called
functions.</P>

<P>
<B>Proposed resolution:</B>
</P>
Change section 5.2.2&nbsp;



 <A HREF="expr.html#expr.call">expr.call</A> paragraph 2 from:
<BLOCKQUOTE>If no declaration of the called function is visible from the
scope of the call the program is ill-formed.</BLOCKQUOTE>
to:
<BLOCKQUOTE>[<I>Note:</I> if a function or member function name is used,
and name lookup (3.4&nbsp;



 <A HREF="basic.html#basic.lookup">basic.lookup</A>) does not find a
declaration of that name,
the program is ill-formed. No function is implicitly declared by such
a call. ]</BLOCKQUOTE>

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

<BR>
<BR>
<HR>
<A NAME="52"></A>
<H4>52.
  
Non-static members, member selection and access checking
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>5.2.5&nbsp;



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

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

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

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



<P>5.2.5&nbsp;



 <A HREF="expr.html#expr.ref">expr.ref</A>
 paragraph 4 should make
it clear that when a nonstatic member is referenced in a member
selection operation, the type of the left operand is implicitly cast
to the naming class of the member. This allows for the detection of
access and ambiguity errors on that implicit cast.</P>

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

<OL>

<LI>
<P>In 11.2&nbsp;



 <A HREF="access.html#class.access.base">class.access.base</A> paragraph 4, remove the following
from the second note:</P>

<BLOCKQUOTE>

If the member <TT>m</TT> is accessible when named in the naming
class according to the rules below, the access to <TT>m</TT> is
nonetheless ill-formed if the type of <TT>p</TT> cannot be
implicitly converted to type <TT>T</TT> (for example, if <TT>T</TT> is an
inaccessible base class of <TT>p</TT>'s class).

</BLOCKQUOTE>
</LI>

<LI>
<P>Add the following as a new paragraph 5 of
11.2&nbsp;



 <A HREF="access.html#class.access.base">class.access.base</A>:</P>

<BLOCKQUOTE>

If a class member access operator, including an
implicit "<TT>this-&gt;</TT>," is used to access a nonstatic
data member or nonstatic member function, the
reference is ill-formed if the left operand
(considered as a pointer in the "." operator case)
cannot be implicitly converted to a pointer to the
naming class of the right operand.  [<I>Note:</I> this
requirement is in addition to the requirement that the
member be accessible as named.]

</BLOCKQUOTE>
</LI>

<LI>
<P>In 11.2&nbsp;



 <A HREF="access.html#class.access.base">class.access.base</A> paragraph 4, fix a typographical
error by adding the missing right parenthesis following the text</P>

<BLOCKQUOTE>

(including cases where an implicit "<TT>this-&gt;</TT>" is added

</BLOCKQUOTE>
</LI>

<LI>
<P>Add following the first sentence of
5.2.2&nbsp;



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

<BLOCKQUOTE>

If the function is a nonstatic member function, the
"<TT>this</TT>" parameter of the function (9.3.2&nbsp;



 <A HREF="class.html#class.this">class.this</A>) shall
be initialized with a pointer to the object of the
call, converted as if by an explicit type conversion
(5.4&nbsp;



 <A HREF="expr.html#expr.cast">expr.cast</A>).  [<I>Note:</I> there is no access checking on
this conversion; the access checking is done as part of
the (possibly implicit) class member access operator.
See 11.2&nbsp;



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

</BLOCKQUOTE>
</LI>

</OL>
<BR>
<BR>
<HR>
<A NAME="53"></A>
<H4>53.
  
Lvalue-to-rvalue conversion before certain static_casts
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>5.2.9&nbsp;



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

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

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

 <B>Date: </B>13 Oct 1998
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Nelson<BR>



<P>Section 5.2.9&nbsp;



 <A HREF="expr.html#expr.static.cast">expr.static.cast</A>
 paragraph 6
should make it clear that when any of the
"inverse of any standard conversion sequence" static_casts are done, the
operand undergoes the lvalue-to-rvalue conversions first.</P>

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

<P>In 5.2.9&nbsp;



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

<BLOCKQUOTE>

can be performed explicitly using <TT>static_cast</TT> subject to the
restriction that the explicit conversion does not cast away constness
(5.2.11&nbsp;



 <A HREF="expr.html#expr.const.cast">expr.const.cast</A>), ...

</BLOCKQUOTE>

<P>to</P>

<BLOCKQUOTE>

can be performed explicitly using <TT>static_cast</TT>.  <B>The
lvalue-to-rvalue (4.1&nbsp;



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



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



 <A HREF="conv.html#conv.func">conv.func</A>) conversions are applied to the operand.  Such a
<TT>static_cast</TT> is</B> subject to the restriction that it does
not cast away constness (5.2.11&nbsp;



 <A HREF="expr.html#expr.const.cast">expr.const.cast</A>), ...

</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="128"></A>
<H4>128.
  
Casting between enum types
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>5.2.9&nbsp;



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

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

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

 <B>Date: </B>10 June 1999
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Nelson<BR>




<P>From reflector messages core-8096 through 8100.</P>


<P>According to 7.2&nbsp;



 <A HREF="dcl.html#dcl.enum">dcl.enum</A>
 paragraph 9,
it is permitted to convert from one enumeration type to another.
However, neither 5.2.9&nbsp;



 <A HREF="expr.html#expr.static.cast">expr.static.cast</A>

nor 5.4&nbsp;



 <A HREF="expr.html#expr.cast">expr.cast</A>
 allows this
conversion.</P>

<P>
<B>Proposed resolution (10/00):</B> Change the first two sentences of
5.2.9&nbsp;



 <A HREF="expr.html#expr.static.cast">expr.static.cast</A>
 paragraph 7 to read</P>

<BLOCKQUOTE>
A value of integral <B>or enumeration</B> type can be explicitly
converted to an enumeration type.  The value is unchanged if the
<B>original</B> value is within the range of the enumeration values
(7.2&nbsp;



 <A HREF="dcl.html#dcl.enum">dcl.enum</A>
).
</BLOCKQUOTE>
<BR>
<BR>
<HR>
<A NAME="137"></A>
<H4>137.
  
<TT>static_cast</TT> of <I>cv</I> <TT>void*</TT>
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>5.2.9&nbsp;



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

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

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

 <B>Date: </B>13 July 1999
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Adamczyk<BR>




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


<P>According to 5.2.9&nbsp;



 <A HREF="expr.html#expr.static.cast">expr.static.cast</A>

paragraph 10,</P>

<BLOCKQUOTE>
An rvalue of type "pointer to <I>cv</I> <TT>void</TT>" can be explicitly
converted to a pointer to object type.
</BLOCKQUOTE>

No requirements are stated regarding the cv-qualification of the
pointer to object type.  Contrast this with the formula used in
paragraphs 5, 8, and 9, where the treatment of cv-qualification
is explicit, requiring that the target type be at least as
cv-qualified as the source.

There is an apparently general requirement on all forms of
<TT>static_cast</TT> in
5.2.9&nbsp;



 <A HREF="expr.html#expr.static.cast">expr.static.cast</A>
 paragraph 1 that it
"shall not cast away constness."
Assuming that this restriction applies to paragraph 10, since there is
no explicit exception to the general rule, that still leaves
open the question of whether one can "cast away volatility"
in a conversion from <TT>volatile void*</TT> to a pointer to object
type.

Should 5.2.9&nbsp;



 <A HREF="expr.html#expr.static.cast">expr.static.cast</A>
 paragraph 10
be rewritten to handle cv-qualification in
the same way as paragraphs 5, 8, and 9?

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

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



 <A HREF="expr.html#expr.static.cast">expr.static.cast</A>
 paragraph 10 to</P>
<BLOCKQUOTE>
An rvalue of type "pointer to <I>cv1</I> <TT>void</TT>" can be
converted to an rvalue of type "pointer to <I>cv2</I> <TT>T</TT>", where
<TT>T</TT> is an object type and <I>cv2</I> is the same cv-qualification
as, or greater cv-qualification than, <I>cv1</I>.
</BLOCKQUOTE>
<BR>
<BR>
<HR>
<A NAME="74"></A>
<H4>74.
  
Enumeration value in direct-new-declarator
</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>DR
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Jason Merrill
 &nbsp;&nbsp;&nbsp;

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




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


<P>5.3.4&nbsp;



 <A HREF="expr.html#expr.new">expr.new</A>

paragraph 6 says:</P>
<BLOCKQUOTE>The expression in a <I>direct-new-declarator</I> shall have integral
type (3.9.1&nbsp;



 <A HREF="basic.html#basic.fundamental">basic.fundamental</A>
) with a non-negative
value.</BLOCKQUOTE>
I assume the intent was to also allow enumeral types, as we do in
5.2.1&nbsp;



 <A HREF="expr.html#expr.sub">expr.sub</A>

?

<P>
<B>Proposed Resolution (10/99):</B>
Replace "integral type" by "integral or enumeration type" in
5.3.4&nbsp;



 <A HREF="expr.html#expr.new">expr.new</A>
 paragraph 6.</P>
<BR>
<BR>
<HR>
<A NAME="127"></A>
<H4>127.
  
Ambiguity in description of matching deallocation function
</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>DR
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Alexander Schiemann
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>8 June 1999
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Crowl<BR>



<P>If a placement allocation function has default arguments for all its
parameters except the first, it can be called using non-placement
syntax.  In such a case, it is not clear whether
the deallocation function to be called if the constructor terminates
by throwing an expression is determined on the basis of
the syntax of the <I>new-expression</I> (i.e., a non-placement
deallocation function)
or the declaration of the selected (placement) allocation function.
5.3.4&nbsp;



 <A HREF="expr.html#expr.new">expr.new</A>
 paragraph 19 indicates
that the deallocation function must match the declaration of the
allocation function.
However, 15.2&nbsp;



 <A HREF="except.html#except.ctor">except.ctor</A>
 says that the
distinction is based on whether the <I>new-expression</I> contains
a <I>new-placement</I> or not.</P>

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

<P>In 15.2&nbsp;



 <A HREF="except.html#except.ctor">except.ctor</A> paragraph 2, replace</P>

<BLOCKQUOTE>

If the object or array was allocated in a <I>new-expression</I> and
the <I>new-expression</I> does not contain a <I>new-placement</I>, the
deallocation function (3.7.3.2&nbsp;



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



 <A HREF="special.html#class.free">class.free</A>) is called to free the storage occupied by the object;
the deallocation function is chosen as specified in 5.3.4&nbsp;



 <A HREF="expr.html#expr.new">expr.new</A>. If the object or array was allocated in a
<I>new-expression</I> and the <I>new-expression</I> contains a
<I>new-placement</I>, the storage occupied by the object is
deallocated only if an appropriate placement operator delete is found,
as specified in 5.3.4&nbsp;



 <A HREF="expr.html#expr.new">expr.new</A>.

</BLOCKQUOTE>

<P>with</P>

<BLOCKQUOTE>

If the object or array was allocated in a <I>new-expression</I>, the
matching deallocation function (3.7.3.2&nbsp;



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



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



 <A HREF="special.html#class.free">class.free</A>), if any, is
called to free the storage occupied by the object.

</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="179"></A>
<H4>179.
  
Function pointers and subtraction
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>5.7&nbsp;



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

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

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

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



<P>5.7&nbsp;



 <A HREF="expr.html#expr.add">expr.add</A>
 paragraph 8 explicitly
allows subtraction of two pointers to functions:</P>

<BLOCKQUOTE>
If two pointers point to the same object <B>or function</B>... and the
two pointers are subtracted...
</BLOCKQUOTE>

However, 5.7&nbsp;



 <A HREF="expr.html#expr.add">expr.add</A>
 paragraph 2
requires that two pointers that are subtracted be pointers to an
<B>object</B> type; function pointers are not allowed.

<P>Being able to subtract two pointers to functions doesn't seem
terribly useful, especially considering that subtracting two pointers
to different functions appears to produce undefined behavior rather
than simply a non-zero result, according to paragraph 6:</P>

<BLOCKQUOTE>
Unless both pointers point to elements of the same array object, or
one past the last element of the array object, the behavior is
undefined.
</BLOCKQUOTE>

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

<P>Remove the words <B>or function</B>
from paragraph 8.</P>
<BR>
<BR>
<HR>
<A NAME="73"></A>
<H4>73.
  
Pointer equality
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>5.10&nbsp;



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

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

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

 <B>Date: </B>13 Nov 1998
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Nelson/Miller<BR>




<P>From reflector messages core-7890, 7895, 7896, 7904, 8101-8106.</P>


<P>
<U>Nathan Myers</U>: In
5.10&nbsp;



 <A HREF="expr.html#expr.eq">expr.eq</A>
, we have:</P>
<BLOCKQUOTE>Pointers to objects or functions of the same type (after pointer
conversions) can be compared for equality. Two pointers of the same type
compare equal if and only if they are both null, both point to the same
object or function, or both point one past the end of the same array.</BLOCKQUOTE>
What does this say, when we have
<PRE>
    int i[1];
    int j[1];
</PRE>
about the expression <TT>(i+1 == j)</TT> ? It seems to require padding
between <TT>i[0]</TT> and <TT>j[0]</TT> so that the comparison will come
out false.
<BR>
<BR>I think this may be a defect, in that the quoted paragraph extends
operator=='s domain too far beyond operator&lt;'s. It should permit
(but not require) an off-the-end pointer to compare equal to another
object, but not to any element of the same array.

<P>
<U>Mike Miller</U>: I think this is reading more into the statement
in
5.10&nbsp;



 <A HREF="expr.html#expr.eq">expr.eq</A>

 paragraph 1 than is actually
there. What does it mean for a pointer to "point to" an object?
I can't find anything that definitively says that <TT>i+1</TT> cannot "point
to" <TT>j[0]</TT> (although it's obviously not required to do so).
If <TT>i+1</TT> is allowed to "point to" <TT>j[0]</TT>, then <TT>i+1==j</TT>
is allowed to be true, and there's no defect. There are places where
aliasing is forbidden, but the N+1th element of an array doesn't appear
to be one of them.</P>

<P>To put it another way, "points to" is undefined in the Standard. The
only definition I can think of that encompasses the possible ways in which
a pointer can get its value (e.g., the implementation-defined conversion
of an arbitrary integer value to a pointer) is that it means "having the
same value representation as would be produced by applying the (builtin)
&amp; operator to an lvalue expression designating that object".
In other words, if the bits are right, it doesn't matter how you produced
the value, as long as you didn't perform any operations that have undefined
results. The expression <TT>i+1</TT> is not undefined, so if the
bits of <TT>i+1</TT> are the same as those of <TT>&amp;j[0]</TT>, then
<TT>i+1</TT> "points to" <TT>j[0]</TT> and <TT>i+i==j</TT> is allowed to
be true.</P>

<P>
<U>Tom MacDonald</U>: C9X contains the following words for the "=="
operator:</P>
<BLOCKQUOTE>Two pointers compare equal if both are null pointers, both
are pointers to the same object (including a pointer to an object and a
subobject at its beginning) or function, both are pointers to one
past the last element of the same array object, or one is a pointer to
one past the end of one array object and the other is a pointer to the
start of a different array object that happens to immediately follow the
first array object in the address space.</BLOCKQUOTE>
<U>Matt Austern</U>: I don't think there's anything wrong with saying that
the result of
<PRE>
    int x[1];
    int y[1]; 
    std::cout &lt;&lt; (y == x + 1) &lt;&lt; std::endl;
</PRE>
is implementation defined, or even that it's undefined.

<P>
<U>Mike Miller</U>: A similar question could be raised about different
objects that (sequentially) share the same storage. Consider the following:</P>
<PRE>
    struct B {
        virtual void f();
    };
    struct D1: B { };
    struct D2: B { };
    void g() {
        B* bp1 = new D1;
        B* bp2 = new (bp1) D2;
        bp1 == bp2; // ???
    }
</PRE>
Section
3.8&nbsp;



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

 paragraph 5 does
not list this kind of comparison among the pointer operations that cause
undefined behavior, so presumably the comparison is allowed. However,
5.10&nbsp;



 <A HREF="expr.html#expr.eq">expr.eq</A>

paragraph 1 describes pointer comparison in terms of "[pointing] to the
same object," which <TT>bp1</TT> and <TT>bp2</TT> clearly do not do. How
should we describe the result of this comparison?

<P>
<U>Jason Merrill</U>:
When you consider comparing pointers to void, this seems to suggest that no
two objects can have the same address, depending on your interpretation of
"point to the same object."  This would cripple the empty base
optimization.</P>

<P>3.9.2&nbsp;



 <A HREF="basic.html#basic.compound">basic.compound</A>
 refers to 'pointers
to void or objects or functions'.  In that case,
5.10&nbsp;



 <A HREF="expr.html#expr.eq">expr.eq</A>
 does
not allow you to compare them; it only allows comparing pointers to
objects and functions.</P>

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

<UL>

<LI>

In 3.9.2&nbsp;



 <A HREF="basic.html#basic.compound">basic.compound</A> paragraph 3, add the following
wording immediately preceding, "The value representation of pointer
types is implementation-defined":

<BLOCKQUOTE>

A valid value of an object pointer type represents either the address
of a byte in memory (1.7&nbsp;



 <A HREF="intro.html#intro.memory">intro.memory</A>) or a null pointer
(4.10&nbsp;



 <A HREF="conv.html#conv.ptr">conv.ptr</A>).  If an object of type <TT>T</TT> is
located at an address <TT>A</TT>, a pointer of type <I>cv</I>
<TT>T*</TT> whose value is the address <TT>A</TT> is said to <I>point
to</I> that object, regardless of how the value was obtained.
[<I>Note:</I> for instance, the address one past the end of an array
(5.7&nbsp;



 <A HREF="expr.html#expr.add">expr.add</A>) would be considered to point to an
unrelated object of the array's element type that might be located at
that address.]

</BLOCKQUOTE>

</LI>
<LI>

In 5.10&nbsp;



 <A HREF="expr.html#expr.eq">expr.eq</A> paragraph 1, change the sentence
beginning, "Two pointers of the same type..." to read:

<BLOCKQUOTE>

Two pointers of the same type compare equal if and only if they are
both null, both point to the same function, or both represent the same
address (3.9.2&nbsp;



 <A HREF="basic.html#basic.compound">basic.compound</A>).

</BLOCKQUOTE>

</LI>
</UL>

<P>(See also paper J16/00-0011 = WG21 N1234.)</P>
<BR>
<BR>
<HR>
<A NAME="188"></A>
<H4>188.
  
Comma operator and rvalue conversion
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>5.18&nbsp;



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

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

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

 <B>Date: </B>20 Dec 1999
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Crowl<BR>




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


<P>Given</P>
 
<PRE>
    char arr[100];
    sizeof(0,arr);
</PRE>
 
<P>What does the <TT>sizeof</TT> expression return?  According to
5.18&nbsp;



 <A HREF="expr.html#expr.comma">expr.comma</A>
 paragraph 1,
the comma operator yields
an lvalue if the second argument is an lvalue.  Since
4.2&nbsp;



 <A HREF="conv.html#conv.array">conv.array</A>
 paragraph 1 says that the
array-to-pointer conversion yields an rvalue, it seems that
<TT>sizeof</TT> should see an array type and give the answer <TT>100</TT>.
If so, the value of the <TT>sizeof</TT> expression would be
different from that of the corresponding expression in C, but there
is nothing in Annex
C&nbsp;



 <A HREF="diff.html#diff">diff</A>
to indicate that an incompatible change was intended.</P>

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

<P>Add the following as paragraph 3 of C.1.3&nbsp;



 <A HREF="diff.html#diff.expr">diff.expr</A>:</P>

<BLOCKQUOTE>

<P>
<B>5.16, 5.17, 5.18</B>
</P>

<P>
<B>Change:</B> The result of a conditional expression, an
assignment expression, or a comma expression may be an lvalue.<BR>
<B>Rationale:</B> C++ is an object-oriented language, placing
relatively more emphasis on lvalues. For example, functions may return
lvalues.<BR>
<B>Effect on original feature:</B> Change to semantics of well-defined
feature.  Some C expressions that implicitly rely on lvalue-to-rvalue
conversions will yield different results.  For example,

<PRE>
    char arr[100];
    sizeof(0, arr)
</PRE>

yields <TT>100</TT> in C++ and <TT>sizeof(char*)</TT> in C.<BR>
<B>Difficulty of converting:</B> Programs must add explicit casts to
the appropriate rvalue.<BR>
<B>How widely used:</B> Rare.
</P>

</BLOCKQUOTE>
<BR>
<BR>
<HR>
<A NAME="94"></A>
<H4>94.
  
Inconsistencies in the descriptions of 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>DR
 &nbsp;&nbsp;&nbsp;

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

 <B>Date: </B>8 Feb 1999
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Miller<BR>



<P>From
reflector messages core-7960, 7961, 7962 and 7965.</P>


<OL>
<LI>
According to
9.4.2&nbsp;



 <A HREF="class.html#class.static.data">class.static.data</A>
 paragraph 4, a static const integral or const enumeration data member initialized
with an integral constant expression "can appear in integral constant expressions
<B>within its scope</B>" [emphasis mine]. This means that the following
is not permitted:

<PRE>
    struct S {
        static const int c = 5;
    };
    int a[S::c];    // error: S::c not in scope
</PRE>
Is this restriction intentional? If so, what was the rationale for the
restriction?

<P>
<U>Bjarne Stroustrup</U>: I think that once you have said <TT>S::</TT>,
<TT>c</TT> is in scope so that</P>
<PRE>
    int a[S::c];
</PRE>
is ok.
    
<P>
<U>Mike Miller</U>: I'd like to think that's what it meant, but I
don't believe that's what it said. According to
3.3&nbsp;



 <A HREF="basic.html#basic.scope">basic.scope</A>
 paragraph 1, the scope of
a name is the region "in which that name may be used as an unqualified
name." You can, indeed, use a qualified name to refer to a name that
is not in scope, but that only goes to reinforce my point that
"<TT>S::c</TT>" is not in scope at the point where the expression
containing it is used. I think the phrase "within its scope" is at
best misleading and should be removed. (Unless there's a reason I'm
missing for restricting the use of static member constants to their
scope.)</P>
</LI>
<LI>
According to 5.19&nbsp;



 <A HREF="expr.html#expr.const">expr.const</A>
 paragraph
1, integral constant expressions can "involve...const variables or static
data members of integral or enumeration types initialized with constant
expressions." However, in 5.19&nbsp;



 <A HREF="expr.html#expr.const">expr.const</A>
paragraph 3, arithmetic constant expressions cannot include them. This
seems a rather gratuitous distinction and one likely to bite programmers
trained always to use const variables instead of preprocessor definitions.
Again, is there a rationale for the difference?

<P>As far as I can tell from 5.19&nbsp;



 <A HREF="expr.html#expr.const">expr.const</A>
paragraph 2, "arithmetic constant expressions" (as distinct from "integral
constant expressions") are used only in static initializers to distinguish
between static and dynamic initialization. They include floating point
types and exclude non-type template parameters, as well as the const variables
and static data members.</P>
<LI>
<P>There is a minor error in 5.19&nbsp;



 <A HREF="expr.html#expr.const">expr.const</A>
paragraph 2. The first sentence says, "Other expressions are considered
constant expressions only for the purpose of non-local static object initialization."
However, 6.7&nbsp;



 <A HREF="stmt.html#stmt.dcl">stmt.dcl</A>
 paragraph 4 appears
to rely on the same definition dealing with the initialization of local
static objects. I think that the words "non-local" should be dropped and
a cross reference to 6.7&nbsp;



 <A HREF="stmt.html#stmt.dcl">stmt.dcl</A>
added.</P>
</LI>
<LI>
5.19&nbsp;



 <A HREF="expr.html#expr.const">expr.const</A>
paragraph 4 says, "An expression
that designates the address of a member or base class of a non-POD class
object (clause 9) is not an address constant expression (12.7&nbsp;



 <A HREF="special.html#class.cdtor">class.cdtor</A>
)."
    
<P>I'm guessing that should be "non-static member," like the similar
prohibition in 12.7&nbsp;



 <A HREF="special.html#class.cdtor">class.cdtor</A>
 regarding
out-of-lifetime access to members of non-POD class objects.</P>
</LI>
</LI>
</OL>

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

<OL>
<LI>
<P>Remove the phrase "within its scope" in
9.4.2&nbsp;



 <A HREF="class.html#class.static.data">class.static.data</A>
 paragraph 4.</P>
</LI>
<LI>

Replace 5.19&nbsp;



 <A HREF="expr.html#expr.const">expr.const</A> paragraph 3 with the following:

<BLOCKQUOTE>

An <I>arithmetic constant expression</I> shall satisfy the
requirements for an integral constant expression, except that

<UL>
<LI>floating literals need not be cast to integral or enumeration
type, and</LI>
<LI>conversions to floating point types are permitted.</LI>
</UL>

</BLOCKQUOTE>
</LI>
<LI>
<P>This is not a defect; no change is required.  The suggested
wording would be more accurate, but since the effect on local
initialization is unobservable the current wording is adequate.</P>
</LI>

<LI>
<P>Change the referenced sentence in 5.19&nbsp;



 <A HREF="expr.html#expr.const">expr.const</A>
paragraph 4 to "An expression that designates the address of a
subobject of a non-POD class object is not an address constant
expression."</P>
</LI>
</OL>
<BR>
<BR>
<HR>
<A NAME="227"></A>
<H4>227.
  
How many scopes in an <TT>if</TT> statement?
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>6.4&nbsp;



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

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

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

 <B>Date: </B>21 Apr 2000<BR>


<P>The wording of 6.4&nbsp;



 <A HREF="stmt.html#stmt.select">stmt.select</A> paragraph 1 is
misleading.  Instead of</P>

<BLOCKQUOTE>

The substatement in a <I>selection-statement</I> (both substatements,
in the <TT>else</TT> form of the <TT>if</TT> statement) implicitly
defines a local scope (3.3&nbsp;



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

</BLOCKQUOTE>

<P>it should say</P>

<BLOCKQUOTE>

... <B>each substatement</B>, in the <TT>else</TT> form...

</BLOCKQUOTE>

<P>As is, one is left with the impression that both "then" and "else"
clauses together form a single scope.</P>

<P>
<B>Proposed resolution (10/00):</B> As suggested.</P>

<BR>
<BR>
<HR>
<A NAME="69"></A>
<H4>69.
  
Storage class specifiers on template declarations
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>7.1.1&nbsp;



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

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

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

 <B>Date: </B>17 Oct 1998
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Vandevoorde<BR>



<P>
<U>Mike Ball:</U> I cannot find anything in the standard that tells me the meaning of
a <I>storage-class-specifier</I> on a function template declaration. In
particular, there is no indication what effect, if any, it has on the storage
class of the instantiations.</P>

<P>There is an explicit prohibition of <I>storage-class-specifier</I>s
on explicit specializations.</P>

<P>For example, if we have</P>
<PRE>
    template&lt;class T&gt; static int foo(T) { return sizeof(T); }
</PRE>
does this generate static functions for all instantiations? By
7.1.1&nbsp;



 <A HREF="dcl.html#dcl.stc">dcl.stc</A>

the storage class applies to the name declared in the declarator, which
is the template <TT>foo</TT>, not an instantiation of <TT>foo</TT>, which
is named with a <I>template-id</I>. There is a statement in clause
14 that template names have linkage, which supports the contention that
"<TT>static</TT>" applies to the template, not to instantiations.

<P>So what does the specifier mean? Lacking a direct statement in
the standard, I see the following posibilities, in my preference order.</P>
<OL>
<LI>
<I>storage-class-specifier</I>s have no meaning on template declarations,
their use being subsumed by "<TT>export</TT>" (for the template name) and
the unnamed namespace (for instantiations)</LI>

<LI>
<I>storage-class-specifier</I>s have no effect on the template name, but
do affect the linkage of the instantiations, though this now applies linkage
to <I>template-id</I>s, which I can find no support for. I suspect
this is what was intended, though I don't remember</LI>
</OL>
Of course, if anybody can find some concrete statement, that would settle
it.

<P>
<U>From John Spicer</U>
</P>

<P>The standard does say that a namespace scope template has external linkage
unless it is a function template declared "static". It doesn't explicitly
say that the linkage of the template is also the linkage of the instantiations,
but I believe that is the intent. For example, a storage class is
prohibited on an explicit specialization to ensure that a specialization
cannot be given a different storage class than the template on which it
is based.</P>
<BLOCKQUOTE>
<U>Mike</U>: This makes sense, but I couldn't find much support
in the document. Sounds like yet another interpretation to add to
the list.

<P>
<U>John</U>: Agreed.</P>
</BLOCKQUOTE>
The standard does not talk about the linkage of instantiations, because
only "names" are considered to have linkage, and instances are not really
names. So, from an implementation point of view, instances have linkage,
but from a language point of view, only the template from which the instances
are generated has linkage.
<BLOCKQUOTE>
<U>Mike</U>: Which is why I think it would be cleaner to eliminate
storage class specifiers entirely and rely on the unnamed namespace.
There is a statement that specializations go into the namespace of the
template. No big deal, it's not something it says, so we live with
what's there.

<P>
<U>John</U>: That would mean prohibiting static function templates.
I doubt those are common, but I don't really see much motivation for getting
rid of them at this point.</P>
</BLOCKQUOTE>
"export" is an additional attribute that is separate from linkage, but
that can only be applied to templates with external linkage.
<BLOCKQUOTE>
<U>Mike</U>: I can't find that restriction in the standard,
though there is one that templates in an unnamed namespace can't be exported.
I'm pretty sure that we intended it, though.

<P>
<U>John</U>: I can't find it either. The "inline" case seems to
be addressed, but not static. Surely this is an error as, by definition,
a static template can't be used from elsewhere.</P>
</BLOCKQUOTE>

<P>
<B>Proposed resolution (10/00):</B>
</P>
Change the text in 14&nbsp;



 <A HREF="template.html#temp">temp</A> paragraph 4 from:
<BLOCKQUOTE>
A template name may have linkage (3.5&nbsp;



 <A HREF="basic.html#basic.link">basic.link</A>).
</BLOCKQUOTE>
to:
<BLOCKQUOTE>
A template name has linkage (3.5&nbsp;



 <A HREF="basic.html#basic.link">basic.link</A>).
A non-member function template
can have internal linkage; any other template name shall have external
linkage. Entities generated from a template with internal linkage are distinct
from all entities generated in other translation units.
</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="56"></A>
<H4>56.
  
Redeclaring typedefs within classes
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>7.1.3&nbsp;



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

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

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

 <B>Date: </B>13 Oct 1998<BR>



<P>Can a typedef redeclaration be done within a class?</P>
<PRE>
    class X { 
        typedef int I; 
        typedef int I; 
    };
</PRE>
See also
9.2&nbsp;



 <A HREF="class.html#class.mem">class.mem</A>
,
<A HREF="
     cwg_active.html#36">Core issue 36</A>,
and
<A HREF="
     cwg_defects.html#85">Core issue 85</A>.

<P>
<B>Proposed Resolution (10/99):</B>
Change 7.1.3&nbsp;



 <A HREF="dcl.html#dcl.typedef">dcl.typedef</A>
 paragraph 2
from "In a given scope" to "In a given non-class scope."</P>
<BR>
<BR>
<HR>
<A NAME="76"></A>
<H4>76.
  
Are const volatile variables considered "constant expressions"?
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>7.1.5.1&nbsp;



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

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

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

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



<P>The following code does not compile with the EDG compiler:</P>
<PRE>
    volatile const int a = 5;
    int b[a];
</PRE>
The standard,
7.1.5.1&nbsp;



 <A HREF="dcl.html#dcl.type.cv">dcl.type.cv</A>
, says:
<BLOCKQUOTE>A variable of const-qualified integral or enumeration type
initialized by an integral constant expression can be used in integral
constant expressions.</BLOCKQUOTE>
This doesn't say it can't be const volatile-qualified, although I think
that was what was intended.

<P>
<B>Proposed Resolution (10/99):</B>
Change the referenced text in paragraph 2 of
7.1.5.1&nbsp;



 <A HREF="dcl.html#dcl.type.cv">dcl.type.cv</A>
 to read:</P>

<UL>A variable of <B>non-volatile</B> const-qualified ...</UL>
<BR>
<BR>
<HR>
<A NAME="68"></A>
<H4>68.
  
Grammar does not allow "friend class A&lt;int&gt;;"
</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>DR
 &nbsp;&nbsp;&nbsp;

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

 <B>Date: </B>17 Oct 1998
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Schmeiser<BR>



<P>I can't find the answer to the following in the standard. Does
anybody have a reference?</P>

<P>The syntax for elaborated type specifier is
<UL>
<I>elaborated-type-specifier</I>:
<UL>
<I>class-key</I> <TT>::</TT><SUB>opt</SUB> <I>nested-name-specifier<SUB>opt</SUB>
identifier</I>
<BR>
<TT>enum</TT> <TT>::</TT><I><SUB>opt</SUB> nested-name-specifier<SUB>opt</SUB>
identifier</I>
<BR>
<TT>typename</TT> <TT>::</TT><SUB>opt</SUB>&nbsp;
<I>nested-name-specifier</I> <I>identifier</I>
<BR>
<TT>typename</TT> <TT>::</TT><SUB>opt</SUB>&nbsp;
<I>nested-name-specifier</I> <TT>template</TT><SUB>opt</SUB>&nbsp;<I>template-id</I>
</UL>
<BR>
If an <I>elaborated-type-specifier</I> is the sole constituent of a declaration,
the declaration is ill-formed unless it is an explicit specialization
(14.7.3&nbsp;



 <A HREF="template.html#temp.expl.spec">temp.expl.spec</A>
),
an explicit instantiation
(14.7.2&nbsp;



 <A HREF="template.html#temp.explicit">temp.explicit</A>
) or it has one of the following
forms:
<BR>
<BR>
<UL>
<I>class-key</I> <I>identifier</I> <TT>;</TT>
<BR>
<TT>friend</TT> <I>class-key</I> <I>identifier</I> <TT>;</TT>
<BR>
<TT>friend</TT> <I>class-key</I> <TT>::</TT> <I>identifier</I> <TT>;</TT>
<BR>
<TT>friend</TT> <I>class-key</I> <I>nested-name-specifier</I>&nbsp;<I>identifier</I>&nbsp;<TT>;</TT>
</UL>
</UL>
Which does not allow the production</P>
<PRE>
    class foo&lt;int&gt; // foo is a template
</PRE>
On the other hand, a friend declaration seems to require this production,
<BLOCKQUOTE>An <I>elaborated-type-specifier</I> shall be used in a
friend declaration for a class.*

<P>[<I>Footnote:</I> The <I>class-key</I> of the
<I>elaborated-type-specifier</I> is required.
&mdash;<I>end footnote</I>]</P>
</BLOCKQUOTE>
And in 14.5.3&nbsp;



 <A HREF="template.html#temp.friend">temp.friend</A>
 we find the example
<BLOCKQUOTE>
[<I>Example:</I>
<PRE>
    template&lt;class T&gt; class task;
    template&lt;class T&gt; task&lt;T&gt;* preempt(task&lt;T&gt;*);

    template&lt;class T&gt; class task {
        // ...
        friend void next_time();
        friend void process(task&lt;T&gt;*);
        friend task&lt;T&gt;* preempt&lt;T&gt;(task&lt;T&gt;*);
        template&lt;class C&gt; friend int func(C);

        friend class task&lt;int&gt;;
        template&lt;class P&gt; friend class frd;
        // ...
    };
</PRE>
</BLOCKQUOTE>
Is there some special dispensation somewhere to allow the syntax in this
context?  Is there something I've missed about <I>elaborated-type-specifier</I>?
Is it just another bug in the standard?

<P>An additional problem was reported via <TT>comp.std.c++</TT>: the
grammar does not allow the following example:</P>

<PRE>
    namespace A{
      class B{};
    };

    namespace B{
      class A{};
      class C{
	friend class ::A::B;
      };
    };
</PRE>

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

<P>Change the grammar in 7.1.5.3&nbsp;



 <A HREF="dcl.html#dcl.type.elab">dcl.type.elab</A> to read<BR>
<UL>
<I>elaborated-type-specifier:</I>
<UL>
<I>class-key</I> <TT>::<SUB>opt</SUB></TT>
<I>nested-name-specifier<SUB>opt</SUB> identifier</I>
</UL>
<UL>
<I>class-key</I> <TT>::<SUB>opt</SUB></TT>
<I>nested-name-specifier<SUB>opt</SUB></I>
<TT>template<SUB>opt</SUB></TT> <I>template-id</I>
</UL>
<UL>
<TT>enum ::<SUB>opt</SUB></TT>
<I>nested-name-specifier<SUB>opt</SUB> identifier</I>
</UL>
<UL>
<TT>typename ::<SUB>opt</SUB></TT> <I>nested-name-specifier
identifier</I>
</UL>
<UL>
<TT>typename ::<SUB>opt</SUB></TT> <I>nested-name-specifier</I>
<TT>template<SUB>opt</SUB></TT> <I>template-id</I>
</UL>
</UL>

and change the forms allowed in paragraph 1 to
<UL>
<I>class-key identifier</I> <TT>;</TT>
<BR>
<TT>friend</TT> <I>class-key</I> <TT>::<SUB>opt</SUB></TT> <I>identifier</I>
<TT>;</TT>
<BR>
<TT>friend</TT> <I>class-key</I> <TT>::<SUB>opt</SUB></TT> <I>template-id</I>
<TT>;</TT>
<BR>
<TT>friend</TT> <I>class-key</I> <TT>::<SUB>opt</SUB></TT>
<I>nested-name-specifier identifier</I> <TT>;</TT>
<BR>
<TT>friend</TT> <I>class-key</I> <TT>::<SUB>opt</SUB></TT>
<I>nested-name-specifier</I> <TT>template<SUB>opt</SUB></TT>
<I>template-id</I> <TT>;</TT>
</UL>
</P>
<BR>
<BR>
<HR>
<A NAME="171"></A>
<H4>171.
  
Global namespace scope
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>7.3&nbsp;



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

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

 <B>Submitter: </B>Greg Lutz
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>19 Sep 1999
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Merrill<BR>



<P>7.3&nbsp;



 <A HREF="dcl.html#basic.namespace">basic.namespace</A>
 paragraph 2 says:</P>

<BLOCKQUOTE>
A name declared outside all named namespaces, blocks
(6.3&nbsp;



 <A HREF="stmt.html#stmt.block">stmt.block</A>
) and
classes (clause 9&nbsp;



 <A HREF="class.html#class">class</A>
) has
global namespace scope
(3.3.5&nbsp;



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

But 3.3.5&nbsp;



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

paragraph 3 says:

<BLOCKQUOTE>
A name declared outside all named or unnamed namespaces
(7.3&nbsp;



 <A HREF="dcl.html#basic.namespace">basic.namespace</A>
),
blocks (6.3&nbsp;



 <A HREF="stmt.html#stmt.block">stmt.block</A>
),
function declarations
(8.3.5&nbsp;



 <A HREF="decl.html#dcl.fct">dcl.fct</A>
),
function definitions
(8.4&nbsp;



 <A HREF="decl.html#dcl.fct.def">dcl.fct.def</A>
) and classes
(clause 9&nbsp;



 <A HREF="class.html#class">class</A>
) has global
namespace scope (also called global scope).
</BLOCKQUOTE>

7.3&nbsp;



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

should evidently be changed to match the wording in
3.3.5&nbsp;



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

&mdash; the unnamed namespace is <I>not</I> global scope.

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

<OL>

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



 <A HREF="basic.html#basic.scope.namespace">basic.scope.namespace</A>
paragraph 3 with</P>

<BLOCKQUOTE>

The outermost declarative region of a translation unit is also a
namespace, called the <I>global namespace</I>.  A name declared in the
global namespace has <I>global namespace scope</I> (also called
<I>global scope</I>).

</BLOCKQUOTE>
</LI>

<LI>
<P>In the last sentence of the same paragraph, change "Names
declared in the global namespace scope" to "Names with global
namespace scope."</P>
</LI>

<LI>
<P>Replace 7.3&nbsp;



 <A HREF="dcl.html#basic.namespace">basic.namespace</A> paragraph 2 with

<BLOCKQUOTE>

The outermost declarative region of a translation unit is a namespace;
see 3.3.5&nbsp;



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

</BLOCKQUOTE>
</P>
</LI>

</OL>

<BR>
<BR>
<HR>
<A NAME="166"></A>
<H4>166.
  
Friend declarations of <I>template-id</I>s
</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>DR
 &nbsp;&nbsp;&nbsp;

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

 <B>Date: </B>8 Sep 1999
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Spicer<BR>




<P>From reflector messages 8321-3.</P>


<P>
<U>John Spicer</U>:
I believe the standard is not clear with respect to this example:</P>

<PRE>
    namespace N {
      template &lt;class T&gt; void f(T);
      namespace M {
        struct A {
          friend void f&lt;int&gt;(int);  // okay - refers to N::f
        };
      }
    }
</PRE>

At issue is whether the friend declaration refers to <TT>N::f</TT>, or
whether it is invalid.

<P>A note in
3.3.1&nbsp;



 <A HREF="basic.html#basic.scope.pdecl">basic.scope.pdecl</A>
 paragraph 6 says</P>

<BLOCKQUOTE>
friend declarations refer to functions or classes
that are members of the nearest enclosing namespace ...
</BLOCKQUOTE>

I believe it
is intended to mean <I>unqualified</I> friend declarations.  Certainly
<TT>friend void A::B()</TT> need not refer
to a member of the nearest enclosing
namespace.  Only when the declarator is unqualified (i.e., it is a declaration
and not a reference) does this rule need to apply.  The presence of an
explicit template argument list requires
that a previous declaration be visible and renders this a reference and not
a declaration that is subject to this rule.

<P>
<U>Mike Miller</U>:
7.3.1.2&nbsp;



 <A HREF="dcl.html#namespace.memdef">namespace.memdef</A>
 paragraph 3 says,</P>

<BLOCKQUOTE>
When looking for a prior declaration of a
class or a function declared as a friend, scopes outside the
innermost enclosing namespace scope are not considered.
</BLOCKQUOTE>

On the other hand, the friend declaration would be a syntax
error if <TT>f</TT> weren't declared as a template name; it would
seem very strange not to find the declaration that made the
friend declaration syntactically correct.

However, it also seems strange to treat this case differently
from ordinary functions and from templates:

<PRE>
    namespace N {
      template &lt;class T&gt; void f(T);
      void g();
      namespace M {
        struct A {
          friend void f&lt;int&gt;(int);               // N::f
          template &lt;class T&gt; friend void f(T);   // M::f
          friend void g();                       // M::g
        };
      }
    }
</PRE>

<P>
<U>John Spicer</U>:
This section refers to "looking for a prior declaration".  This
gets back to an earlier discussion we've had about the difference between
matching two declarations of the same name and doing name lookup.  I would
maintain that in <TT>f&lt;int&gt;</TT>
the <TT>f</TT> is looked up using a normal lookup.  In
practice, this is really how it has to be done because the declaration
could actually be <TT>f&lt;int&gt;::x</TT>.</P>

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

<P>In
7.3.1.2&nbsp;



 <A HREF="dcl.html#namespace.memdef">namespace.memdef</A>
 paragraph 3, change</P>

<BLOCKQUOTE>
When looking for a prior declaration of a class or a function declared
as a friend, scopes outside the innermost enclosing namespace scope are
not considered.
</BLOCKQUOTE>

to

<BLOCKQUOTE>
When looking for a prior declaration of a class or a function declared
as a friend, and when the name of the friend class or function is
neither a qualified name nor a <I>template-id</I>, scopes outside the
innermost enclosing namespace scope are not considered.
</BLOCKQUOTE>

Also, change the example in that paragraph as follows:

<PRE>
    void h(int);
    template &lt;class T&gt; void f2(T);
    namespace A {
        class X {
            friend void f(X);       // A::f(X) is a friend
            friend void f2&lt;&gt;(int);  // ::f2&lt;&gt;(int) is a friend
    ...
</PRE>

<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_active.html#143">143</A>, and
<A HREF="
     cwg_closed.html#165">165</A>.)</P>
<BR>
<BR>
<HR>
<A NAME="101"></A>
<H4>101.
  
Redeclaration of extern "C" names via using-declarations
</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>DR
 &nbsp;&nbsp;&nbsp;

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

 <B>Date: </B>10 Mar 1999<BR>




<P>From reflector message core-7994:</P>


<P>Consider the following:</P>
<PRE>
    extern "C" void f();
    namespace N {
        extern "C" void f();
    }
    using N::f;
</PRE>
According to
7.3.3&nbsp;



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

paragraph 11, the <I>using-declaration</I> is an error:
<BLOCKQUOTE>
If a function declaration in namespace scope or block
scope has the same name and the same parameter types
as a function introduced by a <I>using-declaration</I>, the
program is ill-formed.
</BLOCKQUOTE>
Based on the context (7.3.3&nbsp;



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

paragraph 10 simply reiterates the requirements
of
3.3&nbsp;



 <A HREF="basic.html#basic.scope">basic.scope</A>
), one might wonder if
the failure to exempt <TT>extern&nbsp;"C"</TT>
functions was intentional or an oversight.  After all, there is
only one function <TT>f()</TT> involved, because it's <TT>extern&nbsp;"C"</TT>, so
ambiguity is not a reason to prohibit the <I>using-declaration</I>.
<P>
This also breaks the relatively strong parallel between <TT>extern&nbsp;"C"</TT>
functions and typedefs established in our discussion of
<A HREF="
     cwg_closed.html#14">Core issue 14</A>
in Santa Cruz.  There the question was for <I>using-directives</I>:</P>
<PRE>
    typedef unsigned int size_t;
    extern "C" int f();
    namespace N {
        typedef unsigned int size_t;
        extern "C" int f();
    }
    using namespace N;
    int i = f();        // ambiguous "f"?
    size_t x;           // ambiguous "size_t"?
</PRE>
We decided for both that there was no ambiguity because each
pair of declarations declares the same entity.  (According to
3&nbsp;



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

paragraph 3, a typedef name is not an entity, but a type is; thus the
declarations of <TT>size_t</TT> declare the same entity "<TT>unsigned int</TT>".)
<P>
In the context of <I>using-declaration</I>s, there is no explicit
extension of the restrictions in 3.3&nbsp;



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

paragraph 4 except as noted above for function declarations; thus the parallel
scenario for a typedef is not ill-formed:</P>
<PRE>
    typedef unsigned int size_t;
    namespace N {
        typedef unsigned int size_t;
    };
    using N::size_t;        // okay, both declarations
                            // refer to the same entity
</PRE>
I think the first sentence of
7.3.3&nbsp;



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

paragraph 11 ought to be rewritten as:
<BLOCKQUOTE>
If a function declaration in namespace scope or block
scope has the same name and the same parameter types
as a function introduced by a <I>using-declaration</I>,
<B>and the declarations do not declare the same function</B>, the
program is ill-formed.
</BLOCKQUOTE>

<P>
<B>Proposed Resolution (10/99):</B>
As suggested.</P>
<BR>
<BR>
<HR>
<A NAME="103"></A>
<H4>103.
  
Is it <I>extended-namespace-definition</I> or <I>extension-namespace-definition</I> ?
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>7.3.4&nbsp;



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

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

 <B>Submitter: </B>Herb Sutter
 &nbsp;&nbsp;&nbsp;

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




<P>From reflector messages core-8001 and core-8003.</P>


<P>
Section 7.3.4&nbsp;



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

paragraph 3 uses the term <I>extended-namespace-definition</I> three times:</P>
<BLOCKQUOTE>
If a namespace is extended by an <I>extended-namespace-definition</I> after a
<I>using-directive</I> for that namespace is given, the additional members of
the extended namespace and the members of namespaces nominated by
<I>using-directive</I>s in the <I>extended-namespace-definition</I> can be used
after the <I>extended-namespace-definition</I>.
</BLOCKQUOTE>
I think the intent is clear, but unfortunately I cannot find any other
mention (or definition) of this term.
<P>
<U>Mike Miller</U>: True enough; in
Section 7.3.1&nbsp;



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

[the grammar] it's called an <I>extension-namespace-definition</I>.</P>

<P>
<B>Proposed Resolution (10/99):</B>
Systematically replace "extended-namespace-definition" by "extension-namespace-definition".</P>
<BR>
<BR>
<HR>
<A NAME="4"></A>
<H4>4.
  
Does extern "C" affect the linkage of function names with internal linkage?
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>7.5&nbsp;



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

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

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

 <B>Date: </B>unknown
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Gibbons/Adamczyk<BR>




<P>(Previously numbered 864.)</P>


<P>7.5&nbsp;



 <A HREF="dcl.html#dcl.link">dcl.link</A>
 paragraph 6 says the following:</P>
<UL>At most one of a set of overloaded functions with a particular name
can have C linkage.</UL>
Does this apply to static functions as well? For example, is the following
well-formed?
<PRE>
        extern "C" {
            static void f(int) {}
            static void f(float) {}
        };
</PRE>
Can a function with internal linkage "have C linkage" at all (assuming
that phrase means "has extern "C" linkage"), for how can a function be
extern "C" if it's not extern? The function <B>type</B> can have extern
"C" linkage &mdash; but I think that's independent of the linkage of the function
<B>name</B>. It should be perfectly reasonable to say, in the example above,
that extern "C" applies only to the types of <TT>f(int)</TT> and <TT>f(float)</TT>,
not to the function names, and that the rule in 7.5&nbsp;



 <A HREF="dcl.html#dcl.link">dcl.link</A>
 paragraph 6 doesn't apply.
<P>
<B>Suggested  resolution:</B> The extern "C" linkage specification applies
only to the type of functions with internal linkage, and therefore some
of the rules that have to do with name overloading don't apply.</P>

<P>
<B>Proposed Resolution:</B>
</P>

<P>The intent is to distingush <I>implicit</I> linkage from explicit linkage
for both name linkage and language (function type) linkage. (It might
be more clear to use the terms <I>name linkage</I> and <I>type linkage</I>
to distinguish these concepts. A function can have a name with one
kind of linkage and a type with a different kind of linkage. The
function itself has no linkage: it has no name, only the declaration has
a name. This becomes more obvious when you consider function pointers.)</P>

<P>The tentatively agreed proposal is to apply implicit linkage to names
declared in brace-enclosed linkage specifications and to non-top-level
names declared in simple linkage specifications; and to apply explicit
linkage to top-level names declared in simple linkage specifications.</P>

<P>The language linkage of any function type formed through a function
declarator is that of the nearest enclosing <I>linkage-specification</I>.
For purposes of determining whether the declaration of a namespace-scope
name matches a previous declaration, the language linkage portion of the
type of a function declaration (that is, the language linkage of the function
itself, not its parameters, return type or exception specification) is
ignored.</P>

<P>For a <I>linkage-specification</I> using braces, i.e.</P>
<BLOCKQUOTE>
<TT>extern</TT> <I>string-literal</I> <TT>{</TT> <I>declaration-seq</I><SUB>opt</SUB>
<TT>}</TT>
</BLOCKQUOTE>
the linkage of any declaration of a namespace-scope name (including local
externs) which is not contained in a nested <I>linkage-specification</I>,
is not declared to have no linkage (static), and does not match a previous
declaration is given the linkage specified in the <I>string-literal.</I>
The language linkage of the type of any function declaration of a namespace-scope
name (including local externs) which is not contained in a nested <I>linkage-specification</I>
and which is declared with function declarator syntax is the same as that
of a matching previous declaration, if any, else is specified by <I>string-literal</I>.

<P>For a <I>linkage-specification</I> without braces, i.e.</P>
<BLOCKQUOTE>
<TT>extern</TT> <I>string-literal</I> <I>declaration</I>
</BLOCKQUOTE>
<P>the linkage of the names declared in the top-level declarators of <I>declaration</I>
is specified by <I>string-literal</I>; if this conflicts with the linkage
of any matching previous declarations, the program is ill-formed. The language
linkage of the type of any top-level function declarator is specified by
<I>string-literal</I>; if this conflicts with the language linkage of the
type of any matching previous function declarations, the program is ill-formed.
The effect of the <I>linkage-specification</I> on other (non top-level)
names declared in <I>declaration</I> is the same as that of the brace-enclosed
form.</P>


<P>
<I>[The following discussion is from messages 8722 and 8724.]</I>
</P>


<P>
<U>Bill Gibbons</U>: In particular, these should be well-formed:</P>

<PRE>
    extern "C" void f(void (*fp)());   // parameter type is pointer to
                                       // function with C language linkage
    extern "C++" void g(void (*fp)()); // parameter type is pointer to
                                       // function with C++ language linkage

    extern "C++" {                     // well-formed: the linkage of "f"
        void f(void(*fp)());           // and the function type used in the
    }                                  // parameter still "C"

    extern "C" {                       // well-formed: the linkage of "g"
        void g(void(*fp)());           // and the function type used in the
    }                                  // parameter still "C++"
</PRE>

<P>but these should not:</P>

<PRE>
    extern "C++" void f(void(*fp)());  // error - linkage of "f" does not
                                       // match previous declaration
                                       // (linkage of function type used in
                                       // parameter is still "C" and is not
                                       // by itself ill-formed)
    extern "C" void g(void(*fp)());    // error - linkage of "g" does not
                                       // match previous declaration
                                       // (linkage of function type used in
                                       // parameter is still "C++" and is not
                                       // by itself ill-formed)
</PRE>

<P>That is, non-top-level declarators get their linkage from matching
declarations, if any, else from the nearest enclosing linkage
specification.  (As already described, top-level declarators in a
brace-enclosed linkage specification get the linkage from matching
declarations, if any, else from the linkage specifcation; while
top-level declarators in direct linkage specifications get their
linkage from that specification.)</P>

<P>
<U>Mike Miller</U>: This is a pretty significant change from the
current specification, which treats the two forms of language linkage
similarly for most purposes.  I don't understand why it's desirable to
expand the differences.</P>

<P>It seems very unintuitive to me that you could have a top-level
declaration in an <TT>extern "C"</TT>  block that would <I>not</I>
receive "C" linkage.</P>

<P>In the current standard, the statement in
7.5&nbsp;



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

<BLOCKQUOTE>

the specified language linkage applies to the function types of all
function declarators, function names, and variable names introduced by
the declaration(s)

</BLOCKQUOTE>

<P>applies to both forms.  I would thus expect that in</P>

<PRE>
    extern "C" void f(void(*)());
    extern "C++" {
        void f(void(*)());
    }
    extern "C++" f(void(*)());
</PRE>

<P>both "C++" declarations would be well-formed, declaring an
overloaded version of <TT>f</TT> that takes a pointer to a "C++"
function as a parameter.  I wouldn't expect that either declaration
would be a redeclaration (valid or invalid) of the "C" version of
<TT>f</TT>.</P>

<P>
<U>Bill Gibbons</U>: The potential difficulty is the matching
process and the handling of deliberate overloading based on language
linkage.  In the above examples, how are these two declarations
matched:</P>

<PRE>
    extern "C" void f(void (*fp1)());

    extern "C++" {
        void f(void(*fp2)());
    }
</PRE>

<P>given that the linkage that is part of fp1 is "C" while the linkage (prior
to the matching process) that is part of fp2 is "C++"?</P>

<P>The proposal is that the linkage which is part of the parameter type is not
determined until after the match is attempted.  This almost always correct
because you can't overload "C" and "C++" functions; so if the function names
match, it is likely that the declarations are supposed to be the
same.</P>

<P>
<U>Mike Miller</U>: This seems like more trouble than it's worth.
This comparison of function types ignoring linkage specifications is,
as far as I know, not found anywhere in the current standard.  Why do
we need to invent it?</P>

<P>
<U>Bill Gibbons</U>: It is possible to construct pathological cases where this fails, e.g.</P>

<PRE>
    extern "C" typedef void (*PFC)();  // pointer to "C" linkage function
    void f(PFC);         // parameter is pointer to "C" function
    void f(void (*)());  // matching declaration or overload based on
                         // difference in linkage type?
</PRE>

<P>It is reasonable to require explicit typedefs in this case so that
in the above example the second function declaration gets its parameter type
function linkage from the first function declaration.</P>

<P>(In fact, I think you can't get into this situation without having already
used typedefs to declare different language linkage for the top-level and
parameter linkages.)</P>

<P>For example, if the intent is to overload based on linkage a
typedef is needed:</P>

<PRE>
    extern "C" typedef void (*PFC)();  // pointer to "C" linkage function
    void f(PFC);              // parameter is pointer to "C" function
    typedef void (*PFCPP)();  // pointer to "C++" linkage function
    void f(PFCPP);            // parameter is pointer to "C++" function
</PRE>

<P>In this case the two function declarations refer to different
functions.</P>

<P>
<U>Mike Miller</U>: This seems pretty strange to me.  I think it
would be simpler to determine the type of the parameter based on the
containing linkage specification (implicitly "C++") and require a
typedef if the user wants to override the default behavior.  For
example:</P>

<PRE>
    extern "C" {
        typedef void (*PFC)();    // pointer to "C" function
        void f(void(*)());        // takes pointer to "C" function
    }

    void f(void(*)());            // new overload of "f", taking
                                  // pointer to "C++" function

    void f(PFC);                  // redeclare extern "C" version
</PRE>

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

<P>The following changes were tentatively approved, but because they
do not completely implement the proposal above the issue is being kept
for the moment in "drafting" status.</P>

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

<P>After further discussion, the core language working group
determined that the more extensive proposal described above is
not needed and that the following changes are sufficient.</P>

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

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



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

<BLOCKQUOTE>
All function types, function names, and variable names
have a language linkage.
</BLOCKQUOTE>

<P>to</P>

<BLOCKQUOTE>
All function types, function names with external
linkage, and variable names with external linkage have
a language linkage.
</BLOCKQUOTE>
</LI>

<LI>Change the following sentence of 7.5&nbsp;



 <A HREF="dcl.html#dcl.link">dcl.link</A>
paragraph 4:

<BLOCKQUOTE>
In a <I>linkage-specification</I>, the specified language
linkage applies to the function types of all function
declarators, function names, and variable names
introduced by the declaration(s).
</BLOCKQUOTE>

<P>to</P>

<BLOCKQUOTE>
In a <I>linkage-specification</I>, the specified language
linkage applies to the function types of all function
declarators, function names with external linkage, and
variable names with external linkage declared within
the <I>linkage-specification</I>.
</BLOCKQUOTE>
</LI>

<LI>
<P>Add at the end of the final example on 7.5&nbsp;



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

<PRE>
    extern "C" {
      static void f4();    // <I>the name of the function</I> f4 <I>has</I>
                           // <I>internal linkage (not C language</I>
                           // <I>linkage) and the function's type</I>
                           // <I>has C language linkage</I>
    }
    extern "C" void f5() {
      extern void f4();    // <I>Okay -- name linkage (internal)</I>
                           // <I>and function type linkage (C</I>
                           // <I>language linkage) gotten from</I>
                           // <I>previous declaration.</I>
    }
    extern void f4();      // <I>Okay -- name linkage (internal)</I>
                           // <I>and function type linkage (C</I>
                           // <I>language linkage) gotten from</I>
                           // <I>previous declaration.</I>
    void f6() {
      extern void f4();    // <I>Okay -- name linkage (internal)</I>
                           // <I>and function type linkage (C</I>
                           // <I>language linkage) gotten from</I>
                           // <I>previous declaration.</I>
    }
</PRE>
</LI>

<LI>
<P>Change 7.5&nbsp;



 <A HREF="dcl.html#dcl.link">dcl.link</A> paragraph 7 from</P>

<BLOCKQUOTE>
<P>Except for functions with internal linkage, a function
first declared in a <I>linkage-specification</I> behaves as a
function with external linkage.  [<I>Example:</I>
</P>

<PRE>
    extern "C" double f();
    static double f();     // <I>error</I>
</PRE>

<P>is ill-formed (7.1.1&nbsp;



 <A HREF="dcl.html#dcl.stc">dcl.stc</A>). ] The form of
<I>linkage-specification</I> that contains a braced-enclosed
<I>declaration-seq</I> does not affect whether the contained
declarations are definitions or not (3.1&nbsp;



 <A HREF="basic.html#basic.def">basic.def</A>); the
form of <I>linkage-specification</I> directly containing a
single declaration is treated as an <TT>extern</TT> specifier
(7.1.1&nbsp;



 <A HREF="dcl.html#dcl.stc">dcl.stc</A>) for the purpose of determining whether
the contained declaration is a definition.  [<I>Example:</I>
</P>

<PRE>
    extern "C" int i;      // <I>declaration</I>
    extern "C" {
	  int i;           // <I>definition</I>
    }
</PRE>

<P>&mdash;<I>end example</I>] A <I>linkage-specification</I> directly
containing a single declaration shall not specify a
storage class.  [<I>Example:</I>
</P>

<PRE>
    extern "C" static void f(); // <I>error</I>
</PRE>

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

<P>to</P>

<BLOCKQUOTE>
A declaration directly contained in a
<I>linkage-specification</I> is treated as if it contains the
<TT>extern</TT> specifier (7.1.1&nbsp;



 <A HREF="dcl.html#dcl.stc">dcl.stc</A>) for the purpose of
determining the linkage of the declared name and
whether it is a definition.  Such a declaration shall
not specify a storage class.  [<I>Example:</I>

<PRE>
    extern "C" double f();
    static double f();     // <I>error</I>
    extern "C" int i;      // <I>declaration</I>
    extern "C" {
	    int i;         // <I>definition</I>
    }
    extern "C" static void g(); // <I>error</I>
</PRE>

<P>&mdash;<I>end example</I>]</P>
</BLOCKQUOTE>
</LI>
</OL>
<BR>
<BR>
<HR>
<A NAME="29"></A>
<H4>29.
  
Linkage of locally declared functions
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>7.5&nbsp;



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

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

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

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




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


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

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

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

<P>Yes: from 7&nbsp;



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



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

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

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

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

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

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

<P>The ODR should also be checked to see whether it addresses name and
type linkage.</P>
<BR>
<BR>
<HR>
<A NAME="160"></A>
<H4>160.
  
Missing <TT>std::</TT> qualification
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>8.2&nbsp;



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

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

 <B>Submitter: </B>Al Stevens
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>23 Aug 1999
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Maurer<BR>



<P>8.2&nbsp;



 <A HREF="decl.html#dcl.ambig.res">dcl.ambig.res</A>
 paragraph 3
shows an example that includes <TT>&lt;cstddef&gt;</TT> with no using
declarations or directives and refers to <TT>size_t</TT>
without the <TT>std::</TT>
qualification.</P>

<P>Many references to <TT>size_t</TT> throughout the document omit the
<TT>std::</TT>
namespace
qualification.</P>

<P>This is a typical case. The use of <TT>std::</TT>
is inconsistent throughout
the
document.</P>

<P>In addition, the use of exception specifications should be
examined for consistency.</P>

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

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

<P>In
1.9&nbsp;



 <A HREF="intro.html#intro.execution">intro.execution</A>
paragraph 9, replace all two instances of "<TT>sig_atomic_t</TT>"
by "<TT>std::sig_atomic_t</TT>".</P>


<P>In
3.1&nbsp;



 <A HREF="basic.html#basic.def">basic.def</A>
paragraph 4, replace all three instances of "<TT>string</TT>" by
"<TT>std::string</TT>" in the example and insert "<TT>#include
&lt;string&gt;</TT>" at the beginning of the example code.</P>


<P>In
3.6.1&nbsp;



 <A HREF="basic.html#basic.start.main">basic.start.main</A>
paragraph 4, replace</P>
<BLOCKQUOTE>
Calling the function
<BLOCKQUOTE>
<TT>void exit(int);</TT>
</BLOCKQUOTE>
declared in <TT>&lt;cstdlib&gt;</TT>...
</BLOCKQUOTE>
<P>by</P>
<BLOCKQUOTE>
Calling the function <TT>std::exit(int)</TT> declared in
<TT>&lt;cstdlib&gt;</TT>...
</BLOCKQUOTE>
<P>and also replace "<TT>exit</TT>" by "<TT>std::exit</TT>" in
the last sentence of that paragraph.</P>


<P>In
3.6.1&nbsp;



 <A HREF="basic.html#basic.start.main">basic.start.main</A>
first sentence of paragraph 5, replace "<TT>exit</TT>" by
"<TT>std::exit</TT>".</P>


<P>In
3.6.2&nbsp;



 <A HREF="basic.html#basic.start.init">basic.start.init</A>
paragraph 4, replace "<TT>terminate</TT>" by
"<TT>std::terminate</TT>".</P>


<P>In
3.6.3&nbsp;



 <A HREF="basic.html#basic.start.term">basic.start.term</A>
paragraph 1, replace "<TT>exit</TT>" by "<TT>std::exit</TT>"
(see also <A HREF="
     cwg_active.html#28">issue 28</A>).</P>


<P>In
3.6.3&nbsp;



 <A HREF="basic.html#basic.start.term">basic.start.term</A>
paragraph 3, replace all three instances of "<TT>atexit</TT>" by
"<TT>std::atexit</TT>" and both instances of "<TT>exit</TT>"
by "<TT>std::exit</TT>" (see also <A HREF="
     cwg_active.html#28">issue 28</A>).</P>


<P>In
3.6.3&nbsp;



 <A HREF="basic.html#basic.start.term">basic.start.term</A>
paragraph 4, replace</P>
<BLOCKQUOTE>
Calling the function
<BLOCKQUOTE>
<TT>void abort();</TT>
</BLOCKQUOTE>
declared in <TT>&lt;cstdlib&gt;</TT>...
</BLOCKQUOTE>
<P>by</P>
<BLOCKQUOTE>
Calling the function <TT>std::abort()</TT> declared in
<TT>&lt;cstdlib&gt;</TT>...</BLOCKQUOTE>
and "<TT>atexit</TT>" by "<TT>std::atexit</TT>" (see also
<A HREF="
     cwg_active.html#28">issue 28</A>).


<P>In
3.7.3.1&nbsp;



 <A HREF="basic.html#basic.stc.dynamic.allocation">basic.stc.dynamic.allocation</A>
paragraph 1 third sentence, replace "<TT>size_t</TT>" by
"<TT>std::size_t</TT>".</P>


<P>In
3.7.3.1&nbsp;



 <A HREF="basic.html#basic.stc.dynamic.allocation">basic.stc.dynamic.allocation</A>
paragraph 3, replace "<TT>new_handler</TT>" by
"<TT>std::new_handler</TT>". Furthermore, replace
"<TT>set_new_handler</TT>" by "<TT>std::set_new_handler</TT>"
in the note.</P>


<P>In
3.7.3.1&nbsp;



 <A HREF="basic.html#basic.stc.dynamic.allocation">basic.stc.dynamic.allocation</A>
paragraph 4, replace "<TT>type_info</TT>" by
"<TT>std::type_info</TT>" in the note.</P>


<P>In
3.7.3.2&nbsp;



 <A HREF="basic.html#basic.stc.dynamic.deallocation">basic.stc.dynamic.deallocation</A>
paragraph 3, replace all four instances of "<TT>size_t</TT>" by
"<TT>std::size_t</TT>".</P>


<P>In
3.8&nbsp;



 <A HREF="basic.html#basic.life">basic.life</A>
paragraph 5, replace "<TT>malloc</TT>" by
"<TT>std::malloc</TT>" in the example code and insert
"<TT>#include &lt;cstdlib&gt;</TT>" at the beginning of the example
code.</P>


<P>In
3.9&nbsp;



 <A HREF="basic.html#basic.types">basic.types</A>
paragraph 2, replace "<TT>memcpy</TT>" by
"<TT>std::memcpy</TT>" (the only instance in the footnote and both
instances in the example) and replace "<TT>memmove</TT>" by
"<TT>std::memmove</TT>" in the footnote (see also
<A HREF="
     cwg_defects.html#43">issue 43</A>).</P>


<P>In
3.9&nbsp;



 <A HREF="basic.html#basic.types">basic.types</A>
paragraph 3, replace "<TT>memcpy</TT>" by
"<TT>std::memcpy</TT>", once in the normative text and once in the
example (see also <A HREF="
     cwg_defects.html#43">issue 43</A>).</P>


<P>In
3.9.1&nbsp;



 <A HREF="basic.html#basic.fundamental">basic.fundamental</A>
paragraph 8 last sentence, replace "<TT>numeric_limits</TT>" by
"<TT>std::numeric_limits</TT>".</P>


<P>In
5.2.7&nbsp;



 <A HREF="expr.html#expr.dynamic.cast">expr.dynamic.cast</A>
paragraph 9 second sentence, replace "<TT>bad_cast</TT>" by
"<TT>std::bad_cast</TT>".</P>


<P>In
5.2.8&nbsp;



 <A HREF="expr.html#expr.typeid">expr.typeid</A>
paragraph 2, replace "<TT>type_info</TT>" by
"<TT>std::type_info</TT>" and "<TT>bad_typeid</TT>" by
"<TT>std::bad_typeid</TT>".</P>


<P>In
5.2.8&nbsp;



 <A HREF="expr.html#expr.typeid">expr.typeid</A>
paragraph 3, replace "<TT>type_info</TT>" by
"<TT>std::type_info</TT>".</P>


<P>In
5.2.8&nbsp;



 <A HREF="expr.html#expr.typeid">expr.typeid</A>
paragraph 4, replace both instances of "<TT>type_info</TT>" by
"<TT>std::type_info</TT>".</P>


<P>In
5.3.3&nbsp;



 <A HREF="expr.html#expr.sizeof">expr.sizeof</A>
paragraph 6, replace both instances of "<TT>size_t</TT>" by
"<TT>std::size_t</TT>".</P>


<P>In
5.3.4&nbsp;



 <A HREF="expr.html#expr.new">expr.new</A>
paragraph 11 last sentence, replace "<TT>size_t</TT>" by
"<TT>std::size_t</TT>".</P>


<P>In
5.7&nbsp;



 <A HREF="expr.html#expr.add">expr.add</A>
paragraph 6, replace both instances of "<TT>ptrdiff_t</TT>" by
"<TT>std::ptrdiff_t</TT>".</P>


<P>In
5.7&nbsp;



 <A HREF="expr.html#expr.add">expr.add</A>
paragraph 8, replace "<TT>ptrdiff_t</TT>" by
"<TT>std::ptrdiff_t</TT>".</P>


<P>In
6.6&nbsp;



 <A HREF="stmt.html#stmt.jump">stmt.jump</A>
paragraph 2, replace "<TT>exit</TT>" by "<TT>std::exit</TT>"
and "<TT>abort</TT>" by "<TT>std::abort</TT>" in the note.</P>


<P>In
8.2&nbsp;



 <A HREF="decl.html#dcl.ambig.res">dcl.ambig.res</A>
paragraph 3, replace "<TT>size_t</TT>" by
"<TT>std::size_t</TT>" in the example.</P>


<P>In
8.4&nbsp;



 <A HREF="decl.html#dcl.fct.def">dcl.fct.def</A>
paragraph 5, replace "<TT>printf</TT>" by
"<TT>std::printf</TT>" in the note.</P>


<P>In
12.4&nbsp;



 <A HREF="special.html#class.dtor">class.dtor</A>
paragraph 13, replace "<TT>size_t</TT>" by
"<TT>std::size_t</TT>" in the example.</P>


<P>In
12.5&nbsp;



 <A HREF="special.html#class.free">class.free</A>
paragraph 2, replace all four instances of "<TT>size_t</TT>" by
"<TT>std::size_t</TT>" in the example.</P>


<P>In
12.5&nbsp;



 <A HREF="special.html#class.free">class.free</A>
paragraph 6, replace both instances of "<TT>size_t</TT>" by
"<TT>std::size_t</TT>" in the example.</P>


<P>In
12.5&nbsp;



 <A HREF="special.html#class.free">class.free</A>
paragraph 7, replace all four instances of "<TT>size_t</TT>" by
"<TT>std::size_t</TT>" in the two examples.</P>


<P>In
12.7&nbsp;



 <A HREF="special.html#class.cdtor">class.cdtor</A>
paragraph 4, replace "<TT>type_info</TT>" by
"<TT>std::type_info</TT>".</P>


<P>In
13.6&nbsp;



 <A HREF="over.html#over.built">over.built</A>
paragraph 13, replace all five instances of "<TT>ptrdiff_t</TT>"
by "<TT>std::ptrdiff_t</TT>".</P>


<P>In
13.6&nbsp;



 <A HREF="over.html#over.built">over.built</A>
paragraph 14, replace "<TT>ptrdiff_t</TT>" by
"<TT>std::ptrdiff_t</TT>".</P>


<P>In
13.6&nbsp;



 <A HREF="over.html#over.built">over.built</A>
paragraph 21, replace both instances of "<TT>ptrdiff_t</TT>" by
"<TT>std::ptrdiff_t</TT>".</P>


<P>In
14.2&nbsp;



 <A HREF="template.html#temp.names">temp.names</A>
paragraph 4, replace both instances of "<TT>size_t</TT>" by
"<TT>std::size_t</TT>" in the example.  (The example is quoted in
<A HREF="
     cwg_active.html#96">issue 96</A>.)</P>


<P>In
14.3&nbsp;



 <A HREF="template.html#temp.arg">temp.arg</A>
paragraph 1, replace "<TT>complex</TT>" by
"<TT>std::complex</TT>", once in the example code and once in the
comment.</P>


<P>In
14.7.3&nbsp;



 <A HREF="template.html#temp.expl.spec">temp.expl.spec</A>
paragraph 8, <A HREF="
     cwg_defects.html#24">issue 24</A>
has already corrected the example.</P>


<P>In
15.1&nbsp;



 <A HREF="except.html#except.throw">except.throw</A>
paragraph 6, replace "<TT>uncaught_exception</TT>" by
"<TT>std::uncaught_exception</TT>".</P>


<P>In
15.1&nbsp;



 <A HREF="except.html#except.throw">except.throw</A>
paragraph 7, replace "<TT>terminate</TT>" by
"<TT>std::terminate</TT>" and both instances of
"<TT>unexpected</TT>" by "<TT>std::unexpected</TT>".</P>


<P>In
15.1&nbsp;



 <A HREF="except.html#except.throw">except.throw</A>
paragraph 8, replace "<TT>terminate</TT>" by
"<TT>std::terminate</TT>".</P>


<P>In
15.2&nbsp;



 <A HREF="except.html#except.ctor">except.ctor</A>
paragraph 3, replace "<TT>terminate</TT>" by
"<TT>std::terminate</TT>".</P>


<P>In
15.3&nbsp;



 <A HREF="except.html#except.handle">except.handle</A>
paragraph 9, replace "<TT>terminate</TT>" by
"<TT>std::terminate</TT>".</P>


<P>In
15.4&nbsp;



 <A HREF="except.html#except.spec">except.spec</A>
paragraph 8, replace "<TT>unexpected</TT>" by
"<TT>std::unexpected</TT>".</P>


<P>In
15.4&nbsp;



 <A HREF="except.html#except.spec">except.spec</A>
paragraph 9, replace "<TT>unexpected</TT>" by
"<TT>std::unexpected</TT>" and "<TT>terminate</TT>" by
"<TT>std::terminate</TT>".</P>


<P>In
15.5&nbsp;



 <A HREF="except.html#except.special">except.special</A>
paragraph 1, replace "<TT>terminate</TT>" by
"<TT>std::terminate</TT>" and "<TT>unexpected</TT>" by
"<TT>std::unexpected</TT>".</P>


<P>In the heading of
15.5.1&nbsp;



 <A HREF="except.html#except.terminate">except.terminate</A>,
replace "<TT>terminate</TT>" by "<TT>std::terminate</TT>".</P>


<P>In
15.5.1&nbsp;



 <A HREF="except.html#except.terminate">except.terminate</A>
paragraph 1, footnote in the first bullet, replace
"<TT>terminate</TT>" by "<TT>std::terminate</TT>".  In the
same paragraph, fifth bullet, replace "<TT>atexit</TT>" by
"<TT>std::atexit</TT>".  In the same paragraph, last bullet,
replace "<TT>unexpected_handler</TT>" by
"<TT>std::unexpected_handler</TT>".</P>


<P>In
15.5.1&nbsp;



 <A HREF="except.html#except.terminate">except.terminate</A>
paragraph 2, replace</P>
<BLOCKQUOTE>
In such cases,
<BLOCKQUOTE>
<TT>void terminate();</TT>
</BLOCKQUOTE>
is called...
</BLOCKQUOTE>
<P>by</P>
<BLOCKQUOTE>
In such cases, <TT>std::terminate()</TT> is called...
</BLOCKQUOTE>
<P>and replace all three instances of "<TT>terminate</TT>" by
"<TT>std::terminate</TT>".</P>


<P>In the heading of
15.5.2&nbsp;



 <A HREF="except.html#except.unexpected">except.unexpected</A>,
replace "<TT>unexpected</TT>" by "<TT>std::unexpected</TT>".</P>


<P>In
15.5.2&nbsp;



 <A HREF="except.html#except.unexpected">except.unexpected</A>
paragraph 1, replace </P>
<BLOCKQUOTE>
...the function
<BLOCKQUOTE>
<TT>void unexpected();</TT>
</BLOCKQUOTE>
is called...
</BLOCKQUOTE>
<P>by</P>
<BLOCKQUOTE>
...the function <TT>std::unexpected()</TT> is called...
</BLOCKQUOTE>.


<P>In
15.5.2&nbsp;



 <A HREF="except.html#except.unexpected">except.unexpected</A>
paragraph 2, replace "<TT>unexpected</TT>" by
"<TT>std::unexpected</TT>" and "<TT>terminate</TT>" by
"<TT>std::terminate</TT>".</P>


<P>In
15.5.2&nbsp;



 <A HREF="except.html#except.unexpected">except.unexpected</A>
paragraph 3, replace "<TT>unexpected</TT>" by
"<TT>std::unexpected</TT>".</P>


<P>In the heading of
15.5.3&nbsp;



 <A HREF="except.html#except.uncaught">except.uncaught</A>,
replace "<TT>uncaught_exception</TT>" by
"<TT>std::uncaught_exception</TT>".</P>


<P>In 
15.5.3&nbsp;



 <A HREF="except.html#except.uncaught">except.uncaught</A>
paragraph 1, replace</P>
<BLOCKQUOTE>
The function
<BLOCKQUOTE>
<TT>bool uncaught_exception()</TT>
</BLOCKQUOTE>
returns <TT>true</TT>...
</BLOCKQUOTE>
<P>by</P>
<BLOCKQUOTE>
The function <TT>std::uncaught_exception()</TT> returns <TT>true</TT>...
</BLOCKQUOTE>.
<P>In the last sentence of the same paragraph, replace
"<TT>uncaught_exception</TT>" by
"<TT>std::uncaught_exception</TT>".</P>

<BR>
<BR>
<HR>
<A NAME="40"></A>
<H4>40.
  
Syntax of <I>declarator-id</I>
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>8.3&nbsp;



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

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

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

 <B>Date: </B>01 Sep 1998<BR>



<P>(From J16/99-0005 = WG21 N1182, "Proposed Resolutions for Core
Language Issues 6, 14, 20, 40, and 89")</P>

<P>There are two sub-issues. The first concerns the statement in
8.3&nbsp;



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


paragraph 1,</P>
<BLOCKQUOTE>The <I>id-expression</I> of a <I>declarator-id</I> shall be
a simple identifier except for the declaration of some special functions
(12.3&nbsp;



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



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



 <A HREF="over.html#over.oper">over.oper</A>
) and for the declaration
of template specializations or partial specializations
(14.7&nbsp;



 <A HREF="template.html#temp.spec">temp.spec</A>
).</BLOCKQUOTE>
The second sub-issue is regarding another statement in the same paragraph:
<BLOCKQUOTE>A <I>declarator-id</I> shall not be qualified except for the
definition of a member function (9.3&nbsp;



 <A HREF="class.html#class.mfct">class.mfct</A>
)
or static data member (9.4&nbsp;



 <A HREF="class.html#class.static">class.static</A>
)
or nested class (9.7&nbsp;



 <A HREF="class.html#class.nest">class.nest</A>
) outside
of its class, the definition or explicit instantiation of a function, variable
or class member of a namespace outside of its namespace, or...</BLOCKQUOTE>
<U>Analysis</U>

<P>The problem in the first sub-issue is that the wrong syntactic non-terminal
is mentioned. The relevant portions of the grammar are:</P>
<UL>
<I>declarator-id </I>:
<UL>
<I>id-expression</I>
<BR>
<TT>::</TT><SUB>opt</SUB>&nbsp; <I>nested-name-specifier</I><SUB>opt</SUB>
<I>type-name</I>
</UL>
<I>id-expression </I>:
<UL>
<I>unqualified-id</I>
<BR>
<I>qualified-id</I>
</UL>
<I>unqualified-id </I>:
<UL>
<I>identifier</I>
<BR>
<I>operator-function-id</I>
<BR>
<I>conversion-function-id</I>
<BR>~ <I>class-name</I>
<BR>
<I>template-id</I>
</UL>
</UL>
The exceptions in the citation from
8.3&nbsp;



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


paragraph 1 are all the non-identifier cases of <I>unqualified-id</I>:
12.3&nbsp;



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


is for <I>conversion-function-id</I>s,
12.4&nbsp;



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


is for destructors,
13.5&nbsp;



 <A HREF="over.html#over.oper">over.oper</A>

 is
for overloaded operators, and
14.7&nbsp;



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


is for <I>template-id</I>s. If taken literally, this sentence would exclude
all <I>qualified-id</I>s, which it obviously is not intended to do. Instead,
the apparent intent is something along the lines of
<BLOCKQUOTE>If an <I>unqualified-id</I> is used as the <I>id-expression</I>
of a <I>declarator-id</I>, it shall be a simple identifier except...</BLOCKQUOTE>
However, it does not appear that this restriction has any meaning; all
of the possible cases of <I>unqualified-id</I>s are represented in the
list of exceptions! Rather than recasting the sentence into a correct but
useless form, it would be better to remove it altogether.

<P>The second sub-issue deals with the conditions under which a <I>qualified-id</I>
can be used in a declarator, including "the definition of a...nested class"
and "the definition or explicit instantiation of a...class member of a
namespace." However, the name in a class definition is not part of a declarator;
these constructs do not belong in a list of declarator contexts.</P>

<P>
<B>Proposed Resolution for sub-issue 1 (04/99):</B>
</P>
<P>The suggested resolution for the first sub-issue overlooked the
fact that the existing wording has the additional effect of prohibiting
the use of the non-identifier syntax for declaring other than the
listed entities.  Thus the proposed wording
for the first sub-issue is:</P>
<P>Change 8.3&nbsp;



 <A HREF="decl.html#dcl.meaning">dcl.meaning</A>
 paragraph 1 from:</P>
<BLOCKQUOTE>The <I>id-expression</I> of a <I>declarator-id</I> shall be a simple <I>identifier</I> except...</BLOCKQUOTE>
to:
<BLOCKQUOTE>An <I>unqualified-id</I> occurring in a <I>declarator-id</I> shall be a simple <I>identifier</I> except...</BLOCKQUOTE>

<P>
<B>Proposed Resolution for sub-issue 2 (10/99):</B>
</P>

<P>Change 8.3&nbsp;



 <A HREF="decl.html#dcl.meaning">dcl.meaning</A>
 paragraph 1 from:</P>
<BLOCKQUOTE>A <I>declarator-id</I> shall not be qualified except for the
definition of a member function (9.3&nbsp;



 <A HREF="class.html#class.mfct">class.mfct</A>
)
or static data member (9.4&nbsp;



 <A HREF="class.html#class.static">class.static</A>
)
or nested class (9.7&nbsp;



 <A HREF="class.html#class.nest">class.nest</A>
) outside
of its class, the definition or explicit instantiation of a function, variable
or class member of a namespace outside of its namespace, or...</BLOCKQUOTE>

to

<BLOCKQUOTE>A <I>declarator-id</I> shall not be qualified except for the
definition of a member function (9.3&nbsp;



 <A HREF="class.html#class.mfct">class.mfct</A>
)
or static data member (9.4&nbsp;



 <A HREF="class.html#class.static">class.static</A>
)
outside
of its class, the definition or explicit instantiation of a function or
variable member of a namespace outside of its namespace, or...</BLOCKQUOTE>
<BR>
<BR>
<HR>
<A NAME="159"></A>
<H4>159.
  
Namespace qualification in declarators
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>8.3&nbsp;



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

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

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

 <B>Date: </B>23 Aug 1999
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Vandevoorde<BR>



<P>8.3&nbsp;



 <A HREF="decl.html#dcl.meaning">dcl.meaning</A>
 paragraph 1 says:</P>

<BLOCKQUOTE>
In the qualified <I>declarator-id</I> for a class or namespace member
definition that appears outside of the member's class or namespace,
the <I>nested-name-specifier</I> shall not name any of the namespaces that
enclose the member's definition.
</BLOCKQUOTE>

This results in the following behavior:

<PRE>
    namespace N {
        namespace M {
            void f();
            void g();
        }
        void M::f(){}     // okay
        void N::M::g(){}  // error
    }
</PRE>

I was very surprised when this rule was pointed out to me.  The change
appears to have been introduced around the time of the first Santa
Cruz meeting, but I don't recall discussion of it and could not find a
motion related to it.

<P>Regardless of where it came from, I also can't understand why it is there.
Certainly it shouldn't matter <I>how</I> you name a given class or namespace.</P>

<P>For example, the standard permits:</P>

<PRE>
    namespace N {
        namespace M {
            void f();
            void g();
        }
        namespace X = M;
        namespace Y = N::M;
        void X::f(){}  // okay
        void Y::g(){}  // okay
    }
</PRE>

So, it is okay to use an alias for <TT>N::M</TT>,
but not to use <TT>N::M</TT> directly. 
Note that it <I>is</I> okay to use <TT>N::M</TT>
in any other context at this point
in the program (i.e., the rule is a specific restriction on declarator
names, not a general rule on the use of qualified names).

<P>Does anyone recall the intent of this rule or any rationale for its
existence?</P>

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

<P>There was some question as to whether this issue actually
constituted a defect in the Standard.  John Spicer suggested that
machine-generated source code would be likely to run afoul of this
prohibition.  Francis Glassborow expressed support for a rule that
would allow full qualification, or qualification relative to the
namespace containing the definition, but not qualification relative to
a containing namespace.  There was no consensus for moving forward
with a DR at this point, so the issue was left in "review" status.</P>

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

<P>Remove the last sentence of
8.3&nbsp;



 <A HREF="decl.html#dcl.meaning">dcl.meaning</A> paragraph 1 (cited above) and the example
that follows.</P>

<BR>
<BR>
<HR>
<A NAME="112"></A>
<H4>112.
  
Array types and cv-qualifiers
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>8.3.4&nbsp;



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

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

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

 <B>Date: </B>4 May 1999
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Merrill<BR>




<P>From reflector messages 8041-8044.</P>


<P>
<U>Steve Clamage:</U>
Section 8.3.4&nbsp;



 <A HREF="decl.html#dcl.array">dcl.array</A>
 paragraph 1
reads in part as follows:</P>

<BLOCKQUOTE>
Any type of the form "<I>cv-qualifier-seq</I> array of <TT>N T</TT>"
is adjusted to
"array of <TT>N</TT> <I>cv-qualifier-seq</I> <TT>T</TT>,"
and similarly for "array of unknown
bound of <TT>T</TT>." [<I>Example:</I>
<PRE>
    typedef int A[5], AA[2][3];
    typedef const A CA;     // <I>type is "array of 5 const int"</I>
    typedef const AA CAA;   // <I>type is "array of 2 array of 3 const int"</I>
</PRE>
&mdash;<I>end example</I>]
[<I>Note:</I> an "array of <TT>N</TT> <I>cv-qualifier-seq</I> <TT>T</TT>"
has cv-qualified type; such
an array has internal linkage unless explicitly declared <TT>extern</TT>
(7.1.5.1&nbsp;



 <A HREF="dcl.html#dcl.type.cv">dcl.type.cv</A>
)
and must be initialized as specified in
8.5&nbsp;



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

The Note appears to contradict the sentence that precedes it. 

<P>
<U>Mike Miller:</U>
I disagree; all it says is that whether the qualification on
the element type is direct ("<TT>const int x[5]</TT>") or indirect
("<TT>const A CA</TT>"), the array itself is qualified in the same way
the elements are.</P>

<P>
<U>Steve Clamage:</U> In addition, section
3.9.3&nbsp;



 <A HREF="basic.html#basic.type.qualifier">basic.type.qualifier</A>
 paragraph 2 says:</P>

<BLOCKQUOTE>
A compound type (3.9.2&nbsp;



 <A HREF="basic.html#basic.compound">basic.compound</A>
)
is not cv-qualified by the cv-qualifiers (if
any) of the types from which it is compounded.  Any cv-qualifiers
applied to an array type affect the array element type, not the
array type (8.3.4&nbsp;



 <A HREF="decl.html#dcl.array">dcl.array</A>
)."
</BLOCKQUOTE>

The Note appears to contradict that section as well.

<P>
<U>Mike Miller:</U>
Yes, but consider the last two sentences of
3.9.3&nbsp;



 <A HREF="basic.html#basic.type.qualifier">basic.type.qualifier</A>
 paragraph 5:</P>
<BLOCKQUOTE>
Cv-qualifiers applied to an array type attach to the
underlying element type, so the notation "<I>cv</I> <TT>T</TT>,"
where <TT>T</TT> is
an array type, refers to an array whose elements are
so-qualified.  Such array types can be said to be more (or
less) cv-qualified than other types based on the cv-qualification
of the underlying element types.
</BLOCKQUOTE>

I think this says essentially the same thing as
8.3.4&nbsp;



 <A HREF="decl.html#dcl.array">dcl.array</A>
 paragraph 1 and
its note: the qualification of an array is (bidirectionally)
equivalent to the qualification of its members.

<P>
<U>Mike Ball:</U>
I find this a very far reach.  The text in
8.3.4&nbsp;



 <A HREF="decl.html#dcl.array">dcl.array</A>
 is essentially that which
is in the C standard (and is a change from early versions of C++).
I don't see any justification at all for the bidirectional equivalence.
It seems to me that
the note is left over from the earlier version of the language.</P>

<P>
<U>Steve Clamage:</U> Finally, the Note seems to say that the declaration</P>
<PRE>
    volatile char greet[6] = "Hello";
</PRE>
gives "greet" internal linkage, which makes no sense.

<P>Have I missed something, or should that Note be entirely removed?</P>

<P>
<U>Mike Miller:</U>
At least the wording in the note
should be repaired not to indicate that volatile-qualification
gives an array internal linkage.  Also, depending on how the
discussion goes, either the wording in
3.9.3&nbsp;



 <A HREF="basic.html#basic.type.qualifier">basic.type.qualifier</A>
 paragraph 2
or in paragraph 5 needs
to be amended to be consistent regarding whether an array type
is considered qualified by the qualification of its element
type.</P>

<P>
<U>Steve Adamczyk</U> pointed out that
the current state of affairs resulted from the need to handle
reference binding consistently.  The wording is intended to define
the question, "Is an array type cv-qualified?" as being equivalent
to the question, "Is the element type of the array cv-qualified?"</P>

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

<P>Replace the portion of the note in 8.3.4&nbsp;



 <A HREF="decl.html#dcl.array">dcl.array</A>
paragraph 1 reading</P>

<BLOCKQUOTE>

such an array has internal linkage unless explicitly declared
<TT>extern</TT> (7.1.5.1&nbsp;



 <A HREF="dcl.html#dcl.type.cv">dcl.type.cv</A>) and must be
initialized as specified in 8.5&nbsp;



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

</BLOCKQUOTE>

<P>with</P>

<BLOCKQUOTE>

see 3.9.3&nbsp;



 <A HREF="basic.html#basic.type.qualifier">basic.type.qualifier</A>.

</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="135"></A>
<H4>135.
  
Class type in in-class member function definitions
</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>DR
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Gabriel Netterdag
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>1 July 1999
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Adamczyk<BR>




<P>From reflector messages 8167, 8170-76.</P>


<P>3.2&nbsp;



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



 <A HREF="decl.html#dcl.fct">dcl.fct</A>
 paragraph 6 indicate that
the return type and parameter types must be complete in a function
definition.  However, when
9.2&nbsp;



 <A HREF="class.html#class.mem">class.mem</A>
 paragraph 2 lists the
contexts in a class <I>member-specification</I> in which the class
is considered complete, the return type and parameter types of a
member function defined in the class definition are not included.
It thus appears that the following example is ill-formed:</P>

<PRE>
    struct S {
        S f() { return S(); }    // error: incomplete return type
        void g(S) { }            // error: incomplete parameter type
    };
</PRE>

<U>Jack Rouse</U>:
I suggest supplementing the text in 8.3.5p6 with something like:

<BLOCKQUOTE>
The type of a parameter or the return type for a function definition
shall not be an incomplete class type unless the function definition
is nested in the <I>member-specification</I> for that class (including
definitions in nested classes defined within the class).
</BLOCKQUOTE>

<P>
<B>Proposed resolution (10/00):</B> Replace the last sentence of
8.3.5&nbsp;



 <A HREF="decl.html#dcl.fct">dcl.fct</A>
 paragraph 6 with</P>
<BLOCKQUOTE>
The type of a parameter or the return type for a function definition
shall not be an incomplete class type (possibly cv-qualified) unless
the function definition is nested within the
<I>member-specification</I> for that class (including definitions in
nested classes defined within the class).
</BLOCKQUOTE>
<BR>
<BR>
<HR>
<A NAME="140"></A>
<H4>140.
  
Agreement of parameter declarations
</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>DR
 &nbsp;&nbsp;&nbsp;

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

 <B>Date: </B>15 Jul 1999
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>O'Riordan<BR>




<P>From reflector messages 8214, 8216, and 8220.</P>


<P>8.3.5&nbsp;



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

<BLOCKQUOTE>
All declarations for a function with a given parameter list shall
agree exactly both in the type of the value returned and in the
number and type of parameters.
</BLOCKQUOTE>

It is not clear what this requirement means with respect to a pair
of declarations like the following:

<PRE>
    int f(const int);
    int f(int x) { ... }
</PRE>

Do they violate this requirement?  Is <TT>x const</TT> in the body of
the function declaration?

<P>
<U>Tom Plum</U>:
I think the FDIS quotation means that the pair of decls are valid.
But it doesn't clearly answer whether
<TT>x</TT> is <TT>const</TT> inside the function definition.
As to intent, I <I>know</I> the intent was that if the function
definition wants to specify that <TT>x</TT> is <TT>const</TT>,
the <TT>const</TT> must appear specifically in the defining
decl, not just on some decl elsewhere.
But I can't prove that intent from the drafted words.</P>

<P>
<U>Mike Miller</U>:
I think the intent was something along the
following lines:</P>

<BLOCKQUOTE>
Two function declarations denote the same entity if
the names are the same and the function signatures
are the same.  (Two function declarations with C
language linkage denote the same entity if the names
are the same.)  All declarations of a given function
shall agree exactly both in the type of the value
returned and in the number and type of parameters;
the presence or absence of the ellipsis is considered
part of the signature.
</BLOCKQUOTE>

(See 3.5&nbsp;



 <A HREF="basic.html#basic.link">basic.link</A>
 paragraph 9.
That paragraph talks about names in different
scopes and says that function references are the same if the
"types are identical for purposes of overloading," i.e., the
signatures are the same.  See also
7.5&nbsp;



 <A HREF="dcl.html#dcl.link">dcl.link</A>
 paragraph 6
regarding C language
linkage, where only the name is required to be the same for
declarations in different namespaces to denote the same
function.)

<P>According to this paragraph, the type of a parameter is
determined by considering its <I>decl-specifier-seq</I> and
<I>declarator</I>
and then applying the array-to-pointer and function-to-pointer
adjustments.  The <I>cv-qualifier</I> and storage class adjustments
are performed for the function type but not for the parameter
types.</P>

<P>If my interpretation of the intent of the second sentence of
the paragraph is correct, the two declarations in the example
violate that restriction &mdash; the parameter types are not the
same, even though the function types are.  Since there's no
dispensation mentioned for "no diagnostic required," an
implementation presumably must issue a diagnostic in this
case.  (I think "no diagnostic required" should be stated if
the declarations occur in different translation units &mdash;
unless there's a blanket statement to that effect that I have
forgotten?)</P>

<P>(I'd also note in passing that, if my interpretation is
correct,</P>

<PRE>
    void f(int);
    void f(register int) { }
</PRE>

is also an invalid pair of declarations.)


<P>Note also reflector message c++std-edit-838, in which Sean Corfield
observed that some people have read this paragraph as indicating that
the parameter adjustments apply only to overload resolution and suggested
that the paragraph be split in two to clarify the intent.</P>


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

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



 <A HREF="intro.html#defns.signature">defns.signature</A>, change
"the types of its parameters"
to
"its parameter-type-list (8.3.5&nbsp;



 <A HREF="decl.html#dcl.fct">dcl.fct</A>)".
</P>
</LI>

<LI>
<P>In the third bullet of 3.5&nbsp;



 <A HREF="basic.html#basic.link">basic.link</A> paragraph 9
change
"the function types are identical for the purposes of overloading"
to
"the parameter-type-lists of the functions (8.3.5&nbsp;



 <A HREF="decl.html#dcl.fct">dcl.fct</A>) are identical."
</P>
</LI>

<LI>
<P>In the sub-bullets of the third bullet of
5.2.5&nbsp;



 <A HREF="expr.html#expr.ref">expr.ref</A> paragraph 4, change all four occurrences
of
"function of (parameter type list)"
to
"function of parameter-type-list."
</P>
</LI>

<LI>
<P>In 8.3.5&nbsp;



 <A HREF="decl.html#dcl.fct">dcl.fct</A> paragraph 3, change

<BLOCKQUOTE>
All declarations for a function with a given parameter list shall agree
exactly both in the type of the value returned and in the number and
type of parameters; the presence or absence of the ellipsis is
considered part of the function type.
</BLOCKQUOTE>

to

<BLOCKQUOTE>
All declarations for a function shall
agree exactly in both the return type and the
parameter-type-list.
</BLOCKQUOTE>
</P>
</LI>

<LI>
<P>In 8.3.5&nbsp;



 <A HREF="decl.html#dcl.fct">dcl.fct</A> paragraph 3, change

<BLOCKQUOTE>
The resulting list of transformed parameter types is the function's
<I>parameter type list</I>.
</BLOCKQUOTE>

to

<BLOCKQUOTE>
The resulting list of transformed parameter types and the presence or
absence of the ellipsis is the function's <I>parameter-type-list</I>.
</BLOCKQUOTE>
</P>
</LI>

<LI>
<P>In 8.3.5&nbsp;



 <A HREF="decl.html#dcl.fct">dcl.fct</A> paragraph 4, change
"the parameter type list"
to
"the parameter-type-list."
</P>
</LI>

<LI>
<P>In the second bullet of 13.1&nbsp;



 <A HREF="over.html#over.load">over.load</A> paragraph 2,
change all three occurrences of "parameter types" to
"parameter-type-list."
</P>
</LI>

<LI>
<P>In 13.3&nbsp;



 <A HREF="over.html#over.match">over.match</A> paragraph 1, change "the types of
the parameters" to "the parameter-type-list."
</P>
</LI>

<LI>
<P>In the last sub-bullet of the third bullet of
13.3.1.2&nbsp;



 <A HREF="over.html#over.match.oper">over.match.oper</A> paragraph 3, change "parameter type
list" to "parameter-type-list."
</P>
</LI>

</OL>
<P>
<B>Note, 7 Sep 2001:</B>
</P>
<P>Editorial changes while putting in <A HREF="
     cwg_defects.html#147">issue 147</A>
brought up the fact that injected-class-name is not a syntax term and
therefore perhaps shouldn't be written with hyphens. The same can be said of
parameter-type-list.

See message c++std-edit-880.

</P>
<BR>
<BR>
<HR>
<A NAME="1"></A>
<H4>1.
  
What if two using-declarations refer to the same function but the declarations introduce different default-arguments?
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>8.3.6&nbsp;



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

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

 <B>Submitter: </B>Bill Gibbons
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Vandevoorde<BR>




<P>(Previously numbered 689.)</P>


<P>3.3&nbsp;



 <A HREF="basic.html#basic.scope">basic.scope</A>
 paragraph 4 says:</P>
<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 ...
</LI>
</UL>
</BLOCKQUOTE>
8.3.6&nbsp;



 <A HREF="decl.html#dcl.fct.default">dcl.fct.default</A>
 paragraph 9 says:
<BLOCKQUOTE>When a declaration of a function is introduced by way of a
<I>using-declaration</I> (7.3.3&nbsp;



 <A HREF="dcl.html#namespace.udecl">namespace.udecl</A>),
any default argument information associated with the
declaration is imported as well.</BLOCKQUOTE>
This is not really clear regarding what happens in the following case:
<PRE>
    namespace A {
            extern "C" void f(int = 5);
    }
    namespace B {
            extern "C" void f(int = 7);
    }
     
    using A::f;
    using B::f;
     
    f(); // ???
</PRE>
<B>Proposed resolution (10/00):</B>

<P>Add the following at the end of 13.3.3&nbsp;



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

<BLOCKQUOTE>
If the best viable function resolves to a function for which
multiple declarations were found, and if at least two of these
declarations &mdash; or
the declarations they refer to in the case of
<I>using-declaration</I>s &mdash; specify
a default argument that made the function viable, the program is ill-formed.
[<I>Example:</I>
<BR>
<TT>&nbsp;&nbsp;&nbsp; namespace A {</TT>
<BR>
<TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; extern "C" void f(int = 5);</TT>
<BR>
<TT>&nbsp;&nbsp;&nbsp; }</TT>
<BR>
<TT>&nbsp;&nbsp;&nbsp; namespace B {</TT>
<BR>
<TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; extern "C" void f(int = 5);</TT>
<BR>
<TT>&nbsp;&nbsp;&nbsp; }</TT>
<P>
<TT>&nbsp;&nbsp;&nbsp; using A::f;</TT>
<BR>
<TT>&nbsp;&nbsp;&nbsp; using B::f;</TT>
</P>
<P>
<TT>&nbsp;&nbsp;&nbsp; void use() {</TT>
<BR>
<TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; f(3);&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
// OK, default argument was not used for viability</TT>
<BR>
<TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; f();&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
// Error: found default argument twice</TT>
<BR>
<TT>&nbsp;&nbsp;&nbsp; }</TT>
</P>
<P>&nbsp; &mdash;<I>end example</I>]</P>
</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="65"></A>
<H4>65.
  
Typo in default argument example
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>8.3.6&nbsp;



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

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

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

 <B>Date: </B>6 Oct 1998<BR>



<P>
<B>Proposed Resolution (04/99):</B>
Change the text in the example of section 8.3.6&nbsp;



 <A HREF="decl.html#dcl.fct.default">dcl.fct.default</A>
 paragraph 5
from:</P>
<BLOCKQUOTE>... <TT>g</TT> will be called with the value <TT>f(1)</TT>.</BLOCKQUOTE>
to:
<BLOCKQUOTE>... <TT>g</TT> will be called with the value <TT>f(2)</TT>.</BLOCKQUOTE>
<BR>
<BR>
<HR>
<A NAME="136"></A>
<H4>136.
  
Default arguments and friend declarations
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>8.3.6&nbsp;



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

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

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

 <B>Date: </B>9 July 1999
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2<BR>




<P>From reflector messages 8180-90, 8192-8205, and 8215.</P>


<P>8.3.6&nbsp;



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

<BLOCKQUOTE>
For non-template functions, default arguments can be added in later
declarations of a function in the same scope.  Declarations in
different scopes have completely distinct sets of default arguments.
That is, declarations in inner scopes do not acquire default arguments
from declarations in outer scopes, and vice versa.
</BLOCKQUOTE>

It is unclear how this wording applies to friend function declarations.
For example,

<PRE>
    void f(int, int, int=0);             // #1
    class C {
        friend void f(int, int=0, int);  // #2
    };
    void f(int=0, int, int);             // #3
</PRE>

Does the declaration at #2 acquire the default argument from #1, and
does the one at #3 acquire the default arguments from #2?

<P>There are several related questions involved with this issue:</P>

<OL>
<LI>Is the friend
declaration in the scope of class C or in the surrounding namespace
scope?

<P>
<U>Mike Miller</U>:
8.3.6&nbsp;



 <A HREF="decl.html#dcl.fct.default">dcl.fct.default</A>
 paragraph 4
is speaking about the lexical location of the
declaration...
The friend declaration occurs in a different declarative region
from the declaration at #1, so I would read [this paragraph] as saying that it
starts out with a clean slate of default arguments.</P>

<P>
<U>Bill Gibbons</U>:
Yes.  It occurs in a different region, although it declares a name
in the same region (i.e. a redeclaration).  This is the same as with
local externs and is intended to work the same way.  We decided that
local extern declarations cannot add (beyond the enclosing block) new
default arguments, and the same should apply to friend declarations.</P>

<P>
<U>John Spicer</U>:
The question is whether [this paragraph]
does (or should) mean declarations that appear in the same lexical
scope or declarations that declare names in the same scope.  In my opinion,
it really needs to be the latter.  It seems somewhat paradoxical to say
that a friend declaration declares a function in namespace scope yet the
declaration in the class still has its own attributes.  To make that work
I think you'd have to make friends more like block externs that really do
introduce a name into the scope in which the declaration is contained.</P>
</LI>

<LI>Should default arguments be permitted in friend function
declarations, and what effect should they have?

<P>
<U>Bill Gibbons</U>:
In the absence of a declaration visible in class scope to which
they could be attached, default arguments on friend declarations
do not make sense.
[They should be] ill-formed, to prevent surprises.</P>

<P>
<U>John Spicer</U>:
It is important that
the following case work correctly:</P>

<PRE>
        class X {
                friend void f(X x, int i = 1){}
        };

        int main()
        {
                X x;
                f(x);
        }
</PRE>

<P>In other words, a function first declared in a friend declaration must be
permitted to have default arguments and those default arguments must be
usable when the function is found by argument dependent lookup.  The reason
that this is important is that it is common practice to <I>define</I> functions
in friend declarations in templates, and that definition is the only place
where the default arguments can be specified.</P>
</LI>

<LI>What restrictions should be placed on default argument usage with
friend declarations?

<P>
<U>John Spicer</U>:
We want to avoid instantiation side effects.  IMO, the way to do this
would be to prohibit a friend declaration from providing default arguments
if a declaration of that function is already visible.
Once a function has had a default specified in a friend
declaration it should not be possible to add defaults in another declaration
be it a friend or normal declaration.</P>

<P>
<U>Mike Miller</U>:
The position that seems most reasonable to me is to
allow default arguments in friend declarations to be used in
Koenig lookup, but to say that they are
completely unrelated to default arguments in declarations in
the surrounding scope; and to forbid use of a default argument
in a call if more than one declaration in the overload set has
such a default, as in the proposed resolution for
<A HREF="
     cwg_defects.html#1">issue 1</A>.</P>
</LI>

</OL>

(See also issues
<A HREF="
     cwg_defects.html#21">21</A>,
<A HREF="
     cwg_closed.html#95">95</A>,
<A HREF="
     cwg_active.html#138">138</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>.)

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

<P>Four possible outcomes were identified:</P>

<OL>

<LI>If a friend declaration declares a default parameter, allow no
other declarations of that function in the translation unit.</LI>

<LI>Same as preceding, but only allow the friend declaration if it is
also a definition.</LI>

<LI>Disallow default arguments in friend declarations.</LI>

<LI>Treat the default arguments in each friend declaration as a
distinct set, causing an error if the call would be ambiguous.</LI>

</OL>

<P>The core group eliminated the first and fourth options from
consideration, but split fairly evenly between the remaining two.</P>

<P>A straw poll of the full committee yielded the following results
(given as number favoring/could live with/"over my dead body"):</P>

<OL>

<LI>0/14/5</LI>

<LI>8/13/5</LI>

<LI>11/7/14</LI>

<LI>7/10/9</LI>

</OL>

<P>Additional discussion is recorded in the "Record of Discussion" for
the meeting, J16/99-0036 = WG21 N1212.  See also paper
J16/00-0040 = WG21 N1263.</P>

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

<P>In 8.3.6&nbsp;



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

<BLOCKQUOTE>

If a friend declaration specifies a default argument expression,
that declaration must be a definition and shall be the only declaration
of the function or function template in the translation unit.

</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="217"></A>
<H4>217.
  
Default arguments for non-template member functions of class templates
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>8.3.6&nbsp;



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

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

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

 <B>Date: </B>22 Mar 2000
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Spicer<BR>



<P>From reflector messages 8602-4.</P>


<P>
According to 8.3.6&nbsp;



 <A HREF="decl.html#dcl.fct.default">dcl.fct.default</A> paragraphs 4 and 6,

<BLOCKQUOTE>

<P>For non-template functions, default arguments can be added in later
declarations of a function in the same scope.</P>

<P>The default arguments in a member function definition that appears
outside of the class definition are added to the set of default
arguments provided by the member function declaration in the class
definition.</P>

</BLOCKQUOTE>
</P>

<P>This would appear to allow the following example, in which a
default argument is added to a non-template member function of a class
template:</P>

<PRE>
    template &lt;class T&gt;
    struct S
    {
	void foo (int);
    };

    template &lt;class T&gt;
    void S&lt;T&gt;::foo (int = 0) { }
</PRE>

<P>
<U>John Spicer</U>:
The wording "non-template
functions" is somewhat unclear with respect to member functions of class
templates, but I know that this was intended to include them because it
originates from issue 3.13 of the template issues list that I maintained for
several years.</P>

<P>Having said that, the rationale for this restriction has since been made
obsolete, so this could (in theory) be changed in the standard if it is
problematic for users.</P>

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

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

<P>In 8.3.6&nbsp;



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

<BLOCKQUOTE>

The default arguments in a member function definition that appears
outside of the class definition are added to the set of default
arguments provided by the member function declaration in the class
definition.

</BLOCKQUOTE>

<P>with</P>

<BLOCKQUOTE>

Except for member functions of class templates, the default arguments
in a member function definition that appears outside of the class
definition are added to the set of default arguments provided by the
member function declaration in the class definition.  Default
arguments for a member function of a class template must be specified
on the initial declaration of the member function within the class
template.

</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="5"></A>
<H4>5.
  
CV-qualifiers and type conversions
</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>DR
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Josee Lajoie
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Adamczyk<BR>




<P>(Previously numbered 866.)</P>


<P>The description of copy-initialization in 8.5&nbsp;



 <A HREF="decl.html#dcl.init">dcl.init</A>
 paragraph 14 says:</P>
<UL>
<LI>
If the destination type is a (possibly cv-qualified) class type:

<BR>&nbsp;...</LI>
<LI>
Otherwise (i.e. for the remaining copy-initialization cases), user-defined
conversion sequences that can convert from the source type to the destination
type or (when a conversion function is used) to a derived class thereof
are enumerated ... if the function is a constructor, the call initializes
a temporary of the destination type. ...
</LI>
</UL>
Should "destination type" in this last bullet refer to "cv-unqualified
destination type" to make it clear that the destination type excludes any
cv-qualifiers? This would make it clearer that the following example is
well-formed:
<PRE>
     struct A {
       A(A&amp;);
     };
     struct B : A { };
     
     struct C {
       operator B&amp;();
     };
     
     C c;
     const A a = c; // allowed?
</PRE>
<P>The temporary created with the conversion function is an lvalue of type
<TT>B</TT>. If the temporary must have the cv-qualifiers of the destination
type (i.e. const) then the copy-constructor for <TT>A</TT> cannot be called
to create the object of type <TT>A</TT> from the lvalue of type <TT>const
B</TT>. If the temporary has the cv-qualifiers of the result type of the
conversion function, then the copy-constructor for <TT>A</TT> can be called
to create the object of type <TT>A</TT> from the lvalue of type <TT>const
B</TT>. This last outcome seems more appropriate.</P>

<P>
<U>Steve Adamczyk</U>: (See message
8897.)</P>
<P>Because of late changes to this area, the
relevant text is now the third sub-bullet of the fourth bullet of
8.5&nbsp;



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

<BLOCKQUOTE>

Otherwise (i.e., for the remaining copy-initialization cases),
user-defined conversion sequences that can convert from the source
type to the destination type or (when a conversion function is used)
to a derived class thereof are enumerated...
The function selected is called with the initializer expression as its
argument; if the function is a constructor, the call initializes a
temporary of the destination type.  The result of the call (which is
the temporary for the constructor case) is then used to
direct-initialize, according to the rules above, the object that is
the destination of the copy-initialization.

</BLOCKQUOTE>

<P>The issue still remains whether the wording should refer to "the
cv-unqualified version of the destination type."  I think it
should.
</P>

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

<P>The original example does not illustrate the remaining
problem.  The following example does:</P>

<PRE>
    struct C { };
    C c;
    struct A {
        A(const A&amp;);
        A(const C&amp;);
    };
    const volatile A a = c;    // Okay
</PRE>

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

<P>In 8.5&nbsp;



 <A HREF="decl.html#dcl.init">dcl.init</A>, paragraph 14, bullet 4,
sub-bullet 3, change</P>

<BLOCKQUOTE>

if the function is a constructor, the call initializes a temporary
of the destination type.

</BLOCKQUOTE>

<P>to</P>

<BLOCKQUOTE>

if the function is a constructor, the call initializes a temporary
of the cv-unqualified version of the destination type.

</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="35"></A>
<H4>35.
  
Definition of default-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>DR
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Andrew Koenig
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>29 Jul 1998<BR>




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


<P>Given:</P>
<PRE>
    struct S1 {
        int x;
    };
    
    struct S2 {
        int x;
        double y;
    };
    
    struct S3 {
        int x;
        double y;
        string s;
    };
</PRE>
Once upon a time, we went through a fairly protracted discussion to ensure
that <TT>S1().x</TT> would be guaranteed to be 0. Note that if we declare
<PRE>
    void f()
    {
        S1 s1;
    
        // ...
    }
</PRE>
there is no guarantee of the value of <TT>s1.x</TT>, and that is intentional.
But <TT>S1().x</TT> is different, because <TT>S1()</TT> is an rvalue, and
unless all of its members are defined, the effect of copying it is undefined.

<P>Similarly, <TT>S2().x</TT> and <TT>S2().y</TT> are also defined to be
equal to zero, and here it really matters for many implementations, because
if <TT>S2().y</TT> is just a bunch of random bits, it is entirely possible
that trying to copy <TT>S2().y</TT> will yield a floating-point trap.</P>

<P>However, rather to my surprise, the standard does not define the value
of <TT>S3().x</TT> or <TT>S3().y</TT>, because <TT>S3</TT> is not a POD.
It does define <TT>S3().s</TT> (by running the string constructor), but
once a structure is no longer a POD, the values of uninitialized members
are no longer guaranteed in expressions of the form T().</P>

<P>In my opinion, this definition is a mistake, and the committee's intention
was to zero-initialize all members that do not have an explicitly defined
constructor, whether or not the class is a POD.</P>

<P>
See core reflector messages 7780, 7782, 7785-7787, 7789-7791, 7796 and
7798-7805 for a spirited discussion of this topic.

See also paper J16/99-0014 = WG21 N1191.</P>

<P>
<I>[Note: this issue is resolved by the resolution of
<A HREF="
     cwg_defects.html#178">issue 178</A>.]</I>
</P>
<BR>
<BR>
<HR>
<A NAME="78"></A>
<H4>78.
  
Section 8.5 paragraph 9 should state it only applies to non-static objects
</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>DR
 &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>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>
It should be made clear that this paragraph does not apply to static objects.

<P>
<B>Proposed resolution (10/00):</B> In
8.5&nbsp;



 <A HREF="decl.html#dcl.init">dcl.init</A>
 paragraph 9, replace</P>
<BLOCKQUOTE>
Otherwise, if no initializer is specified for an object..."
</BLOCKQUOTE>
with
<BLOCKQUOTE>
Otherwise, if no initializer is specified for a <B>non-static</B>
object...
</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="151"></A>
<H4>151.
  
Terminology of zero-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>DR
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Valentin Bonnard
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>4 August 1999
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Nelson<BR>



<P>In 3.6.2&nbsp;



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



 <A HREF="decl.html#dcl.init">dcl.init</A>
 paragraphs 5 and 6, the
terms "memory" and "storage" are used in connection with
zero-initialization.  This is inaccurate; it is the variables that are
zero-initialized, not the storage.  (An all-zero bit pattern in the
storage may, in fact, not correspond to the representation of zero
converted to the appropriate type, and it is the latter that is being
described.)</P>

<P>Suggested resolution: remove the words "storage" and "memory" in
these contexts.</P>

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

<P>
Delete the words "The storage for" from the first sentence of
3.6.2&nbsp;



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

<P>
<I>[Note: Revised wording in 8.5&nbsp;



 <A HREF="decl.html#dcl.init">dcl.init</A>
relating to this issue is also found
in <A HREF="
     cwg_defects.html#178">issue 178</A>.]</I>
</P>
<BR>
<BR>
<HR>
<A NAME="178"></A>
<H4>178.
  
More on value-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>DR
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Andrew Koenig
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>25 Oct 1999
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Koenig<BR>



<P>When the Committee considered
<A HREF="
     cwg_defects.html#35">issue 35</A>, another context in which
value initialization might be relevant was overlooked:
<I>mem-initializer</I>s.  It would seem reasonable that if
<TT>T()</TT> as an expression invokes value initialization, that the
same syntactic construct in a <I>mem-initializer-list</I> would do the
same, and the usefulness of value initialization in that context is at
least as great as the standalone case.</P>

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

<P>
<I>[Note: this resolution supersedes the resolution to
<A HREF="
     cwg_defects.html#35">issue 35</A>.]</I>
</P>

<P>In 5.2.3&nbsp;



 <A HREF="expr.html#expr.type.conv">expr.type.conv</A> paragraph 2, replace "whose value
is determined by default-initialization" by "which is
value-initialized".
</P>

<P>In 5.3.4&nbsp;



 <A HREF="expr.html#expr.new">expr.new</A> paragraph 15,</P>

<UL>

<LI>In the first subitem of the first item, restore the missing
period at the end of the first sentence.</LI>

<LI>In the second item, replace the text after the comma by
"the item is value-initialized (8.5&nbsp;



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

</UL>

<P>Replace 8.5&nbsp;



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

<BLOCKQUOTE>

<P>To <I>zero-initialize</I> an object of type <TT>T</TT> means:</P>

<UL>

<LI>if <TT>T</TT> is a scalar type (3.9&nbsp;



 <A HREF="basic.html#basic.types">basic.types</A>), the
object is set to the value of 0 (zero) converted to <TT>T</TT>;</LI>

<LI>if <TT>T</TT> is a non-union class type, each non-static data
member and each base-class subobject is zero-initialized;</LI>

<LI>if <TT>T</TT> is a union type, the object's first named data member
[<I>Footnote:</I> This member must not be <TT>static</TT>, by virtue
of the requirements in 9.5&nbsp;



 <A HREF="class.html#class.union">class.union</A>. <I>end
footnote</I>] is zero-initialized;</LI>

<LI>if <TT>T</TT> is an array type, each element is
zero-initialized;</LI>

<LI>if <TT>T</TT> is a reference type, no initialization is
performed.</LI>

</UL>

<P>To <I>default-initialize</I> an object of type <TT>T</TT> means:</P>

<UL>

<LI>if <TT>T</TT> is a non-POD class type (clause 9&nbsp;



 <A HREF="class.html#class">class</A>), the default constructor for <TT>T</TT> is called (and the
initialization is ill-formed if <TT>T</TT> has no accessible default
constructor);</LI>

<LI>if <TT>T</TT> is an array type, each element is
default-initialized;</LI>

<LI>otherwise, the object is zero-initialized.</LI>

</UL>

<P>To <I>value-initialize</I> an object of type <TT>T</TT> means: </P>

<UL>

<LI>if <TT>T</TT> is a class type (clause 9&nbsp;



 <A HREF="class.html#class">class</A>)
with a user-declared constructor (12.1&nbsp;



 <A HREF="special.html#class.ctor">class.ctor</A>), then
the default constructor for <TT>T</TT> is called (and the
initialization is ill-formed if <TT>T</TT> has no accessible default
constructor);</LI>

<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;</LI>

<LI>if <TT>T</TT> is an array type, then each element is
value-initialized; </LI>

<LI>otherwise, the object is zero-initialized. </LI>

</UL>

<P>A program that calls for default-initialization of an entity of
reference type is ill-formed.  If <TT>T</TT> is a cv-qualified type,
the cv-unqualified version of <TT>T</TT> is used for these definitions
of zero-initialization, default-initialization, and
value-initialization.</P>

</BLOCKQUOTE>

<P>In 8.5&nbsp;



 <A HREF="decl.html#dcl.init">dcl.init</A> paragraph 6, change "The memory
occupied by any" to "Every".</P>


<P>In 8.5&nbsp;



 <A HREF="decl.html#dcl.init">dcl.init</A> paragraph 7, replace
"default-initialized" by "value-initialized".</P>


<P>In 8.5.1&nbsp;



 <A HREF="decl.html#dcl.init.aggr">dcl.init.aggr</A> paragraph 7, replace
"default-initialized" by "value-initialized".</P>


<P>In 12.3.1&nbsp;



 <A HREF="special.html#class.conv.ctor">class.conv.ctor</A> paragraph 2, insert "or
value-initialization" after the first occurrence of
"default-initialization".</P>


<P>In 12.6&nbsp;



 <A HREF="special.html#class.init">class.init</A> paragraph 1, replace the note by "The
object is default-initialized if there is no initializer, or
value-initialized if the initializer is <TT>()</TT>" [i.e., replace
the non-normative note by different, normative text].</P>


<P>In 12.6.1&nbsp;



 <A HREF="special.html#class.expl.init">class.expl.init</A> paragraph 2, replace
"default-initialized" by "value-initialized".</P>


<P>In 12.6.2&nbsp;



 <A HREF="special.html#class.base.init">class.base.init</A> paragraph 3, replace
"default-initialized" by "value-initialized" in the first bulleted
item.</P>

<P>In 12.6.2&nbsp;



 <A HREF="special.html#class.base.init">class.base.init</A> paragraph 4, replace
"default-initialized, nor initialized" by "default-initialized, nor
value-initialized, nor assigned".</P>

<BR>
<BR>
<HR>
<A NAME="277"></A>
<H4>277.
  
Zero-initialization of pointers
</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>DR
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Andrew Sawyer
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>5 Apr 2001
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>0
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Miller<BR>


<P>(From messages 9110-15, 9130, and 9135.)</P>

<P>The intent of 8.5&nbsp;



 <A HREF="decl.html#dcl.init">dcl.init</A> paragraph 5 is that
pointers that are zero-initialized will contain a null pointer
value.  Unfortunately, the wording used,</P>

<BLOCKQUOTE>

...set to the value of 0 (zero) converted to <TT>T</TT>

</BLOCKQUOTE>

<P>does not match the requirements for creating a null pointer
value given in 4.10&nbsp;



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

<BLOCKQUOTE>

A <I>null pointer constant</I> is an integral constant expression
(5.19&nbsp;



 <A HREF="expr.html#expr.const">expr.const</A>) rvalue of integer type that evaluates to
zero. A null pointer constant can be converted to a pointer type; the
result is the <I>null pointer value</I> of that type...

</BLOCKQUOTE>

<P>The problem is that the "value of 0" in the description of
zero-initialization is not specified to be an integral constant
expression.  Nonconstant expressions can also have the value 0,
and converting a nonconst 0 to pointer type need not result in
a null pointer value.</P>

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

<P>In 8.5&nbsp;



 <A HREF="decl.html#dcl.init">dcl.init</A> paragraph 5, change</P>

<BLOCKQUOTE>

...set to the value 0 (zero) converted to <TT>T</TT>;

</BLOCKQUOTE>

<P>to</P>

<BLOCKQUOTE>

...set to the value 0 (zero), taken as an integral constant
expression, converted to <TT>T</TT>; [<I>footnote:</I> as
specified in 4.10&nbsp;



 <A HREF="conv.html#conv.ptr">conv.ptr</A>, converting an integral
constant expression whose value is 0 to a pointer type results
in a null pointer value.]

</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="163"></A>
<H4>163.
  
Description of subaggregate initializer
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>8.5.1&nbsp;



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

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

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

 <B>Date: </B>12 Aug 1999<BR>



<P>8.5.1&nbsp;



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

<BLOCKQUOTE>
When an aggregate is initialized the <I>initializer</I> can be an
<I>initializer-clause</I> consisting of a brace-enclosed,
comma-separated list of <I>initializer</I>s for the members of the
aggregate.
</BLOCKQUOTE>

Neither of these uses of the syntactic nonterminal <I>initializer</I>
corresponds to the grammar:

<UL>
<I>initializer</I>:
<UL>
<TT>=</TT> <I>initializer-clause</I>
</UL>
<UL>
<TT>(</TT> <I>expression-list</I> <TT>)</TT>
</UL>
</UL>

<P>
<B>Proposed resolution (10/99):</B> replace the quoted words with:</P>

<BLOCKQUOTE>
When an aggregate is initialized the <I>initializer</I> can
<B>contain</B> an <I>initializer-clause</I> consisting of a
brace-enclosed, comma-separated list of
<B><I>initializer-clause</I>s</B> for the members of the aggregate.
</BLOCKQUOTE>
<BR>
<BR>
<HR>
<A NAME="148"></A>
<H4>148.
  
POD classes and pointers to members
</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>DR
 &nbsp;&nbsp;&nbsp;

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

 <B>Date: </B>31 Jul 1999
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>3<BR>



<P>3.9&nbsp;



 <A HREF="basic.html#basic.types">basic.types</A>
 paragraph 10
defines pointer to member types to be scalar types. It
also defines scalar types to be one of the POD types.</P>

<P>9&nbsp;



 <A HREF="class.html#class">class</A>
 paragraph 4
defines a POD struct as an aggregate class with no non-static data
members of type pointer to member.</P>

<P>It seems contradictory that a type can be POD,
yet a class containing that type
is non-POD.</P>

<P>Suggested resolution:
Alter 9&nbsp;



 <A HREF="class.html#class">class</A>
 paragraph 4
to allow pointer to member objects as non-static data members of POD
class.</P>

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

<P>In 9&nbsp;



 <A HREF="class.html#class">class</A> paragraph 4, remove all occurrences of
"pointer to member."</P>
<BR>
<BR>
<HR>
<A NAME="175"></A>
<H4>175.
  
Class name injection and base name access
</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>DR
 &nbsp;&nbsp;&nbsp;

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

 <B>Date: </B>21 February 1999
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Spicer<BR>



<P>With class name injection, when a base class name is used in a derived
class, the name found is the injected name in the base class, not the
name of the class in the scope containing the base class.
Consequently, if the base class name is not accessible (e.g., because
is is in a private base class), the base class name cannot be used
unless a qualified name is used to name the class in the class or
namespace of which it is a member.</P>

<P>Without class name injection the following example is valid.  With
class name injection, <TT>A</TT> is inaccessible in class <TT>C</TT>.</P>

<PRE>
    class A { };
    class B: private A { };
    class C: public B {
        A* p;    // error: A inaccessible
    };
</PRE>

<P>At the least, the standard should be more explicit that this is, in
fact, ill-formed.</P>

<P>(See paper J16/99-0010 = WG21 N1187.)</P>

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

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



 <A HREF="access.html#class.access.spec">class.access.spec</A> paragraph 3:</P>

<BLOCKQUOTE>

<P>[<I>Note:</I> In a derived class, the lookup of a base class name
will find the injected-class-name instead of the name of the base
class in the scope in which it was declared.  The
injected-class-name might be less accessible than the name of the
base class in the scope in which it was declared.] [<I>Example:</I>
</P>

<PRE>
    class A { };
    class B : private A { };
    class C : public B {
        A* p;    // error: injected-class-name A is inaccessible
        ::A* q;  // OK
    };
</PRE>

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

</BLOCKQUOTE>
<BR>
<BR>
<HR>
<A NAME="176"></A>
<H4>176.
  
Name injection and templates
</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>DR
 &nbsp;&nbsp;&nbsp;

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

 <B>Date: </B>21 February 1999
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>1
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Spicer<BR>



<P>There is some controversy about whether class name injection applies
to class templates.  If it does apply, what is injected?  Is a class
name injected or is the thing that is injected actually a template?</P>

<P>Clause 9&nbsp;



 <A HREF="class.html#class">class</A>
 paragraph 2 says,</P>
<BLOCKQUOTE>
The <I>class-name</I> is also inserted into the scope of the class
itself.
</BLOCKQUOTE>

In general, clause 9 applies to both classes and class templates, so I
would take this to mean that class name imjection does indeed apply to
class templates.  One problem with this is that clause 9 uses the
syntactic term <I>class-name</I>, which I would take to imply that the
inserted name is always a class.  This is clearly unacceptable for
class templates as it makes the template itself unusable from with the
template.  For example:

<PRE>
    template &lt;class T&gt; struct A {
        A&lt;T*&gt; ptr;    // Invalid: A refers to a class
    };
</PRE>

<P>Clearly the injected name must be usable as both a class and a
class template.  This kind of magic already exists in the standard.
In 14.6.1&nbsp;



 <A HREF="template.html#temp.local">temp.local</A>
 it says,</P>

<BLOCKQUOTE>
Within the scope of a class template, when the name of the template is
neither qualified nor followed by <TT>&lt;</TT>, it is equivalent to
the name of the template followed by the
<I>template-parameter</I>s enclosed in &lt;&gt;.
</BLOCKQUOTE>

<P>The proposal here is that we clarify that name injection does
indeed apply to class templates, and that it is the injected name that
has the special property of being usable as both a class and a
template name (as described in
14.6.1&nbsp;



 <A HREF="template.html#temp.local">temp.local</A>
).  This would eliminate
the need for special wording regarding the qualification of the name,
but would achieve the same result.  This would also make this
"special" name available to a derived class of a class template
&mdash; something which is necessary if the benefits of class name
injection are to be made uniformly available for class templates, too.</P>

<PRE>
    template &lt;class T&gt; struct Base {
        Base* p;
        Base&lt;T*&gt;* p2;
        ::Base* p3;    // Error: only injected name usable as class
    };

    template &lt;class T&gt; struct Derived: public Base&lt;T&gt; {
        Base* p;    // Now okay
        Base&lt;T*&gt;* p2;    // Still okay
        Derived::Base* p3;    // Now okay
</PRE>

Note that by giving the special attribute of being usable as both a
class and a template to the injected name it is now clear where this
attribute can and cannot be used.

<P>(See paper J16/99-0010 = WG21 N1187.)</P>

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

<P>
<I>[Note: these changes depend on the resolution for <A HREF="
     cwg_defects.html#147">issue 147</A>.]</I>
</P>

<P>Replace 14.6.1&nbsp;



 <A HREF="template.html#temp.local">temp.local</A> paragraphs 1 and 2 with the
following:</P>

<BLOCKQUOTE>

<P>Like normal (non-template) classes, class templates have an
injected-class-name (clause 9&nbsp;



 <A HREF="class.html#class">class</A>).  The
injected-class-name can be used with or without a
<I>template-argument-list</I>.  When it is used without a
<I>template-argument-list</I>, it is equivalent to the
injected-class-name followed by the <I>template-parameter</I>s of the
class template enclosed in <TT>&lt;&gt;</TT>.  When it is used with a
<I>template-argument-list</I>, it refers to the specified class
template specialization, which could be the current specialization or
another specialization.</P>

<P>Within the scope of a class template specialization or partial
specialization, when the injected-class-name is not followed by a
<TT>&lt;</TT>, it is equivalent to the injected-class-name followed by
the <I>template-argument</I>s of the class template specialization or
partial specialization enclosed in <TT>&lt;&gt;</TT>.
[<I>Example:</I>
</P>

<PRE>
    template&lt;class T&gt; class Y;
    template&lt;&gt; class Y&lt;int&gt; {
        Y* p;          // <I>meaning</I> Y&lt;int&gt;
        Y&lt;char&gt;* q;    // <I>meaning</I> Y&lt;char&gt;
    };
</PRE>

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

<P>The injected-class-name of a class template or class template
specialization can be used either with or without a
<I>template-argument-list</I> wherever it is in scope.
[<I>Example:</I>
</P>

<PRE>
    template &lt;class T&gt; struct Base {
        Base* p;
    };

    template &lt;class T&gt; struct Derived: public Base&lt;T&gt; {
        typename Derived::Base* p;  // <I>meaning</I> Derived::Base&lt;T&gt;
    };
</PRE>

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

<P>A lookup that finds an injected-class-name (10.2&nbsp;



 <A HREF="derived.html#class.member.lookup">class.member.lookup</A>) can result in an ambiguity in certain cases (for
example, if it is found in more than one base class).  If all of the
injected-class-names that are found refer to specializations of the
same class template, and if the name is followed by a
<I>template-argument-list</I>, the reference refers to the class
template itself and not a specialization thereof, and is not
ambiguous.  [<I>Example:</I>
</P>

<PRE>
    template &lt;class T&gt; struct Base { };
    template &lt;class T&gt; struct Derived: Base&lt;int&gt;, Base&lt;char&gt; {
        typename Derived::Base b;            // <I>error: ambiguous</I>
        typename Derived::Base&lt;double&gt; d;    // <I>OK</I>
    };
</PRE>

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

<P>When the normal name of the template (i.e., the name from the
enclosing scope, not the injected-class-name) is used without a
<I>template-argument-list</I>, it refers to the class template itself
and not a specialization of the template.  [<I>Example:</I>
</P>

<PRE>
    template &lt;class T&gt; class X {
        X* p;         // <I>meaning</I> X&lt;T&gt;
        X&lt;T&gt;* p2;
        X&lt;int&gt;* p3;
        ::X* p4;      // <I>error: missing template argument list</I>
                      // ::X <I>does not refer to the injected-class-name</I>
    };
</PRE>

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

</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="75"></A>
<H4>75.
  
In-class initialized members must be const
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>9.2&nbsp;



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

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

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

 <B>Date: </B>29 Dec 1998<BR>




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


<P>The standard says, in
9.2&nbsp;



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

paragraph 4:</P>
<BLOCKQUOTE>A <I>member-declarator</I> can contain a
<I>constant-initializer</I> only
if it declares a <TT>static</TT> member
(9.4&nbsp;



 <A HREF="class.html#class.static">class.static</A>
)
of integral or enumeration type, see
9.4.2&nbsp;



 <A HREF="class.html#class.static.data">class.static.data</A>
.</BLOCKQUOTE>
But later, in the section on static class data member initialization,
9.4.2&nbsp;



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

paragraph 4, it says:
<BLOCKQUOTE>
If a <TT>static</TT> data member is of <TT>const</TT> integral
or <TT>const</TT> enumeration
type, its declaration in the class definition can specify a
<I>constant-initializer</I> which shall be an integral constant expression
(5.19&nbsp;



 <A HREF="expr.html#expr.const">expr.const</A>
). In that case, the
member can appear in integral constant expressions within its scope.
</BLOCKQUOTE>
The first paragraph should be modified to make it clear that it is not possible
to initialize a static data member in-line with a constant-initializer if that
data member is of integral (or enumeration) type, and yet not const.

<P>
<B>Proposed Resolution (10/99):</B>
Change the sentence in 9.2&nbsp;



 <A HREF="class.html#class.mem">class.mem</A>
 paragraph 4 to read:</P>
<BLOCKQUOTE>
A <I>member-declarator</I> can contain a <I>constant-initializer</I>
only if it declares a <TT>static</TT> member
(9.4&nbsp;



 <A HREF="class.html#class.static">class.static</A>
)
of <TT>const</TT> integral or <TT>const</TT> enumeration type,
see 9.4.2&nbsp;



 <A HREF="class.html#class.static.data">class.static.data</A>
.
</BLOCKQUOTE>
<BR>
<BR>
<HR>
<A NAME="80"></A>
<H4>80.
  
Class members with same name as class
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>9.2&nbsp;



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

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

 <B>Submitter: </B>Jason Merrill
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>5 Dec 1998
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Merrill<BR>




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


<P>Between the May '96 and September '96 working papers, the text in
9.2&nbsp;



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

paragraph 13:</P>
<BLOCKQUOTE>If <TT>T</TT> is the name of a class, then each of the following
shall have a name different from <TT>T</TT>:
<UL>
<LI>
every static data member of class <TT>T</TT>;</LI>
</UL>
</BLOCKQUOTE>
was changed by removing the word 'static'. Looking over the meeting
minutes from Stockholm, none of the proposals seem to include this
change, which breaks C compatibility and is not mentioned in the compatibility
annex. Was this change actually voted in by the committee?

<P>Specifically, this breaks <TT>/usr/include/netinet/in.h</TT> under Linux,
in which "<TT>struct ip_opts</TT>" shares its name with one of its members.</P>

<P>
<B>Proposed resolution (10/00):</B>
</P>
<OL>
<LI>
Change the first bullet of
9.2&nbsp;



 <A HREF="class.html#class.mem">class.mem</A>
 paragraph 13 to say
<UL>
<LI>
every static data member of class <TT>T</TT>;</LI>
</UL>
<LI>
Add another paragraph before
9.2&nbsp;



 <A HREF="class.html#class.mem">class.mem</A>
 paragraph 14, reading
<BLOCKQUOTE>
In addition, if class <TT>T</TT> has a user-declared constructor
(12.1&nbsp;



 <A HREF="special.html#class.ctor">class.ctor</A>
), every nonstatic
data member of class <TT>T</TT> shall have a name different from
<TT>T</TT>.
</BLOCKQUOTE>
</LI>
</LI>
</OL>
<BR>
<BR>
<HR>
<A NAME="190"></A>
<H4>190.
  
Layout-compatible POD-struct types
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>9.2&nbsp;



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

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

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

 <B>Date: </B>20 Dec 1999
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>3
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Merrill<BR>




<P>From reflector messages 8411-12.</P>


<P>The definition of layout-compatible POD-struct types in
9.2&nbsp;



 <A HREF="class.html#class.mem">class.mem</A>
 paragraph 14 requires that
the two types</P>

<BLOCKQUOTE>
have the same number of members, and corresponding members (in order)
have layout-compatible types (3.9).
</BLOCKQUOTE>

There does not appear to be any reason for including member functions
and static data members in this requirement.  It would be more logical
to require only that the non-static data members of the two types must
match.

<P>The characteristics of layout-compatible types are not well
described in the current wording, either.  Apart from their use in
9.2&nbsp;



 <A HREF="class.html#class.mem">class.mem</A>
 paragraph 16 to define the
term "common initial sequence," there appears to be nothing said about
which operations are possible between objects of layout-compatible types.
For example, 3.9&nbsp;



 <A HREF="basic.html#basic.types">basic.types</A>
 paragraphs
2-3 give certain guarantees regarding use of <TT>memcpy</TT> on
objects of the same type; it might be reasonable to assume that the
same kinds of guarantees might apply to objects of layout-compatible
types, but that is not said.  Similarly,
3.10&nbsp;



 <A HREF="basic.html#basic.lval">basic.lval</A>
 paragraph 15 describes
permissible "type punning" but does not mention layout-compatible types.</P>

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

<P>In 9.2&nbsp;



 <A HREF="class.html#class.mem">class.mem</A> paragraphs 14 and 15, change all
occurrences of "members" to "nonstatic data members."</P>
<BR>
<BR>
<HR>
<A NAME="67"></A>
<H4>67.
  
Evaluation of left side of object-expression
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>9.4&nbsp;



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

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

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

 <B>Date: </B>6 Oct 1998<BR>



<P>Paragraph 2 says that "the object-expression is always evaluated" when
the class member syntax is used to refer to a static member. This
presumably should say that the object expression is evaluated if the member
access is performed, i.e., not if the overall expression is the operand
of <TT>sizeof</TT> or the unevaluated branch of <TT>?:</TT>, <TT>||</TT>, or <TT>&amp;&amp;</TT>.</P>

<P>
<B>Proposed Resolution (10/99):</B>
Replace "is always evaluated" by "is evaluated" in
9.4&nbsp;



 <A HREF="class.html#class.static">class.static</A>
 paragraph 2.</P>
<BR>
<BR>
<HR>
<A NAME="48"></A>
<H4>48.
  
Definitions of unused static members
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>9.4.2&nbsp;



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

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

 <B>Submitter: </B>Bill Gibbons
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>23 Nov 1997<BR>



<P>Also see section: 3.2&nbsp;



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

<P>Originally, all static data members still had to be defined outside the
class whether they were used or not.</P>

<P>But that restriction was supposed to be lifted so that static
data members need not be defined outside the class unless they are used
in a manner which requires their definition,
in the same manner as namespace-scope
variables. In particular, if an integral/enum const static data member
is initialized within the class, and its address is never taken, we agreed
that no namespace-scope definition was required.</P>

<P>For example:</P>
<PRE>
    struct A {
        static const int size = 10;
        int array[size];
    };
    
    int main() {
        A a;
        return 0;
    }
</PRE>
However, 9.4.2&nbsp;



 <A HREF="class.html#class.static.data">class.static.data</A>
 paragraph 4 says:
<BLOCKQUOTE>The member shall still be defined in a namespace scope if it
is used in the program and the namespace scope definition shall not contain
an initializer.</BLOCKQUOTE>
A narrow interpreration of "used" in this rule would make the example ill-formed
because there is no namespace-scope definition of "<TT>size</TT>".
A better wording for this rule would be:
<BLOCKQUOTE>The member shall still be defined in a namespace scope if it
is used in the program in the manner described in 3.2&nbsp;



 <A HREF="basic.html#basic.def.odr">basic.def.odr</A>
.
The namespace scope definition shall not contain an initializer.</BLOCKQUOTE>
Also, the wording in 3.2&nbsp;



 <A HREF="basic.html#basic.def.odr">basic.def.odr</A>
 paragraph 2:
<BLOCKQUOTE>An expression is potentially evaluated unless either it is
the operand of the <TT>sizeof</TT> operator (5.3.3&nbsp;



 <A HREF="expr.html#expr.sizeof">expr.sizeof</A>
), or it is the operand
of the <TT>typeid</TT> operator and does not designate an lvalue of polymorphic
class type (5.2.8&nbsp;



 <A HREF="expr.html#expr.typeid">expr.typeid</A>
).</BLOCKQUOTE>
is incomplete because it does not mention the use of a compile-time constant
as an array bound or template argument. It should say something like:
<BLOCKQUOTE>An expression is potentially evaluated unless it is the operand
of the sizeof operator (5.3.3&nbsp;



 <A HREF="expr.html#expr.sizeof">expr.sizeof</A>
), the operand of the typeid operator,
<U>an <I>integral constant-expression</I> used as an array bound or an
<I>integral constant-expression</I> used as a <I>template-argument</I>
for a non-reference <I>template-parameter</I></U>; and the expression
does not designate an lvalue of polymorphic class type (5.2.8&nbsp;



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

<P>
<B>Proposed Resolution (04/99):</B>
Change the first sentence of 3.2&nbsp;



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

paragraph 2 from:</P>
<BLOCKQUOTE>An expression is <I>potentially evaluated</I> unless either
it is the operand of the <TT>sizeof</TT> operator (5.3.3&nbsp;



 <A HREF="expr.html#expr.sizeof">expr.sizeof</A>
), or it is the
operand of the <TT>typeid</TT> operator and does not designate an lvalue
of polymorphic class type (5.2.8&nbsp;



 <A HREF="expr.html#expr.typeid">expr.typeid</A>
).</BLOCKQUOTE>
to:
<BLOCKQUOTE>An expression is <I>potentially evaluated</I> unless <U>it
appears where an <I>integral constant expression</I> is required (see 5.19&nbsp;



 <A HREF="expr.html#expr.const">expr.const</A>
),
is
</U>the operand of the <TT>sizeof</TT> operator (5.3.3&nbsp;



 <A HREF="expr.html#expr.sizeof">expr.sizeof</A>
), or
is the operand of the <TT>typeid</TT> operator and the expression does
not designate an lvalue of polymorphic class type (5.2.8&nbsp;



 <A HREF="expr.html#expr.typeid">expr.typeid</A>
).</BLOCKQUOTE>
<BR>
<BR>
<HR>
<A NAME="8"></A>
<H4>8.
  
Access to template arguments used in a function return type and in the nested name specifier
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>11&nbsp;



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

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

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

 <B>Date: </B>unknown
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>3<BR>




<P>(Previously numbered 898.)</P>


<P>Consider the following example:</P>
<PRE>
    class A {
       class A1{};
       static void func(A1, int);
       static void func(float, int);
       static const int garbconst = 3;
     public:
       template &lt; class T, int i, void (*f)(T, int) &gt; class int_temp {};
       template&lt;&gt; class int_temp&lt;A1, 5, func&gt; { void func1() };
       friend int_temp&lt;A1, 5, func&gt;::func1();
       int_temp&lt;A1, 5, func&gt;* func2();
   };
   A::int_temp&lt;A::A1, A::garbconst + 2, &amp;A::func&gt;* A::func2() {...}
</PRE>
<B><U>ISSUE 1:</U></B>

<P>In 11&nbsp;



 <A HREF="access.html#class.access">class.access</A>
 paragraph 5 we have:
<UL>All access controls in clause 11 affect the ability to access a class
member name from a particular scope... In particular, access controls
apply as usual to member names accessed as part of a function return type,
even though it is not possible to determine the access privileges of that
use without first parsing the rest of the function declarator.</UL>
This means, if we take the loosest possible definition of "access from
a particular scope", that we have to save and check later the following
names</P>
<PRE>
      A::int_temp
      A::A1
      A::garbconst (part of an expression)
      A::func (after overloading is done)
</PRE>
I suspect that member templates were not really considered when this was
written, and that it might have been written rather differently if they
had been. Note that access to the template arguments is only legal because
the class has been declared a friend, which is probably not what most programmers
would expect.

<P>
<B>Rationale:</B>
</P>

<P>Not a defect. This behavior is as intended.</P>

<P>
<B><U>ISSUE 2:</U></B>
</P>

<P>Now consider <TT>void A::int_temp&lt;A::A1, A::garbconst + 2, &amp;A::func&gt;::func1()
{...}</TT> By my reading of 11.8&nbsp;



 <A HREF="access.html#class.access.nest">class.access.nest</A>
, the references to
<TT>A::A1</TT>, <TT>A::garbconst</TT> and <TT>A::func</TT> are now illegal,
and there is no way to define this function outside of the class. Is there
any need to do anything about either of these Issues?</P>

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

<P>The resolution for this issue is contained in the resolution
for <A HREF="
     cwg_defects.html#45">issue 45</A>.</P>
<BR>
<BR>
<HR>
<A NAME="9"></A>
<H4>9.
  
Clarification of access to base class members
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>11.2&nbsp;



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

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

 <B>Submitter: </B>unknown
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Wilcox<BR>




<P>(Previously numbered 899.)</P>


<P>11.2&nbsp;



 <A HREF="access.html#class.access.base">class.access.base</A>
 paragraph 4 says:</P>
<BLOCKQUOTE>A base class is said to be accessible if an invented public
member of the base class is accessible. If a base class is accessible,
one can implicitly convert a pointer to a derived class to a pointer to
that base class.</BLOCKQUOTE>
Given the above, is the following well-formed?
<PRE>
    class D;
     
    class B
    {
     protected:
       int b1;
 
       friend void foo( D* pd );
    };
     
    class D : protected B { };
     
    void foo( D* pd )
    {
       if ( pd-&gt;b1 &gt; 0 ); // Is 'b1' accessible?
    }
</PRE>
Can you access the protected member <TT>b1</TT> of <TT>B</TT> in <TT>foo</TT>?
Can you convert a <TT>D*</TT> to a <TT>B*</TT> in <TT>foo</TT>?

<P>
<U>1st interpretation:</U>
</P>

<P>A public member of <TT>B</TT> is accessible within <TT>foo</TT> (since
<TT>foo</TT> is a friend), therefore <TT>foo</TT> can refer to <TT>b1</TT> and convert
a <TT>D*</TT> to a <TT>B*</TT>.</P>

<P>
<U>2nd interpretation:</U>
</P>

<P>
<TT>B</TT> is a protected base class of <TT>D</TT>, and a public member of <TT>B</TT>
is a protected member of <TT>D</TT> and can only be accessed within members
of <TT>D</TT> and friends of <TT>D</TT>. Therefore <TT>foo</TT> cannot refer to
<TT>b1</TT> and cannot convert a <TT>D*</TT> to a <TT>B*</TT>.</P>

<P>(See J16/99-0042 = WG21 N1218.)</P>

<P>
<B>Proposed Resolution (04/01):</B>
</P>
<OL>
<LI>
Add preceding 11.2&nbsp;



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

paragraph 4:

<BLOCKQUOTE>
A base class <TT>B</TT> of <TT>N</TT> is <I>accessible</I> at <I>R</I>,
if
<UL>
<LI>
an invented public member of <TT>B</TT> would be a public member
of <TT>N</TT>, or</LI>
<LI>
<I>R</I> occurs in a member or friend of class <TT>N</TT>, and an
invented public member of <TT>B</TT> would be a private or protected
member of <TT>N</TT>, or</LI>
<LI>
<I>R</I> occurs in a member or friend of a class <TT>P</TT> derived
from <TT>N</TT>, and an invented public member of <TT>B</TT> would be
a private or protected member of <TT>P</TT>, or</LI>
<LI>
there exists a class <TT>S</TT> such that <TT>B</TT> is a base class
of <TT>S</TT> accessible at <I>R</I> and <TT>S</TT> is a base class
of <TT>N</TT> accessible at <I>R</I>. [<I>Example:</I>
<PRE>
    class B {
    public:
        int m;
    };

    class S: private B {
        friend class N;
    };

    class N: private S {
        void f() {
	    B* p = this;  // <I>OK because class S satisfies the</I>
			// <I>fourth condition above: B is a base</I>
			// <I>class of N accessible in f() because</I>
			// <I>B is an accessible base class of S</I>
			// <I>and S is an accessible base class of N.</I>
        }
    };
</PRE>
&mdash;<I>end example</I>]
</LI>
</UL>
</BLOCKQUOTE>
</LI>
<LI>
Delete the first sentence of
11.2&nbsp;



 <A HREF="access.html#class.access.base">class.access.base</A>
 paragraph 4:
<BLOCKQUOTE>
A base class is said to be accessible if an invented public member
of the base class is accessible.
</BLOCKQUOTE>
</LI>
<LI>
Replace the last sentence ("A member <I>m</I> is accessible...")
by the following:
<BLOCKQUOTE>
A member <TT>m</TT> is accessible at the point <I>R</I> when
named in class <TT>N</TT> if
<UL>
<LI>
<TT>m</TT> as a member of <TT>N</TT> is public, or</LI>
<LI>
<TT>m</TT> as a member of <TT>N</TT> is private, and <I>R</I>
occurs in a member or friend of class <TT>N</TT>, or</LI>
<LI>
<TT>m</TT> as a member of <TT>N</TT> is protected, and <I>R</I>
occurs in a member or friend of class <TT>N</TT>, or in a member
or friend of a class <TT>P</TT> derived from <TT>N</TT>, where
<TT>m</TT> as a member of <TT>P</TT> is private or protected, or</LI>
<LI>
there exists a base class <TT>B</TT> of <TT>N</TT> that is
accessible at <I>R</I>, and <TT>m</TT> is accessible at <I>R</I>
when named in class <TT>B</TT>. [<I>Example:</I>...
</LI>
</UL>
</BLOCKQUOTE>
</LI>
</OL>

<P>The resolution for <A HREF="
     cwg_defects.html#207">issue 207</A> modifies
this wording slightly.</P>

<BR>
<BR>
<HR>
<A NAME="16"></A>
<H4>16.
  
Access to members of indirect private base classes
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>11.2&nbsp;



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

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

 <B>Submitter: </B>unknown
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Wilcox<BR>




<P>(Previously numbered 924.)</P>


<P>The text in 11.2&nbsp;



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

paragraph 4 does not seem to handle the following cases:</P>
<PRE>
    class D;
     
    class B {
    private:
        int i;
        friend class D;
    };
     
    class C : private B { };
     
    class D : private C {
        void f() {
            B::i; //1: well-formed?
            i;    //2: well-formed?
        }
    };
</PRE>
The member <TT>i</TT> is not a member of <TT>D</TT> and cannot be
accessed in the
scope of <TT>D</TT>. What is the naming class of the member
<TT>i</TT> on line <TT>//1</TT>
and <TT>line //2</TT>?

<P>
<B>Proposed Resolution (04/01):</B> The resolution for this issue
is contained in the resolution for <A HREF="
     cwg_defects.html#9">issue 9</A>..</P>
<BR>
<BR>
<HR>
<A NAME="142"></A>
<H4>142.
  
Injection-related errors in access example
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>11.2&nbsp;



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

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

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

 <B>Date: </B>16 Jul 1999
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Adamczyk<BR>




<P>From reflector messages 8217-19.</P>


<P>In the example in paragraph 3 of
11.2&nbsp;



 <A HREF="access.html#class.access.base">class.access.base</A>
, all the references
to <TT>B</TT> in <TT>DD::f()</TT> should be replaced by <TT>::B</TT>.
The reason is that the class name <TT>B</TT> is private in <TT>D</TT>
and thus inaccessible in <TT>DD</TT>.  (The example was probably not
updated when class name injection was added.)</P>

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

<P>Replace the example in
11.2&nbsp;



 <A HREF="access.html#class.access.base">class.access.base</A>
 paragraph 3 with:</P>
<PRE>
    class B {
    public:
        int mi;                 // nonstatic member
        static int si;          // static member
    };
    class D: private B {
    };
    class DD: public D {
        void f();
    };
    void DD::f() {
        mi = 3;                 // error: mi is private in D
        si = 3;                 // error: si is private in D
        ::B b;
        b.mi = 3;               // OK (b.mi is different from this-&gt;mi)
        b.si = 3;               // OK (b.si is different from this-&gt;si)
        ::B::si = 3;            // OK
        ::B* bp1 = this;        // error: B is a private base class
        ::B* bp2 = (::B*)this;  // OK with cast
        bp2-&gt;mi = 3;            // OK: access through a pointer to B
    }
</PRE>
<BR>
<BR>
<HR>
<A NAME="207"></A>
<H4>207.
  
<I>using-declaration</I>s and protected access
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>11.2&nbsp;



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

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

 <B>Submitter: </B>Jason Merrill
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>28 Feb 2000
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Merrill<BR>



<P>From reflector messages 8562-3.</P>


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

<PRE>
  class A {
  protected:
    static void f() {};
  };

  class B : A {
  public:
    using A::f;
    void g() {
      A::f();
    }
  };
</PRE>

<P>The standard says in 11.2&nbsp;



 <A HREF="access.html#class.access.base">class.access.base</A> paragraph 4 that
the call to <TT>A::f</TT> is ill-formed:</P>

<BLOCKQUOTE>
A member <I>m</I> is accessible when named in class <I>N</I> if

<UL>
<LI>
<I>m</I> as a member of <I>N</I> is public, or</LI>

<LI>
<I>m</I> as a member of <I>N</I> is private, and the reference
occurs in a member or friend of class <I>N</I>, or</LI>

<LI>
<I>m</I> as a member of <I>N</I> is protected, and the reference
occurs in a member or friend of class <I>N</I>, or in a member or
friend of a class <I>P</I> derived from <I>N</I>, where <I>m</I> as a
member of <I>P</I> is private or protected, or</LI>

<LI>there exists a base class <I>B</I> of <I>N</I> that is accessible
at the point of reference, and <I>m</I> is accessible when named in
class <I>B</I>.</LI>

</UL>
</BLOCKQUOTE>

<P>Here, <I>m</I> is <TT>A::f</TT> and <I>N</I> is <TT>A</TT>.</P>

<UL>
<LI>
<TT>f</TT> as a member of <TT>A</TT> is public?  <B>No</B>.</LI>

<LI>
<TT>f</TT> as a member of <TT>A</TT> is private? <B>No</B>.</LI>

<LI>
<TT>f</TT> as a member of <TT>A</TT> is protected?
<B>Yes</B>.</LI>

<UL>
<LI>reference in a member or friend of <TT>A</TT>? <B>No</B>.</LI>

<LI>reference in a member or friend of a class derived from
<TT>A</TT>? <B>Yes</B>, <TT>B</TT>.</LI>

<UL>
<LI>
<TT>f</TT> as a member of <TT>B</TT> private or protected?
<B>No</B>, public.</LI>

</UL>
</UL>

<LI>base of <TT>A</TT> accessible at point of reference? <B>No</B>.</LI>
</UL>

<P>It seems clear to me that the third bullet should say "public,
private or protected".</P>

<P>
<U>Steve Adamczyk</U>:The words were written before
<I>using-declaration</I>s existed, and therefore didn't anticipate
this case.
</P>

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

<P>Modify  the third bullet of the third change ("A member <I>m</I>
is accessible...") in the resolution
of <A HREF="
     cwg_defects.html#9">issue 9</A> to read "public, private,
or protected" instead of "private or protected."</P>

<BR>
<BR>
<HR>
<A NAME="161"></A>
<H4>161.
  
Access to protected nested type
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>11.5&nbsp;



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

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

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

 <B>Date: </B>26 Aug 1999<BR>



<P>11.5&nbsp;



 <A HREF="access.html#class.protected">class.protected</A>
 paragraph 1 begins:</P>

<BLOCKQUOTE>
When a friend or a member function of a derived class references a
protected nonstatic member of a base class, an access check applies in
addition to those described earlier in clause
11&nbsp;



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

<P>This was intended to refer to nonstatic member functions and
nonstatic data members.  However, a protected nested type declared
in a base class is, by
some definition of the word, a "nonstatic" member, and therefore subject
to this additional access check.</P>

<P>
<B>Proposed resolution (10/99):</B>
change "protected nonstatic member" in the above to
"protected nonstatic member function or protected nonstatic data member"
to make the intent clear.</P>
<BR>
<BR>
<HR>
<A NAME="10"></A>
<H4>10.
  
Can a nested class access its own class name as a qualified name if it is a private member of the enclosing class?
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>11.8&nbsp;



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

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

 <B>Submitter: </B>Josee Lajoie
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2<BR>




<P>(Previously numbered 900.)</P>


<P>Paragraph 1 says: "The members of a nested class have no special access
to members of an enclosing class..."</P>

<P>This prevents a member of a nested class from being defined outside
of its class definition. i.e. Should the following be well-formed?</P>
<PRE>
    class D {
        class E {
            static E* m;
        };
    };
     
    D::E* D::E::m = 1; // ill-formed
</PRE>
This is because the nested class does not have access to the member <TT>E</TT>
in <TT>D</TT>. 11&nbsp;



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

paragraph 5 says that access to <TT>D::E</TT> is checked with
member access to class <TT>E</TT>, but unfortunately that doesn't give
access to <TT>D::E</TT>. 11&nbsp;



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

paragraph 6 covers the access for <TT>D::E::m</TT>,
but it doesn't affect the <TT>D::E</TT> access. Are there any implementations
that are standard compliant that support this?

<P>Here is another example:</P>
<PRE>
    class C {
        class B
        {
            C::B *t; //2 error, C::B is inaccessible
        };
    };
</PRE>
This causes trouble for member functions declared outside of the class
member list. For example:
<PRE>
    class C {
        class B
        {
            B&amp; operator= (const B&amp;);
        };
    };
     
    C::B&amp; C::B::operator= (const B&amp;) { } //3
</PRE>
If the return type (i.e. <TT>C::B</TT>) is access checked in the scope
of class <TT>B</TT> (as implied by
11&nbsp;



 <A HREF="access.html#class.access">class.access</A>
 paragraph 5)
as a qualified name, then
the return type is an error just like referring to <TT>C::B</TT> in the
member list of class <TT>B</TT> above (i.e. //2) is ill-formed.

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

<P>The resolution for this issue is incorporated into the
resolution for <A HREF="
     cwg_defects.html#45">issue 45</A>.</P>
<BR>
<BR>
<HR>
<A NAME="45"></A>
<H4>45.
  
Access to nested classes
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>11.8&nbsp;



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

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

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

 <B>Date: </B>29 Sep 1998
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>O'Riordan<BR>




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


<P>Example:</P>
<PRE>
    #include &lt;iostream.h&gt;
    
    class C {  // entire body is private
        struct Parent {
            Parent() { cout &lt;&lt; "C::Parent::Parent()\n"; }
        };
    
        struct Derived : Parent {
            Derived() { cout &lt;&lt; "C::Derived::Derived()\n"; }
        };
    
        Derived d;
    };
    
    
    int main() {
        C c;      //  Prints message from both nested classes
        return 0;
    }
</PRE>
How legal/illegal is this? Paragraphs that seem to apply here are:
<P>11&nbsp;



 <A HREF="access.html#class.access">class.access</A>
 paragraph 1:</P>
<BLOCKQUOTE>
A member of a class can be
<UL>
<LI>
<TT>private</TT>; that is, its name can be used only by members and
friends of the class in which it is declared. [...]</LI>
</UL>
</BLOCKQUOTE>
and
11.8&nbsp;



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

paragraph 1:
<BLOCKQUOTE>
The members of a nested class
have no special access to members of an enclosing class, nor to classes
or functions that have granted friendship to an enclosing class; the usual
access rules (clause 11&nbsp;



 <A HREF="access.html#class.access">class.access</A>
)
shall be obeyed. [...]</BLOCKQUOTE>
This makes me think that the '<TT>: Parent</TT>' part is OK by itself,
but that the implicit call of '<TT>Parent::Parent()</TT>' by '<TT>Derived::Derived()</TT>'
is not.

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

<P>I think it is completely legal, by the reasoning given in the (non-normative)
11.8&nbsp;



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

paragraph 2. The use of a private nested class as a base of another nested class
is explicitly declared to be acceptable there. I think the rationale in
the comments in the example ("// OK because of injection of name A in A")
presupposes that public members of the base class will be public members
in a (publicly-derived) derived class, regardless of the access of the
base class, so the constructor invocation should be okay as well.</P>

<P>I can't find anything normative that explicitly says that,
though.</P>

<P>(See also papers J16/99-0009 = WG21 N1186,
J16/00-0031 = WG21 N1254, and J16/00-0045 = WG21 N1268.)</P>

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

<OL>

<LI>
<P>Insert the following as a new paragraph following
11&nbsp;



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

<BLOCKQUOTE>

A member of a class can also access all names as the class of which
it is a member.  A local class of a member function may access the
same names that the member function itself may access.  [<I>Footnote:</I>
Access permissions are thus transitive and cumulative to nested and
local classes.]

</BLOCKQUOTE>
</LI>

<LI>
<P>Delete 11&nbsp;



 <A HREF="access.html#class.access">class.access</A> paragraph 6.</P>
</LI>

<LI>
<P>In 11.8&nbsp;



 <A HREF="access.html#class.access.nest">class.access.nest</A> paragraph 1, change</P>

<BLOCKQUOTE>

The members of a nested class have no special access to members of an
enclosing class, nor to classes or functions that have granted
friendship to an enclosing class; the usual access rules
(clause 11&nbsp;



 <A HREF="access.html#class.access">class.access</A>) shall be obeyed.

</BLOCKQUOTE>

<P>to</P>

<BLOCKQUOTE>

A nested class is a member and as such has the same access rights
as any other member.

</BLOCKQUOTE>

<P>Change</P>

<PRE>
    B b;       // error: E::B is private
</PRE>

<P>to</P>

<PRE>
    B b;       // Okay, E::I can access E::B
</PRE>

<P>Change</P>

<PRE>
    p-&gt;x = i;      // error: E::x is private
</PRE>

<P>to</P>

<PRE>
    p-&gt;x = i;      // Okay, E::I can access E::x
</PRE>

</LI>

<LI>
<P>Delete 11.8&nbsp;



 <A HREF="access.html#class.access.nest">class.access.nest</A> paragraph 2.</P>
</LI>

</OL>

<P>(This resolution also resolves issues
<A HREF="
     cwg_defects.html#8">8</A> and
<A HREF="
     cwg_defects.html#10">10</A>.</P>

<BR>
<BR>
<HR>
<A NAME="194"></A>
<H4>194.
  
Identifying constructors
</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>DR
 &nbsp;&nbsp;&nbsp;

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

 <B>Date: </B>11 Jan 2000
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Miller<BR>




<P>From reflector messages 8433-38.</P>


<P>According to 12.1&nbsp;



 <A HREF="special.html#class.ctor">class.ctor</A>
 paragraph
1, the syntax used in declaring a constructor allows at most one
<I>function-specifier</I>.  It is thus not permitted to declare a
constructor both <TT>inline</TT> and <TT>explicit</TT>.  This seems
overly restrictive.</P>

<P>On a related note, there doesn't seem to be any explicit
prohibition against member functions with the same name as the class.
(Such a prohibition might reasonably be expected to occur in
9.2&nbsp;



 <A HREF="class.html#class.mem">class.mem</A>
 paragraph 13, but member
functions are not listed there.)</P>

<P>One possible interpretation would be that such member functions
would violate the restrictions in
3.3.6&nbsp;



 <A HREF="basic.html#basic.scope.class">basic.scope.class</A>
 paragraph 1,
because the class name would refer to the class at some points in the
class scope and to the member function at others.  However, this seems
a bit tenuous.  Is an explicit prohibition needed?</P>

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

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

<OL>
<LI>
<P>Add to 9.2&nbsp;



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

<BLOCKQUOTE>
<UL>
<LI>every member function of class <TT>T</TT> [<I>Note:</I> this
restriction does not apply to constructors, which do not have names
(12.1&nbsp;



 <A HREF="special.html#class.ctor">class.ctor</A>). ];</LI>
</UL>
</BLOCKQUOTE>

<P>immediately following the line</P>

<BLOCKQUOTE>
<UL>
<LI>every data member of class <TT>T</TT>;</LI>
</UL>
</BLOCKQUOTE>
</LI>

<LI>
<P>Change 12.1&nbsp;



 <A HREF="special.html#class.ctor">class.ctor</A> paragraph 1 from</P>

<BLOCKQUOTE>
A special declarator syntax using an optional
<I>function-specifier</I> (7.1.2&nbsp;



 <A HREF="dcl.html#dcl.fct.spec">dcl.fct.spec</A>)...
</BLOCKQUOTE>

<P>to</P>

<BLOCKQUOTE>
A special declarator syntax using an optional sequence of
<I>function-specifier</I>s (7.1.2&nbsp;



 <A HREF="dcl.html#dcl.fct.spec">dcl.fct.spec</A>)...
</BLOCKQUOTE>
</LI>
</OL>
<BR>
<BR>
<HR>
<A NAME="124"></A>
<H4>124.
  
Lifetime of temporaries in default initialization of class arrays
</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>DR
 &nbsp;&nbsp;&nbsp;

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

 <B>Date: </B>3 June 1999
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Adamczyk<BR>




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


<P>
<U>Jack Rouse:</U>
12.2&nbsp;



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

states that temporary objects will normally be destroyed at the
end of the full expression in which they are created.  This can create
some unique code generation requirements when initializing a class
array with a default constructor that uses a default argument.  Consider
the code:</P>

<PRE>
    struct T {
       int i;
       T( int );
       ~T();
    };

    struct S {
       S( int = T(0).i );
       ~S();
    };

    S* f( int n )
    {
       return new S[n];
    }
</PRE>

The full expression allocating the array in <TT>f(int)</TT> includes the
default constructor for <TT>S</TT>.  Therefore according to
1.9&nbsp;



 <A HREF="intro.html#intro.execution">intro.execution</A> paragraph 14, it
includes the default argument expression for <TT>S(int)</TT>.
So evaluation of
the full expression should include evaluating the default argument "n"
times and creating "n" temporaries of type <TT>T</TT>.  But the destruction of
the temporaries must be delayed until the end of the full expression
so this requires allocating space at runtime for "n" distinct
temporaries.  It is unclear how these temporaries are supposed to be
allocated and deallocated.  They cannot readily be autos because a
variable allocation is required.

<P>I believe that many existing implementations will destroy the
temporaries needed by the default constructor after each array element
is initialized.  But I can't find anything in the standard that allows
the temporaries to be destroyed early in this case.</P>

<P>I think the standard should allow the early destruction of temporaries
used in the default initialization of class array elements.  I believe
early destruction is the status quo, and I don't think the users of
existing C++ compilers have been adversely impacted by it.</P>

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

<P>The proposed resolution is contained in the proposal for
<A HREF="
     cwg_defects.html#201">issue 201</A>.</P>
<BR>
<BR>
<HR>
<A NAME="201"></A>
<H4>201.
  
Order of destruction of temporaries in initializers
</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>DR
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Alan Nash
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>31 Jan 2000
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Adamczyk<BR>




<P>From reflector messages 8516, 8519-20.</P>


<P>According to 12.2&nbsp;



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

paragraph 4, an expression appearing as the initializer in an object
definition constitutes a context "in which temporaries are destroyed
at a different point than the end of the full-expression."  It goes on
to say that the temporary containing the value of the expression
persists until after the initialization is complete (see also
<A HREF="
     cwg_closed.html#117">issue 117</A>).  This seems to presume
that the end of the full-expression is a point earlier than the
completion of the initialization.</P>

<P>However, according to
1.9&nbsp;



 <A HREF="intro.html#intro.execution">intro.execution</A>
 paragraphs 12-13, the
full-expression in such cases is, in fact, the entire initialization.
If this is the case, the behavior described for temporaries in an
initializer expression is simply the normal behavior of temporaries in
any expression, and treating it as an exception to the general rule is
both incorrect and confusing.</P>

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

<P>
<I>[Note: this proposal also addresses <A HREF="
     cwg_defects.html#124">issue 124</A>.]</I>
</P>

<OL>

<LI>
<P>Add to the end of 1.9&nbsp;



 <A HREF="intro.html#intro.execution">intro.execution</A> paragraph 12:</P>

<BLOCKQUOTE>

If the initializer for an object or
sub-object is a full-expression, the initialization of
the object or sub-object (e.g., by calling a constructor
or copying an expression value) is considered to be part
of the full-expression.

</BLOCKQUOTE>
</LI>

<LI>
<P>Replace 12.2&nbsp;



 <A HREF="special.html#class.temporary">class.temporary</A> paragraph 4 with:</P>

<BLOCKQUOTE>

There are two contexts in which temporaries are
destroyed at a different point than the end of the
full-expression.  The first context is when a
default constructor is called to initialize an
element of an array.  If the constructor has one
or more default arguments, any temporaries created
in the default argument expressions are destroyed
immediately after return from the constructor.

</BLOCKQUOTE>
</LI>

</OL>

<BR>
<BR>
<HR>
<A NAME="152"></A>
<H4>152.
  
<TT>explicit</TT> copy constructors
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>12.3.1&nbsp;



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

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

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

 <B>Date: </B>4 August 1999
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Adamczyk<BR>




<P>From reflector messages 8237-8.</P>


<P>Can a copy-constructor declared as <TT>explicit</TT> be used to
copy class values implicitly?  For example,</P>

<PRE>
   struct X {
      X();
      explicit X(const X&amp;);
   };
   void f(X);
   int main() { X x; f(x); }
</PRE>

According to 12.3.1&nbsp;



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

paragraphs 2-3,

<BLOCKQUOTE>
An explicit constructor constructs objects just like non-explicit
constructors, but does so only where the direct-initialization syntax
(8.5&nbsp;



 <A HREF="decl.html#dcl.init">dcl.init</A>
) or where casts
(5.2.9&nbsp;



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



 <A HREF="expr.html#expr.cast">expr.cast</A>
) are explicitly used...
A copy-constructor (12.8&nbsp;



 <A HREF="special.html#class.copy">class.copy</A>
) is a
converting constructor.  An implicitly-declared copy constructor is
not an explicit constructor; it may be called for implicit type
conversions.
</BLOCKQUOTE>

This passage would appear to indicate that the call in the example is
ill-formed, since it uses neither the direct-initialization syntax nor
an explicit cast.  The last sentences are especially interesting in
this regard, indicating that <TT>explicit</TT> and
non-<TT>explicit</TT> copy constructors are handled differently.

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



 <A HREF="decl.html#dcl.init">dcl.init</A>
 paragraph 14, bullet 4,
sub-bullet 2 says,</P>

<BLOCKQUOTE>
If the initialization is direct-initialization, or if it is
copy-initialization where the cv-unqualified version of the source
type is the same class as, or a derived class of, the class of the
destination... [the] applicable constructors are enumerated
(13.3.1.3&nbsp;



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

The cited passage says that

<BLOCKQUOTE>
The candidate functions are all the constructors of the class of the
object being initialized.
</BLOCKQUOTE>

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

<P>After the issue was accepted as a DR with the proposed
resolution to change 13.3.1.3&nbsp;



 <A HREF="over.html#over.match.ctor">over.match.ctor</A> paragraph 1
as described below, it was noticed that 12.3.1&nbsp;



 <A HREF="special.html#class.conv.ctor">class.conv.ctor</A>
paragraph 3 states that:</P>

<BLOCKQUOTE>

A copy-constructor (12.8&nbsp;



 <A HREF="special.html#class.copy">class.copy</A>) is a converting
constructor.

</BLOCKQUOTE>

<P>In addition to making the proposed resolution for this issue
ineffectual, the wording of paragraph 3 also contradicts that of
paragraph 1:</P>

<BLOCKQUOTE>

A constructor declared without the <I>function-specifier</I>
<TT>explicit</TT> that can be called with a single parameter specifies
a conversion from the type of its first parameter to the type of its
class. Such a constructor is called a converting constructor.

</BLOCKQUOTE>

<P>These considerations led to the addition of the second point
of the proposed resolution.</P>

<P>
<B>Proposed resolution (04/01):</B>
</P>
<OL>
<LI>
<P>Change the first two sentences of
13.3.1.3&nbsp;



 <A HREF="over.html#over.match.ctor">over.match.ctor</A>
 paragraph 1 to</P>
<BLOCKQUOTE>
When objects of class type are direct-initialized
(8.5&nbsp;



 <A HREF="decl.html#dcl.init">dcl.init</A>), or copy-initialized
from an expression of the same or a derived class type
(8.5&nbsp;



 <A HREF="decl.html#dcl.init">dcl.init</A>), overload
resolution selects the constructor.  For direct-initialization, the
candidate functions are all the constructors of the class of the object
being initialized.  For copy-initialization, the candidate functions are
all the converting constructors
(12.3.1&nbsp;



 <A HREF="special.html#class.conv.ctor">class.conv.ctor</A>
) of that class.
</BLOCKQUOTE>
</LI>

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



 <A HREF="special.html#class.conv.ctor">class.conv.ctor</A>
paragraph 3 to read:</P>

<BLOCKQUOTE>

A non-explicit copy constructor (12.8&nbsp;



 <A HREF="special.html#class.copy">class.copy</A>) is a
converting constructor.

</BLOCKQUOTE>
</LI>
</OL>
<BR>
<BR>
<HR>
<A NAME="193"></A>
<H4>193.
  
Order of destruction of local automatics of destructor
</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>DR
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Gerhard Menzl
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>7 Jan 2000
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Crowl<BR>



<P>The Standard is not clear whether automatic objects in a destructor
are destroyed before or after the destruction of the class's base and
member subobjects.  That is, given</P>

<PRE>
    struct S { ~S(); };

    struct T {
        S x;
        ~T() {
            S y;
        };
    };
</PRE>

<P>which will be destroyed first, <TT>x</TT> or <TT>y</TT>?</P>

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

<P>In 12.4&nbsp;



 <A HREF="special.html#class.dtor">class.dtor</A> paragraph 6, change

<BLOCKQUOTE>
A destructor for class <TT>X</TT> calls the destructors for
<TT>X</TT>'s direct members, ...
</BLOCKQUOTE>

to

<BLOCKQUOTE>
After executing the body of the destructor and destroying any
automatic objects allocated within the body, a destructor for class
<TT>X</TT> calls the destructors for <TT>X</TT>'s direct members, ...
</BLOCKQUOTE>
</P>
<BR>
<BR>
<HR>
<A NAME="252"></A>
<H4>252.
  
Looking up deallocation functions in virtual destructors
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>12.4&nbsp;



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

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

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

 <B>Date: </B>19 Oct 2000
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>1
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Miller<BR>


From messages 8934-5.

<P>There is a mismatch between 12.4&nbsp;



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



 <A HREF="special.html#class.free">class.free</A> paragraph 4 regarding
the lookup of deallocation functions in virtual destructors.
12.4&nbsp;



 <A HREF="special.html#class.dtor">class.dtor</A> says,</P>

<BLOCKQUOTE>

At the point of definition of a virtual destructor (including an
implicit definition (12.8&nbsp;



 <A HREF="special.html#class.copy">class.copy</A>)), non-placement
operator delete shall be looked up in the scope of the destructor's
class (3.4.1&nbsp;



 <A HREF="basic.html#basic.lookup.unqual">basic.lookup.unqual</A>) and if found shall be accessible
and unambiguous. [<I>Note</I>: this assures that an operator delete
corresponding to the dynamic type of an object is available for the
<I>delete-expression</I> (12.5&nbsp;



 <A HREF="special.html#class.free">class.free</A>). ]

</BLOCKQUOTE>

<P>The salient features to note from this description are:</P>

<OL>

<LI>The lookup is "in the scope of the destructor's class," which
implies that only members are found (cf 12.2&nbsp;



 <A HREF="special.html#class.temporary">class.temporary</A>).
(The cross-reference would indicate otherwise, however, since it
refers to the description of looking up unqualified names; this kind
of lookup "spills over" into the surrounding scope.)</LI>

<LI>Only non-placement operator delete is looked up.  Presumably
this means that a placement operator delete is ignored in the
lookup.</LI>

</OL>

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



 <A HREF="special.html#class.free">class.free</A> says,</P>

<BLOCKQUOTE>

If a <I>delete-expression</I> begins with a unary <TT>::</TT>
operator, the deallocation function's name is looked up in global
scope. Otherwise, if the <I>delete-expression</I> is used to
deallocate a class object whose static type has a virtual destructor,
the deallocation function is the one found by the lookup in the
definition of the dynamic type's virtual destructor (12.4&nbsp;



 <A HREF="special.html#class.dtor">class.dtor</A>). Otherwise, if the <I>delete-expression</I> is used to
deallocate an object of class <TT>T</TT> or array thereof, the static
and dynamic types of the object shall be identical and the
deallocation function's name is looked up in the scope of
<TT>T</TT>. If this lookup fails to find the name, the name is looked
up in the global scope. If the result of the lookup is ambiguous or
inaccessible, or if the lookup selects a placement deallocation
function, the program is ill-formed.

</BLOCKQUOTE>

<P>Points of interest in this description include:</P>

<OL>

<LI>For a class type with a virtual destructor, the lookup is
described as being "in the definition of the dynamic type's
virtual destructor," rather than "in the scope of the dynamic
type."  That is, the lookup is assumed to be an unqualified
lookup, presumably terminating in the global scope.</LI>

<LI>The assumption is made that the lookup in the virtual
destructor was successful ("...the one found...", not "...the
one found..., <B>if any"</B>).  This will not be the case if
the deallocation function was not declared as a member somewhere
in the inheritance hierarchy.</LI>

<LI>The lookup in the non-virtual-destructor case <B>does</B>
find placement deallocation functions and can fail as a result.</LI>

</OL>

<P>
<B>Suggested resolution:</B> Change the description of the
lookup in 12.4&nbsp;



 <A HREF="special.html#class.dtor">class.dtor</A> paragraph 11 to match the
one in 12.5&nbsp;



 <A HREF="special.html#class.free">class.free</A> paragraph 4.</P>

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

<OL>

<LI>
<P>Replace 12.4&nbsp;



 <A HREF="special.html#class.dtor">class.dtor</A> paragraph 11 with
the following:</P>

<BLOCKQUOTE>
At the point of definition of a virtual destructor (including an
implicit definition), the non-array deallocation function is looked up
in the scope of the destructor's class (10.2&nbsp;



 <A HREF="derived.html#class.member.lookup">class.member.lookup</A>),
and, if no declaration is found, the function is looked up in the
global scope.  If the result of this lookup is ambiguous or
inaccessible, or if the lookup selects a placement deallocation
function, the program is ill-formed.  [<I>Note:</I> this assures that
a deallocation function corresponding to the dynamic type of an object
is available for the <I>delete-expression</I> (12.5&nbsp;



 <A HREF="special.html#class.free">class.free</A>).]

</BLOCKQUOTE>
</LI>

<LI>
<P>In 12.5&nbsp;



 <A HREF="special.html#class.free">class.free</A> paragraph 4, change</P>

<BLOCKQUOTE>

...the deallocation function is the one found by the lookup in
the definition of the dynamic type's virtual destructor
(12.4&nbsp;



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

</BLOCKQUOTE>

<P>to</P>

<BLOCKQUOTE>

...the deallocation function is the one selected at the point of
definition of the dynamic type's virtual destructor
(12.4&nbsp;



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

</BLOCKQUOTE>
</LI>

</OL>

<BR>
<BR>
<HR>
<A NAME="272"></A>
<H4>272.
  
Explicit destructor invocation and <I>qualified-id</I>s
</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>DR
 &nbsp;&nbsp;&nbsp;

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

 <B>Date: </B>22 Feb 2001
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>0
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Adamczyk<BR>


12.4&nbsp;



 <A HREF="special.html#class.dtor">class.dtor</A> paragraph 12 contains the following note:

<BLOCKQUOTE>

an explicit destructor call must always be written using a member
access operator (5.2.5&nbsp;



 <A HREF="expr.html#expr.ref">expr.ref</A>); in particular, the
<I>unary-expression</I> <TT>~X()</TT> in a member function is not an
explicit destructor call (5.3.1&nbsp;



 <A HREF="expr.html#expr.unary.op">expr.unary.op</A>).

</BLOCKQUOTE>

<P>This note is incorrect, as an explicit destructor call can be
written as a <I>qualified-id</I>, e.g., <TT>X::~X()</TT>, which
does not use a member access operator.</P>

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

<P>Change 12.4&nbsp;



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

<BLOCKQUOTE>

[<I>Note:</I> an explicit destructor call must always be written
using a member access operator (5.2.5&nbsp;



 <A HREF="expr.html#expr.ref">expr.ref</A>)
<B>or a <I>qualified-id</I> (5.1&nbsp;



 <A HREF="expr.html#expr.prim">expr.prim</A>)</B>;
in particular, the <I>unary-expression</I> <TT>~X()</TT> in a
member function is not an explicit destructor call
(5.3.1&nbsp;



 <A HREF="expr.html#expr.unary.op">expr.unary.op</A>).]

</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="235"></A>
<H4>235.
  
Assignment vs 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>DR
 &nbsp;&nbsp;&nbsp;

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

 <B>Date: </B>16 Sep 2000<BR>


<P>In 12.6.2&nbsp;



 <A HREF="special.html#class.base.init">class.base.init</A> paragraph 4 we read:</P>

<BLOCKQUOTE>

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

</BLOCKQUOTE>

<P>Using the term "initialized" to describe setting the value of a
member inside the body of a constructor is a misuse of the term: only
by use of a placement <TT>new</TT> expression can a member be
<I>initialized</I> "during the execution of the body of the
constructor."</P>

<P>
<B>Suggested resolution:</B> Change "initialized" to "given a
value."</P>

<P>
<B>Proposed resolution (10/00):</B> As suggested.</P>

<BR>
<BR>
<HR>
<A NAME="20"></A>
<H4>20.
  
Some clarifications needed for 12.8 para 15
</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>DR
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>unknown
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown<BR>




<P>(Previously numbered 931.)</P>


<P>
<B><U>Issue 1</U></B>
</P>

<P>12.8&nbsp;



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


(From J16/99-0005 = WG21 N1182, "Proposed Resolutions for Core
Language Issues 6, 14, 20, 40, and 89")</P>

<P>There are three related sub-issues in this issue, all dealing with the
elision of copy constructors as described in
12.8&nbsp;



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

paragraph 15:</P>
<OL>
<LI>
The text should make clear that the requirement that the copy constructor
be accessible and unambiguous is not relaxed in cases where a call to a
copy constructor is elided.</LI>

<LI>
It is not clear from the text that the two optimizations described can
be applied transitively, and, if so, the implications for the order of
destruction are not spelled out.</LI>

<LI>
The text should exclude applying the function-return optimization if the
expression names a static or volatile local object.</LI>
</OL>
<U>Analysis</U>

<P>After discussion in Santa Cruz, the core group decided that sub-issue
#1 required no change; the necessity of an accessible and unambiguous copy
constructor is made clear in
12.2&nbsp;



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

paragraph 1 and need not be repeated in this text. The remaining two sub-issues
appear to be valid criticisms and should be addressed.</P>

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

<P>
<I>[Note: a small portion of this wording is superseded by the
resolution of <A HREF="
     cwg_defects.html#185">issue 185</A>.]</I>
</P>

<P>The paragraph in question should be rewritten as follows.
In addition,
references to this section should be added to the index under "temporary,
elimination of," "elimination of temporary," and "copy, constructor elision."</P>
<UL>When certain criteria are met, an implementation is allowed to omit
the copy construction of a class object, even if the copy constructor
and/or destructor
for the object have side effects. In such cases, the implementation treats
the source and target of the omitted copy operation as simply two different
ways of referring to the same object, and the destruction of that object
occurs at the later of the times when the two objects would have been destroyed
without the optimization [<I>footnote:</I> Because only one object is destroyed
instead of two, and one copy constructor is not executed, there is still
one object destroyed for each one constructed. <I>end footnote</I>].
This elision
of copy operations is permitted in the following circumstances (which may
be combined to eliminate multiple copies):
<BR>
<UL>
<LI>
<P>in a return statement in a function with a class return type, where the
expression is the name of a non-volatile automatic object with the same
cv-unqualified type as the function return type, the copy operation can
be omitted by constructing the automatic object directly into the function's
return value</P>
</LI>
</UL>
</UL>

<UL>
<UL>
<LI>
when a temporary class object 
(12.2&nbsp;



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

<UL>[<I>Example:</I>
</UL>

<UL>
<PRE>
    class Thing {
    public:
        Thing();
        ~Thing();
        Thing(const Thing&amp;);
    };
    
    Thing f() {
        Thing t;
        return t;
    }
    
    Thing t2 = f();
</PRE>
</UL>
Here the criteria for elision can be combined to eliminate two calls to
the copy constructor of class <TT>Thing</TT>: the copying of the local
automatic object <TT>t</TT> into the temporary object for the return value
of function <TT>f()</TT> and the copying of that temporary object into
object <TT>t2</TT>. Effectively, the construction of the local object <TT>t</TT>
can be viewed as directly initializing the global object <TT>t2</TT>, and
that object's destruction will occur at program exit.
&mdash;<I>end example</I>]
<BR>
<BR>
<HR>
<A NAME="185"></A>
<H4>185.
  
"Named" temporaries and copy elision
</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>DR
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Bill Wade
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>11 Nov 1999
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Miller<BR>



<P>12.8&nbsp;



 <A HREF="special.html#class.copy">class.copy</A>
 paragraph 15 refers only
to "temporary class objects."  It needs to be made clear that these
provisions do <B>not</B> apply to temporaries that have been bound to
references.  For instance,</P>

<PRE>
    struct A {
        mutable int value;
        explicit A(int i) : value(i) {}
        void mutate(int i) const { value = i; }
    };

    int foo() {
        A const&amp; t = A(1);
        A n(t);          // can this copy be elided?
        t.mutate(2);
        return n.value;  // can this return 2?
    }
</PRE>

The current wording seems to allow an implementation not to perform
the copy in <TT>A N(t)</TT> because the source object is a temporary
(created explicitly by <TT>A(1)</TT>).

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

<P>Change the wording proposed in the resolution of <A HREF="
     cwg_defects.html#20">issue 20</A> from</P>

<BLOCKQUOTE>
<UL>
<LI>when a temporary class object (12.2&nbsp;



 <A HREF="special.html#class.temporary">class.temporary</A>)
would be copied to a class object...</LI>
</UL>
</BLOCKQUOTE>

<P>to</P>

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



 <A HREF="special.html#class.temporary">class.temporary</A>) would be copied to a class
object...</LI>
</UL>
</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="239"></A>
<H4>239.
  
Footnote 116 and Koenig lookup
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>13.3.1.1.1&nbsp;



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

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

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

 <B>Date: </B>2 Aug 2000
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>1
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Adamczyk<BR>


<P>From messages 8848 and 8850.</P>

In describing non-member functions in an overload set, footnote
116 (13.3.1.1.1&nbsp;



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

<BLOCKQUOTE>

Because of the usual name hiding rules, these will be introduced by
declarations or by <i>using-directive</i>s all found in the same block
or all found at namespace scope.

</BLOCKQUOTE>

<P>At least in terms of the current state of the Standard, this
is not correct: a block extern declaration does not prevent
Koenig lookup from occurring.  For example,</P>

<PRE>
    enum E { zero };
    void f(E);
    void g() {
        void f(int);
        f(zero);
    }
</PRE>

<P>In this example, the overload set will include declarations
from both namespace and block scope.</P>

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

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

<OL>

<LI>
<P>In 3.4.2&nbsp;



 <A HREF="basic.html#basic.lookup.koenig">basic.lookup.koenig</A> paragraph 2, change</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>to</P>

<BLOCKQUOTE>

If the ordinary unqualified lookup of the name finds the declaration
of a class member function, or a block-scope function declaration
that is not a <I>using-declaration</I>, the associated namespaces
and classes are not considered.

</BLOCKQUOTE>

<P>and change the example to:</P>

<PRE>
    namespace NS {
        class T { };
        void f(T);
        void g(T, int);
    }
    NS::T parm;
    void g(NS::T, float);
    int main() {
        f(parm);            // OK: calls NS::f
        extern void g(NS::T, float);
        g(parm, 1);         // OK: calls g(NS::T, float)
    }
</PRE>

</LI>

<LI>
<P>In 13.3.1.1.1&nbsp;



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

<BLOCKQUOTE>

If the name resolves to a non-member function declaration, that
function and its overloaded declarations constitute the set of
candidate functions.

</BLOCKQUOTE>

<P>to</P>

<BLOCKQUOTE>

If the name resolves to a set of non-member function declarations,
that set of functions constitutes the set of candidate functions.

</BLOCKQUOTE>

<P>Also, remove the associated footnote 116.</P>

</LI>

</OL>

<BR>
<BR>
<HR>
<A NAME="59"></A>
<H4>59.
  
Clarification of overloading and UDC to reference type
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>13.3.1.4&nbsp;



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

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

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

 <B>Date: </B>13 Oct 1998<BR>



<P>Sections
13.3.1.4&nbsp;



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

 and
13.3.1.5&nbsp;



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


should be clarified regarding the treatment of conversion functions which
return reference types.</P>

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

<P>In
13.3.1.4&nbsp;



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

 paragraph
1, change</P>
<BLOCKQUOTE>Conversion functions that return "reference to <TT>T</TT>"
return lvalues
of type <TT>T</TT> and are therefore considered to yield <TT>T</TT>
for this process of selecting
candidate functions.</BLOCKQUOTE>
to
<BLOCKQUOTE>Conversion functions that return "reference to <TT>X</TT>"
return lvalues
of type <TT>X</TT> and are therefore considered to yield <TT>X</TT>
for this process of selecting
candidate functions.</BLOCKQUOTE>
In
13.3.1.5&nbsp;



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

 paragraph 1,
change
<BLOCKQUOTE>Conversion functions that return "reference to <TT>T</TT>"
return lvalues
of type <TT>T</TT> and are therefore considered to yield <TT>T</TT>
for this process of selecting
candidate functions.</BLOCKQUOTE>
to
<BLOCKQUOTE>Conversion functions that return "reference to
<I>cv2</I> <TT>X</TT>"
return lvalues of type "<I>cv2</I> <TT>X</TT>" and are therefore
considered to yield
<TT>X</TT> for this process of selecting candidate functions.</BLOCKQUOTE>
<BR>
<BR>
<HR>
<A NAME="51"></A>
<H4>51.
  
Overloading and user-defined conversions
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>13.3.3&nbsp;



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

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

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

 <B>Date: </B>13 Oct 1998<BR>



<P>In 13.3.3&nbsp;



 <A HREF="over.html#over.match.best">over.match.best</A>
 paragraph 1,
bullet 4 of the second set of bullets, there is a cross-reference
to 8.5&nbsp;



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



 <A HREF="over.html#over.match.conv">over.match.conv</A>
. I believe it should also
reference 13.3.1.6&nbsp;



 <A HREF="over.html#over.match.ref">over.match.ref</A>
.
I think the phrase "initialization by user-defined
conversion" was intended to refer to all initializations using user-defined
conversions, and not just the case in 
13.3.1.5&nbsp;



 <A HREF="over.html#over.match.conv">over.match.conv</A>
. Referring to only
13.3.1.5&nbsp;



 <A HREF="over.html#over.match.conv">over.match.conv</A>
 suggests a narrower
meaning of the phrase.</P>

<P>13.3.1.4&nbsp;



 <A HREF="over.html#over.match.copy">over.match.copy</A>
,
although it does deal with initialization by user-defined
conversion, does not need to be referenced because it deals with class
&mdash;&gt; class cases, and therefore there are no standard conversions involved
that could be compared.</P>

<BR>
<BR>
<HR>
<A NAME="84"></A>
<H4>84.
  
Overloading and conversion loophole used by <TT>auto_ptr</TT>
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>13.3.3.1&nbsp;



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

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

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

 <B>Date: </B>10 Dec 1998
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>1<BR>



<P>By the letter of the standard, the conversions required to
make <TT>auto_ptr</TT> work should be accepted.</P>

<P>However, there's good reason to wonder if there isn't a bug in the standard
here. Here's the issue: line 16 in the example below comes down to
<BLOCKQUOTE>copy-initialize an <TT>auto_ptr&lt;Base&gt;</TT> from
an <TT>auto_ptr&lt;Derived&gt;</TT> rvalue</BLOCKQUOTE>
To do that, we first look to see whether we can convert
an <TT>auto_ptr&lt;Derived&gt;</TT>
to an <TT>auto_ptr&lt;Base&gt;</TT>, by enumerating the
constructors of <TT>auto_ptr&lt;Base&gt;</TT>
and the conversion functions of <TT>auto_ptr&lt;Derived&gt;</TT>.
There's a single possible way to do the conversion, namely the conversion
function</P>
<PRE>
    auto_ptr&lt;Derived&gt;::operator auto_ptr&lt;Base&gt;()
</PRE>
(generated from the template).  (The constructor 
<TT>auto_ptr&lt;Base&gt;(auto_ptr_ref&lt;Base&gt;)</TT>
doesn't work because it requires a  user-defined conversion on the
argument.)
    
<P>So far, so good.  Now, we do the copy step:</P>
<BLOCKQUOTE>direct-initialize an <TT>auto_ptr&lt;Base&gt;</TT>
from an <TT>auto_ptr&lt;Base&gt;</TT>
rvalue</BLOCKQUOTE>
This, as we've gone to great lengths to set up, is done by calling 
the conversion function
<PRE>
    auto_ptr&lt;Base&gt;::operator auto_ptr_ref&lt;Base&gt;()
</PRE>
(generated from the template), and then the constructor
<PRE>
    auto_ptr&lt;Base&gt;(auto_ptr_ref&lt;Base&gt;)
</PRE>
(generated from the template).
    
<P>The problem with this interpretation is that it violates the long-standing 
common-law rule that only a single user-defined conversion will be called 
to do an implicit conversion.  I find that pretty disturbing. 
(In fact, the full operation involves two conversion functions and two
constructors, but "copy" constructors are generally considered not to be
conversions.)</P>
    
<P>The direct-initialization second step of a copy-initialization was intended
to be a simple copy &mdash; you've made a temporary, and now you use a copy
constructor to copy it.  Because it is defined in terms of direct
initialization, however, it can exploit the loophole that auto_ptr
is based on.</P>
    
<P>To switch to personal opinion for a second, I think it's bad enough
that auto_ptr has to exploit a really arcane loophole of overload resolution,
but in this case it seems like it's exploiting a loophole on a loophole.</P>
<PRE>
    struct Base {                             //  2
       static void sink(auto_ptr&lt;Base&gt;);      //  3
    };                                        //  4

    struct Derived : Base {                   //  5
       static void sink(auto_ptr&lt;Derived&gt;);   //  6
    };                                        //  7

    auto_ptr&lt;Derived&gt; source() {              //  8
       auto_ptr&lt;Derived&gt; p(source());         //  9
       auto_ptr&lt;Derived&gt; pp(p);               // 10
       Derived::sink(source());               // 11
       p = pp;                                // 12
       p = source();                          // 13
       auto_ptr&lt;Base&gt; q(source());            // 14
       auto_ptr&lt;Base&gt; qp(p);                  // 15
       Base::sink(source());                  // 16
       q = pp;                                // 17
       q = source();                          // 18
       return p;                              // 19
       return source();
    }
</PRE>

<U>Derek Inglis</U>:

(in core-8564)

<P>It seems clear to me that the result of this direct initilization
must be the second standard conversion sequence in a user defined
conversion sequence.  Otherwise the resulting conversion sequence is
not an implicit conversion sequence.  By the letter of the standard,
the sequence of conversions making up a copy-initialization must be an
implicit conversion sequence.</P>

<P>Paragraph 3 of clause 4&nbsp;



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

<BLOCKQUOTE>

An expression <TT>e</TT> can be <I>implicitly converted</I> to a type
<TT>T</TT> if and only if the declaration "<TT>T t=e;</TT>" is
well-formed, for some invented temporary variable <TT>t</TT>
(8.5&nbsp;



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

</BLOCKQUOTE>

<P>Paragraph 1 of 13.3.3.1&nbsp;



 <A HREF="over.html#over.best.ics">over.best.ics</A>:</P>

<BLOCKQUOTE>

An <I>implicit conversion sequence</I> is a sequence of conversions
used to convert an argument in a function call to the type of the
corresponding parameter of the function being called.  The sequence of
conversions is an implicit conversion as defined in clause
4&nbsp;



 <A HREF="conv.html#conv">conv</A>, which means it is governed by the rules for
initialization of an object or reference by a single expression
(8.5&nbsp;



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



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

</BLOCKQUOTE>

Sentence 1 of paragraph 12 of 8.5&nbsp;



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

<BLOCKQUOTE>

The initialization that occurs in argument passing ...
is  called <I>copy-initialization</I> and is equivalent to  the form

<PRE>
     T x = a;
</PRE>

</BLOCKQUOTE>

<P>For me, these sentences imply that all sequences of conversions
permitted on a function argument must be valid implicit conversion
sequences.</P>

<P>The 'loophole' can be closed by adding a sentence (or note) to the
section describing the 'direct initialization second step of a copy
initialization' stating that the copy initialization is ill-formed if
the conversion sequence resulting from the direct initialization is
not a standard conversion sequence.</P>

<P>(See also <A HREF="
     cwg_active.html#177">issue 177</A> and paper
J16/00-0009 = WG21 N1232.)</P>

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

<P>Change 13.3.3.1&nbsp;



 <A HREF="over.html#over.best.ics">over.best.ics</A> paragraphs 3 and 4 from</P>

<BLOCKQUOTE>

<P>Except in the context of an initialization by user-defined
conversion (13.3.1.4&nbsp;



 <A HREF="over.html#over.match.copy">over.match.copy</A>,
13.3.1.5&nbsp;



 <A HREF="over.html#over.match.conv">over.match.conv</A>), a well-formed implicit conversion
sequence is one of the following forms:</P>

<UL>

<LI>a <I>standard conversion sequence</I>
(13.3.3.1.1&nbsp;



 <A HREF="over.html#over.ics.scs">over.ics.scs</A>),</LI>

<LI>a <I>user-defined conversion sequence</I>
(13.3.3.1.2&nbsp;



 <A HREF="over.html#over.ics.user">over.ics.user</A>), or</LI>

<LI>an <I>ellipsis conversion sequence
(13.3.3.1.3&nbsp;



 <A HREF="over.html#over.ics.ellipsis">over.ics.ellipsis</A>)</I>
</LI>

</UL>

<P>In the context of an initialization by user-defined conversion (i.e.,
when considering the argument of a user-defined conversion function;
see 13.3.1.4&nbsp;



 <A HREF="over.html#over.match.copy">over.match.copy</A>, 13.3.1.5&nbsp;



 <A HREF="over.html#over.match.conv">over.match.conv</A>),
only standard conversion sequences and
ellipsis conversion sequences are allowed.</P>

</BLOCKQUOTE>

<P>to</P>

<BLOCKQUOTE>

<P>A well-formed implicit conversion
sequence is one of the following forms:</P>

<UL>

<LI>a <I>standard conversion sequence</I>
(13.3.3.1.1&nbsp;



 <A HREF="over.html#over.ics.scs">over.ics.scs</A>),</LI>

<LI>a <I>user-defined conversion sequence</I>
(13.3.3.1.2&nbsp;



 <A HREF="over.html#over.ics.user">over.ics.user</A>), or</LI>

<LI>an <I>ellipsis conversion sequence</I>
(13.3.3.1.3&nbsp;



 <A HREF="over.html#over.ics.ellipsis">over.ics.ellipsis</A>)</LI>

</UL>

<P>However, when considering the argument of a user-defined conversion
function that is a candidate by 13.3.1.3&nbsp;



 <A HREF="over.html#over.match.ctor">over.match.ctor</A>
when invoked for the copying
of the temporary in the second step of a class copy-initialization, or
by 13.3.1.4&nbsp;



 <A HREF="over.html#over.match.copy">over.match.copy</A>, 13.3.1.5&nbsp;



 <A HREF="over.html#over.match.conv">over.match.conv</A>,
or 13.3.1.6&nbsp;



 <A HREF="over.html#over.match.ref">over.match.ref</A> in all cases, only standard
conversion sequences and ellipsis conversion sequences are
allowed.</P>

</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="83"></A>
<H4>83.
  
Overloading and deprecated conversion of string literal
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>13.3.3.2&nbsp;



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

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

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

 <B>Date: </B>24 Jan 1999
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Adamczyk<BR>



<P>In
13.3.3.2&nbsp;



 <A HREF="over.html#over.ics.rank">over.ics.rank</A>
, we have</P>
<UL>
<LI>
<TT>S1</TT> and <TT>S2</TT> differ only in their
qualification conversion and
yield similar types <TT>T1</TT> and <TT>T2</TT>
(4.4&nbsp;



 <A HREF="conv.html#conv.qual">conv.qual</A>
),
respectively, and the cv-qualification signature of type <TT>T1</TT>
is a proper
subset of the cv-qualification signature of type <TT>T2</TT>,
[<I>Example:</I>
<PRE>
    int f(const int *);
    int f(int *); 
    int i;
    int j = f(&amp;i); // <I>Calls</I> f(int *)
</PRE>
&mdash;<I>end example</I>] or, if not that,</LI>
</UL>
This does not work right with respect to the deprecated conversion from
string literal to "<TT>char *</TT>". Consider
<PRE>
    void f(char *);
    void f(const char *);
    
    f("abc");
</PRE>
The two conversion sequences differ only in their qualification conversions,
and the destination types are similar. The cv-qualification signature of
"<TT>char *</TT>", is a proper subset of the cv-qualification signature
of "<TT>const char *</TT>", so <TT>f(char *)</TT> is chosen, which is wrong.
The rule should be like the one for conversion to bool &mdash; the deprecated
conversion should be worse than another exact match that is not the deprecated
conversion.

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

<P>Change
13.3.3.2&nbsp;



 <A HREF="over.html#over.ics.rank">over.ics.rank</A>
 paragraph 3 bullet 1
sub-bullet 3 from</P>
<BLOCKQUOTE>
<TT>S1</TT> and <TT>S2</TT> differ only in their qualification
conversion and yield similar types <TT>T1</TT> and <TT>T2</TT>
(4.4&nbsp;



 <A HREF="conv.html#conv.qual">conv.qual</A>
), respectively, and the
cv-qualification signature of type <TT>T1</TT> is a proper subset of
the cv-qualification signature of type <TT>T2</TT>.
</BLOCKQUOTE>
to
<BLOCKQUOTE>
<TT>S1</TT> and <TT>S2</TT> differ only in their qualification
conversion and yield similar types <TT>T1</TT> and <TT>T2</TT>
(4.4&nbsp;



 <A HREF="conv.html#conv.qual">conv.qual</A>
), respectively, and the
cv-qualification signature of type <TT>T1</TT> is a proper subset of
the cv-qualification signature of type <TT>T2</TT>, and <TT>S1</TT> is
not the deprecated string literal array-to-pointer conversion
(4.2&nbsp;



 <A HREF="conv.html#conv.array">conv.array</A>
).
</BLOCKQUOTE>
<BR>
<BR>
<HR>
<A NAME="153"></A>
<H4>153.
  
Misleading wording (rank of conversion)
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>13.3.3.2&nbsp;



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

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

 <B>Submitter: </B>Valentin Bonnard
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>6 Aug 1999
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Adamczyk<BR>



<P>13.3.3.2&nbsp;



 <A HREF="over.html#over.ics.rank">over.ics.rank</A>
 paragraph 3 bullet 1
sub-bullet 2 says,</P>

<BLOCKQUOTE>
the rank of <TT>S1</TT> is better than the rank of <TT>S2</TT> (by the
rules defined below)...
</BLOCKQUOTE>

This wording is confusing.  The word "below" refers to paragraph 4
(which may not be clear), and the bulk of paragraph 4 deals with
comparing conversion sequences whose "rank" is the same.

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

<P>In
13.3.3.2&nbsp;



 <A HREF="over.html#over.ics.rank">over.ics.rank</A>
 paragraph 3, change</P>
<BLOCKQUOTE>
the rank of <TT>S1</TT> is better than the rank of <TT>S2</TT> (by the
rules defined below)
</BLOCKQUOTE>
to
<BLOCKQUOTE>
the rank of <TT>S1</TT> is better than the rank of <TT>S2</TT>, or
<TT>S1</TT> and <TT>S2</TT> have the same rank and are distinguishable
by the rules in the paragraph below
</BLOCKQUOTE>
<BR>
<BR>
<HR>
<A NAME="202"></A>
<H4>202.
  
Use of overloaded function name
</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>DR
 &nbsp;&nbsp;&nbsp;

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

 <B>Date: </B>2 Feb 2000
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Spicer<BR>




<P>From reflector messages 8521 and 8524.</P>


<P>13.4&nbsp;



 <A HREF="over.html#over.over">over.over</A>
 paragraph 1 contains a
supposedly exhaustive list of contexts in which the name of an
overloaded function can be used without an argument list ("...shall
not be used without arguments in contexts other than those listed").
However, 14.3.2&nbsp;



 <A HREF="template.html#temp.arg.nontype">temp.arg.nontype</A>
 paragraph 5,
bullet 4 gives another context: as a template nontype argument.</P>

<P>
<B>Suggested resolution:</B> Add the missing case to
13.4&nbsp;



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

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

<P>Add as the final bullet in 13.4&nbsp;



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

<BLOCKQUOTE>
<UL>
<LI>a non-type template-parameter (14.3.2&nbsp;



 <A HREF="template.html#temp.arg.nontype">temp.arg.nontype</A>).</LI>
</UL>
</BLOCKQUOTE>

<P>and adjust the "or" and final period on the preceding
two bullets.</P>

<BR>
<BR>
<HR>
<A NAME="250"></A>
<H4>250.
  
Address of function template specialization with non-deduced template arguments
</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>DR
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Nikolas Kauer
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>10 Oct 2000<BR>


<P>13.4&nbsp;



 <A HREF="over.html#over.over">over.over</A> paragraph 2 says,</P>

<BLOCKQUOTE>

If the name is a function template, template argument deduction is
done (14.8.2.2&nbsp;



 <A HREF="template.html#temp.deduct.funcaddr">temp.deduct.funcaddr</A>), and if the argument
deduction succeeds, the deduced template arguments are used to
generate a single template function, which is added to the set of
overloaded functions considered.

</BLOCKQUOTE>

<P>It is not clear whether this formulation allows explicit
specification of non-deduced template arguments.  For instance,</P>

<PRE>
    template &lt;int I&gt; void f(double x[]);
    typedef void (*FPtr)(double x[]);
    FPtr fp = &amp;f&lt;3&gt;;
</PRE>

<P>If only deduced arguments can be used, this example is
ill-formed.</P>

<P>
<B>Suggested resolution:</B> Clarify 13.4&nbsp;



 <A HREF="over.html#over.over">over.over</A>
paragraph 2 to allow both deduced and explicitly-specified
template arguments to be used to determine the function template
specialization to be added to the overload set.</P>

<P>(See also issues <A HREF="
     cwg_active.html#115">115</A> and
<A HREF="
     cwg_active.html#214">214</A>.)</P>

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

<P>In 13.4&nbsp;



 <A HREF="over.html#over.over">over.over</A> paragraph 2, change</P>

<BLOCKQUOTE>

...if the argument deduction succeeds, the deduced template arguments
are used to generate a single template function...

</BLOCKQUOTE>

<P>to</P>

<BLOCKQUOTE>

...if the argument deduction succeeds, the resulting template
argument list is used to generate a single function template
specialization...

</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="221"></A>
<H4>221.
  
Must compound assignment operators be member functions?
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>13.5.3&nbsp;



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

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

 <B>Submitter: </B>Jim Hyslop
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>3 Apr 2000
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Merrill<BR>


<P>Is the intent of 13.5.3&nbsp;



 <A HREF="over.html#over.ass">over.ass</A> paragraph 1 that
<I>all</I> assignment operators be non-static member functions
(including <TT>operator+=</TT>, <TT>operator*=</TT>, etc.) or only
simple assignment operators (<TT>operator=</TT>)?</P>

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

<P>Nearly all references to "assignment operator" in the IS mean
<TT>operator=</TT> and not the compound assignment operators.  The ARM
was specific that this restriction applied only to <TT>operator=</TT>.
If it did apply to compound assignment operators, it would be
impossible to overload these operators for <TT>bool</TT> operands.</P>

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

<OL>
<LI>
<P>Change the title of 5.17&nbsp;



 <A HREF="expr.html#expr.ass">expr.ass</A> from "Assignment
operators" to "Assignment and compound assignment operators."</P>
</LI>

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



 <A HREF="expr.html#expr.ass">expr.ass</A>
paragraph 1 from</P>
<BLOCKQUOTE>

There are several assignment operators, all of which group
right-to-left.  All require a modifiable lvalue as their left operand,
and the type of an assignment expression is that of its left operand.
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>to</P>

<BLOCKQUOTE>

The assignment operator (<TT>=</TT>) and the compound assignment
operators all group right-to-left.  All require a modifiable lvalue as
their left operand and return an lvalue with the type and value of
the left operand after the assignment has taken place.

</BLOCKQUOTE>
</LI>
</OL>

<P>
<B>Additional note (10/00):</B> Paragraphs 2-6 of
5.17&nbsp;



 <A HREF="expr.html#expr.ass">expr.ass</A> should all be understood to apply to
simple assignment only and not to compound assignment operators.</P>

<BR>
<BR>
<HR>
<A NAME="32"></A>
<H4>32.
  
Clarification of explicit instantiation of non-exported 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>DR
 &nbsp;&nbsp;&nbsp;

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

 <B>Date: </B>10 Jul 1998<BR>




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


<P>Section 14&nbsp;



 <A HREF="template.html#temp">temp</A>
 paragraph 8 says:
<BLOCKQUOTE>A non-exported template that is neither explicitly specialized
<U>nor explicitly instantiated</U> must be defined in every translation
unit in which it is implicitly instantiated (14.7.1&nbsp;



 <A HREF="template.html#temp.inst">temp.inst</A>
) or <U>explicitly
instantiated</U> (14.7.2&nbsp;



 <A HREF="template.html#temp.explicit">temp.explicit</A>
); no diagnostic is required.</BLOCKQUOTE>
Shouldn't the first underlined phrase be omitted to avoid conflict with
the second underlined phrase?</P>

<P>
<U>From John Spicer:</U>
</P>

<P>The first "explicitly instantiated" is intended to mean "explicitly instantiated
in some other translation unit".</P>

<P>
<B>Proposed Resolution (04/99):</B>
Change the text in 14&nbsp;



 <A HREF="template.html#temp">temp</A>
 paragraph 8 from:</P>
<BLOCKQUOTE>A non-exported template that is neither explicitly specialized
nor explicitly instantiated must be defined in every translation unit in
which it is implicitly instantiated (14.7.1&nbsp;



 <A HREF="template.html#temp.inst">temp.inst</A>
) or explicitly instantiated
(14.7.2&nbsp;



 <A HREF="template.html#temp.explicit">temp.explicit</A>
); no diagnostic is required.</BLOCKQUOTE>
to:
<BLOCKQUOTE>A non-exported template must be defined in every translation
unit in which it is implicitly instantiated (14.7.1&nbsp;



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



 <A HREF="template.html#temp.explicit">temp.explicit</A>
) in some translation
unit; no diagnostic is required. [<I>Note:</I> See also 14.7.2&nbsp;



 <A HREF="template.html#temp.explicit">temp.explicit</A>
]</BLOCKQUOTE>
<BR>
<BR>
<HR>
<A NAME="105"></A>
<H4>105.
  
Meaning of "template function"
</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>DR
 &nbsp;&nbsp;&nbsp;

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

 <B>Date: </B>16 Apr 1999
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Vandevoorde<BR>



<P>The phrase "template function" is sometimes used to refer to a
template (e.g., in 14&nbsp;



 <A HREF="template.html#temp">temp</A>
 paragraph 8)
and sometimes to refer to a function generated from a template (e.g.,
13.4&nbsp;



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

<P>
<B>Suggested Resolution:</B>
</P>

<P>The phrase should mean "a function generated from a template"
(or might perhaps include explicit specializations).</P>

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

<P>In 1.3.10&nbsp;



 <A HREF="intro.html#defns.signature">defns.signature</A> paragraph 10, replace "template function specialization"
by "function template specialization".
</P>

<P>In 9.3&nbsp;



 <A HREF="class.html#class.mfct">class.mfct</A> paragraph 2, replace "template
member functions" by "member functions of class templates and
member function templates."</P>

<P>In 13.3.1&nbsp;



 <A HREF="over.html#over.match.funcs">over.match.funcs</A> paragraph 7 and footnote, replace
all instances of "template functions" by "function template
specializations."</P>

<P>In 13.3.3&nbsp;



 <A HREF="over.html#over.match.best">over.match.best</A> paragraph 1, fourth bullet (counting all
bullets in that paragraph), replace "template function specialization" by
"function template specialization".  In the fifth bullet, replace
"template functions" by "function template specializations."
</P>

<P>In 13.4&nbsp;



 <A HREF="over.html#over.over">over.over</A> paragraph 2, replace "template
function" by "function template specialization."</P>

<P>Change 13.4&nbsp;



 <A HREF="over.html#over.over">over.over</A> paragraph 4 from:
<BLOCKQUOTE>If more than one function is selected, any template functions
in the set are eliminated if the set also contains a non-template function,
and any given template function is eliminated if the set contains a second
template function that is more specialized than the first according to
the partial ordering rules of 14.5.5.2&nbsp;



 <A HREF="template.html#temp.func.order">temp.func.order</A>. After such eliminations, if any,
there shall remain exactly one selected function.</BLOCKQUOTE>
to:
<BLOCKQUOTE>If more than one function is selected, any function
template specializations
in the set are eliminated if the set also contains a non-template function,
and any given function template specialization <TT>F1</TT> is eliminated if the set contains a
second function template specialization whose function template is more specialized than
the function template of <TT>F1</TT> according to the partial ordering rules of
14.5.5.2&nbsp;



 <A HREF="template.html#temp.func.order">temp.func.order</A>. After such eliminations, if any, there shall remain exactly one
selected function.</BLOCKQUOTE>
</P>
<P>Change text in section 14&nbsp;



 <A HREF="template.html#temp">temp</A> paragraph 8 from:
<BLOCKQUOTE>A template function declared both exported and inline is just
inline and not exported.</BLOCKQUOTE>
to:
<BLOCKQUOTE>A function template declared both exported and inline is just
inline and not exported.</BLOCKQUOTE>
</P>

<P>In 14.5.3&nbsp;



 <A HREF="template.html#temp.friend">temp.friend</A> paragraph 1, third bullet, replace
"template function" by "function template" and "function
specialization" by "function template specialization."</P>

<P>In footnote 130 (14.5.5&nbsp;



 <A HREF="template.html#temp.fct">temp.fct</A> paragraph 2),
replace "template functions" by "function template specializations."</P>

<P>In 14.5.5.2&nbsp;



 <A HREF="template.html#temp.func.order">temp.func.order</A> paragraph 1, third bullet change "template
function specialization" to "function template specialization".
</P>
<P>In 14.8.2&nbsp;



 <A HREF="template.html#temp.deduct">temp.deduct</A> paragraph 1, change "template function specialization"
to "function template specialization".
</P>
<P>In 17.1.5&nbsp;



 <A HREF="lib-intro.html#defns.component">defns.component</A> change "non-member template functions that
operate" to "non-member function templates that operate".
</P>
<P>In 17.1.18&nbsp;



 <A HREF="lib-intro.html#defns.traits">defns.traits</A> change "template classes and template functions"
to "class templates and function templates".
</P>
<P>In 20.2&nbsp;



 <A HREF="lib-utilities.html#lib.utility">lib.utility</A> paragraph 1 change:
<BLOCKQUOTE>This subclause contains some basic template functions and classes
that are used throughout the rest of the library.</BLOCKQUOTE>
to:
<BLOCKQUOTE>This subclause contains some basic function and class templates
that are used throughout the rest of the library.</BLOCKQUOTE>
</P>
<P>In 20.2.2&nbsp;



 <A HREF="lib-utilities.html#lib.pairs">lib.pairs</A> paragrah 1 change "template function" to "function
template".
</P>
<P>In footnote 215 (20.3.7&nbsp;



 <A HREF="lib-utilities.html#lib.function.pointer.adaptors">lib.function.pointer.adaptors</A> paragraph 6)
change "template functions" to "function templates".
</P>
<P>In 22.1.1&nbsp;



 <A HREF="lib-locales.html#lib.locale">lib.locale</A> paragraph 4 change "template function" to "function
template".
</P>
<P>In 24.1&nbsp;



 <A HREF="lib-iterators.html#lib.iterator.requirements">lib.iterator.requirements</A> paragraph 2 change "template function"
to "function template".
</P>

<P>In 24.3.3&nbsp;



 <A HREF="lib-iterators.html#lib.std.iterator.tags">lib.std.iterator.tags</A> paragraph 1, change "template
function" to "function template specialization."</P>

<P>In 24.3.4&nbsp;



 <A HREF="lib-iterators.html#lib.iterator.operations">lib.iterator.operations</A> paragraph 1 change "template function"
to "function template", and "These functions use" to "These function templates
use".
</P>
<P>In the section heading of 27.6.2.5.4&nbsp;



 <A HREF="lib-iostreams.html#lib.ostream.inserters.character">lib.ostream.inserters.character</A>
change "template functions" to "function templates".
</P>
<P>In 17.3.1.2&nbsp;



 <A HREF="lib-intro.html#lib.structure.requirements">lib.structure.requirements</A> paragraph 2 change "template
class name <TT>char_traits</TT>" to "class template <TT>char_traits</TT>".
</P>
<P>In the section heading of 18.2.1.1&nbsp;



 <A HREF="lib-support.html#lib.numeric.limits">lib.numeric.limits</A> change "Template
class" to "Class template".
</P>
<P>In 20.1.5&nbsp;



 <A HREF="lib-utilities.html#lib.allocator.requirements">lib.allocator.requirements</A> paragraph 3 change "template
class member <TT>rebind</TT>" to "member class template <TT>rebind</TT>"
and change "template typedef" to "typedef template".
</P>
<P>In the section heading of 20.3.6.1&nbsp;



 <A HREF="lib-utilities.html#lib.binder.1st">lib.binder.1st</A> change "Template
class" to "Class template".
</P>
<P>In the section heading of 20.3.6.3&nbsp;



 <A HREF="lib-utilities.html#lib.binder.2nd">lib.binder.2nd</A> change "Template
class" to "Class template".
</P>
<P>In the section heading of 20.4.5&nbsp;



 <A HREF="lib-utilities.html#lib.auto.ptr">lib.auto.ptr</A> change "Template class"
to "Class template".
</P>
<P>In the section heading of 21.3&nbsp;



 <A HREF="lib-strings.html#lib.basic.string">lib.basic.string</A> change "Template
class" to "Class template".
</P>
<P>In 21.3&nbsp;



 <A HREF="lib-strings.html#lib.basic.string">lib.basic.string</A> paragraphs 1 and 2 change "template class
<TT>basic_string</TT>"
to "class template <TT>basic_string</TT>".
</P>
<P>In the section heading of 22.2.1.1&nbsp;



 <A HREF="lib-locales.html#lib.locale.ctype">lib.locale.ctype</A> change "Template
class" to "Class template".
</P>
<P>In the section heading of 22.2.1.2&nbsp;



 <A HREF="lib-locales.html#lib.locale.ctype.byname">lib.locale.ctype.byname</A> change
"Template class" to "Class template".
</P>
<P>In the section heading of 22.2.1.5&nbsp;



 <A HREF="lib-locales.html#lib.locale.codecvt">lib.locale.codecvt</A> change "Template
class" to "Class template".
</P>
<P>In the section heading of 22.2.1.6&nbsp;



 <A HREF="lib-locales.html#lib.locale.codecvt.byname">lib.locale.codecvt.byname</A> change
"Template class" to "Class template".
</P>
<P>In the section heading of 22.2.2.1&nbsp;



 <A HREF="lib-locales.html#lib.locale.num.get">lib.locale.num.get</A> change "Template
class" to "Class template".
</P>
<P>In the section heading of 22.2.2.2&nbsp;



 <A HREF="lib-locales.html#lib.locale.nm.put">lib.locale.nm.put</A> change "Template
class" to "Class template".
</P>
<P>In the section heading of 22.2.3.1&nbsp;



 <A HREF="lib-locales.html#lib.locale.numpunct">lib.locale.numpunct</A> change "Template
class" to "Class template".
</P>
<P>In the section heading of 22.2.3.2&nbsp;



 <A HREF="lib-locales.html#lib.locale.numpunct.byname">lib.locale.numpunct.byname</A> change
"Template class" to "Class template".
</P>
<P>In the section heading of 22.2.4.1&nbsp;



 <A HREF="lib-locales.html#lib.locale.collate">lib.locale.collate</A> change "Template
class" to "Class template".
</P>
<P>In the section heading of 22.2.4.2&nbsp;



 <A HREF="lib-locales.html#lib.locale.collate.byname">lib.locale.collate.byname</A> change
"Template class" to "Class template".
</P>
<P>In the section heading of 22.2.5.1&nbsp;



 <A HREF="lib-locales.html#lib.locale.time.get">lib.locale.time.get</A> change "Template
class" to "Class template".
</P>
<P>In the section heading of 22.2.5.2&nbsp;



 <A HREF="lib-locales.html#lib.locale.time.get.byname">lib.locale.time.get.byname</A> change
"Template class" to "Class template".
</P>
<P>In the section heading of 22.2.5.3&nbsp;



 <A HREF="lib-locales.html#lib.locale.time.put">lib.locale.time.put</A> change "Template
class" to "Class template".
</P>
<P>In the section heading of 22.2.5.4&nbsp;



 <A HREF="lib-locales.html#lib.locale.time.put.byname">lib.locale.time.put.byname</A> change
"Template class" to "Class template".
</P>
<P>In the section heading of 22.2.6.1&nbsp;



 <A HREF="lib-locales.html#lib.locale.money.get">lib.locale.money.get</A> change "Template
class" to "Class template".
</P>
<P>In the section heading of 22.2.6.2&nbsp;



 <A HREF="lib-locales.html#lib.locale.money.put">lib.locale.money.put</A> change "Template
class" to "Class template".
</P>
<P>In the section heading of 22.2.6.3&nbsp;



 <A HREF="lib-locales.html#lib.locale.moneypunct">lib.locale.moneypunct</A> change "Template
class" to "Class template".
</P>
<P>In the section heading of 22.2.6.4&nbsp;



 <A HREF="lib-locales.html#lib.locale.moneypunct.byname">lib.locale.moneypunct.byname</A> change
"Template class" to "Class template".
</P>
<P>In the section heading of 22.2.7.1&nbsp;



 <A HREF="lib-locales.html#lib.locale.messages">lib.locale.messages</A> change "Template
class" to "Class template".
</P>
<P>In the section heading of 22.2.7.2&nbsp;



 <A HREF="lib-locales.html#lib.locale.messages.byname">lib.locale.messages.byname</A> change
"Template class" to "Class template".
</P>
<P>In the section heading of 23.2.1&nbsp;



 <A HREF="lib-containers.html#lib.deque">lib.deque</A> change "Template class"
to "Class template".
</P>
<P>In the section heading of 23.2.2&nbsp;



 <A HREF="lib-containers.html#lib.list">lib.list</A> change "Template class"
to "Class template".
</P>
<P>In the section heading of 23.2.3.1&nbsp;



 <A HREF="lib-containers.html#lib.queue">lib.queue</A> change "Template class"
to "Class template".
</P>
<P>In the section heading of 23.2.3.2&nbsp;



 <A HREF="lib-containers.html#lib.priority.queue">lib.priority.queue</A> change "Template
class" to "Class template".
</P>
<P>In the section heading of 23.2.3.3&nbsp;



 <A HREF="lib-containers.html#lib.stack">lib.stack</A> change "Template class"
to "Class template".
</P>
<P>In the section heading of 23.2.4&nbsp;



 <A HREF="lib-containers.html#lib.vector">lib.vector</A> change "Template class"
to "Class template".
</P>
<P>In the section heading of 23.3.1&nbsp;



 <A HREF="lib-containers.html#lib.map">lib.map</A> change "Template class"
to "Class template".
</P>
<P>In the section heading of 23.3.2&nbsp;



 <A HREF="lib-containers.html#lib.multimap">lib.multimap</A> change "Template class"
to "Class template".
</P>
<P>In the section heading of 23.3.3&nbsp;



 <A HREF="lib-containers.html#lib.set">lib.set</A> change "Template class"
to "Class template".
</P>
<P>In the section heading of 23.3.4&nbsp;



 <A HREF="lib-containers.html#lib.multiset">lib.multiset</A> change "Template class"
to "Class template".
</P>
<P>In the section heading of 23.3.5&nbsp;



 <A HREF="lib-containers.html#lib.template.bitset">lib.template.bitset</A> change "Template
class" to "Class template".
</P>
<P>In 23.3.5&nbsp;



 <A HREF="lib-containers.html#lib.template.bitset">lib.template.bitset</A> paragraph 1, change "template class"
to "class template".
</P>
<P>In the section heading of 24.4.1.1&nbsp;



 <A HREF="lib-iterators.html#lib.reverse.iterator">lib.reverse.iterator</A> change "Template
class" to "Class template".
</P>
<P>In the section heading of 24.4.2.1&nbsp;



 <A HREF="lib-iterators.html#lib.back.insert.iterator">lib.back.insert.iterator</A> change
"Template class" to "Class template".
</P>
<P>In the section heading of 24.4.2.3&nbsp;



 <A HREF="lib-iterators.html#lib.front.insert.iterator">lib.front.insert.iterator</A> change
"Template class" to "Class template".
</P>
<P>In the section heading of 24.4.2.5&nbsp;



 <A HREF="lib-iterators.html#lib.insert.iterator">lib.insert.iterator</A> change "Template
class" to "Class template".
</P>
<P>In 24.5&nbsp;



 <A HREF="lib-iterators.html#lib.stream.iterators">lib.stream.iterators</A> paragraph 1, change "template classes"
to "class templates".
</P>
<P>In the section heading of 24.5.1&nbsp;



 <A HREF="lib-iterators.html#lib.istream.iterator">lib.istream.iterator</A> change "Template
class" to "Class template".
</P>
<P>In the section heading of 24.5.2&nbsp;



 <A HREF="lib-iterators.html#lib.ostream.iterator">lib.ostream.iterator</A> [lib.ostream.iterator] change "Template
class" to "Class template".
</P>
<P>In the section heading of 24.5.3&nbsp;



 <A HREF="lib-iterators.html#lib.istreambuf.iterator">lib.istreambuf.iterator</A> change "Template
class" to "Class template".
</P>
<P>In 24.5.3&nbsp;



 <A HREF="lib-iterators.html#lib.istreambuf.iterator">lib.istreambuf.iterator</A> paragraph 1, change "template class"
to "class template".
</P>
<P>In the section heading of 24.5.3.1&nbsp;



 <A HREF="lib-iterators.html#lib.istreambuf.iterator::proxy">lib.istreambuf.iterator::proxy</A>
change "Template class" to "Class template".
</P>
<P>In the section heading of 24.5.4&nbsp;



 <A HREF="lib-iterators.html#lib.ostreambuf.iterator">lib.ostreambuf.iterator</A> change "Template
class" to "Class template".
</P>
<P>In 24.5.4&nbsp;



 <A HREF="lib-iterators.html#lib.ostreambuf.iterator">lib.ostreambuf.iterator</A> paragraph 1, change "template class"
to "class template".
</P>
<P>In 26.2&nbsp;



 <A HREF="lib-numerics.html#lib.complex.numbers">lib.complex.numbers</A> paragraph 1, change "template class"
to "class template".
</P>
<P>In the section heading of 26.2.2&nbsp;



 <A HREF="lib-numerics.html#lib.complex">lib.complex</A> change "Template class"
to "Class template".
</P>
<P>In 26.3.1&nbsp;



 <A HREF="lib-numerics.html#lib.valarray.synopsis">lib.valarray.synopsis</A> paragraph 1, change "template classes"
to "class templates" and change "function signatures" to "function templates".
</P>
<P>In the section heading of 26.3.2&nbsp;



 <A HREF="lib-numerics.html#lib.template.valarray">lib.template.valarray</A> change "Template
class" to "Class template".
</P>
<P>In the section heading of 26.3.5&nbsp;



 <A HREF="lib-numerics.html#lib.template.slice.array">lib.template.slice.array</A> change
"Template class" to "Class template".
</P>
<P>In the section heading of 26.3.7&nbsp;



 <A HREF="lib-numerics.html#lib.template.gslice.array">lib.template.gslice.array</A> change
"Template class" to "Class template".
</P>
<P>In the section heading of 26.3.8&nbsp;



 <A HREF="lib-numerics.html#lib.template.mask.array">lib.template.mask.array</A> change "Template
class" to "Class template".
</P>
<P>In the section heading of 26.3.9&nbsp;



 <A HREF="lib-numerics.html#lib.template.indirect.array">lib.template.indirect.array</A> change
"Template class" to "Class template".
</P>
<P>In 27.2&nbsp;



 <A HREF="lib-iostreams.html#lib.iostream.forward">lib.iostream.forward</A> [lib.iostream.forward] paragraphs 3 to 7, change "template
classes" to "class templates".
<I>[Note: Some editorial changes were made in paragraphs 2 to 8 when these
changes were applied in September 2001.]</I>
</P>
<P>In the section heading of 27.4.3&nbsp;



 <A HREF="lib-iostreams.html#lib.fpos">lib.fpos</A> change "Template class"
to "Class template".
</P>
<P>In the section heading of 27.4.4&nbsp;



 <A HREF="lib-iostreams.html#lib.ios">lib.ios</A> change "Template class"
to "Class template".
</P>
<P>In the section heading of 27.5.2&nbsp;



 <A HREF="lib-iostreams.html#lib.streambuf">lib.streambuf</A> change "Template class"
to "Class template".
</P>
<P>In 27.5.2&nbsp;



 <A HREF="lib-iostreams.html#lib.streambuf">lib.streambuf</A> paragraphs 2 and 3, change "template class"
to "class template".
</P>
<P>In the section heading of 27.6.1.1&nbsp;



 <A HREF="lib-iostreams.html#lib.istream">lib.istream</A> change "Template class"
to "Class template".
</P>
<P>In the section heading of 27.6.1.5&nbsp;



 <A HREF="lib-iostreams.html#lib.iostreamclass">lib.iostreamclass</A> change "Template
class" to "Class template".
</P>
<P>In the section heading of 27.6.2.1&nbsp;



 <A HREF="lib-iostreams.html#lib.ostream">lib.ostream</A> change "Template class"
to "Class template".
</P>
<P>In 27.7&nbsp;



 <A HREF="lib-iostreams.html#lib.string.streams">lib.string.streams</A> paragraph 1 change "template classes"
to "class templates".
</P>
<P>In the section heading of 27.7.1&nbsp;



 <A HREF="lib-iostreams.html#lib.stringbuf">lib.stringbuf</A> change "Template class"
to "Class template".
</P>
<P>In the section heading of 27.7.2&nbsp;



 <A HREF="lib-iostreams.html#lib.istringstream">lib.istringstream</A> change "Template
class" to "Class template".
</P>
<P>In the section heading of 27.7.4&nbsp;



 <A HREF="lib-iostreams.html#lib.stringstream">lib.stringstream</A> change "Template
class" to "Class template".
</P>
<P>In the section heading of 27.8.1.1&nbsp;



 <A HREF="lib-iostreams.html#lib.filebuf">lib.filebuf</A> change "Template class"
to "Class template".
</P>
<P>In the section heading of 27.8.1.5&nbsp;



 <A HREF="lib-iostreams.html#lib.ifstream">lib.ifstream</A> change "Template
class" to "Class template".
</P>
<P>In the section heading of 27.8.1.8&nbsp;



 <A HREF="lib-iostreams.html#lib.ofstream">lib.ofstream</A> change "Template
class" to "Class template".
</P>
<P>In the section heading of 27.8.1.11&nbsp;



 <A HREF="lib-iostreams.html#lib.fstream">lib.fstream</A> change "Template
class" to "Class template".</P>

<BR>
<BR>
<HR>
<A NAME="134"></A>
<H4>134.
  
Template classes and <I>declarator-id</I>s
</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>DR
 &nbsp;&nbsp;&nbsp;

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

 <B>Date: </B>17 June 1999
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Miller<BR>




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


<P>14&nbsp;



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

<BLOCKQUOTE>
[<I>Note:</I> in a class template declaration, if the
<I>declarator-id</I> is a <I>template-id</I>, the declaration
declares a class template partial specialization
(14.5.4&nbsp;



 <A HREF="template.html#temp.class.spec">temp.class.spec</A>
). ]
</BLOCKQUOTE>

There is no <I>declarator-id</I> in a class template declaration
(cf paragraph 3).

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

<P>Replace the phrase "if the
<I>declarator-id</I> is a <I>template-id</I>" with "if the class name
is a <I>template-id</I>."</P>
<BR>
<BR>
<HR>
<A NAME="21"></A>
<H4>21.
  
Can a default argument for a template parameter appear in a friend declaration?
</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>DR
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>unknown
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Spicer<BR>




<P>(Previously numbered 932.)</P>


<P>14.1&nbsp;



 <A HREF="template.html#temp.param">temp.param</A>
 paragraph 10 says:</P>
<BLOCKQUOTE>The set of default template-arguments available for use with
a template declaration or definition is obtained by merging the default
arguments from the definition (if in scope) and all declarations in scope
in the same way as default function arguments are (8.3.6&nbsp;



 <A HREF="decl.html#dcl.fct.default">dcl.fct.default</A>
)."</BLOCKQUOTE>
Can a default argument for a template argument appear in a friend declaration?
If so, when is this default argument considered for template instantiations?

<P>For example,</P>
<PRE>
    template&lt;class T1, class T2 = int&gt; class A;
 
    class B {
        template&lt;class T1 = int, class T2&gt; friend class A;
    };
</PRE>
Is this well-formed? If it is, should the IS say when the default argument
for <TT>T1</TT> is considered for instantiations of class <TT>A</TT>?

<P>
<B>Proposed resolution (10/00):</B> Add to the end of
14.1&nbsp;



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

<BLOCKQUOTE>
A default <I>template-argument</I> shall not be specified in a friend
template declaration.
</BLOCKQUOTE>
<P>(See also <A HREF="
     cwg_defects.html#136">issue 136</A>.)</P>
<BR>
<BR>
<HR>
<A NAME="49"></A>
<H4>49.
  
Restriction on non-type, non-value template arguments
</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>DR
 &nbsp;&nbsp;&nbsp;

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

 <B>Date: </B>16 Oct 1998<BR>



<P>The example in
14.1&nbsp;



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

 paragraph
8 is:</P>
<PRE>
    template&lt;int* a&gt; struct R { /*...*/ };
    int* p;
    R&lt;p&gt; w;
</PRE>
There was a French comment was that this is an error, and there was general
agreement with that.

<P>I've been looking for the verbiage that specifies that this is an error
and haven't found it. In particular, nothing in 14.1&nbsp;



 <A HREF="template.html#temp.param">temp.param</A>
 ("Template parameters")
nor 14.3.2&nbsp;



 <A HREF="template.html#temp.arg.nontype">temp.arg.nontype</A>
 ("Template non-type arguments") appears to rule out this case.
(14.3.2&nbsp;



 <A HREF="template.html#temp.arg.nontype">temp.arg.nontype</A>
 paragraph 1 allows an argument to be "the name of an object or function with
external linkage," with no limitation on the kinds of parameters such a
name can match; "p" is, in fact, such a name.)</P>

<P>Should the resolution of the French comment include beefing up one or
both of these sections to cover the applicable rules explicitly?</P>

<P>
<B>Proposed Resolution (04/99):</B>
Change the example in 14.1&nbsp;



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

paragraph 8 from:</P>
<PRE>
    template&lt;int *a&gt; struct R { /* ... */ };
    template&lt;int b[5]&gt; struct S { /* ... */ };
    int *p;
    R&lt;p&gt; w; // <I>OK</I>
    S&lt;p&gt; x; // <I>OK due to parameter adjustment</I>
    int v[5];
    R&lt;v&gt; y; // <I>OK due to implicit argument conversion</I>
    S&lt;v&gt; z; // <I>OK due to both adjustment and conversion</I>
</PRE>
to:
<PRE>
    template&lt;int *a&gt; struct R { /* ... */ };
    template&lt;int b[5]&gt; struct S { /* ... */ };
    int p;
    R&lt;&amp;p&gt; w; // <I>OK</I>
    S&lt;&amp;p&gt; x; // <I>OK due to parameter adjustment</I>
    int v[5];
    R&lt;v&gt; y; // <I>OK due to implicit argument conversion</I>
    S&lt;v&gt; z; // <I>OK due to both adjustment and conversion</I>
</PRE>
Furthermore, in 14.3.2&nbsp;



 <A HREF="template.html#temp.arg.nontype">temp.arg.nontype</A>
 paragraph 1:
<UL>
<LI>the fourth bullet item should be changed from "...where the &amp; is optional
if the name refers to a function or array;" to "...where the &amp; is optional
if the name refers to a function or array, or if
the corresponding <I>template-parameter</I> is a reference;"</LI>

<LI>the third bullet item should be removed.</LI>
</UL>
<BR>
<BR>
<HR>
<A NAME="187"></A>
<H4>187.
  
Scope of template parameter names
</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>DR
 &nbsp;&nbsp;&nbsp;

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

 <B>Date: </B>15 Nov 1999<BR>




<P>From reflector messages 8364-6, 8369, 8370, and 8372.</P>


<P>At the Dublin meeting (04/99), the Committee proposed to resolve
<A HREF="
     cwg_defects.html#22">issue 22</A> by simply changing the
wording to make clear that a template parameter cannot be used in its
own default argument.  This creates a third treatment of this kind of
situation, in addition to
3.3.1&nbsp;



 <A HREF="basic.html#basic.scope.pdecl">basic.scope.pdecl</A>
 paragraph 1, where
declarators are in scope and can be used in their initializers, and
paragraph 3, where an enumerator is not in scope until after its
complete <I>enumerator-definition</I>.  The Dublin resolution is for
the template parameter to be in scope in its default argument but not
usable.  It would be more consistent to treat template parameters like
enumerators: simply not in scope until the entire
<I>template-parameter</I> declaration is seen.</P>

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



 <A HREF="template.html#temp.param">temp.param</A>
 paragraph 14 should be
rewritten to connect the prohibition with visibility rules; otherwise,
it sounds as if the following example is not permitted:</P>

<PRE>
    const int Z = 1;
    template &lt;int X = Z, int Z&gt; class A {};
</PRE>

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

<P>The core working group did not reach consensus on the suggested
approach to <A HREF="
     cwg_defects.html#22">issue 22</A>.  However, it was
agreed that the intent expressed in the earlier resolution would be
better served by different wording.</P>

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

<P>
<I>[Note: This resolution supersedes the resolution to
<A HREF="
     cwg_defects.html#22">issue 22</A>.]</I>
</P>

<P>Replace 14.1&nbsp;



 <A HREF="template.html#temp.param">temp.param</A> paragraph 14 as follows:</P>

<BLOCKQUOTE>
A template parameter shall not be used in its own default argument.
</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="30"></A>
<H4>30.
  
Valid uses of "<TT>::template</TT>"
</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>DR
 &nbsp;&nbsp;&nbsp;

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

 <B>Date: </B>28 May 1998<BR>




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


<P>I have a request for clarification regarding a issue similar to John
Wiegley's, but wrt. the <TT>::template</TT> syntax. More precisely, where
is</P>
<PRE>
    X::template Y
</PRE>
allowed? (It is required for dependent <TT>X</TT> where <TT>Y</TT> is a
<I>template-id</I>, I believe, but it doesn't seem to be disallowed elsewhere.)
    
<P>The question also holds for '<TT>.template</TT>' and '<TT>-&gt;template</TT>'.</P>
    
<P>
<B>Proposed Resolution (04/99):</B>
Append to 14.2&nbsp;



 <A HREF="template.html#temp.names">temp.names</A>
 paragraph 5:</P>
<BLOCKQUOTE>Furthermore, names of member templates shall not be prefixed
by the keyword <TT>template</TT> if the <I>postfix-expression</I> or <I>qualified-id</I>
does not appear in the scope of a template. [<I>Note:</I> just as is the case
with the <TT>typename</TT> prefix, the <TT>template</TT> prefix is allowed
in cases where it is not strictly necessary; i.e., when the expression
on the left of the <TT>-&gt;</TT> or <TT>.</TT>, or the <I>nested-name-specifier</I>
is not dependent on a <I>template-parameter</I>. ]</BLOCKQUOTE>
<BR>
<BR>
<HR>
<A NAME="38"></A>
<H4>38.
  
Explicit template arguments and operator functions
</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>DR
 &nbsp;&nbsp;&nbsp;

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

 <B>Date: </B>17 Aug 1998
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Spicer/Schmeiser<BR>



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


<P>It appears from the grammar that explicit template arguments cannot
be specified for overloaded operator names. Does this mean that
template operators can never be friends?</P>
 
<P>But assuming that I read things wrong, then I should be able to
specify a global template '<TT>operator +</TT>' by writing:</P>

<PRE>
    friend A::B operator + &lt;&gt;(char&amp;);
</PRE>
<U>John Spicer:</U>

<P>You <B>should</B> be able to have explicit template arguments on operator
functions, but the grammar does seem to prohibit it (unless I'm reading
it incorrectly). This is an error in the grammar, they should be permitted.</P>

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

<P>Change the grammar specified in 13.5&nbsp;



 <A HREF="over.html#over.oper">over.oper</A>
paragraph 1 from <BR>

<UL>
<I>operator-function-id:</I>
<UL>
<TT>operator</TT> <I>operator</I>
</UL>
</UL>

to<BR>

<UL>
<I>operator-function-id:</I>
<UL>
<TT>operator</TT> <I>operator</I>
<BR>
<TT>operator</TT> <I>operator</I> <TT>&lt;</TT>
<I>template-argument-list<SUB>opt</SUB></I> <TT>&gt;</TT>
</UL>
</UL>
</P>
<BR>
<BR>
<HR>
<A NAME="246"></A>
<H4>246.
  
Jumps in <I>function-try-block</I> handlers
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>14.3&nbsp;



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

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

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

 <B>Date: </B>15 Sep 2000
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>0
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Miller<BR>


<P>From messages 8899-8902.</P>

<P>Is it permitted to jump from a handler of a
<I>function-try-block</I> into the body of the function?</P>

<P>15&nbsp;



 <A HREF="except.html#except">except</A> paragraph 2 would appear to disallow
such a jump:</P>

<BLOCKQUOTE>

A <TT>goto</TT>, <TT>break</TT>, <TT>return</TT>, or <TT>continue</TT>
statement can be used to transfer control out of a try block or
handler, but not into one.

</BLOCKQUOTE>

<P>However, 15.3&nbsp;



 <A HREF="except.html#except.handle">except.handle</A> paragraph 14 mentions
only constructors and destructors for the prohibition:</P>

<BLOCKQUOTE>

If the handlers of a <I>function-try-block</I> contain a jump into the
body of a constructor or destructor, the program is ill-formed.

</BLOCKQUOTE>

<P>Is this paragraph simply reemphasizing the more general
restriction, or does it assume that such a jump would be permitted
for functions other than constructors or destructors?  If the
former interpretation is correct, it is confusing and should be
either eliminated or turned into a note.  If the latter
interpretation is accurate, 15&nbsp;



 <A HREF="except.html#except">except</A> paragraph 2
must be revised.</P>

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

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

<P>Delete 15.3&nbsp;



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

<BR>
<BR>
<HR>
<A NAME="62"></A>
<H4>62.
  
Unnamed members of classes used as type parameters
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>14.3.1&nbsp;



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

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

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

 <B>Date: </B>13 Oct 1998
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Miller<BR>



<P>Section 14.3.1&nbsp;



 <A HREF="template.html#temp.arg.type">temp.arg.type</A>
 paragraph 2 says</P>
<BLOCKQUOTE>A local type, a type with no linkage, an unnamed type or a
type compounded from any of these types shall not be used as a <I>template-argument
</I>for a template <I>type-parameter</I>.</BLOCKQUOTE>
<P>It probably wasn't intended that classes with unnamed members should be
included in this list, but they are arguably compounded from unnamed types.</P>

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

<P>In 14.3.1&nbsp;



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

<BLOCKQUOTE>

A local type, a type with no linkage, an unnamed type or a type
compounded from any of these types shall not be used as a
<I>template-argument</I> for a template <I>type-parameter</I>.

</BLOCKQUOTE>

<P>to</P>

<BLOCKQUOTE>

The following types shall not be used as a <I>template-argument</I>
for a template <I>type-parameter</I>:

<UL>

<LI>a type whose name has no linkage</LI>

<LI>an unnamed class or enumeration type that has no name for
linkage purposes (7.1.3&nbsp;



 <A HREF="dcl.html#dcl.typedef">dcl.typedef</A>)</LI>

<LI>a cv-qualified version of one of the types in this list</LI>

<LI>a type created by application of declarator operators to one
of the types in this list</LI>

<LI>a function type that uses one of the types in this list</LI>

</UL>

</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="100"></A>
<H4>100.
  
Clarify why string literals are not allowed as template arguments
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>14.3.2&nbsp;



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

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

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

 <B>Date: </B>9 Mar 1999<BR>



<P>The explanation in
14.3.2&nbsp;



 <A HREF="template.html#temp.arg.nontype">temp.arg.nontype</A>

paragraph 2 of why a string literal cannot be
used as a template argument leaves something to be desired:</P>
<BLOCKQUOTE>
...because a string literal is an object with internal linkage.
</BLOCKQUOTE>
I can't find anything that says that a string literal has
internal linkage.  In fact, I'd be pretty surprised if I did,
since linkage is defined (in
3.5&nbsp;



 <A HREF="basic.html#basic.link">basic.link</A>
) strictly in terms of
names, and a string literal doesn't have a name.

Actually, I think that it's the namelessness of a string literal
that prevents it from being a template argument; only the
third and fourth bullets of
14.3.2&nbsp;



 <A HREF="template.html#temp.arg.nontype">temp.arg.nontype</A>

paragraph 1 could conceivably apply,
and both of those require that the entity have a name (i.e.,
that they be given as an <I>id-expression</I>).

<P>
<B>Proposed Resolution (10/99):</B>
In 14.3.2&nbsp;



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

<BLOCKQUOTE>
[<I>Note:</I> a string literal
(2.13.4&nbsp;



 <A HREF="lex.html#lex.string">lex.string</A>
) is not an acceptable
<I>template-argument</I> because a string literal is an object
with internal linkage.
</BLOCKQUOTE>

to

<BLOCKQUOTE>
[<I>Note:</I> a string literal
(2.13.4&nbsp;



 <A HREF="lex.html#lex.string">lex.string</A>
) does not satisfy the
requirements of  any of these categories and thus is not an
acceptable <I>template-argument</I>.
</BLOCKQUOTE>
<BR>
<BR>
<HR>
<A NAME="249"></A>
<H4>249.
  
What is a member function template?
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>14.5.1.1&nbsp;



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

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

 <B>Submitter: </B>David Thornley
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>11 Oct 2000<BR>


<P>The phrase "member function template" is used in
3.2&nbsp;



 <A HREF="basic.html#basic.def.odr">basic.def.odr</A> paragraph 5 in the list of entities whose
definitions can appear more than once in a program, with a
cross-reference to 14.5.1.1&nbsp;



 <A HREF="template.html#temp.mem.func">temp.mem.func</A>.  The title of
that section is "Member functions of class templates," and paragraph 1
of that section says,</P>

<BLOCKQUOTE>

A member function template may be defined outside of the class
template in which it is declared.

</BLOCKQUOTE>

<P>The example in that paragraph shows a non-template member function
of a class template being defined.  This gives the impression that the
phrase "member function template" is intended to refer to a member
function of a class template.</P>

<P>If this usage were intended, much of the rest of the Standard
would be unintelligible: objects of class template specializations
could not be copied (12.8&nbsp;



 <A HREF="special.html#class.copy">class.copy</A> paragraph 3),
member functions of class templates could not be declared
<TT>virtual</TT> (14.5.2&nbsp;



 <A HREF="template.html#temp.mem">temp.mem</A> paragraph 3),
etc.</P>

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

<P>Change "member function template" to "member function of a class
template" in both 3.2&nbsp;



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



 <A HREF="template.html#temp.mem.func">temp.mem.func</A> paragraph 1.</P>

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

<P>
<B>Proposed resolution (10/00):</B> As suggested.</P>

<BR>
<BR>
<HR>
<A NAME="116"></A>
<H4>116.
  
Equivalent and functionally-equivalent function templates
</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>DR
 &nbsp;&nbsp;&nbsp;

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

 <B>Date: </B>11 May 1999<BR>




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


<P>14.5.5.1&nbsp;



 <A HREF="template.html#temp.over.link">temp.over.link</A>
, paragraphs 5 and 6,
describes equivalence and
functional equivalence for expressions involving template
parameters.  As a note in paragraph 5 points out, such
expressions may involve type parameters as well as non-type
parameters.</P>

<P>Paragraph 7, however, describes the equivalence of function
templates only with respect to non-type template parameters.
It appears to be unspecified how to determine the equivalence
of template functions whose types involve expressions that
use template type parameters.</P>

<PRE>
    template &lt;int I&gt; struct S { };

    // The following two declarations are equivalent:
    template &lt;int I&gt; void f(S&lt;I&gt;);
    template &lt;int J&gt; void f(S&lt;J&gt;);

    // The IS doesn't say whether these are equivalent:
    template &lt;class T&gt; void f(S&lt;sizeof(T)&gt;);
    template &lt;class T&gt; void f(S&lt;sizeof(T)&gt;);
</PRE>

<P>
<B>Proposed resolution (10/99):</B>
Remove the three uses of the words "non-type" in
14.5.5.1&nbsp;



 <A HREF="template.html#temp.over.link">temp.over.link</A>
 paragraph 7.</P>
<BR>
<BR>
<HR>
<A NAME="120"></A>
<H4>120.
  
Nonexistent non-terminal <I>qualified-name</I>
</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>DR
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Bill Gibbons
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>28 May 1999<BR>



<P>In 14.6&nbsp;



 <A HREF="template.html#temp.res">temp.res</A>
, references to the
nonexistent syntactic non-terminal <I>qualified-name</I> occur twice
in paragraph 3, twice in paragraph 4, and once in paragraph 5.  There
is also a reference in
14.1&nbsp;



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

<P>
<B>Proposed resolution (10/99):</B> Change
the reference in all these cases to <I>qualified-id</I>.</P>
<BR>
<BR>
<HR>
<A NAME="121"></A>
<H4>121.
  
Dependent type names with non-dependent <I>nested-name-specifier</I>s
</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>DR
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Bill Gibbons
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>28 May 1999
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Miller<BR>



<P>The wording in
14.6&nbsp;



 <A HREF="template.html#temp.res">temp.res</A>
 paragraph 3:</P>
<BLOCKQUOTE>
A <I>qualified-name</I> that refers to a type and that depends on a
<I>template-parameter</I>
(14.6.2&nbsp;



 <A HREF="template.html#temp.dep">temp.dep</A>
) shall be prefixed by the keyword
<TT>typename</TT>
to indicate that the <I>qualified-name</I> denotes a type, forming an
elaborated-type-specifier
(7.1.5.3&nbsp;



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

was intended to say:
<BLOCKQUOTE>
A <I>qualified-id</I> that refers to a type and in which the
<I>nested-name-specifier</I> depends on a <I>template-parameter</I>
(14.6.2&nbsp;



 <A HREF="template.html#temp.dep">temp.dep</A>
) shall ...
</BLOCKQUOTE>

in much the same vein as
14.6.2.1&nbsp;



 <A HREF="template.html#temp.dep.type">temp.dep.type</A>, second bullet, first half.

<P>
<B>Proposed resolution (10/00):</B> As suggested.</P>
<BR>
<BR>
<HR>
<A NAME="183"></A>
<H4>183.
  
<TT>typename</TT> in explicit specializations
</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>DR
 &nbsp;&nbsp;&nbsp;

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

 <B>Date: </B>9 Nov 1999
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Spicer<BR>




<P>From reflector messages 8353-5.</P>


<P>
<U>John Spicer</U>:
In 14.6&nbsp;



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

<BLOCKQUOTE>
The keyword <TT>typename</TT> shall only be used in
template declarations and definitions...
</BLOCKQUOTE>

My understanding of the intent of this restriction is to say that
<TT>typename</TT> is only allowed in contexts in which template
dependent names can be found, but the wording leaves open to
interpretation whether <TT>typename</TT> is allowed in an explicit
specialization, such as:

<PRE>
    template &lt;class T&gt; struct A {};
    template &lt;class T&gt; struct B { typedef int X; };
    template &lt;&gt; struct A&lt;int&gt; {
        typename B&lt;int&gt;::X x;
    };
</PRE>

My understanding is that such usage is not permitted.
This should be clarified one way or the other.

<P>
<U>Mike Miller</U>:
I agree with your understanding that you are not allowed to
use <TT>typename</TT> in an explicit specialization.  However, I think
the standard already says that &mdash; an explicit specialization
is not a template declaration.  According to the grammar in
14&nbsp;



 <A HREF="template.html#temp">temp</A>
 paragraph 1, a
<I>template-declaration</I> must have a non-empty
<I>template-parameter-list</I>.</P>

<P>
<U>Nathan Myers</U>:
Is there any actual reason for this restriction?  Its only apparent
effect is to make it harder to specialize templates, with no
corresponding benefit.</P>

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

<P>In 14.6&nbsp;



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

<BLOCKQUOTE>

The keyword <TT>typename</TT> shall only be applied to qualified
names, but those names need not be dependent.

</BLOCKQUOTE>

<P>with</P>

<BLOCKQUOTE>

The keyword <TT>typename</TT> shall be applied only to qualified
names, but those names need not be dependent.  The keyword
<TT>typename</TT> shall be used only in contexts in which dependent
names can be used.  This includes template declarations and
definitions but excludes explicit specialization declarations and
explicit instantiation declarations.

</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="213"></A>
<H4>213.
  
Lookup in dependent base classes
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>14.6.2&nbsp;



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

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

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

 <B>Date: </B>10 Mar 2000
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Spicer<BR>



<P>From reflector messages 8595-9.</P>


<P>Paragraphs 3-4 of 14.6.2&nbsp;



 <A HREF="template.html#temp.dep">temp.dep</A> say, in part,</P>

<BLOCKQUOTE>

if a base class of [a class] template depends on a
<I>template-parameter</I>, the base class scope is not examined during
name lookup until the class template is instantiated...  If a base
class is a dependent type, a member of that class cannot hide a name
declared within a template, or a name from the template's enclosing
scope.

</BLOCKQUOTE>

<P>
<U>John Spicer</U>: The wording in paragraph 4 seems particularly
odd to me.  It essentially changes the order in which scopes are
considered.  If a scope outside of the template declares a given name,
that declaration hides entities of the same name from template
dependent base classes (but not from nondependent base classes).</P>

<P>In the following example, the calls of <TT>f</TT> and <TT>g</TT>
are handled differently because <TT>B::f</TT> cannot hide
<TT>::f</TT>, but <TT>B::g</TT> doesn't try to hide anything, so it
can be called.</P>

<PRE>
    extern "C" int printf(char *, ...);
    template &lt;class T&gt; struct A : T {
        void h(T t) {
            f(t);  // calls ::f(B)
            g(t);  // calls B::g
        }
    };

    struct B {
        void f(B){printf("%s", "in B::f\n");}
        void g(B){printf("%s", "in B::g\n");}
    };

    void f(B){printf("%s", "in ::f\n");}

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

<P>I don't think the current wording in the standard provides a useful
facility.  The author of class <TT>A</TT> can't be sure that a given
call is going to call a base class function unless the base class is
explicitly specified.  Adding a new global function could cause the
program to suddenly change meaning.</P>

<P>What I <I>thought</I> the rule was is, "If a base class is a
dependent type a member of that class is not found by unqualified
lookup".</P>

<P>
<U>Derek Inglis:</U> My understanding is the same except that I'd
remove the word "qualified" from your sentence.</P>

<P>
<U>Erwin Unruh</U>: My interpretation is based on 14.6.4&nbsp;



 <A HREF="template.html#temp.dep.res">temp.dep.res</A> and especially 14.6.4.2&nbsp;



 <A HREF="template.html#temp.dep.candidate">temp.dep.candidate</A> (and
largely on my memory of the discussions). For all unqualified names
you do something like the following algorithm:</P>

<OL>
<LI>check whether it is a dependent function call</LI>
<LI>Do a lookup in the definition context and remember what you found there</LI>
<LI>Do a Koenig-Lookup at instantiation time</LI>
<LI>perform overloading if necessary</LI>
</OL>

<P>Regarding names from base classes you cannot find them in 2) because you
don't know what base class you have. You cannot find them in 3) because
members of classes are not found by Koenig lookup (only namespaces are
considered). So you don't find them at all (for unqualified names).</P>

<P>For a qualified name, you start lookup for each 'part' of the qualification.
Once you reach a dependent part, you stop and continue lookup at the
instantiation point. For example:</P>

<PRE>
    namespace A {
      namepace B {
	template &lt;class T&gt; class C {
	  template &lt;class U&gt; class D {
	    typedef int E;
	    // ...
	  };
	};
      };
    };

    template &lt;class T&gt; class F : public T {
      typename A::B::C&lt;int&gt;::D&lt;T&gt;::E var1;
      typename A::B::C&lt;T&gt;::D&lt;int&gt;::E var2;
      typename F::T::X var3;
    }
</PRE>

<P>For <TT>var1</TT> you do lookup for <TT>A::B::C&lt;int&gt;::D</TT>
at definition time, for <TT>var2</TT> you only do lookup for
<TT>A::B::C</TT>. The rest of the lookup is done at instantiation time
since specialisations could change part of the lookup. Similarly the
lookup for <TT>var3</TT> stops after <TT>F::T</TT> at definition
time.</P>

<P>My impression was that an unqualified name never refers to a name
in a dependent base class.</P>

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

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

<OL>

<LI>

<P>In 14.6.2&nbsp;



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

<BLOCKQUOTE>

In the definition of a class template or in the definition of a member
of such a template that appears outside of the template definition, if
a base class of this template depends on a <I>template-parameter</I>,
the base class scope is not examined during name lookup until the
class template is instantiated.

</BLOCKQUOTE>

<P>with</P>

<BLOCKQUOTE>

In the definition of a class template or a member of a class template,
if a base class of the class template depends on a
<I>template-parameter</I>, the base class scope is not examined during
unqualified name lookup either at the point of definition of the class
template or member or during an instantiation of the class template or
member.

</BLOCKQUOTE>

</LI>

<LI>

<P>Remove from 14.6.2&nbsp;



 <A HREF="template.html#temp.dep">temp.dep</A> paragraph 4:</P>

<BLOCKQUOTE>

If a base class is a dependent type, a member of that class cannot
hide a name declared within a template, or a name from the template's
enclosing scopes.

</BLOCKQUOTE>

</LI>

</OL>

<BR>
<BR>
<HR>
<A NAME="108"></A>
<H4>108.
  
Are classes nested in templates dependent?
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>14.6.2.1&nbsp;



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

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

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

 <B>Date: </B>14 Apr 1999
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Spicer<BR>




<P>From messages 8011 and 8016.</P>


<P>
<U>Mark Mitchell (via John Spicer):</U> Given:</P>
<PRE>
  template &lt;class T&gt; struct S {
     struct I1 {
       typedef int X;
     };
     struct I2 : public I1 {
        X x;
     };
  };
</PRE>
<P>Is this legal?  The question really boils down to asking whether or
not <TT>I1</TT> is a dependent type.  On the one hand, it doesn't seem to fit
any of the qualifications in 14.6.2.1&nbsp;



 <A HREF="template.html#temp.dep.type">temp.dep.type</A>
.
On the other, 14.7.3&nbsp;



 <A HREF="template.html#temp.expl.spec">temp.expl.spec</A>
 allows
explicit specialization of a member class of a class template, so something
like:</P>
<PRE>
  template &lt;&gt; 
  struct S&lt;double&gt;::I1 {
     int X;
  };
</PRE>
<P>is apparently legal.  But, then, `X' no longer refers to a type name.
So, it seems like `I1' should be classified as dependent.  What am I
missing?</P>

<P>
<U>Erwin Unruh:</U> I wrote that particular piece of text and I just
missed the problem above. It is intended to be a dependent type. The
reasoning is that <TT>I1</TT> is just a shorthand for
<TT>S&lt;T&gt;::I1</TT> which clearly is
dependent.</P>

<P>
<B>Suggested Resolution:</B> (Erwin Unruh)</P>
<P>I think the list of what is a dependent type should be extended to cover
"a type declared and used within the same template" modulo of
phrasing.</P>

<P>(See also paper J16/00-0009 = WG21 N1231.  This issue is also
somewhat related to <A HREF="
     cwg_active.html#205">issue 205</A>: classes
nested inside template classes are, in some sense, "templates," just
as non-template member functions of class templates and static data
members of class templates are "templates.")</P>

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

<P>Add after 14.6.1&nbsp;



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

<BLOCKQUOTE>

Within the scope of a class template, when the unqualified name of a
nested class of the class template is referred to, it is equivalent to
the name of the nested class qualified by the name of the enclosing
class template. [<I>Example:</I>

<PRE>
    template &lt;class T&gt; struct A {
	class B {};
	// B is equivalent to A::B, which is equivalent to A&lt;T&gt;::B,
	// which is dependent.
	class C : B { };
    };
</PRE>

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

</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="224"></A>
<H4>224.
  
Definition of dependent names
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>14.6.2.1&nbsp;



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

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

 <B>Submitter: </B>Derek Inglis
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>30 Nov 1999
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>1
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Spicer<BR>



<P>From reflector messages 8384-89, 8394.</P>


<P>The definition of when a type is dependent, given in
14.6.2.1&nbsp;



 <A HREF="template.html#temp.dep.type">temp.dep.type</A>, is essentially syntactic: if the
reference is a <I>qualified-id</I> and one of the <I>class-name</I>s
in the <I>nested-name-specifier</I> is dependent, the type is
dependent.  This approach leads to surprising results:</P>

<PRE>
    template &lt;class T&gt; class X {
        typedef int I;
	I a;                 // non-dependent
        typename X&lt;T&gt;::I b;  // dependent
        typename X::I c;     // dependent (X is equivalent to X&lt;T&gt;)
    };
</PRE>

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

<P>The decision on whether a name is dependent or non-dependent should
be based on lookup, not on the form of the name: if the name can be
looked up in the definition context and cannot be anything else as the
result of specialization, the name should be non-dependent.</P>

<P>See papers J16/00-0028 = WG21 N1251 and
J16/00-0056 = WG21 N1279.</P>

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

<OL>

<LI>
<P>Replace section 14.6.2.1&nbsp;



 <A HREF="template.html#temp.dep.type">temp.dep.type</A> with the
following:

<BLOCKQUOTE>

<P>In the definition of a class template, a nested class of a class
template, a member of a class template, or a member of a nested class
of a class template, a name refers to the <I>current
instantiation</I> if it is</P>

<UL>

<LI>the injected-class-name (clause 9&nbsp;



 <A HREF="class.html#class">class</A>) of the
class template or nested class,</LI>

<LI>in the definition of a primary class template, the name of the
class template followed by the template argument list of the
primary template (as described below) enclosed in &lt;&gt;,</LI>

<LI>in the definition of a nested class of a class template,
the name of the nested class referenced as a member of the
current instantiation, or</LI>

<LI>in the definition of a partial specialization, the name of
the class template followed by the template argument list of
the partial specialization enclosed in &lt;&gt;.</LI>

</UL>

<P>The template argument list of a primary template is a
template argument list in which the n<SUP>th</SUP> template
argument has the value of the n<SUP>th</SUP> template
parameter of the class template.</P>

<P>A template argument that is equivalent to a template
parameter (i.e., has the same constant value or the same type
as the template parameter) can be used in place of that
template parameter in a reference to the current
instantiation.  In the case of a nontype template argument,
the argument must have been given the value of the
template parameter and not an expression involving the
template parameter.</P>

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

<PRE>
template &lt;class T&gt; class A {
    A* p1;      // A is the current instantiation
    A&lt;T&gt;* p2;   // A&lt;T&gt; is the current instantiation
    A&lt;T*&gt; p3;   // A&lt;T*&gt; is not the current instantiation
    ::A&lt;T&gt;* p4; // ::A&lt;T&gt; is the current instantiation
    class B {
	B* p1;        // B is the current instantiation
	A&lt;T&gt;::B* p2;  // A&lt;T&gt;::B is the current instantiation
	typename A&lt;T*&gt;::B* p3; // A&lt;T*&gt;::B is not the
			     // current instantiation
    };
};

template &lt;class T&gt; class A&lt;T*&gt; {
    A&lt;T*&gt;* p1;  // A&lt;T*&gt; is the current instantiation
    A&lt;T&gt;* p2;   // A&lt;T&gt; is not the current instantiation
};

template &lt;class T1, class T2, int I&gt; struct B {
    B&lt;T1, T2, I&gt;*	b1;        // refers to the current instantiation
    B&lt;T2, T1, I&gt;*	b2;        // not the current instantiation
    typedef T1 my_T1;
    static const int my_I = I;
    static const int my_I2 = I+0;
    static const int my_I3 = my_I;
    B&lt;my_T1, T2, my_I&gt;* b3;  // refers to the current instantiation
    B&lt;my_T1, T2, my_I2&gt;* b4; // not the current instantiation
    B&lt;my_T1, T2, my_I3&gt;* b5; // refers to the current instantiation
};
</PRE>

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

<P>A name is a <I>member of the current instantiation</I> if it is</P>

<UL>

<LI>An unqualified name that, when looked up, refers to a member
of a class template.  [<I>Note:</I> This can only occur when
looking up a name in a scope enclosed by the definition of a
class template.]</LI>

<LI>A <I>qualified-id</I> in which the <I>nested-name-specifier</I>
refers to the current instantiation.</LI>

</UL>

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

<PRE>
template &lt;class T&gt; class A {
    static const int i = 5;
    int n1[i];        // i refers to a member of the current instantiation 
    int n2[A::i];     // A::i refers to a member of the current instantiation 
    int n3[A&lt;T&gt;::i];  // A&lt;T&gt;::i refers to a member of the current instantiation 
    int f();
};

template &lt;class T&gt; int A&lt;T&gt;::f()
{
    return i;  // i refers to a member of the current instantiation
}
</PRE>

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

<P>A name is a <I>member of an unknown specialization</I> if the
name is a <I>qualified-id</I> in which the
<I>nested-name-specifier</I> names a dependent type that is not
the current instantiation.</P>

<P>A type is dependent if it is</P>

<UL>

<LI>a template parameter,</LI>

<LI>a member of an unknown specialization,</LI>

<LI>a nested class that is a member of the current
instantiation,</LI>

<LI>a cv-qualified type where the cv-unqualified type is dependent,</LI>

<LI>a compound type constructed from any dependent type,</LI>

<LI>an array type constructed from any dependent type or whose
size is specified by a constant expression that is value-dependent, or</LI>

<LI>a <I>template-id</I> in which either the template name is a
template parameter or any of the template arguments is a dependent
type or an expression that is type-dependent or value-dependent.</LI>

</UL>

<P>[<I>Note:</I> Because typedefs to not introduce new types, but
instead simply refer to other types, a name that refers to a
typedef that is a member of the current instantiation is dependent
only if the type referred to is dependent.]</P>

</BLOCKQUOTE>

</P>
</LI>

<LI>
<P>In 14.6.2.2&nbsp;



 <A HREF="template.html#temp.dep.expr">temp.dep.expr</A> paragraph 3, replace</P>

<BLOCKQUOTE>

<UL>
<LI>a <I>nested-name-specifier</I> that contains a
<I>class-name</I> that names a dependent type.</LI>
</UL>

</BLOCKQUOTE>

<P>with</P>

<BLOCKQUOTE>

<UL>
<LI>a <I>nested-name-specifier</I> or <I>qualified-id</I> that
names a member of an unknown specialization.</LI>
</UL>

</BLOCKQUOTE>

</LI>

<LI>
<P>In 14.6.2.2&nbsp;



 <A HREF="template.html#temp.dep.expr">temp.dep.expr</A>, add the following
paragraph:</P>

<BLOCKQUOTE>

A class member access expression (5.2.5&nbsp;



 <A HREF="expr.html#expr.ref">expr.ref</A>) is
type-dependent if the type of the referenced member is dependent.
[<I>Note:</I> In an expression of the form <TT>x.y</TT> or
<TT>xp-&gt;y</TT> the type of the expression is usually the type
of the member <TT>y</TT> of the class of <TT>x</TT> (or the class
pointed to by <TT>xp</TT>).  However, if <TT>x</TT> or <TT>xp</TT>
refers to a dependent type that is not the current instantiation,
the type of <TT>y</TT> is always dependent.  If <TT>x</TT> or
<TT>xp</TT> refers to a non-dependent type or refers to the
current instantiation, the type of <TT>y</TT> is the type of the
class member access expression.]

</BLOCKQUOTE>

</LI>

<LI>
<P>In 14.6&nbsp;



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

<BLOCKQUOTE>

A <I>qualified-name</I> that refers to a type and that depends
on a <I>template-parameter</I> (14.6.2&nbsp;



 <A HREF="template.html#temp.dep">temp.dep</A>) shall
be prefixed by the keyword <TT>typename</TT>.

</BLOCKQUOTE>

<P>with</P>

<BLOCKQUOTE>

A <I>qualified-id</I> that refers to a type and that depends on
a <I>template-parameter</I> (14.6.2&nbsp;



 <A HREF="template.html#temp.dep">temp.dep</A>) but
does not refer to a member of the current instantiation shall be
prefixed by the keyword <TT>typename</TT>.

</BLOCKQUOTE>

</LI>

<LI>
<P>In 14.2&nbsp;



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

<BLOCKQUOTE>

When the name of a member template specialization appears after
<TT>.</TT> or <TT>-&gt;</TT> in a <I>postfix-expression</I>, or
after a <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.

</BLOCKQUOTE>

<P>with</P>

<BLOCKQUOTE>

When the name of a member template specialization appears after
<TT>.</TT> or <TT>-&gt;</TT> in a <I>postfix-expression</I>, or
after a <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>)
but does not refer to a member of the current instantiation
(14.6.2.1&nbsp;



 <A HREF="template.html#temp.dep.type">temp.dep.type</A>), the member template name must
be prefixed by the keyword <TT>template</TT>.  Otherwise the name
is assumed to name a non-template.

</BLOCKQUOTE>

</LI>

<LI>
<P>In 14.6.1&nbsp;



 <A HREF="template.html#temp.local">temp.local</A> paragraph 2, remove the
following text, which was added for <A HREF="
     cwg_defects.html#108">issue 108</A>.
The updated definition of dependent name now addresses this case.</P>

<BLOCKQUOTE>

<P>Within the scope of a class template, when the unqualified name of
a nested class of the class template is referred to, it is
equivalent to the name of the nested class qualified by the name
of the enclosing class template.  [<I>Example:</I>
</P>

<PRE>
template &lt;class T&gt; struct A {
	class B {};
	// B is equivalent to A::B, which is equivalent to A&lt;T&gt;::B,
	// which is dependent.
	class C : B { };
};
</PRE>

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

</BLOCKQUOTE>

</LI>

</OL>

<BR>
<BR>
<HR>
<A NAME="206"></A>
<H4>206.
  
Semantic constraints on non-dependent names
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>14.6.3&nbsp;



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

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

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

 <B>Date: </B>23 Feb 2000
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Spicer<BR>



<P>At what point are semantic constraints applied to uses of
non-dependent names in template definitions?  According to
14.6.3&nbsp;



 <A HREF="template.html#temp.nondep">temp.nondep</A>
, such names are looked up
and bound at the point at which they are used, i.e., the point of
definition and not the point of instantiation.  However, the text does
not mention the checking of semantic constraints.</P>

<P>Contrast this omission with the treatment of names in default
argument expressions given in
8.3.6&nbsp;



 <A HREF="decl.html#dcl.fct.default">dcl.fct.default</A>
 paragraph 5, where
the treatment of semantic constraints is explicit:</P>

<BLOCKQUOTE>
The names in the expression are bound, and the semantic constraints
are checked, at the point where the default argument expression
appears.
</BLOCKQUOTE>

The following code is an example of where this distinction matters:

<PRE>
    struct S;

    template &lt;class T&gt; struct Q {
        S s;    // incomplete type if semantic constraints
                // are applied in the definition context
    };

    struct S { };

    // Point of instantiation of Q&lt;int&gt;; S is complete here

    Q&lt;int&gt; si;        
</PRE>

There is real-world code that depends on late checking of semantic
constraints.  The Standard should be explicit about whether this code
is broken or not.

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

<P>In 14.6&nbsp;



 <A HREF="template.html#temp.res">temp.res</A> paragraph 7, add the following
immediately preceding the note:</P>

<BLOCKQUOTE>

If a type used in a non-dependent name is incomplete at the point at
which a template is defined but is complete at the point at which an
instantiation is done, and if the completeness of that type affects
whether or not the program is well-formed or affects the semantics of
the program, the program is ill-formed; no diagnostic is required.

</BLOCKQUOTE>

<BR>
<BR>
<HR>
<A NAME="22"></A>
<H4>22.
  
Template parameter with a default argument that refers to itself
</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>DR
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>unknown
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown<BR>




<P>(Previously numbered 933.)</P>


<P>14.1&nbsp;



 <A HREF="template.html#temp.param">temp.param</A>
 paragraph 13 says:</P>
<BLOCKQUOTE>The scope of a <I>template-parameter</I> extends from its point of
declaration until the end of its template. In particular, a <I>template-parameter</I>
can be used in the declaration of subsequent <I>template-parameter</I>s and their
default arguments.</BLOCKQUOTE>
Is the following well-formed?
<PRE>
    template&lt;class U = U&gt; class X { ... };
</PRE>

<P>
<I>[Note: this issue is resolved by the resolution of
<A HREF="
     cwg_defects.html#187">issue 187</A>.]</I>
</P>
<BR>
<BR>
<HR>
<A NAME="24"></A>
<H4>24.
  
Errors in examples in 14.7.3
</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>DR
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>unknown
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown<BR>




<P>(Previously numbered 935; revised by Robert Klarer.)</P>


<P>
<B>Problem Description:</B>
At least four of the examples in 14.7.3&nbsp;



 <A HREF="template.html#temp.expl.spec">temp.expl.spec</A>
 have errors. </P>

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

<P>1. Change the example in paragraph 8 from: </P>
<BLOCKQUOTE>
[<I>Example:</I>
<PRE>
    // <I>file #1 </I>
    #include &lt;vector&gt; 
    // <I>Primary class template</I> vector
    export template&lt;class T&gt; void f(t) { 
        vector&lt;T&gt; vec;         // <I>should match the specialization</I>
        /* ... */ 
    } 

    // <I>file #2 </I>
    #include &lt;vector&gt; 
    class B { }; 
    // <I>Explicit specialization of </I>vector<I> for </I>vector&lt;B&gt;
    template&lt;class T&gt; class vector&lt;B&gt; { /* ... */ } 
    template&lt;class T&gt; void f(T); 
    void g(B b) { 
        f(b);                   // <I>ill formed: </I>
                                // f&lt;B&gt; <I>should refer to </I>vector&lt;B&gt;<I>, but the </I>
                                // <I>specialization was not declared with the </I>
                                // <I>definition of </I>f<I> in file #1 </I>
    } 
</PRE>
<I>&mdash;end example</I>]
</BLOCKQUOTE>
to: 
<BLOCKQUOTE>
[<I>Example: </I>
<PRE>
    // <I>file #1 </I>
    #include &lt;vector&gt; 
    // <I>Primary class template</I> vector
    export template&lt;class T&gt; void f(T) { 
        std::vector&lt;T&gt; vec;     // <I>should match the specialization </I>
        /* ... */ 
    }; 

    // <I>file #2 </I>
    #include &lt;vector&gt; 
    class B { }; 
    // <I>Explicit specialization of </I>vector<I> for </I>vector&lt;B&gt;
    namespace std { 
        template&lt;&gt; class vector&lt;B&gt; { /* ... */ }; 
    } 
    template&lt;class T&gt; void f(T); 
    void g(B b) { 
        f(b);                   // <I>ill formed: </I>
                                // f&lt;B&gt; <I>should refer to </I>vector&lt;B&gt;<I>, but the </I>
                                // <I>specialization was not declared with the </I>
                                // <I>definition of </I>f<I> in file #1 </I>
    } 
</PRE>
    <I>&mdash;end example</I>] 
</BLOCKQUOTE>

<P>2. The example in paragraph 16 as it appears in the IS: </P>
<BLOCKQUOTE>
[<I>Example: </I>
<PRE>
    template&lt;class T&gt; struct A { 
        void f(T); 
        template&lt;class X&gt; void g(T, X); 
        void h(T) { } 
    }; 

    // <I>specialization </I>
    template&lt;&gt; void A&lt;int&gt;::f(int); 

    // <I>out of class member template definition </I>
    template&lt;class T&gt; template&lt;class X&gt; void A&lt;T&gt;::g(T,X) { } 

    // <I>member template partial specialization </I>
    template&lt;&gt; template&lt;class X&gt; void A&lt;int&gt;::g(int, X); 

    // <I>member template specialization </I>
    template&lt;&gt; template&lt;&gt; 
        void A&lt;int&gt;::g(int, char);        // X <I>deduced as</I> char
    template&lt;&gt; template&lt;&gt; 
        void A&lt;int&gt;::g&lt;char&gt;(int, char);  // X <I>specified as</I> char

    // <I>member specialization even if defined in class definition </I>
    template&lt;&gt; void A&lt;int&gt;::h(int) { } 
</PRE>
&mdash;<I>end example</I>] 
</BLOCKQUOTE>

The word 'partial' in the third comment in the example
should be removed because this example does not illustrate partial
specialization.  Also, the two specializations of <TT>template&lt;&gt;
template&lt;&gt; void A&lt;int&gt;::g(int, char);</TT> violate
14.7&nbsp;



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

<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.  An implementation is not required
to diagnose a violation of this rule.
</BLOCKQUOTE>

<B>Proposed resolution (10/99): </B>
<BLOCKQUOTE>
[<I>Example: </I>
<PRE>
    template&lt;class T&gt; struct A { 
        void f(T); 
        template&lt;class X1&gt; void g1(T, X1); 
        template&lt;class X2&gt; void g2(T, X2); 
        void h(T) { } 
    }; 

    // <I>specialization </I>
    template&lt;&gt; void A&lt;int&gt;::f(int); 

    // <I>out of class member template definition </I>
    template&lt;class T&gt; template&lt;class X1&gt; void A&lt;T&gt;::g1(T,X1) { } 

    // <I>member template specialization </I>
    template&lt;&gt; template&lt;class X1&gt; void A&lt;int&gt;::g1(int, X1); 

    // <I>member template specialization </I>
    template&lt;&gt; template&lt;&gt; 
        void A&lt;int&gt;::g1(int, char);        // X1 <I>deduced as</I> char 
    template&lt;&gt; template&lt;&gt; 
        void A&lt;int&gt;::g2&lt;char&gt;(int, char);  // X2 <I>specified as</I> char 

    // <I>member specialization even if defined in class definition </I>
    template&lt;&gt; void A&lt;int&gt;::h(int) { } 
</PRE>
&mdash;<I>end example</I>] 
</BLOCKQUOTE>

<P>3. Remove the spurious semicolon (or the curly brackets) from the
end of the last line in the example in paragraph 17.  This is the
example as it appears in the IS:</P>

<BLOCKQUOTE>
[<I>Example: </I>
<PRE>
    template&lt;class T1&gt; class A { 
        template&lt;class T2&gt; class B { 
            void mf(); 
        };
    };
    template&lt;&gt; template&lt;&gt; A&lt;int&gt;::B&lt;double&gt; { };
    template&lt;&gt; template&lt;&gt; void A&lt;char&gt;::B&lt;char&gt;::mf() {};
</PRE>
&mdash;<I>end example</I>]
</BLOCKQUOTE>

<B>Proposed resolution (10/99):</B>

<BLOCKQUOTE>
[<I>Example: </I>
<PRE>
    template&lt;class T1&gt; class A { 
        template&lt;class T2&gt; class B { 
            void mf(); 
        };
    };
    template&lt;&gt; template&lt;&gt; A&lt;int&gt;::B&lt;double&gt;;
    template&lt;&gt; template&lt;&gt; void A&lt;char&gt;::B&lt;char&gt;::mf();
</PRE>
&mdash;<I>end example</I>]
</BLOCKQUOTE>

<P>4. Remove spurious semicolons (or curly brackets) from the
specializations of <TT>mf1</TT> and <TT>mf2</TT> in the example in
paragraph 18.  This is the text of the example as it appears in the
IS:</P>

<BLOCKQUOTE>
[<I>Example: </I>
<PRE>
    template&lt;class T1&gt; class A { 
        template&lt;class T2&gt; class B { 
            template&lt;class T3&gt; void mf1(T3); 
            void mf2(); 
        }; 
    }; 
    template&lt;&gt; template&lt;class X&gt; 
        class A&lt;int&gt;::B { }; 
    template&lt;&gt; template&lt;&gt; template&lt;class T&gt; 
        void A&lt;int&gt;::B&lt;double&gt;::mf1(T t) { }; 
    template&lt;class Y&gt; template&lt;&gt; 
        void A&lt;Y&gt;::B&lt;double&gt;::mf2() { }; // <I>ill-formed; </I>B&lt;double&gt;<I> is specialized but </I>
                                         // <I>its enclosing class template </I>A<I> is not </I>
</PRE>
&mdash;<I>end example</I>] 
</BLOCKQUOTE>

<B>Proposed resolution (10/99):</B>
<BLOCKQUOTE>
[<I>Example: </I>
<PRE>
    template&lt;class T1&gt; class A { 
        template&lt;class T2&gt; class B { 
            template&lt;class T3&gt; void mf1(T3); 
            void mf2(); 
        }; 
    }; 
    template&lt;&gt; template&lt;class X&gt; 
        class A&lt;int&gt;::B { }; 
    template&lt;&gt; template&lt;&gt; template&lt;class T&gt; 
        void A&lt;int&gt;::B&lt;double&gt;::mf1(T t) { }
    template&lt;class Y&gt; template&lt;&gt; 
        void A&lt;Y&gt;::B&lt;double&gt;::mf2() { } // <I>ill-formed; </I>B&lt;double&gt;<I> is specialized but </I>
                                         // <I>its enclosing class template </I>A<I> is not </I>
</PRE>
&mdash;<I>end example</I>] 
</BLOCKQUOTE>
<BR>
<BR>
<HR>
<A NAME="44"></A>
<H4>44.
  
Member 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>DR
 &nbsp;&nbsp;&nbsp;

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

 <B>Date: </B>19 Sep 1998
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Spicer<BR>




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


<P>Some compilers reject the following:</P>
<PRE>
    struct A {
        template &lt;int I&gt; void f();
        template &lt;&gt; void f&lt;0&gt;();
    };
</PRE>
on the basis of 14.7.3&nbsp;



 <A HREF="template.html#temp.expl.spec">temp.expl.spec</A>

paragraph 2:
<BLOCKQUOTE>An explicit specialization shall be declared in the namespace
of which the template is a member, or, for member templates, in the namespace
of which the enclosing class or enclosing class template is a member. An
explicit specialization of a member function, member class or static data
member of a class template shall be declared in the namespace of which
the class template is a member. ...</BLOCKQUOTE>
claiming that the specialization above is not "in the namespace of which
the enclosing class ... is a member". Elsewhere, declarations are sometimes
required to be "at" or "in" "namespace scope", which is not what it says
here. Paragraph 17 says:
<BLOCKQUOTE>A member or a member template may be nested within many enclosing
class templates. If the declaration of an explicit specialization for such
a member appears in namespace scope, the member declaration shall be preceded
by a <TT>template&lt;&gt;</TT> for each
enclosing class template that is explicitly
specialized.</BLOCKQUOTE>
The qualification "if the declaration ... appears in namespace scope",
implies that it might appear elsewhere. The only other place I can think
of for a member specialization is in class scope.

<P>Was it the intent of the committee to forbid the construction above?
(Note that A itself is not a template.) If so, why?</P>

<P>
<B>Proposed resolution (04/01):</B> In-class specializations
of member templates are not allowed. In
14.7.3&nbsp;



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

<BLOCKQUOTE>
If the declaration of an explicit specialization for such a member
appears in namespace scope...
</BLOCKQUOTE>

with

<BLOCKQUOTE>
In an explicit specialization for such a member...
</BLOCKQUOTE>

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

<P>This issue was kept in "review" status for two major reasons:</P>

<OL>

<LI>It's not clear that a change is actually needed.  All uses of the
phrase "in the namespace" in the IS mean "directly in the namespace,"
not in a scope nested within the namespace.</LI>

<LI>There was substantial sentiment for actually adding support for
in-class specializations at a future time, and it might be perceived
as a reversal of direction to pass a change aimed at reinforcing the
absence of the feature, only to turn around afterward and add it.</LI>

</OL>

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

<P>The core working group felt that the value of additional
clarity here outweighs the potential disadvantages that were noted
at the preceding meeting.</P>

<BR>
<BR>
<HR>
<A NAME="64"></A>
<H4>64.
  
Partial ordering to disambiguate explicit specialization
</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>DR
 &nbsp;&nbsp;&nbsp;

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

 <B>Date: </B>13 Oct 1998
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Spicer<BR>



<P>Paragraph 12 should address partial ordering. It wasn't updated
when that change was made and conflicts with
14.5.5.2&nbsp;



 <A HREF="template.html#temp.func.order">temp.func.order</A>
 paragraph 1.</P>

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

<P>Remove
14.7.3&nbsp;



 <A HREF="template.html#temp.expl.spec">temp.expl.spec</A>
 paragraph 12 and the
example that follows.</P>
<BR>
<BR>
<HR>
<A NAME="241"></A>
<H4>241.
  
Error in example in 14.8.1
</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>DR
 &nbsp;&nbsp;&nbsp;

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

 <B>Date: </B>9 Aug 2000<BR>


<P>14.8.1&nbsp;



 <A HREF="template.html#temp.arg.explicit">temp.arg.explicit</A> paragraph 6 contains the following
example:</P>

<PRE>
    namespace A {
        struct B { };
        template&lt;int X&gt; void f();
    }
    namespace C {
        template&lt;class T&gt; void f(T t);
    }
    void g(A::B b) {
        f&lt;3&gt;(b);    // ill-formed: not a function call
        A::f&lt;3&gt;(b); // well-formed
        C::f&lt;3&gt;(b); // ill-formed; argument dependent lookup
                    // only applies to unqualified names
        using C::f;
        f&lt;3&gt;(b);    // well-formed because C::f is visible; then
                    // A::f is found by argument dependent lookup
    }
</PRE>

<P>
<TT>A::f()</TT> should have a parameter of type <TT>A::B</TT>.</P>

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

<P>In the example in 14.8.1&nbsp;



 <A HREF="template.html#temp.arg.explicit">temp.arg.explicit</A> paragraph 6,
change the third line from</P>

<PRE>
        template &lt;int X&gt; void f();
</PRE>

<P>to</P>

<PRE>
        template &lt;int X&gt; void f(B);
</PRE>

<BR>
<BR>
<HR>
<A NAME="70"></A>
<H4>70.
  
Is an array bound a nondeduced context?
</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>DR
 &nbsp;&nbsp;&nbsp;

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

 <B>Date: </B>29 Sep 1998
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Spicer<BR>



<P>Paragraph 4 lists contexts in which template formals are not deduced.
Were template formals in an expression in the array bound of an array type
specification intentionally left out of this list? Or was the intent
that such formals always be explicitly specified? Otherwise I believe the
following should be valid:</P>
<PRE>
    template &lt;int I&gt; class IntArr {};

    template &lt;int I, int J&gt;
    void concat( int (&amp;d)[I+J], const IntArr&lt;I&gt;&amp; a, const IntArr&lt;J&gt;&amp; b ) {}

    int testing()
    {
        IntArr&lt;2&gt; a;
        IntArr&lt;3&gt; b;
        int d[5];

        concat( d, a, b );
    }
</PRE>
Can anybody shed some light on this?

<P>
<U>From John Spicer:</U>
</P>

<P>Expressions involving nontype template parameters are nondeduced
contexts, even though they are omitted from the list in
14.8.2.4&nbsp;



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



 <A HREF="template.html#temp.deduct.type">temp.deduct.type</A>
 paragraphs
12-14:</P>

<OL START="12">
<LI>
A template type argument cannot be deduced from the type of a non-type
<I>template-argument</I>.
<P>&nbsp;...</P>
</LI>
</OL>
<OL START="14">
<LI>
If, in the declaration of a function template with
a non-type <I>template-parameter</I>, the non-type <I>template-parameter</I>
is used in an expression in the function parameter-list, the corresponding
<I>template-argument</I> must always be explicitly specified or deduced
elsewhere because type deduction would otherwise always
fail for such a <I>template-argument</I>.</LI>
</OL>

<P>
<B>Proposed resolution (04/01):</B> In
14.8.2.4&nbsp;



 <A HREF="template.html#temp.deduct.type">temp.deduct.type</A>
 paragraph 4, add a
third bullet:</P>

<UL>
<LI>
An array bound that is an expression that references a
<I>template-parameter</I>
</LI>
</UL>
<BR>
<BR>
<HR>
<A NAME="181"></A>
<H4>181.
  
Errors in template <I>template-parameter</I> example
</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>DR
 &nbsp;&nbsp;&nbsp;

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

 <B>Date: </B>4 Nov 1999<BR>




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


<P>14.8.2.4&nbsp;



 <A HREF="template.html#temp.deduct.type">temp.deduct.type</A>
 paragraph 18 uses
incorrect syntax.  Instead of</P>

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

it should be

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

<P>
<B>Proposed resolution (10/00):</B> As suggested.</P>
<BR>
<BR>
<HR>
<A NAME="98"></A>
<H4>98.
  
Branching into try block
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>15&nbsp;



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

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

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

 <B>Date: </B>23 Feb 1999
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Vandevoorde<BR>



<P>At the top of clause 15, in paragraph 2, it says:</P>
<BLOCKQUOTE>
A <TT>goto</TT>, <TT>break</TT>, <TT>return</TT>, or <TT>continue</TT> statement can be used to transfer
control out of a try block or handler, but not into one.
</BLOCKQUOTE>
What about <TT>switch</TT> statements?
<PRE>
    switch ( f() )
    {
    case 1:
         try {
             g();
    case 2:
             h();
         }
         catch (...)
         {
             // handler
         }
    break;
    }
</PRE>

<B>Daveed Vandevoorde:</B>

(core-8045)

<P>Consider:</P>
<PRE>
    void f() {
        try {
        label:
            ;
        } catch(...) {
            goto label;
        }
    }
</PRE>

Now the phrase "try block" (without a hyphen) is used in paragraph
1 in a way that causes me to think that it is not intended to
include the corresponding handlers. On the other hand, the grammar
entity "<I>try-block</I>" (with hyphen) does include the handlers.

So is the intent to prohibit the above or not?

<P>
<B>Proposed resolution (10/00:</B>
</P>

<P>Change text in 15&nbsp;



 <A HREF="except.html#except">except</A> paragraph 2 from:</P>

<BLOCKQUOTE>A <TT>goto</TT>, <TT>break</TT>, <TT>return</TT>, or
<TT>continue</TT> statement
can be used to transfer control out of a try block or handler, but not
into one.
</BLOCKQUOTE>
to:
<BLOCKQUOTE>
A <TT>goto</TT> or <TT>switch</TT> statement shall not be used
to transfer control into a try block or into a handler.
<BR>[ <I>Example:</I>
<BLOCKQUOTE>
<TT>void f() {</TT>
<BR>
<TT>&nbsp; goto l1;&nbsp; // Ill-formed</TT>
<BR>
<TT>&nbsp; goto l2;&nbsp; // Ill-formed</TT>
<BR>
<TT>&nbsp; try {</TT>
<BR>
<TT>&nbsp;&nbsp;&nbsp; goto l1;&nbsp; // OK</TT>
<BR>
<TT>&nbsp;&nbsp;&nbsp; goto l2;&nbsp; // Ill-formed</TT>
<BR>
<TT>&nbsp;&nbsp;&nbsp; l1: ;</TT>
<BR>
<TT>&nbsp; } catch (...) {</TT>
<BR>
<TT>&nbsp;&nbsp;&nbsp; l2: ;</TT>
<BR>
<TT>&nbsp;&nbsp;&nbsp; goto l1;&nbsp; // Ill-formed</TT>
<BR>
<TT>&nbsp;&nbsp;&nbsp; goto l2;&nbsp; // OK</TT>
<BR>
<TT>&nbsp; }</TT>
<BR>
<TT>}</TT>
</BLOCKQUOTE>
&mdash;<I>end example</I> ]
<BR>A <TT>goto</TT>, <TT>break</TT>, <TT>return</TT>, or <TT>continue</TT>
statement can be used to transfer control out of a try block or handler.
</BLOCKQUOTE>

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

<BR>
<BR>
<HR>
<A NAME="208"></A>
<H4>208.
  
Rethrowing exceptions in nested handlers
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>15.1&nbsp;



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

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

 <B>Submitter: </B>Bill Wade
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>28 Feb 2000
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Merrill<BR>



<P>Paragraph 7 of 15.1&nbsp;



 <A HREF="except.html#except.throw">except.throw</A> discusses which exception
is thrown by a <I>throw-expression</I> with no operand.</P>

<P>May an expression which has been "finished" (paragraph 7) by an
inner catch block be rethrown by an outer catch block?</P>

<PRE>
    catch(...)    // Catch the original exception
    {
      try{ throw; }    // rethrow it at an inner level
                       // (in reality this is probably
                       // inside a function)
      catch (...)
      {
      }   // Here, an exception (the original object)
          // is "finished" according to 15.1p7 wording

      // 15.1p7 says that only an unfinished exception
      // may be rethrown.
      throw;    // Can we throw it again anyway?  It is
                // certainly still alive (15.1p4).
    }
</PRE>

<P>I believe this is ok, since the paragraph says that the exception
is finished when the "corresponding" catch clause exits.  However
since we have two clauses, and only one exception, it would seem that
the one exception gets "finished" twice.</P>

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

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



 <A HREF="except.html#except.throw">except.throw</A> paragraph 4, change

<BLOCKQUOTE>

When the last handler being executed for the exception exits by any
means other than <TT>throw;</TT> ...

</BLOCKQUOTE>

to

<BLOCKQUOTE>

When the last remaining active handler for the exception exits by any
means other than <TT>throw;</TT> ...

</BLOCKQUOTE>
</P>
</LI>

<LI>
<P>In 15.1&nbsp;



 <A HREF="except.html#except.throw">except.throw</A> paragraph 6, change

<BLOCKQUOTE>

A <I>throw-expression</I> with no operand rethrows the exception being
handled.

</BLOCKQUOTE>

to

<BLOCKQUOTE>

A <I>throw-expression</I> with no operand rethrows the currently
handled exception (15.3&nbsp;



 <A HREF="except.html#except.handle">except.handle</A>).

</BLOCKQUOTE>
</P>
</LI>

<LI>
<P>Delete 15.1&nbsp;



 <A HREF="except.html#except.throw">except.throw</A> paragraph 7.</P>
</LI>

<LI>
<P>Add the following before 15.1&nbsp;



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

<BLOCKQUOTE>

An exception is considered caught when a handler for that exception
becomes active (15.3&nbsp;



 <A HREF="except.html#except.handle">except.handle</A>).  [<I>Note:</I> an
exception can have active handlers and still be considered uncaught if
it is rethrown.]

</BLOCKQUOTE>
</P>
</LI>

<LI>
<P>Change 15.3&nbsp;



 <A HREF="except.html#except.handle">except.handle</A> paragraph 8 from

<BLOCKQUOTE>

An exception is considered handled upon entry to a handler.
[<I>Note:</I> the stack will have been unwound at that point.]

</BLOCKQUOTE>

to

<BLOCKQUOTE>

<P>A handler is considered active when initialization is complete for
the formal parameter (if any) of the catch clause.  [<I>Note:</I> the
stack will have been unwound at that point.]  Also, an implicit
handler is considered active when <TT>std::terminate()</TT> or
<TT>std::unexpected()</TT> is entered due to a throw.  A handler is no
longer considered active when the catch clause exits or when
<TT>std::unexpected()</TT> exits after being entered due to a throw.</P>

<P>The exception with the most recently activated handler that is
still active is called the <I>currently handled exception</I>.</P>

</BLOCKQUOTE>
</P>
</LI>

<LI>
<P>In 15.3&nbsp;



 <A HREF="except.html#except.handle">except.handle</A> paragraph 16, change "exception
being handled" to "currently handled exception."
</P>
</LI>
</OL>

<BR>
<BR>
<HR>
<A NAME="210"></A>
<H4>210.
  
What is the type matched by an exception handler?
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>15.3&nbsp;



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

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

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

 <B>Date: </B>6 Mar 2000
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Merrill<BR>



<P>15.3&nbsp;



 <A HREF="except.html#except.handle">except.handle</A> paragraph 3 says,</P>

<BLOCKQUOTE>

A <I>handler</I> is a match for a <I>throw-expression</I> with an
object of type <TT>E</TT>...

</BLOCKQUOTE>

<P>This wording leaves it unclear whether it is the dynamic type of the
object being thrown or the static type of the expression that
determines whether a handler is a match for a given exception.  For
instance,</P>

<PRE>
    struct B { B(); virtual ~B(); };
    struct D : B { D(); };
    void toss(const B* b) { throw *b; }
    void f() { const D d; toss(&amp;d); }
</PRE>

<P>In this code, presumably the type to be matched is <TT>B</TT> and not
<TT>const D</TT> (15.1&nbsp;



 <A HREF="except.html#except.throw">except.throw</A>).</P>

<P>
<B>Suggested resolution:</B> Replace the cited wording as follows:</P>

<BLOCKQUOTE>

A <I>handler</I> is a match for a <I>throw-expression</I> which
initialized a temporary (15.1&nbsp;



 <A HREF="except.html#except.throw">except.throw</A>) of type
<TT>E</TT>...

</BLOCKQUOTE>

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

<OL>

<LI>
<P>Change 15.1&nbsp;



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

<BLOCKQUOTE>

A <I>throw-expression</I> initializes a temporary object, the type of
which is determined...

</BLOCKQUOTE>

<P>to</P>

<BLOCKQUOTE>

A <I>throw-expression</I> initializes a temporary object, called the
<I>exception object</I>, the type of which is determined...

</BLOCKQUOTE>
</LI>

<LI>
<P>Change 15.3&nbsp;



 <A HREF="except.html#except.handle">except.handle</A> paragraph 3 from</P>

<BLOCKQUOTE>

A <I>handler</I> is a match for a <I>throw-expression</I> with an
object of type <TT>E</TT> if...

</BLOCKQUOTE>

<P>to</P>

<BLOCKQUOTE>

A <I>handler</I> is a match for an exception object of type <TT>E</TT>
if...

</BLOCKQUOTE>
</LI>
</OL>

<BR>
<BR>
<HR>
<A NAME="25"></A>
<H4>25.
  
Exception specifications and pointers to members
</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>DR
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>unknown
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown<BR>




<P>(Previously numbered 936.)</P>


<P>15.4&nbsp;



 <A HREF="except.html#except.spec">except.spec</A>
 paragraph 3 should say what
happens when two pointers to members with
different exception specifications are assigned to each other, initialized
with one another, etc.</P>

<P>
<B>Proposed Resolution (04/99):</B>
Change the text in 15.4&nbsp;



 <A HREF="except.html#except.spec">except.spec</A>
 paragraph 3 from:</P>
<BLOCKQUOTE>Similarly, any function or pointer to function assigned to,
or initializing, a pointer to function shall only allow exceptions that
are allowed by the pointer or function being assigned to or initialized.</BLOCKQUOTE>
to:
<BLOCKQUOTE>A similar restriction applies to assignment to and initialization
of pointers to functions, pointers to member functions, and references
to functions: the target entity shall allow at least the exceptions allowed
by the source value in the assignment or initialization.</BLOCKQUOTE>
<BR>
<BR>
<HR>
<A NAME="87"></A>
<H4>87.
  
Exception specifications on function parameters
</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>DR
 &nbsp;&nbsp;&nbsp;

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

 <B>Date: </B>25 Jan 1999
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Vandevoorde<BR>



<P>In
15.4&nbsp;



 <A HREF="except.html#except.spec">except.spec</A>

paragraph 2:</P>
<BLOCKQUOTE>An exception-specification shall appear only on a function
declarator in a function, pointer, reference or pointer to member declaration
or definition.</BLOCKQUOTE>
Does that mean in the top-level function declarator, or one at any level?
Can one, for example, specify an exception specification on a pointer-to-function
parameter of a function?
<PRE>
    void f(int (*pf)(float) throw(A))
</PRE>
Suggested answer: no. The exception specifications are valid only on the
top-level function declarators.
    
<P>However, if exception specifications are made part of a function's type
as has been tentatively agreed, they would have to be allowed on any function
declaration. </P>

<P>There is already an example
of an exception specification for a parameter in the example in
15.4&nbsp;



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

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

Change text in 15.4&nbsp;



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

<BLOCKQUOTE>An <I>exception-specification</I> shall appear only on
a function declarator in a function, pointer, reference or pointer to member
declaration or definition.</BLOCKQUOTE>
to:
<BLOCKQUOTE>

An <I>exception-specification</I> shall appear only on a function
declarator for a function type, pointer to function type, reference to
function type, or pointer to member function type that is the
top-level type of a declaration or definition, or on such a type
appearing as a parameter or return type in a function declarator.

</BLOCKQUOTE>
<P>(See also issues <A HREF="
     cwg_defects.html#25">25</A>,
<A HREF="
     cwg_active.html#92">92</A>, and
<A HREF="
     cwg_closed.html#133">133</A>.)</P>
<BR>
<BR>
<HR>
<A NAME="126"></A>
<H4>126.
  
Exception specifications and <TT>const</TT>
</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>DR
 &nbsp;&nbsp;&nbsp;

 <B>Submitter: </B>Martin von Loewis
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>8 June 1999
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Miller<BR>



<P>The standard is inconsistent about constness inside exception
specifications.</P>

<PRE>
    struct X {};
    struct Y:X {};

    const Y bar() {return Y();}

    void foo()throw(const X)
    {
      throw bar();
    }
</PRE>

It is unclear whether calling <TT>foo</TT> will result in a call
to <TT>std::unexpected</TT>.  According to
15.4&nbsp;



 <A HREF="except.html#except.spec">except.spec</A>
 paragraph 7,
only two cases are treated
specially with regard to inheritance: If "class X" appears in the
<I>type-id-list</I>, or if "class X*" appears in the
<I>type-id-list</I>. Neither is
the case here, so <TT>foo</TT> only allows exceptions of the same type
(<TT>const X</TT>). As a result, <TT>std::unexpected</TT> should be called.

<P>On the other hand, the intent of exception specification appears to
allow an implementation of this example as</P>

<PRE>
    void foo()
    try{
      throw bar();
    }catch(const X){
      throw;
    }catch(...){
      std::unexpected();
    }
</PRE>

According to
15.3&nbsp;



 <A HREF="except.html#except.handle">except.handle</A>
,
this replacement code would catch the exception, so
<TT>std::unexpected</TT> would not be called.

<P>Suggested resolution: Change
15.4&nbsp;



 <A HREF="except.html#except.spec">except.spec</A>
 paragraph 7 to read</P>

<BLOCKQUOTE>
A function is said to <I>allow</I> all exception objects of all
types <TT>E</TT> for which one of the types <TT>T</TT>
in the <I>type-id-list</I> would be a handler, according to
15.3&nbsp;



 <A HREF="except.html#except.handle">except.handle</A>
.
</BLOCKQUOTE>

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

<P>Replace 15.4&nbsp;



 <A HREF="except.html#except.spec">except.spec</A> paragraph 7 with the
following:</P>

<BLOCKQUOTE>

A function is said to <I>allow</I> an exception of type <TT>E</TT> if
its <I>exception-specification</I> contains a type <TT>T</TT> for
which a handler of type <TT>T</TT> would be a match (15.3&nbsp;



 <A HREF="except.html#except.handle">except.handle</A>) for an exception of type <TT>E</TT>.

</BLOCKQUOTE>
<BR>
<BR>
<HR>
<A NAME="145"></A>
<H4>145.
  
Deprecation of prefix <TT>++</TT>
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>D.1&nbsp;



 <A HREF="future.html#depr.post.incr">depr.post.incr</A>
 &nbsp;&nbsp;&nbsp;

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

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

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



<P>D.1&nbsp;



 <A HREF="future.html#depr.post.incr">depr.post.incr</A>

indicates that use of the postfix <TT>++</TT> with a <TT>bool</TT>
operand is
deprecated.
Annex D&nbsp;



 <A HREF="future.html#depr">depr</A>

says nothing about prefix <TT>++</TT>.  However, this
use of prefix <TT>++</TT> is also deprecated, according to
5.3.2&nbsp;



 <A HREF="expr.html#expr.pre.incr">expr.pre.incr</A>
 paragraph 1.
Presumably D.1&nbsp;



 <A HREF="future.html#depr.post.incr">depr.post.incr</A>

should be expanded to cover prefix <TT>++</TT>, or another
section should be added to Annex
D&nbsp;



 <A HREF="future.html#depr">depr</A>.</P>

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

<P>Change the entire section
D.1&nbsp;



 <A HREF="future.html#depr.post.incr">depr.post.incr</A>, including its heading, to read as
follows:</P>

<BLOCKQUOTE>

<TABLE CELLSPACING="0" CELLPADDING="0" FRAME="VOID" RULES="NONE" WIDTH="85%">
 <TR>
  <TD>
   <B>D.1 Increment operator with <TT>bool</TT> operand</B>
  </TD>
  <TD ALIGN="RIGHT">
   <B>[depr.incr.bool]</B>
  </TD>
 </TR>
</TABLE>

<P>The use of an operand of type <TT>bool</TT> with the <TT>++</TT>
operator is deprecated (see 5.3.2&nbsp;



 <A HREF="expr.html#expr.pre.incr">expr.pre.incr</A> and
5.2.6&nbsp;



 <A HREF="expr.html#expr.post.incr">expr.post.incr</A>).</P>

</BLOCKQUOTE>
<BR>
<BR>
<HR>
<A NAME="131"></A>
<H4>131.
  
Typo in Lao 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>DR
 &nbsp;&nbsp;&nbsp;

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

 <B>Date: </B>23 June 1999<BR>




<P>From reflector messages 8147 and 8153.</P>


<P>The Lao character 0e0d should be 0e8d.  0e0d is both out of order
and already used in the Thai characters.</P>

<P>
<B>Proposed resolution (10/99):</B> As suggested.</P>
<BR>
<BR>
<HR>
<A NAME="106"></A>
<H4>106.
  
Creating references to references during template deduction/instantiation
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>unknown&nbsp;



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

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

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

 <B>Date: </B>unknown
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Adamczyk/Unruh<BR>



<P>The main defect is in the library, where the binder template can
easily lead to reference-to-reference situations.</P>

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

<OL>

<LI>
Add the following as paragraph 6 of 7.1.3&nbsp;



 <A HREF="dcl.html#dcl.typedef">dcl.typedef</A>:

<BLOCKQUOTE>

<P>If a typedef <TT>TD</TT> names a type "reference to
<I>cv1</I> <TT>S</TT>," an attempt to create the type
"reference to <I>cv2</I> <TT>TD</TT>" creates the type
"reference to <I>cv12"</I> <TT>S</TT>," where <I>cv12</I> is the
union of the cv-qualifiers <I>cv1</I> and <I>cv2</I>.
Redundant qualifiers are ignored.  [<I>Example:</I>
</P>

<PRE>
    int i;
    typedef int&amp; RI;
    RI&amp; r = i;          // r <I>has the type</I> int&amp;
    const RI&amp; r = i;    // r <I>has the type</I> const int&amp;
</PRE>

&mdash;<I>end example</I>]
</BLOCKQUOTE>
</LI>

<LI>
Add the following as paragraph 4 of 14.3.1&nbsp;



 <A HREF="template.html#temp.arg.type">temp.arg.type</A>:

<BLOCKQUOTE>

<P>If a <I>template-argument</I> for a <I>template-parameter</I>
<TT>T</TT> names a type "reference to <I>cv1</I> <TT>S</TT>,"
an attempt to create the type "reference to <I>cv2</I> <TT>T</TT>"
creates the type "reference to <I>cv12</I> <TT>S</TT>," where
<I>cv12</I> is the union of the cv-qualifiers <I>cv1</I> and
<I>cv2</I>.  Redundant cv-qualifiers are ignored.
[<I>Example:</I>
</P>

<PRE>
    template &lt;class T&gt; class X {
        f(const T&amp;);
        /* ... */
    };
    X&lt;int&amp;&gt; x;    // X&lt;int&amp;&gt;::f <I>has the parameter type</I> const int&amp;
</PRE>

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

</BLOCKQUOTE>
</LI>

<LI>In 14.8.2&nbsp;



 <A HREF="template.html#temp.deduct">temp.deduct</A> paragraph 2 bullet 3 sub-bullet
5, remove the indicated text:

<BLOCKQUOTE>

Attempting to create <S>a reference to a reference type or</S> a
reference to <TT>void</TT>.

</BLOCKQUOTE>
</LI>
</OL>

<P>(See also paper J16/00-0022 = WG21 N1245.)</P>

<BR>
<BR>
<BR>
<BR>
</BODY>
</HTML>
