This document contains the C++ core language issues that have been categorized as Defect Reports by the C++ Standard Committee (J16 + WG21), along with their proposed resolutions. THESE RESOLUTIONS ARE NOT YET PART OF THE INTERNATIONAL STANDARD FOR C++. They are provided for informational purposes only, as an indication of the intent of the Committee. They should not be considered definitive until or unless they appear in an approved Technical Corrigendum or revised International Standard for C++.

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:

• Active Issues List, 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.
• Closed Issues List, which contains the issues which the Committee has decided are not defects in the International Standard, including a brief rationale explaining the reason for the decision.
• Table of Contents, which contains a summary listing of all issues in numerical order.
• Index by Section, which contains a summary listing of all issues arranged in the order of the sections of the Standard with which they deal most directly.
• Index by Status, which contains a summary listing of all issues grouped by status.

For more information, including a description of the meaning of the issue status codes and instructions on reporting new issues, please see the Active Issues List.

Issues with "DR" Status

173. Constraints on execution character set

[Part of TC1.]

22.2.1.1.2  lib.locale.ctype.virtuals paragraph 13 states a constraint on the values of the characters representing the decimal digits in the execution character set:

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

Proposed resolution (10/00):

In 2.2  lex.charset paragraph 3, after the sentence

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

In both the source and execution basic character sets, the value of each character after 0 in the above list of decimal digits shall be one greater than the value of the previous.

41. Clarification of lookup of names after declarator-id

[Part of TC1.]

From reflector message core-7838.

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

Proposed Resolution (04/99): Change the text in 3.4.1  basic.lookup.unqual paragraph 6 from:

A name used in the definition of a function [footnote: This refers to unqualified names following the function declarator; such a name may be used as a type or as a default argument name in the parameter-declaration-clause, or may be used in the function body. end footnote] that is ...

A name used in the definition of a function following the function's declarator-id [footnote: This refers to unqualified names that occur, for instance, in a type or default argument expression in the parameter-declaration-clause or used in the function body. end footnote] that is ...

A name used in the definition of a function that is a member function (9.3  class.mfct ) [footnote: That is, an unqualified name following the function declarator; such a name may be used as a type or as a default argument name in the parameter-declaration-clause, or may be used in the function body, or, if the function is a constructor, may be used in the expression of a mem-initializer. end footnote] of class X shall be ...

A name used in the definition of a member function (9.3  class.mfct ) of class X following the function's declarator-id [footnote: That is, an unqualified name that occurs, for instance, in a type or default argument expression in the parameter-declaration-clause, in the function body, or in an expression of a mem-initializer in a constructor definition. end footnote] shall be ...

139. Error in friend lookup example

[Moved to DR at 10/01 meeting.]

The example in 3.4.1  basic.lookup.unqual paragraph 3 is incorrect:

    typedef int f;
    struct A {
        friend void f(A &);
        operator int();
        void g(A a) {
            f(a);
        }
    };

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

(See also issues 95, 136, 138, 143, 165, and 166.)

Proposed resolution (04/01):

1. Change the example in 3.4.1  basic.lookup.unqual paragraph 3 to read:

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

2. Delete the sentence immediately following the example:

   The expression f(a) is a cast-expression equivalent to int(a).

33. Argument dependent lookup and overloaded functions

[Part of TC1.]

From reflector message core-7768.

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

My inclination is to say no to both.

From Mike Miller:

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

Proposed Resolution (04/99): In 3.4.2  basic.lookup.koenig paragraph 2, add following the last bullet in the list of associated classes and namespaces for various argument types (not a bullet itself because overload sets and templates do not have a type):

In addition, if the argument is the name or address of a set of overloaded functions and/or function templates, its associated classes and namespaces are the union of those associated with each of the members of the set: the namespace in which the function or function template is defined and the classes and namespaces associated with its (non-dependent) parameter types and return type.

90. Should the enclosing class be an "associated class" too?

[Part of TC1.]

From reflector message core-7952.

Section 3.4.2  basic.lookup.koenig includes the following:

• If T is a class type, its associated classes are the class itself and its direct and indirect base classes. Its associated namespaces are the namespaces in which its associated classes are defined.
• If T is a union or enumeration type, its associated namespace is the namespace in which it is defined. If it is a class member, its associated class is the member's class; else it has no associated class.

    struct A {
        union U {};
        friend void f(U);
    };
            
    struct B {
        struct S {};
        friend void f(S);
    };
             
    int main() { 
        A::U    u; 
        f(u);        // okay: A is an associated class
        B::S    s;
        f(s);        // error: no matching f(), B is not an associated class
    }

Proposed Resolution (10/99): Change the two referenced bullets to read:

• If T is a class type (including unions), its associated classes are: the class itself; the class of which it is a member, if any; and its direct and indirect base classes. Its associated namespaces are the namespaces in which its associated classes are defined.
• If T is an enumeration type, its associated namespace is the namespace in which it is defined. If it is class member, its associated class is the member's class; else it has no associated class.

143. Friends and Koenig lookup

[Moved to DR at 4/02 meeting.]

From reflector message 8228.

Paragraphs 1 and 2 of 3.4.2  basic.lookup.koenig say, in part,

When an unqualified name is used as the postfix-expression in a function call (5.2.2  expr.call )... namespace-scope friend function declarations (11.4  class.friend ) not otherwise visible may be found... the set of declarations found by the lookup of the function name [includes] the set of declarations found in the... classes associated with the argument types.

Consider the following example:

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

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

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

Proposed resolution (04/01): The "associated classes" are handled adequately under this interpretation by 3.4.2  basic.lookup.koenig paragraph 3, which describes the lookup in the associated namespaces as including the friend declarations from the associated classes. Other mentions of the associated classes should be removed or qualified to avoid the impression that there is a lookup in those classes:

1. In 3.4.2  basic.lookup.koenig, change

   When an unqualified name is used as the postfix-expression in a function call (5.2.2  expr.call), other namespaces not considered during the usual unqualified lookup (3.4.1  basic.lookup.unqual) may be searched, and namespace-scope friend function declarations (11.4  class.friend) not otherwise visible may be found.

   to

   When an unqualified name is used as the postfix-expression in a function call (5.2.2  expr.call), other namespaces not considered during the usual unqualified lookup (3.4.1  basic.lookup.unqual) may be searched, and in those namespaces, namespace-scope friend function declarations (11.4  class.friend) not otherwise visible may be found.

2. In 3.4.2  basic.lookup.koenig paragraph 2, delete the words and classes in the following two sentences:

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

(See also issues 95, 136, 138, 139, 165, 166, and 218.)

164. Overlap between Koenig and normal lookup

[Part of TC1.]

The description of Koenig lookup in 3.4.2  basic.lookup.koenig paragraph 1 says,

...other namespaces not considered during the usual unqualified lookup (3.4.1  basic.lookup.unqual ) may be searched.

    void f(int);

    template <class T> void g(T t) {
        f(t);
    }

    enum E { e };

    void f(E);

    void h() {
        g(e);
    }

Proposed Resolution (10/00):

Immediately preceding the example at the end of 3.4.2  basic.lookup.koenig paragraph 2, add the following:

[Note: the namespaces and classes associated with the argument types can include namespaces and classes already considered by the ordinary unqualified lookup.]

85. Redeclaration of member class

[Part of TC1.]

In 3.4.4  basic.lookup.elab paragraph 3, there is the example

    struct Base {
        // ...
        struct Data { /* ... */ };  // Defines nested Data
        struct Data;                // OK: Redeclares nested Data
    };

Proposed resolution (10/00): Remove the line

        struct Data;                // OK: Redeclares nested Data

See also Core issue 36 and Core issue 56.

216. Linkage of nameless class-scope enumeration types

[Moved to DR at 10/01 meeting.]

From reflector message 8600.

A name having namespace scope has external linkage if it is the name of

• [...]
• a named enumeration (7.2  dcl.enum), or an unnamed enumeration defined in a typedef declaration in which the enumeration has the typedef name for linkage purposes (7.1.3  dcl.typedef)

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

However, the same prohibition was not made for class scope types. Indeed, 3.5  basic.link paragraph 5 says:

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

That allows for:

    struct S {
       typedef enum { e1 } *MPE;
       void mf(MPE) {}
    };

My guess is that this is an unintentional consequence of 3.5  basic.link paragraph 5, but I would like confirmation on that.

Proposed resolution:

Change text in 3.5  basic.link paragraph 5 from:

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

In addition, a member function, a static data member, a named class or enumeration of class scope, or an unnamed class or enumeration defined in a class-scope typedef declaration such that the class or enumeration has the typedef name for linkage purposes (7.1.3  dcl.typedef), has external linkage if the name of the class has external linkage.

270. Order of initialization of static data members of class templates

[Moved to DR at 4/02 meeting.]

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

Suggested resolution: Add the following verbiage to either 3.6.2  basic.start.init or 9.4.2  class.static.data:

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

Notes from 04/01 meeting:

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

Proposed resolution (04/01, updated slightly 10/01):

Replace the following sentence in 3.6.2  basic.start.init paragraph 1:

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

with

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

Note (07/01):

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

(The full text is in core message 9263.)

I have a class for representing linked lists which looks something like

    template <class T>
    class List {
       ...  static List<T>* sentinel; ...
    };
 
    template <class T>
    List<T>* List<T>::sentinel( new List<T> ); // static member definition

The sentinel list node is used to represent "nil" (the null pointer cannot be used with my implementation, for reasons which are immaterial to this discussion). All of the List's non-static member functions and constructors depend upon the value of the sentinel. Under the proposed resolution for issue #270, Lists cannot be safely instantiated before main() begins, as the sentinel's initialization is "unordered".

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

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

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

Replace the following sentence in 3.6.2  basic.start.init paragraph 1:

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

Objects with static storage duration defined in namespace scope shall be initialized in the order described below.

Dynamic initialization is either ordered or quasi-ordered. Explicit specializations of class template static data members have ordered initialization. Other class template static data member instances have quasi-ordered initialization. All other objects defined in namespace scope have ordered initialization. The order of initialization is specified as follows:

• Objects that are defined within a single translation unit and that have ordered initialization shall be initialized in the order of their definitions in the translation unit.
• Objects that are defined only within a single translation unit and that have quasi-ordered initialization shall also be initialized in the order of their definitions in the translation unit -- that is, as though these objects had ordered initialization.
• Objects that are defined within multiple translation units (which, therefore, must have quasi-ordered initialization) shall be initialized as follows: in exactly one translation unit (which one is unspecified), the object shall be treated as though it has ordered initialization; in the other translation units which define the object, the object will be initialized before all other objects that have ordered initialization in those translation units.
• For any two objects, "X" and "Y", with static storage duration and defined in namespace scope, if the previous bullets do not imply a relationship for the initialization ordering between "X" and "Y", then the relative initialization order of these objects is unspecified.

[ Note: The intention is that translation units can each be compiled separately with no knowledge of what objects may be re-defined in other translation units. Each translation unit can contain a method which initializes all objects (both quasi-ordered and ordered) as though they were ordered. When these translation units are linked together to create an executable program, all of these objects can be initialized by simply calling the initialization methods (one from each translation unit) in any order. Quasi-ordered objects require some kind of guard to ensure that they are not initialized more than once (the first attempt to initialize such an object should succeed; any subsequent attempts should simply be ignored). ]

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

I would reject this idea and stand with the proposed resolution of issue 270.

There just is no portable way to ensure the "right" ordering of construction.

Notes from 10/01 meeting:

The Core Working Group reaffirmed its previous decision.

89. Object lifetime does not account for reference rebinding

[Part of TC1.]

A reference is rebindable. This is surprising and unnatural. This can also cause subtle optimizer bugs.

Example:

    struct T {
        int& ri;
        T (int& r) : ri (r) { }
    };
    
    void bar (T*);
    
    void foo () {
        int i;
        T x (i);
        x.ri = 3;   // the optimizer understands that this is really i = 3
        bar (&x);
        x.ri = 4;   // optimizer assumes that this writes to i, but this is incorrect
    }
    
    int gi;
    
    void bar (T* p) {
        p->~T ();
        new (p) T (gi);
    }

If we replace T& with T* const in the example then undefined behavior result and the optimizer is correct.

Proposal: make T& equivalent to T* const by extending the scope of 3.8  basic.life paragraph 9 to references.

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

In addition, Lisa Lippincott pointed out the following example:

    void f( const bool * );
    void g();

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

    void f( const bool *b ) {
       new ( const_cast<bool *>(b) ) const bool( true );
    }

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

Proposed Resolution (10/00):

Add a new bullet to the list of restrictions in 3.8  basic.life paragraph 7, following the second bullet ("the new object is of the same type..."):

• the type of the original object is not const-qualified, and, if a class type, does not contain any non-static data member whose type is const-qualified or a reference type, and

93. Missing word in 3.8 basic.life paragraph 2

[Part of TC1.]

From reflector message core-7956.

The text of 3.8  basic.life paragraph 2 currently reads,

[Note: the lifetime of an array object or of an object of type (3.9  basic.types ) starts...]

The phrase "an object of type" is obviously incorrect. I believe it should read "an object of POD type." Does anyone disagree?

Proposed Resolution (10/99): As suggested.

119. Object lifetime and aggregate initialization

[Moved to DR at 4/02 meeting.]

From reflector messages 8072-8073.

Jack Rouse: 3.8  basic.life paragraph 1 includes:

The lifetime of an object is a runtime property of the object. The lifetime of an object of type T begins when:

• storage with the proper alignment and size for type T is obtained, and
• if T is a class type with a non-trivial constructor (12.1  class.ctor ), the constructor call has completed.

    struct B {
        B( int = 0 );
        ~B();
    };

    struct S {
        B b1;
    };

    int main()
    {
        S s = { 1 };
        return 0;
    }

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

Another would be to add following "a class type with a non-trivial constructor" the phrase "that is not initialized with the brace notation (8.5.1  dcl.init.aggr )."

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

Proposed resolution (04/01):

In 3.8  basic.life paragraph 1, change

If T is a class type with a non-trivial constructor (12.1  class.ctor), the constructor call has completed.

to

If T is a class type with a non-trivial constructor (12.1  class.ctor), the initialization is complete. [Note: the initialization can be performed by a constructor call or, in the case of an aggregate with an implicitly-declared non-trivial default constructor, an aggregate initialization (8.5.1  dcl.init.aggr).]

43. Copying base classes (PODs) using memcpy

[Part of TC1.]

From reflector message core-7850.

Can you use memcpy on non-member POD subobjects of non-POD objects?

In 3.9  basic.types paragraphs 2 and 3 we have:

For any complete POD object type T, whether or not the object holds a valid value of type T, the underlying bytes (1.7  intro.memory ) making up the object can be copied into an array of char or unsigned char*. If the content of the array of char or unsigned char is copied back into the object, the object shall subsequently hold its original value. [Example elided]

*[Footnote: By using, for example, the library functions (17.4.1.2  lib.headers ) memcpy or memmove. end footnote]

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

Proposed Resolution (04/99): Change the text in 3.9  basic.types paragraph 2 from:

For any complete POD object type T, ...

For any object (other than a base class subobject) of POD type T, ...

For any POD type T, if two pointers to T point to distinct T objects obj1 and obj2,

For any POD type T, if two pointers to T point to distinct T objects obj1 and obj2, where neither obj1 nor obj2 is a base class subobject, ...

158. Aliasing and qualification conversions

[Moved to DR at 4/02 meeting.]

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

However, 4.4  conv.qual paragraph 4 permits a "conversion [to] add cv-qualifiers at levels other than the first in multi-level pointers." The combination of these two rules allows creation of pointers that cannot be dereferenced without causing undefined behavior. For instance:

    int* jp;
    const int * const * p1 = &jp;
    *p1;    // undefined behavior!

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

Since the conversion is permitted, we must give it defined semantics, hence we need to fix the wording in 3.10  basic.lval to include all possible conversions of the type via 4.4  conv.qual.

Proposed resolution (04/01):

Add a new bullet to 3.10  basic.lval paragraph 15, following "a cv-qualified version of the dynamic type of the object:"

• A type similar (as defined in 4.4  conv.qual) to the dynamic type of the object,

149. Accessibility and ambiguity

[Part of TC1.]

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

4.10  conv.ptr paragraph 3:

If B is an inaccessible or ambiguous base ...

... has an unambiguous public base ...

... is an unambiguous direct or indirect base ... and is accessible ...

not involving conversions to pointers to private or protected or ambiguous classes

The phrase "unambiguous public base" is unfortunate as it could mean either "an unambiguous base not considering accessibility, which is public" or "an unambiguous base considering only the publicly accessible bases." I believe the former interpretation correct, as accessibility is applied after visibility (11  class.access paragraph 4) and ambiguity is described in terms of visibility (10.2  class.member.lookup paragraph 2).

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

Proposed resolution (10/00):

• 5.2.7  expr.dynamic.cast paragraph 8, bullet 2: change "unambiguous public base class" to "unambiguous and public base class"
• 10.3  class.virtual paragraph 5: change "the class in the return type... is an unambiguous direct or indirect base class... and is accessible in D" to "the class in the return type... is an unambiguous and accessible direct or indirect base class..."

122. template-ids as unqualified-ids

[Moved to DR at 10/01 meeting.]

From reflector message core-8091.

5.1  expr.prim paragraph 11 reads,

A template-id shall be used as an unqualified-id only as specified in 14.7.2  temp.explicit , 14.7  temp.spec , and 14.5.4  temp.class.spec .

What uses of template-ids as unqualified-ids is this supposed to prevent? And is the list of referenced sections correct/complete? For instance, what about 14.8.1  temp.arg.explicit, "Explicit template argument specification?" Does its absence from the list in 5.1  expr.prim paragraph 11 mean that "f<int>()" is ill-formed?

This is even more confusing when you recall that unqualified-ids are contained in qualified-ids:

qualified-id: ::_opt nested-name-specifier template_opt unqualified-id

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

Proposed resolution (10/00):

Remove the referenced sentence altogether.

123. Bad cross-reference

[Part of TC1.]

From reflector message core-8092.

A nested-name-specifier that names a class, optionally followed by the keyword template (14.8.1  temp.arg.explicit ), ...

147. Naming the constructor

[Part of TC1.]

From paper J16/99-0010 = WG21 N1187.

5.1  expr.prim paragraph 7 says that class-name::class-name names the constructor when both class-name refer to the same class. (Note the different perspective, at least, in 12.1  class.ctor paragraph 1, in which constructors have no names and are recognized by syntactic context rather than by name.)

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

    template <class T> struct A {
        template <class T2> A(T2);
    };
    template<> template<> A<int>::A<int>(int);

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

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

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

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

    template <class T> struct A {
        template <class T2> A(T2);
        static A x;
    };
    template<> A<int>::A<int>(A<int>::x);

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

Proposed resolution (10/00):

In 9  class paragraph 2, change

The class-name is also inserted into the scope of the class itself. For purposes of access checking the inserted class name...

to

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

Also, in 3.4.3.1  class.qual, add the following before paragraph 2:

If the nested-name-specifier nominates a class C, and the name specified after the nested-name-specifier, when looked up in C, is the injected-class-name of C (clause 9  class), the name is instead considered to name the constructor of class C. Such a constructor name shall only be used in the declarator-id of a constructor definition that appears outside of the class definition. [Example:

    struct A { A(); };
    struct B: public A { B(); };

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

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

—end example]

Also, change 3.4  basic.lookup paragraph 3 from

Because the name of a class is inserted in its class scope (clause 9  class), the name of a class is also considered a member of that class for the purposes of name hiding and lookup.

to

The injected-class-name of a class (clause 9  class) is also considered to be a member of that class for the purposes of name hiding and lookup.

(See also issue 194.)

113. Visibility of called function

[Moved to DR at 10/01 meeting.]

From reflector messages 8046-8047.

Christophe de Dinechin: In 5.2.2  expr.call , paragraph 2 reads:

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

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

In fact, this paragraph should be a note. There's a general rule that says you have to find an unambiguous declaration of any name that is used (3.4  basic.lookup paragraph 1); the only reason this paragraph is here is to contrast with C's implicit declaration of called functions.

Proposed resolution:

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

[Note: if a function or member function name is used, and name lookup (3.4  basic.lookup) does not find a declaration of that name, the program is ill-formed. No function is implicitly declared by such a call. ]

(See also issue 218.)

52. Non-static members, member selection and access checking

[Part of TC1.]

5.2.5  expr.ref paragraph 4 should make it clear that when a nonstatic member is referenced in a member selection operation, the type of the left operand is implicitly cast to the naming class of the member. This allows for the detection of access and ambiguity errors on that implicit cast.

Proposed Resolution (10/00):

1. In 11.2  class.access.base paragraph 4, remove the following from the second note:

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

2. Add the following as a new paragraph 5 of 11.2  class.access.base:

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

3. In 11.2  class.access.base paragraph 4, fix a typographical error by adding the missing right parenthesis following the text

   (including cases where an implicit "this->" is added

4. Add following the first sentence of 5.2.2  expr.call paragraph 4:

   If the function is a nonstatic member function, the "this" parameter of the function (9.3.2  class.this) shall be initialized with a pointer to the object of the call, converted as if by an explicit type conversion (5.4  expr.cast). [Note: there is no access checking on this conversion; the access checking is done as part of the (possibly implicit) class member access operator. See 11.2  class.access.base.]

53. Lvalue-to-rvalue conversion before certain static_casts

[Part of TC1.]

Section 5.2.9  expr.static.cast paragraph 6 should make it clear that when any of the "inverse of any standard conversion sequence" static_casts are done, the operand undergoes the lvalue-to-rvalue conversions first.

Proposed Resolution (10/00):

In 5.2.9  expr.static.cast paragraph 6, change

can be performed explicitly using static_cast subject to the restriction that the explicit conversion does not cast away constness (5.2.11  expr.const.cast), ...

to

can be performed explicitly using static_cast. The lvalue-to-rvalue (4.1  conv.lval), array-to-pointer (4.2  conv.array), and function-to-pointer (4.3  conv.func) conversions are applied to the operand. Such a static_cast is subject to the restriction that it does not cast away constness (5.2.11  expr.const.cast), ...

128. Casting between enum types

[Part of TC1.]

From reflector messages core-8096 through 8100.

According to 7.2  dcl.enum paragraph 9, it is permitted to convert from one enumeration type to another. However, neither 5.2.9  expr.static.cast nor 5.4  expr.cast allows this conversion.

Proposed resolution (10/00): Change the first two sentences of 5.2.9  expr.static.cast paragraph 7 to read

A value of integral or enumeration type can be explicitly converted to an enumeration type. The value is unchanged if the original value is within the range of the enumeration values (7.2  dcl.enum ).

137. static_cast of cv void*

[Part of TC1.]

From reflector message core-8198.

According to 5.2.9  expr.static.cast paragraph 10,

An rvalue of type "pointer to cv void" can be explicitly converted to a pointer to object type.

Proposed resolution (10/00):

Change the first sentence of 5.2.9  expr.static.cast paragraph 10 to

An rvalue of type "pointer to cv1 void" can be converted to an rvalue of type "pointer to cv2 T", where T is an object type and cv2 is the same cv-qualification as, or greater cv-qualification than, cv1.

74. Enumeration value in direct-new-declarator

[Part of TC1.]

From reflector message core-7911.

5.3.4  expr.new paragraph 6 says:

The expression in a direct-new-declarator shall have integral type (3.9.1  basic.fundamental ) with a non-negative value.

Proposed Resolution (10/99): Replace "integral type" by "integral or enumeration type" in 5.3.4  expr.new paragraph 6.

127. Ambiguity in description of matching deallocation function

[Part of TC1.]

If a placement allocation function has default arguments for all its parameters except the first, it can be called using non-placement syntax. In such a case, it is not clear whether the deallocation function to be called if the constructor terminates by throwing an expression is determined on the basis of the syntax of the new-expression (i.e., a non-placement deallocation function) or the declaration of the selected (placement) allocation function. 5.3.4  expr.new paragraph 19 indicates that the deallocation function must match the declaration of the allocation function. However, 15.2  except.ctor says that the distinction is based on whether the new-expression contains a new-placement or not.

Proposed resolution (10/00):

In 15.2  except.ctor paragraph 2, replace

If the object or array was allocated in a new-expression and the new-expression does not contain a new-placement, the deallocation function (3.7.3.2  basic.stc.dynamic.deallocation, 12.5  class.free) is called to free the storage occupied by the object; the deallocation function is chosen as specified in 5.3.4  expr.new. If the object or array was allocated in a new-expression and the new-expression contains a new-placement, the storage occupied by the object is deallocated only if an appropriate placement operator delete is found, as specified in 5.3.4  expr.new.

with

If the object or array was allocated in a new-expression, the matching deallocation function (3.7.3.2  basic.stc.dynamic.deallocation, 5.3.4  expr.new, 12.5  class.free), if any, is called to free the storage occupied by the object.

179. Function pointers and subtraction

[Part of TC1.]

5.7  expr.add paragraph 8 explicitly allows subtraction of two pointers to functions:

If two pointers point to the same object or function... and the two pointers are subtracted...

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

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

Proposed resolution (10/00):

Remove the words or function from paragraph 8.

73. Pointer equality

[Part of TC1.]

From reflector messages core-7890, 7895, 7896, 7904, 8101-8106.

Nathan Myers: In 5.10  expr.eq , we have:

Pointers to objects or functions of the same type (after pointer conversions) can be compared for equality. Two pointers of the same type compare equal if and only if they are both null, both point to the same object or function, or both point one past the end of the same array.

    int i[1];
    int j[1];

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

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

Tom MacDonald: C9X contains the following words for the "==" operator:

Two pointers compare equal if both are null pointers, both are pointers to the same object (including a pointer to an object and a subobject at its beginning) or function, both are pointers to one past the last element of the same array object, or one is a pointer to one past the end of one array object and the other is a pointer to the start of a different array object that happens to immediately follow the first array object in the address space.

    int x[1];
    int y[1]; 
    std::cout << (y == x + 1) << std::endl;

Mike Miller: A similar question could be raised about different objects that (sequentially) share the same storage. Consider the following:

    struct B {
        virtual void f();
    };
    struct D1: B { };
    struct D2: B { };
    void g() {
        B* bp1 = new D1;
        B* bp2 = new (bp1) D2;
        bp1 == bp2; // ???
    }

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

3.9.2  basic.compound refers to 'pointers to void or objects or functions'. In that case, 5.10  expr.eq does not allow you to compare them; it only allows comparing pointers to objects and functions.

Proposed Resolution (10/00):

• In 3.9.2  basic.compound paragraph 3, add the following wording immediately preceding, "The value representation of pointer types is implementation-defined":

  A valid value of an object pointer type represents either the address of a byte in memory (1.7  intro.memory) or a null pointer (4.10  conv.ptr). If an object of type T is located at an address A, a pointer of type cv T* whose value is the address A is said to point to that object, regardless of how the value was obtained. [Note: for instance, the address one past the end of an array (5.7  expr.add) would be considered to point to an unrelated object of the array's element type that might be located at that address.]

• In 5.10  expr.eq paragraph 1, change the sentence beginning, "Two pointers of the same type..." to read:

  Two pointers of the same type compare equal if and only if they are both null, both point to the same function, or both represent the same address (3.9.2  basic.compound).

(See also paper J16/00-0011 = WG21 N1234.)

188. Comma operator and rvalue conversion

[Part of TC1.]

From reflector messages 8396-7.

Given

    char arr[100];
    sizeof(0,arr);

What does the sizeof expression return? According to 5.18  expr.comma paragraph 1, the comma operator yields an lvalue if the second argument is an lvalue. Since 4.2  conv.array paragraph 1 says that the array-to-pointer conversion yields an rvalue, it seems that sizeof should see an array type and give the answer 100. If so, the value of the sizeof expression would be different from that of the corresponding expression in C, but there is nothing in Annex C  diff to indicate that an incompatible change was intended.

Proposed resolution (10/00):

Add the following as paragraph 3 of C.1.3  diff.expr:

5.16, 5.17, 5.18

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

    char arr[100];
    sizeof(0, arr)

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

94. Inconsistencies in the descriptions of constant expressions

[Part of TC1.]

From reflector messages core-7960, 7961, 7962 and 7965.

1. According to 9.4.2  class.static.data paragraph 4, a static const integral or const enumeration data member initialized with an integral constant expression "can appear in integral constant expressions within its scope" [emphasis mine]. This means that the following is not permitted:

       struct S {
           static const int c = 5;
       };
       int a[S::c];    // error: S::c not in scope
   

   Is this restriction intentional? If so, what was the rationale for the restriction?

   Bjarne Stroustrup: I think that once you have said S::, c is in scope so that

       int a[S::c];
   

   is ok.

   Mike Miller: I'd like to think that's what it meant, but I don't believe that's what it said. According to 3.3  basic.scope paragraph 1, the scope of a name is the region "in which that name may be used as an unqualified name." You can, indeed, use a qualified name to refer to a name that is not in scope, but that only goes to reinforce my point that "S::c" is not in scope at the point where the expression containing it is used. I think the phrase "within its scope" is at best misleading and should be removed. (Unless there's a reason I'm missing for restricting the use of static member constants to their scope.)

2. According to 5.19  expr.const paragraph 1, integral constant expressions can "involve...const variables or static data members of integral or enumeration types initialized with constant expressions." However, in 5.19  expr.const paragraph 3, arithmetic constant expressions cannot include them. This seems a rather gratuitous distinction and one likely to bite programmers trained always to use const variables instead of preprocessor definitions. Again, is there a rationale for the difference?

   As far as I can tell from 5.19  expr.const paragraph 2, "arithmetic constant expressions" (as distinct from "integral constant expressions") are used only in static initializers to distinguish between static and dynamic initialization. They include floating point types and exclude non-type template parameters, as well as the const variables and static data members.

3. There is a minor error in 5.19  expr.const paragraph 2. The first sentence says, "Other expressions are considered constant expressions only for the purpose of non-local static object initialization." However, 6.7  stmt.dcl paragraph 4 appears to rely on the same definition dealing with the initialization of local static objects. I think that the words "non-local" should be dropped and a cross reference to 6.7  stmt.dcl added.

4. 5.19  expr.const paragraph 4 says, "An expression that designates the address of a member or base class of a non-POD class object (clause 9) is not an address constant expression (12.7  class.cdtor )."

   I'm guessing that should be "non-static member," like the similar prohibition in 12.7  class.cdtor regarding out-of-lifetime access to members of non-POD class objects.

Proposed resolutions (10/00):

1. Remove the phrase "within its scope" in 9.4.2  class.static.data paragraph 4.

2. Replace 5.19  expr.const paragraph 3 with the following:

   An arithmetic constant expression shall satisfy the requirements for an integral constant expression, except that

   • floating literals need not be cast to integral or enumeration type, and
   • conversions to floating point types are permitted.

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

4. Change the referenced sentence in 5.19  expr.const paragraph 4 to "An expression that designates the address of a subobject of a non-POD class object is not an address constant expression."

227. How many scopes in an if statement?

[Part of TC1.]

The wording of 6.4  stmt.select paragraph 1 is misleading. Instead of

The substatement in a selection-statement (both substatements, in the else form of the if statement) implicitly defines a local scope (3.3  basic.scope).

it should say

... each substatement, in the else form...

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

Proposed resolution (10/00): As suggested.

69. Storage class specifiers on template declarations

[Part of TC1.]

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

There is an explicit prohibition of storage-class-specifiers on explicit specializations.

For example, if we have

    template<class T> static int foo(T) { return sizeof(T); }

So what does the specifier mean? Lacking a direct statement in the standard, I see the following posibilities, in my preference order.

1. storage-class-specifiers have no meaning on template declarations, their use being subsumed by "export" (for the template name) and the unnamed namespace (for instantiations)
2. storage-class-specifiers have no effect on the template name, but do affect the linkage of the instantiations, though this now applies linkage to template-ids, which I can find no support for. I suspect this is what was intended, though I don't remember

From John Spicer

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.

Mike: This makes sense, but I couldn't find much support in the document. Sounds like yet another interpretation to add to the list.

John: Agreed.

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

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

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

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

Proposed resolution (10/00):

A template name may have linkage (3.5  basic.link).

A template name has linkage (3.5  basic.link). A non-member function template can have internal linkage; any other template name shall have external linkage. Entities generated from a template with internal linkage are distinct from all entities generated in other translation units.

56. Redeclaring typedefs within classes

[Part of TC1.]

Can a typedef redeclaration be done within a class?

    class X { 
        typedef int I; 
        typedef int I; 
    };

Proposed Resolution (10/99): Change 7.1.3  dcl.typedef paragraph 2 from "In a given scope" to "In a given non-class scope."

76. Are const volatile variables considered "constant expressions"?

[Part of TC1.]

The following code does not compile with the EDG compiler:

    volatile const int a = 5;
    int b[a];

A variable of const-qualified integral or enumeration type initialized by an integral constant expression can be used in integral constant expressions.

Proposed Resolution (10/99): Change the referenced text in paragraph 2 of 7.1.5.1  dcl.type.cv to read:

A variable of non-volatile const-qualified ...

68. Grammar does not allow "friend class A<int>;"

[Part of TC1.]

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

The syntax for elaborated type specifier is

elaborated-type-specifier:
class-key ::_opt nested-name-specifier_opt identifier
enum ::_opt nested-name-specifier_opt identifier
typename ::_opt  nested-name-specifier identifier
typename ::_opt  nested-name-specifier template_opt template-id

If an elaborated-type-specifier is the sole constituent of a declaration, the declaration is ill-formed unless it is an explicit specialization (14.7.3  temp.expl.spec ), an explicit instantiation (14.7.2  temp.explicit ) or it has one of the following forms:


class-key identifier ;
friend class-key identifier ;
friend class-key :: identifier ;
friend class-key nested-name-specifier identifier ;

    class foo<int> // foo is a template

An elaborated-type-specifier shall be used in a friend declaration for a class.*

[Footnote: The class-key of the elaborated-type-specifier is required. —end footnote]

[Example:

    template<class T> class task;
    template<class T> task<T>* preempt(task<T>*);

    template<class T> class task {
        // ...
        friend void next_time();
        friend void process(task<T>*);
        friend task<T>* preempt<T>(task<T>*);
        template<class C> friend int func(C);

        friend class task<int>;
        template<class P> friend class frd;
        // ...
    };

An additional problem was reported via comp.std.c++: the grammar does not allow the following example:

    namespace A{
      class B{};
    };

    namespace B{
      class A{};
      class C{
	friend class ::A::B;
      };
    };

Proposed resolution (10/00):

Change the grammar in 7.1.5.3  dcl.type.elab to read

elaborated-type-specifier:
class-key ::_opt nested-name-specifier_opt identifier
class-key ::_opt nested-name-specifier_opt template_opt template-id
enum ::_opt nested-name-specifier_opt identifier
typename ::_opt nested-name-specifier identifier
typename ::_opt nested-name-specifier template_opt template-id

class-key identifier ;
friend class-key ::_opt identifier ;
friend class-key ::_opt template-id ;
friend class-key ::_opt nested-name-specifier identifier ;
friend class-key ::_opt nested-name-specifier template_opt template-id ;

171. Global namespace scope

[Part of TC1.]

7.3  basic.namespace paragraph 2 says:

A name declared outside all named namespaces, blocks (6.3  stmt.block ) and classes (clause 9  class ) has global namespace scope (3.3.5  basic.scope.namespace ).

A name declared outside all named or unnamed namespaces (7.3  basic.namespace ), blocks (6.3  stmt.block ), function declarations (8.3.5  dcl.fct ), function definitions (8.4  dcl.fct.def ) and classes (clause 9  class ) has global namespace scope (also called global scope).

Proposed resolution (10/00):

1. Replace the first sentence of 3.3.5  basic.scope.namespace paragraph 3 with

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

2. In the last sentence of the same paragraph, change "Names declared in the global namespace scope" to "Names with global namespace scope."

3. Replace 7.3  basic.namespace paragraph 2 with

   The outermost declarative region of a translation unit is a namespace; see 3.3.5  basic.scope.namespace.

166. Friend declarations of template-ids

[Part of TC1.]

From reflector messages 8321-3.

John Spicer: I believe the standard is not clear with respect to this example:

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

A note in 3.3.1  basic.scope.pdecl paragraph 6 says

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

Mike Miller: 7.3.1.2  namespace.memdef paragraph 3 says,

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

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

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

Proposed resolution (10/00):

In 7.3.1.2  namespace.memdef paragraph 3, change

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

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

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

(See also issues 95, 136, 138, 139, 143, and 165.)

101. Redeclaration of extern "C" names via using-declarations

[Part of TC1.]

From reflector message core-7994:

Consider the following:

    extern "C" void f();
    namespace N {
        extern "C" void f();
    }
    using N::f;

If a function declaration in namespace scope or block scope has the same name and the same parameter types as a function introduced by a using-declaration, the program is ill-formed.

This also breaks the relatively strong parallel between extern "C" functions and typedefs established in our discussion of Core issue 14 in Santa Cruz. There the question was for using-directives:

    typedef unsigned int size_t;
    extern "C" int f();
    namespace N {
        typedef unsigned int size_t;
        extern "C" int f();
    }
    using namespace N;
    int i = f();        // ambiguous "f"?
    size_t x;           // ambiguous "size_t"?

In the context of using-declarations, there is no explicit extension of the restrictions in 3.3  basic.scope paragraph 4 except as noted above for function declarations; thus the parallel scenario for a typedef is not ill-formed:

    typedef unsigned int size_t;
    namespace N {
        typedef unsigned int size_t;
    };
    using N::size_t;        // okay, both declarations
                            // refer to the same entity

If a function declaration in namespace scope or block scope has the same name and the same parameter types as a function introduced by a using-declaration, and the declarations do not declare the same function, the program is ill-formed.

Proposed Resolution (10/99): As suggested.

103. Is it extended-namespace-definition or extension-namespace-definition ?

[Part of TC1.]

From reflector messages core-8001 and core-8003.

Section 7.3.4  namespace.udir paragraph 3 uses the term extended-namespace-definition three times:

If a namespace is extended by an extended-namespace-definition after a using-directive for that namespace is given, the additional members of the extended namespace and the members of namespaces nominated by using-directives in the extended-namespace-definition can be used after the extended-namespace-definition.

Mike Miller: True enough; in Section 7.3.1  namespace.def [the grammar] it's called an extension-namespace-definition.

Proposed Resolution (10/99): Systematically replace "extended-namespace-definition" by "extension-namespace-definition".

4. Does extern "C" affect the linkage of function names with internal linkage?

[Moved to DR at 4/01 meeting.]

(Previously numbered 864.)

7.5  dcl.link paragraph 6 says the following:

At most one of a set of overloaded functions with a particular name can have C linkage.

        extern "C" {
            static void f(int) {}
            static void f(float) {}
        };

Suggested resolution: The extern "C" linkage specification applies only to the type of functions with internal linkage, and therefore some of the rules that have to do with name overloading don't apply.

Proposed Resolution:

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

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

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

For a linkage-specification using braces, i.e.

extern string-literal { declaration-seq_opt }

For a linkage-specification without braces, i.e.

extern string-literal declaration

the linkage of the names declared in the top-level declarators of declaration is specified by string-literal; if this conflicts with the linkage of any matching previous declarations, the program is ill-formed. The language linkage of the type of any top-level function declarator is specified by string-literal; if this conflicts with the language linkage of the type of any matching previous function declarations, the program is ill-formed. The effect of the linkage-specification on other (non top-level) names declared in declaration is the same as that of the brace-enclosed form.

[The following discussion is from messages 8722 and 8724.]

Bill Gibbons: In particular, these should be well-formed:

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

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

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

but these should not:

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

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

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

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

In the current standard, the statement in 7.5  dcl.link paragraph 4 that

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

applies to both forms. I would thus expect that in

    extern "C" void f(void(*)());
    extern "C++" {
        void f(void(*)());
    }
    extern "C++" f(void(*)());

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

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

    extern "C" void f(void (*fp1)());

    extern "C++" {
        void f(void(*fp2)());
    }

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

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

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

Bill Gibbons: It is possible to construct pathological cases where this fails, e.g.

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

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

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

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

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

In this case the two function declarations refer to different functions.

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

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

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

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

Notes from 04/00 meeting:

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

Notes from 10/00 meeting:

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

Proposed resolution (04/01):

1. Change the first sentence of 7.5  dcl.link paragraph 1 from

   All function types, function names, and variable names have a language linkage.

   to

   All function types, function names with external linkage, and variable names with external linkage have a language linkage.

2. Change the following sentence of 7.5  dcl.link paragraph 4:

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

   to

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

3. Add at the end of the final example on 7.5  dcl.link paragraph 4:

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

4. Change 7.5  dcl.link paragraph 7 from

   Except for functions with internal linkage, a function first declared in a linkage-specification behaves as a function with external linkage. [Example:

       extern "C" double f();
       static double f();     // error
   

   is ill-formed (7.1.1  dcl.stc). ] The form of linkage-specification that contains a braced-enclosed declaration-seq does not affect whether the contained declarations are definitions or not (3.1  basic.def); the form of linkage-specification directly containing a single declaration is treated as an extern specifier (7.1.1  dcl.stc) for the purpose of determining whether the contained declaration is a definition. [Example:

       extern "C" int i;      // declaration
       extern "C" {
   	  int i;           // definition
       }
   

   —end example] A linkage-specification directly containing a single declaration shall not specify a storage class. [Example:

       extern "C" static void f(); // error
   

   —end example]

   to

   A declaration directly contained in a linkage-specification is treated as if it contains the extern specifier (7.1.1