<HTML>
<HEAD>
<TITLE>



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



     C++ Standard Core Language
     
       Closed Issues,
      



     Revision
     46</H2>
</CENTER>
<BR>
<P>
      This document contains the C++ core language issues for which the
      Committee (J16 + WG21) has decided that no action is required,
      that is, issues with status
      "<A HREF="#NAD Status">NAD</A>" ("Not A Defect"),
      "<A HREF="#Dup Status">dup</A>" (duplicate), and
      "<A HREF="#Extension Status">extension</A>."
     </P>
<P>
    This document is part of a group of related documents that
    together describe the issues that have been raised regarding the
    C++ Standard.  The other documents in the group are:
   </P>
<UL>
<LI>
<A HREF="cwg_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_defects.html">Defect Reports List</A>, which contains
      the issues that have been categorized by the Committee as Defect
      Reports, along with their proposed resolutions.
     </LI>
<LI>
<A HREF="cwg_toc.html">Table of Contents</A>, which contains a
     summary listing of all issues in numerical order.
    </LI>
<LI>
<A HREF="cwg_index.html">Index by Section</A>, which contains a
     summary listing of all issues arranged in the order of the
     sections of the Standard with which they deal most directly.
    </LI>
<LI>
<A HREF="cwg_status.html">Index by Status</A>, which contains a
     summary listing of all issues grouped by status.
    </LI>
</UL>
<P>
     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>
<HR>
<A NAME="NAD Status"></A>
<H3>Issues with "NAD" Status</H3>
<HR>
<A NAME="449"></A>
<H4>449.
  
Consistency in use of hyphen with names of "non" entities
</H4>
<B>Section: </B>1.3&nbsp;



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

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

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

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


<P>The standard is inconsistent in its use of a hyphen on the
following:
nontype vs. non-type,
non-dependent vs. nondependent,
non-deduced vs. nondeduced, and
non-template vs. nontemplate.
We should pick a preferred form.</P>

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

<P>If this isn't a purely editorial issue, nothing is.  We're referring this
to the editor. We prefer the hyphenated forms.</P>

<BR>
<BR>
<HR>
<A NAME="50"></A>
<H4>50.
  
Converting pointer to incomplete type to same type
</H4>
<B>Section: </B>3.2&nbsp;



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

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

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

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



<P>In 3.2&nbsp;



 <A HREF="basic.html#basic.def.odr">basic.def.odr</A>
 paragraph 4
bullet 4, it's presumably the case that a conversion to <TT>T*</TT>
requires that <TT>T</TT> be complete only if the conversion is from a different
type. One could argue that there is no conversion (and therefore
the text is accurate as it stands) if a cast does not change the type of
the expression, but it's probably better to be more explicit here.</P>

<P>On the other hand, this text is non-normative (it's in a note).</P>

<P>
<B>Rationale (04/99):</B>
The relevant normative text makes this clear.  Implicit conversion
and <TT>static_cast</TT> are defined (in
4&nbsp;



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



 <A HREF="expr.html#expr.static.cast">expr.static.cast</A>
,
respectively) as equivalent to declaration with initialization, which
permits pointers to incomplete types, and <TT>dynamic_cast</TT>
(5.2.7&nbsp;



 <A HREF="expr.html#expr.dynamic.cast">expr.dynamic.cast</A>
) explicitly
prohibits pointers to incomplete types.</P>
<BR>
<BR>
<HR>
<A NAME="42"></A>
<H4>42.
  
Redefining names from base classes
</H4>
<B>Section: </B>3.3.6&nbsp;



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

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

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

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





<P>Consider this code:</P>
<PRE>
    struct Base {
        enum { a, b, c, next };
    };

    struct Derived : public Base {
        enum { d = Base::next, e, f, next };
    };

</PRE>
The idea is that the enumerator "next" in each class is the next available
value for enumerators in further derived classes.

<P>If we had written</P>
<PRE>
    enum { d = next, e, f, next };

</PRE>
I think we would run afoul of 3.3.6&nbsp;



 <A HREF="basic.html#basic.scope.class">basic.scope.class</A>
:
<BLOCKQUOTE>A name <TT>N</TT> used in a class <TT>S</TT> shall refer to
the same declaration in its context and when re-evaluated in the completed
scope of <TT>S</TT>. No diagnostic is required for a violation of this
rule.</BLOCKQUOTE>
But in the original code, we don't have an unqualified "next" that refers
to anything but the current scope. I think the intent was to allow the
code, but I don't find the wording clear on on that point.

<P>Is there another section that makes it clear whether the original code
is valid? Or am I being obtuse? Or should the quoted section say "An unqualified
name N used in a class ..."?</P>

<P>
<B>Rationale (04/99):</B> It is sufficiently clear that "name"
includes qualified names and hence the usual lookup rules make this
legal.</P>
<BR>
<BR>
<HR>
<A NAME="231"></A>
<H4>231.
  
Visibility of names after <I>using-directive</I>s
</H4>
<B>Section: </B>3.4.1&nbsp;



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

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

 <B>Submitter: </B>J&ouml;rg Barfurth
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>31 May 2000<BR>


<P>The wording of 3.4.1&nbsp;



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

<BLOCKQUOTE>

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



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

</BLOCKQUOTE>

<P>According to 7.3.4&nbsp;



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

<BLOCKQUOTE>

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

</BLOCKQUOTE>

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

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

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



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

<BLOCKQUOTE>

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

</BLOCKQUOTE>

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

<P>After a lot of discussion of possible wording changes, we decided
the wording should be left alone.  3.4.1&nbsp;



 <A HREF="basic.html#basic.lookup.unqual">basic.lookup.unqual</A>
paragraph 2 is not intended to be a full specification; that's in
7.3.4&nbsp;



 <A HREF="dcl.html#namespace.udir">namespace.udir</A> paragraph 1.  See also
3.3.5&nbsp;



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

<BR>
<BR>
<HR>
<A NAME="91"></A>
<H4>91.
  
A union's associated types should include the union itself
</H4>
<B>Section: </B>3.4.2&nbsp;



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

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

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

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





<P>When a union is used in argument-dependent lookup, the union's type
is not an associated class type. Consequently, code like this will fail
to work.</P>
<PRE>
    union U {
        friend void f(U);
    };
    
    int main() {
        U u;
        f(u);  // error: no matching f &mdash; U is not an associated class
    }
</PRE>
Is this an error in the description of unions in argument-dependent lookup?

<P>Also, this section is written as if unions were distinct from classes.
So adding unions to the "associated classes" requires either rewriting
the section so that "associated classes" can include unions, or changing
the term to be more inclusive, e.g. "associated classes and unions" or
"associated types".</P>

<P>
<U>Jason Merrill</U>: Perhaps in both cases, the standard text was intended
to only apply to anonymous unions.</P>

<P>
<U>Liam Fitzpatrick</U>: One cannot create expressions of an
anonymous union type.</P>

<P>
<B>Rationale (04/99):</B> Unions are class types, so the example is
well-formed. Although the wording here could be improved, it does not rise
to the level of a defect in the Standard.</P>
<BR>
<BR>
<HR>
<A NAME="384"></A>
<H4>384.
  
Argument-dependent lookup and operator functions
</H4>
<B>Section: </B>3.4.2&nbsp;



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

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

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

 <B>Date: </B>18 Sept 2002<BR>




<P>I believe the following code example should unambiguously call the
member operator+. Am I right?</P>
<PRE>
  //--- some library header ---
  //
  namespace N1 {
    template&lt;class T&gt; struct Base { };

    template&lt;class T&gt; struct X {
      struct Y : public Base&lt;T&gt; {     // here's a member operator+
        Y operator+( int _Off ) const { return Y(); }
      };

      Y f( unsigned i ) { return Y() + i; } // the "+" in question
    };
  }

  //--- some user code ---
  //
  namespace N2 {
    struct Z { };

    template&lt;typename T&gt;              // here's another operator+
    int* operator+( T , unsigned ) { static int i ; return &amp;i ; }
  }

  int main() {
    N1::X&lt; N2::Z &gt; v;
    v.f( 0 );
  }
</PRE>
<P>My expectation is that 3.4.2&nbsp;



 <A HREF="basic.html#basic.lookup.argdep">basic.lookup.argdep</A>
 would govern, specifically:
<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>
So I think the member should hide the otherwise-better-matching one in
the associated namespace. Here's what compilers do:</P>

<P>  Agree with me and call the member operator+:
    Borland 5.5, Comeau 4.3.0.1, EDG 3.0.1, Metrowerks 8.0, MSVC 6.0</P>

<P>  Disagree with me and try to call N2::operator+:
    gcc 2.95.3, 3.1.1, and 3.2; MSVC 7.0</P>

<P>Simple so far, but someone tells me that 13.3.1.2&nbsp;



 <A HREF="over.html#over.match.oper">over.match.oper</A>
muddies the waters.
There, paragraph 10 summarizes that subclause:
<BLOCKQUOTE>
  [Note: the lookup rules for operators in expressions are
  different than the lookup rules for operator function names
  in a function call, ...
</BLOCKQUOTE>
In particular, consider the above call to "Y() + unsigned" and please
help me step through 13.3.1.2&nbsp;



 <A HREF="over.html#over.match.oper">over.match.oper</A> paragraph 3:
<BLOCKQUOTE>
  ... for a binary operator @ with a left operand of a type whose
  cv-unqualified version is T1 and a right operand of a type
  whose cv-unqualified version is T2,
</BLOCKQUOTE>
OK so far, here @ is +, and T1 is N1::X::Y.
<BLOCKQUOTE>
  three sets of candidate functions, designated member candidates,
  non-member candidates and built-in candidates, are constructed
  as follows:
</BLOCKQUOTE>
[and later are union'd together to get the candidate list]
<BLOCKQUOTE>
  If T1 is a class type, the set of member candidates is the result
  of the qualified lookup of T1::operator@ (over.call.func);
  otherwise, the set of member candidates is empty.
</BLOCKQUOTE>
So there is one member candidate, N1::X::Y::operator+.
<BLOCKQUOTE>
  The set of non-member candidates is the result of the unqualified
  lookup of operator@ in the context of the expression according to
  the usual rules for name lookup in unqualified function calls
  (basic.lookup.argdep) except that all member functions are ignored.
</BLOCKQUOTE>
</P>

<P>*** This is the question: What does that last phrase mean? Does it mean:</P>

<P>a) first apply the usual ADL rules to generate a candidate list, then
ignore any member functions in that list (this is what I believe and
hope it means, and in particular it means that the presence of a member
will suppress names that ADL would otherwise find in the associated
namespaces); or</P>

<P>b) something else?</P>

<P>In short, does N2::operator+ make it into the candidate list? I think it
shouldn't. Am I right?</P>

<P>
<U>John Spicer</U>:
I believe that the answer is sort-of "a" above.  More specifically, the
unqualified lookup consists of a "normal" unqualified lookup and ADL.
ADL always deals with only namespace members, so the "ignore members
functions" part must affect the normal lookup, which should ignore class
members when searching for an operator.</P>

<P>I suspect that the difference between compilers may have to do with details
of argument-dependent lookup.  In the example given, the argument types
are "N1::X&lt;N2::Z&gt;::Y" and "unsigned int".  In order for N2::operator+ to
be a candidate, N2 must be an associated namespace.</P>

<P>N1::X&lt;N2::Z&gt;::Y is a class type, so
3.4.2&nbsp;



 <A HREF="basic.html#basic.lookup.argdep">basic.lookup.argdep</A> says that its associated classes are
its direct and indirect base classes, and its namespaces are the namespaces
of those classes.  So, its associated namespace is just N1.</P>

<P>3.4.2&nbsp;



 <A HREF="basic.html#basic.lookup.argdep">basic.lookup.argdep</A> also says:
<BLOCKQUOTE>
If T is a template-id, its associated namespaces and classes are the
    namespace  in  which  the template is defined; for member templates,
    the member template's class; the namespaces and  classes  associated
    with  the types of the template arguments provided for template type
    parameters (excluding template template parameters); the  namespaces
    in  which  any  template  template  arguments  are  defined; and the
    classes in which any member  templates  used  as  template  template
    arguments  are  defined.   [Note: non-type template arguments do not
    contribute to the set of associated namespaces.  ]
</BLOCKQUOTE>
First of all, there is a problem with the term "is a template-id".  template-id
is a syntactic constuct and you can't really talk about a type being a
template-id.  Presumably, this is intended to mean "If T is the type of a
class template specialization ...".
But does this apply to N1::X&lt;N2::Z&gt;::Y?
Y is a class nested within a class template specialization.  In addition,
its base class is a class template specialization.</P>

<P>I think this raises two issues:</P>
<OL>
<LI>
Should the enclosing class(es) of a class, and their template argument lists
 (if any) contribute to the associated classes/namespaces for ADL?</LI>

<LI>Should the template argument lists of base classes contribute to the
   associated classes/namespaces for ADL?</LI>
</OL>

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

<P>The ADL rules in the standard sort of look at if they are fully
recursive, but in fact they are not; in some cases, enclosing classes
and base classes are considered, and in others they are not.
Microsoft and g++ did fully-recursive implementations, and
EDG and IBM did it the other way.  Jon Caves reports that Microsoft saw
no noticeable difference (e.g., no complaints from customers
internal or external) when they made this change, so we believe
that even if the rules are imperfect the way they are in the
standard, they are clear and the imperfections are small enough
that programmers will not notice them.  Given that, it seemed
prudent to make no changes and just close this issue.</P>

<P>The template-id issue is spun off as
<A HREF="
     cwg_defects.html#403">issue 403</A>.</P>

<BR>
<BR>
<HR>
<A NAME="132"></A>
<H4>132.
  
Local types and linkage
</H4>
<B>Section: </B>3.5&nbsp;



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

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

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

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





<P>3.5&nbsp;



 <A HREF="basic.html#basic.link">basic.link</A>
 paragraph 8 says,</P>

<BLOCKQUOTE>
A name with no linkage (notably, the name of a class or enumeration
declared in a local scope
(3.3.2&nbsp;



 <A HREF="basic.html#basic.scope.local">basic.scope.local</A>
)) shall not be
used to declare an entity with linkage.
</BLOCKQUOTE>

This wording does not, but should, prohibit use of an unnamed local
type in the declaration of an entity with linkage.  For example,

<PRE>
    void f() {
        extern struct { } x;  // currently allowed
    }
</PRE>

<P>
<B>Proposed resolution:</B> Change the text in
3.5&nbsp;



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

<BLOCKQUOTE>A name with no linkage (notably, the name of a class or enumeration
declared in a local scope (3.3.2&nbsp;



 <A HREF="basic.html#basic.scope.local">basic.scope.local</A>)) shall not be used to declare an entity
with linkage.</BLOCKQUOTE>
to:
<BLOCKQUOTE>A name with no linkage (notably, the name of a class or enumeration
declared in a local scope (3.3.2&nbsp;



 <A HREF="basic.html#basic.scope.local">basic.scope.local</A>)) or an unnamed type shall not be used
to declare an entity with linkage.</BLOCKQUOTE>
In section 3.5&nbsp;



 <A HREF="basic.html#basic.link">basic.link</A> paragraph 8, add to the example, before the
closing brace of function <TT>f</TT>:
<BLOCKQUOTE>
<TT>extern struct {} x;&nbsp;&nbsp;&nbsp; //</TT> <I>ill-formed</I>
</BLOCKQUOTE>

<P>
<B>Rationale (10/00):</B> The proposed change would have introduced
an incompatibility with the C language.  For example, the global
declaration</P>

<PRE>
    static enum { A, B, C } abc;
</PRE>

<P>represents an idiom that is used in C but would be prohibited
under this resolution.</P>

<BR>
<BR>
<HR>
<A NAME="269"></A>
<H4>269.
  
Order of initialization of multiply-defined static data members
of class templates
</H4>
<B>Section: </B>3.6.2&nbsp;



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

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

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

 <B>Date: </B>8 Feb 2001<BR>


<P>According to 3.2&nbsp;



 <A HREF="basic.html#basic.def.odr">basic.def.odr</A> paragraph 5, it is possible
for a static data member of a class template to be defined more than
once in a given program provided that each such definition occurs in a
different translation unit and the ODR is met.</P>

<P>Now consider the following example:</P>

<P>
<I><B>src1.cpp:</B></I>
</P>

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

    int  initializer()
    {
       static int   counter;
       return  counter++;
    }

    int   g_data1 = initializer();

    template&lt;class T&gt;
    struct  exp  {
       static int   m_data;
    };
    template&lt;class T&gt;
    int  exp&lt;T&gt;::m_data = initializer();

    int   g_data2 = initializer();
    extern int   g_data3;

    int  main()
    {
       std::cout &lt;&lt; exp&lt;char&gt;::m_data &lt;&lt; ", " &lt;&lt; g_data1 &lt;&lt; ", "
	  &lt;&lt; g_data2 &lt;&lt; ", " &lt;&lt; g_data3 &lt;&lt; std::endl;
       return  0;
    }
</PRE>

<P>
<I><B>src2.cpp:</B></I>
</P>

<PRE>
    extern int  initializer();
    int  g_data3 = initializer();

    template&lt;class T&gt;
    struct  exp  {
       static int   m_data;
    };
    template&lt;class T&gt;
    int  exp&lt;T&gt;::m_data = initializer();

    void  func()
    {
      exp&lt;char&gt;::m_data++;
    }
</PRE>

<P>The specialization <TT>exp&lt;char&gt;::m_data</TT> is implicitly
instaniated in both translation units, hence (14.7.1&nbsp;



 <A HREF="template.html#temp.inst">temp.inst</A> paragraph 1) its initialization occurs. And for both
definitions of <TT>exp&lt;T&gt;::m_data</TT> the ODR is met. According
to 3.6.2&nbsp;



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

<BLOCKQUOTE>

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

</BLOCKQUOTE>

<P>But for <TT>exp&lt;T&gt;::m_data</TT> we have two definitions. Does
it mean that both <TT>g_data1</TT> and <TT>g_data3</TT> are guaranteed
to be dynamically initialized before
<TT>exp&lt;char&gt;::m_data</TT>?</P>

<P>
<U>Suggested Resolution</U>:
Insert the following sentence before the last two sentences of
3.2&nbsp;



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

<BLOCKQUOTE>

<P>In the case of <TT>D</TT> being a static data member of a class
template the following shall also hold:</P>

<UL>
<LI>
for a given (not explicit) specialization of <TT>D</TT> initialized dynamically
(3.6.2&nbsp;



 <A HREF="basic.html#basic.start.init">basic.start.init</A>), the accumulated set of objects initialized dynamically
in namespace scope before the specialization of <TT>D</TT> shall be the same in every
translation unit that contains the definition for this specialization.
</LI>
</UL>

</BLOCKQUOTE>

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

<P>It was decided that this issue is not linked to
<A HREF="
     cwg_defects.html#270">issue 270</A> and that there is no problem, because
there is only one instantiation (see 2.1&nbsp;



 <A HREF="lex.html#lex.phases">lex.phases</A> paragraph 8).
</P>
<BR>
<BR>
<HR>
<A NAME="465"></A>
<H4>465.
  
May constructors of global objects call <TT>exit()</TT>?
</H4>
<B>Section: </B>3.6.2&nbsp;



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

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

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

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




<P>The subject line pretty much says it all.  It's a possibility that 
hadn't ever occurred to me.  I don't see any prohibition in the 
standard, and I also don't think the possibility introduces any logical 
inconsistencies.  The proper behavior, presumably, would be to go 
through the list of already-constructed objects (not including the 
current one, since its constructor wouldn't have finished executing) 
and destroy them in reverse order.  Not fundamentally hard, and I'm 
sure lots of existing implementations already do that.</P>

<P>I'm just not sure whether the standard was intended to support this, or 
whether it's just that nobody else thought of it either.  If the 
former, then a non-normative note somewhere in
3.6.2&nbsp;



 <A HREF="basic.html#basic.start.init">basic.start.init</A> might be nice.</P>

<P>
<B>Rationale (October 2004):</B>
</P>

<P>There is nothing in the Standard to indicate that this usage
is prohibited, so it must be presumed to be permitted.</P>

<BR>
<BR>
<HR>
<A NAME="234"></A>
<H4>234.
  
Reuse of base class subobjects
</H4>
<B>Section: </B>3.8&nbsp;



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

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

 <B>Submitter: </B>Bill Wade
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>28 Jun 2000<BR>


<P>3.8&nbsp;



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



 <A HREF="special.html#class.dtor">class.dtor</A> discuss
explicit management of object lifetime.  It seems clear that most
object lifetime issues apply to sub-objects (array elements, and data
members) as well.  The standard supports</P>

<PRE>
     struct X { T t } x;
     T* pt = &amp;x.t;
     pt-&gt;~T();
     new(pt) T;
</PRE>

<P>and this kind of behavior is useful  in allocators.</P>

<P>However the standard does not seem to prohibit the same operations
on base sub-objects.</P>

<PRE>
   struct D: B{ ... } d;
   B* pb = &amp;d;
   pb-&gt;~B();
   new(pb) B;
</PRE>

<P>However if <TT>B</TT> and/or <TT>D</TT> have virtual member
functions or virtual bases, it is unlikely that this code will result
in a well-formed <TT>D</TT> object in current implementations (note
that the various lines may be in different functions).</P>

<P>
<B>Suggested resolution:</B> 12.4&nbsp;



 <A HREF="special.html#class.dtor">class.dtor</A> should be
modified so that explicit destruction of base-class sub-objects be
made illegal, or legal only under some restrictive conditions.</P>

<P>
<B>Rationale (04/01):</B>
</P>

<P>Reallocation of a base class subobject is already disallowed
by 3.8&nbsp;



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

<BR>
<BR>
<HR>
<A NAME="290"></A>
<H4>290.
  
Should memcpy be allowed into a POD with a const member?
</H4>
<B>Section: </B>3.9&nbsp;



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

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

 <B>Submitter: </B>Garry Lancaster
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>12 Jun 2001<BR>


<P>Following the definition in 9&nbsp;



 <A HREF="class.html#class">class</A> paragraph 4
the following is a valid POD (actually a POD-struct):</P>

<PRE>
    struct test
    {
        const int i;
    };
</PRE>

<P>The legality of PODs with const members is also implied by the text of
5.3.4&nbsp;



 <A HREF="expr.html#expr.new">expr.new</A> paragraph 15 bullet 1, sub-bullet 2 and
12.6.2&nbsp;



 <A HREF="special.html#class.base.init">class.base.init</A> paragraph 4 bullet 2.</P>

<P>3.9&nbsp;



 <A HREF="basic.html#basic.types">basic.types</A> paragraph 3 states that</P>

<BLOCKQUOTE>
For any POD type
<TT>T</TT>, if two pointers to <TT>T</TT> point to distinct objects
<TT>obj1</TT> and <TT>obj2</TT>, if the value of <TT>obj1</TT> is copied
into <TT>obj2</TT>, using the <TT>memcpy</TT> library function, <TT>obj2</TT>
shall subsequently hold the same value as <TT>obj1</TT>.
</BLOCKQUOTE>

<P>
<I>[Note: this text was changed by TC1, but the essential point
stays the same.]</I>
</P>

<P>This implies that the following is required to work:</P>

<PRE>
    test obj1 = { 1 };
    test obj2 = { 2 };
    memcpy( &amp;obj2, &amp;obj1, sizeof(test) );
</PRE>

<P>The memcpy of course changes the value of the const member, surely
something that shouldn't be allowed.</P>

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

<P>It is recommended that 3.9&nbsp;



 <A HREF="basic.html#basic.types">basic.types</A> paragraph 3 be
reworded to exclude PODs which contain (directly or indirectly) members
of const-qualified type.</P>

<P>
<B>Rationale (October, 2004):</B>
</P>

<P>7.1.5.1&nbsp;



 <A HREF="dcl.html#dcl.type.cv">dcl.type.cv</A> paragraph 4 already forbids
modifying a const member of a POD struct.  The prohibition need
not be repeated in 3.9&nbsp;



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

<BR>
<BR>
<HR>
<A NAME="584"></A>
<H4>584.
  
Unions and aliasing
</H4>
<B>Section: </B>3.10&nbsp;



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

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

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

 <B>Date: </B>10 June 2006<BR>


<P>The C++ standard says in 3.10&nbsp;



 <A HREF="basic.html#basic.lval">basic.lval</A>, in paragraph 15:</P>

<UL>
<LI>
<P>an aggregate or union type that includes one of the
aforementioned types among its members (including, recursively, a
member of a subaggregate or contained union),</P>
</LI>
</UL>

<P>Note that it is a literal copy from the C standard, but this is of
course not the problem.</P>

<P>In C, union is not defined as an aggregate type. Therefore it is
appropriate to say &ldquo;aggregate or union.&rdquo; But things
changed in C++: aggregate type includes union type now (though not all
unions are aggregates), and it becomes clear that the
&ldquo;union&rdquo; in &ldquo;aggregate or union&rdquo; is redundant
and should be deleted.</P>

<P>The above cited paragraph could be changed to:</P>

<UL>
<LI>
<P>an aggregate type that includes one of the aforementioned
types among its members (including, recursively, a member of a
subaggregate)</P>
</LI>
</UL>

<P>
<B>Rationale (October, 2006):</B>
</P>

<P>As noted in the issue, not all unions are aggregates, but those
that are not aggregates still allow aliasing.  That part of the
specification would be lost with the suggested change.</P>

<BR>
<BR>
<HR>
<A NAME="303"></A>
<H4>303.
  
Integral promotions on bit-fields
</H4>
<B>Section: </B>4.5&nbsp;



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

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

 <B>Submitter: </B>Kiril Avdeiv
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>24 Jul 2001<BR>


<P>Paragraph 3 of section 4.5&nbsp;



 <A HREF="conv.html#conv.prom">conv.prom</A> contains a statement
saying that if a bit-field is larger than int or unsigned int, no integral
promotions apply to it. This phrase needs further clarification, as it
is hardly possible to fugure out what it means. See below.</P>

<P>Assuming a machine with a size of general-purpose register equal 32
bits (where a byte takes up 8 bits) and a C++ implementation where an
int is 32 bits and a long is 64 bits. And the following snippet of
code:</P>
<PRE>
    struct ExternalInterface {
      long field1:36, field2:28;
    };
    int main() {
      ExternalInterface  myinstance = { 0x100000001L, 0x12,};
      if(myinstance.field1 &lt; 0x100000002L) { //do something }
    }
</PRE>

<P>Does the standard prohibit the implementation from promoting field1's
value into two general purpose registers? And imposes a burden of
using shift machine instructions to work with the field's value? What
else could that phrase mean?</P>

<P>Either alternative is implementation specific, so I don't understand
why the phrase "If the bit-field is larger yet, no integral promotions
apply to it" made it to the standard.</P>

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

<P>The standard of course does not dictate what an implementation
might do with regard to use of registers or shift instructions in
the generated code.  The phrase cited means only that a larger
bit-field does not undergo integral promotions, and therefore it
retains the type with which it was declared (<TT>long</TT> in
the above example).  The Core Working Group judged that this
was sufficiently clear in the standard.</P>
<P>Note that 9.6&nbsp;



 <A HREF="class.html#class.bit">class.bit</A> paragraph 1
indicates that any bits in excess of the size of the underlying type
are padding bits and do not participate in the value representation.
Therefore the <TT>field1</TT> bit field in the above example is not
capable of holding the indicated values, which require more than 32 bits.</P>

<BR>
<BR>
<HR>
<A NAME="566"></A>
<H4>566.
  
Conversion of negative floating point values to integer type
</H4>
<B>Section: </B>4.9&nbsp;



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

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

 <B>Submitter: </B>Seungbeom Kim
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>13 March 2006<BR>


<P>Section 4.9&nbsp;



 <A HREF="conv.html#conv.fpint">conv.fpint</A> paragraph 1 states:</P>

<BLOCKQUOTE>

An rvalue of a floating point type can be converted to an rvalue of an
integer type. The conversion truncates; that is, the fractional part
is discarded.

</BLOCKQUOTE>

<P>Here, the concepts of &ldquo;truncation&rdquo; and
&ldquo;fractional part&rdquo; seem to be used without precise
definitions. When -3.14 is converted into an integer, is the
truncation toward zero or away from zero? Is the fractional part -0.14
or 0.86? The standard seem to give no clear answer to these.</P>

<P>Suggested resolution:</P>

<OL>

<LI>
<P>Replace &ldquo;truncates&rdquo; with &ldquo;truncates toward
zero.&rdquo;</P>
</LI>

<LI>
<P>Replace &ldquo;the fractional part&rdquo; with &ldquo;the
fractional part (where that of <TT>x</TT> is defined
as <TT>x-floor(x)</TT> for nonnegative <TT>x</TT>
and <TT>x-ceiling(x)</TT> for negative <TT>x</TT>);&rdquo; there
should be a better wording for this, or the entire statement
&ldquo;that is, the fractional part is discarded&rdquo; can be removed,
once the meaning of &ldquo;truncation&rdquo; becomes unambiguous as
above.</P>
</LI>

</OL>

<P>
<B>Rationale (October, 2006):</B>
</P>

<P>The specification is clear enough: &ldquo;fractional part&rdquo;
refers to the digits following the decimal point, so that -3.14
converted to <TT>int</TT> becomes -3.</P>

<BR>
<BR>
<HR>
<A NAME="456"></A>
<H4>456.
  
Is initialized const int or const bool variable a null pointer constant?
</H4>
<B>Section: </B>4.10&nbsp;



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

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

 <B>Submitter: </B>Lloyd Lewins
 &nbsp;&nbsp;&nbsp;

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


<P>In the following code, I expect both "null" and "FALSE" to be null
pointer constants -- and that the code should compile and output the
string "int*" twice to cout:</P>
<PRE>
#include &lt;iostream&gt;

using namespace std;

void foo(int* p)
{
     cout &lt;&lt; "int*" &lt;&lt; endl;
}

int main(void)
{
     const int null = 0;
     foo(null);
     const bool FALSE = false;
     foo(FALSE);
}
</PRE>
<P>ISO/IEC 14882-1998 4.10&nbsp;



 <A HREF="conv.html#conv.ptr">conv.ptr</A> states:</P>
<BLOCKQUOTE>
An  integral constant expression rvalue of integer type that evaluates
to zero (called a /null pointer constant/)  can  be  converted  to  a
pointer  type.
</BLOCKQUOTE>
<P>Stroustrup appears to agree with me -- he states (3rd edition page 88):</P>
<BLOCKQUOTE>
In C, it has been popular to define a macro NULL to represent the zero
pointer. Because of C++`s tighter type checking, the use of plain 0,
rather than any suggested NULL macro, leads to fewer problems. If you
feel you must define NULL, use:
<PRE>
   const int NULL = 0;
</PRE>
</BLOCKQUOTE>
<P>However gcc 3.3.1 rejects this code with the errors:</P>
<PRE>
     bug.cc:17: error: invalid conversion from `int' to `int*'
     bug.cc:19: error: cannot convert `const bool' to `int*' for argument `1' to `
         void foo(int*)'
</PRE>
<P>I have reported this as a bug
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13867), but the gcc team
states that 4.10 requires that a null pointer constant must be an rvalue
-- and no implicit conversion from an lvalue to an rvalue is required
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=396):</P>
<BLOCKQUOTE>
a null pointer constant is an integral constant expression rvalue that
evaluates to zero [4.10/1] in this case `null' is an lvalue. The
standard does not specify that lvalue-&gt;rvalue decay happens here, so
`null' is not a null pointer constant.
</BLOCKQUOTE>

<P>I disagree with the gcc teams interpretation -- I don't see why
3.10&nbsp;



 <A HREF="basic.html#basic.lval">basic.lval</A> doesn't apply:</P>
<BLOCKQUOTE>
Whenever  an  lvalue appears in a context where an rvalue is expected,
the lvalue is converted to an rvalue;
</BLOCKQUOTE>
<P>The insertion of the word rvalue appears to have occurred during
standardization -- it is not present in either Stroustrup 2nd edition or
the 3rd edition. Does the committee deliberately intend to exclude an
lvalue as a null pointer constant by adding the word rvalue? If so, it
leads to the rather bizarre fact that "null" is not a null pointer
constant, but "null + 0" is!</P>

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

<P>We think this is just a bug in gcc.  The const variable does
get converted to an rvalue in this context.  This case is not
really any different than cases like
<PRE>
  const int null = 0;
  int i = null;
</PRE>
or
<PRE>
  const int i = 1;
  int a[i];
</PRE>
(which are accepted by gcc).
No one would argue that the second lines of those examples
are invalid because the variables are lvalues, and yet the conversions
to rvalue happen implicitly for the same reason cited above -- the
contexts require an rvalue. </P>

<BR>
<BR>
<HR>
<A NAME="71"></A>
<H4>71.
  
Incorrect cross reference
</H4>
<B>Section: </B>5&nbsp;



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

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

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

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





<P>An operator expression can, according to
5&nbsp;



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

paragraph 2, require transformation into function call syntax. The
reference in that paragraph is to
13.5&nbsp;



 <A HREF="over.html#over.oper">over.oper</A>
, but it should be to
13.3.1.2&nbsp;



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

<P>
<B>Rationale (04/99):</B> The subsections
13.5.1&nbsp;



 <A HREF="over.html#over.unary">over.unary</A>
,
13.5.2&nbsp;



 <A HREF="over.html#over.binary">over.binary</A>
, etc. of the referenced
section are in fact relevant.</P>
<BR>
<BR>
<HR>
<A NAME="31"></A>
<H4>31.
  
Looking up new/delete
</H4>
<B>Section: </B>5.3.4&nbsp;



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

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

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

 <B>Date: </B>23 Jun 1998<BR>





<P>Section 12.5&nbsp;



 <A HREF="special.html#class.free">class.free</A>
 paragraph 4 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>
I contrast that with 5.3.4&nbsp;



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

paragraphs 16 and 17:
<BLOCKQUOTE>If the <I>new-expression</I> creates an object or an array of objects
of class type, access and ambiguity control are done for the allocation
function, the deallocation function (12.5&nbsp;



 <A HREF="special.html#class.free">class.free</A>
), and the constructor
(12.1&nbsp;



 <A HREF="special.html#class.ctor">class.ctor</A>
). If the <I>new-expression</I> creates an array of objects of class
type, access and ambiguity control are done for the destructor (12.4&nbsp;



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

<P>If any part of the object initialization described above terminates
by throwing an exception and a suitable deallocation function can be found,
the deallocation function is called to free the memory in which the object
was being constructed, after which the exception continues to propagate
in the context of the <I>new-expression</I>. If no unambiguous matching deallocation
function can be found, propagating the exception does not cause the object's
memory to be freed. [<I>Note:</I> This is appropriate when the called allocation
function does not allocate memory; otherwise, it is likely to result in
a memory leak. ]</P>
</BLOCKQUOTE>
I think nothing in the latter paragraphs implies that the deallocation
function found is the same as that for a corresponding <I>delete-expression</I>.
I suspect that may not have been intended and that the lookup should occur
"as if for a <I>delete-expression</I>".

<P>
<B>Rationale:</B>
</P>

<P>Paragraphs 16 through 18 are sufficiently correct and unambiguous as
written.</P>
<BR>
<BR>
<HR>
<A NAME="130"></A>
<H4>130.
  
Sequence points and <I>new-expression</I>s
</H4>
<B>Section: </B>5.3.4&nbsp;



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

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

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

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





<P>Clause 5&nbsp;



 <A HREF="expr.html#expr">expr</A>
 paragraph 4 appears to
grant an implementation the right to generate code for a function
call like</P>

<PRE>
    f(new T1, new T2)
</PRE>

in the order

<UL>
<LI>allocate memory for the <TT>T1</TT> object</LI>
<LI>allocate memory for the <TT>T2</TT> object</LI>
<LI>call the <TT>T1</TT> constructor</LI>
<LI>call the <TT>T2</TT> constructor</LI>
<LI>call <TT>f</TT>
</LI>
</UL>

However, 5.3.4&nbsp;



 <A HREF="expr.html#expr.new">expr.new</A>
 paragraph 17
seems to require the deallocation of the storage for an object only
if part of the initialization of that object terminates with an
exception.  Given the ordering above, this specification would
appear to allow the memory for the <TT>T2</TT> object to be leaked
if the <TT>T1</TT> constructor throws an exception.

<P>Suggested resolution: either forbid the ordering above or expand
the requirement for reclaiming storage to include exceptions thrown
in all operations between the allocation and the completion of the
constructor.</P>

<P>
<B>Rationale (10/99):</B> Even in the "traditional" ordering of the calls
to allocation functions and constructors, memory can still leak.  For
instance, if <TT>T1</TT> were successfully constructed and then the
construction of <TT>T2</TT> were terminated by an exception, the
memory for <TT>T1</TT> would be lost.  Programmers concerned about
memory leaks will avoid this kind of construct, so it seems
unnecessary to provide special treatment for it to avoid the memory
leaks associated with one particular implementation strategy.</P>
<BR>
<BR>
<HR>
<A NAME="55"></A>
<H4>55.
  
Adding/subtracting pointer and enumeration value
</H4>
<B>Section: </B>5.7&nbsp;



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

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

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

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



<P>An expression of the form pointer + enum (see paragraph 5) is not given
meaning, and ought to be, given that paragraph 2 of this section makes
it valid. Presumably, the enum value should be converted to an integral
value, and the rest of the processing done on that basis. Perhaps
we want to invoke the integral promotions here.</P>

<P>[Should this apply to (pointer - enum) too?]</P>

<P>
<B>Rationale (04/99):</B>
Paragraph 1 invokes "the usual arithmetic conversions" for operands
of enumeration type.</P>

<P>(It was later pointed out that the builtin operator
<TT><I>T*</I> operator+(<I>T</I>*, ptrdiff_t)</TT>
(13.6&nbsp;



 <A HREF="over.html#over.built">over.built</A>
 paragraph 13) is
selected by overload resolution.  Consequently, according to
13.3.1.2&nbsp;



 <A HREF="over.html#over.match.oper">over.match.oper</A>
 paragraph 7,
the operand of enumeration type is converted to <TT>ptrdiff_t</TT>
before being interpreted according to the rules in
5.7&nbsp;



 <A HREF="expr.html#expr.add">expr.add</A>
.)</P>
<BR>
<BR>
<HR>
<A NAME="567"></A>
<H4>567.
  
Can <TT>size_t</TT> and <TT>ptrdiff_t</TT> be larger than <TT>long</TT>?
</H4>
<B>Section: </B>5.7&nbsp;



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

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

 <B>Submitter: </B>Nick MacLaren
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>14 March 2006<BR>


<P>Code that was portable in C90 and C++98 is no longer portable with
the introduction of data types longer than <TT>long</TT>; code that
could previously cast <TT>size_t</TT> and <TT>ptrdiff_t</TT> to
<TT>long</TT> without loss of precision (because <TT>long</TT> was
the largest type) can no longer rely on that idiom.</P>

<P>The CWG discussed this during the Berlin (April, 2006) meeting.  The
general consensus was that this was unavoidable: there are valid
reasons for implementations to keep <TT>long</TT> at a size less than
that required for address arithmetic.</P>

<P>See paper J16/06-0053 = WG21 N1983, which also suggests the
possibility of required diagnostics for problematic cases as an
alternative to restricting the size of <TT>size_t</TT> and
<TT>ptrdiff_t</TT>.</P>

<P>
<B>Rationale (October, 2006):</B>
</P>

<P>This is not an area in which the Standard should override the
decisions of implementors who wish to maintain the size of
<TT>long</TT> for backward compatibility but need a
larger <TT>size_t</TT> to deal with expanded address spaces.  Also,
diagnostics of the sort described are better treated as quality of
implementation issues rather than topics for standardization.</P>

<BR>
<BR>
<HR>
<A NAME="97"></A>
<H4>97.
  
Use of bool constants in integral constant expressions
</H4>
<B>Section: </B>5.19&nbsp;



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

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

 <B>Submitter: </B>Andy Koenig
 &nbsp;&nbsp;&nbsp;

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




    
<P>Consider:</P>
<PRE>
    int* p = false;         // Well-formed?
    int* q = !1;            // What about this?
</PRE>

&gt;From 3.9.1&nbsp;



 <A HREF="basic.html#basic.fundamental">basic.fundamental</A>
 paragraph 6:
"As described below, <TT>bool</TT> values behave as integral types."

<P>From 4.10&nbsp;



 <A HREF="conv.html#conv.ptr">conv.ptr</A>
 paragraph 1: "A null
pointer constant is an integral constant expression rvalue of integer
type that evaluates to zero."</P>

<P>From 5.19&nbsp;



 <A HREF="expr.html#expr.const">expr.const</A>
 paragraph 1: "An
<I>integral constant-expression</I> can involve only literals,
enumerators, const variables or static members of integral or
enumeration types initialized with constant expressions, ..."</P>

<P>In 2.13.1&nbsp;



 <A HREF="lex.html#lex.icon">lex.icon</A>
: No mention of
<TT>true</TT> or <TT>false</TT> as an integer literal.</P>

<P>From 2.13.5&nbsp;



 <A HREF="lex.html#lex.bool">lex.bool</A>
: <TT>true</TT> and
<TT>false</TT> are Boolean literals.</P>

<P>So the definition of <TT>q</TT> is certainly valid, but the
validity of <TT>p</TT> depends on how the sentence in
5.19&nbsp;



 <A HREF="expr.html#expr.const">expr.const</A>
 is parsed. Does it mean
<UL>{literals, enumerators, const variables, or static members} of
integral of integral or enumeration types...</UL> Or does it mean
<UL>literals (of any type), enumerators, const variables, or {static
members of integral or enumeration types}</UL> Or something else?</P>

<P>If the latter, then <TT>(3.0 &lt; 4.0)</TT> is a constant expression,
which I don't think we ever wanted. If the former, though, we have the
anomalous notion that <TT>true</TT> and <TT>false</TT> are not constant
expressions.</P>

<P>Now, you may argue that you shouldn't be allowed to convert
<TT>false</TT> to a pointer. But what about this?</P>

<PRE>
    static const bool debugging = false;
    
    // ...
    
    int table[debugging? n+1: n];
</PRE>

Whether the definition of table is well-formed hinges on whether
<TT>false</TT> is an integral constant expression.

<P>I think that it should be, and that failure to make it so was just
an oversight.</P>

<P>
<B>Rationale (04/99):</B> A careful reading of
5.19&nbsp;



 <A HREF="expr.html#expr.const">expr.const</A>
 indicates that all types of
literals can appear in integral constant expressions, but
floating-point literals must immediately be cast to an integral type.</P>
<BR>
<BR>
<HR>
<A NAME="487"></A>
<H4>487.
  
Operator overloading in constant expressions
</H4>
<B>Section: </B>5.19&nbsp;



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

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

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

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


<P>According to 5.19&nbsp;



 <A HREF="expr.html#expr.const">expr.const</A> paragraph 1,</P>

<BLOCKQUOTE>

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

</BLOCKQUOTE>

<P>Given a case like</P>

<PRE>
    enum E { e };
    int operator+(int, E);
    int i[4 + e];
</PRE>

<P>does this mean that the overloaded <TT>operator+</TT> is not
considered (because it can't be called), or is it selected by
overload resolution, thus rendering the program ill-formed?</P>

<P>
<B>Rationale (April, 2005):</B>
</P>

<P>All expressions, including constant expressions, are subject to
overload resolution.  The example is ill-formed.
</P>

<BR>
<BR>
<HR>
<A NAME="467"></A>
<H4>467.
  
Jump past initialization of local static variable
</H4>
<B>Section: </B>6.7&nbsp;



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

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

 <B>Submitter: </B>Kerch Holt
 &nbsp;&nbsp;&nbsp;

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


<P>When jumping past initialization of a local static variable the
value of the static becomes indeterminate. Seems like this
behavior should be illegal just as it is for local variables
with automatic linkage.</P>

<P>Here is an example:</P>
<PRE>
struct X {
    X(int i) : x(i) {}
    int x;
};
int f(int c) {
    if (c)
        goto ly;    // error here for jumping past next stmt.
    static X a = 1;
ly:
    return a.x;  // either 1 or 0 depending on implementation.
}
</PRE>
<P>6.7&nbsp;



 <A HREF="stmt.html#stmt.dcl">stmt.dcl</A> P3 should be changed to:
<BLOCKQUOTE>
A program that jumps from a point where a local variable with automatic
<B>or static</B> storage duration is not in scope to a point where it is in
scope is
ill-formed unless the variable has POD type (3.9) and is declared without
an initializer  (8.5).
</BLOCKQUOTE>
This would imply "static X a = 1;" should be flagged as an error.
Note that this behavior a may be a "quality of implementation issue"
which may be covered in 6.7 P4.  Paragraph 4 seems to make the
choice of static/dynamic initialization indeterminate.
Making this an error and thus determinate seems the correct thing
to do since that is what is already required of automatic variables.</P>

<P>
<U>Steve Adamczyk:</U>
Some version of this may be appropriate, but it's common to have code
that is executed only the first time it is reached, and to have
an initialization of a static variable inside such a piece of code.
In such a case, on executions after the first there is indeed a
jump over the declaration, but the static variable is correctly
initialized -- it was initialized the first time the routine
was called.</P>
<PRE>
  void f() {
    static bool first_time = true;
    if (!first_time) goto after_init;
    static int i = g();
    first_time = false;
  after_init:
    ...
  }
</PRE>

<P>
<B>Rationale (October, 2004):</B>
</P>

<P>The CWG sees no reason to change this specification.  Local
static variables are different from automatic variables:
automatic variables, if not explicitly initialized, can have
indeterminate (&ldquo;garbage&rdquo;) values, including trap
representations, while local static variables are subject to zero
initialization and thus cannot have garbage values.</P>

<P>The latitude granted to implementations regarding performing
dynamic initialization of local static objects as if it were
static initialization is exactly parallel to namespace scope
objects (3.6.2&nbsp;



 <A HREF="basic.html#basic.start.init">basic.start.init</A>), as are the restrictions
on programmer assumptions.</P>

<BR>
<BR>
<HR>
<A NAME="435"></A>
<H4>435.
  
Change "declararation or definition" to "declaration"
</H4>
<B>Section: </B>7&nbsp;



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

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

 <B>Submitter: </B>Jens Maurer
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>27 Oct 2003<BR>


<P>Because a definition is also a declaration, it might make sense
to change uses of "declaration or definition" to simply "declaration".</P>

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

<P>Jens Maurer prepared drafting for this issue, but we find ourselves
reluctant to actually make the changes.  Though correct, they seemed
more likely to be misread than the existing wording.</P>

<P>
<B>Proposed resolution:</B>
</P>
<P>
Remove in 1.3.9&nbsp;



 <A HREF="intro.html#defns.parameter">defns.parameter</A>
the indicated words:</P>
<BLOCKQUOTE>
an object or reference declared as part of a function declaration <S>or
definition</S>, or in the catch clause of an exception handler, that
acquires a value on entry to the function or handler; ...
</BLOCKQUOTE>

<P>
Remove in 14.1&nbsp;



 <A HREF="template.html#temp.param">temp.param</A>
paragraph 10 the indicated words:</P>
<BLOCKQUOTE>
The set of default <I>template-argument</I>s available for use with a
template declaration <S>or definition</S> is obtained by
merging the default arguments from the definition (if in scope) and
all declarations in scope in the same way default function arguments
are (...).
</BLOCKQUOTE>

<P>
Remove in 14.6&nbsp;



 <A HREF="template.html#temp.res">temp.res</A> paragraph 2 the indicated words:</P>
<BLOCKQUOTE>
A name used in a template declaration <S>or definition</S>
and that is dependent on a <I>template-parameter</I> is assumed not to
name a type unless the applicable name lookup finds a type name or the
name is qualified by the keyword <TT>typename</TT>.
</BLOCKQUOTE>

<P>
Remove in 14.6.4.1&nbsp;



 <A HREF="template.html#temp.point">temp.point</A> paragraph 1 the indicated words:</P>
<BLOCKQUOTE>
Otherwise, the point of instantiation for such a specialization
immediately follows the namespace scope declaration <S>or
definition</S> that refers to the specialization.
</BLOCKQUOTE>

<P>
Remove in 14.6.4.1&nbsp;



 <A HREF="template.html#temp.point">temp.point</A> paragraph 3 the indicated words:</P>
<BLOCKQUOTE>
Otherwise, the point of instantiation for such a specialization
immediately precedes the namespace scope declaration <S>or
definition</S> that refers to the specialization.
</BLOCKQUOTE>

<P>
Remove in 14.7.3&nbsp;



 <A HREF="template.html#temp.expl.spec">temp.expl.spec</A> paragraph 21 the indicated words:</P>
<BLOCKQUOTE>
Default function arguments shall not be specified in a declaration
<S>or a definition</S> for one of the following explicit
specializations:
<UL>
<LI>...</LI>
</UL>
[<I>Note:</I> default function arguments may be specified in the
declaration <S>or definition</S> of a member function of a
class template specialization that is explicitly specialized.  ]
</BLOCKQUOTE>

<P>
Remove in 14.8.2.5&nbsp;



 <A HREF="template.html#temp.deduct.type">temp.deduct.type</A>
paragraph 18 the indicated words:</P>
<BLOCKQUOTE>
[Note: a default <I>template-argument</I> cannot be specified in a
function template declaration <S>or definition</S>; ...]
</BLOCKQUOTE>

<P>
Remove in 17.4.2.1&nbsp;



 <A HREF="lib-intro.html#lib.using.headers">lib.using.headers</A>
paragraph 3 the indicated words:</P>
<BLOCKQUOTE>
A translation unit shall include a header only outside of any external
declaration <S>or definition</S>, and shall include the
header lexically before the first reference to any of the entities it
declares <S>or first defines</S> in that translation unit.
</BLOCKQUOTE>

<P>
<B>Rationale (October, 2004):</B>
</P>

<P>CWG felt that readers might misunderstand
&ldquo;declaration&rdquo; as meaning &ldquo;non-definition
declaration.&rdquo;</P>

<BR>
<BR>
<HR>
<A NAME="154"></A>
<H4>154.
  
Anonymous unions in unnamed namespaces
</H4>
<B>Section: </B>7.1.1&nbsp;



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

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

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

 <B>Date: </B>9 Aug 1999<BR>





<P>9.5&nbsp;



 <A HREF="class.html#class.union">class.union</A>
 paragraph 3 implies
that anonymous unions in unnamed namespaces need not be declared
<TT>static</TT> (it only places that restriction on anonymous unions
"declared in a named namespace or in the global namespace").</P>

<P>However, 7.1.1&nbsp;



 <A HREF="dcl.html#dcl.stc">dcl.stc</A>
 paragraph 1 says
that "global anonymous unions... shall be declared <TT>static</TT>."
This could be read as prohibiting anonymous unions in unnamed
namespaces, which are the preferred alternative to the deprecated use
of static.</P>

<P>
<B>Rationale (10/99):</B> An anonymous union in an unnamed
namespace is not "a global anonymous union," i.e., it is not a
member of the global namespace.</P>
<BR>
<BR>
<HR>
<A NAME="376"></A>
<H4>376.
  
Class "definition" versus class "declaration"
</H4>
<B>Section: </B>7.1.2&nbsp;



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

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

 <B>Submitter: </B>Randy Maddox
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>28 August 2002<BR>


<P>In clause 7.1.2&nbsp;



 <A HREF="dcl.html#dcl.fct.spec">dcl.fct.spec</A>, para. 3, the following sentence</P>
<BLOCKQUOTE>
A function defined within a class <B>definition</B> is an inline
function.
</BLOCKQUOTE>
<P>should, if I am not mistaken, instead be:</P>
<BLOCKQUOTE>
A function defined within a class <B>declaration</B> is an inline
function."
</BLOCKQUOTE>

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

<P>This is not a defect.  Though there is a long history, going
back to the ARM, of use of the term "class declaration" to mean the
definition of the class, we believe "class definition" is clearer.
We have opened <A HREF="
     cwg_defects.html#379">issue 379</A> to deal
with changing all other uses of "class declaration" to "class
definition" where appropriate.</P>

<BR>
<BR>
<HR>
<A NAME="412"></A>
<H4>412.
  
Can a replacement allocation function be inline?
</H4>
<B>Section: </B>7.1.2&nbsp;



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

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

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

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




<P>A customer reports that when he attempts to replace
<TT>::operator new</TT> with 
a user-defined function, the standard library calls the default 
function by preference if the user-defined function is inline.  I 
believe that our compiler is correct, and that such a replacement 
function isn't allowed to be inline, but I'm not sure there's 
sufficiently explicit language in the standard.</P>

<P>In general, of course, the definition of an inline function must be 
present in every translation unit where the function is called.
(7.1.2&nbsp;



 <A HREF="dcl.html#dcl.fct.spec">dcl.fct.spec</A>, 
par 4)  It could be argued that this requirement doesn't quite address 
replacement functions: what we're dealing with is the odd case where 
we've already got one definition and the user is supplying a different 
one.  I'd like to see something specifically addressing the case of a 
replacement function.</P>

<P>So what do we have?  I see discussion of requirement for a replacement 
<TT>::operator new</TT> in three places:
17.4.3.4&nbsp;



 <A HREF="lib-intro.html#lib.replacement.functions">lib.replacement.functions</A>,
18.4.1.1&nbsp;



 <A HREF="lib-support.html#lib.new.delete.single">lib.new.delete.single</A> par 2, and
3.7.3&nbsp;



 <A HREF="basic.html#basic.stc.dynamic">basic.stc.dynamic</A> par 
2-3.  I don't see anything explicitly saying that the replacement 
function may not be inline.  The closest I can find is
18.4.1.1&nbsp;



 <A HREF="lib-support.html#lib.new.delete.single">lib.new.delete.single</A> par 2, 
which says that "a C++ program may define a function with this function 
signature that displaces the default version defined by the C++ 
Standard library".  One might argue that "with this function signature" 
rules out inline, but that strikes me as a slight stretch.</P>

<P>Have I missed anything?</P>

<P>
<U>Andrew Koenig</U>:
I think you've turned up a problem in
7.1.2&nbsp;



 <A HREF="dcl.html#dcl.fct.spec">dcl.fct.spec</A> paragraph 4.  Consider:</P>
<PRE>
  // Translation unit 1
  #include &lt;iostream&gt;

  extern void foo(void (*)());

  inline void bar() {
    std::cout &lt;&lt; "Hello, world!" &lt;&lt; std::endl;
  }

  int main() {
    foo(bar);
  }

  // Translation unit 2
  void foo(void (*f)()) { (*f)(); }
</PRE>

<P>Are you really trying to tell me that this program is ill-formed because
the definition of bar is not available in translation unit 2?</P>

<P>I think not.  The actual words in
7.1.2&nbsp;



 <A HREF="dcl.html#dcl.fct.spec">dcl.fct.spec</A> par 4 are
<BLOCKQUOTE>
An inline function shall be defined in every translation unit in
which it is used...
</BLOCKQUOTE>
and I think at in this context, ``used'' should be interpreted to mean
that foo is used only in translation unit 1, where it is converted to
a value of type void(*)().</P>

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

<P>We don't think Andy Koenig's comment requires any action;
"used" is already defined appropriately.</P>

<P>We agree that this replacement should not be allowed, but
we think it's a library issue (in the rules for allowed
replacements).  Forwarded to library group; it's issue 404
on the library issues list.</P>

<BR>
<BR>
<HR>
<A NAME="422"></A>
<H4>422.
  
Is a typedef redeclaration allowed with a template type that might be the same?
</H4>
<B>Section: </B>7.1.3&nbsp;



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

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

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

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


<P>Is the following valid?</P>
<PRE>
  template &lt;class T&gt; void f(T) {
    typedef int x;
    typedef T x;
  }
  int main() {
    f(1);
  }
</PRE>
<P>There is an instantiation where the function is valid.  Is an
implementation allowed to issue an error on the template declaration
because the types on the typedef are not the same
(7.1.3&nbsp;



 <A HREF="dcl.html#dcl.typedef">dcl.typedef</A>)?</P>

<P>How about
<PRE>
  typedef T x;
  typedef T2 x;
</PRE>
?</P>

<P>It can be argued that these cases should be allowed because they
aren't necessarily wrong, but it can also be argued that there's no
reason to write things like the first case above, and if such
a case appears it's more likely to be a mistake than some kind
of intentional test that int and T are the same type.</P>

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

<P>We believe that all these cases should be allowed, and that
errors should be required only when an instance of the template is
generated.  The current standard wording does not seem to
disallow such cases, so no change is required.</P>

<BR>
<BR>
<HR>
<A NAME="311"></A>
<H4>311.
  
Using qualified name to reopen nested namespace
</H4>
<B>Section: </B>7.3.1&nbsp;



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

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

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

 <B>Date: </B>18 Sep 2001<BR>




<P>I received an inquiry/complaint that you cannot re-open a namespace using a 
qualified name. For example, the following program is ok, but if you uncomment 
the commented lines you get an error:</P>
<PRE>
namespace A {
    namespace N {
	int a;
    }
    int b;
    namespace M {
	int c;
    }
}

//namespace A::N {
//    int d;
//}

namespace A {
    namespace M {
        int e;
    }
}

int main()
{
    A::N::a = 1;
    A::b = 2;
    A::M::c = 3;
//  A::N::d = 4;
    A::M::e = 5;
}
</PRE>

<P>
<U>Andrew Koenig</U>:
There's a name lookup issue lurking here.  For example:</P>
<PRE>
    int x;

    namespace A {
	int x;
	namespace N {
	   int y;
	};
    }

    namespace A::N {
        int* y = &amp;x;  // which x?
    }
</PRE>

<P>
<U>Jonathan Caves</U>:
I would assume that any rule would state that:
<PRE>
namespace A::B {
</PRE>
would be equivalent to:
<PRE>
namespace A {
   namespace B {
</PRE>
so in your example 'x' would resolve to A::x</P>

<P>BTW: we have received lots of bug reports about this "oversight".</P>

<P>
<U>Lawrence Crowl</U>:
Even worse is
<PRE>
    int x;
    namespace A {
      int x;
    }
    namespace B {
      int x;
      namespace ::A {
         int* y = &amp;x;
      }
    }
</PRE>
I really don't think that the benefits of qualified names here is worth
the cost.</P>

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

<P>We're closing this because it's on the Evolution working group
list.</P>

<BR>
<BR>
<HR>
<A NAME="95"></A>
<H4>95.
  
Elaborated type specifiers referencing names declared in friend decls
</H4>
<B>Section: </B>7.3.1.2&nbsp;



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

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

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

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




<P>A change was introduced into the language that made names first declared
in friend declarations "invisible" to normal lookups until such time that
the identifier was declared using a non-friend declaration. This is described
in 7.3.1.2&nbsp;



 <A HREF="dcl.html#namespace.memdef">namespace.memdef</A>
 paragraph 3 and
11.4&nbsp;



 <A HREF="access.html#class.friend">class.friend</A>
 paragraph 9 (and perhaps other places).</P>

<P>The standard gives examples of how this all works with friend declarations,
but there are some cases with nonfriend elaborated type specifiers for
which there are no examples, and which might yield surprising results.</P>

<P>The problem is that an elaborated type specifier is sometimes a declaration
and sometimes a reference. The meaning of the following code changes depending
on whether or not friend class names are injected (visibly) into the enclosing
namespace scope.</P>
<PRE>
    struct A;
    struct B;
    namespace N {
        class X {
            friend struct A;
            friend struct B;
        };
        struct A *p;     // N::A with friend injection, ::A without
        struct B;        // always N::B
    }
</PRE>
Is this the desired behavior, or should
all elaborated type specifiers (and not just those of the form 
"<I>class-key&nbsp;identifier</I>;") have the effect of finding
previously declared "invisible"
names and making them visible?

<P>
<U>Mike Miller</U>: That's not how I would categorize the effect of
"<TT>struct B;</TT>". That declaration introduces the name 
"<TT>B</TT>" into namespace <TT>N</TT>
in exactly the same fashion as if the friend declaration did not exist.
The preceding friend declaration simply stated that, if a class 
<TT>N::B</TT> were
ever defined, it would have friendly access to the members of 
<TT>N::X</TT>. In
other words, the lookups in both "<TT>struct A*</TT>..." and 
"<TT>struct B;</TT>" ignore
the friend declarations.</P>

<P>(The standard is schizophrenic on the issue of whether such friend declarations
introduce names into the enclosing namespace. 3.3&nbsp;



 <A HREF="basic.html#basic.scope">basic.scope</A>
 paragraph 4 says,
<UL>friend declarations (11.4&nbsp;



 <A HREF="access.html#class.friend">class.friend</A>
) may introduce a (possibly not visible) name
into an enclosing name-space</UL>
while 3.3.1&nbsp;



 <A HREF="basic.html#basic.scope.pdecl">basic.scope.pdecl</A>
 paragraph 6 says exactly the opposite:
<UL>friend declarations refer to functions or classes that are members
of the nearest enclosing namespace, but they do not introduce new names
into that namespace (7.3.1.2&nbsp;



 <A HREF="dcl.html#namespace.memdef">namespace.memdef</A>
).</UL>
Both of these are just notes; the normative text doesn't commit itself
either way, just stating that the name is not found until actually declared
in the enclosing namespace scope. I prefer the latter description; I think
it makes the behavior you're describing a lot clearer and easier to understand.)</P>

<P>
<U>John Spicer</U>: The previous declaration of B is not completely
ignored though, because certainly changing "friend struct B;" to "friend
union B;" would result in an error when B was later redeclared as a struct,
wouldn't it?</P>

<P>
<U>Bill Gibbons</U>: Right. I think the intent was to model this after
the existing rule for local declarations of functions (which dates back
to C), where the declaration is introduced into the enclosing scope but
the name is not. Getting this right requires being somewhat more rigorous
about things like the ODR because there may be declaration clashes even
when there are no name clashes. I suspect that the standard gets this right
in most places but I would expect there to be a few that are still wrong,
in addition to the one Mike pointed out.</P>

<P>
<U>Mike Miller</U>: Regarding <I>would result in an error when <TT>B</TT>
was later redeclared</I>
</P>

<P>I don't see any reason why it should. The restriction that the class-key
must agree is found in 7.1.5.3&nbsp;



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

and is predicated on having found a matching
declaration in a lookup according to 3.4.4&nbsp;



 <A HREF="basic.html#basic.lookup.elab">basic.lookup.elab</A>
.
Since a lookup of a name declared
only (up to that point) in a friend declaration does not find that name
(regardless of whether you subscribe to the "does-not-introduce" or "introduces-invisibly"
school of thought), there can't possibly be a mismatch. </P>

<P>I don't
think that the Standard's necessarily broken here. There is no requirement
that a class declared in a friend declaration ever be defined. Explicitly
putting an incompatible declaration into the namespace where that friend
class would have been defined is, to me, just making it impossible to define
&mdash; which is no problem, since it didn't have to be defined anyway. The
only error would occur if the same-named but unbefriended class attempted
to use the nonexisting grant of friendship, which would result in an access
violation.</P>

<P>(BTW, I couldn't
find anything in the Standard that forbids <I>defining</I> a class with a mismatched
<I>class-key</I>, only using one in an 
<I>elaborated-type-specifier</I>. Is this a hole
that needs to be filled?)</P>

<P>
<U>John Spicer</U>: This is what 7.1.5.3&nbsp;



 <A HREF="dcl.html#dcl.type.elab">dcl.type.elab</A>
 paragraph 3 says:
<UL>The <I>class-key</I> or <TT>enum</TT> keyword present in the 
<I>elaborated-type-specifier</I>
shall agree in kind with the declaration to which the name in the 
<I>elaborated-type-specifier</I>
refers. This rule also applies to the form of <I>elaborated-type-specifier</I>
that declares a <I>class-name</I> or <TT>friend</TT> class since it can be
construed as
referring to the definition of the class. Thus, in any 
<I>elaborated-type-specifier</I>,
the <TT>enum</TT> keyword shall be used to refer to an enumeration (7.2&nbsp;



 <A HREF="dcl.html#dcl.enum">dcl.enum</A>
),
the <TT>union</TT> <I>class-key</I> shall be used to refer to a union 
(clause 9&nbsp;



 <A HREF="class.html#class">class</A>
),
and either the <TT>class</TT> or <TT>struct</TT> <I>class-key</I> 
shall be used to refer to a class
(clause 9&nbsp;



 <A HREF="class.html#class">class</A>
) declared using the 
<TT>class</TT> or <TT>struct</TT> <I>class-key</I>.</UL>
The latter part of this paragraph (beginning "This rule also applies...")
is somewhat murky to me, but I think it could be interpreted to say that</P>
<PRE>
            class B;
            union B {};
</PRE>
and
<PRE>
            union B {};
            class B;
</PRE>
are both invalid. I think this paragraph is <I>intended</I> to say that. I'm
not so sure it actually does say that, though.

<P>
<U>Mike Miller</U>: Regarding <I>I think the intent was to model this
after the existing rule for local declarations of functions (which dates
back to C)</I>
</P>

<P>Actually, that's not the C (1989) rule. To quote the Rationale from
X3.159-1989:</P>
<UL>While it was generally agreed that it is poor practice to take advantage
of an external declaration once it had gone out of scope, some argued that
a translator had to remember the declaration for checking anyway, so why
not acknowledge this? The compromise adopted was to decree essentially
that block scope rules apply, but that a conforming implementation need
not diagnose a failure to redeclare an external identifier that had gone
out of scope (undefined behavior).</UL>

<P>Regarding <I>Getting this right requires being somewhat more rigorous</I>
</P>

<P>Yes, I think if this is to be made illegal, it would have to be done
with the ODR; the name-lookup-based current rules clearly (IMHO) don't
apply. (Although to be fair, the [non-normative] note in 3.3&nbsp;



 <A HREF="basic.html#basic.scope">basic.scope</A>
 paragraph 4 sounds as
if it expects friend invisible injection to trigger the multiple-declaration
provisions of that paragraph; it's just that there's no normative text
implementing that expectation.)</P>

<P>
<U>Bill Gibbons</U>: Nor does the ODR currently disallow:</P>
<PRE>
    translation unit #1    struct A;
    
    translation unit #2    union A;
</PRE>
since it only refers to class definitions, not declarations.

<P>But the obvious form of the missing rule (all declarations of a class
within a program must have compatible struct/class/union keys) would also
answer the original question.</P>

<P>The declarations need not be visible. For example:</P>
<PRE>
    translation unit #1    int f() { return 0; }
    
    translation unit #2:   void g() {
                               extern long f();
                           }
</PRE>
is ill-formed even though the second "<TT>f</TT>" is not a visible declaration.

<P>
<B>Rationale (10/99):</B> The main issue (differing behavior of
standalone and embedded <I>elaborated-type-specifier</I>s) is as
the Committee intended.  The remaining questions mentioned in the
discussion may be addressed in dealing with related issues.</P>

<P>(See also issues
<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_defects.html#143">143</A>,
<A HREF="
     cwg_closed.html#165">165</A>, and
<A HREF="
     cwg_defects.html#166">166</A>.)</P>
<BR>
<BR>
<HR>
<A NAME="165"></A>
<H4>165.
  
Definitions of friends and block-scope externs
</H4>
<B>Section: </B>7.3.1.2&nbsp;



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

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

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

 <B>Date: </B>7 Sep 1999<BR>



<P>7.3.1.2&nbsp;



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

<BLOCKQUOTE>
Members of a named namespace can also be defined outside that
namespace by explicit qualification
(3.4.3.2&nbsp;



 <A HREF="basic.html#namespace.qual">namespace.qual</A>
) of the name being
defined, provided that the entity being defined was already declared
in the namespace...
</BLOCKQUOTE>

It is not clear whether block-scope <TT>extern</TT> declarations and
<TT>friend</TT> declarations are sufficient to permit the named
entities to be defined outside their namespace.  For example,

<PRE>
    namespace NS {
       struct A { friend struct B; };
       void foo() { extern void bar(); }
    }
    struct NS::B { };   // 1) legal?
    void NS::bar() { }  // 2) legal?
</PRE>

<P>
<B>Rationale (10/99):</B> Entities whose names are "invisibly
injected" into a namespace as a result of <TT>friend</TT> declarations
are not "declared" in that namespace until an explicit declaration of
the entity appears at namespace scope.  Consequently, the definitions
in the example are ill-formed.</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_defects.html#139">139</A>,
<A HREF="
     cwg_defects.html#143">143</A>, and
<A HREF="
     cwg_defects.html#166">166</A>.)</P>
<BR>
<BR>
<HR>
<A NAME="553"></A>
<H4>553.
  
Problems with friend allocation and deallocation functions
</H4>
<B>Section: </B>7.3.1.2&nbsp;



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

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

 <B>Submitter: </B>Dmitriy Litskalov
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>16 December 2005<BR>


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

<PRE>
    class C {
       public: enum E {};

       friend void* operator new(size_t, E);
       friend void  operator delete(void*, E);
    };

    void foo() {
       C::E e;
       C* ptr = new(e) C();
    }
</PRE>

<P>This code, which is valid in global scope, becomes ill-formed when
the class definition is moved into a namespace, and there is no way
to make it valid:</P>

<PRE>
    namespace N {
       class C {
          public: enum E {};

          friend void* operator new(size_t, E);
          friend void  operator delete(void*, E);
       };
    }

    void foo() {
       N::C::E e;
       N::C* ptr = new(e) N::C();
    }
</PRE>

<P>The reason for this is that non-member allocation and deallocation
functions are required to be members of the global scope (3.7.3.1&nbsp;



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



 <A HREF="basic.html#basic.stc.dynamic.deallocation">basic.stc.dynamic.deallocation</A>
paragraph 1), unqualified friend declarations declare names in the
innermost enclosing namespace (7.3.1.2&nbsp;



 <A HREF="dcl.html#namespace.memdef">namespace.memdef</A>
paragraph 3), and these functions cannot be declared in global scope
at a point where the friend declarations could refer to them using
<I>qualified-id</I>s because their second parameter is a member of the
class and thus can't be named before the class containing the friend
declarations is defined.</P>

<P>Possible solutions for this conundrum include invention of some
mechanism to allow a friend declaration to designate a namespace scope
other than the innermost enclosing namespace in which the friend class
or function is to be declared or to relax the innermost enclosing
namespace lookup restriction in 7.3.1.2&nbsp;



 <A HREF="dcl.html#namespace.memdef">namespace.memdef</A>
paragraph 3 for friend declarations that nominate allocation and
deallocation functions. </P>

<P>
<B>Rationale (April, 2006):</B>
</P>

<P>The CWG acknowledged that it is not always possible to move
code from the global scope into a namespace but felt that this
problem was not severe enough to warrant changing the language to
accommodate it.  Possible solutions include moving the enumeration
outside the class or defining member allocation and deallocation
functions.</P>

<BR>
<BR>
<HR>
<A NAME="109"></A>
<H4>109.
  
Allowing ::template in using-declarations
</H4>
<B>Section: </B>7.3.3&nbsp;



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

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

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

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



<P>
<I>Daveed Vandevoorde

:</I>
While reading <A HREF="
     cwg_defects.html#11">Core issue 11</A>
I thought it implied the following
possibility:</P>
<PRE>
    template&lt;typename T&gt;
    struct B {
       template&lt;int&gt; void f(int);
    };

    template&lt;typename T&gt;
    struct D: B&lt;T&gt; {
       using B&lt;T&gt;::template f;
       void g() { this-&gt;f&lt;1&gt;(0); } // OK, f is a template
    };
</PRE>
<P>However, the grammar for a <I>using-declaration</I> reads:</P>
<UL>
<TT>using typename<SUB>opt</SUB>&nbsp;::<SUB>opt</SUB>&nbsp;<I>nested-name-specifier&nbsp;unqualified-id</I> ;</TT>
</UL>
<P>and <I>nested-name-specifier</I> never ends in "<TT>template</TT>".</P>
<P>Is that intentional?</P>

<P>
<I>Bill Gibbons

:</I>
</P>
<P>It certainly appears to be, since we have:</P>
<UL>
<I>qualified-id</I>:
<UL>
<TT>::<SUB>opt</SUB> <I>nested-name-specifier</I> template<SUB>opt</SUB> <I>unqualified-id</I></TT>
</UL>
</UL>
so it would be easier to specify <I>using-declaration</I> as:
<UL>
<TT>using typename<SUB>opt</SUB> <I>qualified-id</I> ;</TT>
</UL>
if the "<TT>template</TT>" keyword were allowed.

There was a discussion about whether a dependent name specified in a
<I>using-declaration</I> could be given an "is a type" attribute through the
<TT>typename</TT> keyword; the decision was to allow this.  But I don't recall
if the "is a template" attribute was discussed.

<P>
<B>Rationale (04/99):</B> Any semantics associated with the
<TT>template</TT> keyword in <I>using-declaration</I>s should be considered an
extension.</P>

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

<P>See also issues <A HREF="
     cwg_active.html#96">96</A> and
<A HREF="
     cwg_defects.html#11">11</A>.</P>

<P>We decided to make no change and to close this issue as not-a-defect.
This is not needed functionality; the example above, for example, can
be written with <TT>-&gt;template</TT>.  This issue has been on the
issues list for years as an extension, and there has been no clamor
for it.</P>

<P>It was also noted that knowing that something is a template is
not enough; there's still the issue of knowing whether it is a
class or function template.</P>

<BR>
<BR>
<HR>
<A NAME="169"></A>
<H4>169.
  
<I>template-id</I>s in <I>using-declaration</I>s
</H4>
<B>Section: </B>7.3.3&nbsp;



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

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

 <B>Submitter: </B>Valentin Bonnard
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>16 Sep 1999<BR>



<P>7.3.3&nbsp;



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

<BLOCKQUOTE>
A <I>using-declaration</I> shall not name a <I>template-id</I>.
</BLOCKQUOTE>

It is not clear whether this prohibition applies to the entity for
which the <I>using-declaration</I> is a synonym or to any name that
appears in the <I>using-declaration</I>.  For example, is the
following code well-formed?

<PRE>
    template &lt;typename T&gt;
    struct base {
	void bar ();
    };

    struct der : base&lt;int&gt; 
    {
	using base&lt;int&gt;::bar; // ill-formed ?
    };
</PRE>

<P>
<B>Rationale (10/99):</B>
7.3.3&nbsp;



 <A HREF="dcl.html#namespace.udecl">namespace.udecl</A>
 paragraph 1 says,
"A <I>using-declaration</I> introduces a name..."  It is the name
that is thus introduced that cannot be a <I>template-id</I>.</P>
<BR>
<BR>
<HR>
<A NAME="461"></A>
<H4>461.
  
Make <TT>asm</TT> conditionally-supported
</H4>
<B>Section: </B>7.4&nbsp;



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

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

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

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


<P>Now that the concept of "conditionally-supported" is available (see
N1564), perhaps <TT>asm</TT> should not be required of every
implementation.</P>

<P>
<B>Rationale (October, 2004):</B>
</P>

<P>This is covered in paper N1627.  We would like to keep
<TT>asm</TT> as a keyword for all implementations, however, to
enhance portability by preventing programmers from inadvertently
using it as an identifier.</P>

<BR>
<BR>
<HR>
<A NAME="14"></A>
<H4>14.
  
extern "C" functions and declarations in different namespaces
</H4>
<B>Section: </B>7.5&nbsp;



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

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

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

 <B>Date: </B>unknown<BR>


    

    
<P>
<B><U>Issue 1</U></B>
</P>
    
<P>7.5&nbsp;



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

paragraph 6 says the following:</P>
<UL>extern "C" functions in multiple namespaces refer to the same function.</UL>
Is this only for linkage purposes or for both name look up and linkage
purposes:
<PRE>
    extern "C" int f(void);
    namespace A {
         extern "C" int f(void);
    };
    using namespace A;
     
    int i = f(); // Ok because only one function f() or
                 // ill-formed
</PRE>
For name lookup, both declarations of f are visible and overloading cannot
distinguish between them. Has the compiler to check that these functions
are really the same function or is the program in error?

<P>
<B>Rationale:</B> These are the same function for all purposes.</P>

<P>
<B><U>Issue 2</U></B>
</P>

<P>A similar question may arise with typedefs:</P>
<PRE>
    // vendor A
    typedef unsigned int size_t;
    // vendor B
    namespace std {
            typedef unsigned int size_t;
    }
    using namespace std;
    size_t something(); // error?
</PRE>
Is this valid because the typedef <TT>size_t</TT> refers to the same type in both
namespaces?

<P>
<B>Rationale (04/99):</B>
In
7.3.4&nbsp;



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

 paragraph 4:
<BLOCKQUOTE>If name lookup finds a declaration for a name in two different
namespaces, and the declarations do not declare the same entity and do
not declare functions, the use of the name is ill-formed.</BLOCKQUOTE>
The term <I>entity</I> applied to typedefs refers to the underlying type
or class (3&nbsp;



 <A HREF="basic.html#basic">basic</A>
, paragraph 3); therefore
both declarations of <TT>size_t</TT> declare the same entity and
the above example is well-formed.</P>
<BR>
<BR>
<HR>
<A NAME="358"></A>
<H4>358.
  
Namespaces and extern "C"
</H4>
<B>Section: </B>7.5&nbsp;



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

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

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

 <B>Date: </B>28 May 2002<BR>




<P>Is this code valid:</P>
<PRE>
  extern "C" void f();

  namespace N
  {
    int var; 
    extern "C" void f(){ var = 10; }
  }
</PRE>
<P>
The two declarations of f refer to the same external function,
but is this a valid way to declare and define f?</P>

<P>And is the definition of f considered to be in namespace N
or in the global namespace?</P>

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

<P>Yes, this example is valid.  See 7.5&nbsp;



 <A HREF="dcl.html#dcl.link">dcl.link</A>
paragraph 6, which contains a similar example with the definition in
the global namespace instead.
There is only one f, so the question of whether the definition
is in the global namespace or the namespace N is not meaningful.
The same function is found by name lookup whether it is found
from the declaration in namespace N or the declaration in
the global namespace, or both (7.3.4&nbsp;



 <A HREF="dcl.html#namespace.udir">namespace.udir</A>
paragraph 4).</P>

<BR>
<BR>
<HR>
<A NAME="333"></A>
<H4>333.
  
Ambiguous use of "declaration" in disambiguation section
</H4>
<B>Section: </B>8.2&nbsp;



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

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

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

 <B>Date: </B>14 Jan 2002<BR>


<P>In deciding whether a construct is an object declaration or
a function declaration, 8.2&nbsp;



 <A HREF="decl.html#dcl.ambig.res">dcl.ambig.res</A> contains the following
gem: "In that context, the choice is between a function declaration
[...] and an object declaration [...]
Just as for the ambiguities mentioned in 6.8&nbsp;



 <A HREF="stmt.html#stmt.ambig">stmt.ambig</A>,
the resolution is to
consider any construct that could possibly be a declaration 
a declaration."</P>

<P>To what declaration do the last two "declarations" refer? Object,
function, or (following from the syntax) possibly parameter
declarations?</P>

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

<P>This is not a defect.  Section 8.2&nbsp;



 <A HREF="decl.html#dcl.ambig.res">dcl.ambig.res</A> reads:</P>
<BLOCKQUOTE>
The ambiguity arising from the similarity between a function-style
cast and a declaration mentioned in 6.8&nbsp;



 <A HREF="stmt.html#stmt.ambig">stmt.ambig</A>
can also occur in the context
of a declaration. In that context, the choice is between a function
declaration with a redundant set of parentheses around a parameter
name and an object declaration with a function-style cast as the
initializer. Just as for the ambiguities mentioned in
6.8&nbsp;



 <A HREF="stmt.html#stmt.ambig">stmt.ambig</A>, the
resolution is to consider any construct that could possibly be a
declaration a declaration.
</BLOCKQUOTE>
<P>The wording "any construct" in the last sentence is not limited
to top-level constructs.  In particular, the function declaration
encloses a parameter declaration, whereas the object declaration
encloses an expression.  Therefore, in case of ambiguity between
these two cases, the declaration is parsed as a function declaration.</P>

<BR>
<BR>
<HR>
<A NAME="340"></A>
<H4>340.
  
Unclear wording in disambiguation section </H4>
<B>Section: </B>8.2&nbsp;



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

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

 <B>Submitter: </B>Bart v Ingen Schenau
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>27 Feb 2002<BR>


<P>Consider the following program:</P>
<PRE>
  struct Point
  {
    Point(int){}
  };
  struct Lattice 
  {
    Lattice(Point, Point, int){}
  };
  int main(void)
  {
    int a, b;
    Lattice latt(Point(a), Point(b), 3);   /* Line X */
  }
</PRE>

<P>The problem concerns the line marked <TT>/* Line X */</TT>, which is an
ambiguous declarations for either an object or a function.
The clause that governs this ambiguity is 8.2&nbsp;



 <A HREF="decl.html#dcl.ambig.res">dcl.ambig.res</A>
paragraph 1, and reads:</P>
<BLOCKQUOTE>
The ambiguity arising from the similarity between a function-style
cast and a declaration mentioned in 6.8&nbsp;



 <A HREF="stmt.html#stmt.ambig">stmt.ambig</A>
can also occur in the context
of a declaration. In that context, the choice is between a function
declaration with a redundant set of parentheses around a parameter
name and an object declaration with a function-style cast as the
initializer. Just as for the ambiguities mentioned in
6.8&nbsp;



 <A HREF="stmt.html#stmt.ambig">stmt.ambig</A>, the
resolution is to consider any construct that could possibly be a
declaration a declaration. [Note: a declaration can be explicitly
disambiguated by a nonfunction-style cast, by a <TT>=</TT> to indicate
initialization or by removing the redundant parentheses around the
parameter name. ]
</BLOCKQUOTE>

<P>Based on this clause there are two possible interpretations of the
declaration in line X:</P>
<OL>
<LI>
The declaration of latt declares a function with a return value of
the type Lattice and taking three arguments. The type of the first two
arguments is Point and each of these arguments is followed by a
parameter name in redundant parentheses. The type of the third
argument can not be determined, because it is a literal. 
This will result in a syntax error.
</LI>
<LI>
The declaration of latt declares an object, because the other option
(a function declaration) would result in a syntax error.
</LI>
</OL>

<P>Note that the last sentence before the "[Note:" is not much help,
because both options are declarations.</P>

<P>
<I>Steve Adamczyk: a number of people replied to this posting
on comp.std.c++ saying that they did not see a problem.  The
original poster replied:</I>
</P>

<P>I can't do anything but agree with your argumentation.
So there is only one correct interpretation of clause
8.2&nbsp;



 <A HREF="decl.html#dcl.ambig.res">dcl.ambig.res</A> paragraph 1, but I
have to say that with some rewording, the clause can be made a lot
clearer, like stating explicitly that the entire declaration must be
taken into account and that function declarations are preferred over
object declarations.</P>

<P>I would like to suggest the following as replacement for the current
clause 8.2&nbsp;



 <A HREF="decl.html#dcl.ambig.res">dcl.ambig.res</A> paragraph 1:</P>
<BLOCKQUOTE>
The ambiguity arising from the similarity between a functionstyle
cast and a declaration mentioned in
6.8&nbsp;



 <A HREF="stmt.html#stmt.ambig">stmt.ambig</A> can also occur in the context
of a declaration. In that context, the choice is between a function
declaration with a redundant set of parentheses around a parameter
name and an object declaration with a function-style cast as the
initializer. The resolution is to consider any construct that could
possibly be a function declaration a function declaration. [Note: To
disambiguate, the whole declaration might have to be examined to
determine if it is an object or a function declaration.] [Note: a
declaration can be explicitly disambiguated by a nonfunction-style
cast, by a <TT>=</TT> to indicate initialization or by removing the redundant
parentheses around the parameter name. ]
</BLOCKQUOTE>

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

<P>The working group felt that the current wording is clear enough.</P>

<BR>
<BR>
<HR>
<A NAME="478"></A>
<H4>478.
  
May a function parameter be an array of an abstract class type?
</H4>
<B>Section: </B>8.3.4&nbsp;



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

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

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

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


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

<PRE>
    struct S {
      virtual void v() = 0;
    };

    void f(S sa[10]);     // permitted?
</PRE>

<P>8.3.4&nbsp;



 <A HREF="decl.html#dcl.array">dcl.array</A> paragraph 1 says that a
declaration like that of <TT>sa</TT> is ill-formed:</P>

<BLOCKQUOTE>

<TT>T</TT> is called the array <I>element type</I>; this type
shall not be a reference type, the (possibly cv-qualified) type
<TT>void</TT>, a function type or an abstract class type.

</BLOCKQUOTE>

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



 <A HREF="decl.html#dcl.fct">dcl.fct</A> paragraph 3
says that the type of <TT>sa</TT> is adjusted to <TT>S*</TT>,
which would be permitted:</P>

<BLOCKQUOTE>

The type of each parameter is determined from its own
<I>decl-specifier-seq</I> and <I>declarator</I>. After
determining the type of each parameter, any parameter of type
&ldquo;array of <TT>T</TT>&rdquo; or &ldquo;function returning
<TT>T</TT>&rdquo; is adjusted to be &ldquo;pointer to
<TT>T</TT>&rdquo; or &ldquo;pointer to function returning
<TT>T</TT>,&rdquo; respectively.

</BLOCKQUOTE>

<P>It is not clear whether the parameter adjustment trumps the
prohibition on declaring an array of an abstract class type or
not.  Implementations differ in this respect: EDG 2.4.2 and
MSVC++ 7.1 reject the example, while g++ 3.3.3 and Sun Workshop 8
accept it.</P>

<P>
<B>Rationale (April, 2005):</B>
</P>

<P>The prohibition in 8.3.4&nbsp;



 <A HREF="decl.html#dcl.array">dcl.array</A> is absolute
and does not allow for exceptions.  Even though such a type in a
parameter declaration would decay to an allowed type, the prohibition
applies to the type before the decay.</P>

<P>This interpretation is consistent with the resolution of
<A HREF="
     cwg_defects.html#337">issue 337</A>, which causes template type
deduction to fail if such types are deduced.  It was also observed
that pointer arithmetic on pointers to abstract classes is very
likely to fail, and the fact that the programmer used array notation
to declare the pointer type is a strong indication that he/she
expected to use subscripting.</P>

<BR>
<BR>
<HR>
<A NAME="18"></A>
<H4>18.
  
f(TYPE) where TYPE is void should be allowed
</H4>
<B>Section: </B>8.3.5&nbsp;



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

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

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

 <B>Date: </B>unknown<BR>





<P>8.3.5&nbsp;



 <A HREF="decl.html#dcl.fct">dcl.fct</A>
 paragraph 2 says:
<BLOCKQUOTE>If the <I>parameter-declaration-clause</I> is empty, the function
takes no arguments. The parameter list <TT>(void)</TT> is equivalent to
the empty parameter list.</BLOCKQUOTE>
Can a typedef to void be used instead of the type void in the parameter
list?</P>

<P>
<B>Rationale:</B>
The IS is already clear that this is not allowed.</P>
<BR>
<BR>
<HR>
<A NAME="66"></A>
<H4>66.
  
Visibility of default args vs overloads added after using-declaration
</H4>
<B>Section: </B>8.3.6&nbsp;



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

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

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

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




<P>Paragraph 9 of says that extra default arguments added after a
<I>using-declaration</I> but before a call are usable in the call, while
7.3.3&nbsp;



 <A HREF="dcl.html#namespace.udecl">namespace.udecl</A>
 paragraph 9 says that
extra function overloads are not. This seems inconsistent, especially
given the similarity of default arguments and overloads.</P>

<P>
<B>Rationale (10/99):</B> The Standard accurately reflects the
intent of the Committee.</P>
<BR>
<BR>
<HR>
<A NAME="434"></A>
<H4>434.
  
Unclear suppression of standard conversions while binding reference to lvalue
</H4>
<B>Section: </B>8.5.3&nbsp;



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

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

 <B>Submitter: </B>Bronek Kozicki
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>14 September 2003<BR>


<P>In section 8.5.3&nbsp;



 <A HREF="decl.html#dcl.init.ref">dcl.init.ref</A>, paragraph 5, there is
following note:</P>
<BLOCKQUOTE>
Note: the usual lvalue-to-rvalue (4.1), array-to-pointer (4.2), and
function-to-pointer (4.3) standard conversions are not needed, and
therefore are suppressed, when such direct bindings to lvalues are done.
</BLOCKQUOTE>

<P>I believe that this note is misleading. There should be either:</P>
<UL>
<LI>no note, and leave this issue to be explained in section 4 only </LI>
<LI>explicit list of all suppressed conversions (including pointer
qualification conversion, as covered in section 4.4)</LI>
<LI>reminder that result of all standard conversions is never an lvalue,
thus these conversions are suppressed when binding reference to lvalue</LI>
</UL>

<P>The problem:</P>
<OL>
<LI>
under current wording it's unclear if following code is legal, or
not:
<PRE>
int main()
{
  const int ci = 10;
  int * pi = NULL;
  const int * &amp; rpci = pi;
  rpci = &amp;ci;
  *pi = 12; // circumvent constness of "ci"
}
</PRE>
</LI>
<LI>
it is also unclear what behaviour should following program expose:
<PRE>
int main()
{
  int * pi = NULL;
  const int * const &amp; rcpci = pi; // 1
  int i = 0;
  pi = &amp;i; // 2
  if (pi == rcpci)
    std::cout &lt;&lt; "bound to lvalue" &lt;&lt; std::endl;
  else
    std::cout &lt;&lt; "bound to temporary rvalue" &lt;&lt; std::endl;
}
</PRE>
</LI>
</OL>
<P>There has been discussion on this issue on comp.lang.c++.moderated month
ago, see
<A HREF="http://groups.google.pl/groups?threadm=9bed99bb.0308041153.1c79e882%40posting.google.com">
http://groups.google.pl/groups?threadm=9bed99bb.0308041153.1c79e882%40posting.google.com</A>
and there seems to be some confusion about it. I understand that note is
not normative, but apparently even some compiler writers are misled (try
above code snippets on few different compilers, and using different
compilation options - notably GCC 3.2.3 with -Wall -pedantic), thus it
should be cleared up.</P>

<P>My proposal is to change wording of discussed note to:</P>
<BLOCKQUOTE>
Note: result of every standard conversion is never an lvalue, and
therefore all standard conversions (clause 4) are suppressed, when such
direct bindings to lvalues are done.
</BLOCKQUOTE>

<P>
<B>Rationale (April, 2005):</B>
</P>

<P>As acknowledged in the description of the issue, the referenced
text is only a note and has no normative impact.  Furthermore, the
examples cited do not involve the conversions mentioned in the note,
and the normative text is already sufficiently clear that the types in
the examples are not reference-compatible.</P>

<BR>
<BR>
<HR>
<A NAME="315"></A>
<H4>315.
  
Is call of static member function through null pointer undefined?
</H4>
<B>Section: </B>9.4.1&nbsp;



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

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

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

 <B>Date: </B>7 Oct 2001<BR>




<P>Another instance to consider is that of invoking a member function from a
null pointer:</P>
<PRE>
  struct A { void f () { } };
  int main ()
  {
    A* ap = 0;
    ap-&gt;f ();
  }
</PRE>
<P>Which is explicitly noted as undefined in 9.3.1&nbsp;



 <A HREF="class.html#class.mfct.nonstatic">class.mfct.nonstatic</A>,
even though one could argue that since <TT>f()</TT> is empty, there is no
lvalue-&gt;rvalue conversion.</P>

<P>If <TT>f</TT> is static, however, there seems to be no such rule, and
the call is only undefined if the dereference implicit in the <TT>-&gt;</TT>
operator is undefined.  IMO it should be.</P>

<P>Incidentally, another thing that ought to be cleaned up is the inconsistent
use of "indirection" and "dereference".  We should pick one. <I>(This
terminology issue has been broken out as
<A HREF="
     cwg_active.html#342">issue 342</A>.)</I>
</P>

<P>This is related to <A HREF="
     cwg_active.html#232">issue 232</A>
</P>

<P>
<B>Rationale (October 2003):</B>
</P>

<P>We agreed the example should be allowed.  <TT>p-&gt;f()</TT>
is rewritten as <TT>(*p).f()</TT> according to 5.2.5&nbsp;



 <A HREF="expr.html#expr.ref">expr.ref</A>.
<TT>*p</TT> is not an error when <TT>p</TT> is null unless the
lvalue is converted to an rvalue (4.1&nbsp;



 <A HREF="conv.html#conv.lval">conv.lval</A>), which it
isn't here.</P>

<BR>
<BR>
<HR>
<A NAME="7"></A>
<H4>7.
  
Can a class with a private virtual base class be derived from?
</H4>
<B>Section: </B>11.2&nbsp;



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

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

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

 <B>Date: </B>unknown<BR>





<PRE>
    class Foo { public: Foo() {}  ~Foo() {} };
    class A : virtual private Foo { public: A() {}  ~A() {} };
    class Bar : public A { public: Bar() {}  ~Bar() {} };
</PRE>
<TT>~Bar()</TT> calls <TT>~Foo()</TT>, which is ill-formed due to access
violation, right? (<TT>Bar</TT>'s constructor has the same problem since it
needs to call <TT>Foo</TT>'s constructor.) There seems to be some disagreement
among compilers. Sun, IBM and g++ reject the testcase, EDG and HP
accept it. Perhaps this case should be clarified by a note in the
draft.

<P>In short, it looks like a class with a virtual private base can't be
derived from.</P>

<P>
<B>Rationale:</B> This is what was intended.</P>
<BR>
<BR>
<HR>
<A NAME="17"></A>
<H4>17.
  
Footnote 99 should discuss the naming class when describing members that can be accessed from friends
</H4>
<B>Section: </B>11.2&nbsp;



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

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

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

 <B>Date: </B>unknown<BR>





<P>Footnote 98 says:</P>
<BLOCKQUOTE>As specified previously in clause 11&nbsp;



 <A HREF="access.html#class.access">class.access</A>
, private members
of a base class remain inaccessible even to derived classes unless friend
declarations within the base class declaration are used to grant access
explicitly.</BLOCKQUOTE>
This footnote does not fit with the algorithm provided in 
11.2&nbsp;



 <A HREF="access.html#class.access.base">class.access.base</A>
 paragraph 4 because
it does not take into account the naming class concept introduced in this
paragraph.

<P>(See also paper J16/99-0002 = WG21 N1179.)</P>

<P>
<B>Rationale (10/99):</B> The footnote should be read as referring
to immediately-derived classes, and is accurate in that context.</P>
<BR>
<BR>
<HR>
<A NAME="471"></A>
<H4>471.
  
Conflicting inherited access specifications
</H4>
<B>Section: </B>11.2&nbsp;



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

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

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

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


<P>The Standard does not appear to specify how to handle cases in
which conflicting access specifications for a member are
inherited from different base classes.  For example,</P>

<PRE>
    struct A {
    public:
      int i;
    };
    struct B : virtual public A {
    protected:
      using A::i;
    };
    struct C : virtual public A, public B {
      // "i" is protected from B, public from A
    };
</PRE>

<P>This question affects both the existing wording of
11.2&nbsp;



 <A HREF="access.html#class.access.base">class.access.base</A> paragraph 4 (&ldquo;<I>m</I> as a
member of <I>N</I> is public ... <I>m</I> as a member of <I>N</I>
is private ... <I>m</I> as a member of <I>N</I> is
protected&rdquo;) and the proposed wording for <A HREF="
     cwg_defects.html#385">issue 385</A> (&ldquo;when a nonstatic data member or
nonstatic member function is a protected member of its naming
class&rdquo;).</P>

<P>One possible definition of &ldquo;is public&rdquo; would be
something like, &ldquo;if any visible declaration of the entity
has public access.&rdquo; One could also plausibly define the
access of <TT>m</TT> in <TT>N</TT> to be the minimum of all the
visible declarations, or even an error if the visible
declarations are inconsistent.</P>

<P>11.2&nbsp;



 <A HREF="access.html#class.access.base">class.access.base</A> paragraph 1 describes the access of
inherited members, so a clarifying statement resolving this issue
might plausibly be inserted at the end of that paragraph.</P>

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

<P>Add the following text as a new paragraph after 11.2&nbsp;



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

<BLOCKQUOTE>

<P>If a given base class can be reached along more than one path
through a derived class's sub-object lattice (10.1&nbsp;



 <A HREF="derived.html#class.mi">class.mi</A>), a member of that base class could have different
accessibility in the derived class along different paths.  In
such cases, the most permissive access
prevails. [<I>Example:</I>
</P>

<PRE>
    struct B { static int i; };
    class I: protected B { };
    class D1: public B, public I { };
    class D2: public I, private B { };
</PRE>

<P>
<TT>i</TT> is accessible as a public member of <TT>D1</TT> and
as a protected member of <TT>D2</TT>. &mdash;<I>end
example</I>]</P>

</BLOCKQUOTE>

<P>
<B>Rationale (03/2005):</B> This question is already covered, in
almost identical words, in 11.7&nbsp;



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

<BR>
<BR>
<HR>
<A NAME="209"></A>
<H4>209.
  Must friend declaration names be
accessible?</H4>
<B>Section: </B>11.4&nbsp;



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

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

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

 <B>Date: </B>1 Mar 2000<BR>



<P>
11.4&nbsp;



 <A HREF="access.html#class.friend">class.friend</A>, paragraph 7, says

<BLOCKQUOTE>

A name nominated by a friend declaration shall be accessible in the
scope of the class containing the friend declaration.

</BLOCKQUOTE>
</P>
<P>
Does that mean the following should be illegal?
</P>

<PRE>
    class A { void f(); };
    class B { friend void A::f(); }; // Error: A::f not accessible from B
</PRE>

<P>
I discussed this with Bjarne in email, and he thinks it was an
editorial error and this was not the committee's intention. The
paragraph seems to have been added in the pre-Kona (24 Sept 1996)
mailing, and I could not find anything in the previous meeting's
(Stockholm) mailings which led me to believe this was intentional. The
only compiler vendor which I think currently implements it is the
latest release (2.43) of the EDG front end.
</P>

<P>
<B>Proposed resolution (10/00):</B>
</P>
<P>
Remove the first sentence of 11.4&nbsp;



 <A HREF="access.html#class.friend">class.friend</A>, paragraph 7.
</P>

<P>
<B>Rationale (04/01):</B>
</P>

<P>After the 10/00 vote to accept this issue as a DR with the
proposed resolution, it was noted that the first two sentences
of 11&nbsp;



 <A HREF="access.html#class.access">class.access</A> paragraph 3 cause the proposed change
to have no effect:</P>

<BLOCKQUOTE>

Access control is applied uniformly to all names, whether the names
are referred to from declarations or expressions. [<I>Note:</I> access
control applies to names nominated by <TT>friend</TT> declarations
(11.4&nbsp;



 <A HREF="access.html#class.friend">class.friend</A>) and <I>using-declaration</I>s
(7.3.3&nbsp;



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

</BLOCKQUOTE>

<P>In addition to the obvious editing to the text of the note,
an exception to the blanket statement in the first sentence
would also be required.  However, discussion during the 04/01
meeting failed to produce consensus on exactly <I>which</I> names
in the <TT>friend</TT> declaration should be exempted from the
requirements of access control.</P>

<P>One possibility would be that only the name nominated as
<TT>friend</TT> should be exempt.  However, that approach
would make it impossible to name a function as a friend if it
used private types in its parameters or return type.  Another
suggestion was to ignore access for every name used in a
<TT>friend</TT> declaration.  That approach raised a question
about access within the body of a <TT>friend</TT> function
defined inline in the class body &mdash; the body is part of
the declaration of a function, but references within the body
of a <TT>friend</TT> function should still be subject to the
usual access controls.</P>

<P>Other possibilities were raised, such as allowing the
declaration of a <TT>friend</TT> member function if the
declaration were permissible in its containing class, or
taking the union of the access within the befriending class
and the befriended entity.  However, these suggestions would
have been complex and difficult to specify correctly.</P>

<P>Ultimately it was decided that the original perceived
defect was not sufficiently serious as to warrant the degree
of complexity required to resolve it satisfactorily and the
issue was consequently declared not to be a defect.  It was
observed that most of the problems involved with the current
state of affairs result from inability to declare a
particular member function as a <TT>friend</TT>; in such cases,
an easy workaround is simply to befriend the entire class
rather than the specific member function.</P>

<BR>
<BR>
<HR>
<A NAME="445"></A>
<H4>445.
  
Wording issue on friend declarations
</H4>
<B>Section: </B>11.4&nbsp;



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

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

 <B>Submitter: </B>Risto Lankinen
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>5 Dec 2003<BR>


<P>
Thus says the section
11.4&nbsp;



 <A HREF="access.html#class.friend">class.friend</A>/7 in ISO 14882 C++ standard:</P>
<BLOCKQUOTE>
A name nominated by a friend declaration shall be accessible
<U>in the scope of the class</U> containing the friend declaration.
</BLOCKQUOTE>

<P>The obvious intention of this is to allow a friend declaration to
specify a function (or nested class, enum, etc.) that is declared
"private" or "protected" in its enclosing class.  However, literal
interpretation seems to allow a broader access to the befriended
function by the whole class that is declaring the friendship.</P>

<P>If the rule were interpreted literally as it is currently written, this
would compile (when it, of course, shouldn't be allowed at all):</P>
<PRE>
class C
{
private:
  static void f();
};

class D
{
  friend void C::f();  // A name nominated by friend declaration...

  D()
  {
   C::f();  // ... shall be accessible in scope of class declaring friendship
  }
};
</PRE>

<P>Suggested fix is to reword "in the scope of the class containing
the friend declaration" to exclude all other references from the
scope of the declaring class, except the friend-declaration itself.</P>

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

<P>We considered this and concluded that the standard is clear enough.</P>

<BR>
<BR>
<HR>
<A NAME="501"></A>
<H4>501.
  
Visibility of friend declarations within the befriending class
</H4>
<B>Section: </B>11.4&nbsp;



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

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

 <B>Submitter: </B>Gabriel Dos Reis
 &nbsp;&nbsp;&nbsp;

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




<P>I just received a query from a user of why line #1 in the following
snippet is ill-formed:</P>

<PRE>
    void g(int (*)(int));

    template&lt;class T&gt;
    class A {
       friend int f(int) { return 0; }

       void h() {
           g(f);          // #1
       }
    };
</PRE>

<P>I believe that the special invisibility rule about friends is too
complicated and makes life too complicated, especially considering
that friends in templates are not templates, nor can they be
conveniently rewritten with a &ldquo;first declare at the namespace
scope&rdquo; rule.  I can understand the rules when they make
programming easier or prevent some obvious &ldquo;silly&rdquo;
mistakes; but that does not seem to be the case here.
</P>

<P>
<U>John Spicer</U>: See two papers that discuss this issue: N0878
by Bill Gibbons, which ultimately gave rise to our current rules, and
N0913 by me as an alternative to N0878.</P>

<P>
<B>Rationale (April, 2005):</B>
</P>

<P>The Standard is clear and consistent; this rule is the result of an
explicit decision by the Committee.</P>

<BR>
<BR>
<HR>
<A NAME="19"></A>
<H4>19.
  
Clarify protected member access
</H4>
<B>Section: </B>11.5&nbsp;



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

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

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

 <B>Date: </B>unknown<BR>





<P>11.5&nbsp;



 <A HREF="access.html#class.protected">class.protected</A>
 paragraph 1 says:
<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 ...</BLOCKQUOTE>
Instead of saying "references a protected nonstatic member of a base class",
shouldn't this be rewritten to use the concept of naming class as
11.2&nbsp;



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

paragraph 4 does?</P>

<P>
<B>Rationale (04/99):</B> This rule is orthogonal to the specification
in 11.2&nbsp;



 <A HREF="access.html#class.access.base">class.access.base</A>
 paragraph 4.</P>
<BR>
<BR>
<HR>
<A NAME="117"></A>
<H4>117.
  
Timing of destruction of temporaries
</H4>
<B>Section: </B>12.2&nbsp;



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

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

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

 <B>Date: </B>14 May 1999<BR>





<P>12.2&nbsp;



 <A HREF="special.html#class.temporary">class.temporary</A>
 paragraph 4 seems
self-contradictory:</P>
<BLOCKQUOTE>

the temporary that holds the result of the expression shall persist
until the object's initialization is complete... the temporary
is destroyed after it has been copied, before or when the
initialization completes.

</BLOCKQUOTE>

How can it be destroyed "before the initialization completes" if
it is required to "persist until the object's initialization is
complete?"

<P>
<B>Rationale (04/00):</B>
</P>

<P>It was suggested that "before the initialization completes" refers
to the case in which some part of the initialization terminates by
throwing an exception.  In that light, the apparent contradiction does
not apply.</P>

<BR>
<BR>
<HR>
<A NAME="363"></A>
<H4>363.
  
Initialization of class from self
</H4>
<B>Section: </B>12.6.1&nbsp;



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

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

 <B>Submitter: </B>Sergey P. Derevyago
 &nbsp;&nbsp;&nbsp;

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


<P>Is the following code well-formed?</P>
<PRE>
 struct A { /* */ };

 int main()
 {
  A a=a;
 }
</PRE>
<P>Note, that { int a=a; } is pretty legal.</P>

<P>And if so, what is the semantics of the self-initialization of UDT? For
example</P>
<PRE>
 #include &lt;stdio.h&gt;

 struct A {
        A()           { printf("A::A() %p\n",            this);     }
        A(const A&amp; a) { printf("A::A(const A&amp;) %p %p\n", this, &amp;a); }
        ~A()          { printf("A::~A() %p\n",           this);     }
 };

 int main()
 {
  A a=a;
 }
</PRE>
<P>can be compiled and prints:</P>
<PRE>
A::A(const A&amp;) 0253FDD8 0253FDD8
A::~A() 0253FDD8
</PRE>
<P>(on some implementations).</P>

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

<P>3.8&nbsp;



 <A HREF="basic.html#basic.life">basic.life</A> paragraph 6 indicates that the
references here are valid.  It's permitted to take the address
of a class object before it is fully initialized, and it's
permitted to pass it as an argument to a reference parameter
as long as the reference can bind directly.
Except for the failure to cast the pointers
to <TT>void *</TT> for the <TT>%p</TT> in the <TT>printf</TT>s,
these examples are standard-conforming.</P>

<BR>
<BR>
<HR>
<A NAME="307"></A>
<H4>307.
  
Initialization of a virtual base class subobject
</H4>
<B>Section: </B>12.7&nbsp;



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

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

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

 <B>Date: </B>31 Aug 2001<BR>


<P>The second paragraph of section 12.7&nbsp;



 <A HREF="special.html#class.cdtor">class.cdtor</A> contains the
following text:</P>
<BLOCKQUOTE>
To explicitly or implicitly convert a pointer (an
lvalue) referring to an object of class X to a pointer (reference) to
a direct or indirect base class B of X, the construction of X and the
construction of all of its direct or indirect bases that directly or
indirectly derive from B shall have started and the destruction of
these classes shall not have completed, otherwise the conversion
results in undefined behavior.
</BLOCKQUOTE>

<P>Now suppose we have the following piece of code:</P>
<PRE>
    struct  a  {
       a() :  m_a_data(0)  {   }
       a(const a&amp; rhsa) :  m_a_data(rhsa.m_a_data)  {   }
       int   m_a_data;
    };

    struct  b :  virtual a  {
       b() :  m_b_data(0)  {   }
       b(const b&amp; rhsb) :  a(rhsb),  m_b_data(rhsb.m_b_data)  {   }
       int   m_b_data;
    };

    struct  c :  b  {
       c() :  m_c_data(0)  {   }
       c(const c&amp; rhsc) :  a(rhsc),// Undefined behaviour when constru-
                                   // cting an object of type 'c'
                           b(rhsc),  m_c_data(rhsc.m_c_data)  {   }
       int   m_c_data;
    };

    int  main()
    {   c   ac1,   ac2(ac1);   }
</PRE>   
<P> The problem with the above snippet is that when the value '<TT>ac2</TT>' is
being created and its construction gets started, <TT>c</TT>'s copy constructor
has first to initialize the virtual base class subobject '<TT>a</TT>'. Which
requires that the lvalue expression '<TT>rhsc</TT>' be converted to the type of
the parameter of <TT>a</TT>'s copy constructor,
which is 'const a&amp;'. According
to the wording quoted above, this can be done without undefined
behaviour if and only if <TT>b</TT>'s construction has already started, which
is not possible since '<TT>a</TT>', being a virtual base class, has to be
initialized first by a constructor of the most derived object
(12.6.2&nbsp;



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

<P>The issue could in some cases be alleviated when '<TT>c</TT>' has a
user-defined copy constuctor. The constructor could default-initialize
its '<TT>a</TT>' subobject and then initialize <TT>a</TT>'s members
as needed taking
advantage of the latitude given in paragraph 2 of
12.6.2&nbsp;



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

<P>But if '<TT>c</TT>' ends up having the implicitly-defined copy constuctor,
there's no way to evade undefined behaviour.</P>
<PRE>
    struct  c :  b  {
       c() :  m_c_data(0)  {   }
       int   m_c_data;
    };

    int  main()
    {   c   ac1,   ac2(ac1);   }
</PRE>
<P>Paragraph 8 of 12.8&nbsp;



 <A HREF="special.html#class.copy">class.copy</A> states</P>
<BLOCKQUOTE>
The
implicitly-defined copy constructor for class X performs a memberwise
copy of its subobjects. The order of copying is the same as the order
of initialization of bases and members in a user-defined constructor
(see 12.6.2&nbsp;



 <A HREF="special.html#class.base.init">class.base.init</A>).
Each subobject is copied in the manner appropriate to
its type:
<UL>
<LI>
if the subobject is of class type, the copy constructor for the
class is used;
</LI>
</UL>
</BLOCKQUOTE>
<P>Which effectively means that the implicitly-defined copy constructor
for '<TT>c</TT>' will have to initialize its '<TT>a</TT>'
base class subobject first and
that must be done with <TT>a</TT>'s copy constructor, which will always require
a conversion of an lvalue expression of type '<TT>const c</TT>' to an lvalue of
type '<TT>const a&amp;</TT>'. The situation would be the same if all the three
classes shown had implicitly-defined copy constructors.</P>

<P>
<B>Suggested resolution:</B>
</P>
<P>Prepend to paragraph 2 of 12.7&nbsp;



 <A HREF="special.html#class.cdtor">class.cdtor</A> the following:
<BLOCKQUOTE>
Unless the conversion happens in a mem-initializer whose
mem-initializer-id designates a virtual base class of X, to explicitly
or implicitly convert ...
</BLOCKQUOTE>
</P>

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

<P>There is no problem in this example.  <TT>ac1</TT> is fully initialized
before it is used in the initialization of <TT>ac2</TT>.</P>

<BR>
<BR>
<HR>
<A NAME="26"></A>
<H4>26.
  
Copy constructors and default arguments
</H4>
<B>Section: </B>12.8&nbsp;



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

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

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

 <B>Date: </B>22 Sep 1997<BR>





<P>The working paper is quite explicit about</P>
<PRE>
    struct X {
         X(X, X const&amp; = X());
    };
</PRE>
being illegal (because of the chicken &amp; egg problem wrt copying.)

<P>Shouldn't it be as explicit about the following?</P>
<PRE>
    struct Y {
        Y(Y const&amp;, Y = Y());
    };
</PRE>
<B>Rationale:</B>
There is no need for additional wording. This example leads to
a program which either fails to compile (due to resource limits on recursive
inlining) or fails to run (due to unterminated recursion). In either case
the implementation may generate an error when the program is compiled.
<BR>
<BR>
<HR>
<A NAME="356"></A>
<H4>356.
  
Wording of behavior of generated copy constructor for scalar members
</H4>
<B>Section: </B>12.8&nbsp;



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

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

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

 <B>Date: </B>25 May 2002<BR>




<P>Section 12.8&nbsp;



 <A HREF="special.html#class.copy">class.copy</A> paragraph 8 says the
compiler-generated copy constructor copies
scalar elements via the built-in assignment operator.
Seems inconsistent. Why not the built-in initialization?</P>

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

<P>The Core Working Group believes this should not be changed.  The
standard already mentions <I>built-in operators</I> and the
assignment operator does clearly define what must be done for
scalar types.  There is currently no concept of
<I>built-in initialization</I>.</P>

<BR>
<BR>
<HR>
<A NAME="444"></A>
<H4>444.
  
Overriding and the generated copy assignment operator
</H4>
<B>Section: </B>12.8&nbsp;



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

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

 <B>Submitter: </B>Kerch Holt
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>26 Nov 2003<BR>


<P>EDG (and g++, for that matter) picks the explicit copy assignment
operator, which we think is wrong in this case:</P>
<PRE>
#include &lt;stdio.h&gt;
struct D;   // fwd declaration
struct B {
    D&amp; operator=(D&amp;);
};
struct D : B {
    D() {}
    D(int ii) { s = ii; }
    using B::operator=;
    int s;
};
int main() {
    D od, od1(10);
    od = od1; // implicit D::operator=(D&amp;) called, not BASE::operator=(D&amp;)
}
D&amp; B::operator=(D&amp; d) { 
    printf("B::operator called\n");
    return d;
}
</PRE>

<P>If you look at 12.8&nbsp;



 <A HREF="special.html#class.copy">class.copy</A> paragraph 10 it
explicitly states that
in such a case the "using B::operator=" will not be considered.</P>

<P>
<U>Steve Adamczyk:</U>
The fact that the operator= you declared is (D&amp;) and not (const D&amp;)
is fooling you.  As the standard says, the operator= introduced
by the using-declaration does not suppress the generation of
the implicit operator=.  However, the generated operator= has the 
(const D&amp;) signature, so it does not hide B::operator=;
it overloads it.</P>

<P>
<U>Kerch Holt:</U>
I'm not sure this is correct. Going by 12.8 P10 first paragraph
we think that the other form "operator=(D&amp;)" is generated because
the two conditions mentioned were not met in this case.
1) there is no direct base with a "const [volatile] B&amp;" or "B" operator
2) And no member has a operator= either.
This implies the implicit operator is "operator=(D&amp;)".
So, if that is the case the "hiding" should happen.</P>

<P>Also, in the last paragraph it seems to state that operators
brought in from "using", no matter what the parameter is, are
always hidden.</P>

<P>
<U>Steve Adamczyk:</U>
Not really.  I think this section is pretty clear about the fact that
the implicit copy assignment operator is generated.  The question is whether it
hides or overloads the one imported by the using-declaration.</P>

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

<P>(a) Class B does get an implicitly-generated
<TT>operator=(const B&amp;)</TT>; (b) the using-declaration brings in
two <TT>operator=</TT> functions from B, the explicitly-declared
one and the implicitly-generated one; (c) those two functions overload 
with the implicitly-generated <TT>operator=(const D&amp;)</TT> in
the derived class, rather than being hidden by the derived-class
function, because it does not match either of their signatures;
(d) overload resolution picks the explicitly-declared
function from the base class because it's the best match in this
case.  We think the standard wording says this clearly enough.</P>
<BR>
<BR>
<HR>
<A NAME="102"></A>
<H4>102.
  
Operator lookup rules do not work well with parts of the library
</H4>
<B>Section: </B>13.3.1.2&nbsp;



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

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

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

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





<P>
The following example does not work as one might expect:</P>
<PRE>
    namespace N { class C {}; }
    int operator +(int i, N::C) { return i+1; }

    #include &lt;numeric&gt;
    int main() {
        N::C a[10];
        std::accumulate(a, a+10, 0);
    }
</PRE>
According to
3.4.1&nbsp;



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

paragraph 6, I would expect that the "+" call inside
<TT>std::accumulate</TT> would find the global <TT>operator+</TT>.
Is this true, or am I
missing a rule? Clearly, the <TT>operator+</TT> would be found by Koenig lookup
if it were in namespace <TT>N</TT>.
<P>
<U>Daveed Vandevoorde</U>:

But doesn't unqualified lookup of
the <TT>operator+</TT> in the definition
of <TT>std::accumulate</TT> proceed in the namespace where the implicit
specialization is generated; i.e., in namespace <TT>std</TT>?</P>
<P>
In that case, you may find a non-empty overload set for <TT>operator+</TT>
in namespace <TT>std</TT> and the surrounding (global) namespace is no longer
considered?</P>
<P>
<U>Nathan Myers</U>:

Indeed, <TT>&lt;string&gt;</TT> defines <TT>operator+</TT>,
as do <TT>&lt;complex&gt;</TT>, <TT>&lt;valarray&gt;</TT>,
and <TT>&lt;iterator&gt;</TT>.  Any of these might hide the global operator.</P>
<P>
<U>Herb Sutter</U>:

These examples fail for the same reason:</P>
<PRE>
    struct Value { int i; };

    typedef map&lt;int, Value &gt; CMap;
    typedef CMap::value_type CPair;

    ostream &amp; operator&lt;&lt; ( ostream &amp;os, const CPair &amp;cp )
      { return os &lt;&lt; cp.first &lt;&lt; "/" &lt;&lt; cp.second.i; }

    int main() {
      CMap courseMap;
      copy( courseMap.begin(), courseMap.end(),
            ostream_iterator&lt;CPair&gt;( cout, "\n" ) );
    }

    template&lt;class T, class S&gt;
    ostream&amp; operator&lt;&lt; (ostream&amp; out, pair&lt;T,S&gt; pr)
      { return out &lt;&lt; pr.first &lt;&lt; " : " &lt;&lt; pr.second &lt;&lt; endl; }

    int main() {
      map &lt;int, string&gt; pl;
      copy( pl.begin(), pl.end(),
            ostream_iterator &lt;places_t::value_type&gt;( cout, "\n" ) );
    }
</PRE>
This technique (copying from a map to another container or stream)
should work. If it really cannot be made to work, that would seem broken
to me. The reason is does not work is that <TT>copy</TT> and <TT>pair</TT> are in
namespace <TT>std</TT> and the name lookup rules do not permit the global
<TT>operator&lt;&lt;</TT> to be found because the other <TT>operator&lt;&lt;</TT>'s
in namespace <TT>std</TT>
hide the global operator. (Aside: FWIW, I think most programmers don't
realize that a typedef like <TT>CPair</TT> is actually in namespace <TT>std</TT>, and not
the global namespace.)
<P>
<U>Bill Gibbons</U>: It looks like part of this problem is that the library
is referring to names which it requires the client to declare in the global namespace
(the operator names) while also declaring those names in namespace <TT>std</TT>.
This would be considered very poor design for plain function names; but the
operator names are special.</P>
<P>
There is a related case in the lookup of operator conversion functions.  The
declaration of a conversion function in a derived class does not hide any
conversion functions in a base class unless they convert to the same type.
Should the same thing be done for the lookup of operator function names,
e.g. should an operator name in the global namespace be visible in namespace
<TT>std</TT> unless there is a matching declaration in <TT>std</TT>?</P>
<P>
Because the operator function names are fixed, it it much more likely that
a declaration in an inner namespace will accidentally hide a declaration
in an outer namespace, and the two declarations are much less likely to
interfere with each other if they are both visible.</P>
<P>The lookup rules for operator names (when used implicitly) are already
quite different from those for ordinary function names.  It might be worthwhile
to add one more special case.</P>

<P>
<U>Mike Ball</U>

:  The original SGI proposal said that non-transitive points of
instantiation were also considered. Why, when, and by whom was it added?</P>

<P>
<B>Rationale (10/99):</B> This appears to be mainly a program
design issue.  Furthermore, any attempt to address it in the core
language would be beyond the scope of what can be done in a
Technical Corrigendum.</P>
<BR>
<BR>
<HR>
<A NAME="423"></A>
<H4>423.
  
Can a conversion be done on the left operand of a compound assignment?
</H4>
<B>Section: </B>13.3.1.2&nbsp;



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

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

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

 <B>Date: </B>19 Jun 2003<BR>


<P>Is the following well-formed?</P>
<PRE>
  template &lt;typename T&gt;
  class test
  {
  public:
    operator T&amp; (){ return m_i; }
  private:
    T m_i;
  }; 
  int main()
  {
    test&lt;int*&gt; t2;
    t2 += 1;  // Allowed?
  }
</PRE>
<P>Is it possible that by "assignment operators"
(13.3.1.2&nbsp;



 <A HREF="over.html#over.match.oper">over.match.oper</A> paragraph 4) only the built-in
candidates for operator= (i.e. excluding +=, *=, etc.) were meant? On one hand
the plural ("operators") seems to imply that all the assignment operators are
considered. OTOH, there has already been a core DR (221) about a missing
distinction between "assignment operator" and "compound assignment operators".
Is there a similar defect here?</P>

<P>
<U>Steve Adamczyk:</U>
The standard is ambiguous.  However,
I think the ARM was fairly clear about "assignment operators" meaning only
"=", and I find that Cfront 3.0.1 accepts the test case (with typename
changed to class).  I don't know whether that's good or bad, but it's
at least a precedent.  Given the change of
<A HREF="
     cwg_defects.html#221">Core Issue 221</A>, if we do nothing
further conversions are valid on += and therefore this case is valid.</P>

<P>Note that "<TT>t2++;</TT>" is unquestionably valid, so one could
also argue for the status quo (post-221) on the basis of consistency.</P>

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

<P>We believe the example is well-formed, and no change other than
that in issue 221 is needed.</P>

<BR>
<BR>
<HR>
<A NAME="243"></A>
<H4>243.
  
Weighting of conversion functions in direct-initialization
</H4>
<B>Section: </B>13.3.3.1.2&nbsp;



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

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

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

 <B>Date: </B>5 Sep 2000<BR>




<P>There is a moderately serious problem with
the definition of overload resolution.  Consider this example:</P>

<PRE>
    struct B;
    struct A {
        A(B);
    };
    struct B {
        operator A();
    } b;
    int main() {
        (void)A(b);
    }
</PRE>

<P>This is pretty much the definition of "ambiguous," right?  You want
to convert a <TT>B</TT> to an <TT>A</TT>, and there are two equally
good ways of doing that: a constructor of <TT>A</TT> that takes a
<TT>B</TT>, and a conversion function of <TT>B</TT> that returns an
<TT>A</TT>.</P>

<P>What we discover when we trace this through the standard,
unfortunately, is that the constructor is favored over the conversion
function.  The definition of direct-initialization (the parenthesized
form) of a class considers only constructors of that class.  In this
case, the constructors are the <TT>A(B)</TT> constructor and the
(implicitly-generated) <TT>A(const A&amp;)</TT> copy constructor.
Here's how they are ranked on the argument match:</P>

<TABLE BORDER="1" CELLSPACING="0" CELLPADDING="4">
<TR>
<TD><TT>A(B)</TT></TD>
<TD>exact match (need a <TT>B</TT>, have a <TT>B</TT>)</TD>
</TR>
<TR>
<TD><TT>A(const A&amp;)</TT></TD>
<TD>user-defined conversion (<TT>B::operator A</TT> used to
convert <TT>B</TT> to <TT>A</TT>)</TD>
</TR>
</TABLE>

<P>In other words, the conversion function does get considered, but
it's operating with, in effect, a handicap of one user defined
conversion.  To put that a different way, this problem is a problem of
weighting, not a problem that certain conversion paths are not
considered.</P>

<P>I believe the reason that the
standard's approach doesn't yield the "intuitive" result is
that programmers expect copy constructor elision
to be done whenever reasonable, so the intuitive cost of using
the conversion function in the example above is simply the cost
of the conversion function, not the cost of the conversion function
plus the cost of the copy constructor (which is what the standard
counts).</P>

<P>
<U>Suggested resolution:</U>
</P>

<P>In a direct-initialization overload
resolution case, if the candidate function being called is a copy
constructor and its argument (after any implicit conversions) is a
temporary that is the return value of a conversion function, and the
temporary can be optimized away, the cost of the argument match for
the copy constructor should be considered to be the cost of the
argument match on the conversion function argument.</P>

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

<P>It turns out that there is existing practice both ways on this
issue, so it's not clear that it is "broken". There is some reason to
feel that something that looks like a "constructor call" should call a
constructor if possible, rather than a conversion function.
The CWG decided to leave it alone.</P>

<BR>
<BR>
<HR>
<A NAME="61"></A>
<H4>61.
  
Address of static member function "<TT>&amp;p-&gt;f</TT>"
</H4>
<B>Section: </B>13.4&nbsp;



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

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

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

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



<P>Can <TT>p-&gt;f</TT>, where <TT>f</TT> refers to a set of overloaded functions
all of which are static member functions, be used as an expression in an
address-of-overloaded-function context? A strict reading of this
section suggests "no", because "<TT>p-&gt;f</TT>" is not the name of an overloaded
function (it's an expression). I'm happy with that, but the core
group should decide and should add an example to document the decision,
whichever way it goes.</P>

<P>
<B>Rationale (10/99):</B> The "strict reading" correctly reflects
the intent of the Committee, for the reason given, and no clarification
is required.</P>
<BR>
<BR>
<HR>
<A NAME="247"></A>
<H4>247.
  
Pointer-to-member casts and function overload resolution
</H4>
<B>Section: </B>13.4&nbsp;



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

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

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

 <B>Date: </B>22 Sep 2000<BR>




<P>It is unclear whether the following code is well-formed or not:</P>

<PRE>
    class A { }; 

    struct B : public A
    { 
	void foo (); 
	void foo (int);
    }; 

    int main ()
    {
	void (A::*f)() = (void (A::*)())&amp;B::foo;
    }
</PRE>

<P>13.4&nbsp;



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

<BLOCKQUOTE>

The function selected is the one whose type matches the target
type required in the context.  The target can be

<UL>

<LI>
<B>...</B>
</LI>

<LI>an explicit type conversion (5.2.3&nbsp;



 <A HREF="expr.html#expr.type.conv">expr.type.conv</A>,
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>).</LI>

</UL>

</BLOCKQUOTE>

<P>This would appear to make the program ill-formed, since the
type in the cast is different from that of either interpretation
of the address-of-member expression (its class is <TT>A</TT>,
while the class of the address-of-member expression is <TT>B</TT>)</P>

<P>However, 13.4&nbsp;



 <A HREF="over.html#over.over">over.over</A> paragraph 3 says,</P>

<BLOCKQUOTE>

Nonstatic member functions match targets of type
"pointer-to-member-function;" the function type of the pointer
to member is used to select the member function from the set
of overloaded member functions.

</BLOCKQUOTE>

<P>The class of which a function is a member is <B>not</B> part of the
"function type" (8.3.5&nbsp;



 <A HREF="decl.html#dcl.fct">dcl.fct</A> paragraph 4).
Paragraph 4 is thus either a misuse of the phrase "function type," a
contradiction of paragraph 1, or an explanation of what "matching
the target type" means in the context of a pointer-to-member
target.  By the latter interpretation, the example is well-formed
and <TT>B::foo()</TT> is selected.</P>

<P>
<U>Bill Gibbons</U>: I think this is an accident due to vague
wording.  I think the intent was</P>

<BLOCKQUOTE>

The function selected is the one which will make the effect of
the cast be that of the identity conversion.

</BLOCKQUOTE>

<P>
<U>Mike Miller</U>: The "identity conversion" reading seems
to me to be overly restrictive.  It would lead to the following:</P>

<PRE>
    struct B {
        void f();
        void f(int);
    };
    struct D: B { };
    void (D::* p1)() = &amp;D::f;                  // ill-formed
    void (D::* p2)() = (void (B::*)()) &amp;D::f;  // okay
</PRE>

<P>I would find the need for an explicit cast here surprising, since
the downcast is a standard conversion and since the declaration of
<TT>p1</TT> certainly has enough information to disambiguate the
overload set.  (See also <A HREF="
     cwg_active.html#203">issue 203</A>.)</P>

<P>
<U>Bill Gibbons</U>: There is an interesting situation with
<I>using-declaration</I>s.  If a base class member function is present
in the overload set in a derived class due to a
<I>using-declaration</I>, it is treated as if it were a derived class
member function for purposes of overload resolution in a call
(13.3.1&nbsp;



 <A HREF="over.html#over.match.funcs">over.match.funcs</A> paragraph 4):</P>

<BLOCKQUOTE>

For non-conversion functions introduced by a <I>using-declaration</I>
into a derived class, the function is considered to be a member of the
derived class for the purpose of defining the type of the implicit
object parameter

</BLOCKQUOTE>

<P>There is no corresponding rule for casts. Such a rule would be
practical, but if the base class member function were selected it
would not have the same class as that specified in the cast.  Since
base-to-derived pointer to member conversions are implicit
conversions, it would seem reasonable to perform this conversion
implicitly in this case, so that the result of the cast has the right
type.  The usual ambiguity and access restrictions on the
base-to-derived conversion would not apply since they do not apply to
calling through the <I>using-declaration</I> either.</P>

<P>On the other hand, if there is no special case for this, we end up with
the bizarre case:</P>

<PRE>
    struct A {
        void foo();
    };
    struct B : A {
        using A::foo;
        void foo(int);
    }
    int main() {
        // Works because "B::foo" contains A::foo() in its overload set.
        (void (A::*)())&amp;B::foo;
        // Does not work because "B::foo(int)" does not match the cast.
        (void (A::*)(int))&amp;B::foo;
    }
</PRE>

<P>I think the standard should be clarified by either:</P>

<UL>

<LI>
<P>Adding a note to 13.4&nbsp;



 <A HREF="over.html#over.over">over.over</A> saying that
<I>using-declaration</I>s do not participate
in this kind of overload resolution; or</P>
</LI>

<LI>
<P>Modifying 13.4&nbsp;



 <A HREF="over.html#over.over">over.over</A> saying that
<I>using-declaration</I>s are treated as members of the derived class
for matching purposes, and if selected, the resulting pointer to
member is implicitly converted to the derived type with no access or
ambiguity errors.  (The <I>using-declaration</I> itself has already
addressed both of these areas.)</P>
</LI>

</UL>

<P>
<B>Rationale (10/00):</B> The cited example is well-formed.
The function type, ignoring the class specification, is used to
select the matching function from the overload set as specified
in 13.4&nbsp;



 <A HREF="over.html#over.over">over.over</A> paragraph 3.  If the target
type is supplied by an explicit cast, as here, the conversion is
then performed on the selected pointer-to-member value, with the
usual restrictions on what can and cannot be done with the
converted value (5.2.9&nbsp;



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



 <A HREF="expr.html#expr.reinterpret.cast">expr.reinterpret.cast</A> paragraph 9).</P>

<BR>
<BR>
<HR>
<A NAME="27"></A>
<H4>27.
  
Overload ambiguities for builtin ?: prototypes
</H4>
<B>Section: </B>13.6&nbsp;



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

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

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

 <B>Date: </B>25 Sep 1997<BR>





<P>I understand that the lvalue-to-rvalue conversion was removed in London.
I generally agree with this, but it means that <TT>?:</TT> needs to be
fixed:</P>

<P>Given:</P>
<PRE>
    bool test;
    Integer a, b;
    test ? a : b;
</PRE>
What builtin do we use? The candidates are
<PRE>
    operator ?:(bool, const Integer &amp;, const Integer &amp;)
    operator ?:(bool, Integer, Integer)
</PRE>
which are both perfect matches.

<P>(Not a problem in FDIS, but misleading.)</P>

<P>
<B>Rationale:</B>
The description of the conditional operator in
5.16&nbsp;



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

handles the lvalue case before the prototype is considered.</P>
<BR>
<BR>
<HR>
<A NAME="552"></A>
<H4>552.
  
Use of <TT>typename</TT> in the type in a non-type <I>parameter-declaration</I>
</H4>
<B>Section: </B>14.2&nbsp;



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

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

 <B>Submitter: </B>Andre Morozov
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>15 December 2005<BR>


<P>The discussion in of the use of <TT>typename</TT> with a
<I>qualified-id</I> in a template <I>parameter-declaration</I> in
14.2&nbsp;



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

<BLOCKQUOTE>

<TT>typename</TT> followed by an <I>unqualified-id</I> names a
template type parameter. <TT>typename</TT> followed by
a <I>qualified-id</I> denotes the type in a non-type
<I>parameter-declaration</I>.

</BLOCKQUOTE>

<P>This rule would be clearer if the <I>unqualified-id</I> case were
described in terms of resolving the ambiguity of declaring a
template parameter name versus referring to a <I>type-name</I>
from the enclosing scope, and if the <I>qualified-id</I> case
referred to the use of the <TT>typename</TT> keyword with
dependent types in 14.6&nbsp;



 <A HREF="template.html#temp.res">temp.res</A>.  An example would
also be helpful.</P>

<P>
<B>Rationale (April, 2006):</B>
</P>

<P>The CWG felt that the wording was already clear enough.</P>

<BR>
<BR>
<HR>
<A NAME="114"></A>
<H4>114.
  
Virtual overriding by template member function specializations
</H4>
<B>Section: </B>14.5.2&nbsp;



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

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

 <B>Submitter: </B>Bill Gibbons
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>7 May 1999<BR>





<P>According to 14.5.2&nbsp;



 <A HREF="template.html#temp.mem">temp.mem</A>
 paragraph 4,</P>
<BLOCKQUOTE>
A specialization of a member function template does not override
a virtual function from a base class.
</BLOCKQUOTE>

<B>Bill Gibbons:</B>
I think that's sufficiently surprising behavior that it should be ill-formed
instead.

<P>As I recall, the main reason why a member function template cannot be
virtual is that you can't easily construct reasonable vtables for an
infinite set of functions.  That doesn't apply to overrides.</P>

<P>Another problem is that you don't know that a specialization overrides
until the specialization exists:</P>
<PRE>
    struct A {
        virtual void f(int);
    };
    struct B : A {
        template&lt;class T&gt; void f(T);  // does this override?
    };
</PRE>
But this could be handled by saying:
<UL>
<LI>If deduction using the type of an overridable function in
a base class succeeds, the template is implicitly specialized
to provide the override.</LI>

<LI>If this yields more than one override for a function, the program
is ill-formed.</LI>

<LI>If a specialization due to explicit template arguments creates
an override that did not previously exist, the program is
ill-formed.  (Or alternatively, it is not an override.)</LI>
</UL>

The last case might only involve non-deducible contexts, e.g.
<PRE>
    template&lt;int I&gt; struct X;
    struct A {
        virtual void f(A&lt;5&gt;);
    };
    struct B : A {
        template&lt;int I, int J&gt; void f(A&lt;I+J&gt;);  // does not overrride
    };

    void g(B *b) {
        X&lt;t&gt; x;
        b-&gt;f&lt;3,2&gt;(x);  // specialization B::f(A&lt;5&gt;) makes program ill-formed
    }
</PRE>
So I think there are reasonable semantics.  But is it useful?

<P>If not, I think the creation of a specialization that would have been
an override had it been declared in the class should be an error.</P>

<P>
<B>Daveed Vandevoorde:</B>
There is real code out there that is written with this rule
in mind. Changing the standard on them would not be good
form, IMO.</P>

<P>
<B>Mike Ball:</B>
Also, if you allow template functions to be specialized outside
of the class you introduce yet another non-obvious ordering constraint.</P>

<P>Please don't make such a change after the fact.</P>

<P>
<B>John Spicer:</B> This is the result of an explicit committee
decision.  The reason for this rule is that it is too easy to
unwittingly override a function from a base class, which was probably
not what was intended when the template was written.  Overriding
should be a conscious decision by the class writer, not something done
accidentally by a template.</P>

<P>
<B>Rationale (10/99):</B> The Standard correctly reflects the
intent of the Committee.</P>

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

<P>
This was reopened because of a discussion while reviewing possible
extensions.</P>



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

<P>This was discussed again, and the consensus was that we did
not want to make a change, and in particular we did not want to
make it an error and risk breaking existing code.
</P>

<BR>
<BR>
<HR>
<A NAME="47"></A>
<H4>47.
  
Template friend issues
</H4>
<B>Section: </B>14.5.3&nbsp;



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

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

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

 <B>Date: </B>7 Nov 1997<BR>




<P>
<U>Issue 1</U>
</P>

<P>Paragraph 1 says that a friend of a class template can be a template.
Paragraph 2 says: A friend template may be declared within a non-template
class. A friend function template may be defined within a non-template
class.</P>

<P>I'm not sure what this wording implies about friend template definitions
within template classes. The rules for class templates and normal classes
should be the same: a function template can be declared or defined, but
a class template can only be declared in a friend declaration.</P>

<P>
<U>Issue 2</U>
</P>

<P>Paragraph 4 says: When a function is defined in a friend function declaration
in a class template, the function is defined when the class template is
first instantiated. I take it that this was intended to mean that a function
that is defined in a class template is not defined until the first instantiation.
I think this should say that a function that is defined in a class template
is defined each time the class is instantiated. This means that a function
that is defined in a class template must depend on all of the template
parameters of the class template, otherwise multiple definition errors
could occur during instantiations. If we don't have a rule like this, compilers
would have to compare the definitions of functions to see whether they
are the same or not. For example:</P>
<PRE>
    template &lt;class T&gt; struct A {
            friend int f() { return sizeof(T); }
    };
    
    A&lt;int&gt; ai;
    A&lt;long&gt; ac;
</PRE>
I hope we would all agree that this program is ill-formed, even if long
and int have the same size.

<P>
<U>From Bill Gibbons:</U>
</P>

<P>[1] That sounds right.</P>

<P>[2] Whenever possible, I try to treat instantiated class templates as
if they were ordinary classes with funny names. If you write:</P>
<PRE>
    struct A_int {
        friend int f() { return sizeof(int); }
    };
    struct A_long {
        friend int f() { return sizeof(long); }
    };
</PRE>
it is a redefinition (which is not allowed) and an ODR violation. And if
you write:
<PRE>
    template &lt;class T, class U&gt; struct A {
                friend int f() { return sizeof(U); }
    };
    
    A&lt;int,float&gt; ai;
    A&lt;long,float&gt; ac;
</PRE>
the corresponding non-template code would be:
<PRE>
    struct A_int_float {
        friend int f() { return sizeof(float); }
    };
    struct A_long_float {
        friend int f() { return sizeof(float); }
    };
</PRE>
then the two definitions of "<TT>f</TT>" are identical so there is no ODR
violation, but it is still a redefinition. I think this is just an editorial
clarification.

<P>
<B>Rationale (04/99):</B> The first sub-issue reflects wording that was
changed to address the concern before the IS was issued.  A close and
careful reading of the Standard already leads to the conclusion that the
example in the second sub-issue is ill-formed, so no change is needed.</P>
<BR>
<BR>
<HR>
<A NAME="316"></A>
<H4>316.
  
Injected-class-name of template used as template template parameter
</H4>
<B>Section: </B>14.6.1&nbsp;



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

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

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

 <B>Date: </B>14 Oct 2001<BR>




<P>A gcc hacker recently sent in a patch to make the compiler give an error on
code like this:
<PRE>
  template &lt;template &lt;typename&gt; class T&gt; struct A { };

  template &lt;typename U&gt; struct B
  {
    A&lt;B&gt; *p;
  };
</PRE>
presumably because the DR from <A HREF="
     cwg_defects.html#176">issue 176</A>
says that we decide whether or not
B is to be treated as a template depending on whether a
template-argument-list is supplied.  I think this is a drafting oversight,
and that B should also be treated as a template when passed as a template
template parameter.  The discussion in the issue list only talks about
making the name usable both as a class and as a template.</P>

<P>
<U>John Spicer</U>:
This case was explicitly discussed and it was agreed that to use the injected
name as a template template parameter you need to use the non-injected
name.</P>

<P>A (possibly unstated) rule that I've understood about template
arguments is that
the form of the argument (type/nontype/template) is based only on the
argument and not on the kind of template parameter.  An example is that
"<TT>int()</TT>" is always "function taking no arguments returning int"
and never a convoluted way of saying zero.</P>

<P>In a similar way, we now decide whether or not something is a template based
only on the form of the argument.</P>

<P>I think this rule is important for two kinds of cases.  The first case
involves explicit arguments of function templates:</P>
<PRE>
  template &lt;template &lt;typename&gt; class T&gt; void f(){} // #1
  template &lt;class T&gt; void f(){}  // #2

  template &lt;typename U&gt; struct B {
	void g() {
		f&lt;B&gt;();
	}
  };

  int main() {
	B&lt;int&gt; b;
	b.g();
  }
</PRE>
<P>With the current rules, this uses B as a type argument to template #2.</P>

<P>The second case involves the use of a class template for which the template
parameter list is unknown at the point where the argument list is scanned:</P>
<PRE>
  template &lt;class T&gt; void f(){}

  template &lt;typename U&gt; struct B {
	void g() {
		f&lt; U::template X&lt;B&gt; &gt;();  // what is B?
	}
  };

  struct Z1 {
	template &lt;class T&gt; struct X {};
  };

  struct Z2 {
	template &lt;template &lt;class&gt; class T&gt; struct X {};
  };

  int main() {
	B&lt;Z1&gt; b1;
	b1.g();

	B&lt;Z2&gt; b2;
	b2.g();
  }
</PRE>
<P>If B could be used as a template name we would be
unable to decide how to treat
B at the point that it was scanned in the template argument list.</P>

<P>So, I think it is not an oversight and that it should be
left the way it is.</P>

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

It was agreed that this is Not a Defect.

<BR>
<BR>
<HR>
<A NAME="544"></A>
<H4>544.
  
Base class lookup in explicit specialization
</H4>
<B>Section: </B>14.6.2&nbsp;



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

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

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

 <B>Date: </B>01 November 2005<BR>


<P>There is some question as to whether 14.6.2&nbsp;



 <A HREF="template.html#temp.dep">temp.dep</A>
paragraph 3 applies to the definition of an explicitly-specialized
member of a class template:</P>

<BLOCKQUOTE>

In the definition of a class template or a member of a class template,
if a base class of the class template depends on
a <I>template-parameter</I>, the base class scope is not examined
during unqualified name lookup either at the point of definition of
the class template or member or during an instantiation of the class
template or member.

</BLOCKQUOTE>

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

<PRE>
    template &lt;class T&gt;
    struct A {
     void foo() {}
    };

    template &lt;class T&gt;
    struct B: A&lt;T&gt; {
     int bar();
    };

    int foo() { return 0; }

    template &lt;&gt;
    int B&lt;int&gt;::bar() { return foo(); }

    int main() {
     return B&lt;int&gt;().bar();
    }
</PRE>

<P>Does <TT>foo</TT> in the definition of <TT>B&lt;int&gt;::bar()</TT>
refer to <TT>::foo()</TT> or to <TT>A&lt;int&gt;::foo()</TT>?</P>

<P>
<B>Rationale (April, 2006):</B>
</P>

<P>An explicitly-specialized member of a class template is not, in
fact, a member of a class template but a member of a particular
specialization of that template.  The special treatment of lookup
vis-a-vis dependent base classes in 14.6.2&nbsp;



 <A HREF="template.html#temp.dep">temp.dep</A>
thus does not apply, and base class members are found by unqualified
name lookup.</P>

<BR>
<BR>
<HR>
<A NAME="334"></A>
<H4>334.
  
Is a comma-expression dependent if its first operand is?
</H4>
<B>Section: </B>14.6.2.2&nbsp;



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

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

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

 <B>Date: </B>10 Jan 2002<BR>


<P>Is the comma expression in the following dependent?</P>
<PRE>
  template &lt;class T&gt; static void f(T)
  {
  }
  template &lt;class T&gt; void g(T)
  {
    f((T::x, 0));
  }
  struct A {
    static int x;
  };
  void h()
  {
    g(A());
  }
</PRE>
<P>According to the standard, it is, because 14.6.2.2&nbsp;



 <A HREF="template.html#temp.dep.expr">temp.dep.expr</A>
says that an expression is dependent if any of its sub-expressions is
dependent, but there is a question about whether the language should
say something different.  The type and value of the expression are not really
dependent, and similar cases (like casting <TT>T::x</TT>
to <TT>int</TT>) are not dependent.</P>

<P>
<U>Mark Mitchell:</U> If the first operand is dependent, how
do we know it does not have an overloaded comma operator?</P>

<P>
<B>Rationale (October, 2004):</B>
</P>

<P>CWG agreed that such comma expressions are and ought to be
dependent, for the reason expressed in Mark Mitchell's
comment.</P>

<BR>
<BR>
<HR>
<A NAME="34"></A>
<H4>34.
  
Argument dependent lookup and points of instantiation
</H4>
<B>Section: </B>14.7.1&nbsp;



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

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

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

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


    

    
<P>Does Koenig lookup create a point of instantiation for class types?
I.e., if I say:</P>
<PRE>
    TT&lt;int&gt; *p;
    f(p);
</PRE>
The namespaces and classes associated with <TT>p</TT> are those associated with
the type pointed to, i.e., <TT>TT&lt;int&gt;</TT>. However, to determine those
I need to know <TT>TT&lt;int&gt;</TT> bases and its friends, which requires
instantiation.

<P>Or should this be special cased for templates?</P>

<P>
<B>Rationale:</B>
The standard already specifies that this creates a point of instantiation.</P>
<BR>
<BR>
<HR>
<A NAME="489"></A>
<H4>489.
  
Must member function templates be instantiated during overload resolution?
</H4>
<B>Section: </B>14.7.1&nbsp;



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

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

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

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


<P>A related question to that raised in <A HREF="
     cwg_active.html#488">issue 488</A> is whether member function templates must be
instantiated if the compiler can determine that they will not be
needed by the function selected by overload resolution.  That is
explicitly specified for class templates in 14.7.1&nbsp;



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

<BLOCKQUOTE>

If the overload resolution process can determine the correct function
to call without instantiating a class template definition, it is
unspecified whether that instantiation actually takes place.

</BLOCKQUOTE>

<P>Should the same be true for member function templates?  In the
example from <A HREF="
     cwg_active.html#488">issue 488</A>,</P>

<PRE>
    struct S {
        template &lt;typename T&gt; S(const T&amp;);
    };
    void f(const S&amp;);
    void f(int);
    void g() {
        enum E { e };
        f(e);    // ill-formed?
    }
</PRE>

<P>a compiler could conceivably determine that <TT>f(int)</TT>
would be selected by overload resolution (because it involves
only an integral promotion, while the alternative requires a
user-defined conversion) without instantiating the declaration of
the <TT>S</TT> constructor.  Should the compiler have that
freedom?</P>

<P>
<B>Rationale (April, 2005):</B>
</P>

<P>In order for this question to come up, there would need to be a
&ldquo;gap&rdquo; between the the normal rules and the rules for
template argument deduction failure.  The resolution for
<A HREF="
     cwg_active.html#488">issue 488</A> will close the only such
gap of which the CWG is aware.  The issue can be reopened if other
such cases turn up.</P>

<BR>
<BR>
<HR>
<A NAME="46"></A>
<H4>46.
  
Explicit instantiation of member templates
</H4>
<B>Section: </B>14.7.2&nbsp;



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

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

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

 <B>Date: </B>28 Jan 1998<BR>



<P>Is the second explicit instantiation below well-formed?</P>
<PRE>
    template &lt;class T&gt; struct A {
        template &lt;class T2&gt; void f(T2){}
    };

    template void A&lt;int&gt;::f(char); // okay
    
    template template void A&lt;int&gt;::f(float); // ?
</PRE>
Since multiple "<TT>template&lt;&gt;</TT>" clauses are permitted in an explicit
specialization, it might follow that multiple "<TT>template</TT>" keywords
should also be permitted in an explicit instantiation. Are multiple "<TT>template</TT>"
keywords not allowed in an explicit instantiation? The grammar permits
it, but the grammar permits <B>lots</B> of stuff far weirder than that.
My opinion is that, in the absence of explicit wording permitting that
kind of usage (as is present for explicit specializations) that such usage
is not permitted for explicit instantiations.

<P>
<B>Rationale (04/99):</B> The Standard does not describe the meaining
of multiple <TT>template</TT> keywords in this context, so the example
should be considered as resulting in undefined behavior according to
1.3.12&nbsp;



 <A HREF="intro.html#defns.undefined">defns.undefined</A>
.</P>
<BR>
<BR>
<HR>
<A NAME="3"></A>
<H4>3.
  
The template compilation model rules render some explicit specialization declarations not visible during instantiation
</H4>
<B>Section: </B>14.7.3&nbsp;



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

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

 <B>Submitter: </B>Bill Gibbons
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>unknown<BR>





<P>[N1065 issue 1.19] An explicit specialization declaration may not be
visible during instantiation under the template compilation model rules,
even though its existence must be known to perform the instantiation correctly.
For example:</P>

<P>translation unit #1</P>
<PRE>
      template&lt;class T&gt; struct A { };
      export template&lt;class T&gt; void f(T) { A&lt;T&gt; a; }
</PRE>
translation unit #2
<PRE>
      template&lt;class T&gt; struct A { };
      template&lt;&gt; struct A&lt;int&gt; { }; // not visible during instantiation
      template&lt;class T&gt; void f(T);
      void g() { f(1); }
</PRE>
<B>Rationale:</B>
This issue was addressed in the FDIS and should have been closed.
<BR>
<BR>
<HR>
<A NAME="88"></A>
<H4>88.
  
Specialization of member constant templates
</H4>
<B>Section: </B>14.7.3&nbsp;



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

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

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

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



<P>Is this valid C++?
The question is whether a member constant can be specialized.
My inclination is to say no.</P>
<PRE>
    template &lt;class T&gt; struct A {
        static const T i = 0;
    };

    template&lt;&gt; const int A&lt;int&gt;::i = 42;
    
    int main () {
        return A&lt;int&gt;::i;
    }
</PRE>
<U>John Spicer</U>: This is ill-formed because
9.4.2&nbsp;



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

paragraph 4 prohibits an initializer on a definition of a static data member
for which an initializer was provided in the class.

<P>The program would be valid if the initializer were removed from the
specialization.</P>

<P>
<U>Daveed Vandevoorde</U>: Or at least, the specialized member should
not be allowed in constant-expressions.</P>

<P>
<U>Bill Gibbons</U>: Alternatively, the use of a member constant within
the definition could be treated the same as the use of "sizeof(<I>member
class</I><TT>)</TT>". For example:</P>
<PRE>
    template &lt;class T&gt; struct A {
        static const T i = 1;
        struct B { char b[100]; };
        char x[sizeof(B)];     // specialization can affect array size
        char y[i];             // specialization can affect array size 
    };

    template&lt;&gt; const int A&lt;int&gt;::i = 42;
    template&lt;&gt; struct A&lt;int&gt;::B { char z[200] };

    int main () {
        A&lt;int&gt; a;
        return sizeof(a.x)   // 200  (unspecialized value is 100)
             + sizeof(a.y);  // 42   (unspecialized value is 1)
    }
</PRE>
For the member template case, the array size "<TT>sizeof(B)</TT>" cannot
be evaluated until the template is instantiated because <TT>B</TT> might
be specialized. Similarly, the array size "<TT>i</TT>" cannot be evaluated
until the template is instantiated.

<P>
<B>Rationale (10/99):</B> The Standard is already sufficiently clear
on this question.</P>
<BR>
<BR>
<HR>
<A NAME="182"></A>
<H4>182.
  
Access checking on explicit specializations
</H4>
<B>Section: </B>14.7.3&nbsp;



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

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

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

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





<P>
<U>John Spicer</U>:
Certain access checks are suppressed on explicit instantiations.
14.7.2&nbsp;



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

<BLOCKQUOTE>
The usual access checking rules do not apply to names used to specify
explicit instantiations. [<I>Note:</I> In particular, the template arguments
and names used in the function declarator (including parameter types,
return types and exception specifications) may be private types or
objects which would normally not be accessible and the template may be
a member template or member function which would not normally be
accessible. ]
</BLOCKQUOTE>

I was surprised that similar wording does not exist (that I could find) for
explicit specializations.  I believe that the two cases should be handled
equivalently in the example below (i.e., that the specialization should be
permitted).

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

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

    class A {
    class B {};
    void f();
    };

    template void C&lt;A::B&gt;::f();    // okay
    template &lt;&gt; void C&lt;A::B&gt;::g(); // error - A::B inaccessible

    void A::f() {
    C&lt;B&gt; cb;
    cb.f();
    }
</PRE>

<P>
<U>Mike Miller</U>:
According to the note in
14.3&nbsp;



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

<BLOCKQUOTE>
if the name of a <I>template-argument</I> is accessible
at the point where it is used as a <I>template-argument</I>,
there is no further access restriction in the
resulting instantiation where the corresponding
<I>template-parameter</I> name is used.
</BLOCKQUOTE>

<P>(Is this specified anywhere in the normative text?  Should
it be?)</P>

<P>In the absence of text to the contrary, this blanket
permission apparently applies to explicitly-specialized
templates as well as to implicitly-generated ones (is that
right?).  If so, I don't see any reason that an explicit
instantiation should be treated differently from an explicit
specialization, even though the latter involves new program
text and the former is just a placement instruction to the
implementation.</P>

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

<P>In 14.7.2&nbsp;



 <A HREF="template.html#temp.explicit">temp.explicit</A> delete paragraph 8:</P>
<BLOCKQUOTE>
The usual access checking rules do not apply to names used to specify explicit
instantiations. [Note: In particular, the template arguments and names used in
the function declarator (including parameter types, return types and exception
specifications) may be private types or objects which would normally not be
accessible and the template may be a member template or member function which
would not normally be accessible. ]
</BLOCKQUOTE>

<P>In 14.7&nbsp;



 <A HREF="template.html#temp.spec">temp.spec</A> add the paragraph deleted above as
paragraph 7 with the changes highlighted below:</P>

<BLOCKQUOTE>
The usual access checking rules do not apply to names used to specify explicit
instantiations <B>or explicit specializations</B>. <S>[Note: In
particular, t</S><B>T</B>he template arguments and names used in the
function declarator (including parameter types, return types and exception
specifications) may be private types or objects which would normally not be
accessible and the template may be a member template or member function
which would not normally be accessible. <S>]</S>
</BLOCKQUOTE>

<P>
<B>Rationale (October 2002):</B>
</P>

<P>We reconsidered this and decided that the difference between the
two cases (explicit specialization and explicit instantiation) is
appropriate.  The access rules are sometimes bent when necessary to
allow naming something, as in an explicit instantiation, but
explicit specialization requires not only naming the entity but
also providing a definition somewhere.</P>

<BR>
<BR>
<HR>
<A NAME="285"></A>
<H4>285.
  
Identifying a function template being specialized
</H4>
<B>Section: </B>14.7.3&nbsp;



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

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

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

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


<P>The Standard does not describe how to handle an example
like the following:</P>

<PRE>
    template &lt;class T&gt; int f(T, int);
    template &lt;class T&gt; int f(int, T);

    template&lt;&gt; int f&lt;int&gt;(int, int) { /*...*/ }
</PRE>

<P>It is impossible to determine which of the function templates
is being specialized.  This problem is related to the discussion
of <A HREF="
     cwg_closed.html#229">issue 229</A>, in which one of the objections
raised against partial specialization of function templates is
that it is not possible to determine which template is being
specialized.</P>

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

<P>It was decided that while this is true, it's not a problem.  You
can't call such functions anyway; the call would be ambiguous.</P>

<BR>
<BR>
<HR>
<A NAME="99"></A>
<H4>99.
  
Partial ordering, references and cv-qualifiers
</H4>
<B>Section: </B>14.8.2.1&nbsp;



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

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

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

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



<P>Consider:</P>
<PRE>
    template &lt;class T&gt; void f(T&amp;);
    template &lt;class T&gt; void f(const T&amp;);
    void m() {
        const int p = 0;
        f(p);
    }
</PRE>
Some compilers treat this as ambiguous; others prefer <TT>f(const T&amp;)</TT>.

The question turns out to revolve around whether
14.8.2.1&nbsp;



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

paragraph 2 says what it ought to regarding the removal of cv-qualifiers
and reference modifiers from template function parameters in
doing type deduction.
<P>
<U>John Spicer</U>: 
The partial ordering rules as originally proposed specified that, for
purposes of comparing parameter types, you remove a top level reference,
and after having done that you remove top level qualifiers.  This is not
what is actually in the IS however.  The IS says that you remove top
level qualifiers and then top level references.</P>
<P>
The original rules were intended to prefer <TT>f(A&lt;T&gt;)</TT> over <TT>f(const T&amp;)</TT>.</P>

<P>
<B>Rationale (10/99):</B> The Standard correctly reflects the intent
of the Committee.</P>

<P>
<B>(October 2002)</B>
This is resolved by <A HREF="
     cwg_defects.html#214">issue 214</A>.</P>

<BR>
<BR>
<HR>
<A NAME="211"></A>
<H4>211.
  
Constructors should not be allowed to return normally after an exception
</H4>
<B>Section: </B>15&nbsp;



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

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

 <B>Submitter: </B>Bruce Mellows
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>8 Mar 2000<BR>


<P>The grammar should be changed so that constructor
<I>function-try-block</I>s must end with a
<I>throw-expression</I>.</P>

<P>
<B>Rationale (04/00):</B>
</P>

<P>No change is needed.  It is already the case that flowing off the
end of a <I>function-try-block</I> of a constructor rethrows the
exception, and <TT>return</TT> statements are prohibited in
constructor <I>function-try-block</I>s
(15.3&nbsp;



 <A HREF="except.html#except.handle">except.handle</A> paragraphs 15-16.</P>

<BR>
<BR>
<HR>
<A NAME="104"></A>
<H4>104.
  
Destroying the exception temp when no handler is found
</H4>
<B>Section: </B>15.1&nbsp;



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

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

 <B>Submitter: </B>Jonathan Schilling
 &nbsp;&nbsp;&nbsp;

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





<P>Questions regarding when a throw-expression temporary object is destroyed.</P>
<P>
Section 15.1&nbsp;



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

paragraph 4 describes when the temporary is destroyed when a handler is found.
But what if no handler is found:</P>
<PRE>
    struct A {
        A() { printf ("A() \n"); }
        A(const A&amp;) { printf ("A(const A&amp;)\n"); }
        ~A() { printf ("~A() \n"); }
    };

    void t() { exit(0); }

    int main() {
        std::set_terminate(t);
        throw A();
    }
</PRE>
Does <TT>A::~A()</TT> ever execute here?
(Or, in case two constructions are done,
are there two destructions done?)  Is it implementation-defined, analogously
to whether the stack is unwound before <TT>terminate()</TT> is called
(15.3&nbsp;



 <A HREF="except.html#except.handle">except.handle</A>
 paragraph 9)?
<P>
Or what if an exception specification is violated?  There are several
different scenarios here:</P>
<PRE>
    int glob = 0; // or 1 or 2 or 3

    struct A {
        A() { printf ("A() \n"); }
        A(const A&amp;) { printf ("A(const A&amp;)\n"); }
        ~A() { printf ("~A() \n"); }
    };

    void u() {
        switch (glob) {
        case 0:  exit(0);
        case 1:  throw "ok";
        case 2:  throw 17;
        default: throw;
        }
    }

    void foo() throw(const char*, std::bad_exception) {
        throw A();
    }

    int main() {
        std::set_unexpected(u);
        try {
            foo();
        }
        catch (const char*) { printf("in handler 1\n"); }
        catch (std::bad_exception) { printf("in handler 2\n"); }
    }
</PRE>
The case where <TT>u()</TT> exits is presumably similar to the <TT>terminate()</TT> case.
But in the cases where the program goes on, <TT>A::~A()</TT> should be called
for the thrown object at some point.  But where does this happen?
The standard doesn't really say.  Since an exception is defined to
be "finished" when the <TT>unexpected()</TT> function exits, it seems to me that
is where <TT>A::~A()</TT> should be called &mdash; in this case, as the throws of
new (or what will become new) exceptions are made out of <TT>u()</TT>.
Does this make sense?

<P>
<B>Rationale (10/99):</B> Neither <TT>std::exit(int)</TT> nor
<TT>std::abort()</TT> destroys temporary objects, so the exception
temporary is not destroyed when no handler is found.  The original
exception object is destroyed when it is replaced by an
<TT>unexpected()</TT> handler.  The Standard is sufficiently clear
on these points.</P>
<BR>
<BR>
<HR>
<A NAME="308"></A>
<H4>308.
  
Catching exceptions with ambiguous base classes
</H4>
<B>Section: </B>15.3&nbsp;



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

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

 <B>Submitter: </B>Sergey P. Derevyago
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>04 Sep 2001<BR>


<P>15.3&nbsp;



 <A HREF="except.html#except.handle">except.handle</A> paragraph 3 contains the following text:</P>
<BLOCKQUOTE>
A handler is a match for a throw-expression with an object of type E if
<UL>
<LI>
The handler is of type cv T or cv T&amp; and E and T are the same type
(ignoring the top-level cv- qualifiers), or
</LI>
<LI>
the handler is of type cv T or cv T&amp; and T is an unambiguous public base
class of E, or
</LI>
<LI>
the handler is of type cv1 T* cv2 and E is a pointer type that can be
converted to the type of the handler by either or both of 
<UL>
<LI>
a standard pointer conversion (4.10&nbsp;



 <A HREF="conv.html#conv.ptr">conv.ptr</A>) not involving
conversions to pointers to private or protected or ambiguous classes
</LI>
<LI>
a qualification conversion
</LI>
</UL>
</LI>
</UL>
</BLOCKQUOTE>

<P>I propose to alter this text to allow to catch exceptions with ambiguous
public base classes by some of the public subobjects. I'm really sure that
if someone writes:
<PRE>
    try {
        // ...
    }
    catch (Matherr&amp; m) {
        // ...
    }
</PRE>
he really wants to catch <I>all</I> <TT>Matherrs</TT> rather than to allow
some of the <TT>Matherrs</TT> to escape:
<PRE>
    class SomeMatherr : public Matherr { /* */ };
    struct TrickyBase1 : public SomeMatherr { /* */ };
    struct TrickyBase2 : public SomeMatherr { /* */ };
    struct TrickyMatherr : public TrickyBase1, TrickyBase2 { /* */ };
</PRE>
</P>

<P>According to the standard <TT>TrickyMatherr</TT>
will leak through the catch
<TT>(Matherr&amp; m)</TT> clause. For example:</P>
<PRE>
    #include &lt;stdio.h&gt;

    struct B {};
    struct B1 : B {};
    struct B2 : B {};
    struct D : B1, B2 {};  // D() has two B() subobjects

    void f() { throw D(); }

    int main()
    {
     try { f(); }
     catch (B&amp; b) { puts("B&amp;"); }  // passed
     catch (D&amp; d) { puts("D&amp;"); }  // really works _after_ B&amp;!!!
    }
</PRE>
<P>Also I see one more possible solution: to forbid objects with ambiguous
base classes to be "exceptional objects" (for example Borland C++ goes this
way) but it seems to be unnecessary restrictive.</P>

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

<P>The Core Working Group did not feel this was a significant problem.
Catching either of the ambiguous base classes would be surprising, and
giving an error on throwing an object that has an ambiguous base class
would break existing code.</P>

<BR>
<BR>
<HR>
<A NAME="593"></A>
<H4>593.
  
Falling off the end of a destructor's <I>function-try-block</I> handler
</H4>
<B>Section: </B>15.3&nbsp;



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

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

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

 <B>Date: </B>30 August 2006<BR>


<P>If control reaches the end of handler in a
destructor's <I>function-try-block</I>, the exception is rethrown
(15.3&nbsp;



 <A HREF="except.html#except.handle">except.handle</A> paragraph 15).  Because of the danger
of destructors that throw exceptions, would it be better to
treat this case as an implicit <TT>return;</TT> statement, as in
a function body?  There could be a transitional period, perhaps
using conditionally-supported behavior or the like, before
mandating the change.</P>

<P>
<B>Rationale (October, 2006):</B>
</P>

<P>The CWG felt that the current behavior is clearly specified and
reflects the intention of the Committee at the time the rules were
adopted.  Possible changes to these rules should be pursued through
the Evolution Working Group.</P>

<BR>
<BR>
<HR>
<A NAME="346"></A>
<H4>346.
  
Typo in 15.4
</H4>
<B>Section: </B>15.4&nbsp;



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

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

 <B>Submitter: </B>Lois Goldthwaite
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>18 March 2002<BR>


<P>15.4&nbsp;



 <A HREF="except.html#except.spec">except.spec</A> paragraph 13 contains the following text.
I believe 'implicitLY' marked below should be replaced with
'implicit.'</P>
<BLOCKQUOTE>
<P>An implicitly declared special member
 function (clause 12&nbsp;



 <A HREF="special.html#special">special</A>)
shall have an exception-specification. If f is an implicitly
declared default constructor, copy constructor, destructor, or copy 
assignment operator, its implicit exception-specification
specifies the <I>type-id</I> T if and only if T is allowed by the 
exception-specification of a function directly invoked 
by f's <B>implicitly</B> definition;
f shall allow all exceptions if any function it directly invokes 
allows all exceptions, and f shall allow no exceptions if
every function it directly invokes allows no exceptions. [Example: </P>
<PRE>
    struct A {
        A();
        A(const A&amp;) throw();
        ~A() throw(X);
    };
    struct B {
        B() throw();
        B(const B&amp;) throw();
        ~B() throw(Y);
    };
    struct D : public A, public B {
            //  Implicit declaration of  D::D();
            //  Implicit declaration of  D::D(const   D&amp;)   throw();
            //  Implicit declaration of  D::~D()   throw   (X,Y);
    };
</PRE>

<P>Furthermore, if A::~A() or B::~B() were virtual, D::~D() would not be as
restrictive as that of A::~A, and the program would
be ill-formed since a function that overrides a virtual function from a
base class shall have an exception-specification at least as
restrictive as that in the base class. ] </P>
</BLOCKQUOTE>

<P>The example code shows structs whose destructors have exception
specifications which throw certain types. There is no defect here, but
it doesn't sit well with our general advice elsewhere that destructors
should not throw. I wish I could think of some other way to illustrate
this section.</P>

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

<P>This was previously resolved by an editorial change.</P>

<BR>
<BR>
<HR>
<A NAME="37"></A>
<H4>37.
  
When is uncaught_exception() true?
</H4>
<B>Section: </B>15.5.3&nbsp;



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

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

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

 <B>Date: </B>10 Aug 1998<BR>


    

    
<P>The term "throw exception" seems to sometimes refer to an expression
of the form "<TT>throw</TT> <I>expr</I>" and
sometimes just to the "<I>expr</I>"
portion thereof.</P>
    
<P>As a result it is not quite clear to me
whether when "<TT>uncaught_exception()</TT>"
becomes true: before or after the temporary
copy of the value of "<I>expr</I>".</P>
    
<P>Is there a definite consensus about that?</P>
    
<P>
<B>Rationale:</B>
    
The standard is sufficiently clear; the phrase "to be thrown" indicates
that the throw itself (which includes the copy to the temporary object)
has not yet begun. The footnote in
15.5.1&nbsp;



 <A HREF="except.html#except.terminate">except.terminate</A>
 paragraph 1 reinforces
this ordering. </P>

<P>See also <A HREF="
     cwg_active.html#475">issue 475</A>.</P>
<BR>
<BR>
<HR>
<A NAME="266"></A>
<H4>266.
  
No grammar sentence symbol
</H4>
<B>Section: </B>A&nbsp;



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

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

 <B>Submitter: </B>Hans Aberg
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>2 Dec 2000<BR>


<P>The grammar in Appendix A does not indicate a grammar sentence
symbol and is therefore formally not a grammar.</P>

<P>
<B>Rationale (04/01):</B>
</P>

<P>Appendix A does not claim to be a formal grammar.  The
specification is clear enough in its current formulation.</P>

<BR>
<BR>
<HR>
<A NAME="81"></A>
<H4>81.
  
Null pointers and C compatability
</H4>
<B>Section: </B>C&nbsp;



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

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

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

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




    
<P>Annex C lists C compatibility issues. One item not in the annex came
up in a discussion in comp.std.c++.</P>
    
<P>Consider this C and C++ code:</P>
<PRE>
    const int j = 0;
    char* p = (char*)j;
</PRE>

<P>
<B>Rationale (10/99):</B> Because <TT>j</TT> is not a constant
expression in C, this code fragment has implementation-defined behavior
in C.  There is no incompatibility with C resulting from the fact that
C++ defines this behavior.</P>
<BR>
<BR>
<HR>
<A NAME="167"></A>
<H4>167.
  
Deprecating static functions
</H4>
<B>Section: </B>D.2&nbsp;



 <A HREF="future.html#depr.static">depr.static</A>
 &nbsp;&nbsp;&nbsp;

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

 <B>Submitter: </B>Darin Adler
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>8 Sep 1999<BR>



<P>D.2&nbsp;



 <A HREF="future.html#depr.static">depr.static</A>
 says that declaring
namespace-scope <I>objects</I> as <TT>static</TT> is deprecated.
Declaring namespace-scope <I>functions</I> as <TT>static</TT> should
also be deprecated.</P>

<P>
<B>Proposed resolution (10/99):</B> In both
7.3.1.1&nbsp;



 <A HREF="dcl.html#namespace.unnamed">namespace.unnamed</A>
 paragraph 2 and
D.2&nbsp;



 <A HREF="future.html#depr.static">depr.static</A>
 paragraph 1, replace</P>

<BLOCKQUOTE>
when declaring objects in a namespace scope
</BLOCKQUOTE>

with

<BLOCKQUOTE>
when declaring entities in a namespace scope
</BLOCKQUOTE>

In addition, there are a number of locations in the Standard where use
of or reference to <TT>static</TT> should be reconsidered.  These
include:

<UL>
<LI>3.2&nbsp;



 <A HREF="basic.html#basic.def.odr">basic.def.odr</A>
 paragraph 5,</LI>
<LI>3.5&nbsp;



 <A HREF="basic.html#basic.link">basic.link</A>
 paragraph 6,</LI>
<LI>3.6.2&nbsp;



 <A HREF="basic.html#basic.start.init">basic.start.init</A>
 paragraph 4,</LI>
<LI>5.19&nbsp;



 <A HREF="expr.html#expr.const">expr.const</A>
 paragraph 2,</LI>
<LI>7.1&nbsp;



 <A HREF="dcl.html#dcl.spec">dcl.spec</A>
 paragraph 2,</LI>
<LI>7.5&nbsp;



 <A HREF="dcl.html#dcl.link">dcl.link</A>
 paragraph 7, and</LI>
<LI>8.3.4&nbsp;



 <A HREF="decl.html#dcl.array">dcl.array</A>
 paragraph 4.</LI>
</UL>

<P>
<B>Rationale (04/00):</B>
</P>

<P>This issue, along with <A HREF="
     cwg_closed.html#174">issue 174</A>, has
been subsumed by <A HREF="
     cwg_active.html#223">issue 223</A>.  Until the
committee determines the meaning of deprecation, it does not make
sense either to extend or reduce the number of features to which it is
applied.</P>
<BR>
<BR>
<HR>
<A NAME="174"></A>
<H4>174.
  
Undeprecating global static
</H4>
<B>Section: </B>D.2&nbsp;



 <A HREF="future.html#depr.static">depr.static</A>
 &nbsp;&nbsp;&nbsp;

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

 <B>Submitter: </B>Lawrence Crowl
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>25 Oct 1999<BR>



<P>The decision to deprecate global static should be reversed.</P>

<OL>
<LI>
We cannot deprecate static because it is an important part of C and to
abandon it would make C++ unnecessarily incompatible with C.</LI>

<LI>
Because templates may be instantiated on members of unnamed namespaces,
some compilation systems may place such symbols in the global linker
space, which could place a significant burden on the linker.  Without
static, programmers have no mechanism to avoid the burden.</LI>

</OL>

<P>
<B>Rationale (04/00):</B>
</P>

<P>This issue, along with <A HREF="
     cwg_closed.html#167">issue 167</A>, has
been subsumed by <A HREF="
     cwg_active.html#223">issue 223</A>.  Until the
committee determines the meaning of deprecation, it does not make
sense either to extend or reduce the number of features to which it is
applied.</P>
<BR>
<BR>
<BR>
<BR>
<HR>
<A NAME="Dup Status"></A>
<H3>Issues with "Dup" Status</H3>
<HR>
<A NAME="82"></A>
<H4>82.
  
Definition of "using" a constant expression
</H4>
<B>Section: </B>3.2&nbsp;



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

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

 <B>Submitter: </B>Bill Gibbons
 &nbsp;&nbsp;&nbsp;

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





<P>The wording in
3.2&nbsp;



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

paragraph 2 about "potentially evaluated" is incomplete. It does not distinguish
between expressions which are used as "integral constant expressions" and
those which are not; nor does it distinguish between uses in which an objects
address is taken and those in which it is not. (A suitable definition
of "address taken" could be written without actually saying "address".)</P>

<P>Currently the definition of "use" has two parts (part (a) and (d) below);
but in practice there are two more kinds of "use" as in (b) and (c):</P>
<OL TYPE="a">
<LI>
Use in "sizeof" or a non-polymorphic "typeid". Neither the value
nor the address is really used. No definition is needed at all.</LI>

<LI>
Use as an integral constant expression. Only the value is used. A
static data member with its initializer given in the class need not have
a namespace-scope definition.</LI>

<LI>
Use which requires the value, which is known at compile time because the
object is const, of integral or enum type, and initialized with an integral
constant expression. Only the value need be used, but an implementation
is not required to use the value from the initializer; it might access
the object. So in the original example, the namespace-scope definition
is required even though most compilers will not require it.</LI>

<LI>
All other uses require that the object actually exist because its address
will be taken implicitly or explicitly.</LI>
</OL>
We discussed (b) and decided that the namespace-scope definition was not
needed, but the wording did not make it into the standard.

<P>I don't think we discussed (c).</P>

<P>
<B>Rationale (04/99):</B> The substantive part of this issue is
covered by <A HREF="
     cwg_defects.html#48">Core issue 48</A>
</P>
<BR>
<BR>
<HR>
<A NAME="12"></A>
<H4>12.
  
Default arguments on different declarations for the same function and the Koenig lookup
</H4>
<B>Section: </B>3.4.2&nbsp;



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

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

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

 <B>Date: </B>unknown<BR>





<P>Given the following test case:</P>
<PRE>
    enum E { e1, e2, e3 };
    
    void f(int, E e = e1);
    void f(E, E e = e1);
    
    void g() {
        void f(long, E e = e2);
        f(1); // calls ::f(int, E)
        f(e1); // ?
    }

</PRE>
First note that Koenig lookup breaks the concept of hiding functions through
local extern declarations as illustrated by the call `<TT>f(1)</TT>'. Should
the WP show this as an example?

<P>Second, it appears the WP is silent as to what happens with the call
`<TT>f(e1)</TT>': do the different default arguments create an ambiguity?
is the local choice preferred? or the global?</P>

<P>
<B>Tentative Resolution (10/98)</B>
In 3.4.2&nbsp;



 <A HREF="basic.html#basic.lookup.argdep">basic.lookup.argdep</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>
to
<BLOCKQUOTE>If the ordinary unqualified lookup of the name finds the declaration
of a class member function or the declaration of a function at block scope,
the associated namespaces and classes are not considered.</BLOCKQUOTE>

<P>
<B>Rationale (04/99):</B> The proposal would also apply to local
<I>using-declaration</I>s (per Mike Ball) and was therefore deemed
undesirable.  The ambiguity issue is
dealt with in <A HREF="
     cwg_defects.html#1">Core issue 1</A>
</P>
<BR>
<BR>
<HR>
<A NAME="313"></A>
<H4>313.
  
Class with single conversion function to integral as array size in <TT>new</TT>
</H4>
<B>Section: </B>5.3.4&nbsp;



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

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

 <B>Submitter: </B>Bill Gibbons
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>22 Oct 2001<BR>


<P>Should it be allowed to use an object of a class type having a single
conversion function to an integral type as an array size in the first
bound of the type in an array new?</P>

<PRE>
  struct A {
    operator int();
  } a;
  int main () {
    new int[a];
  }
</PRE>

<P>There are similar accommodations
for the expression in a <TT>delete</TT> (5.3.5&nbsp;



 <A HREF="expr.html#expr.delete">expr.delete</A>
paragraph 1) and in a <TT>switch</TT> (6.4.2&nbsp;



 <A HREF="stmt.html#stmt.switch">stmt.switch</A>
paragraph 2).  There is also widespread existing practice on this
(g++, EDG, MSVC++, and Sun accept it, and even cfront 3.0.2).</P>

<P>
<B>Rationale (October, 2004):</B>
</P>

<P>Duplicate of <A HREF="
     cwg_defects.html#299">issue 299</A>.</P>

<BR>
<BR>
<HR>
<A NAME="548"></A>
<H4>548.
  
<I>qualified-id</I>s in declarations
</H4>
<B>Section: </B>8.3&nbsp;



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

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

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

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


<P>According to 8.3&nbsp;



 <A HREF="decl.html#dcl.meaning">dcl.meaning</A> paragraph 1, the declarator
in the definition or explicit instantiation of a namespace member can
only be qualified if the definition or explicit instantiation appears
outside the member's namespace:</P>

<BLOCKQUOTE>

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



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



 <A HREF="class.html#class.static">class.static</A>) outside of its class, the
definition or explicit instantiation of a function or variable member
of a namespace outside of its namespace, or the definition of a
previously declared explicit specialization outside of its namespace,
or the declaration of a friend function that is a member of another
class or namespace (11.4&nbsp;



 <A HREF="access.html#class.friend">class.friend</A>). When
the <I>declarator-id</I> is qualified, the declaration shall refer to
a previously declared member of the class or namespace to which the
qualifier refers, and the member shall not have been introduced by
a <I>using-declaration</I> in the scope of the class or namespace
nominated by the <I>nested-name-specifier</I> of
the <I>declarator-id</I>.

</BLOCKQUOTE>

<P>There is no similar restriction on a <I>qualified-id</I> in a
class definition (9&nbsp;



 <A HREF="class.html#class">class</A> paragraph 5):</P>

<BLOCKQUOTE>

If a <I>class-head</I> contains a <I>nested-name-specifier</I>,
the <I>class-specifier</I> shall refer to a class that was previously
declared directly in the class or namespace to which the
<I>nested-name-specifier</I> refers (i.e., neither inherited nor
introduced by a <I>using-declaration</I>), and
the <I>class-specifier</I> shall appear in a namespace enclosing the
previous declaration.

</BLOCKQUOTE>

<P>An <I>elaborated-type-specifier</I> in an explicit instatiation
containing a <I>qualified-id</I> is also not prohibited from appearing
in the namespace nominated by its <I>nested-name-specifier</I>
(14.7.2&nbsp;



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

<BLOCKQUOTE>

An explicit instantiation shall appear in an enclosing namespace of
its template. If the name declared in the explicit instantiation is an
unqualified name, the explicit instantiation shall appear in the
namespace where its template is declared.

</BLOCKQUOTE>

<P>(This asymmetry is due to the removal of inappropriate mention
of classes in 8.3&nbsp;



 <A HREF="decl.html#dcl.meaning">dcl.meaning</A> by
<A HREF="
     cwg_defects.html#40">issue 40</A> and a failure to insert the
intended restrictions elsewhere.)</P>

<P>An example of this inconsistency is:</P>

<PRE>
    namespace N {
      template &lt;class T&gt; struct S { };
      template &lt;class T&gt; void foo () { }

      template struct N::S&lt;int&gt;;   //<SPAN STYLE="font-family:Times"><I> OK</I></SPAN>
      template void N::foo&lt;int&gt;(); //<SPAN STYLE="font-family:Times"><I> ill-formed</I></SPAN>
    }
</PRE>

<P>It is not clear that any purpose is served by the &ldquo;outside of
its namespace&rdquo; restriction on declarators in definitions and
explicit instantiations; if possible, it would be desirable to
reconcile the treatment of declarators and class names by removing
the restriction on declarators (which appears to be widespread
implementation practice, anyway).</P>

<P>
<B>Rationale (April, 2006):</B>
</P>

<P>This is the same as <A HREF="
     cwg_active.html#482">issue 482</A>.</P>

<BR>
<BR>
<HR>
<A NAME="15"></A>
<H4>15.
  
Default arguments for parameters of function templates
</H4>
<B>Section: </B>8.3.6&nbsp;



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

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

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

 <B>Date: </B>unknown<BR>





<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 functions in the same scope.</BLOCKQUOTE>
Why say for non-template functions? Why couldn't the following allowed?
<PRE>
    template &lt;class T&gt; struct B {
        template &lt;class U&gt; inline void f(U);
    };
     
    template &lt;class T&gt; template &lt;class U&gt;
    inline void B&lt;T&gt;::f(U = int) {} // adds default arguments
                                       // is this well-formed?
    void g()
    {
        B&lt;int&gt; b;
        b.f();
    }
</PRE>
If this is ill-formed, chapter 14 should mention this.

<P>
<B>Rationale:</B>
This is sufficiently clear in the standard. Allowing additional
default arguments would be an extension.</P>

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

<P>The example here is flawed.  It's not clear what is being requested.
One possibility is the extension introduced by
<A HREF="
     cwg_defects.html#226">issue 226</A>.  Other meanings don't seem to be
useful.</P>

<BR>
<BR>
<HR>
<A NAME="72"></A>
<H4>72.
  
Linkage and storage class specifiers for templates
</H4>
<B>Section: </B>14&nbsp;



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

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

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

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





<P>
<U>John Spicer</U>: 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>

<P>
<U>Mike Ball</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>

<P>
<U>John Spicer</U>: 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.</P>

<P>
<U>Mike Ball</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>

<P>
<U>John Spicer</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>

<P>"export" is an additional attribute that is separate from linkage, but
that can only be applied to templates with external linkage.</P>

<P>
<U>Mike Ball</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>

<P>
<U>John Spicer</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>

<P>
<B>Rationale:</B> Duplicate of
<A HREF="
     cwg_defects.html#69">Core issue 69</A>.</P>
<BR>
<BR>
<HR>
<A NAME="200"></A>
<H4>200.
  
Partial ordering and explicit arguments
</H4>
<B>Section: </B>14.5.5.2&nbsp;



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

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

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

 <B>Date: </B>28 Jan 2000<BR>





<P>The description of how the partial ordering of template functions
is determined in
14.5.5.2&nbsp;



 <A HREF="template.html#temp.func.order">temp.func.order</A>
 paragraphs 3-5 does
not make any provision for nondeduced template parameters.  For
example, the function call in the following code is ambiguous, even
though one template is "obviously" more specialized than the other:</P>

<PRE>
    template &lt;class T&gt; T f(int);
    template &lt;class T, class U&gt; T f(U);
    void g() {
        f&lt;int&gt;(1);
    }
</PRE>

The reason is that neither function parameter list allows template
parameter <TT>T</TT> to be deduced; both deductions fail, so neither
template is considered more specialized than the other and the
function call is ambiguous.

<P>One possibility of addressing this situation would be to
incorporate explicit template arguments from the call in the argument
deduction using the transformed function parameter lists.  In this
case, that would result in finding the first template to be more
specialized than the second.</P>

<P>
<B>Rationale (04/00):</B>
</P>

<P>This issue is covered in a more general context in
<A HREF="
     cwg_defects.html#214">issue 214</A>.</P>

<BR>
<BR>
<HR>
<A NAME="375"></A>
<H4>375.
  
Confusing example on lookup with <TT>typename</TT>
</H4>
<B>Section: </B>14.6&nbsp;



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

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

 <B>Submitter: </B>Manish Pagey
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>23 August 2002<BR>


<P>Section 14.6&nbsp;



 <A HREF="template.html#temp.res">temp.res</A> paragraph 4 uses the
following example to show that 
qualified name lookup described in Section 3.4.3&nbsp;



 <A HREF="basic.html#basic.lookup.qual">basic.lookup.qual</A>
applies even in the presence of "typename":</P>
<PRE>
  struct A {
    struct X { } ;
    int X ;
  } ;
  template&lt;class T&gt; void f(T t) {
    typename T::X x ; // ill-formed: finds the data member X
                      // not the member type X
  }
</PRE>
<P>This example is confusing because the definition of the template function 
itself is not ill formed unless it is instantiated with "A" as the template 
parameter. In other words, the example should be modified to something 
like: </P>
<PRE>
  struct A {
    struct X { } ;
    int X ; 
  } ; 
  struct B {
    struct X { } ;
  } ;
  template&lt;class T&gt; void f(T t) {
    typename T::X x ; 
  }
  void foo() {
    A a ; 
    B b ;
    f(b) ; // OK -- finds member type B::X.
    f(a) ; // ill-formed: finds the data member A::X not 
           // the member type A::X.
  }
</PRE>

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

<P>This is a duplicate of <A HREF="
     cwg_defects.html#345">Core Issue 345</A>.</P>

<BR>
<BR>
<HR>
<A NAME="133"></A>
<H4>133.
  
Exception specifications and checking
</H4>
<B>Section: </B>15.4&nbsp;



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

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

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

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





<P>15.4&nbsp;



 <A HREF="except.html#except.spec">except.spec</A>
 paragraph 1 says,</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>

This wording forbids
exception specifications in declarations where they might plausibly
occur (e.g., an array of function pointers).  This restriction seems
arbitrary.  It's also unclear whether this wording allows declarations
such as

<PRE>
    void (*f())() throw(int);  // returns a pointer to a function
                               // that might throw "int"
</PRE>

<P>At the same time, other cases are allowed by the wording in
paragraph 1 (e.g., a pointer to a pointer to a function), but no
checking for such cases is specified in paragraph 3.  For example,
the following appears to be allowed:</P>

<PRE>
    void (*p)() throw(int);
    void (**pp)() throw() = &amp;p;
</PRE>

<P>
<B>Rationale (10/99):</B> Duplicate of issues
<A HREF="
     cwg_defects.html#87">87</A> and
<A HREF="
     cwg_active.html#92">92</A>.</P>
<BR>
<BR>
<HR>
<A NAME="79"></A>
<H4>79.
  
Alignment and placement new
</H4>
<B>Section: </B>18.4.1.3&nbsp;



 <A HREF="lib-support.html#lib.new.delete.placement">lib.new.delete.placement</A>
 &nbsp;&nbsp;&nbsp;

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

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

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


    

    
<P>The example in 18.4.1.3&nbsp;



 <A HREF="lib-support.html#lib.new.delete.placement">lib.new.delete.placement</A>

reads:</P>
<BLOCKQUOTE>[<I>Example:</I>  This  can  be  useful for constructing
an object at a known address:
<PRE>
    char place[sizeof(Something)];
    Something* p = new (place) Something();
</PRE>
&mdash;<I>end example</I>]</BLOCKQUOTE>
This example has potential alignment problems. One way to correct it would
be to change the definition of <TT>place</TT> to read:
<PRE>
    char* place = new char[sizeof(Something)];
</PRE>

<P>
<B>Rationale (10/99):</B> This is an issue for the Library
Working Group.</P>
<BR>
<BR>
<BR>
<BR>
<HR>
<A NAME="Extension Status"></A>
<H3>Issues with "Extension" Status</H3>
<HR>
<A NAME="220"></A>
<H4>220.
  
All deallocation functions should be required not to throw
</H4>
<B>Section: </B>3.7.3.2&nbsp;



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

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

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

 <B>Date: </B>31 Mar 2000<BR>


<P>[Picked up by evolution group at October 2002 meeting.]</P>



<P>The default global operators <TT>delete</TT> are specified to not
throw, but there is no requirement that replacement global, or
class-specific, operators <TT>delete</TT> must not throw. That ought
to be required.</P>

<P>In particular:</P>

<UL>

<LI>3.7.3.2&nbsp;



 <A HREF="basic.html#basic.stc.dynamic.deallocation">basic.stc.dynamic.deallocation</A> paragraph 2, at the end of the
first sentence, should also require that no exceptions be thrown.</LI>

<LI>12.5&nbsp;



 <A HREF="special.html#class.free">class.free</A>, including its examples, should require
nonthrowing class-specific <TT>operator delete</TT>.</LI>

<LI>17.4.3.4&nbsp;



 <A HREF="lib-intro.html#lib.replacement.functions">lib.replacement.functions</A> paragraph 2 should append
<TT>throw()</TT> to the signature of each of the four operators
<TT>delete</TT>.</LI>

</UL>

<P>We already require that all versions of an allocator's deallocate()
must not throw, so that part is okay.</P>

<P>
<B>Rationale (04/00):</B>
</P>

<OL>

<LI>Replacement deallocation functions are already required not to
throw an exception (cf 17.4.3.6&nbsp;



 <A HREF="lib-intro.html#lib.res.on.functions">lib.res.on.functions</A> paragraph 2,
as applied to 18.4.1.1&nbsp;



 <A HREF="lib-support.html#lib.new.delete.single">lib.new.delete.single</A> paragraph 12 and
18.4.1.2&nbsp;



 <A HREF="lib-support.html#lib.new.delete.array">lib.new.delete.array</A> paragraph 11).</LI>

<LI>Section 17.4.3.4&nbsp;



 <A HREF="lib-intro.html#lib.replacement.functions">lib.replacement.functions</A> is describing the
signatures of the functions to be replaced; exception specfications
are not part of the signature.</LI>

<LI>There does not appear to be any pressing need to require that
class member deallocation functions not throw.</LI>

</OL>

<BR>
<BR>
<HR>
<A NAME="294"></A>
<H4>294.
  
Can <TT>static_cast</TT> drop exception specifications?
</H4>
<B>Section: </B>5.2.9&nbsp;



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

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

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

 <B>Date: </B>27 Jun 2001<BR>


<P>[Picked up by evolution group at October 2002 meeting.]</P>

<P>Is it okay for a <TT>static_cast</TT> to drop exception
specifications?</P>
<PRE>
    void f() throw(int);
    int main () {
      static_cast&lt;void (*)() throw()&gt;(f);  // Okay?
      void (*p)() throw() = f;  // Error
    }
</PRE>

<P>The fact that a <TT>static_cast</TT> is defined, more or less,
as an initialization suggests that a check ought to be made.</P>

<P>One tricky point: this is another case where the general rule that
the reverse of an implicit cast is allowed as a <TT>static_cast</TT>
bites you -- the reverse conversion doesn't drop exception
specifications, and so is okay.  Perhaps this should be treated
like casting away constness.</P>

<P>
<U>Mike Miller</U> comments
:
I don't think that case can arise.  According to 15.4&nbsp;



 <A HREF="except.html#except.spec">except.spec</A>,
</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>
<P>We strengthened that in <A HREF="
     cwg_defects.html#87">issue 87</A>
(voted to DR status in Copenhagen) to</P>
<BLOCKQUOTE>
An exception-specification 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>As I read that, you can't put an exception-specification on the
type-id in a static_cast, which means that a static_cast can
only weaken, not strengthen, the exception specification.</P>

<P>The core WG discussed this at the 10/01 meeting and agreed.</P>

<BR>
<BR>
<HR>
<A NAME="256"></A>
<H4>256.
  
Overflow in size calculations
</H4>
<B>Section: </B>5.3.4&nbsp;



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

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

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

 <B>Date: </B>15 Oct 2000<BR>


<P>[Picked up by evolution group at October 2002 meeting.]</P>

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



<P>The size requested by an array allocation is computed by multiplying
the number of elements requested by the size of each element and adding
an implementation-specific amount for overhead.  It is possible for this
calculation to overflow.  Is an implementation required to detect this
situation and, for instance, throw <TT>std::bad_alloc</TT>?</P>

<P>On one hand, the maximum allocation size is one of the implementation
limits specifically mentioned in Annex B&nbsp;



 <A HREF="limits.html#limits">limits</A>, and,
according to 1.4&nbsp;



 <A HREF="intro.html#intro.compliance">intro.compliance</A> paragraph 2, an implementation
is only required to "accept and correctly execute" programs that do
not violate its resource limits.</P>

<P>On the other hand, it is difficult or impossible for user code
to detect such overflows in a portable fashion, especially given that
the array allocation overhead is not fixed, and it would be a
service to the user to handle this situation gracefully.</P>

<P>
<B>Rationale (04/01):</B>
</P>

<P>Each implementation is required to document the maximum size
of an object (Annex B&nbsp;



 <A HREF="limits.html#limits">limits</A>).  It is not
difficult for a program to check array allocations to ensure
that they are smaller than this quantity.  Implementations
can provide a mechanism in which users concerned with this
problem can request extra checking before array allocations,
just as some implementations provide checking for array index
and pointer validity.  However, it would not be appropriate to
require this overhead for every array allocation in every
program.</P>

<P>(See <A HREF="
     cwg_active.html#624">issue 624</A> for a request to
reconsider this resolution.)</P>

<BR>
<BR>
<HR>
<A NAME="13"></A>
<H4>13.
  
extern "C" for Parameters of Function Templates
</H4>
<B>Section: </B>7.5&nbsp;



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

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

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

 <B>Date: </B>unknown<BR>



<P>[Picked up by evolution group at October 2002 meeting.]</P>



<P>How can we write a function template, or member function of a class
template that takes a C linkage function as a parameter when the function
type depends on one of the template parameter types?</P>
<PRE>
    extern "C" void f(int);
    void g(char);

    template &lt;class T&gt; struct A {
        A(void (*fp)(T));
    };

    A&lt;char&gt; a1(g);  // okay
    A&lt;int&gt; a2(f);   // error
</PRE>
Another variant of the same problem is:
<PRE>
    extern "C" void f(int);
    void g(char);

    template &lt;class T&gt; void h( void (*fp)(T) );
    
    int main() {
        h(g);  // okay
        h(f);  // error
    }
</PRE>

<BR>
<B>Suggested resolution:</B> (John Spicer)

<P>Somehow permit a language linkage to be specified as part of a function
parameter declaration. i.e.</P>
<PRE>
    template &lt;class T&gt; struct A {
        A( extern "C" void (*fp)(T) );
    };

    template &lt;class T&gt; void h( extern "C" void (*fp)(T) );
</PRE>
<B>Suggested resolution:</B> (Bill Gibbons)
    
<P>The whole area of linkage needs revisiting.  Declaring calling
convention as a storage class was incorrect to begin
with; it should be a function qualifier, as in:</P>
<PRE>
    void f( void (*pf)(int) c_linkage );
</PRE>
instead of the suggested:
<PRE>
    void f( extern "C" void (*pf)(int) );
</PRE>
I would like to keep calling convention on the "next round" issues list,
including the alternative of using function qualifiers.
    
<P>And to that end, I suggest that the use of linkage specifiers to specify
calling convention be deprecated - which would make any use of linkage
specifiers in a parameter declaration deprecated.</P>

<P>
<U>Martin Sebor</U>:

7.5&nbsp;



 <A HREF="dcl.html#dcl.link">dcl.link</A>, paragraph 4 says that "A
linkage-specification shall occur only in namespace scope..." I'm
wondering why this restriction is necessary since it prevents, among
other things, the use of the functions defined <TT>&lt;cmath&gt;</TT>
in generic code that involves function objects. For example, the
program below is ill-formed since
<TT>std::pointer_to_binary_function&lt;&gt;</TT> takes a pointer to a
function with extern "C++" linkage which is incompatible with the type
of the <TT>double</TT> overload of <TT>std::pow</TT>.</P>

<P>Relaxing the restriction to allow linkage specification in
declarations of typedefs in class scope would allow
<TT>std::pointer_to_binary_function&lt;&gt;</TT> ctor to be overloaded
on both types (i.e., extern "C" and extern "C++"). An alternative
would be to allow for the linkage specification to be deduced along
with the type.</P>

<PRE>
    #include &lt;cmath&gt;
    #include &lt;functional&gt;
    #include &lt;numeric&gt;

    int main () {
      double a[] = { 1, 2, 3 };
      return std::accumulate (a, a + 3, 2.0,
        std::pointer_to_binary_function&lt;double, double, double&gt;(std::pow));
    }
</PRE>

<BR>
<BR>
<HR>
<A NAME="107"></A>
<H4>107.
  
Linkage of operator functions
</H4>
<B>Section: </B>7.5&nbsp;



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

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

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

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



<P>[Picked up by evolution group at October 2002 meeting.]</P>



<P>
<U>Steve Clamage:</U>
I can't find anything in the standard that prohibits a language
linkage on an operator function.  For example:</P>
<BLOCKQUOTE>
<PRE>
extern "C" int operator+(MyInt, MyInt) { ... }
</PRE>
</BLOCKQUOTE>
<P>Clearly it is a bad idea, you could have only one <TT>operator+</TT>
with "C" linkage in the entire program, and you can't call the function
from C code.</P>

<P>
<U>Mike Miller:</U>
Well, you can't <I>name</I> an operator function in C code, but if
the arguments are compatible (e.g., not references), you <I>can</I>
call it from C code via a pointer.  In fact, because the language
linkage is part of the function type, you couldn't pass the
address of an operator function into C code unless you could
declare the function to be extern "C".</P>

<P>
<U>Fergus Henderson:</U>
In the general case, for linkage to languages other than C,
this could well make perfect sense.</P>

<P>
<U>Steve Clamage:</U>
</P>
<P>But is it disallowed (as opposed to being stupid), and if so, where
in the standard does it say so?</P>

<P>
<U>Mike Miller:</U>
I don't believe there's a restriction.  Whether that is because
of the (rather feeble) justification of being able to call an
operator from C code via a pointer, or whether it was simply
overlooked, I don't know.</P>

<P>
<U>Fergus Henderson:</U>
I don't think it is disallowed.  I also don't think there is any need
to explicitly disallow it.</P>

<P>
<U>Steve Clamage</U>:
I don't think the standard is clear enough on this point.  I'd
like to see a clarification.</P>

<P>I think either of these two clarifications would be appropriate:</P>

<OL>
<LI>
A linkage specification on an operator function is ill-formed.</LI>

<LI>
A linkage specification on an operator function is
well-formed, but the semantics (e.g.  name mangling) are
implementation-defined.  In addition, the rule about multiple
functions with the same name having "C" linkage applies.</LI>

<PRE>
    extern "C" T operator+(T,T); // ok
    extern "C" T operator-(T,T); // ok
    extern "C" U operator-(U);   // error, two extern "C" operator- 
</PRE>
</OL>

<P>
<U>Mike Miller</U>:
I think the point here is that something like</P>

<PRE>
    extern "xyzzy" bool operator&lt;(S&amp;,S&amp;)
</PRE>

could well make sense, if language xyzzy is sufficiently compatible with
C++, and the one-function rule only applies to extern "C", not to other
language linkages.  Given that it might make sense to have general
language linkages for operators, is it worthwhile to make an exception
to the general rule by saying that you can have any language linkage
on an operator function except "C" linkage?  I don't like exceptions to
general rules unless they're very well motivated, and I don't see
sufficient motivation to make one here.

<P>Certainly this capability isn't very useful.  There are lots
of things in C++ that aren't very useful but just weren't
worth special-casing out of the language.  I think this falls
into the same category.</P>

<P>
<U>Mike Ball</U>:
I DON'T want to forbid operator functions within an
extern "C".  Rather I want to add operator functions to that sentence
in paragraph 4 of
7.5&nbsp;



 <A HREF="dcl.html#dcl.link">dcl.link</A>
 which reads</P>

<BLOCKQUOTE>
A C language linkage is ignored for the names of class members and 
the member function type of class member functions.
</BLOCKQUOTE>

My reason is simple:  C linkage makes a total hash of scope. Any "C" functions
declared with the same name in any namespace scope are the same function.
In other words, namespaces are totally ignored.

<P>This provision was added in toward the end of the standardization process,
and was, I thought, primarily to make it possible to put the C library
in namespace <TT>std</TT>.  Otherwise, it seems an unwarrented attack on the
very concept of scope.  We (wisely) didn't force this on static member
functions, since it would essentially promote them to the global scope.</P>

<P>Now I think that programmers think of operator functions as essentially
part of a class.  At least for one very common design pattern they are
treated as part of the class interface.  This pattern is the reason we
invented Koenig lookup for operator functions.</P>

<P>What happens when such a class definition is included, deliberately or
not, in an extern "C" declaration?  The member operators continue to
work, but the non-member operators can suddenly get strange and
hard to understand messages.  Quite possibly, they get the messages
only when combined with other classes in other compilation units.
You can argue that the programmer shouldn't put the class header
in a linkage delaration in the first place, but I can still find books
that recommend putting `extern "C"' around entire header files,
so it's going to happen.</P>

<P>I think that including operator functions in the general exclusion from
extern "C" doesn't remove a capability, rather it ensurs a capability
that programmers already think they have.</P>

<P>
<B>Rationale (10/00):</B>
</P>

<P>The benefits of creating an exception for operator functions
were outweighed by the complexity of adding another special case
to the rules.</P>
<BR>
<BR>
<HR>
<A NAME="168"></A>
<H4>168.
  
C linkage for static member functions
</H4>
<B>Section: </B>7.5&nbsp;



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

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

 <B>Submitter: </B>Darin Adler
 &nbsp;&nbsp;&nbsp;

 <B>Date: </B>9 Sep 1999<BR>



<P>[Picked up by evolution group at October 2002 meeting.]</P>

<P>7.5&nbsp;



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

<BLOCKQUOTE>
A C language linkage is 
ignored for the names of class members and the member function types of
class member functions.
</BLOCKQUOTE>

This makes good sense, since C linkage names
typically aren't compatible with the naming used for member functions at
link time, nor is C language linkage function type necessarily compatible
with the calling convention for passing <TT>this</TT> to a non-static member
function.

<P>But C language linkage type (not name) for a static member function is
invaluable for a common programming idiom. When calling a C function that
takes a pointer to a function, it's common to use a private static member
function as a "trampoline" which retrieves an object reference (perhaps by
casting) and then calls a non-static private member function. If a static
member function can't have a type with C language linkage, then a global or
friend function must be used instead. These alternatives expose more of a
class's implementation than a static member function; either the friend
function itself is visible at namespace scope alongside the class definition
or the private member function must be made public so it can be called by a
non-friend function.</P>

<P>Suggested Resolution: Change the sentence cited above
to:</P>

<BLOCKQUOTE>
A C language linkage is ignored for the names of class members and the
member function types of <B>non-static</B> class member functions.
</BLOCKQUOTE>

The example
need not be changed because it doesn't involve a static member function.

<P>The following workaround accomplishes the goal of not exposing
the class's implementation, but at the cost of significant
superstructure and obfuscation:</P>

<PRE>
    // foo.h
    extern "C" typedef int c_func(int);
    typedef int cpp_func(int);
    class foo
    {
    private:
      c_func* GetCallback();
      static int Callback(int);
    };

    // foo.cpp
    #include "foo.h"

    // A local pointer to the static member that will handle the callback.
    static cpp_func* cpp_callback=0;

    // The C function that will actually get registered.
    extern "C" int CFunk(int i)
    {
      return cpp_callback(i);
    }

    c_func* foo::GetCallback()
    {
      cpp_callback = &amp;Callback;    // Only needs to be done once.
      return &amp;CFunk;
    }
</PRE>

<P>
<B>Rationale (10/99):</B> The Standard correctly reflects the
intent of the Committee.</P>
<BR>
<BR>
<HR>
<A NAME="359"></A>
<H4>359.
  
Type definition in anonymous union
</H4>
<B>Section: </B>9.5&nbsp;



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

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

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

 <B>Date: </B>31 May 2002<BR>


<P>Is this legal?  Should it be?</P>
<PRE>
  struct E {
    union {
      struct { int x; } s;
    } v;
  };
</PRE>
<P>One compiler faults a type definition (i.e. of the anonymous
struct) since it is in an anonymous union [9.5&nbsp;



 <A HREF="class.html#class.union">class.union</A>
paragraph 2:
"The <I>member-specification</I> of an anonymous union shall only define
non-static data members."].</P>

<P>I would suggest that compiler B is correctly interpreting the
standard but that this is a defect in the standard.  There is
no reason to disallow definition of anonymous structs.</P>

<P>Furthermore, is it really necessary to disallow definition of
named types in anonymous unions in general, as long as the
types do not need fully qualified names for external linkage?
Why should this be illegal?</P>
<PRE>
  struct E {
    union {
      typedef int Int;
      struct X { X *next; Int n; } list;
    } v;
  };
</PRE>

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

<P>There was agreement that the standard says such declarations
are invalid; therefore this must be considered as an extension.
There was general feeling that this extension would not
be too useful, though
Jason Merrill was sympathetic to the argument.  It was also
agreed that if this were to be changed it would require careful
wording so as not to allow too many cases.</P>

<BR>
<BR>
<HR>
<A NAME="6"></A>
<H4>6.
  
Should the optimization that allows a class object to alias another object also allow the case of a parameter in an inline function to alias its argument?
</H4>
<B>Section: </B>12.8&nbsp;



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

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

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

 <B>Date: </B>unknown<BR>



<P>[Picked up by evolution group at October 2002 meeting.]</P>


 
(See also paper J16/99-0005 = WG21 N1182.)

<P>At the London meeting,
12.8&nbsp;



 <A HREF="special.html#class.copy">class.copy</A>
 paragraph 15 was changed to
limit the optimization described to only the following cases:</P>
<UL>
<LI>
the source is a temporary object</LI>
    
<LI>
the return value optimization</LI>
</UL>
One other case was deemed desirable as well:
<UL>
<LI>
aliasing a parameter in an inline function call to the function call argument.</LI>
</UL>
However, there are cases when this aliasing was deemed undesirable and,
at the London meeting, the committee was not able to clearly delimit which
cases should be allowed and which ones should be prohibited.
    
<P>Can we find an appropriate description for the desired cases?</P>
    
<P>
<B>Rationale (04/99):</B> The absence of this optimization does
not constitute a defect in the Standard,
although the proposed resolution in the paper
should be considered when the Standard is revised.</P>
<BR>
<BR>
<HR>
<A NAME="150"></A>
<H4>150.
  
Template template parameters and default arguments
</H4>
<B>Section: </B>14.3.3&nbsp;



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

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

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

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



<P>[Picked up by evolution group at October 2002 meeting.]</P>



<P>How are default template arguments handled with respect to template
template parameters?  Two separate questions have been raised:</P>

<OL>
<LI>
Do default template arguments allow a template argument to match a
template parameter with fewer template parameters, and can the
template template parameter be specialized using the smaller number of
template arguments?  For example,

<PRE>
    template &lt;class T, class U = int&gt;
    class ARG { };

    template &lt;class X, template &lt;class Y&gt; class PARM&gt;
    void f(PARM&lt;X&gt;) { }    // specialization permitted?

    void g() {
        ARG&lt;int&gt; x;        // actually ARG&lt;int, int&gt;
        f(x);              // does ARG (2 parms, 1 with default)
                           // match PARM (1 parm)?
</PRE>

Template template parameters are deducible
(14.8.2.5&nbsp;



 <A HREF="template.html#temp.deduct.type">temp.deduct.type</A>
 paragraph 9),
but 14.3.3&nbsp;



 <A HREF="template.html#temp.arg.template">temp.arg.template</A>
 does not
specify how matching is done.

<P>
<U>Jack Rouse</U>:
I implemented template template parameters assuming template signature
matching is analogous to function type matching.  This seems like the
minimum reasonable implementation.  The code in the example would not
be accepted by this compiler.  However, template default arguments are
compile time entities so it seems reasonable to relax the matching
rules to allow cases like the one in the example.  But I would
consider this to be an extension to the language.</P>

<P>
<U>Herb Sutter</U>:
An open issue in the LWG is that the standard
doesn't explicitly permit or forbid implementations' adding additional
<I>template-parameter</I>s
to those specified by the standard, and the LWG may be
leaning toward explicitly permitting this. 
[Under this interpretation,]
if the standard is ever modified to allow additional
<I>template-parameter</I>s,
then writing "a template that takes a standard library template as a
template template parameter" won't be just ugly because you have to mention
the defaulted parameters; it would not be (portably) possible at all except
possibly by defining entire families of overloaded templates to account for
all the possible numbers of parameters
<TT>vector&lt;&gt;</TT> (or anything else) might
actually have. That seems unfortunate.</P>
</LI>

<LI>
Are default arguments permitted in the template parameter list of a
template template parameter?  For example,

<PRE>
    template &lt;template &lt;class T, class U = int&gt; class PARM&gt;
    class C {
        PARM&lt;int&gt; pi;
    };
</PRE>

<P>
<U>Jack Rouse</U>:
I decided they could not in the compiler I support.  This continues
the analogy with function type matching.  Also, I did not see a strong
need to allow default arguments in this context.</P>

<P>A class template used as a template template argument can have default
template arguments from its declarations.  How are the two sources of
default arguments to be reconciled?  The default arguments from the
template template formal could override.  But it could be cofusing if
a <I>template-id</I> using the argument template, <TT>ARG&lt;int&gt;</TT>, behaves
differently from a <I>template-id</I> using the template formal name,
<TT>FORMAL&lt;int&gt;</TT>.</P>
</LI>

</OL>

<P>
<B>Rationale (10/99):</B> Template template parameters are intended
to be handled analogously to function function parameters.  Thus the
number of parameters in a template template argument must match the
number of parameters in a template template parameter, regardless of
whether any of those paramaters have default arguments or not.  Default
arguments are allowed for the parameters of a template template
parameter, and those default arguments alone will be considered in
a specialization of the template template parameter within a template
definition; any default arguments for the parameters of a template
template argument are ignored.</P>

<P>
<B>Note (Mark Mitchell, February, 2006):</B>
</P>

<P>Perhaps it is already obvious to all, but it seems worth noting that
this extension would change the meaning of conforming programs:</P>

<PRE>
    struct Dense { static const unsigned int dim = 1; };

    template &lt;template &lt;typename&gt; class View,
              typename Block&gt;
    void operator+(float, View&lt;Block&gt; const&amp;);

    template &lt;typename Block,
              unsigned int Dim = Block::dim&gt;
    struct Lvalue_proxy { operator float() const; };

    void test_1d (void) {
        Lvalue_proxy&lt;Dense&gt; p;
        float b;
        b + p;
    }
</PRE>

<P>If <TT>Lvalue_proxy</TT> is allowed to bind to <TT>View</TT>, then the
template <TT>operator+</TT> will be used to perform addition; otherwise,
<TT>Lvalue_proxy</TT>'s implicit conversion to float, followed by the
built-in addition on floats will be used.</P>

<BR>
<BR>
<HR>
<A NAME="229"></A>
<H4>229.
  
Partial specialization of function templates
</H4>
<B>Section: </B>14.5.4&nbsp;



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

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

 <B>Submitter: </B>Dave Abrahams
 &nbsp;&nbsp;&nbsp;

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


<P>Library issue 225 poses the following questions:</P>

<OL>

<LI>How can a 3rd party library implementor (lib1) write a version of
a standard algorithm which is specialized to work with his own class
template? </LI>

<LI>How can another library implementor (lib2) write a generic
algorithm which will take advantage of the specialized algorithm in
lib1?</LI>

</OL>

<P>For example, a programmer might want to provide a version of
<TT>std::swap</TT> that would be used for any specialization of a
particular class template.  It is possible to do that for specific
types, but not for all specializations of a template.</P>

<P>The problem is due to the fact that programmers are forbidden to
add overloads to namespace <TT>std</TT>, although specializations are
permitted.  One suggested solution would be to allow partial
specialization of function templates, analogous to partial
specialization of class templates.</P>

<P>Library issue 225 contains a detailed proposal for adding partial
specialization of function templates (not reproduced here in the
interest of space and avoiding multiple-copy problems).  This Core
issue is being opened to provide for discussion of the proposal within
the core language working group.</P>

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

<P>A major concern over the idea of partial specialization of
function templates is that function templates can be overloaded,
unlike class templates.  Simply naming the function template in
the specialization, as is done for class specialization, is not
adequate to identify the template being specialized.</P>

<P>In view of this problem, the library working group is exploring
the other alternative, permitting overloads to be added to functions
in namespace <TT>std</TT>, as long as certain restrictions (to be
determined) are satisfied.</P>

<P>(See also documents N1295 and N1296 and
<A HREF="
     cwg_closed.html#285">issue 285</A>.)</P>

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

<P> The Core Working Group decided to ask the Library Working Group
for guidance on whether this feature is still needed to resolve a
library issue.  The answer at present is "we don't know."</P>

<P>
<B>Rationale (October, 2004):</B>
</P>

<P>The Core Working Group decided that the Evolution Working Group is
the appropriate forum in which to explore the desirability and form of
this feature.</P>

<BR>
<BR>
<BR>
<BR>
</BODY>
</HTML>
