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

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 2

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 3

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.