| Document number: | J16/03-0015 = WG21 N1433 |
| Date: | 3 March, 2003 |
| Project: | Programming Language C++ |
| Reference: | ISO/IEC IS 14882:1998(E) |
| Reply to: | J. Stephen Adamczyk |
| jsa@edg.com |
This document contains the C++ core language issues on which the Committee (J16 + WG21) has not yet acted, that is, issues issues with status "Ready," "Review," "Drafting," and "Open."
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:
The purpose of these documents is to record the disposition of issues which have come before the Core Language Working Group of the ANSI (J16) and ISO (WG21) C++ Standard Committee.
Issues represent potential defects in the ISO/IEC IS 14882:1998(E) document; they are not necessarily formal ISO Defect Reports (DRs). While some issues will eventually be elevated to DR status, others will be disposed of in other ways. (See Issue Status below.)
The most current public version of this document can be found at http://www.dkuug.dk/jtc1/sc22/wg21. Requests for further information about these documents should include the document number, reference ISO/IEC 14882:1998(E), and be submitted to the Information Technology Information Council (ITI), 1250 Eye Street NW, Washington, DC 20005, USA.
Information regarding how to obtain a copy of the C++ Standard, join the Standard Committee, or submit an issue can be found in the C++ FAQ at http://www.research.att.com/~austern/csc/faq.html . Public discussion of the C++ Standard and related issues occurs on newsgroup comp.std.c++.
Issues progress through various statuses as the Core Language Working Group and, ultimately, the full J16 and WG21 committees deliberate and act. For ease of reference, issues are grouped in these documents by their status. Issues have one of the following statuses:
Open: The issue is new or the working group has not yet formed an opinion on the issue. If a Suggested Resolution is given, it reflects the opinion of the issue's submitter, not necessarily that of the working group or the Committee as a whole.
Drafting: Informal consensus has been reached in the working group and is described in rough terms in a Tentative Resolution, although precise wording for the change is not yet available.
Review: Exact wording of a Proposed Resolution is now available for an issue on which the working group previously reached informal consensus.
Ready: The working group has reached consensus that the issue is a defect in the Standard, the Proposed Resolution is correct, and the issue is ready to forward to the full Committee for ratification as a proposed defect report.
DR: The full J16 Committee has approved the item as a proposed defect report. The Proposed Resolution in an issue with this status reflects the best judgment of the Committee at this time regarding the action that will be taken to remedy the defect; however, the current wording of the Standard remains in effect until such time as a Technical Corrigendum or a revision of the Standard is issued by ISO.
Dup: The issue is identical to or a subset of another issue, identified in a Rationale statement.
NAD: The working group has reached consensus that the issue is not a defect in the Standard. A Rationale statement describes the working group's reasoning.
Extension: The working group has reached consensus that the issue is not a defect in the Standard but is a request for an extension to the language. Under ISO rules, extensions cannot be considered for at least five years from the approval of the Standard, at which time the Standard will be open for review. The working group expresses no opinion on the merits of an issue with this status; however, the issue will be maintained on the list for possible future consideration when extension proposals will be in order.
Can a typedef T to a cv-qualified class type be used in a qualified name T::x?
struct A { static int i; };
typedef const A CA;
int main () {
CA::i = 0; // Okay?
}
Suggested answer: Yes. All the compilers I tried accept the test case.
Proposed resolution (10/01):
In 3.4.3.1 class.qual paragraph 1 add the indicated text:
If the nested-name-specifier of a qualified-id nominates a class, the name specified after the nested-name-specifier is looked up in the scope of the class (10.2 class.member.lookup), except for the cases listed below. The name shall represent one or more members of that class or of one of its base classes (clause 10 class.derived). If the class-or-namespace-name of the nested-name-specifier names a cv-qualified class type, it nominates the underlying class (the cv-qualifiers are ignored).
Notes from 4/02 meeting:
There is a problem in that class-or-namespace-name does not include typedef names for cv-qualified class types. See 7.1.3 dcl.typedef paragraph 4:
Argument and text removed from proposed resolution (October 2002):
7.1.3 dcl.typedef paragraph 5:
Here's a good question: in this example, should X be used as a name-for-linkage-purposes (FLP name)?
typedef class { } const X;
Because a type-qualifier is parsed as a decl-specifier, it isn't possible to declare cv-qualified and cv-unqualified typedefs for a type in a single declaration. Also, of course, there's no way to declare a typedef for the cv-unqualified version of a type for which only a cv-qualified version has a name. So, in the above example, if X isn't used as the FLP name, then there can be no FLP name. Also note that a FLP name usually represents a parameter type, where top-level cv-qualifiers are usually irrelevant anyway.
Data points: for the above example, Microsoft uses X as the FLP name; GNU and EDG do not.
My recommendation: for consistency with the direction we're going on this issue, for simplicity of description (e.g., "the first class-name declared by the declaration"), and for (very slightly) increased utility, I think Microsoft has this right.
If the typedef declaration defines an unnamed class type (or enum type), the first typedef-name declared by the declaration tobehave thatclasstype(or enum type)or a cv-qualified version thereof is used to denote the class type (or enum type) for linkage purposes only (3.5 basic.link). [Example: ...
Proposed resolution (October 2002):
3.4.4 basic.lookup.elab paragraphs 2 and 3:
This sentence is deleted twice:
...If this name lookup finds a typedef-name, the elaborated-type-specifier is ill-formed....
Note that the above changes are included in N1376 as part of the resolution of issue 245.
5.1 expr.prim paragraph 7:
This is only a note, and it is at least incomplete (and quite possibly inaccurate), despite (or because of) its complexity. I propose to delete it.
... [Note: a typedef-name that names a class is a class-name (9.1 class.name).Except as the identifier in the declarator for a constructor or destructor definition outside of a class member-specification (12.1 class.ctor, 12.4 class.dtor), a typedef-name that names a class may be used in a qualified-id to refer to a constructor or destructor.]
7.1.3 dcl.typedef paragraph 4:
My first choice would have been to make this the primary statement about the equivalence of typedef-name and class-name, since the equivalence comes about as a result of a typedef declaration. Unfortunately, references to class-name point to 9.1 class.name, so it would seem that the primary statement should be there instead. To avoid the possiblity of conflicts in the future, I propose to make this a note.
[Note: A typedef-name that names a class type, or a cv-qualified version thereof, is also a class-name (9.1 class.name). If a typedef-name is usedfollowing the class-key in an elaborated-type-specifier (7.1.5.3 dcl.type.elab), or in the class-head of a class declaration (9 class), or is used as the identifier in the declarator for a constructor or destructor declaration (12.1 class.ctor, 12.4 class.dtor),to identify the subject of an elaborated-type-specifier (7.1.5.3 dcl.type.elab), class declaration (clause 9 class), constructor declaration (12.1 class.ctor), or destructor declaration (12.4 class.dtor), the program is ill-formed. ] [Example: ...
7.1.5.3 dcl.type.elab paragraph 2:
This is the only remaining (normative) statement that a typedef-name can't be used in an elaborated-type-specifier. The reference to template type-parameter is deleted by the resolution of issue 283.
... If the identifier resolves to a typedef-nameor a template type-parameter, the elaborated-type-specifier is ill-formed. [Note: ...
8 dcl.decl grammar rule declarator-id:
When I looked carefully into the statement of the rule prohibiting a typedef-name in a constructor declaration, it appeared to me that this grammar rule (inadvertently?) allows something that's always forbidden semantically.
declarator-id:
id-expression
::opt nested-name-specifieropttype-nameclass-name
9.1 class.name paragraph 5:
Unlike the prohibitions against appearing in an elaborated-type-specifier or constructor or destructor declarator, each of which was expressed more than once, the prohibition against a typedef-name appearing in a class-head was previously stated only in 7.1.3 dcl.typedef. It seems to me that that prohibition belongs here instead. Also, it seems to me important to clarify that a typedef-name that is a class-name is still a typedef-name. Otherwise, the various prohibitions can be argued around easily, if perversely ("But that isn't a typedef-name, it's a class-name; it says so right there in 9.1 class.name.")
A typedef-name (7.1.3 dcl.typedef) that names a class type or a cv-qualified version thereof is also a class-name, but shall not be usedin an elaborated-type-specifier; see also 7.1.3 dcl.typedef.as the identifier in a class-head.
12.1 class.ctor paragraph 3:
The new nonterminal references are needed to really nail down what we're talking about here. Otherwise, I'm just eliminating redundancy. (A typedef-name that doesn't name a class type is no more valid here than one that does.)
A typedef-name that names a class is a class-name (7.1.3 dcl.typedef); however, aA typedef-namethat names a classshall not be used as theidentifierclass-name in thedeclaratordeclarator-id for a constructor declaration.
12.4 class.dtor paragraph 1:
The same comments apply here as to 12.1 class.ctor.
...A typedef-name that names a class is a class-name (7.1.3); however, aA typedef-namethat names a classshall not be used as theidentifierclass-name following the ~ in the declarator for a destructor declaration.
A use of an injected-class-name in an elaborated-type-specifier should not name the constructor of the class, but rather the class itself, because in that context we know that we're looking for a type. See issue 147.
Proposed Resolution (revised October 2002):
This clarifies the changes made in the TC for issue 147.
In 3.4.3.1 class.qual paragraph 1a replace:
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.
with
In a lookup in which the constructor is an acceptable lookup result, 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. [Note: For example, the constructor is not an acceptable lookup result in an elaborated type specifier so the constructor would not be used in place of the injected class name.]
Note that issue 263 updates a part of the same paragraph.
Append to the example:
struct A::A a2; // object of type A
I have some concerns with the description of name lookup for elaborated type specifiers in 3.4.4 basic.lookup.elab:
Paragraph 2 has some parodoxical statements concerning looking up names that are simple identifers:
If the elaborated-type-specifier refers to an enum-name and this lookup does not find a previously declared enum-name, the elaborated-type-specifier is ill-formed. If the elaborated-type-specifier refers to an [sic] class-name and this lookup does not find a previously declared class-name... the elaborated-type-specifier is a declaration that introduces the class-name as described in 3.3.1 basic.scope.pdecl."
It is not clear how an elaborated-type-specifier can refer to an enum-name or class-name given that the lookup does not find such a name and that class-name and enum-name are not part of the syntax of an elaborated-type-specifier.
The second sentence quoted above seems to suggest that the name found will not be used if it is not a class name. typedef-name names are ill-formed due to the sentence preceding the quote. If lookup finds, for instance, an enum-name then a new declaration will be created. This differs from C, and from the enum case, and can have surprising effects:
struct S {
enum E {
one = 1
};
class E* p; // declares a global class E?
};
Was this really the intent? If this is the case then some more work is needed on 3.4.4 basic.lookup.elab. Note that the section does not make finding a type template formal ill-formed, as is done in 7.1.5.3 dcl.type.elab. I don't see anything that makes a type template formal name a class-name. So the example in 7.1.5.3 dcl.type.elab of friend class T; where T is a template type formal would no longer be ill-formed with this interpretation because it would declare a new class T.
(See also issue 254.)
Notes from the 4/02 meeting:
This will be consolidated with the changes for issue 254. See also issue 298.
Proposed resolution (October 2002):
As given in N1376=02-0034. Note that the inserts and strikeouts in that document do not display correctly in all browsers; <del> --> <strike> and <ins> --> <b>, and the similar changes for the closing delimiters, seem to do the trick.
The text in 3.4.4 basic.lookup.elab paragraph 2 twice refers to the possibility that an elaborated-type-specifier might have the form
class-key identifier ;
However, the grammar for elaborated-type-specifier does not include a semicolon.
In both 3.4.4 basic.lookup.elab and 7.1.5.3 dcl.type.elab, the text asserts that an elaborated-type-specifier that refers to a typedef-name is ill-formed. However, it is permissible for the form of elaborated-type-specifier that begins with typename to refer to a typedef-name.
This problem is the result of adding the typename form to the elaborated-type-name grammar without changing the verbiage correspondingly. It could be fixed either by updating the verbiage or by moving the typename syntax into its own production and referring to both nonterminals when needed.
(See also issue 180. If this issue is resolved in favor of a separate nonterminal in the grammar for the typename forms, the wording in that issue's resolution must be changed accordingly.)
Notes from 04/01 meeting:
The consensus was in favor of moving the typename forms out of the elaborated-type-specifier grammar.
Notes from the 4/02 meeting:
This will be consolidated with the changes for issue 245.
Proposed resolution (October 2002):
As given in N1376=02-0034.
The wording in 3.8 basic.life paragraph 6 allows an lvalue designating an out-of-lifetime object to be used as the operand of a static_cast only if the conversion is ultimately to "char&" or "unsigned char&". This description excludes the possibility of using a cv-qualified version of these types for no apparent reason.
Notes on 04/01 meeting:
The wording should be changed to allow cv-qualified char types.
Proposed resolution (04/01):
In 3.8 basic.life paragraph 6 change the third bullet:
In a couple of comp.std.c++ threads, people have asked whether the Standard guarantees that the deallocation function will be called in a delete-expression if the destructor throws an exception. Most/all people have expressed the opinion that the deallocation function must be called in this case, although no one has been able to cite wording in the Standard supporting that view.
#include <new.h>
#include <stdio.h>
#include <stdlib.h>
static int flag = 0;
inline
void operator delete(void* p) throw()
{
if (flag)
printf("in deallocation function\n");
free(p);
}
struct S {
~S() { throw 0; }
};
void f() {
try {
delete new S;
}
catch(...) { }
}
int main() {
flag=1;
f();
flag=0;
return 0;
}
Proposed resolution (October 2002):
Add to 5.3.5 expr.delete paragraph 7 the highlighted text:
The delete-expression will call a deallocation function (3.7.3.2 basic.stc.dynamic.deallocation) [Note: The deallocation function is called regardless of whether the destructor for the object or some element of the array throws an exception. ]
Although 14.1 temp.param paragraph 3 contains an assertion that
A type-parameter defines its identifier to be a type-name (if declared with class or typename)
the grammar in 7.1.5.2 dcl.type.simple paragraph 1 says that a type-name is either a class-name, an enum-name, or a typedef-name. The identifier in a template type-parameter is none of those. One possibility might be to equate the identifier with a typedef-name instead of directly with a type-name, which would have the advantage of not requiring parallel treatment of the two in situations where they are treated the same (e.g., in elaborated-type-specifiers, see issue 245). See also issue 215.
Proposed resolution (Clark Nelson, March 2002):
In 14.1 temp.param paragraph 3, change "A type-parameter defines its identifier to be a type-name" to "A type-parameter defines its identifier to be a typedef-name"
In 7.1.5.3 dcl.type.elab paragraph 2, change "If the identifier resolves to a typedef-name or a template type-parameter" to "If the identifier resolves to a typedef-name".
This has been consolidated with the edits for some other issues. See N1376=02-0034.
7.2 dcl.enum defines the underlying type of an enumeration as an integral type "that can represent all the enumerator values defined in the enumeration".
What does the standard say about this code:
enum E { a = LONG_MIN, b = ULONG_MAX };
?
I think this should be ill-formed.
Proposed resolution:
In 7.2 dcl.enum paragraph 5 after
The underlying type of an enumeration is an integral type that can represent all the enumerator values defined in the enumeration.insert
If no integral type can represent all the enumerator values, the enumeration is ill-formed.
According to 7.3.3 namespace.udecl paragraph 12,
When a using-declaration brings names from a base class into a derived class scope, member functions in the derived class override and/or hide member functions with the same name and parameter types in a base class (rather than conflicting).
Note that this description says nothing about the cv-qualification of the hiding and hidden member functions. This means, for instance, that a non-const member function in the derived class hides a const member function with the same name and parameter types instead of overloading it in the derived class scope. For example,
struct A {
virtual int f() const;
virtual int f();
};
struct B: A {
B();
int f();
using A::f;
};
const B cb;
int i = cb.f(); // ill-formed: A::f() const hidden in B
The same terminology is used in 10.3 class.virtual paragraph 2:
If a virtual member function vf is declared in a class Base and in a class Derived, derived directly or indirectly from Base, a member function vf with the same name and same parameter list as Base::vf is declared, then Derived::vf is also virtual (whether or not it is so declared) and it overrides Base::vf.
Notes on the 04/01 meeting:
The hiding and overriding should be on the basis of the function signature, which includes any cv-qualification on the function.
Proposed resolution (04/02):
In 7.3.3 namespace.udecl paragraph 12 change:
When a using-declaration brings names from a base class into a derived class scope, member functions in the derived class override and/or hide member functions with the same name and parameter types in a base class (rather than conflicting).to read:
When a using-declaration brings names from a base class into a derived class scope, member functions and member function templates in the derived class override and/or hide member functions and member function templates with the same name, parameter-type-list (8.3.5 dcl.fct), and cv-qualification in a base class (rather than conflicting).
In 10.3 class.virtual paragraph 2 change:
If a virtual member function vf is declared in a class Base and in a class Derived, derived directly or indirectly from Base, a member function vf with the same name and same parameter list as Base::vf is declared, then Derived::vf is also virtual (whether or not it is so declared) and it overrides Base::vf.to read:
If a virtual member function vf is declared in a class Base and in a class Derived, derived directly or indirectly from Base, a member function vf with the same name, parameter-type-list (8.3.5 dcl.fct), and cv-qualification as Base::vf is declared, then Derived::vf is also virtual (whether or not it is so declared) and it overrides Base::vf.
See issue 140 for the definition of parameter-type-list.
The interaction of default arguments and ellipsis is not clearly spelled out in the current wording of the Standard. 8.3.6 dcl.fct.default paragraph 4 says,
In a given function declaration, all parameters subsequent to a parameter with a default argument shall have default arguments supplied in this or previous declarations.
Strictly speaking, ellipsis isn't a parameter, but this could be clearer. Also, in 8.3.5 dcl.fct paragraph 2,
If the parameter-declaration-clause terminates with an ellipsis, the number of arguments shall be equal to or greater than the number of parameters specified.
This could be interpreted to refer to the number of arguments after the addition of default arguments to the argument list given in the call expression, but again it could be clearer.
Notes from 04/01 meeting:
The consensus opinion was that an ellipsis is not a parameter and that default arguments should be permitted preceding an ellipsis.
Proposed Resolution (4/02):
Change the following sentence in 8.3.5 dcl.fct paragraph 2 from
If the parameter-declaration-clause terminates with an ellipsis, the number of arguments shall be equal to or greater than the number of parameters specified.
to
If the parameter-declaration-clause terminates with an ellipsis, the number of arguments shall be equal to or greater than the number of parameters that do not have a default argument.
As noted in the defect, section 8.3.6 dcl.fct.default is correct but could be clearer.
In 8.3.6 dcl.fct.default, add the following as the first line of the example in paragraph 4.
void g(int = 0, ...); // okay, ellipsis is not a parameter so it can follow
// a parameter with a default argument
Is it legal to use an incomplete type (3.9 basic.types paragraph 6) as a class member, if no object of such class is ever created ?
And as a class template member, even if the template is instantiated, but no object of the instantiated class is created?
The consensus seems to be NO, but no wording was found in the standard which explicitly disallows it.
The problem seems to be that most of the restrictions on incomplete types are on their use in objects, but class members are not objects.
A possible resolution, if this is considered a defect, is to add to 3.2 basic.def.odr paragraph 4, (situations when T must be complete), the use of T as a member of a class or instantiated class template.
The thread on comp.std.c++ which brought up the issue was "Compiler differences: which is correct?", started 2001 11 30. <3c07c8fb$0$8507$ed9e5944@reading.news.pipex.net>
Proposed Resolution (4/02):
Add after the first bullet of the note in 3.2 basic.def.odr paragraph 4:
Replace 9.2 class.mem paragraph 8 by:
Non-static (9.4 class.static) data members shall not have incomplete types. In particular, a class C shall not contain a non-static member of class C, but it can contain a pointer or reference to an object of class C.
See also 3.9 basic.types paragraph 6, which is relevant but not changed by the Proposed Resolution.
9.8 class.local paragraph 1 says,
Declarations in a local class can use only type names, static variables, extern variables and functions, and enumerators from the enclosing scope.The definition of when an object or function is "used" is found in 3.2 basic.def.odr paragraph 2 and essentially says that the operands of sizeof and non-polymorphic typeid operators are not used. (The resolution for issue 48 will add contexts in which integral constant expressions are required to the list of non-uses.)
This definition of "use" would presumably allow code like
void foo() {
int i;
struct S {
int a[sizeof(i)];
};
};
which is required for C compatibility.
However, the restrictions on nested classes in 9.7 class.nest paragraph 1 are very similar to those for local classes, and the example there explicitly states that a reference in a sizeof expression is a forbidden use (abbreviated for exposition):
class enclose {
public:
int x;
class inner {
void f(int i)
{
int a = sizeof(x); // error: refers to enclose::x
}
};
};
[As a personal note, I have seen real-world code that was exactly like this; it was hard to persuade the author that the required writearound, sizeof(((enclose*) 0)->x), was an improvement over sizeof(x). —wmm]
Similarly, 9.2 class.mem paragraph 9 would appear to prohibit examples like the following:
struct B {
char x[10];
};
struct D: B {
char y[sizeof(x)];
};
Suggested resolution: Add cross-references to 3.2 basic.def.odr following the word "use" in both 9.7 class.nest and 9.8 class.local , and change the example in 9.7 class.nest to indicate that a reference in a sizeof expression is permitted. In 9.2 class.mem paragraph 9, "referred to" should be changed to "used" with a cross_reference to 3.2 basic.def.odr.
Notes from 10/01 meeting:
It was noted that the suggested resolution did not make the sizeof() example in 9.7 class.nest valid. Although the reference to the argument of sizeof() is not regarded as a use, the right syntax must be used nonetheless to reference a non-static member from the enclosing class. The use of the member name by itself is not valid. The consensus within the core working group was that nothing should be done about this case. It was later discovered that 9.4 class.static paragraph 3 states that
The definition of a static member shall not use directly the names of the nonstatic members of its class or of a base class of its class (including as operands of the sizeof operator). The definition of a static member may only refer to these members to form pointer to members (5.3.1 expr.unary.op) or with the class member access syntax (5.2.5 expr.ref).
This seems to reinforce the decision of the working group.
The use of "use" should still be cross-referenced. The statements in 9.7 class.nest and 9.8 class.local should also be rewritten to state the requirement positively rather than negatively as the list of "can't"s is already missing some cases such as template parameters.
Notes from the 4/02 meeting:
We backed away from "use" in the technical sense, because the requirements on the form of reference are the same whether or not the reference occurs inside a sizeof.
Proposed Resolution (revised October 2002):
In 9.2 class.mem paragraph 9, replace
Except when used to form a pointer to member (5.3.1 expr.unary.op), when used in the body of a nonstatic member function of its class or of a class derived from its class (9.3.1 class.mfct.nonstatic), or when used in a mem-initializer for a constructor for its class or for a class derived from its class (12.6.2 class.base.init), a nonstatic data or function member of a class shall only be referred to with the class member access syntax (5.2.5 expr.ref).
with the following paragraph
Each occurrence in an expression of the name of a nonstatic data member or nonstatic member function of a class shall be expressed as a class member access (5.2.5 expr.ref), except when it appears in the formation of a pointer to member (5.3.1 expr.unary.op), when it appears in the body of a nonstatic member function of its class or of a class derived from its class (9.3.1 class.mfct.nonstatic), or when it appears in a mem-initializer for a constructor for its class or for a class derived from its class (12.6.2 class.base.init).
In 9.7 class.nest paragraph 1, replace the last sentence,
Except by using explicit pointers, references, and object names, declarations in a nested class can use only type names, static members, and enumerators from the enclosing class.
with the following
[Note: In accordance with 9.2 class.mem, except by using explicit pointers, references, and object names, declarations in a nested class shall not use nonstatic data members or nonstatic member functions from the enclosing class. This restriction applies in all constructs including the operands of the sizeof operator.]
In the example following 9.7 class.nest paragraph 1, change the comment on the first statement of function f to emphasize that sizeof(x) is an error. The example reads in full:
int x;
int y;
class enclose {
public:
int x;
static int s;
class inner {
void f(int i)
{
int a = sizeof(x); // error: direct use of enclose::x even in sizeof
x = i; // error: assign to enclose::x
s = i; // OK: assign to enclose::s
::x = i; // OK: assign to global x
y = i; // OK: assign to global y
}
void g(enclose* p, int i)
{
p->x = i; // OK: assign to enclose::x
}
};
};
inner* p = 0; // error: inner not in scope
According to 12.1 class.ctor paragraph 1, a declaration of a constructor has a special limited syntax, in which only function-specifiers are allowed. A friend specifier is not a function-specifier, so one interpretation is that a constructor cannot be declared in a friend declaration.
(It should also be noted, however, that neither friend nor function-specifier is part of the declarator syntax, so it's not clear that anything conclusive can be derived from the wording of 12.1 class.ctor.)
Notes from 04/01 meeting:
The consensus of the core language working group was that it should be permitted to declare constructors as friends.
Proposed Resolution (revised October 2002):
Change paragraph 1a in 3.4.3.1 class.qual (added by the resolution of issue 147) as follows:
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 be used only in the declarator-id of aconstructor definitiondeclaration thatappears outside of the class definitionnames a constructor....
Note: the above does not allow qualified names to be used for in-class declarations; see 8.3 dcl.meaning paragraph 1. Also note that issue 318 updates the same paragraph.
Change the example in 11.4 class.friend, paragraph 4 as follows:
class Y {
friend char* X::foo(int);
friend X::X(char); // constructors can be friends
friend X::~X(); // destructors can be friends
//...
};
14 temp paragraph 7 allows class templates to be declared exported, including member classes and member class templates (implicitly by virtue of exporting the containing template class). However, paragraph 8 does not exclude exported class templates from the statement that
An exported template need only be declared (and not necessarily defined) in a translation unit in which it is instantiated.This is an incorrect implication; however, it is also not dispelled in 14.7.1 temp.inst paragraph 6:
If an implicit instantiation of a class template specialization is required and the template is declared but not defined, the program is ill-formed.This wording says nothing about the translation unit in which the definition must be provided. Contrast this with 14.7.2 temp.explicit paragraph 3:
A definition of a class template or a class member template shall be in scope at the point of the explicit instantiation of the class template or class member template.
Suggested resolution:
(See also issue 212.)
Notes from 04/00 meeting:
John Spicer opined that even though 14 temp paragraph 7 speaks of "declaring a class template exported," that does not mean that the class template is "an exported template" in the sense of paragraph 8. He suggested clarifying paragraph 7 to that effect instead of the change to paragraph 8 suggested above, and questioned the need for a change to 14.7.1 temp.inst.
Notes from the 4/02 meeting:
This is resolved by the proposed changes for issue 323.
The standard doesn't seem to describe whether the keyword export should appear on exported template declarations that are not used or defined in that particular translation unit.
For example:
// File 1:
template<typename T> void f(); // export omitted
// File 2:
export template<typename T> void f() {}
int main() { f<int>(); }
Another example is:
// File 1:
struct S {
template<typename T> void m();
};
// File 2:
struct S {
template<typename T> void m();
};
export template<typename T> void S::m() {}
int main() {
S s;
S.m<int>();
}
I think both examples should be clarified to be invalid. If a template is exported in one translation unit, it should be declared export in all translation units in which it appears.
With the current wording, it seems that even the following is valid:
// File 1:
export template<typename T> void f(); // export effectively ignored
// File 2:
template<typename T> void f() {} // Inclusion model
void g() { f<int>(); }
// File 3:
void g();
template<typename T> void f() {} // Inclusion model
int main() {
g();
f<int>();
}
In fact, I think the declaration in "File 1" could be a definition and this would still satisfy the the requirements of the standard, which definitely seems wrong.
Proposed Resolution (revised October 2002):
Replace 14 temp paragraphs 6, 7, and 8 by the following text:
A template-declaration may be preceded by the export keyword. Such a template is said to be exported. Declaring exported a class template is equivalent to declaring exported all of its non-inline member functions, static data members, member classes, member class templates, and non-inline member function templates.
If a template is exported in one translation unit, it shall be exported in all translation units in which it appears; no diagnostic is required. A declaration of an exported template shall appear with the export keyword before any point of instantiation (14.6.4.1 temp.point) of that template in that translation unit. In addition, the first declaration of an exported template containing the export keyword must not follow the definition of that template. The export keyword shall not be used in a friend declaration.
Templates defined in an unnamed namespace, inline functions, and inline function templates shall not be exported. An exported non-class template shall be defined only once in a program; no diagnostic is required. An exported non-class template need only be declared (and not necessarily defined) in a translation unit in which it is instantiated.
A non-exported non-class 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: This change also resolves issues 204 and 335.
The syntax for "export" permits it only on template declarations. Clause 14 temp paragraph 6 further restricts "export" to appear only on namespace scope declarations. This means that you can't export a member template of a non-template class, as in:
class A {
template <class T> void f(T);
};
You can, of course, put export on the definition:
export template <class T> void A<T>::f(T){}
but in order for the template to be used from other translation units
(the whole point of export) the declaration in the other translation
unit must also be declared export.
There is also the issue of whether or not we should permit this usage:
export struct A {
template <class T> void f(T);
};
My initial reaction is to retain this prohibition as all current uses
of "export" are preceding the "template" keyword.
If we eliminate the requirement that "export" precede "template" there is a similar issue regarding this case, which is currently prohibited:
template <class T> struct B {
export void f();
};
My preference is still to permit only "export template".
Notes from the 4/02 meeting:
This is resolved by the proposed changes for issue 323.
John Spicer: Where can default values for the template parameters of template template parameters be specified and where so they apply?
For normal template parameters, defaults can be specified only in class template declarations and definitions, and they accumulate across multiple declarations in the same way that function default arguments do.
I think that defaults for parameters of template template parameters should be handled differently, though. I see no reason why such a default should extend beyond the template declaration with which it is associated. In other words, such defaults are a property of a specific template declaration and are not part of the interface of the template.
template <class T = float> struct B {};
template <template <class _T = float> class T> struct A {
inline void f();
inline void g();
};
template <template <class _T> class T> void A<T>::f() {
T<> t; // Okay? (proposed answer - no)
}
template <template <class _T = char> class T> // Okay? (proposed answer - yes)
void A<T>::g() {
T<> t; // T<char> or T<float>? (proposed answer - T<char>)
}
int main() {
A<B> ab;
ab.f();
}
I don't think this is clear in the standard.
Gabriel Dos Reis: On the other hand I fail to see the reasons why we should introduce yet another special rule to handle that situation differently. I think we should try to keep rules as uniform as possible. For default values, it has been the case that one should look for any declaration specifying default values. Breaking that rules doesn't buy us anything, at least as far as I can see. My feeling is that [allowing different defaults in different declarations] is very confusing.
Mike Miller: I'm with John on this one. Although we don't have the concept of "prototype scope" for template parameter lists, the analogy with function parameters would suggest that the two declarations of T (in the template class definition and the template member function definition) are separate declarations and completely unrelated. While it's true that you accumulate default arguments on top-level declarations in the same scope, it seems to me a far leap to say that we ought also to accumulate default arguments in nested declarations. I would expect those to be treated as being in different scopes and thus not to share default argument information.
When you look up the name T in the definition of A<T>::f(), the declaration you find has no default argument for the parameter of T, so T<> should not be allowed.
Proposed Resolution (revised October 2002):
In 14.1 temp.param, add the following as a new paragraph at the end of this section:
A template-parameter of a template template-parameter
is permitted to have a default template-argument. When such
default arguments are specified, they apply to the template
template-parameter in the scope of the template
template-parameter. [Example:
template <class T = float> struct B {};
template <template <class TT = float> class T> struct A {
inline void f();
inline void g();
};
template <template <class TT> class T> void A<T>::f() {
T<> t; // error - TT has no default template argument
}
template <template <class TT = char> class T>void A<T>::g() {
T<> t; // OK - T<char>
}
-- end example]
The prohibition of default template arguments for function templates is a misbegotten remnant of the time where freestanding functions were treated as second class citizens and required all template arguments to be deduced from the function arguments rather than specified.
The restriction seriously cramps programming style by unnecessarily making freestanding functions different from member functions, thus making it harder to write STL-style code.
Suggested resolution:
Replace
A default template-argument shall not be specified in a function template declaration or a function template definition, nor in the template-parameter-list of the definition of a member of a class template.
by
A default template-argument shall not be specified in the template-parameter-list of the definition of a member of a class template.
The actual rules are as stated for arguments to class templates.
Notes from 10/00 meeting:
The core language working group was amenable to this change. Questions arose, however, over the interaction between default template arguments and template argument deduction: should it be allowed or forbidden to specify a default argument for a deduced parameter? If it is allowed, what is the meaning: should one or the other have priority, or is it an error if the default and deduced arguments are different?
Notes from the 10/01 meeting:
It was decided that default arguments should be allowed on friend declarations only when the declaration is a definition. It was also noted that it is not necessary to insist that if there is a default argument for a given parameter all following parameters have default arguments, because (unlike in the class case) arguments can be deduced if they are not specified.
Note that there is an interaction with issue 115.
Proposed resolution (revised October 2002):
In 14.1 temp.param paragraph 9, replace
A default template-argument may be specified in a class template declaration or a class template definition. A default template-argument shall not be specified in a function template declaration or a function template definition, nor in the template-parameter-list of the definition of a member of a class template.
with
A default template-argument may be specified in a template declaration. A default template-argument shall not be specified in the template-parameter-lists of the definition of a member of a class template that appears outside of the member's class.
In 14.1 temp.param paragraph 9, replace
A default template-argument shall not be specified in a friend template declaration.
with
A default template-argument shall not be specified in a friend class template declaration. If a friend function template declaration specifies a default template-argument, that declaration shall be a definition and shall be the only declaration of the function template in the translation unit.
In 14.1 temp.param paragraph 11, replace
If a template-parameter has a default template-argument, all subsequent template-parameters shall have a default template-argument supplied.
with
If a template-parameter of a class template has a default template-argument, all subsequent template-parameters shall have a default template-argument supplied. [Note: This is not a requirement for function templates because template arguments might be deduced (14.8.2 temp.deduct).]
In 14.8 temp.fct.spec paragraph 1, replace
Template arguments can either be explicitly specified when naming the function template specialization or be deduced (14.8.2 temp.deduct) from the context, e.g. from the function arguments in a call to the function template specialization.
with
Template arguments can be explicitly specified when naming the function template specialization, deduced from the context (14.8.2 temp.deduct), e.g., deduced from the function arguments in a call to the function template specialization), or obtained from default template arguments.
In 14.8.1 temp.arg.explicit paragraph 2, replace
Trailing template arguments that can be deduced (14.8.2 temp.deduct) may be omitted from the list of explicit template-arguments.
with
Trailing template arguments that can be deduced (14.8.2 temp.deduct) or obtained from default template-arguments may be omitted from the list of explicit template-arguments.
In 14.8.2 temp.deduct paragraph 1, replace
The values can be either explicitly specified or, in some cases, deduced from the use.
with
The values can be explicitly specified or, in some cases, be deduced from the use or obtained from default template-arguments.
In 14.8.2 temp.deduct paragraph 4, replace
The resulting substituted and adjusted function type is used as the type of the function template for template argument deduction. When all template arguments have been deduced, all uses of template parameters in nondeduced contexts are replaced with the corresponding deduced argument values. If the substitution results in an invalid type, as described above, type deduction fails.
with
The resulting substituted and adjusted function type is used as the type of the function template for template argument deduction. If a template argument has not been deduced, its default template argument, if any, is used. [Example:
template <class T, class U = double> void f(T t = 0, U u = 0); void g() { f(1, 'c'); // f<int,char>(1,'c') f(1) // f<int,double>(1,0) f(); // error: T cannot be deduced f<int>(); // f<int,double>(0,0) f<int,char>(); // f<int,char>(0,0) }---end example]
When all template arguments have been deduced or obtained from default template arguments, all uses of template parameters in nondeduced contexts are replaced with the corresponding deduced or default argument values. If the substitution results in an invalid type, as described above, type deduction fails.
Consider the following example:
template<class T>
struct X {
virtual void f();
};
template<class T>
struct Y {
void g(X<T> *p) {
p->template X<T>::f();
}
};
This is an error because X is not a member template; 14.2 temp.names paragraph 5 says:
If a name prefixed by the keyword template is not the name of a member template, the program is ill-formed.
In a way this makes perfect sense: X is found to be a template using ordinary lookup even though p has a dependent type. However, I think this makes the use of the template prefix even harder to teach.
Was this intentionally outlawed?
Proposed Resolution (4/02):
Elide the first use of the word "member" in 14.2 temp.names paragraph 5 so that its first sentence reads:
If a name prefixed by the keyword template is not the name of amembertemplate, the program is ill-formed.
The following example from 14.6 temp.res paragraph 4:
struct A {
struct X { };
int X;
};
template<class T> void f(T t) {
typename T::X x; // ill-formed: finds the data member X
// not the member type X
}
is not ill-formed. The intent of the example is obvious, but some mention should be made that it is only ill-formed when T=A. For other T's, it could be well formed.
Proposed resolution (October 2002):
In 14.6 temp.res paragraph 4, replace the example with:
struct A {
struct X { };
int X;
} ;
struct B {
struct X { };
} ;
template<class T> void f(T t) {
typename T::X x;
}
void foo() {
A a;
B b;
f(b); // OK -- T::X refers to B::X.
f(a); // error: T::X refers to the data member A::X not
// the struct A::X.
}
The examples corrected by issue 24 are still wrong in one case.
In item #4 (a correction to the example in paragraph 18), the proposed resolution is:
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
The explicit specialization of member A<int>::B<double>::mf1 is ill-formed. The class template A<int>::B is explicitly specialized and contains no members, so any implicit specialization (such as A<int>::B<double>) would also contain no members.
Proposed Resolution (4/02):
Fix the example in 14.7.3 temp.expl.spec paragraph 18 to read:
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<class T> void mf1(T);
};
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
In 14.8.2 temp.deduct, attempting to create an array of abstract class type should be included in the list of things that cause type deduction to fail.
Proposed Resolution (4/02):
In 14.8.2 temp.deduct paragraph 2 amend the bullet item:
Attempting to create an array with an element type that is void, a function type, or a reference type, or attempting to create an array with a size that is zero or negative.
To the following:
Attempting to create an array with an element type that is void, a function type,ora reference type, or an abstract class type, or attempting to create an array with a size that is zero or negative.
Consider:
struct S {
template <class T> operator T& ();
};
int main ()
{
S s;
int i = static_cast<int&> (s);
}
14.8.2.3
temp.deduct.conv says that we strip the
reference from int&, but doesn't say
anything about T&. As a result, P (T&)
and A (int) have incompatible forms
and deduction fails.
Proposed Resolution (4/02):
Change the last chunk of 14.8.2.3 temp.deduct.conv paragraph 2 from
If A is a cv-qualified type, the top level cv-qualifiers of A's type are ignored for type deduction. If A is a reference type, the type referred to by A is used for type deduction.to
If A is a cv-qualified type, the top level cv-qualifiers of A's type are ignored for type deduction. If A is a reference type, the type referred to by A is used for type deduction. If P is a reference type, the type referred to by P is used for type deduction.
Should this program do what its author obviously expects? As far as I can tell, the standard says that the point of instantiation for Fib<n-1>::Value is the same as the point of instantiation as the enclosing specialization, i.e., Fib<n>::Value. What in the standard actually says that these things get initialized in the right order?
template<int n>
struct Fib { static int Value; };
template <>
int Fib<0>::Value = 0;
template <>
int Fib<1>::Value = 1;
template<int n>
int Fib<n>::Value = Fib<n-1>::Value + Fib<n-2>::Value;
int f ()
{
return Fib<40>::Value;
}
John Spicer: My opinion is that the standard does not specify the behavior of this program. I thought there was a core issue related to this, but I could not find it. The issue that I recall proposed tightening up the static initialization rules to make more cases well defined.
Your comment about point of instantiation is correct, but I don't think that really matters. What matters is the order of execution of the initialization code at execution time. Instantiations don't really live in "translation units" according to the standard. They live in "instantiation units", and the handling of instantiation units in initialization is unspecified (which should probably be another core issue). See 2.1 lex.phases paragraph 8.
Notes from October 2002 meeting:
We discussed this and agreed that we really do mean the the order is unspecified. John Spicer will propose wording on handling of instantiation units in initialization.
Proposed resolution (October 2002):
In 3.6.2 basic.start.init paragraph 1, replace
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
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. Definitions of template static data members are contained in instantiation units and not translation units (2.1 lex.phases); their order of initialization is unspecified both with respect to other template static data members and with respect to other objects with static storage duration.
An assignment returns an lvalue for its left operand. If that operand refers to a bit field, can the "&" operator be applied to the assignment? Can a reference be bound to it?
struct S { int a:3; int b:3; int c:3; };
void f()
{
struct S s;
const int *p = &(s.b = 0); // (a)
const int &r = (s.b = 0); // (b)
int &r2 = (s.b = 0); // (c)
}
Notes from the 4/02 meeting:
The working group agreed that this should be an error.
Proposed resolution (October 2002):
In 5.3.2 expr.pre.incr paragraph 1 (prefix "++" and "--" operators), change
The value is the new value of the operand; it is an lvalue.to
The result is the updated operand; it is an lvalue, and it is a bit-field if the operand is a bit-field.
In 5.16 expr.cond paragraph 4 ("?" operator), add the indicated text:
If the second and third operands are lvalues and have the same type, the result is of that type and is an lvalue and it is a bit-field if the second or the third operand is a bit-field, or if both are bit-fields.
In 5.17 expr.ass paragraph 1 (assignment operators) add the indicated text (the original text is as updated by issue 221, which is DR but not in TC1):
The assignment operator (=) and the compound assignment operators all group right-to-left. All require a modifiable lvalue as their left operand and return an lvalue with the type and value of the left operand after the assignment has taken place. The result in all cases is a bit-field if the left operand is a bit-field.
Note that issue 222 adds (non-conflicting) text at the end of this same paragraph (5.17 expr.ass paragraph 1).
In 5.18 expr.comma paragraph 1 (comma operator), change:
The type and value of the result are the type and value of the right operand; the result is an lvalue if its right operand is.to
The type and value of the result are the type and value of the right operand; the result is an lvalue if the right operand is an lvalue, and is a bit-field if the right operand is an lvalue and a bit-field.
Relevant related text (no changes required):
5.3.1 expr.unary.op paragraph 4:
The operand of & shall not be a bit-field.
8.5.3 dcl.init.ref paragraph 5, bullet 1, sub-bullet 1 (regarding binding a reference to an lvalue):
... is an lvalue (but is not a bit-field) ...
According to 16.1 cpp.cond paragraph 1, the if-group
#if "Hello, world"
is well-formed, since it is an integral constant expression. Since that may not be obvious, here is why:
5.19 expr.const paragraph 1 says that an integral constant expression may involve literals (2.13 lex.literal); "Hello, world" is a literal. It restricts operators to not use certain type conversions; this expression does not use type conversions. It further disallows functions, class objects, pointers, ... - this expression is none of those, since it is an array.
However, 16.1 cpp.cond paragraph 6 does not explain what to do with this if-group, since the expression evaluates neither to false(zero) nor true(non-zero).
Proposed resolution (October 2002):
Change the beginning of the second sentence of 5.19 expr.const paragraph 1 which currently reads
An integral constant-expression can involve only literals (2.13 lex.literal), ...to say
An integral constant-expression can involve only literals of arithmetic types (2.13 lex.literal, 3.9.1 basic.fundamental), ...
The ARM used the term "class declaration" to refer to what would usually be termed the definition of the class. The standard now often uses "class definition", but there are some surviving uses of "class declaration" with the old meaning. They should be found and changed.
Proposed resolution (October 2002):
Replace in 3.1 basic.def paragraph 2
A declaration is a definition unless it declares a function without specifying the function's body (8.4 dcl.fct.def), it contains the extern specifier (7.1.1 dcl.stc) or a linkage-specification [Footnote: Appearing inside the braced-enclosed declaration-seq in a linkage-specification does not affect whether a declaration is a definition. --- end footnote] (7.5 dcl.link) and neither an initializer nor a function-body, it declares a static data member in a classdeclarationdefinition (9.4 class.static), it is a class name declaration (9.1 class.name), or it is a typedef declaration (7.1.3 dcl.typedef), a using-declaration (7.3.3 namespace.udecl), or a using-directive (7.3.4 namespace.udir).
Replace in 7.1.2 dcl.fct.spec paragraphs 5 and 6
The virtual specifier shall only be used in declarations of nonstatic class member functions that appear within a member-specification of a class
declarationdefinition; see 10.3 class.virtual.The explicit specifier shall be used only in declarations of constructors within a class
declarationdefinition; see 12.3.1 class.conv.ctor.
Replace in 7.3.1.2 namespace.memdef paragraph 3
The name of the friend is not found by simple name lookup until a matching declaration is provided in that namespace scope (either before or after the classdeclarationdefinition granting friendship).
Replace in 8.5.3 dcl.init.ref paragraph 3
The initializer can be omitted for a reference only in a parameter declaration (8.3.5 dcl.fct), in the declaration of a function return type, in the declaration of a class member within its classdeclarationdefinition (9.2 class.mem), and where the extern specifier is explicitly used.
Replace in 9.4 class.static paragraph 4
Static members obey the usual class member access rules (clause 11 class.access). When used in the declaration of a class member, the static specifier shall only be used in the member declarations that appear within the member-specification of the classdeclarationdefinition.
Replace in 9.7 class.nest paragraph 1
A class can bedefineddeclared within another class. A classdefineddeclared within another is called a nested class. The name of a nested class is local to its enclosing class. The nested class is in the scope of its enclosing class. Except by using explicit pointers, references, and object names, declarations in a nested class can use only type names, static members, and enumerators from the enclosing class.
Replace in 9.8 class.local paragraph 1
A class can bedefineddeclared within a function definition; such a class is called a local class. The name of a local class is local to its enclosing scope. The local class is in the scope of the enclosing scope, and has the same access to names outside the function as does the enclosing function. Declarations in a local class can use only type names, static variables, extern variables and functions, and enumerators from the enclosing scope.
Replace in 10.4 class.abstract paragraph 2
... A virtual function is specified pure by using a pure-specifier (9.2 class.mem) in the function declaration in the classdeclarationdefinition. ...
Replace in the footnote at the end of 11.2 class.access.base paragraph 1
[Footnote: As specified previously in clause 11 class.access, private members of a base class remain inaccessible even to derived classes unless friend declarations within the base classdeclarationdefinition are used to grant access explicitly.]
Replace in 11.3 class.access.dcl paragraph 1
The access of a member of a base class can be changed in the derived class by mentioning its qualified-id in the derived classdeclarationdefinition. Such mention is called an access declaration. ...
Replace in C.1.7 diff.class paragraph 3
In C++, a typedef name may not be redefined in a classdeclarationdefinition after being used inthe declarationthat definition
Drafting note: The following occurrences of "class declaration" are not changed:
The ambiguity text in 10.2 class.member.lookup may not say what we intended. It makes the following example ill-formed:
struct A {
int x(int);
};
struct B: A {
using A::x;
float x(float);
};
int f(B* b) {
b->x(3); // ambiguous
}
This is a name lookup ambiguity because of 10.2
class.member.lookup
paragraph 2:
... Each of these declarations that was introduced by a using-declaration is considered to be from each sub-object of C that is of the type containing the declaration designated by the using-declaration. If the resulting set of declarations are not all from sub-objects of the same type, or the set has a nonstatic member and includes members from distinct sub-objects, there is an ambiguity and the program is ill-formed.This contradicts the text and example in paragraph 12 of 7.3.3 namespace.udecl .
Proposed Resolution (10/00):
Replace the two cited sentences from 10.2 class.member.lookup paragraph 2 with the following:
The resulting set of declarations shall all be from sub-objects of the same type, or there shall be a set of declarations from sub-objects of a single type that contains using-declarations for the declarations found in all other sub-object types. Furthermore, for nonstatic members, the resulting set of declarations shall all be from a single sub-object, or there shall be a set of declarations from a single sub-object that contains using-declarations for the declarations found in all other sub-objects. Otherwise, there is an ambiguity and the program is ill-formed.
Replace the examples in 10.2 class.member.lookup paragraph 3 with the following:
struct A {
int x(int);
static int y(int);
};
struct V {
int z(int);
};
struct B: A, virtual V {
using A::x;
float x(float);
using A::y;
static float y(float);
using V::z;
float z(float);
};
struct C: B, A, virtual V {
};
void f(C* c) {
c->x(3); // ambiguous -- more than one sub-object A
c->y(3); // not ambiguous
c->z(3); // not ambiguous
}
Notes from 04/01 meeting:
The following example should be accepted but is rejected by the wording above:
struct A { static void f(); };
struct B1: virtual A {
using A::f;
};
struct B2: virtual A {
using A::f;
};
struct C: B1, B2 { };
void g() {
C::f(); // OK, calls A::f()
}
Notes from 10/01 meeting (Jason Merrill):
The example in the issues list:
struct A {
int x(int);
};
struct B: A {
using A::x;
float x(float);
};
int f(B* b) {
b->x(3); // ambiguous
}
Is broken under the existing wording:
... Each of these declarations that was introduced by a using-declaration is considered to be from each sub-object of C that is of the type containing the declaration designated by the using-declaration. If the resulting set of declarations are not all from sub-objects of the same type, or the set has a nonstatic member and includes members from distinct sub-objects, there is an ambiguity and the program is ill-formed.Since the two x's are considered to be "from" different objects, looking up x produces a set including declarations "from" different objects, and the program is ill-formed. Clearly this is wrong. The problem with the existing wording is that it fails to consider lookup context.
The first proposed solution:
The resulting set of declarations shall all be from sub-objects of the same type, or there shall be a set of declarations from sub-objects of a single type that contains using-declarations for the declarations found in all other sub-object types. Furthermore, for nonstatic members, the resulting set of declarations shall all be from a single sub-object, or there shall be a set of declarations from a single sub-object that contains using-declarations for the declarations found in all other sub-objects. Otherwise, there is an ambiguity and the program is ill-formed.breaks this testcase:
struct A { static void f(); };
struct B1: virtual A {
using A::f;
};
struct B2: virtual A {
using A::f;
};
struct C: B1, B2 { };
void g() {
C::f(); // OK, calls A::f()
}
because it considers the lookup context, but not the definition context;
under this definition of "from", the two declarations found are the
using-declarations, which are "from" B1 and B2.
The solution is to separate the notions of lookup and definition context. I have taken an algorithmic approach to describing the strategy.
Incidentally, the earlier proposal allows one base to have a superset of the declarations in another base; that was an extension, and my proposal does not do that. One algorithmic benefit of this limitation is to simplify the case of a virtual base being hidden along one arm and not another ("domination"); if we allowed supersets, we would need to remember which subobjects had which declarations, while under the following resolution we need only keep two lists, of subobjects and declarations.
Proposed resolution (October 2002):
Replace 10.2 class.member.lookup paragraph 2 with:
The following steps define the result of name lookup for a member name f in a class scope C.
The lookup set for f in C, called S(f,C), consists of two component sets: the declaration set, a set of members named f; and the subobject set, a set of subobjects where declarations of these members (possibly including using-declarations) were found. In the declaration set, using-declarations are replaced by the members they designate, and type declarations (including injected-class-names) are replaced by the types they designate. S(f,C) is calculated as follows.
If C contains a declaration of the name f, the declaration set contains every declaration of f in C (excluding bases), the subobject set contains C itself, and calculation is complete.
Otherwise, S(f,C) is initially empty. If C has base classes, calculate the lookup set for f in each direct base class subjobject Bi, and merge each such lookup set S(f,Bi) in turn into S(f,C).
The following steps define the result of merging lookup set S(f,Bi) into the intermediate S(f,C):
- If each of the subobject members of S(f,Bi) is a base class subobject of at least one of the subobject members of S(f,C), S(f,C) is unchanged and the merge is complete. Conversely, if each of the subobject members of S(f,C) is a base class subobject of at least one of the subobject members of S(f,Bi), the new S(f,C) is a copy of S(f,Bi).
- Otherwise, if the declaration sets of S(f,Bi) and S(f,C) differ, the merge is ambiguous: the new S(f,C) is a lookup set with an invalid declaration set and the union of the subobject sets. In subsequent merges, an invalid declaration set is considered different from any other.
- Otherwise, consider each declaration d in the set, where d is a member of class A. If d is a nonstatic member, compare the A base class subobjects of the subobject members of S(f,Bi) and S(f,C). If they do not match, the merge is ambiguous, as in the previous step. [Note: It is not necessary to remember which A subobject each member comes from, since using-declarations don't disambiguate. ]
- Otherwise, the new S(f,C) is a lookup set with the shared set of declarations and the union of the subobject sets.
The result of name lookup for f in C is the declaration set of S(f,C). If it is an invalid set, the program is ill-formed.
[Example:
struct A { int x; }; // S(x,A) = {{ A::x }, { A }} struct B { float x; }; // S(x,B) = {{ B::x }, { B }} struct C: public A, public B { }; // S(x,C) = { invalid, { A in C, B in C }} struct D: public virtual C { }; // S(x,D) = S(x,C) struct E: public virtual C { char x; }; // S(x,E) = {{ E::x }, { E }} struct F: public D, public E { }; // S(x,F) = S(x,E) int main() { F f; f.x = 0; // OK, lookup finds { E::x } }S(x,F) is unambiguous because the A and B base subobjects of D are also base subobjects of E, so S(x,D) is discarded in the first merge step. --end example]
Turn 10.2 class.member.lookup paragraphs 5 and 6 into notes.
Is the following well-formed?
struct A {
struct B { };
};
struct C : public A, public A::B {
B *p;
};
The lookup of B finds both the struct B in A
and the injected B from the A::B base class.
Are they the same thing? Does the standard say so?
What if a struct is found along one path and a typedef to that struct is found along another path? That should probably be valid, but does the standard say so?
This is resolved by issue 39
In 12.1 class.ctor paragraph 5, the standard says "A constructor is trivial if [...]", and goes on to define a trivial default constructor. Taken literally, this would mean that a copy constructor can't be trivial (contrary to 12.8 class.copy paragraph 6). I suggest changing this to "A default constructor is trivial if [...]". (I think the change is purely editorial.)
Proposed Resolution (revised October 2002):
Change 12.1 class.ctor paragraph 5-6 as follows:
A default constructor for a class X is a constructor of class X that can be called without an argument. If there is no
user-declareduser-declared constructor for class X, a default constructor is implicitly declared. Animplicitly-declaredimplicitly-declared default constructor is an inline public member of its class. A default constructor is trivial if it is an implicitly-declared default constructor and if:
- its class has no virtual functions (10.3 class.virtual) and no virtual base classes (10.1 class.mi), and
- all the direct base classes of its class have trivial default constructors, and
- for all the nonstatic data members of its class that are of class type (or array thereof), each such class has a trivial default constructor.
Otherwise, the default constructor is non-trivial.
Change 12.4 class.dtor paragraphs 3-4 as follows (the only changes are removing italics):
If a class has no
user-declareduser-declared destructor, a destructor is declared implicitly. Animplicitly-declaredimplicitly-declared destructor is an inline public member of its class. A destructor is trivial if it is an implicitly-declared destructor and if:
- all of the direct base classes of its class have trivial destructors and
- for all of the non-static data members of its class that are of class type (or array thereof), each such class has a trivial destructor.
Otherwise, the destructor is
non-trivialnon-trivial.
In 9.5 class.union paragraph 1, change "trivial constructor" to "trivial default constructor".
In 12.2 class.temporary paragraph 3, add to the reference to 12.1 class.ctor a second reference, to 12.8 class.copy.
12.1 class.ctor paragraph 10 states
A copy constructor for a class X is a constructor with a first parameter of type X & or of type const X &. [Note: see 12.8 class.copy for more information on copy constructors.]
No mention is made of constructors with first parameters of types volatile X & or const volatile X &. This statement seems to be in contradiction with 12.8 class.copy paragraph 2 which states
A non-template constructor for class X is a copy constructor if its first parameter is of type X &, const X &, volatile X & or const volatile X &, ...
12.8 class.copy paragraph 5 also mentions the volatile versions of the copy constructor, and the comparable paragraphs for copy assignment (12.8 class.copy paragraphs 9 and 10) all allow volatile versions, so it seems that 12.1 class.ctor is at fault.
Suggested resolution:
Change the wording of 12.1 class.ctor paragraph 10 to
A copy constructor for a class X is a constructor with a first parameter of type X &, const X &, volatile X & or const volatile X &. [Note: see 12.8 class.copy for more information on copy constructors.]
Proposed resolution (October 2002):
Change 12.1 class.ctor paragraph 10 from
A copy constructor for a class X is a constructor with a first parameter of type X& or of type const X&. [Note: see 12.8 class.copy for more information on copy constructors. ]to:
A copy constructor (12.8 class.copy) is used to copy objects of class type.
Consider this program:
struct S {
static void f (int);
void f (char);
};
void g () {
S::f ('a');
}
G++ 3.1 rejects it, saying:
test.C:7: cannot call member function `void S::f(char)' without object
Mark Mitchell: It looks to me like G++ is correct, given 13.3.1.1.1 over.call.func. This case is the "unqualified function call" case described in paragraph 3 of that section. ("Unqualified" here means that there is no "x->" or "x." in front of the call, not that the name is unqualified.)
That paragraph says that you first do name lookup. It then asks you to look at what declaration is returned. (That's a bit confusing; you presumably get a set of declarations. Or maybe not; the name lookup section says that if name lookup finds a non-static member in a context like this the program is in error. But surely this program is not erroneous. Hmm.)
Anyhow, you have -- at least -- "S::f(char)" as the result of the lookup.
The keyword "this" is not in scope, so "all overloaded declarations of the function name in T become candidate functions and a contrived object of type T becomes the implied object argument." That means we get both versions of "f" at this point. Then, "the call is ill-formed, however, if overload resolution selects one of the non-static members of T in this case." Since, in this case, "S::f(char)" is the winner, the program is ill-formed.
Steve Adamczyk: This result is surprising, because we've selected a function that we cannot call, when there is another function that can be called. This should either be ambiguous, or it should select the static member function. See also 13.3.1 over.match.funcs paragraph 2: "Similarly, when appropriate, the context can construct an argument list that contains an implied object argument..."
Notes from October 2002 meeting:
We agreed that g++ has it right, but the standard needs to be clearer.
Proposed resolution (October 2002):
Change 13.3.1.1.1 over.call.func paragraphs 2 and 3 as follows:
In qualified function calls, the name to be resolved is an id-expression and is preceded by an -> or . operator. Since the construct A->B is generally equivalent to (*A).B, the rest of clause 13 over assumes, without loss of generality, that all member function calls have been normalized to the form that uses an object and the . operator. Furthermore, clause 13 over assumes that the postfix-expression that is the left operand of the . operator has type ``cv T'' where T denotes a class. [Footnote: Note that cv-qualifiers on the type of objects are significant in overload resolution for both lvalue and class rvalue objects. --- end footnote] Under this assumption, the id-expression in the call is looked up as a member function of T following the rules for looking up names in classes (10.2 class.member.lookup).
If a member function is found, that function and its overloaded declarationsThe function declarations found by that lookup constitute the set of candidate functions. The argument list is the expression-list in the call augmented by the addition of the left operand of the . operator in the normalized member function call as the implied object argument (13.3.1 over.match.funcs).In unqualified function calls, the name is not qualified by an -> or . operator and has the more general form of a primary-expression. The name is looked up in the context of the function call following the normal rules for name lookup in function calls (3.4.2 basic.lookup.koenig).
If the name resolves to a non-member function declaration, that function and its overloaded declarationsThe function declarations found by that lookup constitute the set of candidate functions.[Footnote: Because of the usual name hiding rules, these will be introduced by declarations or by using-directives all found in the same block or all found at namespace scope. --- end footnote]Because of the rules for name lookup (3.4.2 basic.lookup.koenig), the set of candidate functions consists (1) entirely of non-member functions or (2) entirely of member functions of some class T. In case (1), tThe argument list is the same as the expression-list in the call.If the name resolves to a nonstatic member function, then the function call is actually a member function call.In case (2), the argument list is the expression-list in the call augmented by the addition of an implied object argument as in a qualified function call. If the keyword this (9.3.2 class.this) is in scope and refers totheclass Tof that member function, or a derived classthereofof T, then thefunction call is transformed into a normalized qualified function call usingimplied object argument is(*this)as the postfix-expression to the left of the . operator.The candidate functions and argument list are as described for qualified function calls above.If the keyword this is not in scope or refers to another class, thenname resolution found a static member of some classT. In this case,all overloaded declarations of the function name in T become candidate functions anda contrived object of type T becomes the implied object argument. [Footnote: An implied object argument must be contrived to correspond to the implicit object parameter attributed to member functions during overload resolution. It is not used in the call to the selected function. Since the member functions all have the same implicit object parameter, the contrived object will not be the cause to select or reject a function. --- end footnote] If the argument list is augmented by a contrived object andThe call is ill-formed, however, ifoverload resolution selects one of the non-static member functions of T, the call is ill-formedin this case.
According to 13.3.1.1.2 over.call.object paragraph 2, when the primary-expression E in the function call syntax evaluates to a class object of type "cv T", a surrogate call function corresponding to an appropriate conversion function declared in a direct or indirect base class B of T is included or not included in the set of candidate functions based on class B being accessible.
For instance in the following code sample, as per the paragraph in question, the expression c(3) calls f2, instead of the construct being ill-formed due to the conversion function A::operator fp1 being inaccessible and its corresponding surrogate call function providing a better match than the surrogate call function corresponding to C::operator fp2:
void f1(int) { }
void f2(float) { }
typedef void (* fp1)(int);
typedef void (* fp2)(float);
struct A {
operator fp1()
{ return f1; }
};
struct B : private A { };
struct C : B {
operator fp2()
{ return f2; }
};
int main()
{
C c;
c(3); // f2 is called, instead of the construct being ill-formed.
return 0;
}
The fact that the accessibility of a base class influences the overload resolution process contradicts the fundamental language rule (3.4 basic.lookup paragraph 1, and 13.3 over.match paragraph 2) that access checks are applied only once name lookup and function overload resolution (if applicable) have succeeded.
Notes from 4/02 meeting:
There was some concern about whether 10.2 class.member.lookup (or anything else, for that matter) actually defines "ambiguous base class". See issue 39. See also issue 156.
Notes from October 2002 meeting:
It was suggested that the ambiguity check is done as part of the call of the conversion function.
Proposed resolution (revised October 2002):
In 13.3.1.1.2 over.call.object paragraph 2, replace the last sentence
Similarly, surrogate call functions are added to the set of candidate functions for each conversion function declared in an accessible base class provided the function is not hidden within T by another intervening declaration.
with
Similarly, surrogate call functions are added to the set of candidate functions for each conversion function declared in a base class of T provided the function is not hidden within T by another intervening declaration.
Replace 13.3.1.1.2 over.call.object paragraph 3
If such a surrogate call function is selected by overload resolution, its body, as defined above, will be executed to convert E to the appropriate function and then to invoke that function with the arguments of the call.by
If such a surrogate call function is selected by overload resolution, the corresponding conversion function will be called to convert E to the appropriate function pointer or reference, and the function will then be invoked with the arguments of the call. If the conversion function cannot be called (e.g., because of an ambiguity), the program is ill-formed.
template <class T> void f(T);
template <class T> void g(T);
template <class T> void g(T,T);
int main()
{
(&f<int>);
(&g<int>);
}
The question is whether &f<int> identifies a unique function.
&g<int> is clearly ambiguous.
13.4 over.over paragraph 1 says that a function template name is considered to name a set of overloaded functions. I believe it should be expanded to say that a function template name with an explicit template argument list is also considered to name a set of overloaded functions.
In the general case, you need to have a destination type in order to identify a unique function. While it is possible to permit this, I don't think it is a good idea because such code depends on there only being one template of that name that is visible.
The EDG front end issues an error on this use of "f". egcs 1.1.1 allows it, but the most current snapshot of egcs that I have also issues an error on it.
It has been pointed out that when dealing with nontemplates, the rules for taking the address of a single function differ from the rules for an overload set, but this asymmetry is needed for C compatibility. This need does not exist for the template case.
My feeling is that a general rule is better than a general rule plus an exception. The general rule is that you need a destination type to be sure that the operation will succeed. The exception is when there is only one template in the set and only then when you provide values for all of the template arguments.
It is true that in some cases you can provide a shorthand, but only if you encourage a fragile coding style (that will cause programs to break when additional templates are added).
I think the standard needs to specify one way or the other how this case should be handled. My recommendation would be that it is ill-formed.
Nico Josuttis: Consider the following example:
template <int VAL>
int add (int elem)
{
return elem + VAL;
}
std::transform(coll.begin(), coll.end()
coll.begin(),
add<10>);
If John's recommendation is adopted, this code will become ill-formed. I bet there will be a lot of explanation for users necessary why this fails and that they have to change add<10> to something like (int (*)(int))add<10>.
This example code is probably common practice because this use of the STL is typical and is accepted in many current implementations. I strongly urge that this issue be resolved in favor of keeping this code valid.
Bill Gibbons: I find this rather surprising. Shouldn't a template-id which specifies all of the template arguments be treated like a declaration-only explicit instantiation, producing a set of ordinary function declarations? And when that set happens to contain only one function, shouldn't the example code work?
(See also issue 250.)
Notes from 04/01 meeting:
The consensus of the group was that the add example should not be an error.
Proposed resolution (October 2002):
In 13.4 add to the end of paragraph 2:
[Note: As described in 14.8.1 temp.arg.explicit, if deduction fails and the function template name is followed by an explicit template argument list, the template-id is then examined to see whether it identifies a single function template specialization. If it does, the template-id is considered to be an lvalue for that function template specialization. The target type is not used in that determination.]
In 14.8.1 temp.arg.explicit paragraph 2 insert before the first example:
In contexts where deduction is done and fails, or in contexts where deduction is not done, if a template argument list is specified and it, along with any default template arguments, identifies a single function template specialization, then the template-id is an lvalue for the function template specialization.
Change the first example of 14.8.1 temp.arg.explicit paragraph 2:
template<class X, class Y> X f(Y);
void g()
{
int i = f<int>(5.6); // Y is deduced to be double
int j = f(5.6); // ill-formed: X cannot be deduced
}
to read:
template<class X, class Y> X f(Y);
void g()
{
int i = f<int>(5.6); // Y is deduced to be double
int j = f(5.6); // ill-formed: X cannot be deduced
f<void>(f<int, bool>); // Y for outer f deduced to be
// int (*)(bool)
f<void>(f<int>); // ill-formed: f<int> does not denote a
// single template function specialization
}
Note: This interacts with the resolution of issue 226 (default template arguments for function templates).
I'm not really sure what the standard says about this. Personally, I'd like for it to be ill-formed, but I can't find any words that I can interpret to say so.
template<class T>
class X
{
protected:
typedef T Type;
};
template<class T>
class Y
{
};
template<class T,
template<class> class T1,
template<class> class T2>
class Z:
public T2<typename T1<T>::Type>,
public T1<T>
{
};
Z<int, X, Y> z;
John Spicer: I don't think the standard really addresses this case. There is wording about access checking of things used as template arguments, but that doesn't address accessing members of the template argument type (or template) from within the template.
This example is similar, but does not use template template arguments.
class X {
private:
struct Type {};
};
template <class T> struct A {
typename T::Type t;
};
A<X> ax;
This gets an error from most compilers, though the standard is probably mute on this as well. An error makes sense -- if there is no error, there is a hole in the access checking. (The special rule about no access checks on template parameters is not a hole, because the access is checked on the type passed in as an argument. But when you look up something in the scope of a template parameter type, you need to check the access to the member found.)
The logic in the template template parameter case should be similar: anytime you look up something in a template-dependent class, the member's access must be checked, because it could be different for different template instances.
Proposed Resolution (October 2002):
Change the last sentence of 14.3 temp.arg paragraph 3 from:
For a template-argument of class type, the template definition has no special access rights to the inaccessible members of the template argument type.to:
For a template-argument that is a class type or a class template, the
template definition has no special access rights to the members
of the template-argument. [Example:
template <template <class TT> class T> class A {
typename T<int>::S s;
};
template <class U> class B {
private:
struct S { /* ... */ };
};
A<B> b; // ill-formed, A has no access to B::S
-- end example]
14.5.3 temp.friend paragraph 5 says:
When a function is defined in a friend function declaration in a class template, the function is defined at each instantiation of the class template. The function is defined even if it is never used. The same restrictions on multiple declarations and definitions which apply to non-template function declarations and definitions also apply to these implicit definitions. [Note: if the function definition is ill-formed for a given specialization of the enclosing class template, the program is ill-formed even if the function is never used. ]
This means that the following program is invalid, even without the call of f(ai):
template <class T> struct A {
friend void f(A a) {
g(a);
}
};
int main()
{
A<int> ai;
// f(ai); // Error if f(ai) is actually called
}
The EDG front end issues an error on this case even if f(ai) is never called. Of the compilers I tried (g++, Sun, Microsoft, Borland) we are the only ones to issue such an error.
This issue came up because there is a library that either deliberately or accidentally makes use of friend functions that are not valid for certain instantiations.
The wording in the standard is the result of a deliberate decision made long ago, but given the fact that most implementations do otherwise it raises the issue of whether we did the right thing.
Upon further investigation, the current rule was adopted as the resolution to issue 6.47 in my series of template issue papers. At the time the issue was discussed (7/96) most compilers did evaluate such friends. So it seems that a number of compilers have changed their behavior since then.
Based on current practice, I think the standard should be changed to evaluate such friends only when used.
Proposed resolution (October 2002):
Change section 14.5.3 temp.friend paragraph 5 from:
When a function is defined in a friend function declaration in a class template, the function is defined at each instantiation of the class template. The function is defined even if it is never used. The same restrictions on multiple declarations and definitions which apply to non-template function declarations and definitions also apply to these implicit definitions. [Note: if the function definition is ill-formed for a given specialization of the enclosing class template, the program is ill-formed even if the function is never used. ]to:
When a function is defined in a friend function declaration in a class template, the function is instantiated when the function is used. The same restrictions on multiple declarations and definitions that apply to non-template function declarations and definitions also apply to these implicit definitions.Note the change from "which" to "that" in the last sentence.
In 14.5.5.2 temp.func.order, partial ordering is explained in terms of template argument deduction. However, the exact procedure for doing so is not specified. A number of details are missing, they are explained as sub-issues below.
template<class T> void g(T); // #1
template<class T> void g(T&); // #2
Here, #2 is at least as specialized as #1: With a synthetic type
U, #2 becomes g(U&); argument deduction against
#1 succeeds with T=U&. However, #1 is not at least as
specialized as #2: Deducing g(U) against g(T&)
fails. Therefore, the second template is more specialized than the
first, and the call g(x) is not ambiguous.
template<class S> void g(S); // #1
template<class T> void g(T const &); // #3
Here, #3 is clearly at least as specialized as #1. To determine
whether #1 is at least as specialized as #3, a unique type U
is synthesized, and deduction of g<U>(U) is performed
against #3. Following the rules in 14.8.2.1
temp.deduct.call,
deduction succeeds with T=U. Since the template argument is
U, and the deduced template parameter is also U, we
have an exact match between the template parameters. Even though the
conversion from U to U const & is an exact
match, it is not clear whether the added qualification should be taken
into account, as it is in other places.Issue 200 covers a related issue, illustrated by the following example:
template <class T> T f(int);
template <class T, class U> T f(U);
void g() {
f<int>(1);
}
Even though one template is "obviously" more specialized than the other, deduction fails in both directions because neither function parameter list allows template parameter T to be deduced.
(See also issue 250.)
Nathan Sidwell:
14.5.5.2 temp.func.order describes the partial ordering of function templates. Paragraph 5 states,
A template is more specialized than another if, and only if, it is at least as specialized as the other template and that template is not at least as specialized as the first.To paraphrase, given two templates A & B, if A's template parameters can be deduced by B, but B's cannot be deduced by A, then A is more specialized than B. Deduction is done as if for a function call. In particular, except for conversion operators, the return type is not involved in deduction. This leads to the following templates and use being unordered. (This example is culled from G++ bug report 4672 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=4672)
template <typename T, class U> T checked_cast(U from); //#1
template <typename T, class U> T checked_cast(U * from); //#2
class C {};
void foo (int *arg)
{
checked_cast <C const *> (arg);
}
In the call,
#1 can be deduced with T = 'C const *' and U = 'int *'
#2 can be deduced with T = 'C const *' and U = 'int'
It looks like #2 is more specialized that #1, but 14.5.5.2 temp.func.order does not make it so, as neither template can deduce 'T' from the other template's function parameters.
Possible Resolutions:
There are several possible solutions, however through experimentation I have discounted two of them.
Option 1:
When deducing function ordering, if the return type of one of the templates uses a template parameter, then return types should be used for deduction. This, unfortunately, makes existing well formed programs ill formed. For example
template <class T> class X {};
template <class T> X<T> Foo (T *); // #1
template <class T> int Foo (T const *); // #2
void Baz (int *p1, int const *p2)
{
int j = Foo (p2); //#3
}
Here, neither #1 nor #2 can deduce the other, as the return
types fail to match. Considering only the function parameters
gives #2 more specialized than #1, and hence makes the call
#3 well formed.
Option 2:
As option 1, but only consider the return type when deducing the template whose return type involves template parameters. This has the same flaw as option 1, and that example is similarly ill formed, as #1's return type 'X<T,0>' fails to match 'int' so #1 cannot deduce #2. In the converse direction, return types are not considered, but the function parameters fail to deduce.
Option 3:
It is observed that the original example is only callable with a template-id-expr to supply a value for the first, undeducible, parameter. If that parameter were deducible it would also appear within at least one of the function parameters. We can alter paragraph 4 of [temp.func.order] to indicate that it is not necessary to deduce the parameters which are provided explicitly, when the call has the form of a template-id-expr. This is a safe extension as it only serves to make ill formed programs well formed. It is also in line with the concept that deduction for function specialization order should proceed in a similar manner to function calling, in that explicitly provided parameter values are taken into consideration.
Suggested resolution:
Insert after the first sentence of paragraph 4 in
Should any template parameters remain undeduced, and the function call be of the form of a template-id-expr, those template parameters provided in the template-id-expr may be arbitrarily synthesized prior to determining whether the deduced arguments generate a valid function type.
See also issue 200.
(April 2002) John Spicer and John Wiegley have written a paper on this. See 02-0051/N1393.
Proposed resolution (October 2002):
Change 14.5.5.2 temp.func.order paragraph 2 to read:
Partial ordering selects which of two function templates is more specialized than the other by transforming each template in turn (see next paragraph) and performing template argument deduction using the function parameter types, or in the case of a conversion function the return type. The deduction process determines whether one of the templates is more specialized than the other. If so, the more specialized template is the one chosen by the partial ordering process.
Change 14.5.5.2 temp.func.order paragraph 3 to read:
To produce the transformed template, for each type, non-type, or template template parameter synthesize a unique type, value, or class template respectively and substitute it for each occurrence of that parameter in the function type of the template.
Change 14.5.5.2 temp.func.order paragraph 4 to read (note: the section reference should refer to the section added to 14.8.2 temp.deduct below):
Using the transformed function template's function parameter list, or in the case of a conversion function its transformed return type, perform type deduction against the function parameter list (or return type) of the other function. The mechanism for performing these deductions is given in 14.8.2.x.
Remove the text of 14.5.5.2 temp.func.order paragraph 5 but retain the example. The removed text is:
A template is more specialized than another if, and only if, it is at least as specialized as the other template and that template is not at least as specialized as the first.
Insert the following section before 14.8.2.4 temp.deduct.type: (Note that this would either be a new 14.8.2.4, or would be given a number like 14.8.2.3a. If neither of these is possible from a troff point of view, this could be made 14.8.2.5)
Deducing template arguments when determining the partial ordering of function templates (temp.deduct.partial)
Template argument deduction is done by comparing certain types associated with the two function templates being compared.
Two sets of types are used to determine the partial ordering. For each of the templates involved there is the original function type and the transformed function type. [Note: The creation of the transformed type is described in 14.5.5.2 temp.func.order.] The deduction process uses the transformed type as the argument template and the original type of the other template as the parameter template. This process is done twice for each type involved in the partial ordering comparison: once using the transformed template-1 as the argument template and template-2 as the parameter template and again using the transformed template-2 as the argument template and template-1 as the parameter template.
The types used to determine the ordering depend on the context in which the partial ordering is
- In the context of a function call, the function parameter types are used.
- In the context of a call to a conversion operator, the return types of the conversion function templates are used.
- In other contexts (14.5.5.2 temp.func.order), the function template's function type is used.
Each type from the parameter template and the corresponding type from the argument template are used as the types of P and A.
Before the partial ordering is done, certain transformations are performed on the types used for partial ordering:
- If P is a reference type, P is replaced by the type referred to.
- If A is a reference type, A is replaced by the type referred to.
If both P and A were reference types (before being replaced with the type referred to above), determine which of the two types (if any) is more cv-qualified than the other; otherwise the types are considered to be equally cv-qualified for partial ordering purposes. The result of this determination will be used below.
Remove any top-level cv-qualifiers:
- If P is a cv-qualified type, P is replaced by the cv-unqualified version of P.
- If A is a cv-qualified type, A is replaced by the cv-unqualified version of A.
Using the resulting types P and A the deduction is then done as described in (14.8.2.4 temp.deduct.type). If deduction succeeds for a given type, the type from the argument template is considered to be at least as specialized as the type from the parameter template.
If, for a given type, deduction succeeds in both directions (i.e., the types are identical after the transformations above) if the type from the argument template is more cv-qualified than the type from the parameter template (as described above) that type is considered to be more specialized than the other. If neither type is more cv-qualified than the other then neither type is more specialized than the other.
If for each type being considered a given template is at least as specialized for all types and more specialized for some set of types and the other template is not more specialized for any types or is not at least as specialized for any types, then the given template is more specialized than the other template. Otherwise, neither template is more specialized than the other.
In most cases, all template parameters must have values in order for deduction to succeed, but for partial ordering purposes a template parameter may remain without a value provided it is not used in the types being used for partial ordering. [Note: A template parameter used in a non-deduced context is considered used.]
[Example:
template <class T> T f(int); // #1 template <class T, class U> T f(U); // #2 void g() { f<int>(1); // #1 }--end example]
Nathan Sidwell: John Spicer's proposed resolution does not make the following well-formed.
template <typename T> int Foo (T const *) {return 1;} //#1
template <unsigned I> int Foo (char const (&)[I]) {return 2;} //#2
int main ()
{
return Foo ("a") != 2;
}
Both #1 and #2 can deduce the "a" argument, #1 deduces T as char and #2 deduces I as 2. However, neither is more specialized because the proposed rules do not have any array to pointer decay.
#1 is only deduceable because of the rules in 14.8.2.1 temp.deduct.call paragraph 2 that decay array and function type arguments when the template parameter is not a reference. Given that such behaviour happens in deduction, I believe there should be equivalent behaviour during partial ordering. #2 should be resolved as more specialized as #1. The following alteration to the proposed resolution of DR214 will do that.
Insert before,
the following
For the example above, this change results in deducing 'T const *' against 'char const *' in one direction (which succeeds), and 'char [I]' against 'T const *' in the other (which fails).
John Spicer: I don't consider this a shortcoming of my proposed wording, as I don't think this is part of the current rules. In other words, the resolution of 214 might make it clearer how this case is handled (i.e., clearer that it is not allowed), but I don't believe it represents a change in the language.
I'm not necessarily opposed to such a change, but I think it should be reviewed by the core group as a related change and not a defect in the proposed resolution to 214.
I understand the rules in 14.8.2 temp.deduct paragraph 2 are meant to be an exhaustive list of what can cause type deduction to fail.
Consider:
template<typename U,U u> struct wrap_t;
template<typename U> static yes check( wrap_t<U,U(0)>* );
struct X { X(int); };
int main() {
check<X>(0);
}
I can see 2 reasons this might cause type deduction to fail:
Neither case is mentioned in 14.8.2 temp.deduct paragraph 2, nor do I see a DR mentioning these.
Proposed resolution (October 2002):
Add after the fourth-to-last bullet of 14.8.2 temp.deduct paragraph 2:
- Attempting to give an invalid type to a nontype template parameter. [Example:
template <class T, T> struct S {}; template <class T> int f(S<T, T()>*); struct X {}; int i0 = f<X>(0);]
We ran into an issue concerning qualification conversions when doing template argument deduction for conversion functions.
The question is: What is the type of T in the conversion functions called by this example? Is T "int" or "const int"?
If T is "int", the conversion function in class A works and the one in class B fails (because the return expression cannot be converted to the return type of the function). If T is "const int", A fails and B works.
Because the qualification conversion is performed on the result of the conversion function, I see no benefit in deducing T as const int.
In addition, I think the code in class A is more likely to occur than the code in class B. If the author of the class was planning on returning a pointer to a const entity, I would expect the function to have been written with a const in the return type.
Consequently, I believe the correct result should be that T is int.
struct A {
template <class T> operator T***() {
int*** p = 0;
return p;
}
};
struct B {
template <class T> operator T***() {
const int*** p = 0;
return p;
}
};
int main()
{
A a;
const int * const * const * p1 = a;
B b;
const int * const * const * p2 = b;
}
We have just implemented this feature, and pending clarification by the committee, we deduce T as int. It appears that g++ and the Sun compiler deduce T as const int.
One way or the other, I think the standard should be clarified to specify how cases like this should be handled.
Notes from October 2002 meeting:
There was consensus on having the deduced type be "int" in the above.
Proposed resolution (October 2002):
Add to the end of 14.8.2.3 temp.deduct.conv (following paragraph 3):
When the deduction process requires a qualification conversion for a pointer or pointer to member type as described above, the following process is used to determine the deduced template argument values:
If A is a type cv1,0 pointer to ... cv1,n-1 pointer to cv1,n T1
and P is a type cv1,0 pointer to ... cv1,n-1 pointer to cv1,n T2
The cv-unqualified T1 and T2 are used as the types of A and P respectively.
[Example:
struct A { template <class T> operator T***(); }; A a; const int * const * const * p1 = a; // T is deduced as int, not const int-- end example]
In discussing issue 197, the question arose as to whether the handling of fundamental types in argument-dependent lookup is actually what is desired. This question needs further discussion.
Paragraph 7 of 3.4.5 basic.lookup.classref says,
If the id-expression is a conversion-function-id, its conversion-type-id shall denote the same type in both the context in which the entire postfix-expression occurs and in the context of the class of the object expression (or the class pointed to by the pointer expression).Does this mean that the following example is ill-formed?
struct A { operator int(); } a;
void foo() {
typedef int T;
a.operator T(); // 1) error T is not found in the context
// of the class of the object expression?
}
The second bullet in paragraph 1 of
3.4.3.1
class.qual
says,
a conversion-type-id of an operator-function-id is looked up both in the scope of the class and in the context in which the entire postfix-expression occurs and shall refer to the same type in both contextsHow about:
struct A { typedef int T; operator T(); };
struct B : A { operator T(); } b;
void foo() {
b.A::operator T(); // 2) error T is not found in the context
// of the postfix-expression?
}
Is this interpretation correct? Or was the intent for
this to be an error only if
T was found in both scopes and referred to different entities?
If the intent was for these to be errors, how do these rules apply to template arguments?
template <class T1> struct A { operator T1(); }
template <class T2> struct B : A<T2> {
operator T2();
void foo() {
T2 a = A<T2>::operator T2(); // 3) error? when instantiated T2 is not
// found in the scope of the class
T2 b = ((A<T2>*)this)->operator T2(); // 4) error when instantiated?
}
}
(Note bullets 2 and 3 in paragraph 1 of 3.4.3.1 class.qual refer to postfix-expression. It would be better to use qualified-id in both cases.)
Erwin Unruh: The intent was that you look in both contexts. If you find it only once, that's the symbol. If you find it in both, both symbols must be "the same" in some respect. (If you don't find it, its an error).
Mike Miller: What's not clear to me in these examples is whether what is being looked up is T or int. Clearly the T has to be looked up somehow, but the "name" of a conversion function clearly involves the base (non-typedefed) type, not typedefs that might be used in a definition or reference (cf 3 basic paragraph 7 and 12.3 class.conv paragraph 5). (This is true even for types that must be written using typedefs because of the limited syntax in conversion-type-ids — e.g., the "name" of the conversion function in the following example
typedef void (*pf)();
struct S {
operator pf();
};
is S::operator void(*)(), even though you can't write its name
directly.)
My guess is that this means that in each scope you look up the type named in the reference and form the canonical operator name; if the name used in the reference isn't found in one or the other scope, the canonical name constructed from the other scope is used. These names must be identical, and the conversion-type-id in the canonical operator name must not denote different types in the two scopes (i.e., the type might not be found in one or the other scope, but if it's found in both, they must be the same type).
I think this is all very vague in the current wording.
I believe this program is invalid:
struct A {
};
struct C {
struct A {};
void f ();
};
void C::f () {
::A *a;
a->~A ();
}
The problem is that 3.4.5
basic.lookup.classref says that you have to look
up A in both the context of the pointed-to-type (i.e.,
::A), and
in the context of the postfix-expression (i.e., the body of C::f), and
that if the name is found in both places it must name the same type in
both places.
The EDG front end does not issue an error about this program, though.
Am I reading the standardese incorrectly?
John Spicer: I think you are reading it correctly. I think I've been hoping that this would get changed. Unlike other dual lookup contexts, this is one in which the compiler already knows the right answer (the type must match that of the left hand of the -> operator). So I think that if either of the types found matches the one required, it should be sufficient. You can't say a->~::A(), which means you are forced to say a->::A::~A(), which disables the virtual mechanism. So you would have to do something like create a local tyepdef for the desired type.
See also issue 244.
Standard is clear on behaviour of default allocation/deallocation functions. However, it is surpisingly vague on requirements to the behaviour of user-defined deallocation function and an interaction between delete-expression and deallocation function. This caused a heated argument on fido7.su.c-cpp newsgroup.
Resume:
It is not clear if user-supplied deallocation function is called from delete-expr when the operand of delete-expr is the null pointer (5.3.5 expr.delete). If it is, standard does not specify what user-supplied deallocation function shall do with the null pointer operand (18.4.1 lib.new.delete). Instead, Standard uses the term "has no effect", which meaning is too vague in context given (5.3.5 expr.delete).
Description:
Consider statements
char* p= 0; //result of failed non-throwing ::new char[] ::delete[] p;Argument passed to delete-expression is valid - it is the result of a call to the non-throwing version of ::new, which has been failed. 5.3.5 expr.delete paragraph 1 explicitly prohibit us to pass 0 without having the ::new failure.
Standard does NOT specify whether user-defined deallocation function should be called in this case, or not.
Specifically, standard says in 5.3.5 expr.delete paragraph 2:
...if the value of the operand of delete is the null pointer the operation has no effect.Standard doesn't specify term "has no effect". It is not clear from this context, whether the called deallocation function is required to have no effect, or delete-expression shall not call the deallocation function.
Furthermore, in para 4 standard says on default deallocation function:
If the delete-expression calls the implementation deallocation function (3.7.3.2 basic.stc.dynamic.deallocation), if the operand of the delete expression is not the null pointer constant, ...Why it is so specific on interaction of default deallocation function and delete-expr?
If "has no effect" is a requirement to the deallocation function, then it should be stated in 3.7.3.2 basic.stc.dynamic.deallocation, or in 18.4.1.1 lib.new.delete.single and 18.4.1.2 lib.new.delete.array, and it should be stated explicitly.
Furthermore, standard does NOT specify what actions shall be performed by user-supplied deallocation function if NULL is given (18.4.1.1 lib.new.delete.single paragraph 12):
Required behaviour: accept a value of ptr that is null or that was returned by an earlier call to the default operator new(std::size_t) or operator new(std::size_t, const std::nothrow_t&).
The same corresponds to ::delete[] case.
Expected solution:
Notes from October 2002 meeting:
We believe that study of 18.4.1.1 lib.new.delete.single paragraphs 12 and 13, 18.4.1.2 lib.new.delete.array paragraphs 11 and 12, and 3.7.3.2 basic.stc.dynamic.deallocation paragraph 3 shows that the system-provided operator delete functions must accept a null pointer and ignore it. Those sections also show that a user-written replacement for the system-provided operator delete functions must accept a null pointer. There is no requirement that such functions ignore a null pointer, which is okay -- perhaps the reason for replacing the system-provided functions is to do something special with null pointer values (e.g., log such calls and return).
We believe that the standard should not require an implementation to call a delete function with a null pointer, but it must allow that. For the system-provided delete functions or replacements thereof, the standard already makes it clear that the delete function must accept a null pointer. For class-specific delete functions, we believe the standard should require that such functions accept a null pointer, though it should not mandate what they do with null pointers.
5.3.5 expr.delete needs to be updated to say that it is unspecified whether or not the operator delete function is called with a null pointer, and 3.7.3.2 basic.stc.dynamic.deallocation needs to be updated to say that any deallocation function must accept a null pointer.
Sent in by David Abrahams:
Yes, and to add to this tangent, 3.9.1 basic.fundamental paragraph 1 states "Plain char, signed char, and unsigned char are three distinct types." Strangely, 3.9 basic.types paragraph 2 talks about how "... the underlying bytes 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." I guess there's no requirement that this copying work properly with signed chars!
Notes from October 2002 meeting:
We should do whatever C99 does. 6.5p6 of the C99 standard says "array of character type", and "character type" includes signed char (6.2.5p15), and 6.5p7 says "character type". But see also 6.2.6.1p4, which mentions (only) an array of unsigned char.
I believe that the committee has neglected to take into account one of the differences between C and C++ when defining sequence points. As an example, consider
(a += b) += c;
where a, b, and c all have type int. I believe that this expression has undefined behavior, even though it is well-formed. It is not well-formed in C, because += returns an rvalue there. The reason for the undefined behavior is that it modifies the value of `a' twice between sequence points.
Expressions such as this one are sometimes genuinely useful. Of course, we could write this particular example as
a += b; a += c;
but what about
void scale(double* p, int n, double x, double y) {
for (int i = 0; i < n; ++i) {
(p[i] *= x) += y;
}
}
All of the potential rewrites involve multiply-evaluating p[i] or unobvious circumlocations like creating references to the array element.
One way to deal with this issue would be to include built-in operators in the rule that puts a sequence point between evaluating a function's arguments and evaluating the function itself. However, that might be overkill: I see no reason to require that in
x[i++] = y;
the contents of `i' must be incremented before the assignment.
A less stringent alternative might be to say that when a built-in operator yields an lvalue, the implementation shall not subsequently change the value of that object as a consequence of that operator.
I find it hard to imagine an implementation that does not do this already. Am I wrong? Is there any implementation out there that does not `do the right thing' already for (a += b) += c?
5.17 expr.ass paragraph 1 says,
The result of the assignment operation is the value stored in the left operand after the assignment has taken place; the result is an lvalue.
What is the normative effect of the words "after the assignment has taken place"? I think that phrase ought to mean that in addition to whatever constraints the rules about sequence points might impose on the implementation, assignment operators on built-in types have the additional constraint that they must store the left-hand side's new value before returning a reference to that object as their result.
One could argue that as the C++ standard currently stands, the effect of x = y = 0; is undefined. The reason is that it both fetches and stores the value of y, and does not fetch the value of y in order to compute its new value.
I'm suggesting that the phrase "after the assignment has taken place" should be read as constraining the implementation to set y to 0 before yielding the value of y as the result of the subexpression y = 0.
Francis Glassborow:
My understanding is that for a single variable:
It is the 3) that is often ignored because in practice the compiler hardly ever codes for the read because it already has that value but in complicated evaluations with a shortage of registers, that is not always the case. Without getting too close to the hardware, I think we both know that a read too close to a write can be problematical on some hardware.
So, in x = y = 0;, the implementation must NOT fetch a value from y, instead it has to "know" what that value will be (easy because it has just computed that in order to know what it must, at some time, store in y). From this I deduce that computing the lvalue (to know where to store) and the rvalue to know what is stored are two entirely independent actions that can occur in any order commensurate with the overall requirements that both operands for an operator be evaluated before the operator is.
Erwin Unruh:
C distinguishes between the resulting value of an assignment and putting the value in store. So in C a compiler might implement the statement x=y=0; either as x=0;y=0; or as y=0;x=0; In C the statement (x += 5) += 7; is not allowed because the first += yields an rvalue which is not allowed as left operand to +=. So in C an assignment is not a sequence of write/read because the result is not really "read".
In C++ we decided to make the result of assignment an lvalue. In this case we do not have the option to specify the "value" of the result. That is just the variable itself (or its address in a different view). So in C++, strictly speaking, the statement x=y=0; must be implemented as y=0;x=y; which makes a big difference if y is declared volatile.
Furthermore, I think undefined behaviour should not be the result of a single mentioning of a variable within an expression. So the statement (x +=5) += 7; should NOT have undefined behaviour.
In my view the semantics could be:
Jerry Schwarz:
My recollection is different from Erwin's. I am confident that the intention when we decided to make assignments lvalues was not to change the semantics of evaluation of assignments. The semantics was supposed to remain the same as C's.
Ervin seems to assume that because assignments are lvalues, an assignment's value must be determined by a read of the location. But that was definitely not our intention. As he notes this has a significant impact on the semantics of assignment to a volatile variable. If Erwin's interpretation were correct we would have no way to write a volatile variable without also reading it.
Lawrence Crowl:
For x=y=0, lvalue semantics implies an lvalue to rvalue conversion on the result of y=0, which in turn implies a read. If y is volatile, lvalue semantics implies both a read and a write on y.
The standard apparently doesn't state whether there is a value dependence of the lvalue result on the completion of the assignment. Such a statement in the standard would solve the non-volatile C compatibility issue, and would be consistent with a user-implemented operator=.
Another possible approach is to state that primitive assignment operators have two results, an lvalue and a corresponding "after-store" rvalue. The rvalue result would be used when an rvalue is required, while the lvalue result would be used when an lvalue is required. However, this semantics is unsupportable for user-defined assignment operators, or at least inconsistent with all implementations that I know of. I would not enjoy trying to write such two-faced semantics.
Erwin Unruh:
The intent was for assignments to behave the same as in C. Unfortunately the change of the result to lvalue did not keep that. An "lvalue of type int" has no "int" value! So there is a difference between intent and the standard's wording.
So we have one of several choices:
I think the last one has the least impact on existing programs, but it is an ugly solution.
Andrew Koenig:
Whatever we may have intended, I do not think that there is any clean way of making
volatile int v;
int i;
i = v = 42;
have the same semantics in C++ as it does in C. Like it or not, the
subexpression v = 42 has the type ``reference to volatile int,''
so if this statement has any meaning at all, the meaning must be to store 42
in v and then fetch the value of v to assign it to i.
Indeed, if v is volatile, I cannot imagine a conscientious programmer writing a statement such as this one. Instead, I would expect to see
v = 42;
i = v;
if the intent is to store 42 in v and then fetch the (possibly
changed) value of v, or
v = 42;
i = 42;
if the intent is to store 42 in both v and i.
What I do want is to ensure that expressions such as ``i = v = 42'' have well-defined semantics, as well as expressions such as (i = v) = 42 or, more realistically, (i += v) += 42 .
I wonder if the following resolution is sufficient:
Append to 5.17 expr.ass paragraph 1:
There is a sequence point between assigning the new value to the left operand and yielding the result of the assignment expression.
I believe that this proposal achieves my desired effect of not constraining when j is incremented in x[j++] = y, because I don't think there is a constraint on the relative order of incrementing j and executing the assignment. However, I do think it allows expressions such as (i += v) += 42, although with different semantics from C if v is volatile.
Notes on 10/01 meeting:
There was agreement that adding a sequence point is probably the right solution.
Notes from the 4/02 meeting:
The working group reaffirmed the sequence-point solution, but we will look for any counter-examples where efficiency would be harmed.
For drafting, we note that ++x is defined in 5.3.2 expr.pre.incr as equivalent to x+=1 and is therefore affected by this change. x++ is not affected. Also, we should update any list of all sequence points.
I have found what looks like a bug in clause 5 expr, paragraph 4:
Between the previous and next sequence point a scalar object shall
have its stored value modified at most once by the evaluation of an
expression. Furthermore, the prior value shall be accessed only to
determine the value to be stored. The requirements of this
paragraph shall be met for each allowable ordering of the
subexpressions of a full expression; otherwise the behavior is
undefined. Example:
i = v[i++]; // the behavior is unspecified
i = 7, i++, i++; // i becomes 9
i = ++i + 1; // the behavior is unspecified
i = i + 1; // the value of i is incremented
--end example]
So which is it, unspecified or undefined?
Notes from October 2002 meeting:
We should find out what C99 says and do the same thing.
The example below is ambiguous.
struct A{
struct B{};
};
A::B C();
namespace B{
A C();
}
struct Test {
friend A::B ::C();
};
Here, it is not clear whether the friend declaration denotes
A B::C() or A::B C(), yet the standard does not resolve this
ambiguity.
The ambiguity arises since both the simple-type-specifier (7.1.5.2 dcl.type.simple paragra 1) and an init-declararator (8 dcl.decl paragraph 1) contain an optional :: and an optional nested-name-specifier (5.1 expr.prim paragraph 1). Therefore, two different ways to analyse this code are possible:
simple-type-specifier = A::Bor
init-declarator = ::C()
simple-declaration = friend A::B ::C();
simple-type-specifier = ASince it is a friend declaration, the init-declarator may be qualified, and start with a global scope.
init-declarator = ::B::C()
simple-declaration = friend A ::B::C();
Suggested Resolution: In the definition of nested-name-specifier, add a sentence saying that a :: token immediately following a nested-name-specifier is always considered as part of the nested-name-specifier. Under this interpretation, the example is ill-formed, and should be corrected as either
friend A (::B::C)(); //or
friend A::B (::C)();
An alternate suggestion — changing 7.1 dcl.spec to say that
The longest sequence of tokens that could possibly be a type name is taken as the decl-specifier-seq of a declaration.
— is undesirable because it would make the example well-formed rather than requiring the user to disambiguate the declaration explicitly.
Proposed resolution (04/01):
(See below for problem with this, from 10/01 meeting.)
In 5.1 expr.prim paragraph 7,
Before the grammar for qualified-id, start a new paragraph 7a with the text
A qualified-id is an id-expression that contains the scope resolution operator ::.
Following the grammar fragment, insert the following:
The longest sequence of tokens that could form a qualified-id constitutes a single qualified-id. [Example:
// classes C, D; functions F, G, namespace N; non-class type T friend C ::D::F(); // ill-formed, means friend (C::D::F)(); friend C (::D::F)(); // well-formed friend N::T ::G(); // ill-formed, means friend (N::T::G)(); friend N::T (::G)(); // well-formed—end example]
Start a new paragraph 7b following the example.
(This resolution depends on that of issue 215.)
Notes from 10/01 meeting:
It was pointed out that the proposed resolution does not deal with cases like X::Y where X is a type but not a class type. The working group reaffirmed its decision that the disambiguation should be syntactic only, i.e., it should depend only on whether or not the name is a type.
Jason Merrill :At the Seattle meeting, I suggested that a solution might be to change the class-or-namespace-name in the nested-name-specifier rule to just be "identifier"; there was some resistance to this idea. FWIW, I've tried this in g++. I had to revise the idea so that only the second and subsequent names were open to being any identifier, but that seems to work just fine.
So, instead of
it would be
Or some equivalent but right-associative formulation, if people feel that's important, but it seems irrelevant to me.
Clark Nelson :
Personally, I prefer the left-associative rule. I think it makes it easier to understand. I was thinking about this production a lot at the meeting, considering also some issues related to 301. My formulation was getting kind of ugly, but with a left-associative rule, it gets a lot nicer.
Your proposal isn't complete, however, as it doesn't allow template arguments without an explicit template keyword. You probably want to add an alternative for:
There is admittedly overlap between this alternative and
but I think they're both necessary.
Notes from the 4/02 meeting:
The changes look good. Clark Nelson will merge the two proposals to produce a single proposed resolution.
The following translation unit appears to be well-formed.
int x[true?throw 4:5];
According to 5.19 expr.const, this appears to be an integral constant expression: it is a conditional expression, involves only literals, and no assignment, increment, decrement, function-call, or comma operators. However, if this is well-formed, the standard gives no meaning to this declaration, since the array bound (8.3.4 dcl.array paragraph 1) cannot be computed.
I believe the defect is that throw expressions should also be banned from constant expressions.
Notes from October 2002 meeting:
We should also check on new and delete.
7.3.1.2 namespace.memdef paragraph 3 says,
If a friend declaration in a non-local class first declares a class or function the friend class or function is a member of the innermost enclosing namespace... 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.It is not clear from this passage how to determine whether an entity is "first declared" in a friend declaration. One question is whether a using-declaration influences this determination. For instance:
void foo();
namespace A{
using ::foo;
class X{
friend void foo();
};
}
Is the friend declaration a reference to ::foo or
a different foo?
Part of the question involves determining the meaning of the word "synonym" in 7.3.3 namespace.udecl paragraph 1:
A using-declaration introduces a name into the declarative region in which the using-declaration appears. That name is a synonym for the name of some entity declared elsewhere.Is "using ::foo;" the declaration of a function or not?
More generally, the question is how to describe the lookup of the name in a friend declaration.
John Spicer: When a declaration specifies an unqualified name, that name is declared, not looked up. There is a mechanism in which that declaration is linked to a prior declaration, but that mechanism is not, in my opinion, via normal name lookup. So, the friend always declares a member of the nearest namespace scope regardless of how that name may or may not already be declared there.
Mike Miller: 3.4.1 basic.lookup.unqual paragraph 7 says:
A name used in the definition of a class X outside of a member function body or nested class definition shall be declared in one of the following ways:... [Note: when looking for a prior declaration of a class or function introduced by a friend declaration, scopes outside of the innermost enclosing namespace scope are not considered.]The presence of this note certainly implies that this paragraph describes the lookup of names in friend declarations.
John Spicer: It most certainly does not. If that section described the friend lookup it would yield the incorrect results for the friend declarations of f and g below. I don't know why that note is there, but it can't be taken to mean that that is how the friend lookup is done.
void f(){}
void g(){}
class B {
void g();
};
class A : public B {
void f();
friend void f(); // ::f not A::f
friend void g(); // ::g not B::g
};
Mike Miller: If so, the lookups for friend functions and classes behave differently. Consider the example in 3.4.4 basic.lookup.elab paragraph 3:
struct Base {
struct Data; // OK: declares nested Data
friend class Data; // OK: nested Data is a friend
};
If the friend declaration is not a reference to ::foo, there is a related but separate question: does the friend declaration introduce a conflicting (albeit "invisible") declaration into namespace A, or is it simply a reference to an as-yet undeclared (and, in this instance, undeclarable) A::foo? Another part of the example in 3.4.4 basic.lookup.elab paragraph 3 is related:
struct Data {
friend struct Glob; // OK: Refers to (as yet) undeclared Glob
// at global scope.
};
John Spicer: You can't refer to something that has not yet been declared. The friend is a declaration of Glob, it just happens to declare it in a such a way that its name cannot be used until it is redeclared.
(A somewhat similar question has been raised in connection with issue 36. Consider:
namespace N {
struct S { };
}
using N::S;
struct S; // legal?
According to 9.1 class.name paragraph 2,
A declaration consisting solely of class-key identifier ; is either a redeclaration of the name in the current scope or a forward declaration of the identifier as a class name.
Should the elaborated type declaration in this example be considered a redeclaration of N::S or an invalid forward declaration of a different class?)
(See also issues 95, 136, 139, 143, 165, and 166, as well as paper J16/00-0006 = WG21 N1229.)
Here's an interesting case:
int f;
namespace N {
extern "C" void f () {}
}
As far as I can tell, this is not precluded by the ODR section
(3.2
basic.def.odr)
or the extern "C" section (7.5
dcl.link).
However, I believe many compilers
do not do name mangling on variables and (more-or-less by definition)
on extern "C" functions. That means the variable and the function
in the above end up having the same name at link time. EDG's front
end, g++, and the Sun compiler all get essentially the same error,
which is a compile-time assembler-level error because of the
duplicate symbols (in other words, they fail to check for this, and the
assembler complains). MSVC++ 7 links the program without error,
though I'm not sure how it is interpreted.
Do we intend for this case to be valid? If not, is it a compile time error (required), or some sort of ODR violation (no diagnostic required)? If we do intend for it to be valid, are we forcing many implementations to break binary compatibility by requiring them to mangle variable names?
Personally, I favor a compile-time error, and an ODR prohibition on such things in separate translation units.
Notes from the 4/02 meeting:
The working group agreed with the proposal. We feel a diagnostic should be required for declarations within one translation unit. We also noted that if the variable in global scope in the above example were declared static we would still expect an error.
Relevant sections in the standard are 7.5 dcl.link paragraph 6 and 3.5 basic.link paragraph 9. We feel that the definition should be written such that the entities in conflict are not "the same entity" but merely not allowed together.
This case is nonstandard by 8.3 dcl.meaning paragraph 1 (there is a requirement that the specialization first be declared within the namespace before being defined outside of the namespace), but probably should be allowed:
namespace NS1 {
template<class T>
class CDoor {
public:
int mtd() { return 1; }
};
}
template<> int NS1::CDoor<char>::mtd()
{
return 0;
}
Notes from October 2002 meeting:
There was agreement that we wanted to allow this.
In 12.2 class.temporary paragraph 5, should binding a reference to the result of a "?" operation, each of whose branches is a temporary, extend both temporaries?
Here's an example:
const SFileName &C = noDir ? SFileName("abc") : SFileName("bcd");
Do the temporaries created by the SFileName conversions survive the end of the full expression?
Notes from 10/00 meeting:
Other problematic examples include cases where the temporary from one branch is a base class of the temporary from the other (i.e., where the implementation must remember which type of temporary must be destroyed), or where one branch is a temporary and the other is not. Similar questions also apply to the comma operator. The sense of the core language working group was that implementations should be required to support these kinds of code.
Static data members of template classes and of nested classes of template classes are not themselves templates but receive much the same treatment as template. For instance, 14 temp paragraph 1 says that templates are only "classes or functions" but implies that "a static data member of a class template or of a class nested within a class template" is defined using the template-declaration syntax.
There are many places in the clause, however, where static data members of one sort or another are overlooked. For instance, 14 temp paragraph 6 allows static data members of class templates to be declared with the export keyword. I would expect that static data members of (non-template) classes nested within class templates could also be exported, but they are not mentioned here.
Paragraph 8, however, overlooks static data members altogether and deals only with "templates" in defining the effect of the export keyword; there is no description of the semantics of defining a static data member of a template to be exported.
These are just two instances of a systematic problem. The entire clause needs to be examined to determine which statements about "templates" apply to static data members, and which statements about "static data members of class templates" also apply to static data members of non-template classes nested within class templates.
(The question also applies to member functions of template classes; see issue 217, where the phrase "non-template function" in 8.3.6 dcl.fct.default paragraph 4 is apparently intended not to include non-template member functions of template classes. See also issue 108, which would benefit from understanding nested classes of class templates as templates. Also, see issue 249, in which the usage of the phrase "member function template" is questioned.)
Notes from the 4/02 meeting:
Daveed Vandevoorde will propose appropriate terminology.
According to 14.1 temp.param paragraph 3, the following fragment is ill-formed:
template <class T>
class X{
friend void T::foo();
};
In the friend declaration, the T:: part is a nested-name-specifier (8 dcl.decl paragraph 4), and T must be a class-name or a namespace-name (5.1 expr.prim paragraph 7). However, according to 14.1 temp.param paragraph 3, it is only a type-name. The fragment should be well-formed, and instantiations of the template allowed as long as the actual template argument is a class which provides a function member foo. As a result of this defect, any usage of template parameters in nested names is ill-formed, e.g., in the example of 14.6 temp.res paragraph 2.
Notes from 04/00 meeting:
The discussion at the meeting revealed a self-contradiction in the current IS in the description of nested-name-specifiers. According to the grammar in 5.1 expr.prim paragraph 7, the components of a nested-name-specifier must be either class-names or namespace-names, i.e., the constraint is syntactic rather than semantic. On the other hand, 3.4.3 basic.lookup.qual paragraph 1 describes a semantic constraint: only object, function, and enumerator names are ignored in the lookup for the component, and the program is ill-formed if the lookup finds anything other than a class-name or namespace-name. It was generally agreed that the syntactic constraint should be eliminated, i.e., that the grammar ought to be changed not to use class-or-namespace-name.
A related point is the explicit prohibition of use of template parameters in elaborated-type-specifiers in 7.1.5.3 dcl.type.elab paragraph 2. This rule was the result of an explicit Committee decision and should not be unintentionally voided by the resolution of this issue.
Proposed resolution (04/01):
Change 5.1 expr.prim paragraph 7 and A.4 gram.expr from
to
This resolution depends on the resolutions for issues 245 (to change the name lookup rules in elaborated-type-specifiers to include all type-names) and 283 (to categorize template type-parameters as type-names).
Notes from 10/01 meeting:
There was some sentiment for going with simply identifier in front of the "::", and stronger sentiment for going with something with a more descriptive name if possible. See also issue 180.
The grammar for a template-name is:
That's not right; consider:
template <class T> T operator+(const T&, const T&);
template <> S operator+<S>(const S&, const S&);
This is ill-formed according to the standard, since operator+ is not a template-name.
Suggested resolution:
I think the right rule is
John Spicer adds that there's some question about whether conversion functions should be included, as they cannot have template argument lists.
Notes from 4/02 meeting:
If the change is made as a syntax change, we'll need a semantic restriction to avoid operator+<int> as a class. Clark Nelson will work on a compromise proposal -- not the minimal change to the syntax proposed, not the maximal change either.
The EDG front-end accepts:
template <typename T>
struct A {
template <typename U>
struct B {};
};
template <typename T>
struct C : public A<T>::template B<T> {
};
It rejects this code if the base-specifier is spelled A<T>::B<T>.
However, the grammar for a base-specifier does not allow the template keyword.
Suggested resolution:
It seems to me that a consistent approach to the solution that looks like it will be adopted for issue 180 (which deals with the typename keyword in similar contexts) would be to assume that B is a template if it is followed by a "<". After all, an expression cannot appear in this context.Notes from the 4/02 meeting:
We agreed that template must be allowed in this context. The syntax needs to be changed. We also opened the related issue 343.
Implementations differ in their treatment of the following code:
template <class T>
struct A {
typename T::X x;
};
template <class T>
struct B {
typedef T* X;
A<B> a;
};
int main ()
{
B<int> b;
}
Some implementations accept it. At least one rejects it because the instantiation of A<B<int> > requires that B<int> be complete, and it is not at the point at which A<B<int> > is being instantiated.
Erwin Unruh:
In my view the programm is ill-formed. My reasoning:
So each class needs the other to be complete.
The problem can be seen much easier if you replace the typedef with
typedef T (*X) [sizeof(B::a)];
Now you have a true recursion. The compiler cannot easily distinguish between a true recursion and a potential recursion.
John Spicer:
Using a class to form a qualified name does not require the class to be complete, it only requires that the named member already have been declared. In other words, this kind of usage is permitted:
class A {
typedef int B;
A::B ab;
};
In the same way, once B has been declared in A, it is also visible to any template that uses A through a template parameter.
The standard could be more clear in this regard, but there are two notes that make this point. Both 3.4.3.1 class.qual and 5.1 expr.prim paragraph 7 contain a note that says "a class member can be referred to using a qualified-id at any point in its potential scope (3.3.6 basic.scope.class)." A member's potential scope begins at its point of declaration.
In other words, a class has three states: incomplete, being completed, and complete. The standard permits a qualified name to be used once a name has been declared. The quotation of the notes about the potential scope was intended to support that.
So, in the original example, class A does not require the type of T to be complete, only that it have already declared a member X.
Bill Gibbons:
The template and non-template cases are different. In the non-template case the order in which the members become declared is clear. In the template case the members of the instantiation are conceptually all created at the same time. The standard does not say anything about trying to mimic the non-template case during the instantiation of a class template.
Mike Miller:
I think the relevant specification is 14.6.4.1 temp.point paragraph 3, dealing with the point of instantiation:
For a class template specialization... if the specialization is implicitly instantiated because it is referenced from within another template specialization, if the context from which the specialization is referenced depends on a template parameter, and if the specialization is not instantiated previous to the instantiation of the enclosing template, the point of instantiation is immediately before the point of instantiation of the enclosing template. Otherwise, the point of instantiation for such a specialization immediately precedes the namespace scope declaration or definition that refers to the specialization.
That means that the point of instantiation of A<B<int> > is before that of B<int>, not in the middle of B<int> after the declaration of B::X, and consequently a reference to B<int>::X from A<B<int> > is ill-formed.
To put it another way, I believe John's approach requires that there be an instantiation stack, with the results of partially-instantiated templates on the stack being available to instantiations above them. I don't think the Standard mandates that approach; as far as I can see, simply determining the implicit instantiations that need to be done, rewriting the definitions at their respective points of instantiation with parameters substituted (with appropriate "forward declarations" to allow for non-instantiating references), and compiling the result normally should be an acceptable implementation technique as well. That is, the implicit instantiation of the example (using, e.g., B_int to represent the generated name of the B<int> specialization) could be something like
struct B_int;
struct A_B_int {
B_int::X x; // error, incomplete type
};
struct B_int {
typedef int* X;
A_B_int a;
};
Notes from 10/01 meeting:
This was discussed at length. The consensus was that the template case should be treated the same as the non-template class case it terms of the order in which members get declared/defined and classes get completed.
Proposed resolution:
In 14.6.4.1 temp.point paragraph 3 change:
the point of instantiation is immediately before the point of instantiation of the enclosing template. Otherwise, the point of instantiation for such a specialization immediately precedes the namespace scope declaration or definition that refers to the specialization.
To:
the point of instantiation is the same as the point of instantiation of the enclosing template. Otherwise, the point of instantiation for such a specialization immediately precedes the nearest enclosing declaration. [Note: The point of instantiation is still at namespace scope but any declarations preceding the point of instantiation, even if not at namespace scope, are considered to have been seen.]
Add following paragraph 3:
If an implicitly instantiated class template specialization, class member specialization, or specialization of a class template references a class, class template specialization, class member specialization, or specialization of a class template containing a specialization reference that directly or indirectly caused the instantiation, the requirements of completeness and ordering of the class reference are applied in the context of the specialization reference.
and the following example
template <class T> struct A {
typename T::X x;
};
struct B {
typedef int X;
A<B> a;
};
template <class T> struct C {
typedef T* X;
A<C> a;
};
int main ()
{
C<int> c;
}
Notes from the October 2002 meeting:
This needs work. Moved back to drafting status.
The example in 14.6 temp.res paragraph 9 is incorrect, according to 14.6.4.2 temp.dep.candidate . The example reads,
void f(char);
template <class T> void g(T t)
{
f(1); // f(char);
f(T(1)); // dependent
f(t); // dependent
dd++; // not dependent
// error: declaration for dd not found
}
void f(int);
double dd;
void h()
{
g(2); // will cause one call of f(char) followed
// by two calls of f(int)
g('a'); // will cause three calls of f(char)
}
Since 14.6.4.2
temp.dep.candidate
says that
only Koenig lookup is done from the instantiation context, and since
3.4.2
basic.lookup.koenig
says that
fundamental types have no associated namespaces, either the example is
incorrect (and f(int) will never be called) or the
specification in 14.6.4.2
temp.dep.candidate
is incorrect.
Notes from 04/00 meeting:
The core working group agreed that the example as written is incorrect and should be reformulated to use a class type instead of a fundamental type. It was also decided to open a new issue dealing more generally with Koenig lookup and fundamental types.
(See also issues 213 and 225.)
The current definition of the C++ language speaks about nondeduced contexts only in terms of deducing template arguments from a type 14.8.2.4 temp.deduct.type paragraph 4. Those cases, however, don't seem to be the only ones when template argument deduction is not possible. The example below illustrates that:
namespace A {
enum ae { };
template<class R, class A>
int foo(ae, R(*)(A))
{ return 1; }
}
template<typename T>
void tfoo(T)
{ }
template<typename T>
int tfoo(T)
{ return 1; }
/*int tfoo(int)
{ return 1; }*/
int main()
{
A::ae a;
foo(a, &tfoo);
}
Here argument-dependent name lookup finds the function template 'A::foo' as a candidate function. None of the function template's function parameter types constitutes a nondeduced context as per 14.8.2.4 temp.deduct.type paragraph 4. And yet, quite clearly, argument deduction is not possible in this context. Furthermore it is not clear what a conforming implementation shall do when the definition of the non-template function '::tfoo' is uncommented.
Suggested resolution:
Add the following as a new paragraph immediately before paragraph 3 of 14.8.2.1 temp.deduct.call:
After the above transformations, in the event of P being a function type, a pointer to function type, or a pointer to member function type and the corresponding A designating a set of overloaded (member) functions with at least one of the (member) functions introduced by the use of a (member) function template name (13.4 over.over) or by the use of a conversion function template (14.8.2.3 temp.deduct.conv), the whole function call expression is considered to be a nondeduced context. [Example:
namespace A {
enum ae { };
template<class R, class A>
int foo(ae, R(*)(A))
{ return 1; }
}
template<typename T>
void tfoo(T)
{ }
template<typename T>
int tfoo(T)
{ return 1; }
int tfoo(int)
{ return 1; }
int main()
{
A::ae a;
foo(a, &tfoo); // ill-formed, the call is a nondeduced context
using A::foo;
foo<void,int>(a, &tfoo); // well-formed, the address of the spe-
// cialization 'void tfoo<int>(int)' is
// the second argument of the call
}
Notes from October 2002 meeting:
There was agreement that deduction should fail but it's still possible to get a result -- it's just not a "nondeduced context" in the sense of the standard.
The presence of a template in the overload set should not automatically disqualify the overload set.
The motivation for this issue is a desire to write portable programs which will work with any conforming implementation.
The C++ Standard (16.2 cpp.include) provides two forms of #include directives, with the <...> form being described (16.2 cpp.include paragraph 2) as "for a header", and the "..." form (16.2 cpp.include paragraph 3) as for "the source file" identified between the delimiters. When the standard uses the term "header", it often appears to be limiting the term to apply to the Standard Library headers only. Users of the standard almost always use the term "header" more broadly, to cover all #included source files, but particularly those containing interface declarations.
Headers, including source files, can be categorized according to their origin and usage:
Existing practice varies widely, but it is fairly easy to find users advocating:
Do any of the practices A, B, or C result in programs which can be rejected by a conforming implementation?
The first defect is that readers of the standard have not been able to reach consensus on the answers to the above question.
A second possible defect is that if A, B, or C can be rejected by a conforming implementation, then the standard should be changed because would mean there is a wide variance between the standard and existing practice.
Matt Austern: I really only see two positions:
I agree that the standard should clarify which of those two is the case (I imagine it'll hinge on finding one crucual sentence that either says "implementation defined" or "unspecified"), but from the standpoint of portability I don't see much difference between the two. I claim that, with either of those two interpretations, using #include <foo> is already nonportable.
(Of course, I claim that almost anything having to do with headers, including the #include "foo" form, is also nonportable. In practice there's wide variation in how compilers handle paths, especially relative paths.)
Beman Dawes: The whole issue can be resolved by replacing "header" with "header or source file" in 16.2 cpp.include paragraph 2. That will bring the standard into alignment with existing practice by both users and implementations. The "header and/or source file" wording is used at least three other places in the standard where otherwise there might be some confusion.
John Skaller: In light of Andrew Koenig's comments, this doesn't appear to be the case, since the mapping of include names to file names is implementation defined, and therefore source file inclusion cannot be made portable within the ISO C/C++ standards (since that provision obviously cannot be removed).
A possible idea is to create a binding standard, outside the C/C++ ISO Standards, which specifies not only the path lookup mechanism but also the translation from include names to file names. Clearly that is OS dependent, encoding dependent, etc, but there is no reason not to have a binding standard for Unix, Windows, etc, and specify these bindings in such a way that copying directories from one OS to the other can result in programs working on both OS's.
Andy Koenig: An easier solution might be to specify a (presumably unbounded, or bounded only by implementation capacity) collection of header-file names that every implementation must make it possible for programs to access somehow, without specifying exactly how.
Notes from October 2002 meeting:
This was discussed at some length. While there was widespread agreement that such inclusion is inherently implementation-dependent, we agreed to try to add wording that would make it clear that implementations are permitted (but not required) to allow inclusion of files using the <...> form of #include.
Section 1.3.10 defns.signature, definition of "signature" omits the function name as part of the signature. Since the name participates in overload resolution, shouldn't it be included in the definition? I didn't find a definition of signature in the ARM, but I might have missed it.
Fergus Henderson: I think so. In particular, 17.4.3.1.2 lib.global.names reserves certain "function signatures" for use by the implementation, which would be wrong unless the signature includes the name.
-2- Each global function signature declared with external linkage in a header is reserved to the implementation to designate that function signature with external linkage.
-5- Each function signature from the Standard C library declared with external linkage is reserved to the implementation for use as a function signature with both extern "C" and extern "C++" linkage, or as a name of namespace scope in the global namespace.
Other uses of the term "function signature" in the description of the standard library also seem to assume that it includes the name.
Does the Standard require that an uninitialized auto variable have a stable (albeit indeterminate) value? That is, does the Standard require that the following function return true?
bool f() {
unsigned char i; // not initialized
unsigned char j = i;
unsigned char k = i;
return j == k; // true iff "i" is stable
}
3.9.1
basic.fundamental
paragraph 1
requires that uninitialized unsigned char variables have a
valid value, so the initializations of j and k are
well-formed and required not to trap. The question here is whether
the value of i is allowed to change between those
initializations.
Mike Miller: 1.9 intro.execution paragraph 10 says,
An instance of each object with automatic storage duration (3.7.2 basic.stc.auto ) is associated with each entry into its block. Such an object exists and retains its last-stored value during the execution of the block and while the block is suspended...I think that the most reasonable way to read this is that the only thing that is allowed to change the value of an automatic (non-volatile?) value is a "store" operation in the abstract machine. There are no "store" operations to i between the initializations of j and k, so it must retain its original (indeterminate but valid) value, and the result of the program is well-defined.
The quibble, of course, is whether the wording "last-stored value" should be applied to a "never-stored" value. I think so, but others might differ.
Tom Plum: 7.1.5.1 dcl.type.cv paragraph 8 says,
[Note: volatile is a hint to the implementation to avoid aggressive optimization involving the object because the value of the object might be changed by means undetectable by an implementation. See 1.9 intro.execution for detailed semantics. In general, the semantics of volatile are intended to be the same in C++ as they are in C. ]>From this I would infer that non-volatile means "shall not be changed by means undetectable by an implementation"; that the compiler is entitled to safely cache accesses to non-volatile objects if it can prove that no "detectable" means can modify them; and that therefore i shall maintain the same value during the example above.
Nathan Myers: This also has practical code-generation consequences. If the uninitialized auto variable lives in a register, and its value is really unspecified, then until it is initialized that register can be used as a temporary. Each time it's "looked at" the variable has the value that last washed up in that register. After it's initialized it's "live" and cannot be used as a temporary any more, and your register pressure goes up a notch. Fixing the uninit'd value would make it "live" the first time it is (or might be) looked at, instead.
Mike Ball: I agree with this. I also believe that it was certainly never my intent that an uninitialized variable be stable, and I would have strongly argued against such a provision. Nathan has well stated the case. And I am quite certain that it would be disastrous for optimizers. To ensure it, the frontend would have to generate an initializer, because optimizers track not only the lifetimes of variables, but the lifetimes of values assigned to those variables. This would put C++ at a significant performance disadvantage compared to other languages. Not even Java went this route. Guaranteeing defined behavior for a very special case of a generally undefined operation seems unnecessary.
2.4 lex.pptoken paragraph 2 specifies that there are 5 categories of tokens in phases 3 to 6. With 2.12 lex.operators paragraph 1, it is unclear whether new is an identifier or a preprocessing-op-or-punc; likewise for delete. This is relevant to answer the question whether
#define delete foo
is a well-formed control-line, since that requires an identifier after the define token.
The nonterminals operator and punctuator in 2.6 lex.token are not defined. There is a definition of the nonterminal operator in 13.5 over.oper paragraph 1, but it is apparent that the two nonterminals are not the same: the latter includes keywords and multi-token operators and does not include the nonoverloadable operators mentioned in paragraph 3.
There is a definition of preprocessing-op-or-punc in 2.12 lex.operators , with the notation that
Each preprocessing-op-or-punc is converted to a single token in translation phase 7 (2.1).However, this list doesn't distinguish between operators and punctuators, it includes digraphs and keywords (can a given token be both a keyword and an operator at the same time?), etc.
Suggested resolution:
3 basic paragraph 8, while not incorrect, does not allow for linkage of operators and conversion functions. It says:
An identifier used in more than one translation unit can potentially refer to the same entity in these translation units depending on the linkage (3.5 basic.link) of the identifier specified in each translation unit.
The current description of unqualified name lookup in 3.4.1 basic.lookup.unqual paragraph 8 does not correctly handle complex cases of nesting. The Standard currently reads,
A name used in the definition of a function that is a member function (9.3) of a class X shall be declared in one of the following ways:In particular, this formulation does not handle the following example:
- before its use in the block in which it is used or in an enclosing block (6.3), or
- shall be a member of class X or be a member of a base class of X (10.2), or
- if X is a nested class of class Y (9.7), shall be a member of Y, or shall be a member of a base class of Y (this lookup applies in turn to Y's enclosing classes, starting with the innermost enclosing class), or
- if X is a local class (9.8) or is a nested class of a local class, before the definition of class X in a block enclosing the definition of class X, or
- if X is a member of namespace N, or is a nested class of a class that is a member of N, or is a local class or nested class within a local class of a function that is a member of N, before the member function definition, in namespace N or in one of N's enclosing namespaces.
struct outer {
static int i;
struct inner {
void f() {
struct local {
void g() {
i = 5;
}
};
}
};
};
Here the reference to i is from a member function of a local
class of a member function of a nested class. Nothing in the rules
allows outer::i to be found, although intuitively it should
be found.
A more comprehensive formulation is needed that allows traversal of any combination of blocks, local classes, and nested classes. Similarly, the final bullet needs to be augmented so that a function need not be a (direct) member of a namespace to allow searching that namespace when the reference is from a member function of a class local to that function. That is, the current rules do not allow the following example:
int j; // global namespace
struct S {
void f() {
struct local2 {
void g() {
j = 5;
}
};
}
};
The description of name lookup in the parameter-declaration-clause of member functions in 3.4.1 basic.lookup.unqual paragraphs 7-8 is flawed in at least two regards.
First, both paragraphs 7 and 8 apply to the parameter-declaration-clause of a member function definition and give different rules for the lookup. Paragraph 7 applies to names "used in the definition of a class X outside of a member function body...," which includes the parameter-declaration-clause of a member function definition, while paragraph 8 applies to names following the function's declarator-id (see the proposed resolution of issue 41), including the parameter-declaration-clause.
Second, paragraph 8 appears to apply to the type names used in the parameter-declaration-clause of a member function defined inside the class definition. That is, it appears to allow the following code, which was not the intent of the Committee:
struct S {
void f(I i) { }
typedef int I;
};
The original intent of the Committee when Koenig lookup was added to the language was apparently something like the following:
This approach is not reflected in the current wording of the Standard. Instead, the following appears to be the status quo:
John Spicer: Argument-dependent lookup was created to solve the problem of looking up function names within templates where you don't know which namespace to use because it may depend on the template argument types (and was then expanded to permit use in nontemplates). The original intent only concerned functions. The safest and simplest change is to simply clarify the existing wording to that effect.
Bill Gibbons: I see no reason why non-function declarations should not be found. It would take a special rule to exclude "function objects", as well as pointers to functions, from consideration. There is no such rule in the standard and I see no need for one.
There is also a problem with the wording in 3.4.2 basic.lookup.koenig paragraph 2:
If the ordinary unqualified lookup of the name finds the declaration of a class member function, the associated namespaces and classes are not considered.
This implies that if the ordinary lookup of the name finds the declaration of a data member which is a pointer to function or function object, argument-dependent lookup is still done.
My guess is that this is a mistake based on the incorrect assumption that finding any member other than a member function would be an error. I would just change "class member function" to "class member" in the quoted sentence.
Mike Miller: In light of the issue of "short-circuiting" Koenig lookup when normal lookup finds a non-function, perhaps it should be written as "...finds the declaration of a class member, an object, or a reference, the associated namespaces..."?
Andy Koenig: I think I have to weigh in on the side of extending argument-dependent lookup to include function objects and pointers to functions. I am particularly concerned about [function objects], because I think that programmers should be able to replace functions by function objects without changing the behavior of their programs in fundamental ways.
Bjarne Stroustrup: I don't think we could seriously argue from first principles that [argument-dependent lookup should find only function declarations]. In general, C++ name lookup is designed to be independent of type: First we find the name(s), then, we consider its(their) meaning. 3.4 basic.lookup states "The name lookup rules apply uniformly to all names ..." That is an important principle.
Thus, I consider text that speaks of "function call" instead of plain "call" or "application of ()" in the context of koenig lookup an accident of history. I find it hard to understand how 5.2.2 expr.call doesn't either disallow all occurrences of x(y) where x is a class object (that's clearly not intended) or requires koenig lookup for x independently of its type (by reference from 3.4 basic.lookup). I suspect that a clarification of 5.2.2 expr.call to mention function objects is in order. If the left-hand operand of () is a name, it should be looked up using koenig lookup.
John Spicer: This approach causes otherwise well-formed programs to be ill-formed, and it does so by making names visible that might be completely unknown to the author of the program. Using-directives already do this, but argument-dependent lookup is different. You only get names from using-directives if you actually use using-directives. You get names from argument-dependent lookup whether you want them or not.
This basically breaks an important reason for having namespaces. You are not supposed to need any knowledge of the names used by a namespace.
But this example breaks if argument-dependent lookup finds non-functions and if the translation unit includes the <list> header somewhere.
namespace my_ns {
struct A {};
void list(std::ostream&, A&);
void f() {
my_ns::A a;
list(cout, a);
}
}
This really makes namespaces of questionable value if you still need to avoid using the same name as an entity in another namespace to avoid problems like this.
Erwin Unruh: Before we really decide on this topic, we should have more analysis on the impact on programs. I would also like to see a paper on the possibility to overload functions with function surrogates (no, I won't write one). Since such an extension is bound to wait until the next official update, we should not preclude any outcome of the discussion.
I would like to have a change right now, which leaves open several outcomes later. I would like to say that:
Koenig lookup will find non-functions as well. If it finds a variable, the program is ill-formed. If the primary lookup finds a variable, Koenig lookup is done. If the result contains both functions and variables, the program is ill-formed. [Note: A future standard will assign semantics to such a program.]
I myself are not comfortable with this as a long-time result, but it prepares the ground for any of the following long term solutions:
The note is there to prevent compiler vendors to put their own extensions in here.
(See also issues 113 and 143.)
Notes from 04/00 meeting:
Although many agreed that there were valid concerns motivating a desire for Koenig lookup to find non-function declarations, there was also concern that supporting this capability would be more dangerous than helpful in the absence of overload resolution for mixed function and non-function declarations.
A straw poll of the group revealed 8 in favor of Koenig lookup finding functions and function templates only, while 3 supported the broader result.
Notes from the 10/01 meeting:
There was unanimous agreement on one less controversial point: if the normal lookup of the identifier finds a non-function, argument-dependent lookup should not be done.
On the larger issue, the primary point of consensus is that making this change is an extension, and therefore it should wait until the point at which we are considering extensions (which could be very soon). There was also consensus on the fact that the standard as it stands is not clear: some introductory text suggests that argument-dependent lookup finds only functions, but the more detailed text that describes the lookup does not have any such restriction.
It was also noted that some existing implementations (e.g., g++) do find some non-functions in some cases.
The issue at this point is whether we should (1) make a small change to make the standard clear (presumably in the direction of not finding the non-functions in the lookup), and revisit the issue later as an extension, or (2) leave the standard alone for now and make any changes only as part of considering the extension. A straw vote favored option (1) by a strong majority.
The last bullet of the second paragraph of section 3.4.2 basic.lookup.koenig says that:
If T is a template-id, its associated namespaces and classes are the namespace in which the template is defined; for member templates, the member template's class; the namespaces and classes associated with the types of the template arguments provided for template type parameters (excluding template template parameters); the namespaces in which any template template arguments are defined; and the classes in which any member templates used as template template arguments are defined.
The first problem with this wording is that it is misleading, since one cannot get such a function argument whose type would be a template-id. The bullet should be speaking about template specializations instead.
The second problem is owing to the use of the word "defined" in the phrases "are the namespace in which the template is defined", "in which any template template arguments are defined", and "as template template arguments are defined". The bullet should use the word "declared" instead, since scenarios like the one below are possible:
namespace A {
template<class T>
struct test {
template<class U>
struct mem_templ { };
};
// declaration in namespace 'A'
template<> template<>
struct test<int>::mem_templ<int>;
void foo(test<int>::mem_templ<int>&)
{ }
}
// definition in the global namespace
template<> template<>
struct A::test<int>::mem_templ<int> {
};
int main()
{
A::test<int>::mem_templ<int> inst;
// According to the current definition of 3.4.2
// foo is not found.
foo(inst);
}
In addition, the bullet doesn't make it clear whether a T which is a class template specialization must also be treated as a class type, i.e. if the contents of the second bullet of the second paragraph of section 3.4.2 basic.lookup.koenig.
must apply to it or not. The same stands for a T which is a function template specialization. This detail can make a difference in an example such as the one below:
- 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. [This wording is as updated by core issue 90.]
template<class T>
struct slist_iterator {
friend bool operator==(const slist_iterator& x, const slist_iterator& y)
{ return true; }
};
template<class T>
struct slist {
typedef slist_iterator<T> iterator;
iterator begin()
{ return iterator(); }
iterator end()
{ return iterator(); }
};
int main()
{
slist<int> my_list;
slist<int>::iterator mi1 = my_list.begin(), mi2 = my_list.end();
// Must the the friend function declaration
// bool operator==(const slist_iterator<int>&, const slist_iterator<int>&);
// be found through argument dependent lookup? I.e. is the specialization
// 'slist<int>' the associated class of the arguments 'mi1' and 'mi2'. If we
// apply only the contents of the last bullet of 3.4.2/2, then the type
// 'slist_iterator<int>' has no associated classes and the friend declaration
// is not found.
mi1 == mi2;
}
Suggested resolution:
Replace the last bullet of the second paragraph of section 3.4.2 basic.lookup.koenig
with
- If T is a template-id, its associated namespaces and classes are the namespace in which the template is defined; for member templates, the member template's class; the namespaces and classes associated with the types of the template arguments provided for template type parameters (excluding template template parameters); the namespaces in which any template template arguments are defined; and the classes in which any member templates used as template template arguments are defined.
- If T is a class template specialization, its associated namespaces and classes are those associated with T when T is regarded as a class type; the namespaces and classes associated with the types of the template arguments provided for template type parameters (excluding template template parameters); the namespaces in which the primary templates making template template arguments are declared; and the classes in which any primary member templates used as template template arguments are declared.
- If T is a function template specialization, its associated namespaces and classes are those associated with T when T is regarded as a function type; the namespaces and classes associated with the types of the template arguments provided for template type parameters (excluding template template parameters); the namespaces in which the primary templates making template template arguments are declared; and the classes in which any primary member templates used as template template arguments are declared.
Replace the second bullet of the second paragraph of section 3.4.2 basic.lookup.koenig
with
- 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 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 declared [Note: in case of any of the associated classes being a class template specialization, its associated namespace is acually the namespace containing the declaration of the primary class template of the class template specialization].
I believe the following code example should unambiguously call the member operator+. Am I right?
//--- some library header ---
//
namespace N1 {
template<class T> struct Base { };
template<class T> struct X {
struct Y : public Base<T> { // here's a member operator+
Y operator+( int _Off ) const { return Y(); }
};
Y f( unsigned i ) { return Y() + i; } // the "+" in question
};
}
//--- some user code ---
//
namespace N2 {
struct Z { };
template<typename T> // here's another operator+
int* operator+( T , unsigned ) { static int i ; return &i ; }
}
int main() {
N1::X< N2::Z > v;
v.f( 0 );
}
My expectation is that 3.4.2 basic.lookup.koenig would govern, specifically:
If the ordinary unqualified lookup of the name finds the declaration of a class member function, the associated namespaces and classes are not considered.So I think the member should hide the otherwise-better-matching one in the associated namespace. Here's what compilers do:
Agree with me and call the member operator+: Borland 5.5, Comeau 4.3.0.1, EDG 3.0.1, Metrowerks 8.0, MSVC 6.0
Disagree with me and try to call N2::operator+: gcc 2.95.3, 3.1.1, and 3.2; MSVC 7.0
Simple so far, but someone tells me that 13.3.1.2 over.match.oper muddies the waters. There, paragraph 10 summarizes that subclause:
[Note: the lookup rules for operators in expressions are different than the lookup rules for operator function names in a function call, ...In particular, consider the above call to "Y() + unsigned" and please help me step through 13.3.1.2 over.match.oper paragraph 3:
... for a binary operator @ with a left operand of a type whose cv-unqualified version is T1 and a right operand of a type whose cv-unqualified version is T2,OK so far, here @ is +, and T1 is N1::X::Y.
three sets of candidate functions, designated member candidates, non-member candidates and built-in candidates, are constructed as follows:[and later are union'd together to get the candidate list]
If T1 is a class type, the set of member candidates is the result of the qualified lookup of T1::operator@ (over.call.func); otherwise, the set of member candidates is empty.So there is one member candidate, N1::X::Y::operator+.
The set of non-member candidates is the result of the unqualified lookup of operator@ in the context of the expression according to the usual rules for name lookup in unqualified function calls (basic.lookup.koenig) except that all member functions are ignored.
*** This is the question: What does that last phrase mean? Does it mean:
a) first apply the usual ADL rules to generate a candidate list, then ignore any member functions in that list (this is what I believe and hope it means, and in particular it means that the presence of a member will suppress names that ADL would otherwise find in the associated namespaces); or
b) something else?
In short, does N2::operator+ make it into the candidate list? I think it shouldn't. Am I right?
John Spicer: I believe that the answer is sort-of "a" above. More specifically, the unqualified lookup consists of a "normal" unqualified lookup and ADL. ADL always deals with only namespace members, so the "ignore members functions" part must affect the normal lookup, which should ignore class members when searching for an operator.
I suspect that the difference between compilers may have to do with details of argument-dependent lookup. In the example given, the argument types are "N1::X<N2::Z>::Y" and "unsigned int". In order for N2::operator+ to be a candidate, N2 must be an associated namespace.
N1::X<N2::Z>::Y is a class type, so 3.4.2 basic.lookup.koenig says that its associated clases are its direct and indirect base classes, and its namespaces are the namespaces of those classes. So, its associated namespace is just N1.
3.4.2 basic.lookup.koenig also says:
If T is a template-id, its associated namespaces and classes are the namespace in which the template is defined; for member templates, the member template's class; the namespaces and classes associated with the types of the template arguments provided for template type parameters (excluding template template parameters); the namespaces in which any template template arguments are defined; and the classes in which any member templates used as template template arguments are defined. [Note: non-type template arguments do not contribute to the set of associated namespaces. ]First of all, there is a problem with the term "is a template-id". template-id is a syntactic constuct and you can't really talk about a type being a template-id. Presumably, this is intended to mean "If T is the type of a class template specialization ...". But does this apply to N1::X<N2::Z>::Y? Y is a class nested within a class template specialization. In addition, its base class is a class template specialization.
I think this raises two issues:
Consider this code:
struct A { int i; struct i {}; };
struct B { int i; struct i {}; };
struct D : public A, public B { using A::i; void f (); };
void D::f () { struct i x; }
I can't find anything in the standard that says definitively what this means. 7.3.3 namespace.udecl says that a using-declaration shall name "a member of a base class" -- but here we have two members, the data member A::i and the class A::i.
Personally, I'd find it more attractive if this code did not work. I'd like "using A::i" to mean "lookup A::i in the usual way and bind B::i to that", which would mean that while "i = 3" would be valid in D::f, "struct i x" would not be. However, if there were no A::i data member, then "A::i" would find the struct and the code in D::f would be valid.
John Spicer: I agree with you, but unfortunately the standard committee did not.
I remembered that this was discussed by the committee and that a resolution was adopted that was different than what I hoped for, but I had a hard time finding definitive wording in the standard.
I went back though my records and found the paper that proposed a resolution and the associated committee motion that adopted the proposed resolution The paper is N0905, and "option 1" from that paper was adopted at the Stockholm meeting in July of 1996. The resolution is that "using A::i" brings in everything named i from A.
3.4.3.2 namespace.qual paragraph 2 was modified to implement this resolution, but interestingly that only covers the namespace case and not the class case. I think the class case was overlooked when the wording was drafted. A core issue should be opened to make sure the class case is handled properly.
3.4.5 basic.lookup.classref paragraph 1 says,
In a class member access expression (5.2.5 expr.ref ), if the . or -> token is immediately followed by an identifier followed by a <, the identifier must be looked up to determine whether the < is the beginning of a template argument list (14.2 temp.names ) or a less-than operator. The identifier is first looked up in the class of the object expression. If the identifier is not found, it is then looked up in the context of the entire postfix-expression and shall name a class or function template.There do not seem to be any circumstances in which use of a non-member template function would be well-formed as the id-expression of a class member access expression.
The example in 3.4.5 basic.lookup.classref paragraph 4 is wrong (see 11.2 class.access.base paragraph 5; the cast to the naming class can't be done) and needs to be corrected. This was noted when the final version of the algorithm for issue 39 was checked against it.
Is this case valid? G++ compiles it.
namespace X {
namespace Y {
struct X {
void f()
{
using X::Y;
namespace Z = X::Y;
}
};
}
}
The relevant citation from the standard is 3.4.6 basic.lookup.udir: "When looking up a namespace-name in a using-directive or namespace-alias-definition, only namespace names are considered." This statement could reasonably be interpreted to apply only to the last element of a qualified name, and that's the way EDG and Microsoft seem to interpret it.
However, since a class can't contain a namespace, it seems to me that this interpretation is, shall we say, sub optimal. If the X qualifiers in the above example are interpreted as referring to the struct X, an error of some sort is inevitable, since there can be no namespace for the qualified name to refer to. G++ apparently interprets 3.4.6 basic.lookup.udir as applying to nested-name-specifiers in those contexts as well, which makes a valid interpretation of the test possible.
I'm thinking it might be worth tweaking the words in 3.4.6 basic.lookup.udir to basically mandate the more useful interpretation. Of course a person could argue that the difference would matter only to a perverse program. On the other hand, namespaces were invented specifically to enable the building of programs that would otherwise be considered perverse. Where name clashes are concerned, one man's perverse is another man's real world.
It is unclear to what extent entities without names match across translation units. For example,
struct S {
int :2;
enum { a, b, c } x;
static class {} *p;
};
If this declaration appears in multiple translation units, are all these members "the same" in each declaration?
A similar question can be asked about non-member declarations:
// Translation unit 1:
extern enum { d, e, f } y;
// Translation unit 2:
extern enum { d, e, f } y;
// Translation unit 3:
enum { d, e, f } y;
Is this valid C++? Is it valid C?
James Kanze: S::p cannot be defined, because to do so requires a type specifier and the type cannot be named. ::y is valid C because C only requires compatible, not identical, types. In C++, it appears that there is a new type in each declaration, so it would not be valid. This differs from S::x because the unnamed type is part of a named type — but I don't know where or if the Standard says that.
John Max Skaller: It's not valid C++, because the type is a synthesised, unique name for the enumeration type which differs across translation units, as if:
extern enum _synth1 { d,e,f} y;
..
extern enum _synth2 { d,e,f} y;
had been written.
However, within a class, the ODR implies the types are the same:
class X { enum { d } y; };
in two translation units ensures that the type of member y is the same: the two X's obey the ODR and so denote the same class, and it follows that there's only one member y and one type that it has.
(See also issues 132 and 216.)
The standard says that an unnamed class or enum definition can be given a "name for linkage purposes" through a typedef. E.g.,
typedef enum {} E;
extern E *p;
can appear in multiple translation units.
How about the following combination?
// Translation unit 1:
struct S;
extern S *q;
// Translation unit 2:
typedef struct {} S;
extern S *q;
Is this valid C++?
Also, if the answer is "yes", consider the following slight variant:
// Translation unit 1:
struct S {}; // <<-- class has definition
extern S *q;
// Translation unit 2:
typedef struct {} S;
extern S *q;
Is this a violation of the ODR because two definitions of type S consist of differing token sequences?
According to 3.5 basic.link paragraph 8, "A name with no linkage ... shall not be used to declare an entity with linkage." This would appear to rule out code such as:
typedef struct {
int i;
} *PT;
extern "C" void f(PT);
[likewise]
static enum { a } e;
which seems rather harmless to me.
See issue 132, which dealt with a closely related issue.
Andrei Iltchenko submitted the same issue via comp.std.c++ on 17 Dec 2001:
Paragraph 8 of Section 3.5 basic.link contains the following sentences: "A name with no linkage shall not be used to declare an entity with linkage. If a declaration uses a typedef name, it is the linkage of the type name to which the typedef refers that is considered."
The problem with this wording is that it doesn't cover cases where the type to which a typedef-name refers has no name. As a result it's not clear whether, for example, the following program is well-formed:
#include <vector>
int main()
{
enum { sz = 6u };
typedef int (* aptr_type)[sz];
typedef struct data {
int i, j;
} * elem_type;
std::vector<aptr_type> vec1;
std::vector<elem_type> vec2;
}
Suggested resolution:
My feeling is that the rules for whether or not a typedef-name used in a declaration shall be treated as having or not having linkage ought to be modelled after those for dependent types, which are explained in 14.6.2.1 temp.dep.type.
Add the following text at the end of Paragraph 8 of Section 3.5 basic.link and replace the following example:
In case of the type referred to by a typedef declaration not having a name,
the newly declared typedef-name has linkage if and only if its referred type
comprises no names of no linkage excluding local names that are eligible for
appearance in an integral constant-expression (5.19
expr.const).
[Note: if the referred
type contains a typedef-name that does not denote an unnamed class, the
linkage of that name is established by the recursive application of this
rule for the purposes of using typedef names in declarations.] [Example:
void f()
{
struct A { int x; }; // no linkage
extern A a; // ill-formed
typedef A Bl
extern B b; // ill-formed
enum { sz = 6u };
typedef int (* C)[sz]; // C has linkage because sz can
// appear in a constant expression
}
--end example.]
Additional issue (13 Jan 2002, from Andrei Iltchenko):
Paragraph 2 of Section 14.3.1 temp.arg.type is inaccurate and unnecessarily prohibits a few important cases; it says "A local type, a type with no linkage, an unnamed type or a type compounded from any of these types shall not be used as a template-argument for a template-parameter." The inaccuracy stems from the fact that it is not a type but its name that can have a linkage.
For example based on the current wording of 14.3.1 temp.arg.type, the following example is ill-formed.
#include <vector>
struct data {
int i, j;
};
int main()
{
enum { sz = 6u };
std::vector<int(*)[sz]> vec1; // The types 'int(*)[sz]' and 'data*'
std::vector<data*> vec2; // have no names and are thus illegal
// as template type arguments.
}
Suggested resolution:
Replace the whole second paragraph of Section 14.3.1 temp.arg.type with the following wording:
A type whose name does not have a linkage or a type compounded from any such
type shall not be used as a template-argument for a template-parameter. In
case of a type T used as a template type argument not having a name,
T
constitutes a valid template type argument if and only if the name of an
invented typedef declaration referring to T would have linkage;
see 3.5.
[Example:
template <class T> class X { /* ... */ };
void f()
{
struct S { /* ... */ };
enum { sz = 6u };
X<S> x3; // error: a type name with no linkage
// used as template-argument
X<S*> x4; // error: pointer to a type name with
// no linkage used as template-argument
X<int(*)[sz]> x5; // OK: since the name of typedef int
// (*pname)[sz] would have linkage
}
--end example] [Note: a template type argument may be an incomplete type
(3.9
basic.types).]
The following declarations are allowed within a translation unit:
struct S;
enum { S };
However, 3.5 basic.link paragraph 9 seems to say these two declarations cannot appear in two different translation units. That also would mean that the inclusion of a header containing the above in two different translation units is not valid C++.
I suspect this is an oversight and that users should be allowed to have the declarations above appear in different translation units. (It is a fairly common thing to do, I think.)
Mike Miller: I think you meant "enum E { S };" -- enumerators only have external linkage if the enumeration does (3.5 basic.link paragraph 4), and 3.5 basic.link paragraph 9 only applies to entities with external linkage.
I don't remember why enumerators were given linkage; I don't think it's necessary for mangling non-type template arguments. In any event, I can't think why cross-TU name collisions between enumerators and other entities would cause a problem, so I guess a change here would be okay. I can think of three changes that would have that effect:
Daveed Vandevoorde: I don't think any of these are sufficient in the sense that the problem isn't limited to enumerators. E.g.:
struct X; extern void X();shouldn't create cross-TU collisions either.
Mike Miller: So you're saying that cross-TU collisions should only be prohibited if both names denote entities of the same kind (both functions, both objects, both types, etc.), or if they are both references (regardless of what they refer to, presumably)?
Daveed Vandevoorde: Not exactly. Instead, I'm saying that if two entities (with external linkage) can coexist when they're both declared in the same translation unit (TU), then they should also be allowed to coexist when they're declared in two different translation units.
For example:
int i; void i(); // ErrorThis is an error within a TU, so I don't see a reason to make it valid across TUs.
However, "tag names" (class/struct/union/enum) can sometimes coexist with identically named entities (variables, functions & enumerators, but not namespaces, templates or type names).
3.5 basic.link paragraph 5 says (among other things):
A name with no linkage (notably, the name of a class or enumeration declared in a local scope (3.3.2 basic.scope.local)) shall not be used to declare an entity with linkage. If a declaration uses a typedef name, it is the linkage of the type name to which the typedef refers that is considered.
I would expect this to catch situations such as the following:
// File 1:
typedef struct {} *UP;
void f(UP) {}
// File 2:
typedef struct {} *UP; // Or: typedef struct {} U, *UP;
void f(UP);
The problem here is that most implementations must generate the same mangled name for "f" in two translation units. The quote from the standard above isn't quite clear, unfortunately: There is no type name to which the typedef refers.
A related situation is the following:
enum { no, yes } answer;
The variable "answer" is declared as having external linkage, but it is
declared
with an unnamed type. Section 3.5
basic.link
talks about the linkage of names, however,
and does therefore not prohibit this. There is no implementation issue
for most
compilers because they do not ordinarily mangle variable names, but I
believe
the intent was to allow that implementation technique.
Finally, these problems are much less relevant when declaring names with internal linkage. For example, I would expect there to be few problems with:
typedef struct {} *UP;
static void g(UP);
I recently tried to interpret 3.5 basic.link paragraph 8 with the assumption that types with no names have no linkage. Surprisingly, this resulted in many diagnostics on variable declarations (mostly like "answer" above).
I'm pretty sure the standard needs clarifying words in this matter, but which way should it go?
Is a compiler allowed to interleave constructor calls when performing dynamic initialization of nonlocal objects? What I mean by interleaving is: beginning to execute a particular constructor, then going off and doing something else, then going back to the original constructor. I can't find anything explicit about this in clause 3.6.2 basic.start.init.
I'll present a few different examples, some of which get a bit wild. But a lot of what this comes down to is exactly what the standard means when it talks about the order of initialization. If it says that some object x must be initialized before a particular event takes place, does that mean that x's constructor must be entered before that event, or does it mean that it must be exited before that event? If object x must be initialized before object y, does that mean that x's constructor must exit before y's constructor is entered?
(The answer to that question might just be common sense, but I couldn't find an answer in clause 3.6.2 basic.start.init. Actually, when I read 3.6.2 basic.start.init carefully, I find there are a lot of things I took for granted that aren't there.)
OK, so a few specific scenerios.
<runtime gunk>
<Enter A's constructor>
<Enter f>
<runtime gunk>
<Enter B's constructor>
<Enter f>
<Leave f>
<Leave B's constructor>
<Leave f>
<Leave A's constructor>
The implication of a 'yes' answer for users is that any function
called by a constructor, directly or indirectly, must be reentrant.At this point, you might be thinking we could avoid all of this nonsense by removing compilers' freedom to defer initialization until after the beginning of main(). I'd resist that, for two reasons. First, it would be a huge change to make after the standard has been out. Second, that freedom is necessary if we want to have support for dynamic libraries. I realize we don't yet say anything about dynamic libraries, but I'd hate to make decisions that would make such support even harder.
The C++ standard has inherited the definition of the 'exit' function more or less unchanged from ISO C.
However, when the 'exit' function is called, objects of static extent which have been initialised, will be destructed if their types posses a destructor.
In addition, the C++ standard has inherited the definition of the 'signal' function and its handlers from ISO C, also pretty much unchanged.
The C standard says that the only standard library functions that may be called while a signal handler is executing, are the functions 'abort', 'signal' and 'exit'.
This introduces a bit of a nasty turn, as it is not at all unusual for the destruction of static objects to have fairly complex destruction semantics, often associated with resource release. These quite commonly involve apparently simple actions such as calling 'fclose' for a FILE handle.
Having observed some very strange behaviour in a program recently which in handling a SIGTERM signal, called the 'exit' function as indicated by the C standard.
But unknown to the programmer, a library static object performed some complicated resource deallocation activities, and the program crashed.
The C++ standard says nothing about the interaction between signals, exit and static objects. My observations, was that in effect, because the destructor called a standard library function other than 'abort', 'exit' or 'signal', while transitively in the execution context of the signal handler, it was in fact non-compliant, and the behaviour was undefined anyway.
This is I believe a plausible judgement, but given the prevalence of this common programming technique, it seems to me that we need to say something a lot more positive about this interaction.
Curiously enough, the C standard fails to say anything about the analogous interaction with functions registered with 'atexit' ;-)
Proposed Resolution (10/98):
The current Committee Draft of the next version of the ISO C standard specifies that the only standard library function that may be called while a signal handler is executing is 'abort'. This would solve the above problem.
[This issue should remain open until it has been decided that the next version of the C++ standard will use the next version of the C standard as the basis for the behavior of 'signal'.]
There are several problems with 3.7 basic.stc:
3.7 basic.stc paragraph 2 says that "Static and automatic storage durations are associated with objects introduced by declarations (3.1 basic.def) and implicitly created by the implementation (12.2 class.temporary)."
In fact, objects "implicitly created by the implementation" are the temporaries described in (12.2 class.temporary), and have neither static nor automatic storage duration, but a totally different duration, described in 12.2 class.temporary.
3.7 basic.stc uses the expression "local object" in several places, without ever defining it. Presumably, what is meant is "an object declared at block scope", but this should be said explicitly.
In a recent discussion in comp.lang.c++.moderated, on poster interpreted "local objects" as including temporaries. This would require them to live until the end of the block in which they are created, which contradicts 12.2 class.temporary. If temporaries are covered by this section, and the statement in 3.7 basic.stc seems to suggest, and they aren't local objects, then they must have static storage duration, which isn't right either.
I propose adding a fourth storage duration to the list after 3.7 basic.stc paragraph 1:
And rewriting the second paragraph of this section as follows:
Temporary storage duration is associated with objects implicitly created by the implementation, and is described in 12.2 class.temporary. Static and automatic storage durations are associated with objects defined by declarations; in the following, an object defined by a declaration with block scope is a local object. The dynamic storage duration is associated with objects created by the operator new.
Steve Adamczyk: There may well be an issue here, but one should bear in mind the difference between storage duration and object lifetime. As far as I can see, there is no particular problem with temporaries having automatic or static storage duration, as appropriate. The point of 12.2 class.temporary is that they have an unusual object lifetime.
Notes from Ocrober 2002 meeting:
It might be desirable to shorten the storage duration of temporaries to allow reuse of them. The as-if rule allows some reuse, but such reuse requires analysis, including noting whether the addresses of such temporaries have been taken.
3.7.3.2 basic.stc.dynamic.deallocation paragraph 4 mentions that the effect of using an invalid pointer value is undefined. However, the standard never says what it means to 'use' a value.
There are a number of possible interpretations, but it appears that each of them leads to undesired conclusions:
int *x = new int(0); delete x; x = 0;into undefined behaviour. As this is a common idiom, this is clearly undesirable.
int *x = new int(0); delete x; x->~int();into undefined behaviour; according to 5.2.4 expr.pseudo, the variable x is 'evaluated' as part of evaluating the pseudo destructor call. This, in turn, would mean that all containers (23 lib.containers) of pointers show undefined behaviour, e.g. 23.2.2.3 lib.list.modifiers requires to invoke the destructor as part of the clear() method of the container.
If any other meaning was intended for 'using an expression', that meaning should be stated explicitly.
Following the definition in 9 class paragraph 4 the following is a valid POD (actually a POD-struct):
struct test
{
const int i;
};
The legality of PODs with const members is also implied by the text of 5.3.4 expr.new paragraph 15 bullet 1, sub-bullet 2 and 12.6.2 class.base.init paragraph 4 bullet 2.
3.9 basic.types paragraph 3 states that
For any POD type T, if two pointers to T point to distinct 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.
[Note: this text was changed by TC1, but the essential point stays the same.]
This implies that the following is required to work:
test obj1 = { 1 };
test obj2 = { 2 };
memcpy( &obj2, &obj1, sizeof(test) );
The memcpy of course changes the value of the const member, surely something that shouldn't be allowed.
Suggested resolution:
It is recommended that 3.9 basic.types paragraph 3 be reworded to exclude PODs which contain (directly or indirectly) members of const-qualified type.
3.9.1 basic.fundamental does not impose a requirement on the floating point types that there be an exact representation of the value zero. This omission is significant in 4.12 conv.bool paragraph 1, in which any non-zero value converts to the bool value true.
Suggested resolution: require that all floating point types have an exact representation of the value zero.
3.9.1 basic.fundamental paragraph 2 says that
There are four signed integer types: "signed char", "short int", "int", and "long int."
This would indicate that const int is not a signed integer type.
4.1 conv.lval paragraph 1 says,
If the object to which the lvalue refers is not an object of type T and is not an object of a type derived from T, or if the object is uninitialized, a program that necessitates this conversion has undefined behavior.
I think there are at least three related issues around this specification:
Presumably assigning a valid value to an uninitialized object allows it to participate in the lvalue-to-rvalue conversion without undefined behavior (otherwise the number of programs with defined behavior would be vanishingly small :-). However, the wording here just says "uninitialized" and doesn't mention assignment.
There's no exception made for unsigned char types. The wording in 3.9.1 basic.fundamental was carefully crafted to allow use of unsigned char to access uninitialized data so that memcpy and such could be written in C++ without undefined behavior, but this statement undermines that intent.
It's possible to get an uninitialized rvalue without invoking the lvalue-to-rvalue conversion. For instance:
struct A {
int i;
A() { } // no init of A::i
};
int j = A().i; // uninitialized rvalue
There doesn't appear to be anything in the current IS wording that says that this is undefined behavior. My guess is that we thought that in placing the restriction on use of uninitialized objects in the lvalue-to-rvalue conversion we were catching all possible cases, but we missed this one.
In light of the above, I think the discussion of uninitialized objects ought to be removed from 4.1 conv.lval paragraph 1. Instead, something like the following ought to be added to 3.9 basic.types paragraph 4 (which is where the concept of "value" is introduced):
Any use of an indeterminate value (5.3.4 expr.new, 8.5 dcl.init, 12.6.2 class.base.init) of any type other than char or unsigned char results in undefined behavior.
John Max Skaller:
A().i had better be an lvalue; the rules are wrong. Accessing a member of a structure requires it be converted to an lvalue, the above calculation is 'as if':
struct A {
int i;
A *get() { return this; }
};
int j = (*A().get()).i;
and you can see the bracketed expression is an lvalue.
A consequence is:
int &j= A().i; // OK, even if the temporary evaporates
j now refers to a 'destroyed' value. Any use of j is an error. But the binding at the time is valid.
Section 4.4 conv.qual covers the case of multi-level pointers, but does not appear to cover the case of pointers to arrays of pointers. The effect is that arrays are treated differently from simple scalar values.
Consider for example the following code: (from the thread "Pointer to array conversion question" begun in comp.lang.c++.moderated)
int main()
{
double *array2D[2][3];
double * (*array2DPtr1)[3] = array2D; // Legal
double * const (*array2DPtr2)[3] = array2DPtr1; // Legal
double const * const (*array2DPtr3)[3] = array2DPtr2; // Illegal
}
and compare this code with:-
int main()
{
double *array[2];
double * *ppd1 = array; // legal
double * const *ppd2 = ppd1; // legal
double const * const *ppd3 = ppd2; // certainly legal (4.4/4)
}
The problem appears to be that the pointed to types in example 1 are unrelated since nothing in the relevant section of the standard covers it - 4.4 conv.qual does not mention conversions of the form "cv array of N pointer to T" into "cv array of N pointer to cv T"
It appears that reinterpret_cast is the only way to perform the conversion.
Suggested resolution:
Artem Livshits proposed a resolution :-
"I suppose if the definition of "similar" pointer types in 4.4 conv.qual paragraph 4 was rewritten like this:
it would address the problem.T1 is cv1,0 P0 cv1,1 P1 ... cv1,n-1 Pn-1 cv1,n T
and
T2 is cv1,0 P0 cv1,1 P1 ... cv1,n-1 Pn-1 cv1,n T
where Pi is either a "pointer to" or a "pointer to an array of Ni"; besides P0 may be also a "reference to" or a "reference to an array of N0" (in the case of P0 of T2 being a reference, P0 of T1 may be nothing).
In fact I guess Pi in this notation may be also a "pointer to member", so 4.4 conv.qual/{4,5,6,7} would be nicely wrapped in one paragraph."
The descriptions of explicit (5.2.9 expr.static.cast paragraph 9) and implicit (4.11 conv.mem paragraph 2) pointer-to-member conversions differ in two significant ways:
(This situation cannot arise in an implicit pointer-to-member conversion where the source value is something like &X::f, since you can only implicitly convert from pointer-to-base-member to pointer-to-derived-member. However, if the source value is the result of an explicit "up-cast," the target type of the conversion might still not contain the member referred to by the source value.)
It is not clear what constraints are placed on a floating point implementation by the wording of the Standard. For instance, is an implementation permitted to generate a "fused multiply-add" instruction if the result would be different from what would be obtained by performing the operations separately? To what extent does the "as-if" rule allow the kinds of optimizations (e.g., loop unrolling) performed by FORTRAN compilers?
Martin O'Riordan: Having gone through all the relevant references in the IS, it is not conclusive that a call via a pointer to a virtual member function is polymorphic at all, and could legitimately be interpreted as being static.
Consider 5.2.2 expr.call paragraph 1:
The function called in a member function call is normally selected according to the static type of the object expression (clause 10 class.derived ), but if that function is virtual and is not specified using a qualified-id then the function actually called will be the final overrider (10.3 class.virtual ) of the selected function in the dynamic type of the object expression.Here it is quite specific that you get the polymorphic call only if you use the unqualified syntax. But, the address of a member function is "always" taken using the qualified syntax, which by inference would indicate that call with a PMF is static and not polymorphic! Not what was intended.
Yet other references such as 5.5 expr.mptr.oper paragraph 4:
If the dynamic type of the object does not contain the member to which the pointer refers, the behavior is undefined.indicate that the opposite may have been intended, by stating that it is the dynamic type and not the static type that matters. Also, 5.5 expr.mptr.oper paragraph 6:
If the result of .* or ->* is a function,
then that result can be used
only as the operand for the function
call operator (). [Example:
(ptr_to_obj->*ptr_to_mfct)(10);
calls the member function denoted by ptr_to_mfct
for the object pointed
to by ptr_to_obj. ]
which also implies that it is the object pointed to that determines both the
validity of the expression (the static type of 'ptr_to_obj'
may not have a
compatible function) and the implicit (polymorphic) meaning. Note too,
that this is stated in the non-normative example text.
Andy Sawyer: Assuming the resolution is what I've assumed it is for the last umpteen years (i.e. it does the polymorphic thing), then the follow on to that is "Should there also be a way of selecting the non-polymorphic behaviour"?
Mike Miller: It might be argued that the current wording of 5.2.2 expr.call paragraph 1 does give polymorphic behavior to simple calls via pointers to members. (There is no qualified-id in obj.*pmf, and the IS says that if the function is not specified using a qualified-id, the final overrider will be called.) However, it clearly says the wrong thing when the pointer-to-member itself is specified using a qualified-id (obj.*X::pmf).
Bill Gibbons: The phrase qualified-id in 5.2.2 expr.call paragraph 1 refers to the id-expression and not to the "pointer-to-member expression" earlier in the paragraph:
For a member function call, the postfix expression shall be an implicit (9.3.1 class.mfct.nonstatic , 9.4 class.static ) or explicit class member access (5.2.5 expr.ref ) whose id-expression is a function member name, or a pointer-to-member expression (5.5 expr.mptr.oper ) selecting a function member.
Mike Miller: To be clear, here's an example:
struct S {
virtual void f();
};
void (S::*pmf)();
void g(S* sp) {
sp->f(); // 1: polymorphic
sp->S::f(); // 2: non-polymorphic
(sp->S::f)(); // 3: non-polymorphic
(sp->*pmf)(); // 4: polymorphic
(sp->*&S::f)(); // 5: polymorphic
}
Notes from October 2002 meeting:
This was moved back to open for lack of a champion. Martin O'Riordan is not expected to be attending meetings.
The original proposed resolution for issue 160 included changing extended_type_info (5.2.8 expr.typeid paragraph 1, footnote 61) to std::extended_type_info. There was no consensus on whether this name ought to be part of namespace std or in a vendor-specific namespace, so the question was moved into a separate issue.
It is currently not permitted to cast directly between a pointer to function type and a pointer to object type. This conversion is not listed in 5.2.9 expr.static.cast and 5.2.10 expr.reinterpret.cast and thus requires a diagnostic to be issued. However, if a sufficiently long integral type exists (as is the case in many implementations), it is permitted to cast between pointer to function types and pointer to object types using that integral type as an intermediary.
In C the cast results in undefined behavior and thus does not require a diagnostic, and Unix C compilers generally do not issue one. This fact is used in the definition of the standard Unix function dlsym, which is declared to return void* but in fact may return either a pointer to a function or a pointer to an object. The fact that C++ compilers are required to issue a diagnostic is viewed as a "competitive disadvantage" for the language.
Suggested resolution: Add wording to 5.2.10 expr.reinterpret.cast allowing conversions between pointer to function and pointer to object types, if the implementation has an integral data type that can be used as an intermediary.
Several points were raised in opposition to this suggestion:
Martin O'Riordan suggested an alternative approach:
The advantage of this approach is that it would permit writing portable, well-defined programs involving such conversions. However, it breaks the current degree of compatibility between old and new casts, and it adds functionality to dynamic_cast which is not obviously related to its current meaning.
Notes from 04/00 meeting:
Andrew Koenig suggested yet another approach: specify that "no diagnostic is required" if the implementation supports the conversion.
Later note:
It was observed that conversion between function and data pointers is listed as a "common extension" in C99.
Notes on the 10/01 meeting:
It was decided that we want the conversion defined in such a way that it always exists but is always undefined (as opposed to existing only when the size relationship is appropriate, and being implementation-defined in that case). This would allow an implementation to issue an error at compile time if the conversion does not make sense.
Bill Gibbons notes that the definitions of the other similar casts are inconsistent in this regard. Perhaps they should be updated as well.
Split off from issue 315.
Incidentally, another thing that ought to be cleaned up is the inconsistent use of "indirection" and "dereference". We should pick one.
5.3.1 expr.unary.op paragraph 2 indicates that the type of an address-of-member expression reflects the class in which the member was declared rather than the class identified in the nested-name-specifier of the qualified-id. This treatment is unintuitive and can lead to strange code and unexpected results. For instance, in
struct B { int i; };
struct D1: B { };
struct D2: B { };
int (D1::* pmD1) = &D2::i; // NOT an error
More seriously, template argument deduction can give surprising
results:
struct A {
int i;
virtual void f() = 0;
};
struct B : A {
int j;
B() : j(5) {}
virtual void f();
};
struct C : B {
C() { j = 10; }
};
template <class T>
int DefaultValue( int (T::*m) ) {
return T().*m;
}
... DefaultValue( &B::i ) // Error: A is abstract
... DefaultValue( &C::j ) // returns 5, not 10.
Suggested resolution: 5.3.1 expr.unary.op should be changed to read,
If the member is a nonstatic member (perhaps by inheritance) of the class nominated by the nested-name-specifier of the qualified-id having type T, the type of the result is "pointer to member of class nested-name-specifier of type T."and the comment in the example should be changed to read,
// has type int B::*
Notes from 04/00 meeting:
The rationale for the current treatment is to permit the widest possible use to be made of a given address-of-member expression. Since a pointer-to-base-member can be implicitly converted to a pointer-to-derived-member, making the type of the expression a pointer-to-base-member allows the result to initialize or be assigned to either a pointer-to-base-member or a pointer-to-derived-member. Accepting this proposal would allow only the latter use.
Additional notes:
Another problematic example has been mentioned:
class Base {
public:
int func() const;
};
class Derived : public Base {
};
template<class T>
class Templ {
public:
template<class S>
Templ(S (T::*ptmf)() const);
};
void foo()
{
Templ<Derived> x(&Derived::func); // ill-formed
}
In this example, even though the conversion of &Derived::func to int (Derived::*)() const is permitted, the initialization of x cannot be done because template argument deduction for the constructor fails.
If the suggested resolution were adopted, the amount of code broken by the change might be reduced by adding an implicit conversion from pointer-to-derived-member to pointer-to-base-member for appropriate address-of-member expressions (not for arbitrary pointers to members, of course).
(See also issue 247.)
At least a couple of places in the IS state that indirection through a null pointer produces undefined behavior: 1.9 intro.execution paragraph 4 gives "dereferencing the null pointer" as an example of undefined behavior, and 8.3.2 dcl.ref paragraph 4 (in a note) uses this supposedly undefined behavior as justification for the nonexistence of "null references."
However, 5.3.1 expr.unary.op paragraph 1, which describes the unary "*" operator, does not say that the behavior is undefined if the operand is a null pointer, as one might expect. Furthermore, at least one passage gives dereferencing a null pointer well-defined behavior: 5.2.8 expr.typeid paragraph 2 says
If the lvalue expression is obtained by applying the unary * operator to a pointer and the pointer is a null pointer value (4.10 conv.ptr), the typeid expression throws the bad_typeid exception (18.5.3 lib.bad.typeid).
This is inconsistent and should be cleaned up.
Bill Gibbons:
At one point we agreed that dereferencing a null pointer was not undefined; only using the resulting value had undefined behavior.
For example:
char *p = 0;
char *q = &*p;
Similarly, dereferencing a pointer to the end of an array should be allowed as long as the value is not used:
char a[10];
char *b = &a[10]; // equivalent to "char *b = &*(a+10);"
Both cases come up often enough in real code that they should be allowed.
Mike Miller:
I can see the value in this, but it doesn't seem to be well reflected in the wording of the Standard. For instance, presumably *p above would have to be an lvalue in order to be the operand of "&", but the definition of "lvalue" in 3.10 basic.lval paragraph 2 says that "an lvalue refers to an object." What's the object in *p? If we were to allow this, we would need to augment the definition to include the result of dereferencing null and one-past-the-end-of-array.
Tom Plum:
Just to add one more recollection of the intent: I was very happy when (I thought) we decided that it was only the attempt to actually fetch a value that creates undefined behavior. The words which (I thought) were intended to clarify that are the first three sentences of the lvalue-to-rvalue conversion, 4.1 conv.lval:
An lvalue (3.10 basic.lval) of a non-function, non-array type T can be converted to an rvalue. If T is an incomplete type, a program that necessitates this conversion is ill-formed. If the object to which the lvalue refers is not an object of type T and is not an object of a type derived from T, or if the object is uninitialized, a program that necessitates this conversion has undefined behavior.
In other words, it is only the act of "fetching", of lvalue-to-rvalue conversion, that triggers the ill-formed or undefined behavior. Simply forming the lvalue expression, and then for example taking its address, does not trigger either of those errors. I described this approach to WG14 and it may have been incorporated into C 1999.
Mike Miller:
If we admit the possibility of null lvalues, as Tom is suggesting here, that significantly undercuts the rationale for prohibiting "null references" -- what is a reference, after all, but a named lvalue? If it's okay to create a null lvalue, as long as I don't invoke the lvalue-to-rvalue conversion on it, why shouldn't I be able to capture that null lvalue as a reference, with the same restrictions on its use?
I am not arguing in favor of null references. I don't want them in the language. What I am saying is that we need to think carefully about adopting the permissive approach of saying that it's all right to create null lvalues, as long as you don't use them in certain ways. If we do that, it will be very natural for people to question why they can't pass such an lvalue to a function, as long as the function doesn't do anything that is not permitted on a null lvalue.
If we want to allow &*(p=0), maybe we should change the definition of "&" to handle dereferenced null specially, just as typeid has special handling, rather than changing the definition of lvalue to include dereferenced nulls, and similarly for the array_end+1 case. It's not as general, but I think it might cause us fewer problems in the long run.
Requirements for the alignment of pointers returned by new-expressions are given in 5.3.4 expr.new paragraph 10:
For arrays of char and unsigned char, the difference between the result of the new-expression and the address returned by the allocation function shall be an integral multiple of the most stringent alignment requirement (3.9 basic.types) of any object type whose size is no greater than the size of the array being created.
The intent of this wording is that the pointer returned by the new-expression will be suitably aligned for any data type that might be placed into the allocated storage (since the allocation function is constrained to return a pointer to maximally-aligned storage). However, there is an implicit assumption that each alignment requirement is an integral multiple of all smaller alignment requirements. While this is probably a valid assumption for all real architectures, there's no reason that the Standard should require it.
For example, assume that int has an alignment requirement of 3 bytes and double has an alignment requirement of 4 bytes. The current wording only requires that a buffer that is big enough for an int or a double be aligned on a 4-byte boundary (the more stringent requirement), but that would allow the buffer to be allocated on an 8-byte boundary — which might not be an acceptable location for an int.
Suggested resolution: Change "of any object type" to "of every object type."
A similar assumption can be found in 5.2.10 expr.reinterpret.cast paragraph 7:
...converting an rvalue of type "pointer to T1" to the type "pointer to T2" (where ... the alignment requirements of T2 are no stricter than those of T1) and back to its original type yields the original pointer value...
Suggested resolution: Change the wording to
...converting an rvalue of type "pointer to T1" to the type "pointer to T2" (where ... the alignment requirements of T1 are an integer multiple of those of T2) and back to its original type yields the original pointer value...
The same change would also be needed in paragraph 9.
According to the C++ Standard section 5.3.4 expr.new paragraph 21 it is unspecified whether the allocation function is called before evaluating the constructor arguments or after evaluating the constructor arguments but before entering the constructor.
On top of that paragraph 17 of the same section insists that
If any part of the object initialization described above [Footnote: This may include evaluating a new-initializer and/or calling a constructor.] terminates by throwing an exception and a suitable deallocation function is found, the deallocation function is called to free the memory in which the object was being constructed... If no unambiguous matching deallocation function can be found, propagating the exception does not cause the object's memory to be freed...
Now suppose we have:
struct copy_throw {
copy_throw(const copy_throw&)
{ throw std::logic_error("Cannot copy!"); }
copy_throw(long, copy_throw)
{ }
copy_throw()
{ }
};
int main()
try {
copy_throw an_object, /* undefined behaviour */
* a_pointer = ::new copy_throw(0, an_object);
return 0;
}
catch(const std::logic_error&)
{ }
Here the new-expression '::new copy_throw(0, an_object)' throws an exception when evaluating the constructor's arguments and before the allocation function is called. However, 5.3.4 expr.new paragraph 17 prescribes that in such a case the implementation shall call the deallocation function to free the memory in which the object was being constructed, given that a matching deallocation function can be found.
So a call to the Standard library deallocation function '::operator delete(void*)' shall be issued, but what argument is an implementation supposed to supply to the deallocation function? As per 5.3.4 expr.new paragraph 17 - the argument is the address of the memory in which the object was being constructed. Given that no memory has yet been allocated for the object, this will qualify as using an invalid pointer value, which is undefined behaviour by virtue of 3.7.3.2 basic.stc.dynamic.deallocation paragraph 4.
Suggested resolution:
Change the first sentence of 5.3.4 expr.new paragraph 17 to read:
If the memory for the object being created has already been successfully allocated and any part of the object initialization described above...
In 5.3.4 expr.new, the standard says that the expression in an array-new has to have integral type. There's already a DR (issue 74) that says it should also be allowed to have enumeration type. But, it should probably also say that it can have a class type with a single conversion to integral type; in other words the same thing as in 6.4.2 stmt.switch paragraph 2.
Suggested resolution:
In 5.3.4 expr.new paragraph 6, replace "integral or enumeration type (3.9.1 basic.fundamental)" with "integral or enumeration type (3.9.1 basic.fundamental), or a class type for which a single conversion function to integral or enumeration type exists".
Should it be allowed to use an object of a class type having a single conversion function to an integral type as an array size in the first bound of the type in an array new?
struct A {
operator int();
} a;
int main () {
new int[a];
}
There are similar accommodations for the expression in a delete (5.3.5 expr.delete paragraph 1) and in a switch (6.4.2 stmt.switch paragraph 2). There is also widespread existing practice on this (g++, EDG, MSVC++, and Sun accept it, and even cfront 3.0.2).
5.3.4 expr.new paragraph 10 says that the result of an array allocation function and the value of the array new-expression from which it was invoked may be different, allowing for space preceding the array to be used for implementation purposes such as saving the number of elements in the array. However, there is no corresponding description of the relationship between the operand of an array delete-expression and the argument passed to its deallocation function.
3.7.3.2 basic.stc.dynamic.deallocation paragraph 3 does state that
the value supplied to operator delete[](void*) in the standard library shall be one of the values returned by a previous invocation of either operator new[](std::size_t) or operator new[](std::size_t, const std::nothrow_t&) in the standard library.
This statement might be read as requiring an implementation, when processing an array delete-expression and calling the deallocation function, to perform the inverse of the calculation applied to the result of the allocation function to produce the value of the new-expression. (5.3.5 expr.delete paragraph 2 requires that the operand of an array delete-expression "be the pointer value which resulted from a previous array new-expression.") However, it is not completely clear whether the "shall" expresses an implementation requirement or a program requirement (or both). Furthermore, there is no direct statement about user-defined deallocation functions.
Suggested resolution: A note should be added to 5.3.5 expr.delete to clarify that any offset added in an array new-expression must be subtracted in the array delete-expression.
Does the Standard require that the deallocation function will be called if the destructor throws an exception? For example,
struct S {
~S() { throw 0; }
};
void f() {
try {
delete new S;
}
catch(...) { }
}
The question is whether the memory for the S object will be freed or not. It doesn't appear that the Standard answers the question, although most people would probably assume that it will be freed.
Notes from 04/01 meeting:
There is a widespread feeling that it is a poor programming practice to allow destructors to terminate with an exception (see issue 219). This question is thus viewed as a tradeoff between efficiency and supporting "bad code." It was observed that there is no way in the current language to protect against a throwing destructor, since the throw might come from a virtual override.
It was suggested that the resolution to the issue might be to make it implementation-defined whether the storage is freed if the destructor throws. Others suggested that the Standard should require that the storage be freed, with the understanding that implementations might have a flag to allow optimizing away the overhead. Still others thought that both this issue and issue 219 should be resolved by forbidding a destructor to exit via an exception. No consensus was reached.
For delete expressions, 5.3.5 expr.delete paragraph 1 says
The operand shall have a pointer type, or a class type having a single conversion function to a pointer type.
However, paragraph 3 of that same section says:
if the static type of the operand is different from its dynamic type, the static type shall be a base class of the operand's dynamic type and the static type shall have a virtual destructor or the behavior is undefined.
Since the operand must be of pointer type, its static type is necessarily the same as its dynamic type. That clause is clearly referring to the object being pointed at, and not to the pointer operand itself.
Correcting the wording gets a little complicated, because dynamic and static types are attributes of expressions, not objects, and there's no sub-expression of a delete-expression which has the relevant types.
Suggested resolution:
then there is a static type and a dynamic type that the hypothetical expression (* const-expression) would have. If that static type is different from that dynamic type, then that static type shall be a base class of that dynamic type, and that static type shall have a virtual destructor, or the behavior is undefined.
There's precedent for such use of hypothetical constructs: see 5.10 expr.eq paragraph 2, and 8.1 dcl.name paragraph 1.
10.3 class.virtual paragraph 3 has a similar problem. It refers to
the type of the pointer or reference denoting the object (the static type).
The type of the pointer is different from the type of the reference, both of which are different from the static type of '*pointer', which is what I think was actually intended. Paragraph 6 contains the exact same wording, in need of the same correction. In this case, perhaps replacing "pointer or reference" with "expression" would be the best fix. In order for this fix to be sufficient, pointer->member must be considered equivalent to (*pointer).member, in which case the "expression" referred to would be (*pointer).
12.5 class.free paragraph 4 says thatif a delete-expression is used to deallocate a class object whose static type has...
This should be changed to
if a delete-expression is used to deallocate a class object through a pointer expression whose dereferenced static type would have...
The same problem occurs later, when it says that the
static and dynamic types of the object shall be identical
In this case you could replace "object" with "dereferenced pointer expression".
Footnote 104 says that
5.3.5 expr.delete requires that ... the static type of the delete-expression's operand be the same as its dynamic type.
This would need to be changed to
the delete-expression's dereferenced operand
The meaning of an old-style cast is described in terms of const_cast, static_cast, and reinterpret_cast in 5.4 expr.cast paragraph 5. Ignoring const_cast for the moment, it basically says that if the conversion performed by a given old-style cast is one of those performed by static_cast, the conversion is interpreted as if it were a static_cast; otherwise, it's interpreted as if it were a reinterpret_cast, if possible. The following example is given in illustration:
struct A {};
struct I1 : A {};
struct I2 : A {};
struct D : I1, I2 {};
A *foo( D *p ) {
return (A*)( p ); // ill-formed static_cast interpretation
}
The obvious intent here is that a derived-to-base pointer conversion is one of the conversions that can be performed using static_cast, so (A*)(p) is equivalent to static_cast<A*>(p), which is ill-formed because of the ambiguity.
Unfortunately, the description of static_cast in 5.2.9 expr.static.cast does NOT support this interpretation. The problem is in the way 5.2.9 expr.static.cast lists the kinds of casts that can be performed using static_cast. Rather than saying something like "All standard conversions can be performed using static_cast," it says
An expression e can be explicitly converted to a type T using a static_cast of the form static_cast<T>(e) if the declaration "T t(e);" is well-formed, for some invented temporary variable t.
Given the declarations above, the hypothetical declaration
A* t(p);
is NOT well-formed, because of the ambiguity. Therefore the old-style cast (A*)(p) is NOT one of the conversions that can be performed using static_cast, and (A*)(p) is equivalent to reinterpret_cast<A*>(p), which is well-formed under 5.2.10 expr.reinterpret.cast paragraph 7.
Other situations besides ambiguity which might raise similar questions include access violations, casting from virtual base to derived, and casting pointers-to-members when virtual inheritance is involved.
Does an explicit temporary of an integral type qualify as an integral constant expression? For instance,
void* p = int(); // well-formed?
It would appear to be, since int() is an explicit type conversion according to 5.2.3 expr.type.conv (at least, it's described in a section entitled "Explicit type conversion") and type conversions to integral types are permitted in integral constant expressions (5.19 expr.const). However, this reasoning is somewhat tenuous, and some at least have argued otherwise.
I've seen some pieces of code recently that put complex expressions involving overload resolution inside sizeof operations in constant expressions in templates.
5.19 expr.const paragraph 1 implies that some kinds of nonconstant expressions are allowed inside a sizeof in a constant expression, but it's not clear that this was intended to extend all the way to things like overload resolution. Allowing such things has some hidden costs. For example, name mangling has to be able to represent all operators, including calls, and not just the operators that can appear in constant expressions.
template <int I> struct A {};
char xxx(int);
char xxx(float);
template <class T> A<sizeof(xxx((T)0))> f(T){}
int main()
{
f(1);
}
If complex expressions are indeed allowed, it should be because of an explicit committee decision rather than because of some looseness in this section of the standard.
Notes from the 4/02 meeting:
Any argument for restricting such expressions must involve a cost/benefit ratio: a restriction would be palatable only if it causes minimum hardship for users and allows a substantial reduction in implementation cost. If we propose a restriction, it must be one that library writers can live with.
Lots of these cases fail with current compilers, so there can't be a lot of existing code using them. We plan to find out what cases there are in libraries like Loki and Boost.
We noted that in many cases one can move the code into a class to get the same result. The implementation problem comes up when the expression-in-sizeof is in a template deduction context or part of a template signature. The problem cases are ones where an error causes deduction to fail, as opposed to contexts where an error causes a diagnostic. The latter contexts are easier to handle; however, there are situations where "fail deduction" may be the desired behavior.
According to 6.6 stmt.jump paragraph 2,
On exit from a scope (however accomplished), destructors (12.4 class.dtor) are called for all constructed objects with automatic storage duration (3.7.2 basic.stc.auto) (named objects or temporaries) that are declared in that scope, in the reverse order of their declaration.
This wording is problematic for temporaries and for parameters. First, temporaries are not "declared," so this requirement does not apply to them, in spite of the assertion in the quoted text that it does.
Second, although the parameters of a function are declared in the called function, they are constructed and destroyed in the calling context, and the order of evaluation of the arguments is unspecified (cf 5.2.2 expr.call paragraphs 4 and 8). The order of destruction of the parameters might, therefore, be different from the reverse order of their declaration.
Notes from 04/01 meeting:
Any resolution of this issue should be careful not to introduce requirements that are redundant or in conflict with those of other parts of the IS. This is especially true in light of the pending issues with respect to the destruction of temporaries (see issues 86, 124, 199, and 201). If possible, the wording of a resolution should simply reference the relevant sections.
It was also noted that the temporary for a return value is also destroyed "out of order."
Paragraph 6.6 stmt.jump paragraph 2 of the standard says:
On exit from a scope (however accomplished), destructors (12.4 class.dtor) are called for all constructed objects with automatic storage duration (3.7.2 basic.stc.auto) (named objects or temporaries) that are declared in that scope.
It refers to objects "that are declared" but the text in parenthesis also mentions temporaries, which cannot be declared. I think that text should be removed.
7 dcl.dcl paragraph 3 reads,
In a simple-declaration, the optional
init-declarator-list can be omitted only when... the
decl-specifier-seq contains either a class-specifier,
an elaborated-type-specifier with a class-key
(9.1
class.name
), or an
enum-specifier. In these cases and whenever a
class-specifier or enum-specifier is present in the
decl-specifier-seq, the identifiers in those specifiers are
among the names being declared by the declaration... In such cases,
and except for the declaration of an unnamed bit-field
(9.6
class.bit
), the
decl-specifier-seq shall introduce one or more names into the
program, or shall redeclare a name introduced by a previous
declaration. [Example:
enum { }; // ill-formed
typedef class { }; // ill-formed
—end example]
In the absence of any explicit restrictions in
7.1.3
dcl.typedef
, this paragraph appears
to allow declarations like the following:
typedef struct S { }; // no declarator
typedef enum { e1 }; // no declarator
In fact, the final example in
7
dcl.dcl
paragraph 3 would seem to
indicate that this is intentional: since it is illustrating the
requirement that the decl-specifier-seq must introduce a name
in declarations in which the init-declarator-list is omitted,
presumably the addition of a class name would have made the example
well-formed.
On the other hand, there is no good reason to allow such declarations; the only reasonable scenario in which they might occur is a mistake on the programmer's part, and it would be a service to the programmer to require that such errors be diagnosed.
Steve Clamage: Consider this sequence of declarations:
void foo() { ... }
inline void foo();
The non-inline definition of foo precedes the inline declaration.
It seems to me this code should be ill-formed, but I could not find
anything in the standard to cover the situation.
Bjarne Stroustrup: Neither could I, so I looked in the ARM, which addressed this case (apparently for member function only) in some detail in 7.1.2 (pp103-104).
The ARM allows declaring a function inline after its initial declaration, as long as it has not been called.
Steve Clamage: If the above code is valid, how about this:
void foo() { ... } // define foo
void bar() { foo(); } // use foo
inline void foo(); // declare foo inline
Bjarne Stroustrup: ... and [the ARM] disallows declaring a function inline after it has been called.
This may still be a good resolution.
Steve Clamage: But the situation in the ARM is the reverse: Declare a function inline, and define it later (with no intervening call). That's a long-standing rule in C++, and allows you to write member function definitions outside the class.
In my example, the compiler could reasonably process the entire function as out-of-line, and not discover the inline declaration until it was too late to save the information necessary for inline generation. The equivalent of another compiler pass would be needed to handle this situation.
Bjarne Stroustrup: I see, and I think your argument it conclusive.
Steve Clamage: I'd like to open a core issue on this point, and I recommend wording along the lines of: "A function defined without an inline specifier shall not be followed by a declaration having an inline specifier."
I'd still like to allow the common idiom
class T {
int f();
};
inline int T::f() { ... }
Martin Sebor: Since the inline keyword is just a hint to the compiler, I don't see any harm in allowing the construct. Your hypothetical compiler can simply ignore the inline on the second declaration. On the other hand, I feel that adding another special rule will unnecessarily complicate the language.
Steve Clamage: The inline specifier is more than a hint. You can have multiple definitions of inline functions, but only one definition of a function not declared inline. In particular, suppose the above example were in a header file, and included multiple times in a program.
BTW, I noticed that the following note in 7.1.1 dcl.stc paragraph 2 doesn't seem to have made it onto the issues list or into the TR:
[Note: hence, the auto specifier is almost always redundant and not often used; one use of auto is to distinguish a declaration-statement from an expression-statement (stmt.ambig) explicitly. --- end note]
I thought that this was well known to be incorrect, because using auto does not disambiguate this. Writing:
auto int f();is still a declaration of a function f, just now with an error since the function's return type may not use an auto storage class specifier. I suppose an error is an improvement over a silent ambiguity going the wrong way, but it's still not a solution for the user who wants to express the other in a compilable way.
Proposed resolution: Replace that note with the following note:
[Note: hence, the auto specifier is always redundant and not often used. --- end note]
John Spicer: I support the proposed change, but I think the disambiguation case is not the one that you describe. An example of the supposed disambiguation is:
int i;
int j;
int main()
{
int(i); // declares i, not reference to ::i
auto int(j); // declares j, not reference to ::j
}
cfront would take "int(i)" as a cast of ::i, so the auto would force what it would otherwise treat as a statement to be considered a declaration (cfront 3.0 warned that this would change in the future).
In a conforming compiler the auto is always redundant (as you say) because anything that could be considered a valid declaration should be treated as one.
Are string literals from default arguments used in extern inlines supposed to have the same addresses across all translation units?
void f(const char* = "s")
inline g() {
f();
}
Must the "s" strings be the same in all copies of the inline function?
Steve Adamczyk: The totality of the standard's wisdom on this topic is (7.1.2 dcl.fct.spec paragraph 4):
A string literal in an extern inline function is the same object in different translation units.
I'd hazard a guess that a literal in a default argument expression is not "in" the extern inline function (it doesn't appear in the tokens of the function), and therefore it need not be the same in different translation units.
I don't know that users would expect such strings to have the same address, and an equally valid (and incompatible) expectation would be that the same string literal would be used for every expansion of a given default argument in a single translation unit.
7.1.5.3 dcl.type.elab paragraph 1 seems to impose an ordering constraint on the elements of friend class declarations. However, the general rule is that declaration specifiers can appear in any order. Should
class C friend;
be well-formed?
I received an inquiry/complaint that you cannot re-open a namespace using a qualified name. For example, the following program is ok, but if you uncomment the commented lines you get an error:
namespace A {
namespace N {
int a;
}
int b;
namespace M {
int c;
}
}
//namespace A::N {
// int d;
//}
namespace A {
namespace M {
int e;
}
}
int main()
{
A::N::a = 1;
A::b = 2;
A::M::c = 3;
// A::N::d = 4;
A::M::e = 5;
}
Andrew Koenig: There's a name lookup issue lurking here. For example:
int x;
namespace A {
int x;
namespace N {
int y;
};
}
namespace A::N {
int* y = &x; // which x?
}
Jonathan Caves: I would assume that any rule would state that:
namespace A::B {
would be equivalent to:
namespace A {
namespace B {
so in your example 'x' would resolve to A::x
BTW: we have received lots of bug reports about this "oversight".
Lawrence Crowl: Even worse is
int x;
namespace A {
int x;
}
namespace B {
int x;
namespace ::A {
int* y = &x;
}
}
I really don't think that the benefits of qualied names here is worth
the cost.
Issue 1:
The working paper is not clear about how the typename/template keywords interact with using-declarations:
template<class T> struct A {
typedef int X;
};
template<class T> void f() {
typename A<T>::X a; // OK
using typename A<T>::X; // OK
typename X b; // ill-formed; X must be qualified
X c; // is this OK?
}
When the rules for typename and the similar use of template
were decided, we chose to require that they be used at every reference.
The way to avoid typename at every use is to declare a typedef;
then the typedef name itself is known to be a type. For using-declarations,
we decided that they do not introduce new declarations but rather are aliases
for existing declarations, like symbolic links. This makes it unclear whether
the declaration "X c;" above should be well-formed, because there
is no new name declared so there is no declaration with a "this is a type"
attribute. (The same problem would occur with the template keyword
when a member template of a dependent class is used). I think these are
the main options:
The core WG already resolved this issue according to (1), but the wording does not seem to have been added to the standard. New wording needs to be drafted.
Issue 2:
Either way, one more point needs clarification. If the first option is adopted:
template<class T> struct A {
struct X { };
};
template<class T> void g() {
using typename A<T>::X;
X c; // if this is OK, then X by itself is a type
int X; // is this OK?
}
When "g" is instantiated, the two declarations of X are compatible
(7.3.3
namespace.udecl
paragraph 10).
But there is no way to know this when the definition of "g" is
compiled. I think this case should be ill-formed under the first option.
(It cannot happen under the second option.) If the second option is adopted:
template<class T> struct A {
struct X { };
};
template<class T> void g() {
using A<T>::X;
int X; // is this OK?
}
Again, the instantiation would work but there is no way to know that in
the template definition. I think this case should be ill-formed under the
second option. (It would already be ill-formed under the first option.)
From John Spicer:
The "not a new declaration" decision is more of a guiding principle than a hard and fast rule. For example, a name introduced in a using-declaration can have different access than the original declaration.Tentative Resolution:Like symbolic links, a using-declaration can be viewed as a declaration that declares an alias to another name, much like a typedef.
In my opinion, "X c;" is already well-formed. Why would we permit typename to be used in a using-declaration if not to permit this precise usage?
In my opinion, all that needs to be done is to clarify that the "typeness" or "templateness" attribute of the name referenced in the using-declaration is attached to the alias created by the using-declaration. This is solution #1.
The rules for multiple declarations with the same name in the same scope should treat a using-declaration which names a type as a typedef, just as a typedef of a class name is treated as a class declaration. This needs drafting work. Also see Core issue 36.
Rationale (04/99): Any semantics associated with the typename keyword in using-declarations should be considered an extension.
Section 7.3.3 namespace.udecl paragraph 8 says:
A using-declaration is a declaration and can therefore be used repeatedly where (and only where) multiple declarations are allowed.It contains the following example:
namespace A {
int i;
}
namespace A1 {
using A::i;
using A::i; // OK: double declaration
}
void f()
{
using A::i;
using A::i; // error: double declaration
}
However, if "using A::i;" is really a declaration, and not a definition, it is far from clear that repeating it should be an error in either context.
Consider:
namespace A {
int i;
void g();
}
void f() {
using A::g;
using A::g;
}
Surely the definition of f should be analogous to
void f() {
void g();
void g();
}
which is well-formed because "void g();" is a declaration and
not a definition.
Indeed, if the double using-declaration for A::i is prohibited in f, why should it be allowed in namespace A1?
Proposed Resolution (04/99): Change the comment "// error: double declaration" to "// OK: double declaration". (This should be reviewed against existing practice.)
Notes from 04/00 meeting:
The core language working group was unable to come to consensus over what kind of declaration a using-declaration should emulate. In a straw poll, 7 members favored allowing using-declarations wherever a non-definition declaration could appear, while 4 preferred to allow multiple using-declarations only in namespace scope (the rationale being that the permission for multiple using-declarations is primarily to support its use in multiple header files, which are seldom included anywhere other than namespace scope). John Spicer pointed out that friend declarations can appear multiple times in class scope and asked if using-declarations would have the same property under the "like a declaration" resolution.
As a result of the lack of agreement, the issue was returned to "open" status.
See also issues 56, 85, and 138..
Daveed Vandevoorde : While reading Core issue 11 I thought it implied the following possibility:
template<typename T>
struct B {
template<int> void f(int);
};
template<typename T>
struct D: B<T> {
using B<T>::template f;
void g() { this->f<1>(0); } // OK, f is a template
};
However, the grammar for a using-declaration reads:
and nested-name-specifier never ends in "template".
Is that intentional?
Bill Gibbons :
It certainly appears to be, since we have:
Rationale (04/99): Any semantics associated with the template keyword in using-declarations should be considered an extension.
The following came up recently on comp.lang.c++.moderated (edited for brevity):
namespace N1 {
template<typename T> void f( T* x ) {
// ... other stuff ...
delete x;
}
}
namespace N2 {
using N1::f;
template<> void f<int>( int* ); // A: ill-formed
class Test {
~Test() { }
friend void f<>( Test* x ); // B: ill-formed?
};
}
I strongly suspect, but don't have standardese to prove, that the friend declaration in line B is ill-formed. Can someone show me the text that allows or disallows line B?
Here's my reasoning: Writing "using" to pull the name into namespace N2 merely allows code in N2 to use the name in a call without qualification (per 7.3.3 namespace.udecl). But just as declaring a specialization must be done in the namespace where the template really lives (hence line A is ill-formed), I suspect that declaring a specialization as a friend must likewise be done using the original namespace name, not obliquely through a "using". I see nothing in 7.3.3 namespace.udecl that would permit this use. Is there?
Andrey Tarasevich: 14.5.3 temp.friend paragraph 2 seems to get pretty close: "A friend declaration that is not a template declaration and in which the name of the friend is an unqualified 'template-id' shall refer to a specialization of a function template declared in the nearest enclosing namespace scope".
Herb Sutter: OK, thanks. Then the question in this is the word "declared" -- in particular, we already know we cannot declare a specialization of a template in any other namespace but the original one.
John Spicer: This seems like a simple question, but it isn't.
First of all, I don't think the standard comments on this usage one way or the other.
A similar example using a namespace qualified name is ill-formed based on 8.3 dcl.meaning paragraph 1:
namespace N1 {
void f();
}
namespace N2 {
using N1::f;
class A {
friend void N2::f();
};
}
Core issue 138 deals with this example:
void foo();
namespace A{
using ::foo;
class X{
friend void foo();
};
}
The proposed resolution (not yet approved) for issue 138 is that the friend declares a new foo that conflicts with the using-declaration and results in an error.
Your example is different than this though because the presence of the explicit argument list means that this is not declaring a new f but is instead using a previously declared f.
One reservation I have about allowing the example is the desire to have consistent rules for all of the "declaration like" uses of template functions. Issue 275 (in DR status) addresses the issue of unqualified names in explicit instantiation and explicit specialization declarations. It requires that such declarations refer to templates from the namespace containing the explicit instantiation or explicit specialization. I believe this rule is necessary for those directives but is not really required for friend declarations -- but there is the consistency issue.
8.3.5 dcl.fct/2 restricts the use of void as parameter type, but does not mention CV qualified versions. Since void f(volatile void) isn't a callable function anyway, 8.3.5 dcl.fct should also ban cv-qualified versions. (BTW, this follows C)
Suggested resolution:
A possible resolution would be to add (cv-qualified) before void in
The parameter list (void) is equivalent to the empty parameter list. Except for this special case, (cv-qualified) void shall not be a parameter type (though types derived from void, such as void*, can).
EDG rejects this code:
template <typename T>
struct S {};
void f (S<int (*)[]>);
G++ accepts it.
This is another case where the standard isn't very clear:
The language from 8.3.5 dcl.fct is:
If the type of a parameter includes a type of the form "pointer to array of unknown bound of T" or "reference to array of unknown bound of T," the program is ill-formed.Since "includes a type" is not a term defined in the standard, we're left to guess what this means. (It would be better if this were a recursive definition, the way a type theoretician would do it:
The standard is not precise enough about when the default arguments of member functions are parsed. This leads to confusion over whether certain constructs are legal or not, and the validity of certain compiler implementation algorithms.
8.3.6 dcl.fct.default paragraph 5 says "names in the expression are bound, and the semantic constraints are checked, at the point where the default argument expression appears"
However, further on at paragraph 9 in the same section there is an example, where the salient parts are
int b;
class X {
int mem2 (int i = b); // OK use X::b
static int b;
};
which appears to contradict the former constraint. At the point the default
argument expression appears in the definition of X, X::b has not been
declared, so one would expect ::b to be bound. This of course appears to
violate 3.3.6
basic.scope.class paragraph 1(2) "A name N used in
a class S shall
refer to the same declaration in its context and when reevaluated in the
complete scope of S. No diagnostic is required."
Furthermore 3.3.6 basic.scope.class paragraph 1(1) gives the scope of names declared in class to "consist not only of the declarative region following the name's declarator, but also of .. default arguments ...". Thus implying that X::b is in scope in the default argument of X::mem2 previously.
That previous paragraph hints at an implementation technique of saving the token stream of a default argument expression and parsing it at the end of the class definition (much like the bodies of functions defined in the class). This is a technique employed by GCC and, from its behaviour, in the EDG front end. The standard leaves two things unspecified. Firstly, is a default argument expression permitted to call a static member function declared later in the class in such a way as to require evaluation of that function's default arguments? I.e. is the following well formed?
class A {
static int Foo (int i = Baz ());
static int Baz (int i = Bar ());
static int Bar (int i = 5);
};
If that is well formed, at what point does the non-sensicalness of
class B {
static int Foo (int i = Baz ());
static int Baz (int i = Foo());
};
become detected? Is it when B is complete? Is it when B::Foo or B::Baz is
called in such a way to require default argument expansion? Or is no
diagnostic required?
The other problem is with collecting the tokens that form the default argument expression. Default arguments which contain template-ids with more than one parameter present a difficulty in determining when the default argument finishes. Consider,
template <int A, typename B> struct T { static int i;};
class C {
int Foo (int i = T<1, int>::i);
};
The default argument contains a non-parenthesized comma. Is it required
that this comma is seen as part of the default argument expression and not
the beginning of another of argument declaration? To accept this as
part of the default argument would require name lookup of T (to determine
that the '<' was part of a template argument list and not a less-than
operator) before C is complete. Furthermore, the more pathological
class D {
int Foo (int i = T<1, int>::i);
template T<int A, typename B> struct T {static int i;};
};
would be very hard to accept. Even though T is declared after Foo, T is
in scope within Foo's default argument expression.
Suggested resolution:
Append the following text to 8.3.6 dcl.fct.default paragraph 8.
The default argument expression of a member function declared in the class definition consists of the sequence of tokens up until the next non-parenthesized, non-bracketed comma or close parenthesis. Furthermore such default argument expressions shall not require evaluation of a default argument of a function declared later in the class.
This would make the above A, B, C and D ill formed and is in line with the existing compiler practice that I am aware of.
Is this program well-formed?
struct S {
static int f2(int = f1()); // OK?
static int f1(int = 2);
};
int main()
{
return S::f2();
}
A class member function can in general refer to class members that are declared lexically later. But what about referring to default arguments of member functions that haven't yet been declared?
It seems to me that if f2 can refer to f1, it can also refer to the default argument of f1, but at least one compiler disagrees.
It is not clear whether the following declaration is well-formed:
struct S { int i; } s = { { 1 } };
According to 8.5.1
dcl.init.aggr
paragraph 2, a brace-enclosed initializer is permitted for a
subaggregate of an aggregate; however, i is a scalar, not an
aggregate. 8.5
dcl.init
paragraph 13
says that a standalone declaration like
int i = { 1 };
is permitted, but it is not clear whether this says anything about the
form of initializers for scalar members of aggregates.
This is (more) clearly permitted by the C89 Standard.
Paragraph 9 of 8.5 dcl.init says:
If no initializer is specified for an object, and the object is of (possibly cv-qualified) non-POD class type (or array thereof), the object shall be default-initialized; if the object is of const-qualified type, the underlying class type shall have a user-declared default constructor. Otherwise, if no initializer is specified for an object, the object and its subobjects, if any, have an indeterminate initial value; if the object or any of its subobjects are of const-qualified type, the program is ill-formed.
What if a const POD object has no non-static data members? This wording requires an empty initializer for such cases:
struct Z {
// no data members
operator int() const { return 0; }
};
void f() {
const Z z1; // ill-formed: no initializer
const Z z2 = { }; // well-formed
}
Similar comments apply to a non-POD const object, all of whose non-static data members and base class subobjects have default constructors. Why should the class of such an object be required to have a user-declared default constructor?
(See also issue 78.)
There is an inconsistency in the handling of references vs pointers in user defined conversions and overloading. The reason for that is that the combination of 8.5.3 dcl.init.ref and 4.4 conv.qual circumvents the standard way of ranking conversion functions, which was probably not the intention of the designers of the standard.
Let's start with some examples, to show what it is about:
struct Z { Z(){} };
struct A {
Z x;
operator Z *() { return &x; }
operator const Z *() { return &x; }
};
struct B {
Z x;
operator Z &() { return x; }
operator const Z &() { return x; }
};
int main()
{
A a;
Z *a1=a;
const Z *a2=a; // not ambiguous
B b;
Z &b1=b;
const Z &b2=b; // ambiguous
}
So while both classes A and B are structurally equivalent, there is a difference in operator overloading. I want to start with the discussion of the pointer case (const Z *a2=a;): 13.3.3 over.match.best is used to select the best viable function. Rule 4 selects A::operator const Z*() as best viable function using 13.3.3.2 over.ics.rank since the implicit conversion sequence const Z* -> const Z* is a better conversion sequence than Z* -> const Z*.
So what is the difference to the reference case? Cv-qualification conversion is only applicable for pointers according to 4.4 conv.qual. According to 8.5.3 dcl.init.ref paragraphs 4-7 references are initialized by binding using the concept of reference-compatibility. The problem with this is, that in this context of binding, there is no conversion, and therefore there is also no comparing of conversion sequences. More exactly all conversions can be considered identity conversions according to 13.3.3.1.4 over.ics.ref paragraph 1, which compare equal and which has the same effect. So binding const Z* to const Z* is as good as binding const Z* to Z* in terms of overloading. Therefore const Z &b2=b; is ambiguous. [13.3.3.1.4 over.ics.ref paragraph 5 and 13.3.3.2 over.ics.rank paragraph 3 rule 3 (S1 and S2 are reference bindings ...) do not seem to apply to this case]
There are other ambiguities, that result in the special treatment of references: Example:
struct A {int a;};
struct B: public A { B() {}; int b;};
struct X {
B x;
operator A &() { return x; }
operator B &() { return x; }
};
main()
{
X x;
A &g=x; // ambiguous
}
Since both references of class A and B are reference compatible with references of class A and since from the point of ranking of implicit conversion sequences they are both identity conversions, the initialization is ambiguous.
So why should this be a defect?
So overall I think this was not the intention of the authors of the standard.
So how could this be fixed? For comparing conversion sequences (and only for comparing) reference binding should be treated as if it was a normal assignment/initialization and cv-qualification would have to be defined for references. This would affect 8.5.3 dcl.init.ref paragraph 6, 4.4 conv.qual and probably 13.3.3.2 over.ics.rank paragraph 3.
Another fix could be to add a special case in 13.3.3 over.match.best paragraph 1.
There is a place in the Standard where overload resolution is implied but the way that a set of candidate functions is to be formed is omitted. See below.
According to the Standard, when initializing a reference to a non-volatile const class type (cv1 T1) with an rvalue expression (cv2 T2) where cv1 T1 is reference compatible with cv2 T2, the implementation shall proceed in one of the following ways (except when initializing the implicit object parameter of a copy constructor) 8.5.3 dcl.init.ref paragraph 5 bullet 2 sub-bullet 1:
While the first case is quite obvious, the second one is a bit unclear as it says "a constructor is called to copy the entire rvalue object into the temporary" without specifying how the temporary is created -- by direct-initialization or by copy-initialization? As stated in DR 152, this can make a difference when the copy constructor is declared as explicit. How should the set of candidate functions be formed? The most appropriate guess is that it shall proceed as per 13.3.1.3 over.match.ctor.
Another detail worth of note is that in the draft version of the Standard as of 2 December 1996 the second bullet read:
J. Stephen Adamczyk replied that the reason for changing "a copy constructor" to "a constructor" was to allow for member template converting constructors.
However, the new wording is somewhat in conflict with the footnote #93 that says that when initializing the implicit object parameter of a copy constructor an implementation must eventually choose the first alternative (binding without copying) to avoid infinite recursion. This seems to suggest that a copy constructor is always used for initializing the temporary of type "cv1 T2".
Furthermore, now that the set of candidate functions is not limited to only the copy constructors of T2, there might be some unpleasant consequences. Consider a rather contrived sample below:
int * pi = ::new(std::nothrow) int;
const std::auto_ptr<int> & ri = std::auto_ptr<int>(pi);
In this example the initialization of the temporary of type '<TT>const std::auto_ptr<int>' (to which 'ri' is meant to be subsequently bound) doesn't fail, as it would had the approach with copy constructors been retained, instead, a yet another temporary gets created as the well-known sequence:
std::auto_ptr<int>::operator std::auto_ptr_ref<int>()
std::auto_ptr<int>(std::auto_ptr_ref<int>)
is called (assuming, of course, that the set of candidate functions is formed as per 13.3.1.3 over.match.ctor). The second temporary is transient and gets destroyed at the end of the initialization. I doubt that this is the way that the committee wanted this kind of reference binding to go.
Besides, even if the approach restricting the set of candidates to copy constructors is restored, it is still not clear how the initialization of the temporary (to which the reference is intended to be bound) is to be performed -- using direct-initialization or copy-initialization.
Another place in the Standard that would benefit from a similar clarification is the creation of an exception object, which is delineated in 15.1 except.throw.
After some email exchanges with Rani Sharoni, I've come up with the following proposal to allow reference binding to non-copyable rvalues in some cases. Rationale and some background appear afterwards.
---- proposal ----
Replace the section of 8.5.3 dcl.init.ref paragraph 5 that begins "If the initializer expression is an rvalue" with the following:
---- rationale ----
class nc {
nc (nc const &); // private, nowhere defined
public:
nc ();
nc const &by_ref () const { return *this; }
};
void f () {
void g (nc const &);
g (nc()); // Ill-formed
g (nc().by_ref()); // Ok - binds directly to rvalue
}
Forcing a direct binding in this way is possible wherever
the lifetime of the reference does not extend beyond the
containing full expression, since the reference returned
by the member function remains valid for this long.
---- background ----
The proposal is based on a recent discussion in this group. I originally wanted to leave the implementation free to copy the rvalue if there was a callable copy constructor, and only have to bind directly if none was callable. Unfortunately, a traditional compiler can't always tell whether a function is callable or not, e.g. if the copy constructor is declared but not defined. Rani pointed this out in an example, and suggested that maybe trivial copy constructors should still be allowed (by extension, maybe wherever the compiler can determine callability). I've gone with this version because it's simpler, and I also figure the "as if" rule gives the compiler some freedom with POD types anyway.
In 9 class paragraph 4, the first sentence says "A structure is a class definition defined with the class-key struct". As far as I know, there is no such thing as a structure in C++; it certainly isn't listed as one of the possible compound types in 3.9.2 basic.compound. And defining structures opens the question of whether a forward declaration is a structure or not. The parallel here with union (which follows immediately) suggests that structures and classes are really different things, since the same wording is used, and classes and unions do have some real differences, which manifest themselves outside of the definition. It also suggests that since one can't forward declare union with class and vice versa, the same should hold for struct and class -- I believe that the intent was that one could use struct and class interchangeably in forward declaration.
Suggested resolution:
I suggest something like the following:
If a class is defined with the class-key class, its members and base classes are private by default. If a class is defined with the class-key struct, its members and base classes are public by default. If a class is defined with the class-key union, its members are public by default, and it holds only one data member at a time. Such classes are called unions, and obey a number of additional restrictions, see 9.5 class.union.
In looking at a large handful of core issues related to elaborated-type-specifiers and the naming of classes in general, I discovered an odd fact. It turns out that there is exactly one place in the grammar where nested-name-specifier is not immediately preceded by "::opt": in class-head, which is used only for class definitions. So technically, this example is ill-formed, and should evoke a syntax error:
struct A;
struct ::A { };
However, all of EDG, GCC and Microsoft's compiler accept it without a qualm. In fact, I couldn't get any of them to even warn about it.
Suggested resolution:
It would simplify the grammar, and apparently better reflect existing practice, to factor the global-scope operator into the rule for nested-name-specifier.
The standard (9 class par. 4) says that "A POD-struct is an aggregate class that has no non-static data members of type non-POD-struct, non-POD-union (or array of such types) or reference, and has no user-defined copy assignment operator and no user-defined destructor."
Note that it says 'user-defined', not 'user-declared'. Is it the intent that if e.g. a copy assignment operator is declared but not defined, this does not (per se) prevent the class to be a POD-struct?
Another instance to consider is that of invoking a member function from a null pointer:
struct A { void f () { } };
int main ()
{
A* ap = 0;
ap->f ();
}
Which is explicitly noted as undefined in 9.3.1 class.mfct.nonstatic, even though one could argue that since f() is empty, there is no lvalue->rvalue conversion.
If f is static, however, there seems to be no such rule, and the call is only undefined if the dereference implicit in the -> operator is undefined. IMO it should be.
Incidentally, another thing that ought to be cleaned up is the inconsistent use of "indirection" and "dereference". We should pick one. (This terminology issue has been broken out as issue 342.)
This is related to issue 232
There doesn't seem to be a prohibition in 9.5 class.union against a declaration like
union { int : 0; } x;
Should that be valid? If so, 8.5
dcl.init
paragraph 5 third bullet, which deals with
default-initialization of unions, should say that no initialization is
done if there are no data members.
What about:
union { } x;
static union { };
If the first example is well-formed, should either or both of these cases
be well-formed as well?
(See also the resolution for issue 151.)
Notes from 10/00 meeting: The resolution to issue 178, which was accepted as a DR, addresses the first point above (default initialization). The other questions have not yet been decided, however.
Section 9.6 class.bit paragraph 4 needs to be more specific about the signedness of bit fields of enum type. How much leeway does an implementation have in choosing the signedness of a bit field? In particular, does the phrase "large enough to hold all the values of the enumeration" mean "the implementation decides on the signedness, and then we see whether all the values will fit in the bit field", or does it require the implementation to make the bit field signed or unsigned if that's what it takes to make it "large enough"?
(See also issue 172.)
9.3 class.mfct paragraph 5 says this about member functions defined lexically outside the class:
the member function name shall be qualified by its class name using the :: operator
9.4.2 class.static.data paragraph 2 says this about static data members:
In the definition at namespace scope, the name of the static data member shall be qualified by its class name using the :: operator
I would have expected similar wording in 9.7 class.nest paragraph 3 for nested classes. Without such wording, the following seems to be legal (and is allowed by all the compilers I have):
struct base {
struct nested;
};
struct derived : base {};
struct derived::nested {};
Is this just an oversight, or is there some rationale for this behavior?
The term "ambiguous base class" doesn't seem to be actually defined anywhere. 10.2 class.member.lookup paragraph 7 seems like the place to do it.
According to 10.4 class.abstract paragraph 6,
Member functions can be called from a constructor (or destructor) of an abstract class; the effect of making a virtual call (10.3 class.virtual) to a pure virtual function directly or indirectly for the object being created (or destroyed) from such a constructor (or destructor) is undefined.
This prohibition is unnecessarily restrictive. It should not apply to cases in which the pure virtual function has been defined.
Currently the "pure" specifier for a virtual member function has two meanings that need not be related:
The prohibition of virtual calls to pure virtual functions arises from the first meaning and unnecessarily penalizes those who only need the second.
For example, consider a scenario such as the following. A class B is defined containing a (non-pure) virtual function f that provides some initialization and is thus called from the base class constructor. As time passes, a number of classes are derived from B and it is noticed that each needs to override f, so it is decided to make B::f pure to enforce this convention while still leaving the original definition of B::f to perform its needed initialization. However, the act of making B::f pure means that every reference to f that might occur during the execution of one of B's constructors must be tracked down and edited to be a qualified reference to B::f. This process is tedious and error-prone: needed edits might be overlooked, and calls that actually should be virtual when the containing function is called other than during construction/destruction might be incorrectly changed.
Suggested resolution: Allow virtual calls to pure virtual functions if the function has been defined.
In clause 10.4 class.abstract paragraph 2, it reads:
A pure virtual function need be defined only if explicitly called with the qualified-id syntax (5.1 expr.prim).
This is IMHO incomplete. A dtor is a function (well, a "special member function", but this also makes it a function, right?) but it is called implicitly and thus without a qualified-id syntax. Another alternative is that the pure virtual function is called directly or indirectly from the ctor. Thus the above sentence which specifies when a pure virtual function need be defined ("...only if...") needs to be extended:
A pure virtual function need be defined only if explicitly called with the qualified-id syntax (5.1 expr.prim) or if implicitly called (12.4 class.dtor or 12.7 class.cdtor).
I have heard a claim that the following code is valid, but I don't see why.
struct A {
int foo ();
};
struct B: A {
private:
using A::foo;
};
int main ()
{
return B ().foo ();
}
It seems to me that the using declaration in B should hide the public foo in A. Then the call to B::foo should fail because B::foo is not accessible in main.
Am I missing something?
Steve Adamczyk: This is similar to the last example in 11.2 class.access.base. In prose, the rule is that if you have access to cast to a base class and you have access to the member in the base class, you are given access in the derived class. In this case, A is a public base class of B and foo is public in A, so you can access foo through a B object. The actual permission for this is in the fourth bullet in 11.2 class.access.base paragraph 4.
The wording changes for issue 9 make this clearer, but I believe even without them this example could be discerned to be valid.
See my paper J16/96-0034, WG21/N0852 on this topic.
Steve Clamage: But a using-declaration is a declaration (7.3.3 namespace.udecl). Compare with
struct B : A {
private:
int foo();
};
In this case, the call would certainly be invalid, even though your argument about casting B to an A would make it OK. Your argument basically says that an access adjustment to make something less accessible has no effect. That also doesn't sound right.
Steve Adamczyk: I agree that is strange. I do think that's what 11.2 class.access.base says, but perhaps that's not what we want it to say.
We consider it not unreasonable to do the following
class A {
protected:
void g();
};
class B : public A {
public:
using A::g; // B::g is a public synonym for A::g
};
class C: public A {
void foo();
};
void C::foo() {
B b;
b.g();
}
However the EDG front-end does not like and gives the error
#410-D: protected function "A::g" is not accessible through a "B" pointer or object
b.g();
^
Steve Adamczyk: The error in this case is due to 11.5 class.protected of the standard, which is an additional check on top of the other access checking. When that section says "a protected nonstatic member function ... of a base class" it doesn't indicate whether the fact that there is a using-declaration is relevant. I'd say the current wording taken at face value would suggest that the error is correct -- the function is protected, even if the using-declaration for it makes it accessible as a public function. But I'm quite sure the wording in 11.5 class.protected was written before using-declarations were invented and has not been reviewed since for consistency with that addition.
12.2 class.temporary paragraph 3 simply states the requirement that temporaries created during the evaluation of an expression
are destroyed as the last step in evaluating the full-expression (1.9) that (lexically) contains the point where they were created.There is nothing said about the relative order in which these temporaries are destroyed.
Paragraph 5, dealing with temporaries bound to references, says
the temporaries created during the evaluation of the expression initializing the reference, except the temporary to which the reference is bound, are destroyed at the end of the full-expression in which they are created and in the reverse order of the completion of their construction.Is this difference intentional? May temporaries in expressions other than those initializing references be deleted in non-LIFO order?
Notes from 04/00 meeting:
Steve Adamczyk expressed concern about constraining implementations that are capable of fine-grained parallelism -- they may be unable to determine the order of construction without adding undesirable overhead.
Section 12.2 class.temporary paragraph 2, abridged:
X f(X); void g() { X a; a = f(a); }a=f(a) requires a temporary for either the argument a or the result of f(a) to avoid undesired aliasing of a.
The note seems to imply that an implementation is allowed to omit copying "a" to f's formal argument, or to omit using a temporary for the return value of f. I don't find that license in normative text.
Function f returns an X by value, and in the expression the value is assigned (not copy-constructed) to "a". I don't see how that temporary can be omitted. (See also 12.8 class.copy p 15)
Since "a" is an lvalue and not a temporary, I don't see how copying "a" to f's formal parameter can be avoided.
Am I missing something, or is 12.2 class.temporary p 2 misleading?
class C {
public:
C();
~C();
int& get() { return p; } // reference return
private:
int p;
};
int main ()
{
if ( C().get() ) // OK?
}
Section 12.2 class.temporary paragraph 3 says a temp is destroyed as the last step in evaluating the full expression. But the expression C().get() has a reference type. Does 12.2 class.temporary paragraph 3 require that the dereference to get a boolean result occur before the destructor runs, making the code valid? Or does the code have undefined behavior?
Bill Gibbons: It has undefined behavior, though clearly this wasn't intended. The lvalue-to-rvalue conversion that occurs in the "if" statement is not currently part of the full-expression.
From section 12.2 class.temporary paragraph 3:
Temporary objects are destroyed as the last step in evaluating the full-expression (1.9 intro.execution) that (lexically) contains the point where they were created.
From section 1.9 intro.execution paragraph 12:
A full-expression is an expression that is not a subexpression of another expression. If a language construct is defined to produce an implicit call of a function, a use of the language construct is considered to be an expression for the purposes of this definition.
The note in section 1.9 intro.execution paragraph 12 goes on to explain that this covers expressions used as initializers, but it does not discuss lvalues within temporaries.
It is a small point but it is probably worth correcting 1.9 intro.execution paragraph 12. Instead of the "implicit call of a function" wording, it might be better to just say that a full-expression includes any implicit use of the expression value in the enclosing language construct, and include a note giving implicit calls and lvalue-to-rvalue conversions as examples.
Offhand the places where this matters include: initialization (including member initializers), selection statements, iteration statements, return, throw
A posting in comp.lang.c++.moderated prompted me to try the following code:
struct S {
template<typename T, int N> (&operator T())[N];
};
The goal is to have a (deducible) conversion operator template to a reference-to-array type.
This is accepted by several front ends (g++, EDG), but I now believe that 12.3.2 class.conv.fct paragraph 1 actually prohibits this. The issue here is that we do in fact specify (part of) a return type.
OTOH, I think it is legitimate to expect that this is expressible in the language (preferably not using the syntax above ;-). Maybe we should extend the syntax to allow the following alternative?
struct S {
template<typename T, int N> operator (T(&)[N])();
};
Eric Niebler: If the syntax is extended to support this, similar constructs should also be considered. For instance, I can't for the life of me figure out how to write a conversion member function template to return a member function pointer. It could be useful if you were defining a null_t type. This is probably due to my own ignorance, but getting the syntax right is tricky.
Eg.
struct null_t {
// null object pointer. works.
template<typename T> operator T*() const { return 0; }
// null member pointer. works.
template<typename T,typename U> operator T U::*() const { return 0; }
// null member fn ptr. doesn't work (with Comeau online). my error?
template<typename T,typename U> operator T (U::*)()() const { return 0; }
};
Martin Sebor: Intriguing question. I have no idea how to do it in a single declaration but splitting it up into two steps seems to work:
struct null_t {
template <class T, class U>
struct ptr_mem_fun_t {
typedef T (U::*type)();
};
template <class T, class U>
operator typename ptr_mem_fun_t<T, U>::type () const {
return 0;
}
};
Note that destructors suffer from similar problems as those of constructors dealt with in issue 194 and in 263 (constructors as friends). Also, the wording in 12.4 class.dtor, paragraph 1 does not permit a destructor to be defined outside of the memberlist.
Change 12.4 class.dtor, paragraph 1 from
...A special declarator syntax using an optional function-specifier (7.1.2 dcl.fct.spec) followed by ~ followed by the destructor's class name followed by an empty parameter list is used to declare the destructor in a class definition. In such a declaration, the ~ followed by the destructor's class name can be enclosed in optional parentheses; such parentheses are ignored....
to
...A special declarator syntax using an optional sequence of function-specifiers (7.1.2 dcl.fct.spec), an optional friend keyword, an optional sequence of function-specifiers (7.1.2 dcl.fct.spec) followed by an optional :: scope-resolution-operator followed by an optional nested-name-specifier followed by ~ followed by the destructor's class name followed by an empty parameter list is used to declare the destructor. The optional nested-name-specifier shall not be specified in the declaration of a destructor within the member-list of the class of which the destructor is a member. In such a declaration, the optional :: scope-resolution-operator followed by an optional nested-name-specifier followed by ~ followed by the destructor's class name can be enclosed in optional parentheses; such parentheses are ignored....
Mark Mitchell raised a number of issues related to the resolution of issue 244 and of destructor lookup in general.
Issue 244 says:
... in a qualified-id of the form:::opt nested-name-specifieropt class-name :: ~ class-name
the second class-name is looked up in the same scope as the first.
But if the reference is "p->X::~X()", the first class-name is looked up in two places (normal lookup and a lookup in the class of p). Does the new wording mean:
This is a test case that illustrates the issue:
struct A {
typedef A C;
};
typedef A B;
void f(B* bp) {
bp->B::~B(); // okay B found by normal lookup
bp->C::~C(); // okay C found by class lookup
bp->B::~C(); // B found by normal lookup C by class -- okay?
bp->C::~B(); // C found by class lookup B by normal -- okay?
}
A second issue concerns destructor references when the class involved is a template class.
namespace N {
template <typename T> struct S {
~S();
};
}
void f(N::S<int>* s) {
s->N::S<int>::~S();
}
The issue here is that the grammar uses "~class-name" for destructor names, but in this case S is a template name when looked up in N.
Finally, what about cases like:
template <typename T> void f () {
typename T::B x;
x.template A<T>::template B<T>::~B();
}
When parsing the template definition, what checks can be done on "~B"?
Paragraph 4 of 12.5 class.free speaks of looking up a deallocation function. While it is an error if a placement deallocation function alone is found by this lookup, there seems to be an assumption that a placement deallocation function and a usual deallocation function can both be declared in a given class scope without creating an ambiguity. The normal mechanism by which ambiguity is avoided when functions of the same name are declared in the same scope is overload resolution; however, there is no mention of overload resolution in the description of the lookup. In fact, there appears to be nothing in the current wording that handles this case. That is, the following example appears to be ill-formed, according to the current wording:
struct S {
void operator delete(void*);
void operator delete(void*, int);
};
void f(S* p) {
delete p; // ill-formed: ambiguous operator delete
}
Suggested resolution (Mike Miller, March 2002):
I think you might get the right effect by replacing the last sentence of 12.5 class.free paragraph 4 with something like:
After removing all placement deallocation functions, the result of the lookup shall contain an unambiguous and accessible deallocation function.
Must a constructor for an abstract base class provide a mem-initializer for each virtual base class from which it is directly or indirectly derived? Since the initialization of virtual base classes is performed by the most-derived class, and since an abstract base class can never be the most-derived class, there would seem to be no reason to require constructors for abstract base classes to initialize virtual base classes.
It is not clear from the Standard whether there actually is such a requirement or not. The relevant text is found in 12.6.2 class.base.init paragraph 6:
All sub-objects representing virtual base classes are initialized by the constructor of the most derived class (1.8 intro.object). If the constructor of the most derived class does not specify a mem-initializer for a virtual base class V, then V's default constructor is called to initialize the virtual base class subobject. If V does not have an accessible default constructor, the initialization is ill-formed. A mem-initializer naming a virtual base class shall be ignored during execution of the constructor of any class that is not the most derived class.
This paragraph requires only that the most-derived class's constructor have a mem-initializer for virtual base classes. Should the silence be construed as permission for constructors of classes that are not the most-derived to omit such mem-initializers?
Jack Rouse: In 12.8 class.copy paragraph 8, the standard includes the following about the copying of class subobjects in such a constructor:
Mike Miller: I'm more concerned about 12.8 class.copy paragraph 7, which lists the situations in which an implicitly-defined copy constructor can render a program ill-formed. Inaccessible and ambiguous copy constructors are listed, but not a copy constructor with a cv-qualification mismatch. These two paragraphs taken together could be read as requiring the calling of a copy constructor with a non-const reference parameter for a const data member.
According to the Standard (although not implemented this way in most implementations), the following code exhibits non-intuitive behavior:
struct T {
operator short() const;
operator int() const;
};
short s;
void f(const T& t) {
s = t; // surprisingly calls T::operator int() const
}
The reason for this choice is 13.6 over.built paragraph 18:
For every triple (L, VQ, R), where L is an arithmetic type, VQ is either volatile or empty, and R is a promoted arithmetic type, there exist candidate operator functions of the form
VQ L& operator=(VQ L&, R);
Because R is a "promoted arithmetic type," the second argument to the built-in assignment operator is int, causing the unexpected choice of conversion function.
Suggested resolution: Provide built-in assignment operators for the unpromoted arithmetic types.
Related to the preceding, but not resolved by the suggested resolution, is the following problem. Given:
struct T {
operator int() const;
operator double() const;
};
I believe the standard requires the following assignment to be ambiguous (even though I expect that would surprise the user):
double x;
void f(const T& t) { x = t; }
The problem is that both of these built-in operator=()s exist (13.6 over.built paragraph 18):
double& operator=(double&, int);
double& operator=(double&, double);
Both are an exact match on the first argument and a user conversion on the second. There is no rule that says one is a better match than the other.
The compilers that I have tried (even in their strictest setting) do not give a peep. I think they are not following the standard. They pick double& operator=(double&, double) and use T::operator double() const.
I hesitate to suggest changes to overload resolution, but a possible resolution might be to introduce a rule that, for built-in operator= only, also considers the conversion sequence from the second to the first type. This would also resolve the earlier question.
It would still leave x += t etc. ambiguous -- which might be the desired behavior and is the current behavior of some compilers.
Notes from the 04/01 meeting:
The difference between initialization and assignment is disturbing. On the other hand, promotion is ubiquitous in the language, and this is the beginning of a very slippery slope (as the second report above demonstrates).
According to 14 temp paragraph 5,
Except that a function template can be overloaded either by (non-template) functions with the same name or by other function templates with the same name (14.8.3 temp.over ), a template name declared in namespace scope or in class scope shall be unique in that scope.3.3.7 basic.scope.hiding paragraph 2 agrees that only functions, not function templates, can hide a class name declared in the same scope:
A class name (9.1 class.name ) or enumeration name (7.2 dcl.enum ) can be hidden by the name of an object, function, or enumerator declared in the same scope.However, 3.3 basic.scope paragraph 4 treats functions and template functions together in this regard:
Given a set of declarations in a single declarative region, each of which specifies the same unqualified name,
- they shall all refer to the same entity, or all refer to functions and function templates; or
- exactly one declaration shall declare a class name or enumeration name that is not a typedef name and the other declarations shall all refer to the same object or enumerator, or all refer to functions and function templates; in this case the class name or enumeration name is hidden
John Spicer: You should be able to take an existing program and replace an existing function with a function template without breaking unrelated parts of the program. In addition, all of the compilers I tried allow this usage (EDG, Sun, egcs, Watcom, Microsoft, Borland). I would recommend that function templates be handled exactly like functions for purposes of name hiding.
Martin O'Riordan: I don't see any justification for extending the purview of what is decidedly a hack, just for the sake of consistency. In fact, I think we should go further and in the interest of consistency, we should deprecate the hack, scheduling its eventual removal from the C++ language standard.
The hack is there to allow old C programs and especially the 'stat.h' file to compile with minimum effort (also several other Posix and X headers). People changing such older programs have ample opportunity to "do it right". Indeed, if you are adding templates to an existing program, you should probably be placing your templates in a 'namespace', so the issue disappears anyway. The lookup rules should be able to provide the behaviour you need without further hacking.
Is the following well-formed?
class policy {};
class policy_interface {};
template <class POLICY_INTERFACE>
class aph {
protected:
typedef POLICY_INTERFACE PI;
};
template <class POLICY, class BASE, class PI = typename BASE::PI>
class ConcretePolicyHolder : public BASE, protected POLICY
{};
ConcretePolicyHolder < policy , aph < policy_interface > > foo;
void xx() { }
The issue is whether the access to the default argument type BASE::PI is checked before or after it is known that BASE is a base class of the template. To some extent, one needs to develop the list of template arguments (and therefore evaluate the default argument) before one can instantiate the template, and one does not know what base classes the template has until it has been instantiated.
The following is the wording from 14.2 temp.names paragraphs 4 and 5 that discusses the use of the "template" keyword following . or -> and in qualified names.
class X {
public:
template<std::size_t> X* alloc();
template<std::size_t> static X* adjust();
};
template<class T> void f(T* p) {
T* p1 = p->alloc<200>();
// ill-formed: < means less than
T* p2 = p->template alloc<200>();
// OK: < starts template argument list
T::adjust<100>();
// ill-formed: < means less than
T::template adjust<100>();
// OK: < starts explicit qualification
}
—end example]
If a name prefixed by the keyword template is not the name of a member template, the program is ill-formed. [Note: the keyword template may not be applied to non-template members of class templates. ]
The whole point of this feature is to say that the "template" keyword is needed to indicate that a "<" begins a template parameter list in certain contexts. The constraints in paragraph 5 leave open to debate certain cases.First, I think it should be made more clear that the template name must be followed by a template argument list when the "template" keyword is used in these contexts. If we don't make this clear, we would have to add several semantic clarifications instead. For example, if you say "p->template f()", and "f" is an overload set containing both templates and nontemplates: a) is this valid? b) are the nontemplates in the overload set ignored? If the user is forced to write "p->template f<>()" it is clear that this is valid, and it is equally clear that nontemplates in the overload set are ignored. As this feature was added purely to provide syntactic guidance, I think it is important that it otherwise have no semantic implications.
I propose that paragraph 5 be modified to:
(See also issue 30 and document J16/00-0008 = WG21 N1231.)
Notes from 04/00 meeting:
The discussion of this issue revived interest in issues 11 and 109.
By analogy with typename, the keyword template used to indicate that a dependent name will be a template name should be optional in contexts where a type is required, e.g., base class lists. We could also consider member and parameter declarations.
This was suggested by issue 314.
The standard does not permit a null value to be used as a nontype template argument for a nontype template parameter that is a pointer.
This code is accepted by EDG, Microsoft, Borland and Cfront, but rejected by g++ and Sun:
template <int *p> struct A {};
A<(int*)0> ai;
I'm not sure this was ever explicitly considered by the committee. Is there any reason to permit this kind of usage?
Jason Merrill: I suppose it might be useful for a program to be able to express a degenerate case using a null template argument. I think allowing it would be harmless.
According to 14.5.2 temp.mem paragraph 4,
A specialization of a member function template does not override a virtual function from a base class.Bill Gibbons: I think that's sufficiently surprising behavior that it should be ill-formed instead.
As I recall, the main reason why a member function template cannot be virtual is that you can't easily construct reasonable vtables for an infinite set of functions. That doesn't apply to overrides.
Another problem is that you don't know that a specialization overrides until the specialization exists:
struct A {
virtual void f(int);
};
struct B : A {
template<class T> void f(T); // does this override?
};
But this could be handled by saying:
template<int I> struct X;
struct A {
virtual void f(A<5>);
};
struct B : A {
template<int I, int J> void f(A<I+J>); // does not overrride
};
void g(B *b) {
X<t> x;
b->f<3,2>(x); // specialization B::f(A<5>) makes program ill-formed
}
So I think there are reasonable semantics. But is it useful?
If not, I think the creation of a specialization that would have been an override had it been declared in the class should be an error.
Daveed Vandevoorde: There is real code out there that is written with this rule in mind. Changing the standard on them would not be good form, IMO.
Mike Ball: Also, if you allow template functions to be specialized outside of the class you introduce yet another non-obvious ordering constraint.
Please don't make such a change after the fact.
John Spicer: This is the result of an explicit committee decision. The reason for this rule is that it is too easy to unwittingly override a function from a base class, which was probably not what was intended when the template was written. Overriding should be a conscious decision by the class writer, not something done accidentally by a template.
Rationale (10/99): The Standard correctly reflects the intent of the Committee.
Notes from October 2002 meeting:
This was reopened because of a discussion while reviewing possible extensions.
Library issue 225 poses the following questions:
For example, a programmer might want to provide a version of std::swap that would be used for any specialization of a particular class template. It is possible to do that for specific types, but not for all specializations of a template.
The problem is due to the fact that programmers are forbidden to add overloads to namespace std, although specializations are permitted. One suggested solution would be to allow partial specialization of function templates, analogous to partial specialization of class templates.
Library issue 225 contains a detailed proposal for adding partial specialization of function templates (not reproduced here in the interest of space and avoiding multiple-copy problems). This Core issue is being opened to provide for discussion of the proposal within the core language working group.
Notes from 10/00 meeting:
A major concern over the idea of partial specialization of function templates is that function templates can be overloaded, unlike class templates. Simply naming the function template in the specialization, as is done for class specialization, is not adequate to identify the template being specialized.
In view of this problem, the library working group is exploring the other alternative, permitting overloads to be added to functions in namespace std, as long as certain restrictions (to be determined) are satisfied.
(See also documents N1295 and N1296 and issue 285.)
Notes from 10/01 meeting:
The Core Working Group decided to ask the Library Working Group for guidance on whether this feature is still needed to resolve a library issue. The answer at present is "we don't know."
I get the following error diagnostic [from the EDG front end]:
line 8: error: function template "example<T>::foo<R,A>(A)" has
already been declared
R foo(const A);
^
when compiling this piece of code:
struct example {
template<class R, class A> // 1-st member template
R foo(A);
template<class R, class A> // 2-nd member template
const R foo(A&);
template<class R, class A> // 3-d member template
R foo(const A);
};
/*template<> template<>
int example<char>::foo(int&);*/
int main()
{
int (example<char>::* pf)(int&) =
&example<char>::foo;
}
The implementation complains that
template<class R, class A> // 1-st member template R foo(A); template<class R, class A> // 3-d member template R foo(const A);cannot be overloaded and I don't see any reason for it since it is function template specializations that are treated like ordinary non-template functions, meaning that the transformation of a parameter-declaration-clause into the corresponding parameter-type-list is applied to specializations (when determining its type) and not to function templates.
What makes me think so is the contents of 14.5.5.1 temp.over.link and the following sentence from 14.8.2.1 temp.deduct.call "If P is a cv-qualified type, the top level cv-qualifiers of P are ignored for type deduction". If the transformation was to be applied to function templates, then there would be no reason for having that sentence in 14.8.2.1 temp.deduct.call.
14.8.2.2 temp.deduct.funcaddr, which my example is based upon, says nothing about ignoring the top level cv-qualifiers of the function parameters of the function template whose address is being taken.
As a result, I expect that template argument deduction will fail for the 2-nd and 3-d member templates and the 1-st one will be used for the instantiation of the specialization.
Issue 1:
14.5.5.2 temp.func.order paragraph 2 says:
Given two overloaded function templates, whether one is more specialized than another can be determined by transforming each template in turn and using argument deduction (14.8.2 temp.deduct ) to compare it to the other.14.8.2 temp.deduct now has 4 subsections describing argument deduction in different situations. I think this paragraph should point to a subsection of 14.8.2 temp.deduct .
Rationale:
This is not a defect; it is not necessary to pinpoint cross-references to this level of detail.
Issue 2:
14.5.5.2 temp.func.order paragraph 4 says:
Using the transformed function parameter list, perform argument deduction against the other function template. The transformed template is at least as specialized as the other if, and only if, the deduction succeeds and the deduced parameter types are an exact match (so the deduction does not rely on implicit conversions).In "the deduced parameter types are an exact match", the terms exact match do not make it clear what happens when a type T is compared to the reference type T&. Is that an exact match?
Issue 3:
14.5.5.2 temp.func.order paragraph 5 says:
A template is more specialized than another if, and only if, it is at least as specialized as the other template and that template is not at least as specialized as the first.What happens in this case:
template<class T> void f(T,int);
template<class T> void f(T, T);
void f(1,1);
For the first function template, there is no type deduction for the second
parameter. So the rules in this clause seem to imply that the second function
template will be chosen.
Rationale:
This is not a defect; the standard unambiguously makes the above example ill-formed due to ambiguity.
P. J. Plauger, among others, has noted that typename is hard to use, because in a given context it's either required or forbidden, and it's often hard to tell which. It would make life easier for programmers if typename could be allowed in places where it is not required, e.g., outside of templates.
The standard prohibits a class template from having the same name as one of its template parameters (14.6.1 temp.local paragraph 4). This prohibits
template <class X> class X;
for the reason that the template name would hide the parameter, and
such hiding is in general prohibited.
Presumably, we should also prohibit
template <template <class T> class T> struct A;
for the same reason.
Is the comma expression in the following dependent?
template <class T> static void f(T)
{
}
template <class T> void g(T)
{
f((T::x, 0));
}
struct A {
static int x;
};
void h()
{
g(A());
}
According to the standard, it is, because 14.6.2.2 temp.dep.expr says that an expression is dependent if any of its sub-expressions is dependent, but there is a question about whether the language should say something different. The type and value of the expression are not really dependent, and similar cases (like casting T::x to int) are not dependent.
template <class T> class Foo {
public:
typedef int Bar;
Bar f();
};
template <class T> typename Foo<T>::Bar Foo<T>::f() { return 1;}
--------------------
In the class template definition, the declaration of the member function
is interpreted as:
int Foo<T>::f();In the definition of the member function that appears outside of the class template, the return type is not known until the member function is instantiated. Must the return type of the member function be known when this out-of-line definition is seen (in which case the definition above is ill-formed)? Or is it OK to wait until the member function is instantiated to see if the type of the return type matches the return type in the class template definition (in which case the definition above is well-formed)?
Suggested resolution: (John Spicer)
My opinion (which I think matches several posted on the reflector recently) is that the out-of-class definition must match the declaration in the template. In your example they do match, so it is well formed.
I've added some additional cases that illustrate cases that I think either are allowed or should be allowed, and some cases that I don't think are allowed.
template <class T> class A { typedef int X; };
template <class T> class Foo {
public:
typedef int Bar;
typedef typename A<T>::X X;
Bar f();
Bar g1();
int g2();
X h();
X i();
int j();
};
// Declarations that are okay
template <class T> typename Foo<T>::Bar Foo<T>::f()
{ return 1;}
template <class T> typename Foo<T>::Bar Foo<T>::g1()
{ return 1;}
template <class T> int Foo<T>::g2() { return 1;}
template <class T> typename Foo<T>::X Foo<T>::h() { return 1;}
// Declarations that are not okay
template <class T> int Foo<T>::i() { return 1;}
template <class T> typename Foo<T>::X Foo<T>::j() { return 1;}
In general, if you can match the declarations up using only information
from the template, then the declaration is valid.
Declarations like Foo::i and Foo::j are invalid because for a given instance of A<T>, A<T>::X may not actually be int if the class is specialized.
This is not a problem for Foo::g1 and Foo::g2 because for any instance of Foo<T> that is generated from the template you know that Bar will always be int. If an instance of Foo is specialized, the template member definitions are not used so it doesn't matter whether a specialization defines Bar as int or not.
The example in 14.6.5 temp.inject paragraph 2 is incorrect:
template<typename T> class number {
number(int);
//...
friend number gcd(number& x, number& y) { /* ... */ }
//...
};
void g()
{
number<double> a(3), b(4);
//...
a = gcd(a,b); // finds gcd because number<double> is an
// associated class, making gcd visible
// in its namespace (global scope)
b = gcd(3,4); // ill-formed; gcd is not visible
}
Regardless of the last statement ("b = gcd(3,4);"), the above code is ill-formed:
a) number's constructor is private;
b) the definition of (non-void) friend 'gcd' function does not contain a return statement.
Proposed resolution:
change the example to read:
template<typename T> class number {
public:
number(int);
//...
friend number gcd(number& x, number& y);
//...
};
void g()
{
number<double> a(3), b(4);
//...
a = gcd(a,b); // finds gcd because number<double> is an
// associated class, making gcd visible
// in its namespace (global scope)
b = gcd(3,4); // ill-formed; gcd is not visible
}
Three points have been raised where the wording in 14.7.1 temp.inst may not be sufficiently clear.
A class template specialization is implicitly instantiated... if the completeness of the class type affects the semantics of the program...
It is not clear what it means for the "completeness... [to affect] the semantics." Consider the following example:
template<class T> struct A;
extern A<int> a;
void *foo() { return &a; }
template<class T> struct A
{
#ifdef OPTION
void *operator &() { return 0; }
#endif
};
The question here is whether it is necessary for template class A to declare an operator & for the semantics of the program to be affected. If it does not do so, the meaning of &a will be the same whether the class is complete or not and thus arguably the semantics of the program are not affected.
Presumably what was intended is whether the presence or absence of certain member declarations in the template class might be relevant in determining the meaning of the program. A clearer statement may be desirable.
If the overload resolution process can determine the correct function to call without instantiating a class template definition, it is unspecified whether that instantiation actually takes place.
The intent of this wording, as illustrated in the example in that paragraph, is to allow a "smart" implementation not to instantiate class templates if it can determine that such an instantiation will not affect the result of overload resolution, even though the algorithm described in clause 13 over requires that all the viable functions be enumerated, including functions that might be found as members of specializations.
Unfortunately, the looseness of the wording allowing this latitude for implementations makes it unclear what "the overload resolution process" is — is it the algorithm in 13 over or something else? — and what "the correct function" is.
If an implicit instantiation of a class template specialization is required and the template is declared but not defined, the program is ill-formed.
Here, it is not clear what conditions "require" an implicit instantiation. From the context, it would appear that the intent is to refer to the conditions in paragraph 4 that cause a specialization to be instantiated.
This interpretation, however, leads to different treatment of template and non-template incomplete classes. For example, by this interpretation,
class A;
template <class T> struct TA;
extern A a;
extern TA<int> ta;
void f(A*);
void f(TA<int>*);
int main()
{
f(&a); // well-formed; undefined if A
// has operator &() member
f(&ta); // ill-formed: cannot instantiate
}
A different approach would be to understand "required" in paragraph 6 to mean that a complete type is required in the expression. In this interpretation, if an incomplete type is acceptable in the context and the class template definition is not visible, the instantiation is not attempted and the program is well-formed.
The meaning of "required" in paragraph 6 must be clarified.
Notes on 10/01 meeting:
It was felt that item 1 is solved by addition of the word "might" in the resolution for issue 63; item 2 is not much of a problem; and item 3 could be solved by changing "required" to "required to be complete".
In 14.7.2 temp.explicit paragraph 7 we read:
The explicit instantiation of a class template specialization implies the instantiation of all of its members not previously explicitly specialized in the translation unit containing the explicit instantiation.
Is "member" intended to mean "non-inherited member?" If yes, maybe it should be clarified since 10 class.derived paragraph 1 says,
Unless redefined in the derived class, members of a base class are also considered to be members of the derived class.
14.7.2 temp.explicit defines an explicit instantiation as
Syntactically, that allows things like:
template int S<int>::i = 5, S<int>::j = 7;
which isn't what anyone actually expects. As far as I can tell, nothing in the standard explicitly forbids this, as written. Syntactically, this also allows:
template namespace N { void f(); }
although perhaps the surrounding context is enough to suggest that this is invalid.
Suggested resolution:
I think we should say:
[Steve Adamczyk: presumably, this should have template at the beginning.]
and then say that:
There are similar problems in 14.7.3 temp.expl.spec:
Here, I think we want:
with similar restrictions as above.
[Steve Adamczyk: This also needs to have template <> at the beginning, possibly repeated.]
The note in paragraph 5 of 14.8.1 temp.arg.explicit makes clear that explicit template arguments cannot be supplied in invocations of constructors and conversion functions because they are called without using a name. However, there is nothing in the current wording of the Standard that makes declaring a constructor or conversion operator that is unusable because of nondeduced parameters (i.e., that would need to be specified explicitly) ill-formed. It would be a service to the programmer to diagnose this useless construct as early as possible.
Nicolai Josuttis sent me an example like the following:
template <typename RET, typename T1, typename T2>
const RET& min (const T1& a, const T2& b)
{
return (a < b ? a : b);
}
template const int& min<int>(const int&,const int&); // #1
template const int& min(const int&,const int&); // #2
Among the questions was whether explicit instantiation #2 is valid, where deduction is required to determine the type of RET.
The first thing I realized when researching this is that the standard does not really spell out the rules for deduction in declarative contexts (friend declarations, explicit specializations, and explicit instantiations). For explicit instantiations, 14.7.2 temp.explicit paragraph 2 does mention deduction, but it doesn't say which set of deduction rules from 14.8.2 temp.deduct should be applied.
Second, Nicolai pointed out that 14.7.2 temp.explicit paragraph 6 says
A trailing template-argument can be left unspecified in an explicit instantiation provided it can be deduced from the type of a function parameter (14.8.2 temp.deduct).
This prohibits cases like #2, but I believe this was not considered in the wording as there is no reason not to include the return type in the deduction process.
I think there may have been some confusion because the return type is excluded when doing deduction on a function call. But there are contexts where the return type is included in deduction, for example, when taking the address of a function template specialization.
Suggested resolution:
Andrei Iltchenko points out that the standard has no wording that defines how to determine which template is specialized by an explicit specialization of a function template. He suggests "template argument deduction in such cases proceeds in the same way as when taking the address of a function template, which is described in 14.8.2.2 temp.deduct.funcaddr."
John Spicer points out that the same problem exists for all similar declarations, i.e., friend declarations and explicit instantiation directives. Finding a corresponding placement operator delete may have a similar problem.
John Spicer: There are two aspects of "determining which template" is referred to by a declaration: determining the function template associated with the named specialization, and determining the values of the template arguments of the specialization.
template <class T> void f(T); #1
template <class T> void f(T*); #2
template <> void f(int*);
In other words, which f is being specialized (#1 or #2)? And then, what are the deduced template arguments?
14.5.5.2 temp.func.order does say that partial ordering is done in contexts such as this. Is this sufficient, or do we need to say more about the selection of the function template to be selected?
14.8.2 temp.deduct probably needs a new section to cover argument deduction for cases like this.
The following example (simplified from a posting to comp.lang.c++.moderated) is accepted by some compilers (e.g., EDG), but not by other (e.g., g++).
struct S {
static int const I = 42;
};
template<int N> struct X {};
template<typename T> void f(X<T::I>*) {}
template<typename T> void f(X<T::J>*) {}
int main() {
f<S>(0);
}
The wording in the standard that normally would cover this (third sub-bullet in 14.8.2 temp.deduct paragraph 2) says:
Attempting to use a type in the qualifier portion of a qualified name that names a type when that type does not contain the specified member, or if the specified member is not a type where a type is required.(emphasis mine). If the phrase "that names a type" applies to "a qualified name," then the example is invalid. If it applies to "the qualifier portion," then it is valid (because the second candidate is simply discarded).
I suspect we want this example to work. Either way, I believe the sub-bullet deserves clarification.
I have a question about exception handling with respect to derived to base conversions of pointers caught by reference.
What should the result of this program be?
struct S {};
struct SS : public S {};
int main()
{
SS ss;
int result = 0;
try
{
throw &ss; // throw object has type SS*
// (pointer to derived class)
}
catch (S*& rs) // (reference to pointer to base class)
{
result = 1;
}
catch (...)
{
result = 2;
}
return result;
}
The wording of 15.3 except.handle paragraph 3 would seem to say that the catch of S*& does not match and so the catch ... would be taken.
All of the compilers I tried (EDG, g++, Sun, and Microsoft) used the catch of S*& though.
What do we think is the desired behavior for such cases?
My initial reaction is that this is a bug in all of these compilers, but the fact that they all do the same thing gives me pause.
On a related front, if the handler changes the parameter using the reference, what is caught by a subsequent handler?
extern "C" int printf(const char *, ...);
struct S {};
struct SS : public S {};
SS ss;
int f()
{
try
{
throw &ss;
}
catch (S*& rs) // (reference to pointer to base class)
{
rs = 0;
throw;
}
catch (...)
{
}
return 0;
}
int main()
{
try { f(); }
catch (S*& rs) {
printf("rs=%p, &ss=%p\n", rs, &ss);
}
}
EDG, g++, and Sun all catch the original (unmodified) value. Microsoft catches the modified value. In some sense the EDG/g++/Sun behavior makes sense because the later catch could catch the derived class instead of the base class, which would be difficult to do if you let the catch clause update the value to be used by a subsequent catch.
But on this non-pointer case, all of the compilers later catch the modified value:
extern "C" int printf(const char *, ...);
int f()
{
try
{
throw 1;
}
catch (int& i)
{
i = 0;
throw;
}
catch (...)
{
}
return 0;
}
int main()
{
try { f(); }
catch (int& i) {
printf("i=%p\n", i);
}
}
To summarize:
It was tentatively agreed at the Santa Cruz meeting that exception specifications should fully participate in the type system. This change would address gaps in the current static checking of exception specifications such as
void (*p)() throw(int);
void (**pp)() throw() = &p; // not currently an error
This is such a major change that it deserves to be a separate issue.
See also issues 25, 87, and 133.
Destructors that throw can easily cause programs to terminate, with no possible defense. Example: Given
struct XY { X x; Y y; };
Assume that X::~X() is the only destructor in the entire program that can throw. Assume further that Y construction is the only other operation in the whole program that can throw. Then XY cannot be used safely, in any context whatsoever, period — even simply declaring an XY object can crash the program:
XY xy; // construction attempt might terminate program:
// 1. construct x -- succeeds
// 2. construct y -- fails, throws exception
// 3. clean up by destroying x -- fails, throws exception,
// but an exception is already active, so call
// std::terminate() (oops)
// there is no defense
So it is highly dangerous to have even one destructor that could throw.
Suggested Resolution:
Fix the above problem in one of the following two ways. I prefer the first.
Fergus Henderson: I disagree. Code using XY may well be safe, if X::~X() only throws if std::uncaught_exception() is false.
I think the current exception handling scheme in C++ is certainly flawed, but the flaws are IMHO design flaws, not minor technical defects, and I don't think they can be solved by minor tweaks to the existing design. I think that at this point it is probably better to keep the standard stable, and learn to live with the existing flaws, rather than trying to solve them via TC.
Bjarne Stroustrup: I strongly prefer to have the call to std::terminate() be conforming. I see std::terminate() as a proper way to blow away "the current mess" and get to the next level of error handling. I do not want that escape to be non-conforming — that would imply that programs relying on a error handling based on serious errors being handled by terminating a process (which happens to be a C++ program) in std::terminate() becomes non-conforming. In many systems, there are — and/or should be — error-handling and recovery mechanisms beyond what is offered by a single C++ program.
Andy Koenig: If we were to prohibit writing a destructor that can throw, how would I solve the following problem?
I want to write a class that does buffered output. Among the other properties of that class is that destroying an object of that class writes the last buffer on the output device before freeing memory.
What should my class do if writing that last buffer indicates a hardware output error? My user had the option to flush the last buffer explicitly before destroying the object, but didn't do so, and therefore did not anticipate such a problem. Unfortunately, the problem happened anyway. Should I be required to suppress this error indication anyway? In all cases?
In practice, I would rather thrown an exception, even at the risk of crashing the program if we happen to be in the middle of stack unwinding. The reason is that the program would crash only if a hardware error occurred in the middle of cleaning up from some other error that was in the process of being handled. I would rather have such a bizarre coincidence cause a crash, which stands a chance of being diagnosed later, than to be ignored entirely and leave the system in a state where the ignore error could cause other trouble later that is even harder to diagnose.
If I'm not allowed to throw an exception when I detect this problem, what are my options?
Herb Sutter: I understand that some people might feel that "a failed dtor during stack unwinding is preferable in certain cases" (e.g., when recovery can be done beyond the scope of the program), but the problem is "says who?" It is the application program that should be able to decide whether or not such semantics are correct for it, and the problem here is that with the status quo a program cannot defend itself against a std::terminate() — period. The lower-level code makes the decision for everyone. In the original example, the mere existence of an XY object puts at risk every program that uses it, whether std::terminate() makes sense for that program or not, and there is no way for a program to protect itself.
That the "it's okay if the process goes south should a rare combination of things happen" decision should be made by lower-level code (e.g., X dtor) for all apps that use it, and which doesn't even understand the context of any of the hundreds of apps that use it, just cannot be correct.
(See also issue 265.)
In clause 16 cpp, paragraph 1, the control-line non-terminal symbol is defined in terms of the identifier-list non-terminal, which is never defined within the standard document.
The same definition is repeated in clause A.14 gram.cpp.
I suggest that the following definition is added to clause 16 cpp, paragraph 1, after the one for replacement-list:
This should be repeated again in clause A.14 gram.cpp, again after the one for replacement-list. It might also be desirable to include a third repetition in clause 16.3 cpp.replace, paragraph 9.
It is not clear from the Standard what the result of the following example should be:
#define NIL(xxx) xxx
#define G_0(arg) NIL(G_1)(arg)
#define G_1(arg) NIL(arg)
G_0(42)
The relevant text from the Standard is found in 16.3.4 cpp.rescan paragraph 2:
If the name of the macro being replaced is found during this scan of the replacement list (not including the rest of the source file's preprocessing tokens), it is not replaced. Further, if any nested replacements encounter the name of the macro being replaced, it is not replaced. These nonreplaced macro name preprocessing tokens are no longer available for further replacement even if they are later (re)examined in contexts in which that macro name preprocessing token would otherwise have been replaced.
The sequence of expansion of G0(42) is as follows:
G0(42) NIL(G_1)(42) G_1(42) NIL(42)
The question is whether the use of NIL in the last line of this sequence qualifies for non-replacement under the cited text. If it does, the result will be NIL(42). If it does not, the result will be simply 42.
The original intent of the J11 committee in this text was that the result should be 42, as demonstrated by the original pseudo-code description of the replacement algorithm provided by Dave Prosser, its author. The English description, however, omits some of the subtleties of the pseudo-code and thus arguably gives an incorrect answer for this case.
Suggested resolution (Mike Miller): Replace the cited paragraph with the following:
As long as the scan involves only preprocessing tokens from a given macro's replacement list, or tokens resulting from a replacement of those tokens, an occurrence of the macro's name will not result in further replacement, even if it is later (re)examined in contexts in which that macro name preprocessing token would otherwise have been replaced.
Once the scan reaches the preprocessing token following a macro's replacement list — including as part of the argument list for that or another macro — the macro's name is once again available for replacement. [Example:
#define NIL(xxx) xxx #define G_0(arg) NIL(G_1)(arg) #define G_1(arg) NIL(arg) G_0(42) // result is 42, not NIL(42)The reason that NIL(42) is replaced is that (42) comes from outside the replacement list of NIL(G_1), hence the occurrence of NIL within the replacement list for NIL(G_1) (via the replacement of G_1(42)) is not marked as nonreplaceable. —end example]
(Note: The resolution of this issue must be coordinated with J11/WG14.)
During the discussion of issues 167 and 174, it became apparent that there was no consensus on the meaning of deprecation. Some thought that deprecating a feature reflected an intent to remove it from the language. Others viewed it more as an encouragement to programmers not to use certain constructs, even though they might be supported in perpetuity.
There is a formal-sounding definition of deprecation in Annex D depr paragraph 2:
deprecated is defined as: Normative for the current edition of the Standard, but not guaranteed to be part of the Standard in future revisions.However, this definition would appear to say that any non-deprecated feature is "guaranteed to be part of the Standard in future revisions." It's not clear that that implication was intended, so this definition may need to be amended.
This issue is intended to provide an avenue for discussing and resolving those questions, after which the original issues may be reopened if that is deemed desirable.
The list of identifier characters specified in the C++ standard annex E extendid and the C99 standard annex D are different. The C99 standard includes more characters.
The C++ standard says that the characters are from "ISO/IEC PDTR 10176" while the C99 standard says "ISO/IEC TR 10176". I'm guessing that the PDTR is an earlier draft of the TR.
Should the list in the C++ standard be updated?
Tom Plum: In my opinion, the "identifier character" issue has not been resolved with certainty within SC22.
One critical difference in C99 was the decision to allow a compiler to accept more characters than are given in the annex. This allows for future expansion.
The broader issue concerns the venue in which the "identifier character" issue will receive ongoing resolution.
Notes from 10/00 meeting:
The core language working group expressed a strong preference (13/0/5 in favor/opposed/abstaining) that the list of identifier characters should be extensible, as is the case in C99. However, the fact that this topic is under active discussion by other bodies was deemed sufficient reason to defer any changes to the C++ specification until the situation is more stable.