C++ 堆栈和作用域

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
", &A);
    }

    int B;
    printf("%p
", &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.

解决方案

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.