N4527 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:
— each non-static data member of reference type refers to an entity that is a permitted result of a constant expression, and
— 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(){
int a = 1;
int b[a || 1]{};//ok in gcc 5.1.0, error in clang 3.8.0
static_assert(a || 1,"");//ok in gcc 5.1.0, error in clang 3.8.0
switch(1){
case a || 1://ok in gcc 5.1.0, error in clang 3.8.0
;
}
}
Is a || 1 a constant expression?
N4527 5.20[expr.const]p2
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:
(2.7) — an lvalue-to-rvalue conversion (4.1) unless it is applied to
(2.7.1) — 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
(2.7.2) — a non-volatile glvalue that refers to a subobject of a string literal (2.13.5), or
(2.7.3) — a non-volatile glvalue that refers to a non-volatile object defined with constexpr, or that refers
to a non-mutable sub-object of such an object, or
(2.7.4) — a non-volatile glvalue of literal type that refers to a non-volatile object whose lifetime began
within the evaluation of e;
Is a || 1 a core constant expression?
a is not constant expression(see standard quote below) and therefore:
a || 1
Is not a constant expression either, although we know the expression has to evaluate to true the standard requires left to right evaluation here and I see no exceptions that would allow the compiler to skip the lvalue-to-rvalue conversion of a.
but:
const int a = 1;
Could be used in a constant expression because it fall under the exception from 5.20p2 (emphasis mine):
an lvalue-to-rvalue conversion (4.1) unless it is applied to
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
a non-volatile glvalue that refers to a subobject of a string literal (2.13.5), or
a non-volatile glvalue that refers to a non-volatile object defined with constexpr, or that refers
to a non-mutable sub-object of such an object, or
a non-volatile glvalue of literal type that refers to a non-volatile object whose lifetime began
within the evaluation of e
This rule is also why the original case is not a constant expression since none of the exception apply.
Perhaps gcc is allowing this:
int b[a || 1]{};
as a variable length array as an extension, although it should provide a warning using -pedantic. Although that would not explain the static_assert case, they could be constant folding it but I don't think the as-if rule would allow it to be considered a constant expression.
Update, possible gcc extension
From this bug report RHS of logical operators may render LHS unevaluated in constant-expression this looks like a possible gcc extension:
This compiles without incident, despite using a non-constant object in
a constant-expression:
int i;
static_assert( i || true, "" );
static_assert( ! ( i && false ), "" );
It appears to be assuming that || and && are commutative, but
short-circuiting only works in one direction.
and the final comment says:
I think this is a purposeful language extension, which could use a switch to disable. It would be nice if static_assert were always strict.
This seems like a non-conforming extension that should trigger a warning when using the -pedantic flag similar in vain to issue in Is it a conforming compiler extension to treat non-constexpr standard library functions as constexpr?.
C++11/C++14 Quote
Section 5.20 is section 5.19 in C++14 and C++11, the relevant quote from the draft C++14 standard is:
an lvalue-to-rvalue conversion (4.1) unless it is applied to
a non-volatile glvalue of integral or enumeration type that refers to a non-volatile const object with
a preceding initialization, initialized with a constant expression [ Note: a string literal (2.14.5)
corresponds to an array of such objects. —end note ], or
a non-volatile glvalue that refers to a non-volatile object defined with constexpr, or that refers
to a non-mutable sub-object of such an object, or
a non-volatile glvalue of literal type that refers to a non-volatile object whose lifetime began
within the evaluation of e;
and for the draft C++11 standard is:
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 whose lifetime has not
ended, initialized with a constant expression;
Repeating your quote:
(2.7) — an lvalue-to-rvalue conversion (4.1) unless it is applied to
(2.7.1) — 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
a involves an lvalue-to-rvalue conversion. Since a is not a const object, that means a is not a core constant expression; therefore a || 1 is not one either.
However if your code were:
const int a = 1;
then a || 1 would be a core constant expression.
If the compiler checks the entire assignment chain, then it can determine that "a || 1" is a constant expression. However, since a is a variable, unless the compiler checks that a has not been assigned, it has no way of knowing that "a || 1" is a constant expression.
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.
I have this code:
const float foo = 5.0F;
static_assert(foo > 0.0F, "foo must be greater than 0.");
But in visual-studio-2010 I get the error:
error C2057: expected constant expression
I'm actually doing this correctly and visual-studio-2010 just hasn't properly implemented static_assert, right? In visual-studio-2017 it works as intended.
There has been some commentary of the differences between const and constexpr. I understand this difference, however many compilers support this use of static_assert so I'll ask again, is this legal code or not? I'm not as concerned about which compiler supports it, I'm concerned about whether it's defined under the C++ standard.
foo > 0.0F is not a core constant expression:
An expression e is a core constant expression unless the evaluation of e, following the rules of the abstract machine, would evaluate one
of the following expressions:
...
(2.7) an lvalue-to-rvalue conversion unless it is applied to
(2.7.1) 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
(2.7.2) a non-volatile glvalue that refers to a subobject of a string
literal, or
(2.7.3) 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
(2.7.4) a non-volatile glvalue of literal type that refers to a
non-volatile object whose lifetime began within the evaluation of e;
foo is of floating-point type, for foo > 0.0F an lvalue-to-rvalue conversion on foo is required, which doesn't match the above conditions, then foo > 0.0F is not considered as constant expression:
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
On the other hand, if declare foo as integral type the code would be fine. LIVE (Usingconstexpr instead of const works too. LIVE)
Here, at http://eel.is/c++draft/expr.const#2.7 it can be read
3 -
A variable is usable in constant expressions after its initializing declaration is encountered if it is a constexpr variable, or it is of
reference type or of const-qualified integral or enumeration type, and
its initializer is a constant initializer.
Well, the case is that I cannot figure myself an example for the case where the variable is of reference type.
In
int main()
{
static const double& ds = 0.5;
constexpr double cds = ds;
}
Visual Studio 16.1.2 complains:
expression must have a constant value.
the value of variable (declared at line 11) cannot be used as a constant
But, why?
Your code is not legal in C++17 because it contains a constexpr variable whose initialization requests lvalue-to-rvalue conversion and it is not one of the listed exceptions: (C+17 [expr.const]/2.7)
an lvalue-to-rvalue conversion (7.1) unless it is applied to
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
a non-volatile glvalue that refers to a subobject of a string literal, or
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
a non-volatile glvalue of literal type that refers to a non-volatile object whose lifetime began within the evaluation of e;
You should find the code compiles if you change to an integer type instead of double.
The text you quote is from a draft and as such, may or may not eventually form part of some standard.
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.
I have this code:
const float foo = 5.0F;
static_assert(foo > 0.0F, "foo must be greater than 0.");
But in visual-studio-2010 I get the error:
error C2057: expected constant expression
I'm actually doing this correctly and visual-studio-2010 just hasn't properly implemented static_assert, right? In visual-studio-2017 it works as intended.
There has been some commentary of the differences between const and constexpr. I understand this difference, however many compilers support this use of static_assert so I'll ask again, is this legal code or not? I'm not as concerned about which compiler supports it, I'm concerned about whether it's defined under the C++ standard.
foo > 0.0F is not a core constant expression:
An expression e is a core constant expression unless the evaluation of e, following the rules of the abstract machine, would evaluate one
of the following expressions:
...
(2.7) an lvalue-to-rvalue conversion unless it is applied to
(2.7.1) 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
(2.7.2) a non-volatile glvalue that refers to a subobject of a string
literal, or
(2.7.3) 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
(2.7.4) a non-volatile glvalue of literal type that refers to a
non-volatile object whose lifetime began within the evaluation of e;
foo is of floating-point type, for foo > 0.0F an lvalue-to-rvalue conversion on foo is required, which doesn't match the above conditions, then foo > 0.0F is not considered as constant expression:
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
On the other hand, if declare foo as integral type the code would be fine. LIVE (Usingconstexpr instead of const works too. LIVE)