101

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 calculate constexpr int k2.

However, there seems to be a different behavior for doubles. I've created a separate question for that here.

Improve this question
18
  • 3
    I prefer the constexpr approach. It is explicit, and strong. Anyway, the other alternative is not same, from linkage point of view as well: If you put const (or static, or both), it makes the variable to have internal linkage. So they're semantically different. Commented Dec 13, 2016 at 16:15
  • 2
    Which one to prefer depends on what you're going to use them for. As @Nawaz says, those two examples do different things, and without any mention of their intended uses it's impossible to decide which is "better". Commented Dec 13, 2016 at 16:17
  • 1
    At what scope do you define them? Commented Dec 13, 2016 at 16:20
  • 3
    The GCC assembly in your edit proves nothing. Commented Dec 13, 2016 at 16:58
  • 3
    @Nawaz: I don't want to prove anything, except that maybe the optimizer is smart enough ;) I was asking (and experimenting) to try to better learn. Commented Dec 13, 2016 at 17:00

2 Answers 2

Reset to default
90

A constexpr variable is guaranteed to have a value available at compile time, whereas static const members or const variables could either mean a compile time value or a runtime value. constexpr expresses 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 of 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 an 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 initialized 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 that and you can do something about it.

Improve this answer
Sign up to request clarification or add additional context in comments.

16 Comments

I'm not asking "constexpr" vs. "const", but vs. static const. Isn't "static const" compile-time like "constexpr"?
@NathanOliver: Good point. If it's a static const class member, however, I think it's usable in a constant expression, though.
@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: The point is, static const could be compile-time constant, does not mean it has to be.
Ad 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
|
47

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.

Improve this answer

5 Comments

Thanks for your answer. BTW It seems that double gets a different treatment than int regarding initializing constexpr with const (but not in MSVC).
@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.
Thanks. Another reason to prefer constexpr.
"rules of constant initialization prevent local static const int objects from being initialized dynamically" - you mean IF the initializer is a constant expression, right?
It'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?

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.