> ## Documentation Index
> Fetch the complete documentation index at: https://docs.syntblaze.com/llms.txt
> Use this file to discover all available pages before exploring further.
# C++ Constexpr Function
A `constexpr` function is a function explicitly declared with the `constexpr` specifier, indicating to the compiler that its return value can be evaluated at compile time. When invoked with arguments that are constant expressions, the compiler executes the function during the compilation phase, substituting the function call with the computed result. If invoked with runtime values, or if the context does not require a constant expression, it degrades gracefully to behave as a standard runtime function.
```cpp theme={"dark"}
constexpr int calculate_factorial(int n) {
int result = 1;
for (int i = 1; i <= n; ++i) {
result *= i;
}
return result;
}
```
## Core Mechanics
* **Dual Execution Context:** A `constexpr` function does not guarantee compile-time execution. It only indicates that compile-time execution is requested and potentially possible. To force compile-time evaluation, the result must be assigned to a `constexpr` variable or used in a context that requires a compile-time constant (e.g., template arguments, array bounds). To strictly guarantee compile-time execution without relying on the calling context, C++20 introduced the `consteval` specifier (immediate functions).
* **Implicit Inline:** Every `constexpr` function is implicitly an `inline` function. Consequently, its definition must be visible in the translation unit where it is called.
* **Type Flexibility (C++23):** As of C++23, there are no restrictions on the return type or parameter types of a `constexpr` function declaration. Prior to C++23, these were strictly required to be Literal Types (e.g., scalar types, references, or classes with a trivial destructor and at least one `constexpr` constructor).
* **Unconditional Runtime Degradation (C++23):** As of C++23, a `constexpr` function is perfectly well-formed even if no possible invocation could ever result in a constant expression (it simply degrades to a runtime function). Prior to C++23, if a function lacked at least one valid compile-time execution path, the program was ill-formed, no diagnostic required (IFNDR).
## Evolution of Definition Constraints
The rules governing what can legally exist inside the **definition** of a `constexpr` function have been progressively relaxed across C++ standards:
* **C++11:** The function body must consist of exactly one `return` statement. No local variable declarations, loops, or conditional statements (`if`/`switch`) are permitted.
* **C++14:** Permits multiple `return` statements, initialized local variables, mutation of local variables, and control flow structures (`if`, `switch`, `for`, `while`).
* **C++20:** Permits transient dynamic memory allocation (`new` and `delete`, provided memory is allocated and deallocated within the same compile-time evaluation context), `try` and `catch` blocks, virtual function calls, changing the active member of a `union`, and **uninitialized variables**.
* **C++23:** Permits `goto` statements, labels, `static` variables, and `thread_local` variables. It fully permits the declaration and use of `static constexpr` variables inside the function. Crucially, it removes the requirement that parameter/return types must be Literal Types and removes the IFNDR rule for functions lacking a valid compile-time execution path.
## Constant Evaluation Restrictions (Execution Path)
Modern C++ strictly separates function *definition* rules from *evaluation* rules. While C++20 and C++23 allow constructs like uninitialized variables, non-literal types, or `goto` statements to exist within the function's definition, the **execution path** actually taken during compile-time constant evaluation **cannot**:
1. **Call non-`constexpr` functions.**
2. **Read or modify mutable state outside its scope.** It *can* read variables outside its scope, but only if those variables are themselves usable in constant expressions (e.g., reading a global `constexpr` variable or a `const` integral variable is permitted).
3. **Evaluate a `goto` statement or label.** They may exist in the function, but the compile-time control flow must not reach them.
4. **Evaluate the initialization of a `static` or `thread_local` variable**, unless that variable is declared `static constexpr`.
5. **Read from an uninitialized variable.** The variable may be declared without initialization, but it must be assigned a value before it is read.
6. **Perform a `reinterpret_cast` or cast from `void*`.**
7. **Evaluate a `throw` expression.** (`try`/`catch` blocks can exist, but throwing an exception halts constant evaluation).
8. **Evaluate operations on non-literal types.** Even though C++23 allows non-literal types in the signature, attempting to evaluate them at compile time will fail.
## Syntax Visualization: Compile-Time vs Runtime vs Consteval
```cpp theme={"dark"}
constexpr int square(int x) {
return x * x;
}
// C++20: Guarantees compile-time execution
consteval int strict_square(int x) {
return x * x;
}
int main() {
// Evaluated at compile-time.
// The compiler replaces this with `constexpr int a = 25;`
constexpr int a = square(5);
// Evaluated at runtime.
// The compiler generates standard assembly for a function call.
int dynamic_val = 10;
int b = square(dynamic_val);
// Evaluated at compile-time.
// strict_square(dynamic_val) would result in a compilation error.
int c = strict_square(5);
return 0;
}
```
Tired of Poor C++ Skills? Fix That With Deep Grasping!
Learn More
