Constant Expressions and Compile-Time Evaluation

Most of the values a program uses are not known until it runs. A user types a number, a file is read, or a calculation depends on earlier results. Some values, however, are fixed by the language and its types themselves. The largest value an int can hold is one example. C++ lets certain functions take part in this kind of early work, so that their results can be used while the compiler is still processing the source code.

C++ offers two keywords for working with values that should not change: const and constexpr. Both are often described as ways to make something constant, which makes them easy to confuse. They answer different questions, though. const is about a promise that the program makes not to change a value. constexpr is about when a value can be computed, specifically whether it can be evaluated at compile time. The difference between these two questions is the key to using either keyword correctly.

const means roughly 'I promise not to change this value,' and the compiler enforces that promise. It is used primarily to specify interfaces. When data is passed to a function, a const qualifier lets the programmer say that the function will not modify it, so the data can be passed without fear of it being changed.

The important detail is what const does not require. A const value does not have to be known at compile time. A line such as const double s1 = sum(v); is acceptable even though sum(v) is computed while the program runs. The const still applies to s1 afterward. This is the central point of this section: const constrains how a value may be used after it exists, not when that value must be computed.

constexpr is used primarily to specify constants. The source gives two reasons for this: it allows data to be placed in read-only memory, where it is unlikely to be corrupted, and it supports performance. A constexpr declaration therefore makes a stronger demand than const does. The initializer must be computable by the compiler before the program runs, and every value the initializer depends on must itself be known at that stage.

A value can be const without being constexpr. This is why const alone is not enough when you need a value fixed at compile time, and why constexpr is not needed for every value you promise not to change. The two keywords are related, but they make different demands.

The examples in this section use three kinds of values: a named constant declared with const, an ordinary variable that is not declared constant, and a vector of doubles that is also not a constant. The question for every line is the same: does the compiler have enough information to evaluate this initialization before the program runs?

When you are unsure whether a constexpr initialization will compile, apply the rule from the source directly. Ask whether every value that the initializer depends on is one the compiler can evaluate at compile time. The flowchart below captures that check for a constexpr initializer.

Applying this check to max1 gives a yes, since dmv is a named constant. Applying it to max2 gives a no, since var is an ordinary variable. The question is about the dependencies of the initializer, not about how the expression looks on the page.

The same constexpr function can serve two roles. In a compile-time context, its arguments must be known during compilation, and its result becomes part of the compiled program's constant information. In a run-time context, the same function can be called with values that only become available while the program executes. The function body is the same in both cases. What changes is when the inputs are known, and therefore when the call can be completed.

The source identifies numeric_limits<int>::max() as a constexpr function. Calling it returns the largest value an int can represent. Because that call is a constexpr function, its result can be used where the language requires a value that is already known during compilation. Follow the path from source text to compile-time value in the diagram below.

Notice the two roles in the example. The first line uses the call to set a constant value. The static_assert uses the same call inside a condition that must be settled before the program runs. The source describes an assert of this kind as working for the same reason: the tested value comes from a constexpr function.

numeric_limits provides information about the limits of numeric types. It is a fact about a type, not a computation the program performs on its data. Knowing the limit of int is valuable in itself, for example when a program needs to check that a value stays within range.

The constexpr nature of the call is a separate idea. It is the mechanism that lets that fact take part in compile-time checks, such as the static_assert above. Keeping these two ideas apart makes it easier to reason about why a particular numeric_limits call can appear in a constant context while another function call cannot.