<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/01-0037 = WG21 N1323</TD>
</TR>
<TR>
<TD ALIGN="RIGHT">
      Date:
     </TD><TD>
      &nbsp;12 September, 2001</TD>
</TR>
<TR>
<TD ALIGN="RIGHT">
      Project:
     </TD><TD>
      &nbsp;Programming Language C++
     </TD>
</TR>
<TR>
<TD ALIGN="RIGHT">
      Reference:
     </TD><TD>
      &nbsp;ISO/IEC IS 14882:1998(E)
     </TD>
</TR>
<TR>
<TD ALIGN="RIGHT">
      Reply to:
     </TD><TD>
      &nbsp;J. Stephen Adamczyk
     </TD>
</TR>
<TR>
<TD></TD><TD>
      &nbsp;<TT>jsa@edg.com</TT></TD>
</TR>
</TABLE>
<BR CLEAR="ALL">
<BR>
<CENTER>
<H2>



     C++ Standard Core Language
     
       Closed Issues,
      



     Revision
     19</H2>
<H3>Committee Version</H3>
</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>
<SCRIPT type="text/javascript">
  var seqno = 1;
 </SCRIPT>
<HR>
<A NAME="NAD Status"></A>
<H3>Issues with "NAD" Status</H3>
<HR>
<A NAME="50"></A>
<H4>50.
  
Converting pointer to incomplete type to same type
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>3.2&nbsp;



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

 <B>Status: </B>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>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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>From reflector message core-7848.</P>


<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="91"></A>
<H4>91.
  
A union's associated types should include the union itself
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>3.4.2&nbsp;



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

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

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

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




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


<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="132"></A>
<H4>132.
  
Local types and linkage
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>3.5&nbsp;



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

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

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

 <B>Date: </B>25 June 1999
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>Vandevoorde<BR>




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


<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="220"></A>
<H4>220.
  
All deallocation functions should be required not to throw
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>3.7.3.2&nbsp;



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

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

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

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



<P>From reflector message 8653.</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="234"></A>
<H4>234.
  
Reuse of base class subobjects
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>3.8&nbsp;



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

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

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

 <B>Date: </B>28 Jun 2000
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2<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="71"></A>
<H4>71.
  
Incorrect cross reference
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>5&nbsp;



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

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

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

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




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


<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="54"></A>
<H4>54.
  
Static_cast from private base to derived class
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>5.2.9&nbsp;



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

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

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

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



<P>Is it okay to use a <TT>static_cast</TT> to cast from a private base
class to a derived class? That depends on what the words "valid standard
conversion" in paragraph 8 mean &mdash; do they mean the conversion exists,
or that it would not get an error if it were done? I think the former
was intended &mdash; and therefore a <TT>static_cast</TT> from a private base
to a derived class would be allowed.</P>

<P>
<B>Rationale (04/99):</B> A <TT>static_cast</TT> from a private
base to a derived class is not allowed outside a member from the
derived class, because 4.10&nbsp;



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

paragraph 3 implies that the conversion is not valid. (Classic style
casts work.)</P>
<BR>
<BR>
<HR>
<A NAME="31"></A>
<H4>31.
  
Looking up new/delete
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>5.3.4&nbsp;



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

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

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

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




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


<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>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>5.3.4&nbsp;



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

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

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

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




<P>From reflector messages 8132-3, 8136-7, 8141, 8148, 8150-51.</P>


<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="256"></A>
<H4>256.
  
Overflow in size calculations
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>5.3.4&nbsp;



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

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

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

 <B>Date: </B>15 Oct 2000
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2<BR>


<P>From messages 8923-30, 8938.</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>

<BR>
<BR>
<HR>
<A NAME="55"></A>
<H4>55.
  
Adding/subtracting pointer and enumeration value
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>5.7&nbsp;



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

 <B>Status: </B>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="97"></A>
<H4>97.
  
Use of bool constants in integral constant expressions
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>5.19&nbsp;



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

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

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

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




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

    
<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="154"></A>
<H4>154.
  
Anonymous unions in unnamed namespaces
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>7.1.1&nbsp;



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

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

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

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




<P>From reflector messages 8243-4.</P>


<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="95"></A>
<H4>95.
  
Elaborated type specifiers referencing names declared in friend decls
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>7.3.1.2&nbsp;



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

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

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

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



<P>From reflector messages core-7966 through 7974.</P>


<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_active.html#136">136</A>,
<A HREF="
     cwg_active.html#138">138</A>,
<A HREF="
     cwg_active.html#139">139</A>,
<A HREF="
     cwg_active.html#143">143</A>,
<A HREF="
     cwg_closed.html#165">165</A>, and
<A HREF="
     cwg_defects.html#166">166</A>.)</P>
<BR>
<BR>
<HR>
<A NAME="165"></A>
<H4>165.
  
Definitions of friends and block-scope externs
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>7.3.1.2&nbsp;



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

 <B>Status: </B>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_active.html#136">136</A>,
<A HREF="
     cwg_active.html#138">138</A>,
<A HREF="
     cwg_active.html#139">139</A>,
<A HREF="
     cwg_active.html#143">143</A>, and
<A HREF="
     cwg_defects.html#166">166</A>.)</P>
<BR>
<BR>
<HR>
<A NAME="169"></A>
<H4>169.
  
<I>template-id</I>s in <I>using-declaration</I>s
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>7.3.3&nbsp;



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

 <B>Status: </B>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="14"></A>
<H4>14.
  
extern "C" functions and declarations in different namespaces
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>7.5&nbsp;



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

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

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

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


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

    
<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="107"></A>
<H4>107.
  
Linkage of operator functions
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>7.5&nbsp;



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

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

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

 <B>Date: </B>21 Apr 1999
  &nbsp;&nbsp;&nbsp;
  <B>Priority: </B>2<BR>




<P>From reflector messages 8020-21, 8290-8304, 8306-7.</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>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>7.5&nbsp;



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

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

 <B>Submitter: </B>Darin Adler
 &nbsp;&nbsp;&nbsp;

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



<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="18"></A>
<H4>18.
  
f(TYPE) where TYPE is void should be allowed
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>8.3.5&nbsp;



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

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

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

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




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


<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>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>8.3.6&nbsp;



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

 <B>Status: </B>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="7"></A>
<H4>7.
  
Can a class with a private virtual base class be derived from?
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>11.2&nbsp;



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

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

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

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




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


<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>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>11.2&nbsp;



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

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

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

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




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


<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="209"></A>
<H4>209.
  Must friend declaration names be
accessible?</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>11.4&nbsp;



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

 <B>Status: </B>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="19"></A>
<H4>19.
  
Clarify protected member access
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>11.5&nbsp;



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

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

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

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




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


<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>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>12.2&nbsp;



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

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

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

 <B>Date: </B>14 May 1999
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>O'Riordan<BR>




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


<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="26"></A>
<H4>26.
  
Copy constructors and default arguments
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>12.8&nbsp;



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

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

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

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




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


<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="102"></A>
<H4>102.
  
Operator lookup rules do not work well with parts of the library
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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>From reflector messages 7864, 7870, 7872, 7997.</P>


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

(core-7870)

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

(core-7872)

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

(core-7997)

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>

@Dublin '99

:  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="61"></A>
<H4>61.
  
Address of static member function "<TT>&amp;p-&gt;f</TT>"
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>13.4&nbsp;



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

 <B>Status: </B>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>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>13.4&nbsp;



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

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

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

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


<P>From messages 8908, 8910-11, and 8913.</P>

<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>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>13.6&nbsp;



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

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

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

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




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


<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="150"></A>
<H4>150.
  
Template template parameters and default arguments
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>14.3.3&nbsp;



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

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

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

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




<P>From reflector messages 8235-36, 8239-40, and c++std-all-2063.</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.4&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>
<BR>
<BR>
<HR>
<A NAME="114"></A>
<H4>114.
  
Virtual overriding by template member function specializations
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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>From reflector messages 8049-8052, 8054-8058.</P>


<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>
<BR>
<BR>
<HR>
<A NAME="47"></A>
<H4>47.
  
Template friend issues
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>14.5.3&nbsp;



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

 <B>Status: </B>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="34"></A>
<H4>34.
  
Argument dependent lookup and points of instantiation
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>14.7.1&nbsp;



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

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

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

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


    

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

    
<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="46"></A>
<H4>46.
  
Explicit instantiation of member templates
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>14.7.2&nbsp;



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

 <B>Status: </B>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>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>14.7.3&nbsp;



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

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

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

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




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


<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>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>14.7.3&nbsp;



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

 <B>Status: </B>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="99"></A>
<H4>99.
  
Partial ordering, references and cv-qualifiers
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>14.8.2.1&nbsp;



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

 <B>Status: </B>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>
<BR>
<BR>
<HR>
<A NAME="211"></A>
<H4>211.
  
Constructors should not be allowed to return normally after an exception
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>15&nbsp;



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

 <B>Status: </B>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>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>15.1&nbsp;



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

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

 <B>Submitter: </B>Jonathan Schilling
 &nbsp;&nbsp;&nbsp;

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




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


<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="37"></A>
<H4>37.
  
When is uncaught_exception() true?
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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>From reflector message core-7806:</P>

    
<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>
<BR>
<BR>
<HR>
<A NAME="266"></A>
<H4>266.
  
No grammar sentence symbol
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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>From reflector message core-7883.</P>

    
<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>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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
  &nbsp;&nbsp;&nbsp;
  <B>Drafting: </B>O'Riordan<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>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>3.2&nbsp;



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

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

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

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




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


<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>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>3.4.2&nbsp;



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

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

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

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




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


<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.koenig">basic.lookup.koenig</A>
 paragraph 2, change</P>
<BLOCKQUOTE>If the ordinary unqualified lookup of the name finds the declaration
of a class member function, the associated namespaces and classes are not
considered.</BLOCKQUOTE>
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="72"></A>
<H4>72.
  
Linkage and storage class specifiers for templates
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>14&nbsp;



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

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

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

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




<P>From reflector messages core-7876-7878.</P>


<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>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>14.5.5.2&nbsp;



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

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

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

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




<P>From reflector messages 8509, 8511, and 8513-14.</P>


<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_active.html#214">issue 214</A>.</P>

<BR>
<BR>
<HR>
<A NAME="133"></A>
<H4>133.
  
Exception specifications and checking
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>15.4&nbsp;



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

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

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

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




<P>From reflector messages 8158 and 8168.</P>


<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>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><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>From reflector message core-7932.</P>

    
<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="11"></A>
<H4>11.
  
How do the keywords typename/template interact with using-declarations?
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>7.3.3&nbsp;



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

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

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

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




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


<P>
<B><U>Issue 1:</U></B>
</P>

<P>The working paper is not clear about how the typename/template keywords
interact with using-declarations:</P>
<PRE>
     template&lt;class T&gt; struct A {
         typedef int X;
     };
     
     template&lt;class T&gt; void f() {
         typename A&lt;T&gt;::X a;      // OK
         using typename A&lt;T&gt;::X;  // OK
         typename X b;  // ill-formed; X must be qualified
         X c;  // is this OK?
     }
</PRE>
When the rules for <TT>typename</TT> and the similar use of <TT>template</TT>
were decided, we chose to require that they be used at every reference.
The way to avoid <TT>typename</TT> at every use is to declare a typedef;
then the typedef name itself is known to be a type. For <I>using-declaration</I>s,
we decided that they do not introduce new declarations but rather are aliases
for existing declarations, like symbolic links. This makes it unclear whether
the declaration "<TT>X c;</TT>" above should be well-formed, because there
is no new name declared so there is no declaration with a "this is a type"
attribute. (The same problem would occur with the <TT>template</TT> keyword
when a member template of a dependent class is used). I think these are
the main options:
<OL>
<LI>
Continue to allow <TT>typename</TT> in <I>using-declaration</I>s, and <TT>template</TT>
(for member templates) too. Attach the "is a type" or "is a template"
attribute to the placeholder name which the using-declaration "declares"</LI>

<LI>
Disallow <TT>typename</TT> and <TT>template</TT> in <I>using-declaration</I>s
(just as <I>class-key</I>s are disallowed now). Allow <TT>typename</TT>
and <TT>template</TT> before unqualified names which refer to dependent
qualified names through <I>using-declaration</I>s.</LI>

<LI>
Document that this is broken.</LI>
</OL>
<B>Suggested Resolution:</B>

<P>The core WG already resolved this issue according to (1), but the wording
does not seem to have been added to the standard. New wording needs to
be drafted.</P>

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

<P>Either way, one more point needs clarification. If the first option
is adopted:</P>
<PRE>
     template&lt;class T&gt; struct A {
         struct X { };
     };
     
     template&lt;class T&gt; void g() {
         using typename A&lt;T&gt;::X;
         X c;    // if this is OK, then X by itself is a  type
         int X;  // is this OK?
     }
</PRE>
When "<TT>g</TT>" is instantiated, the two declarations of <TT>X</TT> are compatible
(7.3.3&nbsp;



 <A HREF="dcl.html#namespace.udecl">namespace.udecl</A>
 paragraph 10).
But there is no way to know this when the definition of "<TT>g</TT>" is
compiled. I think this case should be ill-formed under the first option.
(It cannot happen under the second option.) If the second option is adopted:
<PRE>
     template&lt;class T&gt; struct A {
         struct X { };
     };
     
     template&lt;class T&gt; void g() {
         using A&lt;T&gt;::X;
         int X;  // is this OK?
     }
</PRE>
Again, the instantiation would work but there is no way to know that in
the template definition. I think this case should be ill-formed under the
second option. (It would already be ill-formed under the first option.)

<P>From John Spicer:</P>
<BLOCKQUOTE>The "not a new declaration" decision is more of a guiding principle
than a hard and fast rule. For example, a name introduced in a 
<I>using-declaration</I>
can have different access than the original declaration.

<P>Like symbolic links, a <I>using-declaration</I> can be viewed as a declaration
that declares an alias to another name, much like a typedef.</P>

<P>In my opinion, "<TT>X c;</TT>" is already well-formed. Why would we permit
<TT>typename</TT> to be used in a <I>using-declaration</I> if not to permit this
precise usage?</P>

<P>In my opinion, all that needs to be done is to clarify that the "typeness"
or "templateness" attribute of the name referenced in the <I>using-declaration</I>
is attached to the alias created by the <I>using-declaration</I>. This is
solution #1.</P>
</BLOCKQUOTE>
<B>Tentative Resolution:</B>

<P>The rules for multiple declarations with the same name in the same scope
should treat a <I>using-declaration</I> which names a type as a typedef,
just as a typedef of a class name is treated as a class declaration. This
needs drafting work. Also see <A HREF="
     cwg_active.html#36">Core issue 36</A>.</P>

<P>
<B>Rationale (04/99):</B> Any semantics associated with the
<TT>typename</TT> keyword in <I>using-declaration</I>s should be considered an
extension.</P>
<BR>
<BR>
<HR>
<A NAME="109"></A>
<H4>109.
  
Allowing ::template in using-declarations
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>7.3.3&nbsp;



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

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

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

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



<P>
<I>Daveed Vandevoorde

in core-8008

:</I>
While reading <A HREF="
     cwg_closed.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

in core-8010

:</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>
<BR>
<BR>
<HR>
<A NAME="13"></A>
<H4>13.
  
extern "C" for Parameters of Function Templates
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>7.5&nbsp;



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

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

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

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




<P>(Previously numbered 921.)</P>
<P>See also reflector messages 8624-6, 8628, and 8630.</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="15"></A>
<H4>15.
  
Default arguments for parameters of function templates
</H4>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>8.3.6&nbsp;



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

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

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

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




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


<P>8.3.6&nbsp;



 <A HREF="decl.html#dcl.fct.default">dcl.fct.default</A>
 paragraph 4 says:</P>
<BLOCKQUOTE>For non-template functions, default arguments can be added
in later declarations of a 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>
<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>
<SCRIPT type="text/javascript">
   document.write("(#" + seqno++ + ") ");
  </SCRIPT><B>Section: </B>12.8&nbsp;



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

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

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

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



 
<P>(Previously numbered 876b.)</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>
<BR>
<BR>
</BODY>
</HTML>
