I ran across this seemingly odd behavior. A const at top level can be used for array size declarations, but not when the const is in a class.
Here's a compiler explorer demo for MSVC, CLANG and GCC all producing an error:
expression did not evaluate to a constant
It's not really a constant if it's not const at the top level?
There's some argument to be made because top level constants can often be stored in read-only memory, while constants that are not at top level cannot. But is this behavior correct?
struct A {
const int i{ 3 };
};
int main()
{
const int ii{ 3 };
A a;
int j[a.i]{}; // C2131: expression did not evaluate to a constant
int k[ii]{};
}
Generally, you can use (meaning perform an lvalue-to-rvalue conversion on) objects with lifetime starting outside a constant expression only if they are variables marked constexpr or their subobjects (plus some other special cases, that I don't think are important here, see [expr.const]/4 for details).
That you can use a const int variable at all in a constant expression is already a very specific exception. Essentially const-qualified integral and enumeration type variables are also usable in constant expressions if you could have added constexpr to them (meaning that their initializer expression is a constant expression).
This exception is there I guess purely for historical reasons, since it had been allowed before constexpr was introduced in C++11.
Note that all of this talks about variables and their subobjects. Non-static data members are specifically not variables and the exception doesn't apply to them. With constexpr this is more obvious by not allowing it on the declaration of a non-static data member in the first place.
The historical rule was never extended to encompass other types that could be marked constexpr, so e.g. const A a; will not help although that would actually cause a to be storable in read-only memory the same way a const int would.
If an object is none of the cases mentioned above, then an lvalue-to-rvalue conversion on it in a constant expression is not allowed, since it is assumed that the value of the object is not determined at compile-time.
Now, in theory the compiler could still do some constant folding and determine that even other objects' values are definitively known at compile-time. But I think the intention is that whether or not an expression is a constant expression should be (reasonably) well-defined independently of the implementation and so shouldn't rely on how much analysis the compiler can do.
For example
A a;
A b(a);
is also guaranteed to result in b.i == 3. How far do you want to require a compiler to go back or keep track of evaluations? You would need to make some definitive specification if you want to keep the behavior consistent between compilers. But there is already a simple method to indicate that you want the compiler to keep track of the values. You just have to add constexpr:
constexpr A a;
constexpr A b(a);
Now b.i can be used as array index (whether or not it is const and whether or not it is initialized).
With the current rules, any compiler only needs to evaluate the value of objects at compile-time when it sees a constexpr variable or a const integral/enumeration type variable. For all other variables it doesn't need to keep track of values or backtrack when it sees them used in a context which requires a constant expression.
The additional effect of constexpr implying const on the variable makes sure that its value will also never be changed in a valid program and so the compiler doesn't need worry about updating or invalidating the value after the initial computation either. And whether or not an expression is a constant expression is (mostly) implementation-dependent.
ii is a compile-time constant. Its value is known at compile-time, and cannot be changed at runtime. So, ii can be used for fixed array sizes at compile-time.
A::i is not a compile-time constant. It is a non-static instance member. Its value is not known until runtime. After an A object is constructed and its i member is initialized, the value of i cannot be changed because of the const, but the caller can initialize i with whatever value it wants, eg: A a{123};, and thus different A objects can have different i values. So, i cannot be used for fixed array sizes at compile-time. But, it can be used for dynamic array sizes at runtime, via new[], std::vector, etc.
TL;DR
Your assumption that const always implies compile time constant is incorrect. See examples at the end of this answer for more details on this.
Now the problem in using a.i as the size of an array is that in standard C++, the size of an array must be a compile time constant, but since i is a non-static data member, it requires an object to be used on. In other words, after construction of the class object nonstatic data member i gets initialized, which in turn means that a.i is not a constant expression, hence we get the mentioned error saying:
expression did not evaluate to a constant
To solve this, you can make i be a constexpr static data member, as shown below. This works because using a static data member doesn't require an object instance (and hence no this pointer).
struct A {
constexpr static int i{ 3 };
};
int main()
{
const int ii{ 3 };
A a;
int j[a.i]{}; //Correct now and works in all compilers
int k[ii]{};
}
I just don't get why a regular const works in some places but not others.
Perhaps you assuming that const implies compile time constant which is a wrong assumption. An example might help you understand this better:
int i = 10; //i is not a constant expression
const int size = i; //size is not a constant expression as the initializer is not a constant expression
//------vvvv------>error here as expected since size is not a constant expression
int arr[size]{};
On the other hand if you were to make i const as shown below, the program will work fine.
const int i = 10; //note the const added here so that now i is a constant expression
const int size = i; //size is a constant expression as the initializer is a constant expression
//------vvvv------>NO ERROR HERE as expected since size is a constant expression
int arr[size]{};
Related
Consider code like the following, where the literal some_magic_int (e.g. 3) is given a name just to make a bit clearer what constant it represents:
void f() {
static constexpr int this_variable{some_magic_int};
do_something_with(this_variable);
}
int main() {
// ...
f();
// ...
}
I'm pretty sure constexpr has to be here: some_magic_int is literal, so it never changes, and I'm giving it a name just for clarity, not to give a mean to change it, so it should be at least const; then why not constexpr to have it at compile-time?
But what about static? Is it just unnecessary? Or is it detrimental? If so, why? And also, does it have any observable effect, when paired with constexpr in the declaration of a local variable?
As regards the question to which this is marked as duplicate of, it is about static constexpr int x [] = {}, and not static constexpr int x {}. This highlights at least one difference between that case (attributes applying to x pointer vs attributes applied to *x pointee) and my case (there's no pointer).
Furthermore, once I add constexpr to the specifier of a local variable (where it makes sense, e.g. to a int), I'm saying that variable is compile-time known. Why in the world doesn't that imply that no run-time entity is needed whatsoever?
The standard doesn’t actually ever talk about compile-time anything except to say that types are checked and templates are instantiated before execution. That means that this program must be diagnosed (not “rejected”!) even though the non-constant array length and template argument are never “used” and might plausibly be ignored by an interpreter:
template<int> void f() {}
int main(int argc,char **argv) {
if(false) {
int buf[argc]; // accepted by a common extension
f<argc>();
}
}
Beyond that, the semantics are that every evaluation is part of the ordinary execution of the program and constant folding is just an as-if optimization like any other. (After all, we can optimize argc*2*3*4 even though it contains no non-literal subexpression that could be a constant expression.) For constant expressions, this is largely unobservable because constant evaluation can’t have side effects (which also avoids interactions among constant-initialized non-block variables). It can, however, make a difference via the address of the local variable:
bool introspect(const int *p=nullptr) {
constexpr int x=0;
return p ? p==&x : introspect(&x); // always false
}
That the compiler must make such variables occupy memory if their address escapes is much of the content of the answers to the previously marked duplicate. It therefore makes sense to prefer static except perhaps when the object is large and its address doesn’t matter (e.g., for use as a template argument or via recursion).
I'm reading C++ Templates: The Complete Guide, chapter 23. Metaprogramming. At the end, it describes
the difference in using enumeration values versus static constants in metaprogramming. Consider the following two implementations of calculating Nth power of 3:
Enumeration implementation:
// primary template to compute 3 to the Nth
template<int N>
struct Pow3 {
enum { value = 3 * Pow3<N-1>::value };
};
// full specialization to end the recursion
template<>
struct Pow3<0> {
enum { value = 1 };
};
Static constant implementation:
// primary template to compute 3 to the Nth
template<int N>
struct Pow3 {
static int const value = 3 * Pow3<N-1>::value;
};
// full specialization to end the recursion
template<>
struct Pow3<0> {
static int const value = 1;
};
Right after that it says there is a drawback to the latter version. If we got a function
void foo(int const&); and pass it the result of metaprogram: foo(Pow3<7>::value); the book says:
A compiler must pass the address of Pow3<7>::value, and that forces the
compiler to instantiate and allocate the definition for the static member. As a result,
the computation is no longer limited to a pure “compile-time” effect. Enumeration values aren’t lvalues (i.e., they don’t have an address). So, when we
pass them by reference, no static memory is used. It’s almost exactly as if you passed
the computed value as a literal.
I don't understand their explanation at all to be honest. I thought in the static constant version we evaluate the result at compile time, but the actual referencing happen in run-time because we need to pass the adress. But then I don't see much difference in the former case (enum implementation) because we should have temporary materialization there (prvalue -> xvalue conversion) and since temporary objects also have the adress my thinking process fails. Also it says "no static memory is used" which I don't understand as well since static memory should refer to allocation that happen at compile-time.
Could someone explain this whole thing in greater detail?
(enum implementation) because we should have temporary materialization there (prvalue -> xvalue conversion) and since temporary objects also have the address
they do, but the temporary xvalue only exists for the duration of the function call. It's identical to passing the function an integer literal. So, an addressable object exists temporarily, at runtime, with automatic scope.
Conversely,
... that forces the compiler to instantiate and allocate the definition for the static member. As a result, the computation is no longer limited to a pure “compile-time” effect.
This static const int is an object with static storage duration. There's no temporary materialization necessary, it's an object, it existed when your program started, and you're taking a reference to it.
If you write multiple .cpp files including the header with Pow3, and they all call foo(Pow3<3>):
the enum version will emit something like foo(27) in each translation unit, with three unrelated temporary xvalues
the static version will emit a global object equivalent to const int Pow3<3>::value = 27; and each translation unit will refer to (ie, take a reference to) the same object
I suggest looking at it this way:
There is a difference between a type, an instance of a type, and the values said type can take.
In the first case you are specifying a type (an unnamed enum) with only one possible value value (which is the compile-time constant).
There are no instantiations of the type, so no memory will be used compile-time or runtime.
Every time the code refers to Pow3<N>::value, the compiler will not create an instance of the type but will instead use the constant directly.
In the second case you are instead specifying a variable value of type int, and assigning the compile-time constant to it.
This variable exists, so memory will be used.
Every time the code refers to Pow3<N>::value, the compiler will use said variable.
int a = 5;
const int b = a, c = 4;
int e[a];
int d[b];
int f[c];
The definition of f[c] is valid.
The variable b is also a constant int, but the compiler gave me the error "expression must have a constant value" for the line int d[b]. What are the differences between b and c?
what are the differences between b and c?
c has a compile time constant initialiser, while b does not. A const object with compile time constant initialiser is itself a compile time constant value.
Since I can define an lenth of an arry using a constant ,so why don't this work?
Not just any constant will do. const qualifier implies runtime constness (i.e the value may be determined at runtime but won't change throughout the lifetime of the object). Only compile time constant values can be used as array size.
You are using a non-constant variable to assign value to a constant. Therefore, that variable's value can't be determined compile time. I know you aren't changing a, but the compiler does not think like this.
The compiler diagnostic should really be compile time evaluable constant expression.
Since the original object to which b is assigned is not const, b is not a compile time evaluable constant expression, so compilation will fail as variable length arrays are not supported in standard C++.
The "const" just only means that the variable will not change at run time, and does not mean that its value can be deduced at compiling time.
I guess what you are looking for is "constexpr".
Maybe you can try it out like this:
constexpr int b = 4; // can't be assigned from a!
int d[b];
The "constexpr" instead means a "real const" and the "const" only means "non-changing var", because some historical reason.
It must be mind that a native array in c++ always is fixed-length as #Bathsheba said.
The term "constant" is really ambiguous, and the keyword const is misleading.
const means: "don't allow this object's value won't be changed after initialisation". It does not mean "compile-time constant". Its initial value can (and usually does) still come from runtime sources.
You need a compile-time constant for an array bound.
It is sometimes possible to have an object named foo that is compile-time constant, if it is const and it was initialised from a constant expression, like a literal or a constexpr thing. That's the case for c; it is not the case for b.
I'm just wondering whether sentences like const int N=10 will be executed at compilation time. The reason I'm asking is because that the following code will work.
int main()
{
const int N=10;
int a[N]={};
return 0;
}
But this one wouldn't.
int main()
{
int N=10;
int a[N]={};
return 0;
}
The compiler must generate code "as if" the expression was evaluated at
compile time, but the const itself isn't sufficient for this. In
order to be used as the dimension of an array, for example, expression
N must be a "constant integral expression". A const int is
a constant integral expresion only if it is initialized with a constant
integral expression, and the initialization is visible to the compiler.
(Something like extern int const N;, for example, can't be used in
a constant integral expression.)
To be a constant integral expression, however, the variable must be
const; in your second example, the behavior of the compiler and the
resulting program must be "as if" the expression were only evaluated at
runtime (which means that it cannot be used as the dimension of an
array). In practice, at least with optimization, the compiler likely
would evaluate N at compile time, but it still has to pretend it
can't, and refuse to compile the code.
The compiler will probably evaluate both of the examples you provided at compile time, since even though the int N = 10; isn't const, you're not changing it anywhere and you're only assigning a constant value to it, which means the compiler can optimize this.
I recommend you take a look at the constexpr keyword introduced in C++11, which is exactly about being able to evaluate things at compile time.
Compilers will resolve const variables to literals at compile time (and also const expressions, see constant folding). The reason that the first method works is that compiler knows how much space to allocate (10*sizeof(int)) to a in the first method. In the second method the value of N is not known at compile time, and as such there is no way for the compiler to know how much space to allocate for a. Hope that helps.
This sort of thing is an implementation detail that technically is up to the compiler to choose. It could be different on different platforms.
In practice, with the most common compilers:
const int sometimes is and sometimes isn't baked at compile time. For example, the compiler clearly can't hardcode the value of a below into the object file:
int foo( int x )
{
const int a = x+ 1;
return a * 2;
}
In that function, const means it is only constant within the scope of foo(), but it is still a local stack variable.
On the other hand, const int x = 5 seems to be a literal that is usually resolved at compile time by GCC and MSVC (except sometimes they don't turn it into a literal for reasons unclear). I've seen some other compilers that won't turn it into a literal, and always put const int on the stack like an ordinary local variable.
const static int is different, because its scope is static, which means it outlives the function it is declared in, which means it will never change over the life of the program. Every compiler I've ever worked with has turned const static primitives into compile-time literals.
Objects with constructors, however, will still need to be initialized at runtime; so
class Foo {
Foo() : { CallGlobalFunction(); }
};
const static Foo g_whatever;
cannot be optimized into a literal by the compiler.
class armon
{
static const int maxSize=10;
int array[maxSize];
int count=0;
int* topOfStack=array;
}
Why does maxSize need to be static for it to be used inside array?
It doesn't have to be static, but it must be a constant expression.
C++ Standard § 8.3.4 [dcl.array] (emphasis mine) :
If the constant-expression (5.19) is present, it shall be a converted constant expression of type std::size_t and its value shall be greater than zero
That is, the following is also valid :
constexpr std::size_t Size() { return 10; };
struct Y
{
int array[Size()];
};
Note:
Since the compiler needs to know the size of the class, you cannot do this :
struct Y
{
const int size = 10;
int array[size];
};
Possibly making different instances of Y having different sizes.
Also note that in this context, int array[size] is not a constant expression, because it makes use of this, see the C++ standard section § 5.19 [expr.const] :
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:
— this (5.1.1), except in a constexpr function or a constexpr constructor that is being evaluated as part of e;
(the evaluation of size is really this->size)
There are two aspects to this question
Aspect 1
C++ array is of fixed size, the size of which needs to be known during compile time. If the decision needs to be deferred during runtime, the array expression becomes ill-formed.
Aspect 2
Declaring a member variable as non-static makes it an instance variable, the value of which only exist once the object is instantiated which is done during run-time. A static variable is a class variable, the value of which can be determined during compile time.
Your particular example becomes the classic chicken-egg paradox.
class armon
{
static const int maxSize=10;
int array[maxSize];
}
In order to instantiate your class armon, you need to know its size.
In order to know its size, you need to know the size of individual members. In your particular case, you need to know the size of the array.
In order to know the size of the array, you need to know the value of the dependent variable maxSize.
In order to access the dependent variable maxSize you need to instantiate the class armon.
In order to instantiate your class armon, you need to know its size.
So, your array size dependent variable should be a constant expression, which in your particular case should be a static variable,
It doesn't have to be static, it has to be constant.
When you declare a constant inside a class you will be making a constant for each instance of the class.
Also if your maxSize is just const you would have to intialize it in the constructor initializer list because const maxSize is treated as variable whose value you can't change.
Inside a class const
keyword means "This is a constant during the hole lifetime of this object". Different objects of the same class can have different values for that constant.
But when it is a static constant there will be only one constant for all instances of the class. This means that you have to initialize constants value on the same line where you are defining it.