constexpr vs. static const: Which one to prefer?
Solution 1
As long as we are talking about declaring compile-time constants of scalar integer or enum types, there's absolutely no difference between using const
(static const
in class scope) or constexpr
.
Note that compilers are required to support static const int
objects (declared with constant initializers) in constant expressions, meaning that they have no choice but to treat such objects as compile-time constants. Additionally, as long as such objects remain odr-unused, they require no definition, which further demonstrates that they won't be used as run-time values.
Also, rules of constant initialization prevent local static const int
objects from being initialized dynamically, meaning that there's no performance penalty for declaring such objects locally. Moreover, immunity of integral static
objects to ordering problems of static initialization is a very important feature of the language.
constexpr
is an extension and generalization of the concept that was originally implemented in C++ through const
with a constant initializer. For integer types constexpr
does not offer anything extra over what const
already did. constexpr
simply performs an early check of the "constness" of initializer. However, one might say that constexpr
is a feature designed specifically for that purpose so it fits better stylistically.
Solution 2
constexpr
variable is guaranteed to have a value available at compile time. whereas static const
members or const
variable could either mean a compile time value or a runtime value. Typing constexpr
express your intent of a compile time value in a much more explicit way than const
.
One more thing, in C++17, constexpr
static data member variables will be inline too. That means you can omit the out of line definition of static constexpr
variables, but not static const
.
As a demand in the comment section, here's a more detailed explanation about static const
in function scope.
A static const
variable at function scope is pretty much the same, but instead of having a automatic storage duration, it has static storage duration. That mean it's in some way the equivalent of declaring the variable as global, but only accessible in the function.
It is true that a static
variable is initialize at the first call of the function, but since it's const
too, the compiler will try to inline the value and optimize out the variable completely. So in a function, if the value is known at compile time for this particular variable, then the compiler will most likely optimize it out.
However, if the value isn't known at compile time for a static const
at function scope, it might silently make your function (a very small bit) slower, since it has to initialize the value at runtime the first time the function is called. Plus, it has to check if the value is initialized each time the function is called.
That's the advantage of a constexpr
variable. If the value isn't known at compile time, it's a compilation error, not a slower function. Then if you have no way of determine the value of your variable at compile time, then the compiler will tell you about it and you can do something about it.
Mr.C64
Updated on July 05, 2022Comments
-
Mr.C64 almost 2 years
For defining compile-time constants of integral types like the following (at function and class scope), which syntax is best?
static const int kMagic = 64; // (1) constexpr int kMagic = 64; // (2)
(1)
works also for C++98/03 compilers, instead(2)
requires at least C++11. Are there any other differences between the two? Should one or the other be preferred in modern C++ code, and why?
EDIT
I tried this sample code with Godbolt's CE:
int main() { #define USE_STATIC_CONST #ifdef USE_STATIC_CONST static const int kOk = 0; static const int kError = 1; #else constexpr int kOk = 0; constexpr int kError = 1; #endif return kOk; }
and for the
static const
case this is the generated assembly by GCC 6.2:main::kOk: .zero 4 main::kError: .long 1 main: push rbp mov rbp, rsp mov eax, 0 pop rbp ret
On the other hand, for
constexpr
it's:main: push rbp mov rbp, rsp mov DWORD PTR [rbp-4], 0 mov DWORD PTR [rbp-8], 1 mov eax, 0 pop rbp ret
Although at
-O3
in both cases I get the same (optimized) assembly:main: xor eax, eax ret
EDIT #2
I tried this simple code (live on Ideone):
#include <iostream> using namespace std; int main() { const int k1 = 10; constexpr int k2 = 2*k1; cout << k2 << '\n'; return 0; }
which shows that
const int k1
is evaluated at compile-time, as it's used to calculateconstexpr int k2
.However, there seems to be a different behavior for
double
s. I've created a separate question for that here. -
Mr.C64 over 7 yearsI'm not asking "constexpr" vs. "const", but vs. static const. Isn't "static const" compile-time like "constexpr"?
-
AndyG over 7 years@NathanOliver: Good point. If it's a
static const
class member, however, I think it's usable in a constant expression, though. -
Mr.C64 over 7 years@NathanOliver: Very good point. Please add that as answer to 1) get better answer visibility and 2) get deserved points (I'll upvote).
-
NathanOliver over 7 years@AndyG Yes as a class member it is usable as it has to be defined at compile time.
-
Nawaz over 7 years@Mr.C64: The keyword
static
has nothing to do with compile-time const-ness or computability. At namespace-level, it affects the linkage; in the class-scope, it makes the member common to all instances; and in function-scope, it makes the variable to persist between calls. -
Mr.C64 over 7 years@Nawaz: I know that about
static
, but I thought thatstatic
could be used as a hint for the C++ compiler to optimize considering thestatic const
variable as a compile-time constant. At least, before C++11'sconstexpr
,static const
was used (as an approximation?) for compile-time constants. -
Nawaz over 7 years@Mr.C64: The point is,
static const
could be compile-time constant, does not mean it has to be. -
Guillaume Racicot over 7 years@Mr.C64 See my edit, I added a more detailed explanation about static const.
-
The Vee over 7 yearsAd the "little bit slower" part: not only because it has to initialize the value the first time the function is called, but it also has to determine at run time at every call whether that is the first time it is called. This is not trivial, see godbolt.org/g/wBejUj
-
T.C. over 7 years"
static constexpr
variables will be inline too" is misleading.constexpr
impliesinline
only for static data members (and functions), not all variables. -
AnT stands with Russia over 7 years@Guillaume Racicot:
static const int
member of a class initialized with constant expression is guaranteed to act as an Integral Constant Expression, i.e. be a compile-time constant. It does not require a deparate definition as long as it is not odr-used anywhere in the code. As long as we are talking about rvalue contexts, there's no difference between aconstexpr int
constant andstatic const int
constant. (The same applies toconst int
objects in local scope.) The difference is purely stylistic. -
AnT stands with Russia over 7 yearsAlso, C++ language prohibits dynamic initialization for local
static
objects of scalar types initialized with constant expressions, meaning that such object cannot make your function slower. -
Guillaume Racicot over 7 years@AnT static constexpr data members are different in c++17. They can be odr used without an out of line definition since they are unlined by default. Whereas static const must have an out of line definition to be odr used.
-
AnT stands with Russia over 7 years@Guillaume Racicot: Yes, but that's a different topic. It applies to "lvalue uses" of such objects. Meanwhile, the topic we are discussing appears to be concerned with the matter of defining compile-time constants.
-
AnT stands with Russia over 7 years@The Vee: The compilers are not allowed to do that if the static object has scalar type and is initialized with constant expressions. Constant initialization (as opposed to dynamic initialization) is mandated by the language in such cases.
-
The Vee over 7 years@AnT Absolutely. But my comment was an extension to this particular paragraph in the answer: "However, if the value isn't known at compile time for a static const at function scope"...
-
Mr.C64 over 7 yearsThanks for your answer. BTW It seems that
double
gets a different treatment thanint
regarding initializingconstexpr
withconst
(but not in MSVC). -
AnT stands with Russia over 7 years@Mr.C64: Yes, it is. I was wrong to use the term "scalar" types in my answer. The full "compile time constant" treatment is only applied to
const
objects of integral or enum types. -
Mr.C64 over 7 yearsThanks. Another reason to prefer
constexpr
. -
aschepler almost 7 years"rules of constant initialization prevent local
static const int
objects from being initialized dynamically" - you mean IF the initializer is a constant expression, right? -
Vegeta over 3 yearsIt's not really exactly the same is it? If you make a variable constexpr it will be initialized on compile time, so that will increase compilation time, but will make run time faster?