Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!ginosko!uunet!pilchuck!dataio!bright
From: bright@Data-IO.COM (Walter Bright)
Newsgroups: comp.lang.c++
Subject: Re: scope of FOR
Message-ID: <2107@dataio.Data-IO.COM>
Date: 23 Aug 89 19:14:29 GMT
References: <1807@hcr.UUCP>
Reply-To: bright@dataio.Data-IO.COM (Walter Bright)
Organization: Data I/O Corporation; Redmond, WA
Lines: 38

In article <1807@hcr.UUCP> ron@hcrvx1.UUCP (Ron Irvine) writes:
<Being able to say "for(int i=0; i<100; ++i) ... " is
<just what I want when I am coding a loop.  However, I
<could not believe that C++ has defined the scope of the
<declared name (i in this case) to be "to the end of the
<block enclosing the for-statement"
<One problem with the current definition is that it
<reduces the possibility of optimizations since the
<variable may be used after the for statement.
<It also makes the job of detecting simple loops
<much harder since the declared variable must be tracked
<until the end of the enclosing scope.

There are well-known algorithms for detecting simple (and complex!) loops.
The algorithms work, even if you code your loops as a rat's nest of goto's.
The loop control variable(s) can be detected by analysis rather than looking
at the various parts of the 'for'.
A technique called 'live variable' analysis can be used to determine the
actual scope of a variable, regardless of which block it's declared in,
and whether a loop variable is used after exit from the loop or not.

I've implemented all this in an optimizer I wrote (for Zortech). The
algorithms work, I got them from Aho, Ullman, and Hennesy.

Declaring the loop variable in the for statement or elsewhere has *no effect*
on the ability of the optimizer to optimize the loop. (With the exception
that you really don't want the loop control variable to be global, because
of aliasing problems.) It's just a style issue for the programmer,
sort of like is "if (!i)" better than "if (i==0)".

Of course, there are some weak optimizers out there where the programmers
who implemented them read the wrong books!

<Bjarne could you please fix this.

No need to. I recommend that you read "Compilers, Principles, Techniques, and
Tools" by Aho, Sethi and Ullman. It's available in good university bookstores,
and even some chain bookstores.