const vs constexpr on variables
Solution 1
I believe there is a difference. Let's rename them so that we can talk about them more easily:
const double PI1 = 3.141592653589793;
constexpr double PI2 = 3.141592653589793;
Both PI1
and PI2
are constant, meaning you can not modify them. However only PI2
is a compile-time constant. It shall be initialized at compile time. PI1
may be initialized at compile time or run time. Furthermore, only PI2
can be used in a context that requires a compile-time constant. For example:
constexpr double PI3 = PI1; // error
but:
constexpr double PI3 = PI2; // ok
and:
static_assert(PI1 == 3.141592653589793, ""); // error
but:
static_assert(PI2 == 3.141592653589793, ""); // ok
As to which you should use? Use whichever meets your needs. Do you want to ensure that you have a compile time constant that can be used in contexts where a compile-time constant is required? Do you want to be able to initialize it with a computation done at run time? Etc.
Solution 2
No difference here, but it matters when you have a type that has a constructor.
struct S {
constexpr S(int);
};
const S s0(0);
constexpr S s1(1);
s0
is a constant, but it does not promise to be initialized at compile-time. s1
is marked constexpr
, so it is a constant and, because S
's constructor is also marked constexpr
, it will be initialized at compile-time.
Mostly this matters when initialization at runtime would be time-consuming and you want to push that work off onto the compiler, where it's also time-consuming, but doesn't slow down execution time of the compiled program
Solution 3
constexpr indicates a value that's constant and known during compilation.
const indicates a value that's only constant; it's not compulsory to know during compilation.
int sz;
constexpr auto arraySize1 = sz; // error! sz's value unknown at compilation
std::array<int, sz> data1; // error! same problem
constexpr auto arraySize2 = 10; // fine, 10 is a compile-time constant
std::array<int, arraySize2> data2; // fine, arraySize2 is constexpr
Note that const doesn’t offer the same guarantee as constexpr, because const objects need not be initialized with values known during compilation.
int sz;
const auto arraySize = sz; // fine, arraySize is const copy of sz
std::array<int, arraySize> data; // error! arraySize's value unknown at compilation
All constexpr objects are const, but not all const objects are constexpr.
If you want compilers to guarantee that a variable has a value that can be used in contexts requiring compile-time constants, the tool to reach for is constexpr, not const.
Solution 4
A constexpr symbolic constant must be given a value that is known at compile time. For example:
constexpr int max = 100;
void use(int n)
{
constexpr int c1 = max+7; // OK: c1 is 107
constexpr int c2 = n+7; // Error: we don’t know the value of c2
// ...
}
To handle cases where the value of a “variable” that is initialized with a value that is not known at compile time but never changes after initialization, C++ offers a second form of constant (a const). For Example:
constexpr int max = 100;
void use(int n)
{
constexpr int c1 = max+7; // OK: c1 is 107
const int c2 = n+7; // OK, but don’t try to change the value of c2
// ...
c2 = 7; // error: c2 is a const
}
Such “const variables” are very common for two reasons:
- C++98 did not have constexpr, so people used const.
- List item “Variables” that are not constant expressions (their value is not known at compile time) but do not change values after initialization are in themselves widely useful.
Reference : "Programming: Principles and Practice Using C++" by Stroustrup
Comments
-
fredoverflow almost 2 years
Is there a difference between the following definitions?
const double PI = 3.141592653589793; constexpr double PI = 3.141592653589793;
If not, which style is preferred in C++11?
-
Matthieu M. over 11 yearsI agree: the conclusion I arrived to was that
constexpr
would lead to a diagnosis should the compile-time computation of the object be impossible. What is less clear is whether a function expecting a constant parameter could be executed at compile-time should the parameter be declared asconst
and not asconstexpr
: ie, wouldconstexpr int foo(S)
be executed at compile-time if I callfoo(s0)
? -
fredoverflow over 11 yearsAre you sure? Because
const int N = 10; char a[N];
works, and array bounds must be compile-time constants. -
Howard Hinnant over 11 yearsI am sure as far as the examples I wrote go (tested each of them before posting). However my compiler does let me convert
PI1
to a compile-time integral constant for use in an array, but not for use as a non-type integral template parameter. So the compile-time convertibility ofPI1
to an integral type seems a little hit & miss to me. -
rici over 11 years@HowardHinnant: The rules for lvalue-to-rvalue conversion are subtly different for integral and non-integral types: (5.19(2))
a glvalue of integral or enumeration type that refers to a non-volatile const object with a preceding initialization, initialized with a constant expression
vs.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
. That's not the same as implicit conversion toint
, which has different rules. -
Damon over 11 years@FredOverflow: Non-const array indices have "worked" for about a decade (there's for example a g++ extension for that), but that does not mean it's strictly legal C++ (though some more recent C or C++ standard made it legal, I forgot which one). As for differences in compiletime constants, template parameters and use as
enum
initializer are the only two notable differences betweenconst
andconstexpr
(and neither works fordouble
anyway). -
rici over 11 years@MatthieuM: I doubt whether
foo(s0)
would be executed at compile-time, but you never know: a compiler is allowed to do such optimizations. Certainly, neither gcc 4.7.2 nor clang 3.2 allow me to compileconstexpr a = foo(s0);
-
Matthieu M. over 11 years@Damon: They do not work in Clang though. However
size_t const int N = 10; char a[N];
works in C++, but not in C (where you need to#define N 10
). -
Luc Danton over 11 yearsParagraph 4 of 5.19 Constant expressions [expr.const] is also a (non-normative) note that famously outlines that an implementation is allowed to do floating-point arithmetic differently (e.g. with respect to accuracy) at compile-time than at runtime. So
1 / PI1
and1 / PI2
may yield different results. I don't think this technicality is quite as important as the advice in this answer however. -
NuPagadi about 10 yearsBut it
constexpr double PI3 = PI1;
works correctly for me. (MSVS2013 CTP). What am I doing wrong? -
Howard Hinnant about 10 years@user2198121: You're not doing anything wrong. Just know that you're taking advantage of a compiler extension. The code is safe, but not portable. On porting any difference will be found at compile-time, not run-time.
-
void.pointer over 9 yearsWill
PI2
have a runtime memory address? If so, I wonder why, since in theory all constant expressions should be inlined (no need to keep a variable around); especially if this is all done by the compiler. The final object code should not have any knowledge of that variable. -
Howard Hinnant over 9 years
PI2
will have internal linkage, meaning it will be local to a translation unit. It will theoretically have an address. However if that address is never used, it need not exist. IfPI2
is ever passed by reference, the compiler will need to store it somewhere for the reference to refer to (unless that function is inlined and the compiler is able to optimize away the reference). -
Super Cat almost 9 yearsA note for anyone confused by
constexpr double PI3 = PI1; // error
- The error is compiler specific. For instance, some compilers will go ahead see thatPI1
itself is a literal, and therefore resolve that that is legal. Others, due to the nature ofconst
, won't perform this check because it may or may not be a literal. -
yapkm01 over 8 years@HowardHinnant i don't get any errors on constexpr double PI3 = PI1; Any idea?
-
Howard Hinnant over 8 years@yapkm01: Probably just a compiler bug. Here is a good place to experiment with various compilers: melpon.org/wandbox/permlink/4blONXNuKtzFkpMO
-
Admin about 8 yearsThank you for your helpful answer! Had a problem with static_assert, now it's all clear to me. I wonder why it's typed with mistake in Straustup book...(C++ 4th edition)
-
Aky almost 8 yearsPerhaps you should have mentioned that the text in your answer is taken verbatim from "Programming: Principles and Practice Using C++" by Stroustrup
-
Mayukh Sarkar almost 8 yearsI liked your explanation a lot..can you please comment more on Where are the cases we may need to use compile time constants in real life scenarios.
-
underscore_d over 7 years@MayukhSarkar Simply Google C++ why constexpr, e.g. stackoverflow.com/questions/4748083/…
-
Shelby Oldfield over 6 yearsI could be wrong, but can't the compiler choose to make a variable a constexpr on its own in certain contexts? So, for example, when you have a const literal like that, it can probably decide it is safe to make it a constexpr, therefore allowing you to use it for array size, static_assert,
constexpr PI3 = PI1;
, template parameters, etc... -
Florian about 5 yearsit may be obvious: but what about taking references from these PIs (pun intended)? should be possible from
PI1
impossible fromPI2
-
curiousguy over 4 years@Damon "but that does not mean it's strictly legal C++" No, actually
const int k = 1;
has always been a compile time constant in C++. "(there's for example a g++ extension for that)," Although there are extensions re: variable size arrays.