C++ stack and scope

Question

I tried this code on Visual C++ 2008 and it shows that A and B don't have the same address.

int main()
{
    {
     int A;
     printf("%p\n", &A);
    }

    int B;
    printf("%p\n", &B);
}

But since A doesn't exist anymore when B gets defined, it seems to me that the same stack location could be reused...

I don't understand why the compiler doesn't seem to do what looks like a very simple optimization (which could matter in the context of larger variables and recursive functions for example). And it doesn't seem like reusing it would be heavier on the CPU nor the memory. Does anyone have an explanation for this?

I guess the answer is along the lines of "because it's much more complex than it looks", but honestly I have no idea.

edit: Some precisions regarding the answers and comments below.

The problem with this code is that each time this function is called, the stack grows "one integer too much". Of course this is no problem in the example, but consider large variables and recursive calls and you have a stack overflow that could be easily avoided.

What I suggest is a memory optimization, but I don't see how it would damage performance.

And by the way, this happens in release builds, will all optimizations on.

Answer 1

It is probably that the compiler is putting both on the same stack frame. So even though A is not accessible outside it's scope, the compiler is free to bound it to a place in memory as long as that doesn't corrupt the semantics of the code. In short, they get both put on the stack at the same time you execute your main.

Answer 2

Reusing stack space for locals like this is a very common optimization. In fact, on an optimized build, if you didn't take the address of the locals, the compiler might not even allocate stack space and the variable would only live in a register.

You might not see this optimization happen for several reasons.

First, if optimizations are off (like a debug build) the compiler won't do either of these to make debugging easier - you can view the value of A even if it is no longer used in the function.

If you are compiling with optimizations, my guess would be since you are taking the address of the local and passing it to another function, the compiler doesn't want to reuse the store since it is unclear what that function is doing with the address.

One can also imagine a compiler that would not use this optimization unless the stack space used by a function exceeds some threshold. I don't know of any compilers that do this, since reusing the space of local variables that are no longer used has zero cost and could be applied across the board.

If stack growth is a serious concern for your application, i.e., in some scenarios you are hitting stack overflows, you should not be relying on the compiler's optimization of stack space. You should consider moving large buffers on the stack to the heap and work to eliminate very deep recursion. For example, on Windows threads have a 1 MB stack by default. If you're concerned about overflowing that because you're allocating 1k of memory on each stack frame and going 1000 recursive calls deep, the fix is not to try to coax the compiler to save some space off of each stack frame.

Answer 3

A is allocated on the stack after B. B is declared after A in the code (which is not allowed by C90 by the way), but it's still in the top scope of the main function and thus exists from the beginning of main til the end. So B is pushed when main starts, A is pushed when the inner scope is entered and popped when it is left, and then B is popped when the main function is left.

Answer 4

Why not check out the assembly?

I changed your code slightly so that int A = 1; and int B = 2; to make it slightly easier to decipher.

From g++ with default settings:

    .globl main
    .type main, @function
main:
.LFB2:
    leal 4(%esp), %ecx
.LCFI0:
    andl $-16, %esp
    pushl -4(%ecx)
.LCFI1:
    pushl %ebp
.LCFI2:
    movl %esp, %ebp
.LCFI3:
    pushl %ecx
.LCFI4:
    subl $36, %esp
.LCFI5:
    movl $1, -8(%ebp)
    leal -8(%ebp), %eax
    movl %eax, 4(%esp)
    movl $.LC0, (%esp)
    call printf
    movl $2, -12(%ebp)
    leal -12(%ebp), %eax
    movl %eax, 4(%esp)
    movl $.LC0, (%esp)
    call printf
    movl $0, %eax
    addl $36, %esp
    popl %ecx
    popl %ebp
    leal -4(%ecx), %esp
    ret
.LFE2:

Ultimately it looks like the compiler just didn't bother to put them in the same address. There was no fancy lookahead optimization involved. Either it wasn't trying to optimize, or it decided there was no benefit.

Notice A is assigned, and then printed. Then B is assigned and printed, just like in the original source. Of course if you use different compiler settings this could look completely different.

Answer 5

By my knowledge the space for B is reserved upon the entry to main, and not at the line

int B;

If you break in the debugger before that line, you are nevertheless able to obtain the address of B. The stackpointer also does not change after this line. The only thing that happens at this line, is that the constructor of B is called.

Answer 6

The compiler really has no choice in this case. It cannot assume any particular behavior of printf(). As a result, it must assume that printf() could hang on to &A as long as A itself exists. Therefore, A itself is live in the entire scope where it is defined.

Answer 7

A big part of my job is fighting compilers, and I have to say that they don't always do what we, humans, expect them to do. Even when you have programmed the compiler, you can still be surprised at the results, the input matrix is impossible to predict 100%.

The optimizing part of the compiler is very complex and as mentioned in other answers, what you observed could be due to a voluntary response to a setting, but it could just be a result of the influence of the surrounding code, or even the absence of this optimization in the logic.

In any case, as Micheal says, you should not be relying on the compiler to prevent stack overflows, because you might just be pushing the problem to later, when normal code maintenance or a different set of input is used, and it will crash much further in the pipeline, maybe in the hands of the user.