Richard Kenner wrote:
On the other hand, C does not have a way to tell the compiler:
"this is my loop variable, it must not be modified inside the loop"
neither you can say:
"this is the upper bound of the loop, it must not be modified"
either.
No, but the compiler can almost always trivially determine that nothing in
the loop can modify the variable, so I'm not sure I understand your point.
My point in the quoted section is that:
1. A programmer can accidentally modify the loop variable, or bound.
It is more
difficult for a programmer to catch such bugs, if the language
does not help.
Having a true "for" syntax will help to catch such bug.
2. If there were a real "for" construct, there would be no question
of termination
in that common case. There would be no need to do the "overflow is
undefined"
hack.
Among other things, complex termination conditions make it
impossible to
figure out if the loop terminates. If a true "for" would have been
defined by C,
then the termination condition would be calculated and known in
advance:
FOR i:=0 TO foo()+1
BEGIN
....
END
We don't care if foo()+1 wraps to MIN_INT. It would be undefined to
have the
upper bound smaller than the lower bound. Wrapping semantics can be
used
everywhere.
Anyway, in most cases one knows the upper limit of the loop upfront.
Anyway, the main point of the complete mail was to propose semantics
that is
strong enough for the "speed is all" camp, and predictable enough for the
"real world code assumes wrapping" camp.
--
Michael Veksler
http:///tx.technion.ac.il/~mveksler
