Related
As a follow-up to this question, clang accepts the code provided there. This question has the following code:
constexpr int func(int const& rf){
return rf;
}
int main(){
constexpr int value = func(0);
}
This question has a good answer, but it follows the C++17 standard. As far as I can tell, the wording regarding constant expression rules is relatively changed from C++17 to C++20 and later.
Basically, It has to determine whether the call expression func(0) is a constant expression; so firstly we have to know whether the call expression is core constant expression or not, which is governed by the rules defined in [expr.const]/5:
An expression E is a core constant expression unless the evaluation
of E, following the rules of the abstract machine
([intro.execution]), would evaluate one of the following:
(5.8) an lvalue-to-rvalue conversion unless it is applied to
(5.8.1) a non-volatile glvalue that refers to an object that is usable in constant expressions, or
(5.8.2) a non-volatile glvalue of literal type that refers to a non-volatile object whose lifetime began within the evaluation of E;
The rule (5.8) is applied because the expression E evaluates an lvalue-to-rvalue conversion: that's, the lvalue rf has to be converted to prvalue as the returned value of the function call.
According to (5.8.1), the expression rf is a non-volatile glvalue; but, does it is usable in constant expressions? Per [expr.const]/4:
[..]
An object or reference is usable in constant expressions if it is
(4.4) a variable that is usable in constant expressions, or
[..]
(4.7) a temporary object of non-volatile const-qualified literal type whose lifetime is extended ([class.temporary]) to that of a
variable that is usable in constant expressions, or
I'm not so sure whether bullet (4.7) is applicable to this case. But I think that it might be applicable because note that rf is bound to a materialized temporary of non-volatile const-qualified literal type whose lifetime is extended and that temporary is usable in constant expression because it's potentially-constant as well as constant-initialized.
Also, I can't find any reason why (4.4) is not applicable: rf is a variable and it's usable in constant expressions because it's potentially-constant and constant-initialized with the value 0.
So that's my confusion: which bullet (if any) is applicable here? and why?
If neither of (4.4) or (4.7) is applicable to this case, that means rf may not be usable in constant expression which also means that (5.8.1) is not satisfied and (5.8.2) is then tried. I'm not having any problem with (5.8.2): if (5.8.1) failed, (5.8.2) succeeded because the lifetime of rf exactly began within the evaluation of func(0). If that's the case, why (5.8.1) is not satisfied? My confusion specifically is why (4.7) is not satisfied.
Also note that [expr.const]/(5.12) is not reached: (5.8) is tried first.
p5.8.1 is not satisfied. rf does not refer to "an object that is usable in constant expressions", because:
p4.4 is not satisfied: the object that rf refers to is not a variable (it is a temporary object). (Notice that whether or not rf itself is a "variable that is usable in constant expressions" is not relevant for p4.4; the test of p5.8.1 is whether the object that the glvalue refers to is a variable that is usable in constant expressions. But see p4.7, below.)
p4.5, 4.6, and 4.8 are obviously not applicable.
p4.7 is not satisfied. Leaving aside the question of whether the temporary object of type int is const-qualified or not (which has been discussed in a previous question), the reference rf is not "a variable that is usable in constant expressions" anyway, because a function parameter doesn't have an initializing declaration.
I would answer this question from the perspective of the c++20 standard since the bullet [expr.const] p5.12 is removed and is taken place by the new concept in the c++23 draft.
First, the constexpr specifier requires the full-expression of the initialization of the variable value to be a constant expression, and a constant expression is either a glvalue core constant expression or a prvalue core constant expression, which is regulated by [expr.const] p5, where the bullet [expr.const] p5.2, [expr.const] p5.8, and [expr.const] p5.12 are relevant here.
An expression E is a core constant expression unless the evaluation of E, following the rules of the abstract machine ([intro.execution]), would evaluate one of the following:
[...]
an invocation of a non-constexpr function
[...]
an lvalue-to-rvalue conversion unless it is applied to
a non-volatile glvalue that refers to an object that is usable in constant expressions, or
a non-volatile glvalue of literal type that refers to a non-volatile object whose lifetime began within the evaluation of E;
an id-expression that refers to a variable or data member of reference type unless the reference has a preceding initialization and either
it is usable in constant expressions or
its lifetime began within the evaluation of E;
In your example, func is a constexpr function, hence, it does not violate the first bullet in the list. The variable rf that appears in the return statement requires lvalue-to-rvalue conversion to apply to rf, where rf is a glvalue that refers to the object that is of literal type(int), and the lifetime of the object began within the evaluation of the full-expression of the initialization, see [class.temporary] p1 and [intro.execution] p5, hence the whole full-expression of the initialization still does not violate the second bullet in the list.
For the third bullet, since the id-expression rf is of reference type, however, its lifetime still began within the evaluation of the full-expression of the initialization, see [basic.life] p1, because the initialization of rf occurs in the evaluation of the full-expression of the initialization. So, eventually, the full-expression of the initialization of the variable value is a constant expression.
For the concept preceding initialization, it basically means it has been initialized. Anyway, it is CWG2186. However, as I said in the initial, the bullet is just removed in c++23 standard.
After hard searching and breaking down the rules from the standard, I would add a C++20 answer for this question.
constexpr int func(int const& rf){
return rf;
}
int main(){
constexpr int value = func(0);
}
As said above we need to determine whether the expression func(0) is a core constant expression or not.
Per [expr.const]/5, the first bullet we encountered that need to be checked is (5.8) since an lvalue-to-rvalue is applied to rf:
An expression E is a core constant expression unless the evaluation
of E, following the rules of the abstract machine
([intro.execution]), would evaluate one of the following:
(5.8) an lvalue-to-rvalue conversion unless it is applied to
(5.8.1) a non-volatile glvalue that refers to an object that is usable in constant expressions, or
(5.8.2) a non-volatile glvalue of a literal type that refers to a non-volatile object whose lifetime began within the evaluation of E;
The bullet (5.8.1) is tried first: The lvalue-to-rvalue is applied to a non-volatile glvalue which is rf; but does this glvalue refers to an object that's usable in constant expressions? In fact, rf refers to a temporary object. In order to know whether this temporary object is usable in constant expression, we've to request [expr.const]/4: Both p4.4 and p4.7 are needed to be checked here:
[..] An object or reference is usable in constant expressions if it is
(4.4) a variable that is usable in constant expressions, or
[..]
(4.7) a temporary object of non-volatile const-qualified literal type whose lifetime is extended ([class.temporary]) to that of a
variable that is usable in constant expressions, or [..]
Intuitively, the bullet (4.4) is not applied because rf refers to a temporary object, not to a variable.
On other hand (4.7) is relevant here: rf refers to a temporary object of non-volatile const-qualified (per [dcl.init.ref]/(5.3)) literal type (per [basic.types.general]/10), and its lifetime is extended (per [class.temporary]); but in order for (4.7) to apply completely, the lifetime of the temporary has to be extended to that of a variable usable in constant expressions: In other words, the variable (rf) that extends the lifetime of the temporary has to usable in constant expressions. So does the variable rf usable in constant expressions?
In order to know whether the variable rf is usable in constant expression, we have to know whether it's potentially-constant and constant-initialized. So per [const.expr]/3:
A variable is potentially-constant if it is constexpr or it has
reference or const-qualified integral or enumeration type.
So, the variable rf is potentially-constant because it's of reference type.
But, per [const.expr]/2:
A variable or temporary object o is constant-initialized if
(2.1) either it has an initializer [..] and
(2.2) the full-expression of its initialization is a constant expression [..]
I'm not so sure whether (2.1) is satisfied or not: That's, I can't tell whether the variable rf has an initializer or not. I will assume that the rf has an initializer which is the materialized temporary even though I made a question on that.
For (2.2) to be applied, the full-expression of the initialization of rf has to be a constant expression. But, the variable rf is bound to a temporary that's not a constant expression per [const.expr]/11:
A constant expression is either a glvalue core constant expression
that refers to an entity that is a permitted result of a constant
expression (as defined below), or a prvalue core constant expression
whose value satisfies the following constraints:
(11.1) if the value is an object of class type, each non-static data member of reference type refers to an entity that is a permitted
result of a constant expression,
(11.2) - if the value is of pointer type, it contains the address of an object with static storage duration, the address past the end of
such an object ([expr.add]), the address of a non-immediate function,
or a null pointer value,
(11.3) - if the value is of pointer-to-member-function type, it does not designate an immediate function, and
(11.4) - if the value is an object of class or array type, each subobject satisfies these constraints for the value.
An entity is a permitted result of a constant expression if it is an
object with static storage duration that either is not a temporary
object or is a temporary object whose value satisfies the above
constraints, or if it is a non-immediate function.
That's the value of the temporary is neither of class type nor pointer type nor array type. But even though the temporary object satisfies those constraints, it's not a permitted result of a constant expression because it's not an object with static storage duration. Hence, the temporary is not glvalue core constant expression and therefore is not a constant expression.
Therefore, the variable rf is not constant-initialized and therefore is not usable in constant expression, therefore (4.7) is failed and therefore the temporary bound by rf is also not usable in constant expressions, and therefore (5.8.1) is failed.
Then, (5.8.2) is tried: (5.8.2) is succeeded because the lifetime of rf exactly began within the evaluation of func(0). Checking the subsequent bullets is not relevant to the question. But since the above program is not ill-formed, this means all subsequent bullets are satisfied, and therefore func(0) is a prvalue core constant expression and therefore a constant expression.
The expression b in this code shall be a core constant expression
int main()
{
constexpr int a = 10;
const int &b = a;
constexpr int c = b; // Here
return 0;
}
since the standard says (8.20, paragraph 2 [expr.const] in n4700)
An expression e is a core constant expression unless the evaluation of
e would evaluate one of the following expressions:
...
an lvalue-to-rvalue conversion (7.1) unless it is applied to
...
a non-volatile glvalue that refers to a non-volatile object defined with constexpr, or that refers to a non-mutable subobject of such an object, or
First, the expression b in the above code is an lvalue (which is also a glvalue) since it's a reference, thereby being a variable (8.1.4.1, paragraph 1
[expr.prim.id.unqual]):
The expression is an lvalue if the entity is a function,
variable, or data member and a prvalue otherwise; it is a bit-field if the identifier designates a bit-field (11.5).
Second, the object the variable b denotes is a, and it's declared with constexpr. However, GCC complains:
./hello.cpp: In function ‘int main()’:
./hello.cpp:6:20: error: the value of ‘b’ is not usable in a constant expression
constexpr int c = b;
^
./hello.cpp:5:13: note: ‘b’ was not declared ‘constexpr’
const int &b = a;
As far as I can tell, a reference is not an object, so the above bullet apparently suggests that a shall be declared with constexpr. Am I missing something?
The reason why I don't agree with GCC is that GCC sees b as an object, thereby requiring it to be declared with constexpr. However, b is not an object!
One of the rules for core constant expressions is that we can't evaluate:
an id-expression that refers to a variable or data member of reference type unless the reference has a preceding initialization and either
it is initialized with a constant expression or
its lifetime began within the evaluation of e;
b is an id-expression that refers to a variable of reference type with preceding initialization. However, it is initialized from a. Is a a constant expression? From [expr.const]/6:
A constant expression is either a glvalue core constant expression that refers to an entity that is a permitted result of a constant expression (as defined below), or a prvalue core constant expression whose value satisfies the following constraints: [... ]
An entity is a permitted result of a constant expression if it is an object with static storage duration that is either not a temporary object or is a temporary object whose value satisfies the above constraints, or it is a function.
a is a glvalue core constant expression (it doesn't hit any of the restrictions in expr.const/2), however it is not an object with static storage duration. Nor is it a function.
Hence, a is not a constant expression. And b, as a result, isn't initialized from a constant expression and so can't be used in a core constant expression. And thus c's initialization is ill-formed as not being a constant expression. Declare a as a static constexpr int, and both GCC and Clang accept the program.
C++, you magical beast.
All quotes given in this answer are from the current working draft.
Given your example:
int main()
{
constexpr int a = 10;
const int &b = a;
constexpr int c = b; // here
return 0;
}
First of all, let's take your example line by line. The first line is a definition of a constexpr variable named by identifier a:
constexpr int a = 10;
The initializer 10 is an integral constant expression, hence it's a core constant expression, per [expr.const]/9:
An integral constant expression is an expression of integral or
unscoped enumeration type, implicitly converted to a prvalue, where
the converted expression is a core constant expression. [ Note: Such
expressions may be used as bit-field lengths, as enumerator
initializers if the underlying type is not fixed, and as alignments.
— end note ]
And it's a constant expression because it's a prvalue core constant expression that satisfies the [expr.const]/12 constraints:
A constant expression is [..] a prvalue core constant expression
whose value satisfies the following constraints:
(12.1) if the value is an object of class type, each non-static data
member of reference type refers to an entity that is a permitted
result of a constant expression,
(12.2) if the value is of pointer
type, it contains the address of an object with static storage
duration, the address past the end of such an object ([expr.add]), the
address of a non-immediate function, or a null pointer value
(12.3)
if the value is of pointer-to-member-function type, it does not
designate an immediate function, and
(12.4) if the value is an object
of class or array type, each subobject satisfies these constraints for
the value.
Hence, the initializer expression 10 is a prvalue core constant expression that's neither a pointer type nor a class type nor an array type. Hence, it's a constant expression.
The second line declares/defines a reference to a named by identifier b:
const int &b = a;
In order to know whether the initializer expression a is a core constant expression, you have to invoke [expr.const]/5:
An expression E is a core constant expression unless the evaluation
of E, following the rules of the abstract machine ([intro.execution]),
would evaluate one of the following: [..]
At this point, the evaluation of E does not evaluate any of the constraints defined in [expr.const]/5. Therefore, the expression E is a core constant expression.
But being E is a glvalue core constant expression that doesn't mean that E is also constant expression; so you have to check [expr.const]/12:
A constant expression is either a glvalue core constant expression
that refers to an entity that is a permitted result of a constant
expression [..]
An entity is a permitted result of a constant expression if it is an
object with static storage duration that either is not a temporary
object or is a temporary object whose value satisfies the above
constraints, or if it is a non-immediate function.
So the entity a is not a permitted result of constant expression because that entity neither refers to an object with static storage duration nor a temporary object or non-immediate function. Therefore, the glvalue core constant expression a is not a constant expression.
The third line defines an constexpr variable named by identifier c initialized by the variable b:
constexpr int c = b;
Again you have to invoke [expr.const]/5 in order to know whether the expression b is a core constant expression or not. As you already noticed, the bullet (5.8) maybe satisfied since the initialization of c involves an lvalue-to-rvalue conversion. So per [expr.const]/5
An expression E is a core constant expression unless the evaluation of
E [..] would evaluate one of the following:
(5.8) an lvalue-to-rvalue conversion unless it is applied to
(5.8.1) a non-volatile glvalue that refers to an object that is usable in constant expressions, or
(5.8.2) a non-volatile glvalue of literal type that refers to a non-volatile object whose lifetime began within the evaluation of E;
Note that the document to which I refer doesn't have the following bullet. But C++20 documents have it. And I don't know why it's removed from the current working draft. ([expr.const]/(5.12)):
(5.12) an id-expression that refers to a variable or data member of
reference type unless the reference has a preceding initialization and
either
(5.12.1) it is usable in constant expressions or
(5.12.2) its
lifetime began within the evaluation of E;
Even if it's checked, the expression E is still not a core constant expression because the reference is not usable in constant expressions (see below) and its lifetime doesn't begin within the evaluation of E.
Back to our explanation. The bullet (5.8) is satisfied since the expression E evaluates an lvalue-to-rvalue conversion. So (5.8.1) is tried first.
Indeed, the lvalue-to-rvalue conversion is applied to a non-volatile glvalue (b). But, Is this glvalue refers to an object that's usable in constant expressions? First, you have to check whether it's a constant-initialized variable, then also you have to check whether it's a potentially-constant variable, so [expr.const]/2 is checked first:
A variable or temporary object o is constant-initialized if
(2.1) either it has an initializer or its default-initialization results in some initialization being performed, and
(2.2) the full-expression of its initialization is a constant expression when interpreted as a constant-expression [..]
The first bullet (2.1) is satisfied because the variable b has an initializer. But the second bullet isn't satisfied because the full-expression of its initialization is not a constant expression because its initializer a is not a constant expression as aforementioned. Therefore, the variable b is not constant-initialized.
Just for completeness, the [expr.const]/3 is tried:
A variable is potentially-constant if it is constexpr or it has a
reference or const-qualified integral or enumeration type.
Since the variable b has a reference type, it's considered to be potentially-constant. Note, there's no need to check whether the variable b is potentially-constant because intuitively you can't even enter the [expr.const]/4 since it requires the variable to be constant-initialized:
A constant-initialized potentially-constant variable is usable in
constant expressions at a point P if its initializing declaration D is
reachable from P [..]
(emphasis mine)
Even though the variable is potentially-constant, it's not usable in a constant expression because it's not constant-initialized. So we ended up with that the variable b is not usable in constant expressions (as the GCC diagnostic hints to you). Therefore, the bullet (5.8.1) is not satisfied: Hence, the expression E is not a core constant expression and therefore not a constant expression.
N4527 5.20 [expr.const]p3
An integral constant expression is an expression of integral or unscoped enumeration type, implicitly converted to a prvalue, where the converted expression is a core constant expression.
5.20 [expr.const]p5
A constant expression is either a glvalue core constant expression whose value refers to an entity that is a permitted result of a constant expression (as defined below), or a prvalue core constant expression whose
value is an object where, for that object and its subobjects:
(5.1) — each non-static data member of reference type refers to an entity that is a permitted result of a constant
expression, and
(5.2) — if the object or subobject is of pointer type, it contains the address of an object with static storage
duration, the address past the end of such an object (5.7), the address of a function, or a null pointer
value.
An entity is a permitted result of a constant expression if it is an object with static storage duration that is either not a temporary object or is a temporary object whose value satisfies the above constraints, or it is a
function.
void foo(){
const int a = 1;//a has automatic storage duration
// all ok in gcc 5.1.0 and clang 3.8.0
int b[a]{};
static_assert(a,"");
switch(1){
case a:
;
}
}
Question1: Is a an integral constant expression?
Question2: Is a a constant expression?
Question3: Is a glvalue integral constant expression a constant expression?
Question4:
If the answer of question 3 is yes,
does this conflict with 5.20 p3 if the object has automatic storage duration?
Is a an integral constant expression?
In the following contexts:
int b[a]{};
static_assert(a,"");
switch(1){
case a:
;
}
yes, a is an integral constant expression. Starting with your first quote:
An integral constant expression is an expression of integral or unscoped enumeration type, implicitly converted
to a prvalue, where the converted expression is a core constant expression.
'a' is an integral type, in your cases it will be implicitly converted to a prvalue, so now is a a core constant expression? Yes, if we go back to paragraph 2 which defines what is not a core constant expression:
A conditional-expression e is a core constant expression unless the evaluation of e, following the rules of the
abstract machine (1.9), would evaluate one of the following expressions
it has the following clause:
an lvalue-to-rvalue conversion (4.1) unless it is applied to
with the following exception:
a non-volatile glvalue of integral or enumeration type that refers to a complete non-volatile const
object with a preceding initialization, initialized with a constant expression, or
which applies to a since it is non-volatile, const and is initialized with a constant expression.
Is a a constant expression?
In the same contexts as above, yes, since we can see from the quote above it is a core constant expression.
Is a glvalue integral constant expression a constant expression?
No, in order for it to be a integral constant expression it must be converted to a prvalue and threfore can not be a glvalue.
Given the following code:
struct A { static constexpr int a[3] = {1,2,3}; };
int main () {
int a = A::a[0];
int b [A::a[1]];
}
is A::a necessarily odr-used in int a = A::a[0]?
Note: This question represents a less flamey/illogical/endless version of a debate in the Lounge.
First use of A::a:
int a = A::a[0];
The initializer is a constant expression, but that doesn't stop A::a from being odr-used here. And, indeed, A::a is odr-used by this expression.
Starting from the expression A::a[0], let's walk through [basic.def.odr](3.2)/3 (for future readers, I'm using the wording from N3936):
A variable x [in our case, A::a] whose name appears as a potentially-evaluated expression ex [in our case, the id-expression A::a] is odr-used unless
applying the lvalue-to-rvalue conversion to x yields a constant expression [it does]
that does not invoke any non-trivial functions [it does not] and,
if x is an object [it is],
ex is an element of the set of potential results of an expression e, where either the lvalue-to-rvalue conversion is applied to e, or e is a discarded-value expression.
So: what possible values of e are there? The set of potential results of an expression is a set of subexpressions of the expression (you can check this by reading through [basic.def.odr](3.2)/2), so we only need to consider expressions of which ex is a subexpression. Those are:
A::a
A::a[0]
Of these, the lvalue-to-rvalue conversion is not applied immediately to A::a, so we only consider A::a[0]. Per [basic.def.odr](3.2)/2, the set of potential results of A::a[0] is empty, so A::a is odr-used by this expression.
Now, you could argue that we first rewrite A::a[0] to *(A::a + 0). But that changes nothing: the possible values of e are then
A::a
A::a + 0
(A::a + 0)
*(A::a + 0)
Of these, only the fourth has an lvalue-to-rvalue conversion applied to it, and again, [basic.def.odr](3.2)/2 says that the set of potential results of *(A::a + 0) is empty. In particular, note that array-to-pointer decay is not an lvalue-to-rvalue conversion ([conv.lval](4.1)), even though it converts an array lvalue to a pointer rvalue -- it's an array-to-pointer conversion ([conv.array](4.2)).
Second use of A::a:
int b [A::a[1]];
This is no different from the first case, according to the standard. Again, A::a[1] is a constant expression, thus this is a valid array bound, but a compiler is still permitted to emit code at runtime to compute this value, and the array bound still odr-uses A::a.
Note in particular that constant expressions are (by default) potentially-evaluated expressions. Per [basic.def.odr](3.2)/2:
An expression is potentially evaluated unless it is an unevaluated operand (Clause 5) or a subexpression thereof.
[expr](5)/8 just redirects us to other subclauses:
In some contexts, unevaluated operands appear (5.2.8, 5.3.3, 5.3.7, 7.1.6.2). An unevaluated operand is not evaluated.
These subclauses say that (respectively) the operand of some typeid expressions, the operand of sizeof, the operand of noexcept, and the operand of decltype are unevaluated operands. There are no other kinds of unevaluated operand.
Yes, A::a is odr-used.
In C++11, the relevant wording is 3.2p2 [basic.def.odr]:
[...] A variable whose name appears as a potentially-evaluated expression is odr-used unless it is an object that satisfies the requirements for appearing in a constant expression (5.19) and the lvalue-to-rvalue conversion (4.1) is immediately applied. [...]
The name of the variable A::a appears in the declaration int a = A::a[0], in the full-expression A::a[0], which is a potentially-evaluated expression. A::a is:
an object
that satisfies the requirements for appearing in a constant expression
However, the lvalue-to-rvalue conversion is not immediately applied to A::a; it is applied to the expression A::a[0]. Indeed, lvalue-to-rvalue conversion may not apply to an object of array type (4.1p1).
So A::a is odr-used.
Since C++11, the rules have been broadened somewhat. DR712 Are integer constant operands of a conditional-expression "used?" introduces the concept of the set of potential results of an expression, which allows expressions such as x ? S::a : S::b to avoid odr-use. However, while the set of potential results respects such operators as the conditional operator and comma operator, it does not respect indexing or indirection; so A::a is still odr-used in the current drafts for C++14 (n3936 as of date).
[I believe this is a condensed equivalent to Richard Smith's answer, which however does not mention the change since C++11.]
At When is a variable odr-used in C++14? we discuss this issue and possible wording changes to section 3.2 to allow indexing or indirecting an array to avoid odr-use.
No, it is not odr-used.
First, both your array and its elements are of literal type:
[C++11: 3.9/10]: A type is a literal type if it is:
a scalar type; or
a class type (Clause 9) with
a trivial copy constructor,
no non-trivial move constructor,
a trivial destructor,
a trivial default constructor or at least one constexpr constructor other than the copy or move constructor, and
all non-static data members and base classes of literal types; or
an array of literal type.
Now we look up the odr-used rules:
[C++11: 3.2/2]: [..] A variable or non-overloaded function whose name appears as a potentially-evaluated expression is odr-used unless it is an object that satisfies the requirements for appearing in a constant expression (5.19) and the lvalue-to-rvalue conversion (4.1) is immediately applied. [..]
And here we've been referred to the rules on constant expressions, which contain nothing prohibiting your initialiser from being a constant expression; the pertinent passages are:
[C++11: 5.19/2]: A conditional-expression is a constant expression unless it involves one of the following as a potentially evaluated subexpression [..]:
[..]
an lvalue-to-rvalue conversion (4.1) unless it is applied to
a glvalue of integral or enumeration type that refers to a non-volatile const object with a preceding initialization, initialized with a constant expression, or
a glvalue of literal type that refers to a non-volatile object defined with constexpr, or that refers to a sub-object of such an object, or
a glvalue of literal type that refers to a non-volatile temporary object initialized with a constant expression;
[..]
(Don't be put off by the name of the production, "conditional-expression": it is the only production of constant-expression and is thus the one we're looking for.)
Then, thinking about the equivalence of A::a[0] to *(A::a + 0), after the array-to-pointer conversion you have an rvalue:
[C++11: 4.2/1]: An lvalue or rvalue of type "array of N T" or "array of unknown bound of T" can be converted to a prvalue of type "pointer to T". The result is a pointer to the first element of the array.
Your pointer arithmetic is then performed on this rvalue and the result is also an rvalue, used to initialise a. No lvalue-to-rvalue conversion here whatsoever, so still nothing violating "the requirements for appearing in a constant expression".
Given the following code:
struct A { static constexpr int a[3] = {1,2,3}; };
int main () {
int a = A::a[0];
int b [A::a[1]];
}
is A::a necessarily odr-used in int a = A::a[0]?
Note: This question represents a less flamey/illogical/endless version of a debate in the Lounge.
First use of A::a:
int a = A::a[0];
The initializer is a constant expression, but that doesn't stop A::a from being odr-used here. And, indeed, A::a is odr-used by this expression.
Starting from the expression A::a[0], let's walk through [basic.def.odr](3.2)/3 (for future readers, I'm using the wording from N3936):
A variable x [in our case, A::a] whose name appears as a potentially-evaluated expression ex [in our case, the id-expression A::a] is odr-used unless
applying the lvalue-to-rvalue conversion to x yields a constant expression [it does]
that does not invoke any non-trivial functions [it does not] and,
if x is an object [it is],
ex is an element of the set of potential results of an expression e, where either the lvalue-to-rvalue conversion is applied to e, or e is a discarded-value expression.
So: what possible values of e are there? The set of potential results of an expression is a set of subexpressions of the expression (you can check this by reading through [basic.def.odr](3.2)/2), so we only need to consider expressions of which ex is a subexpression. Those are:
A::a
A::a[0]
Of these, the lvalue-to-rvalue conversion is not applied immediately to A::a, so we only consider A::a[0]. Per [basic.def.odr](3.2)/2, the set of potential results of A::a[0] is empty, so A::a is odr-used by this expression.
Now, you could argue that we first rewrite A::a[0] to *(A::a + 0). But that changes nothing: the possible values of e are then
A::a
A::a + 0
(A::a + 0)
*(A::a + 0)
Of these, only the fourth has an lvalue-to-rvalue conversion applied to it, and again, [basic.def.odr](3.2)/2 says that the set of potential results of *(A::a + 0) is empty. In particular, note that array-to-pointer decay is not an lvalue-to-rvalue conversion ([conv.lval](4.1)), even though it converts an array lvalue to a pointer rvalue -- it's an array-to-pointer conversion ([conv.array](4.2)).
Second use of A::a:
int b [A::a[1]];
This is no different from the first case, according to the standard. Again, A::a[1] is a constant expression, thus this is a valid array bound, but a compiler is still permitted to emit code at runtime to compute this value, and the array bound still odr-uses A::a.
Note in particular that constant expressions are (by default) potentially-evaluated expressions. Per [basic.def.odr](3.2)/2:
An expression is potentially evaluated unless it is an unevaluated operand (Clause 5) or a subexpression thereof.
[expr](5)/8 just redirects us to other subclauses:
In some contexts, unevaluated operands appear (5.2.8, 5.3.3, 5.3.7, 7.1.6.2). An unevaluated operand is not evaluated.
These subclauses say that (respectively) the operand of some typeid expressions, the operand of sizeof, the operand of noexcept, and the operand of decltype are unevaluated operands. There are no other kinds of unevaluated operand.
Yes, A::a is odr-used.
In C++11, the relevant wording is 3.2p2 [basic.def.odr]:
[...] A variable whose name appears as a potentially-evaluated expression is odr-used unless it is an object that satisfies the requirements for appearing in a constant expression (5.19) and the lvalue-to-rvalue conversion (4.1) is immediately applied. [...]
The name of the variable A::a appears in the declaration int a = A::a[0], in the full-expression A::a[0], which is a potentially-evaluated expression. A::a is:
an object
that satisfies the requirements for appearing in a constant expression
However, the lvalue-to-rvalue conversion is not immediately applied to A::a; it is applied to the expression A::a[0]. Indeed, lvalue-to-rvalue conversion may not apply to an object of array type (4.1p1).
So A::a is odr-used.
Since C++11, the rules have been broadened somewhat. DR712 Are integer constant operands of a conditional-expression "used?" introduces the concept of the set of potential results of an expression, which allows expressions such as x ? S::a : S::b to avoid odr-use. However, while the set of potential results respects such operators as the conditional operator and comma operator, it does not respect indexing or indirection; so A::a is still odr-used in the current drafts for C++14 (n3936 as of date).
[I believe this is a condensed equivalent to Richard Smith's answer, which however does not mention the change since C++11.]
At When is a variable odr-used in C++14? we discuss this issue and possible wording changes to section 3.2 to allow indexing or indirecting an array to avoid odr-use.
No, it is not odr-used.
First, both your array and its elements are of literal type:
[C++11: 3.9/10]: A type is a literal type if it is:
a scalar type; or
a class type (Clause 9) with
a trivial copy constructor,
no non-trivial move constructor,
a trivial destructor,
a trivial default constructor or at least one constexpr constructor other than the copy or move constructor, and
all non-static data members and base classes of literal types; or
an array of literal type.
Now we look up the odr-used rules:
[C++11: 3.2/2]: [..] A variable or non-overloaded function whose name appears as a potentially-evaluated expression is odr-used unless it is an object that satisfies the requirements for appearing in a constant expression (5.19) and the lvalue-to-rvalue conversion (4.1) is immediately applied. [..]
And here we've been referred to the rules on constant expressions, which contain nothing prohibiting your initialiser from being a constant expression; the pertinent passages are:
[C++11: 5.19/2]: A conditional-expression is a constant expression unless it involves one of the following as a potentially evaluated subexpression [..]:
[..]
an lvalue-to-rvalue conversion (4.1) unless it is applied to
a glvalue of integral or enumeration type that refers to a non-volatile const object with a preceding initialization, initialized with a constant expression, or
a glvalue of literal type that refers to a non-volatile object defined with constexpr, or that refers to a sub-object of such an object, or
a glvalue of literal type that refers to a non-volatile temporary object initialized with a constant expression;
[..]
(Don't be put off by the name of the production, "conditional-expression": it is the only production of constant-expression and is thus the one we're looking for.)
Then, thinking about the equivalence of A::a[0] to *(A::a + 0), after the array-to-pointer conversion you have an rvalue:
[C++11: 4.2/1]: An lvalue or rvalue of type "array of N T" or "array of unknown bound of T" can be converted to a prvalue of type "pointer to T". The result is a pointer to the first element of the array.
Your pointer arithmetic is then performed on this rvalue and the result is also an rvalue, used to initialise a. No lvalue-to-rvalue conversion here whatsoever, so still nothing violating "the requirements for appearing in a constant expression".