C++ Weekly - Ep 312 - Stop Using `constexpr` (And Use This Instead!)
Why Stack Overflow recommends it
Stack Overflow users link it when explaining why `static constexpr` is preferred over plain `constexpr` for local and global constants, since it guarantees compile-time initialization instead of leaving it to the optimizer.
Recommended by 0 people across 0 different months, 2022 to 2025.
What it is
An 18-minute episode of Jason Turner's C++ Weekly arguing that function-local constants should be declared `static constexpr` rather than plain `constexpr`. He shows compiler output to explain how the extra `static` forces compile-time initialization and avoids per-call work.
What people said
Cites MiCo · 2022-03 · Stack Overflow · on “constexpr function which is shared in multiple modules”
I noticed a strange behavior when I was working with a constexpr function. I reduced the code to a simplified example. Two functions are called from two different translation units (module A and B). #include <iostream> int mod_a(); int mod_b(); int main() { std::cout << "mod_a(): " << mod_a() << "\n"; std::cout << "mod_b(): " << mod_b() << "\n"; std::cout << std::endl; return 0; } The modules look similar. This is mod_a.cpp: constexpr int X = 3; constexpr int Y = 4; #include "common.h" int mod_a() { return get_product(); } Only some internal constants differ. This is mod_b.cpp: constexpr int X = 6; constexpr int Y = 7; #include "common.h" int mod_b() { return get_product(); } Both modules us
Cites alagner · 2022-05 · Stack Overflow · on “May a compiler store function-scoped, non-static, const arrays in constant data and avoid per-call initialization?”
As for C++: have you seen Jason Turner's C++ Weekly [this video] on this? Generally static mixed with constexpr enforces compile-time initialization by the power of the language standard. AFAIR, compiler is allowed to optimize non-static code in a similar manner utilizing as-if, but then it's simply more likely to fail on that.
Cites Anton Krug · 2022-06 · Stack Overflow · on “Difference between constexpr and static constexpr global variable”
If you can, prefer the static constexpr because with the constexpr it depends on the toolchain how likely it will get done on compile-time. Gcc is most aggressive, MSVS least aggressive and clang is in between. Instead of leaving some values up to optimizer to decide it will do it at compile-time be more explicit and force it. Reference: [this video]
Cites cptFracassa · 2023-06 · Stack Overflow · on “function local static constexpr variables”
This question (and the code) is inspired by Jason Turner's C++ Weekly episode: Stop Using constexpr (And Use This Instead!) [this video] Assume the code below ( compiler explorer [LINK] ) My understanding is that when declaring a function local variable as static constexpr I am guaranteed that the variable is initialized only once (static), and without any thread safety overhead normally required if the compiler cannot prove single thread access (due to it being constexpr). But does the c++ standard guarantee this? Is there anywhere in the standard to point to that ensures me that the line static constexpr auto arr = getArr(); will never result in the compiler adding a mutex or other sort of thre
Cites Adam · 2025-12 · Stack Overflow · on “Why can std::string create a constexpr object only if it's a static variable?”
It's usually best practice [this video] for constexpr variables inside functions to also be declared as static. This avoids the possibility that the compiler will decide to extra work each time you call the function. This will also resolve your compile error, while keeping the definitions inside of the function. #include <string> #include <iostream> #include <cstring> constexpr std::string str15 {"123456789012345"}; // This compiles! struct Foo { constexpr Foo() : a(6) { for (int i = 0; i < 8; ++i) buff[i] = 0; } int a; char buff[8]; }; constexpr void func() { static constexpr Foo f{}; // This compiles static constexpr std::string str15 {"123456789012345"}; // Complies when static } int main() {