Why is visual studio not aware that an integer's value is changing? (debugging)

Question

I have a few simple lines of code (below). [bp] indicates a breakpoint.

     for(int i=0;i<300;i++){}
     int i=0;
     cout<<i;
[bp] for (i=0;i<200;i++){}

When I debug this in visual studio, it tells me that i is equal to 300 on the breakpoint. Annoyingly, 0 is printed to the console. Is there any way to make it realize that two variables in different scopes can actually have the same name?

I also want to add some code to the second loop and then debug it - but when I try to do that, i is consistently shown as 300. Very annoying.

Answer 1

If your breakpoint is on the

for (i=0;i<200;i++){}

line, that means that the new i hasn't initialized yet when the breakpoint is hit, because that line of code hasn't executed yet. So it's still carrying the original i value.

Answer 2

Brace for impact

---

The use of the same varibale for different perpose at different places in code is NOT ideal.

Here's the solution though:
Use braces to separate the different use-cases of the same variable.

for(int i=0;i<300;i++){}

{
     int i=0;
     cout<<i;
}

{
[bp] for (i=0;i<200;i++){}
}

NOTE:
As Robert rightly pointed out, unless the instruction is executed,
i will not be initialised to the new value.

GoodLUCK!!

Answer 3

in my visual studio, looking at the debugger Locals window

        i   300 int
        argc    1   int
        argv    0x00214b88  wchar_t * *
        i   0   int

NOTE! there are two i varibles in the debug output, i == 300 and i == 0

I'm thinking the reason its getting confused is a quirk/bug of the debugger where it tracks both i's then gets confused when you hover over an i, it just returns the first i? or some such, I don't think its semantically checking which i to show.

Answer 4

The third i can alias the first i, because they have non-overlapping scopes. The second i cannot alias the third, because their scopes do overlap.

Hence, the compiler knows it needs to allocate storage for at least two integers. The space for the first integer can be shared by the first and third i, and the the space for the second i is reserved exclusively for the second i. These locations could be registers or stack slots, without loss of generality.

Interim conclusion: for the compiler, it doesn't matter how often you use the name i. It only cares how many variables you have, and how their scopes overlap.

So, when the debugger hits the second for-loop, it sees that you're watching the third i. The debugger looks up the location of the third i. Since that location was also used for the first i, it still contains 300. That of course doesn't matter for the program, as you start out by writing 0 to the third i, overwriting the old value 300 in that location.

So, the essential step is understanding how variables can be mapped to locations.