| Document number: | PL22.16/08-0224 = WG21 N2714 |
| Date: | 2008-08-25 |
| Project: | Programming Language C++ |
| Reference: | ISO/IEC IS 14882:2003 |
| Reply to: | William M. Miller |
| Edison Design Group, Inc. | |
| wmm@edg.com |
This document contains the C++ core language issues on which the Committee (J16 + WG21) has not yet acted, that is, 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:
Section references in this document reflect the section numbering of document PL22.16/08-0201 = WG21 N2691.
The purpose of these documents is to record the disposition of issues that have come before the Core Language Working Group of the ANSI (J16) and ISO (WG21) C++ Standard Committee.
Some issues represent potential defects in the ISO/IEC IS 14882:2003 document and corrected defects in the earlier ISO/IEC 14882:1998 document; others refer to text in the working draft for the next revision of the C++ language, commonly known as C++0x, and not to any Standard text. Issues 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.open-std.org/jtc1/sc22/wg21. Requests for further information about these documents should include the document number, reference ISO/IEC 14882:2003, and be submitted to the InterNational Committee for Information Technology Standards (INCITS), 1250 Eye Street NW, Suite 200, 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.comeaucomputing.com/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 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.
TC1: A DR issue included in Technical Corrigendum 1. TC1 is a revision of the Standard issued in 2003.
WP: A DR issue whose resolution is reflected in the current Working Paper. The Working Paper is a draft for a future version of the Standard.
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. 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 as an extension proposal.
In 1.9 [intro.execution] paragraph 16, the following expression is still listed as an example of undefined behavior:
i = ++i + 1;
However, it appears that the new sequencing rules make this expression well-defined:
The assignment side-effect is required to be sequenced after the value computations of both its LHS and RHS (5.17 [expr.ass] paragraph 1).
The LHS (i) is an lvalue, so its value computation involves computing the address of i.
In order to value-compute the RHS (++i + 1), it is necessary to first value-compute the lvalue expression ++i and then do an lvalue-to-rvalue conversion on the result. This guarantees that the incrementation side-effect is sequenced before the computation of the addition operation, which in turn is sequenced before the assignment side effect. In other words, it yields a well-defined order and final value for this expression.
It should be noted that a similar expression
i = i++ + 1;
is still not well-defined, since the incrementation side-effect remains unsequenced with respect to the assignment side-effect.
It's unclear whether making the expression in the example well-defined was intentional or just a coincidental byproduct of the new sequencing rules. In either case either the example should be fixed, or the rules should be changed.
Clark Nelson: In my opinion, the poster's argument is perfectly correct. The rules adopted reflect the CWG's desired outcome for issue 222. At the Portland meeting, I presented (and still sympathize with) Tom Plum's case that these rules go a little too far in nailing down required behavior; this is a consequence of that.
One way or another, a change needs to be made, and I think we should seriously consider weakening the resolution of issue 222 to keep this example as having undefined behavior. This could be done fairly simply by having the sequencing requirements for an assignment expression depend on whether it appears in an lvalue context.
James Widman: How's this for a possible re-wording?
In all cases, the side effect of the assignment expression is sequenced after the value computations of the right and left operands. Furthermore, if the assignment expression appears in a context where an lvalue is required, the side effect of the assignment expression is sequenced before its value computation.
Notes from the February, 2008 meeting:
There was no real support in the CWG for weakening the resolution of issue 222 and returning the example to having undefined behavior. No one knew of an implementation that doesn't already do the (newly) right thing for such an example, so there was little motivation to go out of our way to increase the domain of undefined behavior. So the proposed resolution is to change the example to one that definitely does have undependable behavior in existing practice, and undefined behavior under the new rules.
Also, the new formulation of the sequencing rules approved in Oxford contained the wording that by and large resolved issue 222, so with the resolution of this issue, we can also close issue 222.
Proposed resolution (March, 2008):
Change the example in 1.9 [intro.execution] paragraph 16 as follows:
i = v[i++]; // the behavior is undefined
i = 7, i++, i++; // i becomes 9
i = ++i i++ + 1; // the behavior is undefined
i = i + 1; // the value of i is incremented
Is the behavior undefined in the following example?
void f() {
int n = 0;
n = --n;
}
1.9 [intro.execution] paragraph 16 says,
If a side effect on a scalar object is unsequenced relative to either a different side effect on the same scalar object or a value computation using the value of the same scalar object, the behavior is undefined.
It's not clear to me whether the two side-effects in n=--n are “different.” As far as I can tell, it seems that both side-effects involve the assignment of -1 to n, which in a sense makes them non-“different.” But I don't know if that's the intent. Would it be better to say “another” instead of “a different?”
On a related note, can we include this example to illustrate?
void f( int, int );
void g( int a ) { f( a = -1, a = -1 ); } // Undefined?
Proposed resolution (March, 2008):
Change 1.9 [intro.execution] paragraph 16 as follows:
...If a side effect on a scalar object is unsequenced relative to either
a differentanother side effect on the same scalar object or a value computation using the value of the same scalar object, the behavior is undefined. [Example:void f(int, int); void g(int i, int* v) { i = v[i++]; // the behavior is undefined i = 7, i++, i++; // i becomes 9 i = ++i + 1; // the behavior is undefined i = i + 1; // the value of i is incremented f(i = -1, i = -1); // the behavior is undefined }—end example] When calling...
Deallocation functions can't be virtual because they are static member functions; however, according to 12.5 [class.free] paragraph 7, they behave like virtual functions when the class's destructor is virtual:
Since member allocation and deallocation functions are static they cannot be virtual. [Note: however, when the cast-expression of a delete-expression refers to an object of class type, because the deallocation function actually called is looked up in the scope of the class that is the dynamic type of the object, if the destructor is virtual, the effect is the same.
Because the intent is to make any use of a deleted function diagnosable at compile time, a virtual deleted function can neither override nor be overridden by a non-deleted function, as described in 10.3 [class.virtual] paragraph 14:
A function with a deleted definition (8.4 [dcl.fct.def]) shall not override a function that does not have a deleted definition. Likewise, a function that does not have a deleted definition shall not override a function with a deleted definition.
One would assume that a similar kind of prohibition is needed for deallocation functions in a class hierarchy with virtual destructors, but it's not clear that the current specification says that. 8.4 [dcl.fct.def] paragraph 10 says,
A program that refers to a deleted function implicitly or explicitly, other than to declare it, is ill-formed.
Furthermore, the deallocation function is looked up at the point of definition of a virtual destructor (12.4 [class.dtor] paragraph 11), and the function found by this lookup is considered to be “used” (3.2 [basic.def.odr] paragraph 2). However, it's not completely clear that this “use” constitutes a “reference” in the sense of 8.4 [dcl.fct.def] paragraph 10, especially in a program in which an object of a type that would call that deallocation function is never deleted.
Suggested resolution:Augment the list of lookup results from a virtual destructor that render a program ill-formed in 12.4 [class.dtor] paragraph 10 to include a deleted function:
If the result of this lookup is ambiguous or inaccessible, or if the lookup selects a placement deallocation function or a function with a deleted definition (8.4 [dcl.fct.def]), the program is ill-formed.
Proposed resolution (June, 2008):
Change 12.4 [class.dtor] paragraph 10 as follows:
If the result of this lookup is ambiguous or inaccessible, or if the lookup selects a placement deallocation function or a function with a deleted definition (8.4 [dcl.fct.def]), the program is ill-formed.
In order for two template-ids to refer to the same function, 14.4 [temp.type] paragraph 1, bullet 1 requires that
their template-names refer to the same template
This makes it impossible for two template-ids referring to operator function templates to be equivalent, because only simple-template-ids have a template-name, and a template-id referring to an operator function template is not a simple-template-id (14.2 [temp.names] paragraph 1).
Suggested resolution:
Change 14.4 [temp.type] paragraph 1, bullet 1 to read,
their template-names or operator-function-ids refer to the same template
Proposed resolution (June, 2008):
Change 14.4 [temp.type] paragraph 1, first bullet, as follows:
their template-names or operator-function-ids refer to the same template, and
The requirements on an implementation when presented with an alignment-specifier not supported by that implementation in that context are contradictory: 3.11 [basic.align] paragraph 9 says,
If a request for a specific extended alignment in a specific context is not supported by an implementation, the implementation may reject the request as ill-formed. The implementation may also silently ignore the requested alignment.
In contrast, 7.1.7 [dcl.align] paragraph 2, bullet 4 says simply,
- if the constant expression evaluates to an extended alignment and the implementation does not support that alignment in the context of the declaration, the program is ill-formed
with no provision to “silently ignore” the requested alignment. These two passages need to be reconciled.
If the outcome of the reconciliation is to grant implementations the license to accept and ignore extended alignment requests, the specification should be framed in terms of mechanisms that already exist in the Standard, such as undefined behavior and/or conditionally-supported constructs; “ill-formed” is a category that is defined by the Standard, not something that an implementation can decide.
Notes from the February, 2008 meeting:
The consensus was that such requests should be ill-formed and require a diagnostic. However, it was also observed that an implementation need not reject an ill-formed program; the only requirement is that it issue a diagnostic. It would thus be permissible for an implementation to “noisily ignore” (as opposed to “silently ignoring”) an unsupported alignment request.
Proposed resolution (June, 2008):
Change 3.11 [basic.align] paragraph 9 as follows:
If a request for a specific extended alignment in a specific context is not supported by an implementation, theimplementation may reject the request asprogram is ill-formed.The implementation may also silently ignore the requested alignment. [Note: aAdditionally, a request for runtime allocation of dynamicmemorystorage for which the requested alignment cannot be honoredmayshall be treated as an allocation failure.—end note]
In ISO/IEC 14882:2003, the second bullet of 3.8 [basic.life] paragraph 1 reads,
if T is a class type with a non-trivial constructor (12.1 [class.ctor]), the constructor call has completed.
Issue 119 pointed out that aggregate initialization can be used with some classes with a non-trivial implicitly-declared default constructor, and that in such cases there is no call to the object's constructor. The resolution for that issue was to change the previously-cited wording to read,
If T is a class type with a non-trivial constructor (12.1 [class.ctor], the initialization is complete.
Later (but before the WP was revised with the wording from the resolution of issue 119), issue 404 changed the 2003 wording to read,
If T is a class type and the constructor invoked to create the object is non-trivial (12.1 [class.ctor]), the constructor call has completed.
thus reversing the effect of issue 119, whose whole purpose was to cover objects with non-trivial constructors that are not invoked.
Through an editorial error, the post-Redmond draft (N1905) still contained the original 2003 wording that should have been replaced by the resolution of issue 119, in addition to the new wording from the resolution:
if T is a class type and the constructor invoked to create the object is non-trivial (12.1 [class.ctor]), the constructor call has completed. the initialization is complete.
Finally, during the application of the edits for delegating constructors (N1986), this editing error was “fixed” by retaining the original 2003 wording (which was needed for the application of the change specified in N1986), so that the current draft (N2009) reads,
if T is a class type and the constructor invoked to create the object is non-trivial (12.1 [class.ctor]), the principal constructor call 12.6.2 [class.base.init]) has completed.
Because the completion of the call to the principal constructor corresponds to the point at which the object is “fully constructed” (15.2 [except.ctor] paragraph 2), i.e., its initialization is complete, I believe that the exact wording of the issue 119 resolution would be correct and should be restored verbatim.
Proposed resolution (June, 2008):
Change 3.8 [basic.life] paragraph 1 as follows:
The lifetime of an object is a runtime property of the object. An object is said to have non-trivial initialization if it is of a class or aggregate type and it or one of its members is initialized by a constructor other than a trivial default constructor. [Note: Initialization by a trivial copy constructor is non-trivial initialization. —end note] The lifetime of an object
of type Tbegins when:
storage with the proper alignment and size
for type Tis obtained, andif
T is a class type and the constructor invoked to create the object is non-trivial (12.1 [class.ctor]), the principal constructor call (12.6.2 [class.base.init]) has completed. [Note: the initialization can be performed by a constructor call or, in the case of an aggregate with an implicitly-declared non-trivial default constructor, an aggregate initialization 8.5.1 [dcl.init.aggr]. —end note]the object has non-trivial initialization, its initialization is complete.The lifetime of an object of type T ends when...
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.
Notes from October 2004 meeting:
Discussion centered around whether a sequence point “between assigning the new value to the left operand and yielding the result of the expression” would require completion of all side effects of the operand expressions before the value of the assignment expression was used in another expression. The consensus opinion was that it would, that this is the definition of a sequence point. Jason Merrill pointed out that adding a sequence point after the assignment is essentially the same as rewriting
b += a
as
b += a, b
Clark Nelson expressed a desire for something like a “weak” sequence point that would force the assignment to occur but that would leave the side effects of the operands unconstrained. In support of this position, he cited the following expression:
j = (i = j++)
With the proposed addition of a full sequence point after the assignment to i, the net effect is no change to j. However, both g++ and MSVC++ behave differently: if the previous value of j is 5, the value of the expression is 5 but j gets the value 6.
Clark Nelson will investigate alternative approaches and report back to the working group.
Proposed resolution (March, 2008):
See issue 637.
Issue 506 changed passing a non-POD class type to an ellipsis from undefined behavior to conditionally-supported behavior. As a result, an implementation could conceivably reject code like the following:
struct two {char _[2];};
template <class From, class To>
struct is_convertible
{
private:
static From f;
template <class U> static char test(const U&);
template <class U> static two test(...);
public:
static const bool value = sizeof(test<To>(f)) == 1;
};
struct A
{
A();
};
int main()
{
const bool b = is_convertible<A,int>::value; // b == false
}
This technique has become popular in template metaprogramming, and no non-POD object is actually passed at runtime. Concepts will eliminate much (perhaps not all) of the need for this kind of programming, but legacy code will persist.
Perhaps this technique should be officially supported by allowing implementations to reject passing a non-POD type to ellipsis only if it appears in a potentially-evaluated expression?
Notes from the July, 2007 meeting:
The CWG agreed with the suggestion to allow such calls in unevaluated contexts.
Proposed resolution (September, 2007):
Change 5.2.2 [expr.call] paragraph 7 as follows:
...Passingana potentially-evaluated argument of non-trivial class type (clause 9 [class]) with no corresponding parameter is conditionally-supported, with implementation-defined semantics...
There appears to be no provision in the Standard for explicit conversion of a value of a scoped enumeration type to an integral type, even though the inverse conversion is permitted. That is,
enum class E { e };
static_cast<E>(0); // #1: OK
static_cast<int>(e); // #2: error
This is because values of scope enumeration types (intentionally) cannot be implicitly converted to integral types (4.5 [conv.prom] and 4.7 [conv.integral]) and 5.2.9 [expr.static.cast] was not updated to permit #2, although #1 is covered by paragraph 8.
Proposed resolution (June, 2008):
Add the following as a new paragraph following 5.2.9 [expr.static.cast] paragraph 8:
A value of a scoped enumeration type (7.2 [dcl.enum]) can be explicitly converted to an integral type. The value is unchanged if the original value can be represented by the specified type. Otherwise, the resulting value is unspecified.
The specification for the alignof operator (5.3.6 [expr.alignof]) does not forbid function types as operands, although it probably should.
Proposed resolution (March, 2008):
The issue, as described, is incorrect. The requirement in 5.3.6 [expr.alignof] is for “a complete object type,” so a function type is already forbidden. However, the existing text does have a problem in this requirement in that it does not allow a reference type, as anticipated by paragraph 3. Consequently, the proposal is to change 5.3.6 [expr.alignof] paragraph 1 as indicated:
An alignof expression yields the alignment requirement of its operand type. The operand shall be a type-id representing a complete object type or a reference to a complete object type.
According to 7.1.5 [dcl.constexpr] paragraph 5,
If the instantiated template specialization of a constexpr function template would fail to satisfy the requirements for a constexpr function, the constexpr specifier is ignored and the specialization is not a constexpr function.
One would expect to see a similar provision for an instantiated constructor template (because the requirements for a constexpr function [paragraph 3] are different from the requirements for a constexpr constructor [paragraph 4]), but there is none; constexpr constructor templates are not mentioned.
Suggested resolution:
Change the wording of 7.1.5 [dcl.constexpr] paragraph 5 as indicated:
If the instantiated template specialization of a constexpr function template would fail to satisfy the requirements for a constexpr function or constexpr constructor, as appropriate to the function template, the constexpr specifier is ignored and the specialization is not a constexpr function or constexpr constructor.
Proposed resolution (June, 2008):
[Drafting note: This resolution goes beyond the problem described in the issue discussion, which is one aspect of the general failure of the existing wording to deal consistently with the distinctions between constexpr functions and constexpr constructors. The wording below attempts to rectify that problem systematically.]
Change 7.1.5 [dcl.constexpr] paragraph 2 as follows:
A constexpr specifier used ina function declarationthe declaration of a function that is not a constructor declares that function to be a constexpr function. Similarly, a constexpr specifier used in a constructor declaration declares that constructor to be a constexpr constructor. Constexpr functions and constexpr constructors are implicitly inline (7.1.2 [dcl.fct.spec]).A constexpr function shall not be virtual (10.3).
Change 7.1.5 [dcl.constexpr] paragraph 3 as follows:
The definition of a constexpr function shall satisfy the following constraints:
it shall not be virtual (10.3 [class.virtual])
its return type shall be a literal type
each of its parameter types shall be a literal type
its function-body shall be a compound-statement of the form
{ return expression ; }
where expression is a potential constant expression (5.19 [expr.const])
every implicit conversion used in converting expression to the function return type (8.5 [dcl.init]) shall be one of those allowed in a constant expression (5.19 [expr.const]).
[Example:...
Change 7.1.5 [dcl.constexpr] paragraph 4 as follows:
The definition of a constexpr constructor shall satisfy the following constraints:
each of its parameter types shall be a literal type
its function-body shall not be a function-try-block
the compound-statement of its function-body shall be empty
every non-static data member and base class sub-object shall be initialized (12.6.2 [class.base.init])
every constructor involved in initializing non-static data members and base class sub-objects invoked by a mem-initializer shall be a constexpr constructor
invoked with potential constant expression arguments, if any.every constructor argument and full-expression in a mem-initializer shall be a potential constant expression
every implicit conversion used in converting a constructor argument to the corresponding parameter type and converting a full-expression to the corresponding member type shall be one of those allowed in a constant expression.
A trivial copy constructor is also a constexpr constructor. [Example: ...
Change 7.1.5 [dcl.constexpr] paragraph 5 as follows:
If the instantiated template specialization of a constexpr function template would fail to satisfy the requirements for a constexpr function or constexpr constructor, the constexpr specifier is ignoredand the specialization is not a constexpr function.
Change 7.1.5 [dcl.constexpr] paragraph 6 as follows:
A constexpr specifierused infor a non-static member functiondefinitionthat is not a constructor declares that member function to be const (9.3.1 [class.mfct.non-static]). [Note: ...
The current wording of 7.1.5 [dcl.constexpr] paragraph 7 seems not quite correct. It reads,
A constexpr specifier used in an object declaration declares the object as const. Such an object shall be initialized, and every expression that appears in its initializer (8.5 [dcl.init]) shall be a constant expression.
The phrase “every expression” is intended to cover multiple arguments to a constexpr constructor and multiple expressions in an aggregate initializer. However, it could be read (incorrectly) as saying that non-constant expressions cannot appear as subexpressions in such initializers, even in places where they do not render the full-expression non-constant (i.e., as unevaluated operands and in the unselected branches of &&, ||, and ?:). Perhaps this problem could be remedied by replacing “every expression” with “every full-expression?”
Proposed resolution (June, 2008):
Change 7.1.5 [dcl.constexpr] paragraph 7 as follows:
A constexpr specifier used in an object declaration declares the object as const. Such an object shall beinitialized, and every expression that appears in its initializer (8.5)initialized. If it is initialized by a constructor call, the constructor shall be a constexpr constructor and every argument to the constructor shall be a constant expression. Otherwise, every full-expression that appears in its initializer shall be a constant expression. Every implicit conversion used...
The second bullet of 7.1.6.2 [dcl.type.simple] paragraph 4 reads,
- otherwise, if e is a function call (5.2.2 [expr.call]) or an invocation of an overloaded operator (parentheses around e are ignored), decltype(e) is the return type of that function;
The reference to “that function” is imprecise; it is not the actual function called at runtime but the statically chosen function (ignoring covariant return types in virtual functions).
Also, the examples in this paragraph have errors:
The declaration of struct A should end with a semicolon.
The lines of the form decltype(...); are ill-formed; they need a declarator.
Proposed Resolution (October, 2007):
Change 7.1.6.2 [dcl.type.simple] paragraph 4 as follows:
The type denoted by decltype(e) is defined as follows:
if e is an id-expression or a class member access (5.2.5 [expr.ref]), decltype(e) is the type of the entity named by e. If there is no such entity, or if e names a set of overloaded functions, the program is ill-formed;
otherwise, if e is a function call (5.2.2 [expr.call]) or an invocation of an overloaded operator (parentheses around e are ignored), decltype(e) is the return type of
thatthe statically chosen function;otherwise, if e is an lvalue, decltype(e) is T&, where T is the type of e;
otherwise, decltype(e) is the type of e.
The operand of the decltype specifier is an unevaluated operand (clause 5 [expr]).
[Example:
const int&& foo(); int i; struct A { double x; }; const A* a = new A(); decltype(foo()) x1; // type is const int&& decltype(i) x2; // type is int decltype(a->x) x3; // type is double decltype((a->x)) x4; // type is const double&—end example]
The current specification of scoped enumerations does not appear to forbid an example like the following, even though the enumerator e cannot be used:
enum class { e };
This might be covered by 7 [dcl.dcl] paragraph 3,
In a simple-declaration, the optional init-declarator-list can be omitted only when declaring a class (clause 9 [class]) or enumeration (7.2 [dcl.enum]), that is, 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 these specifiers are among the names being declared by the declaration (as class-names, enum-names, or enumerators, depending on the syntax). 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.
which, when combined with paragraph 2,
A declaration occurs in a scope (3.3 [basic.scope]); the scope rules are summarized in 3.4 [basic.lookup]. A declaration that declares a function or defines a class, namespace, template, or function also has one or more scopes nested within it. These nested scopes, in turn, can have declarations nested within them. Unless otherwise stated, utterances in clause 7 [dcl.dcl] about components in, of, or contained by a declaration or subcomponent thereof refer only to those components of the declaration that are not nested within scopes nested within the declaration.
appears to rule out the similar class definition,
struct { int m; };
However, a scoped enumeration is not listed in paragraph 2 among the constructs containing a nested scope (although 3.3.7 [basic.scope.enum] does describe “enumeration scope”); furthermore, an enumerator-definition is not formally a “nested declaration.” If unusable scoped enumeration definitions are to be banned, these shortcomings in 7 [dcl.dcl] paragraph 2 must be addressed. (A note in 7.2 [dcl.enum] mentioning that unnamed scoped enumerations are not allowed would also be helpful.)
Notes from the February, 2008 meeting:
The consensus was to require that the identifier be present in an enum-specifier unless the enum-key is enum.
Proposed resolution (June, 2008):
Change 7.2 [dcl.enum] paragraph 2 as follows:
...The enum-keys enum class and enum struct are semantically equivalent; an enumeration type declared with one of these is a scoped enumeration, and its enumerators are scoped enumerators. The optional identifier shall not be omitted in the declaration of a scoped enumeration. The type-specifier-seq of an enum-base...
The restrictions on declaring and/or defining classes inside type-specifier-seqs and type-ids are inconsistent throughout the Standard. This is probably due to the fact that nearly all of the sections that deal with them attempt to state the restriction afresh. There are three cases:
5.3.4 [expr.new], 6.4 [stmt.select], and 12.3.2 [class.conv.fct] prohibit “declarations” of classes and enumerations. That means that
while (struct C* p = 0) ;
is ill-formed unless a prior declaration of C has been seen. These appear to be cases that should have been fixed by issue 379, changing “class declaration” to “class definition,” but were overlooked.
5.1.1 [expr.prim.lambda], 7 [dcl.dcl], and 8.3.5 [dcl.fct] (late-specified return types) do not contain any restriction at all.
All the remaining cases prohibit “type definitions,” apparently referring to classes and enumerations.
Suggested resolution:
Add something like, “A class or enumeration shall not be defined in a type-specifier-seq or in a type-id,” to a single place in the Standard and remove all other mentions of that restriction (allowing declarations via elaborated-type-specifier).
Mike Miller:
An alias-declaration is just a different syntax for a typedef declaration, which allows definitions of a class in the type; I would expect the same to be true of an alias-declaration. I don't have any particularly strong attachment to allowing a class definition in an alias-declaration. My only concern is introducing an irregularity into what are currently exact-match semantics with typedefs.
There's a parallel restriction in many (but not all?) of these places on typedef declarations.
Jens Maurer:
Those are redundant, as typedef is not a type-specifier, and should be removed as well.
Proposed resolution (March, 2008):
Delete the indicated words from 5.2.7 [expr.dynamic.cast] paragraph 1:
...Types shall not be defined in a dynamic_cast....
Delete the indicated words from 5.2.8 [expr.typeid] paragraph 4:
...Types shall not be defined in the type-id....
Delete the indicated words from 5.2.9 [expr.static.cast] paragraph 1:
...Types shall not be defined in a static_cast....
Delete the indicated words from 5.2.10 [expr.reinterpret.cast] paragraph 1:
...Types shall not be defined in a reinterpret_cast....
Delete the indicated words from 5.2.11 [expr.const.cast] paragraph 1:
...Types shall not be defined in a const_cast....
Delete paragraph 5 of 5.3.3 [expr.sizeof]:
Types shall not be defined in a sizeof expression.
Delete paragraph 5 of 5.3.4 [expr.new]:
The type-specifier-seq shall not contain class declarations, or enumeration declarations.
Delete paragraph 4 of 5.3.6 [expr.alignof]:
A type shall not be defined in an alignof expression.
Delete paragraph 3 of 5.4 [expr.cast]:
Types shall not be defined in casts.
Delete the indicated words from 6.4 [stmt.select] paragraph 2:
...The type-specifier-seq shall not contain typedef and shall not declare a new class or enumeration....
Add the indicated words to 7.1.6 [dcl.type] paragraph 3:
At least one type-specifier that is not a cv-qualifier is required in a declaration unless it declares a constructor, destructor or conversion function. [Footnote: ... ] A type-specifier-seq shall not define a class or enumeration unless it appears in the type-id of an alias-declaration (7.1.3 [dcl.typedef]).
Delete the indicated words from 12.3.2 [class.conv.fct] paragraph 1:
...Classes, enumerations, and typedef-names shall not be declared in the type-specifier-seq....
Delete the indicated words from 15.3 [except.handle] paragraph 1:
...Types shall not be defined in an exception-declaration.
Delete paragraph 6 of 15.4 [except.spec]:
Types shall not be defined in exception-specifications.
[Drafting note: no changes are required to 5.1.1 [expr.prim.lambda], 7.1.3 [dcl.typedef], 7.1.7 [dcl.align], 7.2 [dcl.enum], 8.3.5 [dcl.fct], 14.1 [temp.param], or 14.2 [temp.names].]
According to 10.3 [class.virtual] paragraph 2:
Then in any well-formed class, for each virtual function declared in that class or any of its direct or indirect base classes there is a unique final overrider that overrides that function and every other overrider of that function. The rules for member lookup (10.2 [class.member.lookup]) are used to determine the final overrider for a virtual function in the scope of a derived class but ignoring names introduced by using-declarations.
I think that description is wrong on at least a couple of counts. First, consider the following example:
struct A { virtual void f(); };
struct B: A { };
struct C: A { void f(); };
struct D: B, C { };
What is the “unique final overrider” of A::f() in D? According to 10.3 [class.virtual] paragraph 2, we determine that by looking up f in D using the lookup rules in 10.2 [class.member.lookup]. However, that lookup determines that f in D is ambiguous, so there is no “unique final overrider” of A::f() in D. Consequently, because “any well-formed class” must have such an overrider, D must be ill-formed.
Of course, we all know that D is not ill-formed. In fact, 10.3 [class.virtual] paragraph 10 contains an example that illustrates exactly this point:
struct A { virtual void f(); }; struct B1 : A { // note non-virtual derivation void f(); }; struct B2 : A { void f(); }; struct D : B1, B2 { // D has two separate A subobjects };In class D above there are two occurrences of class A and hence two occurrences of the virtual member function A::f. The final overrider of B1::A::f is B1::f and the final overrider of B2::A::f is B2::f.
It appears that the requirement for a “unique final overrider” in 10.3 [class.virtual] paragraph 2 needs to say something about sub-objects. Whatever that “something” is, you can't just say “look up the name in the derived class using 10.2 [class.member.lookup].”
There's another problem with using the 10.2 [class.member.lookup] lookup to specify the final overrider: name lookup just looks up the name, while the overriding relationship is based not only on the name but on a matching parameter-type-list and cv-qualification. To illustrate this point:
struct X {
virtual void f();
};
struct Y: X {
void f(int);
};
struct Z: Y { };
What is the “unique final overrider” of X::f() in A? Again, 10.3 [class.virtual] paragraph 2 says you're supposed to look up f in Z to find it; however, what you find is Y::f(int), not X::f(), and that's clearly wrong.
Proposed Resolution (December, 2006):
Change 10.3 [class.virtual] paragraph 2 as follows:
Then in any well-formed class, for each virtual function declared in that class or any of its direct or indirect base classes there is a unique final overrider that overrides that function and every other overrider of that function. The rules for member lookup (10.2 [class.member.lookup]) are used to determine the final overrider for a virtual function in the scope of a derived class but ignoring names introduced by using-declaration s.A virtual member function vf of a class C is a final overrider unless the most derived class (1.8 [intro.object]) of which C is a base class (if any) declares or inherits another member function that overrides vf. In a derived class, if a virtual member function of a base class subobject has more than one final overrider, the program is ill-formed.
The resolution of issue 372 leaves unclear whether the following are well-formed or not:
class C {
typedef int I; // private
template <int> struct X;
template <int> friend struct Y;
}
template <C::I> struct C::X { }; // C::I accessible to member?
template <C::I> struct Y { }; // C::I accessible to friend?
Presumably the answer to both questions is “yes,” but the new wording does not address template-parameters.
Proposed resolution (June, 2008):
Change 11 [class.access] paragraph 6 as follows:
...For purposes of access control, the base-specifiers of a class, the template-parameters of a template-declaration, and the definitions of class members that appear outside of the class definition are considered to be within the scope of that class...
After the adoption of the wording for extended friend declarations, we now have this new paragraph in 11.4 [class.friend]:
A friend declaration that does not declare a function shall have one of the following forms:
friend elaborated-type-specifier ;
friend simple-type-specifier ;
friend typename-specifier ;
But what about friend class templates? Should the following examples compile in C++0x?
template< template <class> class T >
struct A{ friend T; };
template< class > struct C;
struct B{ friend C; };
Proposed resolution (June, 2008):
Change 11.4 [class.friend] paragraph 3 as follows:
A friend declaration that does not declare a function shall have one of the following forms:
friend elaborated-type-specifier ;
friend simple-type-specifier ;
friend typename-specifier ;
friend ::opt nested-name-specifieropt template-name ;
friend identifier ;
In the last alternative, the identifier shall name a template template-parameter. [Note: a friend declaration may be the declaration in a template-declaration (clause 14 [temp], 14.5.4 [temp.friend]). —end note] If the
type specifier in afriend declaration designates a (possibly cv-qualified) class type or a class template, that class or template is declared as a friend; otherwise, the friend declaration is ignored. [Example:...
Split off from issue 86.
Should binding a reference to the result of a "," operation whose second operand is a temporary extend the lifetime of the temporary?
const SFileName &C = ( f(), SFileName("abc") );
Notes from the March 2004 meeting:
We think the temporary should be extended.
Proposed resolution (October, 2004):
Change 12.2 [class.temporary] paragraph 2 as indicated:
... In all these cases, the temporaries created during the evaluation of the expression initializing the reference, except the temporary that is the overall result of the expression [Footnote: For example, if the expression is a comma expression (5.18 [expr.comma]) and the value of its second operand is a temporary, the reference is bound to that temporary.] and 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...
[Note: this wording partially resolves issue 86. See also issue 446.]
Notes from the April, 2005 meeting:
The CWG suggested a different approach from the 10/2004 resolution, leaving 12.2 [class.temporary] unchanged and adding normative wording to 5.18 [expr.comma] specifying that, if the result of the second operand is a temporary, that temporary is the result of the comma expression as well.
Proposed Resolution (November, 2006):
Add the indicated wording to 5.18 [expr.comma] paragraph 1:
... 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 an lvalue, and is a bit-field if its right operand is an lvalue and a bit-field. If the value of the right operand is a temporary (12.2 [class.temporary]), the result is that temporary.
In describing the order of destruction of temporaries, 12.2 [class.temporary] paragraphs 4-5 say,
There are two contexts in which temporaries are destroyed at a different point than the end of the full-expression...
The second context is when a reference is bound to a temporary... A temporary bound to the returned value in a function return statement (6.6.3 [stmt.return]) persists until the function exits.
The following example illustrates the issues here:
struct S {
~S();
};
S& f() {
S s; // #1
return
(S(), // #2
S()); // #3
}
If the return type of f() were simply S instead of S&, the two temporaries would be destroyed at the end of the full-expression in the return statement in reverse order of their construction, followed by the destruction of the variable s at block-exit, i.e., the order of destruction of the S objects would be #3, #2, #1.
Because the temporary #3 is bound to the returned value, however, its lifetime is extended beyond the end of the full-expression, so that S object #2 is destroyed before #3.
There are two problems here. First, it is not clear what “until the function exits” means. Does it mean that the temporary is destroyed as part of the normal block-exit destructions, as described in 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.
Or is the point of destruction for #3 after the destruction of the “constructed objects... that are declared [emphasis mine] in that scope” (because temporary #3 was not “declared”)? I.e., should #3 be destroyed before or after #1?
The other problem is that, according to the recollection of one of the participants responsible for this wording, the intent was not to extend the lifetime of #3 but simply to emphasize that its lifetime ended before the function returned, i.e., that the result of f() could not be used without causing undefined behavior. This is also consistent with the treatment of this example by many implementations; MSVC++, g++, and EDG all destroy #3 before #2.
Suggested resolution:
Change 12.2 [class.temporary] paragraph 5 as indicated:
AThe lifetime of a temporary bound to the returned value in a function return statement (6.6.3 [stmt.return])persists until the function exitsis not extended; it is destroyed at the end of the full-expression in the return statement.
Proposed resolution (June, 2008):
Change 12.2 [class.temporary] paragraph 5 as follows (converting the running text into a bulleted list and making the indicated edits to the wording):
... The temporary to which the reference is bound or the temporary that is the complete object of a subobject to which the reference is bound persists for the lifetime of the reference except:as specified below.
A temporary bound to a reference member in a constructor's ctor-initializer (12.6.2 [class.base.init]) persists until the constructor exits.
A temporary bound to a reference parameter in a function call (5.2.2 [expr.call]) persists until the completion of the full expression containing the call.
AThe lifetime of a temporary bound to the returned value in a function return statement (6.6.3 [stmt.return])persists until the function exitsis not extended; the temporary is destroyed at the end of the full-expression in the return statement.The destruction of a temporary whose lifetime is not extended...
12.6 [class.init] paragraph 2 says,
When an array of class objects is initialized (either explicitly or implicitly), the constructor shall be called for each element of the array, following the subscript order;
That implies that, given
struct POD {
int x;
};
POD data[10] = {};
this should call the implicitly declared default ctor 10 times, leaving 10 uninitialized ints, rather than value initialize each member of data, resulting in 10 initialized ints (which is required by 8.5.1 [dcl.init.aggr] paragraph 7).
I suggest rephrasing along the lines:
When an array is initialized (either explicitly or implicitly), each element of the array shall be initialized in turn, following the subscript order;
This would allow for PODs and other classes with a dual nature under value/default initialization, and cover copy initialization for arrays too.
Proposed resolution (October, 2006):
Change 12.6 [class.init] paragraph 3 as follows:
When an array of class objects is initialized (either explicitly or implicitly) and the elements are initialized by constructor, the constructor shall be called for each element of the array, following the subscript order; see 8.3.4 [dcl.array].
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?
Christopher Lester, on comp.std.c++, March 19, 2004: If any of you reading this posting happen to be members of the above working group, I would like to encourage you to review the suggestion contained therein, as it seems to me that the final tenor of the submission is both (a) correct (the silence of the standard DOES mandate the omission) and (b) describes what most users would intuitively expect and desire from the C++ language as well.
The suggestion is to make it clearer that constructors for abstract base classes should not be required to provide initialisers for any virtual base classes they contain (as only the most-derived class has the job of initialising virtual base classes, and an abstract base class cannot possibly be a most-derived class).
For example:
struct A {
A(const int i, const int j) {};
};
struct B1 : virtual public A {
virtual void moo()=0;
B1() {}; // (1) Look! not "B1() : A(5,6) {};"
};
struct B2 : virtual public A {
virtual void cow()=0;
B2() {}; // (2) Look! not "B2() : A(7,8) {};"
};
struct C : public B1, public B2 {
C() : A(2,3) {};
void moo() {};
void cow() {};
};
int main() {
C c;
return 0;
};
I believe that, by not expressly forbidding it, the standard does (and should!) allow the above code. However, as the standard doesn't expressly allow it either (have I missed something?) there appears to be room for misunderstanding. For example, g++ version 3.2.3 (and maybe other versions as well) rejects the above code with messages like:
In constructor `B1::B1()':
no matching function for call to `A::A()'
candidates are: A::A(const A&)
A::A(int, int)
Fair enough, the standard is perhaps not clear enough. But it seems to be a shame that although this issue was first raised in 2000, we are still living with it today.
Note that we can work-around, and persuade g++ to compile the above by either (a) providing a default constructor A() for A, or (b) supplying default values for i and j in A(i,j), or (c) replace the construtors B1() and B2() with the forms shown in the two comments in the above example.
All three of these workarounds may at times be appropriate, but equally there are other times when all of these workarounds are particularly bad. (a) and (b) may be very bad if you are trying to enforce string contracts among objects, while (c) is just barmy (I mean why did I have to invent random numbers like 5, 6, 7 and 8 just to get the code to compile?).
So to to round up, then, my plea to the working group is: "at the very least, please make the standard clearer on this issue, but preferrably make the decision to expressly allow code that looks something like the above"
Proposed resolution (March, 2008):
Add the indicated text (moved from paragraph 6) to the end of 12.6.2 [class.base.init] paragraph 3:
...The initialization of each base and member constitutes a full-expression. Any expression in a mem-initializer is evaluated as part of the full-expression that performs the initialization. A mem-initializer where the mem-initializer-id names a virtual base class is ignored during execution of a constructor of any class that is not the most derived class.
Change 12.6.2 [class.base.init] paragraph 4 as follows:
If a given non-static data member or base class is not named by a mem-initializer-id (including the case where there is no mem-initializer-list because the constructor has no ctor-initializer) and the entity is not a virtual base class of an abstract class, then
If the entity is a non-static non-variant data member of (possibly cv-qualified) class type (or array thereof) or a base class, and the entity class is a non-trivial class, the entity is default-initialized (8.5 [dcl.init]). If the entity is a non-static data member of a const-qualified type, the entity class shall have a user-provided default constructor.
Otherwise, the entity is not initialized. If the entity is of const-qualified type or reference type, or of a (possibly cv-qualified) trivial class type (or array thereof) containing (directly or indirectly) a member of a const-qualified type, the program is ill-formed.
[Note: An abstract base class (10.4 [class.abstract]) is never a most derived class, thus its constructors never initialize virtual base classes, therefore the corresponding mem-initializers may be omitted. —end note] After the call to a constructor for class X has completed, if a member of X is neither specified in the constructor's mem-initializers, nor default-initialized, nor value-initialized, nor given a value during execution of the compound-statement of the body of the constructor, the member has indeterminate value.
Change 12.6.2 [class.base.init] paragraph 5 as follows:
Initialization
shallproceeds in the following order:
First, and only for the constructor of the most derived class
as described below(1.8 [intro.object]), virtual base classesshall beare initialized in the order they appear on a depth-first left-to-right traversal of the directed acyclic graph of base classes, where “left-to-right” is the order of appearance of the base class names in the derived class base-specifier-list.Then, direct base classes
shall beare initialized in declaration order as they appear in the base-specifier-list (regardless of the order of the mem-initializers).Then, non-static data members
shall beare initialized in the order they were declared in the class definition (again regardless of the order of the mem-initializers).Finally, the compound-statement of the constructor body is executed.
[Note: the declaration order is mandated to ensure that base and member subobjects are destroyed in the reverse order of initialization. —end note]
[Drafting note: The “shall” clauses above were rewritten to accord with the usual phrasing throughout the rest of the Standard.]
Remove all the normative text in 12.6.2 [class.base.init] paragraph 6, keeping the example:
All subobjects 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.[Example:...
The changes for delegating constructors overlooked the need to change 12.6.2 [class.base.init] paragraph 3:
The expression-list in a mem-initializer is used to initialize the base class or non-static data member subobject denoted by the mem-initializer-id. The semantics of a mem-initializer are as follows:
if the expression-list of the mem-initializer is omitted, the base class or member subobject is value-initialized (see 8.5 [dcl.init]);
otherwise, the subobject indicated by mem-initializer-id is direct-initialized using expression-list as the initializer (see 8.5 [dcl.init]).
The initialization of each base and member constitutes a full-expression. Any expression in a mem-initializer is evaluated as part of the full-expression that performs the initialization.
This paragraph deals only with subobjects; it needs to be made more general to apply to the complete object as well when the mem-initializer-id designates the constructor's class.
Proposed resolution (June, 2008):
Change 12.6.2 [class.base.init] paragraph 3 as follows:
The expression-list in a mem-initializer is used to initialize the base class or non-static data member subobject denoted by the mem-initializer-id. The semantics of a mem-initializer areA mem-initializer in which the mem-initializer-id names the constructor's class initializes the object by invoking the selected target constructor with the mem-initializer's expression-list. A mem-initializer in which the mem-initializer-id names a base class or non-static data member initializes the designated subobject as follows:
if the expression-list of the mem-initializer is omitted, the base class or member subobject is value-initialized (see 8.5 [dcl.init]);
otherwise, the subobject indicated by mem-initializer-id is direct-initialized using expression-list as the initializer (see 8.5 [dcl.init]).
...
The initialization
of each base and memberperformed by each mem-initializer constitutes a full-expression. Any expression...
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.
Proposed Resolution (November, 2006):
This issue is resolved by the proposed resolution for issue 535.
Footnote 112 (12.8 [class.copy] paragraph 2) says,
Because a template constructor is never a copy constructor, the presence of such a template does not suppress the implicit declaration of a copy constructor. Template constructors participate in overload resolution with other constructors, including copy constructors, and a template constructor may be used to copy an object if it provides a better match than other constructors.
However, many of the stipulations about copy construction are phrased to refer only to “copy constructors.” For example, 12.8 [class.copy] paragraph 14 says,
A program is ill-formed if the copy constructor... for an object is implicitly used and the special member function is not accessible (clause 11 [class.access]).
Does that mean that using an inaccessible template constructor to copy an object is permissible, because it is not a “copy constructor?” Obviously not, but each use of the term “copy constructor” in the Standard should be examined to determine if it applies strictly to copy constructors or to any constructor used for copying. (A similar issue applies to “copy assignment operators,” which have the same relationship to assignment operator function templates.)
Proposed Resolution (February, 2008):
Change 3.2 [basic.def.odr] paragraph 2 as follows:
... [Note: this covers calls to named functions (5.2.2 [expr.call]), operator overloading (clause 13 [over]), user-defined conversions (12.3.2 [class.conv.fct]), allocation function for placement new (5.3.4 [expr.new]), as well as non-default initialization (8.5 [dcl.init]). Acopyconstructor selected to copy class objects is used even if the call is actually elided by the implementation (12.8 [class.copy]). —end note] ...A copy-assignment function for a classAn assignment operator function in a class is used by an implicitly-defined copy-assignment function for another class as specified in 12.8 [class.copy]...
Delete 12.1 [class.ctor] paragraphs 10 and 11:
A copy constructor (12.8 [class.copy]) is used to copy objects of class type.
A union member shall not be of a class type (or array thereof) that has a non-trivial constructor.
Replace the “example” in 12.2 [class.temporary] paragraph 1 with a note as follows:
[Example: even if the copy constructor is not called, all the semantic restrictions, such as accessibility (clause 11 [class.access]), shall be satisfied. —end example][Note: This includes accessibility (clause 11 [class.access]) for the constructor selected. —end note]
Change 12.8 [class.copy] paragraph 7 as follows:
A non-user-provided copy constructor is implicitly defined if it is used
to initialize an object of its class type from a copy of an object of its class type or of a class type derived from its class type(3.2 [basic.def.odr]). [Footnote: See 8.5 [dcl.init] for more details on direct and copy initialization. —end footnote] [Note: the copy constructor is implicitly defined even if the implementation elidedits use (12.2 [class.temporary])the copy operation (12.8 [class.copy]). —end note]A program is ill-formed if the class for which a copy constructor is implicitly defined or explicitly defaulted has:
a non-static data member of class type (or array thereof) with an inaccessible or ambiguous copy constructor, or
a base class with an inaccessible or ambiguous copy constructor.
Before the non-user-provided copy constructor for a class is implicitly defined...
Change 12.8 [class.copy] paragraph 8 as follows:
...Each subobject is copied in the manner appropriate to its type:
if the subobject is of class type,
the copy constructor for the class is useddirect-initialization (8.5 [dcl.init]) is performed [Note: If overload resolution fails or the constructor selected by overload resolution is inaccessible (11 [class.access]) in the context of X, the program is ill-formed. —end note];if the subobject is an array...
[Drafting note: 8.5 [dcl.init] paragraph 15 requires “unambiguous” and 13.3 [over.match] paragraph 3 requires “accessible,” thus no need for normative text here.]
Change 12.8 [class.copy] paragraph 12 as follows:
A non-user-provided copy assignment operator is implicitly defined when
an object of its class type is assigned a value of its class type or a value of a class type derived from its class typeit is used (3.2 [basic.def.odr]). A program is ill-formed if the class for which a copy assignment operator is implicitly defined or explicitly defaulted has:a non-static data member of const or reference type.
a non-static data member of const type, or
a non-static data member of reference type, or
a non-static data member of class type (or array thereof) with an inaccessible copy assignment operator, or
a base class with an inaccessible copy assignment operator.
Change 12.8 [class.copy] paragraph 13 as follows:
... Each subobject is assigned in the manner appropriate to its type:
if the subobject is of class type,
the copy assignment operator for the classthe assignment operator function selected by overload resolution (13.3 [over.match]) for that class is used (as if by explicit qualification; that is, ignoring any possible virtual overriding functions in more derived classes) [Note: If overload resolution fails or the assignment operator function selected by overload resolution is inaccessible (11 [class.access]) in the context of X, the program is ill-formed. —end note];if the subobject is an array...
Delete 12.8 [class.copy] paragraph 14:
A program is ill-formed if the copy constructor or the copy assignment operator for an object is implicitly used and the special member function is not accessible (clause 11 [class.access]). [Note: Copying one object into another using the copy constructor or the copy assignment operator does not change the layout or size of either object. —end note]
Change 12.8 [class.copy] paragraph 15 as follows:
When certain criteria are met, an implementation is allowed to omit the copy construction of a class object, even if thecopyconstructor selected for the copy operation and/or the destructor for the object have side effects. In such cases, the implementation treats the source and target of the omitted copy operation as simply two different ways of referring to the same object, and the destruction of that object occurs at the later of the times when the two objects would have been destroyed without the optimization. [Footnote: Because only one object is destroyed instead of two, and onecopyconstructor is not executed, there is still one object destroyed for each one constructed. —end footnote] This elision...
Change 13.3.3.1.2 [over.ics.user] paragraph 4 as follows:
A conversion of an expression of class type to the same class type is given Exact Match rank, and a conversion of an expression of class type to a base class of that type is given Conversion rank, in spite of the fact that acopyconstructor (i.e., a user-defined conversion function) is called for those cases.
Change 15.1 [except.throw] paragraph 3 as follows:
A throw-expression initializes a temporary object, called the exception object,the type of whichby copy-initialization (8.5 [dcl.init]). The type of that temporary object is determined...
Change 15.1 [except.throw] paragraph 5 as follows:
When the thrown object is a class object, thecopyconstructor selected for the copy-initialization and the destructor shall be accessible, even if the copy operation is elided (12.8 [class.copy]).
Change 15.3 [except.handle] paragraphs 16-17 as follows:
When the exception-declaration specifies a class type,
a copy constructorcopy-initialization (8.5 [dcl.init]) is used to initialize either the object declared in the exception-declaration or, if the exception-declaration does not specify a name, a temporary object of that type. The object shall not have an abstract class type. The object is destroyed when the handler exits, after the destruction of any automatic objects initialized within the handler. Thecopyconstructor selected for the copy-initialization and the destructor shall be accessible in the context of the handler, even if the copy operation is elided (12.8 [class.copy]).If the copy constructor and destructor are implicitly declared (12.8 [class.copy]), such a use in the handler causes these functions to be implicitly defined; otherwise, the program shall provide a definition for these functions.
The copy constructor and destructor associated with the object shall be accessible even if the copy operation is elided (12.8 [class.copy]).
Change the footnote in 15.5.1 [except.terminate] paragraph 1 as follows:
[Footnote: For example, if the object being thrown is of a classwith a copy constructortype, std::terminate() will be called ifthat copy constructorthe constructor selected to copy the object exits with an exception during a throw. —end footnote]
(This resolution also resolves issue 111.)
[Drafting note: The following do not require changes: 5.17 [expr.ass] paragraph 4; 9 [class] paragraph 5; 9.5 [class.union] paragraph 1; 12.2 [class.temporary] paragraph 2; 12.8 [class.copy] paragraphs 1-2; 15.4 [except.spec] paragraph 14.]
Notes from February, 2008 meeting:
These changes overlap those that will be made when concepts are added. This issue will be maintained in “review” status until the concepts proposal is adopted and any conflicts will be resolved at that point.
Is the following a “copy assignment operator?”
struct A {
const A& operator=(const A&) volatile;
};
12.8 [class.copy] paragraph 9 doesn't say one way or the other whether cv-qualifiers on the function are allowed. (A similar question applies to the const case, but I avoided that example because it seems so wrong one tends to jump to a conclusion before seeing what the standard says.)
Since the point of the definition of “copy assignment operator” is to control whether the compiler generates a default version if the user doesn’t, I suspect the correct answer is that neither const nor volatile cv-qualification on operator= should be allowed for a “copy assignment operator.” A user can write an operator= like that, but it doesn't affect whether the compiler generates the default one.
Proposed Resolution (November, 2006):
Change 12.8 [class.copy] paragraph 9 as follows:
A user-declared copy assignment operator X::operator= is a non-static non-template non-volatile non-const member function of class X with exactly one parameter of type X, X&, const X&, volatile X& or const volatile X&.
[Drafting note: If a user-declared volatile operator= prevented the implicit declaration of the copy assignment operator, all assignments for objects of the given class (even to non-volatile objects) would pay the penalty for volatile write accesses in the user-declared operator=, despite not needing it.]
How does copy assignment for unions work? For example,
union U {
int a;
float b;
};
void f() {
union U u = { 5 };
union U v;
v = u; // what happens here?
}
9.5 [class.union] is silent on the issue, therefore it seems that 12.8 [class.copy] applies. There is no special case for unions, thus paragraph 13 (memberwise assignment of subobjects) seems to apply. That would seem to imply these actions in the compiler-generated copy assignment operator:
v.a = u.a; v.b = u.b;
And this is just wrong. For example, the lifetime of v.a ends once the second assignment reuses the memory of v.a.
We should probably prescribe “memcpy” copying for unions (both for the copy constructor and the assignment operator) unless the user provided his own special member function.
Proposed resolution (March, 2008):
Change 12.8 [class.copy] paragraph 8 as follows:
The implicitly-defined or explicitly-defaulted copy constructor for a non-union class X performs a memberwise copy of its subobjects...
Add a new paragraph after 12.8 [class.copy] paragraph 8:
The implicitly-defined or explicitly-defaulted copy constructor for a union X where all members have a trivial copy constructor copies the object representation (3.9 [basic.types]) of X. [Note: The behavior is undefined if X is not a trivial type. —end note]
Change 12.8 [class.copy] paragraph 13 as follows:
The implicitly-defined or explicitly-defaulted copy assignment operator for a non-union class X performs memberwise assignment of its subobjects...
Add a new paragraph after 12.8 [class.copy] paragraph 13:
The implicitly-defined or explicitly-defaulted copy assignment operator for a union X where all members have a trivial copy assignment operator copies the object representation (3.9 [basic.types]) of X. [Note: The behavior is undefined if X is not a trivial type. —end note]
Should the following class have a trivial copy assignment operator?
struct A {
int& m;
A();
A(const A&);
};
12.8 [class.copy] paragraph 11 does not mention whether the presence of reference members (or cv-qualifiers, etc.) should affect triviality. Should it?
One reason why this matters is that implementations have to make the builtin type trait operator __has_trivial_default_ctor(T) work so that they can support the type trait template std::has_trivial_default_constructor.
Assuming the answer is “yes,” it looks like we probably need similar wording for trivial default and trivial copy ctors.
Notes from the February, 2008 meeting:
Deleted special member functions are also not trivial. Resolution of this issue should be coordinated with the concepts proposal.
Notes from the June, 2008 meeting:
It appears that this issue will be resolved by the concepts proposal directly. The issue is in “review” status to check if that is indeed the case in the final version of the proposal.
Part of the decision regarding whether a class has a trivial special function (copy constructor, copy assignment operator, default constructor) is whether its base and member subobjects have corresponding trivial member functions. However, with the advent of defaulted functions, it is now possible for a single class to have both trivial and nontrivial overloads for those functions. For example,
struct B {
B(B&) = default; // trivial
B(const B&); // non-trivial, because user-provided
};
struct D : B { };
Although B has a trivial copy constructor and thus satisfies the requirements in 12.8 [class.copy] paragraph 6, the copy constructor in B that would be called by the implicitly-declared copy constructor in D is not trivial. This could be fixed either by requiring that all the subobject's copy constructors (or copy assignment operators, or default constructors) be trivial or that the one that would be selected by overload resolution be trivial.
Proposed resolution (July, 2008):
Change 8.4 [dcl.fct.def] paragraph 9 as follows:
... A special member function that would be implicitly defined as deleted shall not be explicitly defaulted. If a special member function for a class X is defaulted on its first declaration, no other special member function of the same kind (default constructor, copy constructor, or copy assignment operator) shall be declared in class X. A special member function is user-provided...
12.3.2 [class.conv.fct] paragraph 1 says,
A conversion function is never used to convert a (possibly cv-qualified) object to the (possibly cv-qualified) same object type (or a reference to it), to a (possibly cv-qualified) base class of that type (or a reference to it), or to (possibly cv-qualified) void.
At what point is this enforced, and how is it enforced?
Consider this test case:
struct abc;
struct xyz {
xyz();
xyz(xyz &);
operator xyz& (); // #1
operator abc& (); // #2
};
struct abc : xyz {};
void foo(xyz &);
void bar() {
foo (xyz ());
}
If such conversion functions are part of the overload set, #1 is a better conversion than #2 to convert the temporary xyz object to a non-const reference required for foo's operand. If such conversion functions are not part of the overload set, then #2 would be selected, and AFAICT the program would be well formed.
If the conversion functions are not part of the overload set, then it would seem one cannot take their address. For instance, adding the following line to the above test case would find no suitable function:
xyz &(xyz::*ptr) () = &xyz::operator xyz &;
Notes from the October, 2007 meeting:
The intent of 12.3.2 [class.conv.fct] paragraph 1 is that overload resolution not be attempted at all for the listed cases; that is, if the target type is void, the object's type, or a base of the object's type, the conversion is done directly without considering any conversion functions. Consequently, the questions about whether the conversion function is part of the overload set or not are moot. The wording will be changed to make this clearer.
Proposed Resolution (October, 2007):
Change the footnote in 12.3.2 [class.conv.fct] paragraph 1 as follows:
A conversion function is never used to convert a (possibly cv-qualified) object to the (possibly cv-qualified) same object type (or a reference to it), to a (possibly cv-qualified) base class of that type (or a reference to it), or to (possibly cv-qualified) void. [Footnote: These conversions are considered as standard conversions for the purposes of overload resolution (13.3.3.1 [over.best.ics], 13.3.3.1.4 [over.ics.ref]) and therefore initialization (8.5 [dcl.init]) and explicit casts (5.2.9 [expr.static.cast]). A conversion to void does not invoke any conversion function (5.2.9 [expr.static.cast]). Even though never directly called to perform a conversion, such conversion functions can be declared and can potentially be reached through a call to a virtual conversion function in a base class —end footnote]
Additional note (March, 2008):
A slight change to the example above indicates that there is a need for a normative change as well as the clarification of the rationale in the October, 2007 proposed resolution. If the declaration of foo were changed to
void foo(const xyz&);
with the current wording, the call foo(xyz()) would be interpreted as foo(xyz().operator abc&()) instead of binding the parameter directly to the rvalue, which is clearly wrong.
Proposed resolution (March, 2008):
Change the footnote in 12.3.2 [class.conv.fct] paragraph 1 as described in the October, 2007 proposed resolution.
Change 8.5.3 [dcl.init.ref] paragraph 5 as follows:
A reference to type “cv1 T1” is initialized by an expression of type “cv2 T2” as follows:
If the initializer expression
is an lvalue (but is not a bit-field), and “cv1 T1” is reference-compatible with “cv2 T2,” or
has a class type (i.e., T2 is a class type), where T1 is not reference-related to T2, and can be implicitly converted to an lvalue of type “cv3 T3,” where “cv1 T1” is reference-compatible with “cv3 T3” [Footnote: This requires a conversion function (12.3.2 [class.conv.fct]) returning a reference type. —end footnote] (this conversion is selected by enumerating the applicable conversion functions (13.3.1.6 [over.match.ref]) and choosing the best one through overload resolution (13.3 [over.match])),
then...
[Drafting note: this resolution makes the example in the issue description ill-formed.]
The overload resolution rules for ranking a template against a non-template function differ for conversion functions in a surprising way. 13.3.3 [over.match.best] lists four checks, the last three concern this report. For the non-conversion operator case, checks 2 and 3 are applicable, whereas for the conversion operator case checks 3 and 4 are applicable. Checks 2 and 4 concern the ranking of argument and return value conversion sequences respectively. Check 3 concerns only the templatedness of the functions being ranked, and will prefer a non-template to a template. Notice that this check happens after argument conversion sequence ranking, but before return value conversion sequence ranking. This has the effect of always selecting a non-template conversion operator, as the following example shows:
struct C
{
inline operator int () { return 1; }
template <class T> inline operator T () { return 0; }
};
inline long f (long x) { return x; }
int
main (int argc, char *argv[])
{
return f (C ());
}
The non-templated C::operator int function will be selected, rather than the apparently better C::operator long<long> instantiation. This is a surprise, and resulted in a bug report where the user expected the template to be selected. In addition some C++ compilers have implemented the overload ranking as if checks 3 and 4 were transposed.
Is this ordering accidental, or is there a rationale?
Notes from the April, 2005 meeting:
The CWG agreed that the template/non-template distinction should be the final tie-breaker.
Proposed resolution (March, 2007):
In the second bulleted list of 13.3.3 [over.match.best] paragraph 1, move the second and third bullets to the end of the list, to read as follows:
for some argument j, ICSj(F1) is a better conversion sequence than ICSj(F2), or, if not that,
the context is an initialization by user-defined conversion (see 8.5 [dcl.init], 13.3.1.5 [over.match.conv], and 13.3.1.6 [over.match.ref]) and the standard conversion sequence from the return type of F1 to the destination type (i.e., the type of the entity being initialized) is a better conversion sequence than the standard conversion sequence from the return type of F2 to the destination type, [Example: ... —end example] or, if not that,
- F1 is a non-template function and F2 is a function template specialization, or, if not that,
F1 and F2 are function template specializations, and the function template for F1 is more specialized than the template for F2 according to the partial ordering rules described in 14.5.6.2 [temp.func.order].
14.6.2 [temp.dep] paragraph 3 reads,
In the definition of a class template or a member of a class template, if a base class of the class template depends on a template-parameter, the base class scope is not examined during unqualified name lookup either at the point of definition of the class template or member or during an instantiation of the class template or member.
This wording applies only to definitions of class templates and members of class templates. That would make the following program ill-formed (but it probably should be well-formed):
struct B{ void f(int); };
template<class T> struct D: B { };
template<class T> void g() {
struct B{ void f(); };
struct A: D<T> {
B m;
};
A a;
a.m.f(); // Presumably, we want ::g()::B::f(), not ::B::f(int)
}
int main () {
g<int>();
return 0;
}
I suspect the wording should be something like
In the definition of a class template or a class defined (directly or indirectly) within the scope of a class template or function template, if a base class...
That should also include deeply nested classes in templates, local classes of non-template member functions of member classes of class templates, etc.
Proposed resolution (October, 2006):
Change 14.6.2 [temp.dep] paragraph 3 as follows:
In the definition of a class or class templateor a member of a class template, if a base classof the class templatedepends on a template-parameter, the base class scope is not examined during unqualified name lookup either at the point of definition of the class template or member or during an instantiation of the class template or member.
It does not appear that the following example is well-formed, although most compilers accept it:
template <typename T> T foo();
template <> int foo();
The reason is that 14.7.3 [temp.expl.spec] paragraph 11 only allows trailing template-arguments to be omitted if they “can be deduced from the function argument type,” and there are no function arguments in this example.
14.7.3 [temp.expl.spec] should probably say “function type” instead of “function argument type.” Also, a subsection should probably be added to 14.8.2 [temp.deduct] to cover “Deducing template arguments from declarative contexts” or some such. It would be essentially the same as 14.8.2.2 [temp.deduct.funcaddr] except that the function type from the declaration would be used as the type of P.
Proposed resolution (March, 2008):
Insert the following as a new subsection after 14.8.2.5 [temp.deduct.type]:
14.8.2.6 Deducing template arguments in a declaration that names a specialization of a function template [temp.deduct.funcdecl] Template arguments can be deduced from the function type specified when declaring a specialization of a function template. [Note: this can occur in the context of an explicit specialization, an explicit instantiation, or a friend declaration. —end note] The function template's function type and the declared type are used as the types of P and A, and the deduction is done as described in 14.8.2.5 [temp.deduct.type].
Change 14.7.3 [temp.expl.spec] paragraph 11 as follows:
A trailing template-argument can be left unspecified in the template-id naming an explicit function template specialization provided it can be deduced from the functionargumenttype (14.8.2.6 [temp.deduct.funcdecl])...
The last two sentences of 14.8.2 [temp.deduct] paragraph 5 read:
When all template arguments have been deduced or obtained from default template arguments, all uses of template parameters in non-deduced 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.
Shouldn't the substitution occur for all uses of the parameters, so that any of them could result in deduction failure?
Proposed resolution (October, 2006):
Change 14.8.2 [temp.deduct] paragraph 5 as follows:
...When all template arguments have been deduced or obtained from default template arguments, all uses of template parameters innon-deduced contextsthe function type are replaced with the corresponding deduced or default argument values. If the substitution results in an invalid type, as described above, type deduction fails.
A customer of ours recently brought the following example to our attention. There's some question as to whether the Standard adequately addresses this example, and if it does, whether the outcome is what we'd like to see. Here's the example:
struct Abs {
virtual void x() = 0;
};
struct Der: public Abs {
virtual void x();
};
struct Cnvt {
template <typename F> Cnvt(F);
};
void foo(Cnvt a);
void foo(Abs &a);
void f() {
Der d;
Abs *a = &d;
foo(*a); // #1
return 0;
}
The question is how to perform overload resolution for the call at #1. To do that, we need to determine whether foo(Cnvt) is a viable function. That entails deciding whether there is an implicit conversion sequence that converts Abs (the type of *a in the call) to Cnvt (13.3.2 [over.match.viable] paragraph 3), and that involves a recursive invocation of overload resolution.
The initialization of the parameter of foo(Cnvt) is a case of copy-initialization of a class by user-defined conversion, so the candidate functions are the converting constructors of Cnvt (13.3.1.4 [over.match.copy] paragraph 1), of which there are two: the implicitly-declared copy constructor and the constructor template.
According to 14.7.1 [temp.inst] paragraph 8,
If a function template or a member function template specialization is used in a way that involves overload resolution, a declaration of the specialization is implicitly instantiated (14.8.3 [temp.over]).
Template argument deduction results in “synthesizing” (14.8.3 [temp.over] paragraph 1) (or “instantiating,” 14.7.1 [temp.inst] paragraph 8) the declaration
Cnvt::Cnvt(Abs)
Because Abs is an abstract class, this declaration violates the restriction of 10.4 [class.abstract] paragraph 3 (“An abstract class shall not be used as a parameter type...”), and because a parameter of an abstract class type does not cause a deduction failure (it's not in the bulleted list in 14.8.2 [temp.deduct] paragraph 2), the program is ill-formed. This error is reported by both EDG and Microsoft compilers, but not by g++.
It seems unfortunate that the program would be rendered ill-formed by a semantic violation in a declaration synthesized solely for the purpose of overload resolution analysis; foo(Cnvt) would not be selected by overload resolution, so Cnvt::Cnvt(Abs) would not be instantiated.
There's at least some indication that a parameter with an abstract class type should be a deduction failure; an array element of abstract class type is a deduction failure, so one might expect that a parameter would be, also.
(See also issue 339; this question might be addressed as part of the direction described in the notes from the July, 2007 meeting.)
Notes from the June, 2008 meeting:
Paper N2634, adopted at the June, 2008 meeting, replaces the normative list of specific errors accepted as deduction failures by a general statement covering all “invalid types and expressions in the immediate context of the function type and its template parameter types,” so the code is now well-formed. However, the previous list is now a note, and the note should be updated to mention this case.
Proposed resolution (August, 2008):
Add a new bullet following the last bullet of the note in 14.8.2 [temp.deduct] paragraph 8 as follows:
Attempting to create a function type in which a parameter type or the return type is an abstract class type (10.4 [class.abstract]).
There are a couple of minor problems with the rvalue reference wording in the WP. The non-normative note in 14.8.2.1 [temp.deduct.call] paragraph 3 says,
[Note: The effect of this rule for lvalue arguments and rvalue reference parameters is that deduction in such cases will fail unless the function parameter is of the form cv T&& (14.8.2.5 [temp.deduct.type]). —end note]
It turns out that this isn't correct. For example:
template <class T> void g(basic_string<T> && );
...
basic_string<char> s;
g(s); // Note says that it should fail, we want it to call
// g<char>(basic_string<char>&&)
Additionally, consider this case:
template <class T> void f(const T&&);
...
int i;
f(i);
If we deduce T as int& in this case then f(i) calls f<int&>(int&), which seems counterintuitive. We prefer that f<int>(const int&&) be called. Therefore, we would like the wording clarified that the A& deduction rule in 14.8.2.1 [temp.deduct.call] paragraph 3 applies only to the form T&& and not to cv T&& as the note currently implies.
These are minor tweaks to the rvalue reference wording and a fallout from issue 540. In particular, the major applications of move semantics and perfect forwarding are not impacted with respect to the original intentions of the rvalue reference work by these suggestions.
Suggested resolution:
Change 14.8.2.1 [temp.deduct.call] paragraph 3 as follows:
If P is
an rvalue reference typeof the form T&&, where T is a template parameter, and the argument is an lvalue,the type A& is used in place of A for type deductionT is deduced as A&. [Example:template <typename T> int f(T&&); int i; int j = f(i); // calls f<int&>(i) template <typename T> int g(const T&&); int k; int n = g(k); // calls g<int>(k)—end example]
[Note: The effect of this rule for lvalue arguments and rvalue reference parameters is that deduction in such cases will fail unless the function parameter is of the form cv T&& (14.8.2.5 [temp.deduct.type]). —end note]
Proposed resolution (August, 2008):
Change 14.8.2.1 [temp.deduct.call] paragraph 3 as follows:
If P is
an rvalue reference typeof the form T&&, where T is a template parameter, and the argument is an lvalue, the type A& is used in place of A for type deduction. [Example:template <typename T> int f(T&&); int i; int j = f(i); // calls f<int&>(i) template <typename T> int g(const T&&); int k; int n = g(k); // calls g<int>(k)—end example]
[Note: The effect of this rule for lvalue arguments and rvalue reference parameters is that deduction in such cases will fail unless the function parameter is of the form cv T&& (14.8.2.5 [temp.deduct.type]). —end note]
14.8.2.5 [temp.deduct.type] paragraph 22 describes how we cope with partial ordering between two function templates that differ because one has a function parameter pack while the other has a normal function parameter. However, this paragraph was meant to apply to template parameter packs as well, e.g., to help with partial ordering of class template partial specializations:
template <class T1, class ...Z> class S; // #1
template <class T1, class ...Z> class S<T1, const Z&...> {}; // #2
template <class T1, class T2> class S<T1, const T2&> {};; // #3
S<int, const int&> s; // both #2 and #3 match; #3 is more specialized
Suggested resolution:
Change 14.8.2.5 [temp.deduct.type] paragraphs 9-10 as follows (and add the example above to paragraph 9):
If P has a form that contains <T> or <i>, then each argument Pi of the respective template argument list P is compared with the corresponding argument Ai of the corresponding template argument list of A. If the template argument list of P contains a pack expansion that is not the last template argument, the entire template argument list is a non-deduced context. If Pi is a pack expansion, then the pattern of Pi is compared with each remaining argument in the template argument list of A. Each comparison deduces template arguments for subequent positions in the template parameter packs expanded by Pi. During partial ordering (14.8.2.4 [temp.deduct.partial]), if Ai was originally a pack expansion and Pi is not a pack expansion, or if P does not contain a template argument corresponding to Ai, argument deduction fails.
Similarly, if P has a form that contains (T), then each parameter type Pi of the respective parameter-type-list of P is compared with the corresponding parameter type Ai of the corresponding parameter-type-list of A. If the parameter-declaration corresponding to Pi is a function parameter pack, then the type of its declarator-id is compared with each remaining parameter type in the parameter-type-list of A. Each comparison deduces template arguments for subsequent positions in the template parameter packs expanded by the function parameter pack. During partial ordering (14.8.2.4 [temp.deduct.partial]), if Ai was originally a function parameter pack and Pi is not a function parameter pack, or if P does not contain a function parameter type corresponding to Ai, argument deduction fails. [Note: A function parameter pack can only occur at the end of a parameter-declaration-list (8.3.5 [dcl.fct]). —end note]
According to 15.1 [except.throw] paragraph 3,
The type of the throw-expression shall not be an incomplete type, or a pointer to an incomplete type other than (possibly cv-qualified) void.
This disallows cases like the following, because str has an incomplete type (an array of unknown size):
extern const char str[];
void f() {
throw str;
}
The array-to-pointer conversion is applied to the operand of throw, so there's no problem creating the exception object, which is the reason for the restriction on incomplete types. I believe this case should be permitted.
Notes from the April, 2005 meeting:
The CWG agreed that the example should be permitted. Note that the reference to throw-expression in the cited text is incorrect; a throw-expression includes the throw keyword and is always of type void. This wording problem is addressed in the proposed resolution for issue 475.
Proposed resolution (October, 2006)
Change 15.1 [except.throw] paragraph 3 as indicated:
...The type of the throw-expression shall notIf the type of the exception object would be an incomplete type, or a pointer to an incomplete type other than (possibly cv-qualified) void the program is ill-formed...
According to 15.2 [except.ctor] paragraph 2,
An object that is partially constructed or partially destroyed will have destructors executed for all of its fully constructed subobjects, that is, for subobjects for which the principal constructor (12.6.2 [class.base.init]) has completed execution and the destructor has not yet begun execution. Similarly, if the non-delegating constructor for an object has completed execution and a delegating constructor for that object exits with an exception, the object's destructor will be invoked. Should a constructor for an element of an automatic array throw an exception, only the constructed elements of that array will be destroyed.
The requirement for destruction of array elements explicitly applies only to automatic arrays, and one might conclude from the context that only automatic class objects are in view as well, although that is not explicitly stated. What about local static arrays and class objects? Are they intended also to be subject to the requirement that fully-constructed subobjects are to be destroyed?
Proposed resolution (October, 2006):
Change 15.2 [except.ctor] paragraph 2 as follows:
An object that is partially constructed or partially destroyed will have destructors executed for all of its fully constructed subobjects, that is, for subobjects for which the principal constructor (12.6.2 [class.base.init]) has completed execution and the destructor has not yet begun execution. Similarly, if the non-delegating constructor for an object has completed execution and a delegating constructor for that object exits with an exception, the object’s destructor will be invoked.Should a constructor for an element of an automatic array throw an exception, only the constructed elements of that array will be destroyed.If the object or array was allocated in a new-expression, the matching deallocation function (3.7.3.2 [basic.stc.dynamic.deallocation], 5.3.4 [expr.new], 12.5 [class.free]), if any, is called to free the storage occupied by the object.
The destruction of local static objects occurs at the same time as that of non-local objects (3.6.3 [basic.start.term] paragraph 1) and the execution of functions registered with std::atexit (paragraph 3). According to 15.5.1 [except.terminate] paragraph 1, std::terminate is called if a destructor for a non-local object or a function registered with std::atexit exits via an exception, but the Standard is silent about the result of throwing an exception from a destructor for a local static object. Presumably this is an oversight and the same rules should apply to destruction of local static objects.
Proposed resolution (March, 2008):
Change 15.5.1 [except.terminate] paragraph 1, fourth bullet as indicated, and add an additional bullet to follow it:
when construction or destruction of a non-local object
with static storage duration exits using an exception (3.6.2
[basic.start.init]), or
when destruction of an object with static storage duration exits using an exception (3.6.3 [basic.start.term]), or
The description of preprocessing expressions in 16.1 [cpp.cond] paragraph 4 says,
The resulting tokens comprise the controlling constant expression which is evaluated according to the rules of 5.19 using arithmetic that has at least the ranges specified in 18.2 [support.limits], except that all signed and unsigned integer types act as if they have the same representation as, respectively, intmax_t or uintmax_t (18.3.2).
However, this does not address the type implicitly assigned to integral literals. For example, in an implementation where int is 32 bits and long long is 64 bits, is a literal like 0xffffffff signed or unsigned? WG14 adopted DR 265 to deal with this issue in the essentially-identical wording in C99; we should probably follow suit for C++.
Proposed Resolution (November, 2006):
Change 16.1 [cpp.cond] paragraph 4 as follows:
...and then each preprocessing token is converted into a token. The resulting tokens comprise the controlling constant expression which is evaluated according to the rules of 5.19 [expr.const] using arithmetic that has at least the ranges specified in 18.2 [support.limits], except that. For the purposes of that token conversion and evaluation all signed and unsigned integer types act as if they have the same representation as, respectively, intmax_t or uintmax_t (18.3.2 [stdinth])[Footnote: Thus on an implementation where std::numeric_limits<int>::max() is 0x7FFF and std::numeric_limits<unsigned int>::max() is 0xFFFF, the integer literal 0x8000 is signed and positive within a #if expression even though it is unsigned in translation phase 7 (2.1 [lex.phases]). —end footnote]. This includes interpreting character literals...
In language imported directly from the C Standard, 16.2 [cpp.include] paragraph 5 says,
The implementation provides unique mappings for sequences consisting of one or more nondigits (2.10 [lex.name]) followed by a period (.) and a single nondigit.
This is clearly intended to support C header names like stdio.h. However, C++ has header names like cstdio that do not conform to this pattern but still presumably require “unique mappings.”
Proposed resolution (April, 2006):
Change 16.2 [cpp.include] paragraph 5 as indicated:
The implementation provides unique mappings between the delimited sequence and the external source file name for sequences consisting of one or more nondigits or digits (2.10 [lex.name]), optionally followed by a period (.) and a single nondigit...
(Clark Nelson will discuss this revision with WG14.)
Additional notes (October, 2006):
WG14 takes no position on this proposed change.
Clause 16 [cpp] refers in several places to “character string literals” without specifying whether they are narrow or wide strings. For instance, what kind of string does the # operator (16.3.2 [cpp.stringize]) produce?
16.4 [cpp.line] paragraph 1 says,
The string literal of a #line directive, if present, shall be a character string literal.
Is “character string literal” intended to mean a narrow string literal? (Also, there is no string-literal mentioned in the grammatical descriptions of #line; paragraph 4 reads,
which is apparently intended to suggest a string literal but does not use the term.)
16.8 [cpp.predefined] should also specify what kind of character string literals are produced by the various string-valued predefined macros.
Notes from the July, 2007 meeting:
The CWG affirmed that all the string literals mentioned in Clause 16 [cpp] are intended to be narrow strings.
Proposed resolution (September, 2007)
Change the footnote in 16 [cpp] paragraph 1 as follows:
Thus, preprocessing directives are commonly called “lines.” These “lines” have no other syntactic significance, as all white space is equivalent except in certain situations during preprocessing (see the #characterstring literal creation operator in 16.3.2 [cpp.stringize], for example).
Change 16.3.2 [cpp.stringize] paragraph 2 as follows:
If, in the replacement list, a parameter is immediately preceded by a # preprocessing token, both are replaced by a singlecharacternarrow string literal preprocessing token that contains the spelling of the preprocessing token sequence for the corresponding argument... Otherwise, the original spelling of each preprocessing token in the argument is retained in thecharacternarrow string literal, except for special handling for producing the spelling of string literals and character literals: a \ character is inserted before each " and \ character of a character literal or string literal (including the delimiting " characters). If the replacement that results is not a validcharacternarrow string literal, the behavior is undefined. Thecharacternarrow string literal corresponding to an empty argument is "". The order of evaluation of # and ## operators is unspecified.
Change 16.3.5 [cpp.scope] paragraph 6 as follows:
To illustrate the rules for creatingcharacternarrow string literals and concatenating tokens, the sequence... or, after concatenation of thecharacternarrow string literals...
Change 16.4 [cpp.line] paragraph 1 as follows:
The string literal of a #line directive, if present, shall be acharacternarrow string literal.
Change 16.4 [cpp.line] paragraph 4 as follows:
...and changes the presumed name of the source file to be the contents of thecharacternarrow string literal.
Change 16.8 [cpp.predefined] paragraph 1 as follows:
__DATE__
The date of translation of the source file (a
characternarrow string literal of the form...__FILE__
The presumed name of the source file (a
characternarrow string literal)....
__TIME__
The time of translation of the source file (a
characternarrow string literal of the form...
There are a number of specifications in the Standard that should also apply to references. For example:
3 [basic] paragraphs 3-4 indicate that a reference cannot have a name because it is not an entity. (See also issue 485.)
3.4.1 [basic.lookup.unqual] paragraph 13 covers unqualified lookup in the initializer of a variable member of a namespace but not that of a reference member of a namespace. It would be very strange if the lookup in these two cases were different.
3.5 [basic.link] paragraph 8 prohibits use of a type without linkage as the type of a variable with linkage, but not as the type of a reference with linkage. (References with linkage are explicitly mentioned earlier in the section.)
3.7.1 [basic.stc.static] paragraph 3 permits local static variables but not local static references.
A number of other examples could be cited. A thorough review is needed to make sure that references are completely specified.
Proposed resolution (March, 2008):
Change 2.1 [lex.phases] paragraph 1, number 9 as follows:
All external object and function
entity references are resolved. Library components are linked
to satisfy external references to functions and objects
entities not defined in the current
translation...
Change 3.3 [basic.scope] paragraph 4, bullet 2 as follows:
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, reference, or enumerator, or all refer to functions and function templates...
Change 3.3.1 [basic.scope.pdecl] paragraph 9 as follows:
Function declarations at block scope and object or reference declarations with the extern specifier at block scope refer to declarations that are members of an enclosing namespace...
Change 3.3.8 [basic.scope.hiding] paragraph 2 as follows:
A class name (9.1 [class.name]) or enumeration name (7.2 [dcl.enum]) can be hidden by the name of an object, reference, function, or enumerator declared in the same scope. If a class or enumeration name and an object, reference, function, or enumerator are declared in the same scope (in any order) with the same name, the class or enumeration name is hidden wherever the object, reference, function, or enumerator name is visible.
Change 3.4.1 [basic.lookup.unqual] paragraph 14 as follows:
If a variable or reference member of a namespace is defined outside of the scope of its namespace then any nameusedthat appears in the definition of thevariablemember (after the declarator-id) is looked up as if the definition of thevariablemember occurred in its namespace...
Change 3.4.3 [basic.lookup.qual] paragraph 1 as follows:
...During the lookup for a name preceding the :: scope resolution operator, object, reference, function, and enumerator names are ignored...
Change 3.4.3.2 [namespace.qual] paragraph 5 as follows:
During the lookup of a qualified namespace member name, if the lookup finds more than one declaration of the member, and if one declaration introduces a class name or enumeration name and the other declarations either introduce the same object, the same reference, the same enumerator or a set of functions, the non-type name hides the class or enumeration name if and only if the declarations are from the same namespace; otherwise (the declarations are from different namespaces), the program is ill-formed.
Change 3.5 [basic.link] paragraph 6 as follows:
The name of a function declared in block scope, and the name of an object or reference declared by a block scope extern declaration, have linkage...
Change 3.5 [basic.link] paragraph 8 as follows:
...A type without linkage shall not be used as the type of a variable, reference, or function with linkage, unlessthe variable or functionthat entity has extern "C" linkage...
Change 3.5 [basic.link] paragraph 10 as follows:
...the types specified by all declarations referring to a given object, reference, or function shall be identical...
Change 3.6.1 [basic.start.main] paragraph 1 as follows:
...Dynamic initialization of an object or reference is either ordered or unordered. Definitions of explicitly specialized class template static data members have ordered initialization. Other class template static data members (i.e., implicitly or explicitly instantiated specializations) have unordered initialization. Other objects and references defined in namespace scope have ordered initialization. Objects and references defined within a single translation unit and with ordered initialization shall be initialized in the order of their definitions in the translation unit. The order of initialization is unspecified for objects and references with unordered initialization and for objects and references defined in different translation units. An unordered initialization is indeterminately sequenced with respect to every other dynamic initialization. [Note: 8.5.1 [dcl.init.aggr] describes the order in which aggregate members are initialized. The initialization of local static objects and references is described in 6.7 [stmt.dcl]. —end note]
Change 3.6.1 [basic.start.main] paragraph 3 as follows:
It is implementation-defined whether or not the dynamic initialization (8.5 [dcl.init], 9.4 [class.static], 12.1 [class.ctor], 12.6.1 [class.expl.init]) of an object or reference of namespace scope is done before the first statement of main. If the initialization is deferred to some point in time after the first statement of main, it shall occur before the first use of any function,orobject, or reference defined in the same translation unit as the object or reference to be initialized. [Footnote: An object or reference defined in namespace scope having initialization with side-effects must be initialized even if it is not used (3.7.1). —end footnote]
Change 3.7.1 [basic.stc.static] paragraph 3 as follows:
The keyword static can be used to declare a local variable or reference with static storage duration. [Note: 6.7 [stmt.dcl] describesthetheir initializationof local static variables; 3.6.3 [basic.start.term] describesthetheir destructionof local static variables. —end note]
Change 5.1 [expr.prim] paragraph 4 as follows:
...The result is an lvalue if the entity is a function,orvariable, or reference... [Note: the use of :: allowsa type, an object, a function, an enumerator, or a namespacean entity declared in the global namespace to be referred to even if itsidentifiername has been hidden (3.4.3 [basic.lookup.qual]). —end note]
Change 5.1 [expr.prim] paragraph 7 as follows:
...The result is an lvalue if the entity is a function, variable, reference, or data member.
Change 5.1 [expr.prim] paragraph 8 as follows:
...The result is an lvalue if the member is a function,or avariable, or reference.
Change 6.5.1 [stmt.while] paragraph 2 as follows:
...The object or reference created in a condition is destroyed and created with each iteration of the loop...
Change 6.7 [stmt.dcl] paragraph 2 as follows:
Variables and references with automatic storage duration (3.7.2 [basic.stc.auto]) are initialized each time their declaration-statement is executed...
Change 6.7 [stmt.dcl] paragraph 3 as follows:
...A program that jumps from a point where a local variable or reference with automatic storage duration is not in scope to a point where it is in scope is ill-formed unlessthe variable hasit is a variable with trivial type (3.9 [basic.types]) and is declared without an initializer (8.5 [dcl.init])...
Change 6.7 [stmt.dcl] paragraph 4 as follows:
The zero-initialization (8.5 [dcl.init]) of all local objects with static storage duration (3.7.1 [basic.stc.static]) is performed before any other initialization takes place. When initialized with a constant expression, a local reference with static storage duration or aAlocal object of trivial or literal type (3.9 [basic.types]) with static storage durationinitialized with constant-expressionsis initialized before its block is first entered. An implementation is permitted to perform early initialization of other local objects with static storage duration under the same conditions that an implementation is permitted to statically initialize an object with static storage duration in namespace scope (3.6.2 [basic.start.init]). Otherwise such an object or reference is initialized the first time control passes through its declaration; such an object or reference is considered initialized upon the completion of its initialization. If the initialization exits by throwing an exception, the initialization is not complete, so it will be tried again the next time control enters the declaration. If control re-enters the declaration (recursively) while the object or reference is being initialized, the behavior is undefined...
Change 7.1.1 [dcl.stc] paragraphs 2-7 as follows:
The register specifier shall be applied only to names of objects and references declared in a block (6.3 [stmt.block]) or to function parameters (8.4 [dcl.fct.def]). It specifies that the named object or reference has automatic storage duration (3.7.2 [basic.stc.auto]). An object or reference declared without a storage-class-specifier at block scope or declared as a function parameter has automatic storage duration by default.
A register specifier is a hint to the implementation that the object or reference so declared will be heavily used. [Note: the hint can be ignored and in most implementations it will be ignored if the address of the object is taken. —end note]
The static specifier can be applied only to names of objects, references, and functions and to anonymous unions (9.5 [class.union]). There can be no static function declarations within a block, nor any static function parameters. A static specifier used in the declaration of an object or reference declares the
objectentity to have static storage duration (3.7.1 [basic.stc.static]). A static specifier can be used in declarations of class members; 9.4 [class.static] describes its effect. For the linkage of a name declared with a static specifier, see 3.5 [basic.link].The extern specifier can be applied only to the names of objects, references, and functions. The extern specifier cannot be used in the declaration of class members or function parameters. For the linkage of a name declared with an extern specifier, see 3.5 [basic.link]. [Note: The extern keyword can also be used in explicit-instantiations and linkage-specifications, but it is not a storage-class-specifier in such contexts. —end note]
A name declared in a namespace scope without a storage-class-specifier has external linkage unless it has internal linkage because of a previous declaration and provided it is not declared const. Objects declared const and not explicitly declared extern have internal linkage.
The linkages implied by successive declarations for a given entity shall agree. That is, within a given scope, each declaration declaring the same object or reference name or the same overloading of a function name shall imply the same linkage. Each function in a given set of overloaded functions can have a different linkage, however...
Change 7.1.6.4 [dcl.spec.auto] paragraph 1 as follows:
The auto type-specifier signifies that the type of an object or reference being declared shall be deduced from its initializer...
Change 7.1.6.4 [dcl.spec.auto] paragraph 3 as follows:
Otherwise, the type of the object or reference is deduced from its initializer. The name of theobjectentity being declared shall not appear in the initializer expression. This use of auto is allowed when declaring objects and references in a block (6.3 [stmt.block]), in namespace scope (3.3.5 [basic.scope.namespace]), and in a for-init-statement (6.5.3 [stmt.for]).
Change 7.1.6.4 [dcl.spec.auto] paragraph 4 as follows:
The auto type-specifier can also be used in declaring an object or reference in the condition of a selection statement...
Change 7.1.6.4 [dcl.spec.auto] paragraphs 6-7 as follows:
Once the type of a declarator-id has been determined according to 8.3 [dcl.meaning], the type of the declared variable or reference using the declarator-id is determined from the type of its initializer using the rules for template argument deduction. Let T be the type that has been determined for a variable or reference identifier d. Obtain P from T by replacing the occurrences of auto with a new invented type template parameter U. Let A be the type of the initializer expression for d. The type deduced for
the variabled is then the deduced type determined using the rules of template argument deduction from a function call (14.8.2.1 [temp.deduct.call]), where P is a function template parameter type and A is the corresponding argument type. If the deduction fails, the declaration is ill-formed.If the list of declarators contains more than one declarator, the type of each declared
variableentity is determined as described above...
Change 7.3.1.1 [namespace.unnamed] paragraph 2 as follows:
The use of the static keyword is deprecated when declaring objects and references in a namespace scope (see annex D [depr]); the unnamed-namespace provides a superior alternative.
Change 7.3.4 [namespace.udir] paragraph 6 as follows:
...[Note: in particular, the name of an object, reference, function or enumerator does not hide the name of a class or enumeration declared in a different namespace...
Change 8 [dcl.decl] paragraph 1 as follows:
A declarator declares a single object, reference, function, or type, within a declaration...
Change 8 [dcl.decl] paragraph 2 as follows:
...The specifiers indicate the type, storage class or other properties of theobjects, functions or typedefsentities being declared. The declarators specify the names of theseobjects, functions or typedefs,entities and (optionally) modify the type of the specifiers with operators such as * (pointer to) and () (function returning)...
Change 8.1 [dcl.name] paragraph 1 as follows:
...This can be done with a type-id, which is syntactically a declaration for an object, reference, or function of that type that omits the name of theobject or functionentity...
Change 8.5 [dcl.init] paragraph 2 as follows:
Automatic, register, static, and external variables and references of namespace scope can be initialized by arbitrary expressions involving literals and previously declared variables and functions...
Change 8.5 [dcl.init] paragraph 4 as follows:
The order of initialization of static objects and references is described in 3.6 [basic.start] and 6.7 [stmt.dcl].
Delete the last bullet of 8.5 [dcl.init] paragraph 4, first list (zero-initialization) and replace the semicolon with a period in the preceding bullet:
if T is a reference type, no initialization is
performed.
Change 8.5.3 [dcl.init.ref] paragraph 1 as follows:
A variableAn entity declared to be a T& or T&&, that is, “reference to type T” (8.3.2 [dcl.ref]), shall be initialized by an object, or function, of type T or by an object that can be converted into a T...
Change 9.1 [class.name] paragraph 2 as follows:
...If a class name is declared in a scope where an object, reference, function, or enumerator of the same name is also declared, then when both declarations are in scope, the class can be referred to only using an elaborated-type-specifier (3.4.4 [basic.lookup.elab])...
Change 9.4.2 [class.static.data] paragraph 6 as follows:
Static data members are initialized and destroyed exactly like non-local objects and references (3.6.2 [basic.start.init], 3.6.3 [basic.start.term]).
Change 9.8 [class.local] paragraph 1 as follows:
...Declarations in a local class can use only type names,staticvariables and references with static storage duration,extern variables andfunctions, and enumerators from the enclosing scope...
Change 10.2 [class.member.lookup] paragraph 4 as follows:
...[Note: Looking up a name in an elaborated-type-specifier (3.4.4 [basic.lookup.elab]) or base-specifier (clause 10 [class.derived]), for instance, ignores all non-type declarations, while looking up a name in a nested-name-specifier (3.4.3 [basic.lookup.qual]) ignores function, object, reference, and enumerator declarations...
Change 14 [temp] paragraph 5 as follows:
A class template shall not have the same name as any other template, class, function, object, reference, enumeration, enumerator, namespace, or type in the same scope...
Change 14.8 [temp.fct.spec] paragraph 2 as follows:
Each function template specialization instantiated from a template has its own copy of any static variable or reference...
[Drafting notes: This resolution depends on the part of the resolution for issue 485 that adds references to the list of “entities.” It is also partly resolved by the proposed resolution for issue 570. No change is proposed to the text in 7.5 [dcl.link], hence reference names continue to have no language linkage, and prohibitions against conflicting linkage specifications do not apply to reference declarations.]
3.2 [basic.def.odr] paragraph 1 says,
No translation unit shall contain more than one definition of any variable, function, class type, enumeration type or template.
This says nothing about references. Is it permitted to define a reference more than once in a single translation unit? (The list in paragraph 5 of things that can have definitions in multiple translation units does not include references.)
Proposed resolution (March, 2008):
Change 3.2 [basic.def.odr] paragraph 1 as follows:
No translation unit shall contain more than one definition of any variable, reference, function, class type, enumeration type or template.
Change 3.2 [basic.def.odr] paragraph 2 as follows:
...An object, reference, or non-overloaded function whose name appears as a potentially-evaluated expression is used unless it is an object that satisfies the requirements for appearing in a constant expression...
Change 3.2 [basic.def.odr] paragraph 3 as follows:
Every program shall contain exactly one definition of every non-inline function,orobject, or reference that is used in that program...
(Note: this resolution also resolves part of issue 633.)
The various uses of the term “declarative region” throughout the Standard indicate that the term is intended to refer to the entire block, class, or namespace that contains a given declaration. For example, 3.3 [basic.scope] paragraph 2 says, in part:
[Example: in
int j = 24; int main() { int i = j, j; j = 42; }The declarative region of the first j includes the entire example... The declarative region of the second declaration of j (the j immediately before the semicolon) includes all the text between { and }...
However, the actual definition given for “declarative region” in 3.3 [basic.scope] paragraph 1 does not match this usage:
Every name is introduced in some portion of program text called a declarative region, which is the largest part of the program in which that name is valid, that is, in which that name may be used as an unqualified name to refer to the same entity.
Because (except in class scope) a name cannot be used before it is declared, this definition contradicts the statement in the example and many other uses of the term throughout the Standard. As it stands, this definition is identical to that of the scope of a name.
The term “scope” is also misused. The scope of a declaration is defined in 3.3 [basic.scope] paragraph 1 as the region in which the name being declared is valid. However, there is frequent use of the phrase “the scope of a class,” not referring to the region in which the class's name is valid but to the declarative region of the class body, and similarly for namespaces, functions, exception handlers, etc. There is even a mention of looking up a name “in the scope of the complete postfix-expression” (3.4.5 [basic.lookup.classref] paragraph 3), which is the exact inverse of the scope of a declaration.
This terminology needs a thorough review to make it logically consistent. (Perhaps a discussion of the scope of template parameters could also be added to section 3.3 [basic.scope] at the same time, as all other kinds of scopes are described there.)
Proposed resolution (November, 2006):
Change 3.3 [basic.scope] paragraph 1 as follows:
Every name is introduced in some portion of program text called a declarative region, which isthe largest part of the program in which that name is valid, that is, in which that name may be used as an unqualified name to refer to the same entitya statement, block, function declarator, function-definition, class, handler, template-declaration, template-parameter-list of a template template-parameter, or namespace. In general, each particular nameis validmay be used as an unqualified name to refer to the entity of its declaration or to the label only within some possibly discontiguous portion of program text called its scope. To determine the scope of a declaration...
Change 3.3 [basic.scope] paragraph 3 as follows:
The names declared by a declaration are introduced into thescope in which the declaration occursdeclarative region that directly encloses the declaration, except that declaration-statements, function parameter names in the declarator of a function-definition, exception-declarations (3.3.2 [basic.scope.local]), the presence of a friend specifier (11.4 [class.friend]), certain uses of the elaborated-type-specifier (7.1.6.3 [dcl.type.elab]), and using-directives (7.3.4 [namespace.udir]) alter this general behavior.
Change 3.3.2 [basic.scope.local] paragraphs 1-3 and add a new paragraph 4 before the existing paragraph 4 as follows:
A name declared in a block (6.3 [stmt.block]) is local to that block. Its potential scope begins at its point of declaration (3.3.1 [basic.scope.pdecl]) and ends at the end of its declarative region.The declarative region of a name declared in a declaration-statement is the directly enclosing block (6.3 [stmt.block]). Such a name is local to the block.The
potential scopedeclarative region of a function parameter name(including one appearingin the declarator of a function-definition or in a lambda-parameter-declaration-clause)or of a function-local predefined variable in a function definition (8.4 [dcl.fct.def])begins at its point of declaration. If the function has a function-try-block the potential scope of a parameter or of a function-local predefined variable ends at the end of the last associated handler, otherwise it ends at the end of the outermost block of the function definition. A parameter nameis the entire function definition or lambda-expression. Such a name is local to the function definition and shall not be redeclared intheany outermost block of thefunction definition nor in the outermost block of any handler associated with a function-try-blockfunction-body (including handlers of a function-try-block) or lambda-expression.
The name in a catch exception-declarationThe declarative region of a name declared in an exception-declaration is its entire handler. Such a name is local to the handler and shall not be redeclared in the outermost block of the handler.The potential scope of any local name begins at its point of declaration (3.3.1 [basic.scope.pdecl]) and ends at the end of its declarative region.
Change 3.3.4 [basic.funscope] as indicated:
Labels (6.1 [stmt.label]) have function scope and may be used anywhere in the function in which they are declared except in members of local classes (9.8 [class.local]) of that function. Only labels have function scope.
Change 6.7 [stmt.dcl] paragraph 1 as follows:
A declaration statement introduces one or more new
identifiersnames into a block; it has the formdeclaration-statement:
block-declaration
[Note: If
an identifiera name introduced by a declaration was previously declared in an outer block, the outer declaration is hidden for the remainder of the block, after which it resumes its force (3.3.8 [basic.scope.hiding]). —end note]
[Drafting notes: This resolution deals almost exclusively with the unclear definition of “declarative region.” I've left the ambiguous use of “scope” alone for now. However sections 3.3.x all have headings reading “xxx scope,” but they don't mean the scope of a declaration but the different kinds of declarative regions and their effects on the scope of declarations contained therein. To me, it looks like most of 3.4 should refer to “declarative region” and not to “scope.”
The change to 6.7 fixes an “identifier” misuse (e.g., extern T operator+(T,T); at block scope introduces a name but not an identifier) and removes normative redundancy.]
The Standard uses the terms “block scope” and “local scope” interchangeably, but the former is never formally defined. Would it be better to use only one term consistently? “Block scope” seems to be more frequently used.
Notes from the October, 2007 meeting:
The CWG expressed a preference for the term “local scope.”
Proposed resolution (February, 2008):
Change the note in 3.3.1 [basic.scope.pdecl] paragraph 9 as follows:
[Note: friend declarations refer to functions or classes that are members of the nearest enclosing namespace, but they do not introduce new names into that namespace (7.3.1.2 [namespace.memdef]). Function declarations atblocklocal scope and object declarations with the extern specifier atblocklocal scope refer to declarations that are members of an enclosing namespace, but they do not introduce new names into that scope. —end note]
Change the example in 3.4.1 [basic.lookup.unqual] paragraph 6 as follows:
...
// 1) outermostblocklocal scope of A::n::f, before the use of i
...
Change the example in 3.4.1 [basic.lookup.unqual] paragraph 8 as follows:
...
// 1) outermostblocklocal scope of M::N::X::f, before the use of i
...
Change 3.4.1 [basic.lookup.unqual] paragraph 11 as follows:
During the lookup for a name used as a default argument (8.3.6 [dcl.fct.default]) in a function parameter-declaration-clause or used in the expression of a mem-initializer for a constructor (12.6.2 [class.base.init]), the function parameter names are visible and hide the names of entities declared in theblocklocal, class or namespace scopes containing the function declaration...
Change 3.4.1 [basic.lookup.unqual] paragraph 12 as follows:
During the lookup of a name used in the constant-expression of an enumerator-definition, previously declared enumerators of the enumeration are visible and hide the names of entities declared in theblocklocal, class, or namespace scopes containing the enum-specifier.
Change 3.4.2 [basic.lookup.argdep] paragraph 3 as follows:
Let X be the lookup set produced by unqualified lookup (3.4.1 [basic.lookup.unqual]) and let Y be the lookup set produced by argument dependent lookup (defined as follows). If X contains
a declaration of a class member, or
a
blocklocal-scope function declaration that is not a using-declaration, ora declaration that is neither a function or a function template
then Y is empty. Otherwise...
Change 3.5 [basic.link] paragraph 6 as follows:
The name of a function declared inblocklocal scope, and the name of an object declared by ablocklocal scope extern declaration, have linkage. If there is a visible declaration of an entity with linkage having the same name and type, ignoring entities declared outside the innermost enclosing namespace scope, theblocklocal scope declaration declares that same entity and receives the linkage of the previous declaration. If there is more than one such matching entity, the program is ill-formed. Otherwise, if no matching entity is found, theblocklocal scope entity receives external linkage...
Change 3.5 [basic.link] paragraph 7 as follows:
When ablocklocal scope declaration of an entity with linkage is not found to refer to some other declaration, then that entity is a member of the innermost enclosing namespace...
Change 3.6.3 [basic.start.term] paragraph 1 as follows:
Destructors (12.4 [class.dtor]) for initialized objects of static storage duration (declared atblocklocal scope or at namespace scope) are called as a result...
Change 7.1.1 [dcl.stc] paragraph 2 as follows:
...An object declared without a storage-class-specifier atblocklocal scope or declared as a function parameter has automatic storage duration by default.
Change 7.1.2 [dcl.fct.spec] paragraph 3 as follows (cf 7.1.6.4 [dcl.spec.auto] paragraph 3):
...The inline specifier shall not appearon a block scope function declarationwhen declaring a function in a block...
Change 9.5 [class.union] paragraph 3 as follows:
Anonymous unions declared in a named namespace or in the global namespace shall be declared static. Anonymous unions declaredat block scopein a block shall be declared with any storage class allowed for ablocklocal-scope variable, or with no storage class...
Change 20.7.11 [unique.ptr] paragraph 1 as follows:
TemplateThe class template unique_ptr stores a pointer to an object and deletes that object using the associated deleter when it is itself destroyed (such as when leavingblocklocal scope (6.7 [stmt.dcl])).
Change 30.3.3 [thread.lock] paragraph 1 as follows:
A lock is an object that holds a reference to a mutex and may unlock the mutex during the lock's destruction (such as when leavingblocklocal scope)...
Change Appendix B [implimits] paragraph 2, bullet 8 as follows:
Identifiers with block local scope
declared in one block [1 024].
Change C.1.7 [diff.class], reference to 9.1 [class.name] as follows:
...If the hidden name is atblocklocal scope, either the type or the struct tag has to be renamed.
Change D.9.1 [auto.ptr] paragraph 1 as follows:
Template auto_ptr stores a pointer to an object obtained via new and deletes that object when it itself is destroyed (such as when leavingblocklocal scope 6.7 [stmt.dcl]).
The Standard does not completely specify how to look up the type-name(s) in a pseudo-destructor-name (5.2 [expr.post] paragraph 1, 5.2.4 [expr.pseudo]), and what information it does have is incorrect and/or in the wrong place. Consider, for instance, 3.4.5 [basic.lookup.classref] paragraphs 2-3:
If the id-expression in a class member access (5.2.5 [expr.ref]) is an unqualified-id, and the type of the object expression is of a class type C (or of pointer to a class type C), the unqualified-id is looked up in the scope of class C. If the type of the object expression is of pointer to scalar type, the unqualified-id is looked up in the context of the complete postfix-expression.
If the unqualified-id is ~type-name, and the type of the object expression is of a class type C (or of pointer to a class type C), the type-name is looked up in the context of the entire postfix-expression and in the scope of class C. The type-name shall refer to a class-name. If type-name is found in both contexts, the name shall refer to the same class type. If the type of the object expression is of scalar type, the type-name is looked up in the scope of the complete postfix-expression.
There are at least three things wrong with this passage with respect to pseudo-destructors:
A pseudo-destructor call (5.2.4 [expr.pseudo]) is not a “class member access”, so the statements about scalar types in the object expressions are vacuous: the object expression in a class member access is required to be a class type or pointer to class type (5.2.5 [expr.ref] paragraph 2).
On a related note, the lookup for the type-name(s) in a pseudo-destructor name should not be described in a section entitled “Class member access.”
Although the class member access object expressions are carefully allowed to be either a class type or a pointer to a class type, paragraph 2 mentions only a “pointer to scalar type” (disallowing references) and paragraph 3 deals only with a “scalar type,” presumably disallowing pointers (although it could possibly be a very subtle way of referring to both non-class pointers and references to scalar types at once).
The other point at which lookup of pseudo-destructors is mentioned is 3.4.3 [basic.lookup.qual] paragraph 5:
If a pseudo-destructor-name (5.2.4 [expr.pseudo]) contains a nested-name-specifier, the type-names are looked up as types in the scope designated by the nested-name-specifier.
Again, this specification is in the wrong location (a pseudo-destructor-name is not a qualified-id and thus should not be treated in the “Qualified name lookup” section).
Finally, there is no place in the Standard that describes the lookup for pseudo-destructor calls of the form p->T::~T() and r.T::~T(), where p and r are a pointer and reference to scalar, respectively. To the extent that it gives any guidance at all, 3.4.5 [basic.lookup.classref] deals only with the case where the ~ immediately follows the . or ->, and 3.4.3 [basic.lookup.qual] deals only with the case where the pseudo-destructor-name contains a nested-name-specifier that designates a scope in which names can be looked up.
See document J16/06-0008 = WG21 N1938 for further discussion of this and related issues, including 244, 305, 399, and 414.
Proposed resolution (June, 2008):
Add a new paragraph following 5.2 [expr.post] paragraph 2 as follows:
When a postfix-expression is followed by a dot . or arrow -> operator, the interpretation depends on the type T of the expression preceding the operator. If the operator is ., T shall be a scalar type or a complete class type; otherwise, T shall be a pointer to a scalar type or a pointer to a complete class type. When T is a (pointer to) a scalar type, the postfix-expression to which the operator belongs shall be a pseudo-destructor call (5.2.4 [expr.pseudo]); otherwise, it shall be a class member access (5.2.5 [expr.ref]).
Change 5.2.4 [expr.pseudo] paragraph 2 as follows:
The left-hand side of the dot operator shall be of scalar type. The left-hand side of the arrow operator shall be of pointer to scalar type. This scalar typeThe type of the expression preceding the dot operator, or the type to which the expression preceding the arrow operator points, is the object type...
Change 5.2.5 [expr.ref] paragraph 2 as follows:
For the first option (dot) the type of the first expression (the object expression)shall be “class object” (of a complete type)is a class type. For the second option (arrow) the type of the first expression (the pointer expression)shall be “pointer to class object” (of a complete type)is a pointer to a class type. In these cases, the id-expression shall name a member of the class or of one of its base classes.
Add a new paragraph following 3.4 [basic.lookup] paragraph 2 as follows:
In a pseudo-destructor-name that does not include a nested-name-specifier, the type-names are looked up as types in the context of the complete expression.
Delete the last sentence of 3.4.5 [basic.lookup.classref] paragraph 2:
If the id-expression in a class member access (5.2.5 [expr.ref]) is an unqualified-id, and the type of the object expression is of a class type C, the unqualified-id is looked up in the scope of class C.If the type of the object expression is of pointer to scalar type, the unqualified-id is looked up in the context of the complete postfix-expression.
The resolution of issue 33 added the following wording in 3.4.2 [basic.lookup.argdep]:
In addition, if the argument is the name or address of a set of overloaded functions and/or function templates, its associated classes and namespaces are the union of those associated with each of the members of the set: the namespace in which the function or function template is defined and the classes and namespaces associated with its (non-dependent) parameter types and return type.
This wording is self-contradictory: although it claims that the treatment of overload sets is intended to be “the union of those associated with each of the members of the set,” it says that the namespace of which each function or function template is a member is to be considered an associated namespace. That is different from the case of a non-overloaded function argument; in that case, because only the type of the argument is considered, the namespace of which the function is a member is not an associated namespace. This should be rectified so that overloaded and unoverloaded functions really are treated the same.
Proposed resolution (June, 2008):
Change 3.4.2 [basic.lookup.argdep] paragraph 2 as follows:
...In addition, if the argument is the name or address of a set of overloaded functions and/or function templates, its associated classes and namespaces are the union of those associated with each of the members of the set:the namespace in which the function or function template is defined andthe classes and namespaces associated with its (non-dependent) parameter types and return type.
Is this case valid? G++ compiles it.
namespace X {
namespace Y {
struct X {
void f()
{
using namespace 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.
Proposed Resolution (November, 2006):
Change 3.4.6 [basic.lookup.udir] paragraph 1 as follows:
When looking up a namespace-name in a using-directive or namespace-alias-definition,In a using-directive or namespace-alias-definition, during the lookup for a namespace-name or for a name in a nested-name-specifier, only namespace names are considered.
According to 3.5 [basic.link] paragraph 3,
A name having namespace scope (3.3.5 [basic.scope.namespace]) has internal linkage if it is the name of
an object, reference, function or function template that is explicitly declared static or,
an object or reference that is explicitly declared const and neither explicitly declared extern nor previously declared to have external linkage;
It is not possible to declare a reference to be const.
Proposed resolution (March, 2008):
Change 3.5 [basic.link] paragraph 3 as indicated (note addition of punctuation in the first bullet):
A name having namespace scope (3.3.5 [basic.scope.namespace]) has internal linkage if it is the name of
an object, reference, function, or function template that is explicitly declared static; or,
an object
or referencethat is explicitly declared const and neither explicitly declared extern nor previously declared to have external linkage; ora data member of an anonymous union.
Given this literal type,
struct X {
constexpr X() { }
};
and this definition,
static X x;
the current specification does not require that x be statically initialized because it is not “initialized with a constant expression” (3.6.1 [basic.start.main] paragraph 1).
Lawrence Crowl:
This guarantee is essential for atomics.
Jens Maurer:
Suggestion:
A reference with static storage duration or an object of literal type with static storage duration can be initialized with a constant expression (5.19 [expr.const]) or with a constexpr constructor; this is called constant initialization.
(Not spelling out “default constructor” makes it easier to handle multiple-parameter constexpr constructors, where there isn't “a” constant expression but several.)
Peter Dimov:
In addition, there is a need to enforce static initialization for non-literal types: std::shared_ptr, std::once_flag, and std::atomic_* all have nontrivial copy constructors, making them non-literal types. However, we need a way to ensure that a constexpr constructor called with constant expressions will guarantee static initialization, regardless of the nontriviality of the copy constructor.
Proposed resolution (April, 2008):
Change 3.6.2 [basic.start.init] paragraph 1 as follows:
...A reference with static storage duration and an object of trivial or literal type with static storage duration can be initialized with a constant expression (5.19 [expr.const]); thisIf a reference with static storage duration is initialized with a constant expression (5.19 [expr.const]) or if the initialization of an object with static storage duration satisfies the requirements for the object being declared with constexpr (7.1.5 [dcl.constexpr]), that initialization is called constant initialization...
Change 6.7 [stmt.dcl] paragraph 4 as follows:
...A local object of trivial or literal type (3.9 [basic.types]) with static storage duration initialized with constant-expressions is initializedConstant initialization (3.6.2 [basic.start.init]) of a local entity with static storage duration is performed before its block is first entered...
Change 7.1.5 [dcl.constexpr] paragraph 7 as follows:
A constexpr specifier used in an object declaration declares the object as const. Such an object shall be initialized, and every expression that appears in its initializer (8.5 [dcl.init]) shall be a constant expression. Every implicit conversion used in converting the initializer expressions and every constructor call used for the initialization shall be one of those allowed in a constant expression (5.19 [expr.const])...
Replace 8.5.1 [dcl.init.aggr] paragraph 14 as follows:
When an aggregate with static storage duration is initialized with a brace-enclosed initializer-list, if all the member initializer expressions are constant expressions, and the aggregate is a trivial type, the initialization shall be done during the static phase of initialization (3.6.2 [basic.start.init]); otherwise, it is unspecified whether the initialization of members with constant expressions takes place during the static phase or during the dynamic phase of initialization.[Note: The order of initialization for aggregates with static storage duration is specified in 3.6.2 [basic.start.init] and 6.7 [stmt.dcl]. —end note]
(Note: the change to 3.6.2 [basic.start.init] paragraph 1 needs to be reconciled with the conflicting change in issue 684.)
[Picked up by evolution group at October 2002 meeting.]
The default global operators delete are specified to not throw, but there is no requirement that replacement global, or class-specific, operators delete must not throw. That ought to be required.
In particular:
We already require that all versions of an allocator's deallocate() must not throw, so that part is okay.
Rationale (04/00):
Note (March, 2008):
The Evolution Working Group has accepted the intent of this issue and referred it to CWG for action for C++0x (see paper J16/07-0033 = WG21 N2173).
Proposed resolution (March, 2008):
Change 3.7.3.2 [basic.stc.dynamic.deallocation] paragraph 3 as follows:
A deallocation function shall not terminate by throwing an exception. The value of the first argument supplied to a deallocation function...
An lvalue referring to an out-of-lifetime non-POD class objects can be used in limited ways, subject to the restrictions in 3.8 [basic.life] paragraph 6:
if the original object will be or was of a non-POD class type, the program has undefined behavior if:
the lvalue is used to access a non-static data member or call a non-static member function of the object, or
the lvalue is implicitly converted (4.10 [conv.ptr]) to a reference to a base class type, or
the lvalue is used as the operand of a static_cast (5.2.9 [expr.static.cast]) except when the conversion is ultimately to cv char& or cv unsigned char& ), or
the lvalue is used as the operand of a dynamic_cast (5.2.7 [expr.dynamic.cast]) or as the operand of typeid.
There are at least a couple of questionable things in this list. First, there is no “implicit conversion to a reference to a base class,” as assumed by the second bullet. Presumably this is intended to say that the lvalue is bound to a reference to a base class, and the cross-reference should be to 8.5.3 [dcl.init.ref], not to 4.10 [conv.ptr] (which deals with pointer conversions). However, even given that adjustment, it is not clear why it is forbidden to bind a reference to a non-virtual base class of an out-of-lifetime object, as that is just an address offset calculation. (Binding to a virtual base, of course, would require access to the value of the object and thus cannot be done outside the object's lifetime.)
The third bullet also appears questionable. It's not clear why static_cast is discussed at all here, as the only permissible static_cast conversions involving reference types and non-POD classes are to references to base or derived classes and to the same type, modulo cv-qualification; if implicit “conversion” to a base class reference is forbidden in the second bullet, why would an explicit conversion be permitted in the third? Was this intended to refer to reinterpret_cast? Also, is there a reason to allow char types but disallow array-of-char types (which are more likely to be useful than a single char)?
Proposed resolution (March, 2008):
Change 3.8 [basic.life] paragraph 5 as follows:
...If the object will be or was of a non-trivial class type, the program has undefined behavior if:
the pointer is used to access a non-static data member or call a non-static member function of the object, or
the pointer is implicitly converted (
4.10 [conv.ptr] ) to a pointer to a virtual base classtype, orthe pointer is used as the operand of a static_cast (5.2.9 [expr.static.cast])
(except when the conversion is tovoid*, or to void* and subsequently to char*, or unsigned char*).pointer to void, or to pointer to void and subsequently to pointer to cv char or pointer to cv unsigned char, orthe pointer is used as the operand of a dynamic_cast (5.2.7 [expr.dynamic.cast])...
Change 3.8 [basic.life] paragraph 6 as follows:
...if the original object will be or was of a non-trivial class type, the program has undefined behavior if:
the lvalue is used to access a non-static data member or call a non-static member function of the object, or
the lvalue is
implicitly converted (4.10 [conv.ptr])bound to a reference to a virtual base classtype(8.5.3 [dcl.init.ref]), or
the lvalue is used as the operand of a static_cast (5.2.9 [expr.static.cast]) except when the conversion is ultimately to cv char& or cv unsigned char&, orthe lvalue is used as the operand of a dynamic_cast (5.2.7 [expr.dynamic.cast]) or as the operand of typeid.
[Drafting notes: Paragraph 5 was changed to track the changes to paragraph 6. See also the resolution for issue 658.]
Is the following example well-formed?
struct S {
static char a[5];
};
char S::a[]; // Unspecified bound in definition
3.5 [basic.link] paragraph 10 certainly makes allowance for declarations to differ in the presence or absence of a major array bound. However, 3.1 [basic.def] paragraph 5 says that
A program is ill-formed if the definition of any object gives the object an incomplete type (3.9 [basic.types]).
3.9 [basic.types] paragraph 7 says,
The declared type of an array object might be an array of unknown size and therefore be incomplete at one point in a translation unit and complete later on; the array types at those two points (“array of unknown bound of T” and “array of N T”) are different types.
This wording appears to make no allowance for the C concept of “composite type;” instead, each declaration is said to have its own type. By this interpretation, the example is ill-formed, because the type declared by the definition of S::a is incomplete.
If the example is intended to be well-formed, the Standard needs explicit wording stating that an omitted array bound in a declaration is implicitly taken from that of a visible declaration of that object, if any.
Notes from the April, 2007 meeting:
The CWG agreed that this usage should be permitted.
Proposed resolution (June, 2008):
Change 8.3.4 [dcl.array] paragraph 1 as follows:
...IfExcept as noted below, if the constant expression is omitted, the type of the identifier of D is “derived-declarator-type-list array of unknown bound of T,” an incomplete object type...
Change 8.3.4 [dcl.array] paragraph 3 as follows:
When several “array of” specifications are adjacent, a multidimensional array is created; only the first of the constant expressions that specify the bounds of the arrayscanmay be omittedonly for the first member of the sequence. [Note: this elision is useful for function parameters of array types, and when the array is external and the definition, which allocates storage, is given elsewhere. —end note]In addition to declarations in which an incomplete object type is allowed, an array bound may be omitted in the declaration of a function parameter (8.3.5 [dcl.fct]).The first constant-expression canAn array bound may also be omitted when the declarator is followed by an initializer (8.5 [dcl.init]). In this case the bound is calculated from the number of initial elements (say, N) supplied (8.5.1 [dcl.init.aggr]), and the type of the identifier of D is “array of N T.” Furthermore, if there is a visible declaration of the name declared by the declarator-id (if any) in which the bound was specified, an omitted array bound is taken to be the same as in that earlier declaration.
4 [conv] paragraph 1 says,
Standard conversions are implicit conversions defined for built-in types.
However, enumeration types (which take part in the integral promotions) and class types (which take part in the lvalue-to-rvalue conversion) are not “built-in” types, so the definition of “standard conversions” is wrong.
Proposed resolution (October, 2006):
Change 4 [conv] paragraph 1 as follows:
Standard conversions are implicit conversionsdefined for built-in typeswith built-in meaning...
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.
Proposed Resolution (November, 2006):
Add the indicated words to 3.9 [basic.types] paragraph 4:
... For trivial types, the value representation is a set of bits in the object representation that determines a value, which is one discrete element of an implementation-defined set of values. Any use of an indeterminate value (5.3.4 [expr.new], 8.5 [dcl.init], 12.6.2 [class.base.init]) of a type other than unsigned char results in undefined behavior.
Change 4.1 [conv.lval] paragraph 1 as follows:
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.
Additional note (May, 2008):
The C committee is dealing with a similar issue in their DR336. According to this analysis, they plan to take almost the opposite approach to the one described above by augmenting the description of their version of the lvalue-to-rvalue conversion. The CWG did not consider that access to an unsigned char might still trap if it is allocated in a register and needs to reevaluate the proposed resolution in that light. See also issue 129.
The deprecated conversion from string literal to pointer to (non-const) character in 4.2 [conv.array] paragraph 2 has been extended to apply to char16_t and char32_t types, but not to UTF8 and raw string literals. Is this disparity intentional? Should it be extended to all new string types, reverted to just the original character types, or revoked altogether?
Additional places in the Standard that may need to change include 15.1 [except.throw] paragraph 3 and 13.3.4.1 [over.ics.rank] paragraph 3.
Proposed resolution (June, 2008):
Remove 4.2 [conv.array] paragraph 2:
A string literal (2.13.4 [lex.string]) with no prefix, with a u prefix, with a U prefix, or with an L prefix can be converted to an rvalue of type “pointer to char”, “pointer to char16_t”, “pointer to char32_t”, or “pointer to wchar_t”, respectively. In any case, the result is a pointer to the first element of the array. This conversion is considered only when there is an explicit appropriate pointer target type, and not when there is a general need to convert from an lvalue to an rvalue. [Note: this conversion is deprecated. See Annex D [depr]. —end note] For the purpose of ranking in overload resolution (13.3.3.1.1 [over.ics.scs]), this conversion is considered an array-to-pointer conversion followed by a qualification conversion (4.4 [conv.qual]). [Example: "abc" is converted to “pointer to const char” as an array-to-pointer conversion, and then to “pointer to char” as a qualification conversion. —end example]
Delete the indicated text from the third sub-bullet of the first bullet of paragraph 3 of 13.3.4.1 [over.ics.rank]:
S1 and S2 differ only in their
qualification conversion and yield similar types T1 and
T2 (4.4
[conv.qual]), respectively, and the
cv-qualification signature of type T1 is a proper subset of
the cv-qualification signature of type T2, and S1
is not the deprecated string literal array-to-pointer conversion
(4.2). [Example: ...
Delete the note from 15.1 [except.throw] paragraph 3 as follows:
A throw-expression initializes a temporary object, called the exception object, the type of which is determined by removing any top-level cv-qualifiers from the static type of the operand of throw and adjusting the type from “array of T” or “function returning T” to “pointer to T” or “pointer to function returning T”, respectively.[Note: the temporary object created for a throw-expression that is a string literal is never of type char*, char16_t*, char32_t*, or wchar_t*; that is, the special conversions for string literals from the types “array of const char”, “array of const char16_t”, “array of const char32_t”, and “array of const wchar_t” to the types “pointer to char”, “pointer to char16_t”, “pointer to char32_t”, and “pointer to wchar_t”, respectively (4.2 [conv.array]), are never applied to a throw-expression. —end note]The temporary is an lvalue...
Change the discussion of 2.13.4 [lex.string] in C.1.1 [diff.lex] as follows:
...
Difficulty of converting:
Simple syntactic transformation, because string literals can be converted to char*; (4.2 [conv.array]). The most common cases are handled by a new but deprecated standard conversion:Semantic transformation.char* p = "abc"; // valid in C, deprecated in C++ char* q = expr ? "abc" : "de"; // valid in C, invalid in C++How widely used:
Programs that have a legitimate reason to treat string literals as pointers to potentially modifiable memory are probably rare.Seldom.
Delete D.4 [depr.string]:
D.4 Implicit conversion from const strings
The implicit conversion from const to non-const qualification for string literals (4.2 [conv.array]) is deprecated.
Additional discussion (August, 2008):
The removal of this conversion for current string literals would affect overload resolution for existing programs. For example,
struct S {
S(const char*);
};
int f(char *);
int f(X);
int i = f("hello");
If the conversion were removed, the result would be a quiet change in behavior. Another alternative to consider would be a required diagnostic (without making the program ill-formed).
According to 4.5 [conv.prom] paragraph 2,
An rvalue of an unscoped enumeration type (7.2 [dcl.enum]) can be converted to an rvalue of the first of the following types that can represent all the values of the enumeration (i.e. the values in the range bmin to bmax as described in 7.2 [dcl.enum]): int, unsigned int, long int, unsigned long int, long long int, or unsigned long long int.
This wording may have surprising behavior in this case:
enum E: long { e };
void f(int);
void f(long);
void g() {
f(e); // Which f is called?
}
Intuitively, as the programmer has explicitly expressed preference for long as the underlying type, he/she might expect f(long) to be called. However, if long and int happen to have the same size, then e is promoted to int (as it is the first type in the list that can represent all values of E) and f(int) is called instead.
According to 7.2 [dcl.enum] the underlying type of an enumeration is always well-defined for both the fixed and the non-fixed cases, so it makes sense simply to promote to the underlying type unless such a type would itself require promotion.
Suggested resolution:
In 4.5 [conv.prom] paragraph 2, replace all the text from “An rvalue of an unscoped enumeration type” through the end of the paragraph with the following:
An rvalue of an unscoped enumeration type (7.2 [dcl.enum]) is converted to an rvalue of its underlying type if it is different from char16_t, char32_t, wchar_t, or has integer conversion rank greater than or equal to int. Otherwise, it is converted to an rvalue of the first of the following types that can represent all the values of its underlying type: int, unsigned int, long int, unsigned long int, long long int, or unsigned long long int.
(Note that this wording no longer needs to mention extended integer types as special cases.)
Proposed resolution (August, 2008):
Move the following text from 4.5 [conv.prom] paragraph 2 into a separate paragraph, making the indicated changes, and add the following new pargraph after it:
An rvalue of an unscoped enumeration type whose underlying type is not fixed (7.2 [dcl.enum]) can be converted to an rvalue of the first of the following types that can represent all the values of the enumeration (i.e. the values in the range bmin to bmax as described in 7.2 [dcl.enum]): int, unsigned int, long int, unsigned long int, long long int, or unsigned long long int. If none of the types in that list can represent all the values of the enumeration, an rvalue of an unscoped enumeration type can be converted to an rvalue of the extended integer type with lowest integer conversion rank (4.13 [conv.rank]) greater than the rank of long long in which all the values of the enumeration can be represented. If there are two such extended types, the signed one is chosen.
An rvalue of an unscoped enumeration type whose underlying type is fixed (7.2 [dcl.enum]) can be converted to an rvalue of its underlying type. Moreover, if integral promotion can be applied to its underlying type, an rvalue of an unscoped enumeration type whose underlying type is fixed can also be converted to an rvalue of the promoted underlying type.
There appear to be two different specifications for when aliasing is permitted. One is in 3.10 [basic.lval] paragraph 15:
If a program attempts to access the stored value of an object through an lvalue of other than one of the following types the behavior is undefined
the dynamic type of the object,
a cv-qualified version of the dynamic type of the object,
a type similar (as defined in 4.4 [conv.qual]) to the dynamic type of the object,
a type that is the signed or unsigned type corresponding to the dynamic type of the object,
a type that is the signed or unsigned type corresponding to a cv-qualified version of the dynamic type of the object,
an aggregate or union type that includes one of the aforementioned types among its members (including, recursively, a member of a subaggregate or contained union),
a type that is a (possibly cv-qualified) base class type of the dynamic type of the object,
a char or unsigned char type.
There is also a much more restrictive specification in 5.17 [expr.ass] paragraph 8:
If the value being stored in an object is accessed from another object that overlaps in any way the storage of the first object, then the overlap shall be exact and the two objects shall have the same type, otherwise the behavior is undefined.
This affects, for example, the definedness of operations on union members: when may a value be stored into one union member and accessed via another.
It should be noted that this conflict existed in C90 and is unchanged in C99 (see, for example, section 6.5 paragraph 7 and section 6.5.16.1 paragraph 3 of ISO/IEC 9899:1999, which directly parallel the sections cited above).
Notes from the October, 2006 meeting:
This issue is based on a misunderstanding of the intent of the wording in 5.17 [expr.ass] paragraph 8. Instead of being a general statement about aliasing, it's describing the situation in which the source of the value being assigned is storage that overlaps the storage of the target object. The proposed resolution should make that clearer rather than changing the specification.
Proposed resolution (June, 2008):
Add the following note at the end of 5.17 [expr.ass] paragraph 8:
If the value being stored in an object is accessed from another object that overlaps in any way the storage of the first object, then the overlap shall be exact and the two objects shall have the same type, otherwise the behavior is undefined. [Note: this restriction applies to the relationship between the left and right sides of the assignment operation; it is not a statement about how the target of the assignment may be aliased in general. See 3.10 [basic.lval]. —end note]
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.
Note (March, 2008):
This issue should be closed as NAD as a result of the rewrite of 5.19 [expr.const] in conjunction with the constexpr proposal.
It was the intention of the constexpr proposal that implementations be required to evaluate floating-point expressions at compile time. This intention is not reflected in the actual wording of 5.19 [expr.const] paragraph 2, bullet 5:
This restriction has the effect of forbidding the use of floating-point expressions in integral constant expressions.
Proposed resolution (June, 2008):
Delete bullet 6 of 5.19 [expr.const] paragraph 2:
Notes from the June, 2008 meeting:
The CWG agreed with the intent of this issue, that floating-point calculations should be permitted in constant expressions, but acknowledged that this opens the possibility of differing results between compile time and run time. Such issues should be addressed non-normatively, e.g., via a “recommended practice” note like that of C99's 6.4.4.2 or in a technical report.
Proposed resolution (August, 2008):
Delete bullet 6 of 5.19 [expr.const] paragraph 2:
Add a new paragraph after 5.19 [expr.const] paragraph 3:
[Note: Although in some contexts constant expressions must be evaluated during program translation, others may be evaluated during program execution. Since this International Standard imposes no restrictions on the accuracy of floating-point operations, it is unspecified whether the evaluation of a floating-point expression during translation yields the same result as the evaluation of the same expression (or the same operations on the same values) during program execution. [Footnote: Nonetheless, implementations are encouraged to provide consistent results, irrespective of whether the evaluation was actually performed during translation or during program execution. —end footnote] [Example:
bool f() { char array[1 + int(1 + 0.2 - 0.1 - 0.1)]; // Must be evaluated during translation int size = 1 + int(1 + 0.2 - 0.1 - 0.1); // May be evaluated at runtime return sizeof(array) == size; }It is unspecified whether the value of f() will be true or false. —end example] —end note]
The expressions that are excluded from being constant expressions in 5.19 [expr.const] paragraph 2 does not address an example like the following:
void f() {
int a;
constexpr int* p = &a; // should be ill-formed, currently isn't
}
Suggested resolution:
Add the following bullet to the list in 5.19 [expr.const] paragraph 2:
an id-expression that refers to a variable with automatic storage duration unless a permitted lvalue-to-rvalue conversion is applied (see above)
Proposed resolution (June, 2008):
Change 3.6.2 [basic.start.init] paragraph 1 as follows:
Objects with static storage duration (3.7.1 [basic.stc.static]) or thread storage duration (3.7.2) shall be zero-initialized (8.5 [dcl.init]) before any other initialization takes place.A reference with static or thread storage duration and an object of trivial or literal type with static or thread storage duration can be initialized with a constant expression (5.19 [expr.const]); this is called constant initialization.Constant initialization is performed:Together, zero-initialization and constant initialization...
if an object of trivial or literal type with static or thread storage duration is initialized with a constant expression (5.19 [expr.const]), or
if a reference with static or thread storage duration is initialized with a constant expression that is not an lvalue designating an object with thread or automatic storage duration.
Add the following in 5.19 [expr.const] paragraph 2:
an lvalue-to-rvalue conversion (4.1) unless it is applied to...
an array-to-pointer conversion (4.2 [conv.array]) that is applied to an lvalue that designates an object with thread or automatic storage duration
a unary operator & (5.3.1 [expr.unary.op]) that is applied to an lvalue that designates an object with thread or automatic storage duration
an id-expression that refers to a variable or data member of reference type;
...
(Note: the change to 3.6.2 [basic.start.init] paragraph 1 needs to be reconciled with the conflicting change in issue 688.)
The resolution to issue 195 makes “converting a pointer to a function into a pointer to an object type or vice versa” conditionally-supported behavior. In doing so, however, it overlooked the fact that void is not an “object type” (3.9 [basic.types] paragraph 9). The wording should be amended to allow conversion to and from void* types.
Proposed resolution (June, 2008):
Change 3.9.2 [basic.compound] paragraph 4 as follows:
Objects of cv-qualified (3.9.3 [basic.type.qualifier]) or cv-unqualified type void* (pointer to void)A pointer to cv-qualified or cv-unqualified void can be used to point to objects of unknown type. A void* shall be able to hold any object pointer and is thus considered to be an object pointer type, although it is not a pointer to object type (because void is not an object type).A cv-qualified or cv-unqualified (3.9.3 [basic.type.qualifier])An object of type cv void* shall have the same representation and alignment requirements asa cv-qualified or cv-unqualifiedcv char*.
Change 4.10 [conv.ptr] paragraph 1 as follows:
...A null pointer constant can be converted to a pointer type; the result is the null pointer value of that type and is distinguishable from every other value ofpointer to object or pointer to functionobject pointer or function pointer type...
Change 5.2.10 [expr.reinterpret.cast] paragraph 7 as follows:
A pointer to an objectAn object pointer can be explicitly converted toa pointer to an objectan object pointer of different type. Except that converting an rvalue of type “pointer to T1” to the type “pointer to T2” (where T1 and T2 are object types or void and where the alignment requirements of T2 are no stricter than those of T1) and back to its original type yields the original pointer value, the result of such a pointer conversion is unspecified.
Change 5.2.10 [expr.reinterpret.cast] paragraph 8 as follows:
Converting apointer to a function into a pointer to an object typea function pointer to an object pointer or vice versa is conditionally-supported...
[Drafting note: 14.1 [temp.param] paragraph 4 was not changed and thus continues to allow only pointers to objects, not object pointers, as non-type template parameters.]
For years I've noticed that people will write code like this to get the address of an object's bytes:
void foo(long* p) {
char* q = reinterpret_cast<char*>(p); // #1
// do something with the bytes of *p by using q
}
When in fact the only portable way to do it according to the standard is:
void foo(long* p) {
char* q = static_cast<char*>(static_cast<void*>(p)); // #2
// do something with the bytes of *p by using q
}
I thought reinterpret_cast existed so that vendors could provide some weird platform-specific things. However, recently Peter Dimov pointed out to me that if we substitute a class type for long above, reinterpret_cast is required to work as expected by 9.2 [class.mem] paragraph 18:
A pointer to a standard-layout struct object, suitably converted using a reinterpret_cast, points to its initial member (or if that member is a bit-field, then to the unit in which it resides) and vice versa.
So there isn't a whole lot of flexibility to do something different and useful on non-class types. Are there any implementations for which #1 actually fails? If not, I think it would be a good idea to nail reinterpret_cast down so that the standard says it does what people (correctly) think it does in practice.
Proposed resolution (March, 2008):
Change 5.2.10 [expr.reinterpret.cast] paragraph 7 as indicated:
A pointer to an object can be explicitly converted to a pointer to an object of different type. When an rvalue v of type “pointer to T1” is converted to the type “pointer to cv T2,” the result is static_cast<cv T2*>(static_cast<cv void*>(v)) if both T1 and T2 are standard-layout types (3.9 [basic.types]) and the alignment requirements of T2 are no stricter than those of T1.Except that cConverting an rvalue of type “pointer to T1” to the type “pointer to T2” (where T1 and T2 are object types and where the alignment requirements of T2 are no stricter than those of T1) and back to its original type yields the original pointer value, t. The result of any other suchapointer conversion is unspecified.
At least one implementation accepts the following example as well-formed (returning a null pointer at runtime), although others reject it at compile time:
struct A { virtual ~A(); };
struct B: private A { } b;
A* pa = dynamic_cast<A*>(&b);
Presumably the intent of 5.2.7 [expr.dynamic.cast] paragraph 5 is that all up-casts (converting from derived to base) are to be handled at compile time, regardless of whether the class involved is polymorphic or not:
If T is “pointer to cv1 B” and v has type “pointer to cv2 D” such that B is a base class of D, the result is a pointer to the unique B subobject of the D object pointed to by v. Similarly, if T is “reference to cv1 B” and v has type cv2 D such that B is a base class of D, the result is the unique B subobject of the D object referred to by v... In both the pointer and reference cases, cv1 shall be the same cv-qualification as, or greater cv-qualification than, cv2, and B shall be an accessible unambiguous base class of D.
One explanation for the implementation that accepts the example at compile time is that the final sentence is interpreted as part of the condition for the applicability of this paragraph, so that this case falls through into the description of runtime checking that follows. This (mis-)interpretation is buttressed by the example in paragraph 9, which reads in significant part:
class A { virtual void f(); };
class B { virtual void g(); };
class D : public virtual A, private B {};
void g() {
D d;
B* bp;
bp = dynamic_cast<B*>(&d); // fails
}
The “fails” comment is identical to the commentary on the lines in the example where the run-time check fails. If the interpretation that paragraph 5 is supposed to apply to all up-casts, presumably this comment should change to “ill-formed,” or the line should be removed from the example altogether.
It should be noted that this interpretation (that the example is ill-formed and the runtime check applies only to down-casts and cross-casts) rejects some programs that could plausibly be accepted and actually work at runtime. For example,
struct B { virtual ~B(); };
struct D: private virtual B { };
void test(D* pd) {
B* pb = dynamic_cast<B*>(pd); // #1
}
struct D2: virtual B, virtual D {};
void demo() {
D2 d2;
B* pb = dynamic_cast<B*>(&d2); // #2
test(&d2); // #3
}
According to the interpretation that paragraph 5 applies, line #1 is ill-formed. However, converting from D2 to B (line #2) is well-formed; if the alternate interpretation were applied, the conversion in line #1 could succeed when applied to d2 (line #3).
One final note: the wording in 5.2.7 [expr.dynamic.cast] paragraph 8 is incorrect:
The run-time check logically executes as follows:
If, in the most derived object pointed (referred) to by v, v points (refers) to a public base class subobject of a T object, and if only one object of type T is derived from the subobject pointed (referred) to by v the result is a pointer (an lvalue referring) to that T object.
Otherwise, if v points (refers) to a public base class subobject of the most derived object, and the type of the most derived object has a base class, of type T, that is unambiguous and public, the result is a pointer (an lvalue referring) to the T subobject of the most derived object.
Otherwise, the run-time check fails.
All uses of T in this paragraph treat it as if it were a class type; in fact, T is the type to which the expression is being cast and thus is either a pointer type or a reference type, not a class type.
Proposed resolution (June, 2008):
Change 5.2.7 [expr.dynamic.cast] paragraph 5 as follows:
...In both the pointer and reference cases,cv1 shall be the same cv-qualification as, or greater cv-qualification than, cv2, and B shall be an accessible unambiguous base class of Dthe program is ill-formed if cv2 is greater cv-qualification than cv1 or if B is an inaccessible or ambiguous base class of D.
Change the comment in the example in 5.2.7 [expr.dynamic.cast] paragraph 9 as follows:
bp = dynamic_cast<B*>(&d); // fails ill-formed (not a run-time check)
Change 5.2.7 [expr.dynamic.cast] paragraph 8 as follows:
TheIf C is the class type to which T points or refers, the run-time check logically executes as follows:
If, in the most derived object pointed (referred) to by v, v points (refers) to a public base class subobject of a
TC object, and if only one object of typeTC is derived from the subobject pointed (referred) to by v the result is a pointer (an lvalue referring) to thatTC object.Otherwise, if v points (refers) to a public base class subobject of the most derived object, and the type of the most derived object has a base class, of type
TC, that is unambiguous and public, the result is a pointer (an lvalue referring) to theTC subobject of the most derived object.Otherwise, the run-time check fails.
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.
Proposed resolution (December, 2006):
Change 5.3.1 [expr.unary.op] paragraph 1 as follows:
The unary * operatorperforms indirectiondereferences a pointer value: the expression to which it is applied shall be a pointer...
Change 8.3.4 [dcl.array] paragraph 8 as follows:
Theresults are added and indirection appliedvalues are added and the result is dereferenced to yield an array (of five integers), which in turn is converted to a pointer to the first of the integers.
Change 8.3.5 [dcl.fct] paragraph 9 as follows:
The binding of *fpi(int) is *(fpi(int)), so the declaration suggests, and the same construction in an expression requires, the calling of a function fpi, and thenusing indirection throughdereferencing the (pointer) result to yield an integer. In the declarator (*pif)(const char*, const char*), the extra parentheses are necessary to indicate thatindirection throughdereferencing a pointer to a function yields a function, which is then called.
Change the index for * and “dereferencing” no longer to refer to “indirection.”
[Drafting note: 26.5.9 [template.indirect.array] requires no change. Many more places in the current wording use “dereferencing” than “indirection.”]
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...
Proposed resolution (March, 2008):
Change 5.3.4 [expr.new] paragraph 18 as follows:
If any part of the object initialization described above [Footnote: ...] terminates by throwing an exception, storage has been obtained for the object, and a suitable deallocation function can be found, the deallocation function is called...
Issue 256 was closed without action, principally on the the grounds that an implementation could provide a means (command-line option, #pragma, etc.) for requesting that the allocation size be checked for validity, but that “it would not be appropriate to require this overhead for every array allocation in every program.”
This rationale may be giving too much weight to the overhead such a check would add, especially when compared to the likely cost of actually doing the storage allocation. In particular, the test essentially amounts to something like
if (max_allocation_size / sizeof(T) < num_elements)
throw std::bad_alloc();
(noting that max_allocation_size/sizeof(T) is a compile-time constant). It might make more sense to turn the rationale around and require the check, assuming that implementations could provide a mechanism for suppressing it if needed.
Suggested resolution:
In 5.3.4 [expr.new] paragraph 7, add the following words before the example:
If the value of the expression is such that the size of the allocated object would exceed the implementation-defined limit, an exception of type std::bad_alloc is thrown and no storage is obtained.
Note (March, 2008):
The Evolution Working Group has accepted the intent of issue 256 and referred it to CWG for action for C++0x (see paper J16/07-0033 = WG21 N2173).
Proposed resolution (March, 2008):
As suggested.
Notes from the June, 2008 meeting:
The CWG felt that this situation should not be treated like an out-of-memory situation and thus an exception of type std::bad_alloc (or, alternatively, returning a null pointer for a throw() allocator) would not be appropriate.
Proposed resolution (June, 2008):
Change 5.3.4 [expr.new] paragraph 8 as follows:
If the value of the expression in a direct-new-declarator is such that the size of the allocated object would exceed the implementation-defined limit, no storage is obtained and the new-expression terminates by throwing an exception of a type that would match a handler (15.3 [except.handle]) of type std::length_error (19.1.4 [length.error]). Otherwise, ifWhenthe value ofthethat expressionin a direct-new-declaratoris zero, the allocation function is called to allocate an array with no elements.
[Drafting note: std::length_error is thrown by std::string and std::vector and thus appears to be the right choice for the exception to be thrown here.]
Consider the following code, which uses double-checked locking (DCL):
Widget* Widget::Instance() {
if (pInstance == 0) { // 1: first check
lock<mutex> hold(mutW); // 2: acquire lock
if (pInstance == 0) { // 3: second check
pInstance = new Widget(); // 4: create and assign
}
} // 5: release lock
}
We want this to be fully correct when pInstance is an atomic pointer to Widget. To get that result, we have to disallow any assignment to pInstance until after the new object is fully constructed. In other words, we want this to be an invalid transformation of line 4:
pInstance = operator new(sizeof(Widget));
new (pInstance) Widget;
I don't think it would be surprising if this were disallowed. For example, if the constructor were to throw an exception, I think many people would expect the variable not to be modified. I think the question is whether it's sufficiently clearly disallowed.
This could be clarified by stating (somewhere appropriate — probably either in 5.3.4 [expr.new] paragraph 16 or paragraph 22) that the initialization of the allocated object is sequenced before the value computation of the new-expression. Then by 5.17 [expr.ass] paragraph 1 (“In all cases, the assignment is sequenced after the value computation of the right and left operands, and before the value computation of the assignment expression.”), the initialization would have to be sequenced before the assignment.
This is probably not a problem for atomic<Widget*> because its operator= is a function, and function calls provide the necessary guarantees. But for the plain pointer assignment case, there's still a question about whether the sequencing of side effects is constrained as tightly as it should be. In fact, you don't even have to throw an exception from the constructor for there to be a question.
struct X {
static X* p;
X();
};
X* X::p = new X;
When the constructor for X is invoked by this new-expression, would it be valid for X::p to be non-null? If the answer is supposed to be “no,” then I think the Standard should express that intent more clearly.
Proposed resolution (March, 2008):
Change 5.3.4 [expr.new] paragraph 22 as indicated:
WhetherInitialization of the allocated object is sequenced before the value computation of the new-expression. It is unspecified whether the allocation function is called before evaluating the constructor arguments or after evaluating the constructor arguments but before entering the constructoris unspecified. It is also unspecified whether the arguments to a constructor are evaluated if the allocation function returns the null pointer or exits using an exception.
[Drafting note: The editor may wish to move paragraph 22 up to immediately follow paragraph 16 or 17. The paragraphs numbered 18-21 deal with the case where deallocation is done because initialization terminates with an exception, whereas paragraph 22 applies more to the initialization itself, described in paragraph 16.]
The requirements for the operand of the delete operators are given in 5.3.5 [expr.delete] paragraph 2:
In either alternative, the value of the operand of delete may be a null pointer value. If it is not a null pointer value, in the first alternative (delete object), the value of the operand of delete shall be a pointer to a non-array object or a pointer to a subobject (1.8 [intro.object]) representing a base class of such an object (clause 10 [class.derived]). If not, the behavior is undefined. In the second alternative (delete array), the value of the operand of delete shall be the pointer value which resulted from a previous array new-expression. If not, the behavior is undefined.
There are no restrictions on the type of a null pointer, only on a pointer that is not null. That seems wrong.
Proposed resolution (June, 2008):
Change 5.3.5 [expr.delete] paragraph 1 as follows:
...The operand shall have a pointer to object type, or a class type having a single non-explicit conversion function (12.3.2 [class.conv.fct]) to a pointer to object type...
The current Standard leaves it implementation-defined whether integer division rounds the result toward 0 or toward negative infinity and thus whether the result of % may be negative. C99, apparently reflecting (nearly?) unanimous hardware practice, has adopted the rule that integer division rounds toward 0, thus requiring that the result of -1 % 5 be -1. Should the C++ Standard follow suit?
On a related note, does INT_MIN % -1 invoke undefined behavior? The % operator is defined in terms of the / operator, and INT_MIN / -1 overflows, which by 5 [expr] paragraph 5 causes undefined behavior; however, that is not the “result” of the % operation, so it's not clear. The wording of 5.6 [expr.mul] paragraph 4 appears to allow % to cause undefined behavior only when the second operand is 0.
Proposed resolution (August, 2008):
Change 5.6 [expr.mul] paragraph 4 as follows:
The binary / operator yields the quotient, and the binary % operator yields the remainder from the division of the first expression by the second. If the second operand of / or % is zero the behavior is undefined; otherwise (a/b)*b + a%b is equal to a. If both operands are nonnegative then the remainder is nonnegative; if not, the sign of the remainder is implementation-defined. [Footnote: According to work underway toward the revision of ISO C, the preferred algorithm for integer division follows the rules defined in the ISO Fortran standard, ISO/IEC 1539:1991, in which the quotient is always rounded toward zero. —end footnote]. For integral operands, the / operator yields the algebraic quotient with any fractional part discarded; [Footnote: This is often called “truncation towards zero.” —end footnote] if the quotient a/b is representable in the type of the result, (a/b)*b + a%b is equal to a.
[Drafting note: see C99 6.5.5 paragraph 6.]
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.
This is related to issue 276.
Proposed Resolution (November, 2006):
This issue is resolved by the resolution of issue 276.
The grammar in 7 [dcl.dcl] paragraph 1 says that a declaration-seq is either declaration or declaration-seq declaration. Some declarations end with semicolons and others (e.g. function definitions and namespace declarations) don't. This means that users who put a semicolon after every declaration are technically writing ill-formed code. The trouble is that in this respect the standard is out of sync with reality. It's convenient to allow semicolons after every declaration, and there's no implementation difficulty in doing so. All existing compilers accept this, except in extra-pedantic mode. When all implementations disagree with the standard, it's time for the standard to change.
Suggested resolution:
In the grammar in 7 [dcl.dcl] paragraph 11, change the second line in the definition of declaration-seq to
Proposed resolution (October, 2006):
Add the indicated lines to the grammar definitions in 7 [dcl.dcl] paragraph 1:
declaration:
...
namespace-definition
empty-declaration
...
static_assert-declaration:
static_assert ( constant-expression , string-literal ) ;
empty-declaration:
;
Add the following as a new paragraph after 7 [dcl.dcl] paragraph 4:
An empty-declaration has no effect.
7.1.3 [dcl.typedef] paragraph 1 says,
The typedef specifier shall not be used in a function-definition (8.4 [dcl.fct.def])...
Does this mean that the following is ill-formed?
void f() {
typedef int INT;
}
Proposed resolution (March, 2008):
Change 7.1.3 [dcl.typedef] paragraph 1 as follows:
...The typedef specifiershall not be used in a function-definition (8.4 [dcl.fct.def]), and itshall not be combined in a decl-specifier-seq with any other kind of specifier except a type-specifier, and it shall not be used in the declaration of a function parameter nor in the decl-specifier-seq of a function-definition (8.4 [dcl.fct.def])...
The constraints on type-specifiers given in 7.1.6 [dcl.type] paragraphs 2 and 3 (at most one type-specifier except as specified, at least one type-specifier, no redundant cv-qualifiers) are couched in terms of decl-specifier-seqs and declarations. However, they should also apply to constructs that are not syntactically declarations and that are defined to use type-specifier-seqs, including 5.3.4 [expr.new], 6.6 [stmt.jump], 8.1 [dcl.name], and 12.3.2 [class.conv.fct].
Proposed resolution (March, 2008):
Change 7.1.6 [dcl.type] paragraph 3 as follows:
AtIn a complete type-specifier-seq or in a complete decl-specifier-seq of a declaration, at least one type-specifier that is not a cv-qualifieris required in a declarationshall appear unlessitthe declaration declares a constructor, destructor or conversion function.
(Note: paper N2546, voted into the Working Draft in February, 2008, addresses part of this issue.)
According to 7.2 [dcl.enum] paragraph 6, the underlying type of an enumeration with an empty enumeration-list is determined as if the enumeration-list contained a single enumerator with value 0. Paragraph 7, which specifies the values of an enumeration and the minimum size of bit-field needed represent those values needs a similar provision for empty enumeration-lists.
Proposed resolution (March, 2008):
Add the indicated sentence to the end of 7.2 [dcl.enum] paragraph 5:
...It is possible to define an enumeration that has values not defined by any of its enumerators. If the enumerator-list is empty, the values of the enumeration are as if the enumeration had a single enumerator with value 0.
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.
Additional note (September, 2004)
This problem need not involve a conflict between a function and a variable; it can also arise with two variable declarations:
int x;
namespace N {
extern "C" int x;
}
Proposed resolution (March, 2008):
Change 7.5 [dcl.link] paragraph 6 as follows:
At most one function with a particular name can have C language linkage. Two declarations for a function with C language linkage with the same function name (ignoring the namespace names that qualify it) that appear in different namespace scopes refer to the same function. Two declarations for an object with C language linkage with the same name (ignoring the namespace names that qualify it) that appear in different namespace scopes refer to the same object. A function or object with C linkage shall not be declared with the same name (clause 3 [basic]) as an object or reference declared in global scope, unless both declarations denote the same object; no diagnostic is required if the declarations appear in different translation units. [Note:
because of the one definition rule (3.2 [basic.def.odr]), onlyOnly one definition for a function or object with C linkage may appear in the program (see 3.2 [basic.def.odr]); thatis,implies that such a function or object must not be defined in more than one namespace scope. For example,int x; namespace A { extern "C" int f(); extern "C" int g() { return 1; } extern "C" int h(); extern "C" int x(); // ill-formed: same name as global-scope object x } namespace B { extern "C" int f(); // A::f and B::f refer // to the same function extern "C" int g() { return 1; } // ill-formed, the function g // with C language linkage // has two definitions } int A::f() { return 98; } // definition for the function f // with C language linkage extern "C" int h() { return 97; } // definition for the function h // with C language linkage // A::h and ::h refer to the same function—end note]
The wording of 7.5 [dcl.link] paragraph 5 is suspect:
If two declarations of the same function or object specify different linkage-specifications (that is, the linkage-specifications of these declarations specify different string-literals), the program is ill-formed if the declarations appear in the same translation unit, and the one definition rule (3.2) applies if the declarations appear in different translation units.
But what if only one of the declarations has a linkage-specification, while the other is left with the default C++ linkage? Shouldn't this restriction be phrased in terms of the functions’ or objects’ language linkage rather than linkage-specifications?
(Additional note [wmm]: Is the ODR the proper vehicle for enforcing this requirement? This is dealing with declarations, not necessarily definitions. Shouldn't this say “ill-formed, no diagnostic required” instead of some vague reference to the ODR?)
Proposed resolution (June, 2008):
Change 7.5 [dcl.link] paragraph 5 as follows:
If two declarationsof the same function or objectdeclare functions with the same name and parameter-type-list (8.3.5 [dcl.fct]) to be members of the same namespace or declare objects with the same name to be members of the same namespacespecify different linkage-specifications (that is, the linkage-specifications of these declarations specify different string-literals)and the declarations give the names different language linkages, the program is ill-formedif the declarations appear in the same translation unit, and the one definition rule (3.2 [basic.def.odr]) applies; no diagnostic is required if the declarations appear in different translation units.
According to 8.3 [dcl.meaning] paragraph 1,
A declarator-id shall not be qualified except for the definition of a member function (9.3 [class.mfct]) or static data member (9.4 [class.static]) outside of its class, the definition or explicit instantiation of a function or variable member of a namespace outside of its namespace, or the definition of a previously declared explicit specialization outside of its namespace, or the declaration of a friend function that is a member of another class or namespace (11.4 [class.friend]). When the declarator-id is qualified, the declaration shall refer to a previously declared member of the class or namespace to which the qualifier refers...
This restriction prohibits examples like the following:
void f();
void ::f(); // error: qualified declarator
namespace N {
void f();
void N::f() { } // error: qualified declarator
}
There doesn't seem to be any good reason for disallowing such declarations, and a number of implementations accept them in spite of the Standard's prohibition. Should the Standard be changed to allow them?
Notes from the April, 2006 meeting:
In discussing issue 548, the CWG agreed that the prohibition of qualified declarators inside their namespace should be removed.
Proposed resolution (October, 2006):
Remove the indicated words from 8.3 [dcl.meaning] paragraph 1:
...An unqualified-id occurring in a declarator-id shall be a simple identifier except for the declaration of some special functions (12.3 [class.conv], 12.4 [class.dtor], 13.5 [over.oper]) and for the declaration of template specializations or partial specializations ().A declarator-id shall not be qualified except for the definition of a member function (9.3 [class.mfct]) or static data member (9.4 [class.static]) outside of its class, the definition or explicit instantiation of a function or variable member of a namespace outside of its namespace, or the definition of a previously declared explicit specialization outside of its namespace, or the declaration of a friend function that is a member of another class or namespace (11.4 [class.friend]).When the declarator-id is qualified, the declaration shall refer to a previously declared member of the class or namespace to which the qualifier refers, and the member shall not have been introduced by a using-declaration in the scope of the class or namespace nominated by the nested-name-specifier of the declarator-id...
[Drafting note: The omission of “outside of its class” here does not give permission for redeclaration of class members; that is still prohibited by 9.2 [class.mem] paragraph 1. The removal of the enumeration of the kinds of declarations in which a qualified-id can appear does allow a typedef declaration to use a qualified-id, which was not permitted before; if that is undesirable, the prohibition can be reinstated here.]
The following example appears to be well-formed, with the partial specialization matching the type of Y::f(), even though it is rejected by many compilers:
template<class T> struct X;
template<class R> struct X< R() > {
};
template<class F, class T> void test(F T::* pmf) {
X<F> x;
}
struct Y {
void f() {
}
};
int main() {
test( &Y::f );
}
However, 8.3.5 [dcl.fct] paragraph 4 says,
A cv-qualifier-seq shall only be part of the function type for a non-static member function, the function type to which a pointer to member refers, or the top-level function type of a function typedef declaration. The effect of a cv-qualifier-seq in a function declarator is not the same as adding cv-qualification on top of the function type. In the latter case, the cv-qualifiers are ignored.
This specification makes it impossible to write a partial specialization for a const member function:
template<class R> struct X<R() const> {
};
A template argument is not one of the permitted contexts for cv-qualification of a function type. This restriction should be removed.
Notes from the April, 2006 meeting:
During the meeting the CWG was of the opinion that the “R() const” specialization would not match the const member function even if it were allowed and so classified the issue as NAD. Questions have been raised since the meeting, however, suggesting that the template argument in the partial specialization would, in fact, match the type of a const member function (see, for example, the very similar usage via typedefs in 9.3 [class.mfct] paragraph 9). The issue is thus being left open for renewed discussion at the next meeting.
Proposed resolution (June, 2008):
Change 8.3.5 [dcl.fct] paragraph 7 as follows:
A cv-qualifier-seq shall only be part of the function type for a non-static member function, the function type to which a pointer to member refers,orthe top-level function type of a function typedef declaration, or the top-level function type of a type-id that is a template-argument for a type template-parameter. The effect... A ref-qualifier shall only be part of the function type for a non-static member function, the function type to which a pointer to member refers,orthe top-level function type of a function typedef declaration, or the top-level function type of a type-id that is a template-argument for a type template-parameter. The return type...
The wording added to 8.3.5 [dcl.fct] for declarators with late-specified return types says,
In a declaration T D where D has the form
D1 ( parameter-declaration-clause ) cv-qualifier-seqopt ref-qualifieropt exception-specificationopt -> type-id
and the type of the contained declarator-id in the declaration T D1 is “derived-declarator-type-list T,” T shall be the single type-specifier auto and the derived-declarator-type-list shall be empty.
These restrictions were intended to ensure that the return type of the function is exactly the specified type-id following the ->, not modified by declarator operators and cv-qualification.
Unfortunately, the requirement for an empty derived-declarator-type-list does not achieve this goal but instead forbids declarations like
auto (*fp)() -> int; // pointer to function returning int
while allowing declarations like
auto *f() -> int; // function returning pointer to int
The reason for this is that, according to the grammar in 8 [dcl.decl] paragraph 4, the declarator *f() -> int is parsed as a ptr-operator applied to the direct-declarator f() -> int; that is, the declarator D1 seen in 8.3.5 [dcl.fct] is just f, and the derived-declarator-type-list is thus empty.
By contrast, the declarator (*fp)() -> int is parsed as the direct-declarator (*fp) followed by the parameter-declaration-clause, etc. In this case, D1 in 8.3.5 [dcl.fct] is (*fp) and the derived-declarator-type-list is “pointer to,” i.e., not empty.
My personal view is that there is no reason to forbid the (*fp)() -> int form, and that doing so is problematic. For example, this restriction would require users desiring the late-specified return type syntax to write function parameters as function types and rely on parameter type transformations rather than writing them as pointer-to-function types, as they will actually turn out to be:
void f(auto (*fp)() -> int); // ill-formed
void f(auto fp() -> int); // OK (but icky)
It may be helpful in deciding whether to allow this form to consider the example of a function returning a pointer to a function. With the current restriction, only one of the three plausible forms is allowed:
auto (*f())() -> int; // Disallowed
auto f() -> int (*)(); // Allowed
auto f() -> auto (*)() -> int; // Disallowed
Suggested resolution:
Delete the words “and the derived-declarator-type-list shall be empty” from 8.3.5 [dcl.fct] paragraph 2.
Add a new paragraph following 8.4 [dcl.fct.def] paragraph 4:
A ptr-operator shall not be applied, directly or indirectly, to a function declarator with a late-specified return type (8.3.5 [dcl.fct]).
Proposed resolution (June, 2008):
Change the grammar in 8 [dcl.decl] paragraph 4 as follows:
Change the grammar in 8.1 [dcl.name] paragraph 1 as follows:
Change 8.3.5 [dcl.fct] paragraph 2 as follows:
... T shall be the single type-specifier autoand the derived-declarator-type-list shall be empty. Then the type...
Change all occurrences of direct-new-declarator in 5.3.4 [expr.new] to noptr-new-declarator. These changes appear in the grammar in paragraph 1 and in the text of paragraphs 6-8, as follows:
...
new-declarator:
ptr-operator new-declaratoropt
direct-noptr-new-declarator
direct-noptr-new-declarator:
[ expression ]
...
direct-noptr-new-declarator [ constant-expression ]
When the allocated object is an array (that is, the
direct-noptr-new-declarator syntax is used or the new-type-id or type-id denotes an array type), the new-expression yields a pointer to the initial element (if any) of the array. [Note: both new int and new int[10] have type int* and the type of new int[i][10] is int (*)[10] —end note]Every constant-expression in a
direct-noptr-new-declarator shall be an integral constant expression (5.19 [expr.const]) and evaluate to a strictly positive value. The expression in adirect-noptr-new-declarator shall be of integral type, enumeration type, or a class type for which a single non-explicit conversion function to integral or enumeration type exists (12.3 [class.conv]). If the expression is of class type, the expression is converted by calling that conversion function, and the result of the conversion is used in place of the original expression. If the value of the expression is negative, the behavior is undefined. [Example: given the definition int n = 42, new float[n][5] is well-formed (because n is the expression of adirect-noptr-new-declarator), but new float[5][n] is ill-formed (because n is not a constant expression). If n is negative, the effect of new float[n][5] is undefined. —end example]When the value of the expression in a
direct-noptr-new-declarator is zero, the allocation function is called to allocate an array with no elements.
The wording resulting from the resolution of issue 302 does not quite implement the intent of the issue. The revised wording of 3.2 [basic.def.odr] paragraph 2 is:
A default constructor for a class is used by default initialization or value initialization as specified in 8.5 [dcl.init].
This sounds as if 8.5 [dcl.init] specifies how and under what circumstances value initialization uses a default constructor (which was, in fact, the case for default initialization in the original wording). However, the normative text there makes it plain that value initialization does not call the default constructor (the permission granted to implementations to call the default constructor for value initialization is in a non-normative footnote).
The example that occasioned this observation raises an additional question. Consider:
struct POD {
const int x;
};
POD data = POD();
According to the (revised) resolution of issue 302, this code is ill-formed because the implicitly-declared default constructor will be implicitly defined as a result of being used by value initialization (12.1 [class.ctor] paragraph 7), and the implicitly-defined constructor fails to initialize a const-qualified member (12.6.2 [class.base.init] paragraph 4). This seems unfortunate, because the (trivial) default constructor of a POD class is otherwise not used — default initialization applies only to non-PODs — and it is not actually needed in value initialization. Perhaps value initialization should be defined to “use” the default constructor only for non-POD classes? If so, both of these problems would be resolved by rewording the above-referenced sentence of 3.2 [basic.def.odr] paragraph 2 as:
A default constructor for a non-POD class is used by default initialization or value initializationas specified in(8.5 [dcl.init]).
Notes from the April, 2006 meeting:
The approach favored by the CWG was to leave 3.2 [basic.def.odr] unchanged and to add normative wording to 8.5 [dcl.init] indicating that it is unspecified whether the default constructor is called.
Notes from the October, 2006 meeting:
The CWG now prefers that it should not be left unspecified whether programs of this sort are well- or ill-formed; instead, the Standard should require that the default constructor be defined in such cases. Three possibilities of implementing this decision were discussed:
Change 3.2 [basic.def.odr] to state flatly that the default constructor is used by value initialization (removing the implication that 8.5 [dcl.init] determines the conditions under which it is used).
Change 8.5 [dcl.init] to specify that non-union class objects with no user-declared constructor are value-initialized by first zero-initializing the object and then calling the (implicitly-defined) default constructor, replacing the current specification of value-initializing each of its sub-objects.
Add a normative statement to 8.5 [dcl.init] that value-initialization causes the implicitly-declared default constructor to be implicitly defined, even if it is not called.
Proposed resolution (June, 2008):
Change the second bullet of the value-initialization definition in 8.5 [dcl.init] paragraph 5 as follows:
if T is a non-union class type without a
user-provided constructor, then every non-static data member and
base-class component of T is value-initialized;
[Footnote: Value-initialization for such a class object may be
implemented by zero-initializing the object and then calling the
default constructor. —end footnote] the object is
zero-initialized and the implicitly-defined default constructor is
called;
8.5 [dcl.init] paragraph 2 reads,
Automatic, register, static, and external variables of namespace scope can be initialized by arbitrary expressions involving literals and previously declared variables and functions.
Both “automatic” and “static” are used to describe storage durations, “register” is a storage class specifier which indicates the object has automatic storage duration, “external” describes linkage, and “namespace scope” is a kind of scope. Automatic, register, static and external, together with namespace scope, are used to restrict the “variables.”
Register objects are only a sub-set of automatic objects and thus the word “register” is redundant and should be elided. If register objects are to be emphasized, they should be mentioned like “Automatic (including register)...”
Variables having namespace scope can never be automatic; they can only be static, with either external or internal linkage. Therefore, there are in fact no “automatic variables of namespace scope,” and the “static” in “static variables of namespace scope” is useless.
In fact, automatic and static variables already compose all variables with either external linkage or not, and thus the “external*#8221; becomes redundant, too, and the quoted sentence seems to mean that all variables of namespace scope can be initialized by arbitrary expressions. But this is not true because not all internal variables of namespace scope can. Therefore, the restrictive “external” is really necessary, not redundant.
As a result, the erroneous restrictive “automatic, register, static” should be removed and the quoted sentence may be changed to:
External variables of namespace scope can be initialized by arbitrary expressions involving literals and previously declared variables and functions.
Notes from the April, 2007 meeting:
This sentence is poorly worded, but the analysis given in the issue description is incorrect. The intent is simply that the storage class of a variable places no restrictions on the kind of expression that can be used to initialize it (in contrast to C, where variables of static storage duration can only be initialized by constant expressions).
Proposed resolution (June, 2008):
Change 8.5 [dcl.init] paragraph 2 as follows:
Automatic, register, static, and external variables of namespace scopeVariables of automatic, thread, and static storage duration can be initialized by arbitrary expressions involving literals and previously declared variables and functions...
The C committee is considering changing the definition of zero-initialization of unions to guarantee that the bytes of the entire union are set to zero before assigning 0, converted to the appropriate type, to the first member. The argument (summarized here) is for backward compatibility. The C++ Committee may want to consider the same change.
Proposed resolution (August, 2008):
Change bullet 4 of 8.5 [dcl.init] paragraph 5 as follows:
[Drafting notes: Ask a C liaison about the progress of DR16 in WG14. Since the adoption of paper N2544, unions may have static data members, hence the change to refer to the first non-static data member and the deletion of the footnote.]
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.
Proposed resolution (November, 2006):
In 3.4.3 [basic.lookup.qual] paragraph 6, change the grammar snippet as follows:
Delete 5.1 [expr.prim] paragraph 4 (“The operator :: followed by...”). [Drafting note: It's covered by paragraph 8 (type, lvalue-ness, member-ness, reference to 3.4.3.2 [namespace.qual]) and 3.4.3.2 [namespace.qual] (qualified lookup for namespace members).]
Change the grammar in 5.1 [expr.prim] paragraph 7 as follows (deleting the :: forms from qualified-id and adding :: as a new production for nested-name-specifier):
Change 5.1 [expr.prim] paragraph 8 as follows:
A nested-name-specifier thatnamesdesignates a namespace (7.3 [basic.namespace]), followed by the name of a member of that namespace...
Change 5.1 [expr.prim] paragraph 10 as follows:
In a qualified-id, if theid-expressionunqualified-id is a conversion-function-id...
In 5.2 [expr.post] paragraph 1, change the grammar as follows:
In 5.2.4 [expr.pseudo] paragraph 2, change the grammar snippet as follows:
In 7.1.6.2 [dcl.type.simple] paragraph 1, change the grammar as follows:
In 7.1.6.3 [dcl.type.elab] before paragraph 1, change the grammar as follows:
In 7.1.6.3 [dcl.type.elab] paragraph 1, change the grammar snippet as follows:
In 7.3.2 [namespace.alias] paragraph 1, change the grammar as follows:
In 7.3.3 [namespace.udecl] paragraph 1, change the grammar as follows:
In 7.3.4 [namespace.udir] before paragraph 1, change the grammar as follows:
In 8 [dcl.decl] paragraph 4, change the grammar as follows:
In 8.3.3 [dcl.mptr] paragraph 1, change the grammar snippet as follows:
In 9.2 [class.mem] before paragraph 1, change the grammar as follows:
In 10 [class.derived] paragraph 1, change the grammar as follows:
In 12.6.2 [class.base.init] paragraph 1, change the grammar as follows:
In 14.6 [temp.res] paragraph 3, change the grammar as follows:
[Drafting notes: gcc 4.1.1 rejects the example in the issue description. I still think it's a good idea to make the grammar more uniform, and there ought to be nothing special about the global scope operator. However, there is a slight change in effective grammar with these modification: all places that require a non-optional nested-name-specifier used to required at least one named level of nesting. With these changes, "::" is a valid nested-name-specifier (that denotes the global scope). Any such use needed to protect against non-class (i.e. namespace) scopes in its semantic description anyway, which also covers the "::" case.]
The current wording defining a “common initial sequence” in 9.2 [class.mem] paragraph 17 does not address the case in which one member is a bit-field and the corresponding member is not:
Two standard-layout structs share a common initial sequence if corresponding members have layout-compatible types (and, for bit-fields, the same widths) for a sequence of one or more initial members.
Presumably the intent was something like, “(and, if one of the pair is a bit-field, the other is also a bit-field of the same width).”
Proposed Resolution (October, 2007):
Change 9.2 [class.mem] paragraph 18 as follows:
... Two standard-layout structs share a common initial sequence if corresponding members have layout-compatible types(and, for bit-fields, the same widths)and either neither is a bit-field or both are bit-fields with the same widths for a sequence of one or more initial members.
Can a member of a union be of a class that has a user-declared non-default constructor? The restrictions on union membership in 9.5 [class.union] paragraph 1 only mention default and copy constructors:
An object of a class with a non-trivial default constructor (12.1 [class.ctor]), a non-trivial copy constructor (12.8 [class.copy]), a non-trivial destructor (12.4 [class.dtor]), or a non-trivial copy assignment operator (13.5.3 [over.ass], 12.8 [class.copy]) cannot be a member of a union...
(12.1 [class.ctor] paragraph 11 does say, “a non-trivial constructor,” but it's not clear whether that was intended to refer only to default and copy constructors or to any user-declared constructor. For example, 12.2 [class.temporary] paragraph 3 also speaks of a “non-trivial constructor,” but the cross-references there make it clear that only default and copy constructors are in view.)
Note (March, 2008):
This issue was resolved by the adoption of paper J16/08-0054 = WG21 N2544 (“Unrestricted Unions”) at the Bellevue meeting.
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?
Proposed resolution (February, 2008):
The existing wording in 9 [class] paragraph 10 makes the example ill-formed:
If a class-head contains a nested-name-specifier, the class-specifier shall refer to a class that was previously declared directly in the class or namespace to which the nested-name-specifier refers (i.e., neither inherited nor introduced by a using-declaration), and the class-specifier shall appear in a namespace enclosing the previous declaration.
The issue should be closed as NAD.
According to 1.3 [intro.defs], “dynamic type,”
The dynamic type of an rvalue expression is its static type.
This is not true of an rvalue reference, which can be bound to an object of a class type derived from the reference's static type.
Proposed resolution (June, 2008):
Change 1.3 [intro.defs], “dynamic type,” as follows:
the type of the most derived object (1.8 [intro.object]) to whichthe lvalue denoted byan lvalue or an rvalue-reference (clause 5 [expr]) expression refers. [Example: if a pointer (8.3.1 [dcl.ptr]) p whose static type is “pointer to class B” is pointing to an object of class D, derived from B (clause 10 [class.derived]), the dynamic type of the expression *p is “D.” References (8.3.2 [dcl.ref]) are treated similarly. —end example] The dynamic type of an rvalue expression that is not an rvalue reference is its static type.
Notes from the June, 2008 meeting:
Because expressions have an rvalue reference type only fleetingly, immediately becoming either lvalues or rvalues and no longer references, the CWG expressed a desire for a different approach that would somehow describe an rvalue that resulted from an rvalue reference instead of using the concept of an expression that is an rvalue reference, as above. This approach could also be used in the resolution of issue 664.
Additional note (August, 2008):
This issue, along with issue 664, indicates that rvalue references have more in common with lvalues than with other rvalues: they denote particular objects, thus allowing object identity and polymorphic behavior. That suggests that these issues may be just the tip of the iceberg: restrictions on out-of-lifetime access to objects, the aliasing rules, and many other specifications are written to apply only to lvalues, on the assumption that only lvalues refer to specific objects. That assumption is no longer valid with rvalue references.
This suggests that it might be better to classify all rvalue references, not just named rvalue references, as lvalues instead of rvalues, and then just change the reference binding, overload resolution, and template argument deduction rules to cater to the specific kind of lvalues that are associated with rvalue references.
The execution requirements on a conforming implementation are described twice in the Standard, once in 1.9 [intro.execution] paragraphs 5-6 and again in paragraph 11. These descriptions differ in at least a couple of important ways:
The most significant discrepancy has to do with the way output is described. In paragraph 11, the least requirements are described in terms of data written at program termination, clearly allowing arbitrary buffering, whereas in paragraph 6, the observable behavior is described in terms of calls to I/O functions. For example, there are compilers which transform a call to printf with a single argument into a call to fputs. That's valid under paragraph 11, but not under paragraph 6.
Also, in paragraph 6, volatile accesses and I/O operations are included in a single sequence, suggesting that they are equally constrained by sequencing requirements, whereas in paragraph 11, they are clearly not.
There are also editorial discrepancies that should be cleaned up.
Does the restriction in 11.5 [class.protected] apply to upcasts across protected inheritance, too? For instance,
struct B {
int i;
};
struct I: protected B { };
struct D: I {
void f(I* ip) {
B* bp = ip; // well-formed?
bp->i = 5; // aka "ip->i = 5;"
}
};
I think the rationale for the 11.5 [class.protected] restriction applies equally well here — you don't know whether ip points to a D object or not, so D::f can't be trusted to treat the protected B subobject consistently with the policies of its actual complete object type.
The current treatment of “accessible base class” in 11.2 [class.access.base] paragraph 4 clearly makes the conversion from I* to B* well-formed. I think that's wrong and needs to be fixed. The rationale for the accessibility of a base class is whether “an invented public member” of the base would be accessible at the point of reference, although we obscured that a bit in the reformulation; it seems to me that the invented member ought to be considered a non-static member for this purpose and thus subject to 11.5 [class.protected].
(See also issues 385 and 471.).Notes from October 2004 meeting:
The CWG tentatively agreed that casting across protective inheritance should be subject to the additional restriction in 11.5 [class.protected].
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"?
Sandor Mathe adds :
The standard correction for issue 244 (now in DR status) is still incomplete.
Paragraph 5 of 3.4.3 [basic.lookup.qual] is not applicable for p->T::~T since there is no nested-name-specifier. Section 3.4.5 [basic.lookup.classref] describes the lookup of p->~T but p->T::~T is still not described. There are examples (which are non-normative) that illustrate this sort of lookup but they still leave questions unanswered. The examples imply that the name after ~ should be looked up in the same scope as the name before the :: but it is not stated. The problem is that the name to the left of the :: can be found in two different scopes. Consider the following:
struct S {
struct C { ~C() { } };
};
typedef S::C D;
int main() {
D* p;
p->C::~D(); // valid?
}
Should the destructor call be valid? If there were a nested name specifier, then D should be looked for in the same scope as C. But here, C is looked for in 2 different ways. First, it is searched for in the type of the left hand side of -> and it is also looked for in the lexical context. It is found in one or if both, they must match. So, C is found in the scope of what p points at. Do you only look for D there? If so, this is invalid. If not, you would then look for D in the context of the expression and find it. They refer to the same underlying destructor so this is valid. The intended resolution of the original defect report of the standard was that the name before the :: did not imply a scope and you did not look for D inside of C. However, it was not made clear whether this was to be resolved by using the same lookup mechanism or by introducing a new form of lookup which is to look in the left hand side if that is where C was found, or in the context of the expression if that is where C was found. Of course, this begs the question of what should happen when it is found in both? Consider the modification to the above case when C is also found in the context of the expression. If you only look where you found C, is this now valid because it is in 1 of the two scopes or is it invalid because C was in both and D is only in 1?
struct S {
struct C { ~C() { } };
};
typedef S::C D;
typedef S::C C;
int main() {
D* p;
p->C::~D(); // valid?
}
I agree that the intention of the committee is that the original test case in this defect is broken. The standard committee clearly thinks that the last name before the last :: does not induce a new scope which is our current interpretation. However, how this is supposed to work is not defined. This needs clarification of the standard.
Martin Sebor adds this example (September 2003), along with errors produced by the EDG front end:
namespace N {
struct A { typedef A NA; };
template <class T> struct B { typedef B NB; typedef T BT; };
template <template <class> class T> struct C { typedef C NC; typedef T<A> CA; };
}
void foo (N::A *p)
{
p->~NA ();
p->NA::~NA ();
}
template <class T>
void foo (N::B<T> *p)
{
p->~NB ();
p->NB::~NB ();
}
template <class T>
void foo (typename N::B<T>::BT *p)
{
p->~BT ();
p->BT::~BT ();
}
template <template <class> class T>
void foo (N::C<T> *p)
{
p->~NC ();
p->NC::~NC ();
}
template <template <class> class T>
void foo (typename N::C<T>::CA *p)
{
p->~CA ();
p->CA::~CA ();
}
Edison Design Group C/C++ Front End, version 3.3 (Sep 3 2003 11:54:55)
Copyright 1988-2003 Edison Design Group, Inc.
"t.cpp", line 16: error: invalid destructor name for type "N::B<T>"
p->~NB ();
^
"t.cpp", line 17: error: qualifier of destructor name "N::B<T>::NB" does not
match type "N::B<T>"
p->NB::~NB ();
^
"t.cpp", line 30: error: invalid destructor name for type "N::C<T>"
p->~NC ();
^
"t.cpp", line 31: error: qualifier of destructor name "N::C<T>::NC" does not
match type "N::C<T>"
p->NC::~NC ();
^
4 errors detected in the compilation of "t.cpp".
John Spicer: The issue here is that we're unhappy with the destructor names when doing semantic analysis of the template definitions (not during an instantiation).
My personal feeling is that this is reasonable. After all, why would you call p->~NB for a class that you just named as N::B<T> and you could just say p->~B?
Additional note (September, 2004)
The resolution for issue 244 removed the discussion of p->N::~S, where N is a namespace-name. However, the resolution did not make this construct ill-formed; it simply left the semantics undefined. The meaning should either be defined or the construct made ill-formed.
Although the term “move constructor” appears multiple times in the library clauses and is referenced in the newly-added text for the lambda feature, it is not defined anywhere.
Notes from the June, 2008 meeting:
The only reference to “move constructor” in the core language clauses of the Standard is in 5.1.1 [expr.prim.lambda] paragraph 10; there are no semantic implications of the term. This issue will be addressed by using a function signature instead of the term, thus allowing the library section to provide a definition that is appropriate for its needs.
According to 13.3.1.3 [over.match.ctor],
When objects of class type are direct-initialized (8.5 [dcl.init]), or copy-initialized from an expression of the same or a derived class type (8.5 [dcl.init])... [the] argument list is the expression-list within the parentheses of the initializer.
However, in copy initialization (using the “=” notation), there need be no parentheses. What is the argument list in that case?
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).
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.
14.1 [temp.param] paragraph 11 currently says,
If a template-parameter of a class template is a template parameter pack, it shall be the last template-parameter. [Note: These are not requirements for function templates because template arguments might be deduced (14.8.2 [temp.deduct])...
This restriction was only meant to apply to primary class templates, not partial specializations.
Suggested resolution:
If a template-parameter of a primary class template is a template parameter pack, it shall be the last template-parameter. [Note: These are not requirements for function templates or class template partial specializations because template arguments might be deduced (14.8.2 [temp.deduct])...
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.
Notes from the October 2003 meeting:
We reviewed John Spicer's paper N1528 and agreed with his recommendations therein.
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.
Consider this example:
class Foo {
public:
template< typename T > T *get();
};
template< typename U >
U *testFoo( Foo &foo ) {
return foo.get< U >(); //#1
}
I am under the impression that this should compile without requiring the insertion of the template keyword before get in the expression at //#1. This notion is supported by this note excerpted from 14.2 [temp.names]/5:
[Note: just as is the case with the typename prefix, the template prefix is allowed in cases where it is not strictly necessary; i.e., when the expression on the left of the -> or ., or the nested-name-specifier is not dependent on a template parameter.]
But 14.2 [temp.names]/4 contains this text:
When the name of a member template specialization appears after . or -> in a postfix-expression, or after nested-name-specifier in a qualified-id, and the postfix-expression or qualified-id explicitly depends on a template-parameter (14.6.2), the member template name must be prefixed by the keyword template. Otherwise the name is assumed to name a non-template.
The only way that I can read this to support my assumption above is if I assume that the phrase postfix-expression is used twice above with different meaning. That is I read the first use as referring to the full expression while the second use refers to the subexpression preceding the operator. Is this the correct determination of intent? I find this text confusing. Would it be an improvement if the second occurrence of "postfix-expression" should be replaced by "the subexpression preceding the operator". Of course that begs the question "where is subexpression actually defined in the standard?"
John Spicer: I agree that the code should work, and that we should tweak the wording.
Is this allowed?
template<typename T>
struct X
{
static int s[];
int c;
};
template<typename T>
int X<T>::s[sizeof(X<T>)];
int* p = X<char>::s;
I have a compiler claiming that, for the purpose of sizeof(), X<T> is an incomplete type, when it tries to instantiate X<T>::s. It seems to me that X<char> should be considered complete enough for sizeof even though the size of s isn't known yet.
John Spicer: This is a problematic construct that is currently allowed but which I think should be disallowed.
I tried this with a number of compilers. None of which did the right thing. The EDG front end accepts it, but gives X<...>::s the wrong size.
It appears that most compilers evaluate the "declaration" part of the static data member definition only once when the definition is processed. The initializer (if any) is evaluated for each instantiation.
This problem is solvable, and if it were the only issue with incomplete arrays as template static data members, then it would make sense to solve it, but there are other problems.
The first problem is that the size of the static data member is only known if a template definition of the static data member is present. This is weird to start with, but it also means that sizes would not be available in general for exported templates.
The second problem concerns the rules for specialization. An explicit specialization for a template instance can be provided up until the point that a use is made that would cause an implicit instantiation. A reference like "sizeof(X<char>::s)" is not currently a reference that would cause an implicit instantiation of X<char>::s. This means you could use such a sizeof and later specialize the static data member with a different size, meaning the earlier sizeof gave the wrong result. We could, of course, change the "use" rules, but I'd rather see us require that static data members that are arrays have a size specified in the class or have a size based on their initializer.
Notes from the October 2003 meeting:
The example provided is valid according to the current standard. A static data member must be instantiated (including the processing of its initializer, if any) if there is any reference to it. The compiler need not, however, put out a definition in that translation unit. The standard doesn't really have a concept of a "partial instantiation" for a static data member, and although we considered adding that, we decided that to get all the size information that seems to be available one needs a full instantiation in any case, so there's no need for the concept of a partial instantiation.
Note (June, 2006):
Mark Mitchell suggested the following example:
template <int> void g();
template <typename T>
struct S {
static int i[];
void f();
};
template <typename T>
int S<T>::i[] = { 1 };
template <typename T>
void S<T>::f() {
g<sizeof (i) / sizeof (int)>();
}
template <typename T>
int S<int>::i[] = { 1, 2 };
Which g is called from S<int>::f()?
If the program is valid, then surely one would expect g<2> to be called.
If the program is valid, does S<T>::i have a non-dependent type in S<T>::f? If so, is it incomplete, or is it int[1]? (Here, int[1] would be surprising, since S<int>::i actually has type int[2].)
If the program is invalid, why?
For a simpler example, consider:
template <typename T>
struct S {
static int i[];
const int N = sizeof (i);
};
This is only valid if the type of i is dependent, meaning that the sizeof expression isn't evaluated until the class is instantiated.
14.5.4 [temp.friend] paragraph 1 bullet 3 says:
if the name of the friend is a qualified-id and a matching specialization of a function template is found in the specified class or namespace, the friend declaration refers to that function template specialization, otherwise,
I'm not sure this says what it's supposed to say. For example:
namespace N {
template<class T> int f(T);
}
class A {
friend int N::f(int);
int m;
A();
};
namespace N {
template< class T > int f(T) {
A a; // ok for T=int?
return a.m; // ok for T=int?
}
}
int m = N::f(42); // ok?
char c = N::f('a'); // Clearly ill-formed.
The key is that the wording talks about a “matching specialization,” which to me means that N::f<int> is befriended only if that specialization existed in N before the friend declaration. So it's ill-formed as written, but if we move the call to N::f<int> up to a point before the definition of A, it's well-formed.
That seems surprising, especially given that the first bullet does not require a pre-existing specialization. So I suggest replacing bullet 3 with something like:
if the name of the friend is a qualified-id and a matching function template is found in the specified class or namespace, the friend declaration refers to the deduced specialization of that function template, otherwise,
In the following example, the template parameter in the partial specialization is non-deducible:
template <class T> struct A { typedef T U; };
template <class T> struct C { };
template <class T> struct C<typename A<T>::U> { };
Several compilers issue errors for this case, but there appears to be nothing in the Standard that would make this ill-formed; it simply seems that the partial specialization will never be matched, so the primary template will be used for all specializations. Should it be ill-formed?
Notes from the April, 2006 meeting:
It was noted that there are similar issues for constructors and conversion operators with non-deducible parameters, and that they should probably be dealt with similarly.
The Standard does not specify how member and nonmember function templates are to be ordered. This question arises with an example like the following:
struct A {
template<class T> void operator<<(T&);
};
template<class T> struct B { };
template<class T> void operator<<(A&, B<T>&);
int main() {
A a;
B<A> b;
a << b;
}
The two candidates for “a << b” are:
How should we treat the implicit this parameter of #1 and the explicit first parameter of #2?
Option 0: Make them unordered.
Option 1: If either function is a non-static member function, ignore any this parameter and ignore the first parameter of any non-member function. This option will select #2, as “B<T>&” is more specialized than “T&”.
Option 2: Treat the this parameter as if it were of reference to object type, and then perform comparison to the first parameter of the other function. The other function's first parameter will either be another this parameter, or it will be a by-value or by-reference object parameter. In the example above, this option will also select #2.
The difference between option 1 and option 2 can be seen in the following example:
struct A { };
template<class T> struct B {
template<typename R> int operator*(R&); // #1
};
template <typename T> int operator*(T&, A&); // #2
int main() {
A a;
B<A> b;
b * a;
}
Should this select #1, select #2, or be ambiguous? Option 1 will select #2, because “A&” is more specialized than “T&”. Option 2 will make this example ambiguous, because “B<A>&” is more specialized than “T&”.
If one were considering two non-member templates,
template <typename T> int operator*(T&, A&); // #2
template <typename T, typename R> int operator*(B<A>&, R&); // #3
the current rules would make these unordered. Option 2 thus seems more consistent with this existing behavior.
Notes from the April, 2006 meeting:
The group favored option 2.
Consider the following example:
template <class T> struct Outer {
struct Inner {
Inner* self();
};
};
template <class T> Outer<T>::Inner*
Outer<T>::Inner::self() { return this; }
According to 14.6 [temp.res] paragraph 3 (before the salient wording was inadvertently removed, see issue 559),
A qualified-id that refers to a type and in which the nested-name-specifier depends on a template-parameter (14.6.2 [temp.dep]) but does not refer to a member of the current instantiation (14.6.2.1 [temp.dep.type]) shall be prefixed by the keyword typename to indicate that the qualified-id denotes a type, forming a typename-specifier.
Because Outer<T>::Inner is a member of the current instantiation, the Standard does not currently require that it be prefixed with typename when it is used in the return type of the definition of the self() member function. However, it is difficult to parse this definition correctly without knowing that the return type is, in fact, a type, which is what the typename keyword is for. Should the Standard be changed to require typename in such contexts?
Is this program valid?
template <typename T> int g(int);
class h{};
template <typename T> int l(){h j; return g<T>(j);}
template <typename T> int g(const h&);
class j{};
int jj(){return l<j>();}
The key issue is when "g" is looked up, i.e., whether both overloaded template "g" functions are available at the call site or only the first. Clearly, the entire postfix-expression "g<T>(j)" is dependent, but when is the set of available template functions determined?
For consistency with the rules about when the set of available overloads is determined when calling a function given by an unqualified-id, I would think that we should postpone determining the set of template functions if (and only if) any of the explicit template arguments are dependent.
John Spicer: I agree that there should be a core issue for this. The definition of "dependent name" (14.6.2 [temp.dep] paragraph 1) should probably be modified to cover this case. It currently only handles cases where the function name is a simple identifier.
Notes from the March 2004 meeting:
A related issue is a call with a qualified name and dependent arguments, e.g., x::y(depa, depb).
The list of cases in 14.6.1 [temp.local] about when a template parameter is hidden seems to be incomplete.
Consider
// example-1
struct S {
int C;
template<class> void f();
};
template<class C>
void S::f()
{
C c; // #1
}
Someone asked whether line #1 is well-formed and I responded "no" based on my understanding of the rules in 14.6.1. After a second looking, I've realized that the above case is currently missing from the list.
The list in 14.6.1 covers cases like
// example-2
template<class T>
struct S {
int C;
void f();
};
template<class C>
void S<C>::f()
{
C c; // ERROR: 'C' is 'S::C' not the template parameter
}
or
// example-3
struct A { int C; }
template<class C>
struct S : A {
C c; // ERROR: 'C' is 'A::C', not the template parameter
};
But the case of a 'member template' is missing. I believe it should
follow the same rule as above. The reason is this.
In the case listed in 14.6.1 (having to do with members of classes), the "algorithm" seems to be this:
I believe that any rule, coherent with 14.6.1/5 and 14.6.1/7, for covering the cases of member templates (example-1) will be described by the above "algorithm".
Am I missing something?
[1] of course, the standard text does not formally speak of "template parameter scope", but we all know that the template parameters "live" somewhere. I'm using that terminology to designate the declarative region of the template parameters.
Mike Miller: I have a somewhat different perspective on this question. I think your example-1 is fundamentally different from your example-2 and example-3. Looking, for instance, at your example-2, I see four nested scopes:
namespace scope
template scope (where the parameter is)
class S scope
S::f() block scope
Naturally, S::C hides the template parameter C. The same is true of your example-3, with three scopes:
namespace scope
template scope
class S scope (includes 10.2 base class lookup)
Again, it's clear that the C inherited from A hides the template parameter in the containing scope.
The scopes I see in your example-1, however, are different:
namespace scope
struct S scope
template scope (where the parameter is)
S::f() block scope
Here it seems clear to me that the template parameter hides the class member.
It might help to look at the case where the function template is defined inline in the class:
struct S {
int C;
template<class C> int f() {
C c; // #1
}
};
It would be pretty strange, I think, if the #1 C were the member and not the template parameter. It would also be odd if the name lookup were different between an inline definition and an out-of-line definition.
See also issue 459.
Notes from the March 2004 meeting:
Basically, the standard is okay. We think Gaby's desired cases like #1 should be ill-formed.
There is a wording problem in 14.6.1 [temp.local] paragraph 7. It says:
In the definition of a member of a class template that appears outside of the class template definition, the name of a member of this template hides the name of a template-parameter.
It should say "hides the name of a template-parameter of the class template (but not a template-parameter of the member, if the member is itself a template)" or words to that effect.
14.6.2.2 [temp.dep.expr] paragraph 3 says,
An id-expression is type-dependent if it contains:
- an identifier that was declared with a dependent type...
This treatment seems inadequate with regard to id-expressions in function calls:
According to 14.6.2.1 [temp.dep.type] paragraph 6,
A type is dependent if it is
- ...
- a compound type constructed from any dependent type...
This would apply to the type of a member function of a class template if any of its parameters are dependent, even if the return type is not dependent. However, there is no need for a call to such a function to be a type-dependent expression because the type of the expression is known at definition time.
This wording does not handle the case of overloaded functions, some of which might have dependent types (however defined) and others not.
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.
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.
According to 14.6.4.2 [temp.dep.candidate],
For a function call that depends on a template parameter, if the function name is an unqualified-id but not a template-id, the candidate functions are found using the usual lookup rules (3.4.1 [basic.lookup.unqual], 3.4.2 [basic.lookup.argdep]) except that:
For the part of the lookup using unqualified name lookup (3.4.1 [basic.lookup.unqual]), only function declarations with external linkage from the template definition context are found.
For the part of the lookup using associated namespaces (3.4.2 [basic.lookup.argdep]), only function declarations with external linkage found in either the template definition context or the template instantiation context are found.
It is not at all clear why a call using a template-id would be treated differently from one not using a template-id. Furthermore, is it really necessary to exclude internal linkage functions from the lookup? Doesn't the ODR give implementations sufficient latitude to handle this case without another wrinkle on name lookup?
(See also issue 524.)
Notes from the April, 2006 meeting:
The consensus of the group was that template-ids should not be treated differently from unqualified-ids (although it's not clear how argument-dependent lookup works for template-ids), and that internal-linkage functions should be found by the lookup (although they may result in errors if selected by overload resolution).
Note (June, 2006):
Although the notes from the Berlin meeting indicate that argument-dependent lookup for template-ids is under-specified in the Standard, further examination indicates that that is not the case: the note in 14.8.1 [temp.arg.explicit] paragraph 8 clearly indicates that argument-dependent lookup is to be performed for template-ids, and 3.4.2 [basic.lookup.argdep] paragraph 4 describes the lookup performed:
When considering an associated namespace, the lookup is the same as the lookup performed when the associated namespace is used as a qualifier (3.4.3.2 [namespace.qual]) except that:
Any using-directives in the associated namespace are ignored.
Any namespace-scope friend functions declared in associated classes are visible within their respective namespaces even if they are not visible during an ordinary lookup (11.4 [class.friend]).
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".
Issue 470 specified the explicit instantiation of members of explicitly-instantiated class templates. In restricting the affected members to those “whose definition is visible at the point of instantiation,” however, this resolution introduced an incompatibility between explicitly instantiating a member function or static data member and explicitly instantiating the class template of which it is a member (14.7.2 [temp.explicit] paragraph 3 requires only that the class template definition, not that of the member function or static data member, be visible at the point of the explicit instantiation). It would be better to treat the member instantiations the same, regardless of whether they are directly or indirectly explicitly instantiated.
Notes from the April, 2006 meeting:
In forwarding document J16/06-0057 = WG21 N1987 to be approved by the full Committee, the CWG reaffirmed its position that explicitly instantiating a class template only explicitly instantiates those of its members that have been defined before the point of the explicit instantiation. The effect of the position advocated above would be to require all non-exported member functions to be defined in the translation unit in which the class template is explicitly instantiated (cf paragraph 4), and we did not want to require that. We did agree that the “visible” terminology should be replaced by wording along the lines of “has been defined.”
Paragraph 17 of 14.7.3 [temp.expl.spec] says,
A member or a member template may be nested within many enclosing class templates. In an explicit specialization for such a member, the member declaration shall be preceded by a template<> for each enclosing class template that is explicitly specialized.
This is curious, because paragraph 3 only allows explicit specialization of members of implicitly-instantiated class specializations, not explicit specializations. Furthermore, paragraph 4 says,
Definitions of members of an explicitly specialized class are defined in the same manner as members of normal classes, and not using the explicit specialization syntax.
Paragraph 18 provides a clue for resolving the apparent contradiction:
In an explicit specialization declaration for a member of a class template or a member template that appears in namespace scope, the member template and some of its enclosing class templates may remain unspecialized, except that the declaration shall not explicitly specialize a class member template if its enclosing class templates are not explicitly specialized as well. In such explicit specialization declaration, the keyword template followed by a template-parameter-list shall be provided instead of the template<> preceding the explicit specialization declaration of the member.
It appears from this and the following example that the phrase “explicitly specialized” in paragraphs 17 and 18, when referring to enclosing class templates, does not mean that explicit specializations have been declared for them but that their names in the qualified-id are followed by template argument lists. This terminology is confusing and should be changed.
Proposed resolution (October, 2005):
Change 14.7.3 [temp.expl.spec] paragraph 17 as indicated:
A member or a member template may be nested within many enclosing class templates. In an explicit specialization for such a member, the member declaration shall be preceded by a template<> for each enclosing class templatethat is explicitly specializedspecialization. [Example:...
Change 14.7.3 [temp.expl.spec] paragraph 18 as indicated:
In an explicit specialization declaration for a member of a class template or a member template that appears in namespace scope, the member template and some of its enclosing class templates may remain unspecialized,except that the declaration shall not explicitly specialize a class member template if its enclosing class templates are not explicitly specialized as wellthat is, the template-id naming the template may be composed of template parameter names rather than template-arguments.InFor each unspecialized template in such an explicit specialization declaration, the keyword template followed by a template-parameter-list shall be provided instead of the template<> preceding theexplicit specializationdeclaration of the member. The types of the template-parameters in the template-parameter-list shall be the same as those specified in the primary template definition. In such declarations, an unspecialized template-id shall not precede the name of a template specialization in the qualified-id naming the member. [Example:...
Notes from the April, 2006 meeting:
The revised wording describing “unspecialized” templates needs more work to ensure that the parameter names in the template-id are in the correct order; the distinction between template argyments and parameters is also probably not clear enough. It might be better to replace this paragraph completely and avoid the “unspecialized” wording altogether.
The Standard does not fully describe the syntax to be used when a member of an explicitly-specialized member class or member class template is defined in namespace scope. 14.7.3 [temp.expl.spec] paragraph 4 says that the “explicit specialization syntax” (presumably referring to “template<>”) is not used in defining a member of an explicit specialization when a class template is explicitly specialized as a class. However, nothing is said anywhere about how to define a member of a specialization when:
the entity being specialized is a class (member of a template class) rather than a class template.
the result of the specialization is a class template rather than a class (cf 14.7.3 [temp.expl.spec] paragraph 18, which describes this case as a “member template that... remain[s] unspecialized”).
(See paper J16/05-0148 = WG21 N1888 for further details, including a survey of existing implementation practice.)
Notes from the October, 2005 meeting:
The CWG felt that the best approach, balancing consistency with implementation issues and existing practice, would be to require that template<> be used when defining members of all explicit specializations, including those currently covered by 14.7.3 [temp.expl.spec] paragraph 4.
Given
template <class T> static T f(T t) { ... }
template <> int f(int t) { ... }
what is the linkage of f(int)?
Section 14 [temp] paragraph 4 says,
Entities generated from a template with internal linkage are distinct from all entities generated in other translation units.
But is the explicit specialization “generated from” the primary template? Does it inherit the local linkage? If so, where do I find a reference saying so explicitly?
James Widman: Data points: EDG 3.8 inherits, GCC 4.0 does not.
Mike Miller: There's a pretty strong presumption that the linkage of an explicit specialization cannot be different from that of its primary template, given that storage class specifiers cannot appear in an explicit specialization (7.1.1 [dcl.stc] paragraph 1).
Notes from the April, 2007 meeting:
The CWG agreed that the linkage of an explicit specialization must be that of the template. Gabriel dos Reis will investigate the reason for the different behavior of g++.
An expression used in an if statement is implicitly converted to type bool (6.4 [stmt.select]). According to the rules of template argument deduction for conversion functions given in 14.8.2.3 [temp.deduct.conv], the following example is ill-formed:
struct X {
template<class T> operator const T&() const;
};
int main()
{
if( X() ) {}
}
Following the logic in 14.8.2.3 [temp.deduct.conv], A is bool and P is const T (because cv-qualification is dropped from P before the reference is removed), and deduction fails.
It's not clear whether this is the intended outcome or not.
Notes from the April, 2005 meeting:
The CWG observed that there is nothing special about either bool or the context in the example above; instead, it will be a problem wherever a copy occurs, because cv-qualification is always dropped in a copy operation. This appears to be a case where the conversion deduction rules are not properly symmetrical with the rules for arguments. The example should be accepted.
Issue 226 removed the original prohibition on default template-arguments for function templates. However, the note in 14.8.2.5 [temp.deduct.type] paragraph 19 still reflects that prohibition. It should be revised or removed.
See also issue 37.
Given this piece of code and S having a user-defined ctor, at precisely which point must std::uncaught_exception() return true and where false?
try { S s0; throw s0; } catch (S s2) { }
My understanding of the semantics of the code is as follows:
Is my understanding correct?
15.1 [except.throw] paragraph 3 talks about “the exception object” when describing the semantics of the throw-expression:
a throw-expression initializes a temporary object, called the exception object...
However, 15.5.1 [except.terminate] paragraph 1 talks about “the expression to be thrown” when enumerating the conditions under which terminate() is called:
when the exception handling mechanism, after completing evaluation of the expression to be thrown but before the exception is caught (15.1 [except.throw]), calls a user function that exits via an uncaught exception...
And, 15.5.3 [except.uncaught] paragraph 1 refers to “the object to be thrown” in the description of uncaught_exception():
The function std::uncaught_exception() returns true after completing evaluation of the object to be thrown...
Are all these objects one and the same? I believe the answer is important in case the construction of the temporary exception object throws another exception.
Suppose they are the same. Then uncaught_exception() invoked from the copy ctor for s1 (from the example [above]) must return false and a new exception (e.g., bad_alloc) may be thrown and caught by a matching handler (i.e., without calling terminate()).
But if they are not the same, then uncaught_exception() invoked from the copy ctor for s1 must return true and throwing another exception would end up calling terminate(). This would, IMO, have pretty severe consequences on writing exception safe exception classes.
As in the first case, different compilers behave differently, with most compilers not calling terminate() when the ctor for the temporary exception object throws. Unfortunately, the two compilers that I trust the most do call terminate().
FWIW, my feeling is that it should be possible for the copy ctor invoked to initialize the temporary exception object to safely exit by throwing another exception, and that the new exception should be allowed to be caught without calling terminate.
Mike Miller: The way I see this, a throw-expression has an assignment-expression as an operand. This expression is “the expression to be thrown.” Evaluation of this expression yields an object; this object is “the object to be thrown.” This object is then copied to the exception object.
Martin Sebor: Here's a survey of the return value from uncaught_exception() in the various stages of exception handling, implemented by current compilers:
| expr | temp | unwind | handlr | 2nd ex | |
|---|---|---|---|---|---|
| HP aCC 6 | 0 | 0 | 1 | 0 | OK |
| Compaq C++ 6.5 | 0 | 0 | 1 | 1 | ABRT |
| EDG eccp 3.4 | 0 | 1 | 1 | 1 | ABRT |
| g++ 3.4.2 | 0 | 0 | 1 | 0 | OK |
| Intel C++ 7.0 | 0 | 0 | 1 | 0 | OK |
| MIPSpro 7.4.1 | 0 | 0 | 1 | 1 | ABRT |
| MSVC 7.0 | 0 | 0 | 1 | 0 | OK |
| SunPro 5.5 | 1 | 1 | 1 | 0 | OK |
| VisualAge 6.0 | 0 | 1 | 1 | 1 | OK |
In the table above:
| expr | is the evaluation of the assignment-expression in the throw-expression |
| temp | is the invocation of the copy ctor for the unnamed temporary exception object created by the runtime. |
| unwind | is stack unwinding. |
| handlr | is the invocation of the copy ctor in the exception-declaration in the catch handler. |
| 2nd ex | describes the behavior of the implementation when the invocation of the copy ctor for the unnamed temporary exception object [temp] throws another exception. |
Proposed resolution (October, 2004):
Change 15.1 [except.throw] paragraph 3 as follows:
A throw-expression initializes a temporary object, called the exception object,theby copying the thrown object (i.e., the result of evaluating its assignment-expression operand) to it. The type ofwhichthe exception object is determined by removing any top-level cv-qualifiers from the static type of the operand of throw and adjusting the type from “array of T” or “function returning T” to “pointer to T” or “pointer to function returning T,” respectively. [Note: the temporary object createdforby a throw-expressionthatwhose operand is a string literal is never of type char* or wchar_t*; that is, the special conversions for string literals from the types “array of const char” and “array of const wchar_t” to the types “pointer to char” and “pointer to wchar_t,” respectively (4.2 [conv.array]), are never applied to the operand of a throw-expression. —end note] The temporary is an lvalue and is used to initialize the variable named in the matching handler (15.3 [except.handle]). The type of the operand of a throw-expression shall not be an incomplete type, or a pointer to an incomplete type other than (possibly cv-qualified) void. [...]
Change the note in 15.3 [except.handle] paragraph 3 as follows:
[Note: a throw-expression operand thatwhichis an integral constant expression of integer type that evaluates to zero does not match a handler of pointer type; that is, the null pointer constant conversions (4.10 [conv.ptr], 4.11 [conv.mem]) do not apply. —end note]
Change 15.5.1 [except.terminate] paragraph 1 bullet 1 as follows:
when the exception handling mechanism, after completing evaluation of theexpression to be thrownoperand of throw but before the exception is caught (15.1 [except.throw]), calls a user function that exits via an uncaught exception,
Change 15.5.3 [except.uncaught] paragraph 1 as follows:
The function std::uncaught_exception() returns true after completing evaluation of theobject to be thrownoperand of throw until completing the initialization of the exception-declaration in the matching handler (18.7.4 [uncaught]).
Change 18.7.4 [uncaught] paragraph 1 by adding the indicated words:
Returns: true after completing evaluation of the operand of a throw-expression until either completing initialization of the exception-declaration in the matching handler or entering unexpected() due to the throw; or after entering terminate() for any reason other than an explicit call to terminate(). [Note: This includes stack unwinding (15.2 [except.ctor]). —end note]
Notes from the April, 2005 meeting:
The CWG discussed this resolution both within the group and with other interested parties. Among the points that were made:
Martin Sebor pointed to a posting in which he argues that writing copy constructors is more difficult if an exception during the copy to the exception object will result in a call to std::terminate().
In response to a question about why the copy to the exception object is different from the copy from the exception object to the object in the exception-declaration, it was observed that the writer of the handler can avoid the second copy (by using a reference declaration), but the first copy is unavoidable.
John Spicer observed that not exiting via exception should be a design constraint for copy constructors in exception objects, regardless of whether std::terminate() is called or not.
Adopting the position that uncaught_exception() returns false during the copy to the exception object would reduce the differences between the case where that copy is elided and the case where it is performed.
Jason Merrill observed that making uncaught_exception() return false during the copy to the exception object would simplify the code generated by g++; as it currently stands, the compiler must generate code to catch exceptions during that copy so std::terminate() can be called.
Bjarne Stroustrup worried that allowing the copy constructor to throw an exception during the copy to the exception object could result in a serious and specific exception being silently transformed into a more trivial and generic one (although the CWG later noted that this risk already exists if something in the expression being thrown throws an exception before the expression completes).
The CWG felt that more input from a wider audience was necessary before a decision could be made on the appropriate resolution.
Notes from the April, 2006 meeting:
The CWG agreed with the position that std::uncaught_exception() should return false during the copy to the exception object and that std::terminate() should not be called if that constructor exits with an exception. The issue was returned to “drafting” status for rewording to reflect this position.
Additional notes (September, 2007):
Although this issue deals primarily with when std::uncaught_exception() begins to return true, the specification of when it begins to return false is also problematic. There are two parallel sections that define the meaning of std::uncaught_exception() and each has a different problem. 15.5.3 [except.uncaught] reads,
The function std::uncaught_exception() returns true after completing evaluation of the object to be thrown until completing the initialization of the exception-declaration in the matching handler (18.7.4 [uncaught]).
The problem here is that whether an exception is considered caught (the underlying condition tested by the function) is here presented in terms of having initialized the exception-declaration, while in other places it is specified by having an active handler for the exception, e.g., 15.1 [except.throw] paragraph 6:
An exception is considered caught when a handler for that exception becomes active (15.3 [except.handle]).
This distinction is important because of 15.3 [except.handle] paragraph 3:
A handler is considered active when initialization is complete for the formal parameter (if any) of the catch clause. [Note: the stack will have been unwound at that point. —end note] Also, an implicit handler is considered active when std::terminate() or std::unexpected() is entered due to a throw.
Note that there is no exception-declaration to be initialized for the std::terminate() and std::unexpected() cases; nevertheless, according to 18.7.4 [uncaught], std::uncaught_exception() is supposed to return false when one of those two functions is entered.
The specification in 18.7.4 [uncaught] is not well phrased, however, and is open to misinterpretation. It reads,
Returns: true after completing evaluation of a throw-expression until either completing initialization of the exception-declaration in the matching handler or entering unexpected() due to the throw; or after entering terminate() for any reason other than an explicit call to terminate().
The problem here is lack of parallelism: does “after entering terminate” refer to the condition for returning true or false? This would be better phrased along the lines of
Returns: true after completing evaluation of a throw-expression until a handler for the exception becomes active (15.3 [except.handle]).
16.1 [cpp.cond] paragraph 1 states,
The expression that controls conditional inclusion shall be an integral constant expression except that: it shall not contain a cast...
The prohibition of casts is vacuous and misleading: as pointed out in the footnote in that paragraph,
Because the controlling constant expression is evaluated during translation phase 4, all identifiers either are or are not macro names — there simply are no keywords, enumeration constants, and so on.
As a result, there can be no casts, which require either keywords or identifiers that resolve to types in order to be recognized as casts. The wording on casts should be removed and replaced by a note recognizing this implication.
Notes from the April, 2007 meeting:
The CWG agreed with this suggested resolution; however, the reference is in the “Preprocessing Directives” clause, which WG21 intends to keep in as close synchronization as possible with the corresponding wording in the C Standard. Any change here must therefore be done in consultation with WG14. Clark Nelson will fulfill this liaison function.
It was also noted that the imminent introduction of constexpr also has the potential for a similar kind of confusion, so the proposed resolution should address both casts and constexpr.
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:
Additional note (April, 2005):
The resolution for this problem should also address the fact that sizeof and typeid (and potentially others like decltype that may be added in the future) are described in some places as “operators” but are not listed in 13.5 [over.oper] paragraph 3 among the operators that cannot be overloaded.
(See also issue 369.)
WG14 accepted DR 279 regarding the rule known colloquially as the L'x'=='x' rule. This change was made to C99 in TC2. The Austin Group subsequently opened DR 321 against TC2, observing that the change made in TC2 would invalidate existing conforming C code that relied on the L'x'=='x' rule.
DR 321 is now closed and will be included in the TC3 to C99. This change defines a new standard macro, which WG14 drafted as follows:
__STDC_MB_MIGHT_NEQ_WC__: The integer constant 1, intended to indicate that there might be some character x in the basic character set, such that 'x' need not be equal to L'x'.
WG14 requests that WG21 adopt this revision and this macro in C++0x.
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.
(See also issue 189.)
3.1 [basic.def] makes statements about declarations that do not appear to apply to static_assert-declarations. For example, paragraph 1 says,
A declaration (clause 7 [dcl.dcl]) introduces names into a translation unit or redeclares names introduced by previous declarations. A declaration specifies the interpretation and attributes of these names.
What name is being declared or described by a static_assert-declaration?
Also, paragraph 2 lists the kinds of declarations that are not definitions, and a static_assert-declaration is not among them. Is it intentional that static_assert-declarations are definitions?
The aliasing rules given in 3.10 [basic.lval] paragraph 10 rely on the concept of “dynamic type.” The problem is that the dynamic type of an object often cannot be determined (or even sufficiently constrained) at the point at which an optimizer needs to be able to determine whether aliasing might occur or not. For example, consider the function
void foo(int* p, double* q) {
*p = 42;
*q = 3.14;
}
An optimizer, on the basis of the existing aliasing rules, might decide that an int* and a double* cannot refer to the same object and reorder the assignments. This reordering, however, could result in undefined behavior if the function foo is called as follows:
void goo() {
union {
int i;
double d;
} t;
t.i = 12;
foo(&t.i, &t.d);
cout << t.d << endl;
};
Here, the reference to t.d after the call to foo will be valid only if the assignments in foo are executed in the order in which they were written; otherwise, the union will contain an int object rather than a double.
One possibility would be to require that if such aliasing occurs, it be done only via member names and not via pointers.
Notes from the July, 2007 meeting:
This is the same issue as C's DR236. The CWG expressed a desire to address the issue the same way C99 does. The issue also occurs in C++ when placement new is used to end the lifetime of one object and start the lifetime of a different object occupying the same storage.
I thought this case would result in undefined behavior according to 3.2 [basic.def.odr]:
// t.h:
struct A { void (*p)(); };
// t1.cpp:
#include "t.h" // A::p is a pointer to C++ func
// t2.cpp:
extern "C" {
#include "t.h" // A::p is a pointer to C func
}
...but I don't see how any of the bullets in the list in paragraph 5 apply.
When 3.4.1 [basic.lookup.unqual] paragraph 10 says,
In a friend declaration naming a member function, a name used in the function declarator and not part of a template-argument in a template-id is first looked up in the scope of the member function's class. If it is not found, or if the name is part of a template-argument in a template-id, the look up is as described for unqualified names in the definition of the class granting friendship.
what does “in the scope of the member function's class” mean? Does it mean that only members of the class and its base classes are considered? Or does it mean that the same lookup is to be performed as if the name appeared in the member function's class? Implementations vary in this regard. For example:
struct s1;
namespace ns {
struct s1;
}
struct s2 {
void f(s1 &);
};
namespace ns {
struct s3 {
friend void s2::f(s1 &);
};
}
Microsoft Visual C++ and Comeau C++ resolve s1 in the friend declaration to ns::s1 and issue an error, while g++ resolves it to ::s1 and accepts the code.
Notes from the April, 2005 meeting:
The phrase “looked up in the scope of [a] class” occurs frequently throughout the Standard and always refers to the member name lookup described in 10.2 [class.member.lookup]. This is the first interpretation mentioned above (“only members of the class and its base classes”), resolving s1 to ns::s1. A cross-reference to 10.2 [class.member.lookup] will be added to 3.4.1 [basic.lookup.unqual] paragraph 10 to make this clearer.
In discussing this question, the CWG noticed another problem: the text quoted above applies to all template-arguments appearing in the function declarator. The intention of this rule, however, is that only template-arguments in the declarator-id should ignore the member function's class scope; template-arguments used elsewhere in the function declarator should be treated like other names. For example:
template<typename T> struct S;
struct A {
typedef int T;
void foo(S<T>);
};
template <typename T> struct B {
friend void A::foo(S<T>); // i.e., S<A::T>
};
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.
3.4.5 [basic.lookup.classref] does not mention template aliases as the possible result of the lookup but should do so.
An example in 3.5 [basic.link] paragraph 6 creates two file-scope variables with the same name, one with internal linkage and one with external.
static void f();
static int i = 0; //1
void g() {
extern void f(); // internal linkage
int i; //2: i has no linkage
{
extern void f(); // internal linkage
extern int i; //3: external linkage
}
}
Is this really what we want? C99 has 6.2.2.7/7, which gives undefined behavior for having an identifier appear with internal and external linkage in the same translation unit. C++ doesn't seem to have an equivalent.
Notes from October 2003 meeting:
We agree that this is an error. We propose to leave the example but change the comment to indicate that line //3 has undefined behavior, and elsewhere add a normative rule giving such a case undefined behavior.
Proposed resolution (October, 2005):
Change 3.5 [basic.link] paragraph 6 as indicated:
...Otherwise, if no matching entity is found, the block scope entity receives external linkage. If, within a translation unit, the same entity is declared with both internal and external linkage, the behavior is undefined.
[Example:
static void f(); static int i = 0; // 1 void g () { extern void f (); // internal linkage int i; // 2: i has no linkage { extern void f (); // internal linkage extern int i; // 3: external linkage } }
There are three objects named i in this program. The object with internal linkage introduced by the declaration in global scope (line //1 ), the object with automatic storage duration and no linkage introduced by the declaration on line //2, and the object with static storage duration and external linkage introduced by the declaration on line //3.Without the declaration at line //2, the declaration at line //3 would link with the declaration at line //1. But because the declaration with internal linkage is hidden, //3 is given external linkage, resulting in a linkage conflict. —end example]
Notes frum the April 2006 meeting:
According to 3.5 [basic.link] paragraph 9, the two variables with linkage in the proposed example are not “the same entity” because they do not have the same linkage. Some other formulation will be needed to describe the relationship between those two variables.
Notes from the October 2006 meeting:
The CWG decided that it would be better to make a program with this kind of linkage mismatch ill-formed instead of having undefined behavior.
The resolution of issue 389 makes code like
static struct {
int i;
int j;
} X;
ill-formed. This breaks a lot of code for no apparent reason, since the name X is not known outside the translation unit in which it appears; there is therefore no danger of collision and no need to mangle its name.
There has also been recent discussion on the email reflectors as to whether the restrictions preventing use of types without linkage as template arguments is needed or not, with the suggestion that a mechanism like that used to give members of the unnamed namespace unique names could be used for unnamed and local types. See also issue 488, which would become moot if types without linkage could be used as template parameters.
Notes from the October, 2005 meeting:
The Evolution Working Group is discussing changes that would address this issue. CWG will defer consideration until the outcome of the EWG discussions is clear.
Notes from the April, 2006 meeting:
The CWG agreed that the restriction in 3.5 [basic.link] paragraph 8 on use of a type without linkage should apply only to variables and functions with external linkage, not to variables and functions with internal linkage (i.e., the example should be accepted). This is a separate issue from the question before the EWG and should be resolved independently.
Additional note (April, 2006):
Even the restriction of the rule to functions and objects with external linkage may not be exactly what we want. Consider an example like:
namespace {
struct { int i; } s;
}
The variable s has external linkage but can't be named outside its translation unit, so there's again no reason to prohibit use of a type without linkage in its declaration.
Notes from the June, 2008 meeting:
Paper N2657, adopted at the June, 2008 meeting, allows local and unnamed types to be used as template parameters. That resolution is narrowly focused, however, and does not address this issue.
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.
Proposed resolution (April 2003):
Change 3.8 [basic.life] paragraph 5 bullet 3 from
to
Change 3.8 [basic.life] paragraph 6 bullet 3 from
to
Change the beginning of 3.9 [basic.types] paragraph 2 from
For any object (other than a base-class subobject) of POD type T, whether or not the object holds a valid value of type T, the underlying bytes (1.7 [intro.memory]) making up the object can be copied into an array of char or unsigned char.
to
For any object (other than a base-class subobject) of POD type T, whether or not the object holds a valid value of type T, the underlying bytes (1.7 [intro.memory]) making up the object can be copied into an array of byte-character type.
Add the indicated text to 3.9.1 [basic.fundamental] paragraph 1:
Objects declared as characters (char) shall be large enough to store any member of the implementation's basic character set. If a character from this set is stored in a character object, the integral value of that character object is equal to the value of the single character literal form of that character. It is implementation-defined whether a char object can hold negative values. Characters can be explicitly declared unsigned or signed. Plain char, signed char, and unsigned char are three distinct types, called the byte-character types. A char, a signed char, and an unsigned char occupy the same amount of storage and have the same alignment requirements (3.9 [basic.types]); that is, they have the same object representation. For byte-character types, all bits of the object representation participate in the value representation. For unsigned byte-character types, all possible bit patterns of the value representation represent numbers. These requirements do not hold for other types. In any particular implementation, a plain char object can take on either the same values as a signed char or an unsigned char; which one is implementation-defined.
Change 3.10 [basic.lval] paragraph 15 last bullet from
to
Notes from October 2003 meeting:
It appears that in C99 signed char may have padding bits but no trap representation, whereas in C++ signed char has no padding bits but may have -0. A memcpy in C++ would have to copy the array preserving the actual representation and not just the value.
March 2004: The liaisons to the C committee have been asked to tell us whether this change would introduce any unnecessary incompatibilities with C.
Notes from October 2004 meeting:
The C99 Standard appears to be inconsistent in its requirements. For example, 6.2.6.1 paragraph 4 says:
The value may be copied into an object of type unsigned char [n] (e.g., by memcpy); the resulting set of bytes is called the object representation of the value.
On the other hand, 6.2 paragraph 6 says,
If a value is copied into an object having no declared type using memcpy or memmove, or is copied as an array of character type, then the effective type of the modified object for that access and for subsequent accesses that do not modify the value is the effective type of the object from which the value is copied, if it has one.
Mike Miller will investigate further.
According to 4.1 [conv.lval] paragraph 1, applying the lvalue-to-rvalue conversion to any uninitialized object results in undefined behavior. However, character types are intended to allow any data, including uninitialized objects and padding, to be copied (hence the statements in 3.9.1 [basic.fundamental] paragraph 1 that “For character types, all bits of the object representation participate in the value representation” and in 3.10 [basic.lval] paragraph 15 that char and unsigned char types can alias any object). The lvalue-to-rvalue conversion should be permitted on uninitialized objects of character type without evoking undefined behavior.
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.)
There are at least a couple of problems in the description of the various id-expressions in 5.1 [expr.prim]:
Paragraph 4 embodies an incorrect assumption about the syntax of qualified-ids:
The operator :: followed by an identifier, a qualified-id, or an operator-function-id is a primary-expression.
The problem here is that the :: is actually part of the syntax of qualified-id; consequently, “:: followed by... a qualified-id” could be something like “:: ::i,” which is ill-formed. Presumably this should say something like, “A qualified-id with no nested-name-specifier is a primary-expression.”
More importantly, some kinds of id-expressions are not described by 5.1 [expr.prim]. The structure of this section is that the result, type, and lvalue-ness are specified for each of the cases it covers:
paragraph 4 deals with qualified-ids that have no nested-name-specifier
paragraph 7 deals with bare identifiers and with qualified-ids containing a nested-name-specifier that names a class
paragraph 8 deals with qualified-ids containing a nested-name-specifier that names a namespace
This treatment leaves unspecified all the non-identifier unqualified-ids (operator-function-id, conversion-function-id, and template-id), as well as (perhaps) “:: template-id” (it's not clear whether the “:: followed by a qualified-id” case is supposed to apply to template-ids or not). Note also that the proposed resolution of issue 301 slightly exacerbates this problem by removing the form of operator-function-id that contains a tmeplate-argument-list; as a result, references like “::operator+<X>” are no longer covered in 5.1 [expr.prim].
Consider the following example:
template <typename T>
const T* f(bool b) {
static T t1 = T();
static const T t2 = T();
return &(b ? t1 : t2); // error?
}
According to 5.16 [expr.cond], this function is well-formed if T is a class type and ill-formed otherwise. If the second and third operands of a conditional expression are lvalues of the same class type except for cv-qualification, the result of the conditional expression is an lvalue; if they are lvalues of the same non-class type except for cv-qualification, the result is an rvalue.
This difference seems gratuitous and should be removed.
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.6.3 [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.
Notes from the October 2003 meeting:
See also issue 315, which deals with the call of a static member function through a null pointer.
We agreed that the approach in the standard seems okay: p = 0; *p; is not inherently an error. An lvalue-to-rvalue conversion would give it undefined behavior.
Proposed resolution (October, 2004):
(Note: the resolution of issue 453 also resolves part of this issue.)
Add the indicated words to 3.10 [basic.lval] paragraph 2:
An lvalue refers to an object or function or is an empty lvalue (5.3.1 [expr.unary.op]).
Add the indicated words to 5.3.1 [expr.unary.op] paragraph 1:
The unary * operator performs indirection: the expression to which it is applied shall be a pointer to an object type, or a pointer to a function type and the result is an lvalue referring to the object or function to which the expression points, if any. If the pointer is a null pointer value (4.10 [conv.ptr]) or points one past the last element of an array object (5.7 [expr.add]), the result is an empty lvalue and does not refer to any object or function. An empty lvalue is not modifiable. If the type of the expression is “pointer to T,” the type of the result is “T.” [Note: a pointer to an incomplete type (other than cv void) can be dereferenced. The lvalue thus obtained can be used in limited ways (to initialize a reference, for example); this lvalue must not be converted to an rvalue, see 4.1 [conv.lval].—end note]
Add the indicated words to 4.1 [conv.lval] paragraph 1:
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, or if the lvalue is an empty lvalue (5.3.1 [expr.unary.op]), a program that necessitates this conversion has undefined behavior.
Change 1.9 [intro.execution] as indicated:
Certain other operations are described in this International Standard as undefined (for example, the effect ofdereferencing the null pointerdivision by zero).
Note (March, 2005):
The 10/2004 resolution interacts with the resolution of issue 73. We added wording to 3.9.2 [basic.compound] paragraph 3 to the effect that a pointer containing the address one past the end of an array is considered to “point to” another object of the same type that might be located there. The 10/2004 resolution now says that it would be undefined behavior to use such a pointer to fetch the value of that object. There is at least the appearance of conflict here; it may be all right, but it at needs to be discussed further.
Notes from the April, 2005 meeting:
The CWG agreed that there is no contradiction between this direction and the resolution of issue 73. However, “not modifiable” is a compile-time concept, while in fact this deals with runtime values and thus should produce undefined behavior instead. Also, there are other contexts in which lvalues can occur, such as the left operand of . or .*, which should also be restricted. Additional drafting is required.
Here's an example:
typedef struct S { ... } S;
void fs(S *x) { ... }
The big question is, to what declaration does the reference to identifier S actually refer? Is it the S that's declared as a typedef name, or the S that's declared as a class name (or in C terms, as a struct tag)? (In either case, there's clearly only one type to which it could refer, since a typedef declaration does not introduce a new type. But the debugger apparently cares about more than just the identity of the type.)
Here's a classical, closely related example:
struct stat { ... };
int stat();
... stat( ... ) ...
Does the identifier stat refer to the class or the function? Obviously, in C, you can't refer to the struct tag without using the struct keyword, because it is in a different name space, so the reference must be to the function. In C++, the reference is also to the function, but for a completely different reason.
Now in C, typedef names and function names are in the same name space, so the natural extrapolation would be that, in the first example, S refers to the typedef declaration, as it would in C. But C++ is not C. For the purposes of this discussion, there are two important differences between C and C++
The first difference is that, in C++, typedef names and class names are not in separate name spaces. On the other hand, according to section 3.3.8 [basic.scope.hiding] (Name hiding), paragraph 2:
A class name (9.1) or enumeration name (7.2) can be hidden by the name of an object, function, or enumerator declared in the same scope. If a class or enumeration name and an object, function, or enumerator are declared in the same scope (in any order) with the same name, the class or enumeration name is hidden wherever the object, function, or enumerator name is visible.
Please consider carefully the phrase I have highlighted, and the fact that a typedef name is not the name of an object, function or enumerator. As a result, this example:
struct stat { ... };
typedef int stat;
Which would be perfectly legal in C, is disallowed in C++, both implicitly (see the above quote) and explicitly (see section 7.1.3 [dcl.typedef] (The typedef specifier), paragraph 3):
In a given scope, a typedef specifier shall not be used to redefine the name of any type declared in that scope to refer to a different type. Similarly, in a given scope, a class or enumeration shall not be declared with the same name as a typedef-name that is declared in that scope and refers to a type other than the class or enumeration itself.
From which we can conclude that in C++ typedef names do not hide class names declared in the same scope. If they did, the above example would be legal.
The second difference is that, in C++, a typedef name that refers to a class is a class-name; see 7.1.3 [dcl.typedef] paragraph 4:
A typedef-name that names a class is a class-name(9.1). If a typedef-name is used following the class-key in an elaborated-type-specifier (7.1.5.3) or in the class-head of a class declaration (9), or is used as the identifier in the declarator for a constructor or destructor declaration (12.1, 12.4), the program is ill-formed.
This implies, for instance, that a typedef-name referring to a class can be used in a nested-name-specifier (i.e. before :: in a qualified name) or following ~ to refer to a destructor. Note that using a typedef-name as a class-name in an elaborated-type-specifier is not allowed. For example:
struct X { };
typedef struct X X2;
X x; // legal
X2 x2; // legal
struct X sx; // legal
struct X2 sx2; // illegal
The final relevant piece of the standard is 7.1.3 [dcl.typedef] paragraph 2:
In a given scope, a typedef specifier can be used to redefine the name of any type declared in that scope to refer to the type to which it already refers.
This of course is what allows the original example, to which let us now return:
typedef struct S { ... } S;
void fs(S *x) { ... }
The question, again is, to which declaration of S does the reference actually refer? In C, it would clearly be to the second, since the first would be accessible only by using the struct keyword. In C++, if typedef names hid class names declared in the same scope, the answer would be the same. But we've already seen that typedef names do not hide class names declared in the same scope.
So to which declaration does the reference to S refer? The answer is that it doesn't matter. The second declaration of S, which appears to be a declaration of a typedef name, is actually a declaration of a class name (7.1.3 [dcl.typedef] paragraph 4), and as such is simply a redeclaration. Consider the following example:
typedef int I, I; extern int x, x; void f(), f();
To which declaration would a reference to I, x or f refer? It doesn't matter, because the second declaration of each is really just a redeclaration of the thing declared in the first declaration. So to save time, effort and complexity, the second declaration of each doesn't add any entry to the compiler's symbol table.
Note (March, 2005):
Matt Austern: Is this legal?
struct A { };
typedef struct A A;
struct A* p;
Am I right in reading the standard [to say that this is ill-formed]? On the one hand it's a nice uniform rule. On the other hand, it seems likely to confuse users. Most people are probably used to thinking that 'typedef struct A A' is a null operation, and, if this code really is illegal, it would seem to be a gratuitous C/C++ incompatibility.
Mike Miller: I think you're right. 7.1.3 [dcl.typedef] paragraph 1:
A name declared with the typedef specifier becomes a typedef-name.
7.1.3 [dcl.typedef] paragraph 2:
In a given non-class scope, a typedef specifier can be used to redefine the name of any type declared in that scope to refer to the type to which it already refers.
After the typedef declaration in the example, the name X has been “redefined” — it is no longer just a class-name, it has been “redefined” to be a typedef-name (that, by virtue of the fact that it refers to a class type, is also a class-name).
John Spicer: In C, and originally in C++, an elaborated-type-specifier did not consider typedef names, so “struct X* x” would find the class and not the typedef.
When C++ was changed to make typedefs visible to elaborated-type-specifier lookups, I believe this issue was overlooked and inadvertantly made ill-formed.
I suspect we need add text saying that if a given scope contains both a class/enum and a typedef, that an elaborated type specifier lookup finds the class/enum.
Mike Miller: I'm a little uncomfortable with this approach. The model we have for declaring a typedef in the same scope as a class/enum is redefinition, not hiding (like the “struct stat” hack). This approach seems to assume that the typedef hides the class/enum, which can then be found by an elaborated-type-specifier, just as if it were hidden by a variable, function, or enumerator.
Also, this approach reduces but doesn't eliminate the incompatibility with C. For example:
struct S { };
{
typedef struct S S;
struct S* p; // still ill-formed
}
My preference would be for something following the basic principle that declaring a typedef-name T in a scope where T already names the type designated by the typedef should have no effect on whether an elaborated-type-specifier in that or a nested scope is well-formed or not. Another way of saying that is that a typedef-name that designates a same-named class or enumeration in the same or a containing scope is transparent with respect to elaborated-type-specifiers.
John Spicer: This strikes me as being a rather complicated solution. When we made the change to make typedefs visible to elaborated-type-specifiers we did so knowing it would make some C cases ill-formed, so this does not bother me. We've lived with the C incompatibility for many years now, so I don't personally feel a need to undo it. I also don't like the fact that you have to essentially do the old-style elaborated-type-specifier lookup to check the result of the lookup that found the typedef.
I continue to prefer the direction I described earlier where if a given scope contains both a cl