| Document number: | J16/05-0189 = WG21 N1929 |
| Date: | 2005-12-16 |
| 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:
The purpose of these documents is to record the disposition of issues which have come before the Core Language Working Group of the ANSI (J16) and ISO (WG21) C++ Standard Committee.
Issues represent potential defects in the ISO/IEC IS 14882:2003 document and corrected defects in the earlier ISO/IEC 14882:1998 document; they are not necessarily formal ISO Defect Reports (DRs). While some issues will eventually be elevated to DR status, others will be disposed of in other ways. (See Issue Status below.)
The most current public version of this document can be found at http://www.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.jamesd.demon.co.uk/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.
The standard uses “most derived object” in some places (for example, 1.3.3 defns.dynamic.type, 5.3.5 expr.delete) to refer to objects of both class and non-class type. However, 1.8 intro.object only formally defines it for objects of class type.
Possible fix: Change the wording in 1.8 intro.object paragraph 4 from
an object of a most derived class type is called a most derived object
to
an object of a most derived class type, or of non-class type, is called a most derived object
Proposed resolution (October, 2005):
Add the indicated words to 1.8 intro.object paragraph 4:
If a complete object, a data member (9.2 class.mem), or an array element is of class type, its type is considered the most derived class, to distinguish it from the class type of any base class subobject; an object of a most derived class type, or of a non-class type, is called a most derived object.
The C standard says in 6.3.2.3, paragraph 4:
Conversion of a null pointer to another pointer type yields a null pointer of that type. Any two null pointers shall compare equal.
C++ appears to be incompatible with the first sentence in only two areas:
A *a = 0;
void *v = a;
C++ (4.10 conv.ptr paragraph 2) says nothing about the value of v.
void *v = 0;
A *b = (A*)v; // aka static_cast<A*>(v)
C++ (5.2.9 expr.static.cast paragraph 10) says nothing about the value of b.
Suggested changes:
Add the following sentence to 4.10 conv.ptr paragraph 2:
The null pointer value is converted to the null pointer value of the destination type.
Add the following sentence to 5.2.9 expr.static.cast paragraph 10:
The null pointer value (4.10 conv.ptr) is converted to the null pointer value of the destination type.
Proposed resolution (October, 2005):
Add the indicated words to 4.10 conv.ptr paragraph 2:
An rvalue of type “pointer to cv T,” where T is an object type, can be converted to an rvalue of type “pointer to cv void”. The result of converting a “pointer to cv T” to a “pointer to cv void” points to the start of the storage location where the object of type T resides, as if the object is a most derived object (1.8 intro.object) of type T (that is, not a base class subobject). The null pointer value is converted to the null pointer value of the destination type.
Add the indicated words to 5.2.9 expr.static.cast paragraph 11:
An rvalue of type “pointer to cv1 void” can be converted to an rvalue of type “pointer to cv2 T,” where T is an object type and cv2 is the same cv-qualification as, or greater cv-qualification than, cv1. The null pointer value is converted to the null pointer value of the destination type. A value of type pointer to object converted to “pointer to cv void” and back, possibly with different cv-qualification, shall have its original value...
5.2.4 expr.pseudo paragraph 2 says both:
The type designated by the pseudo-destructor-name shall be the same as the object type.and also:
The cv-unqualified versions of the object type and of the type designated by the pseudo-destructor-name shall be the same type.Which is it? "The same" or "the same up to cv-qualifiers"? The second sentence is more generous than the first. Most compilers seem to implement the less restrictive form, so I guess that's what I think we should do.
Proposed resolution (October, 2005):
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 type is the object type.The type designated by the pseudo-destructor-name shall be the same as the object type.The cv-unqualified versions of the object type and of the type designated by the pseudo-destructor-name shall be the same type. Furthermore, the two type-names in a pseudo-destructor-name of the form::opt nested-name-specifieropt type-name ::~ type-name
shall designate the same scalar type.The cv-unqualified versions of the object type and of the type designated by the pseudo-destructor-name shall be the same type.
There is an inconsistency between the normative text in section 5.2.8 expr.typeid and the example that follows.
Here is the relevant passage (starting with paragraph 4):
When typeid is applied to a type-id, the result refers to a std::type_info object representing the type of the type-id. If the type of the type-id is a reference type, the result of the typeid expression refers to a std::type_info object representing the referenced type.
The top-level cv-qualifiers of the lvalue expression or the type-id that is the operand of typeid are always ignored.
and the example:
typeid(D) == typeid(const D&); // yields true
The second paragraph above says the “type-id that is the operand”. This would be const D&. In this case, the const is not at the top-level (i.e., applied to the operand itself).
By a strict reading, the above should yield false.
My proposal is that the strict reading of the normative test is correct. The example is wrong. Different compilers here give different answers.
Proposed resolution (April, 2005):
Change the second sentence of 5.2.8 expr.typeid paragraph 4 as follows:
If the type of the type-id is a reference to a possibly cv-qualified type, the result of the typeid expression refers to a std::type_info object representing the cv-unqualified referenced type.
Is reinterpret_cast<T*>(null_pointer_constant) guaranteed to yield the null pointer value of type T*?
I think a committee clarification is needed. Here's why: 5.2.10 expr.reinterpret.cast par. 8 talks of "null pointer value", not "null pointer constant", so it would seem that
reinterpret_cast<T*>(0)is a normal int->T* conversion, with an implementation-defined result.
However a little note to 5.2.10 expr.reinterpret.cast par. 5 says:
Converting an integral constant expression (5.19) with value zero always yields a null pointer (4.10), but converting other expressions that happen to have value zero need not yield a null pointer.Where is this supported in normative text? It seems that either the footnote or paragraph 8 doesn't reflect the intent.
SUGGESTED RESOLUTION: I think it would be better to drop the footnote #64 (and thus the special case for ICEs), for two reasons:
a) it's not normative anyway; so I doubt anyone is relying on the guarantee it hints at, unless that guarantee is given elsewhere in a normative part
b) users expect reinterpret_casts to be almost always implementation dependent, so this special case is a surprise. After all, if one wants a null pointer there's static_cast. And if one wants reinterpret_cast semantics the special case requires doing some explicit cheat, such as using a non-const variable as intermediary:
int v = 0; reinterpret_cast<T*>(v); // implementation defined reinterpret_cast<T*>(0); // null pointer value of type T* const int w = 0; reinterpret_cast<T*>(w); // null pointer value of type T*
It seems that not only that's providing a duplicate functionality, but also at the cost to hide what seems the more natural one.
Notes from October 2004 meeting:
This footnote was added in 1996, after the invention of reinterpret_cast, so the presumption must be that it was intentional. At this time, however, the CWG feels that there is no reason to require that reinterpret_cast<T*>(0) produce a null pointer value as its result.
Proposed resolution (April, 2005):
Delete the footnote in 5.2.10 expr.reinterpret.cast paragraph 5 reading,
Converting an integral constant expression (5.19 expr.const) with value zero always yields a null pointer (4.10 conv.ptr), but converting other expressions that happen to have value zero need not yield a null pointer.
Add the indicated note to 5.2.10 expr.reinterpret.cast paragraph 8:
The null pointer value (4.10 conv.ptr) is converted to the null pointer value of the destination type. [Note: A null pointer constant, which has integral type, is not necessarily converted to a null pointer value. —end note]
Consider:
template <int* p> struct S {
static const int I = 3;
};
int i;
int a[S<&i>::I];
Clearly this should be valid, but a pedantic reading of 5.19 expr.const would suggest that this is invalid because “&i” is not permitted in integral constant expressions.
Proposed resolution (October, 2005):
Change the last sentence of 5.19 expr.const paragraph 1 as indicated:
In particular, except in non-type template-arguments or sizeof expressions, functions, class objects, pointers, or references shall not be used, and assignment, increment, decrement, function-call, or comma operators shall not be used.
The C language (since C99), and some C++ compilers, accept:
enum { FOO, };
as syntactically valid. It would be useful
for machine generated code
for minimising changes when editing
to allow a distinction between the final item being intended as an ordinary item or as a limit:
enum { red, green, blue, num_colours }; // note no comma
enum { fred, jim, sheila, }; // last is not special
This proposed change is to permit a trailing comma in enum by adding:
enum identifieropt { enumerator-list , }
as an alternative definition for the enum-specifier nonterminal
in
Proposed resolution (October, 2005):
Change the grammar in 7.2 dcl.enum paragraph 1 as indicated:
enum-specifier:enum identifieropt { enumerator-listopt }
enum identifieropt { enumerator-list , }
[Voted into WP at October 2005 meeting.]
In 12.2 class.temporary paragraph 5, should binding a reference to the result of a "?" operation, each of whose branches is a temporary, extend both temporaries?
Here's an example:
const SFileName &C = noDir ? SFileName("abc") : SFileName("bcd");
Do the temporaries created by the SFileName conversions survive the end of the full expression?
Notes from 10/00 meeting:
Other problematic examples include cases where the temporary from one branch is a base class of the temporary from the other (i.e., where the implementation must remember which type of temporary must be destroyed), or where one branch is a temporary and the other is not. Similar questions also apply to the comma operator. The sense of the core language working group was that implementations should be required to support these kinds of code.
Notes from the March 2004 meeting:
We decided that the cleanest model is one in which any "?" operation that returns a class rvalue always copies one of its operands to a temporary and returns the temporary as the result of the operation. (Note that this may involve slicing.) An implementation would be free to optimize this using the rules in 12.8 class.copy paragraph 15, and in fact we would expect that in many cases compilers would do such optimizations. For example, the compiler could construct both rvalues in the above example into a single temporary, and thus avoid a copy.
See also issue 446.
Proposed resolution (October, 2004):
This issue is resolved by the resolutions of issue 446.
Note (October, 2005):
This issue was overlooked when issue 446 was moved to “ready” status and was thus inadvertently omitted from the list of issues accepted as Defect Reports at the October, 2005 meeting.
Section 12.2 class.temporary paragraph 5 ends with this "rule":
For the temporary to be destroyed after obj2 is destroyed, when obj2 has static storage, I would say that the reference to the temporary should also have static storage, but that is IMHO not clear from the paragraph.
Example:
void f ()
{
const T1& ref = T1();
static T2 obj2;
...
}
Here the temporary would be destoyed before obj2, contrary to the rule above.
Steve Adamczyk: I agree there's a minor issue here. I think the clause quoted above meant for obj1 and obj2 to have the same storage duration. Replacing "obj2 is an object with static or automatic storage duration" by "obj2 is an object with the same storage duration as obj1" would, I believe, fix the problem.
Notes from October 2004 meeting:
We agreed with Steve Adamczyk's suggestion.
Proposed resolution (October, 2005):
Change 12.2 class.temporary paragraph 5 as follows:
... In addition, the destruction of temporaries bound to references shall take into account the ordering of destruction of objects with static or automatic storage duration (3.7.1 basic.stc.static, 3.7.2 basic.stc.auto); that is, if obj1 is an objectwith static or automatic storage durationcreated before the temporary is created with the same storage duration as the temporary, the temporary shall be destroyed before obj1 is destroyed; if obj2 is an objectwith static or automatic storage durationcreated after the temporary is created with the same storage duration as the temporary, the temporary shall be destroyed after obj2 is destroyed...
8.5 dcl.init paragraph 10 makes it clear that non-static POD class objects with no initializer are left uninitialized and have an indeterminate initial value:
If no initializer is specified for an object, and the object is of (possibly cv-qualified) non-POD class type (or array thereof), the object shall be default-initialized; if the object is of const-qualified type, the underlying class type shall have a user-declared default constructor. Otherwise, if no initializer is specified for a non-static object, the object and its subobjects, if any, have an indeterminate initial value; if the object or any of its subobjects are of const-qualified type, the program is ill-formed.
12.6 class.init paragraph 1, however, implies that all class objects without initializers, whether POD or not, are default-initialized:
When no initializer is specified for an object of (possibly cv-qualified) class type (or array thereof), or the initializer has the form (), the object is initialized as specified in 8.5 dcl.init. The object is default-initialized if there is no initializer, or value-initialized if the initializer is ().
Proposed resolution (October, 2005):
Remove the indicated words from 12.6 class.init paragraph 1:
When no initializer is specified for an object of (possibly cv-qualified) class type (or array thereof), or the initializer has the form (), the object is initialized as specified in 8.5 dcl.init.The object is default-initialized if there is no initializer, or value-initialized if the initializer is ().
Lets start with the proposed solution. In 13.5.6 over.ref, replace line ...
postfix-expression -> id-expression.... with the lines ...
postfix-expression -> templateopt id-expression(This then is a copy of the two lines in 5.2 expr.post covering "->dtor")
postfix-expression -> pseudo-destructor-name
Alternatively remove the sentence "It implements class member access using ->" and the syntax line following.
Reasons:
Currently stdc++ is inconsistent when handling expressions of the form "postfixexpression->scalar_type_dtor()": If "postfixexpression" is a pointer to the scalar type, it is OK, but if "postfixexpression" refers to any smart pointer class (e.g. iterator or allocator::pointer) with class specific CLASS::operator->() returning pointer to the scalar type, then it is ill-formed; so while c++98 does allow CLASS::operator->() returning pointer to scalar type, c++98 prohibits any '->'-expression involving this overloaded operator function.
Not only is this behaviour inconsistent, but also when comparing the corresponding chapters of c++pl2 and stdc++98 it looks like an oversight and unintended result. Mapping between stdc++98 and c++pl2:
c++pl2.r.5.2 -> 5.2 [expr.post]For the single line of c++pl2.r.5.2 covering "->dtor", 5.2 [expr.post] has two lines. Analogously c++pl2.r.5.2.4 has been doubled to 5.2.4 [expr.pseudo] and 5.2.5 [expr.ref]. From 13.5.6 [over.ref], the sentence forbiding CLASS::operator->() returning pointer to scalar type has been removed. Only the single line of c++pl2.r.13.4.6 (<-> c++pl2.r.5.2's single line) has not gotten its 2nd line when converted into 13.5.6 [over.ref].
c++pl2.r.5.2.4 -> 5.2.4 [expr.pseudo] + 5.2.5 [expr.ref]
c++pl2.r.13.4 -> 13.3.1.2 [over.match.oper]
c++pl2.r.13.4.6 -> 13.5.6 [over.ref]
Additionally GCC32 does is right (but against 13.5.6 [over.ref]).
AFAICS this would not break old code except compilers like VC7x and Comeau4301.
It does not add new functionality, cause any expression class_type->scalar_type_dtor() even today can be substituted through (*class_type).scalar_type_dtor().
Without this fix, template functions like some_allocator<T>::destroy(p) must use "(*p).~T()" or "(*p).T::~T()" when calling the destructor, otherwise the simpler versions "p->~T()" or "p->T::~T()" could be used.
Sample code, compiled with GCC32, VC7[1] and Comeau4301:
struct A {};//any class
template <class T>
struct PTR
{
T& operator* () const;
T* operator-> () const;
};
template <class T>
void f ()
{
{
T* p ;
p = new T ;
(*p).T::~T() ;//OK
p = new T ;
(*p).~T() ;//OK
p = new T ;
p->T::~T() ;//OK
p = new T ;
p->~T() ;//OK
}
{
PTR<T> p = PTR<T>() ;
(*p).T::~T() ;//OK
(*p).~T() ;//OK
p.operator->() ;//OK !!!
p->T::~T() ;//GCC32: OK; VC7x,Com4301: OK for A; ERROR w/ int
p->~T() ;//GCC32: OK; VC7x,Com4301: OK for A; ERROR w/ int
}
}
void test ()
{
f <A> ();
f <int>();
}
Proposed resolution (April, 2005):
Change 13.5.6 over.ref paragraph 1 as indicated:
operator-> shall be a non-static member function taking no parameters. It implements the class member access
usingsyntax that uses ->postfix-expression -> templateopt id-expression
postfix-expression -> pseudo-destructor-nameAn expression x->m is interpreted as (x.operator->())->m for a class object x of type T if T::operator->() exists and if the operator is selected as the best match function by the overload resolution mechanism (13.3 over.match).
The example in 14.7.1 temp.inst paragraph 4 has a typographical error: the third parameter of function g should be D<double>* ppp, but it is missing the *:
template <class T> class B { /* ... */ };
template <class T> class D : public B<T> { /* ... */ };
void f(void*);
void f(B<int >*);
void g(D<int>* p, D<char>* pp, D<double> ppp)
{
f(p); // instantiation of D<int> required: call f(B<int>*)
B<char>* q = pp; // instantiation of D<char> required:
// convert D<char>* to B<char>*
delete ppp; // instantiation of D<double> required
}
Proposed resolution (October, 2005):
As suggested.
According to 14.8.2 temp.deduct paragraph 2,
If a substitution in a template parameter or in the function type of the function template results in an invalid type, type deduction fails.
That would seem to apply to cases like the following:
template <class T> T f(T&){}
void f(const int*){}
int main() {
int a[5];
f(a);
}
Here, the return type of f is deduced as int[5], which is invalid according to 8.3.5 dcl.fct paragraph 6. The outcome of this example, then, should presumably be that type deduction fails and overload resolution selects the non-template function. However, the list of reasons in 14.8.2 temp.deduct for which type deduction can fail does not include function and array types as a function return type. Those cases should be added to the list.
Proposed resolution (October, 2005):
Change the last sub-bullet of 14.8.2 temp.deduct paragraph 2 as indicated:
Attempting to create a function type in which a parameter has a type of void, or in which the return type is a function type or array type.
It is not clear how to handle the following example:
struct S {
template <typename T> S(const T&);
};
void f(const S&);
void f(int);
void g() {
enum E { e };
f(e); // ill-formed?
}
Three possibilities suggest themselves:
Fail during overload resolution. In order to perform overload resolution for the call to f, the declaration of the required specialization of the S constructor must be instantiated. This instantiation uses a local type and is thus ill-formed (14.3.1 temp.arg.type paragraph 2), rendering the example as a whole ill-formed, as well.
Treat this as a type-deduction failure. Although it is not listed currently among the causes of type-deduction failure in 14.8.2 temp.deduct paragraph 2, it could plausibly be argued that instantiating a function declaration with a local type as a template type-parameter falls under the rubric of “If a substitution in a template parameter or in the function type of the function template results in an invalid type” and thus should be a type-deduction failure. The result would be that the example is well-formed because f(const S&) would be removed from the list of viable functions.
Fail only if the function selected by overload resolution requires instantiation with a local type. This approach would require that the diagnostic resulting from the instantiation of the function type during overload resolution be suppressed and either regenerated or regurgitated once overload resolution is complete. (The example would be well-formed under this approach because f(int) would be selected as the best match.)
(See also issue 489.)
Notes from the April, 2005 meeting:
The question in the original example was whether there should be an error, even though the uninstantiable template was not needed for calling the best-matching function. The broader issue is whether a user would prefer to get an error or to call a “worse” non-template function in such cases. For example:
template<typename T> void f(T);
void f(int);
void g() {
enum E { e };
f(e); // call f(int) or get an error?
}
It was observed that the type deduction rules are intended to model, albeit selectively, the other rules of the language. This would argue in favor of the second approach, a type-deduction failure, and the consensus of the group was that the incremental benefit of other approaches was not enough to outweigh the additional complexity of specification and implementation.
Proposed resolution (October, 2005):
Add a new sub-bullet following bullet 3, sub-bullet 7 ("Attempting to give an invalid type to a non-type template parameter") of 14.8.2 temp.deduct paragraph 2:
Attempting to use a local or unnamed type as the value of a template type parameter.
Additional note (December, 2005):
The Evolution Working Group is currently considering an extension that would effectively give linkage to some (but perhaps not all) types that currently have no linkage. If the proposed resolution above is adopted and then later a change along the lines that the EWG is considering were also adopted, the result would be a silent change in the result of overload resolution, because the newly-acceptable specializations would become part of the overload set. It is not clear whether that possibility is sufficient reason to delay adoption of this resolution or not.
I have noticed a couple of confusing and overlapping passages dealing with copy elision. The first is 15.1 except.throw paragraph 5:
If the use of the temporary object can be eliminated without changing the meaning of the program except for the execution of constructors and destructors associated with the use of the temporary object (12.2 class.temporary), then the exception in the handler can be initialized directly with the argument of the throw expression.
The other is 15.3 except.handle paragraph 17:
If the use of a temporary object can be eliminated without changing the meaning of the program except for execution of constructors and destructors associated with the use of the temporary object, then the optional name can be bound directly to the temporary object specified in a throw-expression causing the handler to be executed.
I think these two passages are intended to describe the same optimization. However, as is often the case where something is described twice, there are significant differences. One is just different terminology — is “the exception in the handler” the same as “the object declared in the exception-declaration or, if the exception-declaration does not specify a name, a temporary object of that type” (15.3 except.handle paragraph 16)?
More significant, there is a difference in which kinds of throw-expressions are eligible for the optimization. In 15.1 except.throw paragraph 5, it appears that any object is a candidate, while in 15.3 except.handle paragraph 17 the thrown object must be a temporary (“the temporary object specified in a throw-expression”). For example, it's not clear looking at these two passages whether the copy of a local automatic can be elided. I.e., by analogy with the return value optimization described in 12.8 class.copy paragraph 15:
X x;
return x; // copy may be elided
X x;
throw x; // unclear whether copy may be elided
Which brings up another point: 12.8 class.copy paragraph 15 purports to be an exhaustive list in which copy elision is permitted even if the constructor and/or destructor have side effects; however, these two passages describe another case that is not mentioned in 12.8 class.copy paragraph 15.
A final point of confusion: in the unoptimized abstract machine, there are actually two copies in throwing and handling an exception: the copy from the object being thrown to the exception object, and the copy from the exception object to the object or temporary in the exception-declaration. 15.1 except.throw paragraph 5 speaks only of eliminating the exception object, copying the thrown object directly into the exception-declaration object, while 15.3 except.handle paragraph 17 refers to directly binding the exception-declaration object to the thrown object (if it's a temporary). Shouldn't these be separated, with a throw of an automatic object or temporary being like the return value optimization and the initialization of the object/temporary in the exception-declaration being a separate optimizable step (which could, presumably, be combined to effectively alias the exception-declaration onto the thrown object)?
(See paper J16/04-0165 = WG21 N1725.)
Proposed resolution (April, 2005):
Add two items to the bulleted list in 12.8 class.copy paragraph 15 as follows:
This elision of copy operations is permitted in the following circumstances (which may be combined to eliminate multiple copies):
in a return statement in a function with a class return type, when the expression is the name of a non-volatile automatic object with the same cv-unqualified type as the function return type, the copy operation can be omitted by constructing the automatic object directly into the function’s return value
in a throw-expression, when the operand is the name of a non-volatile automatic object, the copy operation from the operand to the exception object (15.1 except.throw) can be omitted by constructing the automatic object directly into the exception object
when a temporary class object that has not been bound to a reference (12.2 class.temporary) would be copied to a class object with the same cv-unqualified type, the copy operation can be omitted by constructing the temporary object directly into the target of the omitted copy
when the exception-declaration of an exception handler (clause 15 except) declares an object of the same type (except for cv-qualification) as the exception object (15.1 except.throw), the copy operation can be omitted by treating the exception-declaration as an alias for the exception object if the meaning of the program will be unchanged except for the execution of constructors and destructors for the object declared by the exception-declaration
Change 15.1 except.throw paragraph 5 as follows:
If the use of the temporary object can be eliminated without changing the meaning of the program except for the execution of constructors and destructors associated with the use of the temporary object (12.2 class.temporary), then the exception in the handler can be initialized directly with the argument of the throw expression.When the thrown object is a class object,andthe copy constructorused to initialize the temporary copy is notand the destructor shall be accessible,the program is ill-formed (even when the temporary object could otherwise be eliminated)even if the copy operation is elided (12.8 class.copy).Similarly, if the destructor for that object is not accessible, the program is ill-formed (even when the temporary object could otherwise be eliminated).
Change 15.3 except.handle paragraph 17 as follows:
If the use of a temporary object can be eliminated without changing the meaning of the program except for execution of constructors and destructors associated with the use of the temporary object, then the optional name can be bound directly to the temporary object specified in a throw-expression causing the handler to be executed.The copy constructor and destructor associated with the object shall be accessible evenwhen the temporary object is eliminatedif the copy operation is elided (12.8 class.copy).
The current wording of 2.13.2 lex.ccon paragraph 3 states,
If the character following a backslash is not one of those specified, the behavior is undefined.
Paper J16/04-0167=WG21 N1727 suggests that such character escapes be ill-formed. In discussions at the Lillehammer meeting, however, the CWG felt that the newly-approved category of conditionally-supported behavior would be more appropriate.
Proposed resolution (October, 2005):
Change the next-to-last sentence of 2.13.2 lex.ccon paragraph 3 from:
If the character following a backslash is not one of those specified, the behavior is undefined.
to:
Escape sequences in which the character following the backslash is not listed in Table 5 are conditionally-supported, with implementation-defined semantics.
Is the following code well-formed?
namespace N {
int i;
extern int j;
}
int N::j = i;
The question here is whether the lookup for i in the initializer of N::j finds the declaration in namespace N or not. Implementations differ on this question.
If N::j were a static data member of a class, the answer would be clear: both 3.4.1 basic.lookup.unqual paragraph 12 and 8.5 dcl.init paragraph 11 say that the initializer “is in the scope of the member's class.” There is no such provision for namespace members defined outside the namespace, however.
The reasoning given in 3.4.1 basic.lookup.unqual may be instructive:
A name used in the definition of a static data member of class X (9.4.2 class.static.data) (after the qualified-id of the static member) is looked up as if the name was used in a member function of X.
It is certainly the case that a name used in a function that is a member of a namespace is looked up in that namespace (3.4.1 basic.lookup.unqual paragraph 6), regardless of whether the definition is inside or outside that namespace. Initializers for namespace members should probably be looked up the same way.
Proposed resolution (October, 2005):
Add a new paragraph following 3.4.1 basic.lookup.unqual paragraph 12:
If a variable member of a namespace is defined outside of the scope of its namespace then any name used in the definition of the variable member (after the qualified-id) is looked up as if the definition of the variable member occurred in its namespace. [Example:
namespace N { int i = 4; extern int j; } int i = 2; int N::j = i; // N::j == 4—end example]
I believe this program is invalid:
struct A {
};
struct C {
struct A {};
void f ();
};
void C::f () {
::A *a;
a->~A ();
}
The problem is that 3.4.5
basic.lookup.classref says that you have to look
up A in both the context of the pointed-to-type (i.e.,
::A), and
in the context of the postfix-expression (i.e., the body of C::f), and
that if the name is found in both places it must name the same type in
both places.
The EDG front end does not issue an error about this program, though.
Am I reading the standardese incorrectly?
John Spicer: I think you are reading it correctly. I think I've been hoping that this would get changed. Unlike other dual lookup contexts, this is one in which the compiler already knows the right answer (the type must match that of the left hand of the -> operator). So I think that if either of the types found matches the one required, it should be sufficient. You can't say a->~::A(), which means you are forced to say a->::A::~A(), which disables the virtual mechanism. So you would have to do something like create a local typedef for the desired type.
See also issues 244, 399, and 466.
Proposed resolution (October, 2005):
Change 3.4.5 basic.lookup.classref paragraph 3 as indicated:
If the unqualified-id is ~type-name, the type-name is looked up in the context of the entire postfix-expression.andIf the type T of the object expression is of a class type C(or of pointer to a class type C), the type-name is also looked upin the context of the entire postfix-expression andin 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.At least one of the lookups shall find a name that refers to (possibly cv-qualified) T. [Example:struct A { }; struct B { struct A { }; void f(::A* a); }; void B::f(::A* a) { a->~A(); // OK, lookup in *a finds the injected-class-name }—end example]
[Note: this change also resolves issue 414.]
By 3.4.5 basic.lookup.classref paragraph 3, the following is ill-formed because the two lookups of the destructor name (in the scope of the class of the object and in the surrounding context) find different Xs:
struct X {};
int main() {
X x;
struct X {};
x.~X(); // Error?
}
This is silly, because the compiler knows what the type has to be, and one of the things found matches that. The lookup should require only that one of the lookups finds the required class type.
Proposed resolution (April, 2005):
This issue is resolved by the resolution of issue 305.
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]
According to 3.7.3.1 basic.stc.dynamic.allocation paragraph 3,
Any other allocation function that fails to allocate storage shall only indicate failure by throwing an exception of class std::bad_alloc (18.4.2.1 lib.bad.alloc) or a class derived from std::bad_alloc.
Shouldn't this statement have the usual requirements for an unambiguous and accessible base class?
Proposed resolution (October, 2005):
Change the last sentence of 3.7.3.1 basic.stc.dynamic.allocation paragraph 3 as indicated:
Any other allocation function that fails to allocate storage shall only indicate failure by throwing an exception ofclass std::bad_alloc (18.4.2.1 lib.bad.alloc) or a class derived from std::bad_alloca type that would match a handler (15.3 except.handle) of type std::bad_alloc (18.4.2.1 lib.bad.alloc).
When the Standard refers to a virtual base class, it should be understood to include base classes of virtual bases. However, the Standard doesn't actually say this anywhere, so when 4.11 conv.mem (for example) forbids casting to a derived class member pointer from a virtual base class member pointer, it could be read as meaning:
struct B {};
struct D : public B {};
struct D2 : virtual public D {};
int B::*p;
int D::*q;
void f() {
static_cast<int D2::*>(p); // permitted
static_cast<int D2::*>(q); // forbidden
}
Proposed resolution (October, 2005):
Change 4.11 conv.mem paragraph 2 as indicated:
...If B is an inaccessible (clause 11 class.access), ambiguous (10.2 class.member.lookup) or virtual (10.1 class.mi) base class of D, or a base class of a virtual base class of D, a program that necessitates this conversion is ill-formed...
Change 5.2.9 expr.static.cast paragraph 2 as indicated:
...and B isnotneither a virtual base class of D nor a base class of a virtual base class of D...
Change 5.2.9 expr.static.cast paragraph 9 as indicated:
...and B isnotneither a virtual base class of D nor a base class of a virtual base class of D...
The current wording of 5.2.2 expr.call paragraph 7 states:
When there is no parameter for a given argument, the argument is passed in such a way that the receiving function can obtain the value of the argument by invoking va_arg (18.7 lib.support.runtime). The lvalue-to-rvalue (4.1 conv.lval), array-to-pointer (4.2 conv.array), and function-to-pointer (4.3 conv.func) standard conversions are performed on the argument expression. After these conversions, if the argument does not have arithmetic, enumeration, pointer, pointer to member, or class type, the program is ill-formed. If the argument has a non-POD class type (clause 9 class), the behavior is undefined.
Paper J16/04-0167=WG21 N1727 suggests that passing a non-POD object to ellipsis be ill-formed. In discussions at the Lillehammer meeting, however, the CWG felt that the newly-approved category of conditionally-supported behavior would be more appropriate.
Proposed resolution (October, 2005):
Change 5.2.2 expr.call paragraph 7 as indicated:
...After these conversions, if the argument does not have arithmetic, enumeration, pointer, pointer to member, or class type, the program is ill-formed.If the argument has a non-POD class type (clause 9), the behavior is undefined.Passing an argument of non-POD class type (clause 9) with no corresponding parameter is conditionally-supported, with implementation-defined semantics.
5.4 expr.cast paragraph 6 says,
The operand of a cast using the cast notation can be an rvalue of type “pointer to incomplete class type”. The destination type of a cast using the cast notation can be “pointer to incomplete class type”. In such cases, even if there is a inheritance relationship between the source and destination classes, whether the static_cast or reinterpret_cast interpretation is used is unspecified.
The wording seems to allow the following:
casting from void pointer to incomplete type
struct A;
struct B;
void *v;
A *a = (A*)v; // allowed to choose reinterpret_cast
variant application of static or reinterpret casting
B *b = (B*)a; // compiler can choose static_cast here
A *aa = (A*)b; // compiler can choose reinterpret_cast here
assert(aa == a); // might not hold
ability to somehow choose static_cast
It's not entirely clear how a compiler can
choose static_cast as 5.4
expr.cast paragraph 6
seems to allow. I believe the intent of 5.4
expr.cast
paragraph 6 is to force the use of reinterpret_cast when
either are incomplete class types and static_cast iff the
compiler knows both types and there is a non-ambiguous
hierarchy-traversal between that cast (or maybe not, core issue 242 talks about this). I cannot see any
other interpretation because it isn't intuitive, every compiler I've
tried agrees with me, and neither standard pointer conversions
(4.10
conv.ptr paragraph 3) nor static_cast
(5.2.9
expr.static.cast paragraph 5) talk about incomplete
class types. If the committee agrees with me, I would like to see
Proposed resolution (October, 2005):
Change 5.4 expr.cast paragraph 6 as indicated:
The operand of a cast using the cast notation can be an rvalue of type “pointer to incomplete class type.” The destination type of a cast using the cast notation can be “pointer to incomplete class type.” In such cases, even if there isaan inheritance relationship between the source and destination classes, whether the static_cast or reinterpret_cast interpretation is used is unspecified. [Note: For example, if the classes were defined later in the translation unit, a multi-pass compiler would be permitted to interpret a cast between pointers to the classes as if the class types were complete at that point. —end note]
The following translation unit appears to be well-formed.
int x[true?throw 4:5];
According to 5.19 expr.const, this appears to be an integral constant expression: it is a conditional expression, involves only literals, and no assignment, increment, decrement, function-call, or comma operators. However, if this is well-formed, the standard gives no meaning to this declaration, since the array bound (8.3.4 dcl.array paragraph 1) cannot be computed.
I believe the defect is that throw expressions should also be banned from constant expressions.
Notes from October 2002 meeting:
We should also check on new and delete.
Notes from the April, 2005 meeting:
Although it could be argued that all three of these operators potentially involve function calls — throw to std::terminate, new and delete to the corresponding allocation and deallocation functions — and thus would already be excluded from constant expressions, this reasoning was considered to be too subtle to allow closing the issue with no change. A modification that explicitly clarifies the status of these operators will be drafted.
Proposed resolution (October, 2005):
Change the last sentence of 5.19 expr.const as indicated:
In particular, except in sizeof expressions, functions, class objects, pointers, or references shall not be used, and assignment, increment, decrement,function-callfunction call (including new-expressions and delete-expressions),orcomma operators, or throw-expressions shall not be used.
Note: this sentence is also changed by the resolution of issue 530.
Are string literals from default arguments used in extern inlines supposed to have the same addresses across all translation units?
void f(const char* = "s")
inline g() {
f();
}
Must the "s" strings be the same in all copies of the inline function?
Steve Adamczyk: The totality of the standard's wisdom on this topic is (7.1.2 dcl.fct.spec paragraph 4):
A string literal in an extern inline function is the same object in different translation units.
I'd hazard a guess that a literal in a default argument expression is not "in" the extern inline function (it doesn't appear in the tokens of the function), and therefore it need not be the same in different translation units.
I don't know that users would expect such strings to have the same address, and an equally valid (and incompatible) expectation would be that the same string literal would be used for every expansion of a given default argument in a single translation unit.
Notes from April 2003 meeting:
The core working group feels that the address of a string literal should be guaranteed to be the same only if it actually appears textually within the body of the inline function. So a string in a default argument expression in a block extern declaration inside the body of a function would be the same in all instances of the function. On the other hand, a string in a default argument expression in the header of the function (i.e., outside of the body) would not be the same.
Proposed resolution (April 2003):
Change the last sentence and add the note to the end of 7.1.2 dcl.fct.spec paragraph 4:
A string literal in the body of an extern inline function is the same object in different translation units. [Note: A string literal that is encountered only in the context of a function call (in the default argument expression of the called function), is not “in” the extern inline function.]
Notes from October 2003 meeting:
We discussed ctor-initializer lists and decided that they are also part of the body. We've asked Clark Nelson to work on syntax changes to give us a syntax term for the body of a function so we can refer to it here. See also issue 452, which could use this term.
(October, 2005: moved to “review” status in concert with issue 452. With that resolution, the wording above needs no further changes.)
I couldn't find wording that makes it invalid to say friend virtual... The closest seems to be 7.1.2 dcl.fct.spec paragraph 5, which says:
The virtual specifier shall only be used in declarations of nonstatic class member functions that appear within a member-specification of a class definition; see 10.3 class.virtual.
I don't think that excludes a friend declaration (which is a valid member-specification by 9.2 class.mem).
John Spicer: I agree that virtual should not be allowed on friend declarations. I think the wording in 7.1.2 dcl.fct.spec is intended to be the declaration of a function within its class, although I think the wording should be improved to make it clearer.
Proposed resolution (October, 2005):
Change 7.1.2 dcl.fct.spec paragraphs 5-6 as indicated:
The virtual specifier shall
onlybe used only indeclarationsthe declaration of a non-static class memberfunctions that appear within afunction that appears within the member-specification ofaits class definition; see10.3 class.virtual .The explicit specifier shall be used only in
declarationsthe declaration ofconstructorsa constructor withinaits class definition; see 12.3.1 class.conv.ctor.
7.1.5.2 dcl.type.simple paragraph 3 reads,
It is implementation-defined whether bit-fields and objects of char type are represented as signed or unsigned quantities. The signed specifier forces char objects and bit-fields to be signed; it is redundant with other integral types.
The last sentence in that quote is misleading w.r.t. bit-fields. The first sentence in that quote is correct but incomplete.
Proposed fix: change the two sentences to read:
It is implementation-defined whether objects of char type are represented as signed or unsigned quantities. The signed specifier forces char objects signed; it is redundant with other integral types except when declaring bit-fields (9.6 class.bit).
Proposed resolution (October, 2005):
Change 7.1.5.2 dcl.type.simple paragraph 3 as indicated:
When multiple simple-type-specifiers are allowed, they can be freely intermixed with other decl-specifiers in any order. [Note: It is implementation-defined whetherbit-fields andobjects of char type and certain bit-fields (9.6 class.bit) are represented as signed or unsigned quantities. The signed specifier forces bit-fields and char objectsand bit-fieldsto be signed; it is redundantwith other integral typesin other contexts. —end note]o
8.3.2 dcl.ref paragraph 4 says:
A reference shall be initialized to refer to a valid object or function. [Note: in particular, a null reference cannot exist in a well-defined program, because the only way to create such a reference would be to bind it to the "object" obtained by dereferencing a null pointer, which causes undefined behavior ...]
What is a "valid" object? In particular the expression "valid object" seems to exclude uninitialized objects, but the response to Core Issue 363 clearly says that's not the intent. This is an example (overloading construction on constness of *this) by John Potter, which I think is supposed to be legal C++ though it binds references to objects that are not initialized yet:
struct Fun {
int x, y;
Fun (int x, Fun const&) : x(x), y(42) { }
Fun (int x, Fun&) : x(x), y(0) { }
};
int main () {
const Fun f1 (13, f1);
Fun f2 (13, f2);
cout << f1.y << " " << f2.y << "\n";
}
Suggested resolution: Changing the final part of 8.3.2 dcl.ref paragraph 4 to:
A reference shall be initialized to refer to an object or function.
From its point of declaration on (see 3.3.1
basic.scope.pdecl)
its name is an lvalue
which refers to that object or function. The reference may be
initialized to refer to an uninitialized object but, in that case,
it is usable in limited ways (3.8
basic.life, paragraph 6)
[Note: On the other hand, a declaration like this:
int & ref = *(int*)0;
is ill-formed because ref will not refer to any object or function
]
I also think a "No diagnostic is required." would better be added (what about something like int& r = r; ?)
Proposed Resolution (October, 2004):
(Note: the following wording depends on the proposed resolution for issue 232.)
Change 8.3.2 dcl.ref paragraph 4 as follows:
A reference shall be initialized to refer to a valid object or function.If an lvalue to which a reference is directly bound designates neither an existing object or function of an appropriate type (8.5.3 dcl.init.ref), nor a region of memory of suitable size and alignment to contain an object of the reference's type (1.8 intro.object, 3.8 basic.life, 3.9 basic.types), the behavior is undefined. [Note: in particular, a null reference cannot exist in a well-defined program, because the only way to create such a reference would be to bind it to the“object”empty lvalue obtained by dereferencing a null pointer, whichcauses undefined behavior. Asdoes not designate an object or function. Also, as described in 9.6 class.bit, a reference cannot be bound directly to a bit-field. ]The name of a reference shall not be used in its own initializer. Any other use of a reference before it is initialized results in undefined behavior. [Example:
int& f(int&); int& g(); extern int& ir3; int* ip = 0; int& ir1 = *ip; // undefined behavior: null pointer int& ir2 = f(ir3); // undefined behavior: ir3 not yet initialized int& ir3 = g(); int& ir4 = f(ir4); // ill-formed: ir4 used in its own initializer—end example]
Rationale: The proposed wording goes beyond the specific concerns of the issue, primarily in response to messages 10498-10506 on the core reflector. It was noted that, while the current wording makes cases like int& r = r; ill-formed (because r in the initializer does not "refer to a valid object"), an inappropriate initialization can only be detected, if at all, at runtime and thus "undefined behavior" is a more appropriate treatment. Nevertheless, it was deemed desirable to continue to require a diagnostic for obvious compile-time cases.
It was also noted that the current Standard does not say anything about using a reference before it is initialized. It seemed reasonable to address both of these concerns in the same wording proposed to resolve this issue.
Notes from the April, 2005 meeting:
The CWG decided that whether to require an implementation to diagnose initialization of a reference to itself should be handled as a separate issue (504) and also suggested referring to “storage” instead of “memory” (because 1.8 intro.object defines an object as a “region of storage”).
Proposed Resolution (April, 2005):
(Note: the following wording depends on the proposed resolution for issue 232.)
Change 8.3.2 dcl.ref paragraph 4 as follows:
A reference shall be initialized to refer to a valid object or function.If an lvalue to which a reference is directly bound designates neither an existing object or function of an appropriate type (8.5.3 dcl.init.ref), nor a region of storage of suitable size and alignment to contain an object of the reference's type (1.8 intro.object, 3.8 basic.life, 3.9 basic.types), the behavior is undefined. [Note: in particular, a null reference cannot exist in a well-defined program, because the only way to create such a reference would be to bind it to the“object”empty lvalue obtained by dereferencing a null pointer, whichcauses undefined behavior. Asdoes not designate an object or function. Also, as described in 9.6 class.bit, a reference cannot be bound directly to a bit-field. ]Any use of a reference before it is initialized results in undefined behavior. [Example:
int& f(int&); int& g(); extern int& ir3; int* ip = 0; int& ir1 = *ip; // undefined behavior: null pointer int& ir2 = f(ir3); // undefined behavior: ir3 not yet initialized int& ir3 = g(); int& ir4 = f(ir4); // undefined behavior: ir4 used in its own initializer—end example]
According to the definition of value initialization (8.5 dcl.init paragraph 5), non-union class types without user-declared constructors are value-initialized by value-initializing each of their members rather than by executing the (generated) default constructor. However, a number of other items in the Standard are described in relationship to the execution of the constructor:
12.4 class.dtor paragraph 6: “Bases and members are destroyed in the reverse order of the completion of their constructor.” If a given base or member is value-initialized without running its constructor, is it destroyed? (For that matter, paragraph 10 refers to “constructed” objects; is an object that is value-initialized without invoking a constructor “constructed?”)
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 constructor has completed execution...”
3.8 basic.life paragraph 1: The lifetime of an object begins when “the constructor call has completed.” (In the TC1 wording — “if T is a class type with a non-trivial constructor (12.1 class.ctor), the constructor call has completed” — the lifetime of some value-initialized objects never began; in the current wording — “the constructor invoked to create the object is non-trivial” — the lifetime begins before any of the members are initialized.)
Proposed resolution (October, 2005):
Add the indicated words to 8.5 dcl.init paragraph 6:
A program that calls for default-initialization or value-initialization of an entity of reference type is ill-formed. If T is a cv-qualified type, the cv-unqualified version of T is used for these definitions of zero-initialization, default-initialization, and value-initialization. Even when value-initialization of an object does not call that object's constructor, the object is deemed to have been fully constructed once its initialization is complete and thus subject to provisions of this International Standard applying to “constructed” objects, objects “for which the constructor has completed execution,” etc.
The current wording of 8.5.1 dcl.init.aggr paragraph 8 requires that
An initializer for an aggregate member that is an empty class shall have the form of an empty initializer-list {}.
This is overly constraining. There is no reason that the following should be ill-formed:
struct S { };
S s;
S arr[1] = { s };
Mike Miller: The wording of 8.5.1 dcl.init.aggr paragraph 8 is unclear. “An aggregate member” would most naturally mean “a member of an aggregate.” In context, however, I think it must mean “a member [of an aggregate] that is an aggregate”, that is, a subaggregate. Members of aggregates need not themselves be aggregates (cf paragraph 13 and 12.6.1 class.expl.init); it cannot be the case that an object of an empty class with a user-declared constructor must be initialized with {} when it is a member of an aggregate. This wording should be clarified, regardless of the decision on Nathan's point.
Proposed resolution (October, 2005):
This issue is resolved by the resolution of issue 413.
The proposal says that value is true if "T is an empty class (10)". Clause 10 doesn't define an empty class, although it has a note that says a base class may "be of zero size (clause 9)" 9/3 says "Complete objects and member subobjects of class type shall have nonzero size." This has a footnote, which says "Base class subobjects are not so constrained."
The standard uses the term "empty class" in two places (8.5.1 dcl.init.aggr), but neither of those places defines it. It's also listed in the index, which refers to the page that opens clause 9, i.e. the nonzero size stuff cited above.
So, what's the definition of "empty class" that determines whether the predicate is_empty is true?
The one place where it's used is 8.5.1 dcl.init.aggr paragraph 8, which says (roughly paraphrased) that an aggregate initializer for an empty class must be "{}", and when such an initializer is used for an aggregate that is not an empty class the members are default-initialized. In this context it's pretty clear what's meant. In the type traits proposal it's not as clear, and it was probably intended to have a different meaning. The boost implementation, after it eliminates non-class types, determines whether the trait is true by comparing the size of a class derived from T to the size of an otherwise-identical class that is not derived from T.
Howard Hinnant: is_empty was created to find out whether a type could be derived from and have the empty base class optimization successfully applied. It was created in part to support compressed_pair which attempts to optimize away the space for one of its members in an attempt to reduce spatial overhead. An example use is:
template <class T, class Compare = std::less<T> >
class SortedVec
{
public:
...
private:
T* data_;
compressed_pair<Compare, size_type> comp_;
Compare& comp() {return comp_.first();}
const Compare& comp() const {return comp_.first();}
size_type& sz() {return comp_.second();}
size_type sz() const {return comp_.second();}
};
Here the compare function is optimized away via the empty base optimization if Compare turns out to be an "empty" class. If Compare turns out to be a non-empty class, or a function pointer, the space is not optimized away. is_empty is key to making this work.
This work built on Nathan's article: http://www.cantrip.org/emptyopt.html.
Clark Nelson: I've been looking at issue 413, and I've reached the conclusion that there are two different kinds of empty class. A class containing only one or more anonymous bit-field members is empty for purposes of aggregate initialization, but not (necessarily) empty for purposes of empty base-class optimization.
Of course we need to add a definition of emptiness for purposes of aggregate initialization. Beyond that, there are a couple of questions:
Notes from the October, 2005 meeting:
There are only two places in the Standard where the phrase “empty class” appears, both in 8.5.1 dcl.init.aggr paragraph 8. Because it is not clear whether the definition of “empty for initialization purposes” is suitable for use in defining the is_empty predicate, it would be better just to avoid using the phrase in the language clauses. The requirements of 8.5.1 dcl.init.aggr paragraph 8 appear to be redundant; paragraph 6 says that an initializer-list must have no more initializers than the number of elements to initialize, so an empty class already requires an empty initializer-list, and using an empty initializer-list with a non-empty class is covered adequately by paragraph 7's description of the handling of an initializer-list with fewer initializers than the number of members to initialize.
Proposed resolution (October, 2005):
Change
Static data members and anonymous bit fields are not considered members of the class for purposes of aggregate initialization. [Example:
struct A { int i; static int s; int j; int :17; int k; } a = { 1 , 2 , 3 };Here, the second initializer 2 initializes a.j and not the static data member A::s, and the third initializer 3 initializes a.k and not the padding before it. —end example]
Delete 8.5.1 dcl.init.aggr paragraph 8:
An initializer for an aggregate member that is an empty class shall have the form of an empty initializer-list {}. [Example:
struct S { }; struct A { S s; int i; } a = { { } , 3 };—end example] An empty initializer-list can be used to initialize any aggregate. If the aggregate is not an empty class, then each member of the aggregate shall be initialized with a value of the form T() (5.2.3 expr.type.conv), where T represents the type of the uninitialized member.
This resolution also resolves issue 491.
Additional note (October, 2005):
Deleting 8.5.1 dcl.init.aggr paragraph 8 altogether may not be a good idea. It would appear that, in its absence, the initializer elision rules of paragraph 11 would allow the initializer for a in the preceding example to be written { 3 } (because the empty-class member s would consume no initializers from the list).
9.3.2 class.this paragraph 1, which specifies the meaning of the keyword 'this', seems to limit its usage to the *body* of non-static member functions. However 'this' is also usable in ctor-initializers which, according to the grammar in 8.4 dcl.fct.def par. 1, are not part of the body.
Proposed resolution: Changing the first part of 9.3.2 class.this par. 1 to:
In the body of a nonstatic (9.3) member function or in a ctor-initializer (12.6.2), the keyword this is a non-lvalue expression whose value is the address of the object for which the function is called.
NOTE: I'm talking of constructors as functions that are "called"; there have been discussions on c.l.c++.m as to whether constructors are "functions" and to whether this terminology is correct or not; I think it is both intuitive and in agreement with the standard wording.
Steve Adamczyk: See also issue 397, which is defining a new syntax term for the body of a function including the ctor-initializers.
Notes from the March 2004 meeting:
This will be resolved when issue 397 is resolved.
Proposed resolution (October, 2005):
Change 8.4 dcl.fct.def paragraph 1 as indicated:
Function definitions have the form
function-definition:
decl-specifier-seqopt declarator
ctor-initializeroptfunction-bodyfunction-body:
decl-specifier-seqopt declarator function-try-blockctor-initializer compound-statement
function-try-block
An informal reference to the body of a function should be interpreted as a reference to the nonterminal function-body.
Change the definition of function-try-block in 15 except paragraph 1:
function-try-block:
try ctor-initializeropt
function-bodycompound-statement handler-seq
Change 3.3.6 basic.scope.class paragraph 1, point 1, as indicated:
The potential scope of a name declared in a class consists not only of the declarative region following the name's point of declaration, but also of all functionbodies,bodies and default arguments, and constructor ctor-initializersin that class (including such things in nested classes).
Change 3.3.6 basic.scope.class paragraph 1, point 5, as indicated:
The potential scope of a declaration that extends to or past the end of a class definition also extends to the regions defined by its member definitions, even if the members are defined lexically outside the class (this includes static data member definitions, nested class definitions, member function definitions (including the member function bodyand, for constructor functions (12.1 class.ctor), the ctor-initializer () and any portion of the declarator part of such definitions which follows the identifier, including a parameter-declaration-clause and any default arguments (8.3.6 dcl.fct.default). [Example:...12.6.2 class.base.init )
Change footnote 32 in 3.4.1 basic.lookup.unqual paragraph 8 as indicated:
That is, an unqualified name that occurs, for instance, in a type or default argument expression in theparameter-declaration-clause,parameter-declaration-clause or in the function body, or in an expression of a mem-initializer in a constructor definition.
Change 5.1 expr.prim paragraph 3 as indicated:
...The keyword this shall be used only inside a non-static class member function body (9.3 class.mfct)or in a constructor mem-initializer (12.6.2 class.base.init)...
Change 9.2 class.mem paragraph 2 as indicated:
...Within the class member-specification, the class is regarded as complete within function bodies, default arguments, and exception-specifications, and constructor ctor-initializers(including such things in nested classes)...
Change 9.2 class.mem paragraph 9 as indicated:
Each occurrence in an expression of the name of a non-static data member or non-static member function of a class shall be expressed as a class member access (5.2.5 expr.ref), except when it appears in the formation of a pointer to member (5.3.1 expr.unary.op), oror when it appears in the body of a non-static member function of its class or of a class derived from its class (9.3.1 class.mfct.nonstatic), or when it appears in a mem-initializer for a constructor for its class or for a class derived from its class (12.6.2 class.base.init).
Change the note in 9.3 class.mfct paragraph 5 as indicated:
[Note: a name used in a member function definition (that is, in the parameter-declaration-clause including the default arguments (8.3.6 dcl.fct.default), oror in the member function body, or, for a constructor function (12.1 class.ctor), in a mem-initializer expression (12.6.2 class.base.init)) is looked up as described in 3.4 basic.lookup. —end note]
Change 9.3.1 class.mfct.nonstatic paragraph 1 as indicated:
...A non-static member function may also be called directly using the function call syntax (5.2.2 expr.call, 13.3.1.1 over.match.call) from within the body of a member function of its class or of a class derived from its class.
- from within the body of a member function of its class or of a class derived from its class, or
- from a mem-initializer (12.6.2 class.base.init) for a constructor for its class or for a class derived from its class.
Change 9.3.1 class.mfct.nonstatic paragraph 3 as indicated:
When an id-expression (5.1 expr.p