onstant expressions are tricky. Not all of them have an overt const qualifier. Furthermore, in some cases, a const-qualified variable is just a constant, but not a constant expression. These nuances aren’t just bits of C++ trivia. Rather, they affect the correctness of your code and its performance. The following sections explain the rules of constant integral expressions and show how to avert common mishaps.

How do you know whether an expression is a constant expression? How do you turn a non-constant expression into a constant expression when necessary?

Learn the rules of constant integral expressions.

In the following cases, C++ requires expressions that evaluate to an integral constant expression:

• Array bounds
• Case labels in switch statements
• Bit-fields lengths
• Initializers of enumerators
• Initializers of static data members
• Non-type template arguments, for example, std::bitset<12>.

Contrary to popular conception, not every const variable of an integral type is a constant expression. Consider the following two examples:

struct C{ inline static int getval() {return 4;}};const int MAX=1024;const int MIN=C::getval();

Both MAX and MIN are constants, eg., the program can’t modify their values. However, there is a substantial difference between them. MAX is a constant integral expression. As such, it can be used in an array declaration, case labels, etc.:

char buff[MAX];int sizes=getsizes();switch (sizes){case MAX://.. break;default://.. break;};

What about MIN? Syntactically speaking, it’s a const object with an initializer, just as MAX is. However, if you try to use MIN in places where an integral constant expression is required, your compiler will complain:

struct bitpattern{ signed nibble: MIN;//error: constant expression required unsigned octet: 8; };enum SIZES { S=MIN, //error: constant expression required L=512,  XL=MAX //fine};

In the examples above, a compilation error reveals that MIN isn’t a constant expression. In fact, this is your litmus test: use a constant as an enumerator’s initializer to check whether it’s a valid constant expression.

Compile-time Evaluation
In time critical applications, constants are often chosen for performance reasons i.e., to ensure compile time evaluation of expressions. MIN can be evaluated at compile-time if C::getval() is inlined (every decent compiler will inline the call anyway). Thus, performance-wise, MIN and MAX are equally efficient. However, MIN isn’t an integral constant expression even when C::getval() is inlined since the rules of constant integral expressions are very strict. To qualify as a constant expression, MIN‘s initializer must be one of the following:

• A literal such as 5, 8ul, ‘z’, and false
• An enumerator
• A sizeof expression
• A const static data member initialized with a constant expression

To turn MIN into a constant expression, it’s therefore necessary to replace the C::getval() call with a literal. If you’re concerned about the maintenance problems that hard-coded literals might incur, use a macro instead. Yes, in spite of the fair criticism that macros often attract, they are still useful in some cases, so to speak:

#ifndef C_GETVAL#define C_GETVAL 4#endifconst int MIN=C_GETVAL;

Lo and behold, MIN is now a valid constant expression:

enum SIZES { S=MIN, //now OK L=512,  XL=MAX //fine};

Const Static Data Members
const static data members initialized by a constant expression require special attention. Seemingly, the recursive definition ensures that every const static member whose initializer is a constant expression is also a valid constant expression. This isn’t always true, though. Consider the following counter example:

struct C{ const static int X;};const int Y=C::X;const int C::X=2; //initialized by a constant expression

The static member X is initialized with a literal. The constant Y looks as a constant expression because its initializer C::X is seemingly a constant expression. Well, not quite:

char arr[Y];//error, constant expression required

Actually, neither C::X nor Y is a constant expression! The order of their definitions makes all the difference. The definition of Y uses C::X as the initializer but at this point, C::X hasn’t been defined yet. Consequently, the static initialization of Y is silently replaced with dynamic initialization, which means that Y is no longer a constant expression. Replacing the order of the definitions fixes this mess:

 const int C::X=2;  const int Y=C::X;//Y is now a constant expressionchar arr1[Y], arr2[C::X] //OK

Of course, you can eliminate such mishaps by using in-class initialization:

struct C{ const static int X=2;};

This will guarantee that C::X is a constant expression.

A Programmer’s Best Friend
The standards committee is now working on a mechanism that will allow programmers to use inline functions as initializers of constant expressions (further information on this proposal is available here). However, for the time being, you can use a macro?unsavory as this may seem.

With respect to const static data members of an integral type, the best policy is to use in-class initializers. However, older compilers don’t support in-class initializations. If you’re using such a compiler, always initialize const static members before using them or better yet, replace them with nameless enums.

To check whether your constants qualify as constant expressions, use them as initializers of dummy enumerators. This way your loyal compiler becomes the “constant expression watchdog”, alerting you whenever an expression that should be a constant expression isn’t really so.