Are constant C expressions evaluated at compile time or at runtime?

Question

If I write a #define that performs an operation using other preprocessor constants, is the final value computed each time the macro appears at runtime? Does this depend on optimizations in the compiler, or is it covered under a standard?

Example:

#define EXTERNAL_CLOCK_FREQUENCY    32768
#define TIMER_1_S                   EXTERNAL_CLOCK_FREQUENCY
#define TIMER_100_MS                TIMERB_1_S / 10

Will the operation 32768 / 10 occur at runtime every time I use the TIMER_100_MS macro?

I would like to avoid the following:

#define EXTERNAL_CLOCK_FREQUENCY    32768
#define TIMER_1_S                   EXTERNAL_CLOCK_FREQUENCY
#define TIMER_100_MS                3277

---

Summary

A compiler is required to be able to evaluate constant integral expressions because they are necessary for calculating things like array sizes at compile time. However, the standard only says they "can" -- not "must" -- do so. Therefore, only a brain-dead compiler would not evaluate a constant integral expressions at compile time, but a simple check of the assembly output for an unconventional compiler would verify each case.

Answer 1

Why not try it and see?

bar.c:

#define EXTERNAL_CLOCK_FREQUENCY    32768
#define TIMER_1_S                   EXTERNAL_CLOCK_FREQUENCY
#define TIMER_100_MS                TIMER_1_S / 10

TIMER_100_MS
TIMER_100_MS

giving:

% cpp bar.c
# 1 "bar.c"
# 1 "<built-in>"
# 1 "<command line>"
# 1 "bar.c"

32768 / 10
32768 / 10

thereby showing that the macro was indeed expanded each time. This was with gcc 4.0.1 on MacOS X 10.5.6

Answer 2

At compile time. This is a language standard (and always have been) and independent on the compiler.

Edit

A commenter asked for a reference - quoting from "The C programming language" 2nd edition Appendix A12.3 (p. 229):

A control line of the form

#define identifier token-sequence

causes the preprocessor to replace subsequent instances of the identifier with the given sequence of tokens; leading and trailing whitespace around the roken sequence is discaded

End of edit

Answer 3

Will the operation 32768 / 10 occur at runtime every time I use the *TIMERB_100_MS* macro?

Every place in your code where you use TIMERB_100_MS, it will be replaced with 32768 / 10 by the preprocessor.

Whether that expression gets further optimized (it evaluates to a constant) is up to your compiler.

Answer 4

I'm not aware of any standard that guarantees it will be optimized out. The preprocessor will substitute 32768/10 for TIMER_100_MS, which you can see by running gcc -c. To see whether the compiler is optimizing further, run gcc -S and check out the assembler. With gcc 4.1, even without any optimization flags, this gets reduced to the constant during compilation:

#include <stdlib.h>
#include <stdio.h>

#define EXTERNAL_CLOCK_FREQUENCY    32768
#define TIMER_1_S                   EXTERNAL_CLOCK_FREQUENCY
#define TIMER_100_MS                TIMER_1_S / 10

int main(int argc, char **argv)
{
  printf("%d\n", TIMER_100_MS);

  return(0);
}

gcc -S test.c
cat test.s

...
    popl %ebx
    movl $3276, 4(%esp)
    leal LC0-"L00000000001$pb"(%ebx), %eax
    movl %eax, (%esp)
    call L_printf$stub
...

Answer 5

Macros are simply textual substitution, so in your example writing TIMER_100_MS in a program is a fancy way of writing 32768 / 10.

Therefore, the question is when the compiler would evaluate 32768 / 10, which is a constant integral expression. I don't think the standard requires any particular behavior here (since run-time and compile-time evaluation is indistinguishable in effect), but any halfway decent compiler will evaluate it at compile time.

Answer 6

From the WG14/N1124 Committee Draft — May 6, 2005 ISO/IEC 9899:TC2:

6.6 Constant expressions

Syntax

constant-expression:
    conditional-expression

Description

A constant expression can be evaluated during translation rather than runtime, and accordingly may be used in any place that a constant may be.

Constraints

Constant expressions shall not contain assignment, increment, decrement, function-call, or comma operators, except when they are contained within a subexpression that is not evaluated.96)

Each constant expression shall evaluate to a constant that is in the range of epresentable values for its type.

Answer 7

The compiler should optimize that expression out. I don't think it's requited to by the standard, but I've never seen a compiler that would NOT perform that task.

However, you should NOT write:

#define TIMER_100_MS      TIMERB_1_S / 10

... because that's a bug waiting to happen. You should always parenthesize #defines involving expressions.

#define TIMER_100_MS      (TIMERB_1_S / 10)

Consider :

i = 10 * TIMER_100_MS;

The first case would give 32768 ((10 * TIMERB_1_S) / 10) , the second 32760 (10 * (TIMERB_1_S / 10)). Not a critical difference here, but you MUST be aware of it!

Answer 8

Most answers in here focused on the effect of the macro substitution. But i think he wanted to know whether

32768 / 10

is evaluated at compile time. First of all, that is an arithmetic constant expression, and in addition a integral constant expression (because it has only got literals of integer type). The implementation is free to calculate it at runtime, but it must also be able to calculate it at compile time, because

1. it must give a diagnostic message if a constant expression is not representable in the type that its expression has
2. such expressions are allowed in contexts that require the value at translation time, for example if used as the size of an array dimension.

If the compiler can principally calculate the result already at compile time, it should use that value, and not recalculate it at runtime i think. But maybe there is some reason still to do that. I wouldn't know.

Edit: I'm sorry i've answered the question as if it were about C++. Noticed today you asked about C. Overflowing in an expression is deemed as undefined behavior in C, regardless of whether it happens in a constant expression or not. The second point is also true in C, of course.

Answer 9

Folks, this transformation is called "constant folding" and even most student compilers do it. As long as you have a compiler built by somebody not you or your college roommate and you're compiling a statically typed language, you can count on it even without optimization turned on. It's a different matter if you're dealing with some wacky dynamic language that is allowed to change the meaning of /.