But shouldn't the int i in the for-loop be the nearest lexical scope?

So like this:

int i = 42;
// i = 42
for(int i=0;....;...)
{
 // i starts from 0 and changes
}
// i = 42 again because of scopes

If I word it differently, isn't the i in the for-loop not a different i than outside the for-loop?

Or are we talking about (ANSI) C here?
In which case it should say something about not allowing variable declarations there.

In which case it should warn you about a variable redefinition :)

Rename your variable to _LOL_inner_macro_s_loop_counter_please_don_t_make_a_local_variable_with_this_name_anywhere_18y32irh329

Quote: Original post by mldaalder
But shouldn't the int i in the for-loop be the nearest lexical scope?

So like this:

int i = 42;
// i = 42
for(int i=0;....;...)
{
 // i starts from 0 and changes
}
// i = 42 again because of scopes

If I word it differently, isn't the i in the for-loop not a different i than outside the for-loop?

Or are we talking about (ANSI) C here?
In which case it should say something about not allowing variable declarations there.

Yes. My example is shit. I've edited it now [smile]

Quote: Original post by mldaalder
But shouldn't the int i in the for-loop be the nearest lexical scope?

So like this:

int i = 42;
// i = 42
for(int i=0;....;...)
{
 // i starts from 0 and changes
}
// i = 42 again because of scopes

If I word it differently, isn't the i in the for-loop not a different i than outside the for-loop?

Or are we talking about (ANSI) C here?
In which case it should say something about not allowing variable declarations there.

Sorry, this is C++ (Well, CodeWarrior's version of it anyway). The problem is that the macro expansion just causes it to substitute "x" for "i". i is never less than i, so the loop never executes.

Quote: Original post by Jotaf
In which case it should warn you about a variable redefinition :)

Ah, but the variable in the for() loop scope hides the i variable in the outer scope. Because they're at two different scopes, it's all legal and above board.

Quote: Original post by Pouya
Rename your variable to _LOL_inner_macro_s_loop_counter_please_don_t_make_a_local_variable_with_this_name_anywhere_18y32irh329

Actually, the real code was a flood fill algorithm, and the macro was a PutPixel() function (I don't trust CodeWarrior to actually inline anything I tell it to, it has no choice if it's a macro). The loop in the macro was for(int x=0; x<blah; ++x) and a similar loop for y. I just changed the loop vars to xxx and yyy.
So I fully expect to be pulled up on that at the next code review for a) using bizzarely named variables and b) using macros in the first place.

Quote: Original post by mldaalder
But shouldn't the int i in the for-loop be the nearest lexical scope?

So like this:

int i = 42;
// i = 42
for(int i=0;....;...)
{
 // i starts from 0 and changes
}
// i = 42 again because of scopes

If I word it differently, isn't the i in the for-loop not a different i than outside the for-loop?

Or are we talking about (ANSI) C here?
In which case it should say something about not allowing variable declarations there.

Sorry, this is C++ (Well, CodeWarrior's version of it anyway). The problem is that the macro expansion just causes it to substitute "x" for "i". i is never less than i, so the loop never executes.

Quote: Original post by Jotaf
In which case it should warn you about a variable redefinition :)

Ah, but the variable in the for() loop scope hides the i variable in the outer scope. Because they're at two different scopes, it's all legal and above board.

Quote: Original post by Pouya
Rename your variable to _LOL_inner_macro_s_loop_counter_please_don_t_make_a_local_variable_with_this_name_anywhere_18y32irh329

Actually, the real code was a flood fill algorithm, and the macro was a PutPixel() function (I don't trust CodeWarrior to actually inline anything I tell it to, it has no choice if it's a macro). The loop in the macro was for(int x=0; x<blah; ++x) and a similar loop for y. I just changed the loop vars to xxx and yyy.
So I fully expect to be pulled up on that at the next code review for a) using bizzarely named variables and b) using macros in the first place.

Or use an inline function.