variable scope in for loop

[Wenjie]

Hello,
We had a code review with the argument of
whether "i" is out of scope as illustrated
below:
for (int i=0; i<2004; i++)
{
doSomething(i);
}

for (i=0; i<2004; i++)
{
doSomethingElse(i);
}

Is it correct according to C++ language?
VC++6.0 works fine with above code.
Thanks and best regards,
Wenjie

[Rob Williscroft]

Wenjie wrote in news:d2**************************@posting.google.c om:

We had a code review with the argument of
whether "i" is out of scope as illustrated
below:
for (int i=0; i<2004; i++)
{
doSomething(i);
}

for (i=0; i<2004; i++)
{
doSomethingElse(i);
}

Is it correct according to C++ language?
Nope,
VC++6.0 works fine with above code.

Its a well known defect with this compiler, so much so that MSVC 7.1
also behaves this way by default (it has 2 option's that can remove
the defect /Za and /Zc:forScope).
Rob.
--
http://www.victim-prime.dsl.pipex.com/

[Wagner Bruna]

Hello,

go****@yahoo.com (Wenjie) wrote in message news:<d2**************************@posting.google. com>...

We had a code review with the argument of
whether "i" is out of scope as illustrated
below:
for (int i=0; i<2004; i++)
{
doSomething(i);
}

for (i=0; i<2004; i++)
{
doSomethingElse(i);
}

Is it correct according to C++ language?
VC++6.0 works fine with above code.

No, it's not correct. The scope of i ends at the end of the first
loop.

If you need VC++6 portability, a good workaround IMHO is to enclosure
the loops inside artificial blocks:

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

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

--
Wagner

[Dietmar Kuehl]

go****@yahoo.com (Wenjie) wrote:

We had a code review with the argument of
whether "i" is out of scope as illustrated
below:
for (int i=0; i<2004; i++)
{
doSomething(i);
}

for (i=0; i<2004; i++)
{
doSomethingElse(i);
}

Is it correct according to C++ language?
No, it is not.
VC++6.0 works fine with above code.

Well, this compiler is not known for its standard conformance, is it? Try
one base on the EDG front-end or, better yet, verify things in the standard.
--
<mailto:di***********@yahoo.com> <http://www.dietmar-kuehl.de/>
Phaidros eaSE - Easy Software Engineering: <http://www.phaidros.com/>

[Rolf Magnus]

Wagner Bruna wrote:

Hello,

go****@yahoo.com (Wenjie) wrote in message
news:<d2**************************@posting.google. com>...

We had a code review with the argument of
whether "i" is out of scope as illustrated
below:
for (int i=0; i<2004; i++)
{
doSomething(i);
}

for (i=0; i<2004; i++)
{
doSomethingElse(i);
}

Is it correct according to C++ language?
VC++6.0 works fine with above code.

No, it's not correct. The scope of i ends at the end of the first
loop.

If you need VC++6 portability, a good workaround IMHO is to enclosure
the loops inside artificial blocks:

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

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

IIRC, another, less intrusive workaround is to

#define for if(false); else for

[Ron Natalie]

"Wagner Bruna" <wb****@yahoo.com> wrote in message news:54**************************@posting.google.c om...

If you need VC++6 portability, a good workaround IMHO is to enclosure
the loops inside artificial blocks:

What we do (and I know this is technically illegal, but if VC++ is going to
break the rules, we will too!):

#define for if(false);else for

It's in our master win32 config file right after disabling warning 4786!

[Pete Becker]

Rolf Magnus wrote:

Wagner Bruna wrote:

Hello,

go****@yahoo.com (Wenjie) wrote in message
news:<d2**************************@posting.google. com>...

We had a code review with the argument of
whether "i" is out of scope as illustrated
below:
for (int i=0; i<2004; i++)
{
doSomething(i);
}

for (i=0; i<2004; i++)
{
doSomethingElse(i);
}

Is it correct according to C++ language?
VC++6.0 works fine with above code.

No, it's not correct. The scope of i ends at the end of the first
loop.

If you need VC++6 portability, a good workaround IMHO is to enclosure
the loops inside artificial blocks:

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

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

IIRC, another, less intrusive workaround is to

#define for if(false); else for

An even less intrusive workaround is to move the variable declaration
outside the loop:

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

for (i=0; i<2004; i++)
{
doSomethingElse(i);
}

Look, ma, no macros.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

[Ron Natalie]

"Pete Becker" <pe********@acm.org> wrote in message news:3F***************@acm.org...

#define for if(false); else for

An even less intrusive workaround is to move the variable declaration
outside the loop:

int i;

Actually, I find that MORE intrusive. You have to put sloppy coding
practices in your code to correct for defects in the compiler.

If you were going to do that (and eschew macros), it would be better to
rename the variable and keep it defined inside the loop.

[Pete Becker]

Ron Natalie wrote:

"Pete Becker" <pe********@acm.org> wrote in message news:3F***************@acm.org...

#define for if(false); else for

An even less intrusive workaround is to move the variable declaration
outside the loop:

int i;

Actually, I find that MORE intrusive. You have to put sloppy coding
practices in your code to correct for defects in the compiler.

It's only sloppy if you treat it that way. But you often have to do
things you'd rather not in order to get around compiler limitations.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

[Jeff Schwab]

Pete Becker wrote:

Rolf Magnus wrote:

Wagner Bruna wrote:

Hello,

go****@yahoo.com (Wenjie) wrote in message
news:<d2**************************@posting.goog le.com>...

We had a code review with the argument of
whether "i" is out of scope as illustrated
below:
for (int i=0; i<2004; i++)
{
doSomething(i);
}

for (i=0; i<2004; i++)
{
doSomethingElse(i);
}

Is it correct according to C++ language?
VC++6.0 works fine with above code.

No, it's not correct. The scope of i ends at the end of the first
loop.

If you need VC++6 portability, a good workaround IMHO is to enclosure
the loops inside artificial blocks:

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

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

IIRC, another, less intrusive workaround is to

#define for if(false); else for

An even less intrusive workaround is to move the variable declaration
outside the loop:

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

for (i=0; i<2004; i++)
{
doSomethingElse(i);
}

Look, ma, no macros.

I certainly prefer your macroless approach, but why not initialize i
where it is defined, and save an assignment?

int i = 0;

for( ; i < 2004; ++i )
do_something( i );

for( i = 0; i < 2004; ++i )
do_something_else( i );

In production code, I tend to prefer while-loops to for-loops anyway, so
it would look something like this:

int i = 0;

while( i < 2004 )
{
do_something( i );
++i
}

i = 0;

while( i < 2004 )
{
do_something_else( i );
++i;
}

I know folks are religious about for-loops; please don't be offended if
I don't respond to criticisms about keeping loop control at the top of
the block. :)

[Pete Becker]

Jeff Schwab wrote:

I certainly prefer your macroless approach, but why not initialize i
where it is defined, and save an assignment?

Because two things that do the same thing ought to look alike.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

[Jeff Schwab]

Pete Becker wrote:

Jeff Schwab wrote:

I certainly prefer your macroless approach, but why not initialize i
where it is defined, and save an assignment?

Because two things that do the same thing ought to look alike.

Maybe; that's an aesthetic preference. I don't think itt's a good
reason to delay initialization of a variable (or replace it with
assignment).

I admit that there's a nice feeling of symmetry when code is all lined
up, shiny and fixed-width. The proportional font used in TC++PL looks
pretty good, though, even when similar blocks of code are formatted in
totally different ways...

[Pete Becker]

Jeff Schwab wrote:

Pete Becker wrote:

Jeff Schwab wrote:

I certainly prefer your macroless approach, but why not initialize i
where it is defined, and save an assignment?

Because two things that do the same thing ought to look alike.

Maybe; that's an aesthetic preference.

No, it's about readability.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

[Jeff Schwab]

Pete Becker wrote:

Jeff Schwab wrote:

Pete Becker wrote:

Jeff Schwab wrote:
I certainly prefer your macroless approach, but why not initialize i
where it is defined, and save an assignment?
Because two things that do the same thing ought to look alike.

Maybe; that's an aesthetic preference.

No, it's about readability.

I think initialized variables properly does more for readability than
making blocks of code look alike. Just my opinion, though.

[Andrey Tarasevich]

Jeff Schwab wrote:

...
I think initialized variables properly does more for readability than
making blocks of code look alike. Just my opinion, though.
...

In my opinion, separating initialization of loop variable from the loop
itself might create more problems than delayed intialization of a variable.

--
Best regards,
Andrey Tarasevich

[Jeff Schwab]

Andrey Tarasevich wrote:

Jeff Schwab wrote:

...
I think initialized variables properly does more for readability than
making blocks of code look alike. Just my opinion, though.
...

In my opinion, separating initialization of loop variable from the loop
itself might create more problems than delayed intialization of a variable.

For instance?

[Pete Becker]

Jeff Schwab wrote:

I think initialized variables properly does more for readability than
making blocks of code look alike. Just my opinion, though.

Initializing variables isn't about readability, it's about limiting
risk. If you're seriously concerned that you'll use loop index when it
doesn't have a sensible value, then in addition to initializing it when
you create it you need to reset it immediately after the first loop,
just in case you refer to it before it gets reinitialized for the second
loop. But, of course, that would look really stupid. At some point you
have to think, instead of programming by cliche.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

[Andrey Tarasevich]

Jeff Schwab wrote:

...
I think initialized variables properly does more for readability than
making blocks of code look alike. Just my opinion, though.
...

In my opinion, separating initialization of loop variable from the loop
itself might create more problems than delayed intialization of a variable.

For instance?

For example, someone might inadvertently insert some other piece of code
between the declaration of 'i' and the first cycle. If this new code
happens to modify 'i' (let's say it is also a 'for' cycle on 'i') then
the original first cycle will start with incorrect value of 'i'.

C90-style of variable declaration is not really compatible with
"declaration is an initialization" principle.

In my opinion, it makes more sense to assign the initial value to the
variable as close as possible to the spot where the effect of this
assignment is used. In this partucular case this is achieved by placing
the 'i = 0' expression inside each 'for' statement.

--
Best regards,
Andrey Tarasevich

[Rolf Magnus]

Pete Becker wrote:

Rolf Magnus wrote:

Wagner Bruna wrote:

> Hello,
>
> go****@yahoo.com (Wenjie) wrote in message
> news:<d2**************************@posting.google. com>...
>>
>> We had a code review with the argument of
>> whether "i" is out of scope as illustrated
>> below:
>> for (int i=0; i<2004; i++)
>> {
>> doSomething(i);
>> }
>>
>> for (i=0; i<2004; i++)
>> {
>> doSomethingElse(i);
>> }
>>
>> Is it correct according to C++ language?
>> VC++6.0 works fine with above code.
>
> No, it's not correct. The scope of i ends at the end of the first
> loop.
>
> If you need VC++6 portability, a good workaround IMHO is to
> enclosure the loops inside artificial blocks:
>
> {
> for (int i=0; i<2004; i++) {
> doSomething(i);
> }
> }
>
> {
> for (int i=0; i<2004; i++) {
> doSomethingElse(i);
> }
> }
IIRC, another, less intrusive workaround is to

#define for if(false); else for

An even less intrusive workaround is to move the variable declaration
outside the loop:

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

for (i=0; i<2004; i++)
{
doSomethingElse(i);
}

You consider this less intrusive? You have to use that workaround in
every function that has more than one for loop, while the macro only
needs to be defined in one single place in a header that gets included
everywhere. At the place where the for loop is, you don't need to take
care about such things anymore.
Look, ma, no macros.

So you wouldn't use that macro just for the sole sake of avoiding
macros? Or do you have any real technical reason?

[Pete Becker]

Rolf Magnus wrote:

You consider this less intrusive? You have to use that workaround in
every function that has more than one for loop
It's not a workaround. It's a way of writing portable code when you plan
to target a compiler that doesn't support for loop scoping.
So you wouldn't use that macro just for the sole sake of avoiding
macros? Or do you have any real technical reason?

Neither. Apparently you don't grasp humor.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

[Rolf Magnus]

Pete Becker wrote:

Rolf Magnus wrote:

You consider this less intrusive? You have to use that workaround in
every function that has more than one for loop

It's not a workaround. It's a way of writing portable code when you
plan to target a compiler that doesn't support for loop scoping.

I'd not be willing to use that "way of writing code" if I don't need to.
Well, actually, I'm not using VC++ myself, but if anyone wants to port
my code to it, he either needs to change all the for loops (since I
always define the counter in the for scope, which looks cleaner to me),
or add the macro.

So you wouldn't use that macro just for the sole sake of avoiding
macros? Or do you have any real technical reason?

Neither. Apparently you don't grasp humor.

English is not my native tongue, so I might have difficulties to grasp
your humor. Anyway, what's your point then?

[Howard]

"Rolf Magnus" <ra******@t-online.de> wrote in message
news:bt*************@news.t-online.com...

Pete Becker wrote:

Rolf Magnus wrote:

You consider this less intrusive? You have to use that workaround in
every function that has more than one for loop

It's not a workaround. It's a way of writing portable code when you
plan to target a compiler that doesn't support for loop scoping.

I'd not be willing to use that "way of writing code" if I don't need to.
Well, actually, I'm not using VC++ myself, but if anyone wants to port
my code to it, he either needs to change all the for loops (since I
always define the counter in the for scope, which looks cleaner to me),
or add the macro.

So you wouldn't use that macro just for the sole sake of avoiding
macros? Or do you have any real technical reason?

Neither. Apparently you don't grasp humor.

English is not my native tongue, so I might have difficulties to grasp
your humor. Anyway, what's your point then?

Just an old expression used as a joke. Originally it was "look, ma, no
hands"...used when doing something like riding your bicycle without using
your hands.

I think I agree with him that I'd just as soon not use macros. No real
rechnical reason, I just don't like using them, I guess because you have to
go look up what they do, try to figure out what the result of them is after
parsing, and then they can be changed on you and you have to find everywhere
they're used and be sure those places aren't broken. Just a pain in the
arse if you ask me.

Personally, I do it like you and write them according to the standard, with
i declared within each for loop. Then, when I port to VC++ 6.0 (which I
often do), I change the code that fails to compile and use a single
declaration for i before the first loop.

But I never use macros. (Templates are a pain in the ass to figure out
sometimes, too, but their power is to great to ignore! :-))

-Howard

[Jack Klein]

On Tue, 06 Jan 2004 14:41:03 -0500, Jeff Schwab <je******@comcast.net>
wrote in comp.lang.c++:

Pete Becker wrote:

Rolf Magnus wrote:

Wagner Bruna wrote:
Hello,

go****@yahoo.com (Wenjie) wrote in message
news:<d2**************************@posting.goog le.com>...

>We had a code review with the argument of
>whether "i" is out of scope as illustrated
>below:
>for (int i=0; i<2004; i++)
>{
> doSomething(i);
>}
>
>for (i=0; i<2004; i++)
>{
> doSomethingElse(i);
>}
>
>Is it correct according to C++ language?
>VC++6.0 works fine with above code.

No, it's not correct. The scope of i ends at the end of the first
loop.

If you need VC++6 portability, a good workaround IMHO is to enclosure
the loops inside artificial blocks:

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

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

IIRC, another, less intrusive workaround is to

#define for if(false); else for

An even less intrusive workaround is to move the variable declaration
outside the loop:

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

for (i=0; i<2004; i++)
{
doSomethingElse(i);
}

Look, ma, no macros.

I certainly prefer your macroless approach, but why not initialize i
where it is defined, and save an assignment?

int i = 0;

for( ; i < 2004; ++i )
do_something( i );

for( i = 0; i < 2004; ++i )
do_something_else( i );

Because somebody maintaining your code some day, somebody else or even
you, will rearrange the loops or stick another one or another use for
'i' between the definition with initialization and the first for loop.
Then a perhaps strange and hard-to-find defect will be born.

The loop should perform its own initialization.
In production code, I tend to prefer while-loops to for-loops anyway, so
it would look something like this:

int i = 0;

while( i < 2004 )
{
do_something( i );
++i
}

i = 0;

while( i < 2004 )
{
do_something_else( i );
++i;
}

I know folks are religious about for-loops; please don't be offended if
I don't respond to criticisms about keeping loop control at the top of
the block. :)

Nothing against while loops, I use them myself quite frequently, or
even do ... while loops, more often than most.

But I don't like an important condition of the loop separated from the
control statement itself, both for conceptual reasons and also for the
above mentioned maintenance problem. If someone, someday, puts
something between the initialization or the assignment and the
corresponding loop, bang!

In your particular example, I would use the for loop because it allows
setting the initial value of the control variable, a necessary
requirement of the loop, to appear in the loop control logic.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Jack Klein]

On Tue, 06 Jan 2004 16:32:01 -0500, Jeff Schwab <je******@comcast.net>
wrote in comp.lang.c++:

Andrey Tarasevich wrote:

Jeff Schwab wrote:

...
I think initialized variables properly does more for readability than
making blocks of code look alike. Just my opinion, though.
...

In my opinion, separating initialization of loop variable from the loop
itself might create more problems than delayed intialization of a variable.

For instance?

See my reply up-thread.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Gary Labowitz]

"Jack Klein" <ja*******@spamcop.net> wrote in message
news:89********************************@4ax.com...
<<SNIP>>

Nothing against while loops, I use them myself quite frequently, or
even do ... while loops, more often than most.

But I don't like an important condition of the loop separated from the
control statement itself, both for conceptual reasons and also for the
above mentioned maintenance problem. If someone, someday, puts
something between the initialization or the assignment and the
corresponding loop, bang!

In your particular example, I would use the for loop because it allows
setting the initial value of the control variable, a necessary
requirement of the loop, to appear in the loop control logic.

We fought this problem of loop control for years in various shops and the
only bulletproof method we ever decided on was to use differently named loop
control variables in any block. While i, j, k seem traditional, presumably
left over from FORTRAN, it even makes for self-documenting code to use names
that mean something in the process being coded. Loop control variables like
addressVectorItem for referencing an address in a Vector of addresses I feel
is better than just i. Long, fluffy names, that's the ticket!
--
Gary

[E. Mark Ping]

In article <3f***********************@news.newshosting.com> ,
Ron Natalie <ro*@sensor.com> wrote:

"Pete Becker" <pe********@acm.org> wrote in message news:3F***************@acm.org...

> #define for if(false); else for

An even less intrusive workaround is to move the variable declaration
outside the loop:

int i;

Actually, I find that MORE intrusive. You have to put sloppy coding
practices in your code to correct for defects in the compiler.

You're saying that declaring the variable outside the loop is more
intrusive than using a macro to effectively redefine a language
keyword?

I find this baffling.
--
Mark Ping
em****@soda.CSUA.Berkeley.EDU

[Ron Natalie]

"E. Mark Ping" <em****@soda.csua.berkeley.edu> wrote in message news:bt***********@agate.berkeley.edu...

Actually, I find that MORE intrusive. You have to put sloppy coding
practices in your code to correct for defects in the compiler.

You're saying that declaring the variable outside the loop is more
intrusive than using a macro to effectively redefine a language
keyword?

I find this baffling.

I don't. The only thing I'm "redefining" here is making the keyword
behave like the language standard says it should. I pointed out that
it is technically wrong, but so is Microsoft, and I'd rather have standard
compliant code rather than Microsoft compliant code, we're portable
to platforms other than Windows.

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.

[Howard]

"Ron Natalie" <ro*@sensor.com> wrote in message
news:3f***********************@news.newshosting.co m...

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 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?

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.

Personally, I prefer to declare i within each loop construct, and then
change that specific piece of code when I port to VC++. 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!)

-Howard

[Ron Natalie]

"Howard" <al*****@hotmail.com> wrote in message news:bt********@dispatch.concentric.net...

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?
Because why permit it to be inadvertantly used in expressions in between
the unrelated loops you're stuck using it in. Terribly non-structured.
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
If it were not something that made sense to be shared, it should be destroyed.
But you're inventing issues, by default variables should be defined in the smallest
scope that encompasses their use. THIS IS JUST PLAIN GOOD C++ DESIGN.
Having to thwart that because Microsnot can't get it right isn't a good reason
to chage the design rules.
Personally, I prefer to declare i within each loop construct, and then
change that specific piece of code when I port to VC++. If I forget to
change it, the compiler tells me.

If you do what I suggested, you don't have to go bastardizing your code
just because you have the misfortune of using Microsnot's compiler.

[Howard]

Microsnot? I'm telling Bill on you! :-)

[Jeff Schwab]

Ron Natalie wrote:

<snip> macro redefining "for" to get around a non-compliance </>

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.

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]

Howard wrote:

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 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?

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?
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.
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.
Personally, I prefer to declare i within each loop construct, and then
change that specific piece of code when I port to VC++.
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.
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!)

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

[Ron Natalie]

"Jeff Schwab" <je******@comcast.net> wrote in message news:Bu********************@comcast.com...

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.

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.