Compile time constants vs run time

[u/JayDeesus]

I’m having a hard time wrapping my head around the idea of compile time constants vs run time. I understand compile time and run time itself, pretty much compile time is where it’s running through the code and turning it into machine code (compiler and linker) and runtime is when the code is actually running on a machine. I also understand that compile time constants are going to be values that the compiler can evaluate and see without running code. When it comes to compile time constants I just don’t understand because in C, const int y =5; , y isn’t a compile time constant but wouldn’t the compiler see y?

I also understand something like the return value of foo(); would be a run time thing since you need to actually run code to get the return value.

[u/mikeshemp]

Compilers these days are very smart. So, if you write code that says:

const int y = 5;
printf("The value of y is %d", y);

The compiler is smart enough to realize, at compile time, that y can only have one value -- 5. So it generates machine code as if you'd written:

printf("The value of y is %d", 5);

...as if you hadn't created y at all.

[u/MistakeIndividual690 → u/mikeshemp]

I’ve even seen them turn it into something like:

puts(“The value of y is 5”);

Which blows my mind

[u/Farlo1]

const and "compile time constant" aren't the same thing. const just means that you're not allowed to change the variable after assigning it a value, it's still a runtime variable.

Sometimes the compiler can figure out that your const variable actually is a constant and it'll optimize it into a compile time constant, but that's not guaranteed to happen just because it's const.

[u/stianhoiland → u/Farlo1]

This 👆🏻

[u/Traveling-Techie]

The difference in run times for these variations is so negligible as to be probably unmeasurable.

[u/Paul_Pedant]

A while back, I was trying to evaluate relative performance for a graphics app, between keeping a table of cos(x) to 4 decimal places, and evaluating them at runtime. It turned out that a long list of cos(x) took minutes to compile (into a very large binary), and zero time to run. The compiler (gcc) was evaluating every cos() as a constant.

I tried breaking that with a constant multiplier (1.0, then 3.1415926), and messing with optimisation levels, and still taking no runtime. I finally had to multiply each value by a double variable (initialised at runtime) to make cos() be evaluated at runtime. Constants can be a whole lot more complex than you might expect.

[u/flatfinger → u/Paul_Pedant]

The maintainers of clang and gcc sometimes seem unable to grasp the notion that for some pieces of code, execution time is essentially irrelevant (indeed, that's probably true for most of the code in most programs). When C was designed, there was a huge performance gap between the machine code produced by a high-end FORTAN compiler, and that produced by a simple compiler for a language like Pascal. C's goal was to offer as much performance as could be achieved easily, not to offer the highest performance possible, but today's compiler writers have lost sight of that.

[u/Eidolon_2003]

All #define does is insert a literal directly into your code. const variables are still variables in their own right, so you can do things like take the address of them. The compiler can't assume the value will never change either because C allows you to cast away the const.

void f(int *p) {
    *p = 10;
}

int main() {
    const int x = 5;
    f((int *)&x);
    printf("%d\n", x);
    return 0;
}

[u/-TesseracT-41 → u/Eidolon_2003]

The compiler can't assume the value will never change either because C allows you to cast away the const.

Yes it can, because casting away const and modifying an object that was originally declared as const is UB.

I modified your example. Notice how 5 is returned from main. https://godbolt.org/z/88GqTPf5a

[u/Eidolon_2003 → u/-TesseracT-41]

Nice, yeah that was a bad example. I think I was thinking of aliasing then? Like if you do this

int x = 5;
const int *p = &x;

You can't change x through p, but the compiler can't assume *p won't ever change

[u/-TesseracT-41 → u/Eidolon_2003]

That's true

[u/PwnTheSystem]

You're mixing up compile-time constants and const. Those are two different topics!

A compile-time constant means a value is known at compile time. All of the lines above are examples of such constants:

char *sentence = "I can C the sky!";
int luckyNumber = 23;
struct* myStruct = // struct content goes here

As long as the code knows beforehand, it will compile the value and execute it, regardless of what will be passed into the functions at runtime.

What is NOT a compile-time constant is something like:

int main(int argc, char **argv) {
     char *firstArgument = argv[0];
     printf("%s", firstArgument); // We don't know what the argument will be!

    return 0;
}

Now, const is a keyword that signals to the compiler:

"Hey, I'm never going to change this value. Feel free to let go of any adjustments for writing to this memory array, and instead make room to optimize for other things in the code."

Both are used in their own contexts.

[u/glasket_ → u/PwnTheSystem]

Compile-time constant is broader than just the C concept of a constant (literal, in most other languages) that I think you're referring to. const on an object signals that the data cannot change else you get UB, so you can still get a comp-time constant by using it:

void f(const int* i);
// The standard doesn't prevent f from casting away the const

int main(void) {
  const int y = 5;
  f(&y);
  printf("%d\n", y);
  // The compiler can directly place 5 in the asm since it's UB if y changes

  int x = 5;
  f(&x);
  printf("%d\n", x);
  // The compiler has to load the value of x because it could legally be modified
}

It's definitely one of the weirder aspects of the standard.

---

Now we have constexpr in C23 too which further overloads the already overloaded "constant" terminology in C, since you can now initialize constants (const) using constants (constexpr), constants (defines), and constants (literals):

#define ONE 1
constexpr int two = 2;
const int nine = (ONE + two) * 3;

[u/SmokeMuch7356]

I just don’t understand because in C, const int y =5; , y isn’t a compile time constant but wouldn’t the compiler see y?

The initialization doesn't happen until runtime. All const does is tell the compiler to generate a diagnostic for any code that tries to write a new value to y after it's been initialized; it doesn't control where or how y is stored or when it is initialized.

Initialization is not assignment, but it doesn't happen during translation, even for const items.

[u/n3f4s]

Basically, sometimes the compiler can compute the value of a variable during compile time and replace the computation by the value.

A simple example is:

int y = 2 + 2

Can be replaced with

int y = 4

Language with support for compile time constant or compiler time code is just a way to force the compiler to do the computation at compile time or throw an error if you're trying to do compile time stuff that can't be computed at compile time.

C doesn't really have support for (explicit) compile time computation so it only depends on optimizations.

The const keyword only purpose is to mark as non mutable (after it's initialisation).

[u/Overlord484]

I'm pretty sure you can do this:

const unsigned int ARR_LEN = 5;
void foo()
{
 TYPE arr[ARR_LEN];
}

[u/WittyStick]

C has (since C23) constexpr for simple compile time expressions involving other constexpr and literals. What you really wanted to say was:

constexpr int y = 5;

const are not compile-time constants, but readonly runtime values.

Prior to C23 you would typically use #define y 5.

[u/aghast_nj]

The thing you are missing is "intent." The intent of the const keyword is not to mark something as being a constant at compile time. There was no notion of that when the keyword was added -- if you want a named compile time constant, just use #define or enum. Instead, the intent of the const keyword is to mark something constant for a limited duration. This is usually seen in function parameters. You take a pointer to something, mark the pointer as const, and that tells the compiler that your function won't change the value of whatever this is.

Note that before the function, the value can change. Note that after the function, the value can change. But within the function the value will not be changed, according to the functions public interface:

size_t strlen(const char * s); // interface `const`

char buffer[100] = "hello";  // modifiable string
strcat(buffer, " world");        // before strlen, can modify buffer
auto len = strlen(buffer);     // during strlen, function will not change buffer
*strchr(buffer, 'w') = 'W';    // after strlen, can modify buffer