variable scope in for loop

[Jeff Schwab]

Re: variable scope in for loop

Ron Natalie wrote:

<snip> macro redefining "for" to get around a non-compliance </>
[color=blue]
> By making this change, once, with the approval of our design team
> and putting it in a controlled place, it gets around a zillion Microsoft
> specific hacks that involve bad coding practices of leaving variables
> uninitialized or sitting around outside the scope they are used in.
>
> I'm not recommending the willy nilly redefining of keywords, but in
> this case making the tested, controlled, one line change IS LESS
> INTRUSIVE, than having to break standard-conforming code everywhere
> else it appears OR adding bad programming practices because the
> compiler is busted.[/color]

Of course, you'll have to include the macro in each source file using a
"for" loop. You'll need to be careful not to include before any of the
MS headers, too, to avoid breaking them.

[Rolf Magnus]

Re: variable scope in for loop

Howard wrote:
[color=blue][color=green]
>> By making this change, once, with the approval of our design team
>> and putting it in a controlled place, it gets around a zillion
>> Microsoft specific hacks that involve bad coding practices of leaving
>> variables uninitialized or sitting around outside the scope they are
>> used in.
>>[/color]
>
> I'm curious why you call it "bad coding practice" to have a single
> variable
> used more than once. I understand that i is in this case just an
> integer, and there's no logical reason why it *shouldn't* be declared
> in each for loop construct, but what does it hurt to declare it once
> and use it multiple times?[/color]

IMHO, doing that doesn't hurt so much, but it does hurt to be forced to
do it. I think it's cleaner to have a loop counter defined in the loop
instead of before, and I like to be able to do that.
OTOH, how does the proposed macro hurt?
[color=blue]
> Imagine if you had, instead of an integer being used in multiple for
> loops, some more complex object being used in multiple blocks of code
> within one function. The overhead of constructing the object multiple
> times now can outweigh the desired practice of declaring it within
> each block.[/color]

Constructing an object is often less or at least not more expensive than
assigning to it. I would expect an iterator to take the same time for
assigning to it as for constructing it.
[color=blue]
> Personally, I prefer to declare i within each loop construct, and then
> change that specific piece of code when I port to VC++.[/color]

I know it's sometimes necessary to do some changes to conforming code to
make it compile with a specific compiler, but that's not one of those
places. I wouldn't like to do such a change in multiple places if I can
istead just add a single line to make them all work at once without
changing them.
[color=blue]
> If I forget to change it, the compiler tells me.
>
> Provided that you do not rely on the value of i between or at the
> start of any block, but instead assign it a value in the initializer
> portion of each for loop, I fail to see where any harm can come from
> declaring it once and using it multiple times. (And in the bad old
> days when I needed every byte of memory I could get my grubby little
> hands on, it was practically a *requirement* that I do it that way!)[/color]

You could say the same about the "bad old days" when you needed to count
clock cycles.

[Ron Natalie]

Re: variable scope in for loop


"Jeff Schwab" <jeffplus@comca st.net> wrote in message news:BuqdnZtJd7 hWPWGiRVn-sA@comcast.com. ..
[color=blue]
>
> Of course, you'll have to include the macro in each source file using a
> "for" loop. You'll need to be careful not to include before any of the
> MS headers, too, to avoid breaking them.
>[/color]
We have a file that is included in each source module anyhow. There
are always implementation dependencies to resolve. Actually, no Microsoft
header seems affected by the change. Even the V7 compiler can compile
all the MS headers (even the earlier ones) with the option turned on that
causes the compiler to use the proper for loop scoping. The problem
is the V6 compiler, doesn't break this out separately. If you disable
ALL extensions (which will get the right for loop scoping), then something
else that the headers relies on gets shut off.