5.5 — Constant expressions

In lesson 1.10 -- Introduction to expressions, we introduced expressions. By default, expressions evaluate at runtime. And in some cases, they must do so:

std::cin >> x;
std::cout << 5 << '\n';

Because input and output can’t be performed at compile time, the expressions above are required to evaluate at runtime.

In prior lesson 5.4 -- The as-if rule and compile-time optimization, we discussed the as-if rule, and how the compiler can optimize programs by shifting work from runtime to compile-time. Under the as-if rule, the compiler may choose whether to evaluate certain expressions at runtime or compile-time:

const double x { 1.2 };
const double y { 3.4 };
const double z { x + y }; // x + y may evaluate at runtime or compile-time

The expression x + y would normally evaluate at runtime, but since the value of x and y are known at compile-time, the compiler may opt to perform compile-time evaluation instead and initialize z with the compile-time calculated value 4.6.

In a few other cases, the C++ language requires an expression that can be evaluated at compile-time. For example, constexpr variables require an initializer that can be evaluated at compile-time:

int main()
{
    constexpr int x { expr }; // Because variable x is constexpr, expr must be evaluatable at compile-time
}

In cases where a constant expression is required but one is not provided, the compiler will error and halt compilation.

We’ll discuss constexpr variables in the next lesson (5.6 -- Constexpr variables), when we cover constexpr variables.

In this lesson, we’ll explore more of C++’s capabilities around compile-time evaluation, and look at how C++ differentiates this last case from the prior two cases.

The benefits of compile-time programming

While the as-if rule is great for improving performance, it leaves us reliant on the sophistication of the compiler to actually determine what can evaluate at compile-time. This means if there is a section of code we really want to execute at compile-time, it may or may not. That same code compiled on a different platform, or with a different compiler, or using different compilation options, or slightly modified, may produce a different result. Because the as-if rule is applied transparently, we get no feedback from the compiler on what portions of code it decided to evaluate at compile-time, or why. Code we desire to be evaluated at compile-time may not even be eligible (due to a typo or misunderstanding), and we may never know.

To improve upon this situation, the C++ language provides ways for us to be explicit about what parts of code we want to execute at compile-time. The use of language features that result in compile-time evaluation is called compile-time programming.

These features provide a number of important benefits:

• Performance: Compile-time evaluation makes our programs smaller and faster. The more code we can ensure is capable of evaluating at compile-time, the more performance benefit we’ll see.
• Versatility: We can always use such code in places that require a compile-time value. Code that relies on the as-if rule to evaluate at compile-time can’t be used in such places (even if the compiler opts to evaluate that code at compile-time) -- this decision was made so that code that compiles today won’t stop compiling tomorrow, when the compiler decides to optimize differently.
• Predictability: We can have the compiler halt compilation if it determines that code cannot be executed at compile-time (rather than silently opting to have that code evaluate at runtime instead). This allows us to ensure a section of code we really want to execute at compile-time will.
• Safety: We can have the compiler detect certain kinds of errors at compile-time, and halt the build if it encounters them. This is much more effective than trying to detect and gracefully handle those same errors at runtime.
• Safety: Perhaps most importantly, undefined behavior is not allowed at compile-time. If we do something that causes undefined behavior at compile-time, the compiler should halt the build and ask us to fix it. Note that this is a hard problem for compilers, and they may not catch all cases.

Ultimately, compile-time evaluation allows us to write programs that are both more performant and of higher quality (more secure and less buggy)! So while compile-time evaluation does add additional complexity to the language, the benefits can be substantial.

The following C++ features are the most foundational to compile-time programming:

• Constexpr variables (discussed in upcoming lesson 5.6 -- Constexpr variables).
• Constexpr functions (discussed in upcoming lesson F.1 -- Constexpr functions).
• Templates (introduced in lesson 11.6 -- Function templates).
• static_assert (discussed in lesson 9.6 -- Assert and static_assert).

All of these features have one thing in common: they make use of constant expressions.

Constant expressions

Perhaps surprisingly, the C++ standard barely mentions “compile-time” at all. Instead, the standard defines a “constant expression”, which is an expression that must be evaluatable at compile-time, along with rules that determine how the compiler should handle these expressions. Constant expressions form the backbone of compile-time evaluation in C++.

In lesson 1.10 -- Introduction to expressions, we defined an expression as “a non-empty sequence of literals, variables, operators, and function calls”. A constant expression is a non-empty sequence of literals, constant variables, operators, and function calls, all of which must be evaluatable at compile-time. The key difference is that in a constant expression, each part of the expression must be evaluatable at compile-time.

An expression that is not a constant expression is often called a non-constant expression, and may informally be called a runtime expression (as such expressions typically evaluate at runtime).

What can be in a constant expression?

Most commonly, constant expressions contain the following:

• Literals (e.g. ‘5’, ‘1.2’)
• Most operators with constant expression operands (e.g. 3 + 4, 2 * sizeof(int)).
• Const integral variables with a constant expression initializer (e.g. const int x { 5 };). This is a historical exception -- in modern C++, constexpr variables are preferred.
• Constexpr variables (discussed in upcoming lesson 5.6 -- Constexpr variables).
• Constexpr function calls with constant expression arguments (see F.1 -- Constexpr functions).

Examples of constant and non-constant expressions

In the following program, we look some expression statements and indicate whether each expression is a constant expressions or runtime expression:

#include <iostream>

int getNumber()
{
    std::cout << "Enter a number: ";
    int y{};
    std::cin >> y; // can only execute at runtime

    return y;      // return value only known at runtime
}

int five()
{
    return 5;      // return value known at compile-time
}

int main()
{
    // Literals can be used in constant expressions
    5;                           // constant expression            
    1.2;                         // constant expression
    "Hello world!";              // constant expression

    // Most operators that have constant expression operands can be used in constant expressions
    5 + 6;                       // constant expression
    1.2 * 3.4;                   // constant expression
    8 - 5.6;                     // constant expression (even though operands have different types)
    sizeof(int) + 1;             // constant expression (sizeof can be determined at compile-time)

    // Calls to non-constexpr functions can only be used in runtime expressions
    getNumber();                 // runtime expression
    five();                      // runtime expression (even though return value is constant expression)

    // Operators without constant expression operands can only be used in runtime expressions
    std::cout << 5;              // runtime expression (std::cout isn't a constant expression operand)

    return 0;
}

In the following snippet, we define a bunch of variables, and indicate whether they can be used in constant expressions:

    // Const integral variables with a constant expression initializer can be used in constant expressions:
    const int a { 5 };           // a is usable in constant expressions
    const int b { a };           // b is usable in constant expressions (a is a constant expression per the prior statement)
    const long c { a + 2 };      // c is usable in constant expressions (operator+ has constant expression operands)

    // Other variables cannot be used in constant expressions (even when they have a constant expression initializer):
    int d { 5 };                 // d is not usable in constant expressions (d is non-const)
    const int e { d };           // e is not usable in constant expressions (initializer is not a constant expression)
    const double f { 1.2 };      // f is not usable in constant expressions (not a const integral variable)

When constant expressions are evaluated at compile-time

Since constant expressions are always capable of being evaluated at compile-time, you may have assumed that constant expressions will always be evaluated at compile-time. Counterintuitively, this is not the case.

The compiler is only required to evaluate constant expressions at compile-time in contexts that require a constant expression.

In contexts that do not require a constant expression, the compiler may choose whether to evaluate a constant expression at compile-time or at runtime.

const int x { 3 + 4 }; // constant expression 3 + 4 must be evaluated at compile-time
int y { 3 + 4 };       // constant expression 3 + 4 may be evaluated at compile-time or runtime

Variable x has type const int and a constant expression initializer, x is usable in a constant expression. Its initializer must be evaluated at compile-time (otherwise the value of x wouldn’t be known at compile-time, and x wouldn’t be usable in a constant expression). On the other hand, variable y is non-const, so y is not usable in a constant expression. Even though its initializer is a constant expression, the compiler can decide to evaluate the initializer at compile-time or runtime.

Even when not required to do so, modern compilers will usually evaluate a constant expression at compile-time when optimizations are enabled.

Why compile-time expressions must be constant Optional

You may be wondering why compile-time expressions can only contain constant objects (and operators and functions that can evaluate at compile-time to constants).

Consider the following program:

#include <iostream>

int main()
{
    int x { 5 };
    // x is known to the compiler at this point

    std::cin >> x; // read in value of x from user
    // x is no longer known to the compiler

    return 0;
}

To start, x is initialized with value 5. The value of x is known to the compiler at this point. But then x is assigned a value from the user. The compiler can’t know what value the user will provide at compile-time, so beyond this point, the value of x is not known to the compiler. Thus, the expression x is not always evaluatable at compile-time, violating the requirement that such an expression must always be capable of being evaluated at compile-time.

Because constants cannot have their values changed, a constant variable whose initializer is evaluatable at compile-time will always have a value that is known at compile-time. This keeps things simple.

While the language designers could have defined a compile-time expression as one whose values are all currently known at compile-time (rather than an expression that must always be capable of being evaluated at compile-time), this would have added significant complexity to the compiler (as the compiler would now be responsible for determining when every variable could be changed to a value not known at compile-time). Adding a single line of code (such as std::cin >> x) could break the program elsewhere (if x was being used in any context that required a value known at compile-time).

Quiz time

Question #1

For each statement, identify:

• Whether the initializer is a constant expression or non-constant expression.
• Whether the variable is a constant expression or non-constant expression.

a)

    char a { 'q' };

Show Solution

b)

    const int b { 0 };

Show Solution

c)

    const double c { 5.0 };

Show Solution

d)

    const int d { a * 2 }; // a defined as char a { 'q' };

Show Solution

e)

    int e { c + 1.0 }; // c defined as const double c { 5.0 };

Show Solution

f)

    const int f { d * 2 }; // d defined as const int d { 0 };

Show Solution

g)

    const int g { getNumber() }; // getNumber returns an int by value

Show Solution

h)
Extra credit:

    const int h{};

Show Solution