Document number: | J16/00-0014 = WG21 N1237 |
Date: | 21 March, 2000 |
Project: | Programming Language C++ |
Reference: | ISO/IEC IS 14882:1998(E) |
Reply to: | William M. Miller |
wmm@fastdial.net |
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:
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.
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 ...to:
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 ...Change the text in 3.4.1 basic.lookup.unqual ] paragraph 8 from:
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 ...to:
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 ...
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 templates is defined and the classes and namespaces associated with its (non-dependent) parameter types and return type.
Section 3.4.2 basic.lookup.koenig includes the following:
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 }Certainly the enclosing class should also be an associated class for nested class types, shouldn't it?
Proposed Resolution (10/99): Change the two referenced bullets to read:
The text of 3.8 basic.life paragraph 2 currently reads,
The phrase "an object of type" is obviously incorrect. I believe it should read "an object of POD type." Does anyone disgree?
Proposed Resolution (10/99): As suggested.
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]Paragraph 3 doesn't repeat the restriction of paragraph 2. Should it be assumed? Otherwise only complete POD types are copyable to an array of char and back, but scribbling over subobjects is OK. (Or perhaps a "distinct T object" is a complete object...)*[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, ...to:
For any object (other than a base class subobject) of POD type T, ...Change the text in 3.9 basic.types paragraph 3 from:
For any POD type T, if two pointers to T point to distinct T objects obj1 and obj2,to:
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, ...
A nested-name-specifier that names a class, optionally followed by the keyword template (14.8.1 temp.arg.explicit ), ...The use of the template keyword in this context is discussed in 14.2 temp.names , not 14.8.1 temp.arg.explicit .
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.I assume the intent was to also allow enumeral types, as we do in 5.2.1 expr.sub ?
Proposed Resolution (10/99): Replace "integral type" by "integral or enumeration type" in 5.3.4 expr.new paragraph 6.
Can a typedef redeclaration be done within a class?
class X { typedef int I; typedef int I; };See also 9.2 class.mem , Core issue 36 , and Core issue 85 .
Proposed Resolution (10/99): Change 7.1.3 dcl.typedef paragraph 2 from "In a given scope" to "In a given non-class scope."
The following code does not compile with the EDG compiler:
volatile const int a = 5; int b[a];The standard, 7.1.5.1 dcl.type.cv , says:
A variable of const-qualified integral or enumeration type initialized by an integral constant expression can be used in integral constant expressions.This doesn't say it can't be const volatile-qualified, although I think that was what was intended.
Proposed Resolution (10/99): Change 7.1.5.1 dcl.type.cv to read:
Consider the following:
extern "C" void f(); namespace N { extern "C" void f(); } using N::f;According to 7.3.3 namespace.udecl paragraph 11, the using-declaration is an error:
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.Based on the context (7.3.3 namespace.udecl paragraph 10 simply reiterates the requirements of 3.3 basic.scope ), one might wonder if the failure to exempt extern "C" functions was intentional or an oversight. After all, there is only one function f() involved, because it's extern "C", so ambiguity is not a reason to prohibit the using-declaration.
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"?We decided for both that there was no ambiguity because each pair of declarations declares the same entity. (According to 3 basic paragraph 3, a typedef name is not an entity, but a type is; thus the declarations of size_t declare the same entity "unsigned int".)
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 entityI think 7.3.3 namespace.udecl paragraph 11 ought to be rewritten as:
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.
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.I think the intent is clear, but unfortunately I cannot find any other mention (or definition) of this term.
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".
(From J16/99-0005 = WG21 N1182, "Proposed Resolutions for Core Language Issues 6, 14, 20, 40, and 89")
There are two sub-issues. The first concerns the statement in 8.3 dcl.meaning paragraph 1,
The id-expression of a declarator-id shall be a simple identifier except for the declaration of some special functions (12.3 class.conv , 12.4 class.dtor , 13.5 over.oper ) and for the declaration of template specializations or partial specializations (14.7 temp.spec ).The second sub-issue is regarding another statement in the same paragraph:
A declarator-id shall not be qualified except for the definition of a member function (9.3 class.mfct ) or static data member (9.4 class.static ) or nested class (9.7 class.nest ) outside of its class, the definition or explicit instantiation of a function, variable or class member of a namespace outside of its namespace, or...Analysis
The problem in the first sub-issue is that the wrong syntactic non-terminal is mentioned. The relevant portions of the grammar are:
If an unqualified-id is used as the id-expression of a declarator-id, it shall be a simple identifier except...However, it does not appear that this restriction has any meaning; all of the possible cases of unqualified-ids are represented in the list of exceptions! Rather than recasting the sentence into a correct but useless form, it would be better to remove it altogether.
The second sub-issue deals with the conditions under which a qualified-id can be used in a declarator, including "the definition of a...nested class" and "the definition or explicit instantiation of a...class member of a namespace." However, the name in a class definition is not part of a declarator; these constructs do not belong in a list of declarator contexts.
Proposed Resolution for sub-issue 1 (04/99):
The suggested resolution for the first sub-issue overlooked the fact that the existing wording has the additional effect of prohibiting the use of the non-identifier syntax for declaring other than the listed entities. Thus the proposed wording for the first sub-issue is:
Change 8.3 dcl.meaning paragraph 1 from:
The id-expression of a declarator-id shall be a simple identifier except...to:
An unqualified-id occurring in a declarator-id shall be a simple identifier except...
Proposed Resolution for sub-issue 2 (10/99):
Change 8.3 dcl.meaning paragraph 1 from:
A declarator-id shall not be qualified except for the definition of a member function (9.3 class.mfct ) or static data member (9.4 class.static ) or nested class (9.7 class.nest ) outside of its class, the definition or explicit instantiation of a function, variable or class member of a namespace outside of its namespace, or...to
A declarator-id shall not be qualified except for the definition of a member function (9.3 class.mfct ) or static data member (9.4 class.static ) outside of its class, the definition or explicit instantiation of a function or variable member of a namespace outside of its namespace, or...
Proposed Resolution (04/99): Change the text in the example of section 8.3.6 dcl.fct.default paragraph 5 from:
... g will be called with the value f(1).to:
... g will be called with the value f(2).
Given:
struct S1 { int x; }; struct S2 { int x; double y; }; struct S3 { int x; double y; string s; };Once upon a time, we went through a fairly protracted discussion to ensure that S1().x would be guaranteed to be 0. Note that if we declare
void f() { S1 s1; // ... }there is no guarantee of the value of s1.x, and that is intentional. But S1().x is different, because S1() is an rvalue, and unless all of its members are defined, the effect of copying it is undefined.
Similarly, S2().x and S2().y are also defined to be equal to zero, and here it really matters for many implementations, because if S2().y is just a bunch of random bits, it is entirely possible that trying to copy S2().y will yield a floating-point trap.
However, rather to my surprise, the standard does not define the value of S3().x or S3().y, because S3 is not a POD. It does define S3().s (by running the string constructor), but once a structure is no longer a POD, the values of uninitialized members are no longer guaranteed in expressions of the form T().
In my opinion, this definition is a mistake, and the committee's intention was to zero-initialize all members that do not have an explicitly defined constructor, whether or not the class is a POD.
See also paper J16/99-0014 = WG21 N1191.
Proposed Resolution (04/99): Add the following text to the end of section 8.5 dcl.init paragraph 5:
To value-initialize an object of type T means:
- if T is a class type (9 class ) with a user-declared constructor (12.1 class.ctor ), then the default constructor for T is called (and the initialization is ill-formed if T has no accessible default constructor);
- if T is a non-union class type without a user-declared constructor, then every non-static data member and base-class component of T is value-initialized;
- if T is an array type, then each element is value-initialized;
- otherwise, the storage for the object is zero-initialized.
Change "default-initialization" to "value-initialization" in 5.2.3 expr.type.conv paragraph 2 and in 8.5.1 dcl.init.aggr paragraph 7.
8.5.1 dcl.init.aggr paragraph 2 says,
When an aggregate is initialized the initializer can be an initializer-clause consisting of a brace-enclosed, comma-separated list of initializers for the members of the aggregate.Neither of these uses of the syntactic nonterminal initializer corresponds to the grammar:
Proposed resolution (10/99): replace the quoted words with:
When an aggregate is initialized the initializer can contain an initializer-clause consisting of a brace-enclosed, comma-separated list of initializer-clauses for the members of the aggregate.
The standard says, in 9.2 class.mem paragraph 4:
A member-declarator can contain a constant-initializer only if it declares a static member (9.4 class.static ) of integral or enumeration type, see 9.4.2 class.static.data .But later, in the section on static class data member initialization, 9.4.2 class.static.data paragraph 4, it says:
If a static data member is of const integral or const enumeration type, its declaration in the class definition can specify a constant-initializer which shall be an integral constant expression (5.19 expr.const ). In that case, the member can appear in integral constant expressions within its scope.The first paragraph should be modified to make it clear that it is not possible to initialize a static data member in-line with a constant-initializer if that data member is of integral (or enumeration) type, and yet not const.
Proposed Resolution (10/99): Change the sentence in 9.2 class.mem paragraph 4 to read:
A member-declarator can contain a constant-initializer only if it declares a static member (9.4 class.static ) of const integral or const enumeration type, see 9.4.2 class.static.data .
Paragraph 2 says that "the object-expression is always evaluated" when the class member syntax is used to refer to a static member. This presumably should say that the object expression is evaluated if the member access is performed, i.e., not if the overall expression is the operand of sizeof or the unevaluated branch of ?:, ||, or &&.
Proposed Resolution (10/99): Replace "is always evaluated" by "is evaluated" in 9.4 class.static paragraph 2.
Also see section: 3.2 basic.def.odr .
Originally, all static data members still had to be defined outside the class whether they were used or not.
But that restriction was supposed to be lifted so that static data members need not be defined outside the class unless they are used in a manner which requires their definition, in the same manner as namespace-scope variables. In particular, if an integral/enum const static data member is initialized within the class, and its address is never taken, we agreed that no namespace-scope definition was required.
For example:
struct A { static const int size = 10; int array[size]; }; int main() { A a; return 0; }However, 9.4.2 class.static.data paragraph 4 says:
The member shall still be defined in a namespace scope if it is used in the program and the namespace scope definition shall not contain an initializer.A narrow interpreration of "used" in this rule would make the example ill-formed because there is no namespace-scope definition of "size". A better wording for this rule would be:
The member shall still be defined in a namespace scope if it is used in the program in the manner described in 3.2 basic.def.odr . The namespace scope definition shall not contain an initializer.Also, the wording in 3.2 basic.def.odr paragraph 2:
An expression is potentially evaluated unless either it is the operand of the sizeof operator (5.3.3 expr.sizeof ), or it is the operand of the typeid operator and does not designate an lvalue of polymorphic class type (5.2.8 expr.typeid ).is incomplete because it does not mention the use of a compile-time constant as an array bound or template argument. It should say something like:
An expression is potentially evaluated unless it is the operand of the sizeof operator (5.3.3 expr.sizeof ), the operand of the typeid operator, an integral constant-expression used as an array bound or an integral constant-expression used as a template-argument for a non-reference template-parameter; and the expression does not designate an lvalue of polymorphic class type (5.2.8 expr.typeid ).
Proposed Resolution (04/99): Change the first sentence of 3.2 basic.def.odr paragraph 2 from:
An expression is potentially evaluated unless either it is the operand of the sizeof operator (5.3.3 expr.sizeof ), or it is the operand of the typeid operator and does not designate an lvalue of polymorphic class type (5.2.8 expr.typeid ).to:
An expression is potentially evaluated unless it appears where an integral constant expression is required (see 5.19 expr.const ), is the operand of the sizeof operator (5.3.3 expr.sizeof ), or is the operand of the typeid operator and the expression does not designate an lvalue of polymorphic class type (5.2.8 expr.typeid ).
11.5 class.protected paragraph 1 begins:
When a friend or a member function of a derived class references a protected nonstatic member of a base class, an access check applies in addition to those described earlier in clause 11 class.access .
This was intended to refer to nonstatic member functions and nonstatic data members. However, a protected nested type declared in a base class is, by some definition of the word, a "nonstatic" member, and therefore subject to this additional access check.
Proposed resolution (10/99): change "protected nonstatic member" in the above to "protected nonstatic member function or protected nonstatic data member" to make the intent clear.
Issue 1
12.8 class.copy (From J16/99-0005 = WG21 N1182, "Proposed Resolutions for Core Language Issues 6, 14, 20, 40, and 89")
There are three related sub-issues in this issue, all dealing with the elision of copy constructors as described in 12.8 class.copy paragraph 15:
After discussion in Santa Cruz, the core group decided that sub-issue #1 required no change; the necessity of an accessible and unambiguous copy constructor is made clear in 12.2 class.temporary paragraph 1 and need not be repeated in this text. The remaining two sub-issues appear to be valid criticisms and should be addressed.
Proposed Resolution (10/99): The paragraph in question should be rewritten as follows. In addition, references to this section should be added to the index under "temporary, elimination of," "elimination of temporary," and "copy, constructor elision."
class Thing { public: Thing(); ~Thing(); Thing(const Thing&); }; Thing f() { Thing t; return t; } Thing t2 = f();Here the criteria for elision can be combined to eliminate two calls to the copy constructor of class Thing: the copying of the local automatic object t into the temporary object for the return value of function f() and the copying of that temporary object into object t2. Effectively, the construction of the local object t can be viewed as directly initializing the global object t2, and that object's destruction will occur at program exit. —end example]
Sections 13.3.1.4 over.match.copy and 13.3.1.5 over.match.conv should be clarified regarding the treatment of conversion functions which return reference types.
Proposed resolution (10/99):
In 13.3.1.4 over.match.copy paragraph 1, change
Conversion functions that return "reference to T" return lvalues of type T and are therefore considered to yield T for this process of selecting candidate functions.to
Conversion functions that return "reference to X" return lvalues of type X and are therefore considered to yield X for this process of selecting candidate functions.In 13.3.1.5 over.match.conv paragraph 1, change
Conversion functions that return "reference to T" return lvalues of type T and are therefore considered to yield T for this process of selecting candidate functions.to
Conversion functions that return "reference to cv2 X" return lvalues of type "cv2 X" and are therefore considered to yield X for this process of selecting candidate functions.
In 13.3.3 over.match.best paragraph 1, bullet 4 of the second set of bullets, there is a cross-reference to 8.5 dcl.init and 13.3.1.5 over.match.conv . I believe it should also reference 13.3.1.6 over.match.ref . I think the phrase "initialization by user-defined conversion" was intended to refer to all initializations using user-defined conversions, and not just the case in 13.3.1.5 over.match.conv . Referring to only 13.3.1.5 over.match.conv suggests a narrower meaning of the phrase.
13.3.1.4 over.match.copy , although it does deal with initialization by user-defined conversion, does not need to be referenced because it deals with class —> class cases, and therefore there are no standard conversions involved that could be compared.
Section 14 temp paragraph 8 says:
A non-exported template that is neither explicitly specialized nor explicitly instantiated must be defined in every translation unit in which it is implicitly instantiated (14.7.1 temp.inst ) or explicitly instantiated (14.7.2 temp.explicit ); no diagnostic is required.Shouldn't the first underlined phrase be omitted to avoid conflict with the second underlined phrase?
From John Spicer:
The first "explicitly instantiated" is intended to mean "explicitly instantiated in some other translation unit".
Proposed Resolution (04/99): Change the text in 14 temp paragraph 8 from:
A non-exported template that is neither explicitly specialized nor explicitly instantiated must be defined in every translation unit in which it is implicitly instantiated (14.7.1 temp.inst ) or explicitly instantiated (14.7.2 temp.explicit ); no diagnostic is required.to:
A non-exported template must be defined in every translation unit in which it is implicitly instantiated (14.7.1 temp.inst ), unless the corresponding specialization is explicitly instantiated (14.7.2 temp.explicit ) in some translation unit; no diagnostic is required. [Note: See also 14.7.2 temp.explicit ]
The example in 14.1 temp.param paragraph 8 is:
template<int* a> struct R { /*...*/ }; int* p; R<p> w;There was a French comment was that this is an error, and there was general agreement with that.
I've been looking for the verbiage that specifies that this is an error and haven't found it. In particular, nothing in 14.1 temp.param ("Template parameters") nor 14.3.2 temp.arg.nontype ("Template non-type arguments") appears to rule out this case. (14.3.2 temp.arg.nontype paragraph 1 allows an argument to be "the name of an object or function with external linkage," with no limitation on the kinds of parameters such a name can match; "p" is, in fact, such a name.)
Should the resolution of the French comment include beefing up one or both of these sections to cover the applicable rules explicitly?
Proposed Resolution (04/99): Change the example in 14.1 temp.param paragraph 8 from:
template<int *a> struct R { /* ... */ }; template<int b[5]> struct S { /* ... */ }; int *p; R<p> w; // OK S<p> x; // OK due to parameter adjustment int v[5]; R<v> y; // OK due to implicit argument conversion S<v> z; // OK due to both adjustment and conversionto:
template<int *a> struct R { /* ... */ }; template<int b[5]> struct S { /* ... */ }; int p; R<&p> w; // OK S<&p> x; // OK due to parameter adjustment int v[5]; R<v> y; // OK due to implicit argument conversion S<v> z; // OK due to both adjustment and conversionFurthermore, in 14.3.2 temp.arg.nontype paragraph 1:
I have a request for clarification regarding a issue similar to John Wiegley's, but wrt. the ::template syntax. More precisely, where is
X::template Yallowed? (It is required for dependent X where Y is a template-id, I believe, but it doesn't seem to be disallowed elsewhere.)
The question also holds for '.template' and '->template'.
Proposed Resolution (04/99): Append to 14.2 temp.names paragraph 5:
Furthermore, names of member templates shall not be prefixed by the keyword template if the postfix-expression or qualified-id does not appear in the scope of a template. [Note: just as is the case with the typename prefix, the template prefix is allowed in cases where it is not strictly necessary; i.e., when the expression on the left of the -> or ., or the nested-name-specifier is not dependent on a template-parameter. ]
The explanation in 14.3.2 temp.arg.nontype paragraph 2 of why a string literal cannot be used as a template argument leaves something to be desired:
...because a string literal is an object with internal linkage.I can't find anything that says that a string literal has internal linkage. In fact, I'd be pretty surprised if I did, since linkage is defined (in 3.5 basic.link ) strictly in terms of names, and a string literal doesn't have a name. Actually, I think that it's the namelessness of a string literal that prevents it from being a template argument; only the third and fourth bullets of 14.3.2 temp.arg.nontype paragraph 1 could conceivably apply, and both of those require that the entity have a name (i.e., that they be given as an id-expression).
Proposed Resolution (10/99): In 14.3.2 temp.arg.nontype paragraph 2, change
[Note: a string literal (2.13.4 lex.string ) is not an acceptable template-argument because a string literal is an object with internal linkage.to
[Note: a string literal (2.13.4 lex.string ) does not satisfy the requirements of any of these categories and thus is not an acceptable template-argument.
14.5.5.1 temp.over.link , paragraphs 5 and 6, describes equivalence and functional equivalence for expressions involving template parameters. As a note in paragraph 5 points out, such expressions may involve type parameters as well as non-type parameters.
Paragraph 7, however, describes the equivalence of function templates only with respect to non-type template parameters. It appears to be unspecified how to determine the equivalence of template functions whose types involve expressions that use template type parameters.
template <int I> struct S { }; // The following two declarations are equivalent: template <int I> void f(S<I>); template <int J> void f(S<J>); // The IS doesn't say whether these are equivalent: template <class T> void f(S<sizeof(T)>); template <class T> void f(S<sizeof(T)>);
Proposed resolution (10/99): Remove the three uses of the words "non-type" in 14.5.5.1 temp.over.link paragraph 7.
In 14.6 temp.res , references to the nonexistent syntactic non-terminal qualified-name occur twice in paragraph 3, twice in paragraph 4, and once in paragraph 5. There is also a reference in 14.1 temp.param paragraph 2.
Proposed resolution (10/99): Change the reference in all these cases to qualified-id.
14.1 temp.param paragraph 13 says:
The scope of a template-parameter extends from its point of declaration until the end of its template. In particular, a template-parameter can be used in the declaration of subsequent template-parameters and their default arguments.Is the following well-formed?
template<class U = U> class X { ... };
Proposed Resolution (04/99): Change 14.1 temp.param paragraph 14 from:
A template-parameter cannot be used in preceding template-parameters or their default arguments.to:
A template-parameter cannot be used in preceding template-parameters, in their default arguments, or in its own default argument.
Problem Description: At least four of the examples in 14.7.3 temp.expl.spec have errors.
Proposed Resolution (10/99):
1. Change the example in paragraph 8 from:
[Example:to:// file #1 #include <vector> // Primary class template vector export template<class T> void f(t) { vector<T> vec; // should match the specialization /* ... */ } // file #2 #include <vector> class B { }; // Explicit specialization of vector for vector<B> template<class T> class vector<B> { /* ... */ } template<class T> void f(T); void g(B b) { f(b); // ill formed: // f<B> should refer to vector<B>, but the // specialization was not declared with the // definition of f in file #1 }—end example]
[Example:// file #1 #include <vector> // Primary class template vector export template<class T> void f(T) { std::vector<T> vec; // should match the specialization /* ... */ }; // file #2 #include <vector> class B { }; // Explicit specialization of vector for vector<B> namespace std { template<> class vector<B> { /* ... */ }; } template<class T> void f(T); void g(B b) { f(b); // ill formed: // f<B> should refer to vector<B>, but the // specialization was not declared with the // definition of f in file #1 }—end example]
2. The example in paragraph 16 as it appears in the IS:
[Example:The word 'partial' in the third comment in the example should be removed because this example does not illustrate partial specialization. Also, the two specializations of template<> template<> void A<int>::g(int, char); violate 14.7 temp.spec , paragraph 5, which reads:template<class T> struct A { void f(T); template<class X> void g(T, X); void h(T) { } }; // specialization template<> void A<int>::f(int); // out of class member template definition template<class T> template<class X> void A<T>::g(T,X) { } // member template partial specialization template<> template<class X> void A<int>::g(int, X); // member template specialization template<> template<> void A<int>::g(int, char); // X deduced as char template<> template<> void A<int>::g<char>(int, char); // X specified as char // member specialization even if defined in class definition template<> void A<int>::h(int) { }—end example]
No program shall explicitly instantiate any template more than once, both explicitly instantiate and explicitly specialize a template, or specialize a template more than once for a given set of template-arguments. An implementation is not required to diagnose a violation of this rule.Proposed resolution (10/99):
[Example:template<class T> struct A { void f(T); template<class X1> void g1(T, X1); template<class X2> void g2(T, X2); void h(T) { } }; // specialization template<> void A<int>::f(int); // out of class member template definition template<class T> template<class X1> void A<T>::g1(T,X1) { } // member template specialization template<> template<class X1> void A<int>::g1(int, X1); // member template specialization template<> template<> void A<int>::g1(int, char); // X1 deduced as char template<> template<> void A<int>::g2<char>(int, char); // X2 specified as char // member specialization even if defined in class definition template<> void A<int>::h(int) { }—end example]
3. Remove the spurious semicolon (or the curly brackets) from the end of the last line in the example in paragraph 17. This is the example as it appears in the IS:
[Example:Proposed resolution (10/99):template<class T1> class A { template<class T2> class B { void mf(); }; }; template<> template<> A<int>::B<double> { }; template<> template<> void A<char>::B<char>::mf() {};—end example]
[Example:template<class T1> class A { template<class T2> class B { void mf(); }; }; template<> template<> A<int>::B<double>; template<> template<> void A<char>::B<char>::mf();—end example]
4. Remove spurious semicolons (or curly brackets) from the specializations of mf1 and mf2 in the example in paragraph 18. This is the text of the example as it appears in the IS:
[Example:Proposed resolution (10/99):template<class T1> class A { template<class T2> class B { template<class T3> void mf1(T3); void mf2(); }; }; template<> template<class X> class A<int>::B { }; template<> template<> template<class T> void A<int>::B<double>::mf1(T t) { }; template<class Y> template<> void A<Y>::B<double>::mf2() { }; // ill-formed; B<double> is specialized but // its enclosing class template A is not—end example]
[Example:template<class T1> class A { template<class T2> class B { template<class T3> void mf1(T3); void mf2(); }; }; template<> template<class X> class A<int>::B { }; template<> template<> template<class T> void A<int>::B<double>::mf1(T t) { } template<class Y> template<> void A<Y>::B<double>::mf2() { } // ill-formed; B<double> is specialized but // its enclosing class template A is not—end example]
15.4 except.spec paragraph 3 should say what happens when two pointers to members with different exception specifications are assigned to each other, initialized with one another, etc.
Proposed Resolution (04/99): Change the text in 15.4 except.spec paragraph 3 from:
Similarly, any function or pointer to function assigned to, or initializing, a pointer to function shall only allow exceptions that are allowed by the pointer or function being assigned to or initialized.to:
A similar restriction applies to assignment to and initialization of pointers to functions, pointers to member functions, and references to functions: the target entity shall allow at least the exceptions allowed by the source value in the assignment or initialization.
The Lao character 0e0d should be 0e8d. 0e0d is both out of order and already used in the Thai characters.
Proposed resolution (10/99): As suggested.