C++ Loops, scope, and stack (why does this work?)

Question

I'm finding it difficult to find specific answers for questions like this, but I'll explain the way I think think this is supposed to (not) work, and maybe someone can tell me where I'm wrong.

I create an integer array of size 10 in main which lives on the stack. Then I use a for loop to load integers 0-9 into that array. When the for loop ends, the stack pointer returns to where it was after initializing arr1, but those values still exist in memory, and the array is still pointing to them.

Then, I use another for loop to flood the stack, which should overwrite the values created in the first for loop, and now when I go to access my values in arr1, they should be pointing to integers with values of 5000.

When I print the array, it still prints out numbers 0-9. Why does this work? I thought data declared in a loop was popped off the stack when it goes out of scope. Thanks

int main(void)
{
    int arr1[10];

    for(int i = 0; i < 10; i++)
        arr1[i] = i;

    for(int i = 0; i < 500; i++)
        int a = 5000;

    for(int i = 0; i < 10; i++)
        cout << arr1[i] << endl;

    system("PAUSE");

    return 0;
}

Answer 1

You seem to have misunderstood data lifetime in C++. When local data is declared in a scope block (whether in a function, loop, or other control structure), it remains on the stack until that scope block ends.

That means the entirety of arr1 remains allocated and on the stack until main() finishes, no matter what else you do. It will not be overwritten by subsequent local variables in the same function, or variables nested in deeper scope blocks.

In your second loop, variable a is (theoretically) being created and destroyed on every iteration of the loop body. That means you don't have 500 instances of a on the stack during the loop -- you only ever have one. (In practice, the compiler almost certainly optimises that out though, since it's not doing anything useful.)

Answer 2

No, the array is not "pointing to" the values. arr1 is 10 integers, it is not 10 pointers to integers. The values are stored in the array. Creating and then immediately destroying another variable a, even doing it 500 times, does not change what is stored in the array arr1.

It's possible that you have come from a language where variables and/or array elements by definition are references to objects. That is not the case in C++.

And for what it's worth, C++ implementations generally do not move the stack pointer around when you enter and exit a for loop. Generally they only generate one stack frame per function containing all the variables that function needs, although they are permitted to do what they like provided that they call destructors at the correct time.

Answer 3

As you say "data declared in a loop was popped off the stack when it goes out of scope." That is true. But in your sample, the array is NOT declared inside a loop. It is declared outside of the loop and is still in scope for the rest of main().

If you had something like this:

 char * arr1[10];

 for(int i = 0; i < 10; i++)
 {
     char * text[16];
     sprintf(text, "%d", i);
     arr1[i] = text;
 }
 for(int j = 0; j < 10; ++j)
     printf ("%s\n", arr1[i]);

then this would crash because the text[] arrays are declared inside the first loop and they go out of scope at the end of the loop, leaving pointers to the variables that are out of scope. I think this is what you had in mind.

Answer 4

arr1 and a are in totally independent memory locations. You can prove this with this line:

printf("%lu %p %p %p", \
    sizeof(int), (void *)&arr1[0], \
    (void *)&arr1[9], (void *)&a);

For example, on my machine I got this output:

4 0x7fff5541e640 0x7fff5541e664 0x7fff5541e63c

As you can see, &a is four bytes (sizeof(int)) from the first element of arr1.

The following statement:

for(int i = 0; i < 500; i++)
    int a = 5000;

Does not have the effect that you're suspecting. It simply assigns the value 5000 to the variable a over and over again, or, has been optimized and only does it once or even not at all because a is not used.